imxipuvideosink in 3.10.53 on Nitrogex6xlite

imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Paweł Żabiełowicz]

Hi all,

I'm having some problems running video playback on Nitrogen6x-Lite. I'm 
using fido with 3.10.53 kernel. Display is running properly as I see a 
console after start, but starting any simple video with Gstreamer1.0 + 
gstreamer-imx plugins does not give any video output, even though the 
decoding looks like it's working.

Gstreamer log:
gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579 
192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec ! 
imxipuvideosink
[INFO]	Product Info: i.MX6Q/D/S
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://192.168.7.24:554/profile3/media.smp
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (request) SETUP stream 1
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending PLAY request
Progress: (request) Sending PLAY request
Progress: (request) Sent PLAY request
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:15.125067669
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

Plugins installed:

gst-inspect-1.0 | grep imx
imxipu:  imxipuvideotransform: Freescale IPU video transform
imxipu:  imxipuvideosink: Freescale IPU video sink
imxvpu:  imxvpudec: Freescale VPU video decoder
imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
imxg2d:  imxg2dvideosink: Freescale G2D video sink
imxg2d:  imxg2dvideotransform: Freescale G2D video transform
imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
imxpxp:  imxpxpvideosink: Freescale PxP video sink
imxpxp:  imxpxpvideotransform: Freescale PxP video transform
imxeglvivsink:  imxeglvivsink: Freescale EGL video sink

While using imxeglvivsink I'm seeing red flash for few milliseconds over 
the console and that's it.
Any advices will be helpful.

Pawel

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

What happens if you run this?

gst-launch-1.0 videotestsrc ! imxipuvideosink


Am 2015-05-18 um 07:34 schrieb Paweł Żabiełowicz:
> Hi all,
>
> I'm having some problems running video playback on Nitrogen6x-Lite. 
> I'm using fido with 3.10.53 kernel. Display is running properly as I 
> see a console after start, but starting any simple video with 
> Gstreamer1.0 + gstreamer-imx plugins does not give any video output, 
> even though the decoding looks like it's working.
>
> Gstreamer log:
> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579 
> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec ! 
> imxipuvideosink
> [INFO]    Product Info: i.MX6Q/D/S
> Pipeline is live and does not need PREROLL ...
> Progress: (open) Opening Stream
> Progress: (connect) Connecting to 
> rtsp://192.168.7.24:554/profile3/media.smp
> Progress: (open) Retrieving server options
> Progress: (open) Retrieving media info
> Progress: (request) SETUP stream 0
> Progress: (request) SETUP stream 1
> Progress: (open) Opened Stream
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> Progress: (request) Sending PLAY request
> Progress: (request) Sending PLAY request
> Progress: (request) Sent PLAY request
> ^Chandling interrupt.
> Interrupt: Stopping pipeline ...
> Execution ended after 0:00:15.125067669
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> Plugins installed:
>
> gst-inspect-1.0 | grep imx
> imxipu:  imxipuvideotransform: Freescale IPU video transform
> imxipu:  imxipuvideosink: Freescale IPU video sink
> imxvpu:  imxvpudec: Freescale VPU video decoder
> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
> imxg2d:  imxg2dvideosink: Freescale G2D video sink
> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
> imxpxp:  imxpxpvideosink: Freescale PxP video sink
> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>
> While using imxeglvivsink I'm seeing red flash for few milliseconds 
> over the console and that's it.
> Any advices will be helpful.
>
> Pawel

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Nikolay Dimitrov]

Hi Pawel,

On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
> Hi all,
>
> I'm having some problems running video playback on Nitrogen6x-Lite. I'm
> using fido with 3.10.53 kernel. Display is running properly as I see a
> console after start, but starting any simple video with Gstreamer1.0 +
> gstreamer-imx plugins does not give any video output, even though the
> decoding looks like it's working.
>
> Gstreamer log:
> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
> imxipuvideosink
> [INFO]    Product Info: i.MX6Q/D/S
> Pipeline is live and does not need PREROLL ...
> Progress: (open) Opening Stream
> Progress: (connect) Connecting to
> rtsp://192.168.7.24:554/profile3/media.smp
> Progress: (open) Retrieving server options
> Progress: (open) Retrieving media info
> Progress: (request) SETUP stream 0
> Progress: (request) SETUP stream 1
> Progress: (open) Opened Stream
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> Progress: (request) Sending PLAY request
> Progress: (request) Sending PLAY request
> Progress: (request) Sent PLAY request
> ^Chandling interrupt.
> Interrupt: Stopping pipeline ...
> Execution ended after 0:00:15.125067669
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> Plugins installed:
>
> gst-inspect-1.0 | grep imx
> imxipu:  imxipuvideotransform: Freescale IPU video transform
> imxipu:  imxipuvideosink: Freescale IPU video sink
> imxvpu:  imxvpudec: Freescale VPU video decoder
> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
> imxg2d:  imxg2dvideosink: Freescale G2D video sink
> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
> imxpxp:  imxpxpvideosink: Freescale PxP video sink
> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>
> While using imxeglvivsink I'm seeing red flash for few milliseconds over
> the console and that's it.
> Any advices will be helpful.

Please download this file and try a local file playback, to eliminate
possible networking issues:

https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4

Also, please check whether an automatically constructed pipeline is
able to play the file above:

gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4

You can try same tests with Xorg running.

Regards,
Nikolay

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-18 02:18, Nikolay Dimitrov wrote:
> Hi Pawel,
>
> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>> Hi all,
>>
>> I'm having some problems running video playback on Nitrogen6x-Lite. I'm
>> using fido with 3.10.53 kernel. Display is running properly as I see a
>> console after start, but starting any simple video with Gstreamer1.0 +
>> gstreamer-imx plugins does not give any video output, even though the
>> decoding looks like it's working.
>>
>> Gstreamer log:
>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>> imxipuvideosink
>> [INFO]    Product Info: i.MX6Q/D/S
>> Pipeline is live and does not need PREROLL ...
>> Progress: (open) Opening Stream
>> Progress: (connect) Connecting to
>> rtsp://192.168.7.24:554/profile3/media.smp
>> Progress: (open) Retrieving server options
>> Progress: (open) Retrieving media info
>> Progress: (request) SETUP stream 0
>> Progress: (request) SETUP stream 1
>> Progress: (open) Opened Stream
>> Setting pipeline to PLAYING ...
>> New clock: GstSystemClock
>> Progress: (request) Sending PLAY request
>> Progress: (request) Sending PLAY request
>> Progress: (request) Sent PLAY request
>> ^Chandling interrupt.
>> Interrupt: Stopping pipeline ...
>> Execution ended after 0:00:15.125067669
>> Setting pipeline to PAUSED ...
>> Setting pipeline to READY ...
>> Setting pipeline to NULL ...
>> Freeing pipeline ...
>>
>> Plugins installed:
>>
>> gst-inspect-1.0 | grep imx
>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>> imxipu:  imxipuvideosink: Freescale IPU video sink
>> imxvpu:  imxvpudec: Freescale VPU video decoder
>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>
>> While using imxeglvivsink I'm seeing red flash for few milliseconds over
>> the console and that's it.
>> Any advices will be helpful.
>
> Please download this file and try a local file playback, to eliminate
> possible networking issues:
>
> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>
> Also, please check whether an automatically constructed pipeline is
> able to play the file above:
>
> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>
> You can try same tests with Xorg running.

What would that pipeline look like (to force the result into a window
on the screen)?  As is, this simple command takes over the entire screen.


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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

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

Use the imxipuvideosink's 
window-x-coord/window-y-coord/window-width/window-height properties. 
Right now the coordinates have to be passed manually. I have working 
code that creates a window with an empty interior where the IPU can 
paint in, but it is still fairly bug-ridden.


On 05/18/2015 02:04 PM, Gary Thomas wrote:
> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>> Hi Pawel,
>>
>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>> Hi all,
>>>
>>> I'm having some problems running video playback on Nitrogen6x-Lite. I'm
>>> using fido with 3.10.53 kernel. Display is running properly as I see a
>>> console after start, but starting any simple video with Gstreamer1.0 +
>>> gstreamer-imx plugins does not give any video output, even though the
>>> decoding looks like it's working.
>>>
>>> Gstreamer log:
>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>> imxipuvideosink
>>> [INFO]    Product Info: i.MX6Q/D/S
>>> Pipeline is live and does not need PREROLL ...
>>> Progress: (open) Opening Stream
>>> Progress: (connect) Connecting to
>>> rtsp://192.168.7.24:554/profile3/media.smp
>>> Progress: (open) Retrieving server options
>>> Progress: (open) Retrieving media info
>>> Progress: (request) SETUP stream 0
>>> Progress: (request) SETUP stream 1
>>> Progress: (open) Opened Stream
>>> Setting pipeline to PLAYING ...
>>> New clock: GstSystemClock
>>> Progress: (request) Sending PLAY request
>>> Progress: (request) Sending PLAY request
>>> Progress: (request) Sent PLAY request
>>> ^Chandling interrupt.
>>> Interrupt: Stopping pipeline ...
>>> Execution ended after 0:00:15.125067669
>>> Setting pipeline to PAUSED ...
>>> Setting pipeline to READY ...
>>> Setting pipeline to NULL ...
>>> Freeing pipeline ...
>>>
>>> Plugins installed:
>>>
>>> gst-inspect-1.0 | grep imx
>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>
>>> While using imxeglvivsink I'm seeing red flash for few milliseconds 
>>> over
>>> the console and that's it.
>>> Any advices will be helpful.
>>
>> Please download this file and try a local file playback, to eliminate
>> possible networking issues:
>>
>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>
>> Also, please check whether an automatically constructed pipeline is
>> able to play the file above:
>>
>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>
>> You can try same tests with Xorg running.
>
> What would that pipeline look like (to force the result into a window
> on the screen)?  As is, this simple command takes over the entire screen.
>
>


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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-18 06:26, Carlos Rafael Giani wrote:
> Use the imxipuvideosink's window-x-coord/window-y-coord/window-width/window-height properties. Right now the coordinates have to be passed manually. I have working code that
> creates a window with an empty interior where the IPU can paint in, but it is still fairly bug-ridden.

COuld you be a bit more explicit?  I'd just like to see what this does here.

> On 05/18/2015 02:04 PM, Gary Thomas wrote:
>> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>>> Hi Pawel,
>>>
>>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>>> Hi all,
>>>>
>>>> I'm having some problems running video playback on Nitrogen6x-Lite. I'm
>>>> using fido with 3.10.53 kernel. Display is running properly as I see a
>>>> console after start, but starting any simple video with Gstreamer1.0 +
>>>> gstreamer-imx plugins does not give any video output, even though the
>>>> decoding looks like it's working.
>>>>
>>>> Gstreamer log:
>>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>>> imxipuvideosink
>>>> [INFO]    Product Info: i.MX6Q/D/S
>>>> Pipeline is live and does not need PREROLL ...
>>>> Progress: (open) Opening Stream
>>>> Progress: (connect) Connecting to
>>>> rtsp://192.168.7.24:554/profile3/media.smp
>>>> Progress: (open) Retrieving server options
>>>> Progress: (open) Retrieving media info
>>>> Progress: (request) SETUP stream 0
>>>> Progress: (request) SETUP stream 1
>>>> Progress: (open) Opened Stream
>>>> Setting pipeline to PLAYING ...
>>>> New clock: GstSystemClock
>>>> Progress: (request) Sending PLAY request
>>>> Progress: (request) Sending PLAY request
>>>> Progress: (request) Sent PLAY request
>>>> ^Chandling interrupt.
>>>> Interrupt: Stopping pipeline ...
>>>> Execution ended after 0:00:15.125067669
>>>> Setting pipeline to PAUSED ...
>>>> Setting pipeline to READY ...
>>>> Setting pipeline to NULL ...
>>>> Freeing pipeline ...
>>>>
>>>> Plugins installed:
>>>>
>>>> gst-inspect-1.0 | grep imx
>>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>>
>>>> While using imxeglvivsink I'm seeing red flash for few milliseconds over
>>>> the console and that's it.
>>>> Any advices will be helpful.
>>>
>>> Please download this file and try a local file playback, to eliminate
>>> possible networking issues:
>>>
>>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>>
>>> Also, please check whether an automatically constructed pipeline is
>>> able to play the file above:
>>>
>>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>>
>>> You can try same tests with Xorg running.
>>
>> What would that pipeline look like (to force the result into a window
>> on the screen)?  As is, this simple command takes over the entire screen.
>>
>>
>
>
>

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Nikolay Dimitrov]

Hi Gary,

On 05/18/2015 03:04 PM, Gary Thomas wrote:
> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>> Hi Pawel,
>>
>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>> Hi all,
>>>
>>> I'm having some problems running video playback on Nitrogen6x-Lite. I'm
>>> using fido with 3.10.53 kernel. Display is running properly as I see a
>>> console after start, but starting any simple video with Gstreamer1.0 +
>>> gstreamer-imx plugins does not give any video output, even though the
>>> decoding looks like it's working.
>>>
>>> Gstreamer log:
>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>> imxipuvideosink
>>> [INFO]    Product Info: i.MX6Q/D/S
>>> Pipeline is live and does not need PREROLL ...
>>> Progress: (open) Opening Stream
>>> Progress: (connect) Connecting to
>>> rtsp://192.168.7.24:554/profile3/media.smp
>>> Progress: (open) Retrieving server options
>>> Progress: (open) Retrieving media info
>>> Progress: (request) SETUP stream 0
>>> Progress: (request) SETUP stream 1
>>> Progress: (open) Opened Stream
>>> Setting pipeline to PLAYING ...
>>> New clock: GstSystemClock
>>> Progress: (request) Sending PLAY request
>>> Progress: (request) Sending PLAY request
>>> Progress: (request) Sent PLAY request
>>> ^Chandling interrupt.
>>> Interrupt: Stopping pipeline ...
>>> Execution ended after 0:00:15.125067669
>>> Setting pipeline to PAUSED ...
>>> Setting pipeline to READY ...
>>> Setting pipeline to NULL ...
>>> Freeing pipeline ...
>>>
>>> Plugins installed:
>>>
>>> gst-inspect-1.0 | grep imx
>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>
>>> While using imxeglvivsink I'm seeing red flash for few milliseconds over
>>> the console and that's it.
>>> Any advices will be helpful.
>>
>> Please download this file and try a local file playback, to eliminate
>> possible networking issues:
>>
>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>
>> Also, please check whether an automatically constructed pipeline is
>> able to play the file above:
>>
>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>
>> You can try same tests with Xorg running.
>
> What would that pipeline look like (to force the result into a window
> on the screen)?  As is, this simple command takes over the entire screen.

The automatically generated pipeline depends entirely on the media
itself and the set of plugins you have installed - playbin/decodebin
and friends are looking at the stream properties and searching for the
plugin with the highest rank which can be plugged there. The best place
to look at is usually the media graphs (.dot files) after playbin was
able to play something (I do this regularly, as my pipelines are
usually worse than the ones created by playbin).

Also the full-screen behavior depends the videosink configuration, so
hard to give universal answer, as none will fit all cases.

Regards,
Nikolay

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

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

On 2015-05-18 09:55, Nikolay Dimitrov wrote:
> Hi Gary,
>
> On 05/18/2015 03:04 PM, Gary Thomas wrote:
>> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>>> Hi Pawel,
>>>
>>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>>> Hi all,
>>>>
>>>> I'm having some problems running video playback on Nitrogen6x-Lite. I'm
>>>> using fido with 3.10.53 kernel. Display is running properly as I see a
>>>> console after start, but starting any simple video with Gstreamer1.0 +
>>>> gstreamer-imx plugins does not give any video output, even though the
>>>> decoding looks like it's working.
>>>>
>>>> Gstreamer log:
>>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>>> imxipuvideosink
>>>> [INFO]    Product Info: i.MX6Q/D/S
>>>> Pipeline is live and does not need PREROLL ...
>>>> Progress: (open) Opening Stream
>>>> Progress: (connect) Connecting to
>>>> rtsp://192.168.7.24:554/profile3/media.smp
>>>> Progress: (open) Retrieving server options
>>>> Progress: (open) Retrieving media info
>>>> Progress: (request) SETUP stream 0
>>>> Progress: (request) SETUP stream 1
>>>> Progress: (open) Opened Stream
>>>> Setting pipeline to PLAYING ...
>>>> New clock: GstSystemClock
>>>> Progress: (request) Sending PLAY request
>>>> Progress: (request) Sending PLAY request
>>>> Progress: (request) Sent PLAY request
>>>> ^Chandling interrupt.
>>>> Interrupt: Stopping pipeline ...
>>>> Execution ended after 0:00:15.125067669
>>>> Setting pipeline to PAUSED ...
>>>> Setting pipeline to READY ...
>>>> Setting pipeline to NULL ...
>>>> Freeing pipeline ...
>>>>
>>>> Plugins installed:
>>>>
>>>> gst-inspect-1.0 | grep imx
>>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>>
>>>> While using imxeglvivsink I'm seeing red flash for few milliseconds over
>>>> the console and that's it.
>>>> Any advices will be helpful.
>>>
>>> Please download this file and try a local file playback, to eliminate
>>> possible networking issues:
>>>
>>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>>
>>> Also, please check whether an automatically constructed pipeline is
>>> able to play the file above:
>>>
>>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>>
>>> You can try same tests with Xorg running.
>>
>> What would that pipeline look like (to force the result into a window
>> on the screen)?  As is, this simple command takes over the entire screen.
>
> The automatically generated pipeline depends entirely on the media
> itself and the set of plugins you have installed - playbin/decodebin
> and friends are looking at the stream properties and searching for the
> plugin with the highest rank which can be plugged there. The best place
> to look at is usually the media graphs (.dot files) after playbin was
> able to play something (I do this regularly, as my pipelines are
> usually worse than the ones created by playbin).

I tried interpreting these files and since I don't do it all the time
(like you), it was hard for me to see the whole picture.  Is it possible
to look at such a graph and write something equivalent that could be
run via gst-launch?

Here's my graph in case you can make any sense of it.

>
> Also the full-screen behavior depends the videosink configuration, so
> hard to give universal answer, as none will fit all cases.

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

[-- Attachment #2: 0.00.00.539659667-gst-player.0x15ebb20.PAUSED_PLAYING.dot --]
[-- Type: application/msword-template, Size: 29108 bytes --]

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Nikolay Dimitrov]

Ho Gary,

On 05/18/2015 07:27 PM, Gary Thomas wrote:
> On 2015-05-18 09:55, Nikolay Dimitrov wrote:
>> Hi Gary,
>>
>> On 05/18/2015 03:04 PM, Gary Thomas wrote:
>>> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>>>> Hi Pawel,
>>>>
>>>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm having some problems running video playback on Nitrogen6x-Lite.
>>>>> I'm
>>>>> using fido with 3.10.53 kernel. Display is running properly as I see a
>>>>> console after start, but starting any simple video with Gstreamer1.0 +
>>>>> gstreamer-imx plugins does not give any video output, even though the
>>>>> decoding looks like it's working.
>>>>>
>>>>> Gstreamer log:
>>>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>>>> imxipuvideosink
>>>>> [INFO]    Product Info: i.MX6Q/D/S
>>>>> Pipeline is live and does not need PREROLL ...
>>>>> Progress: (open) Opening Stream
>>>>> Progress: (connect) Connecting to
>>>>> rtsp://192.168.7.24:554/profile3/media.smp
>>>>> Progress: (open) Retrieving server options
>>>>> Progress: (open) Retrieving media info
>>>>> Progress: (request) SETUP stream 0
>>>>> Progress: (request) SETUP stream 1
>>>>> Progress: (open) Opened Stream
>>>>> Setting pipeline to PLAYING ...
>>>>> New clock: GstSystemClock
>>>>> Progress: (request) Sending PLAY request
>>>>> Progress: (request) Sending PLAY request
>>>>> Progress: (request) Sent PLAY request
>>>>> ^Chandling interrupt.
>>>>> Interrupt: Stopping pipeline ...
>>>>> Execution ended after 0:00:15.125067669
>>>>> Setting pipeline to PAUSED ...
>>>>> Setting pipeline to READY ...
>>>>> Setting pipeline to NULL ...
>>>>> Freeing pipeline ...
>>>>>
>>>>> Plugins installed:
>>>>>
>>>>> gst-inspect-1.0 | grep imx
>>>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>>>
>>>>> While using imxeglvivsink I'm seeing red flash for few milliseconds
>>>>> over
>>>>> the console and that's it.
>>>>> Any advices will be helpful.
>>>>
>>>> Please download this file and try a local file playback, to eliminate
>>>> possible networking issues:
>>>>
>>>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>>>
>>>> Also, please check whether an automatically constructed pipeline is
>>>> able to play the file above:
>>>>
>>>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>>>
>>>> You can try same tests with Xorg running.
>>>
>>> What would that pipeline look like (to force the result into a window
>>> on the screen)?  As is, this simple command takes over the entire
>>> screen.
>>
>> The automatically generated pipeline depends entirely on the media
>> itself and the set of plugins you have installed - playbin/decodebin
>> and friends are looking at the stream properties and searching for the
>> plugin with the highest rank which can be plugged there. The best place
>> to look at is usually the media graphs (.dot files) after playbin was
>> able to play something (I do this regularly, as my pipelines are
>> usually worse than the ones created by playbin).
>
> I tried interpreting these files and since I don't do it all the time
> (like you)it was hard for me to see the whole picture.  Is it possible
> to look at such a graph and write something equivalent that could be
> run via gst-launch?
>
> Here's my graph in case you can make any sense of it.

