[FFmpeg-cvslog] r13899 - in trunk/libavformat: isom.c mov.c

[Michael Niedermayer]

On Tue, Jun 24, 2008 at 02:42:48AM -0700, Baptiste Coudurier wrote:
> Benoit Fouet wrote:
> > Baptiste Coudurier wrote:
> >> Benoit Fouet wrote:
> >>   
> >>> Baptiste Coudurier wrote:
> >>>     
> >>>> Benoit Fouet wrote:
> >>>>   
> >>>>       
> >>>>> Baptiste Coudurier wrote:
> >>>>>     
> >>>>>
> >>>>>         
> >>> [...]
> >>>
> >>>     
> >>>>>> IMHO the only solution is to export more that what it is atm.
> >>>>>> What needs to be discussed is formatting and api.
> >>>>>>
> >>>>>> A solution which would not breaking anything would be to add
> >>>>>> extended_codec_data field to AVCodecContext which would contain full
> >>>>>> stsd or atoms, so original extradata is kept for backward compat.
> >>>>>>
> >>>>>>   
> >>>>>>       
> >>>>>>           
> >>>>> that could be a solution, even though it would duplicate extradata when
> >>>>> lavf knows how to handle it.
> >>>>>     
> >>>>>         
> >>>> lavf does not have to know how to handle extradata, it only has to
> >>>> export it. Only codecs use extradata.
> >>>>
> >>>>   
> >>>>       
> >>> well, let me rephrase: lavf has to know how to export extradata, and
> >>> this is where I fail to see any generic way.
> >>>     
> >> Not necessarly. I don't see why lavf would have to know.
> >>
> >> What's needed by the codec is in stsd, lavf should export stsd IMHO,
> >> this would also solve the different codec/display resolutions problem,
> >> but yet to avoid duplication.
> >>
> >> I already said Quicktime API export stsd in a generic way.
> >>
> >>   
> >>> for instance, for H.264 in QT, only the demuxer knows how to parse the
> >>> atom to reformat the SPS/PPS data.
> >>>
> >>>     
> >>>> The more generic lavf is, the better it is for its users, that's why it
> >>>> has codec_tag field etc.. to let applications handling what lavf does
> >>>> not know (yet).
> >>>>
> >>>>   
> >>>>       
> >>> "yet" being the important word here
> >>> that means you cannot use extradata field to handle a "generic" case
> >>>     
> >> IMHO "all atoms after stsd" is far more generic than whatever butchered
> >> data present in any frining atom nobody knows about, same for mkv.
> >>
> >> Furthermore it is deadly simple to parse.
> >>
> >>   
> > 
> > yes it is...
> > 
> >>> how is an application supposed to know how to parse / reformat extradata
> >>> to pass it to the decoder ?
> >>>     
> >> Documentation, API.
> >>
> >> "mov/mp4/3gp demuxer exports in extradata all atoms present after stsd
> >> structure" is documentation, and generic for mov/mp4/3gp.
> >>
> >> "avi/asf/wmv/wav demuxer exports in extradata all bytes present after
> >> WAVEFormat/Ex/Extended structure"  is documentation and generic for
> >> avi/asf/wmv/wav.
> >>
> >> It seems obvious that every application does this currently, see below.
> >>
> >>   
> > 
> > then what would you think of having function(s) to parse the extradata
> > we know how to handle ?
> > that would ease the application developpers lives
> 
> Yes, I understand this, and this is the goal.
> 
> There are 4 points:
> - How to retrieve extradata from the demuxer.
> - Format it to feed the decoder.
> - How to retrieve extradata from the encoder.
> - Format it to feed the muxer.
> 
> Exporting all sufficient data is required which is what current
> implementation misses atm.
> 
> Having functions would certainly be handy, and I guess this should go in
> a bitstream filter especially for h264.
> 
> Also I think user could want to add a few other atoms in stsd while
> muxing, it would be nice to allow this.

Exporting extradata as is (full stsd) is fine in principle, what we need
though are
1. bitstream filters capable to convert from any supported encoder or demuxer
to any supported muxer or decoder.
2. These bitstream filters must be activated automatically and must be
manually overrideable.

Currently each codec has a single standard format for extradata, and every
demuxer and muxer convert to/from that. What you suggest, if i understand it
correctly would be to move this convertion code out of demuxers&muxers. This
would split code into smaller easier to understand parts but would not really
reduce the amount of code.

I guess there is not that much to say about "1." its just moving the
convertion code to bitstream filters.

"2." is more tricky, in a normal encoding (demuxer->decoder->encoder->muxer)
there really would be 2 places where extradata converting filters would become
needed.

I think the first thing we should do is introduce a bitstream_id and
corresponding enum that specifies which exact bitstream/extradata formatting
is used, similar to codec_id.

Next bitstream filters, codecs, muxers and demuxers just need to each 
have a list of supported bitstream_ids and suddenly we can autoload them.

For simplicity i suggest a BITSTREAM_ID_DEFAULT=0 which simply is the
default / primary bitstream formating for each codec. Without that we might
need a bitstream_id for each codec_id. With BITSTREAM_ID_DEFAULT we just
need one for codecs which have more than 1 formatting.

Then we can just add a bitstream_id to AVCodecTag which as a sideeffect
will give each muxer and demuxer a list of supported codec_ids/bitstream_ids

Similarly adding AVCodecTag lists to bitstream filters and AVCodecs and
we are done ...


[...]

> We all agree that extradata handling in mov is braindead.

Yes, only ogg is more braindead

[...]
-- 
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: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080624/5ba736d8/attachment.pgp>