Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn FFmpeg the hard way

github.com

Post reply on HN
Print view View original

11–20 of 82 posts

Re: Learn FFmpeg the hard way

#11

Post by exikyut »

sbarre wrote: post #5

This looks pretty awesome.. I was hoping this was about the command-line tool, which is quite daunting to learn once you start getting into the filters and combining/merging multiple audio and video sources. In a recent project I eventually had to write a script to do 2 passes of ffmpeg after spending a good day trying to figure my way through all the filter documentation to do a 5-step process in one pass.. This isn…

The ffmpeg commandline tool is ultimately just a frontend to all the internals.

So understanding how everything works internally will translate directly to a better grasp on how to use ffmpeg at the commandline.

Even though this document is very new I now understand why fiddling with the PTS value in the filtergraph would slow down/speed up some video I was tinkering with a while back, for example.

Re: Learn FFmpeg the hard way

#12

Post by colund »

jiggunjer wrote: post #9
anonymfus wrote: post #6

>In summary this is the very basic idea behind a video: a series of pictures / frames running at a given rate. >Therefore we need to introduce some logic to play each frame smoothly. For that matter, each frame has a presentation timestamp (PTS) which is an increasing number factored in a timebase that is a rational number (where the denominator is know as timescale) divisible by the frame rate (fps). Constant framer…

In my experience even cameras with constant framerates aren't really constant, if you look at the timestamps the delay between frames typically varies a few (dozen) ms. So on average you might have 30fps, but if you sample a random second you might end up with 28-32 frames.

29.97?

Re: Learn FFmpeg the hard way

#13

Post by pselbert »

I’ve spent a large portion of the past month working with ffmpeg. We are using it to repair, concat, and mux an arbitrary number of overlapping audio and video streams recorded via WebRTC. While this sounds straight forward on the face of it, the interplay of filters and controls is impossible to predict without extensive experience.

To my knowledge ffmpeg is the only tool that could possibly do this. It took a whole lot of reading man pages, bug trackers, stack exchange and various online sources to stitch together the necessary info. This seems like a great resource to learn what the tool is really doing and skip scrambling for information so much.

Re: Learn FFmpeg the hard way

#14

Post by jsheard »

lovelearning wrote: post #10
anonymfus wrote: post #6

>In summary this is the very basic idea behind a video: a series of pictures / frames running at a given rate. >Therefore we need to introduce some logic to play each frame smoothly. For that matter, each frame has a presentation timestamp (PTS) which is an increasing number factored in a timebase that is a rational number (where the denominator is know as timescale) divisible by the frame rate (fps). Constant framer…

[1] is a useful list of such assumptions. Found it very handy when programming AV handling. [1]: https://haasn.xyz/posts/2016-12-25-falsehoods-programmers-be...

See also: this talk from a Vimeo engineer about the video encoding horrors they've encountered in the wild.

https://www.youtube.com/watch?v=cRSO3RtUOOk / https://speakerdeck.com/demuxed/things-developers-believe-ab...

Re: Learn FFmpeg the hard way

#15

Post by amelius »

Sidenote: over the years I haven't seen a Linux utility crash so often as ffmpeg; not by a wide margin. So when calling this library, it is probably wise to assume that it may not return.

Re: Learn FFmpeg the hard way

#16

Post by mythrwy »

pselbert wrote: post #13

I’ve spent a large portion of the past month working with ffmpeg. We are using it to repair, concat, and mux an arbitrary number of overlapping audio and video streams recorded via WebRTC. While this sounds straight forward on the face of it, the interplay of filters and controls is impossible to predict without extensive experience. To my knowledge ffmpeg is the only tool that could possibly do this. It took a whole…

FWITW I found a python library moviepy a lot easier to work with (although sometimes you still have to drop down to ffmpeg as it won't do everything ffmpeg can do).

Moviepy is basically an easy to use wrapper around ffmpeg and some other utilities like ImageMagick. Not as full featured, but one can get quite a long way with it.

Re: Learn FFmpeg the hard way

#17

Post by RBO2 »

spython wrote: post #4

I wrote about creating adaptive streaming over HTTP (MPEG-DASH) using ffmpeg and mp4box before [1]. It is nice to see that ffmpeg is incorporating more and more of the same features. Has anybody got ffmpeg to create HLS out of mp4 fragments as well? It would save some conversion time and space, since the same MP4 fragments could be used with the two different manifest files, DASH and HLS. Mp4box is not quite there ye…

I think they're almost there in two ways. 1) is https://github.com/gpac/gpac/issues/790. 2) is to extend FFmpeg to include the MP4Box muxer: http://www.gpac-licensing.com/signals/

Re: Learn FFmpeg the hard way

#18

Post by jamroom »

pselbert wrote: post #13

I’ve spent a large portion of the past month working with ffmpeg. We are using it to repair, concat, and mux an arbitrary number of overlapping audio and video streams recorded via WebRTC. While this sounds straight forward on the face of it, the interplay of filters and controls is impossible to predict without extensive experience. To my knowledge ffmpeg is the only tool that could possibly do this. It took a whole…

I'm sure you did, but just in case - did you checkout Sox?:

http://sox.sourceforge.net/

I've used both FFMpeg and SoX extensively for audio and have found SoX very useful on more than 1 occasion.

Re: Learn FFmpeg the hard way

#19

Post by mulvya »

amelius wrote: post #15

Sidenote: over the years I haven't seen a Linux utility crash so often as ffmpeg; not by a wide margin. So when calling this library, it is probably wise to assume that it may not return.

By utility, I assume you mean the CLI binary. There have been issues with filtergraph buffer management in the past year or so, but other than that, ffmpeg rarely crashes. What sort of commands crash for you?

Re: Learn FFmpeg the hard way

#20

Post by spython »

RBO2 wrote: post #17
spython wrote: post #4

I wrote about creating adaptive streaming over HTTP (MPEG-DASH) using ffmpeg and mp4box before [1]. It is nice to see that ffmpeg is incorporating more and more of the same features. Has anybody got ffmpeg to create HLS out of mp4 fragments as well? It would save some conversion time and space, since the same MP4 fragments could be used with the two different manifest files, DASH and HLS. Mp4box is not quite there ye…

I think they're almost there in two ways. 1) is https://github.com/gpac/gpac/issues/790 . 2) is to extend FFmpeg to include the MP4Box muxer: http://www.gpac-licensing.com/signals/

Thanks for the links. Yes, the gpac dev version is close to have a working solution - https://github.com/gpac/gpac/issues/772

Not quite sure what the signals project strives to be. Is it a framework for commercial applications built on top of gpac?

Post reply on HN