Avi with AC3 why isn't there a better way? [Archive] - Page 2

Chibi Jasmin

13th January 2003, 19:22

Originally posted by alexnoe
@Jasmin:
Yes. It miscalculates the framelength of 44.1 kHz MP3 frames. The deviation is more than 0.1% (acceptable is 0.001%)

@Matter: If you want me to check if NanDub uses the preload value, then i can do that. Takes me a few minutes.

I see...is this an issue that is going to be fixed or is there some limitations?

Maybe you can explain, what preload is actually good for and how it is interpreted?

BTW: You seen my other question above about padding with silent frames for corrupt streams? :D

alexnoe

13th January 2003, 19:34

If I find out why the frame length is miscalculated, then it will be fixed.

Chibi Jasmin

13th January 2003, 23:53

Okay...thx.

MaTTeR

14th January 2003, 00:50

Originally posted by alexnoe
@Matter: If you want me to check if NanDub uses the preload value, then i can do that. Takes me a few minutes. Thx but I'm sure you have other pressing projects to work on:) I might have time this weekend to hack around and see what effect if any it has on the mux.

Chibi Jasmin

14th January 2003, 00:59

@alexnoe:

I just took a Nandub muxed ac3-avi with a fracted frame at the beginning (avimux gui showed a begin value of 560) and did the following two tests:

1. I demuxed the audio with VDubMod.
2. I remuxed the file with 96ms/96ms with VDubMod.

I checked the resulting ac3 (from 1) and avi (from 2) in AviMuxGui and it still showed a begin value of 560 in both cases. So VDubMod actually preserves the fracted frame at the beginning. Just wanted to let you know, as I think you stated differently, didn't you?

alexnoe

14th January 2003, 17:40

No, i didn't: I think that NanDub does not preserve broken MP3 parts...

@Matter: I would just have a look at a NanDub file in the Vdub hex editor...but you may prefer this: Try NanDub with 10000 preload.

Seeking on a CD should become *really* awful if this preload is really applied

Chibi Jasmin

15th January 2003, 09:37

Originally posted by alexnoe
No, i didn't: I think that NanDub does not preserve broken MP3 parts...

Sorry, I remembered it wrong then...but that leaves one more open question...

What happens to that broken frame at the beginning?

We used to fix wrongly muxed nandub streams by remuxing them with 96 ms/96 ms for the plain reason, that it does not produce fracted frames then (since one frame is 32 ms). But if it treats ac3 simply as a bytestream, it would start counting with that half frame at the beginning and move 96 ms further on, what would leave it right in the middle of another frame...!? And cause fracted frames all through the whole file (fracted from one chunk to another, I mean)? Or is the first half frame somehow treated special? Please let me know your findings about this...

alexnoe

15th January 2003, 10:35

We used to fix wrongly muxed nandub streams by remuxing them with 96 ms/96 ms for the plain reason, that it does not produce fracted frames then (since one frame is 32 ms). But if it treats ac3 simply as a bytestream, it would start counting with that half frame at the beginning and move 96 ms further on, what would leave it right in the middle of another frame...!? Right. The decode filter seem to like that somehow :confused:

Chibi Jasmin

15th January 2003, 11:19

Originally posted by alexnoe
Right. The decode filter seem to like that somehow :confused:

Hmm...yeah, the files worked, as we all know...this leaves us the possibility to set delays other than multiples of 32 ms...one advantage, at least...but if this works, why don't Nandubmuxed files with 500ms/1fr work (they play choppy)? I thought, it was the fact, that ac3-frames were fracted...now, I know, they are often also fracted on 96ms/96ms (re)muxed files...so that was not the reason? :confused: Any thoughts on this?

alexnoe

15th January 2003, 13:24

Maybe it's because of the different way they are fracted (e.g. for 96/96, you'll always have the same amount of fraction, while for 80/80 or the such, the sizes of the fractions differ)

Chibi Jasmin

15th January 2003, 14:26

Originally posted by alexnoe
Maybe it's because of the different way they are fracted (e.g. for 96/96, you'll always have the same amount of fraction, while for 80/80 or the such, the sizes of the fractions differ)

Yeah, maybe...so what was your reason for avoiding fracted frames in avimuxgui (and even sacrificing accurate delay control), if these fracted frames work?

alexnoe

15th January 2003, 14:29

(1) the beginning of a stream should not be a fracted frame, otherwise the fracted beginning cannot be replayed anyway
(2) the chunk size must be a multiple of the AC3 frame size
(1)+(2) => no fracted frames at all

Chibi Jasmin

15th January 2003, 14:37

Originally posted by alexnoe
(1) the beginning of a stream should not be a fracted frame, otherwise the fracted beginning cannot be replayed anyway
(2) the chunk size must be a multiple of the AC3 frame size
(1)+(2) => no fracted frames at all

(1) I see...but is its existence taken into account for delay?
(2) In case of 96ms in Nandub chunk size is a multiple of ac3 frame size. But why do you say it must be that way? Where does that come from? Well, obviously only then the files replay fine (although with fracted frames -> Nandub 96/96)

What I wanted to know, why you chose to make AviMuxGUI so that it does not create fracted frames, as the 96/96 Nandub files play fine with fracted frames...

alexnoe

15th January 2003, 14:56

In case of 96ms in Nandub chunk size is a multiple of ac3 frame size. But why do you say it must be that way? Where does that come from? Well, obviously only then the files replay finecrappy replay filters or soundcard drivers.
Theoretically, this limit of non-fracted AC3 frames, in connection with a nGranularity=1, is against AVI specs.

If they can't make better filters, then we have to make files which their filters can replay :sly:

What I wanted to know, why you chose to make AviMuxGUI so that it does not create fracted frames, as the 96/ 96 Nandub files play fine with fracted frames...Because it seems safe to me...

Chibi Jasmin

15th January 2003, 15:21

Originally posted by alexnoe
crappy replay filters or soundcard drivers.
Theoretically, this limit of non-fracted AC3 frames, in connection with a nGranularity=1, is against AVI specs.

If they can't make better filters, then we have to make files which their filters can replay :sly:

Because it seems safe to me...

Okay, let me see, if I understood...

The fact that files only play, if chunk-size is a multiple of ac3 frame size, is due to crappy drivers or filters. Right?

