[FFmpeg-devel] [RFC PATCH 0/3] Propagate PRFT side data

[Clément Péron]

Hi,

On Sun, 24 Sept 2023 at 11:12, Clément Péron <peron.clem at gmail.com> wrote:
>
> Hi,
>
> I plan to resent this series without the latest patch.
>
> Regarding Patch 1 and 2 do you have any comment?
>
> One thing is that unlike the decode.c which has a common
> ff_decode_frame_props_from_pkt() there is no such thing for the encode
> part. Or maybe I missed it ?
>
> I noticed that the propagation of this data doesn't work when I enable
> the hardware Nvidia encoder.
>
> Does it make sense to introduce a ff_encode_packet_props_from_frame()?

So I investigate this and understand that the cuvid packet has its own
format and it's not capable of forwarding metadata.

So I'm not sure I'm going in the right direction by forwarding the
PRFT all along FFMpeg.

Does it make sense to have the PTS to be an absolute timestamp?

If I look at the RTPdec it seems that everybody expects the ts to be relative.

https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/rtpdec.c#L669-L694

Thanks,



>
> Thanks,
>
>
> On Thu, 21 Sept 2023 at 17:41, Clément Péron <peron.clem at gmail.com> wrote:
> >
> > Hi Kieran,
> >
> > On Thu, 21 Sept 2023 at 15:13, Kieran Kunhya <kierank at obe.tv> wrote:
> > >
> > >  On Thu, 21 Sept 2023, 13:17 Clément Péron, <peron.clem at gmail.com> wrote:
> > >>
> > >> 4I have a project where I need to synchronize multiple RTSP cameras with other
> > >> network sensors (sync with NTP or PTP).
> > >
> > >
> > > Just be aware the clock of the vast majority of cameras have no relation to NTP or PTP so you will have drift and need to handle that (e.g by dropping or duplicating frames).
> >
> > Thanks for pointing this out, and yes I consider each of my sensors
> > running on a free clock and I recreate a "virtual frame" that is not
> > correlated to the FPS of each sensor.
> >
> > Thanks,
> > Clement
> >
> > >
> > > Kieran