Working with Multi-media on Low Resource Computers

[mikeslr]

The discussion on this thread, https://www.forum.puppylinux.com/viewtopic.php?t=8001 provided the following tips for working with Multi-Media on computers with limited resources, i.e., RAM and CPU.

1. Locate your Puppy on a Linux Formatted partition, so that you can
2. Create a SaveFolder rather than a SaveFile on first shut-down.
3. Edit your boot menu to include the 'no-copy' argument; that is, if using grub4dos your kernel line should read:

kernel.... pfix=nocopy

if using grub2config,

linux.... pfix=nocopy

4. If you're Puppy is located on a hard-drive, Do NOT operate under PupMode 13 by editing your kernel line to include the pmedia=ataflash argument. Under the default PupMode 12 changes will be immediately written to your SaveFolder. Under PupMode13, changes are held in RAM until a Save is executed; thus occupying RAM.*

5. Create a sizeable swapfile or swap-partition. The 'Rule-of-Thumb' is twice the size of RAM**. To create a swap-partition you'll have to use gparted and perhaps resize existing partitions. To create a swapfile, just open a terminal and type 'pupswap' without the quotes. A GUI will open enabling you to select the size and drive/partition on which the swapfile is to be located. Your operating system will find and use a swap on any partition; even a Fat32 or ntfs.

