ffdshow tryouts project: Discussion & Development

[Dr Pizza]

There aren't any x86_64 CPUs without MMX, there aren't any x86_64 OSs that don't support MMX (win64 allows MMX in userspace, just not in the kernel), and ffmpeg doesn't support using SSE* without using MMX.
But it doesn't work, which seems the more important consideration to me. Furthermore, IsProcessorFeaturePresent returns 0 ("not present") for MMX (for 64-bit apps; for 32-bit apps it returns 1 ("present")).

[akupenguin]

Interesting. Then I wonder why no one has complained about x264, which uses cpuid exclusively and thus always enables MMX on win64.
I also wonder why MS decided not to support MMX. There are good reasons to use it: it's faster than SSE* in any case where your data doesn't fill a whole XMM register, e.g. processing a block <= 8 pixels wide.

[Dr Pizza]

Interesting. I wonder why no one has complained about x264, which uses cpuid exclusively and thus always enables MMX on win64.

It's quite possible that the problem is that the MMX routines don't actually work properly in x64, hence the broken behaviour. I'm not sure at the moment which ones are actually getting called.

[squid_80]

Furthermore, IsProcessorFeaturePresent returns 0 ("not present") for MMX (for 64-bit apps; for 32-bit apps it returns 1 ("present")).
Forget IsProcessorFeaturePresent. MS have obviously broken it on purpose to falsely report MMX as unavailable. As Akupenguin said the OS does support it, it's even possible to use it in inline assembly if you use Intel's compiler. There must be a bug in the MMX code that's causing it to crash. If you can get a crash report from virtualdub, post it here and I'll see if I can figure out what's going wrong.

[LoRd_MuldeR]

Yes, once same was for me too, and I have reported to Haali, but I got no answer:
http://forum.doom9.org/showthread.php?p=1001143#post1001143

It obviously is a ffdshow problem, as "Beta-2a" works okay and current SVN is broken...

[Peuj]

It obviously is a ffdshow problem, as "Beta-2a" works okay and current SVN is broken...

I don't reproduce your image issue but for me the sound is not sync with Haali renderer :confused:

[Px]

It's quite possible that the problem is that the MMX routines don't actually work properly in x64, hence the broken behaviour.
Because of the move to the 64-bit ISA and the elimination of MMX, 3DNow! and the x87 FPU, Windows applications that include inline assembly code will not compile on Windows x64.
Early reports claimed that the operating system scheduler would not save and restore the x87 FPU machine state across thread context switches. Observed behavior shows that this is not the case: the x87 state is saved and restored, except for kernel-mode-only threads. Nevertheless, the most recent documentation available from Microsoft states that the x87/MMX/3DNow! instructions may not be used in long mode.
And also
AMD x64 stated very clear that MMX and others are not supported in x64 mode. SSE and up are x64 compatible according to AMD.

[Dr Pizza]

There must be a bug in the MMX code that's causing it to crash.
It's not crashing; it's just rendering a black video (though occasionally a narrow band on the right edge appears showing what I believe to be some correctly decoded video). I'll have a look closer tonight to see if it's anything easy.

[LoRd_MuldeR]

I don't reproduce your image issue but for me the sound is not sync with Haali renderer :confused:

