v4l2 element stay in READY state

Thu Feb 12 12:36:07 PST 2015

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150212/20226db8/attachment.html>