111–120 of 140 posts
Earlier quoted context omitted.
Encoding settings metatag can be striped. Regardless, I don't think these software are "matching" anything. TMPGEnc for example has settings to choose what quality you want for these re-encoded frames.
The parameters being matched would be those that maintain decoder config. Usually, bitrate/quantizer values don't come into that.
Earlier quoted context omitted.
It's true, and I feel the same, but to give it some credit: wouldn't that apply to anything you don't use regularly? Programming languages or even regular languages. You have to use it or lose it.
If you don't perform a task frequently, a discoverable interface (e.g. GUI) is dramatically more productive than reading documentation.
One of the interesting things you can do with ffmpeg, if you have a LOT of scratch disk space, and you're trying to compare subjective encoder quality (not VMAF, but human eyeballs) on a certain video file: 1) take your raw uncompressed y4m file and write it out to a directory of PNG files, one png file per frame. this is your static image reference baseline for subjective eyeballs. 2) take your raw uncompressed y4m…
For example, x264 will “allocate” more data to parts of the image that change less, as those remain on screen longer so artifacts on them are more visible. While fast moving parts can be compressed into a blurry blocky haze as they appear for maybe 20 frames so few people will really notice artifacts.
(Of course the actual implementation is 100x more sophisticated and complex)
You are doing the opposite with PNG’s: focusing on quality of 1 frame instead of on the perceived quality of the frames when viewed as video.
Might have come in handy while I was struggling to type out ffmpeg -i part0.mp4 -i part1.mp4 -filter_complex "[1:v]scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2[v1]; [0:v] [0:a] [v1] [1:a] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" out.mp4 to concatenate two videos with different sizes today. My relation with it is almost identical to my relation with any bash scripting m…
I never had to use it since I never had anything complicated enough, but next time you relearn things, I've heard good things about ffmpeg-python [0] , it supports multiple inputs, outputs, custom filters, etc. Their example from the readme: ffmpeg -i input.mp4 -i overlay.png -filter_complex "[0]trim=start_frame=10:end_frame=20[v0];\ [0]trim=start_frame=30:end_frame=40[v1];[v0][v1]concat=n=2[v2];[1]hflip[v3];\ [v2][v…
Earlier quoted context omitted.
ffmpeg seeks accurately when transcoding. [1] Cutting on non-keyframes when stream copying results in broken video until the next keyframe. Handbrake does have a CLI. [2] I haven't used it and I'm not sure what advantage it might have over ffmpeg. I personally use mkvmerge or ffmpeg for my muxing/cutting and VapourSynth for encoding. [1] https://trac.ffmpeg.org/wiki/Seeking [2] https://handbrake.fr/docs/en/latest/cli…
Yeah, it is literally not possible to not seek to keyframe if you are stream copying. There are however, plenty of great software that can but at any frame and only re-encode the frames that are outside the whole GOP. Most of them are commercial though, I haven't find one that is free and good. ---- Also, seeking in FFMPEG in practice, is actually more complicated than the guide [1] you linked. Below is a note I keep…
Could you clarify what you mean with "use output seeking for -to"?
From your Python script it seems that you're just using input seeking and then specifying the duration in seconds with `-t`, which is actually the same as using `-to` when doing input seeking.
Also, input seeking should be inaccurate when doing stream copy, so I'm not sure your script actually works as expected?
(And unless I'm missing something, it seems that all of this is well-explained in the ffmpeg guide linked above.)
Thanks!
FFMPEG exposes a terrible API. Even something as simple as thumbnail extraction is overly complex and has a ton of pitfalls that you won't discover until a user uploads a weirdly encoded video.
A tangentially related question: I've always found FFMPEG-the-cli-program an amazing piece of software, incredibly powerful, versatile and well-made. I therefore expected the same when I had to interact with its library interface (i.e. libavcodec, libavformat) recently. How disappointing, and very frustrating an experience! The docs felt extremely thin and full of "ah yeah don't use the foo function afterall, it's since been replaced with foo_2 and foo_2really3forreal, but the docs don't mention it", and the API conventions seemed very random and inconsistent. Is it just me?
This is not a complaint; thank you to the people who spend their free time developing a free multimedia suite for me to use! I was just surprised about the perceived quality differences between FFMPEG-the-cli-program and FFMPEG-the-library.
Earlier quoted context omitted.
If you don't perform a task frequently, a discoverable interface (e.g. GUI) is dramatically more productive than reading documentation.
Conversely, if you perform a task frequently you want to be able to script it out and automate it away.
Something weird (IMO) about ffmpeg is that it doesn't do hardware-accelerated encoding or decoding by default unless you compile it with support and pass it some extra command line flags. If you are using ffmpeg with hardware-accelerated codecs like H.264, remember to take the free 10x speed boost!