OpenDML Discussion (Formally AVI-Mux 1.16.8 and AC3)

[SeeMoreDigital]

As the contents of my original post seems to have moved over to discussing OpenDML, I have decided to amend the subject title...


For anybody who's still interested in my original post. This is how it all began....

Hi Alex,

I think I'm having one of my dumb days!

Anyway I'm trying to create some high-def 1280x720 "Test Cards" complete with 6Ch AC3 audio... However, after muxing, all I get is an encode with 5 channels (I presume the sub is missing)!

What am I doing wrong?


Cheers

[alexnoe]

I don't process any AC3 data, however, I'm writing 5ch into the headers if the frame headers say "5ch", which they do for 6ch files... But that should not affect playback

[SeeMoreDigital]

It would indeed appear that all AC3 channels are their.

Given this to be the case it might be more prudent to write "6Ch" into the headers. So that applications such as GSpot (and Nero's ShowTime player) can display the correct information....


Cheers Alex

[alexnoe]

Yeah, If I wanted to parse deeper into the AC3 frame headers.... GSpot is severely b0rked anyway, so it's easier not to use it.

I would change that behaviour if it caused replay problems, but I won't change it just because of GSpot.

[SeeMoreDigital]

Originally posted by alexnoe
Yeah, If I wanted to parse deeper into the AC3 frame headers.... GSpot is severely b0rked anyway, so it's easier not to use it.

I would change that behaviour if it caused replay problems, but I won't change it just because of GSpot. I think that's a little harsh Alex. Here's what two other apps say about it: -

http://img109.exs.cx/img109/1756/AVI-mux.gif

And here's what's displayed when using the VLC player: -

http://img113.exs.cx/img113/9040/VLC.gif

Cheers

[stephanV]

but thats normal... he writes 5ch in the header...

i think alexnoe is aiming at Gspots "capability" of recognizing opendml or standard AVI

[SeeMoreDigital]

Originally posted by stephanV
but thats normal... he writes 5ch in the header...

i think alexnoe is aiming at Gspots "capability" of recognizing opendml or standard AVI Ugh?

If AC3 streams that are recognised as being 6 channels go in AVI-mux... then that's what should be reported when they come out. Whether they be OpenDML v1 or v2... or without DML

...and like I've already pointed out... it's not just GSpot that's reporting "5 channels"


Cheers

[stephanV]

no of course not... he writes 5ch, so why would you expect anything else to be recognised?

whether it is correct to write 5ch when there are 6 i dont know... it doesnt seem to break anything...

as for GSpot... perhaps someone should file a bug report, because it reports standard avis created by VirtualDub as openDML.

[alexnoe]

And it appearently also misdetects file duration for my files with small RIFF AVI list. At least some guy once sent me a bug report about this. He thought it was my bug :p

It's really just a header value.

[SeeMoreDigital]

Well the issue I reported has nothing to do with GSpot....

I realise it's not the most important thing in the world but never the less, people (like me) might think they've made a mistake during muxing, so can it be fixed please Alex?


Many thanks

[ChristianHJW]

Personally i do believe

6 channel ( 5.1 )

would be perfect ...

Christian

[alexnoe]

Now if you posting made any kind of sense...

[SeeMoreDigital]

Originally posted by alexnoe
Now if you posting made any kind of sense... Who's posting?

[stegre]

Allow me to straighten out some confusion about "OpenDML" here.

VDubMod creates OpenDML files by default, and GSpot reports them as "OpenDML (AVI 2.0)". They aren't the same kind of OpenDML files produced by AVIMuxGUI, but more on that in a sec. In the "save as" dialog, VD has an option "save AVI in old 1.0 (VfW 1.1e) format (compatibility mode)". If you select this, it produces non-openDML and GSpot reports it that way, as "AVI v1.0".

The OpenDML spec, amongst other things, describes an extension to get past the 1GB limit (the limit is sometimes stated as 2GB or even 4GB, but that's beside the point). They set it up for maximum compatibility by having the additional data reside in a new chunk which followed the first one, the idea being that older AVI apps wouldn't even "see" the extra chunk but would at least be able to play the first gigabyte or so.

I've noticed some people use the word "OpenDML" strictly for the files produced by recent versions of AVIMux GUI. These might be better referred to as "maximally incompatible OpenDML files". These files may or may not comply with the letter of the ODML spec, and they certainly don't comply with the spirit. And there's a reason that they are so incompatible: Alex did it on purpose, to force them to be incompatible with XP Windows Explorer so wouldn't keep reading them, as a workaround for an annoying Microsoft bug.

Apps like VDubMod won't even create a second AVI RIFF chunk ("AVIX") unless the file is so large that it's required, as the OpenDML people expected. By contrast, AVIMux starts the second chunk almost immediately - after 1MB, when the first chunk is less than one tenth of one percent full. So any app that can't read multiple chunks is out of luck – which is the the idea - to mess up windows explorer. If you want AVIMux to produce "normal" OpenDML files, go into the AVI file structure output options and select "use Open-DML" and "create legacy index", but put "2044" in the box instead of the default, which is "1".

All of which is really beside the point - getting back to GSpot: not only does it identify OpenDML accurately, it also differentiates the AVIMux style ones from the VDubMod style ones by reporting former as "Multi-Part OpenDML AVI", as well as providing a breakdown of what's in each chunk.

==> See screenshots (http://www.headbands.com/gspot/odml/)

Oh, and really getting back to the point: SMD - I'll look into that 5.1 issue.

[alexnoe]

@stegre: All nonsense. You obviously have no idea what you are talking about. If you had read the opendml specs, you would perfectly know that no minimum size for RIFF lists is defined. If you find any point in those specs that avi-mux gui violates, then send a bug report. If you just want to troll around, then don't do it.

Only the heir of the realm of idiots can read "each RIFF chunk can have a maximum size of 1 GB" as "each RIFF chunk must have a size of 1 GB" and then insist on being right.

It says that files can be extended beyond 1 GB using RIFF AVIX list. Everyone who knows at least a tiny little bit of logics immediately knows that this describes *one possible way* to extend AVI files beyond one GB. It does not, not the tiniest little bit, say
a) that this is the only way to extend AVI files beyond 1 GB (thought OpenDML does not describe any other, but the phrase quoted above does NOT contain that information)
b) that this method cannot be used with smaller files
I'm making use of b) to work around an M$ WXP bug.

the limit is sometimes stated as 2GB or even 4GB, but that's beside the pointThe limit is 1 GB if you want to use MCI, but MCI is broken. The limit for AVI 1.0 files is 2 GB. Not 1 GB, not 4 GB.
as the OpenDML people expected.I don't care about what they expect or dream; i care about what they wrote down in a file called "OpenDML 1.02 Specification" (the one you tried to quote from)
All of which is really beside the point - getting back to GSpot: not only does it identify OpenDML accuratelyAn open-dml file has to have indx chunks, which are not present in files smaller than 2 GB written by VDub. Thus, identifying them as OpenDML is wrong. It's just that simple.
If you want AVIMux to produce "normal" OpenDML files, go into the AVI file structure output options and select "use Open-DML" and "create legacy index", but put "2044" in the box instead of the default, which is "1".You mean files that even GSpot can handle, even if it causes a shitload of overhead? HAHA

In the opposite, i should add a "you are using an idiotic setting" warning if people do that!

What you suggest is:
- increase files size by writing the index for the first 2 GB twice, even though a reader not capable of reading opendml won't see anything after those 2 GB, meaning that a reader capable of reading opendml is necessary anyway, and even though a reader capable of reading opendml can handle files with only an indx/ix## index, but without idx1 chunk and with a small first RIFF list

- you even suggest that broken files be written! (READ THE SPECS! The first AVI RIFF List for OpenDML files is 1 GIGABYTE. It is NOT 2 GIGABYTES.

[stephanV]

Stegre: I meant no offense...

but if you dont believe me or Alexnoe then at least believe Avery Lee (http://virtualdub.everwicked.com/index.php?act=ST&f=6&t=8160&st=0&#entry32733)
VirtualDub writes out AVI headers so that if the file is smaller than 2GB by the time it is finished, the OpenDML indices are omitted and the result is a standard AVI file.

[alexnoe]

Wow. That's even better than "learn reading specifications"... :D

[SeeMoreDigital]

This is exactly what I DID NOT WANT to happen in this thread....

I really don't like to see anybody falling out (especially in my threads) And I think I speak for many forum members when I say both AVI-mux and GSpot are excellent and extremely necessary products.

Alex, do you have a "happy place" you can visit? As you have a tendency to "come on" a bit strong at times. Which could upset some less seasoned members...

Okay then... It would seem there are some Q & A's that need resolving over OpenDML. And how some applications deal with it. I for one, would like to learn more about it but only if the information is based on fact and not so much on interpretation!

In an effort to get input from other forum members about OpenDML, I'm willing to change the title of this thread... if that's okay with you guys?


Cheers

[alexnoe]

Alex, do you have a "happy place" you can visit? As you have a tendency to "come on" a bit strong at times. Which could upset some less seasoned members...Yeah, I'm coming on a bit strong if people are flying higher than they should
I for one, would like to learn more about it but only if the information is based on fact and not so much on interpretation!Specifications usually don't leave much room for being "interpreted". here is the opendml-spec (http://www.matrox.com/video/press/papers/odmlff2.pdf), so you can look at it in your own.
I really don't like to see anybody falling out (especially in my threads) Then don't ask such questions. Some <place some bad word here> (and always the same) is doing that whenever someone mentions "OGM" in an AVI or MKV thread. On cdfreaks, you could achieve the same result by saying "that plextor drive might have a problem" some time ago (though the administrator-plextor-zealot there seems to have settled down), and the dvd+trolls appearently have left doom9, but before they did, it was impossible to talk about dvd- vs dvd+ ... some questions just won't result in a discussion.

And whenever I see the necessity to get someone back to our world, I'll do it. Far too many people have sent problem reports that should have gone to GSpot, and I have told all of them to do that, but either none of them did, or someone is intentionally refusing to fix that in GSpot.

[SeeMoreDigital]

Originally posted by alexnoe
.. Far too many people have sent problem reports that should have gone to GSpot, and I have told all of them to do that, but either none of them did, or someone is intentionally refusing to fix that in GSpot. So why not try and work together to sort these problems out... And if you can, please involve Moitah.

The AVI container needs "all" your tools!


So with response to my opening question.

It seems your product is indicating Dolby Digital 5.1 as having 5 channels instead of 6. Can you confirm whether you will be keeping it like this. And if so, why?


Cheers

[alexnoe]

At the moment, I don't plan to change this.

Reason: Finding out if there are 5 or 6 channels in a AC3 3/2 file requires a deeper look into the AC3 data. If anyone ever finds a player (hardware or software) which malfunctions due to this, then i'll change that.

Excerpt from the source code:

DWORD dwChannelIDs[8] = { 2, 1, 2, 3, 3, 4, 4, 5 };

dwChannelIndex=si->AC3mod >> 5;
if (dwFreqIndex==3) { GetSource()->Seek(qwOldPos); return 0; }
if (dwBitrateIndex>=38) { GetSource()->Seek(qwOldPos); return 0; }

dwBitrate=dwBitrates[dwBitrateIndex];
dwFrameSize=2*dwFrameSizes[dwFreqIndex][dwBitrateIndex];
dwChannels=dwChannelIDs[dwChannelIndex];

As you can see, I'm using exactly what the AC3 frame header is saying.

[SeeMoreDigital]

Maybe there's no need to mention the sub (the 6th) channel in the code because it's "known" to be there and calculated by extraction and not by indication.

As a matter of interest, is the code for Dolby Digital ES streams the same... I presume it would be, as the centre rear channel information is calculated from the left and right rear channels.

I guess the code is quite a bit different for DTS and DTS ES streams?


Cheers

[stegre]

Originally posted by stephanV
Stegre: I meant no offense...
but if you dont believe me or Alexnoe then at least believe Avery Lee (http://virtualdub.everwicked.com/index.php?act=ST&f=6&t=8160&st=0&#entry32733)
None taken.

It's true that the index is omitted. But, as you can see here (http://www.headbands.com/gspot/odml/vdub13c.png), it leaves in an "AVI2 extended header block", as defined in the OpenDML spec. In fact, the actual designation for that block is "odml". Since the spec is a collection of optional items, having any one or more of the items would qualify the file as being the newer type. But I'll look into adding some further clarification, similar to what I do now with the ODML "additional RIFF" feature: I explicitly say "Multi-part OpenDML". I could add "without ODML index" or "ODML, header only" or something.

Back to AC3, I think this table from the AC3-spec (http://www.headbands.com/gspot/odml/ac3.png) is the source of the confusion. As you can see here, there's no code for anything higher than five channels. But, as you can also see in the note below it, there is an "LFE channel" that's handled separately since it's not one of the "full-bandwidth" channels. Its existence is specified by some other bit, elsewhere in the data stream.

GSpot already does parse the actual AC3, though - it doesn't get its AC3 info from the AVI container. I just now modified it to read that LFE bit and display "5.1ch" when its present, "5ch" when it's not. The update will be in the next release.

[alexnoe]

Since the spec is a collection of optional items, having any one or more of the items would qualify the file as being the newer type.INDX is mandatory for OpenDML, so without INDX, it is no Open-DML...

[stegre]

No it isn't. But "vprp" is.

So AVIMuxGUI is non-compliant.

http://www.headbands.com/gspot/odml/vprp.png

[alexnoe]

I hope you've sent that to Avery Lee, because last time i looked VDub didn't write vprp either ;) So GSpot should either ignore this detail, or should not report any file written by VDub or amg to be open-dml. Currently, it is doing some weird stuff inbetween. Also, you totally forgot the film transfer log...

Technically, it indeed seems that the indx itself is not mandatory, but fortunately avi-mux gui as well as VDub are setting the HAS_INDEX flag to 1, meaning that there is an index (not half an index, like an index only over the first GB, but an index), and the only way to have an index if there are more RIFF lists than just one is to have an indx :-)

Now if a file has only one RIFF list, has HAS_INDEX set, but no idx1, then it must have an indx and is opendml. If it has idx1 and indx, then I call it "hybride" because it doesn't matter, from a player's point of view, what it is seeing it as. If it has HAS_INDEX set, has an extended AVI header, but has no indx, then it must have an idx1 and can thus be read by an AVI 1.0 parser (the extended AVI header does not contain any information not found in the main avi header in this case and can be ignored). So the question is: Do you really want to call a file that can perfectly be read by an AVI 1.0 parser, a file that can be "cut down" to an AVI 1.0 file without losing any information, an "Open-DML file"? I'm just realizing how lousy those specs are :angry:

[Sharktooth]

What about agreeing on something (being as most spec compliant as possible) and leave the rest to the ppl who wrote the "lousy" specs?:D

[yaz]

Originally posted by Sharktooth
What about agreeing on something (being as most spec compliant as possible) and leave the rest to the ppl who wrote the "lousy" specs?:D yep ... a good point :-)
... and what about making amg able to change 4cc and AR in avi, and "unpacking the bitstream" ?
... and what about making gspot able to read all this correctly ?

... just sitting and humming ... never mind :-)

the bests
y

[SeeMoreDigital]

Hi guys,

I was about to start a new thread about this subject but thought... What the hey!

Anyway, what I would like to know is. Is it possible to create OpenDML v2.0 .AVI files greater than 2GB, say up-to 4GB without them becomming Multipart OpenDML .AVI files?


Cheers

[Inventive Software]

I thought that was the point of OpenDML in the first place....

[SeeMoreDigital]

I thought that was the point of OpenDML in the first place....So did I.

However, I don't seem to be able to generate such muxes!

[Inventive Software]

Hmm... explicitly enabling it in VirtualDub might work......

Where's Haali when ya need him?! ;)

[stegre]

I should first mention a "Multi-Part" OpenDML is still just a single file, unlike the old "proprietary" VirtualDub hack that extended the maximum AVI size by "linking" together several files. So it's not really any inconvenience; indeed most people would not know or care if an OpenDML AVI file is "MultiPart". It's really just an internal technicality.

But if you're curious for "academic" or other reasons, the actual answer is really neither 4GB nor 2GB; it's 1GB.

The general max AVI size question has been a source of confusion for some 17 years or so (or even 23 years, if you go back to what the format is based on). Here's the whole history, as I understand it:

"Regular" (non-OpenDML) - "AVI 1.0"

1985 EA (Electronic Arts - the same gaming company doing very well today) devised the IFF ("Interchange File Format") the precursor to RIFF ("Resource Interchange File Format"). AVI is one type of RIFF; there are also other non-AVI "RIFF" files, most notably standard .wav files. Note that while AVI is officially a type of RIFF file, though there's no official connection between the RIFF and the earlier IFF). In any event, according to Wikipedia, IFF used a 32-bit unsigned length field, implying a max size of 4GB (and this was in 1985!). As you'll see below, size progress proceeded "backwards" over the next few years...

1991: Microsoft and IBM create the RIFF and AVI 1.0 spec, which also states the length is expressed as a 32-bit unsigned quantity, i.e. 4GB max. Around the same time, Microsoft creates the "MCIAVI" interface to access these files, but for some reason the functions use a signed 32-bit value - a value in the range from -2GB to +2GB. Since the functions you can't access more than 2GB forwards into a RIFF chunk, they effectively limited AVI file access to 2GB, even though Microsoft had just co-written the spec for a file format allowing for 4GB.

OpenDML - "AVI 2.0"

1996: The "OpenDML AVI M-JPEG File Format Subcommittee", some consortium having something to do with the Matrox video card people, write the OpenDML spec. They claim that AVI needs overhaul (and cover a number of subjects), but on the length issue they claim that the previous AVI limit was, in practice, only 1GB. They attribute this to the MCIAVI issue as I mentioned above, though I don't know where they get "1GB" as opposed to two.

Nonetheless, they claim there's no reason why an unlimited number of segments cannot be effectively appended, provided each is 1GB or less. So there's you're answer for open DML, they do explicitly claim the segments should not exceed 1GB. But the overall file can be as large as required.

2006: Apparently fed up with the confusion and the lack of any updates concerning newer issues, outspoken AVI guru and AVIMuxGUI author Alexander Noe wrote his own AVI spec, simply entitled "AVI File Format". The spec has no official "backing", but is well written and generally succeeds in its attempt to specify a set of guidelines to use, based on how AVI files have "developed" in the 10 years that elapsed since last "official" document was published in 1996. Alex is not completely exempt from causing confusion himself (a page on his website strongly points out that the AVI 1.0 specification contained a "32-bit signed value" for length, which, as I mentioned above, is a common misconception, and a mention that the OpenDML chunks could be 2GB each, whereas they are actually limited to 1GB. The PDF document, which I assume is more recent, does appear to correct these errors, however).

So could there be a single part 4GB OpenDML file? It would technically violate the OpenDML spec - but creating one would be relatively easy. It would be interesting to see how the various modern splitters, players and editors handle it; perhaps I'll try it sometime. I bet most would handle it OK, but I assume some would fail. But since there's no real overriding reason to do so, keeping the AVI OpenDML "parts" at or under the 1MB spec value seems to be the most prudent approach.


http://www.ftyps.com/unrelated/aviref1.png

http://www.ftyps.com/unrelated/aviref2.png

refs: to be added

[SeeMoreDigital]

Hi Steve,

Many, many thanks for your extremely clear, concise and informative post about the subject of DML :). It must have taken you quite some time to compile and simplify all the information.

