-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clock recovery is not possible #10
Comments
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.
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. |
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
|
Hi Kieran, Makes perfect sense. I would suggest using the method ->
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 |
It's weird that you want to remove the PCR which is mandatory in MPEG-TS and make it optional. |
The structure that you have to replace PCR seems to be optional so it's unclear how to do clock recovery.
Also any references in the docs to NTP/TAI (or UTC) aren't correct as the clock source comes from the thing generating the video frames (e.g an oscillator on a camera).
The text was updated successfully, but these errors were encountered: