Video exits abnormally after the device is remotely (Windows)

[liaohengfan]

Hello, I found a problem.

Can you watch it for me.

Play a video using your library in WPF.

When a computer remotely (mstsc) to the device playing the video, the video will immediately exit the display blank.

Any video will appear.

I read the source code and found that this behavior is triggered by the MediaElement open close behavior.

I log output my code and find that these functions are not used when I am remote,

I'm confused now. I don't know the specific reason for the problem.

Issue Categories

• [ ] Bug

Version Information

• [ ] NuGet Package 4.4.35

Steps to Reproduce

The logs printed are as follows:

2022-01-19 19:36:48.630 [INF] [36:48.627 | TRC | Engine.Rendering    ] A BLK:     24.704 | CLK:     24.493 | DFT: -211 | IX:   0 | RNG: -20.57% | PQ:    38.8k | TQ:  1801.3k
2022-01-19 19:36:48.662 [INF] [36:48.661 | TRC | Engine.Rendering    ] A BLK:     24.704 | CLK:     24.528 | DFT: -176 | IX:   0 | RNG: -17.23% | PQ:    38.8k | TQ:  1785.9k
2022-01-19 19:36:48.693 [INF] [36:48.685 | DBG | Engine.Commands     ] Direct Command 'Close' accepted. Perparing execution.
2022-01-19 19:36:48.725 [INF] [36:48.709 | DBG | Engine.Commands     ] Direct Command 'Close' entered
2022-01-19 19:36:49.039 [INF] [36:49.032 | TRC | Element.Events      ] EVENT START: MediaStateChanged
2022-01-19 19:36:49.039 [INF] [36:49.034 | TRC | Element.Events      ] EVENT START: MediaClosed
2022-01-19 19:36:49.039 [INF] [36:49.035 | DBG | Engine.Commands     ] Direct Command 'Close' completed. Result: True
2022-01-19 19:36:49.071 [INF] [36:49.062 | TRC | Element.Events      ] EVENT DONE : MediaStateChanged
2022-01-19 19:36:49.071 [INF] [36:49.064 | TRC | Element.Events      ] EVENT DONE : MediaClosed
2022-01-19 19:36:49.086 [INF] [36:49.071 | DBG | Engine.Commands     ] Dispose Entered. Waiting for Command Manager processor to stop.
2022-01-19 19:36:49.086 [INF] [36:49.071 | DBG | Engine.Commands     ] Dispose is waiting for pending direct commands.
2022-01-19 19:36:49.086 [INF] [36:49.071 | DBG | Engine.Commands     ] Dispose is closing media.
2022-01-19 19:36:49.086 [INF] [36:49.071 | TRC | Element.Events      ] EVENT START: MediaClosed
2022-01-19 19:36:49.086 [INF] [36:49.071 | TRC | Element.Events      ] EVENT DONE : MediaClosed
2022-01-19 19:36:49.086 [INF] [36:49.071 | DBG | Engine.Commands     ] Dispose completed.
2022-01-19 19:36:59.341 [INF] [36:59.330 | WRN | Engine.Commands     ] Direct Command 'Close' not accepted. Commanding is disposed or a command is pending completion.

[Videstra]

Are you using TeamViewer?

[liaohengfan]

I use windows mstsc.exe, never tested TeamViewer,I think they may have the same result. I have to try

[Videstra]

I'm not suggesting you switch to a different one, but I ran into an issue in the past with TeamViewer causing applications to lock up when you exited. While that isn't directly your problem - I think these are tricky applications that can and do cause problems. In my case it was a windows forms issue because I started the the main form on a new thread with application.start.
I'd suggest you look at how you are starting the form and make sure it is coming up on the main thread.

[liaohengfan]

Thank you for your answer. I will carefully check the way the video window is created

[liaohengfan]

This problem also occurs using the Sample case provided by the author.

I tried to write the simplest demo.

use. WPF program created by net framework 4.6.2.

This situation still occurs when the device is remote.

Simple demo situation and results: start:

after remote:

My test code, I think this code is very simple

App.xaml.cs:

using System;
using System.Collections.Generic;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Threading.Tasks;
using System.Windows;
using Unosquare.FFME;
namespace FFMEVideoDemo
{
    /// <summary>
    /// App.xaml
    /// </summary>
    public partial class App : Application
    {
        protected override void OnStartup(StartupEventArgs e)
        {
            // ffme libs loader
            Library.FFmpegDirectory = @"g:\ffmpeg-4.4.1-full_build-shared\bin";
            Library.LoadFFmpeg();
            MediaElement.FFmpegMessageLogged += (s, ev) =>
            {
                Console.WriteLine(ev.Message);
            };
            base.OnStartup(e);
        }
    }
}

<Window x:Class="FFMEVideoDemo.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:ffme="clr-namespace:Unosquare.FFME;assembly=ffme.win"
        xmlns:local="clr-namespace:FFMEVideoDemo"
        mc:Ignorable="d"
        Title="MainWindow" Height="450" Width="800">
    <Grid>
        <ffme:MediaElement Name="videoElement" LoadedBehavior="Play" />
    </Grid>
</Window>

MainWindow.xaml.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;
using Unosquare.FFME;
namespace FFMEVideoDemo
{
    /// <summary>
    /// MainWindow.xaml
    /// </summary>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();

            this.videoElement.Open(new Uri(@"G:\video\video.mp4"));
        }
    }
}
``

[Videstra]

I see the screen goes black - has it actually stopped playing, or is it continuing to play but the video window over the remote connection is not showing? Can you look at the local computer and still see the video? If this is the case then it may be that the default codec being used by ffmediaelement is employing some hardware acceleration. For remote access you will likely need to make sure everything is done in the software. I think you can specify which decoder to use in the MediaOpening event (using e.options.decodercodec) - but it's not clear how that's used. You will likely have to check the ffmediaelement source.

[Videstra]

Oh - wait... Your image shows that the player actually stopped. That's weird. Try changing the behavior of the element in the XAML and remove the LoadedBehavior="Play" Call open and play in a load event (or a manual button). My guess then (sorry, lots of guessing here) is that the remote might be changing the behavior of the XAML spec for loadedbehavior...

[liaohengfan]

The picture is an example of Unosquare.FFME.Windows.Sample,

The following code is the simplest way I wrote,

I also tried to remove LoadedBehavior="Play",

but my media player has to play when it is open

I'll try to delete him.

You can also try the example of Unosquare.FFME.Windows.Sample.

Thank you for your reply to my question,

: )

[liaohengfan]

There will also be problems without GPU acceleration. I have also tried other versions, and all of them have reproduced this problem.

[Videstra]

I have tried the sample, but I'm not a C# programmer (I do vb.net) and just loading the program in VS2019 results in a lot of errors that need to be resolved - so sadly I am unable to try it. I have looked through the sample and found much useful information to help with latency (some anyway). My implementation is entirely in VB.net using VS2015. I just tried remoting in with TeamViewer and I do not encounter this problem. I'd say try another remote utility (e.g. VNC, or the many trials that are offered by Splashtop, etc.). Personally I've always found the MS built-in stuff to be wonky anyway - so I avoid it.

[liaohengfan]

Because of other things, I have stopped the investigation of this problem at present, and can only tell my colleagues to avoid this behavior, and I will continue to study it when I have time. Thank you for your answer! : )

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.