Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Video Unity 2019.3.1f1 HDRP - Videoplayer Causing Black screen on Standalone build

Discussion in 'Audio & Video' started by M4dR0b, Mar 18, 2020.

  1. M4dR0b

    M4dR0b

    Joined:
    Feb 1, 2019
    Posts:
    108
    Hi there Unity ppl,

    I'm experiencing a nasty bug where Videoplayer makes the monitor go black for a couple of frames; it occurs at the whole monitor, not the game window, but only if the monitor has a bigger size (it happens on a 27inches monitor not on a 23). Has anyone experienced this or know if it's a known issue?

    I've attached a video with the issue in a newly created project.


    Thanks for the feedbacks :)

    EDIT/UPDATE:
    So...Tested the Test Build on a different rig with same Hw/Sw configs and monitor, and the issue doesn't occur...Tested on a different rig completely with same monitor, issue doesn't occur. Tried upgrading/downgrading gl drivers, doesn't change anything. I'm givin up, being a singularity only on one machine :p but was just curious cause with Unity 2019.2 hdrp, it doesn't happen :/

    System/Unity infos:

    Win 10 64 bit
    Nvidia GeForce RTX 2080 TI
    Unity 2019.3.1f1
    HDRP
    Monitor h 27in
    DirectX 11
     
    Last edited: Mar 18, 2020
  2. DominiqueLrx

    DominiqueLrx

    Unity Technologies

    Joined:
    Dec 14, 2016
    Posts:
    260
    Hi!

    I suppose you've tracked it down to be due to a video being played (like if you don't play the video, then no blanking happens)?

    Does this happen no matter which video you're playing? You could run some tests with H.264, H.265 or VP8 (you can either transcode in the importer, or just choose different file altogether). Note that between 2019.2 and 2019.3, the major difference when it comes to video playback on Windows (for H.264 / H.265) is that it's now hardware accelerated. So the difference in behaviour is likely coming from there.

    You're saying DX11 ... with HDRP? I'm asking because DX11 and DX12 are both supported for hardware-accelerated video decoding, but with different code paths.

    You could also try with the latest version (2019.3.5f1as of this writing).

    But as you say, if it's so hard to reproduce, it'll be hard to try and fix it... Please let us know if you can find a scenario where it's easier to repeat and we'll be able to have a look!

    Dominique Leroux
    A/V developer at Unity
     
  3. M4dR0b

    M4dR0b

    Joined:
    Feb 1, 2019
    Posts:
    108
    Hi Dominique,

    thanks for your reply.

    yep, it only happens when the video is being played.

    Issue not happening with VP8, can't say with h265 'cause it throws an error after transcoding the file internally.
    There's also a low localization bug for the Italian underlined, but those are other issues now...Oh, same happen on 2019.3.5f1 (also the loc bug).


    Tried also the experimental Dx12, no changes.

    Is happening the same with the video encoded at h264.

    I'll try and keep this updated if a way to reproduce this is found.

    Any idea what I could test after having pinned down the issue being the hardware accelerated h264 codec?
    I don't suppose there's a issue using VP8, but just to know.

    Thank you :)
     
  4. DominiqueLrx

    DominiqueLrx

    Unity Technologies

    Joined:
    Dec 14, 2016
    Posts:
    260
    OK, thanks for the additional info!

    Good. So at least this is a workaround if you absolutely need proper playback on this system. Note that our internal conversion to VP8 doesn't do the best possible job quality-wise. So if you want to keep this option, I suggest transcoding to webm/vp8 using an external tool (ffmpeg) that gives you the full control over this.

    This is probably because H.265 (aka HEVC) is not installed on your system. If you dig in the error messages (while trying to play or transcode), you'll see an indication of what to do in order to get this add-on from Microsoft.

    Trying to play different clips could also help. E.g.: see if this has to do with the clip's resolution by trying small/medium/large. Same goes with frame rate (24/25/30/50/60) although this is less likely to be the problem. Another parameter that is more subtle is the codec profile being used. Assuming the original video track is H.264, you'll often see Baseline, Main or High profiles being used. Main and High use more "advanced" codec features that are likely to trigger bugs (the one you're showing here is a bit extreme but still). So re-encoding with the simplest profile (Baseline) may help. But if I understand correctly, you did make an explicit conversion to H.264 in our importer? (our encoder uses baseline, so this would mean that using baseline doesn't bypass the problem). In the unlikely event where the problem exists with baseline video tracks but not on main or high profiles, then it would also be a good test to convert (externally) to one of these profiles to see if the problem remains. But we're getting quite far of what's reasonable to ask you to test (but since the repro setup is so rare...).

    It's also good to compare what Windows' built-in media playback does with this video. The "Film&TV" app (should be the default media handler) also seems to be using Microsoft Media Foundation in its implementation. So it's likely to be plagued with the same issues. Knowing this is helpful with eventual communications with Microsoft when we report the issue to them (assuming we don't find a satisfying workaround/fix).

    And finally, it'd be good to know if there's anything of interest in the log file.

    Hope something in here will help! Also, feel free to share the movie file in here if at all possible: maybe I'll get ideas of things to try if I can see the content details.

    Dominique
     
  5. M4dR0b

    M4dR0b

    Joined:
    Feb 1, 2019
    Posts:
    108
    Hi Dominique,

    Thanks, that is good to know!

    Not possible with that particular video, but is just a screen rec from OBS, 60fps encoded in h264. Not sure what profile does obs use, it is not specified in the software advanced options.

    Yep.

    For now all is good, is still an alpha stage, but when i get to the final video part will definitely try some of the testing you mentioned and update here if I find something else.
    For now thank you very much for your support :)


    ps:
    So you guys communicate with all the OS devs to report bugs too? Didn't know this aspect, hard life being a dev :D