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

[Stefan Gehrer]

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.

Stefan
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cavsprobe2.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090220/7c6030f4/attachment.txt>