[XviD-devel] Re: Bugs in 1.1 beta 2

[bond]

> ----- Original Message ----- 
> From: "Michael Militzer" <michael at xvid.org>
> To: <xvid-devel at xvid.org>
> Sent: Friday, April 08, 2005 11:46 AM
> Subject: Re: [XviD-devel] Bugs in 1.1 beta 2
>
>
> Hi,
>
> Quoting Robert Swain <rob at swains.plus.com>:
>
> > XviD 1.1 beta 2 changed the DivX User Data ID from DivX999b000p to
> > DivX503b1393p. When using b-frames, multiplexing into mp4 with mp4box,
> > playing the file back via Haali's MP4 splitter the output gives very
> > strange
> >
> > jerky playback with divx and xvid dshow decoders. It almost looks to me
as
> > if the frames are being displayed in the wrong order.
> >
> > Apparently a workaround is to edit the XviD beta 2 AVI either changing
the
> > entry back to the original value or to erase it entirely before
> > multiplexing
> >
> > into mp4.
> >
> > Was there a reason for this change or is it simple enough to just change
> > it
> > back?
>
> Yep, there was a reason. We have been advised by DivXNetworks to use the
> 'DivX503b1393p' ID string for better compatibility with their DivX
products.
> So I'm rather amazed that this change introduces jerky playback with the
> DivX decoder. Can you tell us with which version of XviD you've tested?
And
> which profile was used to encode the video?
>
> bye,
> Michael


as i told nexus3 already this issue was caused as mp4box automatically
unpacks packed bitstreams when importing to .mp4 from .avi (as packed
bitstreams arent allowed in .mp4), still it didnt change the userdata which
caused that the resulting .mp4 still had DivX503b1393p there
now when playing the resulting .mp4 files with the divx5 and xvid decoder,
both seemed to think the stream was still packed because of that and played
the stream wrongly (the same goes for divx5 streams with b-frames of
course). the ffdshow (libav) decoder doesnt check the userdata and therefore
handled the file fine

the fix for this was now that mp4box changes the "p" in the userdata string
to "n" always, as it did before on DivX999b000p already, which makes the
divx5/xvid decoder not think the stream is packed and play it correctly

follow the discussion here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1178123&group_id=84101&atid=571738



a different issue, but related to the userdata:

> Yep, there was a reason. We have been advised by DivXNetworks to use the
> 'DivX503b1393p' ID string for better compatibility with their DivX
products.

btw this seems to cause problems on the siemmssen divx player as described
here:
http://forum.doom9.org/showthread.php?s=&postid=637033#post637033 and
http://forum.doom9.org/showthread.php?s=&postid=637040#post637040