How to generate timestamps from the 33-bit PCR count












0














So I have been trying to wrap my head around mpeg-ts timing, and the PCR (program clock reference). I understand that this is used for video/audio synchronisation at the decoder.



My basic understanding so far is that everything is driven by a 27 Mhz clock (oscillator). This clock loops at a rate of 27 Mhz, counting from 0 - 299 and keeps repeating itself. Each time this "rollover" from 299 back to 0 occurs, then a 33-bit PCR counter is incremented by 1. In effect, the 33-bit PCR counter is therefore itself running at a rate of 90 kHz. So another way of saying this is that the 27 Mhz clock is divided by 300, giving us a 90 kHz clock.



This 90 kHz clock is then used for the 33-bit PCR counter.



I understand that historically 90 kHz was chosen because mpeg-1 used a 90kHz timebase. [see source here]



Anyway... I have read that the PCR 33-bit count values range from 0x000000000 all the way through to 0x1FFFFFFFF. And according to this, it shows what these values mean in terms of time as we humans understand it (Hours, Mins, Secs, etc):
00:00:00.000 (0x000000000)
to
26:30:43.717 (0x1FFFFFFFF)



So ultimately, my question is relating to how do these hex codes get translated into those time stamps. What would the equations be if someone gave me a hex code, and now I need to reproduce the time stamp?



I would appreciate any help :)



==========



I am closer to an answer myself. Looking at the range from 0x000000000 to 0x1FFFFFFFF, this is basically 0 to 8589934591 in binary. Since the PCR clock is 90Khz, to get the number of seconds it takes to go from 0 to 8589934591 we can do 8589934591/90000 which gives us 95443.71768 seconds.










share|improve this question
























  • It’s not a “hex code” it’s just a number. You are choosing to represent it in bace 16. You can type it as a decimal as well.
    – szatmary
    Nov 21 '18 at 16:55
















0














So I have been trying to wrap my head around mpeg-ts timing, and the PCR (program clock reference). I understand that this is used for video/audio synchronisation at the decoder.



My basic understanding so far is that everything is driven by a 27 Mhz clock (oscillator). This clock loops at a rate of 27 Mhz, counting from 0 - 299 and keeps repeating itself. Each time this "rollover" from 299 back to 0 occurs, then a 33-bit PCR counter is incremented by 1. In effect, the 33-bit PCR counter is therefore itself running at a rate of 90 kHz. So another way of saying this is that the 27 Mhz clock is divided by 300, giving us a 90 kHz clock.



This 90 kHz clock is then used for the 33-bit PCR counter.



I understand that historically 90 kHz was chosen because mpeg-1 used a 90kHz timebase. [see source here]



Anyway... I have read that the PCR 33-bit count values range from 0x000000000 all the way through to 0x1FFFFFFFF. And according to this, it shows what these values mean in terms of time as we humans understand it (Hours, Mins, Secs, etc):
00:00:00.000 (0x000000000)
to
26:30:43.717 (0x1FFFFFFFF)



So ultimately, my question is relating to how do these hex codes get translated into those time stamps. What would the equations be if someone gave me a hex code, and now I need to reproduce the time stamp?



I would appreciate any help :)



==========



I am closer to an answer myself. Looking at the range from 0x000000000 to 0x1FFFFFFFF, this is basically 0 to 8589934591 in binary. Since the PCR clock is 90Khz, to get the number of seconds it takes to go from 0 to 8589934591 we can do 8589934591/90000 which gives us 95443.71768 seconds.










share|improve this question
























  • It’s not a “hex code” it’s just a number. You are choosing to represent it in bace 16. You can type it as a decimal as well.
    – szatmary
    Nov 21 '18 at 16:55














0












0








0


0





So I have been trying to wrap my head around mpeg-ts timing, and the PCR (program clock reference). I understand that this is used for video/audio synchronisation at the decoder.



My basic understanding so far is that everything is driven by a 27 Mhz clock (oscillator). This clock loops at a rate of 27 Mhz, counting from 0 - 299 and keeps repeating itself. Each time this "rollover" from 299 back to 0 occurs, then a 33-bit PCR counter is incremented by 1. In effect, the 33-bit PCR counter is therefore itself running at a rate of 90 kHz. So another way of saying this is that the 27 Mhz clock is divided by 300, giving us a 90 kHz clock.



This 90 kHz clock is then used for the 33-bit PCR counter.



I understand that historically 90 kHz was chosen because mpeg-1 used a 90kHz timebase. [see source here]



