MPEG-4 video codecs crippled for avi?

[Elias]

Originally posted by Neo Neko
To be quite honest with you Xvid is not AVI specific. There are two versions of Xvid. The original container agnostic non VFW binaries and the AVI crippled VFW binaries. Xvid can be encoded via ffmpeg and written to MP4 or it can be encoded by standalone binaries with the output piped through ffmpeg to an MP4 file. 3ivx I believe is in a similar situation. They have both VFW encoder binaries crippled for AVI and Directshow binaries that are not AVI crippled.

In fact about the only MPEG4 codec which is AVI specific or AVI only is Divx. DXN is trying to focus on image quality which is great but I fear is also pointless. Their competitors not only keep catching up but pulling ahead. What DXN should have been doing IMO is exactly what nero did. Release a tool suite to go MP4 all the way or as close as they could. Ancient versions of Divx had the ability to repackage to MP4. It was not spec compliant but it was a start. And they continued that start by removing it ever since then. Now they have themselves in a bit of a pickle. They have promoted all this "Divx compliantness" which doesn't really support MPEG4 all that well and only supports AVI. Any changes to their codec to remedy things will break their compliance or at least lead to profiles that most of their non-savy users will never use. So it becomes a waste of R&D effort. Neo Neko wrote this in another thread about QT7. http://forum.doom9.org/showthread.php?s=&threadid=88976 Can someone explain what this means? Is DivX less of an MPEG-4 ISO compliant codec than XviD? I can't tell any difference when muxing DivX4/5 video into an mp4 container. How can DivX be avi only if the video works great in mp4?

[celtic_druid]

How can DivX be avi only if the video works great in mp4?
And how exactly do you get it into mp4? You have to encode to avi first as the codec is closed source and the only version available is a VfW encoder. Where as with XviD you can output to mp4, m4v, etc. No need to output to avi first.

The main issue with avi and VfW is bframes.

DivX once properly muxed to mp4 should be just as ISO MPEG-4 compliant is anything else.

[Elias]

Originally posted by celtic_druid
How can DivX be avi only if the video works great in mp4?
And how exactly do you get it into mp4? You have to encode to avi first as the codec is closed source and the only version available is a VfW encoder. Where as with XviD you can output to mp4, m4v, etc. No need to output to avi first.

The main issue with avi and VfW is bframes.

DivX once properly muxed to mp4 should be just as ISO MPEG-4 compliant is anything else. Aaaah, I see :) Well I don't use bframes either way. But I take it that it's a problem in avi for standalones? Because I haven't noticed any trouble with bframes in avi whatsoever.

[Neo Neko]

Originally posted by Elias
Neo Neko wrote this in another thread about QT7. http://forum.doom9.org/showthread.php?s=&threadid=88976 Can someone explain what this means? Is DivX less of an MPEG-4 ISO compliant codec than XviD? I can't tell any difference when muxing DivX4/5 video into an mp4 container. How can DivX be avi only if the video works great in mp4?

Strictly speaking Divx bitstreams are not true MPEG4. You have to "un-pack" them before they become compliant. Just slightly less work than it is to turn MSMPEG4 streams into compliant MPEG4 streams. Needless to say packing them was brought about as a work around for VFW/AVI. And not at all necessary or propper with a propper container. Xvid for instance only supports it largely to be "Divx" compatible and not MPEG4 compatible.

There are many dificulties involved with using MPEG4 streams in AVI. The feature set has to be restricted in many cases effectively cripling the bitstream. Though sometimes I admit I over generalize. The majority of problems and cripling arise from VFW. Which is often synonimous with AVI. If you were to encode via directshow it would eliminate several problems but not all. Problem is DXN at least consumer wise is all about VFW and AVI. I hope this will change in the future. But I can only hold out little hope.

So if we disregard the packed bitstreams issue. Divx "is" MPEG4 compliant. In a very basic way. It just lacks alot of configuration and flexibility that is part of the MPEG4 spec. And Divx is AVI only because that is all DXN supports. They don't even provide their own tools to extract and unpack their own bitstreams let alone mux them into anything else. That is all acomplished through 3rd party tools.

[stephanV]

Originally posted by Neo Neko
So if we disregard the packed bitstreams issue. Divx "is" MPEG4 compliant. In a very basic way. It just lacks alot of configuration and flexibility that is part of the MPEG4 spec.
Configuration like what?

And Divx is AVI only because that is all DXN supports. They don't even provide their own tools to extract and unpack their own bitstreams let alone mux them into anything else.
And they should do that because... ?

[Elias]

I don't get it why people and software companies like DXN go through so much trouble for the sake of *.avi because in my opinion, it's not worth all the hassle and the trouble that comes with it. Sure, some might argue that *.avi has compatibility, but still, I don't see why they didn't aim for full MPEG-4 compliance like Nero did. Neo Neko, do you know perhaps how to make MSMPEG4 ISO MPEG-4 compliant? I'd like that because I got a bunch of DivX 3.11 stuff that I want to convert into mp4 without losing quality.

[Tommy Carrot]

Originally posted by Elias
I don't get it why people and software companies like DXN go through so much trouble for the sake of *.avi because in my opinion, it's not worth all the hassle and the trouble that comes with it. Sure, some might argue that *.avi has compatibility, but still, I don't see why they didn't aim for full MPEG-4 compliance like Nero did.
Probably because full MP4 support is impossible or at least very hard via the VFW interface, and VFW is still the most (or should i say only) popular video codec interface so far. IMO many people feels that MP4 simply doesn't offer enough advantage to completely drop the nice and comfortable VFW solution for some closed/proprietary encoder. MP4 container needs an open/general purpose encoder, like virtualdub, to gain more acceptance among the users imo.

[Elias]

Originally posted by Tommy Carrot
Probably because full MP4 support is impossible or at least very hard via the VFW interface, and VFW is still the most (or should i say only) popular video codec interface so far. IMO many people feels that MP4 simply doesn't offer enough advantage to completely drop the nice and comfortable VFW solution for some closed/proprietary encoder. MP4 container needs an open/general purpose encoder, like virtualdub, to gain more acceptance among the users imo. Yeah. Why can't a bunch of skilled dudes make an mp4 virtualdub? Like they did with VDubMod, but for mp4?

[Tommy Carrot]

Originally posted by Elias
Yeah. Why can't a bunch of skilled dudes make an mp4 virtualdub? Like they did with VDubMod, but for mp4?
It's not so simple. VDM is based on VFW as well, and it's not sufficient for proper MP4 support. For that, someone should develop a new and better general interface first (no, directshow is not good for that), and it would be a very hard task, it would probably take years.

[hhanh00]

Originally posted by Tommy Carrot
It's not so simple. VDM is based on VFW as well, and it's not sufficient for proper MP4 support. For that, someone should develop a new and better general interface first (no, directshow is not good for that), and it would be a very hard task, it would probably take years.

I can see why Dshow is not much better than Vfw but what would a better interface bring? Could you give as much detail as possible in your answer because I haven't found much info on the subject.

These are some ideas to get the conversation started:

1> vfw is 1-frame in 1-frame out. dshow uses a push model. Using vfw, one has to generate fake frames for b-frames. With dshow, you can return 'empty' frames. They would mean that the previous frame should be repeated. A variable framerate container could use that feature. So instead of this work around, one could imagine an interface where a variable frame rate was directly supported
2> vfw and b-frames introduce delay frames. They can be dropped by the encoding app (such as vdubmod). However, they are not distinguishable from the 'empty' frame/repeat frame. (Btw, what happens to the frames at the end? If vfw is 1-1, having N fake frames should mean N missing frames at the end. :-?)
That is debatable. You could reserve another kind of frame for that. Another hack but it is possible, isn't it?
3> with a direct access to the parameters of xvid_encode, you could tweak them on a frame by frame basis. It's similar to what nandub is doing, right? with an open source encoder, it's not obvious to me why you would need to do that
4> what else? color spaces? i/b/p frame type decision? frame ordering?
non-rectangular frames? overlays?

Thanks,
--h

[Doom9]

