RAM boot for video editing - some questions
- bark-woof-fetch
- Posts: 29
- Joined: Mon 18 May 2020, 09:50
RAM boot for video editing - some questions
Lots of newbie confusion re. SFS and PET and PKG and so on here.
Single purpose dog use case:
* kdenlive / olive / shotcut for video editing
* inkscape and mypaint for graphics.
* simple stuff, 5-20 minutes videos, 2-3 tracks, nothing fx heavy
* 16gb USB drive doghouse
* video footage and archive located on either laptop drive or another USB (2) drive
* to be used on 2 different laptops, one i5, 12gb RAM, BIOS; the other i7, 6gb RAM, UEFI. Maybe try the old Chromebook in the closet as well (Celeron something, 4gb RAM). Neither with beefy GPU.
* idea: blast the dog into RAM on boot and give the editors all the speed of the RAM disk.
* goal: keep video editors and settings separate from other daily distros. Easy switch between current and coming hardware.
Is that doable or even recommendable?
So far I've only tried BusterDog (and antiX) live sessions into RAM, the editors and their plugins pull in 2-300mb at least from Debian repos. They fly nicely but may flood the RAM easily upon longer use?
Does it make sense to compress them for this purpose? Or is there better way somewhere among all the puppys?
Any advice highly appreciated,
thanks!
/IRC: ctrlshiftPrhaps
Single purpose dog use case:
* kdenlive / olive / shotcut for video editing
* inkscape and mypaint for graphics.
* simple stuff, 5-20 minutes videos, 2-3 tracks, nothing fx heavy
* 16gb USB drive doghouse
* video footage and archive located on either laptop drive or another USB (2) drive
* to be used on 2 different laptops, one i5, 12gb RAM, BIOS; the other i7, 6gb RAM, UEFI. Maybe try the old Chromebook in the closet as well (Celeron something, 4gb RAM). Neither with beefy GPU.
* idea: blast the dog into RAM on boot and give the editors all the speed of the RAM disk.
* goal: keep video editors and settings separate from other daily distros. Easy switch between current and coming hardware.
Is that doable or even recommendable?
So far I've only tried BusterDog (and antiX) live sessions into RAM, the editors and their plugins pull in 2-300mb at least from Debian repos. They fly nicely but may flood the RAM easily upon longer use?
Does it make sense to compress them for this purpose? Or is there better way somewhere among all the puppys?
Any advice highly appreciated,
thanks!
/IRC: ctrlshiftPrhaps
Last edited by bark-woof-fetch on Mon 18 May 2020, 12:05, edited 1 time in total.
- bark-woof-fetch
- Posts: 29
- Joined: Mon 18 May 2020, 09:50
My experience with video editing is fairly limited, but I have found that disk speed does bugger all to the speed of things. Booting to RAM has great advantages, but ultimately, the CPU can only process things at a rate (generally) much slower than any disk.
To clarify my experience, I have seen zero difference between HDD & SSD for video editing, haven't tried full ram disk.
I'd bet saving RAM for RAM rather than ramdisk would be advantageous
To clarify my experience, I have seen zero difference between HDD & SSD for video editing, haven't tried full ram disk.
I'd bet saving RAM for RAM rather than ramdisk would be advantageous
Booted normally.
A Puppy version, installed as a frugal install or a live USB stick or CD install, is running loaded into RAM.
The only part of the install, that is not loaded into RAM, is the save file/folder. It just gets mounted into the file system.
As soon as you access something that is totally in the save. For example a program you installed. That program is loaded into RAM.
So, running a Puppy frugal install is the way to go. Booting it as a normal boot.
If you boot using the boot loader entry pmedia=usbflash it will give you total control of the save and how it works.
pmedia= is usually, in the kernel line or append line, of the boot loader menu entry.
Just edit the menu config file to change pmedia=
This actually makes the save mount normally, but for changes, it uses a RAM disk to hold these changes, until told to write to the save file/folder.
Could be set to write to save:
At a specific time period.
When you click on save icon.
Save at shutdown.
Even ask if you want to save at shutdown.
Some of the save options are in Puppy Event Manager->Save Session
Tbe pmedia= will control which ones are changeable.
pmedia=usbflash will make all available.
A Puppy version, installed as a frugal install or a live USB stick or CD install, is running loaded into RAM.
The only part of the install, that is not loaded into RAM, is the save file/folder. It just gets mounted into the file system.
As soon as you access something that is totally in the save. For example a program you installed. That program is loaded into RAM.
So, running a Puppy frugal install is the way to go. Booting it as a normal boot.
If you boot using the boot loader entry pmedia=usbflash it will give you total control of the save and how it works.
pmedia= is usually, in the kernel line or append line, of the boot loader menu entry.
Just edit the menu config file to change pmedia=
This actually makes the save mount normally, but for changes, it uses a RAM disk to hold these changes, until told to write to the save file/folder.
Could be set to write to save:
At a specific time period.
When you click on save icon.
Save at shutdown.
Even ask if you want to save at shutdown.
Some of the save options are in Puppy Event Manager->Save Session
Tbe pmedia= will control which ones are changeable.
pmedia=usbflash will make all available.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
- Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
@ bark-woof-fetch:-
Hallo, and to the 'kennels'.
Yah; I see the idea. Run Puppy completely in RAM, and just use 'temporary' or (better still) 'portable' packages. Workable....do-able.
I agree with Flash. The amount of RAM is going to be a relevant issue here, 'cos video-editing can use a huge amount of resources. I'm also going to recommend you use Bionicpup64, because almost everything you want is going to be 64-bit only.....
And bigpup is of course correct; when you have sufficient RAM, the whole of Puppy gets loaded into, and runs in RAM for the duration of the session anyway. This is Pup's 'secret weapon', and why she does run so blazingly fast (especially on modern hardware!)
--------------------------------------
I can help with these.
There's this package format called the AppImage. It's kinda like the Linux equivalent to the Windows PortableApp. The idea is, you download it; you make it executable - run 'chmod +x' on it - and simply click on it to run.....
Okay. Now; video editors:-
Shotcut's an easy one. Just download the AppImage from the Shotcut website:-
DIRECT LINK
Olive - To the best of my knowledge, nobody has yet got this one working in Puppy. Doesn't mean they won't, just that it hasn't happened yet...
KDEnlive - Yah, we can do this. Fancy having OpenShot thrown in as well? Forum member O.F.I.N.S.I.S has recently put together an SFS package - you 'load' these into Puppy, so again, it's not permanent - for both of these that actually works! KDEnlive & Openshot are usually available as AppImages, but we can't normally get 'em to work; I don't know what O.F.I.N.S.I.S has done, but both of them just work OOTB after loading the SFS.
I've used this SFS as the basis for 'Media Pup 8.0', a multimedia Puppy I built myself using Bionicpup64 8.0, and utilising mostly AppImages.
You can find the SFS for these two video editors here, at my Google Drive (I can't remember where the post with the link was now, 'cos it was buried away in the middle of an unrelated thread.....so I've uploaded it):-
https://drive.google.com/file/d/1BOAKxo ... sp=sharing
-----------------------------------------
Graphics stuff:-
Inkscape - You can find the latest release as an AppImage here:-
DIRECT LINK
MyPaint - Again, download as an AppImage from here:-
DIRECT LINK
And - as a 'bonus' - I'm going to throw in the latest release of the G.I.M.P, too!
DIRECT LINK
See if that little lot help. Let us you know how you get on with the 'project', please. Any probs, we're always here....
Mike.
Hallo, and to the 'kennels'.
Yah; I see the idea. Run Puppy completely in RAM, and just use 'temporary' or (better still) 'portable' packages. Workable....do-able.
I agree with Flash. The amount of RAM is going to be a relevant issue here, 'cos video-editing can use a huge amount of resources. I'm also going to recommend you use Bionicpup64, because almost everything you want is going to be 64-bit only.....
And bigpup is of course correct; when you have sufficient RAM, the whole of Puppy gets loaded into, and runs in RAM for the duration of the session anyway. This is Pup's 'secret weapon', and why she does run so blazingly fast (especially on modern hardware!)
--------------------------------------
I can help with these.
There's this package format called the AppImage. It's kinda like the Linux equivalent to the Windows PortableApp. The idea is, you download it; you make it executable - run 'chmod +x' on it - and simply click on it to run.....
Okay. Now; video editors:-
Shotcut's an easy one. Just download the AppImage from the Shotcut website:-
DIRECT LINK
Olive - To the best of my knowledge, nobody has yet got this one working in Puppy. Doesn't mean they won't, just that it hasn't happened yet...
KDEnlive - Yah, we can do this. Fancy having OpenShot thrown in as well? Forum member O.F.I.N.S.I.S has recently put together an SFS package - you 'load' these into Puppy, so again, it's not permanent - for both of these that actually works! KDEnlive & Openshot are usually available as AppImages, but we can't normally get 'em to work; I don't know what O.F.I.N.S.I.S has done, but both of them just work OOTB after loading the SFS.
I've used this SFS as the basis for 'Media Pup 8.0', a multimedia Puppy I built myself using Bionicpup64 8.0, and utilising mostly AppImages.
You can find the SFS for these two video editors here, at my Google Drive (I can't remember where the post with the link was now, 'cos it was buried away in the middle of an unrelated thread.....so I've uploaded it):-
https://drive.google.com/file/d/1BOAKxo ... sp=sharing
-----------------------------------------
Graphics stuff:-
Inkscape - You can find the latest release as an AppImage here:-
DIRECT LINK
MyPaint - Again, download as an AppImage from here:-
DIRECT LINK
And - as a 'bonus' - I'm going to throw in the latest release of the G.I.M.P, too!
DIRECT LINK
See if that little lot help. Let us you know how you get on with the 'project', please. Any probs, we're always here....
Mike.
- bark-woof-fetch
- Posts: 29
- Joined: Mon 18 May 2020, 09:50
great stuff! thanks everyone, plenty to chew on there for a start.
I've only tried BusterDog so far, its boot options (att.) resembled other tryouts with SLAX and antiX, the persistence/frugal/RAM boot options seems similar and spot on for what I'm going for. (not sure if antiX compress frugal save files though but nevermind that for now)
I did try kdenlive and olive appimages and flatpaks elsewhere with varying success, to be tested in Bionicpup64 and BusterDog soon, great if it works out of the box (or container). Thanks for the SFS re-upload Mike.
Kdenlive can do proxy editing of hi-res footage, scaling it down to half size or less during editing and then render in full resolution only at the last step. So maybe the proxies can be loaded in the RAM disk as well for more boost without throttling the general OS.
There are also varying factors on the diff. editors' pull in RAM vs CPU vs GPU that could change the setup, will have to experiment with that anyway.
Interesting project so far, your feedback is truly appreciated, woof!
(believe it or not, I literally let the dog out during writing of this post)
I've only tried BusterDog so far, its boot options (att.) resembled other tryouts with SLAX and antiX, the persistence/frugal/RAM boot options seems similar and spot on for what I'm going for. (not sure if antiX compress frugal save files though but nevermind that for now)
I did try kdenlive and olive appimages and flatpaks elsewhere with varying success, to be tested in Bionicpup64 and BusterDog soon, great if it works out of the box (or container). Thanks for the SFS re-upload Mike.
Kdenlive can do proxy editing of hi-res footage, scaling it down to half size or less during editing and then render in full resolution only at the last step. So maybe the proxies can be loaded in the RAM disk as well for more boost without throttling the general OS.
There are also varying factors on the diff. editors' pull in RAM vs CPU vs GPU that could change the setup, will have to experiment with that anyway.
Interesting project so far, your feedback is truly appreciated, woof!
(believe it or not, I literally let the dog out during writing of this post)
- Attachments
-
- BusterDog-openbox_jwm-2019-12-29_64-bit---boot.PNG
- (44.12 KiB) Downloaded 117 times
-
- Posts: 159
- Joined: Sun 01 Mar 2020, 16:17
- Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
@ bark-woof-fetch:-
I've just tried the Olive AppImage in Media Pup 8.0 (Bionic64-based.) It drops out with a segfault, unfortunately. Mind you, don't be disheartened; this project is in its infancy (it only started last year).....and not everybody has got the hang of building AppImages properly yet, believe me.
Mike.
I've just tried the Olive AppImage in Media Pup 8.0 (Bionic64-based.) It drops out with a segfault, unfortunately. Mind you, don't be disheartened; this project is in its infancy (it only started last year).....and not everybody has got the hang of building AppImages properly yet, believe me.
Mike.
- bark-woof-fetch
- Posts: 29
- Joined: Mon 18 May 2020, 09:50
brief bionic test run notes:Mike Walsh wrote:@ bark-woof-fetch:-
Shotcut's ...download the AppImage from the Shotcut website:-
DIRECT LINK
Olive - To the best of my knowledge, nobody has yet got this one working in Puppy. Doesn't mean they won't, just that it hasn't happened yet...
KDEnlive - Yah, we can do this. Fancy having OpenShot thrown in as well? Forum member O.F.I.N.S.I.S has recently put together an SFS package - you 'load' these into Puppy, so again, it's not permanent - for both of these that actually works! KDEnlive & Openshot are usually available as AppImages, but we can't normally get 'em to work; I don't know what O.F.I.N.S.I.S has done, but both of them just work OOTB after loading the SFS.
https://drive.google.com/file/d/1BOAKxo ... sp=sharing
...
Inkscape - You can find the latest release as an AppImage here:-
DIRECT LINK
MyPaint - Again, download as an AppImage from here:-
DIRECT LINK
And - as a 'bonus' - I'm going to throw in the latest release of the G.I.M.P, too!
DIRECT LINK
kdenlive 18.08.2 was in Quickpet but yours may have some libs on top as it played more file formats OOTB.
The 20.07.70 appimage complained about missing session dbus something...
Olive is missing Qt_5.11, skipping that for now.
Shotcut ran but couldn't play any testfiles thrown at it.
OpenShot couldn't import any files without crashing. Don't troubleshoot on my behalf, just a note.
GIMP and Inkscape flew and picked up my digitizer pen with no fuss.
MyPaint came up, picked up digitizer with some latency between pen press and line on the screen, still usable, perhaps fixable.
In any case:
SFS-Load on the fly seems to work like loading of .sb modules in SLAX so that's handy and the load/unload GUI with run option for one of the apps is 95% more userfriendly.
Even with appimages or flatpaks failing there are still .sfs installs as a DIY container option if I understood that correctly. So I'm not too concerned about that part.
Are there any RAM/performance considerations though? They all end up in the same RAM disk I guess, no matter how or from where they're launched?
Generally genuinely truly impressed about Puppy 2020, the pop up wizards and step by step info notes are spot on, great great work.
Underdog Distro, incredible stuff.
Xorgwizard, amazing
JWM wonderfully retro 90s and perfect for some familymembers.
tbc
-
- Posts: 159
- Joined: Sun 01 Mar 2020, 16:17
On my OS Openshot doesn't crash when importing files. Tried to import via the Menu also as well as per drag'n'drop.OpenShot couldn't import any files without crashing. Don't troubleshoot on my behalf, just a note.
This is equal in version 2.4.1 (the .sfs version) and 2.5.1. (the AppImage version)
Probably your OS is missing some stuff that I have installed in my base .sfs or you might have something installed that is conflicting with Openshot.
I don't use save files and/or save directories in general. So, everything works fine on my OS.
Our Future Is Not Set In Stone
[url]https://www.youtube.com/channel/UCyfyaxCNMduwyXlQFRQKhhQ[/url]
[url]https://soundcloud.com/user-633698367[/url]
[b]My own build of Bionic64[/b]
[url]https://www.youtube.com/channel/UCyfyaxCNMduwyXlQFRQKhhQ[/url]
[url]https://soundcloud.com/user-633698367[/url]
[b]My own build of Bionic64[/b]
- bark-woof-fetch
- Posts: 29
- Joined: Mon 18 May 2020, 09:50
What's the difference or advantage compared to .sfs?Mike Walsh wrote:@ bark-woof-fetch:-
I've used this SFS as the basis for 'Media Pup 8.0', a multimedia Puppy I built myself using Bionicpup64 8.0, and utilising mostly AppImages.
Reckon that appimages to deal with all video editing f.ex, or a .sfs with the same apps and libs, can easily pull 500+mb that you might not need in every session?
Vice versa for any other 'suites' for audio and imaging and so on. Curious about your setup and experiences there
- bark-woof-fetch
- Posts: 29
- Joined: Mon 18 May 2020, 09:50
thanks for checking, I'll have to dig deeper to get it all set up. OpenShot looks fine btw so that's good to know should kdenlive or shotcut or olive tap out during the battleO.F.I.N.S.I.S. wrote:On my OS Openshot doesn't crash when importing files. Tried to import via the Menu also as well as per drag'n'drop.OpenShot couldn't import any files without crashing. Don't troubleshoot on my behalf, just a note.
This is equal in version 2.4.1 (the .sfs version) and 2.5.1. (the AppImage version)
Probably your OS is missing some stuff that I have installed in my base .sfs or you might have something installed that is conflicting with Openshot.
I don't use save files and/or save directories in general. So, everything works fine on my OS.
- bark-woof-fetch
- Posts: 29
- Joined: Mon 18 May 2020, 09:50
thanks, got it, appreciate the write-upbigpup wrote:Booted normally.
A Puppy version, installed as a frugal install or a live USB stick or CD install, is running loaded into RAM.
The only part of the install, that is not loaded into RAM, is the save file/folder. It just gets mounted into the file system.
As soon as you access something that is totally in the save. For example a program you installed. That program is loaded into RAM.
So, running a Puppy frugal install is the way to go. Booting it as a normal boot.
If you boot using the boot loader entry pmedia=usbflash it will give you total control of the save and how it works.
pmedia= is usually, in the kernel line or append line, of the boot loader menu entry.
Just edit the menu config file to change pmedia=
This actually makes the save mount normally, but for changes, it uses a RAM disk to hold these changes, until told to write to the save file/folder.
Could be set to write to save:
At a specific time period.
When you click on save icon.
Save at shutdown.
Even ask if you want to save at shutdown.
Some of the save options are in Puppy Event Manager->Save Session
Tbe pmedia= will control which ones are changeable.
pmedia=usbflash will make all available.
- Attachments
-
- Puppy Event Manager.PNG
- (189.72 KiB) Downloaded 64 times
-
- Posts: 159
- Joined: Sun 01 Mar 2020, 16:17
No, Openshot simply can't beat Kdenlive.OpenShot looks fine btw so that's good to know should kdenlive or shotcut or olive tap out during the battle
Kdenlive not only is my favorite video editor, it's also the best video editor I could get to work in Puppy Linux.
If I couldn't get Kdenlive to work, I probably would use another OS for video editing. But then, only for video editing. Everything else works pretty well in Puppy, so I don't want to use another OS for sure.
Our Future Is Not Set In Stone
[url]https://www.youtube.com/channel/UCyfyaxCNMduwyXlQFRQKhhQ[/url]
[url]https://soundcloud.com/user-633698367[/url]
[b]My own build of Bionic64[/b]
[url]https://www.youtube.com/channel/UCyfyaxCNMduwyXlQFRQKhhQ[/url]
[url]https://soundcloud.com/user-633698367[/url]
[b]My own build of Bionic64[/b]
-
- Posts: 159
- Joined: Sun 01 Mar 2020, 16:17
What's the format of this recorded Video?p310don wrote:I have had the same when using video off my Sony camera. If I convert the file to another format, openshot doesn't die on import.
I had tested with all formats that I have locally existing, which is:
.mpg, .mp4, .mov, .mkv and .avi.
Edit:
@all who experienced this problems
Are you trying to import directly from the camera's storage?
I'm generally copying such videos to my hard drive first.
Our Future Is Not Set In Stone
[url]https://www.youtube.com/channel/UCyfyaxCNMduwyXlQFRQKhhQ[/url]
[url]https://soundcloud.com/user-633698367[/url]
[b]My own build of Bionic64[/b]
[url]https://www.youtube.com/channel/UCyfyaxCNMduwyXlQFRQKhhQ[/url]
[url]https://soundcloud.com/user-633698367[/url]
[b]My own build of Bionic64[/b]
- Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
@ O.F.I.N.S.I.S:-
Have to agree here. Much more straight-forward to transfer them to computer storage first, so they're 'on the system', so to speak.
Everything will work as it should then.
Mike.
Have to agree here. Much more straight-forward to transfer them to computer storage first, so they're 'on the system', so to speak.
Everything will work as it should then.
Mike.
Last edited by Mike Walsh on Wed 20 May 2020, 08:42, edited 1 time in total.
- bark-woof-fetch
- Posts: 29
- Joined: Mon 18 May 2020, 09:50
I'm no video file handler veteran at all but can't imagine nor have ever experienced that a file copy directly from phone or camera mass storage would change its format or encoding.Mike Walsh wrote:@ O.F.I.N.S.I.S:-
Have to agree here. Much more-straight-forward to transfer them to computer storage first, so they're 'on the system', so to speak.
Everything will work as it should then.
Nowadays most consumer cameras will encode in H264 IIRC. If not then maybe in some kind of OEM proprietary format which would then involve a software converter (Win/Mac only probably) of some sort
Ofc you don't want to use the camera SD card as raw file folder in the video editor anyway but I don't think we'd misunderstand each other on that part
Lots of unknowns here, sorry for the noise, workarounds a plenty to figure that out later on
Last edited by bark-woof-fetch on Tue 19 May 2020, 18:00, edited 1 time in total.
Suspect codec problem under Openshot 2.4.3 component.
Hi bark-woof-fetch,
Your post lead me to do some testing. I've posted a discussion of the results, set out in the title of this post, to the thread on which O.F.I.N.S.I.S. linked his combined Openshot-KDEnlive SFS. http://murga-linux.com/puppy/viewtopic. ... 23#1058423
A couple things worth noting here: 666philb, creator of Bionicpup64, found that while Openshot worked well under Xenialpup64, there were problems under Bionicpup64 so KDEnlive was recommended and immediately available via quickpet. Mike Walsh, however, was able to provide a recipe for using Xenialpup64's Openshot 1.4.3. See above post for link to recipe and my SFS using it. It did not have the problems manifested by Openshot 2.4.3.
I don't know how much any of the above carries over to any of the 'Debian Dogs,' especially BusterDog.
Your post lead me to do some testing. I've posted a discussion of the results, set out in the title of this post, to the thread on which O.F.I.N.S.I.S. linked his combined Openshot-KDEnlive SFS. http://murga-linux.com/puppy/viewtopic. ... 23#1058423
A couple things worth noting here: 666philb, creator of Bionicpup64, found that while Openshot worked well under Xenialpup64, there were problems under Bionicpup64 so KDEnlive was recommended and immediately available via quickpet. Mike Walsh, however, was able to provide a recipe for using Xenialpup64's Openshot 1.4.3. See above post for link to recipe and my SFS using it. It did not have the problems manifested by Openshot 2.4.3.
I don't know how much any of the above carries over to any of the 'Debian Dogs,' especially BusterDog.