PDA

View Full Version : FFWD and RWD on MVP recordings



pbj
2004-04-09, 06:07 PM
Sorry sub,

I've kind of lost the plot as to whether the FFDW and RWD should work for recordings on an MVP - nothing happends at the mo' (do I just need to be patient?).

Similarly skip seems to be exibiting strange behaviour. Each successfive skip seems to get larger (and the elasped time on the OSD seems to get a little confused). Eventually the MVP server crashes.

Don't mean to be demanding, just the software is so good the VCR doesn't exist anymore!

gplasky
2004-04-09, 06:48 PM
I'm pretty sure this might, sometimes, not really work on the MVP. This is being worked on but may not be ready by the next release. sub is aware of it. You can search the forums and find other posts about it.

Gerry

2004-04-10, 03:52 AM
I had the same problem twice today. The recording was made with GBPVR at the 1.8GB/hr setting. Just a few seconds into the playback, I pressed the Skip button. It did skip forward in the video but the OSD display said about 9 minutes. Then I pressed Skip again and the OSD said about 26 minutes into the video. Then I pressed Skip a third time and the client hung. No control at all. Could not even close the client from the PC. Had to use the task manager to kill the client.

sub
2004-04-10, 08:18 AM
I've been working FF/RW on the MVP today, and it'll be included in the next release.

------
For those that are interested, there are a few quirky things about the MVP support.

CURRENT PLAYBACK POSITION
The MVP just asks for bits of files (ie give me movie.mpg startpos:32400000 bytes:64000), in effect read chunks of an MPEG2 data file. It seems read ahead a few seconds worth of data. I cant actually tell what it is current playback position. To work out the playback position, I parse bits of the mpeg data that I am giving the MVP, looking for the last timestamp I can find - I then make guess that the current playback position is that minus three seconds. This is crude but generally not far off, but can take a few seconds to update when skipping (which looks confusing).

SKIP POSITION.
When I first start playing back a file, I parse the end of the file looking for the last timestamp (length in seconds). When the user selects to skip 60 seconds (from guessed position above), I divide the file length by the duration, then multiple by the new position in seconds. This gives me an approximate part of the file to move to. This also generally works, but can be a few seconds short or long. It works better for constant bitrate files than variable. I've got a better scheme in mind to find the exact location, but havn't had the time to implement yet.