[Bug 655804] Play position advancing but frames not rendered
bugzilla at gnome.org
Wed Aug 31 03:45:15 PDT 2011
GStreamer | gstreamer (core) | 0.10.34
--- Comment #11 from Simon Farnsworth <simon.farnsworth at onelan.co.uk> 2011-08-31 10:45:11 UTC ---
In theory, at least, we can assume that PCR won't change by more than 100
milliseconds between PCR packets.
Reasoning from the spec (references to ISO/IEC 13818-1:2007):
Section 22.214.171.124 (System clock frequency) tells us that the PCR is derived from
a stable 27MHz clock.
Section 126.96.36.199 says maximum encoding error of the PCR in the stream is 500
nanoseconds as compared to the "real" PCR value.
Section 188.8.131.52 defines a discontinuity_indicator in the adaptation field to
tell us that the PCR is in the process of jumping. When it is set, packets
before the packet with discontinuity_indicator set use the old PCR for their
timestamps, packets after the one with discontinuity_indicator set use the new
Finally, section 2.7.2 tells us that the PCR must be coded in the stream at
least once every 100 milliseconds, or the stream is not a valid transport
Putting all these bits together, we know that for any PCR packet, if the
discontinuity_indicator is not set (indicating that the timebase is changing,
and we need to do future timestamping against the new PCR), any jump of more
than 100 milliseconds is indicative of a broken stream, and we should ignore
this PCR packet and continue to free-run until we pick up a valid PCR again -
we should probably increase the permitted timestamp jump by 100 milliseconds
for each faulty PCR packet we've seen, so we gracefully degrade and recover if
several PCRs in a row are faulty followed by good PCRs again.
There's also the transport_error_indicator in transport packets to hint that
this packet is corrupt; our DVB-T cards do appear to set this whenever there
are uncorrected errors in the packet. This could also be used as a hint that
the PCR is probably wrong if it's a large jump.
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs