[FFmpeg-cvslog] r11621 - trunk/libavformat/mov.c

[Michael Niedermayer]

On Mon, Jan 28, 2008 at 12:18:36PM +0100, Reimar D?ffinger wrote:
> Hello,
> On Sun, Jan 27, 2008 at 03:38:24PM +0100, Baptiste Coudurier wrote:
> > michael wrote:
> > > Author: michael
> > > Date: Sat Jan 26 20:50:04 2008
> > > New Revision: 11621
> > > 
> > > Log:
> > > Select non jpeg if there are multiple substreams.
> > > 
> > > 
> > > Modified:
> > >    trunk/libavformat/mov.c
> > > 
> > > Modified: trunk/libavformat/mov.c
> > > ==============================================================================
> > > --- trunk/libavformat/mov.c	(original)
> > > +++ trunk/libavformat/mov.c	Sat Jan 26 20:50:04 2008
> > > @@ -600,8 +600,10 @@ static int mov_read_stsd(MOVContext *c, 
> > >          get_be16(pb); /* reserved */
> > >          get_be16(pb); /* index */
> > >  
> > > -        if (st->codec->codec_tag) {
> > > -            /* multiple fourcc, just skip for now */
> > > +        if (st->codec->codec_tag && st->codec->codec_tag != MKTAG('j', 'p', 'e', 'g')) {
> > > +            /* multiple fourcc, we skip jpeg, this isnt correct, we should export it as
> > > +               seperate AVStream but this needs a few changes in the mov demuxer, patch
> > > +               welcome */
> > >              url_fskip(pb, size - (url_ftell(pb) - start_pos));
> > >              continue;
> > >          }
> > 
> > This is hackish, and Im against it. You will have to add all image types
> > (png and so on). The proper solution must be implemented, and adding
> > hacks won't help.
> 
> May I suggest a different hack? It is ugly, but it would allow an
> application that does enough of an effort to recover the original data
> almost full, though it will not fix stream copy.
> The idea would be to just have not only one codec id, but also an array
> with additional ids.
> The application could then: try decoding and when decoding fails try the
> other decoders until it find one that works (note: breaks if the switch
> is between formats that do not cause decoding errors like rgb/bgr).
> Or it could export one video stream for each codec (with parts in the
> other codec playing as crap).
> Yes, this is a hackish solution, but I think it could be done quickly
> and is sufficient for most cases.
> A further extension to this would be that in addition to the codec_id
> array we would have another array where the application can codec ids
> for which the data should be discarded by the demuxer, this should even
> allow for mostly working stream copy.

well, why dont we work on a clean solution?

Another example for that would be:
* exporting both the combined AVStream (with NULL AVCodecContext)
  and seperate AVStreams for each stsd entry
* add a int parent_track_id to the uncombined AVStreams
  which points to the combined one or -1 for normal 1 in 1 streams

advantages:
* it doesnt break ABI, no major version bump needed
* stream copy works just fine
* discarding packets works naturally by using AVDiscard for the
  individual uncombined streams

how can the combined stream be used? like

AVStream *uncomb= s->streams[pkt->stream_index];
if(uncomb->parent_track_id>=0){
    if(!stream_copy || target==mov){
        work with AVCodecContext from uncomb
        and       AVStream            s->streams[uncomb->parent_track_id]
        instead of both from uncomb
    }
}

(yes pkt->stream_index would never match that of the combined stream,
though one could use its index for seeking)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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/20080128/f9436cd4/attachment.pgp>