[Ffmpeg-devel] Re: [PATCH] PKT_FLAG_B
Mon Jul 31 22:54:59 CEST 2006
On Mon, Jul 31, 2006 at 10:04:18PM +0200, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> >> [...]
> >> Basically what I would like to access the frame type explicitly for GXF
> >> muxer, and for MOV muxer, to write or not 'ctts' atom. Like I said,
> >> having access to AVCodecParser might be a good solution too.
> > hmm iam still not completely sure what you propose ...
> > but a muxer must use the timestamps given to it, if they are wrong than
> > they are, its not the muxers job to second guess them
> > if for example pts are wrong for x264 b pyramid and xvid then these
> > encoders / wrapers must be fixed, if they are wrong in the source
> > then the source should be fixed, maybe with some generic pts
> > recalculation like -genpts ...
> Well, generic pts recalculation is indeed a good solution. It is also
> actually needed when doing AVI->MOV, or raw h264->MOV. Maybe
> AVTimestampFilter, automatically activated for formats which does not
> contain pts ?
> In GXF muxer, we would still reside on the fact that pts/dts are correct
> though, to assume B frame type, a bit weird IMHO.
> Also why isn't AVCodecParser/AVBitstreamFilter linked to AVCodecContext
please elaborate on what you exactly want here
> I was thinking about automatically activating an AVBistreamFilter in
> codec was h264 in MOV muxer.
yes, this will need some changes, iam not completely sure though how to
best activate AVBistreamFilters automatically, with AVParsers its easy as
each codec has exactly one parser but with AVBistreamFilters its codec+
container which decide on a default filter and the user might want to
have further filters in the chain ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is
More information about the ffmpeg-devel