My personal interest in the creation of OpenDML v2.0 MPEG-4.AVI files greater than 2GB is their compatibility with network/USB2/memory card capable hardware playback devices.

It would seem some devices have difficulty accurately navigating thru' Multipart OpenDML MPEG-4 .AVI files greater than 2GB. Indeed, in some cases it becomes virtually impossible to navigate thru' the second part of the file.

Now... I guess it's no secret. I'm actually not a big fan of the .AVI container (I prefer placing MPEG-4 video within the .MP4 container). That said, I feel motivated to carry out some "hardware" compatibility tests.

In preparation, I'm going to generate the following test files: -
3GB MPEG-4 SP file.
3GB MPEG-4 ASP file.


I'll report back how I get on!

[Jor-El]

SeeMore:

Please read my last post:

http://forum.doom9.org/showthread.php?p=1060050#post1060050

Maybe it can help.
In short:

Virtualdub "Old Format AVI" can make 4Gb Avi 1.0 with one segment and index.
divxmux can read this AVI for muxing audio an subtitles.

[LeXXuz]

In preparation, I'm going to generate the following test files: -
3GB MPEG-4 SP file.
3GB MPEG-4 ASP file.


I'll report back how I get on!

Yes please keep us updated. I'm very eager about your results.

It seems that hardware players indeed have lots of trouble with openDML... :(


My hardware player (TViX with Sigma 8621) seems to play Avi 1.0 Files up to 4GB fine.

Multipart OpenDML files created by AviMux do not work. It seems Avimux creates multipart files with a very small first part (in relation to the following parts). I guess thats why my player has lots of problems with navigating in these files.

OpenDML files with Vdub have parts quite equal in size (with up to 2GB each as a maximum). It is possible to navigate in these files but with delays up to a couple of seconds.

For example a 3GB Avi 2.0 file: I start the playback and enter a jump mark of about 1:00:00 (which is about half the length of the movie). The player needs about 10 to 15 seconds to find this mark.
Same file as Avi 1.0 takes the player about a splitsecond to reach this mark.
With the settings from AviMux (small first part...) the player crashes.

My 2nd player (Philips 5160 with Mediatek chipset) dislikes openDML as well. Navigation is ok, but when the first part of multipart file ends, the player stops playback for no reason.

Interleave and preload values dont seem to have any significant influence to all this.

I would really like to read mor indepth detail about the indexing-differences between opendml and avi1.0.
Whats the use of it? Why need avi 1.0 files to be indexed first by the players while openDML files playback immediately? Do different muxers create different types of indices? Maybe this is where to look for reasons of the playback issues?

[stegre]

...
Multipart OpenDML files created by AviMux do not work. It seems Avimux creates multipart files with a very small first part (in relation to the following parts). I guess thats why my player has lots of problems with navigating in these files.
...

Yes, that's exactly true, and I said it was a bad idea 3 1/2 years ago in a post this very thread (http://forum.doom9.org/showthread.php?p=567179#post567179) (around the next to last paragraph) - along with a work around you might try that avoids it (at least it worked in the versions of AviMuxGui that I was playing with back then).

I don't have the inclination to go back and get worked up by reading the details of the old part of this thread, but you may want to read the aforementioned post.

I disagreed with some of what AviMuxGui author / now banned Doom9 member "alexnoe" did, such as effectively changing "default" AVI format solely to counteract a Windows Explorer bug, which seemed like the "cart pulling the horse". And now we have a case in point: that exact issue that I disagreed with him about 3 1/2 years ago is exactly the cause of the some of the problems you're experiencing now.

Lively debate is great, it wasn't so much the disagreement that makes me disinclined to read the old posts, but it was impossible to have a rational discussion with the guy. In general he was/is a good programmer, but he was not exactly what you'd call "personable. And when his "good programmer / bad personality" dichotomy clashed, apparently the personality won out - see actual AviMuxGui dialog screenshot below for your amusement!

http://ftyps.com/unrelated/stupid.png

[LeXXuz]

http://ftyps.com/unrelated/stupid.png

What a nice attitude... :rolleyes:

Well I haven't read the older messages from 2004 in this thread, only the new one from this year that revived it. I will catch up with that when I have the time.

BTW. How do I scan OpenDML files with Gspot to see the overall frame structure?

[stegre]

It should show a verbal description something like you see below, circled in red - that's a text description of the basic layout. That part of GSpot isn't extensively tested, as 2+ GB AVI files weren't as common as they are when I last worked on that section. I'm working on a GSpot update now and I'm going to do some accuracy checks & maybe even enhance that part of the app. As you can see, VirtualDub made that AVI file, and it seems to be a perfectly fine. I believe the info GSpot's showing about it is totally accurate as well. That was the only 2+ GB file I had lying around to test for this post - as you can see it's totally uncompressed video which is why it's so large for such a short video. But I'll be testing large files more routinely in as I update Gspot.

http://ftyps.com/unrelated/2gb.png

[LeXXuz]

Well what I meant was the analize part on the right like in the picture below:
http://img227.imageshack.us/img227/6691/gspot1hs2.th.png (http://img227.imageshack.us/my.php?image=gspot1hs2.png)
It works fine even for AVI-files >2GB but only the old format ones.


On openDML files no scan is applied and the right part stays blank:
http://img156.imageshack.us/img156/364/gspot2vn8.th.png (http://img156.imageshack.us/my.php?image=gspot2vn8.png)

[stegre]

Thanks for pointing that out, that's an apparent bug or, at best, an "omission" in GSpot, and I shall look at correcting it. I do know the basis behind it:

The basic container information is available from the AVI header only (or at worst may require a few quick 2GB random access jumps). Very early versions of GSpot got all their info from such container header analysis -- and much of the info currently in the "container" box is still derived that same way.

But it wasn't long after GSpot began gaining popularity that I realized I had to take the plunge and demux the streams out of the container in order to get a deeper analysis of them - current versions of GSpot now performs varying degrees of video or audio analysis on a the subset of media containers it can demux at all (all of which I plan to add to).

We're talking quite a few years ago, but coincidentally the first time I realized I'd better start demuxing was when the first stand-alone DivX players came to market. At that time, I started receiving lots of emails - seems everyone wanted to know if their DivX files used "GMC" and or "QPEL" - items which made the files unplayable (at least on the portable players of the day). Since there's no way that info is available from the AVI header, I took the plunge & started demuxing the video stream, even if just a few frames. At first I did that just to add GMC and QPEL "lights" as mentioned above, but demuxing also opened up the door to whole new level of analysis; a world of audio and video parameters were now potentially available for analysis - and pool of information so vast I've only very scratched the surface of tapping it so far.

But back to the point: I think the original header processing may have (and still does) support all variations of AVI, but when the "new" (at the time) demux code was added, I wrote it from scratch. I may not have had the time to properly demux all variations, so I just concentrated on the "popular" ones. And there haven't been a many updates on that demux code section lately.

What you're probably seeing now is a situation where my demux code isn't up to the task of demuxing the particulars of that style multi-part file, so it skips it - and hence much of the video section remains blank. The fields that aren't blank are the ones that are available from the AVI header - framerate, frame size, codec 4cc, etc.

So thanks for pointing that out, I shall look into updating that that AVI demux code, but for unfortunately there's no real workaround at the moment.

[SeeMoreDigital]

So thanks for pointing that out, I shall look into updating that that AVI demux code, but for unfortunately there's no real workaround at the moment.Personally speaking, I don't remember ever seeing a "MultiPart" OpenDML .AVI file that has been unable to display VOP information. I wonder which muxer was used?


Cheers

[LeXXuz]

So thanks for pointing that out, I shall look into updating that that AVI demux code, but for unfortunately there's no real workaround at the moment.

Thanks stegre for that detailed information. :) I'll keep my eyes open, maybe there will be a newer Gspot version sometime^^ ;)

I wonder which muxer was used?



The one on the second screenshot is simply a packetized output from encraw.

[stegre]

After reading SMD's post and taking a closer look at your screenshots, I realized my previous theory must be wrong, because it couldn't, for example, display "BVOP" unless it was demuxing it at least some of it. So maybe it's another bug - which brings up SMD's other question:

How did you mux it? It's clearly an AVI file - xvid_encraw can't output a AVI file by itself, can it?

[LeXXuz]

How did you mux it? It's clearly an AVI file - xvid_encraw can't output a AVI file by itself, can it?

Well it can. At least to my knowledge.

But if I remember correctly I get the same result with some vdub muxed files. I'll do some further testing and post some screenshots if you like.

EDIT: Nevermind. Just take a look into this thread (http://forum.doom9.org/showpost.php?p=1110248&postcount=12). There you'll find some screenshots of big avi files made with vdub & co. The first two screenshots are made from the same file saved as Avi1.0 in vdub and secondly as openDML avi in vdub.

[stegre]

OK. But meanwhile my xvid_encraw can only put out individual frames or elementary MPEG. Maybe it's an older binary. or there's a command line option I'm missing or is undocumented...
http://www.ftyps.com/unrelated/encraw.png

[LeXXuz]

OK. But meanwhile my xvid_encraw can only put out individual frames or elementary MPEG. Maybe it's an older binary. or there's a command line option I'm missing or is undocumented...


You may have a different build. I use Celtic Druids' build which has this function, see below:

http://img138.imageshack.us/img138/6338/xvidencrawvq2.png

My bad. I thought encraw has this option in general. ;)