
FFmpeg 3.0 released - vivagn
https://ffmpeg.org/download.html
======
nakodari
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/00c73c475e3d2d7049ee...](https://github.com/FFmpeg/FFmpeg/commit/00c73c475e3d2d7049eed73ea956f6798365b36a)

~~~
exadeci
First time that I hear about your service and it seems like a copy of Dropbox
but with way more features. (the interface)

Just a suggestion: Jumpshare Plus link should either be at the top or renamed
"Pricing" because you don't see it directly and the usual ctrl+f of pricing
gives nothing. Plus your pricing is nothing to be ashamed of :)

~~~
nakodari
Hi, thank you for the feedback and suggestions. We will make sure to include
the pricing in the new homepage we're working on. :)

By the way, we're more about quick sharing than syncing. We will be
overhauling our homepage to make that clearer. Here's the app if you're using
a Mac (Windows app is coming soon):
[https://itunes.apple.com/us/app/jumpshare/id889922906](https://itunes.apple.com/us/app/jumpshare/id889922906)

~~~
alphapapa
Syncing (and its related attributes of backup and redundancy) are more useful,
and Dropbox facilitates both that and sharing. So what's your angle? :)

~~~
nakodari
At it's core, Dropbox is about "syncing". But at Jumpshare, the core is "quick
sharing". This makes all the difference. We're able to build our product
around the quick sharing aspect, for example, our sharing happens in real-time
so you don't have to wait for uploads to finish first. And we offer a slew of
built-in tools (capturing screenshots, annotations, recording screencasts,
etc) and features to supercharge your sharing.

You can learn more from the discussion here:
[https://www.producthunt.com/tech/jumpshare-for-
mac](https://www.producthunt.com/tech/jumpshare-for-mac)

~~~
alphapapa
Okay, but what happens when Dropbox makes a minor upgrade to their sharing,
making it also "quick" or real-time sharing? Already, when uploading a file to
Dropbox, it can be shared and partially downloaded before it's finished
uploading. Do that with an image or video that was just recorded, or that is
being recorded, and that seems like real-time sharing to me.

And doing that with Dropbox means that, after it's been shared, it's also
synced, mirrored, and backed up for you.

Where does that leave Jumpshare?

~~~
tacos
> Where does that leave Jumpshare?

Promoting six-line pull requests on a fringe news website.

------
Aissen
This screams for proper release notes. The official ones are pretty light
([http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;...](http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=blob;f=RELEASE_NOTES;h=861dc04a1316c8333cc49e9231fd4a6ffabe8282;hb=c40983a6f631d22fede713d535bb9c31d5c9740c)
), and refer to the Changelog
([http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;...](http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=blob;f=Changelog;h=2e1cd36f5fe9cce3880697ddfe3079c0b1654473;hb=c40983a6f631d22fede713d535bb9c31d5c9740c)
) 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....](http://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-3.0-Released)

But honestly this type of stuff should be done by the project before any
release.

~~~
ux
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 them)

Hopefully a proper news will be posted soon. Sorry again.

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

~~~
chx
Wait, are you @majorsheep ? If yes your illustrations are really good :)
[http://www.king-sheep.com/star-wars-the-force-awakens-fan-
ar...](http://www.king-sheep.com/star-wars-the-force-awakens-fan-art-part-2/)

~~~
nattaylor
Nope. I can't take credit for the illustrations, but I might have to get in
touch with Nathan since there is some nattaylor out there who likes to put my
gmail address for all of their online services.

------
djm_
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 given that project a
lot more freedom; with the caveat that the any single task you undertake
should occur within the timeout window (currently 5 minutes). Having said
that, it's also straight forward to split the process into steps and have
multiple lambda jobs to make the flow more of a pipeline.

[1]
[http://docs.aws.amazon.com/elastictranscoder/latest/develope...](http://docs.aws.amazon.com/elastictranscoder/latest/developerguide/limits.html)

~~~
Rezo
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.

~~~
iampims
There are some limits they can't/don't want to increase.

~~~
abrookewood
I'm yet to find a limit that they won't adjust - what ones are you referring
to?

~~~
cthalupa
S3 buckets are one I've seen. But there's not really a reason to have 100 s3
buckets, much less more than that.

~~~
abrookewood
Yes, that's one that you may not be able to change. From memory, they put that
one in place to prevent the equivalent of bucket name squatting (since every
bucket has a corresponding public domain name).

------
danso
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]...What are the use-cases for sticking
with libav these days? I'm almost sure I started using libav because it was
promoted as a concerted effort to create a better API. But by some accounts,
ffmpeg has been incorporating libav's changes...and I honestly don't use libav
or ffmpeg enough, directly, to really benefit from a better API. And
installing both, I believe, has led to a few subtle errors when using
libraries that wrap around either.

So, any reason for the casual graphics developer to install libav?

[1] [https://lwn.net/Articles/650816/](https://lwn.net/Articles/650816/)

edit: Oh I see that VLC at some point switched to libav. That was likely a
deciding factor when I last did my nominal research into ffmpeg vs libav:

[http://git.videolan.org/?p=vlc.git;a=blob;f=contrib/src/ffmp...](http://git.videolan.org/?p=vlc.git;a=blob;f=contrib/src/ffmpeg/rules.mak;h=85fea9c43e5b7e46ab9a2902e7279b9e0674acc0;hb=HEAD)

~~~
bru
> 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, making IMHO
ffmpeg the right choice.

Good article (2012) with in-depth history: [http://blog.pkh.me/p/13-the-
ffmpeg-libav-situation.html](http://blog.pkh.me/p/13-the-ffmpeg-libav-
situation.html)

More recent (2015) short take on the matter, seems pretty biased though:
[https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-
Libav](https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav)

Wikipedia entry:
[https://en.wikipedia.org/wiki/Libav#Fork_from_FFmpeg](https://en.wikipedia.org/wiki/Libav#Fork_from_FFmpeg)

The github link is on mpv wiki. mpv is a descendant of mplayer and mplayer2
(the latter being mostly dead). IMHO mpv is the best media player for any OS
(lightweight, snappy, reads everything, better options and CLI than mplayer*,
etc.).

~~~
kuschku
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.

~~~
danso
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 creator, working freely, is trying
to move the ball forward...having users who can provide feedback is a sort of
moral support.

In the case of libav...as an admitted casual, I'm thankful that ffmpeg exists,
even if its API confuses me...I'm grateful enough to think that the status quo
is just fine, whether I can rationalize it or not. However, I do find it
admirable that some people (ostensibly) wanted to make what they think were
forward-thinking changes, including doing the kind of cleanup that is
generally under-appreciated and under-prioritized in all software.

So if they're promising a transparent, interoperable interface...sure, I'll
give it a try, and it will be for "moral" reasons in the sense of moral
support. I've done the same with MariaDB (over MySQL) and haven't regretted
it.

~~~
LukeShu
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.

------
imaginenore
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 others.

\- New decoding: DXV, Screenpresso SPV1, ADPCM PSX, SDX2 DPCM,
innoHeim/Rsupport Screen Capture Codec, ADPCM AICA, XMA1 & XMA2, and Cineform
HD.

\- New muxing: Chromaprint fingerprinting, WVE demuxer, Interplay ACM, and IVR
demuxer.

\- Dynamic volume control for ffplay.

\- Native AAC encoder improvements.

\- Zero-copy Intel QSV transcoding.

\- Microsoft DXVA2-accelerated VP9 decoding on Windows.

\- VA-API VP9 hardware acceleration.

\- Automatic bitstream filtering.

~~~
Veratyr
Is Intel QSV available on Mac/Linux yet by any chance?

~~~
tmm1
There's a patchset for this feature being discussed on the mailing list:

[http://ffmpeg.org/pipermail/ffmpeg-
devel/2016-February/18953...](http://ffmpeg.org/pipermail/ffmpeg-
devel/2016-February/189533.html)

------
fareesh
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

~~~
krullie
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.

~~~
theoh
FYI, the phrase "quite some users" is not uncommon among (continental
european?) non-native speakers of English, but it's not correct.

"In the British National Corpus, for example, most examples of quite some are
"quite some time", others are "quite some distance". If you replace "quite
some" with "a considerable", the meaning should be clear. If the sentence does
not make sense when you do that, it's likely that "quite some" is not being
used properly."

From [http://forum.wordreference.com/threads/quite-
some.1011589/](http://forum.wordreference.com/threads/quite-some.1011589/)

~~~
krullie
Thanks theoh. Dutchie here. Always nice to learn something new about a foreign
language.

------
esaym
I love FFmpeg. I first used it to help with uploading 700 audio files to
youtube years ago. Of course youtube is video only, so I used ffmpeg to
reencode the audio with an image slideshow as video and then uploaded the
"videos" using some web scrapping with perl.

More recently I have been downloading programming framework tutorials (android
development, django, angular,ect) from youtube to my plex media server. I then
go back with ffmpeg to reencode the vids to playback 50% faster. So now I can
blast through tutorials on my TV while I eat lunch (I work from home mostly)

Edit: The release mentioned hardware acceleration improvements. I never knew
ffmpeg even supported any HW accel:
[https://trac.ffmpeg.org/wiki/HWAccelIntro](https://trac.ffmpeg.org/wiki/HWAccelIntro)

~~~
GhotiFish
mplayer and mpv and vlc and most native players can speed videos up on the
fly, tempo-shifting or pitch shifting the audio based on preferences.

Usually the [ and ] keys.

~~~
esaym
Yes, those are players. But I don't want to sit in front of my computer or
cell phone while on lunch break, I want to sit on the couch in front of a TV.

Natively, neither plex or roku allows videos to be speed up, so they have to
be reencoded at a different speed.

------
pdknsk
If _ffplay_ supported hardware decoding, it'd be the perfect player. You could
not make a more minimal player. It does not, and it doesn't seem to be high on
the priority list, rather in last position perhaps.

[https://trac.ffmpeg.org/ticket/3359](https://trac.ffmpeg.org/ticket/3359)

~~~
cm3
Have you tried mpv?

------
hiphopyo
Awesome! Hoping for quick updates to the OpenBSD and FreeBSD ports.

------
_kyran
Thanks for all the work on FFmpeg!

------
cm3
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.

~~~
slhck
libfdk historically always was a bit better and supports VBR properly.

See also:
[https://trac.ffmpeg.org/wiki/Encode/AAC](https://trac.ffmpeg.org/wiki/Encode/AAC)

~~~
cm3
That's why I've been using it. Is the improved built-in encoder on par now?

~~~
slhck
I haven't done or seen any tests, but I suppose if you require VBR and/or HE-
AAC support, go for libfdk, otherwise for bitrates ~128k or higher, use the
internal AAC encoder.

------
mkagenius
Last version was named Feynman. This 3.0 is released on 15th feb - Death of
Feynman.

Coincidence?

------
obiefernandez
Why the heck do they make it so hard to figure out what's in the release?

~~~
slhck
There will be a proper news release on the homepage soon, I suppose.

