GNOME Bugzilla – Bug 752999
Splitmuxsink does not work with mpegtsmux
Last modified: 2015-08-22 10:38:42 UTC
Hi, splitmuxsink works perfectly with mp4mux as follows gst-launch-1.0 filesrc location=big_buck_bunny_1080p.mp4 ! qtdemux ! video/x-h264 ! h264parse ! splitmuxsink max-size-time=12000000000 location=video%05d.mp4 muxer=mp4mux But does not work with mpegtsmux for H264 and Mpeg2 codec Mpeg2: gst-launch-1.0 videotestsrc ! avenc_mpeg2video ! splitmuxsink max-size-time=12000000000 location=video%05d.ts muxer=mpegtsmux -v (gst-launch-1.0:8166): GStreamer-CRITICAL **: gst_element_request_pad: assertion `templ != NULL' failed WARNING: erroneous pipeline: could not link avenc_mpeg2video0 to splitmuxsink0 H264: gst-launch-1.0 filesrc location=big_buck_bunny_1080p.mp4 ! qtdemux ! video/x-h264 ! h264parse ! splitmuxsink max-size-time=12000000000 location=video%05d.ts muxer=mpegtsmux (gst-launch-1.0:23781): GStreamer-CRITICAL **: gst_element_request_pad: assertion `templ != NULL' failed WARNING: erroneous pipeline: could not link h264parse0 to splitmuxsink0
Created attachment 308364 [details] [review] splitmuxsink: Support mpegtsmux as a muxer. As a fallback, look for a pad template sink_%d on the muxer when requesting pads, to support mpegtsmux
Seems to be some error. It's working fine now. But the output is still mp4
if the output is mp4, it's not using mpegtsmux at all. Did you lose the 'muxer=mpegtsmux' setting?
Sorry, that was a false alarm. It's working perfectly but performance is very low. Take a look at these two pipelines for example. splitmuxsink is almost 55times slower than having traditional mpegtsmux ! filesink. Am I missing something here? Kindly let me know [root@localhost multifile]$ time gst-launch-1.0 filesrc location=/home/root/big_buck_bunny_1080p.mp4 ! qtdemux ! video/x-h264 ! h264parse ! mpegtsmux ! filesink location=single.ts Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:02.164395016 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... real 0m2.251s user 0m1.936s sys 0m0.314s [root@localhost multifile]$ time gst-launch-1.0 filesrc location=/home/root/big_buck_bunny_1080p.mp4 ! qtdemux ! video/x-h264 ! h264parse ! splitmuxsink max-size-time=12000000000 location=video%05d.ts muxer=mpegtsmux sink=filesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:01:50.757893834 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... real 1m50.792s user 1m51.052s sys 0m0.407s
Created attachment 308390 [details] [review] mpegtsmux: Don't clear the PID on reset. The PID on a pad shouldn't change on a state change, only if the pad is freed and a new one created. Clearing the PID prevented mpegtsmux from being reused, because all packets would end up muxed in PID 0
That one line change makes it generate OK files, but there's a remaining problem that the H.264 SPS/PPS don't get inserted into subsequent files. Adding 'config-interval=1' to h264parse makes them at least playable, although a little bit at the start of each file fragment is unplayable until an SPS/PPS is inserted. A better solution would be to be able to insert the SPS/PPS before the keyframe that starts each new file part, but that requires changes in a few places.
Performance of both the pipelines are matching now(with or without fragment) . Not sure how why that one line of code was adding so much of cpu load :) I think introducing SPS/PPS should entirely be left to encoder/h264parser here.
(In reply to Baby octopus from comment #7) > Performance of both the pipelines are matching now(with or without fragment) > . Not sure how why that one line of code was adding so much of cpu load :) It was making every packet be considered a header and accumulated in a linked list that was never intended to be that long :) > I think introducing SPS/PPS should entirely be left to encoder/h264parser > here. Yes, but a mode on h264parse that inserted SPS/PPS before every key-frame would let splitmuxsink split into files where each fragment is playable independently, which would be nice.
Perfect :) I think we can close this bug now