New gst-player

New gst-player

[Gary Thomas]

I like that owl has been replaced by gst-player, but I need
some help figuring out how to get it working :-(  If you ask
it to play something and it doesn't have the appropriate
plugins available, it just sits there and acts stupid (no
error popup, nothing...).  For example, I tried to play a
MP4 file downloaded from YouTube and it complained:
   Now playing /home/root/Vlad+Louise.mp4
   Missing plugin: H.264 decoder
       ...
   Missing plugin: MPEG-4 AAC decoder
       ...
(those are only the relevant lines which I got by running it
by hand in a terminal window).

Any idea what I need to get installed to play this file?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: New gst-player

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On 4 March 2015 at 23:45, Gary Thomas <gary@mlbassoc.com> wrote:

> I like that owl has been replaced by gst-player, but I need
> some help figuring out how to get it working :-(  If you ask
> it to play something and it doesn't have the appropriate
> plugins available, it just sits there and acts stupid (no
> error popup, nothing...).  For example, I tried to play a
> MP4 file downloaded from YouTube and it complained:
>   Now playing /home/root/Vlad+Louise.mp4
>   Missing plugin: H.264 decoder
>       ...
>   Missing plugin: MPEG-4 AAC decoder
>       ...
> (those are only the relevant lines which I got by running it
> by hand in a terminal window).
>
> Any idea what I need to get installed to play this file?
>

Yes, we should probably patch it to hook into those signals and show a
dialog with more useful diagnostics.

If you have recent Intel HW, gstreamer-vaapi-1.0 will handle H264 in
hardware.  Otherwise gstreamer-libav has an AAC decoder and a software H264
decoder.

Ross

[-- Attachment #2: Type: text/html, Size: 1466 bytes --]

Re: New gst-player

[Gary Thomas]

On 2015-03-04 23:32, Burton, Ross wrote:
>
> On 4 March 2015 at 23:45, Gary Thomas <gary@mlbassoc.com <mailto:gary@mlbassoc.com>> wrote:
>
>     I like that owl has been replaced by gst-player, but I need
>     some help figuring out how to get it working :-(  If you ask
>     it to play something and it doesn't have the appropriate
>     plugins available, it just sits there and acts stupid (no
>     error popup, nothing...).  For example, I tried to play a
>     MP4 file downloaded from YouTube and it complained:
>        Now playing /home/root/Vlad+Louise.mp4
>        Missing plugin: H.264 decoder
>            ...
>        Missing plugin: MPEG-4 AAC decoder
>            ...
>     (those are only the relevant lines which I got by running it
>     by hand in a terminal window).
>
>     Any idea what I need to get installed to play this file?
>
>
> Yes, we should probably patch it to hook into those signals and show a dialog with more useful diagnostics.
>
> If you have recent Intel HW, gstreamer-vaapi-1.0 will handle H264 in hardware.  Otherwise gstreamer-libav has an AAC decoder and a software H264 decoder.

Intel hardware?  Nah, everything here is ARM :-)

Using gstreamer1.0-libav seems to work, but it's really power hungry
(i.e can cause my board's power supply over current!).  Does this
plugin just hook into libav?  I've tried playing the same file using
mplayer (which does use libav) and it doesn't have the same power
issues.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: New gst-player

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On 5 March 2015 at 12:16, Gary Thomas <gary@mlbassoc.com> wrote:

> Using gstreamer1.0-libav seems to work, but it's really power hungry
> (i.e can cause my board's power supply over current!).  Does this
> plugin just hook into libav?  I've tried playing the same file using
> mplayer (which does use libav) and it doesn't have the same power
> issues.
>

Yes, gstreamer1.0-libav is a wrapper around libav.  gstreamer1.0-libav does
default to using an internal copy of libav instead of the system one, but
that's a PACKAGECONFIG away from being changed - assuming that it builds -
and might help.

Ross

[-- Attachment #2: Type: text/html, Size: 1031 bytes --]

Re: New gst-player

[Gary Thomas]

On 2015-03-05 05:45, Burton, Ross wrote:
>
> On 5 March 2015 at 12:16, Gary Thomas <gary@mlbassoc.com <mailto:gary@mlbassoc.com>> wrote:
>
>     Using gstreamer1.0-libav seems to work, but it's really power hungry
>     (i.e can cause my board's power supply over current!).  Does this
>     plugin just hook into libav?  I've tried playing the same file using
>     mplayer (which does use libav) and it doesn't have the same power
>     issues.
>
>
> Yes, gstreamer1.0-libav is a wrapper around libav.  gstreamer1.0-libav does default to using an internal copy of libav instead of the system one, but that's a PACKAGECONFIG away
> from being changed - assuming that it builds - and might help.

Thanks, I'll give it a go.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: New gst-player

[Gary Thomas]

On 2015-03-05 05:54, Gary Thomas wrote:
> On 2015-03-05 05:45, Burton, Ross wrote:
>>
>> On 5 March 2015 at 12:16, Gary Thomas <gary@mlbassoc.com <mailto:gary@mlbassoc.com>> wrote:
>>
>>     Using gstreamer1.0-libav seems to work, but it's really power hungry
>>     (i.e can cause my board's power supply over current!).  Does this
>>     plugin just hook into libav?  I've tried playing the same file using
>>     mplayer (which does use libav) and it doesn't have the same power
>>     issues.
>>
>>
>> Yes, gstreamer1.0-libav is a wrapper around libav.  gstreamer1.0-libav does default to using an internal copy of libav instead of the system one, but that's a PACKAGECONFIG away
>> from being changed - assuming that it builds - and might help.
>
> Thanks, I'll give it a go.
>

Sadly, it doesn't build with the libav we have in OE-core :-(

BTW, I measured the current used by my board (i.MX6Q)
   mplayer2 => 1.8A
   gst-play => 2.1A
Given that I normally run my board with a 2.0A wall brick,
it's no wonder that it dies when I run gst-play.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: New gst-player

[Nicolas Dechesne]

On Thu, Mar 5, 2015 at 2:34 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> Sadly, it doesn't build with the libav we have in OE-core :-(
>
> BTW, I measured the current used by my board (i.MX6Q)
>   mplayer2 => 1.8A
>   gst-play => 2.1A
> Given that I normally run my board with a 2.0A wall brick,
> it's no wonder that it dies when I run gst-play.

ouch. that's quite a difference. when you play video this is no just
about the decoders, but also how video is rendered. can you
check/compare what's the overall pipeline, including any processing
done on the video buffers (YUV) after the decoder (including up/down
scaling, color conversion, ...).

cheers
nico

Re: New gst-player

[Gary Thomas]

On 2015-03-05 06:40, Nicolas Dechesne wrote:
> On Thu, Mar 5, 2015 at 2:34 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> Sadly, it doesn't build with the libav we have in OE-core :-(
>>
>> BTW, I measured the current used by my board (i.MX6Q)
>>    mplayer2 => 1.8A
>>    gst-play => 2.1A
>> Given that I normally run my board with a 2.0A wall brick,
>> it's no wonder that it dies when I run gst-play.
>
> ouch. that's quite a difference. when you play video this is no just
> about the decoders, but also how video is rendered. can you
> check/compare what's the overall pipeline, including any processing
> done on the video buffers (YUV) after the decoder (including up/down
> scaling, color conversion, ...).

How would I get that info (short of hacking the library)?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: New gst-player

[Nicolas Dechesne]

On Thu, Mar 5, 2015 at 2:44 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2015-03-05 06:40, Nicolas Dechesne wrote:
>>
>> On Thu, Mar 5, 2015 at 2:34 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>
>>> Sadly, it doesn't build with the libav we have in OE-core :-(
>>>
>>> BTW, I measured the current used by my board (i.MX6Q)
>>>    mplayer2 => 1.8A
>>>    gst-play => 2.1A
>>> Given that I normally run my board with a 2.0A wall brick,
>>> it's no wonder that it dies when I run gst-play.
>>
>>
>> ouch. that's quite a difference. when you play video this is no just
>> about the decoders, but also how video is rendered. can you
>> check/compare what's the overall pipeline, including any processing
>> done on the video buffers (YUV) after the decoder (including up/down
>> scaling, color conversion, ...).
>
>
> How would I get that info (short of hacking the library)?


for Gstreamer you can print/display the actual pipeline by doing:

export GST_DEBUG_DUMP_DOT_DIR=/tmp

and then run your standard Gstreamer application, it will create .dot
files in /tmp (you can use another folder), at each stage of the
pipeline, you can print/share the pipeline when transitioning from
PAUSE to PLAYING. The .dot file can be converted to a nice graph,
using graphviz tool (e.g. dot -Tpng -O xxx.dot)

that will give you all the information about the multimedia pipeline.

for mplayer, i don't know how to get the same info..

Re: New gst-player

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

On 2015-03-05 06:47, Nicolas Dechesne wrote:
> On Thu, Mar 5, 2015 at 2:44 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> On 2015-03-05 06:40, Nicolas Dechesne wrote:
>>>
>>> On Thu, Mar 5, 2015 at 2:34 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>
>>>> Sadly, it doesn't build with the libav we have in OE-core :-(
>>>>
>>>> BTW, I measured the current used by my board (i.MX6Q)
>>>>     mplayer2 => 1.8A
>>>>     gst-play => 2.1A
>>>> Given that I normally run my board with a 2.0A wall brick,
>>>> it's no wonder that it dies when I run gst-play.
>>>
>>>
>>> ouch. that's quite a difference. when you play video this is no just
>>> about the decoders, but also how video is rendered. can you
>>> check/compare what's the overall pipeline, including any processing
>>> done on the video buffers (YUV) after the decoder (including up/down
>>> scaling, color conversion, ...).
>>
>>
>> How would I get that info (short of hacking the library)?
>
>
> for Gstreamer you can print/display the actual pipeline by doing:
>
> export GST_DEBUG_DUMP_DOT_DIR=/tmp
>
> and then run your standard Gstreamer application, it will create .dot
> files in /tmp (you can use another folder), at each stage of the
> pipeline, you can print/share the pipeline when transitioning from
> PAUSE to PLAYING. The .dot file can be converted to a nice graph,
> using graphviz tool (e.g. dot -Tpng -O xxx.dot)
>
> that will give you all the information about the multimedia pipeline.

I ran the gst-play-1.0 and it created a single file.  It looks pretty
when converted to an image, but I'm not sure what it tells me about
the actual pipeline.

>
> for mplayer, i don't know how to get the same info..
>

Given that it's the same file being played on the same hardware,
shouldn't both programs need to be doing the same conversions, etc?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[-- Attachment #2: 0.00.00.616955667-gst-play.async-done.dot --]
[-- Type: application/msword-template, Size: 29209 bytes --]

[-- Attachment #3: 0.00.00.616955667-gst-play.async-done.dot.png --]
[-- Type: image/png, Size: 1293133 bytes --]

Re: New gst-player

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On 5 March 2015 at 14:10, Gary Thomas <gary@mlbassoc.com> wrote:

> Given that it's the same file being played on the same hardware,
> shouldn't both programs need to be doing the same conversions, etc?
>

In theory, yes.  I note that in this pipeline GStreamer is using libav to
decode the video and then displaying it using GL, so maybe that's a
difference and mplayer isn't using GL but something else.

You can manually construct a pipeline using 'gst-launch-1.0 playbin
uri=file:///... video-sink=[some sink name]' to try different sinks.

Ross

[-- Attachment #2: Type: text/html, Size: 1076 bytes --]