Re: h264 recording (Sérgio Agostinho)

[Robert Armstrong]

Adding the -e doesn't seem to fix it.

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?

I can send along the H.264 file if anyone is interested.


> Message: 7
> Date: Wed, 13 Jan 2016 10:22:31 +0100
> From: Sérgio Agostinho <sergio.r.agostinho at gmail.com>
> To: Discussion of the development of and with GStreamer
>         <gstreamer-devel at lists.freedesktop.org>
> Subject: Re: h264 recording
> Message-ID:
>         <CALUX5R0eAt7o5L01XQYpgktA=
> JuuqEkFhEmBupCn-C1avaz+-w at mail.gmail.com>
> 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 <orangerobot at gmail.com>:
>
> > 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
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160114/591cd9b9/attachment.html>