Learn FFmpeg the hard way • Hacker News Board

Re: Learn FFmpeg the hard way

#61

Post by ouid » Sat, Jan 20, 2018, 10:30 PM UTC

dfabulich wrote: post #60

ouid wrote: post #54

Earlier quoted context omitted.

what's wrong with presenting everything in the correct abstraction to start with? Whether you a public school math class, or a git tutorial online, you always get the same thing. A list of procedures for using the tools in the most common cases you are likely to encounter. This seems like a good idea in the move fast and break things ideology, but what do we notice about people's skills in the real world? No one know…

> what's wrong with presenting everything in the correct abstraction to start with? Nobody can retain the material that way. Each thing you learn has to be attached to other concepts you already have, and your skills build on one another. Nobody teaches Peano's axioms of arithmetic to kindergarteners; they're still learning how to identify shapes, to compare quantities. When they eventually learn even the simplest pr…

You're right, I shouldn't have said the correct abstraction, but you should at least provide a complete one. You don't have to build from the most fundamental possible assumptions to build from a set of tools that is provably complete for some domain of problems.

Doing otherwise is like giving someone a screwdriver that only turns clockwise.

Also, I challenge the notion that "no one can retain material that way". Have you ever met anyone who has retained the material any other way who didn't do it despite the system?

Re: Learn FFmpeg the hard way

#62

Post by dylan604 » Sat, Jan 20, 2018, 10:36 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),…

Reading this reminds me of all of the days spent using Manzanita MPEG software to get streams to "work". While its true that the bit rate may/will fluctuate, it was the muxing software that saves the stream. The muxer would introduce those null packets. The studio I used to write automated workflows for would get work specifically because we could make streams work that other facilities could not. Manzanita software was always the difference. Rarely, did an encoding software/hardware output work directly. However, remuxing the same elementary streams with Manz software would pretty much always solve the problem. If that didn't do it, it was probably a VBV buffer under/overflow issue around a scene change somewhere in the stream.

Oh gawd how I don't miss those days.

Re: Learn FFmpeg the hard way

#63

Post by dvirsky » Sat, Jan 20, 2018, 10:52 PM UTC

About 10 years ago I wrote a video encoding app with libavcodec/libavformat. Beyond very simple examples with everything set to default, there was almost zero material on how to use it. There was maybe one trivial example of decoding a file where all the parameters are guessed automatically. But I needed to encode a live video stream from a webcam. I spent a couple of weeks reading the code and hacking away until I got it right. I wish there was stuff like that back then.

Re: Learn FFmpeg the hard way

#64

Post by ouid » Sat, Jan 20, 2018, 11:34 PM UTC

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...

"all frame timestamps are monotonically increasing"

wow...

Re: Learn FFmpeg the hard way

#65

Post by rangibaby » Sat, Jan 20, 2018, 11:37 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…

> often enough that my tools monitor the log file I redirect output to and restart the job if too long passes without progress.

Do you mind sharing an example of how you accomplish this?

Re: Learn FFmpeg the hard way

#66

Post by zerokernel » Sat, Jan 20, 2018, 11:48 PM UTC

jsheard wrote: post #14

lovelearning wrote: post #10

Earlier quoted context omitted.

[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...

Honestly I don't quite know how or why engineers keep working in a "all of this is fundamentally broken always has been and never will be fixed" domain, on a motivational basis.

Re: Learn FFmpeg the hard way

#67

Post by mmanfrin » Sun, Jan 21, 2018, 12:38 AM UTC

Question related to FFMpeg: In the first few examples, there are input options defining the video and audio encoding -- why is this needed? Shouldn't a video container be self evident of things like that?

Re: Learn FFmpeg the hard way

#68

Post by kalimoxto » Sun, Jan 21, 2018, 12:46 AM UTC

mmanfrin wrote: post #67

Question related to FFMpeg: In the first few examples, there are input options defining the video and audio encoding -- why is this needed? Shouldn't a video container be self evident of things like that?

The video container of course tells you what codec the video is, but it can lie or be otherwise incorrect. FFMpeg will use what it says as the default, but you can override it if you'd like (or if you have multiple decoders for a given codec).

But yes, you're right. 99.9% of the time there's no need to specify input decoder library

Re: Learn FFmpeg the hard way

#69

Post by Teknoman117 » Sun, Jan 21, 2018, 12:57 AM UTC

Always wondered why there were never any stellar guides for the underlying libraries of FFmpeg. Had to do a couple of projects with hardware encoding and decoding and the best example I found of how to use it was ripping apart mpv. At least it has samples of how to use the hardware encode features...

Re: Learn FFmpeg the hard way

#70

Post by ourcat » Sun, Jan 21, 2018, 3:48 AM UTC

When ffmpeg came along nearly 20 years ago, it seemed to be the absolute video toolbox I was looking for.

It was, but you needed what seemed to be 'dark arts' to use it. And that took a long long time.

I owe years of my career to working out how to use this.