After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659833 - [tsdemux] Playback stalls with EOS from pipeline at resolution change
[tsdemux] Playback stalls with EOS from pipeline at resolution change
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-22 14:37 UTC by Reynaldo H. Verdejo Pinochet
Modified: 2012-05-24 08:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Failing sample (768.84 KB, application/x-gzip)
2011-09-22 14:37 UTC, Reynaldo H. Verdejo Pinochet
  Details
log from playback attempt (332.24 KB, text/x-log)
2011-09-22 14:39 UTC, Reynaldo H. Verdejo Pinochet
  Details
Preliminary fix (1.02 KB, patch)
2011-09-22 17:06 UTC, Reynaldo H. Verdejo Pinochet
none Details | Review

Description Reynaldo H. Verdejo Pinochet 2011-09-22 14:37:47 UTC
Created attachment 197251 [details]
Failing sample

As on $SUBJECT. you get EOS from pipeline0 at around ~5s.

Pipeline used was:

gst-launch  filesrc location=/home/reynaldo/Desktop/sample.ts ! mpegtsdemux ! h264parse ! ffdec_h264 ! xvimagesink

Using mpegtsdemux you get normal playback till end of
stream (around ~19s) but the frame dimensions doesn't
change as it supposed to happen at ~9s. You can try
playing the sample with mplayer to get the desired
behavior.

This issue an the one in #659723 seem related.

Please find both the .ts sample and a *:3 log from the playback
attempt attached.
Comment 1 Reynaldo H. Verdejo Pinochet 2011-09-22 14:38:50 UTC
pipeline used was the one mentioned but with tsdemux instead of mpegtsdemux, my bad.
Comment 2 Reynaldo H. Verdejo Pinochet 2011-09-22 14:39:27 UTC
Created attachment 197252 [details]
log from playback attempt
Comment 3 Reynaldo H. Verdejo Pinochet 2011-09-22 17:06:39 UTC
Created attachment 197268 [details] [review]
Preliminary fix

Preliminary fix by Vincent Penquerch that avoids the stall with tsdemux. It basically just starts looking for a PCR closer to the end.
Comment 4 Vincent Penquerc'h 2011-09-23 11:25:56 UTC
For clarification, the PCR scanner code reads 50 packets, so by offsetting 50 packets from the end of the stream, rather than 4000, we ensure that the last 50 packets are read, and not 50 packets from a way before the end.

There is a risk that no valid PCR will be found within those 50 last packets, so a really better fix would be to linearly scan from the end of the stream till a valid PCR is found. I've no idea what is the likelohood that no valid PCR will be found within 50 packets, not knowing much at all about MPEG.

Also, MPEG can have PCR discontinuities, so determining stream length like this will yield a wrong result if there's a discontitnuity between start and end of the stream. While this can be detected if endpcr < firstpcr, I don't know if there's a way to detect it if there's a jump forward (eg, some version number, etc).
Comment 5 Edward Hervey 2012-05-24 08:33:19 UTC
Works fine with git. Change is seen and correct