All we can see from your logs is that the hardware video decoder stops sending video frames all of a sudden. We have no other visibility into how nvidia's code for decoding works.
If I initiate a stream via the FNC Android app, should I expect the same behavior where the hardware video decoder stops sending video frames?
My goal is to help improve Channels and if you tell me there's nothing that can be done to resolve the issue when using the hardware decoder, I'll use the software decoder. If this is something you feel like chasing, I'm open to continue testing.
It's best if you use the Software decoder. That's why that option is there, because some TV feeds cause bugs in the nvidia decoder. Debugging further is not useful because we have no way to make improvements to the hardware decoder.
Okay. If I am watching a recording of a stream that causes issues during a live feed, would that also cause the same bug with the hardware decoder?
Don't know without the logs. I'm just stating what I saw in your logs earlier when you said it was stalled during playback.
@jpblanch75 Are you sure the beta build has a problem, or did the problem just go away because you deleted and reinstalled the app?
I've uploaded a new beta which lets you choose Software decoding on Sony TVs. However I'm pretty sure the Sony TV CPU is too slow for that to work reliably.
Also in your DVR logs I'm seeing lots of random network errors that no one else's logs are showing:
dial tcp: i/o timeout
dial tcp: lookup data.tmsapi.com: No address associated with hostname
502 Bad Gateway
read tcp [2604:6000:1518:4008:5dec:9b4f:4782:9153]:39546->[2600:1f16:e2:8105:356d:89c4:6d72:54ec]:443: read: software caused connection abort
context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Many of these seem to match up with when you're losing video. I'm also seeing the same thing in your client logs.. the video player stops receiving any audio/video data over the network.
I'd recommend turning off ipv6 on your network and also making sure you're using a reliable DNS server. If you're running pihole or some other dns filter, try turning that off for now.
2 Likes
I deleted and reinstalled the beta multiple times before I deleted and stopped the beta. I will say now that I have been streaming for 4 hours since then it still exhibits similar issues.
That is there from when I was playing with ipv6..... not recommended from my point of view.
I'm not losing video.... the stream buffers while the timeline is growing. After the 1-3 on and off minutes of buffereing, I can got back in the timeline where the buffering happened and rewatch it. No errors and blips and I didn't miss any content.
I'm not running anything special. I have a Netgear R7000 Router with a Netgear GS308 switch. Everything is wired.
I just installed the Beta and selected Software and its playing just fine. I told you this TV had a strong enough CPU. I posted what CPU this TV has
[SoC: (Mediatek) MT5893 4xARM Cortex A73 @ 1500Mhz with Mali G71 GPU along with Sony X1 Ultimate Chip]
I will test it and let you know. I'll also try out Hybrid.
@tmm1 I may be mixing issues here, but my initial testing of your latest beta build on my Sony TV indicates that software decoding resolves my issue with frequent short video hitches. I haven't spent a lot of time with it yet, but it seems to be running smoothly. So far so good, but what kind of issues could I expect to see if the CPU was too slow?
2 Likes
If the CPU is overloaded you will generally see frame drops and stuttering.
I'll test it for an extended period of time later tonight to confirm, but so far it is running much better than it ever has before with no stuttering. Thank you.
1 Like
I agree right now as I am not having any moments where the Audio continues while the screen freezes for a second then the screen takes off in Play X4 until it catches up to the audio. That was happening a few times an hour.
This is a GREAT question. If you record the same show you are watching live..... when you go back and rewatch it ff the DVR you will not see the problem.
Switched back to using the hardware decoder. Issue just happened and I'm able to rewind and then fast forward which allows me to get back to the live feed. If I rewind and let it play over that section, the problem re-occurs and if I let the video player spin long enough, the broadcast picks back up at the next commercial break. In this instance, it happens exactly when they cut from commercial back to the normal broadcast.
@tmm1 I realize you suspect a bug in the nvidia decoder and I'd love to understand why you've ruled out any issues with the video player and attribute this solely to the hardware decoder
The android decoding api is very simple: you feed packets in and get video frames out. If we're feeding packets in but never getting and video frames, then the vendor backend is not working correctly. If this only happens on some channels, then its further proof of a decoder issue because nothing in our app changes between those channels.
That's not to say we couldn't investigate and find some sort of work-around, but in our experience that workaround usually ends up being "switch to software decoding". Nvidia has confirmed several bugs in their mpeg2 hardware decoder in the past and told us explicitly that they cannot be fixed. We've also experienced several h264 hardware decoding bugs on the SHIELD, particularly around 1080i content, and that's why most of the Channels customers in the UK also have to use software decoding. My hunch is that this is a similar problem, but since I cannot reproduce it on my own SHIELD I have no way to be sure.
Thanks for the explanation. Do you know if any of these Shield bugs carryover to hardware acceleration on nvidia desktop GPUs?
Continuing to test on my Sony TV, Hybrid seems to be working fine too. It is only pure Hardware decoding that is having the issue with video freezing.
So, if the solution is to use Software or Hybrid decoding, I'm ok with that. That is much better than any option I had a day ago.
I am still curious though why Hardware decoding works for recorded content. Why would it be any different for the hardware to decode a recorded program than it is for a live program? It seems strange that it works for one, but not the other.
But I'm not going to worry too much about it, as long as we can continue to have the Software and Hybrid options, since that appears to be an acceptable workaround.
2 Likes
Sounds similar to the effects that 2 of my OTA stations do when using Hardware decode on my Shield,,,,they stream fine with Hybrid and Software decode option.
For me on those 2 channels, with hardware decode, plays fine for a min, then it is a super slow frame rate, then after a bit, the video jumps forward like at 4x spead and catches up to the audio, that is if u just leave it alone, i can also seek forward or back and it plays the same part of the stream fine for a very short time, then does it again.
I am having the same experience.
Yea I've been asking the same question. It makes no sense to me.