Learn FFmpeg the hard way • Hacker News Board

Re: Learn FFmpeg the hard way

#21

Post by djsumdog » Sat, Jan 20, 2018, 3:22 PM UTC

colund wrote: post #12

jiggunjer wrote: post #9

Earlier quoted context omitted.

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?

That comes from the old NTSC standard and the history of adding colour in a backwards compatible way:

https://www.youtube.com/watch?v=3GJUM6pCpew

In the case that the above posters are mentioning, this probably has less to do with NTSC compatibility and more to do with bad timing hardware or cameras that attempt to do too much in PIO mode instead of using real encoding hardware.

Re: Learn FFmpeg the hard way

#22

Post by djsumdog » Sat, Jan 20, 2018, 3:25 PM UTC

mulvya wrote: post #19

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?

Same here, I've rarely ever had anything that links ffmpeg crash, and I have a lot of ancient videos in old formats laying around.

Re: Learn FFmpeg the hard way

#23

Post by barrkel » Sat, Jan 20, 2018, 3:25 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.

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 complexity of video formats. Of course crashes are also potential security problems - I sometimes wonder how far you could get with a malicious video spread virally (in the social sense).

Re: Learn FFmpeg the hard way

#24

Post by mikepurvis » Sat, Jan 20, 2018, 3:35 PM UTC

djsumdog wrote: post #21

colund wrote: post #12

Earlier quoted context omitted.

29.97?

That comes from the old NTSC standard and the history of adding colour in a backwards compatible way: https://www.youtube.com/watch?v=3GJUM6pCpew In the case that the above posters are mentioning, this probably has less to do with NTSC compatibility and more to do with bad timing hardware or cameras that attempt to do too much in PIO mode instead of using real encoding hardware.

Glad to see that video linked; it's a terrific explanation.

Re: Learn FFmpeg the hard way

#25

Post by fndrplayer13 » Sat, Jan 20, 2018, 4:01 PM UTC

Having built programs that used the ffmpeg libraries (as well as x264) I have to say that a tutorial that is up to date and recent like this would have been very helpful at the time. Glad to see somebody is undertaking this effort.

Re: Learn FFmpeg the hard way

#26

Post by Xeoncross » Sat, Jan 20, 2018, 4:17 PM UTC

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.

Re: Learn FFmpeg the hard way

#27

Post by xmichael99 » Sat, Jan 20, 2018, 4:29 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.

I would gladly donate to anyone that wants to statically bind this for use with c# with mono multiplatform support. 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.

Re: Learn FFmpeg the hard way

#28

Post by fest » Sat, Jan 20, 2018, 4:29 PM UTC

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…

This really hits if you try to merge audio which has been recorded separately from video (e.g. Raspberry Pi where at least a few years ago software did not support recording audio synchronously with video).

And the worst thing is- it could vary from one device to other because the crystal oscillators used for image sensor clock have slightly different resonant frequency (which is caused by manufacturing tolerances when cutting the crystals).

Re: Learn FFmpeg the hard way

#29

Post by jallmann » Sat, Jan 20, 2018, 4:32 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.

I looked at some FFmpeg-Go bindings recently. Concluded that it was less effort to write exactly the functionality that's needed in C and expose that to Go, rather than fix up an all-encompassing API. More here: https://github.com/livepeer/lpms/issues/24

Re: Learn FFmpeg the hard way

#30

Post by orev » Sat, Jan 20, 2018, 4:33 PM UTC

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.