Getting video without X through mplayer (fixed)

Message

Bigun · Post by **Bigun** » Sun Nov 04, 2012 9:08 pm

I have a raspberry pi, and I'm trying to get mplayer to play video out of the HMDI port without X.

I got sound working, but video is the current issue.

Post by **NeddySeagoon** » Sun Nov 04, 2012 9:23 pm

Bigun,

What does

Code: Select all

mplayer -vo help

tell you?

Hopefully one of the lines says directfb, if not, fix your mplayer as it has a bit missing.
Now try

Code: Select all

mplayer -vo directfb ...

I haven't actually tried this yet.

Bigun · Post by **Bigun** » Sun Nov 04, 2012 9:30 pm

I was just looking at that command. It looks like SDL and directfb conflict... which is better?

Bigun · Post by **Bigun** » Sun Nov 04, 2012 11:13 pm

I just tried directfb with no success.

I'm running the command from an SSH terminal, does that make any difference?

Bigun · Post by **Bigun** » Sun Nov 04, 2012 11:20 pm

Sorry, here is the error:

Code: Select all

Movie-Aspect is 2.29:1 - prescaling to correct movie aspect.
VO: [directfb] 624x272 => 624x272 Planar YV12
 (!!!)  *** WARNING [letting unprivileged IDirectFBDisplayLayer::GetSurface() call pass until cooperative level handling is finished] *** [idirectfbdisplaylayer.c:176 in IDirectFBDisplayLayer_GetSurface()]
 (!?!)  *** BUG [unknown buffermode] *** [layer_context.c:1752 in allocate_surface()]
 (!?!)  *** BUG [unknown buffermode] *** [layer_context.c:1853 in reallocate_surface()]
(!) Core/Layers: Reallocation of layer surface failed!
    --> Internal bug!
DirectFB: ConfigError in layer configuration (format, flags=4)
(#) DirectFBError [MPlayer - layer pixelformat change]: Internal bug!
FATAL: Cannot initialize video driver.

HolgerB · Post by **HolgerB** » Mon Nov 05, 2012 9:43 am

I am not shure it the Gentoo flavor for Raspi shares the same programs as the Debian-based stuff does but under Raspian I am using OMXPlayer which is adapted for the Raspi and plays back 1080p stuff fine via HDMI without the need for X.

http://elinux.org/Omxplayer

HTH,
Holger

chithanh · Post by **chithanh** » Mon Nov 05, 2012 10:52 am

Getting DirectFB to work with acceleration on the Raspberry Pi is tricky. In addition, you will need at least directfb-1.6 which is not in portage yet.

If mplayer was built with USE="fbcon" then you can use mplayer -vo fbdev, but that is unaccelerated.

HolgerB · Post by **HolgerB** » Mon Nov 05, 2012 11:01 am

Is the vanilla Mplayer capable of accessing the Raspis GPU acceleration for H264 / MPEG4 ?
If not I could imagine that it is pretty useless for daily use due to the low CPU power of the Raspi.

chithanh · Post by **chithanh** » Mon Nov 05, 2012 11:06 am

There is mplayer playback acceleration possible through a GLES patch which has been floating around for a while. Decode acceleration however is not possible at this time.

HolgerB · Post by **HolgerB** » Mon Nov 05, 2012 11:08 am

This is a pitty ! Hopefully we will see a merge of the OMXPlayer code (if possible) with the default branch of MPlayer.
OMXPlayer is really cool and it is surprising to see 1080p stuff via HDMI from a Raspi.

Bigun · Post by **Bigun** » Mon Nov 05, 2012 11:09 am

HolgerB wrote:I am not shure it the Gentoo flavor for Raspi shares the same programs as the Debian-based stuff does but under Raspian I am using OMXPlayer which is adapted for the Raspi and plays back 1080p stuff fine via HDMI without the need for X.

http://elinux.org/Omxplayer

HTH,
Holger

My biggest worry is codec support and using builtin subtitles, how does it do there?

HolgerB · Post by **HolgerB** » Mon Nov 05, 2012 11:11 am

Hm, I can not comment on subtitles but Codecs are limited what is supported by the Raspi's SOC:
Per default most h264 stuff plus MPEG4 SP (DivX / XVid). For MPEG2 you have to pay an extra license.

Bigun · Post by **Bigun** » Mon Nov 05, 2012 7:26 pm

Worst case scenario: How would mplayer perform with xorg installed with no window manager?

Post by **NeddySeagoon** » Mon Nov 05, 2012 7:42 pm

Bigun,

The problem here is hardware assisted acceleration. The same limitations apply regardless if the use of Xorg or not.

Bigun · Post by **Bigun** » Mon Nov 05, 2012 8:22 pm

HolgerB wrote:This is a pitty ! Hopefully we will see a merge of the OMXPlayer code (if possible) with the default branch of MPlayer.
OMXPlayer is really cool and it is surprising to see 1080p stuff via HDMI from a Raspi.

There is an overlay that contains an e-build for it, but a patch failed (and so did the build) and I have no idea where to get support for it.

HolgerB · Post by **HolgerB** » Mon Nov 05, 2012 8:47 pm

Hm, to my best knowledge omxplayer was done as proof-of-concept by the folks from the XBMC for Rasp project.

Post by **NeddySeagoon** » Mon Nov 05, 2012 9:42 pm

Bigun,

The patch fails because the lines in hunk1 that need to be removed have been changed.
After you fix that, omxplayer-9999-wrapper.patch fails to apply too.
The is a bug on bugs.gentoo.org for that.

My Pi doesn't have layman yet, so I can check that the patches apply but not usefully build the code.

Bigun · Post by **Bigun** » Mon Nov 05, 2012 10:23 pm

NeddySeagoon wrote:Bigun,

The patch fails because the lines in hunk1 that need to be removed have been changed.
After you fix that, omxplayer-9999-wrapper.patch fails to apply too.
The is a bug on bugs.gentoo.org for that.

My Pi doesn't have layman yet, so I can check that the patches apply but not usefully build the code.

And it looks like it isn't fixed yet. So we are waiting on the developer of the patch then? What's disheartening is that this was posted in June, it kinda reaks of being dropped with little to no support.

I just tried mplayer using unaccelerated fbdev with overclocking turned on (it isn't mine and I got permission), for the average sized movies it will play fine, although I'm not sure if there is a switch to scale the video in a framebuffer display to fullscreen, so the image is small. If anyone knows a flag, option, or switch to make mplayer scale the video to fit fullscreen in a framebuffer, let me know. For bluray quality stuff, it doesn't even come close to cutting it, even with framdrop turned on.

It would be very nice to get direct rendering to work for gentoo.

*edit*

Would posting that I'm experiencing the same thing on the bug in bugzilla help get some traction on the issue?

Post by **NeddySeagoon** » Mon Nov 05, 2012 10:50 pm

Bigun,

Its not hard to fix so the patches apply.
You need to be able to read the patch files, apply the patch by hand, make a

Code: Select all

diff -u oldfile newfile >patchfile

then use the new patchfile.

A - at the start of the line is a line to be removed
A + at the start of a line is a line to be added.
There is 3 lines of context at the top and bottom of each 'hunk'. A hunk is considered a single change.

The problem with the Makefile.patch is that the region to be patched by hunk1 has changed, so patch can't find it.

I've not really looked at omxplayer-9999-wrapper.patch from a quick look, its a wrapper to set up the output resolution to 1920x1080 and start omxplayer.
If you don't mind doing that by hand, its not needed. The hack is to change the ebuild to not apply the patch.

Whenever you change anything that goes into an ebuild, you need to fix the manifest, so portage doesn't mind. Thats

Code: Select all

ebuild /path/to/.ebuild manifest

Lastly, work in your own private overlay, or syncing will wipe out all your hard work.

You can get my revised Makefile.patch and test if you want.
All I can say right now is that it applies cleanly.

Bigun · Post by **Bigun** » Tue Nov 06, 2012 12:43 pm

With an overlay and a custom e-build in my own local portage environment both named omxplayer, how would emerge know which package I'm wanting to install? Do I need to remove the custom overlay first?

I went ahead and deleted the overlay anyway, just in case.

Code: Select all

gmedia bigun # layman -d xmw
* Deleting directory "/var/lib/layman/xmw"
* Successfully deleted overlay "xmw".

I then created the custom portage overlay and digested the ebuild.

From there I'm not sure where to put the custom makefile patch.

I also see this which worries me:

Code: Select all

>>> Emerging (1 of 1) media-video/omxplayer-9999 from x-portage
>>> Unpacking source...
GIT update -->
   repository:               https://github.com/huceke/omxplayer.git
   at the commit:            4043f6419a163527af2060a7a22a8eed9ffa0b63
   branch:                   master
   storage directory:        "/usr/portage/distfiles/egit-src/omxplayer.git"
   checkout type:            bare repository
Cloning into '/var/tmp/portage/media-video/omxplayer-9999/work/omxplayer-9999'...

Is this ebuild still pulling from the git repository every time it emerges?

Post by **NeddySeagoon** » Tue Nov 06, 2012 8:20 pm

Bigun,

There are two things here. layman installs overlays, which themselves are normally held in a version control system, such as git.

The code you want to compile using the ebuild was at sometime in it life held in a version control system. All projects work that way so that many people can apply patches to the sources at the same time. Again this may be git. For most packages, gentoo provides a mirror of the sources. The is the useful bit of the source code repository. There is no need for you to have the history.
ebuilds ending in -9999 are a special case. The fetch the source code (not the ebuild) for the projects repository. After the first fetch, they just update what you already have.

The source repository for the ebuild and the source repository for the code it builds are two different places.

If you want to have the same ebuild installed on your system from several different repositories, there are two mechanisims for controlling when one gets used.
In your own local overlay, you are in change of versions - you can bump the -r part of the ebuild file name. I usually stat at -r101 as its obvious when you look at the output of emerge -av <package>

The other mechanism is package masking you may speciifiy a repository name in a package.mask, such as

Code: Select all

=media-video/omxplayer-9999::x-portage

This prevents media-video/omxplayer at version 9999 from the x-portage overlay being used. If you have media-video/omxplayer-9999 in another overlay, it cam still be used.
If you have media-video/omxplayer-9999-r1 somewhere, that beats all as its a higher version number.

Bigun · Post by **Bigun** » Thu Nov 08, 2012 11:42 am

It took me a while to digest what you said.

So, I'm still confused. If I have a potential Makefile that could fix this mess, but this e-build will continue to grab the material from the git repository until a successful e-build, but it won't build without the makefile, then how do I apply this patch?

I really don't mean to sound stupid, I've just never messed with 3rd party e-builds all that much.

I've gotten rid of the overlay, as you said, on the next emerge my changes will be gone, no point in having it. So the only thing I have is my own custom overlay.

Post by **NeddySeagoon** » Thu Nov 08, 2012 8:09 pm

Bigun,

Heres the process. In the directory with the .ebuild file is a directory called ./files
You will find the patch files here with names ending .patch.

Rename the makefile patch. You will want to read it to make the new patch file, so don't loose it.
Run

Code: Select all

ebuild /path/to/ebuild manifest

so that portage is happy with the file names, sizes and assorted checksums.

Run

Code: Select all

emerge omxplayer

If you have set your keywords correctly, emerge will start and fail as it can't find the Makefile patch (you renamed it above).

The fail message will tell where the build location is. Proably /var/tmp/portage somewhere. cd to there and you will find
omxplayer sources unpacked. You could just unpack it yourself somewhere in ~/ but this will give you and insight into some of the works.

You will find Makefile there, unchanged by any successfully applied patch hunks. Make a copy of Makefile called Makefile.old You need this to make your patch later.
Open Makefile in your editor and open the original patch file (which you renamed) in your pager.

The first hunk applies tight at the top of the Makefile. Make the changes line by line in Makefile. Where a line in the patch starts with a -, delete the same line from Makefile.
Where it starts with a +, add the line to Makefile. Work through the first hunk like this.
Notice that the three lines of context at the end of hunk1, the line without a leading + or - have changed between the Makefile and the patch. This is what caused the patch to fail.

Further down the file, repeat for hunk2. Save the changed Makefile.

You now have an original Makefile, called Makefile.old and a changed Makefile, so you have all of the ingredients needed to produce a patch.
Do this with

Code: Select all

diff -u Makefile.old Makefile > patch.file

I often get the input files the wrong way round, look at patchfile to make sure the + and - are against the right lines or you will have a reversed patch, which portage won't apply. When the patch is correct, put in in place of the patch file you originally renamed on ./files, using the same name as the original patch.

Make the ebuild manifest again and emerge to test. This time, the Makefile patch will apply but the -wrapper patch will fail.
Rinse and repeat for the -wrapper.

When you have built and tested omxplayer, file a bug at bugs.gentoo.org. In the bug explain what you did, and how you tested it. Attach the two patches to your bug.
It will save others after you repeating your work. Leave a comment on the existing -wrapper bug pointing to your new bug.
Thats how Open Source works. Now you can move on to your next bug.

When you post enough patches, you will be encouraged to become a developer because its less work for existing devs. You get to commit your own work to the tree.
Thats how Gentoo works. You have a lot to learn from your first patch to commit access to the portage tree but everyone starts somewhere.

The workflow I outined is not the best but it takes advantage of portage working the way it normally works. You could fetch the sources to your ./~ and to all the work there.

Bigun · Post by **Bigun** » Sat Nov 10, 2012 8:38 pm

Sorry to keep being a pain, but I'm having issues finding the wrapper patch.

Here is the initial failure when I apply the patch as you described:

Code: Select all

>>> Emerging (1 of 1) media-video/omxplayer-9999 from x-portage
>>> Unpacking source...
GIT update -->
   repository:               https://github.com/huceke/omxplayer.git
   at the commit:            4043f6419a163527af2060a7a22a8eed9ffa0b63
   branch:                   master
   storage directory:        "/usr/portage/distfiles/egit-src/omxplayer.git"
   checkout type:            bare repository
Cloning into '/var/tmp/portage/media-video/omxplayer-9999/work/omxplayer-9999'...
done.
Branch branch-master set up to track remote branch master from origin.
Switched to a new branch 'branch-master'
>>> Unpacked to /var/tmp/portage/media-video/omxplayer-9999/work/omxplayer-9999
>>> Source unpacked in /var/tmp/portage/media-video/omxplayer-9999/work
>>> Preparing source in /var/tmp/portage/media-video/omxplayer-9999/work/omxplayer-9999 ...
 * Applying omxplayer-9999-Makefile.patch ...                                                                                                                                                                                         [ ok ]

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 *
 *   /usr/local/portage/media-video/omxplayer/files/omxplayer-9999-wrapper.patch
 *   ( omxplayer-9999-wrapper.patch )

 * ERROR: media-video/omxplayer-9999 failed (prepare phase):
 *   Cannot find $EPATCH_SOURCE!
 *
 * Call stack:
 *     ebuild.sh, line   93:  Called src_prepare
 *   environment, line 2604:  Called epatch '/usr/local/portage/media-video/omxplayer/files/omxplayer-9999-wrapper.patch'
 *   environment, line  882:  Called die
 * The specific snippet of code:
 *                   die "Cannot find \$EPATCH_SOURCE!";
 *
 * If you need support, post the output of `emerge --info '=media-video/omxplayer-9999'`,
 * the complete build log and the output of `emerge -pqv '=media-video/omxplayer-9999'`.
 * This ebuild is from an overlay named 'x-portage': '/usr/local/portage/'
 * The complete build log is located at '/var/tmp/portage/media-video/omxplayer-9999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/media-video/omxplayer-9999/temp/environment'.
 * Working directory: '/var/tmp/portage/media-video/omxplayer-9999/work/omxplayer-9999'
 * S: '/var/tmp/portage/media-video/omxplayer-9999/work/omxplayer-9999'

I then go to look and I can't seem to find the original wrapper patch:

Code: Select all

gmedia files # ls -la /usr/local/portage/media-video/omxplayer/files/omxplayer-9999-wrapper.patch
ls: cannot access /usr/local/portage/media-video/omxplayer/files/omxplayer-9999-wrapper.patch: No such file or directory

I also don't see it in /var/tmp.

Post by **NeddySeagoon** » Sat Nov 10, 2012 9:02 pm

Bigun,

It should be where this fragment shows

Code: Select all

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 *
 *   /usr/local/portage/media-video/omxplayer/files/omxplayer-9999-wrapper.patch
 *   ( omxplayer-9999-wrapper.patch )

I have it at /usr/local/portage/layman/xmw/media-video/omxplayer/files/omxplayer-9999-wrapper.patch
Fetch http://bpaste.net/show/57139/ put it into the files dir and call it omxplayer-9999-wrapper.patch

It looks like you lost it somehow. Have you already removed the .patch from the filename?