[Matroska-devel] Re: Re: Re: [Ffmpeg-devel] Adding matroska supporttoFFMPEG via libmatroska/libebml, in C++ ?

Moritz Bunkus moritz at bunkus.org
Tue Oct 14 20:00:10 CEST 2003


Hi.

> What if we just had a new ID for the new block design?  Old readers would just
> skip it and would register no Blocks from the stream, which is the point of EBML
> anyway.  Everything else would be identical, so new coding would just be to
> handle the new ID.  What is the cost/benefit of going to a new ID?

Yeah, a new ID might be good. Only drawback I see so far is that we'd
have one more 1 byte ID that's used, but hey, they're there to be used ;)

> Would this help out with the higher bitrate codecs?  The only one that I know of
> that wouldn't use the 'same length flag' would be VBR MP3.  So, would VBR MP3
> benefit from using differentials?

Dunno. No VBR track will have this flag set - this is not about duration but
bitrate. Nevertheless AC3 is CBR if I recall correctly. AAC is VBR and
looks really interesting: (just one sample here)

|  + Block (track number 1, 8 frame(s), timecode 0.000s)
|   + Frame with size 333
|   + Frame with size 329
|   + Frame with size 331
|   + Frame with size 341
|   + Frame with size 345
|   + Frame with size 337
|   + Frame with size 342
|   + Frame with size 340
| + Block group
|  + Block (track number 1, 8 frame(s), timecode 0.170s)
|   + Frame with size 339
|   + Frame with size 341
|   + Frame with size 338
|   + Frame with size 344
|   + Frame with size 345
|   + Frame with size 339
|   + Frame with size 342
|   + Frame with size 333

Here differential values would actually be a gain.

For Vorbis things are different:

|  + Block (track number 1, 8 frame(s), timecode 0.000s)
|   + Frame with size 26
|   + Frame with size 273
|   + Frame with size 223
|   + Frame with size 209
|   + Frame with size 213
|   + Frame with size 207
|   + Frame with size 209
|   + Frame with size 221
| + Block group
|  + Block (track number 1, 8 frame(s), timecode 0.141s)
|   + Frame with size 41
|   + Frame with size 55
|   + Frame with size 56
|   + Frame with size 218
|   + Frame with size 195
|   + Frame with size 193
|   + Frame with size 207
|   + Frame with size 201
| + Block group
|  + Block (track number 1, 8 frame(s), timecode 0.256s)
|   + Frame with size 208
|   + Frame with size 200
|   + Frame with size 204
|   + Frame with size 208
|   + Frame with size 205
|   + Frame with size 209
|   + Frame with size 207
|   + Frame with size 204

Here you might be lucky (or not), but for this example differential
coding would be the winner, too.

And as Cyrius just said:
[.19:57:29.] <@Cyrius> Pamel: some CBR MP3 streams also have variable
frame size
[.19:57:44.] <@Cyrius> those at 44.1kHz (for mpeg v1) IIRC
[.19:58:03.] <@Cyrius> actually those ones vary of 1 byte
[.19:58:21.] <@Cyrius> e.g. 417/418 bytes per frame
[.19:58:29.] <@Pamel> We will lie then and say they are all the same
size.
[.19:58:41.] <@Cyrius> you can't :p
[.19:58:47.] <@Cyrius> we are talking of lacing
[.19:58:51.] <@Pamel> Just pad the frame.  ;)
[.19:59:02.] <@Cyrius> if you lie about the size then you won't read the
correct amount of data :p
[.19:59:09.] <@Cyrius> lol
[.19:59:15.] <@Cyrius> no padding allowed :p
[.19:59:25.] <@Pamel> How often do you see those?

-- 
 ==> Ciao, Mosu (Moritz Bunkus)



More information about the Matroska-devel mailing list