search

OneLiberty / moonlight-chrome-tizen

A WASM port of Moonlight for Samsung Smart TV's running Tizen OS (5.5 and up)
GNU General Public License v3.0
185 stars 15 forks source link

Blackscreen with audio when streaming #7

Open OneLiberty opened 8 months ago

OneLiberty commented 8 months ago

I'm opening this issue to kind of document it to see if we find anything that could help us resolve the problem. So far, i'm looking to get as many TV model numbers as possible.

TV Model Number

Things you should try to fix it

raven02 commented 8 months ago

I am using Samsung series 8 that made in 2018. Tested with 1440p and 4k, default 40 and 80 bitrate are not working with black screen.

Tried to adjust to 30 and works flawlessly.

OneLiberty commented 8 months ago

I am using Samsung series 8 that made in 2018. Tested with 1440p and 4k, default 40 and 80 bitrate are not working with black screen.

Tried to adjust to 30 and works flawlessly.

Thanks for the feedback, could you please share your device ID ? I'll add it to the list, Samsung series 8 is a bit too vague

raven02 commented 8 months ago

The device ID is UA50TU8500JXZK

Naneek-code commented 8 months ago

My TV is a UN50BU8000GXZD, I'm using sunshine with an AMD RX570 GPU, the screen goes black with sound. None of the options presented work for me.

henryfa2 commented 7 months ago

This "bitrate above 30mbps" bug is driving me crazy. According to my TV spec (available on Samsung), it should support bitrate up to 80 mbps when using HEVC (H.265 - Main, Main10), which is the case on this Moonlight app (mimetype is "video/mp4; codecs=\"hev1.2.4.L120.B0\"", which is HEVC 4.1). I forced a higher version codec in the code (HEVC 5.1 and 5.2 since my TV is compatible with those 2, which is mimetype "video/mp4; codecs=\"hev1.2.4.L153.B0\"" and "video/mp4; codecs=\"hev1.2.4.L156.B0\""). Stream is starting, i see the image but it's really laggy and unplayable. I checked the app logs (nice guide btw @OneLiberty) but nothing helped me narrow down what the issue is...

OneLiberty commented 7 months ago

@henryfa2 did you have 2 moonlight version installed on the TV ? I've noticed while testing changes that having 2 side by side causes heavy lag issues in the app while streaming. Uninstalling both then installing the one i wanted to test resolved it.

I still don't know for the 30 mbps limit. Logs didn't provide any info ? stream is starting correctly ?

henryfa2 commented 7 months ago

@henryfa2 did you have 2 moonlight version installed on the TV ? I've noticed while testing changes that having 2 side by side causes heavy lag issues in the app while streaming. Uninstalling both then installing the one i wanted to test resolved it.

I still don't know for the 30 mbps limit. Logs didn't provide any info ? stream is starting correctly ?

