>
> These two chunks look like legit resilience measure, and maybe could be
> even added to upstream ffmpeg, maybe for non-default mode.
>
Well I’ve posted it to the FFmpeg dev list for feedback, so we will see.
Non-default mode - yes maybe it needs to be optional. And/or only have an effect at the start of the capture; I am concerned that in some situation where a capture momentarily loses signal and delivers a corrupted buffer that my patch would then actually do more than an end user would require by ignoring subsequent buffers and maybe turning it into a bigger issue.
>>
>> +
>> + /* if we just encounted some corrupted buffers then we ignore the next few
>> + * legitimate buffers because they can arrive at irregular intervals, causing
>> + * the timestamps of the input and output streams to be out-of-sync and FFmpeg
>> + * to continually emit warnings. */
>> + if (s->buffers_ignore) {
>> + av_log(ctx, AV_LOG_WARNING,
>> + "Ignoring dequeued v4l2 buffer due to earlier corruption.\n");
>> + s->buffers_ignore --;
>> + enqueue_buffer(s, &buf);
>> + return FFERROR_REDO;
>> + }
>
> Not clear exactly happens here so that such workaround is needed…
>
Yes, this is the ugly bit. I had it outputting the timestamps of all the buffers received and it clearly showed that 2-3 of them are stamped closer together. It’s as if something is taking extra time to recover from whatever was causing the original problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
