Rockbox

looks nice, read docs/CONTRIBUTING... you have commented out debug splashes which should be removed, c++ style comments. and its not really a big deal, but function/variable names shhuold be consistant in a source file.. (i.e no CamelCase).
Also, CAPITAL LETTERS IN SPLASHES are not very nice.
also, you shouoldnt use lcd_puts*... you should use FOR_NB_SCREENS(i) {rb->screens[i]->puts*(); } which makes the plugin compatable with targets with more than 1 screens (lcd remotes, etc)

Thanks Jonathan for the tips: I've addressed each of them so now my code should be more clean and consistent with Rockbox practices. Please see attached .diff for the updated code.

$ patch -p0 < mpegplayer-resume.diff
missing header for unified diff at line 3 of patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- rockbox-bleeding\apps\plugins\mpegplayer\mpegplayer.c 2007-05-19 19:38
:22.000000000 -0400
|+++ cygwin\home\j\rockbox\apps\plugins\mpegplayer\mpegplayer.c 2007-06-09 17:05
:03.302509200 -0400
--------------------------
File to patch:
---------------------------------------------------------------------------------
... any suggestions,

Try this patch, it will work with -p0

I was having trouble patching this with VMware. All i did was change the directories and backslashes. Seemed to work for me.

Very useful patch, but unfortunately it seems to break audio playback on some of my clips (F40). There is only a short blip in the beginning. The video plays, button lights come on when pressed, but no reaction to the press. An example video is here: http://roolku.pwp.blueyonder.co.uk/bigad.zip I can't think how the playable clips differ from the unplayable ones. All encoded with mencode.

Robert:

Try this patch - I've successfully tested it with the file you provided in the link. All I needed to do was increase the size of the initial read buffer...

I think the files you are having trouble with (like this bigad.mpg) are encoded with audio at 160kbs, not 128kbs like I use for my files...

Please try this patch with all your videos and if any continue to cause problems, please include a link if at all possible.

Thanks for the quick reply. Your change did indeed fix it for the majority of clips in my collection. By increasing the buffer size further (to 128*1024) I can now play all my files apart from one. Since I don't know what impact the size increase has I didn't want to increase it further.

The attached patch has also two cosmetic changes:
- very small percentages were displayed as huge percentages (probably overflow in the division)
- the interactive prompt would use a buffered button (and not prompt as a result)

EDIT:

Okay, after some more experimentation I can confirm it is the bitrate - not so much the audio bitrate as it is only a fraction of the whole bitrate, but mainly the video bitrate. If one stays below 600 is seems to be okay. I have upped my buffersize to 256*1024 to be on the safe side now, although it is probably a waste of memory.

Sansa E200
Rockbox Revision: 13659
Video bit rate: 175
Audio bit rate: 128
Video Length is about 45 minutes.

Resume function says: "Resuming play back at n%", but starts video from beginning for a few seconds, then says "* End of Video *"

Robert:

The ideal solution would be for the mpegplayer plugin to first calculate all of the .mpeg specifications (video bitrate, audio bitrate, CBR/VBR, total running time, etc) - all of which would be useful. If we had the bitrate (or max bitrate for VBR), we could dynamically set that initial buffer to the correct size for each given video. I don't have a clue how to extract that info from an .mpg file, so I hope that some .mpeg expert can someday enhance the plugin in this regard.

I just rebuilt rockbox using both of the most recent patches (mpegplayer-resume.diff (10.9 KiB) and resume_video.patch (10.6 KiB)) and with both builds, I got the error of "Incompatible Version". I am not sure what is going on, but if I can provide more information using a log of some sorts, please let me know. Here is one file that did not work using the older version (pressing power to end the video locked up the player) and under the new version gives me that same message. This video was created using WinFF and the directions on rockbox.org.

http://lycoloco.thephlogiston.com/files/kylexy-samp.mpg

The error message suggests that your mpegplayer.rock and your rockbox.gigabeat are of different, incompatible version. Check the file date to confirm.

No idea about the second issue (lockup). File works fine here.

Yep, that was it. Thanks! Everything is working great now.

LycoLoco: I d/l'ed and tested the .mpeg in the link you provided (http://lycoloco.thephlogiston.com/files/kylexy-samp.mpg) and it played perfectly on my Gigabeat using the latest patch found a few posts back. Resume feature worked as well. I don't know what hardware you are running, but if this video still isn't working for you with the latest patch, please post more details about your platform.

Jim: That file wouldn't play with, I believe, the original file patch, and I got a few other friends (all three of us are using Gigabeat F40s), and when I tried to resume it would lock up the player so badly that it needed a flip of the battery switch. However with this most recent patch it plays wonderfully as well as works with resume. I guess it was related to the bitrate issue. Nothing to worry about anymore though, as everything is working well.

I tried the patch with the latest SVN and it didn't work (actually it gave me errors when applying the patch). So I did the patch manually and added support for iPod which wasn't working.

I've never sent a diff, I hope it was created properly.

ups, somehow a 0kB file it was uploaded. here it goes again.

Hi, I had posted this in the Sandisk Sansa e200 Rockbox forums at anythingbutipod.com, where I was advised to add a comment here.

"I've been using the Cpchan build with the mpeg-resume patch, and its been great mostly, since there's always some reason I have to stop my movie and come back to it later. I've used it successfully on a few different videos that were about an hour long or so. Today however, I was watching a video that was a little more than 2 hours long, and about 86% into it I had to stop it to do something else. Well when I came back to it, it let me resume back to where I was, and the audio played fine, but the video was extremely slow and lagged way behind. I tried messing with the FPS Limit and Frame Skip, and with those off the video was smooth, but way off sync, so I turned them back on, I'm sure they need to stay on. This is like the 4th mpeg I've watched on my Sansa with the resume patch, and definitely the longest, and its the first time I've had a problem with video playback. I started it from the beginning again, and it plays fine, and continues to play fine as long as I don't try to stop and resume it. I can also stop and resume just fine when I'm early into the video, it only happens late in the video.

I don't know if this is a known issue or not, so I just thought I'd let you guys know about it. I'm sure bugs like these will be worked out over time (and fast forwarding would be nice too). In the meantime I'll try to split long videos in half and see if that helps."

Ed: I don't have a Sansa (I have only gigabeats...) but if you email me a link where I can download the problematic .mpeg file I can at least try to determine if the issue is Sansa-specific or not. I don't see why the resume should work for this .mpeg early into the movie, but not later unless the byte location somehow is causing a variable to overflow. Can you tell me how large in bytes this .mpeg file is?

- Jim

Hey Jim, I had responded to your comment by replying to the email that I got when you made your comment. It was from "Rockbox" <bugs@rockbox.org>, so after thinking about it, I'm not sure if my response ever made it back to you. Here's what I had responded with...

"The mpeg file is a rip I made of Steve Vai: Live at Astoria, it is exactly 2:20:56 long, and 391 MB (410,374,144 bytes). I ripped it with DVD Shrink and then ran it through AutoGK to make an .avi, then WinFF to convert it to mpeg. I used the default settings for the Sansa e200 series, same as I've been doing for all the rips i've made so far. According to my player on my computer it is encoded at 29.97 fps, which is probably too much for the Sansa because they all do skip a little (I read that 15 fps is about the most it can handle), but I didn't have this problem resuming with any other mpegs. Watching back through the file on my computer, I'd say I quit it and tried to resume it at about the 2 hour mark, which should be right because it tried to resume at 86%. Once I tried to resume it, the problem started, the video was running at maybe 2 or 3 frames per second, but the audio kept playing as normal. I rebooted my Sansa, and tried to resume several times, and it kept doing the same thing. I restarted the video from the beginning and let it play for about 15 minutes before I tried to test it again, and resuming worked no problem then. Strange problem?

I hope this info helps pinpoint the problem. I don't know how many other people are watching 2hr 20min videos on their mp3 players, but its bound to happen again to somebody. I'll let the video play again for 2 hours and try to resume again, maybe it was just an isolated incident. I have a question about the resume patch though, when you leave a video early it adds that resume file to the video folder. I opened one of them up and it just had some numbers in it, I didn't know what they meant. Is there any way to edit the resume file to resume somewhere far into a video without having to watch that far? If its done by byte location, how can I know how many bites equal how many minutes?

Thanks for looking into this."

Can somebody please sync it to the latest SVN? It keeps failing on 3 of the hunks and then breaks the compile.

I've (mostly) synced the patch to today's svn. There's still a lot of fuzziness, but it patches cleanly and builds properly. Resume works on elephantsdream.

7487
Gentlemen, we have been working on a means to seek within a movie for sometime now; prior to the start of this patch posting. We have now reached a point where we can post what we have done. There is some overlap in functionality with this resume patch in addition to having more features. The patch we posted includes additional features such as thumbnail preview and movie time seek as well as a ressume feature. This new post has a patch id number 7487. We did not intend to redo other peoples efforts, but we think our approach has a number of advantages. Please, consider it.

Synced and updated (seems that the added line for the 1st, 2nd, and 3rd gen iPods made it not patch cleanly). Tested on Elephant's Dream.