GNOME Bugzilla – Bug 796666
mpegtsmux doesn't write PAT in audio-only mux
Last modified: 2018-07-16 06:46:19 UTC
The following stream: ```gst-launch-1.0 mpegtsmux name=muxer prog-map=programs,sink_102=1 ! buffermonitor name=test-src-8002 ! filesink location=test.ts audiotestsrc wave=sine ! audio/x-raw,channels=2 ! avenc_ac3 bitrate=128 ! muxer.sink_102``` produces a .ts file which does *not* include any PAT tables on a 1.14.1 source-tarball build on Centos7 (or on a 1.14.0 build): ```$ tsinfo -max 50000000 test.ts Reading from test.ts Scanning 50000000 TS packets EOF Found 0 PAT packets and 0 PMT packets in 50000000 TS packets``` The same pipeline works fine *IFF* there is a video stream involved. The same pipeline also works *correctly* on the packaged 1.14.0 Ubuntu 18.04 version of gstreamer. The difference between the two 1.14.0 versions appears to be down to a check to see if the
Sorry, apparently I didn't get the whole sentence in there... down to a check to see if the best stream is a video stream: ``` if (mux->force_key_unit_event != NULL && best->stream->is_video_stream) {``` at line 1359 of `tsmux.c`. The Ubuntu 1.14.0 version doesn't have that check, while the from-tarball centos7 version *does* have the check (and thus never sends PAT tables).
*** Bug 796667 has been marked as a duplicate of this bug. ***
So this would be a regression then. Why is a PAT invalid for audio-only mux?
(In reply to Sebastian Dröge (slomo) from comment #3) > So this would be a regression then. > Why is a PAT invalid for audio-only mux? It isn't - the bug is that the PAT isn't being generated unless there's a video stream.
Must be one of these commits then commit 7a2110a4993da33b9513c58ae0ac8ee1945a5faf Author: Sebastian Dröge <sebastian@centricular.com> Date: Thu Mar 29 19:03:45 2018 +0300 mpegtsmux: Resend initial segments and header sections after FLUSH_STOP https://bugzilla.gnome.org/show_bug.cgi?id=794816 commit 93e56ed4735cb525cac9bf3f833a8342f7543671 Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed Mar 21 13:42:30 2018 +0200 mpegtsmux: Explicitly resend PAT/SI/PMT on force-keyunit events And don't randomly change the PCR stream, which would cause a new PMT version to be generated instead and could confuse players. commit 3f0463c43e2c61ba5509c9466dc2a023dc866ad4 Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed Mar 21 13:34:17 2018 +0200 mpegtsmux: Deterministically set the PCR stream to the first stream of the program Otherwise it would be randomly set to the first stream of the program that receives a buffer.
I can't reproduce this with GIT master and also not with 1.14.1 (from Debian). I tried with gst-launch-1.0 -e mpegtsmux name=muxer prog-map=programs,sink_102=1 ! filesink location=test.ts audiotestsrc wave=sine ! audio/x-raw,channels=2 ! avenc_ac3 bitrate=128 ! muxer.sink_102 And tsinfo on the resulting file gives Reading from test.ts Scanning 1000 TS packets Packet 1 is PAT Program list: Program 1 -> PID 0020 (32) Packet 2 is PMT with PID 0020 (32) Program 1, version 0, PCR PID 0066 (102) Program info (12 bytes): 05 04 48 44 4d 56 88 04 0f ff fc fc Registration HDMV Descriptor tag 88 (136) (4 bytes): 0f ff fc fc Program streams: PID 0066 ( 102) -> Stream type 81 (129) User private ES info (18 bytes): 0a 04 65 6e 00 00 05 0a 41 43 2d 33 81 04 28 c8 04 00 Languages: en Registration AC-3 81 04 28 c8 04 00 Found 400 PAT packets and 200 PMT packets in 1000 TS packets
That condition that is mentioned in the first comment also only causes *resending* of PAT (and PMT and SI) for the video stream on keyunit events. It should not have any effect at all for audio. PAT/PMT/etc are periodically sent (see the *-interval properties on the muxer) and in the very beginning I don't see how the changes since 1.14.0 could cause a behaviour difference for audio-only streams.
(In reply to Sebastian Dröge (slomo) from comment #7) > That condition that is mentioned in the first comment also only causes > *resending* of PAT (and PMT and SI) for the video stream on keyunit events. > It should not have any effect at all for audio. PAT/PMT/etc are periodically > sent (see the *-interval properties on the muxer) and in the very beginning > > I don't see how the changes since 1.14.0 could cause a behaviour difference > for audio-only streams. I got the same result - the stream produced works fine and has PAT/PMT
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!