Not sure that the following will help much, but at least I can share
what I know, so we can be in the same boat...

Please look at the demuxer (qtdemux0), notice that the lower 2 source
pads are denoted with dashed lines, which means these pads are dynamic,
e.g. doesn't exist all the time (there are more components with dynamic
pads in this pipeline).

What happens is that after playback start, the demuxer only consumes
data for a while and doesn't have any output pads. When the demuxer
understands what logical streams are carried over the transport, it
dynamically creates a number of source pads, one for each supported
content type (usually for video/audio/subs, but can be more).

When the demuxer's dynamic pads are created, the pipeline emits events,
and the parent element (decodebin0) catches these events, looks for
appropriate decoding elements, and attaches them to the pipeline
dynamically.

The trouble with these dynamic pipelines is that you can't refer to the
source/sink pads of the elements before the pipeline is created, which
means you can't construct a working dynamic pipeline from the command
line. I looked how to do this, but couldn't find a solution. If someone
knows how to do this, would be great to share.

So the only way I know to create fully custom dynamic pipelines (e.g.
driven by the content) is via source code, otherwise we have to use
automated bins like playbin/decodebin, and give them some parameters.

>
>>
>> Also the full-screen behavior depends the videosink configuration, so
>> hard to give universal answer, as none will fit all cases.
>

Regards,
Nikolay

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-18 17:52, Nikolay Dimitrov wrote:
> Ho Gary,
>
> On 05/18/2015 07:27 PM, Gary Thomas wrote:
>> On 2015-05-18 09:55, Nikolay Dimitrov wrote:
>>> Hi Gary,
>>>
>>> On 05/18/2015 03:04 PM, Gary Thomas wrote:
>>>> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>>>>> Hi Pawel,
>>>>>
>>>>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I'm having some problems running video playback on Nitrogen6x-Lite.
>>>>>> I'm
>>>>>> using fido with 3.10.53 kernel. Display is running properly as I see a
>>>>>> console after start, but starting any simple video with Gstreamer1.0 +
>>>>>> gstreamer-imx plugins does not give any video output, even though the
>>>>>> decoding looks like it's working.
>>>>>>
>>>>>> Gstreamer log:
>>>>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>>>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>>>>> imxipuvideosink
>>>>>> [INFO]    Product Info: i.MX6Q/D/S
>>>>>> Pipeline is live and does not need PREROLL ...
>>>>>> Progress: (open) Opening Stream
>>>>>> Progress: (connect) Connecting to
>>>>>> rtsp://192.168.7.24:554/profile3/media.smp
>>>>>> Progress: (open) Retrieving server options
>>>>>> Progress: (open) Retrieving media info
>>>>>> Progress: (request) SETUP stream 0
>>>>>> Progress: (request) SETUP stream 1
>>>>>> Progress: (open) Opened Stream
>>>>>> Setting pipeline to PLAYING ...
>>>>>> New clock: GstSystemClock
>>>>>> Progress: (request) Sending PLAY request
>>>>>> Progress: (request) Sending PLAY request
>>>>>> Progress: (request) Sent PLAY request
>>>>>> ^Chandling interrupt.
>>>>>> Interrupt: Stopping pipeline ...
>>>>>> Execution ended after 0:00:15.125067669
>>>>>> Setting pipeline to PAUSED ...
>>>>>> Setting pipeline to READY ...
>>>>>> Setting pipeline to NULL ...
>>>>>> Freeing pipeline ...
>>>>>>
>>>>>> Plugins installed:
>>>>>>
>>>>>> gst-inspect-1.0 | grep imx
>>>>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>>>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>>>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>>>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>>>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>>>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>>>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>>>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>>>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>>>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>>>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>>>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>>>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>>>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>>>>
>>>>>> While using imxeglvivsink I'm seeing red flash for few milliseconds
>>>>>> over
>>>>>> the console and that's it.
>>>>>> Any advices will be helpful.
>>>>>
>>>>> Please download this file and try a local file playback, to eliminate
>>>>> possible networking issues:
>>>>>
>>>>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>>>>
>>>>> Also, please check whether an automatically constructed pipeline is
>>>>> able to play the file above:
>>>>>
>>>>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>>>>
>>>>> You can try same tests with Xorg running.
>>>>
>>>> What would that pipeline look like (to force the result into a window
>>>> on the screen)?  As is, this simple command takes over the entire
>>>> screen.
>>>
>>> The automatically generated pipeline depends entirely on the media
>>> itself and the set of plugins you have installed - playbin/decodebin
>>> and friends are looking at the stream properties and searching for the
>>> plugin with the highest rank which can be plugged there. The best place
>>> to look at is usually the media graphs (.dot files) after playbin was
>>> able to play something (I do this regularly, as my pipelines are
>>> usually worse than the ones created by playbin).
>>
>> I tried interpreting these files and since I don't do it all the time
>> (like you)it was hard for me to see the whole picture.  Is it possible
>> to look at such a graph and write something equivalent that could be
>> run via gst-launch?
>>
>> Here's my graph in case you can make any sense of it.
>
> Not sure that the following will help much, but at least I can share
> what I know, so we can be in the same boat...
>
> Please look at the demuxer (qtdemux0), notice that the lower 2 source
> pads are denoted with dashed lines, which means these pads are dynamic,
> e.g. doesn't exist all the time (there are more components with dynamic
> pads in this pipeline).
>
> What happens is that after playback start, the demuxer only consumes
> data for a while and doesn't have any output pads. When the demuxer
> understands what logical streams are carried over the transport, it
> dynamically creates a number of source pads, one for each supported
> content type (usually for video/audio/subs, but can be more).
>
> When the demuxer's dynamic pads are created, the pipeline emits events,
> and the parent element (decodebin0) catches these events, looks for
> appropriate decoding elements, and attaches them to the pipeline
> dynamically.
>
> The trouble with these dynamic pipelines is that you can't refer to the
> source/sink pads of the elements before the pipeline is created, which
> means you can't construct a working dynamic pipeline from the command
> line. I looked how to do this, but couldn't find a solution. If someone
> knows how to do this, would be great to share.
>
> So the only way I know to create fully custom dynamic pipelines (e.g.
> driven by the content) is via source code, otherwise we have to use
> automated bins like playbin/decodebin, and give them some parameters.

Thanks for the explanation, perhaps it can help someone fix this.  My
guess is that the FSL plugin doesn't handle those dynamic elements and
thus is not equipped to set up the render in the appropriate window on
the screen.

>
>>
>>>
>>> Also the full-screen behavior depends the videosink configuration, so
>>> hard to give universal answer, as none will fit all cases.
>>
>
> Regards,
> Nikolay

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Nikolay Dimitrov]

Hi Gary,

On 05/19/2015 01:53 PM, Gary Thomas wrote:
> On 2015-05-18 17:52, Nikolay Dimitrov wrote:
>> Ho Gary,
>>
>> On 05/18/2015 07:27 PM, Gary Thomas wrote:
>>> On 2015-05-18 09:55, Nikolay Dimitrov wrote:
>>>> Hi Gary,
>>>>
>>>> On 05/18/2015 03:04 PM, Gary Thomas wrote:
>>>>> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>>>>>> Hi Pawel,
>>>>>>
>>>>>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm having some problems running video playback on Nitrogen6x-Lite.
>>>>>>> I'm
>>>>>>> using fido with 3.10.53 kernel. Display is running properly as I
>>>>>>> see a
>>>>>>> console after start, but starting any simple video with
>>>>>>> Gstreamer1.0 +
>>>>>>> gstreamer-imx plugins does not give any video output, even though
>>>>>>> the
>>>>>>> decoding looks like it's working.
>>>>>>>
>>>>>>> Gstreamer log:
>>>>>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>>>>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>>>>>> imxipuvideosink
>>>>>>> [INFO]    Product Info: i.MX6Q/D/S
>>>>>>> Pipeline is live and does not need PREROLL ...
>>>>>>> Progress: (open) Opening Stream
>>>>>>> Progress: (connect) Connecting to
>>>>>>> rtsp://192.168.7.24:554/profile3/media.smp
>>>>>>> Progress: (open) Retrieving server options
>>>>>>> Progress: (open) Retrieving media info
>>>>>>> Progress: (request) SETUP stream 0
>>>>>>> Progress: (request) SETUP stream 1
>>>>>>> Progress: (open) Opened Stream
>>>>>>> Setting pipeline to PLAYING ...
>>>>>>> New clock: GstSystemClock
>>>>>>> Progress: (request) Sending PLAY request
>>>>>>> Progress: (request) Sending PLAY request
>>>>>>> Progress: (request) Sent PLAY request
>>>>>>> ^Chandling interrupt.
>>>>>>> Interrupt: Stopping pipeline ...
>>>>>>> Execution ended after 0:00:15.125067669
>>>>>>> Setting pipeline to PAUSED ...
>>>>>>> Setting pipeline to READY ...
>>>>>>> Setting pipeline to NULL ...
>>>>>>> Freeing pipeline ...
>>>>>>>
>>>>>>> Plugins installed:
>>>>>>>
>>>>>>> gst-inspect-1.0 | grep imx
>>>>>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>>>>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>>>>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>>>>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>>>>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>>>>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>>>>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>>>>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>>>>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>>>>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>>>>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>>>>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>>>>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>>>>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>>>>>
>>>>>>> While using imxeglvivsink I'm seeing red flash for few milliseconds
>>>>>>> over
>>>>>>> the console and that's it.
>>>>>>> Any advices will be helpful.
>>>>>>
>>>>>> Please download this file and try a local file playback, to eliminate
>>>>>> possible networking issues:
>>>>>>
>>>>>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>>>>>
>>>>>> Also, please check whether an automatically constructed pipeline is
>>>>>> able to play the file above:
>>>>>>
>>>>>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>>>>>
>>>>>> You can try same tests with Xorg running.
>>>>>
>>>>> What would that pipeline look like (to force the result into a window
>>>>> on the screen)?  As is, this simple command takes over the entire
>>>>> screen.
>>>>
>>>> The automatically generated pipeline depends entirely on the media
>>>> itself and the set of plugins you have installed - playbin/decodebin
>>>> and friends are looking at the stream properties and searching for the
>>>> plugin with the highest rank which can be plugged there. The best place
>>>> to look at is usually the media graphs (.dot files) after playbin was
>>>> able to play something (I do this regularly, as my pipelines are
>>>> usually worse than the ones created by playbin).
>>>
>>> I tried interpreting these files and since I don't do it all the time
>>> (like you)it was hard for me to see the whole picture.  Is it possible
>>> to look at such a graph and write something equivalent that could be
>>> run via gst-launch?
>>>
>>> Here's my graph in case you can make any sense of it.
>>
>> Not sure that the following will help much, but at least I can share
>> what I know, so we can be in the same boat...
>>
>> Please look at the demuxer (qtdemux0), notice that the lower 2 source
>> pads are denoted with dashed lines, which means these pads are dynamic,
>> e.g. doesn't exist all the time (there are more components with dynamic
>> pads in this pipeline).
>>
>> What happens is that after playback start, the demuxer only consumes
>> data for a while and doesn't have any output pads. When the demuxer
>> understands what logical streams are carried over the transport, it
>> dynamically creates a number of source pads, one for each supported
>> content type (usually for video/audio/subs, but can be more).
>>
>> When the demuxer's dynamic pads are created, the pipeline emits events,
>> and the parent element (decodebin0) catches these events, looks for
>> appropriate decoding elements, and attaches them to the pipeline
>> dynamically.
>>
>> The trouble with these dynamic pipelines is that you can't refer to the
>> source/sink pads of the elements before the pipeline is created, which
>> means you can't construct a working dynamic pipeline from the command
>> line. I looked how to do this, but couldn't find a solution. If someone
>> knows how to do this, would be great to share.
>>
>> So the only way I know to create fully custom dynamic pipelines (e.g.
>> driven by the content) is via source code, otherwise we have to use
>> automated bins like playbin/decodebin, and give them some parameters.
>
> Thanks for the explanation, perhaps it can help someone fix this.  My
> guess is that the FSL plugin doesn't handle those dynamic elements and
> thus is not equipped to set up the render in the appropriate window on
> the screen.
>
>>
>>>
>>>>
>>>> Also the full-screen behavior depends the videosink configuration, so
>>>> hard to give universal answer, as none will fit all cases.

I doubt that the issue is caused exactly by the GstImxVpuDec or 
GstOverlaySink, as by looking at your pipeline they seem to have static 
pads. So it's more of how the playbin/decodebin bins handle the pipeline 
creation process...

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-19 05:04, Nikolay Dimitrov wrote:
> Hi Gary,
>
> On 05/19/2015 01:53 PM, Gary Thomas wrote:
>> On 2015-05-18 17:52, Nikolay Dimitrov wrote:
>>> Ho Gary,
>>>
>>> On 05/18/2015 07:27 PM, Gary Thomas wrote:
>>>> On 2015-05-18 09:55, Nikolay Dimitrov wrote:
>>>>> Hi Gary,
>>>>>
>>>>> On 05/18/2015 03:04 PM, Gary Thomas wrote:
>>>>>> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>>>>>>> Hi Pawel,
>>>>>>>
>>>>>>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I'm having some problems running video playback on Nitrogen6x-Lite.
>>>>>>>> I'm
>>>>>>>> using fido with 3.10.53 kernel. Display is running properly as I
>>>>>>>> see a
>>>>>>>> console after start, but starting any simple video with
>>>>>>>> Gstreamer1.0 +
>>>>>>>> gstreamer-imx plugins does not give any video output, even though
>>>>>>>> the
>>>>>>>> decoding looks like it's working.
>>>>>>>>
>>>>>>>> Gstreamer log:
>>>>>>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>>>>>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>>>>>>> imxipuvideosink
>>>>>>>> [INFO]    Product Info: i.MX6Q/D/S
>>>>>>>> Pipeline is live and does not need PREROLL ...
>>>>>>>> Progress: (open) Opening Stream
>>>>>>>> Progress: (connect) Connecting to
>>>>>>>> rtsp://192.168.7.24:554/profile3/media.smp
>>>>>>>> Progress: (open) Retrieving server options
>>>>>>>> Progress: (open) Retrieving media info
>>>>>>>> Progress: (request) SETUP stream 0
>>>>>>>> Progress: (request) SETUP stream 1
>>>>>>>> Progress: (open) Opened Stream
>>>>>>>> Setting pipeline to PLAYING ...
>>>>>>>> New clock: GstSystemClock
>>>>>>>> Progress: (request) Sending PLAY request
>>>>>>>> Progress: (request) Sending PLAY request
>>>>>>>> Progress: (request) Sent PLAY request
>>>>>>>> ^Chandling interrupt.
>>>>>>>> Interrupt: Stopping pipeline ...
>>>>>>>> Execution ended after 0:00:15.125067669
>>>>>>>> Setting pipeline to PAUSED ...
>>>>>>>> Setting pipeline to READY ...
>>>>>>>> Setting pipeline to NULL ...
>>>>>>>> Freeing pipeline ...
>>>>>>>>
>>>>>>>> Plugins installed:
>>>>>>>>
>>>>>>>> gst-inspect-1.0 | grep imx
>>>>>>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>>>>>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>>>>>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>>>>>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>>>>>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>>>>>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>>>>>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>>>>>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>>>>>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>>>>>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>>>>>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>>>>>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>>>>>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>>>>>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>>>>>>
>>>>>>>> While using imxeglvivsink I'm seeing red flash for few milliseconds
>>>>>>>> over
>>>>>>>> the console and that's it.
>>>>>>>> Any advices will be helpful.
>>>>>>>
>>>>>>> Please download this file and try a local file playback, to eliminate
>>>>>>> possible networking issues:
>>>>>>>
>>>>>>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>>>>>>
>>>>>>> Also, please check whether an automatically constructed pipeline is
>>>>>>> able to play the file above:
>>>>>>>
>>>>>>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>>>>>>
>>>>>>> You can try same tests with Xorg running.
>>>>>>
>>>>>> What would that pipeline look like (to force the result into a window
>>>>>> on the screen)?  As is, this simple command takes over the entire
>>>>>> screen.
>>>>>
>>>>> The automatically generated pipeline depends entirely on the media
>>>>> itself and the set of plugins you have installed - playbin/decodebin
>>>>> and friends are looking at the stream properties and searching for the
>>>>> plugin with the highest rank which can be plugged there. The best place
>>>>> to look at is usually the media graphs (.dot files) after playbin was
>>>>> able to play something (I do this regularly, as my pipelines are
>>>>> usually worse than the ones created by playbin).
>>>>
>>>> I tried interpreting these files and since I don't do it all the time
>>>> (like you)it was hard for me to see the whole picture.  Is it possible
>>>> to look at such a graph and write something equivalent that could be
>>>> run via gst-launch?
>>>>
>>>> Here's my graph in case you can make any sense of it.
>>>
>>> Not sure that the following will help much, but at least I can share
>>> what I know, so we can be in the same boat...
>>>
>>> Please look at the demuxer (qtdemux0), notice that the lower 2 source
>>> pads are denoted with dashed lines, which means these pads are dynamic,
>>> e.g. doesn't exist all the time (there are more components with dynamic
>>> pads in this pipeline).
>>>
>>> What happens is that after playback start, the demuxer only consumes
>>> data for a while and doesn't have any output pads. When the demuxer
>>> understands what logical streams are carried over the transport, it
>>> dynamically creates a number of source pads, one for each supported
>>> content type (usually for video/audio/subs, but can be more).
>>>
>>> When the demuxer's dynamic pads are created, the pipeline emits events,
>>> and the parent element (decodebin0) catches these events, looks for
>>> appropriate decoding elements, and attaches them to the pipeline
>>> dynamically.
>>>
>>> The trouble with these dynamic pipelines is that you can't refer to the
>>> source/sink pads of the elements before the pipeline is created, which
>>> means you can't construct a working dynamic pipeline from the command
>>> line. I looked how to do this, but couldn't find a solution. If someone
>>> knows how to do this, would be great to share.
>>>
>>> So the only way I know to create fully custom dynamic pipelines (e.g.
>>> driven by the content) is via source code, otherwise we have to use
>>> automated bins like playbin/decodebin, and give them some parameters.
>>
>> Thanks for the explanation, perhaps it can help someone fix this.  My
>> guess is that the FSL plugin doesn't handle those dynamic elements and
>> thus is not equipped to set up the render in the appropriate window on
>> the screen.
>>
>>>
>>>>
>>>>>
>>>>> Also the full-screen behavior depends the videosink configuration, so
>>>>> hard to give universal answer, as none will fit all cases.
>
> I doubt that the issue is caused exactly by the GstImxVpuDec or GstOverlaySink, as by looking at your pipeline they seem to have static pads. So it's more of how the
> playbin/decodebin bins handle the pipeline creation process...

All I know is that it does work correctly on other platforms, e.g. a
native x86 (intel-corei7-64), as well as when there are no i.MX plugins
installed, so it's definitely tied to the FSL plugin.

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>> guess is that the FSL plugin doesn't handle those dynamic elements and
>>> thus is not equipped to set up the render in the appropriate window on
>>> the screen.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Also the full-screen behavior depends the videosink 
>>>>>> configuration, so
>>>>>> hard to give universal answer, as none will fit all cases.
>>
>> I doubt that the issue is caused exactly by the GstImxVpuDec or 
>> GstOverlaySink, as by looking at your pipeline they seem to have 
>> static pads. So it's more of how the
>> playbin/decodebin bins handle the pipeline creation process...
>
> All I know is that it does work correctly on other platforms, e.g. a
> native x86 (intel-corei7-64), as well as when there are no i.MX plugins
> installed, so it's definitely tied to the FSL plugin.

The issue here is that the IPU sink does not know anything about 
windows. It directly overwrites the framebuffer's pixels. One way I am 
trying out is to create an empty window in the sink and let the IPU 
overwrite its pixels, but this is not exactly clean, and can cause 
artifacts. If you want to render to a window, I recommend using the 
imxeglvivsink instead. In fact, this should be the default one. How did 
you get the plugins?

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Nikolay Dimitrov]

Hi Carlos,

