121–130 of 140 posts
If this book does what it claims to do, it should probably cost more (pls raise the price after I buy it). I strongly believe that inside ffmpeg may be the secret to the cosmos, the universe and life itself
I just had to tangle with ffmpeg to stream some video from a spacecraft. I’m genuinely undecided as to which end of that problem was the more complicated one.
Earlier quoted context omitted.
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…
>The best of the two worlds is to use input seeking for -ss and then output seeking for -to. 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…
In my Python script, I did input seeking for -ss (start point) part, and then output seeking for -t part (end point). As you can see, the -ss part is before -i {inputfile}, and -t is after.
-ss 1:00 -i file -t 5
is NOT the same as
-ss 1:00 -t 5 -i file.
The latter has a bug that happens frequently when I'm trimming MPEG-TS files recorded from HDTV. It literally doesn't stop at the -t/-to timestamp for reason I don't know. And it only happens when stream copy.
Below is a quick showcase: t.ts is the source, and the filenames show how I generate them with FFMPEG (for example, ss_t_i means input seeking -ss first, then -i t.ts, then -t 1:00).
https://i.imgur.com/lLUSzEM.png
As you can see, if I use -t/-to before -i, it doesn't cut the file properly.
>Also, input seeking should be inaccurate when doing stream copy
Yeah, it's not frame accurate, can only cut at keyframes, but enough for my application. By the way the same inaccuracy exists for output seeking if you're doing stream copy.
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.
how is it ffmpeg's fault for a goofy user suppled input?
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.
FFMPEG's API is perfect for what it aims to provide. Not every program is built for every use-case. It's trivial to create helper scripts to provide a simpler API for simple tasks, in fact this is probably how FFMPEG and ImageMagick are most often used; in image, video editing programs and servers.
Earlier quoted context omitted.
>The best of the two worlds is to use input seeking for -ss and then output seeking for -to. 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 think I know where you're confused: from the guide it looks like there is only a difference where you put -ss; but in reality, where you put -t/-to matters too. In my Python script, I did input seeking for -ss (start point) part, and then output seeking for -t part (end point). As you can see, the -ss part is before -i {inputfile}, and -t is after. -ss 1:00 -i file -t 5 is NOT the same as -ss 1:00 -t 5 -i file. The…
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…
That's my relation with regex.
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 have to relearn it every time I want to engage with it That's my relation with regex.
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!
The speed boost isn't free, hardware accelerated encoders often can't compress as well as software encoders.
A video codec isn't a fixed rule book that all the encoders follow to get the same result, it's more akin to CSS: there are a bunch of tools you can use but there's no one way to combine them to get a particular result. If you want to make a chess board with HTML and CSS, just think of how many ways there are to do it, it's similar when it comes to video encoding.
So different encoders have different results but why would a hardware encoder compress worse than a software encoder? The answer is simple: a hardware encoder needs to be implemented in hardware. That comes with a ton of constraints that CPU encoders don't have to deal with, such as physical space on silicon, power, heat, limited memory and so on and so forth. This means that the encoder has to make compromises that a software encoder doesn't.
So how big is the difference? It depends a bit how you measure it but Moscow State University has a ton [0] of data about different encoders and just last year, they evaluated a bunch of hardware encoders [1] and compared them to software. You can see in their results [2] that relative to x264 (software, which happens to be ffmpeg's default), NVENC (NVIDIA's encoder, present on their GPUs) took 21.3% more bytes to produce the same subjective result.
[0]: https://www.compression.ru/video/codec_comparison/index_en.h...
[1]: https://www.compression.ru/video/codec_comparison/hevc_2020/...
Earlier quoted context omitted.
I just had to tangle with ffmpeg to stream some video from a spacecraft. I’m genuinely undecided as to which end of that problem was the more complicated one.
Please elaborate, is this a work or hobby project, which space craft?
1. https://www.rtl-sdr.com/rtl-sdr-tutorial-receiving-noaa-weat...
There are a myriad of StackOverflow questions, mailing lists, forums... but never a well structured and comprehensive analysis of this topic. And FFmpeg itself, while being a feat of a software project, has such a lackluster and incomplete doc.
I'd like to see a discussion about recovering H.264 and VP8 timestamps, with minimal processing (i.e. not transcoding, if possible, otherwise of course it becomes an easy thing), which covered the whys and whens of using these FFmpeg options:
• -fflags +genpts
• -fflags +igndts
• -vsync
• -copyts
• -use_wallclock_as_timestamps
Does this book cover these options and the topic of timestamp reconstruction?
