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 768758 - tsdemux: Re-use pads when possible (decodebin3/playbin3)
tsdemux: Re-use pads when possible (decodebin3/playbin3)
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-13 06:37 UTC by Michael Olbrich
Modified: 2018-05-12 06:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
mpegtsbase: ignore programs with pcr_pid=0x1fff (884 bytes, patch)
2016-07-13 06:37 UTC, Michael Olbrich
none Details | Review

Description Michael Olbrich 2016-07-13 06:37:43 UTC
Created attachment 331383 [details] [review]
mpegtsbase: ignore programs with pcr_pid=0x1fff

What's the correct way to handle programs with pcr_pid == 0x1fff?

I've come across this stream:
http://filmrommet.no/film/playlist.m3u8?id=12450%20TR=1%20type=m3u8

Each fragment starts with a video only program with pcr_pid=0x1fff. I think that's just a cover image or something like that.
Next comes the actual program with audio and video.

GStreamer tries to switch programs every time. Without e3f5ccb3333f3b22c41e59cf78e4343c99187009 ("tsdemux: Change the pad naming scheme to include a generation ID") that breaks completely. With that change the appearing and disappearing audio clock seems to cause various problems. And even with a forced system clock playback is anything but smooth.

I've attached a patch to ignore programs with pcr_pid == 0x1fff. With this playback looks good. But I don't know enough about the spec to know if this is the correct fix.
Comment 1 Michael Olbrich 2016-07-13 07:27:34 UTC
... and of course that patch breaks other streams... Any ideas how to handle this?
Comment 2 Edward Hervey 2016-07-13 08:24:15 UTC
A PCR_PID of 0x1fff is normal (in the sense that means that there isn't a PCR PID specified for that program). There's a bug tracking that issue here : https://bugzilla.gnome.org/show_bug.cgi?id=608148

What's causing problems is more the switch to the other program.
Comment 3 Edward Hervey 2016-07-13 09:06:23 UTC
Figured it out I think.

The problem is that it switches programs ... but we should re-use the existing h264 stream (that contains the SPS/PPS/....). Without this we plug a new parser, which will drop quite a bit of data before it gets the SPS/PPS.

This is case of not removing/re-adding streams which are present in the program update.

We should be able to handle this with decodebin3/playbin3. I have some pending patches that need a bit more work to handle this properly.

Renaming bug accordingly.
Comment 4 Michael Olbrich 2016-07-13 09:41:25 UTC
I don't think that will help with this stream. Each fragment in this hls playlist starts with a PMT with only a video stream. Immediately afterwards comes a PMT with a video and an audio stream.

So only the video pad is reused. The audio pad will be removed and then added again.
Comment 5 Edward Hervey 2018-05-12 06:35:49 UTC
Sadly the stream doesn't exist, and tsdemux has been adapted since to re-use streams as much as possible in decodebin3/playbin3.

Closing as obsolete. Please re-open if you have a stream reproducing the same issue and failing with decodebin3/playbin3.