huge mpegplayer speedup

[gnif]

I have been playing around with the mpegplayer code, and as a test, I commented out the vo_draw_frame call in the video thread in the hopes of seeing how big a bottleneck it is... i then compiled it and copied it to my G5 iPod Video... expecting to have no video output, but still see framerate... etc.

This is where it gets weird... there is still video out! and its FAST! I have turned off frame skipping, and frame limiting and the test video I am using is getting WAY ahead of the audio stream.

So, to double check what the hell is going on, I commented out all the code in "vo_draw_frame", and tried again... still got video output, and still fast!

I mean, What the hell?? Am I doing somthing wrong, or have I stumbled upon a useless call that isnt really doing anything other then slow it all down?

Oh, and where is the video getting outputted? is the buffer that its decoding into, actually mapped to the framebuffer?

[gnif]

I must be an idiot... I have been searching through all the mplayer source... and still cant find where it is outputting the video.

[linuxstb]

I can't explain what you're experiencing.

vo_draw_frame (implemented in video_out_rockbox.c) is the only function that renders the video on the LCD.

Maybe something has gone wrong with your compiling/installing?  Also, check if you have the "Limit FPS" option turned on.  If this is off, then (depending on the speed of your device relative to its LCD size) video may be decoded faster than realtime.

If you are 100% sure you've done what you say you've done, you could post a patch including your changes to the mpegplayer source so others can try and replicate it.

[misterpink]

You're not being an idiot. I get the exact same thing. Commented out the functions definition and where it gets called and recompiled. On my gigabeat it seems to run a lot faster when you have both options switched to off, but I can't say how fast as it seems to break the fps counter- it just keeps increasing, it's currently reading over 1000 fps.

Oddly the video just keeps looping, I've been through Elephants Dream twice now in next to no time. Actually, having not watched it before properly I'm not convinced that its not just playing the first buffer-full of data over and over.

Also seems to be not entirely reproducible. Restarted my gigabeat and tried it again and it played normally. Quit, played it again, and it played really fast. Did you have headphones plugged in? That seems to make some difference for me bizarrely...

[linuxstb]

Could either of you post a patch showing what you've done?

I've commented out the call in mpegplayer.c to vo_draw_frame() and as expected, I get no video displayed...

[misterpink]

Hmm. Well I made a patch but I don't see much point starting a flyspray to uploade it - it does exactly what you'd expect, there's no video. I made the patch from fresh svn source, but I thought I'd done exactly the same as before. I can't really tell what I've done differently this time :S Both tests were done on my gigabeat, only difference is that last time I used RoLo to run the firmware whereas this time I overwrote my normal firmware with it.

[linuxstb]

I wasn't suggesting to post the patch to flyspray - just attach it to this thread.

Also, afaik RoLo isn't implemented on the gigabeat.

[pabouk]

Hmm. Well I made a patch but I don't see much point starting a flyspray to uploade it - it does exactly what you'd expect, there's no video.

Could not the dependencies be set wrong in the Makefile? If you manage to get the speedup again try "make clean" and build Rockbox again to see whether the speedup persists or not.

[gnif]

to ensure that this wasnt a dependency issue, I did a make clean and re-compiled... still get video output.. and still runs faster.

I am absolutly certain I have commented out the correct line... there are two possibilities I can see.

1. The buffer being used to decode into is the framebuffer
2. Have we managed to somehow use the MPEG chip in the iPod Video by accident?

I am dumbfounded as to what the hell is going on... here are my build commands

Code: [Select]

tar -xvjf rockbox-bleeding.tar.bz2
  (Comment out line in mpegplayer.c)
mkdir build
cd build
../rockbox-bleeding/tools/configure
  (Select 22, and Normal Build)
make
make zip

I have used the rockbox tool to install the arm cross compiler

Code: [Select]

/usr/local/arm-elf/bin/arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.0.3/configure --target=arm-elf --prefix=/usr/local/arm-elf --enable-languages=c
Thread model: single
gcc version 4.0.3


[Llorean]

Again: Post a patch.

Essentially, "put up or shut up." People have tried reproducing what you say you've done, and cannot do it. So show us exactly what you've done. Better yet, post a copy of your build plus the patch so that developers with an iPod Video can try it firsthand and see this miraculous speedup.

