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

71–80 of 82 posts

Re: Learn FFmpeg the hard way

#71

Post by Something1234 »

blt wrote: post #50
innagadadavida wrote: post #39

Earlier quoted context omitted.

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.

How to deal with efficiency issues from the huge amount of data being piped? Shared memory area and send pointers over the pipe?

Is this really a problem with pipes. I found that I can easily push 8-9 GIB/s over a standard pipe on my 4 year old desktop

    yes | pv > /dev/null

Re: Learn FFmpeg the hard way

#72

Post by mdip »

About a year ago I wrote a zsh script to analyse files in my collection and format/selectively re-encode them based on a set of rules. Basically, I wanted .mp4 files that the Roku Plex app could play back without having to do any kind of re-encoding (stream/container or otherwise).

That started me on a 2-week mission of understanding the command-line. Good God is it a nightmare! All my script was doing was reading the existing file, deciding on the "correct" video and audio track, creating an AC-3 if only a DTS existed, and adding a two-channel AAC track. It would also re-encode the video track if the bitrate was too high or the profile was greater than the Roku could handle.

Here's the thing that I discovered, as much as I swore at the command-line interface, I couldn't come up with a more elegant solution that would still allow the application to be controlled entirely from the CLI. Ffmpeg is capable of so much that figuring out a way to just "tell it what to do" from a CLI ends up with an interface that's ... that difficult to use. The program, very nearly, handles everything[0] as it relates to media files and simplifying the application to improve the CLI would necessarily involve eliminating features. It's one of those cases where a light-weight DSL would provide a superior interface (and to a certain extent, the command-line of ffmpeg nearly qualifies as a DSL).

[0] The "very nearly" was necessary because of the one feature I found that it didn't handle. It's not possible in the current version to convert subtitle tracks from DVDs to a format that is "legal" in an mp4 file because the DVD subtitles are images rather than text, whereas the only formats that are legal for the mp4 container are text. I found some utilities that can handle this, but didn't try any, opting instead to simply download them when I encountered a file with subtitles in this format.

Re: Learn FFmpeg the hard way

#73

Post by userbinator »

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…

It's true for video recorded by professional cameras, but if you check video recorded by most mobile phones you notice that it's wrong.

It's unfortunate that so many tools assume constant framerate, because VFR is a useful compression technique in itself --- for sequences where there's basically no change between frames (few-second black scenes, for example), the encoder can stop continually encoding "no change" and just wait until there is.

Re: Learn FFmpeg the hard way

#74

Post by jiggunjer »

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.

I wouldn't say bad timing means bad hardware though, even expensive scientific cameras suffer from this. You need rather complex electronics to capture at a high and consistent rate. I think normally the encoding is done by software.

Re: Learn FFmpeg the hard way

#75

Post by FraKtus »

I use FFmpeg since more than 10 years and I am amazed at how stable it is. Even when we say to our users drop anything in our apps we will do our best to handle it .. it's exceptional to have an issue with it. Because the API is always evolving the best advice is to read the headers, the best documentation is there and its accurate.

Re: Learn FFmpeg the hard way

#76

Post by manorwar8 »

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?

FFmpeg can have any numbers of decoders/encoders sometimes you want to use a hardware decode to read and a hardware encoder to write (like the intel), so you can override the default decoders/encoders for each codec.

Re: Learn FFmpeg the hard way

#77

Post by CrystalLangUser »

ouid wrote: post #61
dfabulich wrote: post #60

Earlier quoted context omitted.

> 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". Ha…

Essentially, this is impossible for anything that’s not easily explainable all at once- so it’s useless for any advanced domain.

You can’t just give people a firehose of information. When you learn acoustic engineering, you have to first learn the prerequisite math needed to understand later concepts such as room architecture. It simply does not make sense to jam pack it all in at once, because 1) it won’t make sense and 2) nobody has that kind of memory.

Next, if you want to cover all possible use cases, that could take forever in certain domains.

Last, some of this stuff is objective as to what’s necessary, or what cases need to be covered.

No, what’s better is to give general knowledge as needed, and the student can seek out knowledge for various corner cases. It would be ridiculous otherwise.

Re: Learn FFmpeg the hard way

#78

Post by mrunkel »

mdip wrote: post #72

About a year ago I wrote a zsh script to analyse files in my collection and format/selectively re-encode them based on a set of rules. Basically, I wanted .mp4 files that the Roku Plex app could play back without having to do any kind of re-encoding (stream/container or otherwise). That started me on a 2-week mission of understanding the command-line. Good God is it a nightmare! All my script was doing was reading th…

Would you be willing to share this script?

Re: Learn FFmpeg the hard way

#79

Post by katastic »

ouid wrote: post #54
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.

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?

Because those abstractions obscure the core point being made.

Or did you learn about polynomial long division at the same time as long division during your first few years of grade school?

Post reply on HN