Mpeg4 AVI compliancy discussion involving b-frame implementation & packed bit-streams

[SeeMoreDigital]

In an effort to try and resolve some basic Mpeg4 questions I think it's time that they were discussed in one thread and in one section of the forum instead of all over the place.

The hottest topics in Mpeg4 seems to be with respect to b-frames (aka B-VOP or bi-directional encoding), multiple b-frames and of course packed bit-streams and which method of implementation offers the most compliancy!

Here is what DigitAl56K (of DivX/DXN) had to say about this subject:Actually, this is a misconception. Our bitstream is compliant, it is simply the way that it is stored in the AVI container that is different. Thus, non-certified devices may have problems with packed bitstream in AVI containers if the manufacturer did not consider this in their design. Certification ensures that these issues are caught before a player goes to market. Needless to say our very own bond, was able to present the following argument: well there are also devs around, who are deep into mpeg-4, like Michael Niedermayer from ffmpeg, which have the optinion that packed bitstream breaks the compliance with the mpeg-4 standard

Also a decoder written by following the mpeg-4 standard only, might not be able to decode packed bitstreams. for being able to decode pb extra code has to be added, thats not what i call mpeg-4 compliance but still packed bitstream is here and will not go away (unless people adopt the mp4 container) Here's a link to a post which asks: Is Packed Bitstream an useless setting nowadays? (http://forum.doom9.org/showthread.php?s=&threadid=78329)

One thing is clear. If this issue is to continue to remain unresolved we'll never be able to have true Mpeg4 interoperability. We need to know who's right and who's wrong, so we can all move in the same direction and enjoy a less confused market.


What do you guys have to say about it?


EDIT: Title change - and it only just fits in!

[Sharktooth]

PB was "invented" to use B-Frames in AVI.
And AVI is not in the mpeg4 specs...

[SeeMoreDigital]

You're right.. it's time for a slight title change already!


Cheers

[stephanV]

could we first define what "interoperable" means then, because it not necessarily means the same thing as being compliant.

according to bond in this thread (http://forum.doom9.org/showthread.php?s=&threadid=77577&perpage=20&pagenumber=4):

still placing private/not defined streams in mp4 doesn't break the compliance with the mpeg-4 standard! in fact the standard explicitely gives the possibility to place private streams in mp4 with a privately chosen id (something comparable to fourccs in avi, which are also privately chosen)
therefore the only difference, regarding this issue (!), between placing any stream in matroska and placing any stream in mp4 is that for mp4 these "ids" are not defined in the specs (they are only defined for mpeg streams (asp, avc, aac, mp3, mp2...))


still i also dont think that private streams should be placed in mp4 (with the exception of vobsubs, as they will be supported on standalones), as it hurts interoperability

so apparently "compliant" means something different as "interoperable". personally, i couldn't care less if MPEG4 in avi should be considered a hack or not (compliant). thats just theory, which is nice for purists but not for me. what i do care about is if it works or not (interoperable).

as we are obviously going to have hacks in avi (and why not?) and neither DivX or XviD support the MP4 container, it would be nice if there was some consistency/agreement in how some of the hacks are used (maybe there is already?).

[SeeMoreDigital]

Obviously what DivX and XviD are doing is very important but lets not forget about FFmpeg and Nero are doing about this issue too!

Given that Nero and Kiss/Sigma are all very chummy at the moment, is anyone able confirm weather or not Nero will be offering an Mpeg4 in AVI encoder (as well as an Mpeg4 in MP4 encoder)?

If Nero are going to offer an Mpeg4 in AVI encoder, surely it won't incorporate packed bit-streams!


Cheers

[bond]

well first of all i wanted to say that this discussion comes far to late (and has been discussed already extensively before - use search ;) ), packed bitstream exists and will not go away, whether its mpeg-4 compliant or not

still i think important to mention is in this context that a mpeg-4 decoder which was written following the official mpeg-4 specs will not be able to decode a packed bitstream!
the decoder has to be adopted in a special way to handle packed bitstreams, adopted in a way not described in the official mpeg-4 specs
thats what i heard from devs who are into this stuff, if someone has another technical opinion i would interested in hearing it :)

now if a decoder following the specs cant decode a stream, would you still call the stream mpeg-4 compliant?

[SeeMoreDigital]

While some of us already know that there are discussions regarding this topic already on the forum they appear to be rather 'fragmented'!

Usually you have XviD people in their forum, defending their position and DivX people, in their forum defending their position... and just like the codecs, nothing seems to be coming together. By posting (yet) another discussion here I was hoping that DivX and XviD (sorry 3ivx but you haven't got your own forum section - yet!) might post their comments, reasons, suggestions, dreams etc in one place... And this debate is not solely open to the two main codec players. It's important that the likes of 3ivx, FFmpeg, Nero and any Mpeg4 codec manufacturers join in too.

Call it a meeting of minds, if you will. But if nobody from "the manufacturers" attends, you can't say we "the customers" didn't try to sort out their mess!


Cheers

[Latexxx]

Originally posted by bond
now if a decoder following the specs cant decode a stream, would you still call the stream mpeg-4 compliant?

and the only thing defined in MPEG standards is the decoder.

[Stux]

Originally posted by Latexxx
and the only thing defined in MPEG standards is the decoder.

And the bitstream.

[SeeMoreDigital]

Hi Stux,

I gather 3ivx's next codec release will not include encoding with b-frames.

But as a matter of interest, how would you implement them?


Cheers

[Stux]

Originally posted by SeeMoreDigital
Hi Stux,

I gather 3ivx's next codec release will not include encoding with b-frames.


Awfully big assumption there ;)

Anywho..


But as a matter of interest, how would you implement them?


We wouldn't use packed bframes

[SeeMoreDigital]

I've just generated some B-VOP encodes using the latest version of Nero Recode2 (with v1.2.3.4 encoder filter).

Obviously the encodes are automatically placed within the .MP4 container and don't contain packed bitstream, or GMC or Qpel for that matter! Even so I'm happy to announce that they all worked perfectly with the Xcard.

I've also performed tests with various software players after using mp4UI to de-mux the video stream to the .AVI container.

Upon playback, when using the DivX decoder there's major pixelation drop at every scene change. But with XviD, 3ivX and Nero decoders the playback is perfect. AVI Playback is also perfect in hardware via Sigma Xcard.

So this throws up an puzzling question which maybe the guys at XviD can answer!

How come DivX 1B-VOP encodes (with or) without packed bit-stream and now Recode2 1B-VOP encodes without packed bit-stream work with the Xcard when XviD 1B-VOP encodes don't?

I will provide a short Recode2 1B-VOP samples (in AVI and MP4) if people want to test them in their own hardware and software players.... just ask!


Cheers