[Fwd: Re: [Matroska-devel] Re: matroska excluded from Gordian Knot 0.29 Alpha]

Christian HJ Wiesner chris at matroska.org
Tue Oct 21 12:21:51 CEST 2003


Ok,

this email is going to the gordianknot-alphas list and to matroska-devel 
also. matroska devs please note you cant send emails to the GKnot list 
if you are not subscribed.

Toni, Alex has overworked his MKV overhead code again, and i guess the 
accuracy he thinks is possible should be more than ok for the purposes 
in GKnot. Would you be prepared to look at it again ? You mentioned you 
need a formula for it to work, i dont know if Alex Noe can make such a 
formula from his code, but isnt the C++ code usable somehow ? Maybe as a 
DLL ?

Christian


-------- Original Message --------
Subject: 	Re: [Matroska-devel] Re: matroska excluded from Gordian Knot 
0.29 Alpha
Date: 	Tue, 21 Oct 2003 11:37:33 +0200
From: 	Alexander Noé <alexander.noe at s2001.tu-chemnitz.de>
Reply-To: 	Discussion about the current and future development of 
Matroska <matroska-devel at lists.matroska.org>
To: 	Discussion about the current and future development of Matroska 
<matroska-devel at lists.matroska.org>
References: 	<3F9410BD.3070300 at matroska.org> 
<3F941240.7020808 at hrz.tu-chemnitz.de> <bn2c9j$3tp$1 at sea.gmane.org> 
<3F94E037.4030207 at matroska.org>



Christian HJ Wiesner wrote:

> Pamel wrote:
>
>> Using the AVI code would tell you what size the file will not reach. 
>> This is
>>
>> probably better than nothing at all.
>> Pamel
>>  
>>
> This was exactly the idea ... it will always leave some MB to include 
> either TCMP or one of the matroska packs with the CD :D .... 

I've found out why my code was b0rked. However, with this EBML lacing, I 
will *never* promise an
accuracy any better than 10% for overhead prediction. Basicly, it will 
be off by not more than
0.5 bytes per frame (it can be 1 or 2, so if I assume 1.5 bytes per 
frame, it won't be off by more than
0,5), i.e. 75 kB per hour and stream, which is 450 kB for 3 languages in 
a 2h movie, which is
about 10% of the total overhead of such a thing, roughly estimated. The 
more vbr audio streams
there are, the worse *could* the estimation be.

Anything better would require statistical analysis of the output of 
certain encoders for each bitrate and
quality setting. What you see in the attached file is 3 hours, but only 
one stream.



Alex


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: proto.txt
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20031021/d49cdd65/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: file:///C|/DOKUME%7E1/V-CW/LOKALE%7E1/TEMP/nsmail-2.txt
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20031021/d49cdd65/attachment-0001.txt>


More information about the Matroska-devel mailing list