gst-play does not go to PLAYING when using hardware decoder sinks

[Sachs Jürgen]

Hallo together,
we are developing gstreamer sink-elements to support hardware decoders. That is, we do not need to use some kind of image sink, instead we feed the _encoded_ data directly into hardware.

Now, when using gst-play-1.0 to render a file, we get unexpected behavior:
- when invoking gst-play with the parameters --videosink/audiosink the file is played as expected:
   # gst-play-1.0 --videosink=fakedecodervideo --audiosink=fakedecoderaudio <somefile>

- when invoking without this parameters,
   # gst-play-1.0 <somefile>
the pipeline stops after prerolling/buffering.

Does anybody have an idea, why the playbin does not go to the running state?

In the failure case I see the following output from gst-play
  Now playing <somefile>
  Prerolling...
  Buffering... 100%
  <nothing more>
Our decoder element keep in pause state.

To eliminate all decoder-related effects, I have written two very simple "fake"-decoder elements:
- derived from GstBaseSink
- reporting proper caps ("video/...", audio/...")
- implementing start, stop, set_caps and render, mainly for debug trace - no real functionality inside

With this elements the behavior is the same.
Does somebody have an idea, what's going wrong?

Attached is a file with
 - gst-inspect output of our fake-elements
 - pipeline image for both cases
 
 Kind regards
 Juergen

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

[Sebastian Dröge-3]

On Fri, 2016-10-14 at 12:26 +0200, Sachs Jürgen wrote:
>
> [...]
> With this elements the behavior is the same. 
> Does somebody have an idea, what's going wrong?

Without more information, we can only guess here. You would have to
ideally provide a test-case to reproduce the problem, or at least a
debug log so we can see where exactly it gets stuck.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sachs Jürgen]

Hallo Sebastian,
thanks for your response. I assumed a general issue when using audio/video "decoders" instead of "pulseaudio"/"image sinks".

The test-cases are very simple:
Test-case 1: OK: this runs
  $  gst-play-1.0 --videosink=fakedecodervideo --audiosink=fakedecoderaudio "http://192.168.0.2/media/video/mp4/Wax_%20_Rosana_%20(Official Music Video)_2.mp4"

Test-case 2: fail: this stops after prefetching
$  gst-play-1.0 "http://192.168.0.2/media/video/mp4/Wax_%20_Rosana_%20(Official Music Video)_2.mp4"

The logfiles for the settings I've attached: (I hope "GST_DEBUG=playbin:9" is enough)
  fakedecoder-gst-play-sinks-specified.txt for test-case 1 (OK)
  fakedecoder-gst-play.txt for test-case 2 (fail)
I've also attached the sources for the "fake-decoder" for reference. The resulted pipelines where already attached to my last e-mail.

Kind regards
/Juergen

> From: Sebastian Dröge <[hidden email]>
> Subject: Re: gst-play does not go to PLAYING when using hardware
> decoder sinks
>
> On Fri, 2016-10-14 at 12:26 +0200, Sachs Jürgen wrote:
>>
>> [...]
>> With this elements the behavior is the same. Does somebody have an
>> idea, what's going wrong?
>Without more information, we can only guess here. You would have to ideally provide a test-case
> to reproduce the problem, or at least a debug log so we can see where exactly it gets stuck.

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

[Juergen Sachs]

Sachs Jürgen wrote

we are developing gstreamer sink-elements to support hardware decoders. That is, we do not need to use some kind of image sink, instead we feed the _encoded_ data directly into hardware.

Now, when using gst-play-1.0 to render a file, we get unexpected behavior:
- when invoking gst-play with the parameters --videosink/audiosink the file is played as expected:
   # gst-play-1.0 --videosink=fakedecodervideo --audiosink=fakedecoderaudio <somefile>

- when invoking without this parameters,
   # gst-play-1.0 <somefile>
the pipeline stops after prerolling/buffering.

[...]

I think the problem is localized meanwhile: The hardware decoder sink elements have to be classified as "Sink". When an element is classified as "Decoder" and does not have any output pin, the autoplugging does not finish.

[Sebastian Dröge-3]

On Wed, 2016-10-19 at 07:11 -0700, Juergen Sachs wrote:

> Sachs Jürgen wrote
> > we are developing gstreamer sink-elements to support hardware decoders.
> > That is, we do not need to use some kind of image sink, instead we feed
> > the _encoded_ data directly into hardware. 
> >
> > Now, when using gst-play-1.0 to render a file, we get unexpected behavior:
> > - when invoking gst-play with the parameters --videosink/audiosink the
> > file is played as expected:
> >    # gst-play-1.0 --videosink=fakedecodervideo
> > --audiosink=fakedecoderaudio 
> > <somefile>
> > - when invoking without this parameters, 
> >    # gst-play-1.0 
> > <somefile>
> > the pipeline stops after prerolling/buffering.
> >
> > [...]
>
> I think the problem is localized meanwhile: The hardware decoder sink
> elements have to be classified as "Sink". When an element is classified as
> "Decoder" and does not have any output pin, the autoplugging does not
> finish.

Yes that makes sense. decodebin would wait forever for a srcpad to
appear otherwise.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel