H.264 UDP recording improvements?

[Gerard Toonstra]

Well, one step further. I'm not sure how well this is supposed to work, but I'm getting consistent results. 

I've added config-interval to the h264parse which on a failed run gave me the codec_data buffer. I picked up this codec_data buffer and inserted this into the caps before the mp4mux before the filesink.
The matroskamux allows it, but produces an incorrect file. The mp4mux now produces a playable file with only some incorrect frames at the start, until the next keyframe.


./gst-launch-0.10 -e -vvv udpsrc multicast-group=239.255.12.12 port=5004 auto-multicast=true caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264,payload=(int)96" typefind=true ! rtph264depay ! tee name=my_sink ! queue !  "video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal" ! ffdec_h264 ! videorate ! ffmpegcolorspace ! autovideosink sync=false my_sink. ! queue ! h264parse config-interval=50 ! "video/x-h264,width=(int)1280,height=(int)720,codec_data=(buffer)01428033ffe1000967428033e900a00b7201000468ce3c80" ! mp4mux ! filesink location=/Users/gt/movie.mp4


When I code this into a C application however, h264parse doesn't want to be linked to mp4mux. The (buffer) type is a special type that
needs some special care. Here's what I'm doing:

    GstBuffer *codec_data;
    GValue value = { 0 };
    g_value_init (&value, GST_TYPE_BUFFER);
    gst_value_deserialize (&value, "01428033ffe1000967428033e900a00b7201000468ce3c80");
    codec_data = gst_value_get_buffer (&value);
    
    incaps = gst_caps_new_simple("video/x-h264",
                                 "width", G_TYPE_INT, "1280",
                                 "height", G_TYPE_INT, "720",
                                 "codec_data", GST_TYPE_BUFFER, codec_data,
                                 NULL) ;
    link_ok = gst_element_link_filtered(h264parse, mp4mux, incaps);
    gst_caps_unref(incaps) ;
    g_value_unset (&value);
    if (!link_ok) {
        g_print ("Failed to link h264parse to mp4mux!\n");
        return;
    }

G>

On Jan 17, 2013, at 12:49 PM, Gerard Toonstra <gtoonstra at gmail.com> wrote:

> Hi all,
> 
> I'm attempting to record a UDPSRC stream from an IP camera to disk without re-encoding the stream. This is on a PC that has relatively limited CPU capacity left, as it's also 
> doing other complex things with the video. So preserving CPU utilization is what I'm trying to do.
> 
> On the internet, I found one topic where someone else was looking for the same thing, but this didn't help me much in the end.
> 
> http://lists.freedesktop.org/archives/gstreamer-devel/2012-May/035999.html
> 
> and: 
> 
> http://lists.freedesktop.org/archives/gstreamer-devel/2010-June/027112.html
> 
> 
> when I use the "rtph264depay ! h264parse ! matroskamux ! filesink" pipeline, it fails on caps negotiation. This is because matroskamux doesn't have access to the encoding parameters. I had
> expected h264parse to produce those.
> 
> When I start a desktop capture and copy the sprop-params across, the above pipeline works flawlessly. I don't have those details from the IP camera, however, I can only specify width/height.
> I can get matroskamux to work if I also specify framerate in "video/x-h264,width=640,height=360,framerate=25/1".  It seems to write to the file, but it is not playable. ffplay and mplayer complain
> about missing encoding parameters (surprise) or "no frame!" errors.  This is I think due to missing "codec_data", as specified here:
> 
> http://gstreamer-devel.966125.n4.nabble.com/Setting-codec-data-in-h264-caps-for-qtmux-td4525597.html
> 
> Setting "config-interval" on h264parse did not help.
> 
> So, what i now use is the following:
> 
> gst-launch-0.10 udpsrc multicast-group=239.255.12.12 auto-multicast=true port=5004 ! "application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264,payload=(int)96" ! gstrtpjitterbuffer drop-on-latency=true latency=40 ! rtph264depay ! h264parse ! "video/x-h264,width=(int)640,height=(int)360" ! filesink location=movie.264 sync=false
> 
> This produces a movie.264 file and this is playable through mplayer. However, I'm seeing different results if I use kdenlive for editing for example, which plays 1 fps, so I'd prefer the mux to be used.
> 
> Is there a way to:
> - add the codec_data by adding something in the pipeline?
> - extract the codec_data from the RTP stream and just pass that to the muxer?
> 
> Rgds,
> 
> G>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130117/fccecd83/attachment.html>