avi 2 mp4 - removing divx5's b-frames hacks possible with 3ivx!

[bond]

the 3ivx mp4 muxer automatically removes the hacks (packed bitstream, delay-, dummyframes) used by divx5 to put b-frames (bi-directional encoding) into avi, when muxing into mp4

this makes the 3ivx mp4 muxer the only available way to produce 100% spec compliant .mp4 files out of divx5 avis atm!

beaware

[ChristianHJW]

I can see native matroska MPEG4 files in not so far distance :D ....

[KpeX]

@bond

Thanks for the info, I'm assuming this will work for xvid as well (multiple b-frames)?

Originally posted by ChristianHJW
I can see native matroska MPEG4 files in not so far distance :D ....
Looking forward to native mkv as well...How will it be implemented? Add MP4 video input to mkvmerge?

[shitowax]

It works with variable number of b-frames packed or not, with delay/dummy frames or not. Depending of the source, the resulting stream may be VFR ...

Originally posted by KpeX
@bond

Thanks for the info, I'm assuming this will work for xvid as well (multiple b-frames)?


Looking forward to native mkv as well...How will it be implemented? Add MP4 video input to mkvmerge?

[ChristianHJW]

Originally posted by KpeX Looking forward to native mkv as well...How will it be implemented? Add MP4 video input to mkvmerge? ... i'm more thinking on a graph like

AVI/OGM/MKV splitter ---> 3ivx MP4 muxer ---> 3ivx MP4 splitter ---> matroska muxer ---> file writer

Anybody care testing if it works in principal ? Of course, matroskamuxer filter had to be modified to write native files first, including frame references .... and with Gabest not having much time anymore it will maybe be mkvmerge again, as always, reading MP4 files :) ....

[Stux]

from http://www.3ivx.com/support/tbd_45.html

Non Issues
* The muxer can not be connected to the splitter.

[bond]

Originally posted by KpeX
I'm assuming this will work for xvid as well (multiple b-frames)?xvid doesnt use packed bitstream (like divx5) to put b-frames into avi (and therefore also doesnt output dummyframes), xvid has an option to use packed bitstream, but that isnt recommended anyways

the next problem which can occur are delay frames, which are due to the vfw technology (1 frame in, 1 frame out), but every good encoding tool should skip them anyways (like virtualdub(mod) already does)

so to say:
xvid used in virtualdubmod doesnt use any of these hacks, when putting b-frames into avi!

Originally posted by shitowax
Depending of the source, the resulting stream may be VFR ...how does the source have to look like to make the muxer outputing VFR?

[shitowax]

Let's talk a bit technical ;)

As you say, if the stream was encoded by a stupid application that doesn't drop delay frames (D), you may get something like that:
I D D PB B N PB B N.
As we assume that the stream coming in the muxer is properly synchronized, we'll mux
I P B B P B B with duration
3 1 1 1 1 1 1 so, in this case, the resulting stream is VFR.

Anyway be aware, that 3ivx muxer and splitter are TOTALLY VFR. And as some encoders (like ours) are also able to produce REAL not-coded frames (N), depending of the content, you may get something like
I P P N N N N N N N N P P N N
that will be muxed in MP4 with NVop compression activated as
I P P P P
with duration
1 1 9 1 3

If you deactivate NVop compression, the stream should be muxed exactly as it enters the filter (of course if the source was already VFR, it will stay VFR in mp4 ;))

Originally posted by bond
how does the source have to look like to make the muxer outputing VFR?

[mfluder]

Originally posted by bond
xvid doesnt use packed bitstream (like divx5) to put b-frames into avi (and therefore also doesnt output dummyframes), xvid has an option to use packed bitstream, but that isnt recommended anyways

the next problem which can occur are delay frames, which are due to the vfw technology (1 frame in, 1 frame out), but every good encoding tool should skip them anyways (like virtualdub(mod) already does)

so to say:
xvid used in virtualdubmod doesnt use any of these hacks, when putting b-frames into avi!

Well XviD still has one frame delay when you are using b-frames. But that's inevitable because of VFW limitations, unless you are using some kind of hack like packed bitstream.

mfluder

[bond]

