[PATCH] Better ARM support for mplayer/ffmpeg, ported from atty fork
Hi, while playing with some new hardware, I found it's running a forked mplayer -- and it looks like they're following the GPL. The maintainer's page is here: http://atty.jp/?Zaurus/mplayer Unfortunately it's mostly in Japanese, so it's hard to figure out any details. Their code looks quite interesting (at least to those of us w/ ARM CPUs). The patches I've attached are the patches from atty.jp with a couple of modifications by myself: - ported to current CVS - reverted their change of removing SNOW support from ffmpeg - cleaned up their bswap mess - removed DOS-style linebreaks from various files - reverted their moving "audiocodec mad" in front of "audiocodec ffmp3" in codecs.conf The mplayer part contains some hunks that aren't just for arm optimizations (e.g. they put some stuff into demux_audio.c to detect a Xing mp3 header), so this shouldn't be applied blindly. LLaP bero
On Wed, May 25, 2005 at 04:43:23AM +0200, Bernhard Rosenkraenzer wrote:
while playing with some new hardware, I found it's running a forked mplayer -- and it looks like they're following the GPL.
Did anybody have a look at this? It contains several things that should be committed separately. I took the time to extract an extra slave command from the patch. osd_show_progbar <percent> displays the progress bar at <percent> percentage. It's tested to work, but I'm not sure the implementation couldn't be improved and/or how useful this is. Please review. Diego
On Mon, Jun 06, 2005 at 12:09:51AM +0200, Diego Biurrun wrote:
Did anybody have a look at this?
It contains several things that should be committed separately.
Among this is support for realtime scheduling, might be interesting. Diego
On Mon, Jun 06, 2005 at 12:12:00AM +0200, Diego Biurrun wrote:
On Mon, Jun 06, 2005 at 12:09:51AM +0200, Diego Biurrun wrote:
Did anybody have a look at this?
It contains several things that should be committed separately.
Among this is support for realtime scheduling, might be interesting.
Realtime does NOT belong in MPlayer. I know of several trivial ways to put MPlayer in an infinite loop, one of which is trying to seek past the end of any matroska file. Rich
Rich Felker wrote:
On Mon, Jun 06, 2005 at 12:12:00AM +0200, Diego Biurrun wrote:
On Mon, Jun 06, 2005 at 12:09:51AM +0200, Diego Biurrun wrote:
Did anybody have a look at this?
It contains several things that should be committed separately.
Among this is support for realtime scheduling, might be interesting.
Realtime does NOT belong in MPlayer. I know of several trivial ways to put MPlayer in an infinite loop, one of which is trying to seek past the end of any matroska file.
Um... are you sure about that? I tried to test this (for fun) on the only MKV file I have, and regardless of whether I seek with the arrow keys or by -ss, it does not hang but exits promptly. Am I missing something here? -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. A government exists to serve its citizens, not to control them.
On Mon, Jun 06, 2005 at 10:25:17AM -0400, The Wanderer wrote:
Rich Felker wrote:
On Mon, Jun 06, 2005 at 12:12:00AM +0200, Diego Biurrun wrote:
On Mon, Jun 06, 2005 at 12:09:51AM +0200, Diego Biurrun wrote:
Did anybody have a look at this?
It contains several things that should be committed separately.
Among this is support for realtime scheduling, might be interesting.
Realtime does NOT belong in MPlayer. I know of several trivial ways to put MPlayer in an infinite loop, one of which is trying to seek past the end of any matroska file.
Um... are you sure about that? I tried to test this (for fun) on the only MKV file I have, and regardless of whether I seek with the arrow keys or by -ss, it does not hang but exits promptly. Am I missing something here?
Try hitting pageup.. maybe it only happens if you seek a long distance past the end. BTW, seeking after switching audio streams with the # key also hangs MPlayer.. Rich
Rich Felker wrote:
On Mon, Jun 06, 2005 at 10:25:17AM -0400, The Wanderer wrote:
Rich Felker wrote:
Realtime does NOT belong in MPlayer. I know of several trivial ways to put MPlayer in an infinite loop, one of which is trying to seek past the end of any matroska file.
Um... are you sure about that? I tried to test this (for fun) on the only MKV file I have, and regardless of whether I seek with the arrow keys or by -ss, it does not hang but exits promptly. Am I missing something here?
Try hitting pageup.. maybe it only happens if you seek a long distance past the end.
Nope, closes just fine all the same. Also: I don't know if -ss seeking would also produce the effect you're talking about, but when I do -ss 7:00 or even 10:00 (the file being 5:55 long), there is likewise still no hang.
BTW, seeking after switching audio streams with the # key also hangs MPlayer..
The file I have contains only a single audio stream, so I don't think I can test that. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. A government exists to serve its citizens, not to control them.
On Mon, Jun 06, 2005 at 11:50:43AM -0400, The Wanderer wrote:
Rich Felker wrote:
On Mon, Jun 06, 2005 at 10:25:17AM -0400, The Wanderer wrote:
Rich Felker wrote:
Realtime does NOT belong in MPlayer. I know of several trivial ways to put MPlayer in an infinite loop, one of which is trying to seek past the end of any matroska file.
Um... are you sure about that? I tried to test this (for fun) on the only MKV file I have, and regardless of whether I seek with the arrow keys or by -ss, it does not hang but exits promptly. Am I missing something here?
Try hitting pageup.. maybe it only happens if you seek a long distance past the end.
Nope, closes just fine all the same. Also: I don't know if -ss seeking would also produce the effect you're talking about, but when I do -ss 7:00 or even 10:00 (the file being 5:55 long), there is likewise still no hang.
Fair enough. It exits after 15 seconds or so, after heavy disk thrashing. It's still a bug.
BTW, seeking after switching audio streams with the # key also hangs MPlayer..
The file I have contains only a single audio stream, so I don't think I can test that.
Further testing reveals: This happens on mpeg2 vob source (DVD), not MKV or OGM. Rich
Rich Felker wrote:
On Mon, Jun 06, 2005 at 11:50:43AM -0400, The Wanderer wrote:
Rich Felker wrote:
Try hitting pageup.. maybe it only happens if you seek a long distance past the end.
Nope, closes just fine all the same. Also: I don't know if -ss seeking would also produce the effect you're talking about, but when I do -ss 7:00 or even 10:00 (the file being 5:55 long), there is likewise still no hang.
Fair enough. It exits after 15 seconds or so, after heavy disk thrashing. It's still a bug.
For me, it takes ~1.5 seconds for seeking to one second past the end of the file, ~4 for seeking to 10:00 on that 5:55 file - and if I then play the file again immediately, there is no wait before exit. It does appear to be a disk-access issue, and yes, I'd probably call it a bug.
BTW, seeking after switching audio streams with the # key also hangs MPlayer..
The file I have contains only a single audio stream, so I don't think I can test that.
Further testing reveals: This happens on mpeg2 vob source (DVD), not MKV or OGM.
I haven't got a DVD drive (unless I manage to sponge off my brother's), so I'm not in any position to test that either. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. A government exists to serve its citizens, not to control them.
On Sun, Jun 05, 2005 at 07:04:03PM -0400, Rich Felker wrote:
On Mon, Jun 06, 2005 at 12:12:00AM +0200, Diego Biurrun wrote:
On Mon, Jun 06, 2005 at 12:09:51AM +0200, Diego Biurrun wrote:
Did anybody have a look at this?
It contains several things that should be committed separately.
Among this is support for realtime scheduling, might be interesting.
Realtime does NOT belong in MPlayer.
I only glanced at the code quickly, but I think it supports more scheduling classes than just realtime. BTW, we already have support for setting priorities for Windows. I don't think we should attempt to be cleverer than our users by preventing them from doing possibly dangerous things. Put a warning in the manual and be done with it. If they shoot themselves in the foot, oh well, we told them to be careful. Small anecdote: I used to have a Pentium 120 Notebook that was barely fast enough to play mono MP3 files without skipping. When I ran mpg123 as a realtime task I could play stereo files...
I know of several trivial ways to put MPlayer in an infinite loop, one of which is trying to seek past the end of any matroska file.
That's clearly a bug that needs to be fixed then. Report it to Moritz, he reacts rather promptly. Diego
Hi, On 5/25/05, Bernhard Rosenkraenzer <bero@arklinux.org> wrote:
Hi, while playing with some new hardware, I found it's running a forked mplayer -- and it looks like they're following the GPL.
The maintainer's page is here: http://atty.jp/?Zaurus/mplayer Unfortunately it's mostly in Japanese, so it's hard to figure out any details.
Their code looks quite interesting (at least to those of us w/ ARM CPUs).
I've seen that there has been some further optimizations added to this tree. Unfortunately, I didn't find a way to get the latest svn repo, so it's hard to create some patches. somehow, it seems to be possible to get smth through this command, but it's not an anonymous access...: svn checkout svn+ssh://atty.skr.jp/home/atty/svn/mplayer Cheers, Guillaume -- "Success consists of going from failure to failure without loss of enthusiasm." -- Winston Churchill
On Sunday, 28. May 2006 00:50, Guillaume POIRIER wrote:
I've seen that there has been some further optimizations added to this tree. Unfortunately, I didn't find a way to get the latest svn repo, so it's hard to create some patches.
There doesn't seem to be a way... But this is better than nothing: http://atty.skr.jp/WebSVN/listing.php?repname=mplayer-w100&path=%2F&sc=0
participants (5)
-
Bernhard Rosenkraenzer -
Diego Biurrun -
Guillaume POIRIER -
Rich Felker -
The Wanderer