Can the console window be disabled?

[BattleAxeVR]

After CreateVulkanVideoDecodeParser is called, nvidia-vkvideo-parser.dll begins its duties and opens up a console window during decoding.

Can this be behaviour be disabled?

I'd like to just run my test app without any superfluous windows lying about.

Thanks.

[zlatinski]

After CreateVulkanVideoDecodeParser is called, nvidia-vkvideo-parser.dll begins its duties and opens up a console window during decoding.

Can this be behaviour be disabled?

I'd like to just run my test app without any superfluous windows lying about.

Thanks.

If you would like to disable the console output, please set the following two flags to false:

bool VulkanVideoParser::m_dumpParserData = false; bool VulkanVideoParser::m_dumpDpbData = false;

from vk_video_decoder\libs\VkVideoParser\VulkanVideoParser.cpp:608

The application is invoked from the console with parameters, so I'm not sure how can one run the app without starting from the console. Perhaps if the app is recompiled as a pure WS app.

Please note that the NV parser does not open any consoles, the app does.

[BattleAxeVR]

Hi Tony, I set the m_dumpDpbData to false (m_dumpParserData was already) and the console window still starts up. I'm running a windows app that calls this internally, without any "Shell" classes.

It's mostly empty even while it plays, but I searched in the code for the string "Console opened at" and no hits in show up in Visual Studio search, thus my suspicion that it's in the parser.dll that's pre-compiled.

I put a breakpoint and pinpointed the exact moment the extra console window starts, it's after initialization:

[BattleAxeVR]

This is with both those flags set to false:

[BattleAxeVR]

The popup console window shows up after ParseByteStream is called the second time:

ParseByteStream is a virtual method whose implementation is only inside the Dll, as far as I can tell.

[BattleAxeVR]

Also, not that it matters, but the width and height in that console prompt are swapped. It decodes correctly though. Great job on the lib by the way, it runs fantastic performance-wise, looking forward to HEVC encoding and it coming out of Beta.

[BattleAxeVR]

My app uses windows subsystem, so not definitely a console app.

pragma comment(linker, "/subsystem:windows")

[zlatinski]

The popup console window shows up after ParseByteStream is called the second time:

OK, let me check what is going on, and will come back to you. I'm surprised because the parser does not use any Windows APIs - it uses all standard C++ code. Maybe this is because of the way the dll is built on Windows. Is there a way you can send me your Windows binary executable to test against locally?

[BattleAxeVR]

test.zip

