[FFmpeg-devel] [PATCH] TXD demuxer and decoder

[Michael Niedermayer]

Hi

On Sun, May 06, 2007 at 05:28:34PM +0200, Ivo wrote:
[...]
> > > [..stack based demuxer..]
> >
> > whats the stack good for?
> > i think TXD_FILE / TXD_INFO should be read in the header reading code
> > like read and ignore TXD_FILE
> > skip all TXD_INFO
> >
> > and then the packet read code could do
> > read next chunk
> >
> > if(TXD_TEXTURE)
> >     ignore
> > if(TXD_TEXTURE_DATA)
> >     av_get_packet() ...
> > else
> >     skip
> >
> > or does that fail with any file? if so why?
> > your stack code might appear more robust at first (it did to me) but if
> > the sizes of TXD_TEXTURE and the contained packets missmatch then it will
> > also fail like my suggestion above and if they dont missmatch then i dont
> > see where the stack would do any good ...
> 
> When I started writing the demuxer, I was undecided which approach would be 
> best. I chose to implement a full-blown stack based demuxer because I do 
> not know what other chunks and sub-chunks might exist in other files. I  
> only tested files of Grand Theft Auto: San Andreas, that only have v8 and 
> v9 texture_data chunks and the (sub)chunks I described at the wiki page. 
> But there might well be other sub-chunks that re-use id's of other scopes 
> and/or more levels of encapsulation. The Renderware engine has been in use 
> for over six years and there are more than 60 games listed at 
> http://en.wikipedia.org/wiki/Renderware. I did not want to risk being 
> forced to overhaul the whole demuxer when I encounter a file that cannot be 
> demuxed without knowing the proper context in which a subchunk appears. I 
> think the cost (both in size and speed) of the current demuxer compared to 
> what you suggest is negligible. Sadly I do not have more test files (I 
> might be able to get my hands on older GTA games) so I can not be sure if 
> the current filedescription is conclusive. If it were, I could simplify the 
> demuxer.

even if context would be needed that doesnt mean the stack would be

that is you can write

read_txd_texture_header()
read_txd_texture_data_header()
av_get_packet()

no stack and you have alot of context 


also i think that all cases where the stack would be really needed would
need significant changes anyway ...

i mean where would the current code fail?
if there are several data streams
if TXD_TEXTURE_DATA chunks are split up somehow in smaller chunks

but for these the read_txd_texture_header; read_txd_texture_data_header; ...
should still work ...
and its not hard to add a variable to the context to hold a little bit of
info about the parent chunk, i mean putting the parent chunk id or some other
field into the context is trivial and i dont see what you would gain by 
adding these onto the stack structure

also its not size or speed why i dont like the stack approach but
rather that its hard to understand and debug

and i dont like messy code being justified by (its not slower or bigger
and i know of no case where its needed but maybe there exist some files
which have a different structure which might benefit from the messy code)

messy code rather should be justified with (its smaller or its faster or
file xyz needs it)

[...]
-- 
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: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070506/98ed7774/attachment.pgp>