4K content is 'loading' in my local network

[vdatanet 1549]

14 hours ago, sooty234 said:

He's already told you that it plays with the different audio, and the screenshot shows picture breakup and not that it doesn't play. He's remuxing HDR HEVC media.... How do you guys still not understand this stuff? It's the same stupid remux issue that is now years old! The container that the server uses to remux this content into DOESN'T SUPPORT IT!

There is no way, I have requested a FR again claiming a solution for this (and other problems with the same root), and they have blocked the request.

Raise your hand who wants support for HLS fMP4 - Feature Requests - Emby Community

They are sure that it is a faulty ripping.

Edited April 27, 2021 by vdatanet

[Carlo 4330]

I'm not sure this is related to that in any way.  It is far more likely that the device is reporting audio types that can't be played back and it chokes playback. That would make sense if choosing a different audio track at the start if those playbacks don't have this issue.  To early to tell yet what the problem is but it could be a few things including the media itself.

fMP4 really isn't a "fix" for anything as we can already stream video and audio in many different formats. It's just a matter of knowing what format are properly supported.

Sure fMP4 can have additional functionality but that requires other changes in the server and clients before they would come to fruition. It's not like "hey we have fMP4" and now can do this other stuff right away. But as it's been said it's in the pipeline and work has already been done on it. But fMP4 isn't the only contain to think about using as there are others as well like DASH.

 

[Happy2Play 8325]

1 hour ago, cayars said:

I'm not sure this is related to that in any way.  It is far more likely that the device is reporting audio types that can't be played back and it chokes playback. That would make sense if choosing a different audio track at the start if those playbacks don't have this issue.  To early to tell yet what the problem is but it could be a few things including the media itself.

fMP4 really isn't a "fix" for anything as we can already stream video and audio in many different formats. It's just a matter of knowing what format are properly supported.

Sure fMP4 can have additional functionality but that requires other changes in the server and clients before they would come to fruition. It's not like "hey we have fMP4" and now can do this other stuff right away. But as it's been said it's in the pipeline and work has already been done on it. But fMP4 isn't the only contain to think about using as there are others as well like DASH.

 

Still back to if item does not Direct Play it requires Transcoding do to HLS breaking video stream.  As mentions in almost every 4K issue topic.

[Carlo 4330]

16 minutes ago, Happy2Play said:

Still back to if item does not Direct Play it requires Transcoding do to HLS breaking video stream.  As mentions in almost every 4K issue topic.

Yes I understand but in what way is fMP4 going to improve that.  Right now you still get the same codec for video and audio just a different container (if using fMP4).  If the current codecs can be used in the current container then it's not, or should not be a problem.

Absolutely correct me if I got anything wrong as I haven't programmed any of this stuff in a couple of years so it's just opinion on my part and I'll stand correctly surely if I'm wrong.

[vdatanet 1549]

5 minutes ago, cayars said:

Yes I understand but in what way is fMP4 going to improve that.  Right now you still get the same codec for video and audio just a different container (if using fMP4).  If the current codecs can be used in the current container then it's not, or should not be a problem.

Absolutely correct me if I got anything wrong as I haven't programmed any of this stuff in a couple of years so it's just opinion on my part and I'll stand correctly surely if I'm wrong.

Long time ago, Plex had the same problems, now in Android devices they use mkv fragments and in Apple devices fMP4, problem is gone away.

[Carlo 4330]

Yes but Plex had issues because they were writing codec formats that weren't supported by the containers they were using.  That's not the issue here.

Apples and Oranges

[vdatanet 1549]

4 minutes ago, cayars said:

Yes but Plex had issues because they were writing codec formats that weren't supported by the containers they were using.  That's not the issue here.

Apples and Oranges

[Carlo 4330]

What are you trying to convey?

BTW HEVC does not "require" using fMP4 so that is not true at all.
But for PLEX it is true.

[vdatanet 1549]

4 minutes ago, cayars said:

What are you trying to convey?

BTW HEVC does not "require" using fMP4 so that is not true at all.
But for PLEX it is true.

Yes, but Plex can direct stream or remux HEVC content to Apple TV and no problems are observed remuxing HEVC content. 

[Carlo 4330]

1 hour ago, vdatanet said:

Yes, but Plex can direct stream or remux HEVC content to Apple TV and no problems are observed remuxing HEVC content. 

But that relates to this thread how?

I do not discount transcoding to HEVC and want this myself just so you know.  It can save bandwidth and especially UPSTREAM bandwidth from the server so that can be a VERY GOOD thing (especially for those with data caps) but not sure it helps here and now with this issue.

[sooty234 266]

*facepalm* 

Not all hevc files are affected, and that's just chance. The difference of the issue between an HDR HEVC file and an SDR HEVC 10bit is less macro blocking, which is what you can see in the attached picture. It's macro blocking the most, because he's using an HDR HEVC video. I can replicate this, at will, on every device I have. Each player will exhibit it slightly differently, because they all have different demuxers. But the issue is ultimately the remuxed container not supporting the codec. This has been excessively shown....for several years. All you have to do to circumvent it, is is to play a supported audio track, then the server won't remux, and it will play correctly.

