View previous topic :: View next topic |
Author |
Message |
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Sun Nov 04, 2012 9:08 pm Post subject: Getting video without X through mplayer (fixed) |
|
|
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 |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54423 Location: 56N 3W
|
Posted: Sun Nov 04, 2012 9:23 pm Post subject: |
|
|
Bigun,
What does 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 |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Sun Nov 04, 2012 9:30 pm Post subject: |
|
|
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 |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Sun Nov 04, 2012 11:13 pm Post subject: |
|
|
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 |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Sun Nov 04, 2012 11:20 pm Post subject: |
|
|
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 |
|
|
HolgerB n00b
Joined: 07 Sep 2011 Posts: 49
|
Posted: Mon Nov 05, 2012 9:43 am Post subject: |
|
|
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 |
|
|
chithanh Developer
Joined: 05 Aug 2006 Posts: 2158 Location: Berlin, Germany
|
Posted: Mon Nov 05, 2012 10:52 am Post subject: |
|
|
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 |
|
|
HolgerB n00b
Joined: 07 Sep 2011 Posts: 49
|
Posted: Mon Nov 05, 2012 11:01 am Post subject: |
|
|
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 |
|
|
chithanh Developer
Joined: 05 Aug 2006 Posts: 2158 Location: Berlin, Germany
|
Posted: Mon Nov 05, 2012 11:06 am Post subject: |
|
|
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 |
|
|
HolgerB n00b
Joined: 07 Sep 2011 Posts: 49
|
Posted: Mon Nov 05, 2012 11:08 am Post subject: |
|
|
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 |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Mon Nov 05, 2012 11:09 am Post subject: |
|
|
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 |
|
|
HolgerB n00b
Joined: 07 Sep 2011 Posts: 49
|
Posted: Mon Nov 05, 2012 11:11 am Post subject: |
|
|
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 |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Mon Nov 05, 2012 7:26 pm Post subject: |
|
|
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 |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54423 Location: 56N 3W
|
Posted: Mon Nov 05, 2012 7:42 pm Post subject: |
|
|
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 |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Mon Nov 05, 2012 8:22 pm Post subject: |
|
|
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 |
|
|
HolgerB n00b
Joined: 07 Sep 2011 Posts: 49
|
Posted: Mon Nov 05, 2012 8:47 pm Post subject: |
|
|
Hm, to my best knowledge omxplayer was done as proof-of-concept by the folks from the XBMC for Rasp project. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54423 Location: 56N 3W
|
Posted: Mon Nov 05, 2012 9:42 pm Post subject: |
|
|
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 |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Mon Nov 05, 2012 10:23 pm Post subject: |
|
|
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? _________________ "It's ok, they might have guns but we have flowers." - Perpetual Victim |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54423 Location: 56N 3W
|
Posted: Mon Nov 05, 2012 10:50 pm Post subject: |
|
|
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 |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Tue Nov 06, 2012 12:43 pm Post subject: |
|
|
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 |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54423 Location: 56N 3W
|
Posted: Tue Nov 06, 2012 8:20 pm Post subject: |
|
|
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 |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Thu Nov 08, 2012 11:42 am Post subject: |
|
|
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 |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54423 Location: 56N 3W
|
Posted: Thu Nov 08, 2012 8:09 pm Post subject: |
|
|
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
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 |
|
|
Bigun Advocate
Joined: 21 Sep 2003 Posts: 2196
|
Posted: Sat Nov 10, 2012 8:38 pm Post subject: |
|
|
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 |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54423 Location: 56N 3W
|
Posted: Sat Nov 10, 2012 9:02 pm Post subject: |
|
|
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 |
|
|
|