[FFmpeg-devel] [PATCH 3/3] lavf/utils: add flag to fill unset timestamps from wallclock offset

[Rodger Combs]

> On Dec 10, 2017, at 05:40, Nicolas George <george at nsup.org> wrote:
> 
> Rodger Combs (2017-12-10):
>> The goal is to use this in conjunction with the previous patches in
>> the set to deal with live broadcast streams coming off a tuner. The
>> first patch sets the CORRUPT flag when the TEI bit is set in a TS
>> packet (indicating that the tuner detected uncorrectable errors), the
>> second clears the PTS and DTS in response to that flag (since a bit
>> flip that causes a too-high timestamp can throw off the whole stream,
>> since ffmpeg.c enforces monotonicity), and the third re-generates DTSs
>> by interpolating from the previous packet's receipt time.
> 
> You did not give enough details to judge, but I will try to extrapolate.
> 
> This change would be useful for an application that receives live
> broadcast streams, from a source that may be corrupted, but that uses
> wallclock timestamps, synchronized with the client application and with
> no network delay, and that cannot fiddle with timestamps itself.

Not exactly. I'm not using actual wallclock timestamps anywhere; just _offsets_ of timestamps.
My application uses ffmpeg.c to record OTA and cable broadcasts (which may have corruption) to segments on-disk, which are later either concatenated, or streamed to client devices, or both. In either case, it's preferable to have timestamps be approximately correct in the event of corruption (as this patch produces), rather than entirely absent, or approximated from frame rate (which would produce incorrect values if frames were missing). I think the "remux a broadcast stream to disk" use-case is fairly common.

> 
> It seems awfully specific. Too specific for a change in the core
> workings of the library.
> 
>> In my target use-case
> 
> Stop. We are not speaking of your target use case, we are speaking of a
> change in the core components of the library. It should be designed to
> be useful for more than your own use case.

As described above, I think the use-case I'm referring to is fairly common and worth supporting.

> 
> Regards,
> 
> -- 
>  Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel