[FFmpeg-devel] [PATCH] Parse H.264 is ASF.

[Michael Niedermayer]

On Tue, May 25, 2010 at 02:39:38AM -0400, Alex Converse wrote:
> On Sat, May 22, 2010 at 3:26 AM, Reimar D?ffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > On Fri, May 21, 2010 at 10:52:07PM -0400, Alex Converse wrote:
> >> On Thu, May 20, 2010 at 2:08 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > On Wed, May 19, 2010 at 04:36:16PM -0400, Alex Converse wrote:
> >> >> My H.264 in asf samples[1] seem to put SPS and PPS in its own packet
> >> >> which creates all kinds of problems when remuxing (notably duplicate
> >> >> timestamps and an empty avcC). The attached patch turns on the parser
> >> >> to combine the packets. All my H.264 in asf samples are from the same
> >> >> source so if people have other samples to verify this on, let me know
> >> >> (I didn't find anything on samples.mphq.hu)
> >> >>
> >> >>
> >> >> [1] /incoming/h264_aac_zeropad.asf
> >> >>
> >> >> Regards,
> >> >> Alex Converse
> >> >
> >> >> ?asfdec.c | ? ?2 ++
> >> >> ?1 file changed, 2 insertions(+)
> >> >> cb107db59fdfb193268b15dfd1f5519a0ba1195f ?0003-Parse-H.264-in-ASF-because-SPS-PPS-lives-in-its-own-.patch
> >> >> From ecd789ea2122615205dcd2250715aae1463ef0b4 Mon Sep 17 00:00:00 2001
> >> >> From: Alex Converse <alex.converse at gmail.com>
> >> >> Date: Wed, 19 May 2010 15:57:37 -0400
> >> >> Subject: [PATCH 3/3] Parse H.264 in ASF because SPS+PPS lives in its own packet.
> >> >
> >> > microsoft doesnt fail to come up with new stupidities.
> >> > are there more than some pps/sps at the begin?
> >> > if yes your patch is ok
> >> > otherwise we maybe could try to disable parsing once we are past the pps/sps,
> >> > would make the code slightly faster
> >> >
> >>
> >> To risk sounding like a total goon, where would be a good place to
> >> turn the parser off with some sort of reliable synchronization? Would
> >> it be best to add some sort of PARSE_FLAG_ONCE and do it in the parser
> >> or would there still be giant parser overhead?
> >
> > Is there a problem with just (mis-)using AVSTREAM_PARSE_HEADERS?
> > I suspect it won't work, but maybe to keep it analogous a AVSTREAM_PARSE_EXTRACT_HEADERS?
> 
> AVSTREAM_PARSE_EXTRACT_HEADERS seems to sound like the the description
> of AVSTREAM_PARSE_FULL.
> 
> > And IIRC there should be some parser already that switches itself of (by directly
> > returning the input data), but I couldn't find it right now.
> >
> 
> I can't seem to find it either.
> 
> Does attached seem fair?

looks ok to me but please document that this has only been implemented in h264

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20100526/ad1fd8ba/attachment.pgp>