Audio is perfectly in sync here, only the video is screwed... :(

// EDIT

ffdshow_rev1193_20070522_clsid.exe has the same problem!

[Dr Pizza]

OK, it looks like I need to fill out more of the MMX intrinsics for VC++.

Once it's done in C/SSE2 intrinsics it would be sensible to replace it all with a .asm file to actually use MMX, I suppose (unless it really is going away), but for the time being it's much easier to write SSE2 intrinsics than mess about with stupid x86 asm, not least as I have no idea how parameter passing works.

[chipzoller]

This may be considered an unimportant feature to be developed of ffdshow, but I'm wondering if any work is being done to strengthen the decoding of soft vobsubs? It currently DOES work however not very well. I've only dealt with vobsubs muxed in mkv with AVC content, but I've noticed that ffdshow will sometimes not decode if there is any backwards seeking, or if forward seeking is done without letting the video playback for a minute or thereabouts.

[Leak]

Here's yet another update of my AviSynth filter, hopefully it's the last before checking this into SVN (modulo a documentation update):

* Fix aspect ratio handling (i.e. actually handle AR where it really matters)
* Don't create a new AviSynth clip in setOutFmt if frame size and AR are still the same (should make opening a file a bit quicker when the script takes long to initialize)
* Reset the "Enable buffering" checkbox when resetting the filter settings
* Quench aspect ratio DPRINTF spam

Patch (https://sourceforge.net/tracker/?func=detail&atid=867362&aid=1676882&group_id=173941) (against rev. 1193)
Download (http://leak.no-ip.org/AviSynth/ffdshow/ffdshow_AviSynth_rev1193_20070523.exe)
Documentation (http://leak.no-ip.org/AviSynth/ffdshow/docs/html/en/avisynth.htm) (still as out of date as last time, sorry)

@kurt: could you please try again? The aspect ratio should be correct now, or at least it was for me with that test clip of yours... :)

np: Mikkel Metal - Stand Guard (Brone And Wait)

[kurt]

yeah, it works fine now! Thank you, Leak!

[haruhiko_yamagata]

I just noticed a bug with ffdshow and anamorphic video!

The video was encoded with Xvid at an resolution of 688x560 and a PAR auf 140:129.
The resulting video plays 100% fine at 4:3 in both MPlayer and VLC Media Player.

Unfortuantely this is what happens with MPC + ffdshow:
It works for me. Could you pin point the revision that this bug begins, if you have time?

// EDIT
Please uncheck "Allow output format changes during playback" and try again.

[thuan]

I just noticed a bug with ffdshow and anamorphic video!

The video was encoded with Xvid at an resolution of 688x560 and a PAR auf 140:129.
The resulting video plays 100% fine at 4:3 in both MPlayer and VLC Media Player.

I can't reproduce the problem here works fine as it should. 945G latest driver for Vista. MPC (latest drevil) tested with VMR and Haali. ffdshow rev.1193 by drevil.

[Peuj]

I don't reproduce your image issue but for me the sound is not sync with Haali renderer :confused:

It works for me. Could you pin point the revision that this bug begins, if you have time?

// EDIT
Please uncheck "Allow output format changes during playback" and try again.

Just to say that unchecking "Allow output format changes during playback" solves my issue with the sound not sync.

Thanks

[Episode]

@LoRd_MuldeR, I'm betting this has something to do with graphic card's drivers or operating system. It works fine for me with Nvidia 7800GS with 165.01 driverset under Windows XP.

[haruhiko_yamagata]

I would like to rename "Use overlaymixer" -> "Set pixel aspect ratio in output media type" and add tooltip hint
formerly called "Use overlay mixer".

Checked: Advanced connection method that includes the information about pixel aspect ratio (SAR) and interlacing will be used to connect with the down stream filter (usually video renderer).
Indeterminate state: First try advanced connection method, if failed try classic connection method.

and rename "HW deinterlacing"->"Set interlacing related flag in output media type"
formerly called "HW deinterlacing".

Send the interlacing related information obtained from the upper stream or ffdshow's internal decoders to the down stream.
Down stream filter (usually video renderer) will take this information and try to deinterlace.
This information will be used just for reference and the actual output depends on the implementation of the down stream filter.
Please fix my English and anything.

[Leak]

[...]hopefully it's the last before checking this into SVN (modulo a documentation update)
Yep, it sure was. Checked into SVN as revision 1194.

Since the only difference between my last build and this one is some whitespace changes in the source code and said documentation update I'm not going to post a new build. :)

np: Kettel - Mwoeb (Re: Through Friendly Waters)

[fastplayer]

Please fix my English and anything.
Small correction to the 1st tooltip:
Indeterminate state: First try advanced connection method, if it fails, then try classic connection method.
In the 2nd tooltip please don't start a new line after each period.

[Eragon4ever]

I would say:

Indeterminate state: First try advanced connection method, if it fails try classic connection method.

[Leak]

Agreed - those options really are named a bit awkward nowadays.

I would like to rename "Use overlaymixer" -> "Set pixel aspect ratio in output media type" and add tooltip hint

Hmmm...

Unchecked: Use classic connection method
Checked: Use an advanced connection method that includes pixel aspect ratio (SAR) and interlacing information when connecting with the next filter (usually a video renderer).
Indeterminate/grayed: Try advanced connection method first and fall back to classic connection method if it fails.

(formerly called "Use overlay mixer")

and rename "HW deinterlacing"->"Set interlacing related flag in output media type"

I would have called it "Set interlace flag in output media type":

Send interlacing related information obtained from the input stream or ffdshow's internal decoders to the next filter.
Some filters (like video renderers) will use this information to deinterlace the video if neccessary.

This is just for informing the downstream filters - the actual result will depend purely on the implementation of these filters.

(formerly called "HW deinterlacing")

Please fix my English and anything.

I put the "formerly called ..." at the end of the tooltip, since information about what the option does is probably more relevant. :)

EDIT: Whoa... 2 other replies while I was writing my reply... :D

np: Kettel - Whom (Re: Through Friendly Waters)

[LoRd_MuldeR]

Please uncheck "Allow output format changes during playback" and try again.

Yup, that fixes the problem :) :) :)