On 05/19/2015 02:11 PM, Carlos Rafael Giani wrote:
>
>>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>>> guess is that the FSL plugin doesn't handle those dynamic elements and
>>>> thus is not equipped to set up the render in the appropriate window on
>>>> the screen.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Also the full-screen behavior depends the videosink
>>>>>>> configuration, so
>>>>>>> hard to give universal answer, as none will fit all cases.
>>>
>>> I doubt that the issue is caused exactly by the GstImxVpuDec or
>>> GstOverlaySink, as by looking at your pipeline they seem to have
>>> static pads. So it's more of how the
>>> playbin/decodebin bins handle the pipeline creation process...
>>
>> All I know is that it does work correctly on other platforms, e.g. a
>> native x86 (intel-corei7-64), as well as when there are no i.MX plugins
>> installed, so it's definitely tied to the FSL plugin.
>
> The issue here is that the IPU sink does not know anything about
> windows. It directly overwrites the framebuffer's pixels. One way I am
> trying out is to create an empty window in the sink and let the IPU
> overwrite its pixels, but this is not exactly clean, and can cause
> artifacts. If you want to render to a window, I recommend using the
> imxeglvivsink instead. In fact, this should be the default one. How did
> you get the plugins?

You're talking about X11 overlay, is it correct?

Regards,
Nikolay

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>
>>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>>> guess is that the FSL plugin doesn't handle those dynamic elements and
>>>> thus is not equipped to set up the render in the appropriate window on
>>>> the screen.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Also the full-screen behavior depends the videosink configuration, so
>>>>>>> hard to give universal answer, as none will fit all cases.
>>>
>>> I doubt that the issue is caused exactly by the GstImxVpuDec or GstOverlaySink, as by looking at your pipeline they seem to have static pads. So it's more of how the
>>> playbin/decodebin bins handle the pipeline creation process...
>>
>> All I know is that it does work correctly on other platforms, e.g. a
>> native x86 (intel-corei7-64), as well as when there are no i.MX plugins
>> installed, so it's definitely tied to the FSL plugin.
>
> The issue here is that the IPU sink does not know anything about windows. It directly overwrites the framebuffer's pixels. One way I am trying out is to create an empty window in
> the sink and let the IPU overwrite its pixels, but this is not exactly clean, and can cause artifacts. If you want to render to a window, I recommend using the imxeglvivsink
> instead. In fact, this should be the default one. How did you get the plugins?

Nothing special, I simply included gst1.0-fsl-plugin in my image.
I'm building my own X based image, which includes these packages:
	      gst-player-bin
	      gstreamer1.0-libav
	      gst1.0-fsl-plugin
	      gstreamer1.0-plugins-imx

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

Am 2015-05-19 um 13:17 schrieb Gary Thomas:
> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>
>>>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>>>> guess is that the FSL plugin doesn't handle those dynamic elements 
>>>>> and
>>>>> thus is not equipped to set up the render in the appropriate 
>>>>> window on
>>>>> the screen.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Also the full-screen behavior depends the videosink 
>>>>>>>> configuration, so
>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>
>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or 
>>>> GstOverlaySink, as by looking at your pipeline they seem to have 
>>>> static pads. So it's more of how the
>>>> playbin/decodebin bins handle the pipeline creation process...
>>>
>>> All I know is that it does work correctly on other platforms, e.g. a
>>> native x86 (intel-corei7-64), as well as when there are no i.MX plugins
>>> installed, so it's definitely tied to the FSL plugin.
>>
>> The issue here is that the IPU sink does not know anything about 
>> windows. It directly overwrites the framebuffer's pixels. One way I 
>> am trying out is to create an empty window in
>> the sink and let the IPU overwrite its pixels, but this is not 
>> exactly clean, and can cause artifacts. If you want to render to a 
>> window, I recommend using the imxeglvivsink
>> instead. In fact, this should be the default one. How did you get the 
>> plugins?
>
> Nothing special, I simply included gst1.0-fsl-plugin in my image.
> I'm building my own X based image, which includes these packages:
>           gst-player-bin
>           gstreamer1.0-libav
>           gst1.0-fsl-plugin
>           gstreamer1.0-plugins-imx
>

What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

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

On 2015-05-19 05:23, Carlos Rafael Giani wrote:
>
>
> Am 2015-05-19 um 13:17 schrieb Gary Thomas:
>> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>>
>>>>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>>>>> guess is that the FSL plugin doesn't handle those dynamic elements and
>>>>>> thus is not equipped to set up the render in the appropriate window on
>>>>>> the screen.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also the full-screen behavior depends the videosink configuration, so
>>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>>
>>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or GstOverlaySink, as by looking at your pipeline they seem to have static pads. So it's more of how the
>>>>> playbin/decodebin bins handle the pipeline creation process...
>>>>
>>>> All I know is that it does work correctly on other platforms, e.g. a
>>>> native x86 (intel-corei7-64), as well as when there are no i.MX plugins
>>>> installed, so it's definitely tied to the FSL plugin.
>>>
>>> The issue here is that the IPU sink does not know anything about windows. It directly overwrites the framebuffer's pixels. One way I am trying out is to create an empty window in
>>> the sink and let the IPU overwrite its pixels, but this is not exactly clean, and can cause artifacts. If you want to render to a window, I recommend using the imxeglvivsink
>>> instead. In fact, this should be the default one. How did you get the plugins?
>>
>> Nothing special, I simply included gst1.0-fsl-plugin in my image.
>> I'm building my own X based image, which includes these packages:
>>           gst-player-bin
>>           gstreamer1.0-libav
>>           gst1.0-fsl-plugin
>>           gstreamer1.0-plugins-imx
>>
>
> What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?

Output attached.

Note: based on my capture of the gstreamer info (.dot), that plugin
is not what is being used by gtk-play/gst-play.  You can find the .dot
file in a previous reply on this thread (yesterday) or I'll send it
again if you need.


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

[-- Attachment #2: gst.out --]
[-- Type: text/plain, Size: 6304 bytes --]

# gst-inspect-1.0 imxeglvivsink
Factory Details:
  Rank                     primary + 1 (257)
  Long-name                Freescale EGL video sink
  Klass                    Sink/Video
  Description              Video output using the i.MX6 Vivante GPU
  Author                   Carlos Rafael Giani <dv@pseudoterminal.org>

Plugin Details:
  Name                     imxeglvivsink
  Description              EGL/GLES sink using Vivante direct textures
  Filename                 /usr/lib/gstreamer-1.0/libgstimxeglvivsink.so
  Version                  0.10.1
  License                  LGPL
  Source module            gstreamer-imx
  Binary package           Unknown package release
  Origin URL               Unknown package origin

GObject
 +----GInitiallyUnowned
       +----GstObject
             +----GstElement
                   +----GstBaseSink
                         +----GstVideoSink
                               +----GstImxEglVivSink

Implemented Interfaces:
  GstNavigation
  GstVideoOverlay

Pad Templates:
  SINK template: 'sink'
    Availability: Always
    Capabilities:
      video/x-raw
                 format: { I420, YV12, NV12, NV21, UYVY, RGB16, RGBA, BGRA, RGBx, BGRx, BGR, ARGB, ABGR, xRGB, xBGR }
                  width: [ 1, 2147483647 ]
                 height: [ 1, 2147483647 ]
              framerate: [ 0/1, 2147483647/1 ]


Element Flags:
  no flags set

Element Implementation:
  Has change_state() function: gst_imx_egl_viv_sink_change_state

Element has no clocking capabilities.
Element has no URI handling capabilities.

Pads:
  SINK: 'sink'
    Implementation:
      Has chainfunc(): gst_base_sink_chain
      Has custom eventfunc(): gst_base_sink_event
      Has custom queryfunc(): gst_base_sink_sink_query
      Has custom iterintlinkfunc(): gst_pad_iterate_internal_links_default
    Pad Template: 'sink'

Element Properties:
  name                : The name of the object
                        flags: readable, writable
                        String. Default: "imxeglvivsink0"
  parent              : The parent of the object
                        flags: readable, writable
                        Object of type "GstObject"
  sync                : Sync on the clock
                        flags: readable, writable
                        Boolean. Default: true
  max-lateness        : Maximum number of nanoseconds that a buffer can be late before it is dropped (-1 unlimited)
                        flags: readable, writable
                        Integer64. Range: -1 - 9223372036854775807 Default: 20000000 
  qos                 : Generate Quality-of-Service events upstream
                        flags: readable, writable
                        Boolean. Default: true
  async               : Go asynchronously to PAUSED
                        flags: readable, writable
                        Boolean. Default: true
  ts-offset           : Timestamp offset in nanoseconds
                        flags: readable, writable
                        Integer64. Range: -9223372036854775808 - 9223372036854775807 Default: 0 
  enable-last-sample  : Enable the last-sample property
                        flags: readable, writable
                        Boolean. Default: true
  last-sample         : The last sample received in the sink
                        flags: readable
                        Boxed pointer of type "GstSample"
  blocksize           : Size in bytes to pull per buffer (0 = default)
                        flags: readable, writable
                        Unsigned Integer. Range: 0 - 4294967295 Default: 4096 
  render-delay        : Additional render delay of the sink in nanoseconds
                        flags: readable, writable
                        Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 0 
  throttle-time       : The time to keep between rendered buffers (0 = disabled)
                        flags: readable, writable
                        Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 0 
  max-bitrate         : The maximum bits per second to render (0 = disabled)
                        flags: readable, writable
                        Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 0 
  show-preroll-frame  : Whether to render video frames during preroll
                        flags: readable, writable
                        Boolean. Default: true
  fullscreen          : Whether or not to set the created window to fullscreen mode (ignored if application provides a window handle)
                        flags: readable, writable
                        Boolean. Default: false
  force-aspect-ratio  : When enabled, scaling will respect original aspect ratio
                        flags: readable, writable
                        Boolean. Default: true
  native-display      : String identifying the display to use (default value uses the default display)
                        flags: readable, writable
                        String. Default: null
  window-x-coord      : X coordinate of the window's top left corner, in pixels
                        flags: readable, writable
                        Integer. Range: -2147483648 - 2147483647 Default: 0 
  window-y-coord      : Y coordinate of the window's top left corner, in pixels
                        flags: readable, writable
                        Integer. Range: -2147483648 - 2147483647 Default: 0 
  window-width        : Window width, in pixels (0 = automatically set to the video input width)
                        flags: readable, writable
                        Unsigned Integer. Range: 0 - 2147483647 Default: 0 
  window-height       : Window height, in pixels (0 = automatically set to the video input height)
                        flags: readable, writable
                        Unsigned Integer. Range: 0 - 2147483647 Default: 0 
  borderless-window   : Disable window borders, bypassing any window manager
                        flags: readable, writable
                        Boolean. Default: false


# opkg search /usr/lib/gstreamer-1.0/libgstimxeglvivsink.so
gstreamer1.0-plugins-imx-imxeglvivsink - 0.10.1-r0.1

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

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

It is strange that gtk-play isn't picking this one. Anyway, if you 
explicitely pick it, you should have windowed output.


Am 2015-05-19 um 13:54 schrieb Gary Thomas:
> On 2015-05-19 05:23, Carlos Rafael Giani wrote:
>>
>>
>> Am 2015-05-19 um 13:17 schrieb Gary Thomas:
>>> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>>>
>>>>>>> Thanks for the explanation, perhaps it can help someone fix 
>>>>>>> this.  My
>>>>>>> guess is that the FSL plugin doesn't handle those dynamic 
>>>>>>> elements and
>>>>>>> thus is not equipped to set up the render in the appropriate 
>>>>>>> window on
>>>>>>> the screen.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also the full-screen behavior depends the videosink 
>>>>>>>>>> configuration, so
>>>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>>>
>>>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or 
>>>>>> GstOverlaySink, as by looking at your pipeline they seem to have 
>>>>>> static pads. So it's more of how the
>>>>>> playbin/decodebin bins handle the pipeline creation process...
>>>>>
>>>>> All I know is that it does work correctly on other platforms, e.g. a
>>>>> native x86 (intel-corei7-64), as well as when there are no i.MX 
>>>>> plugins
>>>>> installed, so it's definitely tied to the FSL plugin.
>>>>
>>>> The issue here is that the IPU sink does not know anything about 
>>>> windows. It directly overwrites the framebuffer's pixels. One way I 
>>>> am trying out is to create an empty window in
>>>> the sink and let the IPU overwrite its pixels, but this is not 
>>>> exactly clean, and can cause artifacts. If you want to render to a 
>>>> window, I recommend using the imxeglvivsink
>>>> instead. In fact, this should be the default one. How did you get 
>>>> the plugins?
>>>
>>> Nothing special, I simply included gst1.0-fsl-plugin in my image.
>>> I'm building my own X based image, which includes these packages:
>>>           gst-player-bin
>>>           gstreamer1.0-libav
>>>           gst1.0-fsl-plugin
>>>           gstreamer1.0-plugins-imx
>>>
>>
>> What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?
>
> Output attached.
>
> Note: based on my capture of the gstreamer info (.dot), that plugin
> is not what is being used by gtk-play/gst-play.  You can find the .dot
> file in a previous reply on this thread (yesterday) or I'll send it
> again if you need.
>
>
>
>


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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-19 09:09, Carlos Rafael Giani wrote:
> It is strange that gtk-play isn't picking this one. Anyway, if you explicitely pick it, you should have windowed output.

Do you know how I can force that?

> Am 2015-05-19 um 13:54 schrieb Gary Thomas:
>> On 2015-05-19 05:23, Carlos Rafael Giani wrote:
>>>
>>>
>>> Am 2015-05-19 um 13:17 schrieb Gary Thomas:
>>>> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>>>>
>>>>>>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>>>>>>> guess is that the FSL plugin doesn't handle those dynamic elements and
>>>>>>>> thus is not equipped to set up the render in the appropriate window on
>>>>>>>> the screen.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Also the full-screen behavior depends the videosink configuration, so
>>>>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>>>>
>>>>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or GstOverlaySink, as by looking at your pipeline they seem to have static pads. So it's more of how the
>>>>>>> playbin/decodebin bins handle the pipeline creation process...
>>>>>>
>>>>>> All I know is that it does work correctly on other platforms, e.g. a
>>>>>> native x86 (intel-corei7-64), as well as when there are no i.MX plugins
>>>>>> installed, so it's definitely tied to the FSL plugin.
>>>>>
>>>>> The issue here is that the IPU sink does not know anything about windows. It directly overwrites the framebuffer's pixels. One way I am trying out is to create an empty window in
>>>>> the sink and let the IPU overwrite its pixels, but this is not exactly clean, and can cause artifacts. If you want to render to a window, I recommend using the imxeglvivsink
>>>>> instead. In fact, this should be the default one. How did you get the plugins?
>>>>
>>>> Nothing special, I simply included gst1.0-fsl-plugin in my image.
>>>> I'm building my own X based image, which includes these packages:
>>>>           gst-player-bin
>>>>           gstreamer1.0-libav
>>>>           gst1.0-fsl-plugin
>>>>           gstreamer1.0-plugins-imx
>>>>
>>>
>>> What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?
>>
>> Output attached.
>>
>> Note: based on my capture of the gstreamer info (.dot), that plugin
>> is not what is being used by gtk-play/gst-play.  You can find the .dot
>> file in a previous reply on this thread (yesterday) or I'll send it
>> again if you need.
>>
>>
>>
>>
>
>
>

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Nikolay Dimitrov]

Hi Gary,

On 05/19/2015 06:13 PM, Gary Thomas wrote:
> On 2015-05-19 09:09, Carlos Rafael Giani wrote:
>> It is strange that gtk-play isn't picking this one. Anyway, if you
>> explicitely pick it, you should have windowed output.
>
> Do you know how I can force that?

Hehe, one ugly way to do this is to delete the overlay plugin, thus
gtk-play won't have a big choice ;).

>> Am 2015-05-19 um 13:54 schrieb Gary Thomas:
>>> On 2015-05-19 05:23, Carlos Rafael Giani wrote:
>>>>
>>>>
>>>> Am 2015-05-19 um 13:17 schrieb Gary Thomas:
>>>>> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>>>>>
>>>>>>>>> Thanks for the explanation, perhaps it can help someone fix
>>>>>>>>> this.  My
>>>>>>>>> guess is that the FSL plugin doesn't handle those dynamic
>>>>>>>>> elements and
>>>>>>>>> thus is not equipped to set up the render in the appropriate
>>>>>>>>> window on
>>>>>>>>> the screen.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also the full-screen behavior depends the videosink
>>>>>>>>>>>> configuration, so
>>>>>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>>>>>
>>>>>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or
>>>>>>>> GstOverlaySink, as by looking at your pipeline they seem to have
>>>>>>>> static pads. So it's more of how the
>>>>>>>> playbin/decodebin bins handle the pipeline creation process...
>>>>>>>
>>>>>>> All I know is that it does work correctly on other platforms, e.g. a
>>>>>>> native x86 (intel-corei7-64), as well as when there are no i.MX
>>>>>>> plugins
>>>>>>> installed, so it's definitely tied to the FSL plugin.
>>>>>>
>>>>>> The issue here is that the IPU sink does not know anything about
>>>>>> windows. It directly overwrites the framebuffer's pixels. One way
>>>>>> I am trying out is to create an empty window in
>>>>>> the sink and let the IPU overwrite its pixels, but this is not
>>>>>> exactly clean, and can cause artifacts. If you want to render to a
>>>>>> window, I recommend using the imxeglvivsink
>>>>>> instead. In fact, this should be the default one. How did you get
>>>>>> the plugins?
>>>>>
>>>>> Nothing special, I simply included gst1.0-fsl-plugin in my image.
>>>>> I'm building my own X based image, which includes these packages:
>>>>>           gst-player-bin
>>>>>           gstreamer1.0-libav
>>>>>           gst1.0-fsl-plugin
>>>>>           gstreamer1.0-plugins-imx
>>>>>
>>>>
>>>> What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?
>>>
>>> Output attached.
>>>
>>> Note: based on my capture of the gstreamer info (.dot), that plugin
>>> is not what is being used by gtk-play/gst-play.  You can find the .dot
>>> file in a previous reply on this thread (yesterday) or I'll send it
>>> again if you need.

Regards,
Nikolay

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-19 09:09, Carlos Rafael Giani wrote:
> It is strange that gtk-play isn't picking this one. Anyway, if you explicitely pick it, you should have windowed output.

I tried forcing this via:
   gst-launch-1.0 playbin uri=file:///some_file.mp4

It starts up, then fails with:
   Setting pipeline to PAUSED ...
   Pipeline is PREROLLING ...
   [INFO]  Product Info: i.MX6Q/D/S
   [INFO]  bitstreamMode 1, chromaInterleave 0, mapType 0, tiled2LinearEnable 0
   CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Jun 19 2014 18:30:32.
   Attempt to unlock mutex that was not locked

Using GDB, I tracked this down to
#4  0xb685d318 in gst_imx_egl_viv_sink_egl_platform_expose (platform=0xa93ff460)
     at ../src/eglvivsink/egl_platform_x11.c:497

The code in question looks pretty simple:
   gboolean gst_imx_egl_viv_sink_egl_platform_expose(GstImxEglVivSinkEGLPlatform *platform)
   {
	EGL_PLATFORM_LOCK(platform);
	gst_imx_egl_viv_sink_egl_platform_send_cmd(platform, GSTIMX_EGLX11_CMD_EXPOSE);
	EGL_PLATFORM_UNLOCK(platform);
	return TRUE;
   }

It's failing on the EGL_PLATFORM_UNLOCK() call.

I did have some debug messages show up about this time (many of these):
   mxc_vpu 2040000.vpu: VPU interrupt received.
Could this be involved?

Any ideas?  I'm running this version of that code:
    git log recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb
      commit 1e5f8cea6a779c0dc374cdc3a9a6e2d0bdabbd32
      Author: Otavio Salvador <otavio@ossystems.com.br>
      Date:   Wed Apr 8 11:39:19 2015 -0300


