Live data from Hacker News

All the giant companies used ffmpeg (2020)

twitter.com

171–180 of 202 posts

Re: All the giant companies used ffmpeg (2020)

#171
ffmpeg is great.

I wrote a thing to proxy a twitch livestream and return it as lazy animated gif, so it could be embedded into, like, old-school messageboards and proprietary chat clients that allow hotlinking images. At the core it was feeding a .m3u8 URL into ffmpeg and asking it for a gif. When it turned out that gif was kind of awful for that use-case, I just asked ffmpeg to give me an mjpeg instead, problem solved.

Re: All the giant companies used ffmpeg (2020)

#172
post #63

Earlier quoted context omitted.

Yeah, it’s been said that ffmpeg and vlc could play a vinyl record if you fed it to them. It’s not actually true, but it is story true.

What if you pass it a high-res photo of a vinyl record? There ought to be a transcoder plugin for that lying around somewhere!

The tech to do it is almost there. https://www.windytan.com/2017/07/gramophone-audio-from-photo...

Re: All the giant companies used ffmpeg (2020)

#173

Considering how ubiquitous it is, it's a mystery how and why there's so little documentation about how to use the library versions libavcodec and libavformat.

I agree. Unless you had a lot of domain knowledge or a lot of time with a lot of weirdly encoded media I would say that it is impossible for someone to make something as seemingly simple as a thumbnail extractor with those libraries (eg. take the first frame or x seconds of a video and write an image file) Your best bet is to just call ffmpeg to do what you need and not have to worry about the weirdness of the libav…

I've been struggling with exactly this, setting up ffmpeg to work with buffers instead of files. I'm about ready to just write frames to /tmp or maybe /dev/shm and invoke the CLI. I work with a lot of weirdly encoded media, so I'm thinking that for long-term maintainability it might be better to use the CLI anyways, as you can iterate significantly faster at the cost of control.

I'm just not sure what kind of performance overhead it will have writing to a ramdisk vs. using a buffer, as it's a non-negligible amount of memory to read/write so many extra times.

Re: All the giant companies used ffmpeg (2020)

#174
post #130

Earlier quoted context omitted.

Genuine question: Are there any actual examples of giant companies using gstreamer? Why I ask is that pretty much the only reason I have gstreamer installed on my pesonal laptop is to satisfy certain GNOME dependencies (due to GNOME, understandably, dogfooding its own stuff). Everything else (including apps I use daily e.g. mpv, Firefox, etc) depends on ffmpeg. $ sudo pacman -Rs gstreamer checking dependencies... err…

I have used gstreamer for the Dutch Railways, to stream the announcements to passengers in certain types of rolling stock. The announcements are generated as text, go through a text-to-speech engine and are then streamed to the rolling stock. As you'd expect, every manufacturer uses a different method to broadcast the announcement.

Which text to speech engine are you using, if I may ask?

Re: All the giant companies used ffmpeg (2020)

#175
post #58

The "triumph of high quality open source software" is wrong because ffmpeg is old C/ASM hacky code (not even C++, optimized by speed for hardware). I got my first experience of optimizing ffmpeg video decoder for AMD Alchemy processor in 2006. Let's take a look at the history of ffmpeg created by hackers for hackers. Do you remember how many times you saw strange squares on the screen when rewinding a YouTube video o…

What's high quality open source software? ffmpeg works well, I don't think an alternative would be much better. There will never be a software without bugs. The alternative would be spending tons of money for another piece of software with more bugs.

Good quality software means good architecture design, less code, fewer bugs, more language features and advanced programming to prevent bugs. FFmpeg works well because the hackers did a good job but spent millions of man-hours shooting themselves in the foot.

Re: All the giant companies used ffmpeg (2020)

#176
post #63
post #36

About 14 years ago, at my first job, I worked with a colleague[1] who introduced me to the wonderful world of open source: the culture, the philosophy, how to submit patches to open source projects, etc. He also introduced me to Debian GNU/Linux which I use actively to this day. One day, he began working on certain audio/video encoding problems that needed to be solved for our project. He chose FFmpeg as the primary…

Yeah, it’s been said that ffmpeg and vlc could play a vinyl record if you fed it to them. It’s not actually true, but it is story true.

>Yeah, it’s been said that ffmpeg and vlc could play a vinyl record if you fed it to them.

ffmpeg is doing all the heavy lifting there. VLC mostly uses libraries from ffmpeg.

I have no idea why people are so impressed by VLC. Anything built on libavcodec can play all the same files, but they won't have VLC's deficiencies in performance, quality, reliability, or usability. ffmpeg is a great project and VLC an incompetent one riding its coattails.

Re: All the giant companies used ffmpeg (2020)

#177
post #36

About 14 years ago, at my first job, I worked with a colleague[1] who introduced me to the wonderful world of open source: the culture, the philosophy, how to submit patches to open source projects, etc. He also introduced me to Debian GNU/Linux which I use actively to this day. One day, he began working on certain audio/video encoding problems that needed to be solved for our project. He chose FFmpeg as the primary…

While ffmpeg does support a lot of really old / obscure media formats, support isn’t nearly as good for professional broadcast / film video formats. DNxHD can be hit or miss and it doesn’t support formats like OMF or AAF. I have heard some broadcasters’ QC departments reject ProRes created by ffmpeg as invalid.

It is probably following the spec too closely.

Like when Apple added ExFat support and Windows couldn't handle it, because Microsoft only wrote the spec. They didn't follow it.

Re: All the giant companies used ffmpeg (2020)

#178
post #104

Earlier quoted context omitted.

Debian tried to switch from ffmpeg to libav. It didn't turn out well. But it generally gives me no trouble.

Could you give more details on how it did not turn out well?

As I recall, they were not able to maintain feature, and maybe bug-fix, parity with ffmpeg.

Re: All the giant companies used ffmpeg (2020)

#179
post #11

I came across a set-top box that I suspected used ffmpeg for transcoding, because I recognized some artifacts I saw when I used ffmpeg's defaults for some settings. Looked through their copyright notices and it turns out they were using ffmpeg. It's really everywhere.

Completely idle curiosity: What kind of artifacts? I don’t spend much time on AV stuff, but I always find the details fascinating.

When transcoding some streams, if you use ffmpeg's defaults, sometimes the way it handles PTS, DTS and keyframes isn't ideal, and you'll get weird video pauses, blanks, and strange but distinct visual artifacts while the audio plays just fine.

Having spent a lot of time using ffmpeg for transcoding, it's one of those things I recognized because I'd often forget to set the correct settings and got similar results, as well.

Re: All the giant companies used ffmpeg (2020)

#180
post #154

Earlier quoted context omitted.

There's a recording medium which is worse than a photograph of vinyl. None. If an old photo is what you've got, make the best at extracting from it.

This seems like an argument against something I didn't say in the comment you replied to. Maybe I misunderstood you.

There's at least a plausible interpretation of your earlier comment that the attempt was futile or without merits.

The OP makes clear that this was the only viable way of extracting information. 1 >>> 0.

Also, as a sufficiently early recording (anything before the mid-1940s), the medium would have been shellac or wax rather than vinyl. Shellac especially is immensely fragile and prone to shatter when handling.

Post reply on HN