XviD to 3ivx then back to XviD (Packed Bitstream removal problem)

[oddball]

I want to remove packed bitstream (Please turn if off by default as release groups are using it without realising it making some stand alones b0rk!)

I do my usual graphedit to 3ivx MP4 then back to AVI which strips out packed bitstream.

However. When doing this the resulting AVI still has 3ivx as FourCC and decoder. If I uninstall 3ivx then playing back the AVI results in a blank screen. XviD will not playback 3ivx either.

I want the AVI as it was before but without packed bitstream and nothing else.

Any ideas?

BTW just changing the FourCC to XvID makes no difference on the decoding issue.

[oddball]

Nevermind. MP4UI does it properly. If you use Graphedit to mux a 3ivx MP4 file back to an AVI file I noticed that it does not rewrite all the tags that tell the decoder that it's an XviD file. It leaves it set as 3ivx instead which means only 3ivx plays the file (Even though it was encoded in XviD). If you then uninstall 3ivx the video refuses to play as there is nothing there to read the 3ivx tags in the AVI file.

MP4UI appears to rectify that.

[oddball]

Hmm. MP4UI writes the correct AVI FourCC and decompressor tags but breaks something in the process. The video is super jerky. :/

[bond]

Originally posted by oddball
BTW just changing the FourCC to XvID makes no difference on the decoding issue.the problem is the following:
most codecs set a bitstream description in the video bitstream (not on the container level)
divx5 and xvid indicate there whether a stream is packed or not

now when you use 3ivx to unpack, it still will not change the original bitstream description set by the encoder, which means the bitstream description still claims that the stream is packed, altough it isnt packed anymore

basically thats no problem at all, except when you use the xvid decoder. the xvid decoder, in contrary to other dshow mpeg-4 decoder (tested ffdshow, 3ivx, divx5 and nero digital) looks at the descritption and than decodes according to the info it gets there, which leads to problems as xvid treats the stream as if it were packed altough its not packed anymore

so using any other decoder, but xvid should solve the problem

[oddball]

OK this gets even weirder. It appears the jerkiness is introduced after packed bitstream is removed and only when playing back with XviD's decompressor. Using ffdshow and there is no jerk.

XviD is a fussy and annoying bloody codec!

EDIT: Oops! Yeah just read the reply. You are correct of course.

[bond]

btw its not xvid 2 3ivx 2 xvid, its always mpeg-4

what you do here is removing avi hacks ;)

and another point when wanting to reconvert to avi:
untick the "compress n-vops option" in the 3ivx muxer, cause this can create variable framerate streams in mp4, which are not possible in .avi (will lead to sync issues) - check if the input and ouput avi have the same framenumber to be sure

[SeeMoreDigital]

I did some tests last week with GraphEdit de-muxing known XviD and 3ivX streams out of an MP4 container to an AVI container. When I checked the AVI's 4CC with Gspot they were both described as being mp4v.

May I ask someone to confirm which Mpeg4 encoders offer packed bitsream encoding and which ones don't. As far as I know: -

DivX - does but does not give you an option of not using it.
XviD - does but does give you the option of not using it.
3ivX - not sure
FFvfw - not sure

I wonder if it's worth the time and effort creating some kind of bar chart listing the current functions and features of the most popular Mpeg4 codecs?

Cheers

[gotaserena]

Maybe someone could create a utility that switches off the packed bitstream information that XviD writes. It's a pity that one cannot use the XviD decoder to play mp4 files (except when one remembers to switch off pb before encoding).

[bond]

Originally posted by SeeMoreDigital
When I checked the AVI's 4CC with Gspot they were both described as being mp4v.exactly the 3ivx splitter always outputs "mp4v"

May I ask someone to confirm which Mpeg4 encoders offer packed bitsream encoding and which ones don't.packed bitstreams i used always in divx5 when using b-frames (you cant turn it off)
xvid has an option to turn it off/on

afaik no other encoder uses packed bitstream

Originally posted by gotaserena
Maybe someone could create a utility that switches off the packed bitstream information that XviD writes.the 3ivx guys meant, they are not going to mess around with the bitstream descritptions set by the encoders

It's a pity that one cannot use the XviD decoder to play mp4 files (except when one remembers to switch off pb before encoding)hum till than you can use ffdshow, which is imho simply the best mpeg-4 decoder out there

