Live data from Hacker News

FFmpeg 3.0 released

ffmpeg.org

21–30 of 95 posts

Re: FFmpeg 3.0 released

#21
post #11
post #3

This screams for proper release notes. The official ones are pretty light ( http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;... ), and refer to the Changelog ( http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;... ) which is quite terse. Phoronix did some reformatting of the changelog, it's a bit easier to read: http://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-3.... But honestly this ty…

Yeah, sorry about that. It was indeed done in a hurry. I think the main highlights are: - The API/ABI break (implied by the major bump) - The many improvements in the native AAC encoder making it the recommended one (libaacplus and libvo-aacenc are removed) - A ton of filters were added - Many ASM optimizations that weren't mentioned in the Changelog (it will take a while to make highlights on those, I don't remember…

Any plan to support QuickSync?

Re: FFmpeg 3.0 released

#22
post #11
post #3

This screams for proper release notes. The official ones are pretty light ( http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;... ), and refer to the Changelog ( http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;... ) which is quite terse. Phoronix did some reformatting of the changelog, it's a bit easier to read: http://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-3.... But honestly this ty…

Yeah, sorry about that. It was indeed done in a hurry. I think the main highlights are: - The API/ABI break (implied by the major bump) - The many improvements in the native AAC encoder making it the recommended one (libaacplus and libvo-aacenc are removed) - A ton of filters were added - Many ASM optimizations that weren't mentioned in the Changelog (it will take a while to make highlights on those, I don't remember…

@imaginenore's comment below (https://news.ycombinator.com/item?id=11103063) has a detailed list of the 29! new filters.

Re: FFmpeg 3.0 released

#23
I use ffmpeg for housekeeping stuff like converting videos from one format to the other, and cutting clips - mostly from the command line. Can some advanced users share if there is anything to look forward to with this release? Better performance? Some convenience features? Thank you in advance

Re: FFmpeg 3.0 released

#24
post #10
post #4

I know this has been a constant question (in the lines of "Should I go Python 2.x or 3.x?")...but I feel the need to ask it again on the event of a major point release for ffmpeg...but how are things, pragmatically-speaking, in terms of libav vs ffmpeg? I had thought that libav was the new way a few years ago and have more or less been using it on OS X...but now I see that Debian recently switched back to ffmpeg [1].…

> libav [...] promoted as a concerted effort to create a better API True, but that was biased and unfair. Some developers leveraged their Debian influence to get Debian to switch from ffmpeg to libav, but the technical merits were debatable. In the end, they came back to ffmpeg. This is mostly a political issue. Software-wise AFAIK ffmpeg has been integrating many changes from libav but the opposite is not true, maki…

> This is mostly a political issue.

Let us not forget the reasons for libav. The ffmpeg development process was having a lot of problems due to very controversial decisions that its lead dev was taking. The libav fork has resulted in a restructuring of the ffmpeg development workflow. In this regard, libav is about as important as egcs was to gcc.

Further reading:

http://codecs.multimedia.cx/?p=339

Re: FFmpeg 3.0 released

#25
post #5

Thanks to all the FFmpeg contributors! Fantastic piece of software. On a project I was recently on recently we started hitting the per-region concurrent transcode limits on Amazon's Elastic Transcoder. [1] Instead of sharding over pipelines or accounts we set up a pipeline with FFMPEG + Lambda functions and it performed fantastically (within the free tier even). It was incredibly simple to write the functions and has…

Could you share your experience with FFMPEG+ Lambda ? I ran into trouble with this when dealing with large files, especially when some of the files were being pulled off non S3 sources. Also what EC2 cores were you using. ?

Re: FFmpeg 3.0 released

#26
post #24
post #10

Earlier quoted context omitted.

> libav [...] promoted as a concerted effort to create a better API True, but that was biased and unfair. Some developers leveraged their Debian influence to get Debian to switch from ffmpeg to libav, but the technical merits were debatable. In the end, they came back to ffmpeg. This is mostly a political issue. Software-wise AFAIK ffmpeg has been integrating many changes from libav but the opposite is not true, maki…

> This is mostly a political issue. Let us not forget the reasons for libav. The ffmpeg development process was having a lot of problems due to very controversial decisions that its lead dev was taking. The libav fork has resulted in a restructuring of the ffmpeg development workflow. In this regard, libav is about as important as egcs was to gcc. Further reading: http://codecs.multimedia.cx/?p=339

> very controversial decisions that its lead dev was taking

I have seen this claim frequently, but have never seen an actual list of such (and that link doesn't supply one). I get they didn't like the guy, but what were the terrible things he was supposed to have done?

Re: FFmpeg 3.0 released

#27

At Jumpshare, we use FFmpeg for screen recording. We noticed that the previous version of FFmpeg was not DPI aware. So we went ahead and fixed it. Now FFmpeg will show correct mouse location in hdpi screens. Unfortunately, it seems FFmpeg 3.0 does not ship with this fix. Nevertheless, we're happy to contribute to this open source project. Here's the fix if anyone is interested: https://github.com/FFmpeg/FFmpeg/commit…

You can backport it easily, and it will be present in 3.0.1. Ask on IRC or the dev ML.

Re: FFmpeg 3.0 released

#28
post #5

Thanks to all the FFmpeg contributors! Fantastic piece of software. On a project I was recently on recently we started hitting the per-region concurrent transcode limits on Amazon's Elastic Transcoder. [1] Instead of sharding over pipelines or accounts we set up a pipeline with FFMPEG + Lambda functions and it performed fantastically (within the free tier even). It was incredibly simple to write the functions and has…

Did you try simply asking AWS to raise the limit? It even suggests so on your linked page.

In my experience, every limit is immediately relaxed when requested; number of VPCs (I see people do horrible things to work around this all the time! Just ask!), EC2s / region, SES limits (need to send 10 million emails / day? No problem!), API Gateways / account, total ASGs... I believe all of these are there to keep you from shooting yourself in the foot through automation gone wrong or inexperience.

I've seen some crazy complicated architectures, where just sending an email or lifting up the phone solves the thing within an hour.

Re: FFmpeg 3.0 released

#29
post #18
post #15

Earlier quoted context omitted.

Software-wise, ffmpeg is the more feature complete solution, obviously. But if you want a morally and ethically okay solution, with a cleaner codebase (but also NIH syndrome), libav might be the better solution. The same people who use free software for moral and ethical reasons would also choose libav.

Sorry, what's wrong with using free software for moral and ethical reasons? I often do so because I don't feel like paying nor stealing commercial software. However, being so dependent on OSS has made me appreciate it and want to support it in what ways I can -- call it a moral imperative. Besides contributing bug reports and patches, I sometimes like using new libraries (or edge versions of existing software) if the…

What's wrong with it is that FFmpeg and Libav are on equal footing in that regard; so using that argument in favor of one over the other is... nonsensical.

Re: FFmpeg 3.0 released

#30
post #28
post #5

Thanks to all the FFmpeg contributors! Fantastic piece of software. On a project I was recently on recently we started hitting the per-region concurrent transcode limits on Amazon's Elastic Transcoder. [1] Instead of sharding over pipelines or accounts we set up a pipeline with FFMPEG + Lambda functions and it performed fantastically (within the free tier even). It was incredibly simple to write the functions and has…

Did you try simply asking AWS to raise the limit? It even suggests so on your linked page. In my experience, every limit is immediately relaxed when requested; number of VPCs (I see people do horrible things to work around this all the time! Just ask!), EC2s / region, SES limits (need to send 10 million emails / day? No problem!), API Gateways / account, total ASGs... I believe all of these are there to keep you from…

>number of VPCs (I see people do horrible things to work around this all the time! Just ask!)

I'm intrigued.

Post reply on HN