ffdshow tryouts project: Discussion & Development - Page 677

clsid · 10th May 2011, 23:11

There is no setting in the GUI for that. The default value is 0, so I am curious why it was at 1 for you.

clsid · 10th May 2011, 23:47

Some info about the purpose of the option:
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

pankov · 11th May 2011, 10:48

Quote:

Originally Posted by clsid

There is no setting in the GUI for that. The default value is 0, so I am curious why it was at 1 for you.

I have absolutely no idea, but since I've been using the same settings for several years (imported from .reg files) I guess it's default value could have been different in the past ... or something else could have changed it. In fact I've just looked at my backups and saw that this setting was set to "1" even in my oldest Registry export from 26.02.2005.
I've turned it off now but the question why it causes such behavior in MPC-HC remains. Is this MPC's fault ... or is it a fault at all? Sadly I don't understand that much about DirectShow, but what's the purpose of this setting in ffdshow itself? is it ffdshow that's connecting to remote graphs or it's the other way around?

clsid · 11th May 2011, 12:46

It is for other apps to connect to a graph in which ffdshow is present. For example the "connect to remote graph" function in GraphEdit. Or apps that make use of the RemoteAPI for controlling ffdshow settings.

XhmikosR · 11th May 2011, 15:49

@clsid: ffdshow is crashing for me after r3842 (probably r3844 is the rev which the crash started) with this 10bit h264 video using ffmpeg-mt. r3847 still crashes.

BTW, I'm getting the following warnings when compiling ffmpeg-mt which I guess it's cause by #define HAVE_PTHREADS 1 in ffmpeg-mt's config.h.

Quote:

In file included from libavcodec/pthread.c:33:0:
libavcodec/../../pthreads/pthread.h:108:0: warning: "PTW32_LEVEL" redefined [enabled by default]
libavcodec/../../pthreads/pthread.h:95:0: note: this is the location of the previous definition
In file included from libavcodec/../../pthreads/pthread.h:302:0,
from libavcodec/pthread.c:33:
../pthreads/sched.h:64:0: warning: "PTW32_LEVEL" redefined [enabled by default]
../pthreads/sched.h:51:0: note: this is the location of the previous definition libavcodec/utils.c: In function 'avcodec_open':

As for the ICL12 builds and the crashes I mentioned in my previous post, I'm still getting them with ffmpeg and ICL12 builds but it doesn't happen with all the h264 videos. And the problem is that if I cut a sample I cannot reproduce the crash. I'll try to find the smallest available sample which can be used to reproduce the crashes. BTW, it doesn't matter if I use ffmpeg or ffmpeg-mt, it's crashing in both cases.

EDIT: r3848 still crashes with the above 10bit h264 video.

clsid · 11th May 2011, 17:52

To fix it support needs to be added to ffdshow for handling the newlly added PIX_FMT_YUV420P9 and PIX_FMT_YUV420P10 colorspaces.

nevcairiel · 11th May 2011, 17:58

swscale supports them as input formats , so you can convert them to any of the supported output formats using that pretty easily (even with dithering for the 10->8 conversion). Of course it would be preferable to output the actual 10bit data, if the renderer supports it, but thats alot more work, as these special 10bit DirectShow formats are not supported by swscale.

(and only madVR supports them for rendering, anyhow)

PS:
I don't follow libav development, as i use ffmpeg - so i cannot comment if the swscale support arrived in libav as well.

clsid · 11th May 2011, 19:14

I have added a workaround to get the old behavior. That fixes the crash until the proper colorspace conversion is added.

swscale is already up-to-date, so it is just a matter of updating ffdshow.

XhmikosR · 11th May 2011, 20:16

It seems to work like before in r3850, i.e. no crashes with 10bit videos.

Now about the ICL12 builds crash, I though I'd remove any workarounds in "libavcodec\golomb.h". And what do you know? It doesn't crash anymore. I haven't tried any debug builds though.
So clsid, since MSVC2010 and ICL12 work fine for me and you are the only one know who's using ICL10 and MSVC2008, can you confirm that this patch doesn't cause any crashes for you?
Test builds here for anyone who had crashes with h264 videos and ICL12.

Also, how about the ffmpeg-mt pthreads warnings I told you in my post above?

VipZ · 11th May 2011, 21:11

I was about to post a bug that I had a file with h264 that crashed under x64 but was ok under x86, XhmikosR's golomb fix has fixed this now

clsid · 11th May 2011, 23:23

This file posted by VipZ crashes with MSVC2008 x64 build with that change:
http://www.mediafire.com/?krlxvlj8sb67n90

Do you have more files that I should test?

The weird thing is about this whole issue is that the workaround is for compilers that somehow fail to expand the macro properly. It should not have a negative effect on compilers that do process the macro properly, since the manually expanded code should be equivalent.

VipZ · 11th May 2011, 23:53

Clsid, here is the sample I was going to post about the crash issue, http://www.mediafire.com/?aajakpfoe8utg24

XhmikosR · 12th May 2011, 00:21

Quote:

Originally Posted by clsid

This file posted by VipZ crashes with MSVC2008 x64 build with that change:
http://www.mediafire.com/?krlxvlj8sb67n90

Do you have more files that I should test?

The weird thing is about this whole issue is that the workaround is for compilers that somehow fail to expand the macro properly. It should not have a negative effect on compilers that do process the macro properly, since the manually expanded code should be equivalent.

Well all I know is that with that change the ICL12 crashes are gone for me. MCVS2010 x86 builds work as before, i.e. no crashes, with or without the patch.

But with that sample the ICL12 build indeed crashes, even with that pacth. The MSVC2010 build with my patch doesn't crash. The MSVC2010 build without my patch doesn't crash either. I cannot try the x64 builds since I'm on 32bit Windows. BTW, that sample doesn't play smoothly for me anyway.

Quote:

Originally Posted by VipZ

Clsid, here is the sample I was going to post about the crash issue, http://www.mediafire.com/?aajakpfoe8utg24

With this sample, the unpatched ICL12 build crashes. The patched ICL12 build doesn't. MSVC2010 isn't affected, it doesn't crash with or without the patch.

clsid · 12th May 2011, 00:33

x86 builds work fine. It is only the MSVC x64 builds that are having problems.

SamuriHL · 12th May 2011, 00:33

I just built msvc2010 x86. No problem. I did not do an x64 build.

VipZ · 12th May 2011, 00:34

As far as I discovered about this issue ICL12 and MSVC2010 x64 behave the same way, while MSVC2010 x86 seems to never have an issue.
I tested a MSVC2008 x64 build (ffdshow_rev3844_20110510_clsid_x64.exe) which crashes as well.

With this test patch it would seem to fix 3 builds, but break 1.

XhmikosR · 12th May 2011, 00:58

Well, I don't use MSVC2008. Does the MCVS2010 x64 build crash, with or without the patch?

clsid · 12th May 2011, 00:59

The problem is with the files. I got three test files, MKV/MP4/FLV. Either the FLV crashes and the other two work, or vice versa.

What bothers me is that the code is essentially the same, so I don't understand why the results are different.

XhmikosR · 12th May 2011, 01:04

If the MSVC2010 builds work I'm fine with it. If not then it's something someone should dig into more.

VipZ · 12th May 2011, 01:05

Quote:

Originally Posted by XhmikosR

Well, I don't use MSVC2008. Does the MCVS2010 x64 build crash, with or without the patch?

Without patch MCVS2010 x64 crashes and with patch its fine.

IMO the patch is good.

10th May 2011, 23:11	#13521 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	There is no setting in the GUI for that. The default value is 0, so I am curious why it was at 1 for you. __________________ MPC-HC 2.2.1

10th May 2011, 23:47	#13522 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	Some info about the purpose of the option: http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx __________________ MPC-HC 2.2.1

11th May 2011, 12:46	#13524 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	It is for other apps to connect to a graph in which ffdshow is present. For example the "connect to remote graph" function in GraphEdit. Or apps that make use of the RemoteAPI for controlling ffdshow settings. __________________ MPC-HC 2.2.1

11th May 2011, 17:52	#13526 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	To fix it support needs to be added to ffdshow for handling the newlly added PIX_FMT_YUV420P9 and PIX_FMT_YUV420P10 colorspaces. __________________ MPC-HC 2.2.1

11th May 2011, 17:58	#13527 \| Link
nevcairiel Registered Developer Join Date: Mar 2010 Location: Hamburg/Germany Posts: 10,348	swscale supports them as input formats , so you can convert them to any of the supported output formats using that pretty easily (even with dithering for the 10->8 conversion). Of course it would be preferable to output the actual 10bit data, if the renderer supports it, but thats alot more work, as these special 10bit DirectShow formats are not supported by swscale. (and only madVR supports them for rendering, anyhow) PS: I don't follow libav development, as i use ffmpeg - so i cannot comment if the swscale support arrived in libav as well. __________________ LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 11th May 2011 at 18:01.

11th May 2011, 19:14	#13528 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	I have added a workaround to get the old behavior. That fixes the crash until the proper colorspace conversion is added. swscale is already up-to-date, so it is just a matter of updating ffdshow. __________________ MPC-HC 2.2.1

11th May 2011, 20:16	#13529 \| Link
XhmikosR Registered User Join Date: Mar 2007 Location: Hellas (Greece) Posts: 543	It seems to work like before in r3850, i.e. no crashes with 10bit videos. Now about the ICL12 builds crash, I though I'd remove any workarounds in "libavcodec\golomb.h". And what do you know? It doesn't crash anymore. I haven't tried any debug builds though. So clsid, since MSVC2010 and ICL12 work fine for me and you are the only one know who's using ICL10 and MSVC2008, can you confirm that this patch doesn't cause any crashes for you? Test builds here for anyone who had crashes with h264 videos and ICL12. Also, how about the ffmpeg-mt pthreads warnings I told you in my post above? __________________ My builds Notepad2-mod My Specs

11th May 2011, 21:11	#13530 \| Link
VipZ Registered User Join Date: Jun 2009 Location: London Posts: 378	I was about to post a bug that I had a file with h264 that crashed under x64 but was ok under x86, XhmikosR's golomb fix has fixed this now __________________ Windows 11 Pro, CPU: Ryzen 9 5900X, GPU: GeForce RTX 3090 /w 512.95, Audio: HDMI to Yamaha RX-A3060 (5.1)

11th May 2011, 23:23	#13531 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	This file posted by VipZ crashes with MSVC2008 x64 build with that change: http://www.mediafire.com/?krlxvlj8sb67n90 Do you have more files that I should test? The weird thing is about this whole issue is that the workaround is for compilers that somehow fail to expand the macro properly. It should not have a negative effect on compilers that do process the macro properly, since the manually expanded code should be equivalent. __________________ MPC-HC 2.2.1

11th May 2011, 23:53	#13532 \| Link
VipZ Registered User Join Date: Jun 2009 Location: London Posts: 378	Clsid, here is the sample I was going to post about the crash issue, http://www.mediafire.com/?aajakpfoe8utg24 __________________ Windows 11 Pro, CPU: Ryzen 9 5900X, GPU: GeForce RTX 3090 /w 512.95, Audio: HDMI to Yamaha RX-A3060 (5.1)

12th May 2011, 00:33	#13534 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	x86 builds work fine. It is only the MSVC x64 builds that are having problems. __________________ MPC-HC 2.2.1

12th May 2011, 00:33	#13535 \| Link
SamuriHL Registered User Join Date: May 2004 Posts: 5,351	I just built msvc2010 x86. No problem. I did not do an x64 build. __________________ HTPC: Windows 11, AMD 5900X, RTX 3080, Pioneer Elite VSX-LX303, LG G2 77" OLED

12th May 2011, 00:34	#13536 \| Link
VipZ Registered User Join Date: Jun 2009 Location: London Posts: 378	As far as I discovered about this issue ICL12 and MSVC2010 x64 behave the same way, while MSVC2010 x86 seems to never have an issue. I tested a MSVC2008 x64 build (ffdshow_rev3844_20110510_clsid_x64.exe) which crashes as well. With this test patch it would seem to fix 3 builds, but break 1. __________________ Windows 11 Pro, CPU: Ryzen 9 5900X, GPU: GeForce RTX 3090 /w 512.95, Audio: HDMI to Yamaha RX-A3060 (5.1) Last edited by VipZ; 12th May 2011 at 00:39.

12th May 2011, 00:58	#13537 \| Link
XhmikosR Registered User Join Date: Mar 2007 Location: Hellas (Greece) Posts: 543	Well, I don't use MSVC2008. Does the MCVS2010 x64 build crash, with or without the patch? __________________ My builds Notepad2-mod My Specs

12th May 2011, 00:59	#13538 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	The problem is with the files. I got three test files, MKV/MP4/FLV. Either the FLV crashes and the other two work, or vice versa. What bothers me is that the code is essentially the same, so I don't understand why the results are different. __________________ MPC-HC 2.2.1 Last edited by clsid; 12th May 2011 at 01:01.

12th May 2011, 01:04	#13539 \| Link
XhmikosR Registered User Join Date: Mar 2007 Location: Hellas (Greece) Posts: 543	If the MSVC2010 builds work I'm fine with it. If not then it's something someone should dig into more. __________________ My builds Notepad2-mod My Specs