AC3 in Matroska with VirtualDubMod

[adoniscik]

Do the old preload and interleave guidelines for AC3 in AVI with Nandub still apply for AC3 in Matroska with VirtualDubMod 1.5.10.1, or can I use the default values?

P.S. If every AC3 bit rate has a recommended interleaving setting, why does VirtualDubMod's AC3 importer not set it automatically?

[malkion]

after using avi mux gui once, on an older version, and switching the
defaults over to vdub, i've never had a problem. then again, i dont think these are recommended settings, however, for my pc, it plays smoother than the recommended settings (if there are such a thing).

preload 500ms
interleave every 250ms

for all bitrates... pls enlighten, if there are better settings. thanks

[ChristianHJW]

... matroska is based on timestamps and doesnt know any interleaving, so the settings have no meaning when MKV is used as container ....

[alexnoe]

How much do you want to risk on that I can create a matroska file which is interleaved so crappily that it doesn't play properly, even though it meets the specs?

[Atamido]

I know, we really need to add something to the specs specifying a requirement for data to always be interleaved by progressive timestamp.

[alexnoe]

That would make many older AVI-Mux GUI created files invalid, which are not muxed that way: Older versions created files with about 100ms video blocks (or 120ms for 25 fps) and then added the audio, like

video: 0
video: 40
video: 80
video: 120
audio: 0
audio: 32
audio: 64
audio: 96
audio: 128
...
...

The order of audio and video might be vice versa.

Also, you would kill the idea of 'native mpeg4' ;)

[Mosu]

Originally posted by alexnoe
Also, you would kill the idea of 'native mpeg4' ;)

Well, this is what my take on this topic was: http://lists.matroska.org/pipermail/matroska-devel/2003-October/002457.html Yes, this would mean that your older files would not be spec compliant, but I wouldn't worry about that as players are obviously able to handle those. I'm sure that at some point or other mkvmerge has written invalid files as well ;)

[alexnoe]

Yeah, like all files (written with a b0rked version of libebml) containing void elements that were supposed to be 127 bytes :devil:

[ChristianHJW]

Originally posted by Mosu Yes, this would mean that your older files would not be spec compliant, but I wouldn't worry about that as players are obviously able to handle those. I'm sure that at some point or other mkvmerge has written invalid files as well ;) ... i definitely prefer this to what some MP4 users have encountered recently, where nero decoder couldnt handle files created with 3ivX encoder, and vice versa, while both encoders had definitely been creating MP4 spec compliant files :D ;) ....

[alexnoe]

The p'taghs at ahead have even written invalid ISO file systems in one version, so I'd go for blaming them (and only them....)

[bond]

Originally posted by ChristianHJW
i definitely prefer this to what some MP4 users have encountered recently, where nero decoder couldnt handle files created with 3ivX encoder, and vice versa, while both encoders had definitely been creating MP4 spec compliant fileschris, you do know that the nero and 3ivx developers are around on doom9 very often, dont you?

so for whom do you think this post will be usefull?

if you want to make a usable bug report it would be nice if you could give the guys little bit more details on the problem, or at least link to where you read about "mp4 users" having problems...

Originally posted by alexnoe
The p'taghs at ahead have even written invalid ISO file systems in one version, so I'd go for blaming them (and only them....) just for completness this problem occured with one of the first nero versions writing mp4 files and has been fixed already...

[alexnoe]

so for whom do you think this post will be usefull?For users who consider to use mp4?

[bond]

Originally posted by alexnoe
For users who consider to use mp4? well, i can say i tested all mp4 implementations very often and i never stumbled over a problem to play 3ivx produced files with the nero filter
so without more details this statements isnt usefull :(

[Atamido]

Originally posted by alexnoe
Also, you would kill the idea of 'native mpeg4' I was thinking about writing the rule where frames for a stream are handled in the order given to them. So, you always have a buffer of one Block for each stream. The Block with the lowest timecode gets written first, streams are rebuffered, and the process repeats. I could see this as a problem though if you had 10 B frames before an I frame as all of the B frames would be handed back after the I frame and there would be a cluster of audio Blocks, and then a cluster of video Blocks. Would that make a pause in playback?

@bond: Please don't continue with your MP4 hijacking of the Matroska thread or I will be forced to strike you. ;)

[bond]

Originally posted by Pamel
@bond: Please don't continue with your MP4 hijacking of the Matroska thread or I will be forced to strike you.well, if than you have to blame chris for hijacking a matroska thread with a mp4 issue, which is in no way related to this matroska thread ;)

[SeeMoreDigital]

Originally posted by bond
well, if than you have to blame Chris for hijacking a Matroska thread with a mp4 issue, which is in no way related to this Matroska thread ;) And not accurate either :D

Cheers

[ChristianHJW]

Originally posted by bond
[B]chris, you do know that the nero and 3ivx developers are around on doom9 very often, dont you?
so for whom do you think this post will be usefull?

:eek: ... the problem was fixed lightyears ago already ! All i wanted to say, i rather prefer very strict and straightforward specs like the matroska ones, so that files even play fine with current demuxers if they are not 100% spec compliant, instead of very loose specs giving developers so much room for interpretation that files wont play on different demuxers, even if they ARE spec compliant ..... no offense towards MP4 devs, not at all .....

[bond]

Originally posted by ChristianHJW
the problem was fixed lightyears ago already !
well dont shock me (and others) with bugs, which arent there ;)

All i wanted to say, i rather prefer very strict and straightforward specs like the matroska ones, so that files even play fine with current demuxers if they are not 100% spec compliant, instead of very loose specs giving developers so much room for interpretation that files wont play on different demuxers, even if they ARE spec compliant ..... no offense towards MP4 devs, not at all .....well you are talking in riddles again...
what exactly in the mp4 specs gives so much room that different demuxers could have problems parsing different files, although they should be able to do?

[alexnoe]

I'll tell you if there are any as soon as you get me that file format docu :devil:

[SeeMoreDigital]

Hi Alex,

Is there anything (links etc) on these web pages that might help you?

http://www-courses.cs.uiuc.edu/~cs318/archive/fall2000/mp/mp4/

http://www.acm.org/sigs/sigmm/MM97/papers/eleft/eleft.html#refs

Cheers

[shitowax]

I just want to let you know that the MP4 file format spec is useless without the ISO file format spec, the MPEG-4 Video spec and the MPEG-4 audio spec ... (add the MPEG-4 System one if you want to support bond's subtitles)...

That may also explain why creating 100% valid mp4 files is fairly complex ... ;)

[SeeMoreDigital]

Originally posted by shitowax
I just want to let you know that the MP4 file format spec is useless without the ISO file format spec, the MPEG-4 Video spec and the MPEG-4 audio spec ... (add the MPEG-4 System one if you want to support bond's subtitles)...

That may also explain why creating 100% valid mp4 files is fairly complex ... ;) Would it be too much to ask if you guys can supply Alex with the documentation he needs?

Cheers

[Stux]

Originally posted by shitowax
I just want to let you know that the MP4 file format spec is useless without the ISO file format spec, the MPEG-4 Video spec and the MPEG-4 audio spec ... (add the MPEG-4 System one if you want to support bond's subtitles)...

That may also explain why creating 100% valid mp4 files is fairly complex ... ;)

Also, I believe the bug being referred to is the first versions of Ahead's AAC.mp4 files with "gapless coding" couldn't be played by an ancient version of the 3ivx Splitter. (4.0.3?)

This bug is because the initial version of Ahead gapless coding was not spec compliant. Anywho, we added support for it anyway, as did Apple in iTunes.

[robUx4]

*shock*
you add support for other people's bug in your softwares ? Doh ! What a nice future you're preparing to this format...

[alexnoe]

Would it be too much to ask if you guys can supply Alex with the documentation he needs?And please, don't tell me to go to www.iso.ch and buy stuff for CHF 67...

[shitowax]

We just avoided a crash on their funky (and non compliant) zero duration frames. Nothing to be *shock*ed ... and anyway, they don't use them anymore ... Thanks to be interested in the future of our favorite container =)

Originally posted by robUx4
*shock*
you add support for other people's bug in your softwares ? Doh ! What a nice future you're preparing to this format...

[ChristianHJW]

Originally posted by shitowax Nothing to be *shock*ed ... and anyway, they don't use them anymore ... Thanks to be interested in the future of our favorite container =)

LOL .... dont worry shitowax, robux4 is known for being the hardliner voting for 'clean' things always, even if this means that certain functionalities wont work at all or require much more work to get implemented.

A good example is the ongoing discussion about how to best put DV into MKV. While most of us vote to separate the audio from the video when muxing into matroska, to make editing in existing tools like VirtualdubMod easier, he is voting for a 'clean' way to mux DV into MKV as is, even if this means coding a complete new editor to be able to edit the files ( being the main reason why to make DV-in-MKV available at all ) ...... thats robux4, he doesnt like to make compromises in any respect, even not for the sake of making things easier for the other coders in the team :D ....

[Stux]

We attempt to adopt the RFC mantra, namely, be very strict with what you output, and very lax with what you accept as input

Basically, there are a lot of crappy muxers in the world, and our splitter has to deal with that ;)

After all... we handle perhaps the biggest hack of them all, packed bframes ;)

[alexnoe]

What about notifying the user about this? Pop up an error message like 'this file has been muxed using a crappy program...'

[robUx4]

The user won't care. The best is to degrade the playback everytime a dirty hack is encountered :D