> Am 2015-05-19 um 13:54 schrieb Gary Thomas:
>> On 2015-05-19 05:23, Carlos Rafael Giani wrote:
>>>
>>>
>>> Am 2015-05-19 um 13:17 schrieb Gary Thomas:
>>>> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>>>>
>>>>>>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>>>>>>> guess is that the FSL plugin doesn't handle those dynamic elements and
>>>>>>>> thus is not equipped to set up the render in the appropriate window on
>>>>>>>> the screen.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Also the full-screen behavior depends the videosink configuration, so
>>>>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>>>>
>>>>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or GstOverlaySink, as by looking at your pipeline they seem to have static pads. So it's more of how the
>>>>>>> playbin/decodebin bins handle the pipeline creation process...
>>>>>>
>>>>>> All I know is that it does work correctly on other platforms, e.g. a
>>>>>> native x86 (intel-corei7-64), as well as when there are no i.MX plugins
>>>>>> installed, so it's definitely tied to the FSL plugin.
>>>>>
>>>>> The issue here is that the IPU sink does not know anything about windows. It directly overwrites the framebuffer's pixels. One way I am trying out is to create an empty window in
>>>>> the sink and let the IPU overwrite its pixels, but this is not exactly clean, and can cause artifacts. If you want to render to a window, I recommend using the imxeglvivsink
>>>>> instead. In fact, this should be the default one. How did you get the plugins?
>>>>
>>>> Nothing special, I simply included gst1.0-fsl-plugin in my image.
>>>> I'm building my own X based image, which includes these packages:
>>>>           gst-player-bin
>>>>           gstreamer1.0-libav
>>>>           gst1.0-fsl-plugin
>>>>           gstreamer1.0-plugins-imx
>>>>
>>>
>>> What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?
>>
>> Output attached.
>>
>> Note: based on my capture of the gstreamer info (.dot), that plugin
>> is not what is being used by gtk-play/gst-play.  You can find the .dot
>> file in a previous reply on this thread (yesterday) or I'll send it
>> again if you need.
>>
>>
>>
>>
>
>
>

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-21 07:53, Gary Thomas wrote:
> On 2015-05-19 09:09, Carlos Rafael Giani wrote:
>> It is strange that gtk-play isn't picking this one. Anyway, if you explicitely pick it, you should have windowed output.
>
> I tried forcing this via:
>    gst-launch-1.0 playbin uri=file:///some_file.mp4

Oops, that should be:
     gst-launch-1.0 playbin uri=file:///some_file.mp4 video-sink=imxeglvivsink

I still need to figure out why playbin doesn't chose this element on its own.

>
> It starts up, then fails with:
>    Setting pipeline to PAUSED ...
>    Pipeline is PREROLLING ...
>    [INFO]  Product Info: i.MX6Q/D/S
>    [INFO]  bitstreamMode 1, chromaInterleave 0, mapType 0, tiled2LinearEnable 0
>    CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Jun 19 2014 18:30:32.
>    Attempt to unlock mutex that was not locked
>
> Using GDB, I tracked this down to
> #4  0xb685d318 in gst_imx_egl_viv_sink_egl_platform_expose (platform=0xa93ff460)
>      at ../src/eglvivsink/egl_platform_x11.c:497
>
> The code in question looks pretty simple:
>    gboolean gst_imx_egl_viv_sink_egl_platform_expose(GstImxEglVivSinkEGLPlatform *platform)
>    {
>      EGL_PLATFORM_LOCK(platform);
>      gst_imx_egl_viv_sink_egl_platform_send_cmd(platform, GSTIMX_EGLX11_CMD_EXPOSE);
>      EGL_PLATFORM_UNLOCK(platform);
>      return TRUE;
>    }
>
> It's failing on the EGL_PLATFORM_UNLOCK() call.
>
> I did have some debug messages show up about this time (many of these):
>    mxc_vpu 2040000.vpu: VPU interrupt received.
> Could this be involved?
>
> Any ideas?  I'm running this version of that code:
>     git log recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb
>       commit 1e5f8cea6a779c0dc374cdc3a9a6e2d0bdabbd32
>       Author: Otavio Salvador <otavio@ossystems.com.br>
>       Date:   Wed Apr 8 11:39:19 2015 -0300
>
>
>> Am 2015-05-19 um 13:54 schrieb Gary Thomas:
>>> On 2015-05-19 05:23, Carlos Rafael Giani wrote:
>>>>
>>>>
>>>> Am 2015-05-19 um 13:17 schrieb Gary Thomas:
>>>>> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>>>>>
>>>>>>>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>>>>>>>> guess is that the FSL plugin doesn't handle those dynamic elements and
>>>>>>>>> thus is not equipped to set up the render in the appropriate window on
>>>>>>>>> the screen.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also the full-screen behavior depends the videosink configuration, so
>>>>>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>>>>>
>>>>>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or GstOverlaySink, as by looking at your pipeline they seem to have static pads. So it's more of how the
>>>>>>>> playbin/decodebin bins handle the pipeline creation process...
>>>>>>>
>>>>>>> All I know is that it does work correctly on other platforms, e.g. a
>>>>>>> native x86 (intel-corei7-64), as well as when there are no i.MX plugins
>>>>>>> installed, so it's definitely tied to the FSL plugin.
>>>>>>
>>>>>> The issue here is that the IPU sink does not know anything about windows. It directly overwrites the framebuffer's pixels. One way I am trying out is to create an empty
>>>>>> window in
>>>>>> the sink and let the IPU overwrite its pixels, but this is not exactly clean, and can cause artifacts. If you want to render to a window, I recommend using the imxeglvivsink
>>>>>> instead. In fact, this should be the default one. How did you get the plugins?
>>>>>
>>>>> Nothing special, I simply included gst1.0-fsl-plugin in my image.
>>>>> I'm building my own X based image, which includes these packages:
>>>>>           gst-player-bin
>>>>>           gstreamer1.0-libav
>>>>>           gst1.0-fsl-plugin
>>>>>           gstreamer1.0-plugins-imx
>>>>>
>>>>
>>>> What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?
>>>
>>> Output attached.
>>>
>>> Note: based on my capture of the gstreamer info (.dot), that plugin
>>> is not what is being used by gtk-play/gst-play.  You can find the .dot
>>> file in a previous reply on this thread (yesterday) or I'll send it
>>> again if you need.
>>>
>>>
>>>
>>>
>>
>>
>>

-- 
Gary Thomas

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Nikolay Dimitrov]

Hi Gary,

On 05/21/2015 05:13 PM, Gary Thomas wrote:
> On 2015-05-21 07:53, Gary Thomas wrote:
>> On 2015-05-19 09:09, Carlos Rafael Giani wrote:
>>> It is strange that gtk-play isn't picking this one. Anyway, if you
>>> explicitely pick it, you should have windowed output.
>>
>> I tried forcing this via:
>>    gst-launch-1.0 playbin uri=file:///some_file.mp4
>
> Oops, that should be:
>      gst-launch-1.0 playbin uri=file:///some_file.mp4
> video-sink=imxeglvivsink
>
> I still need to figure out why playbin doesn't chose this element on its
> own.

You can see which video-sink element was cherry-picked by playbin and
delete (or move it somewhere, just make sure it's not available as .so
in gstreamer plugins dir).

Now repeat this until playbin doesn't have a choice anymore :D.

>> It starts up, then fails with:
>>    Setting pipeline to PAUSED ...
>>    Pipeline is PREROLLING ...
>>    [INFO]  Product Info: i.MX6Q/D/S
>>    [INFO]  bitstreamMode 1, chromaInterleave 0, mapType 0,
>> tiled2LinearEnable 0
>>    CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Jun
>> 19 2014 18:30:32.
>>    Attempt to unlock mutex that was not locked
>>
>> Using GDB, I tracked this down to
>> #4  0xb685d318 in gst_imx_egl_viv_sink_egl_platform_expose
>> (platform=0xa93ff460)
>>      at ../src/eglvivsink/egl_platform_x11.c:497
>>
>> The code in question looks pretty simple:
>>    gboolean
>> gst_imx_egl_viv_sink_egl_platform_expose(GstImxEglVivSinkEGLPlatform
>> *platform)
>>    {
>>      EGL_PLATFORM_LOCK(platform);
>>      gst_imx_egl_viv_sink_egl_platform_send_cmd(platform,
>> GSTIMX_EGLX11_CMD_EXPOSE);
>>      EGL_PLATFORM_UNLOCK(platform);
>>      return TRUE;
>>    }
>>
>> It's failing on the EGL_PLATFORM_UNLOCK() call.
>>
>> I did have some debug messages show up about this time (many of these):
>>    mxc_vpu 2040000.vpu: VPU interrupt received.
>> Could this be involved?
>>
>> Any ideas?  I'm running this version of that code:
>>     git log
>> recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb
>>       commit 1e5f8cea6a779c0dc374cdc3a9a6e2d0bdabbd32
>>       Author: Otavio Salvador <otavio@ossystems.com.br>
>>       Date:   Wed Apr 8 11:39:19 2015 -0300
>>
>>
>>> Am 2015-05-19 um 13:54 schrieb Gary Thomas:
>>>> On 2015-05-19 05:23, Carlos Rafael Giani wrote:
>>>>>
>>>>>
>>>>> Am 2015-05-19 um 13:17 schrieb Gary Thomas:
>>>>>> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>>>>>>
>>>>>>>>>> Thanks for the explanation, perhaps it can help someone fix
>>>>>>>>>> this.  My
>>>>>>>>>> guess is that the FSL plugin doesn't handle those dynamic
>>>>>>>>>> elements and
>>>>>>>>>> thus is not equipped to set up the render in the appropriate
>>>>>>>>>> window on
>>>>>>>>>> the screen.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also the full-screen behavior depends the videosink
>>>>>>>>>>>>> configuration, so
>>>>>>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>>>>>>
>>>>>>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or
>>>>>>>>> GstOverlaySink, as by looking at your pipeline they seem to
>>>>>>>>> have static pads. So it's more of how the
>>>>>>>>> playbin/decodebin bins handle the pipeline creation process...
>>>>>>>>
>>>>>>>> All I know is that it does work correctly on other platforms,
>>>>>>>> e.g. a
>>>>>>>> native x86 (intel-corei7-64), as well as when there are no i.MX
>>>>>>>> plugins
>>>>>>>> installed, so it's definitely tied to the FSL plugin.
>>>>>>>
>>>>>>> The issue here is that the IPU sink does not know anything about
>>>>>>> windows. It directly overwrites the framebuffer's pixels. One way
>>>>>>> I am trying out is to create an empty
>>>>>>> window in
>>>>>>> the sink and let the IPU overwrite its pixels, but this is not
>>>>>>> exactly clean, and can cause artifacts. If you want to render to
>>>>>>> a window, I recommend using the imxeglvivsink
>>>>>>> instead. In fact, this should be the default one. How did you get
>>>>>>> the plugins?
>>>>>>
>>>>>> Nothing special, I simply included gst1.0-fsl-plugin in my image.
>>>>>> I'm building my own X based image, which includes these packages:
>>>>>>           gst-player-bin
>>>>>>           gstreamer1.0-libav
>>>>>>           gst1.0-fsl-plugin
>>>>>>           gstreamer1.0-plugins-imx
>>>>>>
>>>>>
>>>>> What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?
>>>>
>>>> Output attached.
>>>>
>>>> Note: based on my capture of the gstreamer info (.dot), that plugin
>>>> is not what is being used by gtk-play/gst-play.  You can find the .dot
>>>> file in a previous reply on this thread (yesterday) or I'll send it
>>>> again if you need.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Nikolay Dimitrov]

On 05/21/2015 05:40 PM, Nikolay Dimitrov wrote:
> Hi Gary,
>
> On 05/21/2015 05:13 PM, Gary Thomas wrote:
>> On 2015-05-21 07:53, Gary Thomas wrote:
>>> On 2015-05-19 09:09, Carlos Rafael Giani wrote:
>>>> It is strange that gtk-play isn't picking this one. Anyway, if you
>>>> explicitely pick it, you should have windowed output.
>>>
>>> I tried forcing this via:
>>>    gst-launch-1.0 playbin uri=file:///some_file.mp4
>>
>> Oops, that should be:
>>      gst-launch-1.0 playbin uri=file:///some_file.mp4
>> video-sink=imxeglvivsink
>>
>> I still need to figure out why playbin doesn't chose this element on its
>> own.
>
> You can see which video-sink element was cherry-picked by playbin and
> delete (or move it somewhere, just make sure it's not available as .so
> in gstreamer plugins dir).
>
> Now repeat this until playbin doesn't have a choice anymore :D.

A more permanent (and better) solution would be to push the plugin rank
higher in the source code, so it could be easily preferred by the
plugin factory when autoplugged.

Regards,
Nikolay

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

Are you starting this from SSH or minicom? If so, make sure you call 
this first:

export DISPLAY=:0

Otherwise, it will not be able to connect to the X display. This might 
explain why the eglvivsink wasn't being picked.
As for the double mutex unlock, this might already have a fix. I'll check.


On 05/21/2015 03:53 PM, Gary Thomas wrote:
> On 2015-05-19 09:09, Carlos Rafael Giani wrote:
>> It is strange that gtk-play isn't picking this one. Anyway, if you 
>> explicitely pick it, you should have windowed output.
>
> I tried forcing this via:
>   gst-launch-1.0 playbin uri=file:///some_file.mp4
>
> It starts up, then fails with:
>   Setting pipeline to PAUSED ...
>   Pipeline is PREROLLING ...
>   [INFO]  Product Info: i.MX6Q/D/S
>   [INFO]  bitstreamMode 1, chromaInterleave 0, mapType 0, 
> tiled2LinearEnable 0
>   CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Jun 19 
> 2014 18:30:32.
>   Attempt to unlock mutex that was not locked
>
> Using GDB, I tracked this down to
> #4  0xb685d318 in gst_imx_egl_viv_sink_egl_platform_expose 
> (platform=0xa93ff460)
>     at ../src/eglvivsink/egl_platform_x11.c:497
>
> The code in question looks pretty simple:
>   gboolean 
> gst_imx_egl_viv_sink_egl_platform_expose(GstImxEglVivSinkEGLPlatform 
> *platform)
>   {
>     EGL_PLATFORM_LOCK(platform);
>     gst_imx_egl_viv_sink_egl_platform_send_cmd(platform, 
> GSTIMX_EGLX11_CMD_EXPOSE);
>     EGL_PLATFORM_UNLOCK(platform);
>     return TRUE;
>   }
>
> It's failing on the EGL_PLATFORM_UNLOCK() call.
>
> I did have some debug messages show up about this time (many of these):
>   mxc_vpu 2040000.vpu: VPU interrupt received.
> Could this be involved?
>
> Any ideas?  I'm running this version of that code:
>    git log 
> recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb
>      commit 1e5f8cea6a779c0dc374cdc3a9a6e2d0bdabbd32
>      Author: Otavio Salvador <otavio@ossystems.com.br>
>      Date:   Wed Apr 8 11:39:19 2015 -0300
>
>
>> Am 2015-05-19 um 13:54 schrieb Gary Thomas:
>>> On 2015-05-19 05:23, Carlos Rafael Giani wrote:
>>>>
>>>>
>>>> Am 2015-05-19 um 13:17 schrieb Gary Thomas:
>>>>> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>>>>>
>>>>>>>>> Thanks for the explanation, perhaps it can help someone fix 
>>>>>>>>> this.  My
>>>>>>>>> guess is that the FSL plugin doesn't handle those dynamic 
>>>>>>>>> elements and
>>>>>>>>> thus is not equipped to set up the render in the appropriate 
>>>>>>>>> window on
>>>>>>>>> the screen.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also the full-screen behavior depends the videosink 
>>>>>>>>>>>> configuration, so
>>>>>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>>>>>
>>>>>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or 
>>>>>>>> GstOverlaySink, as by looking at your pipeline they seem to 
>>>>>>>> have static pads. So it's more of how the
>>>>>>>> playbin/decodebin bins handle the pipeline creation process...
>>>>>>>
>>>>>>> All I know is that it does work correctly on other platforms, 
>>>>>>> e.g. a
>>>>>>> native x86 (intel-corei7-64), as well as when there are no i.MX 
>>>>>>> plugins
>>>>>>> installed, so it's definitely tied to the FSL plugin.
>>>>>>
>>>>>> The issue here is that the IPU sink does not know anything about 
>>>>>> windows. It directly overwrites the framebuffer's pixels. One way 
>>>>>> I am trying out is to create an empty window in
>>>>>> the sink and let the IPU overwrite its pixels, but this is not 
>>>>>> exactly clean, and can cause artifacts. If you want to render to 
>>>>>> a window, I recommend using the imxeglvivsink
>>>>>> instead. In fact, this should be the default one. How did you get 
>>>>>> the plugins?
>>>>>
>>>>> Nothing special, I simply included gst1.0-fsl-plugin in my image.
>>>>> I'm building my own X based image, which includes these packages:
>>>>>           gst-player-bin
>>>>>           gstreamer1.0-libav
>>>>>           gst1.0-fsl-plugin
>>>>>           gstreamer1.0-plugins-imx
>>>>>
>>>>
>>>> What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?
>>>
>>> Output attached.
>>>
>>> Note: based on my capture of the gstreamer info (.dot), that plugin
>>> is not what is being used by gtk-play/gst-play.  You can find the .dot
>>> file in a previous reply on this thread (yesterday) or I'll send it
>>> again if you need.
>>>
>>>
>>>
>>>
>>
>>
>>

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-21 08:46, Carlos Rafael Giani wrote:
> Are you starting this from SSH or minicom? If so, make sure you call this first:
>
> export DISPLAY=:0
>
> Otherwise, it will not be able to connect to the X display. This might explain why the eglvivsink wasn't being picked.
> As for the double mutex unlock, this might already have a fix. I'll check.

Yes, I have DISPLAY set.  playbin without any video-sink option works
fine to my device, but it goes in an overlay (whole screen).  I'm trying
to investigate how to make it work correctly when rendered into a window,
e.g. called from gtk-play/gst-play

>
>
> On 05/21/2015 03:53 PM, Gary Thomas wrote:
>> On 2015-05-19 09:09, Carlos Rafael Giani wrote:
>>> It is strange that gtk-play isn't picking this one. Anyway, if you explicitely pick it, you should have windowed output.
>>
>> I tried forcing this via:
>>   gst-launch-1.0 playbin uri=file:///some_file.mp4
>>
>> It starts up, then fails with:
>>   Setting pipeline to PAUSED ...
>>   Pipeline is PREROLLING ...
>>   [INFO]  Product Info: i.MX6Q/D/S
>>   [INFO]  bitstreamMode 1, chromaInterleave 0, mapType 0, tiled2LinearEnable 0
>>   CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Jun 19 2014 18:30:32.
>>   Attempt to unlock mutex that was not locked
>>
>> Using GDB, I tracked this down to
>> #4  0xb685d318 in gst_imx_egl_viv_sink_egl_platform_expose (platform=0xa93ff460)
>>     at ../src/eglvivsink/egl_platform_x11.c:497
>>
>> The code in question looks pretty simple:
>>   gboolean gst_imx_egl_viv_sink_egl_platform_expose(GstImxEglVivSinkEGLPlatform *platform)
>>   {
>>     EGL_PLATFORM_LOCK(platform);
>>     gst_imx_egl_viv_sink_egl_platform_send_cmd(platform, GSTIMX_EGLX11_CMD_EXPOSE);
>>     EGL_PLATFORM_UNLOCK(platform);
>>     return TRUE;
>>   }
>>
>> It's failing on the EGL_PLATFORM_UNLOCK() call.
>>
>> I did have some debug messages show up about this time (many of these):
>>   mxc_vpu 2040000.vpu: VPU interrupt received.
>> Could this be involved?
>>
>> Any ideas?  I'm running this version of that code:
>>    git log recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb
>>      commit 1e5f8cea6a779c0dc374cdc3a9a6e2d0bdabbd32
>>      Author: Otavio Salvador <otavio@ossystems.com.br>
>>      Date:   Wed Apr 8 11:39:19 2015 -0300
>>
>>
>>> Am 2015-05-19 um 13:54 schrieb Gary Thomas:
>>>> On 2015-05-19 05:23, Carlos Rafael Giani wrote:
>>>>>
>>>>>
>>>>> Am 2015-05-19 um 13:17 schrieb Gary Thomas:
>>>>>> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>>>>>>
>>>>>>>>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>>>>>>>>> guess is that the FSL plugin doesn't handle those dynamic elements and
>>>>>>>>>> thus is not equipped to set up the render in the appropriate window on
>>>>>>>>>> the screen.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also the full-screen behavior depends the videosink configuration, so
>>>>>>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>>>>>>
>>>>>>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or GstOverlaySink, as by looking at your pipeline they seem to have static pads. So it's more of how the
>>>>>>>>> playbin/decodebin bins handle the pipeline creation process...
>>>>>>>>
>>>>>>>> All I know is that it does work correctly on other platforms, e.g. a
>>>>>>>> native x86 (intel-corei7-64), as well as when there are no i.MX plugins
>>>>>>>> installed, so it's definitely tied to the FSL plugin.
>>>>>>>
>>>>>>> The issue here is that the IPU sink does not know anything about windows. It directly overwrites the framebuffer's pixels. One way I am trying out is to create an empty
>>>>>>> window in
>>>>>>> the sink and let the IPU overwrite its pixels, but this is not exactly clean, and can cause artifacts. If you want to render to a window, I recommend using the imxeglvivsink
>>>>>>> instead. In fact, this should be the default one. How did you get the plugins?
>>>>>>
>>>>>> Nothing special, I simply included gst1.0-fsl-plugin in my image.
>>>>>> I'm building my own X based image, which includes these packages:
>>>>>>           gst-player-bin
>>>>>>           gstreamer1.0-libav
>>>>>>           gst1.0-fsl-plugin
>>>>>>           gstreamer1.0-plugins-imx
>>>>>>
>>>>>
>>>>> What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?
>>>>
>>>> Output attached.
>>>>
>>>> Note: based on my capture of the gstreamer info (.dot), that plugin
>>>> is not what is being used by gtk-play/gst-play.  You can find the .dot
>>>> file in a previous reply on this thread (yesterday) or I'll send it
>>>> again if you need.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-21 08:52, Gary Thomas wrote:
> On 2015-05-21 08:46, Carlos Rafael Giani wrote:
>> Are you starting this from SSH or minicom? If so, make sure you call this first:
>>
>> export DISPLAY=:0
>>
>> Otherwise, it will not be able to connect to the X display. This might explain why the eglvivsink wasn't being picked.
>> As for the double mutex unlock, this might already have a fix. I'll check.
>
> Yes, I have DISPLAY set.  playbin without any video-sink option works
> fine to my device, but it goes in an overlay (whole screen).  I'm trying
> to investigate how to make it work correctly when rendered into a window,
> e.g. called from gtk-play/gst-play
>
>>
>>
>> On 05/21/2015 03:53 PM, Gary Thomas wrote:
>>> On 2015-05-19 09:09, Carlos Rafael Giani wrote:
>>>> It is strange that gtk-play isn't picking this one. Anyway, if you explicitely pick it, you should have windowed output.
>>>
>>> I tried forcing this via:
>>>   gst-launch-1.0 playbin uri=file:///some_file.mp4
>>>
>>> It starts up, then fails with:
>>>   Setting pipeline to PAUSED ...
>>>   Pipeline is PREROLLING ...
>>>   [INFO]  Product Info: i.MX6Q/D/S
>>>   [INFO]  bitstreamMode 1, chromaInterleave 0, mapType 0, tiled2LinearEnable 0
>>>   CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Jun 19 2014 18:30:32.
>>>   Attempt to unlock mutex that was not locked
>>>
>>> Using GDB, I tracked this down to
>>> #4  0xb685d318 in gst_imx_egl_viv_sink_egl_platform_expose (platform=0xa93ff460)
>>>     at ../src/eglvivsink/egl_platform_x11.c:497
>>>
>>> The code in question looks pretty simple:
>>>   gboolean gst_imx_egl_viv_sink_egl_platform_expose(GstImxEglVivSinkEGLPlatform *platform)
>>>   {
>>>     EGL_PLATFORM_LOCK(platform);
>>>     gst_imx_egl_viv_sink_egl_platform_send_cmd(platform, GSTIMX_EGLX11_CMD_EXPOSE);
>>>     EGL_PLATFORM_UNLOCK(platform);
>>>     return TRUE;
>>>   }
>>>
>>> It's failing on the EGL_PLATFORM_UNLOCK() call.
>>>
>>> I did have some debug messages show up about this time (many of these):
>>>   mxc_vpu 2040000.vpu: VPU interrupt received.
>>> Could this be involved?
>>>
>>> Any ideas?  I'm running this version of that code:
>>>    git log recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb
>>>      commit 1e5f8cea6a779c0dc374cdc3a9a6e2d0bdabbd32
>>>      Author: Otavio Salvador <otavio@ossystems.com.br>
>>>      Date:   Wed Apr 8 11:39:19 2015 -0300
>>>

