61–70 of 95 posts
Is the built-in aac encoder better or as good as fdk-aac? I've been using fdk-aac because it gives lower bitrates and better/same sound.
libfdk historically always was a bit better and supports VBR properly. See also: https://trac.ffmpeg.org/wiki/Encode/AAC
Is the built-in aac encoder better or as good as fdk-aac? I've been using fdk-aac because it gives lower bitrates and better/same sound.
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
Perhaps the most important is that the ecgs fork announcement [1] was very diplomatically worded, intended to put an end to any bad feelings on either side, and recognized that FSF was completely in their right to be conservative when it came to developing gcc. Another difference is that ecgs really took off and eventually became the official gcc; libav doesn't look like it's doing the same.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
Your mad that the owner of a trademark told others they can't use the trademark?
I’m mad that a person, who bought a trademark for a project, then decided to act against the interest of the majority of the participants of the project,
Seeing as your the maintainer for QuasselDroid, How would you like it if a group of contributors wanted to take the project in a different direction then you, so they fork it, call their fork QuasselDroid, and then say your branch is immoral, like you have throughout this page, I doubt you would enjoy this, and if you owned the QuasselDroid trademark I'm sure you would use it too.
Earlier quoted context omitted.
I’m mad that a person, who bought a trademark for a project, then decided to act against the interest of the majority of the participants of the project,
Let me get this straight, your mad because Fabrice Bellard, the person who started ffmpeg, asserted his trademark on the libav folks because their fork initially used the name ffmpeg? Seeing as your the maintainer for QuasselDroid, How would you like it if a group of contributors wanted to take the project in a different direction then you, so they fork it, call their fork QuasselDroid, and then say your branch is im…
Just in our case the people maintaining the (now dead) original repo decided to give up maintainership to me. (And so we merged everything back).
Also, in your example, I would have no issue.
If another group decided to fork and improve the project, and have more development going on than me, I’d end up just contributing to their project.
This is open source and open development, the very concept is that anyone can and will fork, and may even become the canonical version.
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…
For $2.60 an hour, you get 4x Kepler GPUs that can handle ~4x realtime 1080p encodes each (120fps per GPU), or 16x realtime 1080p encodes total (480fps). To convert this into rather odd units, that works out to ~1.37Tpix/$ (1920x1080 x 480fps x 3600s / $2.6). Put this on reserved instances and that number is pushed up to ~2.2Tpix/$.
According to [1], ffmpeg + x264 performance on the most cost effective instances (c3.xlarge) was 20s for a 30s, 960x540 video, or roughly 0.5Mpix at 45fps. That's 83Gpix for $0.21, or 0.399Tpix/$ at spot prices or 0.672Tpix/$ at reserved prices.
Depending on how much you care about your compression quality (NVENC isn't quite as good as x264 veryslow but it's definitely usable, particularly with its "two pass" preset), it might be worth a good look at the GPU encoders.
[1]: https://github.com/sportarchive/CloudTranscode/blob/master/b...
Among new things: - Common Encryption (CENC) MP4 encoding and decoding support. - New filters: extrastereo, OCR, alimiter, stereowiden, stereotools, rubberband, tremolo, agate, chromakey, maskedmerge, displace, selectivecolor, zscale, shuffleframes, vibrato, realtime, compensationdelay, acompressor, apulsator, sidechaingate, aemphasis, virtual binaural acoustics, showspectrumpic, afftfilt, convolution, swaprect, and…
Earlier quoted context omitted.
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 pers…
You can process several GBs in the 5 minute window by piping your S3 download stream through your transformation steps then directly into an S3 upload stream. Nothing ever persists to disk, so your only worry if anything is managing your stream buffers so you don't run out of memory.
As long as any single step of your pipeline doesn't exceed the time limit, you can make really nifty pipelines for large file processing by using the S3 upload as "temp space" then an S3 event to automatically trigger the next step of your pipeline.
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…