[FFmpeg-cvslog] r210, r10k and avrp encoder

[Reimar Döffinger]

On 26 Jan 2012, at 23:47, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Thu, Jan 26, 2012 at 11:08:16PM +0100, Reimar Döffinger wrote:
>> 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.
> 
> So to summarize, the API is inadequately documented and ffmpeg is
> containing a bug.
> 
> The question is are you volunteering to fix these or should i do it?

I have a patch for FFmpeg and rawenc, the problem is
a) whether it is the best thing to do
b) the many H.264 test failures (which are also visible with my previous hacks in exactly the same way)