[FFmpeg-devel] [PATCH] TXD demuxer and decoder
Sun May 6 18:15:49 CEST 2007
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
even if context would be needed that doesnt mean the stack would be
that is you can write
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
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel