[FFmpeg-devel] [RFC][PATCH] Windows Television (WTV) file system handling

[Michael Niedermayer]

On Tue, Jan 11, 2011 at 01:01:48PM +1100, Peter Ross wrote:
> On Tue, Jan 11, 2011 at 12:33:59AM +0100, Michael Niedermayer wrote:
> > On Sun, Jan 09, 2011 at 05:21:20PM +1100, Peter Ross wrote:
> > > Hi,
> > > 
> > > The Windows Television (WTV) file format is a more complex beast than
> > > initially imagined.
> > > 
> > > WTV is best viewed as a file system. Metadata, seek index tables, and
> > > chunked data are stored in separate files within. The fileystem uses
> > > a simple hierarchical file allocation table, with standard (4k) and big
> > > (256k) sector sizes. Standard FAT concepts apply, like fragmentation
> > > and the existence of slack space.
> > > 
> > > The current WTV demuxer is not aware of the file system, and therefore
> > > only works on smalls wtv samples (<600MiB) where the files are not
> > > fragmented. Most WTV recordings are much larger. e.g. a 3hr HD recording
> > > of the tennis results in a 24GiB file and lots of fragmentation.
> > > 
> > > Due to the complexity, I would really appreciate comments on the patch,
> > > especially my use of ByteIOContext.
> > 
> > Which part of the ByteIOContext use do you want comments about?
> 
> wtvfile_read_packet(), wtvfile_seek() and wtv_open_sector() if possible.
> 
> These functions provide a ByteIOContext instance, representing the contents
> of a file within the filesystem.

I dont think this is the most efficient way to handle it but i dont see a
problem after a quick look.

why dont you build the ByteIOContexts based on something from the underlaying
read_packet/seek ?

and how much seeking does this cause btw? if alot maybe the buffer sizes
could be increased

[...]
--
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110111/d434b88b/attachment.pgp>