will accept incorrect pix_fmt's and such, but decoder will work much better
with containers not setting the same attributes. It seems like there will
be a generic mechanism for checking such constraints, but if not I can always
resurrect this check for *encoder* only.
Originally committed as revision 5114 to svn://svn.ffmpeg.org/ffmpeg/trunk
performance impact is less than 1%.
Patch by Dan Maas (dmaas at maasdigital dot com)
Originally committed as revision 5070 to svn://svn.ffmpeg.org/ffmpeg/trunk
values), so the comparison with vs_total_ac_bits is messed up on the
first couple loop iterations, leading to AC underflows.
the b->prev[] pointers were not being maintained correctly. We
potentially have to update b->prev[] both before and after the area
whose VLC length is getting adjusted.
this also might fix the ppc regression failure?
patch by (Dan Maas <dmaas maasdigital com>)
Originally committed as revision 5064 to svn://svn.ffmpeg.org/ffmpeg/trunk
roman, dont hesitate to reverse this and solve it differntly if you want ...
Originally committed as revision 5053 to svn://svn.ffmpeg.org/ffmpeg/trunk
leak for cases like dlopening libavcodec.so and such, but I still
don't know how to catch such events.
Originally committed as revision 4818 to svn://svn.ffmpeg.org/ffmpeg/trunk
dc coeff rounding fix
class=3 num of bits fix
do interlaced check & idct only if CODEC_FLAG_INTERLACED_DCT
Originally committed as revision 4542 to svn://svn.ffmpeg.org/ffmpeg/trunk
simple now, take a look for yourself).
* additional optimizations of the decoder. It runs at 55fps now
on my desktop and it used to be ~45fps.
Originally committed as revision 2926 to svn://svn.ffmpeg.org/ffmpeg/trunk
from common.c -> common.h so that they can be inlined.
+ performace gain ~1% (measured with DV decoding)
+ code bloat 0.05%
Looks like a win-win solution.
Originally committed as revision 2874 to svn://svn.ffmpeg.org/ffmpeg/trunk
in terms of time and we're doing slightly better w.r.t. to
quality. I don't think there's much room for improvement
left, but I'd like to try and vectorize a couple of things.
Btw, any ideas on what may impact performance will be greatly
appreciated.
Originally committed as revision 2532 to svn://svn.ffmpeg.org/ffmpeg/trunk
* simple/accurate implementation of dct248
* DV encoding now supports 2-4-8 DCT
* DV encoding gets a bit faster (but still miles away
from what I think it could do)
* misc. DV codec cleanups
Originally committed as revision 2425 to svn://svn.ffmpeg.org/ffmpeg/trunk
* fixing YUV4MPEG format.
* fixing a bug in DV codec where coded_frame was not set.
Originally committed as revision 2396 to svn://svn.ffmpeg.org/ffmpeg/trunk
of work to do, but it least people can try it out and share
ideas. Please don't hesitate to give it a spin:
$ ffmpeg -i file.avi file.dv
is all you need.
* fix for a deallocation bug in DV muxer
Originally committed as revision 2327 to svn://svn.ffmpeg.org/ffmpeg/trunk
decoding. All muxing/demuxing functionality is now available
in libavformat/dv.[ch].
* dv1394.c and avidec.c were hooked up with general DV demuxer.
* DVAUDIO is dead! Long live pcm_s16le!
* DV audio is now always recognized -- which means we can
now hear all those ducks quaking in pond.dv.
Originally committed as revision 2319 to svn://svn.ffmpeg.org/ffmpeg/trunk
