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

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090221/ebf8ee70/attachment.pgp>