Jump to content

4K MKVs from Shield to LG TV - Recode: DTS to FLAC buffers, but PCM works fine.


Recommended Posts

Posted

My LG OLED G2 TV doesn't passthrough DTS format audio, so using XMedia Recode, I recoded all DTS MKV files to FLAC. This works fine for 1080P with FLAC, but for 4K with FLAC I get buffering every few minutes on all files; typically when there are significant changes in the video. There are no issues on PC Emby Clients and 4K with TrueHD is fine.

I then recoded the same 4K DTS MKVs with PCM format audio and these now play perfectly from Shield to LG TV with no buffering.

Is it possible the Shield processor is struggling to process both 4K video and decompress FLAC format audio? PCM is uncompressed, so perhaps there is less work for the Shield.

I store MKVs on my local network over 1Gb; Emby Server running on a Windows 10 machine and Emby Client on nvidia Shield, PC's and iOS devices.

PCM takes up a lot of space, but it works.

Either this will be helpful for others with Shields and TVs that don't pass through specific audio formats, or maybe others have manged to get 4K with FLAC to work?

Posted

Ok, I've not produced a log from Emby before. I'll try this evening and report back.
I might also try different FLAC settings.

  • Thanks 1
rbjtech
Posted (edited)

Are you using the TV for actual sound output - or just passing through with an AVR providing the sound ?

If using the TV, then you are unlikely to even notice the difference between DTS/DTS-HD and a conversion to a decent bitrate EAC3.

If passing through to an AVR (which does support DTS), then simply change the HDMI setup - and use the Shield as the Audio Source and passthrough the Video to the TV.     That way, it doesn't matter what your TV supports audio wise, as it doesn't have to pass it through anyway.  ie it does not need use EARC/ARC

Edited by rbjtech
visproduction
Posted (edited)
4 hours ago, ARNiTECT said:

 I get buffering every few minutes on all files; typically when there are significant changes in the video.

VBR (variable) encoding can cause a change in demand on an encoder with heavy screen action.  CBR (Contstant bit rate) encoded does not increase encoder demand in heavy scenes.  VBR is avoided online by social media sites, but many users have VBR set in the encoder to keep the file size down.  Try a similar sized demo media with CBR encoded and see if the stuttering is fixed.

I never use VBR for this reason.

Edited by visproduction
Posted

I'm just passing through:
Shield > TV eARC > AVR
AVR supports DTS-HD / TrueHD
TV does not passthrough DTS/DTS-HD, but does pass through: Dolby TrueHD, Atmos, DD+, FLAC, PCM etc.

I previously split the HDMI output from the Shield to both TV and AVR and this worked fine with all audio formats (the TV would report 'audio not supported' for DTS), but this setup required splitters and switches and resulted in other issues in use, making the system too family unfriendly. The AVR only has one HDMI input, and has other limitations with passing through video to TV; so Shield to TV directly is preferred. We predominantly use the streaming apps on the TV and these don't use DTS.

It appears only FLAC with 4K is affected by buffering issues.

I'm ok with recoding to FLAC for 1080p and PCM for 4K, but would prefer the smaller file sizes of FLAC if possible (8-12GB extra per film).

Posted

Thanks, I'll try to find CBR settings for FLAC in XMedia Recode.

Posted

Let us know how you get on. Thanks.

Posted
1 hour ago, ARNiTECT said:

I'm just passing through:
Shield > TV eARC > AVR
AVR supports DTS-HD / TrueHD
TV does not passthrough DTS/DTS-HD, but does pass through: Dolby TrueHD, Atmos, DD+, FLAC, PCM etc.

I previously split the HDMI output from the Shield to both TV and AVR and this worked fine with all audio formats (the TV would report 'audio not supported' for DTS), but this setup required splitters and switches and resulted in other issues in use, making the system too family unfriendly. The AVR only has one HDMI input, and has other limitations with passing through video to TV; so Shield to TV directly is preferred. We predominantly use the streaming apps on the TV and these don't use DTS.

It appears only FLAC with 4K is affected by buffering issues.

I'm ok with recoding to FLAC for 1080p and PCM for 4K, but would prefer the smaller file sizes of FLAC if possible (8-12GB extra per film).

Why not go Shield->AVR->TV?

That will support all your audio.

Posted
1 hour ago, ebr said:

Why not go Shield->AVR->TV?

That will support all your audio.

Its not a standard AVR
TV > eARC-HDMI adapter > Cambridge Audio CXUHD > HDMI-eARC adapter > miniDSP Flex HT > Power amps
complicated, and as I mentioned, 'not family friendly' but sounds great.

visproduction
Posted

Arn,

On a side note, since you like quality surround,  I ran into a surprise method to playback content via a quality blu-ray player.  I was using a higher end Panasonic 8500 with 7.1 RCA out in back.  To my surprise, not only does a normal blu-ray work, for audio out either to digital HDMI or RCA to older amps,  it also plays surround sound from a single .mkv file h.265.  So, if you really want to show a particular film and something is not quite right with your AVR audio adapters, try burning the mkv file to a data blu-ray and playback through a blu-ray player, if you have one.  I would never have guessed this would work, but stumbled across it.

yocker
Posted

What does the shield report that it can pass through?
You can find this info in the display and audio settings on the shield it self.

rbjtech
Posted
15 hours ago, ARNiTECT said:

I'm just passing through:
Shield > TV eARC > AVR
AVR supports DTS-HD / TrueHD
TV does not passthrough DTS/DTS-HD, but does pass through: Dolby TrueHD, Atmos, DD+, FLAC, PCM etc.

I previously split the HDMI output from the Shield to both TV and AVR and this worked fine with all audio formats (the TV would report 'audio not supported' for DTS), but this setup required splitters and switches and resulted in other issues in use, making the system too family unfriendly. The AVR only has one HDMI input, and has other limitations with passing through video to TV; so Shield to TV directly is preferred. We predominantly use the streaming apps on the TV and these don't use DTS.

It appears only FLAC with 4K is affected by buffering issues.

I'm ok with recoding to FLAC for 1080p and PCM for 4K, but would prefer the smaller file sizes of FLAC if possible (8-12GB extra per film).

ok - understood.

19 hours ago, ARNiTECT said:

This works fine for 1080P with FLAC, but for 4K with FLAC I get buffering every few minutes on all files; typically when there are significant changes in the video.

Going back to the original problem - this sounds like a network or I/O problem rather than a limitation on the Shield.   If you encountered the audio stuttering immediately, then I would say the decoding of the flac + the high video bandwidth of the 4K remux (presumambly) is too much for the shield cpu - but why does it only happen  every few minutes or when there is a large bitrate change ?

I'm unsure if your emby server has local storage or uses a NAS - but if using a NAS - as an experiment, I would copy a problematic file LOCAL on the Emby Server itself.   Create a test library and point to that local file.    If that plays back without issue, then it's related to the file transport over your network - or as I have suspected for some time, the http streaming of the emby server is struggling.

I'm fortunate enough to still be able to use direct SMB via my Shield (using the ATV App), thus I don't use any http 'streaming' - the file is directly accessed for playback (the same as VLC or Kodi etc) - thus playback of multiple high bitrate 4K Remux's on different devices are not an issue.

Posted
2 hours ago, rbjtech said:

ok - understood.

Going back to the original problem - this sounds like a network or I/O problem rather than a limitation on the Shield.   If you encountered the audio stuttering immediately, then I would say the decoding of the flac + the high video bandwidth of the 4K remux (presumambly) is too much for the shield cpu - but why does it only happen  every few minutes or when there is a large bitrate change ?

I'm unsure if your emby server has local storage or uses a NAS - but if using a NAS - as an experiment, I would copy a problematic file LOCAL on the Emby Server itself.   Create a test library and point to that local file.    If that plays back without issue, then it's related to the file transport over your network - or as I have suspected for some time, the http streaming of the emby server is struggling.

I'm fortunate enough to still be able to use direct SMB via my Shield (using the ATV App), thus I don't use any http 'streaming' - the file is directly accessed for playback (the same as VLC or Kodi etc) - thus playback of multiple high bitrate 4K Remux's on different devices are not an issue.

Thanks for sharing your ideas on working through this issue.

I had assumed that as there are no issues with the significantly larger PCM files, or the original smaller DTS/Dolby audio, that it would be something other than network.

I have remuxed a 4K file with original DTS, PCM and a few FLAC formats with a range of compression level: 12,10,8,6,5,4,2,0 and I'll go through these later this evening. There are no options for CBR; I understand FLAC is always VBR; perhaps the lower compression levels are effectively CBR.

My server presents SMB shares from a zfs raid of spinning hard drives, which gets 200-300MB/s, but to the shield limited to ~100MB/s. The Emby server is on a Windows 10 virtual machine on the same server, but the VM is stored on an NVMe based zfs raid. I currently don't have the room for a single 4K file on this VM without adjusting the VM resources and then restoring them after, I'll have a think about this. There is a small 5-port switch in the AV rack, which connects both the Shield and a PC to a single 1Gbe socket to a larger switch to the server. The PC is not on when the Shield is playing.

What do you mean by direct SMB using the ATV app (AndroidTV?) I just use the standard nvidia shield Emby client connected to the Emby server. I assumed the Emby server just sets up the connection, but the file transfer is then direct from source to client and not via the Emby server?

rbjtech
Posted
29 minutes ago, ARNiTECT said:

What do you mean by direct SMB using the ATV app (AndroidTV?) I just use the standard nvidia shield Emby client connected to the Emby server. I assumed the Emby server just sets up the connection, but the file transfer is then direct from source to client and not via the Emby server?

The file is 'streamed' via http 'via' the emby server - the shield with the normal Emby client does not directly connect to the file share.

zfs > smb > Emby Server < http < shield

This is the data flow.

Ideally (as you thought it did and the 'old' AndroidTV App did (and still does if you don't upgrade it..) is

zfs < smb < shield

For high bandwith files - clearly going directly is better and more scalable.

I would load VLC onto the Shield, directly connect to the nas and see if the file plays back ok.  If it does, then you have eliminated your infra (incl the Shield) as the problem.

Posted

Thanks,

I'll try and get VLC working on the shield

Posted

It took me a while to get VLC to see the files, as it didn't seem to like accessing my NAS using domain based credentials.

When testing a 4K file with FLAC in VLC on the Shield, the video stuttered randomly every few seconds and even worse than with Emby. With PCM there was minor stuttering, and with TrueHD it played smooth. I tested FLAC compression levels 0-12, but no difference. Not sure if I need to play around with the settings in VLC. I also noticed VLC swapped the channels around (centre to surround left for example), but Emby channels are ok.

VLC on my PC plays smooth with everything, VLC on my phone over wifi stutters with everything.

  • Like 1
rbjtech
Posted

Hmm ok - so if VLC is having issues, then I'm back to suspecting the transport.

Have you tried connecting the Shield directly to the main switch uplink to eliminate the AV switch ?

It's possible the piggyback switch is causing packet or timing issues.   Are the switches managed - can you get any error stats from them ?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...