Any ideas on how to get this to work (i.e. fix the broken locking)?

>>>
>>>> Am 2015-05-19 um 13:54 schrieb Gary Thomas:
>>>>> On 2015-05-19 05:23, Carlos Rafael Giani wrote:
>>>>>>
>>>>>>
>>>>>> Am 2015-05-19 um 13:17 schrieb Gary Thomas:
>>>>>>> On 2015-05-19 05:11, Carlos Rafael Giani wrote:
>>>>>>>>
>>>>>>>>>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>>>>>>>>>> guess is that the FSL plugin doesn't handle those dynamic elements and
>>>>>>>>>>> thus is not equipped to set up the render in the appropriate window on
>>>>>>>>>>> the screen.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also the full-screen behavior depends the videosink configuration, so
>>>>>>>>>>>>>> hard to give universal answer, as none will fit all cases.
>>>>>>>>>>
>>>>>>>>>> I doubt that the issue is caused exactly by the GstImxVpuDec or GstOverlaySink, as by looking at your pipeline they seem to have static pads. So it's more of how the
>>>>>>>>>> playbin/decodebin bins handle the pipeline creation process...
>>>>>>>>>
>>>>>>>>> All I know is that it does work correctly on other platforms, e.g. a
>>>>>>>>> native x86 (intel-corei7-64), as well as when there are no i.MX plugins
>>>>>>>>> installed, so it's definitely tied to the FSL plugin.
>>>>>>>>
>>>>>>>> The issue here is that the IPU sink does not know anything about windows. It directly overwrites the framebuffer's pixels. One way I am trying out is to create an empty
>>>>>>>> window in
>>>>>>>> the sink and let the IPU overwrite its pixels, but this is not exactly clean, and can cause artifacts. If you want to render to a window, I recommend using the imxeglvivsink
>>>>>>>> instead. In fact, this should be the default one. How did you get the plugins?
>>>>>>>
>>>>>>> Nothing special, I simply included gst1.0-fsl-plugin in my image.
>>>>>>> I'm building my own X based image, which includes these packages:
>>>>>>>           gst-player-bin
>>>>>>>           gstreamer1.0-libav
>>>>>>>           gst1.0-fsl-plugin
>>>>>>>           gstreamer1.0-plugins-imx
>>>>>>>
>>>>>>
>>>>>> What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?
>>>>>
>>>>> Output attached.
>>>>>
>>>>> Note: based on my capture of the gstreamer info (.dot), that plugin
>>>>> is not what is being used by gtk-play/gst-play.  You can find the .dot
>>>>> file in a previous reply on this thread (yesterday) or I'll send it
>>>>> again if you need.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

On 05/26/2015 03:50 PM, Gary Thomas wrote:
>
> Any ideas on how to get this to work (i.e. fix the broken locking)?

Try if building the current master (not 0.10.1) fixes it.

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-26 07:59, Carlos Rafael Giani wrote:
> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>
>> Any ideas on how to get this to work (i.e. fix the broken locking)?
>
> Try if building the current master (not 0.10.1) fixes it.

That's what I'm running:
   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

Try to re-run the playbin pipeline with the GST_DEBUG environment 
variable set to: "2,*imx*:9", and post the log please.


Am 2015-05-26 um 16:04 schrieb Gary Thomas:
> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>
>>> Any ideas on how to get this to work (i.e. fix the broken locking)?
>>
>> Try if building the current master (not 0.10.1) fixes it.
>
> That's what I'm running:
>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

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

On 2015-05-26 12:53, Carlos Rafael Giani wrote:
> Try to re-run the playbin pipeline with the GST_DEBUG environment variable set to: "2,*imx*:9", and post the log please.

Here it is.

> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>
>>>> Any ideas on how to get this to work (i.e. fix the broken locking)?
>>>
>>> Try if building the current master (not 0.10.1) fixes it.
>>
>> That's what I'm running:
>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>
>

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

[-- Attachment #2: gst-play.log --]
[-- Type: text/x-log, Size: 30212 bytes --]

0:00:00.134832666  1507  0x1d53580 INFO      imxeglplatform_x11 egl_platform_x11.c:114:gst_imx_egl_viv_sink_egl_platform_create: X11 EGL platform initialized, using EGL 1.4
0:00:00.139438000  1507  0x1d53580 WARN                 basesrc gstbasesrc.c:3470:gst_base_src_start_complete:<source> pad not activated yet
0:00:00.142412333  1507  0x1d53580 WARN                 basesrc gstbasesrc.c:3470:gst_base_src_start_complete:<source> pad not activated yet
0:00:00.239343000  1507 0xabf3cfb0 WARN                 qtdemux qtdemux_types.c:202:qtdemux_type_get: unknown QuickTime node type iods
0:00:00.239724333  1507 0xabf3cfb0 WARN                 qtdemux qtdemux_types.c:202:qtdemux_type_get: unknown QuickTime node type pasp
0:00:00.239807667  1507 0xabf3cfb0 WARN                 qtdemux qtdemux_types.c:202:qtdemux_type_get: unknown QuickTime node type sgpd
0:00:00.239872000  1507 0xabf3cfb0 WARN                 qtdemux qtdemux_types.c:202:qtdemux_type_get: unknown QuickTime node type sbgp
0:00:00.240018667  1507 0xabf3cfb0 WARN                 qtdemux qtdemux_types.c:202:qtdemux_type_get: unknown QuickTime node type iods
0:00:00.240146333  1507 0xabf3cfb0 WARN                 qtdemux qtdemux_types.c:202:qtdemux_type_get: unknown QuickTime node type pasp
0:00:00.247243667  1507 0xabf3cfb0 WARN                 qtdemux qtdemux_types.c:202:qtdemux_type_get: unknown QuickTime node type sgpd
0:00:00.247285667  1507 0xabf3cfb0 WARN                 qtdemux qtdemux_types.c:202:qtdemux_type_get: unknown QuickTime node type sbgp
0:00:00.288039333  1507 0xab412f80 INFO               imxvpudec decoder.c:666:gst_imx_vpu_dec_start:<imxvpudec0> starting VPU decoder
0:00:00.293150000  1507 0xab412f80 INFO               imxvpudec decoder.c:340:gst_imx_vpu_dec_load: VPU loaded
0:00:00.293204000  1507 0xab412f80 INFO               imxvpudec decoder.c:341:gst_imx_vpu_dec_load: VPU firmware version 3.1.1_r46063
0:00:00.293246333  1507 0xab412f80 INFO               imxvpudec decoder.c:342:gst_imx_vpu_dec_load: VPU library version 5.4.28
0:00:00.293278000  1507 0xab412f80 INFO               imxvpudec decoder.c:343:gst_imx_vpu_dec_load: VPU wrapper version 1.0.58 VPUWRAPPER_ARM_LINUX Build on May 21 2015 10:23:30
0:00:00.293350000  1507 0xab412f80 INFO               imxvpudec decoder.c:384:gst_imx_vpu_dec_alloc_dec_mem_blocks:<imxvpudec0> need to allocate 2 sub blocks for decoding
0:00:00.293384333  1507 0xab412f80 INFO               imxvpudec decoder.c:388:gst_imx_vpu_dec_alloc_dec_mem_blocks:<imxvpudec0> sub block 0  type: virtual  size: 5676
0:00:00.293469000  1507 0xab412f80 INFO         imxvpumemblocks mem_blocks.c:50:gst_imx_vpu_alloc_virt_mem_block: allocated 5676 bytes of heap memory at virt addr 0xaaa10010
0:00:00.293513667  1507 0xab412f80 INFO               imxvpudec decoder.c:388:gst_imx_vpu_dec_alloc_dec_mem_blocks:<imxvpudec0> sub block 1  type: physical  size: 5236744
0:00:00.293723000  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:62:gst_imx_phys_mem_allocator_init:<GstImxPhysMemAllocator@0xab4034f8> initializing physical memory allocator
0:00:00.293841000  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 5236744, align: 0, offset: 0, size: 5236744
0:00:00.310837333  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa985a000 phys: 0x38800000 cpu: 0xe8800000
0:00:00.310908333  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa04a98 at phys addr 0x38800000 with 5236744 bytes
0:00:00.310954667  1507 0xab412f80 INFO               imxvpudec decoder.c:693:gst_imx_vpu_dec_start:<imxvpudec0> VPU decoder started
0:00:00.312911333  1507 0xab412f80 INFO               imxvpudec decoder.c:760:gst_imx_vpu_dec_set_format:<imxvpudec0> setting decoder format
0:00:00.312947000  1507 0xab412f80 INFO               imxvpudec decoder.c:763:gst_imx_vpu_dec_set_format:<imxvpudec0> draining remaining frames from decoder
0:00:00.312991000  1507 0xab412f80 INFO               imxvpudec decoder.c:460:gst_imx_vpu_dec_fill_param_set:<imxvpudec0> setting h.264 as stream format
0:00:00.318514333  1507 0xab412f80 INFO               imxvpudec decoder.c:861:gst_imx_vpu_dec_set_format:<imxvpudec0> setting format finished
0:00:00.319014667  1507 0xab412f80 LOG                imxvpudec decoder.c:925:gst_imx_vpu_dec_handle_frame:<imxvpudec0> VPU_DecDecodeBuf returns: 201
0:00:00.319069333  1507 0xab412f80 LOG                imxvpudec decoder.c:961:gst_imx_vpu_dec_handle_frame:<imxvpudec0> using I420 as video output format
0:00:00.319106333  1507 0xab412f80 INFO               imxvpudec decoder.c:974:gst_imx_vpu_dec_handle_frame:<imxvpudec0> minimum number of framebuffers indicated by the VPU: 6  chosen number: 12
0:00:00.319174667  1507 0xab412f80 INFO               imxvpudec decoder.c:975:gst_imx_vpu_dec_handle_frame:<imxvpudec0> interlacing: 0
0:00:00.319394333  1507 0xab412f80 INFO      imxvpuframebuffers framebuffers.c:249:gst_imx_vpu_framebuffers_configure:<imxvpuframebuffers0> framebuffer requested width/height: 1280/720  actual width/height (after alignment): 1280/720  Y stride: 1280
0:00:00.319451000  1507 0xab412f80 INFO      imxvpuframebuffers framebuffers.c:254:gst_imx_vpu_framebuffers_configure:<imxvpuframebuffers0> num framebuffers:  total: 12  available: 12
0:00:00.319487667  1507 0xab412f80 INFO      imxvpuframebuffers framebuffers.c:259:gst_imx_vpu_framebuffers_configure:<imxvpuframebuffers0> framebuffer memory block size:  total: 1612801  Y: 921600  U: 230400  V: 230400  Mv:  230400  alignment: 1
0:00:00.319538333  1507 0xab412f80 INFO      imxvpuframebuffers framebuffers.c:264:gst_imx_vpu_framebuffers_configure:<imxvpuframebuffers0> total memory required for all framebuffers: 1612801 * 12 = 19353612 byte
0:00:00.319579667  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.326331667  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa8b76000 phys: 0x38d00000 cpu: 0xe8d00000
0:00:00.326424333  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa04cc0 at phys addr 0x38d00000 with 1612801 bytes
0:00:00.326487000  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
Home directory not accessible: Permission denied
0:00:00.332008000  1507 0xab413260 WARN                   pulse pulsesink.c:615:gst_pulseringbuffer_open_device:<pulsesink0> error: Failed to connect: Connection refused
0:00:00.333299667  1507 0xab413260 WARN                 playbin gstplaybin2.c:4497:autoplug_select_cb:<playbin> Could not activate sink pulsesink
0:00:00.336636667  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa89ec000 phys: 0x38f00000 cpu: 0xe8f00000
0:00:00.336711333  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa04d10 at phys addr 0x38f00000 with 1612801 bytes
0:00:00.336758667  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.342781667  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa8862000 phys: 0x39100000 cpu: 0xe9100000
0:00:00.342856667  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa04c20 at phys addr 0x39100000 with 1612801 bytes
0:00:00.342923667  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.349786333  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa86d8000 phys: 0x39300000 cpu: 0xe9300000
0:00:00.349860000  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa04c70 at phys addr 0x39300000 with 1612801 bytes
0:00:00.349905333  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.356415667  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa854e000 phys: 0x39500000 cpu: 0xe9500000
0:00:00.356494333  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa04b38 at phys addr 0x39500000 with 1612801 bytes
0:00:00.356546333  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.358923667  1507 0xab413260 WARN                    alsa conf.c:4563:parse_args: alsalib error: Unknown parameter AES0
0:00:00.358987000  1507 0xab413260 WARN                    alsa conf.c:4723:snd_config_expand: alsalib error: Parse arguments error: No such file or directory
0:00:00.359033667  1507 0xab413260 WARN                    alsa pcm.c:2267:snd_pcm_open_noupdate: alsalib error: Unknown PCM default:{AES0 0x02 AES1 0x82 AES2 0x00 AES3 0x02}
0:00:00.361610000  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:64:gst_imx_audio_uniaudio_codec_table_init_internal: Caps: audio/mpeg, mpegversion=(int)4, framed=(boolean)true, stream-format=(string){ raw, adts, adif }
0:00:00.361742000  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:92:gst_imx_audio_uniaudio_codec_load_codec: trying to load library /usr/lib/imx-mm/audio-codec/wrap/lib_aacd_wrap_arm12_elinux.so.3
0:00:00.365151667  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa83c4000 phys: 0x39700000 cpu: 0xe9700000
0:00:00.365318333  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa04ae8 at phys addr 0x39700000 with 1612801 bytes
0:00:00.365369333  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.365519333  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:64:gst_imx_audio_uniaudio_codec_table_init_internal: Caps: audio/mpeg, mpegversion=(int)1, layer=(int)3, parsed=(boolean)true
0:00:00.365597333  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:92:gst_imx_audio_uniaudio_codec_load_codec: trying to load library /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm12_elinux.so.3
0:00:00.366516000  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:64:gst_imx_audio_uniaudio_codec_table_init_internal: Caps: audio/x-vorbis
0:00:00.366558667  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:92:gst_imx_audio_uniaudio_codec_load_codec: trying to load library /usr/lib/imx-mm/audio-codec/wrap/lib_vorbisd_wrap_arm12_elinux.so.3
0:00:00.367674667  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:64:gst_imx_audio_uniaudio_codec_table_init_internal: Caps: audio/AMR
0:00:00.367828667  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:92:gst_imx_audio_uniaudio_codec_load_codec: trying to load library /usr/lib/imx-mm/audio-codec/wrap/lib_nbamrd_wrap_arm11_elinux.so.1
0:00:00.369606667  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:64:gst_imx_audio_uniaudio_codec_table_init_internal: Caps: audio/AMR-WB
0:00:00.369698000  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:92:gst_imx_audio_uniaudio_codec_load_codec: trying to load library /usr/lib/imx-mm/audio-codec/wrap/lib_wbamrd_wrap_arm12_elinux.so.1
0:00:00.371135000  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:170:gst_imx_audio_uniaudio_dec_class_init: decoder sink caps: audio/mpeg, mpegversion=(int)4, framed=(boolean)true, stream-format=(string){ raw, adts, adif }; audio/mpeg, mpegversion=(int)1, layer=(int)3, parsed=(boolean)true; audio/x-vorbis; audio/AMR; audio/AMR-WB
0:00:00.372574000  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa81f1000 phys: 0x39900000 cpu: 0xe9900000
0:00:00.372659333  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa049f8 at phys addr 0x39900000 with 1612801 bytes
0:00:00.372706333  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.374362667  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:167:gst_imx_audio_uniaudio_codec_table_get_codec: trying to find suitable codec for caps audio/mpeg, mpegversion=(int)4, framed=(boolean)true, stream-format=(string)raw, level=(string)2, base-profile=(string)lc, profile=(string)lc, codec_data=(buffer)1190, rate=(int)48000, channels=(int)2
0:00:00.374505000  1507 0xab413260 DEBUG       imxuniaudiocodec uniaudio_codec.c:172:gst_imx_audio_uniaudio_codec_table_get_codec: codec caps audio/mpeg, mpegversion=(int)4, framed=(boolean)true, stream-format=(string){ raw, adts, adif } compatible: yes
0:00:00.374823667  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:299:gst_imx_audio_uniaudio_dec_set_format:<imxaudiouniaudiodec0> input is framed: 1
0:00:00.374902667  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:304:gst_imx_audio_uniaudio_dec_set_format:<imxaudiouniaudiodec0> input caps sample rate: 48000 Hz
0:00:00.374953333  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:313:gst_imx_audio_uniaudio_dec_set_format:<imxaudiouniaudiodec0> input caps channel count: 2
0:00:00.375003000  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:346:gst_imx_audio_uniaudio_dec_set_format:<imxaudiouniaudiodec0> input caps stream format: raw
0:00:00.375053000  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:395:gst_imx_audio_uniaudio_dec_set_format:<imxaudiouniaudiodec0> reading codec_data value
0:00:00.375155333  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:442:gst_imx_audio_uniaudio_dec_set_format:<imxaudiouniaudiodec0> codec data: 2 byte
0:00:00.375210000  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:446:gst_imx_audio_uniaudio_dec_set_format:<imxaudiouniaudiodec0> decoder configured
0:00:00.375390333  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:492:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> feeding 427 bytes to the decoder
0:00:00.376612667  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:503:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> decode_frame:  return 0x200  offset 427  out_size 0
0:00:00.376727667  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:563:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> output sample width: 16  depth: 16
0:00:00.376776667  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:566:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> setting output format to: S16LE  48000 Hz  2 channels
0:00:00.376853000  1507 0xab413260 DEBUG         imxuniaudiodec uniaudio_decoder.c:656:gst_imx_audio_uniaudio_dec_fill_channel_positions:<imxaudiouniaudiodec0> channel positions are in valid order, no need to reorder channels
0:00:00.377197333  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:492:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> feeding 426 bytes to the decoder
0:00:00.377556667  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:503:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> decode_frame:  return 0x0  offset 426  out_size 4096
0:00:00.380412667  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa7e76000 phys: 0x39b00000 cpu: 0xe9b00000
0:00:00.380487000  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa04a48 at phys addr 0x39b00000 with 1612801 bytes
0:00:00.380532333  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.387196000  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa7cec000 phys: 0x39d00000 cpu: 0xe9d00000
0:00:00.387272000  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa049a8 at phys addr 0x39d00000 with 1612801 bytes
0:00:00.387316667  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.399804667  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa7b62000 phys: 0x39f00000 cpu: 0xe9f00000
0:00:00.399878333  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa04958 at phys addr 0x39f00000 with 1612801 bytes
0:00:00.399924000  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.406092000  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa79d8000 phys: 0x3a100000 cpu: 0xea100000
0:00:00.406166667  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa04868 at phys addr 0x3a100000 with 1612801 bytes
0:00:00.406213667  1507 0xab412f80 DEBUG    imxphysmemallocator phys_mem_allocator.c:117:gst_imx_phys_mem_allocator_alloc_internal:<imxvpudecallocator0> alloc_internal called: maxsize: 1612801, align: 0, offset: 0, size: 1612801
0:00:00.412735667  1507 0xab412f80 DEBUG     imxvpudecallocator allocator.c:84:gst_imx_vpu_dec_alloc_phys_mem:<imxvpudecallocator0> addresses: virt: 0xa784e000 phys: 0x3a300000 cpu: 0xea300000
0:00:00.412810667  1507 0xab412f80 INFO     imxphysmemallocator phys_mem_allocator.c:152:gst_imx_phys_mem_allocator_alloc:<imxvpudecallocator0> allocated memory block 0xaaa048b8 at phys addr 0x3a300000 with 1612801 bytes
0:00:00.413073000  1507 0xab412f80 DEBUG              imxvpudec decoder.c:1331:gst_imx_vpu_dec_handle_frame:<imxvpudec0> nothing to output (ret code: 0x201)
0:00:00.419212333  1507 0xab412f80 LOG                imxvpudec decoder.c:925:gst_imx_vpu_dec_handle_frame:<imxvpudec0> VPU_DecDecodeBuf returns: 809
0:00:00.419253667  1507 0xab412f80 LOG                imxvpudec decoder.c:1076:gst_imx_vpu_dec_handle_frame:<imxvpudec0> one frame got consumed: cur_frame: 0xab407b48  framebuffer: 0xaaa100a0  system frame number: 0  stuff length: 31  frame length: 999
0:00:00.419310000  1507 0xab412f80 LOG       imxvpuframebuffers framebuffers.c:178:gst_imx_vpu_framebuffers_wait_until_frames_available:<imxvpuframebuffers0> flushing = 0  exit_loop = 0
0:00:00.419343667  1507 0xab412f80 LOG                imxvpudec decoder.c:1109:gst_imx_vpu_dec_handle_frame:<imxvpudec0> number of available buffers: 12 -> 12 -> 11
0:00:00.419376000  1507 0xab412f80 DEBUG              imxvpudec decoder.c:1331:gst_imx_vpu_dec_handle_frame:<imxvpudec0> nothing to output (ret code: 0x809)
0:00:00.425978333  1507 0xab412f80 LOG                imxvpudec decoder.c:925:gst_imx_vpu_dec_handle_frame:<imxvpudec0> VPU_DecDecodeBuf returns: 809
0:00:00.426019333  1507 0xab412f80 LOG                imxvpudec decoder.c:1076:gst_imx_vpu_dec_handle_frame:<imxvpudec0> one frame got consumed: cur_frame: 0xab407bf0  framebuffer: 0xaaa100f0  system frame number: 1  stuff length: 0  frame length: 11458
0:00:00.426061667  1507 0xab412f80 LOG       imxvpuframebuffers framebuffers.c:178:gst_imx_vpu_framebuffers_wait_until_frames_available:<imxvpuframebuffers0> flushing = 0  exit_loop = 0
0:00:00.426093000  1507 0xab412f80 LOG                imxvpudec decoder.c:1109:gst_imx_vpu_dec_handle_frame:<imxvpudec0> number of available buffers: 11 -> 11 -> 10
0:00:00.426124000  1507 0xab412f80 DEBUG              imxvpudec decoder.c:1331:gst_imx_vpu_dec_handle_frame:<imxvpudec0> nothing to output (ret code: 0x809)
0:00:00.432687333  1507 0xab412f80 LOG                imxvpudec decoder.c:925:gst_imx_vpu_dec_handle_frame:<imxvpudec0> VPU_DecDecodeBuf returns: 809
0:00:00.432729000  1507 0xab412f80 LOG                imxvpudec decoder.c:1076:gst_imx_vpu_dec_handle_frame:<imxvpudec0> one frame got consumed: cur_frame: 0xab407c98  framebuffer: 0xaaa10140  system frame number: 2  stuff length: 0  frame length: 14878
0:00:00.432771667  1507 0xab412f80 LOG       imxvpuframebuffers framebuffers.c:178:gst_imx_vpu_framebuffers_wait_until_frames_available:<imxvpuframebuffers0> flushing = 0  exit_loop = 0
0:00:00.432803000  1507 0xab412f80 LOG                imxvpudec decoder.c:1109:gst_imx_vpu_dec_handle_frame:<imxvpudec0> number of available buffers: 10 -> 10 -> 9
0:00:00.432834333  1507 0xab412f80 DEBUG              imxvpudec decoder.c:1331:gst_imx_vpu_dec_handle_frame:<imxvpudec0> nothing to output (ret code: 0x809)
0:00:00.440284000  1507 0xab412f80 LOG                imxvpudec decoder.c:925:gst_imx_vpu_dec_handle_frame:<imxvpudec0> VPU_DecDecodeBuf returns: 809
0:00:00.440329333  1507 0xab412f80 LOG                imxvpudec decoder.c:1076:gst_imx_vpu_dec_handle_frame:<imxvpudec0> one frame got consumed: cur_frame: 0xab407d40  framebuffer: 0xaaa10190  system frame number: 3  stuff length: 0  frame length: 1210
0:00:00.440370667  1507 0xab412f80 LOG       imxvpuframebuffers framebuffers.c:178:gst_imx_vpu_framebuffers_wait_until_frames_available:<imxvpuframebuffers0> flushing = 0  exit_loop = 0
0:00:00.440401667  1507 0xab412f80 LOG                imxvpudec decoder.c:1109:gst_imx_vpu_dec_handle_frame:<imxvpudec0> number of available buffers: 9 -> 9 -> 8
0:00:00.440434333  1507 0xab412f80 DEBUG              imxvpudec decoder.c:1331:gst_imx_vpu_dec_handle_frame:<imxvpudec0> nothing to output (ret code: 0x809)
0:00:00.447610333  1507 0xab412f80 LOG                imxvpudec decoder.c:925:gst_imx_vpu_dec_handle_frame:<imxvpudec0> VPU_DecDecodeBuf returns: 805
0:00:00.447649667  1507 0xab412f80 LOG                imxvpudec decoder.c:1076:gst_imx_vpu_dec_handle_frame:<imxvpudec0> one frame got consumed: cur_frame: 0xab407de8  framebuffer: 0xaaa101e0  system frame number: 4  stuff length: 0  frame length: 975
0:00:00.447691667  1507 0xab412f80 LOG       imxvpuframebuffers framebuffers.c:178:gst_imx_vpu_framebuffers_wait_until_frames_available:<imxvpuframebuffers0> flushing = 0  exit_loop = 0
0:00:00.447723000  1507 0xab412f80 LOG                imxvpudec decoder.c:1109:gst_imx_vpu_dec_handle_frame:<imxvpudec0> number of available buffers: 8 -> 8 -> 7
0:00:00.447769667  1507 0xab412f80 LOG                imxvpudec decoder.c:1195:gst_imx_vpu_dec_handle_frame:<imxvpudec0> system frame number valid and corresponding frame is still pending
0:00:00.474733333  1507 0xaaa02a90 LOG       imxeglplatform_x11 egl_platform_x11.c:460:gst_imx_egl_viv_sink_egl_platform_set_video_info: window not open - cannot set video info
0:00:00.474820667  1507 0xaaa02a90 LOG         imxgles2renderer gles2_renderer.c:1140:gst_imx_egl_viv_sink_gles2_renderer_set_force_aspect_ratio: setting force_aspect_ratio to 1
0:00:00.475737333  1507 0xab412f80 INFO               imxvpudec decoder.c:1467:gst_imx_vpu_dec_decide_allocation:<imxvpudec0> number of allocation pools in query: 1
0:00:00.475811333  1507 0xab412f80 INFO               imxvpudec decoder.c:1500:gst_imx_vpu_dec_decide_allocation:<imxvpudec0> no pool supports VPU buffers; creating new pool
0:00:00.475995333  1507 0xab412f80 INFO      imxvpufbbufferpool fb_buffer_pool.c:240:gst_imx_vpu_fb_buffer_pool_init:<GstImxVpuFbBufferPool@0xaaa081b8> initializing VPU buffer pool
0:00:00.476073000  1507 0xab412f80 INFO               imxvpudec decoder.c:1512:gst_imx_vpu_dec_decide_allocation:<imxvpufbbufferpool0> pool config:  outcaps: 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  size: 1612801  min buffers: 0  max buffers: 0
0:00:00.476816667  1507 0xab412f80 LOG       imxvpufbbufferpool fb_buffer_pool.c:319:gst_imx_vpu_set_buffer_contents: setting phys mem meta for buffer with pointer 0xaaa04000: phys addr 0x38d00000 x/y padding 0/0
0:00:00.476896667  1507 0xab412f80 LOG                imxvpudec decoder.c:1226:gst_imx_vpu_dec_handle_frame:<imxvpudec0> output frame:  codecframe: 0xab4079f8  framebuffer phys addr: 0x38d00000  system frame number: 0  gstbuffer addr: 0xaaa04000  field type: 0  pic type: 3  Y stride: 1280  CbCr stride: 640
0:00:00.479308333  1507 0xab412f80 INFO               imxvpudec decoder.c:1467:gst_imx_vpu_dec_decide_allocation:<imxvpudec0> number of allocation pools in query: 1
0:00:00.479461000  1507 0xab412f80 INFO               imxvpudec decoder.c:1500:gst_imx_vpu_dec_decide_allocation:<imxvpudec0> no pool supports VPU buffers; creating new pool
0:00:00.479664333  1507 0xab412f80 INFO      imxvpufbbufferpool fb_buffer_pool.c:240:gst_imx_vpu_fb_buffer_pool_init:<GstImxVpuFbBufferPool@0xaaa082e8> initializing VPU buffer pool
0:00:00.479685667  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:492:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> feeding 427 bytes to the decoder
0:00:00.479744000  1507 0xab412f80 INFO               imxvpudec decoder.c:1512:gst_imx_vpu_dec_decide_allocation:<imxvpufbbufferpool1> pool config:  outcaps: 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  size: 1612801  min buffers: 0  max buffers: 0
0:00:00.480036667  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:503:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> decode_frame:  return 0x0  offset 427  out_size 4096
0:00:00.480769667  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:492:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> feeding 427 bytes to the decoder
0:00:00.481164667  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:503:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> decode_frame:  return 0x0  offset 427  out_size 4096
0:00:00.481799333  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:492:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> feeding 426 bytes to the decoder
0:00:00.482132333  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:503:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> decode_frame:  return 0x0  offset 426  out_size 4096
0:00:00.482596667  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:492:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> feeding 427 bytes to the decoder
0:00:00.482961333  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:503:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> decode_frame:  return 0x0  offset 427  out_size 4096
0:00:00.483379000  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:492:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> feeding 427 bytes to the decoder
0:00:00.483626667  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:503:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> decode_frame:  return 0x0  offset 427  out_size 4096
0:00:00.484281667  1507 0xaaa02a90 LOG       imxeglplatform_x11 egl_platform_x11.c:428:gst_imx_egl_viv_sink_egl_platform_send_cmd: window not open - cannot send cmd
Attempt to unlock mutex that was not locked
0:00:00.484483333  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:492:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> feeding 426 bytes to the decoder
0:00:00.486027333  1507 0xab413260 TRACE         imxuniaudiodec uniaudio_decoder.c:503:gst_imx_audio_uniaudio_dec_handle_frame:<imxaudiouniaudiodec0> decode_frame:  return 0x0  offset 426  out_size 4096
Aborted

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

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

Interesting. This seems familiar, although I thought it is fixed. I will 
do a test run here to see if I can reproduce it.
This happens with gtk-play, right? Please double check if this also 
happens with gst-play on your end. It would be somewhat easier for me if 
it is also reproducible with that.

Am 2015-05-27 um 14:05 schrieb Gary Thomas:
> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>> Try to re-run the playbin pipeline with the GST_DEBUG environment 
>> variable set to: "2,*imx*:9", and post the log please.
>
> Here it is.
>
>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>
>>>>> Any ideas on how to get this to work (i.e. fix the broken locking)?
>>>>
>>>> Try if building the current master (not 0.10.1) fixes it.
>>>
>>> That's what I'm running:
>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>
>>
>
>
>


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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-28 00:33, Carlos Rafael Giani wrote:
> Interesting. This seems familiar, although I thought it is fixed. I will do a test run here to see if I can reproduce it.
> This happens with gtk-play, right? Please double check if this also happens with gst-play on your end. It would be somewhat easier for me if it is also reproducible with that.

I'm only using gst-play at the moment (gtk-play doesn't have a way
to force the appropriate videosink yet).  Here's the command I used:
   # GST_DEBUG_NO_COLOR=1 GST_DEBUG='2,*imx*:9' gst-play-1.0 --videosink=imxeglvivsink Vlad\+Louise.mp4 2>/tmp/gst-play.log

>
> Am 2015-05-27 um 14:05 schrieb Gary Thomas:
>> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>>> Try to re-run the playbin pipeline with the GST_DEBUG environment variable set to: "2,*imx*:9", and post the log please.
>>
>> Here it is.
>>
>>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>>
>>>>>> Any ideas on how to get this to work (i.e. fix the broken locking)?
>>>>>
>>>>> Try if building the current master (not 0.10.1) fixes it.
>>>>
>>>> That's what I'm running:
>>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>>
>>>
>>
>>
>>
>
>
>

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

OK, I was able to reproduce this, thanks. Working on it now.

Am 2015-05-28 um 14:11 schrieb Gary Thomas:
> On 2015-05-28 00:33, Carlos Rafael Giani wrote:
>> Interesting. This seems familiar, although I thought it is fixed. I 
>> will do a test run here to see if I can reproduce it.
>> This happens with gtk-play, right? Please double check if this also 
>> happens with gst-play on your end. It would be somewhat easier for me 
>> if it is also reproducible with that.
>
> I'm only using gst-play at the moment (gtk-play doesn't have a way
> to force the appropriate videosink yet).  Here's the command I used:
>   # GST_DEBUG_NO_COLOR=1 GST_DEBUG='2,*imx*:9' gst-play-1.0 
> --videosink=imxeglvivsink Vlad\+Louise.mp4 2>/tmp/gst-play.log
>
>>
>> Am 2015-05-27 um 14:05 schrieb Gary Thomas:
>>> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>>>> Try to re-run the playbin pipeline with the GST_DEBUG environment 
>>>> variable set to: "2,*imx*:9", and post the log please.
>>>
>>> Here it is.
>>>
>>>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>>>
>>>>>>> Any ideas on how to get this to work (i.e. fix the broken locking)?
>>>>>>
>>>>>> Try if building the current master (not 0.10.1) fixes it.
>>>>>
>>>>> That's what I'm running:
>>>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

Ah, it is as I suspected. There is a fix for that in gstreamer-imx 
master (not meta-fsl-arm master).

In the meta-fsl-arm directory, open 
recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb , and 
replace the line:

SRCREV = "898e51dbdb01926d6423d0d31a9530ec6deb5192"

with:

SRCREV = "50bd7add0b684e966b8a7bdaad47a7e706fc00cc"

then rebuild and reinstall gstreamer-imx, and check if this fixes it.


Am 2015-05-29 um 09:06 schrieb Carlos Rafael Giani:
> OK, I was able to reproduce this, thanks. Working on it now.
>
> Am 2015-05-28 um 14:11 schrieb Gary Thomas:
>> On 2015-05-28 00:33, Carlos Rafael Giani wrote:
>>> Interesting. This seems familiar, although I thought it is fixed. I 
>>> will do a test run here to see if I can reproduce it.
>>> This happens with gtk-play, right? Please double check if this also 
>>> happens with gst-play on your end. It would be somewhat easier for 
>>> me if it is also reproducible with that.
>>
>> I'm only using gst-play at the moment (gtk-play doesn't have a way
>> to force the appropriate videosink yet).  Here's the command I used:
>>   # GST_DEBUG_NO_COLOR=1 GST_DEBUG='2,*imx*:9' gst-play-1.0 
>> --videosink=imxeglvivsink Vlad\+Louise.mp4 2>/tmp/gst-play.log
>>
>>>
>>> Am 2015-05-27 um 14:05 schrieb Gary Thomas:
>>>> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>>>>> Try to re-run the playbin pipeline with the GST_DEBUG environment 
>>>>> variable set to: "2,*imx*:9", and post the log please.
>>>>
>>>> Here it is.
>>>>
>>>>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>>>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>>>>
>>>>>>>> Any ideas on how to get this to work (i.e. fix the broken 
>>>>>>>> locking)?
>>>>>>>
>>>>>>> Try if building the current master (not 0.10.1) fixes it.
>>>>>>
>>>>>> That's what I'm running:
>>>>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

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

On 2015-05-29 01:25, Carlos Rafael Giani wrote:
> Ah, it is as I suspected. There is a fix for that in gstreamer-imx master (not meta-fsl-arm master).
>
> In the meta-fsl-arm directory, open recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb , and replace the line:
>
> SRCREV = "898e51dbdb01926d6423d0d31a9530ec6deb5192"
>
> with:
>
> SRCREV = "50bd7add0b684e966b8a7bdaad47a7e706fc00cc"
>
> then rebuild and reinstall gstreamer-imx, and check if this fixes it.

This does fix the problem when I run gst-play manually (from the command line), thanks.

However, I still have no video when gst-play is started from gtk-play
(because playbin is choosing the wrong plugin).  Any ideas about that?

Finally, there is another problem I've already reported - if you run
gst-play without any specific plugin from the command line, it will
default to a full screen video overlay.  Sadly this fails with the same
error:
   Attempt to unlock mutex that was not locked
This can be fixed using the attached patch (but I'm not sure it's 100% correct)

The gst1.0-fsl-plugin does not list a maintainer - perhaps it's you (Carlos)?

>
>
> Am 2015-05-29 um 09:06 schrieb Carlos Rafael Giani:
>> OK, I was able to reproduce this, thanks. Working on it now.
>>
>> Am 2015-05-28 um 14:11 schrieb Gary Thomas:
>>> On 2015-05-28 00:33, Carlos Rafael Giani wrote:
>>>> Interesting. This seems familiar, although I thought it is fixed. I will do a test run here to see if I can reproduce it.
>>>> This happens with gtk-play, right? Please double check if this also happens with gst-play on your end. It would be somewhat easier for me if it is also reproducible with that.
>>>
>>> I'm only using gst-play at the moment (gtk-play doesn't have a way
>>> to force the appropriate videosink yet).  Here's the command I used:
>>>   # GST_DEBUG_NO_COLOR=1 GST_DEBUG='2,*imx*:9' gst-play-1.0 --videosink=imxeglvivsink Vlad\+Louise.mp4 2>/tmp/gst-play.log
>>>
>>>>
>>>> Am 2015-05-27 um 14:05 schrieb Gary Thomas:
>>>>> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>>>>>> Try to re-run the playbin pipeline with the GST_DEBUG environment variable set to: "2,*imx*:9", and post the log please.
>>>>>
>>>>> Here it is.
>>>>>
>>>>>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>>>>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>>>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>>>>>
>>>>>>>>> Any ideas on how to get this to work (i.e. fix the broken locking)?
>>>>>>>>
>>>>>>>> Try if building the current master (not 0.10.1) fixes it.
>>>>>>>
>>>>>>> That's what I'm running:
>>>>>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>

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

