<div dir="ltr">Hi Everyone, I created a simple pipeline with uridecode, encodebin and filesink to capture a HLS stream, transcode it to mp4 and save it to a file. (I enclosed the dot file of the pipeline in PLAYING state.) Depending on the variant of the mp4mux I use, I experience different kind of problems with the recorded mp4 file. If I set the variant to quicktime or iso, I end up with a file that doesn’t contain playable streams. (Though the size of the file looks ok.) If I use gst-discoverer-1.0 to open it I find the following in the debug output: 0:00:00.248059364 5376 02D3C918 DEBUG qtdemux qtdemux.c:5081:qtdemux_sink_activate:<qtdemux0:sink> activating pull 0:00:00.248639533 5376 02DEF9F0 LOG qtdemux qtdemux.c:4323:gst_qtdemux_loop:<qtdemux0> loop at position 0, state 0 0:00:00.248731297 5376 02DEF9F0 DEBUG qtdemux qtdemux.c:2303:extract_initial_length_and_fourcc: length 0x00000020 0:00:00.248789555 5376 02DEF9F0 DEBUG qtdemux qtdemux.c:2305:extract_initial_length_and_fourcc: atom type ftyp 0:00:00.248860794 5376 02DEF9F0 DEBUG qtdemux qtdemux.c:2211:qtdemux_parse_ftyp:<qtdemux0> major brand: mp42 0:00:00.248921769 5376 02DEF9F0 LOG qtdemux qtdemux.c:4323:gst_qtdemux_loop:<qtdemux0> loop at position 32, state 0 0:00:00.248987573 5376 02DEF9F0 DEBUG qtdemux qtdemux.c:2303:extract_initial_length_and_fourcc: length 0x00000001 0:00:00.249043417 5376 02DEF9F0 DEBUG qtdemux qtdemux.c:2305:extract_initial_length_and_fourcc: atom type mdat 0:00:00.249097751 5376 02DEF9F0 DEBUG qtdemux qtdemux.c:2313:extract_initial_length_and_fourcc: length 0x00000000 0:00:00.249245359 5376 02DEF9F0 WARN qtdemux qtdemux.c:3060:gst_qtdemux_loop_state_header:<qtdemux0> warning: Invalid atom size. 0:00:00.249310258 5376 02DEF9F0 WARN qtdemux qtdemux.c:3060:gst_qtdemux_loop_state_header:<qtdemux0> warning: Header atom 'mdat' has empty length 0:00:00.249483222 5376 02DEF9F0 LOG qtdemux qtdemux.c:4362:gst_qtdemux_loop:<qtdemux0> pausing task, reason eos 0:00:00.249561403 5376 02DEF9F0 WARN qtdemux qtdemux.c:573:gst_qtdemux_post_no_playable_stream_error:<qtdemux0> error: This file contains no playable streams. 0:00:00.249619661 5376 02DEF9F0 WARN qtdemux qtdemux.c:573:gst_qtdemux_post_no_playable_stream_error:<qtdemux0> error: no known streams found 0:00:00.249704181 5376 02DEF9F0 LOG qtdemux qtdemux.c:4397:gst_qtdemux_loop:<qtdemux0> Sending EOS at end of segment 0:00:00.249930875 5376 02DEF9F0 DEBUG qtdemux qtdemux.c:873:gst_qtdemux_push_event:<qtdemux0> pushing eos event on all source pads 0:00:00.250005434 5376 02DEF9F0 WARN qtdemux qtdemux.c:573:gst_qtdemux_post_no_playable_stream_error:<qtdemux0> error: This file contains no playable streams. 0:00:00.250061881 5376 02DEF9F0 WARN qtdemux qtdemux.c:573:gst_qtdemux_post_no_playable_stream_error:<qtdemux0> error: no known streams found 0:00:00.250151834 5376 02D3AC60 DEBUG qtdemux qtdemux.c:1797:gst_qtdemux_reset:<qtdemux0> Resetting demux It is complaining about the size of the first mdat box.To prove that I have the file properly closed, you can find the last few lines of the qtmux log below: 0:00:37.068707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1802:gst_qt_mux_stop_file:<muxer> Updating remaining values and sending last data 0:00:37.068707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1819:gst_qt_mux_stop_file:<muxer> Sending the last buffer for pad video_0 0:00:37.068707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:2347:gst_qt_mux_add_buffer: dts: 0:00:59.880000000 pts: 0:00:59.880000000 timebase_dts: 149700 pts_offset: 0 0:00:37.068707000 6124 10ede9b8 DEBUG filesink gstfilesink.c:661:gst_file_sink_render:<rec_sink> writing 11358 bytes at 15129303 0:00:37.069707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1819:gst_qt_mux_stop_file:<muxer> Sending the last buffer for pad audio_0 0:00:37.069707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:2347:gst_qt_mux_add_buffer: dts: 99:99:99.999999999 pts: 0:00:59.968000000 timebase_dts: 1918976 pts_offset: 0 0:00:37.069707000 6124 10ede9b8 DEBUG filesink gstfilesink.c:661:gst_file_sink_render:<rec_sink> writing 469 bytes at 15140661 0:00:37.069707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1532:gst_qt_mux_configure_moov:<muxer> Updating timescale to 1000 0:00:37.070707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1908:gst_qt_mux_stop_file:<muxer> Media first ts selected: 0:00:00.000000000 0:00:37.070707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1167:gst_qt_mux_setup_metadata:<muxer> Removing bogus tags 0:00:37.070707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1172:gst_qt_mux_setup_metadata:<muxer> Formatting tags 0:00:37.070707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:559:gst_qt_mux_add_mp4_tag:<muxer> Adding tag ©too -> x264 0:00:37.071707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1050:gst_qt_mux_add_xmp_tags:<muxer> Adding xmp tags 0:00:37.071707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1558:gst_qt_mux_send_moov:<muxer> Pushing moov atoms 0:00:37.071707000 6124 10ede9b8 DEBUG filesink gstfilesink.c:661:gst_file_sink_render:<rec_sink> writing 37901 bytes at 15141130 0:00:37.072707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1595:gst_qt_mux_send_extra_atoms:<muxer> Pushing extra top-level atom uuid 0:00:37.072707000 6124 10ede9b8 DEBUG filesink gstfilesink.c:661:gst_file_sink_render:<rec_sink> writing 731 bytes at 15179031 0:00:37.072707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:1988:gst_qt_mux_stop_file:<muxer> updating mdat size 0:00:37.072707000 6124 10ede9b8 DEBUG filesink gstfilesink.c:516:gst_file_sink_do_seek:<rec_sink> Seeking to offset 32 using fseeko 0:00:37.072707000 6124 10ede9b8 DEBUG filesink gstfilesink.c:661:gst_file_sink_render:<rec_sink> writing 16 bytes at 32 0:00:37.073707000 6124 10ede9b8 DEBUG qtmux gstqtmux.c:2447:gst_qt_mux_handle_buffer:<muxer> Pushing eos 0:00:37.091709000 6124 5d92aa0 DEBUG filesink gstfilesink.c:435:gst_file_sink_close_file:<rec_sink> closed file From the sources it looks that mdat is set up by gst_qt_mux_stop_file to NULL on purpose. If I use the iso-fragmented variant of the mp4mux in the encodebin, I end up with a file that looks to be fine, gst-discoverer-1.0 reports the tracks and I can play it with VLC. VLC also properly reports the duration of the file, and I can seek in it without problem. On the other hand if I try to use the fragmented file with gst-rtsp-server based on the test-mp4 example, the server cannot seek in the file and I end up with a “cannot prepare media message” in the logs. Here comes my questions: 1. What am I doing wrong that the non-fragmented media files created with mp4mux/qtmux are not valid? (Using the same audio and video profiles the fragmented variant seems to be ok.) 2. My understanding is that the seek events should be handled by a plugin in the pipeline chain. The pipeline that I use when I play back the prerecorded file locally is using the same elements like the rtsp_media_factory I use in the rtsp server. (filesrc location=%s! qtdemux name=d d. ! queue ! rtph264pay pt=96 name=pay0 ) On the other hand playbin can handle the seek and rtsp-server cannot. What is the reason for this? What is the reason that qtdemux can handle seek event for non-fragmanted files but cannot handle seek event for fragmented files? Please give me some advice how can I move forward from this point. I’ve read the documentation a few times, checked the sources and logs but I’m running out of ideas what could be done next… Thanks in advance! Best Regards, Lajos </div>