And AVI-Specs actually allow fracted ac3-frames (I have to admit I don't understand this nGranularity thing)? Well, they actually play fine (if chunk size = multiple of ac3framesize)...

And what about (1)? The fracted frame at the beginning...does it cause a delay in playback? Then it would have its purpose...or can it just as well be discarded?

Sorry for questioning that much, but you seem to have worked with this a lot and I (and probably many others) would be happy to understand...

alexnoe

15th January 2003, 18:30

Every audio stream has this nGranularity value in its header. This defines the number which each chunk size must be a multiple of.
For AC3, this value is set to 1 => each chunk must have a size which is a multiple of 1.
Setting other values (which make more sense, such as the ac3 frame size) results in unplayable files.

I don't know how fracted frames at the beginning are handled. The AVI file format does not define the behaviour, so I guess than any filter does what it wants.

Chibi Jasmin

15th January 2003, 18:43

Originally posted by alexnoe
Every audio stream has this nGranularity value in its header. This defines the number which each chunk size must be a multiple of.
For AC3, this value is set to 1 => each chunk must have a size which is a multiple of 1.
Setting other values (which make more sense, such as the ac3 frame size) results in unplayable files.

I don't know how fracted frames at the beginning are handled. The AVI file format does not define the behaviour, so I guess than any filter does what it wants.

Every driver and filter does what it wants :D

So may I assume, these files with nGranularity=1 are spec-compliant, even if they have fracted ac3-frames throughout the whole file? Not that being compliant means too much, though...

Now, that you explained what nGranularity is, what did you exactly mean with

Theoretically, this limit of non-fracted AC3 frames, in connection with a nGranularity=1, is against AVI specs.

?

alexnoe

15th January 2003, 18:55

So may I assume, these files with nGranularity=1 are spec-compliant, even if they have fracted ac3-frames throughout the whole file? YesTheoretically, this limit of non-fracted AC3 frames, in connection with a nGranularity=1, is against AVI specs.?`A nGranularity=1 value means that the stream can look like whatever it wants, and this must not affect playback (unless the data source, e.g. CD-ROM, is too slow to manage the seeking).

Filters which require anything else should be considered broken

Chibi Jasmin

15th January 2003, 19:45

Originally posted by alexnoe
A nGranularity=1 value means that the stream can look like whatever it wants, and this must not affect playback (unless the data source, e.g. CD-ROM, is too slow to manage the seeking).

Filters which require anything else should be considered broken

I'm beginning to understand. Trying to sum up:

The Nandub-files with fracted frames are always spec-compliant..but only the ones muxed with interleaving multiple of 32 ms (in this case chunk size is a multiple of ac3 frame size) play flawlessly (even, if the stream is full of fracted frames), probably due to crappy filters/drivers.

AviMuxGUI does not create streams with fracted frames for safety reasons, not because it is proven to be necessary for anything.

A fracted frame at the beginning of a stream cannot be replayed. Its influence on playback filters is unknown or may vary; it might cause a delay. <- would it be possible to find out, if it actually causes a delay in playback or not?

Please correct me, if anything of the above is wrong and/or let me know, if you have an idea how to find out, if a fracted frame at the beginning could actually serve as introducing a delay in audio playback, making setting a delay not multiple of 32 ms possible.

Thanx in advance!

alexnoe

15th January 2003, 20:00

You've summerized correctly.

It will be hard to find out what happenes with the fracted frame at the beginning...I do not know how to determine whether a delay of <32ms is present or not.
You could try inserting more "half" frames to get an audible delay (or not).

BUT: If it is causing no delay, then the file would replay fine at the beginning, but would run off sync as soon as you seek (seeking in the audio stream of an AVI file is only based on "time / bitrate")

Chibi Jasmin

15th January 2003, 20:01

Originally posted by alexnoe
96/96 are 3 chunks.

Okay, the below quote might be crap...but isn't it 3 ac3 frames/1 chunk then?

Originally posted by Chibi Jasmin
Isn't it 2 chunks and 3 chunks in a varying pattern? Well, anyways, that's what I wanted to know, so everything should be fine.

I got to this by looking at this thread: http://forum.doom9.org/showthread.php?s=&threadid=23504 and counting '00dc's between each '01wb' and that is varying between 2 and 3... :D

Originally posted by alexnoe
You've summerized correctly.

It will be hard to find out what happenes with the fracted frame at the beginning...I do not know how to determine whether a delay of <32ms is present or not.
You could try inserting more "half" frames to get an audible delay (or not).

BUT: If it is causing no delay, then the file would replay fine at the beginning, but would run off sync as soon as you seek (seeking in the audio stream of an AVI file is only based on "time / bitrate")

Hmm...why would it go off-sync, if it caused no delay (I didn't get that time/bitrate thing)? And I already thought about inserting more than one half-frame, but had no idea how to achieve that...any hints?

alexnoe

15th January 2003, 20:06

=> you confuse frames and frames!

One AC3 frame lasts 32ms, one video frame lasts 40 frames. => 3 AC3 frames last 96 ms, which is about 2,5 video frames. => of course you get 2/3/2/3...00dc chunks. But these are video frames, not AC3 frames :D

Seeking in an AVI files work like this for audio:

Lets say, you want to seek to the position "1 hour"
=> 448 kBit audio => you can calculate the byte position at which you have "1 hour"

If you have crap data at the beginning, which is not replayed, it would tell the wrong position

Chibi Jasmin

15th January 2003, 20:09

Originally posted by alexnoe
=> you confuse frames and frames!

One AC3 frame lasts 32ms, one video frame lasts 40 frames. => 3 AC3 frames last 96 ms, which is about 2,5 video frames. => of course you get 2/3/2/3...00dc chunks. But these are video frames, not AC3 frames :D

You mean one video frame = 40 ms? (for 25 fps)?

Yeah, I saw I confused it...

but for 96/96 muxed files it's still 3 ac3 frames/chunk, right?

alexnoe

15th January 2003, 20:10

Yes

Chibi Jasmin

15th January 2003, 20:11

Originally posted by alexnoe

Seeking in an AVI files work like this for audio:

Lets say, you want to seek to the position "1 hour"
=> 448 kBit audio => you can calculate the byte position at which you have "1 hour"

If you have crap data at the beginning, which is not replayed, it would tell the wrong position

But it would still be off for only the small value, the fracted frame would have caused? But you say it goes progressively out of sync? I somehow don't get it...sorry for my stupidity...

alexnoe

15th January 2003, 20:14

It doesn't go progressively out of sync.
Still assuming that crap data at the beginning is ignored if you start the replay.

It would start playing fine, but as soon as you seek, it would run out of sync (yes, only a very little bit), and would then keep that off-sync at a constant value, regardless of what you do later.

Chibi Jasmin

15th January 2003, 20:14

Originally posted by Chibi Jasmin
You mean one video frame = 40 ms? (for 25 fps)?

Yeah, I saw I confused it...

but for 96/96 muxed files it's still 3 ac3 frames/chunk, right?

Originally posted by alexnoe
Yes

Yes, what? Yes 40 ms or yes 3 ac3 frames/chunk ? :)

BTW: How could I insert more than one fracted frame at the beginning for testing? Any idea?

Chibi Jasmin

15th January 2003, 20:16

Originally posted by alexnoe
It doesn't go progressively out of sync.
Still assuming that crap data at the beginning is ignored if you start the replay.

It would start playing fine, but as soon as you seek, it would run out of sync (yes, only a very little bit), and would then keep that off-sync at a constant value, regardless of what you do later.

Hmm...does it go more out of sync than the length of one ac3-frame = 32 ms (the maximum delay a fracted frame, let's say 1 byte missing, could cause)? I am asking, because I didn't understand the calculation...

alexnoe

15th January 2003, 20:18

Hmm...does it go more out of sync than the length of one ac3-frameNo, probably not.
But if you don't care about 32ms, then there is no need to implement AC3 silence when encountering broken AC3 data...

Chibi Jasmin

15th January 2003, 20:21

Originally posted by alexnoe
No, probably not.
But if you don't care about 32ms, then there is no need to implement AC3 silence when encountering broken AC3 data...

Well, I do care :D In fact, I am actually hoping, that these fracted frames cause a delay...btw: why wouldn't it be out of sync from the beginning, but only when seeking?

But what I fear (that's why I always wanted silence padding in avimuxgui), is that the error accumulates, if you join multiple nandub files with corrupt frames...if everything fits, avimuxgui can join the split frames from one cd to another, if I got it right, and would only delete the first fracted one causing a delay < 32 ms, but if there's some more corrupt frames somewhere for whatever reason, the delay error, if there's no silence padding inserted accumulates more and more...

Hmm...I will see, if I can somehow insert multiple fracted frames at the beginning of a video to check, if it causes a delay...still no idea, how to do it, though...

alexnoe

15th January 2003, 20:24

Well, I do care In fact, I am actually hoping, that these fracted frames cause a delay...btw: why wouldn't it be out of sync from the beginning, but only when seeking?Maybe because I have written that I assume for these thoughts that broken data at the beginning of the replay is ignored? If it is not ignored, then it could indeed set a delay <32ms without side effect, but I won't do it!

Chibi Jasmin

15th January 2003, 20:34

Originally posted by alexnoe
Maybe because I have written that I assume for these thoughts that broken data at the beginning of the replay is ignored? If it is not ignored, then it could indeed set a delay <32ms without side effect, but I won't do it!

You got the question wrong, I guess....

Two things:

1. You said, if one fracted frame at the beginning caused no delay, it would go out of sync on seeking...my question is...why not instantly on playing?
2. I didn't want you to make AviMuxGUI capable of inserting fracted frames at the beginning to make delays <32 ms possible. Just discard the fracted first frame, if there is one (if begin > gran./2 better add 32 ms delay automatically), as you do now.... What I wanted is, that you insert a full 32 ms long silence frame, wherever you encounter a broken ac3 frame somewhere in the middle of the stream. Please!

alexnoe

15th January 2003, 20:38

You said, if one fracted frame at the beginning caused no delay, it would go out of sync on seeking...my question is...why not instantly on playing?I didn't get it wrong. Again: IF the player first ignores the broken beginning, then it will start in sync. IF = falls...
But when seeking, the calculation of the new position within the stream cannot take care of that beginning.

Chibi Jasmin

15th January 2003, 20:42

Originally posted by alexnoe
I didn't get it wrong. Again: IF the player first ignores the broken beginning, then it will start in sync. IF = falls...
But when seeking, the calculation of the new position within the stream cannot take care of that beginning.

Call me dumb, but then it should be the other way round?

It ignores the fracted frame, so it is slighty off-sync...you seek...it calculates the offset by total length of audio, taking the fraction at the beginning into account and then is in sync? :D

alexnoe

15th January 2003, 20:47

If off-sync before => maybe on-sync afterwards
If on-sync before => off-sync afterwards...

Chibi Jasmin

15th January 2003, 20:58

Originally posted by alexnoe
If off-sync before => maybe on-sync afterwards
If on-sync before => off-sync afterwards...

Okay...I'll just eat this!

Originally posted by Chibi Jasmin
You mean one video frame = 40 ms? (for 25 fps)?

Yeah, I saw I confused it...

but for 96/96 muxed files it's still 3 ac3 frames/chunk, right?

Originally posted by alexnoe
Yes

Yes, what? Yes 40 ms or yes 3 ac3 frames/chunk ? :)

I always got confused by these indexes at the end...how does this work? Let's say we have a 96ms/96ms 25 fps file. one 01wb is an audio chunk lasting 96 ms. one 00dc is one video frame lasting 40 ms, so we have this 2/3 pattern. The indexes say something about how the chunks are organised in the file? One chunk is always stored consecutively...for audio this is 3 frames = 96 ms...and then comes either 2 or 3 video frames that are also stored fully and not somehow fracted...then an audio chunk again...on playback audio and video is read and somehow synced to play correctly...so the index at the file is just indicating how things are stored in the file...the actual length of one video frame or one audio chunk is determined elsewhere and (frame rate, ac3framesize) and these values are used to calculate how the video and audio play together...these 01wb's and 00dc's in a varying pattern have nothing to do with video or audio frames being fracted or synced/not-synced! Is that correct? Probably a dumb explanation...can you shed some light into this?

BTW: How could I insert more than one fracted frame at the beginning for testing? Any idea?

---

take a break, if you don't feel like answering right away, anytime...but I am indeed thankful to you sharing your wisdom with me... ;)

alexnoe

15th January 2003, 22:24

At first: This is one chunk of an AVI file:
typedef struct
{
DWORD dwFourCC;
DWORD dwLength;
BYTE bData[dwLength];
}
The first 8 bytes are called chunk header

Yes, what? Yes 40 ms or yes 3 ac3 frames/chunk ? Both
The indexes say something about how the chunks are organised in the file? The index specifies Stream which a chunk belongs to (number and audio/video) the position and size of each chunk keyframe or deltaframe the order in which the chunks of one stream are played (which is *not* necessarily the order in which the chunks really occur in the file. Although storing them in a weird order does not make sense, except for copy-protecting a CD containing an AVI file, it would be allowed)A Video frame has to occupy one chunk. Fracting is against AVI specs.the actual length of one video frame or one audio chunk is determined elsewhere and (frame rate, ac3framesize)There are 2 framerate values within each AVI file. The first one is ignored by DirectShow (and sometimes broken when using M$ software!). The length of each chunk, measured in bytes, is found in the index, and of course in each chunk header.these 01wb's and 00dc's in a varying pattern have nothing to do with video or audio frames being fracted or synced/not-synced! Is that correct?correct.