[-- Attachment #2: fix-mutex.patch --]
[-- Type: text/x-patch, Size: 583 bytes --]

Index: gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
===================================================================
--- gst1.0-fsl-plugins-4.0.3.orig/plugins/overlay_sink/compositor.c
+++ gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
@@ -278,6 +278,7 @@ static gpointer compositor_compositing_t
 {
   CompositorHandle *hcompositor = (CompositorHandle*) compositor;

+  g_mutex_lock(&hcompositor->lock);
   while (hcompositor->running) {
     COMPOSITOR_WAIT_SURFACE (hcompositor);
     compositor_do_compositing_surface_list (hcompositor);

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

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

Note that the gst1.0-fsl-plugin are not by me. I wrote gstreamer-imx. 
gst1.0-fsl-plugin was written by Freescale.
I never tried a combination of both. It is possible that this is what is 
causing your problems. I'll try to replicate that.

Am 2015-05-29 um 15:00 schrieb Gary Thomas:
> On 2015-05-29 01:25, Carlos Rafael Giani wrote:
>> Ah, it is as I suspected. There is a fix for that in gstreamer-imx 
>> master (not meta-fsl-arm master).
>>
>> In the meta-fsl-arm directory, open 
>> recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb , and 
>> replace the line:
>>
>> SRCREV = "898e51dbdb01926d6423d0d31a9530ec6deb5192"
>>
>> with:
>>
>> SRCREV = "50bd7add0b684e966b8a7bdaad47a7e706fc00cc"
>>
>> then rebuild and reinstall gstreamer-imx, and check if this fixes it.
>
> This does fix the problem when I run gst-play manually (from the 
> command line), thanks.
>
> However, I still have no video when gst-play is started from gtk-play
> (because playbin is choosing the wrong plugin).  Any ideas about that?
>
> Finally, there is another problem I've already reported - if you run
> gst-play without any specific plugin from the command line, it will
> default to a full screen video overlay.  Sadly this fails with the same
> error:
>   Attempt to unlock mutex that was not locked
> This can be fixed using the attached patch (but I'm not sure it's 100% 
> correct)
>
> The gst1.0-fsl-plugin does not list a maintainer - perhaps it's you 
> (Carlos)?
>
>>
>>
>> Am 2015-05-29 um 09:06 schrieb Carlos Rafael Giani:
>>> OK, I was able to reproduce this, thanks. Working on it now.
>>>
>>> Am 2015-05-28 um 14:11 schrieb Gary Thomas:
>>>> On 2015-05-28 00:33, Carlos Rafael Giani wrote:
>>>>> Interesting. This seems familiar, although I thought it is fixed. 
>>>>> I will do a test run here to see if I can reproduce it.
>>>>> This happens with gtk-play, right? Please double check if this 
>>>>> also happens with gst-play on your end. It would be somewhat 
>>>>> easier for me if it is also reproducible with that.
>>>>
>>>> I'm only using gst-play at the moment (gtk-play doesn't have a way
>>>> to force the appropriate videosink yet).  Here's the command I used:
>>>>   # GST_DEBUG_NO_COLOR=1 GST_DEBUG='2,*imx*:9' gst-play-1.0 
>>>> --videosink=imxeglvivsink Vlad\+Louise.mp4 2>/tmp/gst-play.log
>>>>
>>>>>
>>>>> Am 2015-05-27 um 14:05 schrieb Gary Thomas:
>>>>>> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>>>>>>> Try to re-run the playbin pipeline with the GST_DEBUG 
>>>>>>> environment variable set to: "2,*imx*:9", and post the log please.
>>>>>>
>>>>>> Here it is.
>>>>>>
>>>>>>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>>>>>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>>>>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>>>>>>
>>>>>>>>>> Any ideas on how to get this to work (i.e. fix the broken 
>>>>>>>>>> locking)?
>>>>>>>>>
>>>>>>>>> Try if building the current master (not 0.10.1) fixes it.
>>>>>>>>
>>>>>>>> That's what I'm running:
>>>>>>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>


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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

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

Also, when you refer to gtk-play, do you mean libcanberra's gtk play?

Am 2015-06-02 um 17:34 schrieb Carlos Rafael Giani:
> Note that the gst1.0-fsl-plugin are not by me. I wrote gstreamer-imx. 
> gst1.0-fsl-plugin was written by Freescale.
> I never tried a combination of both. It is possible that this is what 
> is causing your problems. I'll try to replicate that.
>
> Am 2015-05-29 um 15:00 schrieb Gary Thomas:
>> On 2015-05-29 01:25, Carlos Rafael Giani wrote:
>>> Ah, it is as I suspected. There is a fix for that in gstreamer-imx 
>>> master (not meta-fsl-arm master).
>>>
>>> In the meta-fsl-arm directory, open 
>>> recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb , 
>>> and replace the line:
>>>
>>> SRCREV = "898e51dbdb01926d6423d0d31a9530ec6deb5192"
>>>
>>> with:
>>>
>>> SRCREV = "50bd7add0b684e966b8a7bdaad47a7e706fc00cc"
>>>
>>> then rebuild and reinstall gstreamer-imx, and check if this fixes it.
>>
>> This does fix the problem when I run gst-play manually (from the 
>> command line), thanks.
>>
>> However, I still have no video when gst-play is started from gtk-play
>> (because playbin is choosing the wrong plugin).  Any ideas about that?
>>
>> Finally, there is another problem I've already reported - if you run
>> gst-play without any specific plugin from the command line, it will
>> default to a full screen video overlay.  Sadly this fails with the same
>> error:
>>   Attempt to unlock mutex that was not locked
>> This can be fixed using the attached patch (but I'm not sure it's 
>> 100% correct)
>>
>> The gst1.0-fsl-plugin does not list a maintainer - perhaps it's you 
>> (Carlos)?
>>
>>>
>>>
>>> Am 2015-05-29 um 09:06 schrieb Carlos Rafael Giani:
>>>> OK, I was able to reproduce this, thanks. Working on it now.
>>>>
>>>> Am 2015-05-28 um 14:11 schrieb Gary Thomas:
>>>>> On 2015-05-28 00:33, Carlos Rafael Giani wrote:
>>>>>> Interesting. This seems familiar, although I thought it is fixed. 
>>>>>> I will do a test run here to see if I can reproduce it.
>>>>>> This happens with gtk-play, right? Please double check if this 
>>>>>> also happens with gst-play on your end. It would be somewhat 
>>>>>> easier for me if it is also reproducible with that.
>>>>>
>>>>> I'm only using gst-play at the moment (gtk-play doesn't have a way
>>>>> to force the appropriate videosink yet).  Here's the command I used:
>>>>>   # GST_DEBUG_NO_COLOR=1 GST_DEBUG='2,*imx*:9' gst-play-1.0 
>>>>> --videosink=imxeglvivsink Vlad\+Louise.mp4 2>/tmp/gst-play.log
>>>>>
>>>>>>
>>>>>> Am 2015-05-27 um 14:05 schrieb Gary Thomas:
>>>>>>> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>>>>>>>> Try to re-run the playbin pipeline with the GST_DEBUG 
>>>>>>>> environment variable set to: "2,*imx*:9", and post the log please.
>>>>>>>
>>>>>>> Here it is.
>>>>>>>
>>>>>>>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>>>>>>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>>>>>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>>>>>>>
>>>>>>>>>>> Any ideas on how to get this to work (i.e. fix the broken 
>>>>>>>>>>> locking)?
>>>>>>>>>>
>>>>>>>>>> Try if building the current master (not 0.10.1) fixes it.
>>>>>>>>>
>>>>>>>>> That's what I'm running:
>>>>>>>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>
>
>


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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-06-02 11:11, Carlos Rafael Giani wrote:
> Also, when you refer to gtk-play, do you mean libcanberra's gtk play?

No, it's a gstreamer-1.0 product.  You get it when you build Yocto (core-image-sato)
from the gst-player recipe.

>
> Am 2015-06-02 um 17:34 schrieb Carlos Rafael Giani:
>> Note that the gst1.0-fsl-plugin are not by me. I wrote gstreamer-imx. gst1.0-fsl-plugin was written by Freescale.
>> I never tried a combination of both. It is possible that this is what is causing your problems. I'll try to replicate that.
>>
>> Am 2015-05-29 um 15:00 schrieb Gary Thomas:
>>> On 2015-05-29 01:25, Carlos Rafael Giani wrote:
>>>> Ah, it is as I suspected. There is a fix for that in gstreamer-imx master (not meta-fsl-arm master).
>>>>
>>>> In the meta-fsl-arm directory, open recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb , and replace the line:
>>>>
>>>> SRCREV = "898e51dbdb01926d6423d0d31a9530ec6deb5192"
>>>>
>>>> with:
>>>>
>>>> SRCREV = "50bd7add0b684e966b8a7bdaad47a7e706fc00cc"
>>>>
>>>> then rebuild and reinstall gstreamer-imx, and check if this fixes it.
>>>
>>> This does fix the problem when I run gst-play manually (from the command line), thanks.
>>>
>>> However, I still have no video when gst-play is started from gtk-play
>>> (because playbin is choosing the wrong plugin).  Any ideas about that?
>>>
>>> Finally, there is another problem I've already reported - if you run
>>> gst-play without any specific plugin from the command line, it will
>>> default to a full screen video overlay.  Sadly this fails with the same
>>> error:
>>>   Attempt to unlock mutex that was not locked
>>> This can be fixed using the attached patch (but I'm not sure it's 100% correct)
>>>
>>> The gst1.0-fsl-plugin does not list a maintainer - perhaps it's you (Carlos)?
>>>
>>>>
>>>>
>>>> Am 2015-05-29 um 09:06 schrieb Carlos Rafael Giani:
>>>>> OK, I was able to reproduce this, thanks. Working on it now.
>>>>>
>>>>> Am 2015-05-28 um 14:11 schrieb Gary Thomas:
>>>>>> On 2015-05-28 00:33, Carlos Rafael Giani wrote:
>>>>>>> Interesting. This seems familiar, although I thought it is fixed. I will do a test run here to see if I can reproduce it.
>>>>>>> This happens with gtk-play, right? Please double check if this also happens with gst-play on your end. It would be somewhat easier for me if it is also reproducible with that.
>>>>>>
>>>>>> I'm only using gst-play at the moment (gtk-play doesn't have a way
>>>>>> to force the appropriate videosink yet).  Here's the command I used:
>>>>>>   # GST_DEBUG_NO_COLOR=1 GST_DEBUG='2,*imx*:9' gst-play-1.0 --videosink=imxeglvivsink Vlad\+Louise.mp4 2>/tmp/gst-play.log
>>>>>>
>>>>>>>
>>>>>>> Am 2015-05-27 um 14:05 schrieb Gary Thomas:
>>>>>>>> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>>>>>>>>> Try to re-run the playbin pipeline with the GST_DEBUG environment variable set to: "2,*imx*:9", and post the log please.
>>>>>>>>
>>>>>>>> Here it is.
>>>>>>>>
>>>>>>>>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>>>>>>>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>>>>>>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Any ideas on how to get this to work (i.e. fix the broken locking)?
>>>>>>>>>>>
>>>>>>>>>>> Try if building the current master (not 0.10.1) fixes it.
>>>>>>>>>>
>>>>>>>>>> That's what I'm running:
>>>>>>>>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani]

Alright, two things:

1) I just made a 0.10.2 release. I'll soon push an update for the 
meta-fsl recipe. This release includes the eglvivsink mutex fix.

2) I replicated your problem. If both gstreamer-imx and 
gst1.0-fsl-plugin are installed, this error occurs. If only 
gstreamer-imx is installed, playback works just fine - eglvivsink is 
used automatically as the video sink. I'll investigate what 
gst1.0-fsl-plugin is doing to override eglvivsink.


Am 2015-06-02 um 19:16 schrieb Gary Thomas:
> On 2015-06-02 11:11, Carlos Rafael Giani wrote:
>> Also, when you refer to gtk-play, do you mean libcanberra's gtk play?
>
> No, it's a gstreamer-1.0 product.  You get it when you build Yocto 
> (core-image-sato)
> from the gst-player recipe.
>
>>
>> Am 2015-06-02 um 17:34 schrieb Carlos Rafael Giani:
>>> Note that the gst1.0-fsl-plugin are not by me. I wrote 
>>> gstreamer-imx. gst1.0-fsl-plugin was written by Freescale.
>>> I never tried a combination of both. It is possible that this is 
>>> what is causing your problems. I'll try to replicate that.
>>>
>>> Am 2015-05-29 um 15:00 schrieb Gary Thomas:
>>>> On 2015-05-29 01:25, Carlos Rafael Giani wrote:
>>>>> Ah, it is as I suspected. There is a fix for that in gstreamer-imx 
>>>>> master (not meta-fsl-arm master).
>>>>>
>>>>> In the meta-fsl-arm directory, open 
>>>>> recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb , 
>>>>> and replace the line:
>>>>>
>>>>> SRCREV = "898e51dbdb01926d6423d0d31a9530ec6deb5192"
>>>>>
>>>>> with:
>>>>>
>>>>> SRCREV = "50bd7add0b684e966b8a7bdaad47a7e706fc00cc"
>>>>>
>>>>> then rebuild and reinstall gstreamer-imx, and check if this fixes it.
>>>>
>>>> This does fix the problem when I run gst-play manually (from the 
>>>> command line), thanks.
>>>>
>>>> However, I still have no video when gst-play is started from gtk-play
>>>> (because playbin is choosing the wrong plugin).  Any ideas about that?
>>>>
>>>> Finally, there is another problem I've already reported - if you run
>>>> gst-play without any specific plugin from the command line, it will
>>>> default to a full screen video overlay.  Sadly this fails with the 
>>>> same
>>>> error:
>>>>   Attempt to unlock mutex that was not locked
>>>> This can be fixed using the attached patch (but I'm not sure it's 
>>>> 100% correct)
>>>>
>>>> The gst1.0-fsl-plugin does not list a maintainer - perhaps it's you 
>>>> (Carlos)?
>>>>
>>>>>
>>>>>
>>>>> Am 2015-05-29 um 09:06 schrieb Carlos Rafael Giani:
>>>>>> OK, I was able to reproduce this, thanks. Working on it now.
>>>>>>
>>>>>> Am 2015-05-28 um 14:11 schrieb Gary Thomas:
>>>>>>> On 2015-05-28 00:33, Carlos Rafael Giani wrote:
>>>>>>>> Interesting. This seems familiar, although I thought it is 
>>>>>>>> fixed. I will do a test run here to see if I can reproduce it.
>>>>>>>> This happens with gtk-play, right? Please double check if this 
>>>>>>>> also happens with gst-play on your end. It would be somewhat 
>>>>>>>> easier for me if it is also reproducible with that.
>>>>>>>
>>>>>>> I'm only using gst-play at the moment (gtk-play doesn't have a way
>>>>>>> to force the appropriate videosink yet).  Here's the command I 
>>>>>>> used:
>>>>>>>   # GST_DEBUG_NO_COLOR=1 GST_DEBUG='2,*imx*:9' gst-play-1.0 
>>>>>>> --videosink=imxeglvivsink Vlad\+Louise.mp4 2>/tmp/gst-play.log
>>>>>>>
>>>>>>>>
>>>>>>>> Am 2015-05-27 um 14:05 schrieb Gary Thomas:
>>>>>>>>> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>>>>>>>>>> Try to re-run the playbin pipeline with the GST_DEBUG 
>>>>>>>>>> environment variable set to: "2,*imx*:9", and post the log 
>>>>>>>>>> please.
>>>>>>>>>
>>>>>>>>> Here it is.
>>>>>>>>>
>>>>>>>>>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>>>>>>>>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>>>>>>>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any ideas on how to get this to work (i.e. fix the broken 
>>>>>>>>>>>>> locking)?
>>>>>>>>>>>>
>>>>>>>>>>>> Try if building the current master (not 0.10.1) fixes it.
>>>>>>>>>>>
>>>>>>>>>>> That's what I'm running:
>>>>>>>>>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Nikolay Dimitrov]

Hi Carlos,

On 06/03/2015 12:05 AM, Carlos Rafael Giani wrote:
> Alright, two things:
>
> 1) I just made a 0.10.2 release. I'll soon push an update for the
> meta-fsl recipe. This release includes the eglvivsink mutex fix.
>
> 2) I replicated your problem. If both gstreamer-imx and
> gst1.0-fsl-plugin are installed, this error occurs. If only
> gstreamer-imx is installed, playback works just fine - eglvivsink is
> used automatically as the video sink. I'll investigate what
> gst1.0-fsl-plugin is doing to override eglvivsink.

Hmm, higher plugin rank?

[snip]

Regards,
Nikolay

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-06-02 15:05, Carlos Rafael Giani wrote:
> Alright, two things:
>
> 1) I just made a 0.10.2 release. I'll soon push an update for the meta-fsl recipe. This release includes the eglvivsink mutex fix.
>
> 2) I replicated your problem. If both gstreamer-imx and gst1.0-fsl-plugin are installed, this error occurs. If only gstreamer-imx is installed, playback works just fine -
> eglvivsink is used automatically as the video sink. I'll investigate what gst1.0-fsl-plugin is doing to override eglvivsink.
>

Verified - if I remove gst1.0-fsl-plugin then gtk-play works.

Sadly, I need the plugins for V4L2 camera support, so I'm quite interested
in a solution that keeps both packages installed.

Thanks for continuing to look into this.

> Am 2015-06-02 um 19:16 schrieb Gary Thomas:
>> On 2015-06-02 11:11, Carlos Rafael Giani wrote:
>>> Also, when you refer to gtk-play, do you mean libcanberra's gtk play?
>>
>> No, it's a gstreamer-1.0 product.  You get it when you build Yocto (core-image-sato)
>> from the gst-player recipe.
>>
>>>
>>> Am 2015-06-02 um 17:34 schrieb Carlos Rafael Giani:
>>>> Note that the gst1.0-fsl-plugin are not by me. I wrote gstreamer-imx. gst1.0-fsl-plugin was written by Freescale.
>>>> I never tried a combination of both. It is possible that this is what is causing your problems. I'll try to replicate that.
>>>>
>>>> Am 2015-05-29 um 15:00 schrieb Gary Thomas:
>>>>> On 2015-05-29 01:25, Carlos Rafael Giani wrote:
>>>>>> Ah, it is as I suspected. There is a fix for that in gstreamer-imx master (not meta-fsl-arm master).
>>>>>>
>>>>>> In the meta-fsl-arm directory, open recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb , and replace the line:
>>>>>>
>>>>>> SRCREV = "898e51dbdb01926d6423d0d31a9530ec6deb5192"
>>>>>>
>>>>>> with:
>>>>>>
>>>>>> SRCREV = "50bd7add0b684e966b8a7bdaad47a7e706fc00cc"
>>>>>>
>>>>>> then rebuild and reinstall gstreamer-imx, and check if this fixes it.
>>>>>
>>>>> This does fix the problem when I run gst-play manually (from the command line), thanks.
>>>>>
>>>>> However, I still have no video when gst-play is started from gtk-play
>>>>> (because playbin is choosing the wrong plugin).  Any ideas about that?
>>>>>
>>>>> Finally, there is another problem I've already reported - if you run
>>>>> gst-play without any specific plugin from the command line, it will
>>>>> default to a full screen video overlay.  Sadly this fails with the same
>>>>> error:
>>>>>   Attempt to unlock mutex that was not locked
>>>>> This can be fixed using the attached patch (but I'm not sure it's 100% correct)
>>>>>
>>>>> The gst1.0-fsl-plugin does not list a maintainer - perhaps it's you (Carlos)?
>>>>>
>>>>>>
>>>>>>
>>>>>> Am 2015-05-29 um 09:06 schrieb Carlos Rafael Giani:
>>>>>>> OK, I was able to reproduce this, thanks. Working on it now.
>>>>>>>
>>>>>>> Am 2015-05-28 um 14:11 schrieb Gary Thomas:
>>>>>>>> On 2015-05-28 00:33, Carlos Rafael Giani wrote:
>>>>>>>>> Interesting. This seems familiar, although I thought it is fixed. I will do a test run here to see if I can reproduce it.
>>>>>>>>> This happens with gtk-play, right? Please double check if this also happens with gst-play on your end. It would be somewhat easier for me if it is also reproducible with
>>>>>>>>> that.
>>>>>>>>
>>>>>>>> I'm only using gst-play at the moment (gtk-play doesn't have a way
>>>>>>>> to force the appropriate videosink yet).  Here's the command I used:
>>>>>>>>   # GST_DEBUG_NO_COLOR=1 GST_DEBUG='2,*imx*:9' gst-play-1.0 --videosink=imxeglvivsink Vlad\+Louise.mp4 2>/tmp/gst-play.log
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 2015-05-27 um 14:05 schrieb Gary Thomas:
>>>>>>>>>> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>>>>>>>>>>> Try to re-run the playbin pipeline with the GST_DEBUG environment variable set to: "2,*imx*:9", and post the log please.
>>>>>>>>>>
>>>>>>>>>> Here it is.
>>>>>>>>>>
>>>>>>>>>>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>>>>>>>>>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>>>>>>>>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any ideas on how to get this to work (i.e. fix the broken locking)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Try if building the current master (not 0.10.1) fixes it.
>>>>>>>>>>>>
>>>>>>>>>>>> That's what I'm running:
>>>>>>>>>>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Pushpal Sidhu]

