ffdshow tryouts project: Discussion & Development - Page 641

panda-34 · 17th December 2010, 22:24

Can an AviSynth script running in ffdshow on MPEG2 video somehow automatically determine what field is first? Or maybe can I reorder top-field-first video so that the script always gets its favorite bottom-field-first stuff? I don't seem to be getting meaningful results with GetParity().

adam777 · 17th December 2010, 23:09

Quote:

Originally Posted by clsid

libavcodec decodes to 16bit, hence the 16bit output.

Thanks for the quick reply, clsid.
So using libavcodec, even if I force, say, 32 bit output by allowing only 32 bit in output formats, I will basically output padded 16 bit? (and lose some information from the original 24 bit stream).

Are there any disadvantages to using libdts in this case?
It seems it outputs 24 bit as expected (actually 32 bit but I think I read somewhere about FFDShow not outputting 24 bit usually but padding it to 32 bit).
I used libavcodec as I'm not sure if/when libdts gets updated.

Thanks again.

clsid · 18th December 2010, 16:05

When software works, there is no need for constant updates. You can safely use libdts, which is also the default in ffdshow. That one decodes to 32-bit float by default.

adam777 · 18th December 2010, 16:48

Quote:

Originally Posted by clsid

When software works, there is no need for constant updates. You can safely use libdts, which is also the default in ffdshow. That one decodes to 32-bit float by default.

STaRGaZeR · 19th December 2010, 00:55

Quote:

Originally Posted by STaRGaZeR

@devs, I need you help.

I'm trying to use new ffmpeg functions. As I've always done, I export them from ffmpeg.dll putting them in ffmpeg.def, then I load them in Tlibavcodec so they can be used elsewhere. However, this time it's not working.

Here's a simple patch to show the issue: http://www.mediafire.com/?3jvbbagt9dajknq

The problem is that when dll->loadFunction(avfilter_graph_alloc,"avfilter_graph_alloc"); is called, the pointer is set to 0x00000000 instead of the proper address, causing ffdshow to crash. I can see (with DLL Export Viewer) that the function is apparently correctly exported. All the other functions are set to their proper addresses, but if I try to add this or any other function, it'll crash for the same reason. Any suggestions?

No one? Without this I can't even try to implement libavfilter's gradfun

sansnom05 · 19th December 2010, 02:26

Quote:

Originally Posted by STaRGaZeR

No one? Without this I can't even try to implement libavfilter's gradfun

Maybe you were trying to load it from ffmpeg-mt.dll instead of ffmpeg.dll?

STaRGaZeR · 19th December 2010, 04:11

Quote:

Originally Posted by sansnom05

Maybe you were trying to load it from ffmpeg-mt.dll instead of ffmpeg.dll?

Nope, check the patch. The 3 yadif functions load correctly, the new one doesn't. All of them are only in ffmpeg.dll.

sansnom05 · 19th December 2010, 08:12

Quote:

Originally Posted by STaRGaZeR

Nope, check the patch. The 3 yadif functions load correctly, the new one doesn't. All of them are only in ffmpeg.dll.

How and where you use this new function? Cause seems to me your avfilter_graph_alloc is not initialized, this will happen when you use ffmpeg-mt, right?

clsid · 19th December 2010, 17:23

@STaRGaZeR

Have you tried adding add this to avfiltergraph.h?
#ifdef __cplusplus
extern "C" {
#endif

STaRGaZeR · 19th December 2010, 18:40

Quote:

Originally Posted by sansnom05

How and where you use this new function? Cause seems to me your avfilter_graph_alloc is not initialized, this will happen when you use ffmpeg-mt, right?

That's the problem: the function is not even used, the patch only puts its pointer in Tlibavcodec. It compiles fine as it should, it's like ffdshow doesn't find the function in ffmpeg.dll at runtime and returns a NULL pointer, but according to the DLL viewer (and the code) it's there.

Quote:

Originally Posted by clsid

@STaRGaZeR

Have you tried adding add this to avfiltergraph.h?
#ifdef __cplusplus
extern "C" {
#endif

Same error unfortunately.

clsid · 19th December 2010, 20:29

After the rar update, I get this compile error with vs2008 for x64:

.\src\subtitles\Tstream.cpp(514) : error C2664: 'void (HANDLE,UNRARCALLBACK,LPARAM)' : cannot convert parameter 2 from 'overloaded-function' to 'UNRARCALLBACK'
None of the functions with this name in scope match the target type

No problem with x86 build. Any ideas?

sansnom05 · 19th December 2010, 22:36

Quote:

Originally Posted by clsid

After the rar update, I get this compile error with vs2008 for x64:

.\src\subtitles\Tstream.cpp(514) : error C2664: 'void (HANDLE,UNRARCALLBACK,LPARAM)' : cannot convert parameter 2 from 'overloaded-function' to 'UNRARCALLBACK'
None of the functions with this name in scope match the target type

No problem with x86 build. Any ideas?

Sorry it's my fault, forgot to change callback function declaration in this commit, though I did make the change in the patch I gave to XhmikosR months ago

. Will fix it now.

grayedout · 20th December 2010, 10:15

Need help with ffdshow x64 version.

I've got crash in ffdshow x64 when memory usage of the program exceeds 2GB. The program I'm developing is 64-bit and using 64-bit version of DirectShow. Main thread is creating several decoder objects and every object creates its own filtergraph which uses ffdshow x64 for decoding. As soon as memory working set of the program exceeds 2GB, program crashes when trying to create next filtergraph with ffdshow in it. Call stack shows that crash is somewhere in libavcodec.dll.

When using another codec (for example CoreAVC x64) in the same configuration, everything works fine even program's working set is 5-6Gb.

Any suggestions why this happens? Thanks in advance.

Reimar · 20th December 2010, 12:35

Quote:

Originally Posted by grayedout

Any suggestions why this happens? Thanks in advance.

Non-64-bit-safe coding. E.g. casting a pointer to an int (HANDLE type might be just as bad, I don't know for sure), or calling a function without including the proper header (should cause an error with C++ though, and for C you should set compiler options so any of these result in a compile error).

sansnom05 · 20th December 2010, 20:24

@clsid

Maybe you forget to copy vp3.c/vp3data.h/xiph.c/xiph.h from ffmpeg -> ffmpeg-mt after you added MT support for vp3/theora?

clsid · 20th December 2010, 22:48

Fixed

grayedout · 21st December 2010, 02:48

Quote:

Originally Posted by Reimar

Non-64-bit-safe coding.

Is there any chance to fix it in ffdshow x64?

grayedout · 21st December 2010, 09:03

Guys, I've tried this build - ffdshow_rev3690_20101220_xhmikosr_x64_MSVC2010.exe taken from the site from XhmikosR signature. And this version works fine so far. Program's working set is over 5GB and no crashes!

STaRGaZeR · 21st December 2010, 14:57

1 more reason to upgrade to VS2010 for generic builds

clsid · 21st December 2010, 16:07

There was a malloc related change in ffmpeg recently. So maybe it is just by using a recent ffdshow build the problem got fixed.

18th December 2010, 16:05	#12803 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	When software works, there is no need for constant updates. You can safely use libdts, which is also the default in ffdshow. That one decodes to 32-bit float by default. __________________ MPC-HC 2.2.1

19th December 2010, 17:23	#12809 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	@STaRGaZeR Have you tried adding add this to avfiltergraph.h? #ifdef __cplusplus extern "C" { #endif __________________ MPC-HC 2.2.1

19th December 2010, 20:29	#12811 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	After the rar update, I get this compile error with vs2008 for x64: .\src\subtitles\Tstream.cpp(514) : error C2664: 'void (HANDLE,UNRARCALLBACK,LPARAM)' : cannot convert parameter 2 from 'overloaded-function' to 'UNRARCALLBACK' None of the functions with this name in scope match the target type No problem with x86 build. Any ideas? __________________ MPC-HC 2.2.1

20th December 2010, 22:48	#12816 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	Fixed __________________ MPC-HC 2.2.1

21st December 2010, 16:07	#12820 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	There was a malloc related change in ffmpeg recently. So maybe it is just by using a recent ffdshow build the problem got fixed. __________________ MPC-HC 2.2.1

17th December 2010, 22:24	#12801 \| Link
panda-34 Registered User Join Date: Dec 2010 Posts: 4	Can an AviSynth script running in ffdshow on MPEG2 video somehow automatically determine what field is first? Or maybe can I reorder top-field-first video so that the script always gets its favorite bottom-field-first stuff? I don't seem to be getting meaningful results with GetParity().

20th December 2010, 10:15	#12813 \| Link
grayedout Registered User Join Date: Mar 2007 Posts: 4	Need help with ffdshow x64 version. I've got crash in ffdshow x64 when memory usage of the program exceeds 2GB. The program I'm developing is 64-bit and using 64-bit version of DirectShow. Main thread is creating several decoder objects and every object creates its own filtergraph which uses ffdshow x64 for decoding. As soon as memory working set of the program exceeds 2GB, program crashes when trying to create next filtergraph with ffdshow in it. Call stack shows that crash is somewhere in libavcodec.dll. When using another codec (for example CoreAVC x64) in the same configuration, everything works fine even program's working set is 5-6Gb. Any suggestions why this happens? Thanks in advance.

20th December 2010, 20:24	#12815 \| Link
sansnom05 Registered User Join Date: Aug 2010 Posts: 52	@clsid Maybe you forget to copy vp3.c/vp3data.h/xiph.c/xiph.h from ffmpeg -> ffmpeg-mt after you added MT support for vp3/theora?

21st December 2010, 09:03	#12818 \| Link
grayedout Registered User Join Date: Mar 2007 Posts: 4	Guys, I've tried this build - ffdshow_rev3690_20101220_xhmikosr_x64_MSVC2010.exe taken from the site from XhmikosR signature. And this version works fine so far. Program's working set is over 5GB and no crashes!