Bug 10287

Can you elaborate on broken, and what happens if you use the command-line player to see any messages that it emits?

As mentioned in the original report, the video will freeze.  In one run (on qemu)
there was no change in the video display from the first frame until about 20 seconds in, then it froze again and there was no other change for many seconds.  The audio seems to run OK (no clicks or pauses).  I've tried other media players (mpv, mplayer2) on the same targets and they can play this video with no troubles.

> Please try with http://www.mlbassoc.com/misc/Vlad+Louise.mp4 (copy
> to local storage) - it will freeze and be basically useless.

Works for me on an old NUC running intel-corei7-64: no frame drops or other visible problems, CPU usage is maybe 2%.

qemu running qemux86-64 manages to play the video without problems but works a lot harder, CPU usage maybe 30%. I can imagine that on a less beefy host that might be choppy...

(In reply to comment #3)
> qemu running qemux86-64 manages to play the video without problems but works
> a lot harder, CPU usage maybe 30%. I can imagine that on a less beefy host
> that might be choppy...

qemux86 plays the clip as well, although with even higher load average.

(In reply to comment #4)
> (In reply to comment #3)
> > qemu running qemux86-64 manages to play the video without problems but works
> > a lot harder, CPU usage maybe 30%. I can imagine that on a less beefy host
> > that might be choppy...
> 
> qemux86 plays the clip as well, although with even higher load average.

So what could be the difference?  My qemux86 test is on a snappy 'Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz', albeit over an SSH connection.  The other tests are on the local hardware.

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > qemu running qemux86-64 manages to play the video without problems but works
> > > a lot harder, CPU usage maybe 30%. I can imagine that on a less beefy host
> > > that might be choppy...
> > 
> > qemux86 plays the clip as well, although with even higher load average.
> 
> So what could be the difference?  My qemux86 test is on a snappy 'Intel(R)
> Core(TM) i5-4460  CPU @ 3.20GHz', albeit over an SSH connection.  The other
> tests are on the local hardware.

I can provide comparative videos (taken of my target hardware) of gst-play vs other media players on Yocto and the exact same system where the gst-play is horrible and other media players work just fine... (e.g. on my RaspberryPi-3)

It's always useful to pin down gst-play vs gst-launch, and identify if there's any particular pipeline that isn't working (ie is it doing video colourspace conversion via software OpenGL).

Also can you replicate if you go back to say the 2.2M2 snapshot.

(In reply to comment #7)
> It's always useful to pin down gst-play vs gst-launch, and identify if
> there's any particular pipeline that isn't working (ie is it doing video
> colourspace conversion via software OpenGL).
> 
> Also can you replicate if you go back to say the 2.2M2 snapshot.

I tried going back as far as the current krogoth branch and it still doesn't work for me (at least on qemux86)

(In reply to comment #5)
> (In reply to comment #4)
> > qemux86 plays the clip as well, although with even higher load average.
> 
> So what could be the difference?  My qemux86 test is on a snappy 'Intel(R)
> Core(TM) i5-4460  CPU @ 3.20GHz', albeit over an SSH connection.

My experience is that qemu runs pretty badly on X-over-SSH. I wouldn't trust video quality tests on that.

(In reply to comment #9)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > qemux86 plays the clip as well, although with even higher load average.
> > 
> > So what could be the difference?  My qemux86 test is on a snappy 'Intel(R)
> > Core(TM) i5-4460  CPU @ 3.20GHz', albeit over an SSH connection.
> 
> My experience is that qemu runs pretty badly on X-over-SSH. I wouldn't trust
> video quality tests on that.

Fair enough, but as I mentioned, I've also tried it directly on the desktop,
and it still didn't work for me.

I'm currently preparing to try it on another reference platform [beaglebone-black] and will let you know the outcome.

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > qemux86 plays the clip as well, although with even higher load average.
> > > 
> > > So what could be the difference?  My qemux86 test is on a snappy 'Intel(R)
> > > Core(TM) i5-4460  CPU @ 3.20GHz', albeit over an SSH connection.
> > 
> > My experience is that qemu runs pretty badly on X-over-SSH. I wouldn't trust
> > video quality tests on that.
> 
> Fair enough, but as I mentioned, I've also tried it directly on the desktop,
> and it still didn't work for me.
> 
> I'm currently preparing to try it on another reference platform
> [beaglebone-black] and will let you know the outcome.

Equally bad on the beaglebone-black I'm afraid.

Just noticed that you're using gst-libav, so I suspect the actual problem is there and not gst-play.

(In reply to comment #12)
> Just noticed that you're using gst-libav, so I suspect the actual problem is
> there and not gst-play.

So what are the options to play this .mp4 file with gst-play?

Hardware-specific, really.  For x86, gst-vaapi.  For beagle and RPi, I've no idea what is best of class and if it should be libav.

I'm afraid I don't know how to push this issue forward: video playback works for me on multiple intel-based machines (and qemux86*) and I don't have imx6 or rpi to test with. If you have a case where intel hardware really can't play video I can continue looking into it. Likewise for qemux86* although it may be slightly less useful: we can't expect hw decode to work there so any tests with a decode step should be taken with a grain of salt.

For the other platforms I can only refer to Ross' earlier comment: 

(In reply to comment #7)
> It's always useful to pin down gst-play vs gst-launch, and identify if
> there's any particular pipeline that isn't working (ie is it doing video
> colourspace conversion via software OpenGL).

I'd run gst-launch using playbin with GST_DEBUG_DUMP_DOT_DIR set:

  GST_DEBUG_DUMP_DOT_DIR=$PWD gst-launch-1.0 playbin uri=file:///home/jku/Vlad+Louise.mp4

This gets you a bunch of dot files that graphviz can convert to images describing the pipeline playbin builds -- probably a very close approximation of what gtk-play does. If there's anything odd in the pipeline I'd try to create one manually (without playbin).

In addition I would look at any platform specific components you might need -- e.g. the earlier raspberries required gst-omx (for the hw-specific h264 decoder element) and meta-freescale has a recipe that provides some gst elements: are these hw specific elements available and do they end up in the pipeline?

I believe Gary is seeing an actual bug somewhere but my current guess is that the bug is in rpi video acceleration support and not yocto itself: GStreamer video acceleration works for me and QA on various Intel hardware (and qemu although that's less relevant).

So I'm closing this for now: If you have any more info, please reopen.