[gotaserena]

About the pb utility, I was thinking more along the lines that one of the XviD team would do that :)

About ffdshow vs. XviD, I'm having some colors mismatches in ffdshow. Part of it was due to MPC, but I still find XviD rendition closer to the original. I have not, however, player with all the switches of ffdshow to bring it to my liking... So, yes, it's my fault ;)

[Jawor]

What iDCT did you use in ffdshow? Was it something other than "XviD"? If yes, try with iDCT="XviD" (in the "Miscellaneous" tab).

But probably you knew that already...

[SeeMoreDigital]

Originally posted by gotaserena
Maybe someone could create a utility that switches off the packed bitstream information that XviD writes. It's a pity that one cannot use the XviD decoder to play mp4 files (except when one remembers to switch off pb before encoding). I'm assuming you're using a hardware device to view your encodes, which is why you are seeing weird things happening. So given that many hardware players don't like more than 1No b-frame and/or packed bitstream (and that packed bitstream and b-frame encoding come hand-in-hand) maybe you could start generating XviD encodes without more than 1No b-frame and/or without packed bitstream'.

I'm reminded, that a lot of people gave XviD some stick regarding generating encodes with 'multiple' b-frames. However, I can confirm that this is not just an XviD issue. You see exactly the same problems when encoding multiple b-frames with FFvfw encoder - or at least I do. Which is why I asked my 'packed bitstream' question, in my previous post!

In short, which causes the most problems. Packed bitstream or multiple b-frames. Or is it the hardware manufacturers fault for promoting DivX's 'certificated' version of Mpeg4 (along with it's crappy 1 warp point and 1 b-frame limitation), while freezing everybody else's version of Mpeg4 out at the same time. I'm starting to think it's more to do with the latter?

Sorry for rambling on...

Cheers

[Jawor]

Or is it the hardware manufacturers fault for promoting DivX's 'certificated' version of Mpeg4 (along with it's crappy 1 warp point and 1 b-frame limitation), while freezing everybody else's version of Mpeg4 out at the same time. I'm starting to think it's more to do with the latter?
I agree. Hardware compatibility profiles are DXN's strategy to keep their position on the market - their codec is too crappy to compete with XviD without such tricks. Many standalone player owners think it's XviD's fault when an XviD-encoded file doesn't play right - I've seen many such posts on a "standalone players" discussion forum in Poland. It' hard to convince them, that XviD is not "broken" and that player manufacturers should implement hardware decoding of real MPEG-4 profiles instead of sticking with DXN profiles.

[gotaserena]

@SeeMoreDigital: actually my Xcard doesn't complain about packed bitstream because the 3ivx muxer strips them from the final .mp4 file :) The problem arises when I try to watch the file in my computer using the XviD decoder.

@Jawor: thanks for the tip. I'm still messing around with ffdshow. LigH gave exactly the same suggestion yesterday.

[virus]

Originally posted by Jawor
Many standalone player owners think it's XviD's fault when an XviD-encoded file doesn't play right - I've seen many such posts on a "standalone players" discussion forum in Poland. It' hard to convince them, that XviD is not "broken" and that player manufacturers should implement hardware decoding of real MPEG-4 profiles instead of sticking with DXN profiles.
...but, as a matter of fact, XviD follows none of the "real" MPEG-4 profiles, since there's no VBV support in the 1.0 branch.
So the standalone owners are just saying the truth in some cases... but sadly blaming DivX for everything is a common activity on this forum ;)

cheers :)
virus

[Jawor]

I don't blame DivX for everything. OK, I blame it for almost everything :D

Of course I'd like to see VBV support in XviD - it's lack is one problem when trying to decode XviD by hardware, but not the only one. I just don't want people to hate XviD because of its more advanced features (like 3-warppoint GMC, multiple B-frames).

[virus]

Originally posted by Jawor
I just don't want people to hate XviD because of its more advanced features (like 3-warppoint GMC, multiple B-frames).
oh yeah, I agree on that. But there's nothing wrong in defining some profiles to ensure hardware compatibility. And, you know, there are features like Qpel and GMC which are not easy to implement in hardware, so the choice made by DXN seems quite sensible to me.

[Jawor]

But there's nothing wrong in defining some profiles to ensure hardware compatibility.
No, there's nothing wrong with that. DXN, just as any other company, want to sell their product, so they have to do something to beat their comptetitors. XviD is certainly the most dangerous of them, but it has no financial support from any industry, so hardware compatibility profiles are a good strategy to make people encode with DivX, although it is less advanced than XviD.

[oddball]

What I would like to see is XviD have it's default setup set to max compatability with hardware (and software) players. If people want to fiddle with the extra encoding settings then fine. But please don't force XvID features on people by default as the newbies will end up encoding stuff in XviD and then finding it does not playback on their shiney new MPEG4 player.

EDIT Why not even put it as an install option? "Would you like to use XviD's special features or use maximum compatability mode (Maximum compatability mode ensures playback on most hardware players)? YES/NO"

Simple really.

[SeeMoreDigital]

The fact is the DivX version of the Mpeg4 codec came out long before a hardware players did. DivX confused the hardware player market by effectively saying "ASP profiles are OK in Mpeg4, but only as long as you implement them our way, ie: using 1 warp point and 1 b-frame".

It was all very good at the time, but things have moved on at quite a pace. So much so that we now have hardware players with more than enough computing power to cope with features such as multiple b-frames and 3 warp points. Hell if they can cope with Qpel, they should be able to cope with just about anything!

Don't get me wrong I like DivX. I've still got at least 100 movies on my server using the DivX codec. Arguably, if it was not for them (and their certification), who knows where the Mpeg4 hardware player market would be now. But I think you can't argue that they are 'currently' a bit behind the Mpeg4 times... no multiple b-frames, no 'solid' warp point configuration, no 'anamorphic signalling' implementation. Jeez, they even removed MP4 container support after DivX5.0.2. How forward thinking was that?

Gej has hinted by saying future versions of DivX will include multiple b-frame encoding... I only hope that their certification program will be altered accordingly and more importantly, that owners of existing Mpeg4 hardware players will be able to receive firmware up-dates so their players can cope with them!

Cheers

[bond]

Originally posted by virus
And, you know, there are features like Qpel and GMC which are not easy to implement in hardwarethats not really true
simply because some first generation decoder chips didnt handle this (namely ess and sigma), it doesnt mean that qpel and gmc support is "not easy to implement"

people should simply not buy such a crap, buy players using better chips, like mediatek or the upcoming new sigma chip

[SeeMoreDigital]

Originally posted by bond
...people should simply not buy such a crap, buy players using better chips, like mediatek or the upcoming new sigma chip Agreed!

However, personally speaking, there's no way I'm going to spend money on a hardware player just yet. And I wont until they start offering MP4 container support (with AAC audio of course), anamorphic signalling, networking, and more than 2GB Mpeg4 file size support!

Cheers

[bond]

Originally posted by SeeMoreDigital
And I wont until they start offering MP4 container support (with AAC audio of course)from what i heard the firmware of the upcoming sigma chip will support .mp4 (including aac)
the new kiss players will use this chip (which supports qpel, but still not 3warppoint gmc as offered by xvid, only weak 1warppoint as divx5 uses :rolleyes: )

[Chainmax]

Is using packed bitstream a good idea or not then?

[bond]

Originally posted by Chainmax
Is using packed bitstream a good idea or not then?it depends what your standalone needs
if you dont own a standalone it depends whether you are smart enough to realise that the "decoder lag" message is not a bug

i always disable pb because its just yet another avi hack and i mux into .mp4 where pb is not allowed anyways

all-in-all both ways can cause different (not serious) troubles...

[Chainmax]

I won't use it then. Thanks for the clarification.

Originally posted by SeeMoreDigital:
However, personally speaking, there's no way I'm going to spend money on a hardware player just yet. And I wont until they start offering MP4 container support (with AAC audio of course), anamorphic signalling, networking, and more than 2GB Mpeg4 file size support!
If you're only interested in MPEG4 playback, you could use an XBOX.

[SeeMoreDigital]

Originally posted by Chainmax
If you're only interested in MPEG4 playback, you could use an XBOX. That's not a bad idea!

I find it very amusing that a M$ product can be hacked to play Mpeg4/AAC streams in an MP4 container :D

It's not a bad price either, when you factor in all of it's other features.

Does anybody know if its RGB output picture quality is any good?

Cheers

[Chainmax]

Not only that, but you also get a superb emulation machine as well.
While we're on the subject, does anyone know if XMC plays nice with packed bitstream?