Problem transcoding when source file is h.265

[muzicman0 59]

4 minutes ago, cayars said:

Couple of things to clarify.  JRiver MC is nothing like Emby in functionality of decoding/changing/encoding (transcoding).  It doesn't do transcoding or streaming in any sense of what we consider streaming.  It does progressive downloads like we did 20 years ago.  It's a media center so the player running on a PC has the muscle to playback the different formats.  From this standpoint it's much closer to Emby Theater or Kodi in nature.  It can do some very limited transcoding of audio only for playing back audio on other devices.

The option "Allow subtitle extraction on the fly" doesn't apply because you aren't extracting the subs on the fly in your examples.

That is not actually true.  JRiver will stream a file just like Emby does (as I understnd it).  The last few major versions of JRiver will absolutely transcode video on the fly while streaming to a client, and I have used it many times to stream videos when I am out of town as well.  You just have to tell it to do that (which I did)...but even so, that wasn't the point of my post, and in no way am I claiming that the 2 applications are the same.  However, the point is that I set it to use Hardware Acceleration (Nvidia) on the decoding.  All this does is narrow down that the Nvidia card is likely not the problem since it handled the decode just fine.  It doesn't tell me anything more than that.  It could be FFMPEG (specific version), or something else that I don't even know about.  I'm not a newbie when it comes to video processing, but I'm also not an expert.  I do know more than the average user though.  

Point is that I am trying to narrow down where the problem is so that I am not just spinning my wheels to figure this out.  I also don't want to just throw money at the problem with no guarantee that it will fix the problem.

[Carlo 4330]

Seems like you already figured out the problem no?  Isn't it a problematic subtitle format in your files?  Have you tried download SRT subtitles for these files?

I haven't tried JRiver MC in a while so maybe they have changed this but they should definitely change their website and FAQ/wiki if this is the case as they say differently https://wiki.jriver.com/index.php/Media_Server#Automatic_File_Conversion.2FTranscoding

Automatic File Conversion/Transcoding

You can set Library Server to automatically convert some lossless file types (ape, wave) to mp3s to conserve bandwidth.

To enable, on the client go to Tools > Options > Library, check this option and then select the original file type in the drop down-menu. Some file types permit more advanced settings.

If transcoding is done, then you will not be able to seek in the track. Transcoding makes it harder or impossible to jump to random parts of the track.

The option must be set on the client, not on the server.

Library Server and Video

Some types of video files can be streamed, some can be streamed if you are willing to wait for the whole file to load first, and some cannot be streamed at all.

Files that are known to be streamable: .mov, .mpeg and .mpg. Files that will stream if you wait: avi, mp2 and wmv. Files that will not stream: DVD files.

 

[muzicman0 59]

No, there is some confusion...this has nothing to do with subtitles.  I think Luke though it might, but it doesn't seem to be related.  The problem is that when I am trying to watch h.265 encoded videos I sometimes have issues.  some files are worse than others.  the UHD disc rip from Solo always has a problem in the same place, however, if I set emby to software decoding instead of hardware accelerated decoding, then there is no issue...which at least implies that the problem lies with the Nvidia hardware decoding.  Not saying that as fact, just a logical assumption.  I installed a different Nvidia GPU (as a secondary GPU), and set Emby to use that instead, and had the same issue.  It was an older card but still supported h.265 (GTX 1050).  I have since pulled that card and reverted back to the GTX 1660.

Also - Yes, JRivers WIKI is severely out of date.  I have been transcoding video on JRiver since at least version 21, which is 4 years ago.  I recently stopped using them for my Home Theater when it became clear that they wouldn't/couldn't support things like ROKU or Nvidia Shields.  I held out for years.

Edited August 13, 2020 by muzicman0

[Carlo 4330]

I doubt it's an Nvidia GPU issue for general HVEC transcoding.  I say this based on the fact that most of my library is now all HEVC that I've encoded myself using software ffmpeg to encode.

In my Emby server which is an original i7 that didn't have QuickSync I put in an old GTX-750TI.  It supports HEVC decoding only but not encoding. It does support AVC encoding however so when a user tries to play back a movie on say a Roku 3 which has no HEVC support my Emby server has to transcode it.  It will decode the HEVC in HW and reenconde to AVC in HW as well and I never have issues with HEVC.  I also strip subtitles from my files and use external SRT if needed for the video so I avoid issues with HW having subtitle issues.

When I see HEVC issues it's normally a badly encoded file and garbage in = garbage out so to speak.  Not saying that's you case of course but I'm just stating what I see on my system.

Mind if we start over to make things clear?

Can you find an HEVC file you have issues with playing back?  Tell us the client and version used to play it.  Don't use subtitles so we avoid that discussion (until later if needed) and upload a picture of your Transcoding configuration page set to Advanced mode.

Then also upload a picture of the problem video file metadata which you can see as the admin by scrolling to the bottom of detail page for that video.

Play the file, then upload the server and ffmpeg logs.

This will put us all on the same page.

[muzicman0 59]

yes, I can do that.  I will get it done tonight after work, or over the weekend if needed.  The file that is consistent with issues is a UHD disc rip, but I will see if I can find a file that I encoded that has a consistent problem as well.  Shouldn't be too hard.  Here is an example of the CLI I currently use for FFMPEG when I transcode:

ffmpeg.exe -ss 00:00:10 -y -i "\\10.3.0.124\rtv\Marvel's-Agents-of-S.H.I.E.L.D\Marvel's-Agents-of-S.H.I.E.L.D..Brand-New-Day-S07E11.ts" -vf yadif=0:-1:0 -c:v hevc_nvenc -rc:v constqp -qp 23 -preset slow -rc-lookahead 32 -g 600 -c:a copy "T:\TV\Marvel's Agents of S.H.I.E.L.D\Season 07\Marvel's Agents of S.H.I.E.L.D. - S07E11 - Brand New Day.mp4"

 