5. Per ozsouth 'you MUST mount a hard drive partition & cd into that' or (generalizing ozsouth's instructions make it the destination for your project).

If you need to, don't hesitate to ask for specific instructions about the application you are want to use.

-=-=-=-=--
** This is contrary to the way I prefer running Puppys for security reasons. My recommendation would be to create two SaveFolders and two menu listings. One SaveFolder would include the term 'usual' in its name; the other 'media work'; the menu-arguments reflecting each SaveFolder's purpose. And on boot-up I'd decide which to use.

* A couple years ago I searched the web in an attempt to find a basis for this Rule-of-Thumb. I only was able to find one post which suggested that if the swap was greater than twice RAM the excess would just be ignored. Even at the time of my search that post was several years old. Since then both computers and operating systems have come a long way. There have been several posts by puppyans who have used swaps many times larger than twice RAM. So the bottom line is that a swap larger than twice RAM can't hurt; and at worst just wastes hard-drive space of which, today, most of us have more than we know what to do with.

[amethyst]

Create a SaveFolder rather than a SaveFile on first shut-down

That will take away the flexibility of running more than one Puppy on the same partition and also limit having your Puppy on a Linux formatted partition only.

[bigpup]

Create a SaveFolder

That will take away the flexibility of running more than one Puppy on the same partition

No it will not.

A save folder is just a folder like any other folder on the partition.

I have 14 different Puppy versions installed as frugal installs on the same partition.
All of them use their own specific save folder. 14 different ones.

Partition formats fat, ntfs do not allow making a save folder, because they are not Linux file systems.
Save file only works on those formats.

The type of save (file or folder) has no affect on how many different Puppy frugal installs, can be put on a partition.

[mikeslr]

It is the swap which can be on any partition without regard how it is formatted. It can even be on USB-Key. However, the reason for the swap is to provide a substitute for RAM and even the fastest hard-drive is still magnitudes slower than RAM; and reading from/ writing to even the fastest USB-Key is magnitudes slower than reading from/ writing to a hard-drive.

A swap may prevent your system from crashing. But you may grow old 'waiting for the paint to dry.'

I recall someone posting that when (s)he was engaged in a RAM-intensive operation it would be started as the last thing at night so that it would be completed by the morning. And that didn't involve using a USB-Key.

[amethyst]

Create a SaveFolder

That will take away the flexibility of running more than one Puppy on the same partition

No it will not.

A save folder is just a folder like any other folder on the partition.

I have 14 different Puppy versions installed as frugal installs on the same partition.
All of them use their own specific save folder. 14 different ones.

Partition formats fat, ntfs do not allow making a save folder, because they are not Linux file systems.
Save file only works on those formats.

The type of save (file or folder) has no affect on how many different Puppy frugal installs, can be put on a partition.

A save file also works on a linux formatted partition, save folder ONLY on a linux formatted partition. That's a severe disadvantage. If you are going to advise a new user to make use of a save folder, you will need to mention that he needs to create a linux formatted partition first. Can one use more than one save folder for the same distribution on the same partition or different partitions (linux formatted partitions) like having more than one save file (on any partition)? Is there any other advantage using a save folder rather than a save file, besides not having to resize it if need be.

[wizard]

@amethyst

Can one use more than one save folder for the same distribution on the same partition or different partitions (linux formatted partitions) like having more than one save file?

Yes, as with save files, they must each have a different name.

wizard

[amethyst]

@amethyst

Can one use more than one save folder for the same distribution on the same partition or different partitions (linux formatted partitions) like having more than one save file?

Yes, as with save files, they must each have a different name.

wizard

Okay, so I suppose on different partitions too (as long as it is linux formatted partitions)?

[wizard]

@amethyst

Okay, so I suppose on different partitions too (as long as it is linux formatted partitions)?

Yes, same as with save files, Puppy just has to know where to find them.

wizard

[amethyst]

Is there any other advantage using a save folder rather than a save file, besides not having to resize it if need be.

The size of the save file will be restricted to 4GB if on a fat32 partition I suppose, can't think of any other...Anyways, both save file and save folder methods are prone to corruption that's why I don't use it. Much better to save your changes to a read-only format.

[geo_c]

Is there any other advantage using a save folder rather than a save file, besides not having to resize it if need be.

The size of the save file will be restricted to 4GB if on a fat32 partition I suppose, can't think of any other...

The main advantage for me is the fact that a save folder can be accessed easily from any distro. I'm constantly grabbing files from one save folder and copying to another savefolder, like from KLV-airedale to fossapup. They can be accessed like any other folder on any drive. I never compress my backup saves or use savefiles because a folder is just easier to manage. The only advantage I see is in a savefile would be the ability to use it on fat32 or ntfs, or possibly not wanting to be able to access it without the use of an sfs load utility for privacy/security reasons.

[amethyst]

or possibly not wanting to be able to access it without the use of an sfs load utility for privacy/security reasons.

You don't need sfs_load to load a save file, it's not in a compressed, archived format. You only need to mount it to work with it (doing copying/pasting/editing), which wouldn't be a problem using any linux system.
I have never used a save folder: you can have more than one save folder for the same Puppy and you will be able to choose which one you want to use at bootup (or the option not to use any one) like with save files. Is this correct?

[wiak]

or possibly not wanting to be able to access it without the use of an sfs load utility for privacy/security reasons.

You don't need sfs_load to load a save file, it's not in a compressed, archived format. You only need to mount it to work with it (doing copying/pasting/editing), which wouldn't be a problem using any linux system.

Unless some extra utility is involved I don't think most filemanagers would be able to open a savefile simply by clicking on it they way they do with a normal folder? Yes, not difficult to open a terminal and mount the savefile (read-write) anyway, but the step is annoying compared to just using a directory.

Squashed filesystems (read-only) are a different matter - problem with them is that if an uncompressed filesystem is large, it takes time to compress using mksquashfs so if you have sufficient storage space better if you don't need to bother squashing filesystems up. Nowadays it is easy to add storage even to otherwise low resourced computers and low-powered computers work faster when using uncompressed or low-compressed filesystems anyway.

A savefile can in the course of using it get corrupted and sometimes, even if it uses a journal, fsck doesn't fix it and that's a problem. Even if something in a savefolder gets corrupted, that may well be just one file so whole save folder is rarely rendered useless. I'm pretty sure there is a speed penalty involved in using a savefile to store whole filesystem, though I don't know how much or how important that is in practice. I certainly also find it much more convenient to use a save folder than a savefile - one inconvenience is simply that a savefile has to first be constructed to a fixed size I think (though again a read-made utility can simplify that job and resize later). Qemu qcow2 type files are compressed I believe but they are not easily mounted (special software required) and not supported by the like of Puppy itself (when not for Qemu use). Some reported they were slower than bit-for-bit raw type files, but recent tests seem to suggest not much difference in performance and they compress very small and grow with usage. Would be maybe worth trying to use compressed qcow2 images as savefiles, but I don't know the ins and outs of how easy or possible that would be.

[rockedge]

one inconvenience is simply that a savefile has to first be constructed to a fixed size

What about the "sparse" disk/partition image? Using this the qcow2 size is dynamic with the max size it was formatted with being the limit. So only as big as the data stored in it. We should look more at the "sparse" images as the virtual HDD and see what, if any, advantages exist using a sparse image file.

[geo_c]

or possibly not wanting to be able to access it without the use of an sfs load utility for privacy/security reasons.

You don't need sfs_load to load a save file, it's not in a compressed, archived format. You only need to mount it to work with it (doing copying/pasting/editing), which wouldn't be a problem using any linux system.

Unless some extra utility is involved I don't think most filemanagers would be able to open a savefile simply by clicking on it they way they do with a normal folder? Yes, not difficult to open a terminal and mount the savefile (read-write) anyway, but the step is annoying compared to just using a directory.

That's it, you have to mount the savefile because it's something like a partition. I was using the wrong terminology when I said "load."

[amethyst]

you can have more than one save folder for the same Puppy and you will be able to choose which one you want to use at bootup (or the option not to use any one) like with save files. Is this correct?

I haven't seen anyone confirm this... I don't use a save file nor save folder so someone needs to confirm. The way I've been operating Puppy for years - I don't install stuff (except for small scripts) and use either application sfs's or portables (rarely). If you are going to use a save file, I suggest it to be very small and only to save system configurations. I save my system configurations to an adrv. It's normally about 5MB in size and takes a few seconds to create and replace my old adrv. In SA at the moment we have a power crisis. Stage 4 loadshedding everyday which means that the power will be off for about 4 hours a day, at least. My setup works perfectly with this sort of rubbish with no possibility of a corrupt save file/folder. I believe this is the safest way to operate Puppy.

[rockedge]

you can have more than one save folder for the same Puppy and you will be able to choose which one you want to use at bootup (or the option not to use any one) like with save files. Is this correct?

Yes this is correct. I use this feature a lot. During the first shutdown/reboot and setting up the save folder I will name it with an "A" suffix. If I want to create a new save folder and retain the first save folder "A", I reboot in RAM only mode which when shutdown/rebooted will again and prompt to save a new folder and I'll name that with a "B" suffix.

When I boot again into the system, during the boot, the cycle will stop and prompt the user which save folder to load and use. 1 is folder A and 2 is folder B with 0 as boot with no save folder loaded.

[geo_c]

you can have more than one save folder for the same Puppy and you will be able to choose which one you want to use at bootup (or the option not to use any one) like with save files. Is this correct?

Yes this is correct. I use this feature a lot. During the first shutdown/reboot and setting up the save folder I will name it with an "A" suffix. If I want to create a new save folder and retain the first save folder "A", I reboot in RAM only mode which when shutdown/rebooted will again and prompt to save a new folder and I'll name that with a "B" suffix.

When I boot again into the system, during the boot, the cycle will stop and prompt the user which save folder to load and use. 1 is folder A and 2 is folder B with 0 as boot with no save folder loaded.

In fact, I use this feature daily. It's one of the best things about puppy IMO. I run pupsave backup and save it in the system install directory at the same level as the working saving folder. Then I rename it to a shorter name as the time stamp gets a little long. At next boot I can choose either or none. The possibilities are endless with this system.

[amethyst]

Okay, so it works the same as save files then. If I would to choose between save folder and save file I would still prefer save file though (more options).

[wiak]

one inconvenience is simply that a savefile has to first be constructed to a fixed size

What about the "sparse" disk/partition image? Using this the qcow2 size is dynamic with the max size it was formatted with being the limit. So only as big as the data stored in it. We should look more at the "sparse" images as the virtual HDD and see what, if any, advantages exist using a sparse image file.

I didn't know you could make a Puppy save file of that type. That's why I mentioned sparse qcow2 format used by Qemu since it is dynamic as you say. What type of sparse savefile can Puppy use? - I've only read about people having to resize their savefiles. Maybe our posts crossed since I was adding bits at the end without writing EDIT and not checking other posts inbetween. But I'm pretty sure Puppy can't use qcow2?

[rockedge]

But I'm pretty sure Puppy can't use qcow2?

why not? A frugal install on a QEMU qcow2 virtual disk drive works. GParted and format the manage the partitions. We can mount sparse images and access them with Rox. There could be some wiggle room......

[wiak]

But I'm pretty sure Puppy can't use qcow2?

why not? A frugal install on a QEMU qcow2 virtual disk drive works. GParted and format the manage the partitions. We can mount sparse images and access them with Rox. There could be some wiggle room......

What I mean is that at present I don't think the Puppy initrd could use a qcow2 savefile in a normal frugal install situation. As far as I know you cannot use mount command to mount qcow2 in which case the initrd will be unable to mount it as a layer. Please let me know if I am wrong; maybe I made an error trying to mount one a few weeks ago, but seemed to me then a special utility was required to mount that file type.

[dimkr]

Puppy can use a sparse file as a save file. Sparse files have two main disadvantages, though - 1) not all file systems support them (FAT32 and exFAT don't) and 2) they only grow in size until they reach their size limit (download a 1 GB sized file while using a fresh, zero-size save file, then delete the downloaded file - the save files doesn't shrink by 1 GB): they allow you to use remaining space only if you use them carefully, a 4 GB sparse save file in a 4 GB partition will leave room for other files on the partition only if you make sure you never fill the save file with 4 GB of data (even if it's temporary).

[wiak]

Puppy can use a sparse file as a save file.
...

Interesting. I really know nothing much at all about sparse files except I noted that qcow2 files were compressed. I guess Puppy save files are uncompressed whether sparse or otherwise?

[trawglodyte]

If you work with video I can give you a few tips for lowering the file size of your videos or reducing bandwidth to stream.

You probably want to use the H264 codec, it's been around awhile and was the first really good compression codec for high-quality vids at a lower file size and is widely supported by software and internet platforms. There are advanced codecs such as HEVC/H265 and AV1, which can make even smaller file size at same quality but you would probably need fairly modern hardware/drivers and some software and internet platforms won't accept content made with them yet.

The frames per second setting is an old hack to reduce filesize. I read a lengthly explanation once, but there is a scientific reason why 24 fps is the magic number where it tricks our eyes into percieving it as fluid motion. These days people usually use 30 or 60. If you can get away with 24 you can cut file size and have a nice looking video. Downside, you don't have extra frames to drop. Other downside, software or internet sites may reprocess it to 30fps and if the technology they use to do that isn't good it may reduce the quality of your vid. Handing them a 30 fps might avoid that issue.

Your bitrate works in conjunction with your frame rate. For example @1920x1080 res a 30 fps vid will need approx 1200 kbps for the same visible quality as a 24 fps vid @ 1000kbps. (the same video @ 60fps would need approx 2400 kbps).

Bitrate is really a huge key if you want lower file-size lower-bandwidth videos, usually default settings have it way higher than you need it.

Resolution - This is not AS big of a deal as people think, but yes if you can get by with 1280x720 vs 1920x1080 it will help you reduce. If 854x480 works for you then use it. When I started dabbling in amateur online A/V we had 320x240 without good compression codecs and we were tickled to be able to do that!!

I will say it is hard for me to make a desktop video with easily legible text at less than 1280x720 though, and sites play nicer when I hand them 1920x1080 h264/AAC vid, so I just have to play with the bitrate on that format.

But it all depends on the person, for a popular streamer trying to make a living with their podcast or something of course you are willing to have a video 4X as large or use 4X the bandwidth for any slight improvement. But for me I just want to send a video to my friend who may have slow internet and I don't want her to wait 30 minutes to download it. Or I just want to post a video of my desktop showing how to do something that someone might find one day to solve their problem. I just need the text on the screen to be reasonably legible. I can make a video like that fairly small size, or stream at a much lower bitrate and get it done.

Container isn't that important, but probably .mp4 is most widely used and there are sites that don't like .mkv yet. The trend for the future as I see it is the following....

video codec h264 > h265/HVEC > AV1 (Apple has a different codec that is interesting and good too, I just don't know much about it)
audio codec AAC > libopus
container .mp4 > .mkv

These are really the most important ones, when you see long lists with dozens of codecs or containers, most of them you will never need and you can ignore.

[amethyst]

I find that zooming the screen of lower resolution video by up to 50% (on an HD monitor) screen works well and is useful for say 360P and 480P video. 24/25 frame rate can look very jerky on HD video with lots of "movement scenes", it's one of the common issues with most streaming sites.

[trawglodyte]

24/25 frame rate can look very jerky on HD video with lots of "movement scenes"

That's true, you can tell a difference, especially when there is a lot of motion like a sports scene. For recording a desktop, or a vid talking to a friend/family or something, it's usually indiscernable. But trust your eye, see what you think.