Clock recovery is not possible about efp

[andersc]

Hi

EFP is a container/framing mechanism of arbitrary data. Along with any data you may attach a uint64_t value referred to in the code as PTS and another uint64_t value referred as DTS.

The PTS value is transparently decoded by the receiver the DTS value may differ max 'UINT32_MAX' since the DTS value is transported as a uint32_t as a 'diff' calculated as a distance from the PTS value.

uint64_t lPtsDtsDiff = lPts - lDts;

So if you want to embed your media (or any other data) frames with the associated PTS/DTS value just as you would by using MPEG-TS way I see no difference between the two.

Some users of EFP has however switched over to TAI. EFP is perfectly suited for transporting the associated TAI times as well since the PTS value is a transparently transported uint64_t. For those cases the media generators are sampling the TAI time at the creation of the media frame or the data event or any other event the user wants to 'time'. At the receiver side the users usually add a constant to the TAI time to cope with the delay of the underlying transport (or what created a delay).

EFP is just a 'Frame' -> fragments -> 'Frame' solution. That is transparently transporting data. How the users deal with the data when sending the data or receiving the data is outside the scope of EFP.

Hope the above explanation gave some answers to your concern.

[kierank]

PTS and DTS are not the same as PCR and can't be used for clock recovery. PTS is reordered and DTS arrives burstily because of the VBV as frames have varying sizes. A (professional) receiver needs to be able to recover the source clock which many have no relation to NTP/TAI/UTC etc. At the moment I don't see a means to do that. In MPEG-TS a receiver uses the PCR to compare to its receiver clock and can calculate the drift. Hope this makes sense. Kieran

On Fri, 3 Jun 2022, 09:26 Anders Cedronius, ***@***.***> wrote: Hi EFP is a container/framing mechanism of arbitrary data. Along with any data you may attach a uint64_t value referred to in the code as PTS and another uint64_t value referred as DTS. The PTS value is transparently decoded by the receiver the DTS value may differ max 'UINT32_MAX' since the DTS value is transported as a uint32_t as a 'diff' calculated as a distance from the PTS value. uint64_t lPtsDtsDiff = lPts - lDts; So if you want to embed your media (or any other data) frames with the associated PTS/DTS value just as you would by using MPEG-TS way I see no difference between the two. Some users of EFP has however switched over to TAI. EFP is perfectly suited for transporting the associated TAI times as well since the PTS value is a transparently transported uint64_t. For those cases the media generators are sampling the TAI time at the creation of the media frame or the data event or any other event the user wants to 'time'. At the receiver side the users usually add a constant to the TAI time to cope with the delay of the underlying transport (or what created a delay). EFP is just a 'Frame' -> fragments -> 'Frame' solution. That is transparently transporting data. How the users deal with the data when sending the data or receiving the data is outside the scope of EFP. Hope the above explanation gave some answers to your concern. — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABDEEBFLAMS2OX67L322XDVNG6SRANCNFSM5XVNVQFA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

Sent from my mobile device

[andersc]

Hi Kieran,

Makes perfect sense. I would suggest using the method ->

addEmbeddedData

For attaching PCR or any other data not natively supported by the fragment headers. That would cater for your use-case.

I'll ask the maintainer to close this issue. If you feel this is not a sufficient answer for your use-case I suggest we meet at IBC (if you are visiting) to further discuss your concern.

Talk to you later.

/Anders

[kierank]

It's weird that you want to remove the PCR which is mandatory in MPEG-TS and make it optional.