Strictly speaking Divx bitstreams are not true MPEG4. You have to "un-pack" them before they become compliant.That is no longer entirely correct.. I rember a thread where bond asked the DXN guys about packed bitstream.. it is no longer turned on for every profile.

There are two versions of Xvid. The original container agnostic non VFW binaries and the AVI crippled VFW binaries. You are misleading people with that statement. Tell me one XviD option that is not available in the VfW interface, one that the VfW interface and AVI output would effectively prevent from being used. To the best of my knowledge, there is none, and that also extends to MPEG-4 AVC codecs. Empty frames and packed bitstream does not have the least bit of influence on the features of a codec you can use. Plus, the VfW interface does in no way limit the output format.. VDubMod allows you to put any codec into either AVI, OGM or MKV container, for every codec using the VfW interface.

You could even write an intelligent "containerizer" that uses a VfW codec interface, but then removes the ordering limitations and puts a perfectly raw output without any container limitations into any container you might like.

[Elias]

Originally posted by Neo Neko
Strictly speaking Divx bitstreams are not true MPEG4. You have to "un-pack" them before they become compliant. Just slightly less work than it is to turn MSMPEG4 streams into compliant MPEG4 streams.

So if we disregard the packed bitstreams issue. Divx "is" MPEG4 compliant. In a very basic way. It just lacks alot of configuration and flexibility that is part of the MPEG4 spec.Okay so hang on a second guys, exactly what features do I need to check/uncheck in order to get a fully compliant MPEG-4 video file that I can safely import into *.mp4? And I don't mean by using Simple Profile 0 because I always use unrestricted. Packed Bitstreams is if I've understood it right, not good in *.mp4? B-Frames/GMC/QPel shouldn't harm the MPEG-4 compliance, but it might not always be the best thing to use for player compatibility... but it's still full MPEG-4 compliance though, right? Also, what about NVOPs? I have no idea why I'm getting them, do they harm the compliance? Why do NVOPs occur? By the way, Neo Neko, since we're at it: how do you turn MSMPEG4 into compliant MPEG-4 streams?

[SeeMoreDigital]

Sorry but I've got to ask you Elias....

What is your obsession regarding Mpeg4 compliance?

Are you worried that your encodes won't play in certain hardware devices or software players?


Cheers

[Elias]

Originally posted by SeeMoreDigital
Sorry but I've got to ask you Elias....

What is your obsession regarding Mpeg4 compliance?

Are you worried that your encodes won't play in certain hardware devices or software players?Hahaha. Yeah, something like that. I just want to make sure that once I've encoded something to MPEG-4, I'll never have to worry about doing it again. Like, I want to make everything right the first time.

[SeeMoreDigital]

Originally posted by Elias
Hahaha. Yeah, something like that. I just want to make sure that once I've encoded something to MPEG-4, I'll never have to worry about doing it again. Like, I want to make everything right the first time. Well I can't say I've come across this problem myself and I have 2No devices that can play Mpeg4 in .MP4 (soon to be 3No... hopefully)!

Okay I think most of us now know the problem with QuickTime player and mp4UI muxes, but GraphEdit/3ivx or MP4Box(GUI) muxes solve this!

I have around 50No "full movie" Mpeg4 encodes with AAC audio in .MP4. Some contain Nero subtitles and chapters, some contain one or more B-VOP, some of the B-VOP encodes even have packed bit-stream (ie: they are non compliant)... They still play in hardware ;)


Cheers

[Elias]

Well, it's not just about hardware compatibility. There are software players that just can't handle any mp4 file that somehow breaks the compliance. Not to mention other inferior hardware devices like cell phones etc. I just want to squeeze out the maximum compatibility of MPEG-4 :)

[Doom9]

Okay so hang on a second guys, exactly what features do I need to check/uncheck in order to get a fully compliant MPEG-4 video file that I can safely import into *.mp4?
Can we have a little more effort please? Bond has spend a great deal of time writing excellent stickies that list all the MPEG-4 options. He also has explained countless times about the problems of putting MPEG-4 video into AVI, and how to properly extract it from there. It does not only violate the rules not to read those posts, it is kinda rude towards bond who has spent a great deal of time teaching people how to do this.

