mazey wrote:i think the buffered output is one of the most important features.
I respectfully disagree. IMHO the buffered output is one of the most overrated and overengineered features.
Since this is a rather bold statement coming from someone relatively new to the code like me, let me explain why.
Looking at it from a high level, why would PMS even bother to buffer output?
The client knows its own limitations best. You can bet that whatever player you are using, it will have some kind of buffering solution that makes sure you get the best playback experience. Having another buffer (like PMS) between the source and the destination will not improve playback.
Compare streaming; when PMS is streaming, it does so in 8192 byte chunks with no extra buffer code whatsoever. This works like a charm on every client, and we don't get complaints like streamed content missing the last few seconds or sound being garbled, nor is skipping or stuttering a problem or is streaming too slow (give or take the odd network problem). Your best experiences with PMS are from streamed content. If you would transcode files manually to another file, then stream the result using PMS, all problems would be gone.
PMS is very good at matching clients with what they can play, and transcoding source material based on that. Just examine the debug output and you'll be very happy that PMS takes all that hard work out of your hands.
PMS is also good at connecting to multiple clients and allowing them to browse the available media.
What PMS is not good at IMHO, is buffering transcoded data and sending it to a client.
I've been looking at the code for weeks now, trying to figure out what it is that makes it break. Or simply trying to understand what it wants to do and how.
This morning I woke up and it dawned upon me: "Why bother with buffering at all?"
If streaming a transcoded file works, then why not simply stream the piped content from the transcoder without any buffering or rewriting attempt whatsoever? Sure, the bytes will come in slower than if it were a file, but the client will probably just wait till its own buffer is filled and then play.
I'm probably oversimplifying here. Examine BufferedOutputFile and you'll see there is *a lot* of extra code to shift audio and video, compensate for WDTV etc.
Still, I am convinced that avoiding the use of BufferedOutputFile in OutputBufferConsumer or ProcessWrapperImpl (line 131) would solve a lot of the transcoding problems. It would probably solve more problems than the extra code currently fixes. And maybe the extra code could be piggybacked onto the new (almost) bufferless solution once that is proven to work.
Unfortunately my reasoning exceeds my coding skills.
I cannot figure out which OutputStream to couple the InputStream of the process to. Doh!
Is there some Java guru out there who is daring enough to attack this problem?