ffdshow tryouts project: Discussion & Development

[MatLz]

Originally Posted by tal.aloni

should be fixed in rev. 3241

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

Originally Posted by CiNcH

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]

Originally Posted by albain

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

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]

Originally Posted by 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.

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]

Originally Posted by 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.

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]

Originally Posted by albain

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

YES!! 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

[Casshern]

Originally Posted by tal.aloni

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

Originally Posted by Casshern

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]

Originally Posted by tal.aloni

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]

Originally Posted by clsid

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]

Originally Posted by Casshern

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