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

From: "Clément Péron" <peron.clem@gmail.com>
To: Kieran Kunhya <kierank@obe.tv>
Cc: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC PATCH 0/3] Propagate PRFT side data
Date: Tue, 24 Oct 2023 17:10:50 +0200
Message-ID: <CAJiuCcesyXxZDA3JbcGyh2oLzvyhSUwVmMoYtzJoCJGU9bbhZA@mail.gmail.com> (raw)
In-Reply-To: <CAJiuCceafG9fFKvGPA0-D0uDZXRrEqgEeBvJoRw1nwFHztXsAw@mail.gmail.com>

Hi,

On Sun, 24 Sept 2023 at 11:12, Clément Péron <peron.clem@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@gmail.com> wrote:
> >
> > Hi Kieran,
> >
> > On Thu, 21 Sept 2023 at 15:13, Kieran Kunhya <kierank@obe.tv> wrote:
> > >
> > >  On Thu, 21 Sept 2023, 13:17 Clément Péron, <peron.clem@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
_______________________________________________
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".