No, I had only one Moonlight version : one of yours, from 2 months ago or so. I updated to the last version you've published (including the Limelog fix you did) + I updated the codec to a more recent version. Now, in the console, I see a difference between a smooth stream experience (using 1080p / 60 FPS / 20 mbps bitrate) and a laggy 30 mbps+ experience (using 4k / 30 FPS / 40 mbps bitrate) : In the laggy experience, I got a lot of errors about frame issues : Waiting for IDR frame moonlight-wasm.js:1 Unrecoverable frame 2578 (block 1 of 3): 36+2=38 received < 39 needed moonlight-wasm.js:1 Network dropped 1 frame (frame 2578) moonlight-wasm.js:1 Waiting for IDR frame moonlight-wasm.js:1 IDR frame request sent 2moonlight-wasm.js:1 Waiting for IDR frame moonlight-wasm.js:1 Unrecoverable frame 2582 (block 1 of 3): 18+0=18 received < 36 needed moonlight-wasm.js:1 Unrecoverable frame 2583 (block 1 of 3): 36+0=36 received < 40 needed moonlight-wasm.js:1 Network dropped 2 frames (frames 2582 to 2583) moonlight-wasm.js:1 Unrecoverable frame 2586 (block 2 of 3): 23+0=23 received < 39 needed moonlight-wasm.js:1 Network dropped 1 frame (frame 2586) moonlight-wasm.js:1 Waiting for IDR frame moonlight-wasm.js:1 IDR frame request sent 3moonlight-wasm.js:1 Waiting for IDR frame moonlight-wasm.js:1 Unrecoverable frame 2591 (block 1 of 3): 19+0=19 received < 40 needed moonlight-wasm.js:1 Unrecoverable frame 2592 (block 1 of 3): 23+0=23 received < 39 needed moonlight-wasm.js:1 Network dropped 2 frames (frames 2591 to 2592) moonlight-wasm.js:1 Unrecoverable frame 2607 (block 1 of 3): 35+0=35 received < 39 needed moonlight-wasm.js:1 Network dropped 1 frame (frame 2607) moonlight-wasm.js:1 Waiting for IDR frame moonlight-wasm.js:1 IDR frame request sent 15moonlight-wasm.js:1 Waiting for IDR frame moonlight-wasm.js:1 Unrecoverable frame 2624 (block 1 of 3): 15+0=15 received < 39 needed moonlight-wasm.js:1 Unrecoverable frame 2625 (block 3 of 3): 11+0=11 received < 34 needed moonlight-wasm.js:1 Unrecoverable frame 2626: lost FEC blocks 1 to 1 moonlight-wasm.js:1 Unrecoverable frame 2627: lost FEC blocks 1 to 1 moonlight-wasm.js:1 Network dropped 4 frames (frames 2624 to 2627)

On a smooth experience, I got none of those errors... My device is a SAMSUNG QE55Q83B TV

OneLiberty commented 7 months ago

@henryfa2 yeah, i had the same thing happen to me with the two apps installed. Might have to do with limitation of dev apps (at least on my end). Do you have another app that is "sideloaded" the same way (or similar) ?

henryfa2 commented 7 months ago

@OneLiberty No, this is the only app I've installed in developer mode

henryfa2 commented 7 months ago

@OneLiberty I made an additional test, that didn't solve the problem : I retrofited the latest moonlight-common-c library (https://github.com/moonlight-stream/moonlight-common-c/) into your version of the Samsung App. I did it like that :

  1. I took the directory on the github repo (https://github.com/moonlight-stream/moonlight-common-c/)
  2. I retrofited all the Samsung Team modifications on those files,
  3. I retrofited all the Moonlight-chrome modifications on those files, made between fork of Samsung Team and today (since our version is based on Moonlight-chrome repository : https://github.com/moonlight-stream/moonlight-chrome)
  4. I retrofited the modification you did on your repository. After all this, everything is working as intended except this bitrate > 30 bug. I gotta motivate myself to make a PR about this. It is always good to be up to date on those type of libraries, but I gotta adapt a bit what I did (I forced the use of VIDEO_FORMAT_H265_MAIN10 video codec, since my TV can handle it and it is the latest, but that video codec depends on the TV Model).
OneLiberty commented 7 months ago

@henryfa2 I did something similar on the testing branch of my repo. (here and here)

Didn't bother to implement it in the current one as it could cause more issue than it fixes.

Could you look at what I've already done on this ? This should look like what you did, I might have missed something. This could fix your issue with laggy image as IDR frame request as changed in this version.

henryfa2 commented 7 months ago

@OneLiberty Yes, what you did is similar. I installed it on my TV and the lag/stutter was worse than my updated version, probably because in your code, you forced the use of H264 codec (if you copied/pasted the Chrome version, that would explain that, since on that version they forced H264). On my version, since my TV is compatible, I forced HEVC MAIN10 : VIDEO_FORMAT_H265_MAIN10.

OneLiberty commented 7 months ago

@henryfa2 Yeah i didn't realize this was H264. Could you create a PR over on the testing branch ? For now i didn't bother updating it, and it's missing quite some update i did on main branch...

henryfa2 commented 7 months ago

@OneLiberty I can do that but how do you want to handle the choice of the codec? Should we put a new parameter where people can choose between the different codecs (VIDEO_FORMAT_H265_MAIN10, VIDEO_FORMAT_H265 or VIDEO_FORMAT_H264), with a default parameter set to H264 value (since it is the most common)?

raven02 commented 7 months ago

It would be good if we can use HEVC . It is available to choose H264 and HEVC on iOS moonlight client

@henryfa2 do you mind sharing your binary that have HEVC set ? would like to test it on my TV.

henryfa2 commented 7 months ago

@raven02 Here you go : https://github.com/henryfa2/moonlight-chrome-tizen/blob/samsung_wasm/Moonlight.wgt At the moment, codec is forced to VIDEO_FORMAT_H265_MAIN10; (HEVC MAIN10) + mimetype "video/mp4; codecs=\"hev1.2.6.L153.B0\"";

henryfa2 commented 7 months ago

You can try to change 2 settings :

  1. /wasm/main.cpp : m_StreamConfig.supportedVideoFormats = VIDEO_FORMAT_H265_MAIN10 => put VIDEO_FORMAT_H265 to downgrade to HEVC (no main10) or put VIDEO_FORMAT_H264 to downgrade to H264
  2. /wasm/wasmplayer.cpp : mimetype = "video/mp4; codecs=\"hev1.2.6.L153.B0\""; put hev1.2.4.L153.B0 instead of 1.2.6

I would recommand doing step 2. If still got the problem, do step 1 with H265 If still got the issue, do step 1 with H264

@OneLiberty This is what we should parametrize : the choice of the codec with a new parameter

OneLiberty commented 7 months ago

Cleaned conversation. This was getting really messy. Here you can find a screenshot of the conversation for archive. We should probably open some kind of discord to prevent this.

@henryfa2 I can create a toggle to change between H264 and H265, but the top bar is getting messy, wouldn't it be better to create something like a setting menu ?

henryfa2 commented 7 months ago

Cleaned conversation. This was getting really messy. Here you can find a screenshot of the conversation for archive. We should probably open some kind of discord to prevent this.

@henryfa2 I can create a toggle to change between H264 and H265, but the top bar is getting messy, wouldn't it be better to create something like a setting menu ?

I agree for the Discord, that's a good idea I'm trying something for the parameter atm, but yes I think we should start to think about an all new page to store the parameters

henryfa2 commented 7 months ago

@OneLiberty All right, I got a working version of the video codec selection on my repo. One limitation atm : If you start a stream with a codec (ie H264), then leave the stream, then change the codec (ie changing to H265), then start another stream => It is not gonna work. You gotta restart the app after changing the codec, if you already started a stream. This limitation is due to a method being called only the 1st time you start a stream (file wasmplayer.cpp, method StartupVidDecSetup). The call to that method is : std::call_once(once_flag, &MoonlightInstance::StartupVidDecSetup,videoFormat, width, height, redrawRate, context, drFlags); I tried to remove that call_once so the method is called each time you start a stream, but that didn't work. The 2nd time i start a stream, it doesn't load. No clue how to solve that atm It would be nice if some people could test it before i push a PR. NB : You can determine the codec in the debug console :

About that Discord idea, if you do not want to setup the Discord, I can do it.

OneLiberty commented 7 months ago

@henryfa2 Great ! I'll be testing your changes when I came back from vacation. For that discord, I have no idea on how to do it would be great if you can create one.

raven02 commented 7 months ago

@henryfa2 I tested your latest version with choice of codec . I tested with H264 and HEVC , it only shows black screen but the app is running on the host.

Removing this commit fixed the issue - Fix last frame from previous session displaying when starting a new one

sieskei commented 7 months ago

I can confirm that without this opacity "fix" it works (4k, 60fps, 50mbps, heic) on qn85a. I have also qn90a in another room and will test later.

BTW: keyboard 'ESC' still has some behaviour.

henryfa2 commented 7 months ago

@sieskei @raven02 Well since both of you got an issue with this fix, i removed it for now from my repo. I had no issue with it so no clue why you got an issue with it.

henryfa2 commented 7 months ago

@OneLiberty Sorry, no clue where to post that message, feel free to delete it and put the link wherever you want :) : https://discord.gg/NAjMuE9nmc