[FFmpeg-devel] [PATCH] issue251, xvid within .ogm will not remux to .avi

[Michael Niedermayer]

On Tue, May 27, 2008 at 01:27:36PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Mon, May 26, 2008 at 07:29:40AM +0100, M?ns Rullg?rd wrote:
> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> 
> >> > Hi
> >> >
> >> > The patch below will fix remuxing from some ogm. Iam not 100% sure that
> >> > this is the correct solution though ...
> >> 
> >> I believe you, but could you please explain a little.
> >
> > Where should i start ...
> >
> > The mpeg4 stream in this ogm uses these infamous packed b frames which avi
> > with some demuxers needed.
> > This should make pts=dts of the packets.
> >
> > Now, the first packet that comes out of the ogg demuxer for the video stream
> > had a pts=0
> > Then it returned 7 packets with pts=AV_NOPTS_VALUE
> > and then a packet with pts=7
> >
> > This cannot be correct as there are just 6 distinct pts values between 0 and
> > 7. (and packed b frames means the stream should behave as if pts=dts and
> > theres no frame reordering)
> 
> In that case, the file is invalid.
> 
> > droping the first timestamp (or using -1) is the smallest change which fixes
> > the issue. I do not know what the correct timestamps are supposed to be. 
> 
> Discarding information from valid files (all ogg files, not just ogm)
> for the sake of one broken ogm file is unacceptable.

not arguing for my patch, but i just found another related issue.
oggdec.c does discard the first timestamp in the start_time calculation
It does so twice actually, once through its design and secondly by an
explicit ogg->streams[i].granule != 0. But as said even without that
check it still looses the first zero timestamp.

The effect of that is that AVPackets returned start from pts==0 while
start_time is set to something like +300ms
this obviously is contradictionary ...

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

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- 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/20080625/9c763138/attachment.pgp>