- Mar 21, 2009
-
-
Jan Schmidt authored
-
- Mar 18, 2009
-
-
Jan Schmidt authored
-
- Mar 17, 2009
-
-
Edward Hervey authored
-
Edward Hervey authored
-
- Mar 13, 2009
-
-
Jan Schmidt authored
-
- Mar 11, 2009
-
-
Edward Hervey authored
-
Edward Hervey authored
It still worked... until the 0.5 ffmpeg release, which made those defines unused. See the bottom of libavutil/pixfmt.h for more details.
-
Edward Hervey authored
This is only a one-commit svn-props change.. but we might as well keep it accurate.
-
- Mar 10, 2009
-
-
Edward Hervey authored
-
Edward Hervey authored
-
Edward Hervey authored
-
Jan Schmidt authored
-
- Mar 09, 2009
-
-
Jan Schmidt authored
From 7032163 to f8b3d91
-
Edward Hervey authored
-
Edward Hervey authored
We do this, because the demuxer is initialized in the loop function. If it's not initialized yet, that means the loop hasn't been entered... and therefore the PIPE GCond will never be signalled.
-
Edward Hervey authored
Currently, only one is blacklisted : ffdemux_ape. This has been confirmed by ffmpeg developers.
-
Edward Hervey authored
-
Edward Hervey authored
-
Edward Hervey authored
-
- Mar 08, 2009
-
-
Sebastian Dröge authored
From ffa738d to 7032163
-
Sebastian Dröge authored
From 3f13e4e to ffa738d
-
- Mar 07, 2009
-
-
Sebastian Dröge authored
From 3c7456b to 3f13e4e
-
Sebastian Dröge authored
From 57c83f2 to 3c7456b
-
- Mar 06, 2009
-
-
Tim-Philipp Müller authored
-
Edward Hervey authored
We simply allocate the memory using ffmpeg's av_malloc which provides us with properly memalign'ed data. This avoids write-outside-of-bounds when sse/altivec code is being used.
-
Edward Hervey authored
The internal resampling functions seem to require a slightly bigger buffer for output than what we require. Therefore we give it an extra 64bytes (although 16 should have been enough).
-
Tim-Philipp Müller authored
We should post a STREAM DECODE error message on the bus when we return GST_FLOW_ERROR, otherwise the user ends up seeing an ugly internal flow error message, which isn't very nice.
-
- Mar 05, 2009
-
-
Edward Hervey authored
It will stay this way until the ffmpeg aac decoder can report before decoding whether it can handle a given stream or not.
-
-
Fixes #570975
-
Edward Hervey authored
Fixes #565269
-
- Mar 04, 2009
-
-
Tim-Philipp Müller authored
-
Edward Hervey authored
The problem is that the ffmpeg aac decoder fails... but still accepts the following buffers as if nothing happened. But because some things were not properly set in the internal code, all hell breaks loose.
-
Edward Hervey authored
They have proven by now that they're more reliable than the -bad real wrapper plugins.
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Mar 03, 2009
-
-
Edward Hervey authored
Normally this should be the last commit before they release 0.5. We should use this for pre-releases in order to help them squash down bugs.
-
- Mar 02, 2009
-
-
Edward Hervey authored
-
- Feb 27, 2009
-
-
Edward Hervey authored
-
Edward Hervey authored
AVOutputFormat does *NOT* contain the full list of codecs a muxer can handle, but does contain the recommended audio and video codecs. Therefore we use that information to expose more muxers, until AVOutputFormat contains a list of *ALL* compatible codecs.
-