[FFmpeg-cvslog] r210, r10k and avrp encoder
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Thu Jan 26 23:08:16 CET 2012
On Thu, Jan 26, 2012 at 10:42:43PM +0100, Michael Niedermayer wrote:
> On Thu, Jan 26, 2012 at 10:10:02PM +0100, Reimar Döffinger wrote:
> > On 26 Jan 2012, at 20:01, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > On Thu, Jan 26, 2012 at 08:45:09AM +0100, Reimar Döffinger wrote:
> > >>
> > >>> + avctx->coded_frame->reference = 0;
> > >>> + avctx->coded_frame->key_frame = 1;
> > >>> + avctx->coded_frame->pict_type = AV_PICTURE_TYPE_I;
> > >>
> > >> That makes yet two more encoders for which pts is not handled correctly.
> > >
> > > why ?
> > >
> > > avctx->coded_frame = avcodec_alloc_frame();
> > > should set all the pts fields to AV_NOPTS_VALUE
> >
> > And why should the outgoing pts be AV_NOPTS_VALUE when the incoming is not?
> > And how would you distinguish the cases where the encoder just never sets pts vs. an encoder that just (possibly with reordering) passed through a AV_NOPTS_VALUE it got as input?
>
> CODEC_CAP_DELAY could be used
Could be. Excuse my inability to contain the snark, but
after a few years of using it, it might be a good idea to
decide on who the API should work...
Because with the current code in FFmpeg an encoder returning
AV_NOPTS_VALUE as far as I can tell is just as broken in the final
result as one returning 0.
> > And should codecs use alloc_frame like this or priv_data like rawenc (which seems to be the reason why it is so competely broken)?
>
> rawenc looks a bit broken yes
It seems "only" the get_frame_defaults was forgotten.
More information about the ffmpeg-cvslog
mailing list