Learn FFmpeg the hard way • Hacker News Board

Re: Learn FFmpeg the hard way

#31

Post by srcmap » Sat, Jan 20, 2018, 4:36 PM UTC

barrkel wrote: post #23

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.

I use ffmpeg to transcode video, perhaps 10,000 times in the past year (part of an automated pipeline). It has failed about 50 times or so, almost every failure down to corrupted input and not a crash per se. It has deadlocked about 200 times, often enough that my tools monitor the log file I redirect output to and restart the job if too long passes without progress. I'm amazed it's as stable as it is, given the comp…

Probably good to document those use cases, collect sample clips and contribute back back to the project as test cases.

Help improve the project for everyone.

Re: Learn FFmpeg the hard way

#32

Post by [deleted] » Sat, Jan 20, 2018, 4:36 PM UTC

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.

[deleted]

Re: Learn FFmpeg the hard way

#33

Post by billconan » Sat, Jan 20, 2018, 5:06 PM UTC

This is great! my experience with libav is very frustrating. There was no document/tutorial. The most useful thing was the example programs. but if a problem is not covered by the examples, then I would be doomed.

The worst part is that when the api doesn't work, you receive meaningless error messages. You don't know what's wrong.

Re: Learn FFmpeg the hard way

#34

Post by opticalflow » Sat, Jan 20, 2018, 5:36 PM UTC

All and all a good intro tutorial that gets into some of the common professional use cases. On "constant bitrate" assumptions and some of the subsequent discussion here, ANY transform-and-entropy codec like VP9 or H264 will ALWAYS be variable bitrate internally. In the pro broadcast world, where you can't go over your FCC-allocated radio frequency bandwidth allocation by even one iota (or nastygrams and fines ensue), this is "handled" by actually having the encoder understoot the actual target (say it's 5mbit), and then the stream is padded with null packets to get a nice even 5mbit/s. This also happens with LTE broadcast as well. The encoders that do this reliably are fabulously expensive and of a rackmount flavor.

Re: Learn FFmpeg the hard way

#35

Post by JustSomeNobody » Sat, Jan 20, 2018, 5:48 PM UTC

orev wrote: post #30

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…

Any tutorial will not get very far if every corner case is spelled out every time. The point of “learning” documents is to give enough concepts and useful information for the reader to have a basis to start building additional knowledge on top of. Getting into the weeds quickly derails this process.

I wouldn't consider options other than constant bit rate (variable bit rate) as corner cases, but your other points stand.

Re: Learn FFmpeg the hard way

#36

Post by bluedino » Sat, Jan 20, 2018, 6:21 PM UTC

opticalflow wrote: post #34

All and all a good intro tutorial that gets into some of the common professional use cases. On "constant bitrate" assumptions and some of the subsequent discussion here, ANY transform-and-entropy codec like VP9 or H264 will ALWAYS be variable bitrate internally. In the pro broadcast world, where you can't go over your FCC-allocated radio frequency bandwidth allocation by even one iota (or nastygrams and fines ensue),…

I'd love to hear more details about those things. I'm guessing it's not as simple as wiggling the quality around to keep the output within a certain size.

Re: Learn FFmpeg the hard way

#37

Post by qwerty456127 » Sat, Jan 20, 2018, 6:32 PM UTC

Why exactly do people call good explanatory manuals "the hard way"? The hard way to learn something is using nothing but the official reference manual or the man pages. What I have found by the link is what I would rather call "for dummies" :-)

Re: Learn FFmpeg the hard way

#38

Post by innagadadavida » Sat, Jan 20, 2018, 6:32 PM UTC

JustSomeNobody wrote: post #35

orev wrote: post #30

Earlier quoted context omitted.

Any tutorial will not get very far if every corner case is spelled out every time. The point of “learning” documents is to give enough concepts and useful information for the reader to have a basis to start building additional knowledge on top of. Getting into the weeds quickly derails this process.

I wouldn't consider options other than constant bit rate (variable bit rate) as corner cases, but your other points stand.

Parent said frame rate, not bitrate. They are orthogonal to each other.

Re: Learn FFmpeg the hard way

#39

Post by innagadadavida » Sat, Jan 20, 2018, 6:38 PM UTC

Xeoncross wrote: post #26

I would gladly donate to anyone that wants to statically bind this for use with Go. I really would love to see the power of FFmpeg open to more apps. I've used FFmpeg libs dynamically linked, but it requires FFmpeg be installed on the system.

IMO better to fork/exec ffmpeg to avoid memory leaks and security issues. The fork/exec takes a few microseconds and works well (you can even pipe it data). Of course, if the command line options doesn’t do what you want, that’s a different issue.

Re: Learn FFmpeg the hard way

#40

Post by aurelian15 » Sat, Jan 20, 2018, 6:38 PM UTC

I wrote a small wrapper library a decade ago that wraps the decoding capabilities of libavcodec/libavformat in way that makes it relatively easy to use from other programming languages (Pascal in this particular case)

https://github.com/astoeckel/acinerella

Note that this was one of the first C programs I ever wrote and the API is suboptimal (relies on structs being passed around instead of providing access via getter/setter functions). I don't really recommend that people use it, yet looking at the code might help people to get started with ffmpeg.

Also note that the libavcodev/libavformat libraries have gone a long way in terms of ease of use. If you have a look at the first versions of my wrapper library, it required really weird hacks (registering a protocol) to get a VIO interface (i.e. have callbacks for read, write, seek).

All that being said, today I usually just spawn subprocesses for ffmpeg/ffprobe if I need to read multimedia-files, and I think that for most server-side applications this is the best method (it also allows to sandbox ffmpeg/ffprobe).