Avi with AC3 why isn't there a better way? - Page 4

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

Quote:

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

Quote:

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

Quote:

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

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

Quote:

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

Quote:

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

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

Quote:

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

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

Quote:

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

?

alexnoe · 15th January 2003, 18:55

Quote:

So may I assume, these files with nGranularity=1 are spec-compliant, even if they have fracted ac3-frames throughout the whole file?

Yes

Quote:

Theoretically, 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

Quote:

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

Quote:

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?

Quote:

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...

Quote:

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

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

Quote:

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

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

Quote:

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

Quote:

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?

Quote:

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

Quote:

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

Quote:

Hmm...does it go more out of sync than the length of one ac3-frame

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...

15th January 2003, 20:00	#71 \| Link
alexnoe Banned Join Date: Aug 2002 Location: Germany Posts: 1,737	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") Last edited by alexnoe; 15th January 2003 at 20:02.

15th January 2003, 13:24	#61 \| Link
alexnoe Banned Join Date: Aug 2002 Location: Germany Posts: 1,737	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)

15th January 2003, 14:29	#63 \| Link
alexnoe Banned Join Date: Aug 2002 Location: Germany Posts: 1,737	(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

15th January 2003, 18:30	#67 \| Link
alexnoe Banned Join Date: Aug 2002 Location: Germany Posts: 1,737	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.

15th January 2003, 20:06	#73 \| Link
alexnoe Banned Join Date: Aug 2002 Location: Germany Posts: 1,737	=> 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 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

15th January 2003, 20:10	#75 \| Link
alexnoe Banned Join Date: Aug 2002 Location: Germany Posts: 1,737	Yes

15th January 2003, 20:14	#77 \| Link
alexnoe Banned Join Date: Aug 2002 Location: Germany Posts: 1,737	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.