Anyway... I have read that the PCR 33-bit count values range from 0x000000000 all the way through to 0x1FFFFFFFF. And according to this, it shows what these values mean in terms of time as we humans understand it (Hours, Mins, Secs, etc):
00:00:00.000 (0x000000000)
to
26:30:43.717 (0x1FFFFFFFF)



So ultimately, my question is relating to how do these hex codes get translated into those time stamps. What would the equations be if someone gave me a hex code, and now I need to reproduce the time stamp?



I would appreciate any help :)



==========



I am closer to an answer myself. Looking at the range from 0x000000000 to 0x1FFFFFFFF, this is basically 0 to 8589934591 in binary. Since the PCR clock is 90Khz, to get the number of seconds it takes to go from 0 to 8589934591 we can do 8589934591/90000 which gives us 95443.71768 seconds.










share|improve this question















So I have been trying to wrap my head around mpeg-ts timing, and the PCR (program clock reference). I understand that this is used for video/audio synchronisation at the decoder.



My basic understanding so far is that everything is driven by a 27 Mhz clock (oscillator). This clock loops at a rate of 27 Mhz, counting from 0 - 299 and keeps repeating itself. Each time this "rollover" from 299 back to 0 occurs, then a 33-bit PCR counter is incremented by 1. In effect, the 33-bit PCR counter is therefore itself running at a rate of 90 kHz. So another way of saying this is that the 27 Mhz clock is divided by 300, giving us a 90 kHz clock.



This 90 kHz clock is then used for the 33-bit PCR counter.



I understand that historically 90 kHz was chosen because mpeg-1 used a 90kHz timebase. [see source here]



Anyway... I have read that the PCR 33-bit count values range from 0x000000000 all the way through to 0x1FFFFFFFF. And according to this, it shows what these values mean in terms of time as we humans understand it (Hours, Mins, Secs, etc):
00:00:00.000 (0x000000000)
to
26:30:43.717 (0x1FFFFFFFF)



So ultimately, my question is relating to how do these hex codes get translated into those time stamps. What would the equations be if someone gave me a hex code, and now I need to reproduce the time stamp?



I would appreciate any help :)



==========



I am closer to an answer myself. Looking at the range from 0x000000000 to 0x1FFFFFFFF, this is basically 0 to 8589934591 in binary. Since the PCR clock is 90Khz, to get the number of seconds it takes to go from 0 to 8589934591 we can do 8589934591/90000 which gives us 95443.71768 seconds.







mpeg2-ts






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 21 '18 at 11:45

























asked Nov 20 '18 at 21:34









Baba.S

529




529












  • It’s not a “hex code” it’s just a number. You are choosing to represent it in bace 16. You can type it as a decimal as well.
    – szatmary
    Nov 21 '18 at 16:55


















  • It’s not a “hex code” it’s just a number. You are choosing to represent it in bace 16. You can type it as a decimal as well.
    – szatmary
    Nov 21 '18 at 16:55
















It’s not a “hex code” it’s just a number. You are choosing to represent it in bace 16. You can type it as a decimal as well.
– szatmary
Nov 21 '18 at 16:55




It’s not a “hex code” it’s just a number. You are choosing to represent it in bace 16. You can type it as a decimal as well.
– szatmary
Nov 21 '18 at 16:55












1 Answer
1






active

oldest

votes


















0














Unless you are creating a strict bitrate encoder for broadcast over satellite or terrestrial radio, the PCR doesn't matter that much.



Scenario:
You are broadcasting to a wireless receiver with no return channel, The receiver has a cock running at what it thinks is 90000 ticks per second. Your encoder is also running at 90000 tickets per second. How can you be sure the receiver and the broadcaster have the EXACT same definition of a second? Maybe one side is running a little fast or slow. To keep the clocks in sync, the encoder sends the current time occasionally, This value is the PCR. For example, if you are broadcasting at 15,040,000 bits per second, the receiver receives a 188 byte packet every 0.0000125 seconds. Every now and then (100 ms) the encoder will insert its current time. The receiver can compare this time to its internal clock and determine if is running faster or slower than the broadcast encoder. To keep the strict 235,000 packets per second (15,040,000/(188*8) = 235,000) the encoder will insert null packets. On the internet, the null packets take bandwidth, and have no value, so they are eliminated. Hence the PCR has almost no value anymore because its time is no longer relative the the reception rate.



To answer your question. Set the 27hz value to zero, use a recent dts minus a small static amount (like 100ms), for the 90khz value.






