GStreamer-devel

tsmux produces timestamps with ~1hr offset

classic Classic list List threaded Threaded
♦
♦
 3 messages Options
Krzysztof Konopko
Reply | Threaded
Open this post in threaded view
♦
♦
|

tsmux produces timestamps with ~1hr offset

Krzysztof Konopko
Hi,

The following will produce a test TS stream:

gst-launch \
  videotestsrc num-buffers=10 \
  ! mpeg2enc ! mpegtsmux \
  ! filesink location=test.ts

Now if I inspect produced TS packets with dvbsnoop [1], I can see that
the first TS packet has a ~1hr offset:

dvbsnoop -s ts -tssubdecode -if test.ts | grep -i time | less

==> program_clock_reference: 97196625000 (0x16a15ecc68)  [=
PCR-Timestamp: 0:59:59.875000]
 ==> PTS: 324000000 (0x134fd900)  [= 90 kHz-Timestamp: 1:00:00.0000]
time_code:
 time_code_hours: 0 (0x00)
 time_code_minutes: 0 (0x00)
 time_code_seconds: 0 (0x00)
 time_code_pictures: 0 (0x00)
   ==> PTS: 324002999 (0x134fe4b7)  [= 90 kHz-Timestamp: 1:00:00.0333]
==> program_clock_reference: 97198424700 (0x16a17a427c)  [=
PCR-Timestamp: 0:59:59.941655]
   ==> PTS: 324005999 (0x134ff06f)  [= 90 kHz-Timestamp: 1:00:00.0666]
   ==> PTS: 324009000 (0x134ffc28)  [= 90 kHz-Timestamp: 1:00:00.1000]
==> program_clock_reference: 97200224700 (0x16a195b9bc)  [=
PCR-Timestamp: 1:00:00.008322]
   ==> PTS: 324011999 (0x135007df)  [= 90 kHz-Timestamp: 1:00:00.1333]
   ==> PTS: 324014999 (0x13501397)  [= 90 kHz-Timestamp: 1:00:00.1666]
==> program_clock_reference: 97202025000 (0x16a1b13228)  [=
PCR-Timestamp: 1:00:00.075000]
   ==> PTS: 324018000 (0x13501f50)  [= 90 kHz-Timestamp: 1:00:00.2000]
   ==> PTS: 324020999 (0x13502b07)  [= 90 kHz-Timestamp: 1:00:00.2333]
==> program_clock_reference: 97203824700 (0x16a1cca83c)  [=
PCR-Timestamp: 1:00:00.141655]
   ==> PTS: 324023999 (0x135036bf)  [= 90 kHz-Timestamp: 1:00:00.2666]
   ==> PTS: 324027000 (0x13504278)  [= 90 kHz-Timestamp: 1:00:00.3000]


It looks like the following code is responsible for that
(tsmux_write_stream_packet()):

    /* FIXME: The current PCR needs more careful calculation than just
     * writing a fixed offset */
    if (cur_pts != -1) {
      /* CLOCK_BASE >= TSMUX_PCR_OFFSET */
      cur_pts += CLOCK_BASE;
      cur_pcr = (cur_pts - TSMUX_PCR_OFFSET) *
          (TSMUX_SYS_CLOCK_FREQ / TSMUX_CLOCK_FREQ);
    }

Gstreamer-0.10.x produces TS packets without the offset so it looks like
a regression. Is there any bug reported? Or maybe there's some
explanation of this situation? Or maybe it doesn't matter at all in
practice?

[1] http://dvbsnoop.sourceforge.net

Cheers,
Kris
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Edward Hervey
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: tsmux produces timestamps with ~1hr offset

Edward Hervey
Administrator
Hi,

  Those are PCR values. They are allowed to be any value whatsoever, and
are not considered as *timestamps* but as references.

  Your "local playback timestamp" will be the difference between the PTS
of the stream and the current PCR.
  In this case, the first PCR is 1hour, and the first video PTS is 1hour
also, therefore you do have a "local playback timestamp" of 0s (plays
straight away).

  Your reader application should be able to support this (else it will
not be able to read 99.9999999% of the mpeg-ts files out there).

    Edward

On Tue, 2012-11-13 at 10:06 +0000, Krzysztof Konopko wrote:

> Hi,
>
> The following will produce a test TS stream:
>
> gst-launch \
>   videotestsrc num-buffers=10 \
>   ! mpeg2enc ! mpegtsmux \
>   ! filesink location=test.ts
>
> Now if I inspect produced TS packets with dvbsnoop [1], I can see that
> the first TS packet has a ~1hr offset:
>
> dvbsnoop -s ts -tssubdecode -if test.ts | grep -i time | less
>
> ==> program_clock_reference: 97196625000 (0x16a15ecc68)  [=
> PCR-Timestamp: 0:59:59.875000]
>  ==> PTS: 324000000 (0x134fd900)  [= 90 kHz-Timestamp: 1:00:00.0000]
> time_code:
>  time_code_hours: 0 (0x00)
>  time_code_minutes: 0 (0x00)
>  time_code_seconds: 0 (0x00)
>  time_code_pictures: 0 (0x00)
>    ==> PTS: 324002999 (0x134fe4b7)  [= 90 kHz-Timestamp: 1:00:00.0333]
> ==> program_clock_reference: 97198424700 (0x16a17a427c)  [=
> PCR-Timestamp: 0:59:59.941655]
>    ==> PTS: 324005999 (0x134ff06f)  [= 90 kHz-Timestamp: 1:00:00.0666]
>    ==> PTS: 324009000 (0x134ffc28)  [= 90 kHz-Timestamp: 1:00:00.1000]
> ==> program_clock_reference: 97200224700 (0x16a195b9bc)  [=
> PCR-Timestamp: 1:00:00.008322]
>    ==> PTS: 324011999 (0x135007df)  [= 90 kHz-Timestamp: 1:00:00.1333]
>    ==> PTS: 324014999 (0x13501397)  [= 90 kHz-Timestamp: 1:00:00.1666]
> ==> program_clock_reference: 97202025000 (0x16a1b13228)  [=
> PCR-Timestamp: 1:00:00.075000]
>    ==> PTS: 324018000 (0x13501f50)  [= 90 kHz-Timestamp: 1:00:00.2000]
>    ==> PTS: 324020999 (0x13502b07)  [= 90 kHz-Timestamp: 1:00:00.2333]
> ==> program_clock_reference: 97203824700 (0x16a1cca83c)  [=
> PCR-Timestamp: 1:00:00.141655]
>    ==> PTS: 324023999 (0x135036bf)  [= 90 kHz-Timestamp: 1:00:00.2666]
>    ==> PTS: 324027000 (0x13504278)  [= 90 kHz-Timestamp: 1:00:00.3000]
>
>
> It looks like the following code is responsible for that
> (tsmux_write_stream_packet()):
>
>     /* FIXME: The current PCR needs more careful calculation than just
>      * writing a fixed offset */
>     if (cur_pts != -1) {
>       /* CLOCK_BASE >= TSMUX_PCR_OFFSET */
>       cur_pts += CLOCK_BASE;
>       cur_pcr = (cur_pts - TSMUX_PCR_OFFSET) *
>           (TSMUX_SYS_CLOCK_FREQ / TSMUX_CLOCK_FREQ);
>     }
>
> Gstreamer-0.10.x produces TS packets without the offset so it looks like
> a regression. Is there any bug reported? Or maybe there's some
> explanation of this situation? Or maybe it doesn't matter at all in
> practice?
>
> [1] http://dvbsnoop.sourceforge.net
>
> Cheers,
> Kris
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Krzysztof Konopko
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: tsmux produces timestamps with ~1hr offset

Krzysztof Konopko
Thanks, that explains a lot.

Cheers,
Kris

On 13/11/12 11:36, Edward Hervey wrote:

> Hi,
>
>   Those are PCR values. They are allowed to be any value whatsoever, and
> are not considered as *timestamps* but as references.
>
>   Your "local playback timestamp" will be the difference between the PTS
> of the stream and the current PCR.
>   In this case, the first PCR is 1hour, and the first video PTS is 1hour
> also, therefore you do have a "local playback timestamp" of 0s (plays
> straight away).
>
>   Your reader application should be able to support this (else it will
> not be able to read 99.9999999% of the mpeg-ts files out there).
>
>     Edward
>
> On Tue, 2012-11-13 at 10:06 +0000, Krzysztof Konopko wrote:
>> Hi,
>>
>> The following will produce a test TS stream:
>>
>> gst-launch \
>>   videotestsrc num-buffers=10 \
>>   ! mpeg2enc ! mpegtsmux \
>>   ! filesink location=test.ts
>>
>> Now if I inspect produced TS packets with dvbsnoop [1], I can see that
>> the first TS packet has a ~1hr offset:
>>
>> dvbsnoop -s ts -tssubdecode -if test.ts | grep -i time | less
>>
>> ==> program_clock_reference: 97196625000 (0x16a15ecc68)  [=
>> PCR-Timestamp: 0:59:59.875000]
>>  ==> PTS: 324000000 (0x134fd900)  [= 90 kHz-Timestamp: 1:00:00.0000]
>> time_code:
>>  time_code_hours: 0 (0x00)
>>  time_code_minutes: 0 (0x00)
>>  time_code_seconds: 0 (0x00)
>>  time_code_pictures: 0 (0x00)
>>    ==> PTS: 324002999 (0x134fe4b7)  [= 90 kHz-Timestamp: 1:00:00.0333]
>> ==> program_clock_reference: 97198424700 (0x16a17a427c)  [=
>> PCR-Timestamp: 0:59:59.941655]
>>    ==> PTS: 324005999 (0x134ff06f)  [= 90 kHz-Timestamp: 1:00:00.0666]
>>    ==> PTS: 324009000 (0x134ffc28)  [= 90 kHz-Timestamp: 1:00:00.1000]
>> ==> program_clock_reference: 97200224700 (0x16a195b9bc)  [=
>> PCR-Timestamp: 1:00:00.008322]
>>    ==> PTS: 324011999 (0x135007df)  [= 90 kHz-Timestamp: 1:00:00.1333]
>>    ==> PTS: 324014999 (0x13501397)  [= 90 kHz-Timestamp: 1:00:00.1666]
>> ==> program_clock_reference: 97202025000 (0x16a1b13228)  [=
>> PCR-Timestamp: 1:00:00.075000]
>>    ==> PTS: 324018000 (0x13501f50)  [= 90 kHz-Timestamp: 1:00:00.2000]
>>    ==> PTS: 324020999 (0x13502b07)  [= 90 kHz-Timestamp: 1:00:00.2333]
>> ==> program_clock_reference: 97203824700 (0x16a1cca83c)  [=
>> PCR-Timestamp: 1:00:00.141655]
>>    ==> PTS: 324023999 (0x135036bf)  [= 90 kHz-Timestamp: 1:00:00.2666]
>>    ==> PTS: 324027000 (0x13504278)  [= 90 kHz-Timestamp: 1:00:00.3000]
>>
>>
>> It looks like the following code is responsible for that
>> (tsmux_write_stream_packet()):
>>
>>     /* FIXME: The current PCR needs more careful calculation than just
>>      * writing a fixed offset */
>>     if (cur_pts != -1) {
>>       /* CLOCK_BASE >= TSMUX_PCR_OFFSET */
>>       cur_pts += CLOCK_BASE;
>>       cur_pcr = (cur_pts - TSMUX_PCR_OFFSET) *
>>           (TSMUX_SYS_CLOCK_FREQ / TSMUX_CLOCK_FREQ);
>>     }
>>
>> Gstreamer-0.10.x produces TS packets without the offset so it looks like
>> a regression. Is there any bug reported? Or maybe there's some
>> explanation of this situation? Or maybe it doesn't matter at all in
>> practice?
>>
>> [1] http://dvbsnoop.sourceforge.net
>>
>> Cheers,
>> Kris
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Free forum by Nabble Edit this page