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

Stefan Gehrer stefan.gehrer
Wed Jul 21 23:33:45 CEST 2010


On 07/21/2010 10:57 PM, Stefan Gehrer wrote:
> 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.

I say intermediate version here because I see no point in having such
a decoder. I think no-one would disagree that FMO has not much practical
relevance. Implementing FMO fully would therefore rather be an exercise
in spec conformance, so that regarding the statements

A) "ffmpeg can decode most H.264 baseline streams in practice"
B) "ffmpeg has a conformant H.264 baseline decoder"

we could move from A to B. But if we had FMO decoding correctly
for disable_deblock_idc == 2 only, we would still stand at A and IMHO
the exercise would be even more pointless and masochistic than it
probably already is.

Stefan



More information about the ffmpeg-devel mailing list