Devin Heitmueller:
> In order to properly process SCTE-35 packets, we need the original
> PTS value from the demux (i.e. not mangled by the application or
> reclocked for the output). This allows us to set the pts_adjustment
> field in an BSF on the output side.
>
> Introduce a new side data type to store the original PTS.
>
> Signed-off-by: Devin Heitmueller <dheitmuel...@ltnglobal.com>
> ---
> libavcodec/packet.h | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavcodec/packet.h b/libavcodec/packet.h
> index f28e7e7..a86a550 100644
> --- a/libavcodec/packet.h
> +++ b/libavcodec/packet.h
> @@ -300,6 +300,16 @@ enum AVPacketSideDataType {
> AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
>
> /**
> + * Provides the original PTS when passed through the demux. This can
> + * be used to offset any subsequent changes made by the caller to
> + * adjust PTS values (such as pts_offset). We need this for SCTE-35,
> + * since by the time the packets reach the output the PTS values have
> + * already been re-written, and we cannot calculate pre-roll values
> + * using the PTS values embedded in the packet content
> + */
> + AV_PKT_DATA_ORIG_PTS,
> +
> + /**
> * The number of side data types.
> * This is not part of the public API/ABI in the sense that it may
> * change when new side data types are added.
A timestamp without a timebase? Doesn't sound good to me. And it also
seems quite hacky.
Apart from that: It needs to specify that the data is a int64_t.
- Andreas
_______________________________________________
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".
