Dynamically record a h264 stream

[Davide Tuccilli]

I have a pipeline like this:

v4l2src device=/dev/video0 ! video/x-h264  ! tee ! queue ! h264parse !
omxh264dec ! glimagesink

And the stream is correctly displayed. I want to dynamically attach a
branch to the tee to save the stream into a mp4 file, and I'm using this
code to attach the recording branch:

     m_recordPad = gst_element_get_request_pad(m_tee, "src_%u");

     GstElement * queue     = gst_element_factory_make("queue", "recqueue");
     GstElement * h264parse = gst_element_factory_make("h264parse",
"rech264parse");
     GstElement * mux       = gst_element_factory_make("mp4mux", "recmux");
     GstElement * fileSink  = gst_element_factory_make("filesink",
"recfilesink");

     g_object_set(G_OBJECT(fileSink), "location", filename, nullptr);

     gst_bin_add_many(GST_BIN(m_pipeline), queue, h264parse, mux,
fileSink, nullptr);

     if (gst_element_link_many(queue, h264parse, mux, fileSink, nullptr)) {

         GstPad * sinkpad = gst_element_get_static_pad(queue, "sink");

         gst_element_sync_state_with_parent(queue);
         gst_element_sync_state_with_parent(h264parse);
         gst_element_sync_state_with_parent(mux);
         gst_element_sync_state_with_parent(fileSink);

         if (!GST_PAD_LINK_FAILED(gst_pad_link(m_recordPad, sinkpad))) {
             return true;
         }

         gst_object_unref(sinkpad);

     }

     return false;

It should be extremely similiar to what I've found here
https://coaxion.net/blog/2014/01/gstreamer-dynamic-pipelines/

Now, when I try to start recording, every frame is dropped with messages
like this:

0:01:23.413955057  1546 0x6bb03340 WARN               h264parse
gsth264parse.c:1205:gst_h264_parse_handle_frame:<rech264parse>
broken/invalid nal Type: 1 Slice, Size: 6860 will be dropped

Am I doing this wrong? How can h264parse fail on the recording branch
when it succeeds on the decoding one?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Fr, 2016-03-18 at 04:59 +0100, Davide Tuccilli wrote:

> I have a pipeline like this:
>
> v4l2src device=/dev/video0 ! video/x-h264  ! tee ! queue ! h264parse ! 
> omxh264dec ! glimagesink
> [...]
>
> Now, when I try to start recording, every frame is dropped with messages 
> like this:
>
> 0:01:23.413955057  1546 0x6bb03340 WARN               h264parse 
> gsth264parse.c:1205:gst_h264_parse_handle_frame: 
> broken/invalid nal Type: 1 Slice, Size: 6860 will be dropped
>
> Am I doing this wrong? How can h264parse fail on the recording branch 
> when it succeeds on the decoding one?

That's indeed a good question. Does it work better if you put the
h264parse in front of the tee? What stream-format and alignment is
output by h264parse?

You will also need to ensure that (ideally) the recorded stream starts
with a keyframe and SPS/PPS.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Davide Tuccilli]

> That's indeed a good question. Does it work better if you put the
> h264parse in front of the tee? What stream-format and alignment is
> output by h264parse?
If I put it in front it does the same, if I put it in front and remove
the h264parse before the muxer the linking fails (not sure if this is to
be expected, I can remove it on the other branch, before the decoder,
once I put one before the tee).

This is the caps: video/x-h264, stream-format=(string)byte-stream,
alignment=(string)au, width=(int)720, height=(int)576,
framerate=(fraction)25/1, parsed=(boolean)true, profile=(string)high,
level=(string)3

The parsed=true is because it's taken with the h264parse before the tee.
> You will also need to ensure that (ideally) the recorded stream starts
> with a keyframe and SPS/PPS.
How would I do that? Another thing that I didn't say is that I can
record the stream just fine without the tee (but I can't watch it of
course).
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Thornton, Keith]

Hi, If you want playable files you will need a parser and a caps filter to convert to avc after the tee but before your filesink.

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von Davide Tuccilli
Gesendet: Freitag, 18. März 2016 14:02
An: Discussion of the development of and with GStreamer
Betreff: Re: Dynamically record a h264 stream


> That's indeed a good question. Does it work better if you put the
> h264parse in front of the tee? What stream-format and alignment is
> output by h264parse?
If I put it in front it does the same, if I put it in front and remove the h264parse before the muxer the linking fails (not sure if this is to be expected, I can remove it on the other branch, before the decoder, once I put one before the tee).

This is the caps: video/x-h264, stream-format=(string)byte-stream,
alignment=(string)au, width=(int)720, height=(int)576, framerate=(fraction)25/1, parsed=(boolean)true, profile=(string)high,
level=(string)3

The parsed=true is because it's taken with the h264parse before the tee.
> You will also need to ensure that (ideally) the recorded stream starts
> with a keyframe and SPS/PPS.
How would I do that? Another thing that I didn't say is that I can record the stream just fine without the tee (but I can't watch it of course).
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Davide Tuccilli]

Thank you for the answer, although I don't know how to interpret it.

Since I'm not sure where to put the filter, I created this caps:

GstCaps * caps = gst_caps_new_simple("video/x-h264",
                                          "stream-format",
G_TYPE_STRING, "avc",
                                          nullptr);

And I tried to link each pair of consecutive elements with this filter:
meaning I tried between the queue and the h264parse first, but it failed
to link, then tried between h264parse and the mux and it still gave
broken NAL, then tried between the mux and the filesink and it failed to
link again.

On 18/03/2016 15:08, Thornton, Keith wrote:
> Hi, If you want playable files you will need a parser and a caps filter to convert to avc after the tee but before your filesink.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Fr, 2016-03-18 at 17:30 +0100, Davide Tuccilli wrote:
> Thank you for the answer, although I don't know how to interpret it.
>
> Since I'm not sure where to put the filter, I created this caps:
>
> GstCaps * caps = gst_caps_new_simple("video/x-h264",
>                                           "stream-format", 
> G_TYPE_STRING, "avc",
>                                           nullptr);

Use the capsfilter element and set those caps to its caps property.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Davide Tuccilli]

Oh I see, I thought it had the same effect. I've been trying to play around with the capsfilter, from my understanding h264parse does the conversion, so I should do something like queue ! capsfilter caps=video/x-h264,stream-format=avc ! h264parse ! mp4mux ! filesink, but when I do this, the linking between the tee src_%u pad and the queue sink pad fails.

On 19/03/2016 10:24, Sebastian Dröge wrote:

On Fr, 2016-03-18 at 17:30 +0100, Davide Tuccilli wrote:

Thank you for the answer, although I don't know how to interpret it.

Since I'm not sure where to put the filter, I created this caps:

GstCaps * caps = gst_caps_new_simple("video/x-h264",
                                          "stream-format", 
G_TYPE_STRING, "avc",
                                          nullptr);

Use the capsfilter element and set those caps to its caps property.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Sa, 2016-03-19 at 18:11 +0100, Davide Tuccilli wrote:
> Oh I see, I thought it had the same effect. I've been trying to play
> around with the capsfilter, from my understanding h264parse does the
> conversion, so I should do something like queue ! capsfilter
> caps=video/x-h264,stream-format=avc ! h264parse ! mp4mux ! filesink,
> but when I do this, the linking between the tee src_%u pad and the
> queue sink pad fails.

You will need one h264parse per branch then. Each of them can only
convert into one stream format, so the one before the tee might convert
into one that the mp4mux branch does not like.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Davide Tuccilli]

On 20/03/2016 10:35, Sebastian Dröge wrote:

On Sa, 2016-03-19 at 18:11 +0100, Davide Tuccilli wrote:

Oh I see, I thought it had the same effect. I've been trying to play
around with the capsfilter, from my understanding h264parse does the
conversion, so I should do something like queue ! capsfilter
caps=video/x-h264,stream-format=avc ! h264parse ! mp4mux ! filesink,
but when I do this, the linking between the tee src_%u pad and the
queue sink pad fails.

You will need one h264parse per branch then. Each of them can only
convert into one stream format, so the one before the tee might convert
into one that the mp4mux branch does not like.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

I've been trying a lot of things, and I noticed that I'm actually having problems even with a static pipeline that tries to achieve the same goal. I'm creating a pipeline like this:

{

    m_recordBin = gst_pipeline_new(nullptr);

    GstElement * v4l2src    = gst_element_factory_make("v4l2src", "recsource");
    GstElement * capsFilter = gst_element_factory_make("capsfilter", nullptr);
    GstElement * h264parse  = gst_element_factory_make("h264parse", nullptr);
    GstElement * mux        = gst_element_factory_make("mp4mux", nullptr);   // mpegtsmux, qtmux, mp4mux
    GstElement * muxCaps    = gst_element_factory_make("capsfilter", nullptr);
    GstElement * fileSink   = gst_element_factory_make("filesink", nullptr);

    g_object_set(G_OBJECT(fileSink), "location", filename, nullptr);
    g_object_set(G_OBJECT(fileSink), "sync", TRUE, nullptr);

    g_object_set(G_OBJECT(v4l2src), "device", "/dev/video1", nullptr);

    GstCaps * caps = gst_caps_new_simple("video/x-h264",
                                         "width", G_TYPE_INT, 720,
                                         "height", G_TYPE_INT, 576,
                                         "framerate", GST_TYPE_FRACTION, 25, 1,
                                         nullptr);

    g_object_set(G_OBJECT(capsFilter), "caps", caps, nullptr);

    GstCaps * capsavc = gst_caps_new_simple("video/x-h264",
                                            "stream-format", G_TYPE_STRING, "avc",
                                            "alignment", G_TYPE_STRING, "au",
                                            nullptr);

    g_object_set(G_OBJECT(muxCaps), "caps", capsavc, nullptr);

    gst_bin_add_many(GST_BIN(m_recordBin), v4l2src, capsFilter, h264parse, muxCaps, mux, fileSink, nullptr);

    if (!gst_element_link_many(v4l2src, capsFilter, h264parse, muxCaps, mux, fileSink, nullptr)) {
        return false;
    }
    else {
        return true;
    }

}

and the weird part is that some times it works, sometimes it doesn't and i get the same broken/invalid nal messages from h264parse

I created a function that iterates over the pads of this pipeline and prints the current caps, and when it works the result is like this:

filesink0 sink : video/quicktime, variant=(string)iso
mp4mux0 src : video/quicktime, variant=(string)iso
mp4mux0 video_0 : video/x-h264, stream-format=(string)avc, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1, parsed=(boolean)true, profile=(string)high, level=(string)4, codec_data=(buffer)01640028ffe1007267640028ad84054562b8ac5474202a2b15c562a3a1015158ae2b151d080a8ac57158a8e84054562b8ac5474202a2b15c562a3a10248521393c9f27e4fe4fc9f279b9b34d081242909c9e4f93f27f27e4f93cdcd9a6b405a093499000003e80000c350e040007a12000112a8bdef85e1108d401000468ee3c30
capsfilter1 sink : video/x-h264, stream-format=(string)avc, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1, parsed=(boolean)true, profile=(string)high, level=(string)4, codec_data=(buffer)01640028ffe1007267640028ad84054562b8ac5474202a2b15c562a3a1015158ae2b151d080a8ac57158a8e84054562b8ac5474202a2b15c562a3a10248521393c9f27e4fe4fc9f279b9b34d081242909c9e4f93f27f27e4f93cdcd9a6b405a093499000003e80000c350e040007a12000112a8bdef85e1108d401000468ee3c30
capsfilter1 src : video/x-h264, stream-format=(string)avc, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1, parsed=(boolean)true, profile=(string)high, level=(string)4, codec_data=(buffer)01640028ffe1007267640028ad84054562b8ac5474202a2b15c562a3a1015158ae2b151d080a8ac57158a8e84054562b8ac5474202a2b15c562a3a10248521393c9f27e4fe4fc9f279b9b34d081242909c9e4f93f27f27e4f93cdcd9a6b405a093499000003e80000c350e040007a12000112a8bdef85e1108d401000468ee3c30
h264parse0 sink : video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
h264parse0 src : video/x-h264, stream-format=(string)avc, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1, parsed=(boolean)true, profile=(string)high, level=(string)4, codec_data=(buffer)01640028ffe1007267640028ad84054562b8ac5474202a2b15c562a3a1015158ae2b151d080a8ac57158a8e84054562b8ac5474202a2b15c562a3a10248521393c9f27e4fe4fc9f279b9b34d081242909c9e4f93f27f27e4f93cdcd9a6b405a093499000003e80000c350e040007a12000112a8bdef85e1108d401000468ee3c30
capsfilter0 sink : video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
capsfilter0 src : video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
recsource src : video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1

When it doesn't the result is like this:

filesink0 sink : NULL
mp4mux0 src : NULL
mp4mux0 video_0 : NULL
capsfilter1 sink : NULL
capsfilter1 src : NULL
h264parse0 sink : video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
h264parse0 src : NULL
capsfilter0 sink : video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
capsfilter0 src : video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
recsource src : video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1

Any reason the current caps might result null for the muxer video_0/h264parse src pads? For what I understand, that's the problem right? I should have stream-format=avc there. I'm not sure how to debug this.


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Di, 2016-03-22 at 20:58 +0100, Davide Tuccilli wrote:
> 
>
> Any reason the current caps might result null for the muxer
> video_0/h264parse src pads? For what I understand, that's the problem
> right? I should have stream-format=avc there. I'm not sure how to
> debug this.

The problem seems to be that for whatever reason h264parse fails to
negotiate. It should indeed output AVC in your case, but it fails doing
so.

You'll have to debug from the debug logs why exactly h264parse fails.
You should also get an error about that, a negotiation error.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Davide Tuccilli]

On 23/03/2016 09:22, Sebastian Dröge wrote:

> On Di, 2016-03-22 at 20:58 +0100, Davide Tuccilli wrote:
>>  
>>
>> Any reason the current caps might result null for the muxer
>> video_0/h264parse src pads? For what I understand, that's the problem
>> right? I should have stream-format=avc there. I'm not sure how to
>> debug this.
> The problem seems to be that for whatever reason h264parse fails to
> negotiate. It should indeed output AVC in your case, but it fails doing
> so.
>
> You'll have to debug from the debug logs why exactly h264parse fails.
> You should also get an error about that, a negotiation error.
>

Seems to me that both in the "bad" log and the "good" log, the h264parse
and mux are linked correctly, this is taken from the bad log:


0:00:02.942548805 20077  0x12b3200 DEBUG  
            GST_CAPS
gstpad.c:2190:gst_pad_link_check_compatible_unlocked:<recsource:src> src
caps image/jpeg; video/mpeg, mpegversion=(int)4,
systemstream=(boolean)false; video/mpeg, mpegversion=(int)2;
video/mpegts, systemstream=(boolean)true; video/x-bayer,
format=(string){ bggr, gbrg, grbg, rggb }, width=(int)[ 1, 32768 ],
height=(int)[ 1, 32768 ], framerate=(fraction)[ 0/1, 2147483647/1 ];
video/x-dv, systemstream=(boolean)true; video/x-h263,
variant=(string)itu; video/x-h264, stream-format=(string)byte-stream,
alignment=(string)au; video/x-pwc1, width=(int)[ 1, 32768 ],
height=(int)[ 1, 32768 ], framerate=(fraction)[ 0/1, 2147483647/1 ];
video/x-pwc2, width=(int)[ 1, 32768 ], height=(int)[ 1, 32768 ],
framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw, format=(string){
RGB15, RGB16, BGR, RGB, BGRx, BGRA, xRGB, ARGB, GRAY8, YVU9, YV12, YUY2,
UYVY, Y42B, Y41B, NV12_64Z32, NV24, YUV9, I420, YVYU, NV61, NV16, NV21,
NV12 }, width=(int)[ 1, 32768 ], height=(int)[ 1, 32768 ],
framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-sonix, width=(int)[
1, 32768 ], height=(int)[ 1, 32768 ], framerate=(fraction)[ 0/1,
2147483647/1 ]; video/x-vp8
0:00:02.942828908 20077  0x12b3200 DEBUG  
            GST_CAPS
gstpad.c:2192:gst_pad_link_check_compatible_unlocked:<capsfilter0:sink>
sink caps video/x-h264, width=(int)720, height=(int)576,
framerate=(fraction)25/1
0:00:02.942910887 20077  0x12b3200 DEBUG  
            GST_CAPS