Hello,

On Tue, Jun 2, 2015 at 3:10 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> Verified - if I remove gst1.0-fsl-plugin then gtk-play works.
>
> Sadly, I need the plugins for V4L2 camera support, so I'm quite interested
> in a solution that keeps both packages installed.
>
> Thanks for continuing to look into this.
<SNIP>

Why don't you use imxv4l2src (from gstreamer-imx, not gst1.0-fsl-plugins)?

- Pushpal

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-06-02 16:17, Pushpal Sidhu wrote:
> Hello,
>
> On Tue, Jun 2, 2015 at 3:10 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> Verified - if I remove gst1.0-fsl-plugin then gtk-play works.
>>
>> Sadly, I need the plugins for V4L2 camera support, so I'm quite interested
>> in a solution that keeps both packages installed.
>>
>> Thanks for continuing to look into this.
> <SNIP>
>
> Why don't you use imxv4l2src (from gstreamer-imx, not gst1.0-fsl-plugins)?

Because it's not there?  After I remove gst1.0-fsl-plugin, here's what I see:

# gst-inspect-1.0 | grep imx
imxg2d:  imxg2dvideosink: Freescale G2D video sink
imxg2d:  imxg2dvideotransform: Freescale G2D video transform
imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
imxaudio:  imxmp3audioenc: Freescale i.MX MP3 encoder
imxvpu:  imxvpudec: Freescale VPU video decoder
imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
imxpxp:  imxpxpvideosink: Freescale PxP video sink
imxpxp:  imxpxpvideotransform: Freescale PxP video transform
imxipu:  imxipuvideotransform: Freescale IPU video transform
imxipu:  imxipuvideosink: Freescale IPU video sink

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

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Pushpal Sidhu]

On Tue, Jun 2, 2015 at 3:33 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2015-06-02 16:17, Pushpal Sidhu wrote:
>>
>> Hello,
>>
>> On Tue, Jun 2, 2015 at 3:10 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>
>>> Verified - if I remove gst1.0-fsl-plugin then gtk-play works.
>>>
>>> Sadly, I need the plugins for V4L2 camera support, so I'm quite
>>> interested
>>> in a solution that keeps both packages installed.
>>>
>>> Thanks for continuing to look into this.
>>
>> <SNIP>
>>
>> Why don't you use imxv4l2src (from gstreamer-imx, not gst1.0-fsl-plugins)?
>
>
> Because it's not there?  After I remove gst1.0-fsl-plugin, here's what I
> see:
>
> # gst-inspect-1.0 | grep imx
> imxg2d:  imxg2dvideosink: Freescale G2D video sink
> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
> imxaudio:  imxmp3audioenc: Freescale i.MX MP3 encoder
> imxvpu:  imxvpudec: Freescale VPU video decoder
> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
> imxpxp:  imxpxpvideosink: Freescale PxP video sink
> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
> imxipu:  imxipuvideotransform: Freescale IPU video transform
> imxipu:  imxipuvideosink: Freescale IPU video sink

Did you use opkg/dpkg to remove gst1.0-fsl-plugins? Because
gst1.0-fsl-plugin takes over the GstImxV4l2Src object before
gstreamer-imx does, you have to rebuild your gstreamer cache.

rm -rf .cache/gstreamer-1.0/

Do your gst-inspect again and it should automagically be there.

- Pushpal

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Nikolay Dimitrov]

On 05/19/2015 02:04 PM, Nikolay Dimitrov wrote:
> Hi Gary,
>
> On 05/19/2015 01:53 PM, Gary Thomas wrote:
>> On 2015-05-18 17:52, Nikolay Dimitrov wrote:
>>> Ho Gary,
>>>
>>> On 05/18/2015 07:27 PM, Gary Thomas wrote:
>>>> On 2015-05-18 09:55, Nikolay Dimitrov wrote:
>>>>> Hi Gary,
>>>>>
>>>>> On 05/18/2015 03:04 PM, Gary Thomas wrote:
>>>>>> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>>>>>>> Hi Pawel,
>>>>>>>
>>>>>>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I'm having some problems running video playback on Nitrogen6x-Lite.
>>>>>>>> I'm
>>>>>>>> using fido with 3.10.53 kernel. Display is running properly as I
>>>>>>>> see a
>>>>>>>> console after start, but starting any simple video with
>>>>>>>> Gstreamer1.0 +
>>>>>>>> gstreamer-imx plugins does not give any video output, even though
>>>>>>>> the
>>>>>>>> decoding looks like it's working.
>>>>>>>>
>>>>>>>> Gstreamer log:
>>>>>>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>>>>>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>>>>>>> imxipuvideosink
>>>>>>>> [INFO]    Product Info: i.MX6Q/D/S
>>>>>>>> Pipeline is live and does not need PREROLL ...
>>>>>>>> Progress: (open) Opening Stream
>>>>>>>> Progress: (connect) Connecting to
>>>>>>>> rtsp://192.168.7.24:554/profile3/media.smp
>>>>>>>> Progress: (open) Retrieving server options
>>>>>>>> Progress: (open) Retrieving media info
>>>>>>>> Progress: (request) SETUP stream 0
>>>>>>>> Progress: (request) SETUP stream 1
>>>>>>>> Progress: (open) Opened Stream
>>>>>>>> Setting pipeline to PLAYING ...
>>>>>>>> New clock: GstSystemClock
>>>>>>>> Progress: (request) Sending PLAY request
>>>>>>>> Progress: (request) Sending PLAY request
>>>>>>>> Progress: (request) Sent PLAY request
>>>>>>>> ^Chandling interrupt.
>>>>>>>> Interrupt: Stopping pipeline ...
>>>>>>>> Execution ended after 0:00:15.125067669
>>>>>>>> Setting pipeline to PAUSED ...
>>>>>>>> Setting pipeline to READY ...
>>>>>>>> Setting pipeline to NULL ...
>>>>>>>> Freeing pipeline ...
>>>>>>>>
>>>>>>>> Plugins installed:
>>>>>>>>
>>>>>>>> gst-inspect-1.0 | grep imx
>>>>>>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>>>>>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>>>>>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>>>>>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>>>>>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>>>>>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>>>>>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>>>>>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>>>>>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>>>>>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>>>>>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>>>>>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>>>>>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>>>>>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>>>>>>
>>>>>>>> While using imxeglvivsink I'm seeing red flash for few milliseconds
>>>>>>>> over
>>>>>>>> the console and that's it.
>>>>>>>> Any advices will be helpful.
>>>>>>>
>>>>>>> Please download this file and try a local file playback, to
>>>>>>> eliminate
>>>>>>> possible networking issues:
>>>>>>>
>>>>>>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>>>>>>
>>>>>>> Also, please check whether an automatically constructed pipeline is
>>>>>>> able to play the file above:
>>>>>>>
>>>>>>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>>>>>>
>>>>>>> You can try same tests with Xorg running.
>>>>>>
>>>>>> What would that pipeline look like (to force the result into a window
>>>>>> on the screen)?  As is, this simple command takes over the entire
>>>>>> screen.
>>>>>
>>>>> The automatically generated pipeline depends entirely on the media
>>>>> itself and the set of plugins you have installed - playbin/decodebin
>>>>> and friends are looking at the stream properties and searching for the
>>>>> plugin with the highest rank which can be plugged there. The best
>>>>> place
>>>>> to look at is usually the media graphs (.dot files) after playbin was
>>>>> able to play something (I do this regularly, as my pipelines are
>>>>> usually worse than the ones created by playbin).
>>>>
>>>> I tried interpreting these files and since I don't do it all the time
>>>> (like you)it was hard for me to see the whole picture.  Is it possible
>>>> to look at such a graph and write something equivalent that could be
>>>> run via gst-launch?
>>>>
>>>> Here's my graph in case you can make any sense of it.
>>>
>>> Not sure that the following will help much, but at least I can share
>>> what I know, so we can be in the same boat...
>>>
>>> Please look at the demuxer (qtdemux0), notice that the lower 2 source
>>> pads are denoted with dashed lines, which means these pads are dynamic,
>>> e.g. doesn't exist all the time (there are more components with dynamic
>>> pads in this pipeline).
>>>
>>> What happens is that after playback start, the demuxer only consumes
>>> data for a while and doesn't have any output pads. When the demuxer
>>> understands what logical streams are carried over the transport, it
>>> dynamically creates a number of source pads, one for each supported
>>> content type (usually for video/audio/subs, but can be more).
>>>
>>> When the demuxer's dynamic pads are created, the pipeline emits events,
>>> and the parent element (decodebin0) catches these events, looks for
>>> appropriate decoding elements, and attaches them to the pipeline
>>> dynamically.
>>>
>>> The trouble with these dynamic pipelines is that you can't refer to the
>>> source/sink pads of the elements before the pipeline is created, which
>>> means you can't construct a working dynamic pipeline from the command
>>> line. I looked how to do this, but couldn't find a solution. If someone
>>> knows how to do this, would be great to share.
>>>
>>> So the only way I know to create fully custom dynamic pipelines (e.g.
>>> driven by the content) is via source code, otherwise we have to use
>>> automated bins like playbin/decodebin, and give them some parameters.
>>
>> Thanks for the explanation, perhaps it can help someone fix this.  My
>> guess is that the FSL plugin doesn't handle those dynamic elements and
>> thus is not equipped to set up the render in the appropriate window on
>> the screen.
>>
>>>
>>>>
>>>>>
>>>>> Also the full-screen behavior depends the videosink configuration, so
>>>>> hard to give universal answer, as none will fit all cases.
>
> I doubt that the issue is caused exactly by the GstImxVpuDec or
> GstOverlaySink, as by looking at your pipeline they seem to have static
> pads. So it's more of how the playbin/decodebin bins handle the pipeline
> creation process...


Sorry for this, icedove sent my mail by displaying a pop-up dialog
while I was pressing Enter for a new line...

Here's a small trick - you can hint playbin about what video sink
element you want to use, regardless of the element ranks and
capabilities:

gst-launch playbin uri=file:///test.mp4 video-sink="myvideosink 
option=value"

So you can enforce you video sink preferences even on automated
pipelines.

Regards,
Nikolay

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-19 05:10, Nikolay Dimitrov wrote:
>
> On 05/19/2015 02:04 PM, Nikolay Dimitrov wrote:
>> Hi Gary,
>>
>> On 05/19/2015 01:53 PM, Gary Thomas wrote:
>>> On 2015-05-18 17:52, Nikolay Dimitrov wrote:
>>>> Ho Gary,
>>>>
>>>> On 05/18/2015 07:27 PM, Gary Thomas wrote:
>>>>> On 2015-05-18 09:55, Nikolay Dimitrov wrote:
>>>>>> Hi Gary,
>>>>>>
>>>>>> On 05/18/2015 03:04 PM, Gary Thomas wrote:
>>>>>>> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>>>>>>>> Hi Pawel,
>>>>>>>>
>>>>>>>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I'm having some problems running video playback on Nitrogen6x-Lite.
>>>>>>>>> I'm
>>>>>>>>> using fido with 3.10.53 kernel. Display is running properly as I
>>>>>>>>> see a
>>>>>>>>> console after start, but starting any simple video with
>>>>>>>>> Gstreamer1.0 +
>>>>>>>>> gstreamer-imx plugins does not give any video output, even though
>>>>>>>>> the
>>>>>>>>> decoding looks like it's working.
>>>>>>>>>
>>>>>>>>> Gstreamer log:
>>>>>>>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>>>>>>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>>>>>>>> imxipuvideosink
>>>>>>>>> [INFO]    Product Info: i.MX6Q/D/S
>>>>>>>>> Pipeline is live and does not need PREROLL ...
>>>>>>>>> Progress: (open) Opening Stream
>>>>>>>>> Progress: (connect) Connecting to
>>>>>>>>> rtsp://192.168.7.24:554/profile3/media.smp
>>>>>>>>> Progress: (open) Retrieving server options
>>>>>>>>> Progress: (open) Retrieving media info
>>>>>>>>> Progress: (request) SETUP stream 0
>>>>>>>>> Progress: (request) SETUP stream 1
>>>>>>>>> Progress: (open) Opened Stream
>>>>>>>>> Setting pipeline to PLAYING ...
>>>>>>>>> New clock: GstSystemClock
>>>>>>>>> Progress: (request) Sending PLAY request
>>>>>>>>> Progress: (request) Sending PLAY request
>>>>>>>>> Progress: (request) Sent PLAY request
>>>>>>>>> ^Chandling interrupt.
>>>>>>>>> Interrupt: Stopping pipeline ...
>>>>>>>>> Execution ended after 0:00:15.125067669
>>>>>>>>> Setting pipeline to PAUSED ...
>>>>>>>>> Setting pipeline to READY ...
>>>>>>>>> Setting pipeline to NULL ...
>>>>>>>>> Freeing pipeline ...
>>>>>>>>>
>>>>>>>>> Plugins installed:
>>>>>>>>>
>>>>>>>>> gst-inspect-1.0 | grep imx
>>>>>>>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>>>>>>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>>>>>>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>>>>>>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>>>>>>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>>>>>>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>>>>>>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>>>>>>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>>>>>>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>>>>>>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>>>>>>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>>>>>>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>>>>>>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>>>>>>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>>>>>>>
>>>>>>>>> While using imxeglvivsink I'm seeing red flash for few milliseconds
>>>>>>>>> over
>>>>>>>>> the console and that's it.
>>>>>>>>> Any advices will be helpful.
>>>>>>>>
>>>>>>>> Please download this file and try a local file playback, to
>>>>>>>> eliminate
>>>>>>>> possible networking issues:
>>>>>>>>
>>>>>>>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>>>>>>>
>>>>>>>> Also, please check whether an automatically constructed pipeline is
>>>>>>>> able to play the file above:
>>>>>>>>
>>>>>>>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>>>>>>>
>>>>>>>> You can try same tests with Xorg running.
>>>>>>>
>>>>>>> What would that pipeline look like (to force the result into a window
>>>>>>> on the screen)?  As is, this simple command takes over the entire
>>>>>>> screen.
>>>>>>
>>>>>> The automatically generated pipeline depends entirely on the media
>>>>>> itself and the set of plugins you have installed - playbin/decodebin
>>>>>> and friends are looking at the stream properties and searching for the
>>>>>> plugin with the highest rank which can be plugged there. The best
>>>>>> place
>>>>>> to look at is usually the media graphs (.dot files) after playbin was
>>>>>> able to play something (I do this regularly, as my pipelines are
>>>>>> usually worse than the ones created by playbin).
>>>>>
>>>>> I tried interpreting these files and since I don't do it all the time
>>>>> (like you)it was hard for me to see the whole picture.  Is it possible
>>>>> to look at such a graph and write something equivalent that could be
>>>>> run via gst-launch?
>>>>>
>>>>> Here's my graph in case you can make any sense of it.
>>>>
>>>> Not sure that the following will help much, but at least I can share
>>>> what I know, so we can be in the same boat...
>>>>
>>>> Please look at the demuxer (qtdemux0), notice that the lower 2 source
>>>> pads are denoted with dashed lines, which means these pads are dynamic,
>>>> e.g. doesn't exist all the time (there are more components with dynamic
>>>> pads in this pipeline).
>>>>
>>>> What happens is that after playback start, the demuxer only consumes
>>>> data for a while and doesn't have any output pads. When the demuxer
>>>> understands what logical streams are carried over the transport, it
>>>> dynamically creates a number of source pads, one for each supported
>>>> content type (usually for video/audio/subs, but can be more).
>>>>
>>>> When the demuxer's dynamic pads are created, the pipeline emits events,
>>>> and the parent element (decodebin0) catches these events, looks for
>>>> appropriate decoding elements, and attaches them to the pipeline
>>>> dynamically.
>>>>
>>>> The trouble with these dynamic pipelines is that you can't refer to the
>>>> source/sink pads of the elements before the pipeline is created, which
>>>> means you can't construct a working dynamic pipeline from the command
>>>> line. I looked how to do this, but couldn't find a solution. If someone
>>>> knows how to do this, would be great to share.
>>>>
>>>> So the only way I know to create fully custom dynamic pipelines (e.g.
>>>> driven by the content) is via source code, otherwise we have to use
>>>> automated bins like playbin/decodebin, and give them some parameters.
>>>
>>> Thanks for the explanation, perhaps it can help someone fix this.  My
>>> guess is that the FSL plugin doesn't handle those dynamic elements and
>>> thus is not equipped to set up the render in the appropriate window on
>>> the screen.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Also the full-screen behavior depends the videosink configuration, so
>>>>>> hard to give universal answer, as none will fit all cases.
>>
>> I doubt that the issue is caused exactly by the GstImxVpuDec or
>> GstOverlaySink, as by looking at your pipeline they seem to have static
>> pads. So it's more of how the playbin/decodebin bins handle the pipeline
>> creation process...
>
>
> Sorry for this, icedove sent my mail by displaying a pop-up dialog
> while I was pressing Enter for a new line...
>
> Here's a small trick - you can hint playbin about what video sink
> element you want to use, regardless of the element ranks and
> capabilities:
>
> gst-launch playbin uri=file:///test.mp4 video-sink="myvideosink option=value"
>
> So you can enforce you video sink preferences even on automated
> pipelines.

Sadly, I'm not sure how to make this happen when the command in question is
hiding behind various wrappers (e.g. gtk-play)

Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Paweł Żabiełowicz]

Indeed the problem was with the pipeline. The 'h264parse' was missing 
after depay plugin. Test with 'videotestsrc' was successful and using 
either 'imxeglvivsink' or 'imxipuvideosink' I was able to see the 
rendered video.
Thank you for the tip.

Pawel

On 18.05.2015 14:04, Gary Thomas wrote:
> On 2015-05-18 02:18, Nikolay Dimitrov wrote:
>> Hi Pawel,
>>
>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote:
>>> Hi all,
>>>
>>> I'm having some problems running video playback on Nitrogen6x-Lite. I'm
>>> using fido with 3.10.53 kernel. Display is running properly as I see a
>>> console after start, but starting any simple video with Gstreamer1.0 +
>>> gstreamer-imx plugins does not give any video output, even though the
>>> decoding looks like it's working.
>>>
>>> Gstreamer log:
>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579
>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec !
>>> imxipuvideosink
>>> [INFO]    Product Info: i.MX6Q/D/S
>>> Pipeline is live and does not need PREROLL ...
>>> Progress: (open) Opening Stream
>>> Progress: (connect) Connecting to
>>> rtsp://192.168.7.24:554/profile3/media.smp
>>> Progress: (open) Retrieving server options
>>> Progress: (open) Retrieving media info
>>> Progress: (request) SETUP stream 0
>>> Progress: (request) SETUP stream 1
>>> Progress: (open) Opened Stream
>>> Setting pipeline to PLAYING ...
>>> New clock: GstSystemClock
>>> Progress: (request) Sending PLAY request
>>> Progress: (request) Sending PLAY request
>>> Progress: (request) Sent PLAY request
>>> ^Chandling interrupt.
>>> Interrupt: Stopping pipeline ...
>>> Execution ended after 0:00:15.125067669
>>> Setting pipeline to PAUSED ...
>>> Setting pipeline to READY ...
>>> Setting pipeline to NULL ...
>>> Freeing pipeline ...
>>>
>>> Plugins installed:
>>>
>>> gst-inspect-1.0 | grep imx
>>> imxipu:  imxipuvideotransform: Freescale IPU video transform
>>> imxipu:  imxipuvideosink: Freescale IPU video sink
>>> imxvpu:  imxvpudec: Freescale VPU video decoder
>>> imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder
>>> imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder
>>> imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder
>>> imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder
>>> imxg2d:  imxg2dvideosink: Freescale G2D video sink
>>> imxg2d:  imxg2dvideotransform: Freescale G2D video transform
>>> imxaudio:  imxuniaudiodec: Freescale i.MX uniaudio decoder
>>> imxv4l2src:  imxv4l2src: V4L2 CSI Video Source
>>> imxpxp:  imxpxpvideosink: Freescale PxP video sink
>>> imxpxp:  imxpxpvideotransform: Freescale PxP video transform
>>> imxeglvivsink:  imxeglvivsink: Freescale EGL video sink
>>>
>>> While using imxeglvivsink I'm seeing red flash for few milliseconds over
>>> the console and that's it.
>>> Any advices will be helpful.
>>
>> Please download this file and try a local file playback, to eliminate
>> possible networking issues:
>>
>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>>
>> Also, please check whether an automatically constructed pipeline is
>> able to play the file above:
>>
>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4
>>
>> You can try same tests with Xorg running.
>
> What would that pipeline look like (to force the result into a window
> on the screen)?  As is, this simple command takes over the entire screen.
>
>