Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg 3.0 released

ffmpeg.org

Post reply on HN
Print view View original

41–50 of 95 posts

Re: FFmpeg 3.0 released

#41

Post by SteveNuts »

Rezo wrote: post #28
djm_ wrote: 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…

>I believe all of these are there to keep you from shooting yourself in the foot through automation gone wrong or inexperience.

Also to prevent you from racking up huge bills in case an api key is compromised, and the attacker is able to spin up tons of instances for a botnet or something on your dime.

Re: FFmpeg 3.0 released

#42

Post by djm_ »

Rezo wrote: post #28
djm_ wrote: 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…

No! Thank you for pointing that out; I've always taken "limit" to mean hard but I shall no longer.

We had other reasons to move and it did end up working well for that project and others, but I can obviously only say that with hindsight.

They need to write that in big bold letters.

Re: FFmpeg 3.0 released

#43

Post by djm_ »

manishsharan wrote: post #25
djm_ wrote: 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. ?

Sure: you likely don't want to be dealing with large files on Lambda. Why?

* The maximum timeout window for a function invocation is 300 seconds

* The maximum available temp disk space per instance is 500MB

* Memory is maxed at 1.5GB

In the function invocation time window you need to:

* retrieve the file (to memory or disk)

* transcode the file (outputting to memory or disk)

* upload the file (as the disk is not persistent)

This along with the following facts make it infeasible:

* transfers from S3 are fast, but non-s3 sources are likely to be much slower.

* assuming you mean large as in GB - you have nowhere to put the files (disk too small, memory too small).

* transfers to S3 are fast, but uploading the transcoded video to a non-s3 source will likely me much slower.

Hope that helps.

Re: FFmpeg 3.0 released

#44

Post by djm_ »

Exuma wrote: post #19
djm_ wrote: 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…

Wow... I would truly appreciate if you could share a bit more about your specific setup. I found myself working on a new project yesterday that I was really really excited about, until I saw the costs to transcode video. How does doing all this in-house compare price wise (say, per minute), compared to using elastic transcoder? Edit: The ultimate lowest cost I can find is $0.0125-0.015

I wish I could edit my parent comment but alas.

The key point was missed: we were dealing with very short, small videos.

If you are dealing with longer or large videos, it's simply not feasible on Lambda.

As for costings, unfortunately I cannot retrieve them as this project was mid last year and I've since moved on to other clients. They can be calculated though with a few short tests I'm sure.

Re: FFmpeg 3.0 released

#45

Post by Twirrim »

kuschku wrote: post #15
bru wrote: 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…

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.

If you're going to fork, you have to accept that you have exactly the same burden on you to keep up to date on security patches etc, at the very least. As a number of parties found, libav wasn't doing that, and regardless of any moral or ethical argument (for which I've mostly seen accusations and no actual evidence.. I'm largely taking it on face value that there were issues), security trumps pretty much everything.

Re: FFmpeg 3.0 released

#46

Post by chx »

nattaylor wrote: post #22
ux wrote: post #11

Earlier quoted context omitted.

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.

Wait, are you @majorsheep ? If yes your illustrations are really good :) http://www.king-sheep.com/star-wars-the-force-awakens-fan-ar...

Re: FFmpeg 3.0 released

#47

Post by krullie »

fareesh wrote: post #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

From the list given by @imaginenore the major one for me is CineformHD support. We work on a lot of VR stuff and there are quite some GoPro users out there that generate material in this codec. Not having to transcode to an intermediate is nice. Also hardware acceleration is always good to have.

Re: FFmpeg 3.0 released

#48

Post by kuschku »

air wrote: post #36
kuschku wrote: post #32

Earlier quoted context omitted.

The way the ffmpeg maintainer behaved – as malevolent dictator – in contrast to the more open development approach of libav, is a pretty big issue, don’t you think?

IMHO the hostile takeover of the ffmpeg project by the libav guys (Fabrice Bellard had to wield trademark to force them to rename the fork) and intense FUD campaign were much bigger issues.

It’s not a takeover – it was a takeover when the trademark was used to force everyone to fork.

But the majority of the project, the people owning the servers, technology, coding the most part, etc – those were the ones renaming to libav.

Re: FFmpeg 3.0 released

#50

Post by 2trill2spill »

kuschku wrote: post #48
air wrote: post #36

Earlier quoted context omitted.

IMHO the hostile takeover of the ffmpeg project by the libav guys (Fabrice Bellard had to wield trademark to force them to rename the fork) and intense FUD campaign were much bigger issues.

It’s not a takeover – it was a takeover when the trademark was used to force everyone to fork. But the majority of the project, the people owning the servers, technology, coding the most part, etc – those were the ones renaming to libav.

Your mad that the owner of a trademark told others they can't use the trademark?
Post reply on HN