It is not used in any filters currently and is inherently evil. If
passing binary data to filters is required in the future, it should be
done with some AVOptions-based system.
Since those are pseudo-palette formats, swscale does not write
into data[1], swscale must initialize the palette properly itself.
This lead to frames that actually decoded as all-gray before.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
We can't use whether the input format is paletted to decide that
the output format has a palette in data[1], too, that makes no sense.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
While quality is bad, PAL8 support is needed to allow testing some
encoders that only support PAL8 input.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Previously, "dar" and "a" were documented like "input display aspect
ratio", but their actual value was "in_w/in_h".
In order to avoid to break scripts which rely on the "a" variable, the
patch keeps the same semantics but fixes the corresponding docs, and
fixes the semantics of the recently added "dar" variable, which
now correctly expresses the input Display Aspect Ratio value as
"(inw_w/in_h)*sar".
Improve consistency with libavcodec.
This breaks libavfilter API/ABI.
The non-sequential 2.1.0 -> 2.4.0 bump is due to the mess previously
done with the lavfi minor number.
Make the filter accept parametric expressions for the output video
size.
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The constant values were never set, thus the evaluation of expressions
referencing those constants were resulting in an error.
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>
Fixes issue2632 if interl=1 is used or the automatic interlace detection is enabled
and works. This has the advantage compared to the patch in issue2632 that it causes
no speed loss and it also works when scaling is used. The disadvantage is that
interlacing autodetection does not yet work very well it seems.
This is the same method mplayer uses
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Define a new struct AVFilterBufferRefVideoProps and add a type field
to AVFilterBufferRef.
Video specific properties in AVFilterBufferRefVideoProps are now
referred to by *video pointer in AVFilterBufferRef.
Patch by S.N. Hemanth Meenakshisundaram smeenaks->ucsd.edu.
Originally committed as revision 24763 to svn://svn.ffmpeg.org/ffmpeg/trunk
AVFilterLink.srcpic -> AVFilterLink.src_buf
AVFilterLink.cur_pic -> AVFilterLink.cur_buf
AVFilterLink.outpic -> AVFilterLink.out_buf
The new names are more generic and more consistent, since the struct
they contain, which was named AVFilterPicRef, has been renamed to
AVFilterBufferRef.
Patch by S.N. Hemanth Meenakshisundaram %smeenaks%ucsd%edu%.
Originally committed as revision 24732 to svn://svn.ffmpeg.org/ffmpeg/trunk
avfilter_(un)ref_pic -> avfilter_(un)ref_buffer
avfilter_copy_picref_props -> avfilter_copy_buffer_ref_props
AVFilterBufferRef.pic -> AVFilterBufferRef.buffer
They have been renamed to allow sharing with audio.
Patch by S.N. Hemanth Meenakshisundaram $smeenaks$ucsd$edu$.
Originally committed as revision 24731 to svn://svn.ffmpeg.org/ffmpeg/trunk
The struct is going to be used for storing audio buffer references as
well, and the new name is more generic.
Patch by S.N. Hemanth Meenakshisundaram @smeenaks@ucsd@edu@.
Originally committed as revision 24730 to svn://svn.ffmpeg.org/ffmpeg/trunk