I may sound very critical, but you're hypothesizing two somewhat ridiculous things, so I may as well speak frankly. Both of those ideas are silly. How would one "accidentally" do such a thing as using the video decoder?

[gnif]

Woah, no need to get upset mate... I am only trying to help, that was un-nessary.

Again: Post a patch.

Ok, no probs, but as said above... its the single and only line that is commented out. Will post it anyway.

Essentially, "put up or shut up." People have tried reproducing what you say you've done, and cannot do it.

there is one person that has reproduced it

Both of those ideas are silly

Well, if a memory address got screwed up its possible its writing to the framebuffer directly... but since I have only just started working with the rockbox source... and still learning the hardware, I realise this could be completly wrong.

How would one "accidentally" do such a thing as using the video decoder?

Again, I am not sure... since nobody knows how the video decoder works... who knows, it might be watching a certain area of memory for a valid mpeg type stream... not very likely i know, and a pretty dumb way of doing things, but again, who really knows?

[gnif]

Requested Diff:

Code: [Select]

--- mpegplayer.c        2007-04-10 11:49:24.000000000 +1000
+++ mpegplayer.c.old    2007-04-10 11:49:18.000000000 +1000
@@ -924,3 +924,3 @@ static void video_thread(void)
                 } else {
-                    //vo_draw_frame(info->display_fbuf->buf);
+                    vo_draw_frame(info->display_fbuf->buf);
                     skipcount = 0;


[Llorean]

You have the person who wrote the mpegplayer plugin saying he tried what you said you did, and it didn't work.

You have one person who claimed to do something impossible (make use of RoLo, which shouldn't be functioning, to swap Rockbox.gigabeat, which wouldn't affect mpegplayer performance since any changes to code in the mpegplayer folder wouldn't change the .gigabeat file) and have the same effect. Not a reliable source compared to the person who wrote the plugin you're playing with. He also would be on entirely different hardware that doesn't have a video decoder chip. Which rules out that possibility if he was reproducing it.

I'm not upset. I'm just incredibly skeptical. My assumption is that you've done something wrong, but since you aren't showing us evidence of this behaviour, and the only person who's "confirmed" it couldn't possibly have done what he's claimed to do (even if RoLo worked, he'd be using the same mpegplayer binary, and thus performance would not change between the two builds), you can see how I might be doubtful.

So, as I said, show us something that we can actually test, rather than making wild statements that are likely to get less technically knowledgeable forum members excited over something that seems very suspicious to me.

(And you'll note, I said post a build that exhibits this behaviour along with the patch)

Basically, unless something is rendering directly to the framebuffer, and happens to be rendering in the framebuffer format for some strange reason, neither of your explanations really make any sense.

I also note the diff is just of two files, the old and the new (which you got backwards). There are no other changes to any other aspect of your source, and you're 100% certain your overwriting the full Rockbox build when you extract?

[gnif]

make use of RoLo, which shouldn't be functioning, to swap Rockbox.gigabeat

Haha, didnt notice that... yeah, wouldnt have made a difference at all.

My assumption is that you've done something wrong

Thats why I am asking the question.... I am not sure of my code, and I am not saying that what I have done is correct.

and happens to be rendering in the framebuffer format

Thats what makes me question the theory of rendering directly to the framebuffer.

Whoops about the diff... a bit tired. I am absolutly 100% certain I am replacing the entire rockbox source since I removed the directory first before extrating (also removed the build directory).

fixed diff

Code: [Select]

--- mpegplayer.c.old    2007-04-10 11:49:18.000000000 +1000
+++ mpegplayer.c        2007-04-10 11:49:24.000000000 +1000
@@ -924,3 +924,3 @@ static void video_thread(void)
 Â                } else {
-                    vo_draw_frame(info->display_fbuf->buf);
+                    //vo_draw_frame(info->display_fbuf->buf);
 Â                    skipcount = 0;

I will upload a build, and source to my server... will post when its there

[gnif]

modified source:
http://www.spacevs.com/~gnif/rockbox-bleeding_mpegplayer_mod.tar.gz (11MB)

entire build directory (including rockbox.zip):
http://www.spacevs.com/~gnif/rockbox_ipod5g.tar.gz (8MB)

If there is any more info needed, let me know.

As I said, I dont understand what is going on... I have spent hours on this before posting to this forum, and only as a last resort. I am waiting for someone to say "you dumbass, you forgot this, there is nothing wrong" .