Win 10 mirroring crashes when youtube is started

[codekoch]

Win 10 mirroring works perfect until I open a browser (Edge/Chrome) and try to play a youtube video...Local Videos are no problem.

[homeworkc]

Try screen layouts that are not "second monitor only".

[codekoch]

Thank you for the reply. I tested other layouts. Surprisingly only the layout "second monitor only" does not crash while opening a website with video content.
Before I used the layout "Duplicate". Is there any way to fix it, so I can use also the layout "Duplicate"? I need this layout because I use the Win10 device as mobile interactive whiteboard in classrooms connected to the pi which delivers its screen to a beamer.

[codekoch]

I wonder also about the the unnamed Window which always opens in the background when I start mirroring a Win 10 device. It doesn't appaer mirroring an android device.

[homeworkc]

Maybe try different players (like player 1)? Or, you can try using "second monitor only", starting the video, then switching to "duplicate". What is the behavior of a crash? Does the player (on Pi) stop playing (but still maintain the connection), or does it always disconnect? The unnamed Window is an X window that is used to capture the mouse/keyboard input on Pi to support the UIBC feature. You can turn it off by setting enable_mouse_keyboard = 0 in d2.py.

[codekoch]

Ok. Thanks. I will continue testing...

[codekoch]

I allways used player 2 and it seems that only h264.bin crashes. I can recconnect by switching the projection mode on windows. With player 1 there is no crash but much more image and sound artefacts.

[codekoch]

Now I have a very rough workaround for d2.py....: [...] def launchplayer(player_select): os.system('pkill vlc') os.system('pkill player.bin') os.system('pkill h264.bin') if player_select == 0: os.system('vlc --fullscreen rtp://0.0.0.0:1028/wfd1.0/streamid=0 &') elif player_select == 1: os.system('./player/player.bin '+str(idrsockport)+' '+str(sound_output_select)+' &') elif player_select == 2: os.system('./h264/h264.bin '+str(idrsockport)+' '+str(sound_output_select)+' &') elif player_select == 3: os.system('omxplayer rtp://0.0.0.0:1028 -n -1 --live &')

crashfix

def running(): output = subprocess.check_output("ps aux | grep 'h264.bin' | wc -l", shell=True) if int(output) > 2: return True
else: return False

crashfix

launchplayer(player_select)

fcntl.fcntl(sock, fcntl.F_SETFL, os.O_NONBLOCK) fcntl.fcntl(idrsock, fcntl.F_SETFL, os.O_NONBLOCK)

csnum = 102 watchdog = 0 while True:

crashfix

    if not running():
        launchplayer(player_select)
    #crashfix
    try:
            data = (sock.recv(1000))

[homeworkc]

Cool. This is a high level workaround for player 2. I suppose that player 2 sometimes does give up too easily and there is no mechanism to detect the crash per se. Originally, player 2 was a simple and small program which I used to compare the performance of different demuxing approaches. Therefore it is not as resilient as player 1. (For example, player 1 can actually detect the format changes (e.g., resolutions) of incoming streams and adopt accordingly, while player 2 cannot. That's why when resolution changes, we need to kill h264.bin and restart it again in https://github.com/homeworkc/lazycast/blob/6f9c5a283cfe08c51641ddb6c05958e4ef7b716d/d2.py#L256. These 2 lines are redundant for player 1.) Ideally, we could trace which line in h264.c triggers a crash to solve the issue fundamentally.