[FFmpeg-devel] [PATCH/RFC] H.264 FMO+ASO decoding

Stefan Gehrer stefan.gehrer
Wed Jul 21 22:57:03 CEST 2010


On 07/21/2010 10:29 PM, Jason Garrett-Glaser wrote:
> On Wed, Jul 21, 2010 at 1:20 PM, Stefan Gehrer<stefan.gehrer at gmx.de>  wrote:
>> Hi,
>>
>> attached is a patch that implements the header stuff for FMO decoding
>> in H.264 baseline streams. It decodes the slice group map and also
>> provides means that at the start of a slice the actual x/y position
>> of the first macroblock can be determined from first_mb_in_slice.
>> If this is done, slices can be decoded out of order, i.e.
>> first_mb_in_slice does not have to increase for slices of the same
>> picture (aka ASO).
>> Let's take as example a tiny video of 4x3 macroblocks which
>> has a slice group map with two slice groups like this:
>>
>> 1  1  1  1
>> 1  0  0  1
>> 1  1  1  1
>>
>> Each slice group itself (0 or 1) is decoded in raster-scan order,
>> so that the macroblock addresses are as follows:
>>
>> 2  3  4  5
>> 6  0  1  7
>> 8  9 10 11
>>
>> So if a slice comes along with first_mb_in_slice equal to 7 we need
>> to start decoding at MB position x=3 and y=1.
>>
>> Unfortunately, the real challenge starts here. A lot of neighbor
>> context handling (i4x4 modes, non-zero counts, MVs) has to be
>> handled differently when the assumption of raster-scan order of
>> macroblocks is not true anymore. Also, deblocking can only be done
>> after the picture has been fully decoded. This is because deblocking
>> goes across slice boundaries and slice group boundaries and the
>> neighbor MB might just happen to be the last to be decoded in the
>> picture.
>
> Not if disable_deblock_idc == 2.

Well yes. Of course an intermediate version could deblock in order.
It would be bitexact for disable_deblock_idc equal to 2.
Otherwise disable_deblock_idc = 2 could be forced internally so
that no deblocking with yet-undecoded pixels takes place and
the output may actually look okay for some low quantizers.



More information about the ffmpeg-devel mailing list