Universal Media Server | Forum

Hi guys! First time poster here, been using UMS since early versions of PS Mediaserver.

I stream material from my Mac to the PS4 with a 2-3 second startup time for files in H264 format. Works flawlessly, can pause rewind fast forward very smooth perfect quality presumably due to that format being streamed without need for transcoding..

X264 is a different story. Takes about a minute or so of the little shapes before crapping out "File format not supported" or some similar message. But then if I try again after about 5-6 seconds it actually works. And for the next minute or so I can pause, rewind, FF. But after a few minutes if I do pause there is a strong chance it will not resume and I need to start the process over.

Could not reproduce that but another similarly irritating behavior is whenever I paused and then unpause I get the same error. It will sometimes resume playback at the same point after a while or, as was the case here, playback for a few seconds before crapping and throwing me back to the beginning. I have attached the log file for this behaviour to the message.

Driving me nuts as it is a completely illogical and inconsistent error. UMS is a default installation. Any thoughts? Thanks!

There is some confusion here. H.264 aka AVC is a video codec. x264 is an open-source video encoder that encodes H.264.

Given this, most of what you're saying doesn't make much sense. Clearly the difference between the files is something else...

That said, it sounds like you're describing the difference between streaming the file as-is and transcoding before streaming. There are multiple bugs in UMS related to pause and resume, which I think only affects transcoding.

Your log hasn't been generated as per the above instructions, so it's quite useless. It does hint to multiple issues though, and the problem might be related to MKVs, not "x264".

Thanks for replying and indeed, the files are in MKV format. What is frustrating is that the same file that does not work initially suddenly works second time around.

That might happen if it has embedded subtitles that must be extracted before transcoding can begin - and the renderer times out in the meanwhile. For some reason unknown to me, this is somehow cached somewhere so that it often goes much faster the second time and thus doesn't time out. FFmpeg is known to do this, while MEncoder start playback immediately.

Yes Nadahar is correct. The MEncoder subtitles rendering is much better than FFmpeg because FFmpeg needs to parse the entire file before it spits any video out, while MEncoder can read it in chunks. I had a request on the FFmpeg tracker years ago but it doesn't seem to get any attention. They are just like us - they are open source and rely on people donating their development time, so we need to wait for someone to want to prioritize that, which doesn't seem likely.
It does seem to go faster the second time, it might be the fontconfig cache or it might just be that the hard drive is already spun to that position, I guess it might be documented somewhere or we could test with an SSD

OK thanks for this guys so I will force rendering on Mencoder and let you know what happens.

I have subtitles disabled by the way.

Hi guys thanks a lot for your help! I have noticed a big improvement and definitely something to do with the subtitles.

I don't need subtitles at all so always have them disabled under Common Transcode Settings.

Now I have completely disabled Mencoder under Video Files Engines and under FFmpeg video I disabled the "Defer to MEncoder when transcoding problematic subtitles"

And so far I get a more stable result. Have only the most occasional crap outs after very long pauses but generally resumes without any further problems.

Thanks again for pointing me in the right direction, much appreciated.