having problem with mp4mux
Lajos Okos
lajos.okos at gmail.com
Fri Apr 4 07:42:01 PDT 2014
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 (c)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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140404/41f8a0b3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: playbin.dot
Type: application/msword
Size: 35290 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140404/41f8a0b3/attachment-0001.dot>
More information about the gstreamer-devel
mailing list