ffdshow tryouts project: Discussion & Development

[panda-34]

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]

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]

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]

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.

:thanks:

[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]

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]

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]

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]

@STaRGaZeR

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

[STaRGaZeR]

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.

@STaRGaZeR

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

Same error unfortunately.

[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?

[sansnom05]

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]

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]

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]

@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]

Fixed ;)

[grayedout]

Non-64-bit-safe coding.

Is there any chance to fix it in ffdshow x64?

[grayedout]

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]

1 more reason to upgrade to VS2010 for generic builds :D

[clsid]

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

[Gser]

Install vfwxvid and x264 to get them back. They were removed because it was pointless to include them in the first place and a major hassle to keep updating them (hence they weren't).

[MicMec]

Thanks for the prompt response clsid,

Looks as though my problem with AC3 in AVI container was related to a couple of corrupt videos and actually works fine with all the other files in the same format - My bad.

I also discovered that the black screen on pause issue goes away if I disable "queue output samples". Not sure what this feature does but it doesn't seem to have caused any other issues.

Now a very happy camper.

[iron2000]

I'm still experiencing the same freezing problem (http://forum.doom9.org/showthread.php?p=1461102#post1461102) with recent builds.

[Gingko]

Hello,

I am trying to decode digital TV with audio as "AAC in transport stream with a synchronization layer (LOAS) and a multiplex layer (LATM)" used in some countries, and to find codecs working with this.

I more or less succeeded with Monogram AAC Decoder (http://blog.monogram.sk/janos/2009/03/08/monogram-aac-decoder-0960/), but I had to modify and recompile it in order to get it working, because the proper Media Type was not exposed to DirectShow (although internally used). Now it works, but with some instabilities.

This Media Type, as far as I understand correctly, is defined (at least by Microsoft (http://msdn.microsoft.com/en-us/library/dd390676%28v=VS.85%29.aspx)) as MEDIASUBTYPE_MPEG_LOAS, and its value is {00001602-0000-0010-8000-00AA00389B71}.

Monogram AAC Decoder is a wrapper for libfaad2, which is used also by ffdshow-tryouts, so logically, ffdshow-tryouts should be able to decode it, but unfortunately, it does not expose this Media Type either.

I'm wondering if it wouldn't be possible to include it in future versions of ffdshow-tryouts in order to make possible, or more easy, to get ffdshow-tryouts decoding AAC+LOAD+LATM?

If you need some sample, you can use this file :
http://gingko.homeip.net/misc/TDT_Continente_2010-12-09_19-20-02.ts

This is a 30 seconds record of a full DVB-T Transport Stream multiplex (from Portuguese TV) with 4 TV channels (plus an empty one), all encoded as H264 (for video) and AAC+LATM+LOAS for audio.

Regards,

Gingko

[robpdotcom]

I have a question about decoding TrueHD:

From what I've read, all TrueHD streams are 24 bit, but sometimes are actually 16 bit padded with 8 empty bits.

So, which output format should be selected to output bit-exact decoded PCM streams? Do you need to know if there are 8 empty bits, and select 16 bit in those cases, or should 24 bit be used for all TrueHD streams?

[xv]

I already made a feature request for Indeo5/I.263 for ffdshow. Since nobody seemed to be interested in that I tried it myself.
I was able to add I.263 support, but I fail with Indeo 5:
For Indeo 5 I have to build ffmpeg.dll myself. Unfortunately that doesn´t work, because all mingw64 versions I tried produce global symbols without underscores in front (I read that this was changed in april 2010).
Unfortunately ffdshow seems to expect underscores in front of global symbols. Can someone post a link to a working version of mingw64 or tell me how to change mingw64 behavior?

[clsid]

Have you also tested the i263 with multiple samples? It was disabled in the past because it did not work properly. But that may have been fixed since then.

Use the sezero mingw64 builds. Or better yet, make a x86 build.

[xv]

Have you also tested the i263 with multiple samples? It was disabled in the past because it did not work properly. But that may have been fixed since then.
No, not all, but most samples, work:
-With PB-frames enabled non-keyframes are corrupted
-With "Strict H.263 Compliance" enabled it doesn´t work at all. (using normal H263 decoder, the files play fine).
Both problems are ffmpeg problems.
All other files work fine and nothing results in a crash.
Maybe I´m able to fix at least the second problem.
Use the sezero mingw64 builds. Or better yet, make a x86 build.That are the builds I used and it contains a readme:
Compatibility Notice: ** No leading underscore **
------------------------------------------------------------------------
Unlike the other builds from mingw-w64 up to 2010-04-27, these new win64
targetting toolchains do *not* prepend an undersocore to the symbols and
follows the MSVC x64 convention. Therefore, any of the link libraries
from previous toolchains are incompatible with the ones created by these
new builds.
That seems to be the problem. Is there a build from 2010-04-27 or older available somewhere? What build should I use for x86? The sezero build only supports x64.

[clsid]

You can find a MinwG32 installer on the ffdshow SourceForge page.

I have just added Indeo5 support.

Can you upload non-working I263 samples? It is always useful to have such samples. Here is FFmpeg bug tracker is case you want to report it:
https://roundup.ffmpeg.org/

[xv]

Both samples are using PB-Mode:

ftp://ftp1.mplayerhq.hu/MPlayer/samples/V-codecs/I263/i263.avi
ftp://ftp1.mplayerhq.hu/MPlayer/samples/V-codecs/I263/i263_2.avi

In Strict mode the files are H.263 compatible, the only difference seems to be the header, my idea is to detect standard H.263 at the beginning of ff_intel_h263_decode_picture_header and just call h263_decode_picture_header if it is standard H.263.

I uploaded file:
https://roundup.ffmpeg.org/issue2449

Note that I.263 was not just disabled in ffdshow, but treated as a extension of H.263 rather than a different codec in several parts of the code, I fixed that to make it work.

Edit:
I was able to compile ffmpeg.dll x86 and fixed the Intel I.263 bug with strict H.263 compliance. Not sure if the PB-frames bug is as easy.
I submitted patch here: https://roundup.ffmpeg.org/issue2449
Edit 2:
Can you (or somebody else) forward this patch to ffmpeg-devel, I´m too stupid for mailing lists.

[PaulJBis]

Hi all:

I've recently been trying to convert a DVD that I have to AVI/Xvid, using ffdshow's Xvid encoding, but I had it crash on me every time. My setup is the following:

-I'm using Windows 7 64 bit.
-Virtualdub 1.9.11 (and 1.9.9 before that). Stock binary from the official download site (in other words, it's the 32 bit version).
-ffdshow v. 3154, 8 dec. 2009 (or, in other words, the last version marked as stable in the official download site (which is also 32-bit)).
-I import the VOBs using the MPEG2 importer plugin for Virtualdub (but before that I was also using DGIndex and Avisynth to frameserve).
-I then resize the video to my desired size, get into ffdshow and, in the "Encoder" section, I pick Xvid. I then set it up for "2 pass encoding, 1st pass".
-...And then, when I hit "Save as AVI", Virtualdub crashes.

I have pasted below the crash report generated by Virtualdub:

VirtualDub crash report -- build 32842 (release)
--------------------------------------

Disassembly:
0f4f9800: 00c0 add al, al
0f4f9802: c785dcfcffff01 mov dword ptr [ebp-324], 00000001
000000
0f4f980c: 8985e4fcffff mov [ebp-31c], eax
0f4f9812: ff1504c2520f call dword ptr [0f52c204]
0f4f9818: 6a00 push 00h
0f4f981a: 8bd8 mov ebx, eax
0f4f981c: ff1508c2520f call dword ptr [0f52c208]
0f4f9822: 8d8528fdffff lea eax, [ebp-2d8]
0f4f9828: 50 push eax
0f4f9829: ff150cc2520f call dword ptr [0f52c20c]
0f4f982f: 85c0 test eax, eax
0f4f9831: 750c jnz 0f4f983f
0f4f9833: 85db test ebx, ebx
0f4f9835: 7508 jnz 0f4f983f
0f4f9837: 6a02 push 02h
0f4f9839: e82d960000 call 0f502e6b
0f4f983e: 59 pop ecx
0f4f983f: 68170400c0 push c0000417
0f4f9844: ff154cc2520f call dword ptr [0f52c24c]
0f4f984a: 50 push eax
0f4f984b: ff1510c2520f call dword ptr [0f52c210]
0f4f9851: 8b4dfc mov ecx, [ebp-04h]
0f4f9854: 33cd xor ecx, ebp
0f4f9856: 5b pop ebx
0f4f9857: e817960000 call 0f502e73
0f4f985c: c9 leave
0f4f985d: c3 ret
0f4f985e: 8bff mov edi, edi
0f4f9860: 55 push ebp
0f4f9861: 8bec mov ebp, esp
0f4f9863: ff350425670f push dword ptr [0f672504]
0f4f9869: e8fa790000 call 0f501268
0f4f986e: 59 pop ecx
0f4f986f: 85c0 test eax, eax
0f4f9871: 7403 jz 0f4f9876
0f4f9873: 5d pop ebp
0f4f9874: ffe0 jmp eax
0f4f9876: 6a02 push 02h
0f4f9878: e8ee950000 call 0f502e6b
0f4f987d: 59 pop ecx
0f4f987e: 5d pop ebp
0f4f987f: e9b2feffff jmp 0f4f9736
0f4f9884: 33c0 xor eax, eax
0f4f9886: 50 push eax
0f4f9887: 50 push eax
0f4f9888: 50 push eax
0f4f9889: 50 push eax
0f4f988a: 50 push eax
0f4f988b: e8ceffffff call 0f4f985e
0f4f9890: 83c414 add esp, 14h <-- FAULT
0f4f9893: c3 ret
0f4f9894: 8bff mov edi, edi
0f4f9896: 55 push ebp
0f4f9897: 8bec mov ebp, esp
0f4f9899: 83ec20 sub esp, 20h
0f4f989c: 8b4508 mov eax, [ebp+08h]
0f4f989f: 56 push esi
0f4f98a0: 57 push edi
0f4f98a1: 6a08 push 08h
0f4f98a3: 59 pop ecx
0f4f98a4: bebc15580f mov esi, 0f5815bc
0f4f98a9: 8d7de0 lea edi, [ebp-20h]
0f4f98ac: f3a5 rep movsd
0f4f98ae: 8945f8 mov [ebp-08h], eax
0f4f98b1: 8b450c mov eax, [ebp+0ch]
0f4f98b4: 5f pop edi
0f4f98b5: 8945fc mov [ebp-04h], eax
0f4f98b8: 5e pop esi
0f4f98b9: 85c0 test eax, eax
0f4f98bb: 740c jz 0f4f98c9
0f4f98bd: f60008 test [eax], 08h
0f4f98c0: 7407 jz 0f4f98c9
0f4f98c2: c745f400409901 mov dword ptr [ebp-0ch], 01994000
0f4f98c9: 8d45f4 lea eax, [ebp-0ch]
0f4f98cc: 50 push eax
0f4f98cd: ff75f0 push dword ptr [ebp-10h]
0f4f98d0: ff75e4 push dword ptr [ebp-1ch]
0f4f98d3: ff75e0 push dword ptr [ebp-20h]
0f4f98d6: ff1500c2520f call dword ptr [0f52c200]
0f4f98dc: c9 leave
0f4f98dd: c20800 ret 0008
0f4f98e0: 8bff mov edi, edi
0f4f98e2: 55 push ebp
0f4f98e3: 8bec mov ebp, esp
0f4f98e5: 51 push ecx
0f4f98e6: 53 push ebx
0f4f98e7: 8b450c mov eax, [ebp+0ch]
0f4f98ea: 83c00c add eax, 0ch
0f4f98ed: 8945fc mov [ebp-04h], eax
0f4f98f0: 648b1d00000000 mov ebx, fs:[00000000]
0f4f98f7: 8b03 mov eax, [ebx]
0f4f98f9: 64a300000000 mov fs:[00000000], eax
0f4f98ff: 8b db 8bh

Built on Aegis on Fri Dec 24 13:18:44 2010 using compiler version 1400

Windows 6.1 (Windows Vista x64 build 7600) []

EAX = 0018efb8
EBX = 00000001
ECX = 00000000
EDX = 00000000
EBP = 00000000
ESI = 0d3d47d8
EDI = 0d43a088
ESP = 0018f28c
EIP = 0f4f9890
EFLAGS = 00200206
FPUCW = 18f004
FPUTW = 0003

Crash reason: unknown exception 0xc0000417

Crash context:
An exception occurred in module 'ffdshow'...

...while passing start message to video compressor (w32videocodecpack.cpp:337).

Pointer dumps:

EAX 0018efb8: 00010001 76eedec6 00000001 00000000 0018f000 0018efec 00000000 0018f004
ESI 0d3d47d8: 0f579ba4 0f579be8 0d4350f4 0d43510c 0d43a088 0d417268 00000000 00000000
EDI 0d43a088: 0f55cb04 0d435600 0d435600 00000001 00000003 00000384 0002123b 00000190
ESP 0018f288: 00000000 0f4f9890 00000000 00000000 00000000 00000000 00000000 0f408407
0018f2a8: 00000000 0d4350f8 0d4353f0 00000001 0f4fd3ba 0dd80000 0d3cd750 00000060
0018f2c8: 00000001 00000000 00000000 00000000 0f4f9356 00000000 00000001 0d4353f4
0018f2e8: 0f3f66ab 00010381 00000000 00000250 00000140 00000000 00000000 00000000

Thread call stack:
0f4f9890: ffdshow!DllGetClassObject [0f2b0000+246430+3460]
0f4f9890: ffdshow!DllGetClassObject [0f2b0000+246430+3460]
0f408407: ffdshow!configureEnc [0f2b0000+106a40+519c7]
0f4fd3ba: ffdshow!DllGetClassObject [0f2b0000+246430+6f8a]
0f4f9356: ffdshow!DllGetClassObject [0f2b0000+246430+2f26]
0f3f66ab: ffdshow!configureEnc [0f2b0000+106a40+3fc6b]
0f4eb20d: ffdshow!configureEnc [0f2b0000+106a40+1347cd]
0f4edc08: ffdshow!configureEnc [0f2b0000+106a40+1371c8]
02d940c5: ff_vfw!DriverProc [02d90000+3f58+16d]
741b1759: MSVFW32!ICSendMessage [741b0000+1728+31]
0057e97a: VDVideoCompressorVCM::Start()
76ef36fa: ntdll!RtlImageNtHeader [76ec0000+32fe4+716]
76ef32f2: ntdll!RtlImageNtHeader [76ec0000+32fe4+30e]
758b14d1: kernel32!HeapFree [758a0000+114bd+14]
005b306d: free()
005b308c: free()
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
005b308c: free()
00577bd8: VDResamplerGenerateTable()
0057005c: VDResamplerSeparableTableRowStage8SSE41::Process()
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
76eedea3: ntdll!RtlFreeHeap [76ec0000+2de25+7e]
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
76eedf72: ntdll!RtlAllocateHeap [76ec0000+2dec6+ac]
005b306d: free()
005b308c: free()
005b308c: free()
0049f9a6: ?$vdfastvector_base::_reserve_always()
76eedea3: ntdll!RtlFreeHeap [76ec0000+2de25+7e]
005b306d: free()
005b308c: free()
005b308c: free()
0055f19a: VDPixmapUberBlitterGenerator::~VDPixmapUberBlitterGenerator()
0055724c: VDPixmapResampler::Init()
75bc4a70: USER32!GetMonitorInfoA [75ba0000+24a21+4f]
75bc4efa: USER32!EnumDisplayDevicesA [75ba0000+24c48+2b2]
75bc4adc: USER32!GetMonitorInfoA [75ba0000+24a21+bb]
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
0057005c: VDResamplerSeparableTableRowStage8SSE41::Process()
76eee20c: ntdll!RtlInitUnicodeString [76ec0000+2e0a8+164]
76eedf72: ntdll!RtlAllocateHeap [76ec0000+2dec6+ac]
005b2fb6: malloc()
0f4eda8c: ffdshow!configureEnc [0f2b0000+106a40+13704c]
02d94125: ff_vfw!DriverProc [02d90000+3f58+1cd]
741b1759: MSVFW32!ICSendMessage [741b0000+1728+31]
005b2fb6: malloc()
005b5097: realloc()
005b526e: realloc()
0041a6ae: Dubber::InitOutputFile()
0041c0f3: Dubber::Init()
0041c0fa: Dubber::Init()
75bbc9e6: USER32!GetWindowLongA [75ba0000+1c9ac+3a]
75bc2d97: USER32!UpdateWindow [75ba0000+22d12+85]
0046309e: VDProject::RunOperation()
004134c7: SaveAVI()
76edf88a: ntdll!NtCallbackReturn [76ec0000+1f878+12]
00523ff9: VDGetSaveFileName()
004608ca: VDProject::SaveAVI()
004528b1: SaveAVI()
00465890: VDProjectUI::SaveAVIAsk()
0046c4e6: VDProjectUI::MenuHit()
75bb6ec0: USER32!GetClassNameW [75ba0000+16b04+3bc]
004794a0: VDUIFrame::DefProc()
0046da41: _catch$?MainWndProc@VDProjectUI@@IAEJIIJ@Z$0()
00465ac0: VDProjectUI::WndProc()
00479b65: VDUIFrame::StaticWndProc()
75bb6238: USER32!gapfnScSendMessage [75ba0000+15fc8+270]
75bb68ea: USER32!gapfnScSendMessage [75ba0000+15fc8+922]
75bb6899: USER32!gapfnScSendMessage [75ba0000+15fc8+8d1]
76ed00e6: ntdll!KiUserCallbackDispatcher [76ec0000+100b8+2e]
75bb7d31: USER32!LoadStringW [75ba0000+17c12+11f]
75bdeec0: USER32!PeekMessageA [75ba0000+3ed58+168]
75bbced4: USER32!GetAncestor [75ba0000+1cebf+15]
75bb8112: USER32!DispatchMessageA [75ba0000+18103+f]
00452596: WinMain@16()
005b78db: __tmainCRTStartup()
758b3677: kernel32!BaseThreadInitThunk [758a0000+13665+12]
76ef9d72: ntdll!RtlInitializeExceptionChain [76ec0000+39d0f+63]
76ef9d45: ntdll!RtlInitializeExceptionChain [76ec0000+39d0f+36]

-- End of report


If you guys need more information, please ask. Apologies if I've skipped some of the existing protocol to report bugs.

[DMD]

Good evening and happy holidays

I apologize if the question has already been posted,
I could not do a thorough search.

What is the difference between the versions:

1 - icl12
2 - MSVC2010
3 - MSVC2008

THANKS

[clsid]

@PaulJBis
You should use the normal Xvid codec. Encoding MPEG-4 with ffdshow is inferior, buggy, and has recently been removed.

@DMD
Read the first post and the last few pages of this topic.

[clsid]

@xv
I will have a look at your patches and if they work I will apply them to our ffdshow trunk.

[xv]

I made I full patch for ffdshow to revision 3701 (attached to this post). supports I263 except PB-mode without strict H.263 compliance (according to http://wiki.multimedia.cx/index.php?title=I263 it uses an old version of enhanced pb-frame mode, ffmpeg doesn´t seem to support that).
Therefore I called the codec "Intel H.263 (incomplete)".

Edit:
You´re really fast, I see you already added I.263. Just my patch(s) for intelh263dec.c are still missing.

[PaulJBis]

@PaulJBis
You should use the normal Xvid codec. Encoding MPEG-4 with ffdshow is inferior, buggy, and has recently been removed.



Oh, okay then. However, I also tried with Xvid 1.2.2, and it also crashed, although it did on the second pass.

[LigH]

Current poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) result:

4× "must have!"
1× "need fixes" -- probably already solved
5× "nice to have"
1× "don't care"

Well, more or less a 10:1 for "keep MJPEG".

I hope it has any value.

[nevcairiel]

You forget about the thousands of people that just use ffdshow, but would never even bother to read any forum about it ;)

[lych_necross]

Current poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) result:

4× "must have!"
1× "need fixes" -- probably already solved
5× "nice to have"
1× "don't care"

Well, more or less a 10:1 for "keep MJPEG".

I hope it has any value.
Well, it verifies what I thought. <opinion>MJPEG should be kept for the time being.</opinion>

[clsid]

I count "nice to have" as "don't care" rather than "must have!". So the poll results are up to different interpretation. And polls like these are biased to begin with.

Skimming through that topic I for example see than someone voted to keep it because he needs to to decode videos from his digital camera. No decoders are going to be removed! The discussion is solely about the encoder.

But don't worry. It won't be removed. For now. This may change in the future.

[Blight]

Hi Guys,
Some recent change(s) to the FFDShow API broke backward compatibility in the 'IffDecoder' interface (the 'putParamStrW' function now crashes due to incompatible headers). Is it possible to update the Delphi header files to the most recent version and possibly keep backward compatibility in future builds?

[clsid]

Please figure out which change broke the API. Your program is a user of the API, so you can test it better. If you post a patch, I will apply it.

Edit: It is probably due to r3603/r3516:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&revision=3616
I am not sure what the proper solution would be. Perhaps adding a dummy function?

[THX-UltraII]

i m using mpc-hc lastest build and ffdshow latest (dl-ed from http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/).

problem is that my subtitles flicker a lot during a movie. what could cause this?

[Blight]

clsid:
I'm not trying to get backward compatibility as I realize it's probably a lost cause. What I'm trying to do is modify my code to be compatible with the current builds, but the Delphi header translation on the SVN is 13 months old and no longer compatible.
I was hoping one of the devs would update the delphi headers and from now on when changes are made, they would be made to a different class (i.e. iffdecoder2, iffdecoder3, etc...) thus maintaining compatibility from now on. I tried doing it myself, but I don't think I'm doing it right as I keep getting crashes.

P.S.
Backward compatibility has been broken at least once before this current issue, that's why I'm asking ...

[Sebastiii]

clsid:
I'm not trying to get backward compatibility as I realize it's probably a lost cause. What I'm trying to do is modify my code to be compatible with the current builds, but the Delphi header translation on the SVN is 13 months old and no longer compatible.
I was hoping one of the devs would update the delphi headers and from now on when changes are made, they would be made to a different class (i.e. iffdecoder2, iffdecoder3, etc...) thus maintaining compatibility from now on. I tried doing it myself, but I don't think I'm doing it right as I keep getting crashes.

P.S.
Backward compatibility has been broken at least once before this current issue, that's why I'm asking ...

Hi,

This is FFDShowAPI that we use in mediaportal -> all is working good so i hope that it's working for you too :)
FFDShowAPI Mediaportal (http://www.mediafire.com/?uhmjo81fzyonmbi)

Edit :
This is the patch that works on FFDShow (small modification on using FFDShow (mediaportal) and FFDShowAPI (FFDShow) and also Copyright).
FFDShowAPI Diff (http://www.mediafire.com/?b3dgaf4vciqyqno)

Cheers,
Seb.

[clsid]

I shall commit that patch.

[Sebastiii]

I shall commit that patch.

Thank you :)

clsid:
I'm not trying to get backward compatibility as I realize it's probably a lost cause. What I'm trying to do is modify my code to be compatible with the current builds, but the Delphi header translation on the SVN is 13 months old and no longer compatible.
I was hoping one of the devs would update the delphi headers and from now on when changes are made, they would be made to a different class (i.e. iffdecoder2, iffdecoder3, etc...) thus maintaining compatibility from now on. I tried doing it myself, but I don't think I'm doing it right as I keep getting crashes.

P.S.
Backward compatibility has been broken at least once before this current issue, that's why I'm asking ...

For the Delphi API, i think you should comment out this line in delphi\IffDecoder_com.pas :

Line 504 : function getPostproc(postprocPtr:ppointer):HRESULT;stdcall;

I think with that all should be ok :)
Seb.

[LigH]

I count "nice to have" as "don't care" rather than "must have!". So the poll results are up to different interpretation. And polls like these are biased to begin with.

Yes, it is possibly biased ... but as I already mentioned, ffdshow's MJPEG encoder is exceptional in quality. There is no known substitute for me. In contrast to e.g. MPEG4-ASP and MPEG4-AVC codecs where we have Xvid and x264 as much more practical solutions for end users.

Well -- I am relieved. :cool: :thanks:

[xv]

I found out that ffmpeg supports neither standard pb-frame nor enhanced correctly. Not sure if it´s a regression or it never worked.

I just noticed you forget to add CODEC_ID_H263I in TimgFilterPostproc.cpp. Or was this intentional?

[Snowknight26]

ffdshow still seems to have issues doing colorspace conversions from BGR24, including a couple of crashes referring ffmpeg.dll (that don't seem to reproduce with the ffmpeg cli).

Sample: http://stfcc.org/misc/ffdshow.fraps.bug.rar