v4l2 element stay in READY state
Sérgio Agostinho
sergio.r.agostinho at gmail.com
Fri Feb 13 04:59:59 PST 2015
I would say dump the entire log on pastebin so that we can see it and in
the meantime (if you have the option) you can try upgrading to the latest
version 1.4.5 to see if the problem persists.
Cheers
2015-02-13 13:01 GMT+01:00 Russell <danrenjian at gmail.com>:
> Hi,
>
> Setting GST_DEBUG did give me much more messages in the output, but I
> couldn't find any warning or errors.
> Most DEBUG messages are about internals of decodebin, and following is the
> last few lines. I get this both through gst-launtch-1.0 and my own c
> program:
>
> 0:00:02.675222833 10239 0x7f7160002370 DEBUG decodebin
> gstdecodebin2.c:4023:gst_decode_bin_expose:<decodebin0> Exposed everything
> 0:00:02.675288957 10239 0x7f7160002370 DEBUG v4l2sink
> gstv4l2sink.c:509:gst_v4l2sink_set_caps:<v4l2sink0> caps: video/x-raw,
> format=(string)I420, width=(int)1280, height=(int)720,
> pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive,
> colorimetry=(string)bt709, framerate=(fraction)25/1
> 0:00:02.676007155 10239 0x7f7160002370 INFO v4l2sink
> gstv4l2sink.c:533:gst_v4l2sink_set_caps:<v4l2sink0> outputting buffers via
> mmap()
> 0:00:02.676039389 10239 0x7f7160002370 DEBUG v4l2sink
> gstv4l2sink.c:587:gst_v4l2sink_propose_allocation:<v4l2sink0> we had a pool
> with caps video/x-raw, format=(string)I420, width=(int)1280,
> height=(int)720, pixel-aspect-ratio=(fraction)1/1,
> interlace-mode=(string)progressive, colorimetry=(string)bt709,
> framerate=(fraction)25/1
> 0:00:02.686470601 10239 0x7f7160002370 DEBUG v4l2sink
> gstv4l2sink.c:587:gst_v4l2sink_propose_allocation:<v4l2sink0> we had a pool
> with caps video/x-raw, format=(string)I420, width=(int)1280,
> height=(int)720, pixel-aspect-ratio=(fraction)1/1,
> interlace-mode=(string)progressive, colorimetry=(string)bt709,
> framerate=(fraction)25/1
>
> Here is my version of gst-launtch and gstreamer if that matters:
> gst-launch-1.0 version 1.2.4
> GStreamer 1.2.4
>
>
>
> On Fri, Feb 13, 2015 at 4:47 AM, Chuck Crisler <ccrisler at mutualink.net>
> wrote:
>
>> Also, when you see something that says 'WARNING' or 'ERROR', copy several
>> lines around those lines and post them here.
>>
>> On Thu, Feb 12, 2015 at 3:36 PM, Sérgio Agostinho <
>> sergio.r.agostinho at gmail.com> wrote:
>>
>>> Indeed, follow Chuck's advice and in the meantime make some more
>>> experiments.
>>>
>>> What happens if you try to set all elements to PAUSE and then to PLAY
>>> again (once they're linked)? Try to set the rtspsrc and the decodebin to
>>> PAUSE before linking the v4l2sink and then set everything to PLAY.
>>>
>>> Cheers
>>>
>>> 2015-02-12 20:34 GMT+01:00 Chuck Crisler <ccrisler at mutualink.net>:
>>>
>>>> It sounds like it is time to crank up logging on the decodebin and
>>>> v4l2sink elements to see what is(n't) happening.
>>>>
>>>> Something like:
>>>> export GST_DEBUG=decodebin:5,v4l2sink:5
>>>>
>>>> This should generate enough messages to understand what is failing.
>>>>
>>>> On Thu, Feb 12, 2015 at 5:05 AM, Russell <danrenjian at gmail.com> wrote:
>>>>
>>>>> By the way, target v4l2 device is created by v4l2loopback
>>>>> <https://github.com/umlaeute/v4l2loopback>
>>>>> Besides, I have output the caps of all pads (static or dynamic) of
>>>>> these elements whenever one of them change states. They seem to be fixed at
>>>>> the end. That is, (dynamic) src pad of rtspsrc and sink pad of decodebin
>>>>> have same fixed caps, and (dynamic) src pad of decodebin and sink pad of
>>>>> v4l2sink have same fixed caps. Does that mean the caps negotiation is
>>>>> completed?
>>>>>
>>>>> Thanks,
>>>>> Russell
>>>>>
>>>>> On Thu, Feb 12, 2015 at 5:58 PM, Russell <danrenjian at gmail.com> wrote:
>>>>>
>>>>>> fakesink works, too.
>>>>>> rtspsrc, decodebin and fakesink (as well as the pipeline itself) are
>>>>>> all in PLAYING state at the end.
>>>>>>
>>>>>> Thanks,
>>>>>> Russell
>>>>>>
>>>>>> On Thu, Feb 12, 2015 at 5:46 PM, Russell <danrenjian at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> autovideosink in code works ok, will give fakesink a try.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Russell
>>>>>>>
>>>>>>> On Thu, Feb 12, 2015 at 5:03 PM, Sérgio Agostinho <
>>>>>>> sergio.r.agostinho at gmail.com> wrote:
>>>>>>>
>>>>>>>> Just for completion, do you have the same issue if you replace
>>>>>>>> v4l2sink for fakesink and then for an autovideosink *in your code*.
>>>>>>>> Trying to understand if this is something specific about the way you're
>>>>>>>> connecting v4l2sink or just live sinks in general.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Sérgio
>>>>>>>>
>>>>>>>> 2015-02-12 7:44 GMT+01:00 Russell <danrenjian at gmail.com>:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Here is how I add and link decodebin and v4l2sink into pipeline:
>>>>>>>>>
>>>>>>>>> 1. When a new src pad is created for rtspsrc
>>>>>>>>> 1. add decodebin to pipeline
>>>>>>>>> 2. set decodebin to PLAYING async
>>>>>>>>> 3. link src pad of rtspsrc to sink pad of decodebin
>>>>>>>>> 2. When a new src pad is created for decodebin
>>>>>>>>> 1. add v4l2sink to pipeline
>>>>>>>>> 2. set v4l2sink to PLAYING async
>>>>>>>>> 3. link src pad of decodebin to sink pad of v4l2sink
>>>>>>>>>
>>>>>>>>> Eventually, rtspsrc will be PLAYING, decodebin be PAUSED, and
>>>>>>>>> v4l2sink be READY.
>>>>>>>>>
>>>>>>>>> But if I detect state change for decodebin, so what when it move
>>>>>>>>> to PAUSED, I set its state to PLAYING asyc again, then eventually decodebin
>>>>>>>>> would be in PLAYING state.
>>>>>>>>> v4l2sink would always be READY state even if I set its state
>>>>>>>>> several times like decodebin.
>>>>>>>>>
>>>>>>>>> And, If I only did 1 and no 2 as decribed above (that is, without
>>>>>>>>> adding and linking for v4l2sink), then both rtspsrc and decodebin would be
>>>>>>>>> in PLAYING state.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is there anything else I can try??
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Russell
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Feb 12, 2015 at 9:06 AM, Russell <danrenjian at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi, Wonchul
>>>>>>>>>>
>>>>>>>>>> How can I confirm whether v4l2sink receives any buffer, are there
>>>>>>>>>> any logs that I can inspect?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Russell
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Feb 11, 2015 at 10:06 PM, Wonchul Lee <chul0812 at gmail.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I guess that v4l2sink didn't receive any buffer.
>>>>>>>>>>> Sink element what inherited from basesink will change to PAUSED
>>>>>>>>>>> states
>>>>>>>>>>> after receiving a buffer for preroll.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-states.txt#n41
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2015-02-11 18:23 GMT+09:00 Sérgio Agostinho <
>>>>>>>>>>> sergio.r.agostinho at gmail.com>:
>>>>>>>>>>> > Hi Russel,
>>>>>>>>>>> >
>>>>>>>>>>> > If you do
>>>>>>>>>>> >
>>>>>>>>>>> > gst-launch-1.0 videotestsrc ! v4l2sink
>>>>>>>>>>> >
>>>>>>>>>>> > do you see video on your v4l2device? Also, if you do
>>>>>>>>>>> >
>>>>>>>>>>> > gst-launch-1.0 rtspsrc location=rtspaddress ! decodebin !
>>>>>>>>>>> autovideosink
>>>>>>>>>>> >
>>>>>>>>>>> > Do you see your rtsp video stream playing on a window?
>>>>>>>>>>> >
>>>>>>>>>>> > Cheers
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > 2015-02-11 7:50 GMT+01:00 Russell <danrenjian at gmail.com>:
>>>>>>>>>>> >>
>>>>>>>>>>> >> Hi,
>>>>>>>>>>> >>
>>>>>>>>>>> >> I was trying this pipeline to feed rtsp stream into a v4l2
>>>>>>>>>>> virtual
>>>>>>>>>>> >> loopback device:
>>>>>>>>>>> >> gst-launch-1.0 rtspsrc location=rtspaddress ! decodebin !
>>>>>>>>>>> v4l2sink
>>>>>>>>>>> >>
>>>>>>>>>>> >> Terminal gave this output and stops, and there are no video
>>>>>>>>>>> in the v4l2
>>>>>>>>>>> >> device:
>>>>>>>>>>> >> Progress: (request) Sending PLAY request
>>>>>>>>>>> >> Progress: (request) Sending PLAY request
>>>>>>>>>>> >> Progress: (request) Sent PLAY request
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> So I am implementing the pipeline in c to see what happened.
>>>>>>>>>>> decodebin and
>>>>>>>>>>> >> v4l2sink are added and linked on on pad-added event.
>>>>>>>>>>> Eventually I found the
>>>>>>>>>>> >> v4l2sink element stay in READY state while the other two are
>>>>>>>>>>> PLAYING. I have
>>>>>>>>>>> >> set v4l2sink to PLAYING asynchronously but the state does not
>>>>>>>>>>> change.
>>>>>>>>>>> >>
>>>>>>>>>>> >> What is the matter here? and where I can find any detailed
>>>>>>>>>>> reason why
>>>>>>>>>>> >> v4l2sink cannot go to PLAYING state?
>>>>>>>>>>> >>
>>>>>>>>>>> >> Thanks in advance.
>>>>>>>>>>> >>
>>>>>>>>>>> >> Sincerely,
>>>>>>>>>>> >> Russell
>>>>>>>>>>> >>
>>>>>>>>>>> >> _______________________________________________
>>>>>>>>>>> >> gstreamer-devel mailing list
>>>>>>>>>>> >> gstreamer-devel at lists.freedesktop.org
>>>>>>>>>>> >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>>> >>
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>> > gstreamer-devel mailing list
>>>>>>>>>>> > gstreamer-devel at lists.freedesktop.org
>>>>>>>>>>> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>>> >
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> gstreamer-devel mailing list
>>>>>>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> gstreamer-devel mailing list
>>>>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> gstreamer-devel mailing list
>>>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> gstreamer-devel mailing list
>>>>> gstreamer-devel at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>
> _______________________________________________
> 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/20150213/5304a87a/attachment-0001.html>
More information about the gstreamer-devel
mailing list