[FFmpeg-devel] [PATCH] raw demuxer for Chinese AVS elementary streams

[Stefan Gehrer]

Michael Niedermayer wrote:
> On Fri, Feb 20, 2009 at 11:10:06PM +0100, Stefan Gehrer wrote:
>> Michael Niedermayer wrote:
>>> On Fri, Feb 20, 2009 at 08:16:15PM +0100, Stefan Gehrer wrote:
>>>> Michael Niedermayer wrote:
>>>>> On Fri, Feb 20, 2009 at 07:04:32PM +0100, Stefan Gehrer wrote:
>>>>>> Michael Niedermayer wrote:
>>>>>>> On Thu, Feb 19, 2009 at 09:33:54PM +0100, Stefan Gehrer wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> attached patch adds $subject. This makes it possible to test the
>>>>>>>> two samples at
>>>>>>>> http://samples.mplayerhq.hu/AVS/issue767/
>>>>>>>> Unfortunately these samples do not work properly yet, only the
>>>>>>>> I-Frames.
>>>>>>>> You can see that the patch contains a probe function and I was
>>>>>>>> trying to make that probing fairly restrictive. However, my feeling
>>>>>>>> is that a probing function is a slightly dangerous addition unless
>>>>>>>> tested against a large number of samples, which I didn't do.
>>>>>>>> So it might be better to consider the patch for after the release ...
>>>>>>> i think the probe function should be improved a bit more if possible
>>>>>>> for example there are quite a few 0x1XX codes that are neither checked
>>>>>>> for being within a valid range nor trigger detection failure
>>>>>> Okay, choose any combination of further restrictions you like:
>>>>>>
>>>>>> 1. The slice start codes are 0x100 to 01xAF. Since slices in AVS are
>>>>>> whole macroblock lines and the start code represents the vertical
>>>>>> macroblock coordinate, this could be restricted e.g. to 0x43 maximum
>>>>>> to support up to 1088 pixels vertically
>>>>> is it allowed for a single slice to contain more than 1 row? 
>>>> yes. And there might not be any slice codes at all in a frame, that is
>>>> why I could not take the pic*9<=slice*10 test from mpegvideo_probe.
>>> ok, what about order, may they be in any order or consequtive? if consecutive
>>> then this could be checked for
>> Slices have to be consecutive. I am checking that now, but did not
>> follow up on the idea of limiting the decodable height.
>>
>>>>>> 2. 0x1B4 is labelled as reserved in AVS and could trigger detection
>>>>>> failure
>>>>> yes
>>>>>
>>>>>
>>>>>> 3. Bail out if the first byte after 0x1B0 (sequence header, profile_id)
>>>>>> is not 0x20. For all AVS samples I know of it has this value,
>>>>>> corresponding to JiZhun profile.
>>>>> but does AVS allow other values?
>>>> The spec I have only defines JiZhun profile and it lists for that field:
>>>> 0x00 forbidden
>>>> 0x20 JiZhun profile
>>>> others reserved
>>>>
>>>> Now as far as I know there is also a "mobile" profile either
>>>> standardized or in the makings, and I could imagine it extending this
>>>> field by using one of the reserved values, but I have no further
>>>> information.
>>> hmm ok then add a check for 0x20, i guess that should be then enough with
>>> some luck
>> New patch attached, having the check on the 0x1B4 code and the profile
>> check when finding a sequence header.
> 
> patch ok

Thanks, applied.