[matroska-devel] Re: [Fwd: Re: Hosting of MPC]

Steve Lhomme steve.lhomme at free.fr
Sat Jan 25 17:04:14 CET 2003


Christian HJ Wiesner wrote:

> Email from Frank :
>
> -------- Original Message --------
> Subject: Re: Hosting of MPC
> Date: Fri, 24 Jan 2003 22:51:12 +0100
> From: Frank Klemm
> To: Christian HJ Wiesner
> References: <3DB411A0.32750.1362067 at localhost> 
> <004e01c2c14f$6dea6450$a70aa8c0 at mahlo.de> 
> <20030123140827.A15489 at fuchs.offl.uni-jena.de> <3E30847C.50104 at web.de>
>
>
>
> http://matroska.sourceforge.net/specs/index.html
>
>
>
>
> ------------------------
>
> SamplingFrequency	4	[B5]	-	>0	-	float		Sampling frequency in Hz.
> Channels		4	[9F]	-	not 0	2	u-integer	Numbers of channels in the track.
>
> ------------------------
>
> würde ich auf ( i would change to )
>
> ------------------------
> SamplingFrequency	4	[B5]	-	>0	8000.	float		Sampling frequency in Hz.
> Channels		4	[9F]	-	not 0	1	u-integer	Numbers of channels in the track.
> ------------------------
>
> 1. halte ich nicht sonderlich viel von solchen impliziten Werten,
>     man spart ein paar Bytes in einer Multimegabyte-Datei und handelt
>     sich vorhersehbaren Ärger ein. Bin genug häufig in so was
>     selbst reingetappt, das letzte mal gestern.
>
> 2. Von Interesse sein können die Einsparungen von ein paar Bytes bei
>     Datenströmen mit sehr geringer Datenrate und Qualität. Das ist dann
>     meistens Mono (und nicht Stereo) und 8 kHz Abtastfrequenz.

Sorry, my german is not good enough to understand this, and I have no 
offline translator ;)
As I said on the EBML website (http://ebml.sourceforge.net/) EBML is 
very verbose (as is XML) so it is convenient to have good default values 
so that the general-case-file will not take too much space. And I think 
the general case for digital audio is still 44100/stereo. I don't know 
much people using 8000/mono... Now of course that would save space in 
the most space limited case.
Which approach is better ?

>
> =============================================================================
>
> ------------------------------------------------------------------------
> PixelAspectRatio	4	[41][52]	-	>0	1.333333	float	Pixel aspect ratio of
> the pixels.
> ------------------------------------------------------------------------
>
> [Frank]Dieses Beispiel ist irreführend. Es gibt kein Movieformat, was ein
> Pixelseitenverhältnis von 4:3 verwendet. Last das so schnell wie möglich
> verschwinden, sonst gibt es so viele fehlerhafte Implementierungen, so daß
> es am Ende einfacher ist den Standard zu ändern als die Fehler zu
> fixen.[/Frank]
>
> This example is not good, there is no such thing as a 4:3 AR. I'd remove
> that or errors will be the result.

Uh ? So we should put 1.00000 ?

> [Frank]Ich hatte die Werte schon man geschickt, zweiter Versuch, einen
> dritten gibt
> es nicht:[/Frank]
>
> I sent these values already, i wont send them another time :
>
> [Frank]        horizontal:vertikal
> HDTV:            1:1
> PAL:            16:15
> PAL anamorph:   64:45
> NTSC:            8:9
> NTSC anamorph:  32:27

Is that the pixel aspect-ratio or the display aspect-ratio ? I think the 
most logicial for a computer format is 1.0000 PAR. What do the experts 
think ?

> Ich würde das Verhältnis als zwei teilerfremde Ganzzahlen abspeichern.
> Gleitkommazahlen sind erstens ungenauer und zweitens verleiten sie zur
> sogenannten Gleitkomma-Schmiererkrankung. Man speichert ungefähr richtige
> Werte ab und überläßt es dem Programmierer, diesen Schlamassel durch
> etwas heuristischen Code meistens unsichtbar zu machen.[/Frank]
>
> I would store the values as two integer numbers. Floats are more
> unprecise and often handled incorrectly.

Well, what would be the difference with the Height and Width of the 
movie ? One would be the encoding and the other the display ?

> [Frank]Wenn z.B. "NTSC anamorph" abgespeichert, ist was ungefähr
> 1:1.18518518518518518518
> ist, dann wird man verschiedene Werte in dem Tag finden:
>
>    1.2
>    1.18
>    1.19
>    1.185
>    1.1852
>    1.185185185
>
> Und der Decoder muß dann wieder raten, was gemeint ist.
> Wenn dagegen { 32, 27 } zu stehen hat, dann ist eindeutig alles andere
> FALSCH. Keine Gleitkommaschmiererkrankung und keiner der fluchen muß,
> daß sein AR von exakt 1:1.2 auf 1:1.185185185 getweakt wird und die
> Software damit für seine Meßzwecke unbrauchbar ist.
> Frank Klemm[/Frank]
>
> E.g, ,these are the values you will find for the NTSC anamorph standard
> if you specify floats. In the end the decoder will have to make a 
> guess again ...


So can we go for the encoding Width/Height and the display Width/Height ?


http://matroska.org



More information about the Matroska-devel mailing list