do you know perhaps how to make MSMPEG4 ISO MPEG-4 compliant?There is a thread and a tool floating around this forum.. once again it's been done and documented so you need to read up.

[Elias]

Okay I'm sorry. I'm honestly not trying to offend anyone. Just trying to learn, that's all :) I'll check bond's FAQ again :) Does anyone have a link to that MSMPEG4 thread? I can't find it and I used search.

[SeeMoreDigital]

Originally posted by Elias
Well, it's not just about hardware compatibility. There are software players that just can't handle any mp4 file that somehow breaks the compliance. Not to mention other inferior hardware devices like cell phones etc. I just want to squeeze out the maximum compatibility of MPEG-4 :) Personally speaking, I know of only one software player that borks when playing Mpeg4/SP with AAC in .MP4... and that's QuickTime. But this is for the reason I posted above and can be easily over come.

I must admit, I don't know about cell phone compatibility issues though!


Cheers

[Yong]

Originally posted by SeeMoreDigital
Personally speaking, I know of only one software player that borks when playing Mpeg4/SP with AAC in .MP4... and that's QuickTime. But this is for the reason I posted above and can be easily over come.

IIRC Quicktime only play MP4 wrapped MPEG-2 AAC...

[SeeMoreDigital]

Originally posted by Yong
IIRC Quicktime only play MP4 wrapped MPEG-2 AAC... The QuickTime player problem I was refering to was caused when using mp4UI to generate muxes. And can only be seen if you don't have any of 3ivx's filters installed. And happens even with "video only" muxes!


Cheers

[Elias]

Originally posted by SeeMoreDigital
The QuickTime player problem I was refering to was caused when using mp4UI to generate muxes. And can only be seen if you don't have any of 3ivx's filters installed. And happens even with "video only" muxes!


Cheers I can't see mp4UI muxes in QT6 without 3ivx installed. However, in VLC they play perfect. I guess VLC is pwnage :D I also checked them in dumpster, and the mp4 files mp4UI generates are seriously b0rked. They don't even have any moov atoms!

[Yong]

Originally posted by SeeMoreDigital
The QuickTime player problem I was refering to was caused when using mp4UI to generate muxes. And can only be seen if you don't have any of 3ivx's filters installed. And happens even with "video only" muxes!


Cheers
mp4UI somrtime still a buggy apps :rolleyes:
I can remember i was successfully play a mp4 warpped XviD-SP and aac in quicktime :D
(mux with mp4creator)

