GNOME Bugzilla – Bug 750660
tsdemux and push-mode not calculating
Last modified: 2018-11-03 13:36:01 UTC
Created attachment 304888 [details] Does not work example log I’m having a problem with the mpegtspacketizer.c implementation of mpegts_packetizer_pts_to_ts I have a HLS demuxer ( not the open source version that is available, but a home grown one that I am working on open sourcing) that pushes TS files into the pipeline. On actual Set top box hardware this implementation autoplugs and works fine. The problem comes when I try to run it on a PC with the tsdemux in gst-plugins-bad. When I send the TS stream to the tsdemux, the tsdemux does actually parse and find the correct PTS and DTS however since I don’t have calculate_skew nor calculate_offset set to TRUE the code flow in mpegts_packetizer_pts_to_ts always reports back that Not enough information to calculate proper timestamp. Now with the exact same stream I do a filesrc autoplugged pipeline and load the first transport stream segment into playbin and because this is a pull src the pipeline and the tsdemux can correctly parse and set the timestamps PTS/ DTS and play the stream. I’m stuck with how to actually fix this function. I have attached two logs, one working ( the pull source I noted from above) and the HLS demux that is a push source that doesn’t work. I have referenced bug 687178 https://bugzilla.gnome.org/review?bug=687178&attachment=228530 However I have the same issue with the 1.4.4 release. Even though my demux element sends a segment event (which should theoretically turn on calculate_skew) it seems the tsdemux is throwing this segment information away and calculate_skew never gets turned on. 0:00:00.185801239 20235 0x1552ca0 DEBUG tsdemux gbuild/src/gst-plugins-bad-1.4.4/gst/mpegtsdemux/tsdemux.c:890:push_event:<tsdemux0> Ignoring segment event (recreated later) I've tried commenting out the above with no change in behavior. Any suggestions on how to proceed would be greatly appreciated. I’m also happy to provide any code or libraries. Thanks, Matt
Created attachment 304889 [details] This is an example of the code working with a push source
Does it work with a pushfile:// uri? This will trigger filesrc under push mode. Does your hls element push a TIME segment?
Hello, Yes it does work with pushfile://uri, however the baseFormat is not GST_FORMAT_TIME, where as my HLS Demux is indeed setting the segment with the GST_FORMAT_TIME parameter. I should have mentioned this earlier. Here is my segment code that I send on new streams and after a flush stop: GstEvent *segmentEvent = NULL; #if GST_CHECK_VERSION(1,0,0) GstSegment segment; gst_segment_init(&segment,GST_FORMAT_TIME); segment.rate = 1.0; segment.applied_rate = 1.0; segment.format = GST_FORMAT_TIME; segment.position = demux->seekpos; //seekpos in a new stream is 0 segment.start = 0;// demux->seekpos; //start; segment.stop = gst_cisco_hls_get_duration(demux); // duration of the HLS VOD asset segment.flags = GST_SEGMENT_FLAG_RESET; GST_WARNING(" Sending NewSegment message with flag set to reset, setting:\n new position to %u (ms) \n start %"G_GINT64_FORMAT" \n stop %"G_GINT64_FORMAT"\n" ,demux->seekpos/ GST_MSECOND,segment.start, segment.stop); segmentEvent = gst_event_new_segment (&segment); Is this what you meant by saying a "TIME segment"? Thanks,
That failing log makes no sense. Are you sure you have no other patches applied to mpegtsdemux ? Does it work with 1.4.5 or 1.5.1 ? If not, please provide a more complete log (GST_DEBUG=2,*ts*:8 and let it run for a bit longer than you did).
I have not tried with 1.4.5 or 1.5.1, I can attempt to do that next. I have created a log and let it run for quite a long time with a virgin copy of 1.4.4. I have removed all my prints. I have also set the log levels to what you requested Edward. the Log is virgin_log.txt
Created attachment 304963 [details] Virgin log of 1.4.4 tsdemux I had to compress this text file as a tarball because it was too big.
Do you set a timestamp on the first buffer you push out ? If you don't, the whole skew calculation system won't be activated.
I have tried setting the buffer timestamp to none GST_BUFFER_TIMESTAMP (buf) =GST_CLOCK_TIME_NONE; with no change in behavior, however when I changed the code to this: GST_BUFFER_TIMESTAMP (buf) =demux->seekpos; Where demux->seekpos is the stream start or the seek position in nano seconds than the demux is able to parse and play back content. Which I guess resolves this bug. However querying for position always returns the running time not the actual stream position time. For example if I seek to 80 seconds into the stream and query for position it returns that the position is 0 and increments from there. Part of that could be the fact that when I do a flush event = gst_event_new_flush_stop (TRUE); I send in a hard reset, if I do not and leave this as false the video freezes and nothing occurs when I do a seek.
Ok, so it's not an issue in GStreamer. Please move your questions to the gst-devel mailing-list. Bugzilla is for tracking bugs in GStreamer.
I have to reopen this bug because I'm seeing the exact same behavior when I do a seek 600 seconds or larger into the playback stream. When I do the seek forward only 100 or 400 sec the seek works fine. My code for the buffers ( for the first buffer and any seeks) looks like this: GstSegment segment; gst_segment_init(&segment,GST_FORMAT_TIME); segment.rate = 1.0; segment.applied_rate = 1.0; segment.format = GST_FORMAT_TIME; segment.position =0; segment.start = demux->seekpos; segment.stop = gst_cisco_hls_get_duration(demux); segment.flags = GST_SEGMENT_FLAG_RESET; segment.time = demux->seekpos; GST_WARNING(" Sending NewSegment message with flag set to reset, setting:\n new position to %u (ms) \n start %"G_GINT64_FORMAT" \n stop %"G_GINT64_FORMAT"\n" ,demux->seekpos/ GST_MSECOND,segment.start, segment.stop); GST_BUFFER_TIMESTAMP (buf) = demux->seekpos; segmentEvent = gst_event_new_segment (&segment); I've collected several logs placed in the seek_logs.tgz file: compare.log: trimmed log that shows the start of the stream playing then after the seek (line 45) seek.log: full log that goes with the compare.log file. The interesting thing in the working cases is that I will always get the gst_ts_demux_parse_pes_header "Got pts/dts update, rechecking all streams" However in the none working case I never see this print. Happy to collect more logs or discuss how I should set the timestamp in the buffers more than what I'm already doing. ( I actually only timestamp the initial buffer after start and after a seek).
Created attachment 305175 [details] Log files that show failure of tsdemux finding PTS /DTS values after a seek.
Created attachment 305333 [details] [review] Resolves the problem with tsdemux not playing back after seek in TS The TS file that I was seeking through had PCR value that would gradually get way off. So when you did a seek the values where more than 15 seconds off. Well there is a check for this in mpegtspacketizer but it only allows for a 15 second variance. I increased it to half the max value.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/259.