gstpad.c:2210:gst_pad_link_check_compatible_unlocked: caps are
compatible
0:00:02.942963022 20077  0x12b3200 INFO   
            GST_PADS gstpad.c:2496:gst_pad_link_full:
linked recsource:src and capsfilter0:sink, successful


0:00:04.479278218 18988  0x14c3200 DEBUG  
            GST_CAPS
gstpad.c:2190:gst_pad_link_check_compatible_unlocked:<capsfilter1:src>
src caps video/x-h264, stream-format=(string)avc, alignment=(string)au,
parsed=(boolean)true
0:00:04.479323217 18988  0x14c3200 DEBUG  
            GST_CAPS
gstpad.c:2192:gst_pad_link_check_compatible_unlocked:<mp4mux0:video_0>
sink caps video/mpeg, mpegversion=(int)4, systemstream=(boolean)false,
width=(int)[ 16, 2147483647 ], height=(int)[ 16, 2147483647 ];
video/x-divx, divxversion=(int)5, width=(int)[ 16, 2147483647 ],
height=(int)[ 16, 2147483647 ]; video/x-h264, stream-format=(string)avc,
alignment=(string)au, width=(int)[ 16, 2147483647 ], height=(int)[ 16,
2147483647 ]; video/x-mp4-part, width=(int)[ 16, 2147483647 ],
height=(int)[ 16, 2147483647 ]
0:00:04.479417019 18988  0x14c3200 DEBUG  
            GST_CAPS
gstpad.c:2210:gst_pad_link_check_compatible_unlocked: caps are
compatible
0:00:04.479457696 18988  0x14c3200 INFO   
            GST_PADS gstpad.c:2496:gst_pad_link_full:
linked capsfilter1:src and mp4mux0:video_0, successful


Anything else I might want to look for in the log, or any reason I can
get null when calling gst_pad_get_sticky_event?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Davide Tuccilli]

On 23/03/2016 15:37, Davide Tuccilli wrote:
>
> Anything else I might want to look for in the log, or any reason I can
> get null when calling gst_pad_get_sticky_event?

Sorry, I meant gst_pad_get_current_caps of course.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Mi, 2016-03-23 at 15:37 +0100, Davide Tuccilli wrote:

>
> On 23/03/2016 09:22, Sebastian Dröge wrote:
> >
> > On Di, 2016-03-22 at 20:58 +0100, Davide Tuccilli wrote:
> > >
> > >   
> > >
> > > Any reason the current caps might result null for the muxer
> > > video_0/h264parse src pads? For what I understand, that's the problem
> > > right? I should have stream-format=avc there. I'm not sure how to
> > > debug this.
> > The problem seems to be that for whatever reason h264parse fails to
> > negotiate. It should indeed output AVC in your case, but it fails doing
> > so.
> >
> > You'll have to debug from the debug logs why exactly h264parse fails.
> > You should also get an error about that, a negotiation error.
> >
>
> Seems to me that both in the "bad" log and the "good" log, the h264parse 
> and mux are linked correctly, this is taken from the bad log:
>
>
> 0:00:02.942548805 20077  0x12b3200 DEBUG   
>             GST_CAPS 
> gstpad.c:2190:gst_pad_link_check_compatible_unlocked: src 
> caps image/jpeg; video/mpeg, mpegversion=(int)4, 
> systemstream=(boolean)false; video/mpeg, mpegversion=(int)2; 
> video/mpegts, systemstream=(boolean)true; video/x-bayer, 
> format=(string){ bggr, gbrg, grbg, rggb }, width=(int)[ 1, 32768 ], 
> height=(int)[ 1, 32768 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; 
> video/x-dv, systemstream=(boolean)true; video/x-h263, 
> variant=(string)itu; video/x-h264, stream-format=(string)byte-stream, 
> alignment=(string)au; video/x-pwc1, width=(int)[ 1, 32768 ], 
> height=(int)[ 1, 32768 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; 
> video/x-pwc2, width=(int)[ 1, 32768 ], height=(int)[ 1, 32768 ], 
> framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw, format=(string){ 
> RGB15, RGB16, BGR, RGB, BGRx, BGRA, xRGB, ARGB, GRAY8, YVU9, YV12, YUY2, 
> UYVY, Y42B, Y41B, NV12_64Z32, NV24, YUV9, I420, YVYU, NV61, NV16, NV21, 
> NV12 }, width=(int)[ 1, 32768 ], height=(int)[ 1, 32768 ], 
> framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-sonix, width=(int)[ 
> 1, 32768 ], height=(int)[ 1, 32768 ], framerate=(fraction)[ 0/1, 
> 2147483647/1 ]; video/x-vp8
> 0:00:02.942828908 20077  0x12b3200 DEBUG   
>             GST_CAPS 
> gstpad.c:2192:gst_pad_link_check_compatible_unlocked: 
> sink caps video/x-h264, width=(int)720, height=(int)576, 
> framerate=(fraction)25/1
> 0:00:02.942910887 20077  0x12b3200 DEBUG   
>             GST_CAPS 
> gstpad.c:2210:gst_pad_link_check_compatible_unlocked: caps are 
> compatible
> 0:00:02.942963022 20077  0x12b3200 INFO    
>             GST_PADS gstpad.c:2496:gst_pad_link_full: 
> linked recsource:src and capsfilter0:sink, successful
>
>
> 0:00:04.479278218 18988  0x14c3200 DEBUG   
>             GST_CAPS 
> gstpad.c:2190:gst_pad_link_check_compatible_unlocked: 
> src caps video/x-h264, stream-format=(string)avc, alignment=(string)au, 
> parsed=(boolean)true
> 0:00:04.479323217 18988  0x14c3200 DEBUG   
>             GST_CAPS 
> gstpad.c:2192:gst_pad_link_check_compatible_unlocked: 
> sink caps video/mpeg, mpegversion=(int)4, systemstream=(boolean)false, 
> width=(int)[ 16, 2147483647 ], height=(int)[ 16, 2147483647 ]; 
> video/x-divx, divxversion=(int)5, width=(int)[ 16, 2147483647 ], 
> height=(int)[ 16, 2147483647 ]; video/x-h264, stream-format=(string)avc, 
> alignment=(string)au, width=(int)[ 16, 2147483647 ], height=(int)[ 16, 
> 2147483647 ]; video/x-mp4-part, width=(int)[ 16, 2147483647 ], 
> height=(int)[ 16, 2147483647 ]
> 0:00:04.479417019 18988  0x14c3200 DEBUG   
>             GST_CAPS 
> gstpad.c:2210:gst_pad_link_check_compatible_unlocked: caps are 
> compatible
> 0:00:04.479457696 18988  0x14c3200 INFO    
>             GST_PADS gstpad.c:2496:gst_pad_link_full: 
> linked capsfilter1:src and mp4mux0:video_0, successful
>
>
> Anything else I might want to look for in the log, or any reason I can 
> get null when calling gst_pad_get_sticky_event?

Can you provide the full log, and also attach it to the mail instead of
pasting it? This one doesn't contain the actual error but only some
setup that happens before and all succeeds.

gst_pad_get_current_caps() will return NULL if no caps are negotiated
on the pad. That is, no caps event was received and accepted.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Davide Tuccilli]

On 25/03/2016 09:08, Sebastian Dröge wrote:

Can you provide the full log, and also attach it to the mail instead of pasting it? This one doesn't contain the actual error but only some setup that happens before and all succeeds. gst_pad_get_current_caps() will return NULL if no caps are negotiated on the pad. That is, no caps event was received and accepted.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Yes sure, the archive contains both a log with a successful negotiation and an unsuccessful one.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Davide Tuccilli]

On 25/03/2016 09:08, Sebastian Dröge wrote:
> Can you provide the full log, and also attach it to the mail instead
> of pasting it? This one doesn't contain the actual error but only some
> setup that happens before and all succeeds. gst_pad_get_current_caps()
> will return NULL if no caps are negotiated on the pad. That is, no
> caps event was received and accepted

I'm not too sure about the etiquette of the mailing list, i tried
attaching and received a message I should wait for approval and didn't
hear anything back. Maybe it's easier if I can just leave a link to the
file (here: https://www.dropbox.com/s/re82ytegvi9cjhf/log.zip?dl=0 ). In
any case, sorry for the double post.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel