OS: Windows 10 Anniversary Update
qTox version: v1.5.0-2-gf05b7e0
Commit hash: f05b7e0
Reproducible: Always
Only opening device in qtox.log
[12:25:23.737 UTC] src/video/camerasource.cpp:266 : Debug: Opening device "video=@device_pnp_\\\\?\\display#int0f38#4&338c1d0d&0&uid134968#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\\{0f35712a-70bd-494d-9ccd-5e2dac09cbc8}"
Still exist in v1.5.1-2 23d08db.
If you have the older v1.4.0/v1.4.1 binaries around, mind trying that?
I thinking this might be due to Anniversary Update. Cause I found stable v1.4.1.1 version and selecting cameras isn't working too (When on previous Windows 10 version it was working).
It's time to reinstall camera drivers? :laughing:
Yeah, that would be nice if you could try that.
It's weird, because Windows can work with cameras. Maybe some methods was changed in update...
All underlying video code is essentially handled by FFmpeg (within qTox), if a previously working binary fails after a windows update, it's likely that routines within FFmpeg that create/initialize the video device no longer properly work. Though, this should not result in a crash of the application (unless FFmpeg itself crashes), I'll make a note of checking initialization results in subsequent changes to the video subsystem.
In the meantime, I can only ask that you narrow down the issue for us. I'll try qTox under Windows later (I have the anniversary update too).
Driver update didn't work. qTox v1.5 and v1.4 still crashes.
And here I mean Windows, not qTox :smile:
Maybe some methods was changed in update...
All underlying video code is essentially handled by FFmpeg (within qTox), if a previously working binary fails after a windows update, it's likely that routines within FFmpeg that create/initialize the video device no longer properly work.
It's worth to note that recently FFmpeg version has been bumped for windows binaries, so if @DX37 didn't try with an old archived one, there's new FFmpeg being used in both versions.
Hell no, I don't have any versions of qTox with old FFmpeg. I have a stable v1.4.1.1 barely found on build.tox.chat and it didn't work due to Anniversary Update, I suppose.
Okay, I can confirm the issue with Windows 10 Anniversary Edition.
I just read this post which bring some information about the webcam problem in win 10 anniversary.
Hope it will help, and i hope the update announced will correct the problem.
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/9d6a8704-764f-46df-a41c-8e9d84f7f0f3/mjpg-encoded-media-type-is-not-available-for-usbuvc-webcameras-after-windows-10-version-1607-os?forum=mediafoundationdevelopment
Hey guys, I was pointed to issues with your project in the MSDN forum thread linked above, and I decided to stop by to help you resolve these reports.
We managed to get a local repro of the crash reported here. It appears to be coming from an implementation of the IBaseFilter::QueryVendorInfo somewhere in qTox. By looking at the logs of our local repro and the information provided here, I traced it down to CameraDevice, which uses ffmpeg's libavdevice, which implements QueryVendorInfo in line 154 of dshow_filter.c, where we find the potential culprit in line 160:
*info = wcsdup(L"libAV");
As per the IBaseFilter::QueryVendorInfo method MSDN documentation:
If the method is supported, it uses the CoTaskMemAlloc function to allocate memory for the string. Call the CoTaskMemFree function to free the memory.
So, because libavdevice in qTox is allocating the output string using wcsdup() instead of CoTaskMemAlloc() (see some more information here), the memory is allocated from a completely different heap. Subsequently, when our component in Windows attempts to free the string returned from this API using CoTaskMemFree(), the heap corruption seen in the crash is triggered.
The reason this wasn't an issue before the Windows 10 Anniversary Update, is because the component on the Windows side didn't call into the implementation of IBaseFilter::QueryVendorInfo for this scenario.
We understand that libavdevice may be a popular library, and we'll be reaching out to the ffmpeg team to help them resolve it, as it appears they're tracking the issue here. This means that qTox and other projects may get the fix once they make the necessary changes.
It seems the ffmpeg teams apply a patch for this error which is include in their last build. May we have a new windows build with the library up to date to test it?
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/18ce63a60e1bffc35b4df5d8a4f9a1ff1a96cb9a
cc @nurupo ?
Did they release a ffmpeg version that fixes it?
Yep, none of the releases include that fix yet. Want me to re-build ffmpeg against its master/dev branch, risking breaking video completely?
why would it break all the video features?
which ffmpeg version is used by qtox?
Ok, I have bumped ffmpeg's version from 3.1.1 to 3.1.3 and also patched it with the the diff of the commit that supposedly fixes the DirectShow issue, since that commit haven't made into any ffmpeg release yet.
Please try qTox nightly for Windows x86 and x86-64 and see if you can reproduce the issue now. Those nighties use the patched ffmpeg. The download links won't stay up for long, as we keep only N last nightly builds.
Tks for the quick answer, i tried the x86_64 version and if the webcam is not use by another program, it works. But if the webcam is already in use, qtox freeze. I think it's another problem, and it is less important since we can use the webcam again :)
Same for the x86 version.
If i may ask it here, were can i find help to build windows version of qtox because the wiki is out of date?
(I tried a lot of things, building and cross building all the library, but i always end up with a library which is not found.)
Can you send me the information of how you build it?
Thank you verry much for this fix!!!
It works now, but on my webcam from 720p, 480p, 360p and 240p modes, 480p and 240p acts weird, like on this screenshot:

@DX37 Mind sending logs?
@DX37 Mind sending logs?
try this: right click on ffmpeg (and ffplay and ffprobe) then go to compatibility and select "run this program as administrator".
@DX37 The corrupted video output has been traced to another unrelated bug (and I am able to reproduce it). I'll see what I can do about that later.
qTox v1.5.2 was released some time ago with patched FFmpeg, thus closing.
As for the corrupted video, new issue should be opened if it's still reproducible.
FFmpeg 3.2.0 includes the fix, so I have updated FFmpeg on our build server from 3.1.3 to 3.2.2. The patching we did on top of 3.1.3 is obviously removed now, since the commit made it into the release.
Most helpful comment
Hey guys, I was pointed to issues with your project in the MSDN forum thread linked above, and I decided to stop by to help you resolve these reports.
We managed to get a local repro of the crash reported here. It appears to be coming from an implementation of the
IBaseFilter::QueryVendorInfosomewhere in qTox. By looking at the logs of our local repro and the information provided here, I traced it down toCameraDevice, which uses ffmpeg's libavdevice, which implementsQueryVendorInfoin line 154 of dshow_filter.c, where we find the potential culprit in line 160:As per the IBaseFilter::QueryVendorInfo method MSDN documentation:
So, because libavdevice in qTox is allocating the output string using
wcsdup()instead ofCoTaskMemAlloc()(see some more information here), the memory is allocated from a completely different heap. Subsequently, when our component in Windows attempts to free the string returned from this API usingCoTaskMemFree(), the heap corruption seen in the crash is triggered.The reason this wasn't an issue before the Windows 10 Anniversary Update, is because the component on the Windows side didn't call into the implementation of
IBaseFilter::QueryVendorInfofor this scenario.We understand that libavdevice may be a popular library, and we'll be reaching out to the ffmpeg team to help them resolve it, as it appears they're tracking the issue here. This means that qTox and other projects may get the fix once they make the necessary changes.