<div dir="ltr">Adding the -e doesn't seem to fix it. <div> </div><div>I've noticed that I can save a raw H.264 file with gstreamer and then convert that to an MP4 using ffmpeg and it works fine. That seems to indicate that there may be an issue with mp4mux?<div> <div class="gmail_extra">I can send along the H.264 file if anyone is interested.</div><div class="gmail_extra"> <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Message: 7 Date: Wed, 13 Jan 2016 10:22:31 +0100 From: Sérgio Agostinho <<a href="mailto:sergio.r.agostinho@gmail.com">sergio.r.agostinho@gmail.com</a>> To: Discussion of the development of and with GStreamer <<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>> Subject: Re: h264 recording Message-ID: <CALUX5R0eAt7o5L01XQYpgktA=<a href="mailto:JuuqEkFhEmBupCn-C1avaz%2B-w@mail.gmail.com">JuuqEkFhEmBupCn-C1avaz+-w@mail.gmail.com</a>> Content-Type: text/plain; charset="utf-8" See if passing the -e switch in your mp4mux + filesink pipeline actually produces a proper file. mp4mux really needs to receive the EOS. Cheers 2016-01-13 2:44 GMT+01:00 Robert Armstrong <<a href="mailto:orangerobot@gmail.com">orangerobot@gmail.com</a>>: > I'm continuing to debug an issue w/ recording/streaming H.264 from a > proprietary UVC USB camera. > > This works fine: > > gst-launch-1.0 v4l2src device=/dev/video1 num-buffers=150 ! queue ! > h264parse ! avimux ! filesink location=foo.avi > > But this produces a file with only few frames: > > gst-launch-1.0 v4l2src device=/dev/video1 num-buffers=150 ! queue ! > h264parse ! mp4mux faststart=true ! filesink location=foo.mp4 > > This has the same issues as the mp4mux: > > 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 > > If I crank up the debug level on the mp4mux example, the main difference > seems to be this: > > 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 > 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 > 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 > 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 > 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 > > The avimux pipeline will only drop one frame over 5 seconds. > > The same frame dropping happens if I try to stream by connecting h264parse > to rtph264pay. > > 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? > > Thanks in advance! > > _______________________________________________ > gstreamer-devel mailing list > <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> > > </blockquote></div> </div></div></div></div>