On 8/23/20, Nicolas George <geo...@nsup.org> wrote:
> Michael Niedermayer (12020-08-23):
>> > + if (buf->pts == AV_NOPTS_VALUE) {
>> > + av_log(ctx, AV_LOG_ERROR, "Frame without timestamp on input
>> > %d\n", in_no);
>> > + return AVERROR(EINVAL);
>> > + }
>>
>> what if the timestamp is "AV_NOPTS_VALUE + 1" ?
>> would that work or overflow ?
>
> I have no idea, I suspect it would overflow too. But "every single
> filter that needs valid timestamps" is not the place to protect against
> overflows caused by widely invalid timestamps. The framework is; I have
> considered going at it, some kind of "require_valid_pts" flag on input
> pads, but it is not my priority right now.
What is valid timestamp?
Filter currently crashes because it receives nopts timestamps.
Why it crashes at all?
Does it crash because it access out of range of allocated memory?
If yes, make sure this patch is real fix and not just band-aid.
>
> This test is already too much, it should be part of the framework, but
> it is very simple and protects against a real current bug.
>
>> also could the filter not use the previous frame pts + "duration" when a
>> PTS
>> is unavailable (maybe that would make sense in some cases) (with a
>> warning)
>
> Not really.
>
> First, again, an individual filter is not the place to implement an
> heuristic.
>
> Second, duration is not part of lavfi's working at all, and could not be
> without a significant redesign of many filters, and increasing the
> latency.
>
> Regards,
>
> --
> Nicolas George
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
