ffdshow tryouts project: Discussion & Development

[MatLz]

Hi!

I've updated to 3237 but I'm in trouble with gamma correction:

A capture speaks more than a thousand words (http://sendspace.com/file/l88t4q)

What's the hell?:devil:

[tal.aloni]

Hi!

I've updated to 3237 but I'm in trouble with gamma correction:


Edit:
I see it now, modifying contrast triggers it.
starts with rev. 3233

[MatLz]

I'm also in trouble with sourceforge and mediafire:D....I can just say I think 3207 was ok.

[thuan]

thuan: could you do me a favor and try out the beta1 or beta2 build with the full processing mode to see if it drops frames like crazy? If the Intel guy wrote his code with an Intel graphics card, maybe you'll have better performance than the rest of us did. That would at least explain why he was able to get performance that is so much better than when tal.aloni used the code in ffdshow.
I will, on Monday as the computer with G45 is my computer at work. By full processing mode you meant Surface Overlay Post Processing mode right? And what did you mean by beta2? The last ffdshow-tryouts version is beta 6. I haven't used ffdshow for far too long (been using MPC-HC internal filter).

[onomatopellan]

@thuan:This is beta1 http://forum.doom9.org/showthread.php?p=1364814#post1364814
and this is the beta 2 http://forum.doom9.org/showthread.php?p=1365503#post1365503

I think this comes from the media types

I removed uncompress mediatypes but this is not a good idea because I guess that FFDShow DXVA may not be consulted for subtitles connection

I have done more tests and these are the results using ffdshow DXVA rev3237 in MPC-HC:

In my PC with Windows 7 32bits -> embedded subs of most files (sample (http://www.mediafire.com/?wnumkztyneo)) aren't detected. Subs are not shown

In the laptop Windows 7 64 bits -> embedded subs of most files aren't detected. Subs are not shown

In a PC with Windows Xp 32 bits -> All the embedded subs of my files are detected flawlessly. Subs are shown without problem

So maybe the problem is in the way Text input pin is connected in Windows 7? Can please somebody with Windows 7 confirm this?

[thuan]

Thanks to albain and tal.aloni that implemented DXVA and sub rendering with DXVA in ffdshow. I still have 2 problems with it though.

Sub bleeding and blocky
http://xs.to/thumb-ECA3_4B626276.jpg (http://xs.to/share-ECA3_4B626276.html)

And broken image when seeking that happens sometimes
http://xs.to/thumb-A38D_4B62643C.jpg (http://xs.to/share-A38D_4B62643C.html)

Tested at work on Intel G45, Windows Vista 64bit up to date BTW. I view my videos with Haali splitter. I also have the 9800GT with Windows 7 64bit at home and the 2nd problem happens there, too. I will check whether the first problem happens at my home computer configuration after work.

Thank you guys for the continuous development.

At home, the blocking problem when seeking is still the same. As for sub with DXVA, it simply does not work on my 9800GT :D. Driver is 196.21 on Windows 7 64bit.

[tal.aloni]

At home, the blocking problem when seeking is still the same. As for sub with DXVA, it simply does not work on my 9800GT :D. Driver is 196.21 on Windows 7 64bit.

what do you mean by "does not work"?
did you enable "post processing"? (see above)

[CiNcH]

We already added it in http://sourceforge.net/apps/trac/mpc-hc/changeset/1552
But this is only MPEG-2 Bitstream which only works for some nVIDIA GPU's, right? Think most GPU's still only do MPEG-2 MC and iDCT.

[albain]

@thuan:This is beta1 http://forum.doom9.org/showthread.php?p=1364814#post1364814
and this is the beta 2 http://forum.doom9.org/showthread.php?p=1365503#post1365503



I have done more tests and these are the results using ffdshow DXVA rev3237 in MPC-HC:

In my PC with Windows 7 32bits -> embedded subs of most files (sample (http://www.mediafire.com/?wnumkztyneo)) aren't detected. Subs are not shown

In the laptop Windows 7 64 bits -> embedded subs of most files aren't detected. Subs are not shown

In a PC with Windows Xp 32 bits -> All the embedded subs of my files are detected flawlessly. Subs are shown without problem

So maybe the problem is in the way Text input pin is connected in Windows 7? Can please somebody with Windows 7 confirm this?

Thanks, I didn't test your sample but if you say that it works on XP this confirms my thoughts : on XP directshow consults filters for uncompressed formats, not on vista/7

Here is a test build to confirm this (http://damienbt.free.fr/ffdshow_rev3240_20100130_dbt_dxva_subs.exe)

Please tell me if this solves the problem

[tal.aloni]

Hi!

I've updated to 3237 but I'm in trouble with gamma correction

should be fixed in rev. 3241

[MatLz]

should be fixed in rev. 3241Thank you.

[AiDz0r]

Hi guys, I'm on Windows 7 64-bit at the moment, and now I need some help using/installing FFDSHOW Video Encoder for "Sony Vegas Pro 9", I'm having trouble encoding with it, I have downloaded two different version which are the latest version thats "ffdshow_rev3200_20100112_clsid_icl10" and "ffdshow_rev3222_20100123_clsid_x64", when ever I try encoding no matter what encoding type I do, if its a H.263 or a Mpeg-4/Xvid my Sony Vegas crashes when ever it begins encoding, also would I get any junk or broken registry on my Windows 7 because its fresh and don't want to ruin it. Here's my log when it crashes;
Extra Information
File: C:\Users\...\AppData\Local\Sony\Vegas Pro\9.0\dx_video_grovel_x64.log
File: C:\Users\...\AppData\Local\Sony\Vegas Pro\9.0\dx_grovel_x64.log
File: C:\Users\...\AppData\Local\Sony\Vegas Pro\9.0\vst_grovel.log

Problem Description
Application Name: Vegas Pro
Application Version: Version 9.0c (Build 895) 64-bit
Problem: Unmanaged Exception (0xc0000005)
Fault Module: C:\Program Files\ffdshow\ffdshow.ax
Fault Address: 0x000000002BC5DFCB
Fault Offset: 0x000000000019DFCB

Fault Process Details
Process Path: C:\Program Files\Sony\Vegas Pro 9.0\vegas90.exe
Process Version: Version 9.0c (Build 895) 64-bit
Process Description: Vegas Pro
Process Image Date: 2009-10-25 (Sun Oct 25) 23:34:26

[tetsuo55]

But this is only MPEG-2 Bitstream which only works for some nVIDIA GPU's, right? Think most GPU's still only do MPEG-2 MC and iDCT.Yes, but the same is true for all DXVA options in MPC-HC and FFdshow, bistreaming only.

[HeadlessCow]

@thuan:This is beta1 http://forum.doom9.org/showthread.ph...14#post1364814
and this is the beta 2 http://forum.doom9.org/showthread.ph...03#post1365503

These earlier betas have three post-processing modes. The third is called Full post-processing. tal.aloni removed it from the newer builds because it was super slow, but the technique came from an article by a guy at Intel that said it should have been waaaaaaaay more than fast enough. I wanted to see if the difference was because he was testing with an Intel embedded GPU and those of us that tested the ffdshow build all have ATI or nVidia.

[onomatopellan]

Thanks, I didn't test your sample but if you say that it works on XP this confirms my thoughts : on XP directshow consults filters for uncompressed formats, not on vista/7

Here is a test build to confirm this (http://damienbt.free.fr/ffdshow_rev3240_20100130_dbt_dxva_subs.exe)

Please tell me if this solves the problem
Thanks albain but it doesn't work. :(
The problem continues in Windows 7 with most of my files. I only can see the subs in Graphstudio reconnecting the subtitles pin.

I also tried updating the ATI drivers (HD3450 in the PC and mobility HD4530 in the laptop) but no luck.

[albain]

Yes, I have spent some time on it this afternoon with no luck

Actually the connection to the text pin is done (with MPC) and the subtitles are received and parsed by the subtitles reader of ffdshow

... but they are not displayed

I'll continue to work on this, maybe Tal will have an idea

The only difference in the logs between ffdshow video and ffdshow dxva is a ReconnectOutput call in ffdshow video.

NAILED IT : the imgfilters are not initialized when the subtitles are loaded

[albain]

This is fixed in revision 3246 (embedded subtitles in DXVA)

[tal.aloni]

I discovered that enabling overlay can make seeking a bit unstable,
it seems that the DXVA API call to GetBuffer() might wait infinitely for a locked buffer to be unlocked. I tried to figure out why, but so far I couldn't.

maybe albain will have an idea. (right back at you, buddy :))

Tal

edit:
this may have something with the fact that we're voilating the API when we're requesting the uncompressed buffer address after the allowed time.

[albain]

I discovered that enabling overlay can make seeking a bit unstable,
it seems that the DXVA API call to GetBuffer() might wait infinitely for a locked buffer to be unlocked. I tried to figure out why, but so far I couldn't.

maybe albain will have an idea. (right back at you, buddy :))

Tal

edit:
this may have something with the fact that we're voilating the API when we're requesting the uncompressed buffer address after the allowed time.

I had this problem when working on multithreading

I had deadlocks that were caused by
1/ either the m_csCodecs_and_imgFilters lock
2/ or the fact that all the buffers are allocated and waiting to be delivered BUT there is a new compressed buffer coming and no more available buffers (GetDeliveryBuffer is locked)

The solution, when a seeking occur, in the NewSegment method (which is called) freeing all the buffers
Easier to tell than to do because some buffers are being processed, some others are being copied

I'll have a look at it tomorrow

[tal.aloni]

albain,
thanks, however, this seems to be occuring with DXVA 1.0 only.
it might be somehow connected to the fact that under windows 7 I get immidiate garbled seeking, and in XP it's usually prettier.

EDIT:
calling Sleep(1) befire calling GetBuffer seems to help more than a bit.
I'll test and commit if this is effective.

[albain]

albain,
thanks, however, this seems to be occuring with DXVA 1.0 only.
it might be somehow connected to the fact that under windows 7 I get immidiate garbled seeking, and in XP it's usually prettier.

EDIT:
calling Sleep(1) befire calling GetBuffer seems to help more than a bit.
I'll test and commit if this is effective.

If this doesn't work you can put a shared CCritsec dxvaLockBuffer
1/ NewSegment or brefore GetDeliveryBuffer (don't know which one causes the deadlock) : autolock(dxvaLockBuffer)

2/ Before calling GetBuffer : autolock(dxvaLockBuffer)

[onomatopellan]

This is fixed in revision 3246 (embedded subtitles in DXVA)
YES!! :D All my files works now. Thanks a lot!

[tal.aloni]

I managed to resolve the deadlock issue in rev. 3248

instead of deadlocking on skip, if the renderer is not ready after 50ms, the frame will not be post processed.
for now, this may create a tiny delay for subtitles (40ms on average, I'm not compensating yet), but it's way better than deadlocking. :)

Tal

[albain]

Glad you fixed it :cool:

[Casshern]

should be fixed in rev. 3241

Hi there is also a long standing bug with 48000 khz, 24 bit, lpcm mono sound. This is found on a lot Criterion BluRay disks. It is played back through ffdshow in slow motion. It is roughly half the speed, as if ffdshow produces only half the samples per second - maybe ffdshow internally still thinks its stereo even though it correctly displays: 48000 khz mono 24 bit as input. If you need a sample - tell me exactly how (what tools) and what you need.

[iron2000]

I artifacting I had with ffdshow DXVA is similar to thuan's (http://forum.doom9.org/showthread.php?p=1369038#post1369038).
The picture explodes on seek and the picture slows and desyncs, theres lag on switching in and out of full screen.

DXVA for MPCHC isn't perfect as well.
Its slow to keep up when seeking(no artifact but desyncs for quite a period).
Sometimes its gets slow and affects the switching in and out of full screen.

So far for me its better to use the CPU to decode video.
DXVA gives me the impression that using GPU to decode is much slower.
(I'm don't know a lot about video decoding so I may have the wrong impression.)

[tal.aloni]

Hi there is also a long standing bug with 48000 khz, 24 bit, lpcm mono sound

I'm pretty sure it has more to do with libavcodec (ffmpeg) than with ffdshow, in any way, to post a sample you'll need eac3to and mkvtoolnix,
use: eac3to "C:\00001.m2ts" --demux
to demux all of the tracks to the current directory, and then use mkvmerge (part of mkvtoolnix) to put the audio track inside mkv / mka, you can split it to several parts with predefined size. just upload a single part.

[Casshern]

I'm pretty sure it has more to do with libavcodec (ffmpeg) than with ffdshow, in any way, to post a sample you'll need eac3to and mkvtoolnix,
use: eac3to "C:\00001.m2ts" --demux
to demux all of the tracks to the current directory, and then use mkvmerge (part of mkvtoolnix) to put the audio track inside mkv / mka, you can split it to several parts with predefined size. just upload a single part.


eac3to created a file with the ending ".pcm". The GUI for MKVtoolnix 3.1.0.0 does not seem to recognize this as a valid format. Could you give me the correct commandline to process the pcm file?

[tal.aloni]

I have a suggestion to make ffdshow DXVA a bit more robust ...

you are right to point out that when some applications would try to use the DXVA decoder (avsp for instance), it would lead to problems.
and you are also right to point out that the DXVA decoder should be used only by video players.

I would not want to limit usage (keep in mind that some players have their own preferred list), but I wouldn't object turning on the white list by default. (one with a short list of popular players)

[tal.aloni]

eac3to created a file with the ending ".pcm".

interesting, I thought it was a compressed format.

you can use eac3to "C:\00001.m2ts" to view the list of streams,
identify the PCM track number, and then use eac3to "C:\00001.m2ts" 4:C:\1.flac
to encode it to flac (lossless), when 4 represents the number of the pcm track. mkvtoolnix will accept flac.

(I'm not sure the problem would persist with a flac though, but it's worth trying)

alternative suggestion: maybe TSMuxer can cut the the m2ts with the PCM

[Casshern]

interesting, I thought it was a compressed format.

you can use eac3to "C:\00001.m2ts" to view the list of streams,
identify the PCM track number, and then use eac3to "C:\00001.m2ts" 4:C:\1.flac
to encode it to flac (lossless), when 4 represents the number of the pcm track. mkvtoolnix will accept flac.

(I'm not sure the problem would persist with a flac though, but it's worth trying)

alternative suggestion: maybe TSMuxer can cut the the m2ts with the PCM

The problem only occurs with pure 48khz mono 24 bit tracks, as they are found on almost all criterion blurays. I will go with TSMuxer, because i suspect that the problem will not occur in another format. I will let you know when i am done with TSMuxer

[CiNcH]

Yes, but the same is true for all DXVA options in MPC-HC and FFdshow, bistreaming only.
I know yes. What I did not know however was that all GPU's with UVD2 and VP3 do support MPEG-2 Bitstream...

[STaRGaZeR]

I know yes. What I did not know however was that all GPU's with UVD2 and VP3 do support MPEG-2 Bitstream...

UVD2 doesn't support MPEG-2 bitstream, at least on Vista. Only MPEG-2 IDCT.

[Casshern]

interesting, I thought it was a compressed format.

you can use eac3to "C:\00001.m2ts" to view the list of streams,
identify the PCM track number, and then use eac3to "C:\00001.m2ts" 4:C:\1.flac
to encode it to flac (lossless), when 4 represents the number of the pcm track. mkvtoolnix will accept flac.

(I'm not sure the problem would persist with a flac though, but it's worth trying)

alternative suggestion: maybe TSMuxer can cut the the m2ts with the PCM

TSremuxer produces a "wav" file... playing this wavfile with mpc hc and ffdshow prefered yielded the following: ffdshow was not loaded and the filter used was waveparser. Interestingly when playing directly from the m2ts file the splitter passes it to ffdshow as l(pcm). So I made ffdshow to accept uncompressed. Now ffdshow is in the filterchain, right after waveparser. And everything works fine - it displays 48khz 24 bit mono (uncompressed) as input. This implies that the problem is due to one of the following:

1) The splitter parses 48khz mono 24 bit (l)pcm tracks from m2ts incorrectly - maybe screwing up the timestamps.

2) The splitter parses correctly (and tsremuxer and eac3to both worked - so it's unlikely that the parser in mpc hc is different) the input via (l)pcm in ffdshow somehow screw up the timestamps.

Now, as the tsremuxed wav file is of no use - how about i used chop a couple of secondes of the m2ts file (including video and all). Would that help to pinpoint the bug?

[tal.aloni]

Now, as the tsremuxed wav file is of no use - how about i used chop a couple of secondes of the m2ts file (including video and all). Would that help to pinpoint the bug?

that's what I meant, using tsmuxer to split the m2ts.

[CiNcH]

UVD2 doesn't support MPEG-2 bitstream, at least on Vista. Only MPEG-2 IDCT.
Think this depends on the decoder..

[Snowknight26]

No, it doesn't.

[CiNcH]

So the Wikipedia information is simply wrong?

[STaRGaZeR]

So the Wikipedia information is simply wrong?

Yes. Use DXVA Checker if you really want to know what modes are supported by your graphics card.

[CiNcH]

Does MS specify MPEG-2 Bitstream somewhere? What do those ID's without name in DXVAChecker mean?

EDIT:
Ah, I see... ModeMPEG-2_VLD would be MPEG-2 Bitstream.

[Kado]

I can't see the subtitles using ffdshow dxva rev. 3247 although they appear appear in the list. OSD also does not work. Tried with graphedit and mpc hc rev.1586. Surface overlay is enabled. W7 x64, EVR and updated DirectX.

[tal.aloni]

Kado,
Are you using nvidia GPU?

my guess is that beta 1 works for you:
http://iknowu.net/files/public/ffdshow/DXVAPostProc/ffdshow_rev3206_20100118-DXVA-Post-Processing-Beta%201.exe

(beta 1 does not violate DXVA GetBuffer() specs)

please also test beta 3:
http://iknowu.net/files/public/ffdshow/DXVAPostProc/ffdshow_rev3227_20100126-DXVAPostProcessing-Beta3.exe

(beta 3 is the last to lock the buffer for write operations, Beta 4+ locks it as read only)

Edit:
This issue should be fixed in rev. 3254,
we now lock the buffer for writing (the intel article suggested locking for read only to improve performance)
if you detect any change related to speed from 3253 to 3254, I would like to hear about it.

Tal

[tal.aloni]

during my post processing tests I encountered an issue with the latest nvidia drivers (196.21) under XP x64.

the overlayed image looked like this:
http://iknowu.net/files/public/ffdshow/DXVAPostProc/Nvidia-DXVA-Post-Processing-Colorspace-Driver-Issue.png

(probably wrong stride [a.k.a pitch] returned by the driver):

older drivers (190.38, 195.62) did not have this problem.

[avivahl]

during my post processing tests I encountered an issue with the latest nvidia drivers (196.21) under XP x64.

the overlayed image looked like this:
http://iknowu.net/files/public/ffdshow/DXVAPostProc/Nvidia-DXVA-Post-Processing-Colorspace-Driver-Issue.png

(probably wrong stride [a.k.a pitch] returned by the driver):

older drivers (190.38, 195.62) did not have this problem.Did you try the latest beta drivers? (196.34)
Did you report the problem to Nvidia?

[Gleb Egorych]

during my post processing tests I encountered an issue with the latest nvidia drivers (196.21) under XP x64.

Please also report it here --> http://forums.nvidia.com/index.php?showforum=33
It's possible that the bug will be fixed.

[tal.aloni]

I tested the nVidia issue further, it seems that after rev. 195.81 nVidia started using a different colorspace for the decoded surface (instead of NV12).
(Edit: this is true for XP x64, but Windows 7 x64 is not affected at all)

I guess I can learn about this new colorspace, write a method to overlay to it, and test adapter and driver revision (done today for different purposes) to choose the correct colorspace, but it's not a priority for me - driver rev. 195.62 works well.

p.s.
1. anybody with an Intel adapter tested DXVA surface overlay?
2. anybody with XP x86 experiencing this?
3. the new colorspace seems to be interlaced format.

[Casshern]

that's what I meant, using tsmuxer to split the m2ts.

Hi,

I made a small 5 sec sample, where you can hear the bug pretty clearly. Interestingly the video ends after 5 seconds and the audio is still playing another 5 seconds with mpc hc + ffdshow(as a audio decoder) at half speed:

http://www.mediafire.com/file/omtnmdnjiyy/sample.m2ts

Thanks very much for looking at this.

[Kado]

@tal.aloni
Thanks! rev3254 works properly.
Only the rendering quality is way worse than of MPC-HC's internal renderer.
http://kado.heliohost.org/kado/bts_720p_subs_compare.png
Subtitles texture resolution for MPC-HC was 1680x1050.
ffdshow was using default settings but I don't think they make any difference.
Embedded ASS subtitles.
I think this was always like this since the subtitle implementation in ffdshow.

[HeadlessCow]

ffdshow uses its own subtitle parsing code and it's... subpar ;) MPC-HC uses vsfilter (basically) and that's what all the fansubbers use to create the subs in the first place. mplayer/VLC use libass which supports nearly everything that vsFilter does (even the bugs) with a few exceptions. Unfortunately, having two strong libraries means that ffdshow gets kinda ignored. And until the recent DXVA work, it didn't matter anyways because you'd just use ffdshow+DirectVobSub if you wanted subs and MPC-HC with the internal sub renderer if you wanted DXVA with subs.

[avivahl]

Well, w/ libass having a lot of progress (http://code.google.com/p/libass/) in the past few months, I think ffdshow can gain a lot by using it for ass rendering (instead of the current code).