So i'm tried to reduce video filesize by scale down video -vf 640:-2, but nothing changes. Scale down or up doesnt affect video filesize
I've read ffmpeg wiki about Scaling but it dont have any information about scale and filesize.
When i'm scale down images, filesize have big drop but for video, nothing changes
You can use -crf option to reduce final video size.
The range of the CRF scale is 0–51, where 0 is lossless (for 8 bit only, for 10 bit use -qp 0), 23 is the default, and 51 is worst quality possible.
-crf 23 (for default)
You have to use H.264 encoder. this will help almost all type of video. works batter in mp4 videos.
Related
I create lots of 4K 60fps 3D animations, and every frame of these animations are exported as separate PNG files to my disk drive. These PNG files use their own lossless compression method, but the file sizes are still quite large (a 30 second animation can take anywhere between 4 and 18 GB). I'm interested in alternative lossless compression formats to reduce the file sizes even further.
The reason I'm interested in lossless compression is because I create a LARGE variety of animations, and lossy algorithms are not always consistent in terms of visual fidelity (what doesn't create visible artifacts for one animation might for another).
Do you have good recommendations for general purpose lossless video codecs that can achieve superior performance to storing the PNG frames individually?
So far, I have attempted to use h.265 lossless using ffmpeg:
ffmpeg -r 60 -i out%04d.png -c:v libx265 -preset ultrafast -x265-params lossless=1 OUTPUT.mp4
But the result was a 15.4GB file when the original PNG files themselves only took up 5.77 GB in total. I assume this was because, for this particular animation, interframe compression was far worse than intraframe compression, but I don't really know.
I understand that this is highly dependent on the content I'm attempting to compress, but I'm just hoping that I can find something that's better than storing the frames individually.
For lossless archival of RGB inputs, I suggest you try x264's RGB encoder.
ffmpeg -framerate 60 -i out%04d.png -c:v libx264rgb -qp 0 OUTPUT.mp4
I am trying to encode video with FFMPEG into H.265, but I have a problem with a weird stretching. Input video is 1920x1080 and output has the same resolution, but when I compare both images on same timestamp, encoded video seems to be stretched by few pixels (it is visibly wider on both sizes despite the fact resolution is same). It seems that this stretching introduces ugly bluriness in whole video. It seems like FFMPEG crop few pixels from left and right (probably black pixels at the edge of video) and stretches content to fill those missing pixels and preserve same resolution.
I did not find any way how to disable this behavior. I tried to change encoder from x265 to x264 to see if that is the problem, but result was still stretched.
I used this command line parameters:
ffmpeg -i input.mkv -c:v libx265 -preset medium -crf 23 -t 30 output.mp4
-t 30 is there to test result visual quality on small sample of length 30 seconds.
Does anyone have any idea why this happens and how to fix it? Most visual quality is lost because of this deformation and not because of recompression, which I proved by encoding with -crf 0, which is basically lossless and result was still blurred.
EDIT: Link to full console output: https://pastebin.com/gpMD5Qec
I need convert MP4 to webm with ffmpeg.
So, i use :
ffmpeg -i input.mp4 -c:v libvpx -crf 10 -b:v 1M -c:a libvorbis output.webm
But it's very long.
Is there faster ?
libvpx is a relatively slow encoder. According to the VP8 Encode Parameter Guide: Encode Quality vs. Speed, you can use the -cpu-used option to increase encoding speed. A higher value results in faster encoding but lower quality:
Setting a value of 0 will give the best quality output but is
extremely slow. Using 1 (default) or 2 will give further significant
boosts to encode speed, but will start to have a more noticeable
impact on quality and may also start to effect the accuracy of the
data rate control. Setting a value of 4 or 5 will turn off "rate
distortion optimisation" which has a big impact on quality, but also
greatly speeds up the encoder.
Alternatively, it appears that VA-API can be utilized for hardware accelerated VP8 encoding, but I have no experience with this.
I have slideshow video (i.e. 10GB) 1080p quality (30 FPS), and each image lasts about 15 seconds ...
Is there any option with FFMPEG, to convert those 15 seconds periods from 30 FPS(because they are just duplicate frames) into i.e. 1 fps, thus, making the video small size...
the only periods that should keep original FPS is the fadeout period from image to image (that lasts 3 seconds... they are not duplicate frames, each frame is different because of fade-out effect).
You just need to re-encode with ffmpeg using a mid CRF value, like between 24-27. I-frames will be smaller but mainly P-frames which are static will only take few dozen bytes to store. Actually decimating the static frames and keeping the fade sequences at full FPS can be done but will be cumbersome and subject to trial and error. Just doing a simple re-encode will get you most of the size savings you would have gotten
Basic command is
ffmpeg -i in.mp4 -crf 25 -c:a copy out.mp4
Our security system records and archives our IP cameras streams with ffmpeg -use_wallclock_as_timestamps 1 -i rtsp://192.168.x.x:554/mpeg4 -c copy -t 60 my_input_video.avi
I run it with crontab every minute so it creates videos of 60 seconds (~15Mb) for each camera every minute. When an intrusion occurs, the camera sends a picture through FTP and a script called by incrontab:
1- forwards immediately the picture by email
2- selects the video covering the minute the intrusion occured, compress it with h264 (to ~2,6Mb) and sends it by email
It is working really well but if a thief crosses the path of various cameras, the connection to the SMTP server is not fast enough so video emails are delayed. I'd like to compress the videos even more to avoid that. I could lower the resolution (640x480 to 320x240 for example) but sometimes 640x480 is handy to zoom on something which looks to be moving...
So my idea is to drop frames in the video in order to lower the filesize. I don't care if the thief is walking like a "stop motion Lego" on the video, the most important is I know there is someone so I can act.
mediainfo my_input_video.avi says Frame rate = 600.000 fps but it is of course wrong. FPS sent by IP cameras are always false because it varies with the network quality; this is why i use "-use_wallclock_as_timestamps 1" in my command to record the streams.
with ffmpeg -i my_input_video.avi -vcodec h264 -preset ultrafast -crf 28 -acodec mp3 -q:a 5 -r 8 output.avi the video is OK but filesize is higher (3Mb)
with ffmpeg -i my_input_video.avi -vcodec h264 -preset ultrafast -crf 28 -acodec mp3 -q:a 5 -r 2 output.avi the filesize is lower (2,2Mb) but the video doesn't work (it is blocked at the first frame).
Creating a mjpeg video (mjpeg = not interlaced frames) in the middle of the process (first exporting to mjpeg with less frames and then exporting to h264) creates same results.
Do you know how I can get my thief to walk like a "stop motion Lego" to lower the filesize to a minimum?
Thanks for any help
What are your constraints file size wise? 2.6MB for 60 seconds of video seems pretty reasonable to me, thats about 350kbps, which is pretty low for video quality.
You need to specify the video bitrate -b:v 125000 (125kbps, should drop you to about 900kb) to control the bitrate/s you want the video encoded at. Your not giving FFMpeg enough hints as to how you want the video handled, so its picking arbitrary values you don't like. As you drop the frame rate, its just using up the buffers allocating more bits to each frame. (one big thing you need to keep in mind with this is, as you stretch the video out over a longer time period the more likely the scene will change significantly require an I frame (full encoded frame vs frame based on previous frame) so reducing the frame rate will help some, but may not help as much as you'd think).
Your "(it is blocked at the first frame)." is most likely an issue with you trying to start decoding a stream when it is not at an I frame and not an issue with your settings.