[Carlo 4330]

Why are you seeking to 10 seconds before converting?  I'd try a problematic file not doing this as well just to make sure this isn't a self inflicted conversion issue.

[muzicman0 59]

9 minutes ago, cayars said:

Why are you seeking to 10 seconds before converting?  I'd try a problematic file not doing this as well just to make sure this isn't a self inflicted conversion issue.

the 10 seconds is because HDHomeRuns have a tendency to spit out corrupt data for the first few frames, which can cause AV sync issues with the transcoded file.  I fought it for a year before I discovered this, and I haven't had a AV sync issue since doing this.  I now use TVHeadend to record, and have it set to a 30 second tuner warm up (basically, it tunes and starts streaming the channel, but waits 30 seconds before start writing to disk) which was implemented to fix just this issue, but I have been too scared to test it out on my automation process, so I still cut out the first 10 seconds when I encode.

[Carlo 4330]

Understood, but you're getting further and further out the the Emby wheelhouse and what it's responsible for.  This is kind of a bandaid for a recording problem which means there are already problems in the file itself.

I can record in Emby from cable, OTA or IPTV and then have Emby do a conversion to HEVC and don't have issues with playback on any of the devices I use (TS or HEVC). AV sync issues are systematic of other problems in the recording.

I certainly not saying you're doing anything wrong, but your process makes this a bit more difficult to pin point the issue or underlying problem.

[muzicman0 59]

I would agree if I didn't see the problem with commercial disc rips as well.  I have done no processing on those files at all, just ripped using MakeMKV.

[Carlo 4330]

Let's start with using a disc rip first when looking at this if possible ok?  If it's the same problem/issue this just removes those other possible issues.  Again everything is in play but let's try to keep diagnoses as easy as possible with less outside factors clouding things.

Disc rips should be perfect for this.

[muzicman0 59]

sounds good.  I will get on this tonight if at all possible.

[muzicman0 59]

OK, to keep things simple, I am playing this in the web client, on the same PC that hosts the Emby server.  It is a i7-4790k with 16 GB RAM.  Just as an aside, the behavior I see is exactly the same playing on a remote Roku.

This is a rip of the movie Solo.  Subtitles are set to Off.

Requested screenshots are attached to this post.

[Carlo 4330]

Turn off Enable Throttle and try again.

[muzicman0 59]

49 minutes ago, cayars said:

Turn off Enable Throttle and try again.

That did not make a difference.  I do have a larger buffer set on my throttle if it makes a difference (~15 minutes of video), just so I can skip through commercials easier when I am away.

[Carlo 4330]

12 minutes ago, muzicman0 said:

That did not make a difference.  I do have a larger buffer set on my throttle if it makes a difference (~15 minutes of video), just so I can skip through commercials easier when I am away.

What do you mean by this?  How did you set that?

[muzicman0 59]

In the encoding.xml file.  I used:

<ThrottleBufferSize>880</ThrottleBufferSize>

Someone on the forum a while ago told me this was how to do it.  

[Luke 37095]

Well for starters i would remove that.

[Carlo 4330]

Maybe even turn off "Enable Throttling" just to eliminate that as a source of issue.

[muzicman0 59]

4 minutes ago, Luke said:

Well for starters i would remove that.

I can do that.  I also just played a different UHD disc rip to compare the logs.  I have attached the log here if you want to see it.

One thing that is different is that in the problomatic file, you get a ton of these:

 

16:44:44.980 [graph 0 input from stream 0:4 @ 000001d4a55539c0] Changing video frame properties on the fly is not supported by all filters.
16:44:45.051 [graph 0 input from stream 0:4 @ 000001d4a55539c0] filter context - w: 3840 h: 2160 fmt: 28, incoming frame - w: 1920 h: 1080 fmt: 28 pts_time: 116.741

 

but not in the new log.

 

I will remove that line from the .xml file and test.

ffmpeg-transcode-9ed3662c-9b40-4914-8032-061d77a992ba_1.txt

Edited August 14, 2020 by muzicman0

[muzicman0 59]

2 minutes ago, cayars said:

Maybe even turn off "Enable Throttling" just to eliminate that as a source of issue.

I did try it with throttling turned off like you requested above, and it did not make a difference (issue still happened).  

I would assume that would make the line in the xml file not matter, but regardless, I will remove and test.

[Carlo 4330]

21 minutes ago, muzicman0 said:

 

16:44:44.980 [graph 0 input from stream 0:4 @ 000001d4a55539c0] Changing video frame properties on the fly is not supported by all filters.
16:44:45.051 [graph 0 input from stream 0:4 @ 000001d4a55539c0] filter context - w: 3840 h: 2160 fmt: 28, incoming frame - w: 1920 h: 1080 fmt: 28 pts_time: 116.741

 

I just realized this is a UHD 4K video you're trying to transcode to an SDR color space.  That not going to happen on your hardware nor is Emby going to do that.

You realistically want to have a separate 4K library just for in home use or friends with fast internet connections that can direct play these.  Otherwise don't give access to the 4K material and have people play back the 1080p version you have in your normal library.

[Luke 37095]

Does this answer your question?

[muzicman0 59]

Not really, I still don't understand why if I use software decoding it works fine.  Also, I am fairly confident that the encodes that I do with FFMPEG are not HDR, so why do they have random problems.  

[Carlo 4330]

What did you mean by "if I use software decoding it works fine"?  How are you doing this?

 

[muzicman0 59]

If I disable HWAcceleration for h.265 decoding (IE: uncheck all boxes on the decoding settings for h.265 in Emby), then I have no issues.

Edited August 24, 2020 by muzicman0