share|improve this answer





















  • Thanks, lots of useful information there! I guess what I want to find out is 1) What do those hex codes mean?and 2) How does that help the PTS and DTS get generated. e.g a PTS of 00:00:00:2600 (Hour:Min:Sec)... How does it get to this format from the hex format?
    – Baba.S
    Nov 21 '18 at 9:19










  • The hex means nothing. It is just the minimum and maximum values of a 33bit integer.
    – szatmary
    Nov 21 '18 at 16:51










  • To convert to seconds, divide the timestamp by the timebase 90000 in this case.
    – szatmary
    Nov 21 '18 at 16:52











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53401917%2fhow-to-generate-timestamps-from-the-33-bit-pcr-count%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














Unless you are creating a strict bitrate encoder for broadcast over satellite or terrestrial radio, the PCR doesn't matter that much.



Scenario:
You are broadcasting to a wireless receiver with no return channel, The receiver has a cock running at what it thinks is 90000 ticks per second. Your encoder is also running at 90000 tickets per second. How can you be sure the receiver and the broadcaster have the EXACT same definition of a second? Maybe one side is running a little fast or slow. To keep the clocks in sync, the encoder sends the current time occasionally, This value is the PCR. For example, if you are broadcasting at 15,040,000 bits per second, the receiver receives a 188 byte packet every 0.0000125 seconds. Every now and then (100 ms) the encoder will insert its current time. The receiver can compare this time to its internal clock and determine if is running faster or slower than the broadcast encoder. To keep the strict 235,000 packets per second (15,040,000/(188*8) = 235,000) the encoder will insert null packets. On the internet, the null packets take bandwidth, and have no value, so they are eliminated. Hence the PCR has almost no value anymore because its time is no longer relative the the reception rate.



To answer your question. Set the 27hz value to zero, use a recent dts minus a small static amount (like 100ms), for the 90khz value.






share|improve this answer





















  • Thanks, lots of useful information there! I guess what I want to find out is 1) What do those hex codes mean?and 2) How does that help the PTS and DTS get generated. e.g a PTS of 00:00:00:2600 (Hour:Min:Sec)... How does it get to this format from the hex format?
    – Baba.S
    Nov 21 '18 at 9:19










  • The hex means nothing. It is just the minimum and maximum values of a 33bit integer.
    – szatmary
    Nov 21 '18 at 16:51










  • To convert to seconds, divide the timestamp by the timebase 90000 in this case.
    – szatmary
    Nov 21 '18 at 16:52
















0














Unless you are creating a strict bitrate encoder for broadcast over satellite or terrestrial radio, the PCR doesn't matter that much.



Scenario:
You are broadcasting to a wireless receiver with no return channel, The receiver has a cock running at what it thinks is 90000 ticks per second. Your encoder is also running at 90000 tickets per second. How can you be sure the receiver and the broadcaster have the EXACT same definition of a second? Maybe one side is running a little fast or slow. To keep the clocks in sync, the encoder sends the current time occasionally, This value is the PCR. For example, if you are broadcasting at 15,040,000 bits per second, the receiver receives a 188 byte packet every 0.0000125 seconds. Every now and then (100 ms) the encoder will insert its current time. The receiver can compare this time to its internal clock and determine if is running faster or slower than the broadcast encoder. To keep the strict 235,000 packets per second (15,040,000/(188*8) = 235,000) the encoder will insert null packets. On the internet, the null packets take bandwidth, and have no value, so they are eliminated. Hence the PCR has almost no value anymore because its time is no longer relative the the reception rate.



To answer your question. Set the 27hz value to zero, use a recent dts minus a small static amount (like 100ms), for the 90khz value.






share|improve this answer





















  • Thanks, lots of useful information there! I guess what I want to find out is 1) What do those hex codes mean?and 2) How does that help the PTS and DTS get generated. e.g a PTS of 00:00:00:2600 (Hour:Min:Sec)... How does it get to this format from the hex format?
    – Baba.S
    Nov 21 '18 at 9:19










  • The hex means nothing. It is just the minimum and maximum values of a 33bit integer.
    – szatmary
    Nov 21 '18 at 16:51










  • To convert to seconds, divide the timestamp by the timebase 90000 in this case.
    – szatmary
    Nov 21 '18 at 16:52














0












0








0






Unless you are creating a strict bitrate encoder for broadcast over satellite or terrestrial radio, the PCR doesn't matter that much.



