GNOME Bugzilla – Bug 744469
tsdemux: No data after prerolling when different PTS in one program
Last modified: 2018-05-14 14:06:14 UTC
When tsdemux shall demux a program with streams that have different pts, sometimes there are non data output after prerolling phase. Results in non playing pipelines. It's simple to test with the commands: filesrc location=phoenix_tail_425.ts ! tsparse ! tsdemux name=dm dm. ! identity dump=true ! mpegvideoparse ! fakesink filesrc location=phoenix_tail_425.ts ! tsparse ! tsdemux name=dm dm. ! identity dump=true ! mpegaudioparse ! fakesink The bug is triggert only sometimes, when the stream with bigger(?) PTS is first found. As attachement one stream which triggers the bug(425) and another one that differs only in that, that the first packet is removed(426). With the second it works perfectly. The problematic stream is the private stream. When I patch tsdemux to ignore private streams it works with both.
Created attachment 296776 [details] not working stream
Created attachment 296777 [details] working stream
Since I have the same issue with some others streams, I take a look at this issue. My current understanding is that the first observed valid timestamp in PES header will trigger the initial PTS/DTS set on all streams. Unfortunately in this case the first stream which have a valid timestamp is the subtitle one (teletext) which have a really big timestamp (something like 13 hours). So when check_pending_buffers() is called, the only stream which have a valid timestamp is this one, leading the following segment logic to choose it as a start value. So in this case the tsdemux ouputs a segment which have ~ 13:00:00 as a start value on all source pad. As a result, when tsdemux pushes audio/video samples with lower timestamp, they are clipped because they are outside of segments. Currently, I'm not very familiar with MPEG-TS and tsdemux but I'm thinking of two solutions: - ignore sparse streams when checking for initial valid timestamp unless we only have sparse stream; (i will suubmit a patch for this way) - when first timestamp of each stream is valid, trigger a new check and adjust segment. What do you think about it ?
Created attachment 299536 [details] [review] tsdemux: ignore sparse stream when checking for initial timestamp Proposal fix/workaround for this issue. It ignores sparse streams for initial timestamp unless we only have sparse stream. It may be not the best solution but it can be a first try to solve this issue.
Thanks for the patch. Pushed: commit 89a85732d4d91ea6b41e3ea85fdf96152bc58e8d (HEAD -> master) Author: Aurélien Zanelli <aurelien.zanelli@parrot.com> Date: Mon Mar 16 16:20:44 2015 +0100 tsdemux: ignore sparse stream when checking for initial timestamp Unless we only have sparse streams. In this case we will consider them. It fixes a bug happening when first observed timestamp comes from a sparse stream and other streams don't have a valid timestamp, yet. Thus leading the timestamp from sparse stream to be the start of the following segment. In this case, if the timestamp is really bigger than non-sparse stream (audio/video), it will lead the pipeline to clip samples from the non-parse stream. https://bugzilla.gnome.org/show_bug.cgi?id=744469