Re: [FFmpeg-devel] [PATCH 1/5] avcodec: Add new side data type to contain original PTS value

[Andreas Rheinhardt <andreas.rheinhardt@outlook.com>]

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 <dheitmueller@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-request@ffmpeg.org with subject "unsubscribe".