Do I still need to find the revision that introduced the bug?


@LoRd_MuldeR, I'm betting this has something to do with graphic card's drivers or operating system. It works fine for me with Nvidia 7800GS with 165.01 driverset under Windows XP.

I've got an ATI Radeon 9800 Pro, running with latest Catalyst 7.4 drivers under Windows XP.

[GmorG McRoth]

Anyone else noticed performance drop between
ffdshow_rev1187_20070520_clsid.exe and ffdshow_rev1193_20070522_clsid.exe
I may be wrong and my testing is unscientific (using task manager), but it seems like with ffdshow_rev1193_20070522_clsid.exe i'm getting about 3-7% more CPU usage (tested on mpeg1 file and divx5 file)

My CPU is prescott 3.0 GHz
GFX is GeForce FX 5700
I'm using MPC with Haali renderer.

[Haali]

Btw, why do you even need that overlay mixer checkbox? I offer both mediatypes (VideoInfo2 first and VideoInfo after it) in my filters, and it seems to work quite good without any need for tunable settings. As for interlaced output, you can easily change the interlace mode with a dynamic mt change. If the only thing that you change is dwInterlaceFlags, then it doesn't cause any problems.

[haruhiko_yamagata]

Yup, that fixes the problem :) :) :)OK, then I'll think what it means.
Do I still need to find the revision that introduced the bug?No.

[LoRd_MuldeR]

OK, then I'll think what it means.

:thanks:

[haruhiko_yamagata]

Btw, why do you even need that overlay mixer checkbox? I offer both mediatypes (VideoInfo2 first and VideoInfo after it) in my filters, and it seems to work quite good without any need for tunable settings. As for interlaced output, you can easily change the interlace mode with a dynamic mt change. If the only thing that you change is dwInterlaceFlags, then it doesn't cause any problems.I agree most people including me don't need "Use overlaymixer" check box. I think this check box is historical stuff. On Windows Xp, it's almost useless.
On Windows 2000, when system default renderer is selected, overlaymixer will be used if checked, while old renderer will be used if unchecked.

As for HW deinterlacing, it's required because the interlacing flag is not always reliable.

Anyway, thank you for coming here.

[Peuj]

URL http://www.comq.ru/user/alex/pirates2/pirates2.mp4
Mpeg4AVC HighProfile video.
Picture is broken using ffdshow, mplayer or KMP.
Look normal using CoreAVC 1.2.

Confirmed with rev 1133, and it plays fine with CoreAVC 1.3 too :) (You sould report this in the coreavc thread, because this is the 1st time when coreavc is able to decode something that ffdshow isn't :) )

No matter, if I remux to mkv. Does the whole file produce this, or only this splitted chunk?

I get artifacts when playing that in MPlayer, and I still get artifacts after remuxing to mkv, but if I demux to raw .264 and play that then it works. (had to demux with MP4Box; mkvextract refuses.) So... maybe a bug in lavc's AVC1 bitstream parser?

Hi,

So it's a libavcodec problem? does somebody has report the problem to the ffmpeg team?

[Thunderbolt8]

anything like multithreading/multi-cpu support planned for ffdshow ?

[haruhiko_yamagata]

@fastplayer, Eragon4ever, Leak
Thank you. Committed as rev 1200.

[Jeremy Duncan]

Hello,

I'm glad to see Leak's tweak added to FFDshow.

I just downloaded and installed FFDshow version 1198, clsid.
I then setup FFDshow as I usually do.
I set output to yv12, input to all supported raw video.
I then used only avisynth, and set the osd to show the nessessary frames, so I could tweak the new setting.
But if showed no frame change.

http://www.imagehosting.com/out.php/t682121_Whahappen.jpg (http://www.imagehosting.com/out.php/i682121_Whahappen.jpg)

SetMemoryMax(1024)
FluxSmoothT(3)
ColorMatrix(Mode="Rec.601->Rec.709",scaling=2,threads=2)
MT("SeeSaw(NRlimit=0, NRlimit2=5, Sstr=2.40, Szp=1, Slimit=50, Sdamplo=16, Spower=1, sootheT=95, SdampHi=39)",3)
lanczosresize(1680, 1050)

I used the settings in post # 2
Link (http://forum.doom9.org/showthread.php?t=115727)

The frontend I used was MPC, the one I lined to in the link above.

Previously, with Leak's other avisynth tweaked ffdshow, there was a few frames shown ahead and back, so I know that it shouldn't be zero.

Please fix this leak. :)

Edit. Oh, the movie was blade 1, the ntsc sddvd version.
If you look at page 6 in the link it will show you previous results using Leak's tweak.

[multiblitz]

Has anyonw looked into this bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=1695996&group_id=173941&atid=867360

"When I build a graph with Haali-splitter, VC-1 codec from Microsoft, I have
a fine playback at 24 fps (HD-DVD-rip from my own Discs onto my media,
server, playing *.evo).

When I integrate ffdshow into the chain, re-clock reports not only 30fps,
but audio and video are heavily out of sync. It does not matter if I use
ffdshow as raw-postprocessor or if I use ffshow as VC-1-decoder as well. As
soon as ffdshow is in the video-chain, video and audio is out of sync
(beta2 release). "

?

If not, could you please be so kind ? I would love to use ffdshow as my playback/pq-tuning solution as well for HD-DCD, as my cinema has a pretty big screnn and ffdshow really shines...

As haali and all other active members are together here: Would it be possible to taggle this bug together ?

[haruhiko_yamagata]

As haali and all other active members are together here: Would it be possible to taggle this bug together ?
I looked into this, I found the timestamps are set to increase 33.36ms (should be 41.6ms) for every frame.
I found no interlacing related flags are set for either for each samples or connection info.

I looked into livavcodec's vc1 decoder, it does not seem to find any information that can fix this issue. Perhaps I passed over it or it's not implemented (stored as "reserved").

But in fact MS decoder can decode properly connected to Haali's splitter.

When microsoft's DMO is called from ffdshow, the DMO does not return any usefull information.

When ffdshow is connect to the DMO's output pin, it does not send any usefull information.

So the information is hidden in the stream, but I cannot find it.
Haali, any advice is wellcome. Should I go to your thread?

[LoRd_MuldeR]

Please uncheck "Allow output format changes during playback" and try again.

I noticed that this (http://forum.doom9.org/showpost.php?p=1006288&postcount=1281) bug is related to "Allow output format changes during playback" and "Set pixel aspect ratio in output media type". If I disable both of them, I get 'correct' video but without any pre-scaling applied. So it's not 4:3, as it should be. If I check "Set pixel aspect ratio in output media type" only, then I still get no pre-scaling! If I check "Allow output format changes during playback" only, then I get the bug, where the lower half of the video frame is filled with crap. Only both options enabled give good result!

[haruhiko_yamagata]

@LoRd_MuldeR
I still cannot reproduce.
I have added a small work around for this issue.
Please see if rev 1203 works.
If I check "Set pixel aspect ratio in output media type" only, then I still get no pre-scaling!
Output format change occurs just before the first frame is shown because AVI splitters do not give the SAR info in the connection process. So technically it's "during playback". I know it's not very user friendly but how should it be explained in the dialog?

[LoRd_MuldeR]

Output format change occurs just before the first frame is shown because AVI splitters do not give the SAR info in the connection process.

Thank you for looking into that issue.
I will test your workaround as soon as there's a new build available...

[LoRd_MuldeR]

@LoRd_MuldeR
I still cannot reproduce.
I have added a small work around for this issue.
Please see if rev 1203 works.

Yes, in rev 1203 I cannot reproduce the error any more :) :) :)

Nevertheless I still need to check both options ("Allow output format changes during playback" and "Set pixel aspect ratio in output media type") to make the video renderer pre-scale the video to the required aspect of 4:3. This combination worked with previous build too.

[haruhiko_yamagata]

Yes, in rev 1203 I cannot reproduce the error any more :) :) :)

Nevertheless I still need to check both options ("Allow output format changes during playback" and "Set pixel aspect ratio in output media type") to make the video renderer pre-scale the video to the required aspect of 4:3. This combination worked with previous build too.
Thank you for testing.
It's OK, because it's the default settings. On beta2a, it was necessary to change "Allow output format changes during playback" from intermediate state to checked.

[Haali]

I looked into this, I found the timestamps are set to increase 33.36ms (should be 41.6ms) for every frame.
I found no interlacing related flags are set for either for each samples or connection info.

I looked into livavcodec's vc1 decoder, it does not seem to find any information that can fix this issue. Perhaps I passed over it or it's not implemented (stored as "reserved").

But in fact MS decoder can decode properly connected to Haali's splitter.

When microsoft's DMO is called from ffdshow, the DMO does not return any usefull information.

When ffdshow is connect to the DMO's output pin, it does not send any usefull information.

So the information is hidden in the stream, but I cannot find it.
Haali, any advice is wellcome. Should I go to your thread?
The samples I have here have 30000/1001 fps interlaced set in the sequence header. I didn't investigate further, but I guess the stream is actually progressive with rff flags set similar to mpeg-2 case. The DMO Wrapper + DMO then ignore the interlaced part and output 24000/1001 fps progressive video.

Edit: I've checked the frame headers, and the streams indeed use TFF/RFF flags. I'll copy them into sample properties, and adjust timestamps slightly to account for RFF, but that's all I can do in the splitter.

[haruhiko_yamagata]

The samples I have here have 30000/1001 fps interlaced set in the sequence header. I didn't investigate further, but I guess the stream is actually progressive with rff flags set similar to mpeg-2 case. The DMO Wrapper + DMO then ignore the interlaced part and output 24000/1001 fps progressive video.

Edit: I've checked the frame headers, and the streams indeed use TFF/RFF flags. I'll copy them into sample properties, and adjust timestamps slightly to account for RFF, but that's all I can do in the splitter.
Thank you very much. Currently RFF is not implemented in ffdshow, but that's our job to do:).

[_xxl]

Is libavcodec compiled with mingw gcc 4.2.0 broken?
http://i11.tinypic.com/4kk4136.jpg
http://i18.tinypic.com/5yu20xx.jpg
Maybe it doesn't crash if SSE2 is not used?

[haruhiko_yamagata]

Is libavcodec compiled with mingw gcc 4.2.0 broken?
Maybe it doesn't crash if SSE2 is not used?
Sorry for that. The message box should be hidden. I have changed it from AV_LOG_ERROR to AV_LOG_WARNING.
It doesn't crash unless SSE2 is used.

[thuan]

In the latest drevil's build (r.1210), liba52 and libdts don't work they are not loaded and showed as not found in the about page -> version details. My computer is a vista core2duo.

[clsid]

Sorry for that. The message box should be hidden. I have changed it from AV_LOG_ERROR to AV_LOG_WARNING.
It doesn't crash unless SSE2 is used.
Could you perhaps add an option (in ffdshow.ax) to write these messages (all av_log_* types) to text file (%TEMP%\ffdshow.log)? I think that would be useful.

[_xxl]

(r.1210)
Removed.
New test build.Fixed SSE2 encoding.Patch by clsid.
MinGW GCC 4.2.0 is needed to compile libavcodec.
Please test it.
http://rapidshare.com/files/33688376/ffdshow_rev1213_20070527_xxl.exe.html
http://rapidshare.com/files/33688474/sse2.patch.html

[JarrettH]

How about a new beta?:eek::cool:

[multiblitz]

Ok, I uploaded a trailer in EVO:

http://www.megaupload.com/?d=8EGB8DWJ

Haali, If it helps, here is a sample I uploaded which comes form a HD-DVD.

[clsid]

Here are two different builds of libavcodec. Everyone please test the performance for both encoding and decoding.

http://rapidshare.com/files/33863226/libavcodectest.rar.html

[LoRd_MuldeR]

Here are two different builds of libavcodec. Everyone please test the performance for both encoding and decoding.

http://rapidshare.com/files/33863226/libavcodectest.rar.html

H.264 playback performance:

[libavcodec_404.dll]
User: 108s, kernel: 20s, total: 129s, real: 136s, fps: 88.2, dfps: 83.8
User: 107s, kernel: 22s, total: 129s, real: 136s, fps: 88.0, dfps: 83.7

[libavcodec_420.dll]
User: 104s, kernel: 25s, total: 129s, real: 136s, fps: 88.0, dfps: 83.8
User: 104s, kernel: 25s, total: 129s, real: 136s, fps: 88.3, dfps: 83.8