Originally posted by mfluder
Well XviD still has one frame delay when you are using b-frames. But that's inevitable because of VFW limitations, unless you are using some kind of hack like packed bitstream.hm, interesting
why and where is it placed (and why isnt it skipped by vd)?

Originally posted by shitowax
And as some encoders (like ours) are also able to produce REAL not-coded frames (N)what are nvops? :eek:

[mfluder]

Originally posted by bond
hm, interesting
why and where is it placed (and why isnt it skipped by vd)?
You know that message in VDub(Mod) when you open a file with b-frames in it: "Warning: nothing to output, bframe decoder lag", well that's the frame I was talking about. You can see that there is one frame delay if you do this: open two instances of VDub(Mod). In first one open your avs file and in second one open your b-frames file. Now move a slider in avs file to, let's say frame no. 100. Do the same thing with avi file. You'll see that the frames are not the same, but if you step to frame no. 101 in avi file you'll see that they are, hence the one frame delay.

Why this happens? Well I really don't know exact explanation but it has something to do with buffering. Maybe someone can explain it more technically. And why it isn't skipped by VDub? That's because of VFW and AVI limitations and that's the exact reason why matroska team is trying to push in that native matroska streams asap.

mfluder

[Stux]

It happens because a B frame is a bi-directionally predicted frame. This means you need two frames to predict from

so

I1 B2 P3 B4 P5 might be your display sequence

Now, the B2 frame is predicted from the I1 and P3 frame, so in order to decode the frame the decoder must have I1 and P3 first. So the encoder will write the frames in this order

I1 P3 B2 P5 B4

The problem is the decoder needs the 3rd frame in the file in order to decode the 2nd frame in the original file. So there has to be a frame of delay... unless the decoder runs a frame ahead, which the VfW architecture doesn't allow.

The normal hack is to pack the 3rd frame into the second frame so that its present at the right time.

Now, if you weren't using VfW (say you were using DirectShow instead) then you could simply take the 1 frame of delay into account and run the decoder 1 frame ahead, end of problem.

--

A frame of delay, not a delay frame. A frame of delay comes from the decoder, where as delay frames come from the encoder (and can be removed at encode time),

[shitowax]

A "VOP" is the MPEG-4 base descriptor for the frame. You can have I, P, B or S VOPs. An "NVop" is a P frame which is not coded. It's used either in the AVI b-frame packing mess, or are used when ... there is nothing to code ;)

Originally posted by bond
what are nvops? :eek:

[Hiro2k]

Originally posted by Stux

Now, if you weren't using VfW (say you were using Direct Show instead) then you could simply take the 1 frame of delay into account and run the decoder 1 frame ahead, end of problem.



So is there anyway to fix this using VfW? I am working on a music video in Adobe Premiere and my source is an XVID with B frames. The problem is that when I finally create the video, there are certain sections where I actually see in my video what Premiere sees "Warning: nothing to output, b-frame decoder lag". So is there any way that I can get rid of it?

[RadicalEd]

In the AMV business, we mostly just say "STOP EDITING WITH DIVX/XVID NOOB" cause they tend to cause crashes and stuff. Interframe codecs aren't great to edit with.

[Hiro2k]

LOL

So I take it that there is no way to fix it then. Oh well, guess I'll have to live with it.

[bond]

We definitely need a XviD directshow encoder filter (not based on the vfw lib)!

radicaled: check your pm ;)

[Neo Neko]

@Hiro2k
I can hook you up with ffmpeg compiled for windows. :D None of that funky VFW stuff and no need for directshow. Actually it is awesome. Only rub is you can't frameserve via Vdub or AVS to it. But it can open VOBs directly and convert straight to MP4 or AVI or VOB or etc or etc or etc. And it will put out either PCM, MP2 or even encode AC3 for you if you tell it! Under Linux Vorbis and Lame are also avalible. Probably AAC soon as well.

[ChristianHJW]

Originally posted by bond We definitely need a XviD directshow encoder filter (not based on the vfw lib)!

LOL ! bond, you are so well informed normally, you really wonna tell me you missed Tim Jansen's Dev API4 encoder filter ?

I am hosting it :

http://christian.matroska.org/downloads/xvidenc-api4.rar

If only Gabest had more time, Tim once offered to me to add a raw MPEG4ES output mode to it, so we could create native files on DirectShow with matroskamuxer ( Gabest had to modify it so it accepts raw ES streams and writes a native codec ID ) ....

[bond]

Originally posted by ChristianHJW
you really wonna tell me you missed Tim Jansen's Dev API4 encoder filterof course i knew that one :p
but as i understand it, it is still based on vfw...

[ChristianHJW]

Yes, the current version of Tim Jansen's encoder filter is wrapping the VfW API of xvid.dll to DirectShow, but Tim and myself already talked about adding a 'raw MPEG4ES' output pin to it, so that the filter could connect directly to matroskamuxer or any other suitable container muxer filter ( 3ivX MP4 muxer ? ), so that native MPEG4 MKV files, or MP4 files, could be made from it.

Unfortunately, with Gabest not coming to IRC for a long time, there was no way Tim and him could discuss how to do it best. The bigger effort was for Gabest in this respect, as his current matroska muxing code doesnt know about frame references IIRC, so he had to add quite some code to be able to make native files IMHO ..... unless he had to add that for RV9 muxing already, and i am talking rubbish, as usual :P ....

[shitowax]

The 3ivx MP4 muxer can use whatever input you have. "Raw MPEG4ES" or not, it's the same, it will remove useless frames, maintain the timestamping and compute track or frame offsets if required ...

Originally posted by ChristianHJW
Yes, the current version of Tim Jansen's encoder filter is wrapping the VfW API of xvid.dll to DirectShow, but Tim and myself already talked about adding a 'raw MPEG4ES' output pin to it, so that the filter could connect directly to matroskamuxer or any other suitable container muxer filter ( 3ivX MP4 muxer ? ), so that native MPEG4 MKV files, or MP4 files, could be made from it.

Unfortunately, with Gabest not coming to IRC for a long time, there was no way Tim and him could discuss how to do it best. The bigger effort was for Gabest in this respect, as his current matroska muxing code doesnt know about frame references IIRC, so he had to add quite some code to be able to make native files IMHO ..... unless he had to add that for RV9 muxing already, and i am talking rubbish, as usual :P ....

[bond]

good news :)

[Stux]

You know, its quite annoying how every 3ivx thread gets turned into a matroska thread

[tiki4]

Sorry, guy. It's the presence of ChristianHJW. What Christian touches turns into a Matroska...

You guys at 3ivx did really an impressive work. But MP4 container is still somewhat limited for us users. Maybe the tools of ENST get somewhat more user-friendly so that an ignorant guy like me can put his subs into MP4 as BIFS encoded 2D scene. Do you have any interest at 3ivx to go the EnvivioTV route?

Regards,

tiki4

[bond]

Originally posted by tiki4
You guys at 3ivx did really an impressive work.yep, we can only say a big "thank you" :)

But MP4 container is still somewhat limited for us users. Maybe the tools of ENST get somewhat more user-friendly so that an ignorant guy like me can put his subs into MP4 as BIFS encoded 2D scene. Do you have any interest at 3ivx to go the EnvivioTV route?hm, the main question is if systems 2D is really possible in directshow:
if you look at enviviotv in graphedit you will see that its more like a black box than a "normal" filter graph. everything is done inside the envivio source filter and the renderer, you cant use some outside decoders (for example you cant decode mp3 atm with the enviviotv filters)

for subs decoding enviviotv already works great, but i wonder if it is possible to write something like a "normal" bifs decoder-only filter, which functions for example gabest could implement in vsfilter to allow subs only decoding or so...

[ChristianHJW]

Originally posted by Stux You know, its quite annoying how every 3ivx thread gets turned into a matroska thread .... every thread ? Could you please point me to any other 3ivX related thread where this happened ?

Sorry for what happened here in this thread, i was pretty excited to read that you guys did what the MPEG4IP people should have implemented since long, to avoid spec incompliant MP4 files being created from DivX5 AVIs with b-frames. I didnt intend to 'convert' this thread into a matroska thread, not at all, i just saw a possible way to create our highly wanted 'native' files using your excellent muxer filter, and stated this here.

Can any mod please split the thread, and remove all posts related on how to make matroska native files ?

[bond]

ok i moved the avs2matroska parts as they really dont belong here

guys, plz note that this thread is about the great 3ivx muxer filter in the first place!
for native matroska discussion plz use already exisiting threads on that issue, thanks