Video playback on Pyra

[Silent-Hunter]

I've just been using mplayer directly. It's my favorite! Is there a way to change the thread count on that? I've been using the X11 decoder. The XV decoder made everything have a blue tint, and also stopped working entirely once I fixed the XFT font issue. OpenGL with gl4es is monochrome, and isn't any faster than X11. If it was faster, I'd put up with lack of colour, but it's not any better. I can always transcode things to XVID if that will help.

 

[levi]

I had to give up using mplayer for anything more than playing audio files. It suddently got far too slow on my old x86 computer about four years ago from memory. Since then I've been using cvlc (from the vlc package) to play back my videos, which seems just as performant as mplayer used to be, and will happily drop frames if things get too taxing. I've not idea if this has any bearing on 32-bit ARM machines, but it might be worth a try.

 

[PowerGod]

While doing tests it is also important to know what codecs audio/video were used to make the video.

For example a movie compressed with a video codec h.265 will require a lot more power than the same movie coded in h.264, at least with software decoding, because if the hardware is capable (and used) that is another story.

Also, if the hardware acceleration is used, it could sometime even slow down the process for codecs not directly supported, and in those cases the software acceleration could improve a lot the performances.

You can see the codecs used with this command:

ffmpeg -i <filename>

The lines starting with "Stream" should contain the codec used for audio and video of every track.

EDIT:
While looking around I found this command for Mplayer, I don't know how it is compiled on the Pyra but you could try:

mplayer -lavdopts threads=2

Multi-threaded MPlayer

I want to make MPlayer utilise more than one core. I searched a bit and found a tutorial and a discussion about this. The solution is to run the mplayer executable with the -lavdopts option like th…

slackalaxy.com

 

[elvissteinjr]

Been using mpv as I do everywhere else these days. I don't think I've shared my optimized config yet, though.

ytdl-format=mp4[height<=720]/mp4/best

scale=bilinear
cscale=bilinear
dscale=bilinear
sws-scaler=bilinear
scale-antiring=0
cscale-antiring=0
dither-depth=no
correct-downscaling=no
sigmoid-upscaling=no
deband=no
#hwdec=auto
audio-pitch-correction=no
vd-lavc-skiploopfilter=all
vd-lavc-fast=yes
vd-lavc-threads=4
ad-lavc-threads=4
blend-subtitles=video
vo=sdl
opengl-es=yes
opengl-restrict=200
gpu-dumb-mode=yes
gpu-context=auto
x11-bypass-compositor=yes
framedrop=decoder+vo

This would go into or be mpv.conf. This config trades quality for speed/codec compliance. I don't think most of the opengl or x11 options actually have any effect when using the SDL output driver. Using that seems to be the only way it will do hardware accelerated output properly (with GL4es).
The following is of course anecdotal as videos can have varying complexity even under the same codec, but h.264 and less complex at or under 720p seems to be no issue (press i or check terminal to see dropped frames and such). 1080p can work, oftentimes with a few drops here and there. Avoid 10-bit color depth if possible.
h.265 is less bad than I'd expect, but of course not good enough.
The top line in the config sets the format for youtube-dl so it grabs up to 720p h.264 if available. You really don't want it to default to 4k VP9. If you want to use youtube-dl, you'll have to grab a current version via pip or from somewhere else. The Debian repo version is outdated to the point of being useless for YouTube itself (other supported sites may still work though).

No clue if the config is ideal btw. Just grabbed a low-power config from the internet and tweaked from there with some trial and error.

 

[Silent-Hunter]

Hmmm... I tried that mpv config but it ends up with about the same result as with mplayer, the video and audio go out of sync. cvlc runs horribly, and if I try to use it with gl4es it segfaults. The file I am using for testing is 1280x720 h.264. I did have to change a config to use SoftEXA instead of hardware 2d acceleration, otherwise fonts didn't work in certain programs. That change makes the XV output completely unavailable.

 

[levi]

Okay, sounds like it might be a little to early in the Pyra's life to use it as a video player, but thanks very much for testing.

 

[FBnil]

@Silent-Hunter What about lower quality video (smaller sizes, like what the Pandora could do, like 640x480 and 720x)?
Could you please test smaller files? Do those also get out of sync?

 

[Silent-Hunter]

@Silent-Hunter What about lower quality video (smaller sizes, like what the Pandora could do, like 640x480 and 720x)?
Could you please test smaller files? Do those also get out of sync?

Oh, I've watched things like that. The Dick Van Dyke Show plays fine, for example.

 

[ingoreis]

Should mplayer not work much better than the "apt install mplayer"....when you do compile it on the Pyra itself?

I think many Users here just try the Downloadversion without Optimations for the PyraOS.

Just an Idea for getting it faster is compile it by yourself and when you installed GL4ES..Mplayer will rekognize that automatic which acceleration Things can be used and which not.

I am curious to try that out when my Pyra arrive soon.
Maybe i will get "the Mail" this Weekend

 

[TrashyMG]

I doubt there is much improvement for a compiled mplayer vs the one off the repo.

 

[elvissteinjr]

Hmmm... I tried that mpv config but it ends up with about the same result as with mplayer, the video and audio go out of sync. cvlc runs horribly, and if I try to use it with gl4es it segfaults. The file I am using for testing is 1280x720 h.264. I did have to change a config to use SoftEXA instead of hardware 2d acceleration, otherwise fonts didn't work in certain programs. That change makes the XV output completely unavailable.

Is it actually using GL4es? Don't forget to use the gl4es command if you're using the package from the Pyra debian repo.
What frame rate is the video at? I've been assuming 24/30 fps content. Haven't checked with 60 fps stuff for example.
If it's possible to share the file I'd take a look at it myself. h.264 can have varying complexity after all.

 

[Silent-Hunter]

My guess is the quality is just too high. I can't really send it unfortunately. The Pyra will improve over time, I'm sure.

 

[asimov-solensan]

Sooooo .... Related question: how well does handbrake works on Pyra?

Is the tool I use to transcode videos for pandora. I do it on my server but would be great having the tool on the go.

 

[levi]

As far as I know, ffmpeg which handbrake actually uses to do its transcoding it a heavy user of graphics tools. It should run without any of that, just not very quickly.