Scenario:
You are broadcasting to a wireless receiver with no return channel, The receiver has a cock running at what it thinks is 90000 ticks per second. Your encoder is also running at 90000 tickets per second. How can you be sure the receiver and the broadcaster have the EXACT same definition of a second? Maybe one side is running a little fast or slow. To keep the clocks in sync, the encoder sends the current time occasionally, This value is the PCR. For example, if you are broadcasting at 15,040,000 bits per second, the receiver receives a 188 byte packet every 0.0000125 seconds. Every now and then (100 ms) the encoder will insert its current time. The receiver can compare this time to its internal clock and determine if is running faster or slower than the broadcast encoder. To keep the strict 235,000 packets per second (15,040,000/(188*8) = 235,000) the encoder will insert null packets. On the internet, the null packets take bandwidth, and have no value, so they are eliminated. Hence the PCR has almost no value anymore because its time is no longer relative the the reception rate.



To answer your question. Set the 27hz value to zero, use a recent dts minus a small static amount (like 100ms), for the 90khz value.






share|improve this answer












Unless you are creating a strict bitrate encoder for broadcast over satellite or terrestrial radio, the PCR doesn't matter that much.



Scenario:
You are broadcasting to a wireless receiver with no return channel, The receiver has a cock running at what it thinks is 90000 ticks per second. Your encoder is also running at 90000 tickets per second. How can you be sure the receiver and the broadcaster have the EXACT same definition of a second? Maybe one side is running a little fast or slow. To keep the clocks in sync, the encoder sends the current time occasionally, This value is the PCR. For example, if you are broadcasting at 15,040,000 bits per second, the receiver receives a 188 byte packet every 0.0000125 seconds. Every now and then (100 ms) the encoder will insert its current time. The receiver can compare this time to its internal clock and determine if is running faster or slower than the broadcast encoder. To keep the strict 235,000 packets per second (15,040,000/(188*8) = 235,000) the encoder will insert null packets. On the internet, the null packets take bandwidth, and have no value, so they are eliminated. Hence the PCR has almost no value anymore because its time is no longer relative the the reception rate.



To answer your question. Set the 27hz value to zero, use a recent dts minus a small static amount (like 100ms), for the 90khz value.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 20 '18 at 22:45









szatmary

17.7k62940




17.7k62940












  • Thanks, lots of useful information there! I guess what I want to find out is 1) What do those hex codes mean?and 2) How does that help the PTS and DTS get generated. e.g a PTS of 00:00:00:2600 (Hour:Min:Sec)... How does it get to this format from the hex format?
    – Baba.S
    Nov 21 '18 at 9:19










  • The hex means nothing. It is just the minimum and maximum values of a 33bit integer.
    – szatmary
    Nov 21 '18 at 16:51










  • To convert to seconds, divide the timestamp by the timebase 90000 in this case.
    – szatmary
    Nov 21 '18 at 16:52


















  • Thanks, lots of useful information there! I guess what I want to find out is 1) What do those hex codes mean?and 2) How does that help the PTS and DTS get generated. e.g a PTS of 00:00:00:2600 (Hour:Min:Sec)... How does it get to this format from the hex format?
    – Baba.S
    Nov 21 '18 at 9:19










  • The hex means nothing. It is just the minimum and maximum values of a 33bit integer.
    – szatmary
    Nov 21 '18 at 16:51










  • To convert to seconds, divide the timestamp by the timebase 90000 in this case.
    – szatmary
    Nov 21 '18 at 16:52
















Thanks, lots of useful information there! I guess what I want to find out is 1) What do those hex codes mean?and 2) How does that help the PTS and DTS get generated. e.g a PTS of 00:00:00:2600 (Hour:Min:Sec)... How does it get to this format from the hex format?
– Baba.S
Nov 21 '18 at 9:19




Thanks, lots of useful information there! I guess what I want to find out is 1) What do those hex codes mean?and 2) How does that help the PTS and DTS get generated. e.g a PTS of 00:00:00:2600 (Hour:Min:Sec)... How does it get to this format from the hex format?
– Baba.S
Nov 21 '18 at 9:19












The hex means nothing. It is just the minimum and maximum values of a 33bit integer.
– szatmary
Nov 21 '18 at 16:51




The hex means nothing. It is just the minimum and maximum values of a 33bit integer.
– szatmary
Nov 21 '18 at 16:51












To convert to seconds, divide the timestamp by the timebase 90000 in this case.
– szatmary
Nov 21 '18 at 16:52




To convert to seconds, divide the timestamp by the timebase 90000 in this case.
– szatmary
Nov 21 '18 at 16:52


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53401917%2fhow-to-generate-timestamps-from-the-33-bit-pcr-count%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Create new schema in PostgreSQL using DBeaver

Deepest pit of an array with Javascript: test on Codility

Costa Masnaga