[Carlo 4330]

1 hour ago, sooty234 said:

*facepalm* 

Not all hevc files are affected, and that's just chance. The difference of the issue between an HDR HEVC file and an SDR HEVC 10bit is less macro blocking, which is what you can see in the attached picture. It's macro blocking the most, because he's using an HDR HEVC video. I can replicate this, at will, on every device I have. Each player will exhibit it slightly differently, because they all have different demuxers. But the issue is ultimately the remuxed container not supporting the codec. This has been excessively shown....for several years. All you have to do to circumvent it, is is to play a supported audio track, then the server won't remux, and it will play correctly.

Can you show us an example of what you are talking about that is used in Emby here in this thread?

Just so we are on the same page can you copy/paste the pic in question you are referring to with the macro blocking? The only pic I see that could fit this description could be cause by numerous things which haven't been identified yet.

What does the log file show as codecs being used and do they fit the transport being used?
In other words show us specifically what is wrong in this situation that a different transport would fix.

I'm not looking for a dispute or argument, just the facts or specifics of what you are saying that apply here.
We can investigate based on what you're saying if factual.

Edited April 27, 2021 by cayars

[sooty234 266]

I'm trying my best not to get all surly...but this has already been documented in probably a dozen threads. The earliest thread is probably this one, but I first brought it to light a long time before that. And nobody paid attention to my talking about it (I can't find that thread). It's been reported in Android section, the server section, the roku section and the apple tv section, and probably others that I haven't seen.

Seriously, I don't get paid for this. Go find them all. Most of them have screenshots. Maybe @Happy2Playcan collate them all? He's very good at tracking threads down. 

[vdatanet 1549]

8 hours ago, cayars said:

I do not discount transcoding to HEVC and want this myself just so you know.  It can save bandwidth and especially UPSTREAM bandwidth from the server so that can be a VERY GOOD thing (especially for those with data caps) but not sure it helps here and now with this issue.

I don't want to discuss the cause of the problem, as maybe I'm wrong. But the fact is, there is a problem when HEVC HDR content requires remux or direct streaming. It doesn't affect all content, I haven't been able to find the pattern, but a lot of HEVC HDR content shows green artifacts when remuxing or direct streaming. 

I don't know if it's the container, the demuxer or whatever, the fact that this has been a problem for years.

Nothing to do with transcoding using HEVC as target, I don't ask for that. I'm just talking about remuxing and direct streaming.

 

[XDavidT 13]

I saw a lot of discuss about that... Can someone tell me summary what should I do to fix the problem ?

[vdatanet 1549]

3 minutes ago, XDavidT said:

I saw a lot of discuss about that... Can someone tell me summary what should I do to fix the problem ?

At this time, the only workaround is avoid remuxing and direct streaming.

[XDavidT 13]

2 minutes ago, vdatanet said:

At this time, the only workaround is avoid remuxing and direct streaming.

How to avoid remuxing ? Is it something I can manage ?
What you mean avoid direct streaming ? streaming is direct, so, how to avoid that ? Is there any option to buffer before watching ?

[vdatanet 1549]

2 minutes ago, XDavidT said:

How to avoid remuxing ? Is it something I can manage ?
What you mean avoid direct streaming ? streaming is direct, so, how to avoid that ? Is there any option to buffer before watching ?

In this case, direct play is the only supported scenario

[XDavidT 13]

Just now, vdatanet said:

In this case, direct play is the only supported scenario

How I can configure it with emby ? or don't use emby ?

[vdatanet 1549]

5 minutes ago, XDavidT said:

How I can configure it with emby ? or don't use emby ?

Use a device that can direct play the content

Here are my options: HTPC, Nvidia Shield and Apple TV using Infuse

Edited April 28, 2021 by vdatanet

[Carlo 4330]

On 3/3/2021 at 2:52 PM, XDavidT said:

 

 ffmpeg-directstream-9c79b645-6822-48ab-aa7a-643c99e09151_1.txt 36.81 kB · 1 download ffmpeg-directstream-effffe8e-1fca-4c19-ad30-8222bdffb767_1.txt 68.63 kB · 0 downloads  

 

@softworkz I know 4.6 will handle these HDR files differently but why are we trying to deliver HEVC via segmented mpegts?
I thought this was changed a while back?

[XDavidT 13]

Hi Guys,

This issue is running a while, but since this days, I was change my stream speed from 'Auto' to '4k-40Mbps'. Last days I was trying to change back to 'Auto' and the movie still buffering while watching.. Is any solution coming ? an update for server ?

[rbjtech 4304]

In short - no.

The only way to watch 4K HDR content without transcoding issues is to Direct Play.

The only to Direct Play is to ensure your client can natively play the Video AND Audio codecs.

A Samsung TV with the latest Emby Client CAN Direct play a 4K Remux without an issue (in HDR) - but you must select AC3 as the Audio BEFORE you hit play.

I still don't understand why Emby cannot automatically select this as part of it's 'what's best' algorithm vs the transcoding or Direct Streaming option which obviously loses all HDR, poor quality and is totally unnecessary given a DirectPlay Audio track is available ...

 

Edited September 7, 2021 by rbjtech