[FFmpeg-cvslog] r11638 - in trunk: libavcodec/avcodec.h libavformat/isom.c libavformat/mov.c

Michael Niedermayer michaelni
Mon Jan 28 01:21:08 CET 2008


On Sun, Jan 27, 2008 at 11:50:57PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Sun, Jan 27, 2008 at 08:48:09PM +0000, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
> >> 
> >> > Hello,
> >> > On Sun, Jan 27, 2008 at 09:13:19PM +0100, Michael Niedermayer wrote:
> >> >> On Sun, Jan 27, 2008 at 08:57:04PM +0100, reimar wrote:
> >> >> > Author: reimar
> >> >> > Date: Sun Jan 27 20:57:04 2008
> >> >> > New Revision: 11638
> >> >> > 
> >> >> > Log:
> >> >> > Add CODEC_ID_MOV_TEXT and use it instead of modifying the stream in the mov demuxer.
> >> >> [...]
> >> >> > Modified: trunk/libavformat/mov.c
> >> >> > ==============================================================================
> >> >> > --- trunk/libavformat/mov.c	(original)
> >> >> > +++ trunk/libavformat/mov.c	Sun Jan 27 20:57:04 2008
> >> >> > @@ -1543,12 +1543,6 @@ static int mov_read_packet(AVFormatConte
> >> >> >      } else {
> >> >> >  #endif
> >> >> >          av_get_packet(s->pb, pkt, sample->size);
> >> >> > -        if (s->streams[sc->ffindex]->codec->codec_id == CODEC_ID_TEXT) {
> >> >> > -            int textlen = FFMIN(AV_RB16(pkt->data), sample->size - 2);
> >> >> > -            textlen = FFMAX(textlen, 0);
> >> >> > -            memmove(pkt->data, pkt->data + 2, textlen);
> >> >> > -            pkt->size = textlen;
> >> >> > -        }
> >> >> 
> >> >> 
> >> >> btw, a bitstream filter doing above would be welcome
> >> >
> >> > Hm.. is a bitstream filter though the best way to do this? I do not
> >> > really like that there is basically only the name for these filters, no
> >> > way to give incoming/outgoing codec id etc, which means every
> >> > application must code explicit support for this kind of thing...
> >> 
> >> What exactly distinguishes a bitstream filter from a codec anyway?
> >
> > compressed frames --- decoder ---> raw video / audio
> >                  <--- encoder ---
> >
> > compressed frames --- bitstream filter ---> compressed frames
> 
> I fail to see a fundamental difference there.  Both convert between
> different formats.  You choose to call anything with uncompressed data
> on one end a codec and everything else a filter.
> 
> > we could also rewrite ffmpeg in java and make everything an object
> > then build a generic Filter and have codec, muxer, parser, bitstream filter
> > video filter, ... be subclasses of that ;)
> 
> No need to use java for that.  I'm doing something along those lines
> in tcvp, and it's working pretty well.  In brief, a demuxer produces
> packets that are passed through a series of filters, typically ending
> at a muxer or output device.

iam not against simplifying things
if you can suggest an API in which codec, parser and bitstream filters
would use the same API that would be great. Though no features must be
lost (direct rendering, slices, zero memcpy where its currently possible)

Of course some volunteer to implement it would be needed as well ...
Iam just saying that iam in favor for a common API if its possible.
When i implemented the bitstream filters i was alraedy quite unhappy
that they didnt fit into any existing API ...

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- 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/b1d83319/attachment.pgp>



More information about the ffmpeg-cvslog mailing list