I can't share my main app, but here's a build of this sample, including a tiny video file whose path is hardcoded during unit (for some reason the command line arguments aren't passing in, weird). Both the flags were set to false. It's compiled in visual studio 2019 manually (after running the batch file initially, of course, per the instructions here).

It needs the other ffmpeg and parser dlls copied here obviously. Thanks for any help you can give. Much appreciated.

[zlatinski]

test.zip

I can't share my main app, but here's a build of this sample, including a tiny video file whose path is hardcoded during unit (for some reason the command line arguments aren't passing in, weird). Both the flags were set to false. It's compiled in visual studio 2019 manually (after running the batch file initially, of course, per the instructions here).

It needs the other ffmpeg and parser dlls copied here obviously. Thanks for any help you can give. Much appreciated.

This zip file is reported to have a malware: https://www.f-secure.com/v-descs/w32_malware.shtml

[BattleAxeVR]

I just scanned it just in case, it says it's ok. I think that's a false positive. But anyway, it should be straightforward to reproduce + fix this using only the sample code and the parser.dll.

If the sample can be compiled and run on Windows without the side window opening up, then the problem is on my end, and I'll figure it out. But, there's no other call happening except for ParseByteStream on my end (it's running single threaded too). I have 100% repro.

[zlatinski]

I just scanned it just in case, it says it's ok. I think that's a false positive. But anyway, it should be straightforward to reproduce + fix this using only the sample code and the parser.dll.

If the sample can be compiled and run on Windows without the side window opening up, then the problem is on my end, and I'll figure it out. But, there's no other call happening except for ParseByteStream on my end (it's running single threaded too). I have 100% repro.

Do you have the MSFT project file with the stripped-down version of what you are trying to do? You can send it directly to my email: zlatinski@gmail.com. The zip file does not have the issue, but when I try to execute the exe file the antivirus is blocking it, claiming for it to have malware.

[BattleAxeVR]

Thanks Tony, I'll get on that monday.

One thing I'm curious about is why put the parser in a closed-source DLL/lib instead of directly as source code, I assume it's chock-full of secret/proprietary Nvidia-specific code?

That's fine, but I thought the whole point of Vulkan Video was that it was vendor neutral, so that kind of defeats the purpose of using this sample over, say, NVDec, doesn't it?

[zlatinski]

Thanks Tony, I'll get on that monday.

One thing I'm curious about is why put the parser in a closed-source DLL/lib instead of directly as source code, I assume it's chock-full of secret/proprietary Nvidia-specific code?

That's fine, but I thought the whole point of Vulkan Video was that it was vendor neutral, so that kind of defeats the purpose of using this sample over, say, NVDec, doesn't it?

The goal is to use open-source parsers, such as FFMPEG. The nvParser is a temporary stop-gap, for evaluation purposes only, until we get the FFMPEG parser fully supported. We may have an open-source parser for VP9/AV1 :).

[BattleAxeVR]

That's great, Tony. FFMPEG doing everything works for me.

I can't send my project via email, it's private and the source code here should repro the issue with the console window popping up. Logically the CreateProcess that spawns the separate console window must exist in the parser DLL so I don't see the point in doing anything else on my end.

But since it's going to be moot soon anyway, you maybe needn't bother fixing this. Anything done with FFMPEG needs to be fully open source due to GPL anyway so if there's an issue after your next big release, I'll be able to fix it myself. Thanks for your time. Fix this or don't, it's not really important. I'll leave it open for now.

[BattleAxeVR]

Is there still no way to disable the console popup window? It's starting to become a real nuisance for me, this popup.

Using the sample as-is in both Debug and Release (with appropriate debug/release versions of the parser dll), is a 100% repro, with or without Visual Studio attached, and from a console or windows app.

I just run it from the command-line and there are 2 windows open. That's one too many. It gets in the way of my work constantly, really irritating. Much obliged if you could find a way to keep the popup from showing, at least in the parser's Release DLL.

[zlatinski]

Is there still no way to disable the console popup window? It's starting to become a real nuisance for me, this popup.

Sorry about that! The parser is built with the same Cmake configuration as the rest of the projects. I'll have to do some more digging to see what is causing the parser to span a console. Unfortunately, I do build and launch the app from the command line and so, it is difficult for me to reproduce this.

[BattleAxeVR]

Much appreciated.

Speaking of the demuxer, I added a call to av_seek_frame so the video will loop, hope this helps someone.

Just call it with timestamp = 0 when the video ends (EOS) if you want the video to loop:

bool Seek(int stream_index, int64_t timestamp, int flags)
{
    if (!fmtc) 
    {
        return false;
    }

    int result = av_seek_frame(fmtc, stream_index, timestamp, flags);

    if (result < 0) 
    {
        return false;
    }

    return true;
}

You also have to reset the m_videoStreamHasEnded flag back to false:

bool VulkanVideoProcessor::Seek(int stream_index, int64_t timestamp, int flags) { m_videoStreamHasEnded = false; return m_pFFmpegDemuxer ? m_pFFmpegDemuxer->Seek(stream_index, timestamp, flags) : false; }

[zlatinski]

Hi Bela Kampis, Can you please check the parser from the ToT of this repo and see if it works for you (without creating a console)? You may need to add a logger function with CreateVulkanVideoDecodeParser() just in case there are any parser errors that you'd need to see.

[BattleAxeVR]

Hi, I'm still getting the same behaviour, I checked all the flags again and the popup is happening in the sample as well as my game.

My guess is the dll, or one of its dependencies, is compiled with /SUBSYSTEM:CONSOLE instead of /SUBSYSTEM:WINDOWS, and whichever process calls the cout << "Console opened at" is responsible. I'm sure you can find this string in the parser code, no?

Stack Overflow suggests this:

[zlatinski]

Hi BattleAxeVR, I've pushed parser's DLLs versions with the "/SUBSYSTEM:WINDOWS" linker flag set - can you please try those? I wish I had a Windows-based application to try this on, locally.

BTW, we build the parser using Cmake automated scripts and I had to explicitly add these linker options to the Cmake project. The parser is based on the standard-C++ library. It is possible we may need to define an explicit DllMain(). If this one does not work for you, then I'll add an explicit DllMain() to the DLL, and hopefully, this one would work.

[BattleAxeVR]

Are you sure we don't need new libs too? Not just the DLLs? It doesn't fix it, sadly:

Whichever process calls cout << "Console opened at" .... must be a console spawned as a child process from inside the DLL somewhere, probably part of the logger class. I tried ripping out everything related to logging in my app, including the class itself, and it didn't fix it.

[zlatinski]

Sorry about that! My theory, at this point, is that we would have to define an explicit DLLMain(). Otherwise, the default one for the DLL, created by the Windows linker, is a console wrapper. I'll compile a version of the DLL with that and see if this works.

[BattleAxeVR]

Hi, will this issue be fixed any time soon? The other feature requests I made would be nice to have, but this issue was opened almost exactly one year ago and it still isn't fixed. If you can't / won't fix it, please say so so I can use a different video library.

[zlatinski]

Hi @BattleAxeVR,

We now support static parser libraries with the decoder. Please refer to the nvidia-vkvideo-parser-static.lib libraries. For ex. https://github.com/nvpro-samples/vk_video_samples/blob/main/vk_video_decoder/bin/libs/nv_vkvideo_parser/wddm2_amd64_debug/nvidia-vkvideo-parser-static.lib