EDIT:
OOOPS! sorry, i'm wrong, Quicktime only play MPEG4-AAC, same as iTunes... :p
(because FAAC default use MPEG2-AAC for output to aac or mp4, but can be overrided by --mpeg-vers 4 flag... i'm apologize in advance...):p

EDIT2: Actaully i don't like this "bloat" player,
after the installation finished, it will modifing the registry setting, and make itself as an default multimedia player...:rolleyes:
Use mplayer instead...:cool:

[Yong]

Originally posted by SeeMoreDigital
The QuickTime player problem I was refering to was caused when using mp4UI to generate muxes. And can only be seen if you don't have any of 3ivx's filters installed. And happens even with "video only" muxes!


Cheers
That's wierd, Quicktime player can't play my MP4(XviD-SP) without 3ivx,
it will cry for "3ivx.dll"...
Tested with latest version of Quicktime player...:D

[video]

Originally posted by Elias
Okay I'm sorry. I'm honestly not trying to offend anyone. Just trying to learn, that's all :) I'll check bond's FAQ again :) Does anyone have a link to that MSMPEG4 thread? I can't find it and I used search.
here it is (http://forum.doom9.org/showthread.php?s=&threadid=80430) what Doom9 was talked about.

[SeeMoreDigital]

Originally posted by video
here it is (http://forum.doom9.org/showthread.php?s=&threadid=80430) what Doom9 was talked about. Agreed... yet another very useful thread from our man bond :)

Perhaps it should be upgraded to a sticky?


Cheers

[bond]

Originally posted by Tommy Carrot
Probably because full MP4 support is impossible or at least very hard via the VFW interfacei dont get why this should be true?
vfw cant handle vfr, so yes encoding/decoding vfr mp4 would not be easily possible in vfw, but the rest...

you only have to look at how mkv is supported in vdm and mkv is not less powerful than mp4

all you would need is a smart mp4 muxer in vdm, which recognizes whether a stream is mpeg-4 or not and than place the stream correctly in mp4

of course this would be hard with encoders outputting packed bitstream as you would have to unpack this again "on thy fly", but well according to bill may from mpeg4ip and michael niedermayer from ffmpeg packed bitstreams are not mpeg-4 compliant, so people shouldnt also expect to be able to encode such streams to mp4 :D

anyways you only have to realise all the workarounds in vd already existing for making b-frames work in avi (eg drop delay frames)...

Originally posted by Doom9
That is no longer entirely correct.. I rember a thread where bond asked the DXN guys about packed bitstream.. it is no longer turned on for every profile.well afaik this isnt the case anymore (for some time divx5 didnt write packed bitstream for > 1 b-frames), as divx5 is said to now write packed bitstream again with any b-frame setting

Originally posted by Elias
[B]Okay so hang on a second guys, exactly what features do I need to check/uncheck in order to get a fully compliant MPEG-4 video file that I can safely import into *.mp4? And I don't mean by using Simple Profile 0 because I always use unrestricted. Packed Bitstreams is if I've understood it right, not good in *.mp4? the 3ivx and mp4box mp4 muxers can correctly import packed bitstream avi files to mp4

B-Frames/GMC/QPel shouldn't harm the MPEG-4 compliance, but it might not always be the best thing to use for player compatibility... but it's still full MPEG-4 compliance though, right?sure

By the way, Neo Neko, since we're at it: how do you turn MSMPEG4 into compliant MPEG-4 streams?while it can be discussed whether packed bitstreams are mpeg-4 compliant or not, there is no doubt that msmpeg4/divx3 is NOT mpeg-4 compliant
still there is a tool which losslessly converts these files to compliant mpeg-4 available here (http://forum.doom9.org/showthread.php?s=&threadid=85229)

IIRC Quicktime only play MP4 wrapped MPEG-2 AAC... wrong, quicktime will not handle aac signalled as "mpeg-2 aac" in mp4! it only handles mpeg-4 aac (of course mpeg-4 aac = mpeg-2 aac, but you can signal the two differently in mp4)
edit: ah already changed

quicktime by itself handles mpeg-4 simple profile video, if you install 3ivx, the 3ivx mpeg-4 decoder will be used in qt too

Agreed... yet another very useful thread from our man bondCan we have a little more effort please? Bond has spend a great deal of time writing excellent stickies that list all the MPEG-4 options. He also has explained countless times about the problems of putting MPEG-4 video into AVI, and how to properly extract it from there. It does not only violate the rules not to read those posts, it is kinda rude towards bond who has spent a great deal of time teaching people how to do this.thx, thx :)

Perhaps it should be upgraded to a sticky? nah, i prefer it to avoid lots of stickies, but instead have single ones for the main topics, from which we link to other important threads

eg if you want to convert from avi to mp4 and you have a question worrying about mpeg-4 compliance, before you post you read the mp4 faq, there you will find an own entry for avi->mp4 conversion telling you what muxers safely mux packed bitstream avis to mp4 and you will also find a link to the thread which explains the vfw/b-frames issues...
well so much the theory ;) posting is still easier than reading i suppose :D

[hhanh00]

We know how b-frames can be worked around with vfw. For variable framerate, the directshow interface isn't much better. It can tell you that the current frame is sufficienly similar to the previous one so that you can reuse it and adjust the time code. It's still the burden of the app to properly support this and besides a mention in a 3ivx forum, this hasn't been done to my knowledge.
Moreover, one can argue that this also possible in vfw. You just need to return a different kind of 'fake' frame to indicate this. You won't be able to put it in an avi container.

There are other features of mpeg-4 that seem also interesting but yet unsupported. I was thinking some anime has very static content. For example, for some of them, only the character mouths are moving during a scene. That's specially true for TV episodes. An encoder could take use this and encode a portion of the picture and overlay it on a lower frame rate background. However, even if there is advantages in this, I don't foresee anyone doing it in the close future. Don't you think?

In any case, does using vfw restrict mpeg-4 encoding in a practical way?' or stated differently, if I use vfw with the current mpeg-4 encoders, are there features that I can't have? So far, I don't think so.

Also with my experience of directshow, I don't think switching to directshow brings much to the table. There is so much work to do and not much to gain, isn't there?

Thanks,
--h

[bond]

well on the playback side dshow supports variable framerate perfectly already
at least dshow doesnt suffer the "one frame in, one frame out" limit of vfw, which makes it already more suitable for things like b-frames or arbitrary frame orders

apart from that, altough hardly anyone realises it, but most new commercial encoding apps are internally based on dshow: mainconcepts encoder, moonlight, nero... so it cant be that bad ;)

[hhanh00]

Yes, for encoding a full movie, dshow is pretty good. Once your graph is setup, you let the source go and everything flows down greatly. For an editing tool, it's not as great since you want to seek back and forth, decode a few frames there, etc. It can get gnarly to synchronize your filter threads. I'd say that the complexity involved exceeds the paybacks of using dshow.

Btw, I just saw your (old) post regarding variable framerate mpeg-4 with vfw. So it has already been done. :)

[bond]

Originally posted by hhanh00
[B]Yes, for encoding a full movie, dshow is pretty good. Once your graph is setup, you let the source go and everything flows down greatly. For an editing tool, it's not as great since you want to seek back and forth, decode a few frames there, etc. It can get gnarly to synchronize your filter threads. I'd say that the complexity involved exceeds the paybacks of using dshow. ic, still the worst thing i know is editing not packed b-frames in vfw :D

Btw, I just saw your (old) post regarding variable framerate mpeg-4 with vfw. So it has already been done.nope, its not variable framerate
it uses n-vops to signal duplicate frames, still the stream is a totally normal constant framerate one

[hhanh00]

Originally posted by bond
ic, still the worst thing i know is editing not packed b-frames in vfw :D
mmmm - Why can't the app call vfw until it gets the P frame if the decoder returns the 'delay-lag' frame?


nope, its not variable framerate
it uses n-vops to signal duplicate frames, still the stream is a totally normal constant framerate one [/B]

I was talking about this post: HowTo create Variable Framerate MPEG-4 video streams in MP4 (http://forum.doom9.org/showthread.php?s=&threadid=73633). That's variable frame rate once you put it inside a mp4 container, isn't it? Obviously, if you leave it in an avi, it's not. But that's not really a limitation of vfw. We are talking about work arounds in vfw here, don't get me wrong but what I'm trying to say is that directshow isn't much superior. And I'm wondering if there is anything interesting that vfw & directshow preclude you from doing.

--h

[stephanV]

Originally posted by bond
ic, still the worst thing i know is editing not packed b-frames in vfw :D


Editing a stream with predicted frames is silly by definition, this has nothing to do with VFW. You can never have accurate cutting points.

[video]

bond however it's not crystal clean for me what is the problem with packed bitstream, anyway. Packed bitstream is a container specific issue, and after the video and audio stream is demuxed by the splitter and the 'n' frame is removed, the video decoder is fed with pure mpeg4 (asp/avc) video stream. does it mean, that an mpeg4 video stream is not parseable without hinting?
however what if you have an alternative splitter for avi, like avifile library on linux and mplayer what is based on the push model and sync-ed with the computer's rtc. both dshow and m$ implementation of vfw syncs on audio. if you have a really terrible sound card, you may encounter permanent lip synchron issues...

[video]

Originally posted by stephanV
Editing a stream with predicted frames is silly by definition, this has nothing to do with VFW. You can never have accurate cutting points.

Yep, damn good right. Some may look at FredThompson's/jinder's pain (http://forum.doom9.org/showthread.php?s=&threadid=92656) with predicted frames+field repeats :)

[hhanh00]

Originally posted by stephanV
Editing a stream with predicted frames is silly by definition, this has nothing to do with VFW. You can never have accurate cutting points.

Why not?

[EDIT: Ok - by editing you mean direct stream cutting and joining.]