GNOME Bugzilla – Bug 659833
[tsdemux] Playback stalls with EOS from pipeline at resolution change
Last modified: 2012-05-24 08:33:19 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.
pipeline used was the one mentioned but with tsdemux instead of mpegtsdemux, my bad.
Created attachment 197252 [details] log from playback attempt
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.
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).
Works fine with git. Change is seen and correct