Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Getting video without X through mplayer (fixed)
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Multimedia
View previous topic :: View next topic  
Author Message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Sun Nov 04, 2012 9:08 pm    Post subject: Getting video without X through mplayer (fixed) Reply with quote

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.
_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim


Last edited by Bigun on Fri Nov 16, 2012 11:12 am; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sun Nov 04, 2012 9:23 pm    Post subject: Reply with quote

Bigun,

What does
Code:
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:
mplayer -vo directfb ...


I haven't actually tried this yet.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Sun Nov 04, 2012 9:30 pm    Post subject: Reply with quote

I was just looking at that command. It looks like SDL and directfb conflict... which is better?
_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim
Back to top
View user's profile Send private message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Sun Nov 04, 2012 11:13 pm    Post subject: Reply with quote

I just tried directfb with no success.

I'm running the command from an SSH terminal, does that make any difference?
_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim
Back to top
View user's profile Send private message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Sun Nov 04, 2012 11:20 pm    Post subject: Reply with quote

Sorry, here is the error:

Code:
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.

_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim
Back to top
View user's profile Send private message
HolgerB
n00b
n00b


Joined: 07 Sep 2011
Posts: 49

PostPosted: Mon Nov 05, 2012 9:43 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
chithanh
Developer
Developer


Joined: 05 Aug 2006
Posts: 2158
Location: Berlin, Germany

PostPosted: Mon Nov 05, 2012 10:52 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
HolgerB
n00b
n00b


Joined: 07 Sep 2011
Posts: 49

PostPosted: Mon Nov 05, 2012 11:01 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
chithanh
Developer
Developer


Joined: 05 Aug 2006
Posts: 2158
Location: Berlin, Germany

PostPosted: Mon Nov 05, 2012 11:06 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
HolgerB
n00b
n00b


Joined: 07 Sep 2011
Posts: 49

PostPosted: Mon Nov 05, 2012 11:08 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Mon Nov 05, 2012 11:09 am    Post subject: Reply with quote

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?
_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim
Back to top
View user's profile Send private message
HolgerB
n00b
n00b


Joined: 07 Sep 2011
Posts: 49

PostPosted: Mon Nov 05, 2012 11:11 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Mon Nov 05, 2012 7:26 pm    Post subject: Reply with quote

Worst case scenario: How would mplayer perform with xorg installed with no window manager?
_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Mon Nov 05, 2012 7:42 pm    Post subject: Reply with quote

Bigun,

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

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Mon Nov 05, 2012 8:22 pm    Post subject: Reply with quote

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. :?
_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim
Back to top
View user's profile Send private message
HolgerB
n00b
n00b


Joined: 07 Sep 2011
Posts: 49

PostPosted: Mon Nov 05, 2012 8:47 pm    Post subject: Reply with quote

Hm, to my best knowledge omxplayer was done as proof-of-concept by the folks from the XBMC for Rasp project.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Mon Nov 05, 2012 9:42 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Mon Nov 05, 2012 10:23 pm    Post subject: Reply with quote

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. :cry:

*edit*

Would posting that I'm experiencing the same thing on the bug in bugzilla help get some traction on the issue?
_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Mon Nov 05, 2012 10:50 pm    Post subject: Reply with quote

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:
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:
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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Tue Nov 06, 2012 12:43 pm    Post subject: Reply with quote

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:
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:
>>> 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?
_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Tue Nov 06, 2012 8:20 pm    Post subject: Reply with quote

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:
=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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Thu Nov 08, 2012 11:42 am    Post subject: Reply with quote

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.
_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim


Last edited by Bigun on Fri Nov 09, 2012 1:41 pm; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Thu Nov 08, 2012 8:09 pm    Post subject: Reply with quote

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:
ebuild /path/to/ebuild manifest
so that portage is happy with the file names, sizes and assorted checksums.

Run
Code:
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:
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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Bigun
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 2196

PostPosted: Sat Nov 10, 2012 8:38 pm    Post subject: Reply with quote

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:
>>> 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:
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.
_________________
"It's ok, they might have guns but we have flowers." - Perpetual Victim
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sat Nov 10, 2012 9:02 pm    Post subject: Reply with quote

Bigun,

It should be where this fragment shows
Code:
 * 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?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Multimedia All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum