especially on moving scenes, it is a lot more smoother. I would very much like to play the media on the samsung tele (through a usb or dlna) - maybe you can tell more about this, but i feel the same video file played through other methods lose quality. also I access the same files through many other players on mobile/ipad (but the roku playback probably is the closest comparison)Ģ. When I use a roku 3 (files are accessed through roku media player and via dlna), I am able to pause and fast forward - so I am guessing this is not about dlna.
#UNIVERSAL MEDIA SERVER FAST FORWARD TV#
When i copy the same files onto a usb drive and plug it to the tv directly, the same player works fine with all controls.ġ. This is regardless of the file type (mp4, mkv). I have a Mybook live NAS drive (uses Twonky), and when playing video files through dlna on my samsung smart tv (ue46f6500) I am not able to pause/rewind/fast forward. If the guy watching the second TV wanted to rewind he would have to shout out for the other guy to do it on his TV.I am wondering if anyone can help / share some knowledge on this scenario.
you can watch as normal on the first, fast forwarding and rewinding, but the second TV can't control what is playing on the first and just sees any seeking as part of the feed. It would be like having a camera pointing at a TV with it's feed going to another TV in a different room. Then could it be possible to make UMS kill and spawn those new sessions manually? If the renderer is acting like "stupid slave" it should work as it has no control anyway except play, pause and stop. The renderer then communicates directly with UMS with everything concerning the playback itself, and the remote control application is nothing more than a "remote control". The problem is that UMS would then need to do the transcoding itself, to be able to manipulate the stream on-the-fly.Ī UPnP remote control application won't make any difference, all it does is send commands to the renderer like "play this URL", "stop", "pause" etc. For those renderers that supports this, it would be possible to feed it whatever one wanted, and the renderer would only serve as a "stupid slave" which didn't try to make sense of time codes etc. With VBR this simply isn't viable, and any attempts at doing so will lead to very inconsistent behavior.ĭLNA actually has a "mode" where the server controls playback, and the renderer just consumes the stream. In the old days where things were CBR only, you could guesstimate the time position from the byte position by calculating a guesstimated total size for the transcoded stream. It is no problem to get renderers to make byte range requests though - the problem is that there's no way to serve those requests. The renderer is the one controlling playback, and thus it must have the real information.
But, even if it was, it wouldn't work, as the time stamps would become all wrong and "confuse" the renderer. There is no way that I know of to actually manipulate the output stream so that it "seeks" while the renderer is non-the-wiser. When seeking by time, what actually happens "under the hood" is that UMS constantly keep spawning new transcoding session from the new time position - while killing off the "old" process. The only thing UMS can do is start them and stop/kill them. Would one of those UPnP remote control apps work? If they connect to the server they might but as they most likely connect to the renderer using it's controls, probably There's no way to communicate with any of the transcoding engines in use during transcoding.
As long as there is constant data being received by the renderer it shouldn't know any different and just keep playing. If that communication cannot be made by the renderer there might be a way of emulating that signal on the computer in UMS to tell the transcoding engine to move to a different part of that file. If using seek by byte then the renderer can't work out how far to move as the file doesn't exist in its entirety so cannot make that request (or in the case of Movian it just restarts that file.) When a renderer uses seek by time there must be some communication between it and the server to request moving to a different time in that file. There must be some way of working round this issue. Also the last time I tried it, the web player can't either.
Unfortunately it's only downside is lack of seeking in transcoded files.
#UNIVERSAL MEDIA SERVER FAST FORWARD PS3#
Samsung TVs are known for not seeking wile transcoding, and while I use a PS3 I have it on custom firmware which allows me to use the superior Movian instead.
0 kommentar(er)
