add avcodec_get_subtitle_defaults() to initialize AVSubtitle struct
Call this new function before decode() to replace the custom and
inconsistant initialization in various decoders.
This function is equivalent to avcodec_get_frame_defaults() for AVFrame.
* qatar/master:
avio: add more documentation for AVIOContext.
Parse sprite data for WMVP and WVP2, and decode sprites for the latter
Replace outdated info on the FAQ
Redefine sameq
pad: fix example explanation
gradfun: add notice from the MPlayer manual
eval: add support for trunc, ceil, and floor functions
documentation: add setdar and setsar description to filters.texi
avio: document some members of AVIOContext.
avio: document avio_close().
avio: cosmetics, vertically align comments.
avio: cosmetics, group the reading functions.
avio: cosmetics, merge all the FF_API_OLD_AVIO blocks.
avio: cosmetics, move AVIOContext to start of the file.
avio: update file header.
os: fix OpenBSD/PowerPC compilation
pixfmt: add PIX_FMT_BGR48LE and PIX_FMT_BGR48BE
oggdec: fix demuxing chained audio streams
fix typo
Oskar Arvidsson [Tue, 29 Mar 2011 15:48:59 +0000 (17:48 +0200)]
Adds 8-, 9- and 10-bit versions of some of the functions used by the h264 decoder.
This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).
Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Oskar Arvidsson [Tue, 29 Mar 2011 15:48:57 +0000 (17:48 +0200)]
Add the notion of pixel size in h264 related functions.
In high bit depth the pixels will not be stored in uint8_t like in the
normal case, but in uint16_t. The pixel size is thus 1 in normal bit
depth and 2 in high bit depth.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Unfortunately the output buffer size check assumes that the
input buffer is never over-consumed, thus this actually
also allowed to write outside the output buffer if "lucky".
When attempting to re-enable the AltiVec support it was noticed
that we need to undefine _POSIX_C_SOURCE to appease the headers
for ff_get_cpu_flags_ppc() to be able to compile.
AS libavcodec/arm/ac3dsp_armv6.o
ffmpeg-src/libavcodec/arm/ac3dsp_armv6.S: Assembler messages:
ffmpeg-src/libavcodec/arm/ac3dsp_armv6.S:40: Error: selected processor
does not support `movw r8,#0x1fe0'
make[1]: *** [libavcodec/arm/ac3dsp_armv6.o] Error 1
MOVW is ARMv7 way to load constant:
* movw, or move wide, will move a 16-bit constant into a register,
implicitly zeroing the top 16 bits of the target register.
* movt, or move top, will move a 16-bit constant into the top half
of a given register without altering the bottom 16 bits
To load 32 bit constant, movw lower16; movt upper16; is better than
ldr if available, because:
While this approach takes two instructions, it does not require any
extra space to store the constant so both the movw/movt method and the
ldr method will end up using the same amount of memory. Memory
bandwidth is precious in and the movw/movt approach avoids an extra
read on the data side, not to mention the read could have missed the
cache.
But here it is armv6 optimization, so that we have to use ldr.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
daud: Don't write packets that are too large to have their size expressed in the bytestream.
DUPLICATE pthread: validate_thread_parameters() ignored slice-threading being intentionally off
DUPLICATE Use consistent condition for whether to run slice-threading execute function.
avformat.h: fix a misplaced #endif
DUPLCIATE vaapi: cope with VA-API 0.32, i.e. fix VC-1 decoding on Sandy Bridge.
DUPLICATE vaapi: filter out DELAYED_PIC_REF flag to determine field.
pthread: validate_thread_parameters() ignored slice-threading being intentionally off
The thread_type API allows you to request only FF_THREAD_FRAME (instead of
FRAME | SLICE), but it was being ignored.
We don't implement both of them at the same time, so there isn't an effect
on current codecs, except that you can request no kinds of threading now
(a bit useless).
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Philip Langdale [Sat, 26 Mar 2011 17:34:20 +0000 (10:34 -0700)]
CrystalHD: Improve detection of h.264 content.
As previously discussed, the CrystalHD hardware returns exceptionally
useless information about interlaced h.264 content - to the extent
that it's not possible to distinguish most MBAFF and PAFF content until
it's too late.
In an attempt to compensate for this, I'm introducing two mechanisms:
1) Peeking at the picture number of the next picture
The hardware provides a capability to peek the next picture number. If
it is the same as the current picture number, then we are clearly dealing
with two fields and not a frame or fieldpair.
If this always worked, it would be all we need, but it's not guaranteed
to work. Sometimes, the next picture may not be decoded sufficiently
for the number to be known; alternately, a corruption in the stream may
cause the hardware to refuse to return the number even if the next
intact frame is decoded. In either case, the query will return 0.
If we are unable to peek the next picture number, we assume that the
picture is a frame/fieldpair and return it accordingly. If that turns
out to be incorrect, we discard the second field, and the user has
to live with the glitch. In testing, false detection can occur for
the first couple of seconds, and then the pipeline stabalizes and
we get correct detection.
2) Use the h264_parser to detect when individual input fields have
been combined into an output fieldpair.
I have multiple PAFF samples where this behaviour is detected. The
peeking mechanism described above will correctly detect that the
output is a fieldpair, but we need to know what the input type was
to ensure pipeline stability (only return one output frame per input
frame).
If we find ourselves with an output fieldpair, yet the input picture
type was a field, as reported by the parser, then we are dealing with
this case, and can make sure not to return anything on the next
decode() call.
Taken together, these allow us to remove the hard-coded hacks for
different h.264 types, and we can clearly describe the conditions
under which we can trust the hardware's claim that content is
interlaced.
Signed-off-by: Philip Langdale <philipl@overt.org>
Philip Langdale [Sat, 26 Mar 2011 05:48:41 +0000 (22:48 -0700)]
CrystalHD: Carry picture type from input to output picture.
Now that we know the type of the input picture, we have to bring
that information to the output picture to help identify its type.
We do this by adding a field to the opaque_list node.
Signed-off-by: Philip Langdale <philipl@overt.org>
Philip Langdale [Sat, 26 Mar 2011 05:46:22 +0000 (22:46 -0700)]
CrystalHD: Bring in h.264 parser to establish picture type.
As the hardware is unreliable, we will have to use the h.264 parser
to identify whether an input picture is a field or a frame. This
change loads the parser and extracts the picture type.
Signed-off-by: Philip Langdale <philipl@overt.org>
Philip Langdale [Sun, 27 Mar 2011 16:37:49 +0000 (09:37 -0700)]
CrystalHD: Handle different h.264 MBAFF packing.
I found another MBAFF sample where the input:output pattern is
the same as mpeg2 and vc1 (fieldpair input, individual field output).
While I'm not sure how you can output individual fields from MBAFF,
if I apply the mpeg2/vc1 handling to this file, it plays correctly.
So, this changes the detection algorithm to handle the known cases.
Whitespace will be fixed in a separate change.
Signed-off-by: Philip Langdale <philipl@overt.org>
flv: Only parse keyframe index when the underlaying protocol allows seeking as we need to seek to read the index Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fix support for flvtool2 "keyframes based" generated index in FLV format decoder
Current keyframes data parser unconditionally rewind metadata to the end
at the end of function. As result ALL metadata located after keyframes
index not parsed,
and as metadata object can have ANY placement inside metadata it can
lead to unpredictable result
(bitrate can not be found, etc.). As result FLV movie will not play at
all in such situation.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
lavf: bump minor and add an APIChanges entry for avformat cleanup
lavf: get rid of ffm-specific stuff in avformat.h
Not pulled: avio: deprecate av_protocol_next().
avio: add a function for iterating though protocol names.
lavf: rename a parameter of av_sdp_create from buff->buf
lavf: rename avf_sdp_create to av_sdp_create.
lavf: make av_guess_image2_codec internal
avio: make URLProtocol internal.
avio: make URLContext internal.
lavf: mark av_pkt_dump(_log) for remove on $next+1 bump.
lavf: use designated initializers for all protocols
applehttp: don't use deprecated url_ functions.
avio: move two ff_udp_* functions from avio_internal to url.h
asfdec: remove a forgotten declaration of nonexistent function
avio: deprecate the typedef for URLInterruptCB
* ffmpeg-mt/master:
DUPLICATE mingw32 compilation after 'unbreak avcodec_thread_init'
pthread: validate_thread_parameters() ignored slice-threading being intentionally off
DUPLICATE Remove unnecessary parameter from ff_thread_init() and fix behavior
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
proto: include os_support.h in network.h
matroskaenc: don't write an empty Cues element.
lavc: add a FF_API_REQUEST_CHANNELS deprecation macro
avio: move extern url_interrupt_cb declaration from avio.h to url.h
avio: make av_register_protocol2 internal.
avio: avio_ prefix for url_set_interrupt_cb.
avio: AVIO_ prefixes for URL_ open flags.
proto: introduce listen option in tcp
doc: clarify configure features
proto: factor ff_network_wait_fd and use it on udp
ffplay: Set EMU_EDGE if dr1, this is an alternative fix for ticket40.
Idea borrowed from mplayer. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
projects / ffmpeg / log