Cannot play h.264 content on Samsung Q60 2020

[Nadahar]

@SubJunk My "suspicion" is https://github.com/UniversalMediaServer ... r/pull/961

It seems to have broken a lot of things, including subtitles for many (most?) users.

[mik_s]

I looked at the logs just now and the MIME type is actually video/mpeg:

<res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" bitrate="2060594" colorDepth="8" duration="2:18:32.972" nrAudioChannels="6" protocolInfo="http-get:*:video/mpeg:DLNA.ORG_PN=AVC_TS_HD_24_AC3_ISO;DLNA.ORG_OP=11" resolution="1920x816" sampleFrequency="48000">http://192.168.0.73:5001/get/688/Wir+wa ... to.ts</res>

ah that makes sense, i was assuming

Code: Select all

Final verdict: "file.mkv" will be transcoded with player "FFmpeg Video" with mime type "video/x-matroska"

meant that the mime sent to the renderer would be "video/x-matroska"

but that is only what is being sent to FFmpeg, UMS would send the correct mime for the transcoded file to the renderer.
I didn't know where to look for what is being sent.

As for when there seems to be a contradiction when UMS matches the MKV line but then transcodes it anyway because one of other audio tracks fails to match, I think UMS is being a bit too strict with the matching. Technically it doesn't 100% match the supported format but shouldn't be transcoded as the first audio track is valid, and since when transcoding only the 1st audio track is used you would lose the unsupported one anyway. The same would also apply to unsupported subtitle formats.

[mik_s]

@Cochrane
From what I see UMS is correctly matching the files that need transcoding, just that your TV has problems playing the transcoded file for some reason

Does the file "Im Erlebnisstudio - Mia's 4. Geburtstagsparty.mp4" play ok? according to your log that is the only file that matches, being MP4/AAC so should be streamed.

[Nadahar]

@mik_s Even though the (almost) correct MIME type is being sent, there are some fresh bugs here. The way you interpreted it used to be correct, and it makes no sense as it is now. No MIME type is sent to FFmpeg, FFmpeg has a much more advanced media probing and analysis itself so you don't need to "tell" FFmpeg what the source is.

So, even if the sent MIME type isn't the issue, something isn't right here...

[SubJunk]

Hi everyone,

first of all let me tell you that I greatly appreciate the effort everyone is putting into this.

I tried SubJunk's config with the current build 9.5.0, behaviour of my renderer didn´t change. Playback of most videos was still impossible, see attached ums_dbg_03 for results.

After that, I uninstalled UMS and installed build 9.0.0 since Nadahar mentioned the bug ocurred with 9.1.0. With the same config file, I could reproduce the exact same problems - see ums_dbg_04 for results.

Should I try an UMS build 8.x or lower?

It's always helpful to pinpoint when a bug was introduced, so if you have the patience for it that would be very useful. Usually I try to fix a bug without that but sometimes we get head-scratchers like this. In the meantime I will look through the logs for more clues.

@SubJunk My "suspicion" is https://github.com/UniversalMediaServer ... r/pull/961

It seems to have broken a lot of things, including subtitles for many (most?) users.

Yes we have had a lot of problems with that one and we have confirmed bugs with it. Valib is working with a user right now to fix them so hopefully we will get some traction on that.

I looked at the logs just now and the MIME type is actually video/mpeg:

<res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" bitrate="2060594" colorDepth="8" duration="2:18:32.972" nrAudioChannels="6" protocolInfo="http-get:*:video/mpeg:DLNA.ORG_PN=AVC_TS_HD_24_AC3_ISO;DLNA.ORG_OP=11" resolution="1920x816" sampleFrequency="48000">http://192.168.0.73:5001/get/688/Wir+wa ... to.ts</res>

ah that makes sense, i was assuming

Code: Select all

Final verdict: "file.mkv" will be transcoded with player "FFmpeg Video" with mime type "video/x-matroska"

meant that the mime sent to the renderer would be "video/x-matroska"

but that is only what is being sent to FFmpeg, UMS would send the correct mime for the transcoded file to the renderer.
I didn't know where to look for what is being sent.

As for when there seems to be a contradiction when UMS matches the MKV line but then transcodes it anyway because one of other audio tracks fails to match, I think UMS is being a bit too strict with the matching. Technically it doesn't 100% match the supported format but shouldn't be transcoded as the first audio track is valid, and since when transcoding only the 1st audio track is used you would lose the unsupported one anyway. The same would also apply to unsupported subtitle formats.

Yes you're right and we have discussed making that change before. It's hard to know if that will cause problems though because maybe some devices will fail if an unsupported format is contained in a video, even if that's not the one they will play? It's hard to know, but I think you might be right that it would be a good change to make. The behaviour I've seen on my devices is that they will pick up the streams they support, and ignore the ones they don't support. Are you on our GitHub tracker? If you are, maybe you can make a new issue for that suggestion?

[Nadahar]

I'm pretty much sure you will find both behaviors if you look hard enough: Both renderers that ignores tracks they don't understand, and renderers that rejects the whole media if there's an unsupported track in it. My guess is that some users will "suffer" either way, so that the only way to please everyone is to make both behaviors possible.

[mik_s]

Yes you're right and we have discussed making that change before. It's hard to know if that will cause problems though because maybe some devices will fail if an unsupported format is contained in a video, even if that's not the one they will play? It's hard to know, but I think you might be right that it would be a good change to make. The behaviour I've seen on my devices is that they will pick up the streams they support, and ignore the ones they don't support. Are you on our GitHub tracker? If you are, maybe you can make a new issue for that suggestion?

Maybe you could have an option in the config whether to have strict matching for some renders, and a more loose match for others as default.

Not on GitHub as no idea how to use it. Was thinking of trying to do something with the GUI to do configs though but no idea on how to get started. My programming is very limited, used to do some BASIC as a kid and did of PHP years ago to make a website for a friend


another interesting thing is on https://www.universalmediaserver.com/fo ... 815#p41815 with a comparison between 9.1 and 9.5 with the same file
9.5 has fixed some things but the mime type is changed

[SubJunk]

Yes we could have an option in the renderer config for it, it's a good idea, but we will still need to decide on a good default because most people won't care enough to specify that new config option to improve their renderer support, there are just so many options already so that's a big investment of time for a user just to avoid transcoding.
I suspect that a good default would be to do the new behaviour - pass the file through if one of the audio streams is supported. Then that can be disabled in the renderer config to make it do what it currently does.
It will be a bit complex when we take into account the language preferences, but the existing logic should mostly cover that, we will just need to remember to respect that so that if a user wants only Spanish audio, and their file has English AC3 and Spanish DTS, but the renderer supports AC3 but not DTS, then we should still transcode even though a supported audio format exists.

[SubJunk]

Not on GitHub as no idea how to use it. Was thinking of trying to do something with the GUI to do configs though but no idea on how to get started. My programming is very limited, used to do some BASIC as a kid and did of PHP years ago to make a website for a friend

GitHub is where the UMS developers attempt to stay organised with what we are and should be working on. Issues are just like forum threads, but they have the ability to tie together with code when they get worked on so it is convenient. We get users creating issues on there just like they do here on the forum so there is some duplicate functionality there. So you don't need to know any programming to be familiar with our GitHub and I invite you to join us on there if you want You might find it interesting to see what we are doing and be able to influence/comment on there. Just an idea
For example I am currently working on https://github.com/UniversalMediaServer ... ssues/2088

another interesting thing is on https://www.universalmediaserver.com/fo ... 815#p41815 with a comparison between 9.1 and 9.5 with the same file
9.5 has fixed some things but the mime type is changed

I'll be interested to see how that develops, and to see if there are any PS4 config improvements we can bring into the program.

[mik_s]

GitHub is where the UMS developers attempt to stay organised with what we are and should be working on. Issues are just like forum threads, but they have the ability to tie together with code when they get worked on so it is convenient. We get users creating issues on there just like they do here on the forum so there is some duplicate functionality there. So you don't need to know any programming to be familiar with our GitHub and I invite you to join us on there if you want You might find it interesting to see what we are doing and be able to influence/comment on there. Just an idea
For example I am currently working on https://github.com/UniversalMediaServer ... ssues/2088

I've had a snoop every now and again but I think I'll look into it a bit more and see if I can make any contributions. Is there a guide on how to use GitHub and setup a programming environment? (I know there might be one on here somewhere but I'm lazy and want to get back to my game )

I hadn't seen the se: and si: before, so that issue explains that they are new but not working correctly. That was one of the original problems with this config.

@Cochrane, Sorry we have taken over your thread a bit