- 10 Apr, 2011 26 commits
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
-
Oskar Arvidsson authored
This patch completes the high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
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 authored
In high bit depth, the QP values may now be up to (51 + 6*(bit_depth-8)). Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
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>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
The functions moved are used when decoding h264. Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Also add support for these formats in libswscale. Needed for high bit depth h264 decoding. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Oskar Arvidsson authored
Needed for high bit depth h264 decoding. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Reimar Döffinger authored
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".
-
Ronald S. Bultje authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Carl Eugen Hoyos authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
pin xue authored
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>
-
Michael Niedermayer authored
* 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. Merged-by: Michael Niedermayer <michaelni@gmx.at>
-
Alex Converse authored
-
- 09 Apr, 2011 14 commits
-
-
Reimar Döffinger authored
Fixes ticket #15.
-
Alexander Strange authored
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>
-
Reimar Döffinger authored
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Anton Khirnov authored
-
Gwenole Beauchesne authored
(cherry picked from commit a18e7b4f) Signed-off-by: Reinhard Tartler <siretart@tauware.de>
-
Gwenole Beauchesne authored
This fixes ticket #23. (cherry picked from commit 621f4c98) Signed-off-by: Reinhard Tartler <siretart@tauware.de>
-
Philip Langdale authored
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 authored
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 authored
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 authored
In preparation for adding additional fields to the node, return the node instead of the pts value. This requires the caller to free the node. Signed-off-by: Philip Langdale <philipl@overt.org>
-
Philip Langdale authored
'git diff -w' confirmed to return nothing. Signed-off-by: Philip Langdale <philipl@overt.org>
-
Philip Langdale authored
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>
-
Michael Niedermayer authored
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>
-
Kharkov Alexander authored
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>
-