@Andrius maybe its better if you first experiment with your own repo for some weeks before pushing to pixls to avoid breakage. There are plenty of resources - especially the Git Handbook and youtube. Happy to help if you run into trouble. Creating a git repo is easy.
Ok, I think I am online now:
https://github.com/AndriusWild/dam_scripts/blob/master/compress2mp4
I can pull changes from the web via git pull origin master but when I am trying to push them back from my PC to the server git push origin master I get a message Everything up-to-date but the changes are not being pushed back to git.
Does it matter how big the changes are? I just changed license from GPL to GPLv3 to check the functionality
Thatâs the one I made on the webpage. I was able to pull it from my laptop. But I canât push anything back to GitHub though⌠it says everything is up to date even though I know it is not
Hello, I figured out how to use GitHub and released v1.0-bash of my script called compress2mp4.
The main purpose of the script is compressing video files created by cameras and mobile phones to free up space on HDD.
Compression is lossy; output format is h.264; container is mp4.
Compression ratio really depends on the input file and is usually higher for MOV files created by digital cameras and Apple iPhones and lower for MP4 files created by Android phones (probably because Android already applied some sort of compression to them).
Script consists of few modules:
- Basic module - compress using ffmpeg. Constant Rate Factor set to 23 by default (the value recommended by FFmpeg team).
- Check compression ratio. If it is less than 1.5 the file will be re-compressed with CRF 26 (lower quality, lower output file size)
- Import [udta] atom from the original to the output using Bento4 SDK. This step required if you want to be able to see your compressed videos on the map from your Android phone. Apparently some information gets lost during the compression even though â-map_metadata 0â option is activated. For videos created by iPhones you will have to copy and paste the [meta] atom (moov/meta) instead.
- Verify GPS information of the output files using MediaInfo. Apparently ffmpeg is not able to catch the error.
- Write FileModifyDate from Quicktime Create Date. This step required if you want to see compressed videos in correct chronological order in digiKam. Apparently exiv2 which digiKam relies on is capable of reading metadata from some certain video formats only (none of the video files I had were detected correct).
- Delete temporary files and move originals to specified folder (I will be deleting originals from that folder after a year or so).
One can delete unwanted modules.
Future plans:
- Rewrite the script in python. Just because I want to learn python for my second hobby - automation where python being used extensively.
- Add an ability to write GPS information into sidecar xmp files that will be recognized by digiKam.
Special thanks to @Morgan_Hardwood who helped me to get started.
Any comments and critics are welcome.
Stay tuned for future releases!
1 Like
I created a service menu to launch the script:
[Desktop Entry]
Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=video/x-msvideo;video/quicktime;video/mpeg;video/mp4;
Icon=folder-video
Actions=compress2mp4
X-KDE-Priority=TopLevel
X-KDE-StartupNotify=false
X-KDE-Submenu=Video
[Desktop Action compress2mp4]
Name=Compress to mp4
Icon=video-mp4
Exec="\\$HOME/Scripts/Git/compress2mp4.sh" %F
But I keep getting this error:
Could not find the program '\$HOME/Scripts/Git/compress2mp4.sh'
It is weird because the same Exec line in .desktop file for âopen withâ menu works just fine.
Does anyone know what is the issue here?
You donât need \\ in front of $HOME.
I tried that but it did not do the trick.
Is the script executable? If not, chmod +x it end remove those two backslashes from the desktop file.
@Morgan_Hardwood while using your script with 422 material ffmpeg issued the advice
No pixel format specified, yuv422p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
Not saying thatâs something wrong with the script 
, but as I wanted a 420 x264, added the before mentioned -pix_fmt yuv420p. Not problem with 10bit streams ( AFAIK x264 also supports 10 bit) which gets the 8bit frog-mask 
On a side note, while the extra info _libx264_23_slow might be useful say if one encodes with different parameters and wants to remember or compare different versions, on a practical scenario becomes ânoiseâ; again this is just my personal view, but if Iâm delivering a light copy to someone the extra long tail is confusing. I guess that changing ${cv}_${crf}_${preset} to just _copy or _x264 would do the trick. Nevertheless I felt like giving user feedback and thank you for sharing it =)
ffmpeg version 3.3
OSX 10.11.6
PS
Also had an error with libfdk_aac, but that was a missing library from ffmpegâs compilation. brew install ffmpeg --with-fdk-aac solved it
You probably opened Morganâs script. Mine adds _x264 as I wanted. But again anyone can clone the project and modify it for their needs
Added later: Sorry I did not notice you were replying to Morgan.
Then your ffmpeg is not compiled with FAAC support. Try " -c:a aac -strict experimental" instead. I think you can actually drop â-strict experimentalâ in current version on ffmpeg
Yes, you can just delete _${cv}_${crf}_${preset}, but as you wrote âjust _copy or _x264 would do the trickâ it ends up being entirely a matter of taste.
420 has lower quality than 422. In 420 the chroma resolution is quartered, but in 422 itâs only halved (horizontally). I donât think supporting obsolete hardware should be the deciding factor regarding which option you use, unless you explicitly have that need. If you have no such need, considering its 2017, the deciding factor should probably be file size and quality. Do note that the casual observer is unlikely to notice a difference between the two.
Iâd encode my stuff in h.265.
Careful with this option - this does not necessarily yield better results, but can result in smaller filesizes for similar visual results. If filesize is not a problem, you can safely stick with x264 at a higher CRF.
1 Like
I donât think supporting obsolete hardware should be the deciding factor regarding which option you use, unless you explicitly have that need.
I guess that I wasnât clear or I kind of mixed my points, sorry about that.
On one hand ffmpegâs dialog is just that: use âthis optionâ to maximize compatibility; I wanted to let you know (case you hadnât seen it).
On the other hand that dialog also gives us the change needed to assure 8bit output regardless of sourceâs colour bit deph. I strive to hit a balance between small size, IQ and playability (hillbilly cousin). For previews and light copies a x264 420 8bit works 4 me. Most computers read it without hiccups and - as you mentioned - only the trained eye ( with a good enough screen) can tell the diff.
/// amend \\
As you and @patdavid mentioned x265, you can pack a lot in the same bag but it can also be tricky to deliver copies in x265 as some clients ( we talking mostly rodents) might not be able to play them. That said I often upload 10bit x265 files to vimeo, sometimes also to youtube (less frequent as in YT thereâs no filesize limit) and I always keep and deliver the masters in proRes 422 HQ.
Thank you and thanks pataD 
=)
@Andrius the libfdk_aac incompability was solved by brew compiling ffmpeg --with-fdk-aac thanks
BTW I also tried you script and works perfectly and output is just _x264 =) It has too many parts though 
Yep my script is a Frankenstein 
But it saves me tons of mouse clicks 
1 Like
Yes it is executable. I did try to remove the back slashes. It did not change anything. If I write /home/username instead there is a window pops up and closes right away but I canât catch what it is.
The script has been updated.
- Fixed - script does not work on Linux Mint (something wrong with the math)
- Minor fixes and improvements (mostly for Linux Mint)
1 Like