<div dir="ltr">See if passing the -e switch in your  mp4mux + filesink pipeline actually produces a proper file. mp4mux really needs to receive the EOS. <div><br></div><div>Cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-13 2:44 GMT+01:00 Robert Armstrong <span dir="ltr"><<a href="mailto:orangerobot@gmail.com" target="_blank">orangerobot@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm continuing to debug an issue w/ recording/streaming H.264 from a proprietary UVC USB camera. <div><br></div><div>This works fine:</div><div><br></div><div>gst-launch-1.0 v4l2src device=/dev/video1 num-buffers=150 ! queue !  h264parse ! avimux ! filesink location=foo.avi<br></div><div><br></div><div>But this produces a file with only few frames:</div><div><br></div><div>gst-launch-1.0 v4l2src device=/dev/video1 num-buffers=150 ! queue !  h264parse ! mp4mux faststart=true ! filesink location=foo.mp4<br></div><div><br></div><div>This has the same issues as the mp4mux:</div><div><br></div><div>gst-launch-1.0 -e v4l2src device=/dev/video1 ! video/x-h264,width=1280,height=720,framerate=30/1 ! h264parse ! queue ! rtph264pay ! udpsink host=192.168.168.121 port=5000<br></div><div><br></div><div>If I crank up the debug level on the mp4mux example, the main difference seems to be this:</div><div><br></div><div><div>0:00:01.864250954   847  0x9ae0db0 WARN               h264parse gsth264parse.c:1205:gst_h264_parse_handle_frame:<h264parse0> broken/invalid nal Type: 1 Slice, Size: 20747 will be dropped</div><div>0:00:01.896477567   847  0x9ae0db0 WARN               h264parse gsth264parse.c:1205:gst_h264_parse_handle_frame:<h264parse0> broken/invalid nal Type: 1 Slice, Size: 21045 will be dropped</div><div>0:00:01.932409929   847  0x9ae0db0 WARN               h264parse gsth264parse.c:1205:gst_h264_parse_handle_frame:<h264parse0> broken/invalid nal Type: 1 Slice, Size: 19627 will be dropped</div><div>0:00:01.964358670   847  0x9ae0db0 WARN               h264parse gsth264parse.c:1205:gst_h264_parse_handle_frame:<h264parse0> broken/invalid nal Type: 1 Slice, Size: 19898 will be dropped</div><div>0:00:01.996332701   847  0x9ae0db0 WARN               h264parse gsth264parse.c:1205:gst_h264_parse_handle_frame:<h264parse0> broken/invalid nal Type: 1 Slice, Size: 19490 will be dropped</div><div><br></div></div><div>The avimux pipeline will only drop one frame over 5 seconds. </div><div><br></div><div>The same frame dropping happens if I try to stream by connecting h264parse to rtph264pay. </div><div><br></div><div>Any suggestions on how to address? Are there parameters I can use to tune mp4mux? Is it possible that avimux is more tolerant of the data it's receiving than mp4mux?</div><div><br></div><div>Thanks in advance!</div></div>
<br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br></div>