Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: vdr / change MaxVideoFileSize > 2000MB



IIRC there is one unused byte per 8 byte entry in the index.vdr anyway.
But I dislike solution like that and would like to reiterate my previous
qustion:

What's the advantage of having large file support over the current situation
???

cu,
Christian.

> -----Original Message-----
> From: Matthias Schniedermeyer [mailto:ms@citd.de]
> Sent: Thursday, July 11, 2002 5:26 PM
> To: vdr@linuxtv.org
> Subject: [vdr] Re: vdr / change MaxVideoFileSize > 2000MB
> 
> 
> On Thu, Jul 11, 2002 at 09:37:23AM +0200, Rienecker, Fa. 
> Evenio, ITS P, M wrote:
> > There was a thread some time ago seriously discussing the 
> pros and cons of this topic.
> > 
> > In short:
> > The index.vdr file format has 4 bytes to store file 
> positions. As does vdr itself.
> > While the latter might be changed seamlesly the former 
> would require a change of file formats to support files > 2GB.
> > Actually, there will be no advantage compared to the 
> current situation having large file support.
> 
> So far thats correct. But you could "missuse" the file-field 
> for another
> 8 bits. So you could create 512MB files.
> 
> This way you don't have to change index.vdr format and still 
> be able to
> get files bigger than 2GB. (With unsigned. You could get 1TB files)
> 
> And if i'm not wrong than there are another 2 "unused" Bytes. 
> (At least
> in "Stone old" VDR they seam to be unused)
> 8 Bytes per Frame:
> 4 Bytes offset
> 1 Byte file
> 1 Byte Frame-type
> 2 Bytes "fill"?
> 
> With the 2 Bytes you could get
> a) 32768/65336 TB
> or if you don't use "file" and only this 2 Bytes
> b) 128/256 TB
> 
> Think that should be enough for the next few years. :-)
> 
> 
> 
> 
> Bis denn
> 
> -- 
> Real Programmers consider "what you see is what you get" to 
> be just as 
> bad a concept in Text Editors as it is in women. No, the Real 
> Programmer
> wants a "you asked for it, you got it" text editor -- complicated, 
> cryptic, powerful, unforgiving, dangerous.
> 
> 
> 




Home | Main Index | Thread Index