- 11 4月, 2011 3 次提交
-
-
由 Oskar Arvidsson 提交于
Also add support for these formats in libswscale. Needed for high bit depth h264 decoding. Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
-
由 Oskar Arvidsson 提交于
Needed for high bit depth h264 decoding. Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
-
由 Michael Niedermayer 提交于
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
-
- 10 4月, 2011 7 次提交
-
-
由 Reimar Döffinger 提交于
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 提交于
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
-
由 Carl Eugen Hoyos 提交于
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
-
由 pin xue 提交于
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: NMichael Niedermayer <michaelni@gmx.at>
-
由 Michael Niedermayer 提交于
* 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: NMichael Niedermayer <michaelni@gmx.at>
-
由 Alex Converse 提交于
-
由 Reimar Döffinger 提交于
Fixes ticket #15.
-
- 09 4月, 2011 18 次提交
-
-
由 Alexander Strange 提交于
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: NRonald S. Bultje <rsbultje@gmail.com>
-
由 Reimar Döffinger 提交于
Signed-off-by: NRonald S. Bultje <rsbultje@gmail.com>
-
由 Anton Khirnov 提交于
-
由 Gwenole Beauchesne 提交于
(cherry picked from commit a18e7b4f) Signed-off-by: NReinhard Tartler <siretart@tauware.de>
-
由 Gwenole Beauchesne 提交于
This fixes ticket #23. (cherry picked from commit 621f4c98) Signed-off-by: NReinhard Tartler <siretart@tauware.de>
-
由 Philip Langdale 提交于
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: NPhilip Langdale <philipl@overt.org>
-
由 Philip Langdale 提交于
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: NPhilip Langdale <philipl@overt.org>
-
由 Philip Langdale 提交于
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: NPhilip Langdale <philipl@overt.org>
-
由 Philip Langdale 提交于
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: NPhilip Langdale <philipl@overt.org>
-
由 Philip Langdale 提交于
'git diff -w' confirmed to return nothing. Signed-off-by: NPhilip Langdale <philipl@overt.org>
-
由 Philip Langdale 提交于
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: NPhilip Langdale <philipl@overt.org>
-
由 Michael Niedermayer 提交于
flv: Only parse keyframe index when the underlaying protocol allows seeking as we need to seek to read the index Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
-
由 Kharkov Alexander 提交于
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: NMichael Niedermayer <michaelni@gmx.at>
-
由 Lou Logan 提交于
FAQ could use some work. This updates a few little details. Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
-
由 Michael Niedermayer 提交于
* 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 Merged-by: NMichael Niedermayer <michaelni@gmx.at>
-
由 Michael Niedermayer 提交于
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
-
由 Anton Khirnov 提交于
-
由 Anton Khirnov 提交于
-
- 08 4月, 2011 12 次提交
-
-
由 Anton Khirnov 提交于
-
由 Anton Khirnov 提交于
-
由 Anton Khirnov 提交于
This is more consistent with the rest of the API.
-
由 Anton Khirnov 提交于
The new name is more consistent with the rest of the API.
-
由 Anton Khirnov 提交于
It doesn't look very useful as a public function.
-
由 Anton Khirnov 提交于
-
由 Anton Khirnov 提交于
-
由 Anton Khirnov 提交于
-
由 Michael Niedermayer 提交于
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
-
由 Anton Khirnov 提交于
This is more readable and makes it easier to reorder URLProtocol members.
-
由 Anton Khirnov 提交于
-
由 Anton Khirnov 提交于
-