ReMux Cache

[knicknak]

So an issue that I really dislike about PS3MediaServer's current implementation is that if you are playing a file that needs to be remuxed, you have a lousy ffwd and rwd experience.

Would the following implementation make sense?
- Add an option for ReMux caching (default could be off)

If turned on, when a file that is a simple remux is played (say an MKV that can be remuxed to M2TS) - it starts playing just like today (on the fly remux), however because the new option has been enabled, a second thread gets spawned to remux the entire file (in the background - lower priority than the on the fly remux). When the entire file has been remuxed, the media server switches over to reading out of the remuxed file instead of continuing to remux on the fly. At this point the user would have full ffwd and rwd available.

Use case: I watch a movie that is being remuxed on the fly, after 5 minutes or whatever the movie has been completely remuxed by the second thread. Now after a half hour of watching I see something that I want to rewind, so I hit rewind and like magic it does what I expect and desire (it rewinds).

When the user starts to play a new file, the cache gets cleaned up.

[shagrath]

Unfortunately if I go this way (let's call it the Tversity way), you will lose the ability to jump at any time you want. I much prefer the "jump to" feature than a regular rwd/fwd.

[knicknak]

Can you elaborate on that? Does jump not work when streaming a native format file?

i.e. if I am streaming a M2TS file vs a MKV file, I can jump in either one right - you don't lose the ability to do this when using a native format file do you?

[shagrath]

actually you are talking about a remuxing occuring on the disk (while the ps3ms remuxing/transcoding is done on memory), so it's a significant change. Besides, like I said, you will lose the ability to jump at the end of the file right after the beginning (because remuxing, even if it's fast, takes some minutes to complete)

[knicknak]

2 threads - one does stuff in memory as it does now - you lose no functionality. The second thread remuxes to disk in the background - when it is finished the threads merge and use the cached file.

If the second thread has not finished remuxing when the the user jumps - the primary thread would behave just like it does now - it would jump and remux on the fly in memory.

The real change in architecture would be firing off a second thread to remux to disk, and changing the primary thread's source when that second thread finishes.

[shagrath]

and also calculate with the remuxed file on disk, the precise matches between time position and file position (the ps3 asks for time ranges, not bytes one). I agree this is possible on paper but very hard to set up