MP4 XviD playback

[pogo stick]

Why XviD video doesn't work right with XviD or FFDshow(XviD1) decoders in mp4 using 3viX media splitter?
Video is jumping back and forward, differently colored block all over and player hangs.
3viX or FFDshow(libavcodec) decoders are OK.
I used GraphEdit and 3viX Media Muxer.
XviD avi was:
544x400, 1414 kbps, AS @ L5, 2 B-VOPS, Closed GOV, Packed bitstream, MSP - 6, VHQ - 4, Cartoon Mode, Trellis
Thanks for any help in advance.

[tiki4]

I have a quite similar problem:

I encoded a short trailer at full 720x576 resolution and enabled DAR 16:9 in XviD encoder options. I put this XviD to MP4 container with the 3ivx muxer in Graphedit.

During decoding the file is scaled correctly to 1024x576 by the 3ivx video decoder. ffdshow with libavcodec (tested with latest builds by athos and Andy and also latest on SF) the video is not scaled. XviD connected to 3ivx splitter shows this nasty coloured blocks all over.

Funnily everything works as expected when I put the video to the Matroska container and set the display resolution to 1024x576. Tested player were mplayer2, MPC (latest) and TCMP 4.0. I tested under Windows XP SP1 and Windows 2000 SP4. The graphics card is an old Geforce 2 MX with 30.82 and 56.xx WHQL drivers by NVidia.

Any input?

tiki4

[SeeMoreDigital]

I think you'll obtain better results if you don't use packed bit-stream.

Packed bit-stream is a b-frame in AVI innovation not b-frame in MP4!


Cheers

[bond]

Originally posted by pogo stick
Why XviD video doesn't work right with XviD or FFDshow(XviD1) decoders in mp4 using 3viX media splitter?
Video is jumping back and forward, differently colored block all over and player hangs.thats the fault of the xvid decoder
the xvid decoder is the only one which analyses the bitstream description stored in the video stream. this description indicates which encoder was used to encode the stream and also whether a stream is packed or not
with packed bitstreams it looks like "DivX500b000p", the "p" indicates that the stream is packed. without packed bitstream the "p" is not there

now the 3ivx muxer doesnt change the bitstream description information during muxing, therefore the "p" stays in the bitstream description

now no mpeg-4 decoder, but xvid, cares about the bitstream description (you can try ffdshow (libav), divx5, 3ivx, nero, envivio...) and therefore no problems occur
xvid analyses the description and thinks the bitstream is packed and therefore treats it like it is packed -> jumpy playback

solution: mux with mp4box OR use another decoder OR make xvid devs change the behaviour OR make the 3ivx devs change the behaviour of their tool

Originally posted by tiki4
During decoding the file is scaled correctly to 1024x576 by the 3ivx video decoder. ffdshow with libavcodec (tested with latest builds by athos and Andy and also latest on SF) the video is not scaled.with scaled you mean anamorphic? if yes, than its because no decoder, but 3ivx and nero handle the way the par is stored in mp4

XviD connected to 3ivx splitter shows this nasty coloured blocks all over. i assume this is the same problem pogo described

[SeeMoreDigital]

I would still recommend not encoding with packed bitstream prior to muxing into MP4!


Cheers

[shitowax]

@bond: We won't change anything about our tool: our muxer won't change private user data of codecs as they are ... private ;) ... and all the decoders (except xvid) works perfectly with that ... So, you may have more success trying to convince xvid's dev that a directshow decoder can perfectly work asynchronously and doesn't care if the bitstream is packed or not... (of course, this is wrong for a VfW decoder).

@tiki4: Depending of the build of ffdshow you use, AR scaling might be activated or not by default ... or even completly deactivated ...

just my two cents.

Originally posted by bond
thats the fault of the xvid decoder
the xvid decoder is the only one which analyses the bitstream description stored in the video stream. this description indicates which encoder was used to encode the stream and also whether a stream is packed or not
with packed bitstreams it looks like "DivX500b000p", the "p" indicates that the stream is packed. without packed bitstream the "p" is not there

now the 3ivx muxer doesnt change the bitstream description information during muxing, therefore the "p" stays in the bitstream description

now no mpeg-4 decoder, but xvid, cares about the bitstream description (you can try ffdshow (libav), divx5, 3ivx, nero, envivio...) and therefore no problems occur
xvid analyses the description and thinks the bitstream is packed and therefore treats it like it is packed -> jumpy playback

solution: mux with mp4box OR use another decoder OR make xvid devs change the behaviour OR make the 3ivx devs change the behaviour of their tool

with scaled you mean anamorphic? if yes, than its because no decoder, but 3ivx and nero handle the way the par is stored in mp4

i assume this is the same problem pogo described

[bond]

hey shitowax, welcome back :)
holidays?

Originally posted by SeeMoreDigital
I would still recommend not encoding with packed bitstream prior to muxing into MP4!yep, if you aim at using smart containers like mp4 or matroska anyways, you should not use avi hackery, it doesnt help in any way :)

[pogo stick]

Originally posted by SeeMoreDigital
I would still recommend not encoding with packed bitstream prior to muxing into MP4!
Yes, but I need packed bitstream to edit video in VirtualDubMod after encoding and before muxing to mp4.
It's so painful without it.
Or is there any other similar to VDM program to edit video with 'unpacked' bitstream? :confused:
Originally posted by bond
solution: mux with mp4box OR use another decoder OR make xvid devs change the behaviour OR make the 3ivx devs change the behaviour of their tool
Fourth is impossible.
Third would be very hard, if not impossible.
Second is too easy and not interesting. :)
I tried first.
But there is another problem. :(
I'll post it in 'GPAC' thread.

[bond]

Originally posted by pogo stick
It's so painful without it.hm but not so hard ;)

Second is too easy and not interesting.lol

[SeeMoreDigital]

He, he,

Nice one bond.... Of course packed bitstream can be removed. Oddball posted a thread about it, here: -

http://forum.doom9.org/showthread.php?s=&threadid=72899


Cheers

[bond]

Originally posted by SeeMoreDigital
Nice one bond.... Of course packed bitstream can be removed. Oddball posted a thread about itsure, with the 3ivx muxer, which doesnt remove the packed flag which confuses the xvid decoder tough :)

[pogo stick]

Originally posted by bond
with packed bitstreams it looks like "DivX500b000p", the "p" indicates that the stream is packed. without packed bitstream the "p" is not there
now the 3ivx muxer doesnt change the bitstream description information during muxing, therefore the "p" stays in the bitstream description

I solved this by replacing 'p'('70') with '00' in hex editor. :)
Thanks for the hint, Bond.
Now it works!
What 'b' and numbers are for?
In my file there is 'DivX999b000' and 'XviD0034C' also.

[bond]

Originally posted by pogo stick
I solved this by replacing 'p'('70') with '00' in hex editor. :)
Thanks for the hint, Bond.
Now it works!great! i hope it doesnt break anything :D
3ivx should change this too (or at least change the "p" to "n", which will work too), as the stream simply isnt packed anymore

What 'b' and numbers are for?dunno, maybe if b-frames are used?

In my file there is 'DivX999b000' and 'XviD0034C' also. cartoon mode ;)
and yes its correct that the divx5 part is there :)

[shitowax]

Already answered. Our muxer won't have any xvid specific code...

Originally posted by bond
great! i hope it doesnt break anything :D
3ivx should change this too (or at least change the "p" to "n", which will work too), as the stream simply isnt packed anymore

dunno, maybe if b-frames are used?

cartoon mode ;)
and yes its correct that the divx5 part is there :)

[tiki4]

I might emphasize that my encoded files weren't using packed bitstream...

About the AR scaling, I don't wonder anymore, as bond stated that only Nero / 3ivx decoder handle it the way it is stored in MP4. I tested 3 different ffdshow builds and none of them scaled it (when connected to 3ivx splitter). I will post about this in the ffdshow devel thread, because this is definitely a feature I'd like to have.


Thanks for your postings.

tiki4

[Stux]

Originally posted by pogo stick
I solved this by replacing 'p'('70') with '00' in hex editor. :)
Thanks for the hint, Bond.
Now it works!
What 'b' and numbers are for?
In my file there is 'DivX999b000' and 'XviD0034C' also.

I don't have the specs with me at the moment... but you really might not want to use 0x00, I think there is a chance of creating non-compliant files if you do that.

(to do with userdata endcode emulation, and mpeg4 startcode alignment)

[pogo stick]

Oh, thanks for warning.
And replacing with what is safe? I can always change it.
Or you mean replacing is bad idea?
Originally posted by Stux
(to do with userdata endcode emulation, and mpeg4 startcode alignment)
I am not sure I understood it. :confused:
Yes, I'm dumb. :)

[Stux]

Originally posted by pogo stick
Oh, thanks for warning.
And replacing with what is safe? I can always change it.
Or you mean replacing is bad idea?

I am not sure I understood it. :confused:
Yes, I'm dumb. :)

Anything other than 0x00 should be fine I suppose

[bond]

syskin, meant that adding a "n" instead of the "p" should be ok

[stax76]

I have a different problem. It appears to be weird as I didn't find anything about this. I mux a XviD AVI created with VirtualDubMod. Now dshow players don't render the video, I tried haali's and gabest's splitters. Normally XviD would be rendered using the XviD decoder, for AVI and MKV this works fine of course. My muxing command line:

"D:\Software\AV\StaxRip Anwendungen\MP4Box\MP4Box.exe" -add "E:\Video\Samples\Handschrift des Todes\Handschrift des Todes_EncoderOutput.avi:name=Video" -add "E:\Video\Samples\Handschrift des Todes\Handschrift des Todes_AudioOutput.mp4:lang=deu:name=German:sbr" -new "E:\Video\Samples\Handschrift des Todes\Handschrift des Todes.mp4"

[SeeMoreDigital]

Before getting into the nitty-gritty issues of direct-show MP4 parsers/splitters and MPEG-4 video decoders... Can you confirm if you are able to play your encodes in VLC player?

We need to establish if your MP4 muxes actually "work" ;)

[stax76]

Sure, sorry, I completely forget to mention it since I always use VLC when DirectShow chokes. It works using VLC.

[SeeMoreDigital]

Well that's a good start!

Not so long ago I managed to get MPC to play MPEG-4 (within MP4) using XviD's decoder by checking the following option: -

http://img307.imageshack.us/img307/7397/xviddecodersettings7hz.png

Unfortunately (bizarrely) if your MPEG-4 stream contains AR signalling... it will not be detected.

Cheers

[stax76]

Thanks, that works fine!

[SeeMoreDigital]

Great.... glad I could help ;)

Now all I need to find out is why AR signalling can't be detected by XviD's decoder!?

I wonder how difficult it would be to sort out?


Cheers

[bond]

http://forum.doom9.org/showthread.php?t=105666
http://forum.doom9.org/showthread.php?t=106824

if you need the xvid decoder use the 3ivx mp4 splitter, for every other splitter use ffdshow