ffdshow tryouts project: Discussion & Development

[ikarad]

A development branch : I made the developements on a branch apart of the trunk (main development line). See subversion for more info

auzentech xfi ? No auzentech had the *good* idea to encrypt the stream between the software and the driver.
Unless we get to know the encryption key and algorithm (this is possible), there is nothing to do for them. I advise you to grab one of the new or future radeon card

no, I have creative xfi titanium, not auzentech.

Your branch, is it to allow decoding of DTS-HD because I don't understand?

if not isn't possible to allow to decoding dts-hd ?


To finish I won't buy a new radeon because I have a geforce gtx280.

[tal.aloni]

libavcodec vs libdts or libavcodec vs liba52 ? is libavcodec better?

IMO libavcodec is better. (by the way, I think it should be our default AC3 / DTS decoder)

[albain]

@rpm7200 : libavcodec decodes in 16 bits depth whereas liba52 can decode at 32 bits so with a better quality.
Actually this was the case last time I checked (2 months ago)

@ikarad : I was just explaining what a subversion branch is, but it has been merged to the trunk yesterday. So now revisions 3161 or greater will give you HD audio bitstream, but not with a xfi
You need a HDMI 1.3 output : a radeon 5xxx, one of the last nvidia series (don't know the reference), or an asus xonar
Also, there is no DTSHD decoder out yet (open source I mean) so only bitstream can get you DTS HD

[jmone]

Also, there is no DTSHD decoder out yet (open source I mean)....

Do you see adding DTSHD decoding as somthing that will happen in the short, medium, or long term?

Thanks

[Mark_A_W]

Do you see adding DTSHD decoding as somthing that will happen in the short, medium, or long term?

Thanks


As far as I understand, DTS has kept their intellectual property confidential (why wouldn't they..), so there isn't enough information for anyone to write a decoder.

(I don't know how plain DTS decoders "happened".)

[THX-UltraII]

where can I find the latest version Albain? I can only find beta 6 @ http://ffdshow-tryout.sourceforge.net/download.php

[albain]

Try this link but it is too fresh : nobody has posted any build yet

https://sourceforge.net/projects/ffdshow-tryout/files/

Otherwise this website that has daily builds :
http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64

[XhmikosR]

THX-UltraII: You can find new builds here (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca95e79d7d0540e1e1).

[leeperry]

IMO libavcodec is better. (by the way, I think it should be our default AC3 / DTS decoder)
liba52 decodes in 32float, libavcodec 16int only...from what this page says, you should always decode lossy audio with the highest accuracy to avoid roundings errors(especially if you post-process your audio afterwards): http://mp3decoders.mp3-tech.org/24bit.html

well, libdts is also 32float but it sounds terrible :scared:

[THX-UltraII]

THX-UltraII: You can find new builds here (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca95e79d7d0540e1e1).

I see that people at this moment talk about version 54 beta of ffdshow. I still cannot find this build. Or does this link have the latest Albain integrated version? http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/

[tal.aloni]

THX-UltraII,
Albain has merged his changes into the main svn branch,
just use the latest build. (from xvidvideo.ru or XhmikosR link)

[THX-UltraII]

thxz!

I need the x86 version because reclock is not in x64 yet. However, I see two different versions: a 'normal' and a 'sse icl11' version. When do you pick the 'icl 11' version? I have a Intel Core2Quad 6600

[khagaroth]

I posted an updated custom_messages.iss file on the tracker as the new Unicode installer needs it to be in UTF-8 or else it doesn't display correctly. Can someone who understands Japanese and/or Chinese verify that the conversion went fine?

[Betsy25]

Can anyone take a look at the problems I have when using ffdshow to play .VOB files (MPEG2) with equally named .SRT subs.

The subs lose sync as soon as jump forward/backward is used.

It doesn't matter whether I set ffdshow to libavcodec or libmpeg2

I can only play it correctly (subs keep synced even when jumping back/forward) by forcing MPC-HC to use its internal MPEG Audio and MPEG PS/TS/PVA source filters.

http://rapidshare.com/files/308449631/VOB_01_1.rar (20MB)

[stumped]

sorry if this has been answered before, but i'm looking at getting a new receiver that support HDMI 7.1 audio. and i know that beofre, you couldn't pass DolbyHD or DTS-HD without first first converting to flac to do lcpm. In the new ffdshow, i saw you can "pass" DTS-HD and DolbyHD through HDMI. can someone please explain to me this, i am very intrigued because i have my blu-rays in .mkv right now and if i get the new receiver, i'd like to know if i can continue going mkv adding in the new DolbyHD and DTS-HD or if i'll have to use powerdvd and make my movies into AVCHD .iso's.

[mikelebron]

First page under setup:

http://forum.doom9.org/showthread.php?t=151151


sorry if this has been answered before, but i'm looking at getting a new receiver that support HDMI 7.1 audio. and i know that beofre, you couldn't pass DolbyHD or DTS-HD without first first converting to flac to do lcpm. In the new ffdshow, i saw you can "pass" DTS-HD and DolbyHD through HDMI. can someone please explain to me this, i am very intrigued because i have my blu-rays in .mkv right now and if i get the new receiver, i'd like to know if i can continue going mkv adding in the new DolbyHD and DTS-HD or if i'll have to use powerdvd and make my movies into AVCHD .iso's.

[horvathd]

Recently I updated ffdshow from rev. 2737 to 3154 and my problem is that the new version can't change the font weight to bold when I use a OpenType (.otf) font. As soon as I converted the font to TrueType (.ttf) with FontForge then it changes the weight to bold.

[fuzz!]

albain: I see you checked in "Created directory 'branches/DXVA'."

You just teasing or we gonna see that soon? :D

[Ger]

@fuzz!
http://forum.doom9.org/showthread.php?p=1355831#post1355831

[Sub-zero]

Hi gentlemen :d
Are there any near-in-future plans to add support for more override tags for the subtitle filter of ffdshow?

This is very great filter. the rendering is so light on cpu, actually it can perfect if more support for ass tags is added :o

Playing softsubbed HD h.264 footage with VSFilter is really painful for my p4 cpu. Even with CoreAVC its really eating out the cpu when playing subtitles with VSfilter.

Thanks very much :thanks:

[THX-UltraII]

In the 3167 release note I see Added option to disable jitter correction for audio decoder.

When do you choose this option?

[XhmikosR]

ffdshow Audio Decoder-->Decoder options-->Jitter correction.

[THX-UltraII]

ffdshow Audio Decoder-->Decoder options-->Jitter correction.

I know, but WHEN does someone needs to check or uncheck this?

[XhmikosR]

Oh, you are right, I misread your post.

[THX-UltraII]

Oh, you are right, I misread your post.

and do you have any thought why someone would need to disable this?

[tal.aloni]

and do you have any thought why someone would need to disable this?

apparently some people still uses an old DTS encoder that does not support 23.976 timecodes, so they use 24hz timecodes instead.
when they mux the 24hz DTS with 23.976 video, it may produce a jitter in the range of +-150 ms.
ffdshow starts correcting the jitter at >100ms, so the badly encoded audio track produces video stutter, if you have such an encode, and prefer a slight audio jitter over video stutter,
you would want to disable the jitter correction mechanism.

(I have a sample of such an encode, if somebody is curious)

AC3Filter offers this ability as well.

it can also be useful on some other scenarios, IMO, the ability of the audio decoder to modify the timecodes of (ultimately) the entire decoding chain is something that you want to be able to disable, even if it doesn't really matter for regular usage.

Tal

[73ChargerFan]

apparently some people still uses an old DTS encoder that does not support 23.976 timecodes, so they use 24hz timecodes instead.
Tal,
Do you know which DTS encoders do this?
Thanks.

[markanini]

Any chance of seeing more of the postprocessing video filters from mplayer like uspp and pp7? Regular pp also has options I don't see in ffdshow according to the mplayer manual. Would be nice to play with for some low quality sources...

[avivahl]

Quick question (and I'm sorry if it has been discussed in the passed 497 pages of this thread :P):
Is there a difference between the "High quality YV12 to RGB conversion" checkboxes in the "Output" page and the "RGB conversion" page?

[fastplayer]

Is there a difference between the "High quality YV12 to RGB conversion" checkboxes in the "Output" page and the "RGB conversion" page?
Nope.

[albain]

Hi all,

I am happy to announce that DXVA is now nearly working

I have finished the import from MPC-HC project (harder than I expected)

Now, I have the following, issues, Tetsuo55 or Casimir666 may have an idea :
1/ I have a green picture (although the input pin bih info from the EVR are identical between MPC and FFDShow). I think this could come from the libavcodec context ??
2/ It works only with MPCHC, not with WMP12

Merry christmas by the way :)

[Sebastiii]

Great news Damien :)
Merry christmas to you and your family :)
Seb.

[avivahl]

Hi all,

I am happy to announce that DXVA is now nearly working

I have finished the import from MPC-HC project (harder than I expected)

Now, I have the following, issues, Tetsuo55 or Casimir666 may have an idea :
1/ I have a green picture (although the input pin bih info from the EVR are identical between MPC and FFDShow). I think this could come from the libavcodec context ??
2/ It works only with MPCHC, not with WMP12

Merry christmas by the way :):goodpost:!!!

[madshi]

apparently some people still uses an old DTS encoder that does not support 23.976 timecodes, so they use 24hz timecodes instead.
when they mux the 24hz DTS with 23.976 video, it may produce a jitter in the range of +-150 ms.
Not sure what you're talking about. A DTS/AC3 encoder takes a specific numbers of samples per frame (usually 48000) and compresses them into a DTS/AC3 frame. The DTS/AC3 encoder does not really care about the audio FPS, let alone change it. Usually the DTS/AC3 encoder does not even *KNOW* which FPS the audio source has. And it doesn't need to know...

[tetsuo55]

Hi all,

I am happy to announce that DXVA is now nearly working

I have finished the import from MPC-HC project (harder than I expected)

Now, I have the following, issues, Tetsuo55 or Casimir666 may have an idea :
1/ I have a green picture (although the input pin bih info from the EVR are identical between MPC and FFDShow). I think this could come from the libavcodec context ??
2/ It works only with MPCHC, not with WMP12

Merry christmas by the way :)We will have to wait for casimir for that issue

[flanger216]

Not sure what you're talking about. A DTS/AC3 encoder takes a specific numbers of samples per frame (usually 48000) and compresses them into a DTS/AC3 frame. The DTS/AC3 encoder does not really care about the audio FPS, let alone change it. Usually the DTS/AC3 encoder does not even *KNOW* which FPS the audio source has. And it doesn't need to know...

Agreed, based on my audio engineering experiences. DAW software (Sonar & Pro Tools) care about frame rates on import, but after that, fps and video timecodes completely fall out of the equation. I have seen issues in NLEs (especially Avid) where there's a mismatch between drop and nondrop timecodes between the audio and video tracks, but that just results in a slight pitch-shift when you conform them for render. Regardless, I've never rendered nor seen a render where timecode mismatches resulted in a constant, built-in jitter. Not that it couldn't happen; I've just never encountered it.

[clsid]

@Albain

I have some suggestions for the DXVA implementation in ffdshow.

1) Please make it a separate filter (new GUID and file). That way people can use it without having to register the standard ffdshow filter. It also keeps the ffdshow code cleaner, because there is no need for any DXVA related workarounds and special casings. The DXVA filter itself will also stay much simpler. Little code is shared between the DXVA stuff and the rest of ffdshow, to thing should be kept separate to avoid making the ffdshow code even more complex than it already is.
2) Don't reuse the presets code from ffdshow. That is too complex and user-unfriendly. Just a few checkboxes should be sufficient for the DXVA filter. For example, "Use DXVA if:" [x] executable equals [wmplayer.exe;mpc-hc.exe], [x]width >= [value], [x]height >= [value], and maybe a few others.

[SamuriHL]

I agree with clsid on this one. That would be an awesome implementation and far easier to maintain, as well.

[rsd78]

Hi all,

I am happy to announce that DXVA is now nearly working

I have finished the import from MPC-HC project (harder than I expected)

Now, I have the following, issues, Tetsuo55 or Casimir666 may have an idea :
1/ I have a green picture (although the input pin bih info from the EVR are identical between MPC and FFDShow). I think this could come from the libavcodec context ??
2/ It works only with MPCHC, not with WMP12

Merry christmas by the way :)

Thanks for all your great work Albain.

From what you can tell will it be possible to implement DXVA + subs within any directshow app (i.e. WMC)?

[tetsuo55]

@Albain

I have some suggestions for the DXVA implementation in ffdshow.

1) Please make it a separate filter (new GUID and file). That way people can use it without having to register the standard ffdshow filter. It also keeps the ffdshow code cleaner, because there is no need for any DXVA related workarounds and special casings. The DXVA filter itself will also stay much simpler. Little code is shared between the DXVA stuff and the rest of ffdshow, to thing should be kept separate to avoid making the ffdshow code even more complex than it already is.
2) Don't reuse the presets code from ffdshow. That is too complex and user-unfriendly. Just a few checkboxes should be sufficient for the DXVA filter. For example, "Use DXVA if:" [x] executable equals [wmplayer.exe;mpc-hc.exe], [x]width >= [value], [x]height >= [value], and maybe a few others.We decided on enabling DXVA exactly the same way as music bitstreaming (a checkbox), so its completely seperated from the codecs.

Is that in line with what you are suggesting?

[saint-francis]

@Albain

I have some suggestions for the DXVA implementation in ffdshow.

1) Please make it a separate filter (new GUID and file). That way people can use it without having to register the standard ffdshow filter. It also keeps the ffdshow code cleaner, because there is no need for any DXVA related workarounds and special casings. The DXVA filter itself will also stay much simpler. Little code is shared between the DXVA stuff and the rest of ffdshow, to thing should be kept separate to avoid making the ffdshow code even more complex than it already is.



I'm not sure I'm following you correctly here. If it were separate, what would the point of it be? Why not just use the MPC HC stand alone filter?

[STaRGaZeR]

I'm not sure I'm following you correctly here. If it were separate, what would the point of it be? Why not just use the MPC HC stand alone filter?

This. Also not using ffdshow presets is just silly IMO.

[albain]

@clsid

the current code is clean in my opinion as there are very few code insertions in the existing classes but rather a few new classes : a new decoder that derivates from TvidecodecLibavcodec (that won't appear in the codecs section because it is preset-based), the DXVA allocator, and the H264 and VC1 DXVA classes

I added a new dialog called "hardware acceleration" with 2 checkboxes to enable DXVA/H264 but maybe it will be better to put these in the output section has bitstream for audio but there may be a need of additional options : for example DXVA may require to select a video adapter.
MPCHC has the ability to detect it easily by associating the video window the right adapter but FFDShow does not

I will post when it will work a debug build to gather the opinions and the SVN patch

About the separate filter, I kindof disagree with your point of view because I am thinking about people who have lower CPU and who would use a preset with DXVA for high def videos, and another preset for lowres videos to get benefits of subtitles, postprocessing...
However I am totally opened to discussions ;-)

http://damienbt.free.fr/Capture.PNG

[saint-francis]

Albain, could you explain how this will all work? It is my understanding from MPC HC that the DXVA decoder needs to connect directly to the render. Is this still the case? If not then will we be able to use this with DirectShowSource for avisynth decoding? I'm kind of at a loss here since it has been stated in this thread that DXVA woudn't be implemented in FFDShow due to the aforementioned limitations.

[tetsuo55]

Albain, could you explain how this will all work? It is my understanding from MPC HC that the DXVA decoder needs to connect directly to the render. Is this still the case? If not then will we be able to use this with DirectShowSource for avisynth decoding? I'm kind of at a loss here since it has been stated in this thread that DXVA woudn't be implemented in FFDShow due to the aforementioned limitations.You will lose all post-processing options, just like mpc-hc

[leeperry]

apparently some people still uses an old DTS encoder that does not support 23.976 timecodes, so they use 24hz timecodes instead.
well, unchecking this option on 23.976 FLAC/h264 MKV files(@48.000Hz w/ Reclock) gives completely desynced audio...I think there's a hell lot of jitter in 23.976 MKV files(easy to see in HR), so I'm leaving it checked :p

[Mangix]

would this work in EVR under XP? It's only possible to do so within VMR9 and not EVR in MPC.

[hoborg]

would this work in EVR under XP? It's only possible to do so within VMR9 and not EVR in MPC.

No. Rules are simple to make DXVA working:

WinXP - VMR9
Vista/Win7 - EVR

[ikarad]

Albain, one question:
Is it possible to add support of PGS (subtitle form blu-ray) subtitles in a new version of ffdshow because subtitles form blu-ray aren't recognized by ffdshow?

[clsid]

@clsid

the current code is clean in my opinion as there are very few code insertions in the existing classes but rather a few new classes : a new decoder that derivates from TvidecodecLibavcodec (that won't appear in the codecs section because it is preset-based), the DXVA allocator, and the H264 and VC1 DXVA classes

I added a new dialog called "hardware acceleration" with 2 checkboxes to enable DXVA/H264 but maybe it will be better to put these in the output section has bitstream for audio but there may be a need of additional options : for example DXVA may require to select a video adapter.
MPCHC has the ability to detect it easily by associating the video window the right adapter but FFDShow does not

I will post when it will work a debug build to gather the opinions and the SVN patch

About the separate filter, I kindof disagree with your point of view because I am thinking about people who have lower CPU and who would use a preset with DXVA for high def videos, and another preset for lowres videos to get benefits of subtitles, postprocessing...
However I am totally opened to discussions ;-)

http://damienbt.free.fr/Capture.PNG
None of the options in ffdshow video decoder configuration apply to DXVA, so it would be silly to add DXVA to it, and deactivate (grey out) all those options whenever DXVA is active.

The decoders share little code, as you have said so yourself, so please make them separate filters. That will keep things much cleaner and maintainable. Do it as a favor to me. Keeping things simple and flexible will benefit the end-user.

With regard to presets, I am not saying that this functionality shouldn't be there. I am suggesting a simpler solution, that can still do EVERYTHING that you want it to do. Instead of "presets", I call them "loading rules".

How I envision everything to work:

filter X: ffdshow video decoder
filter Y: ffdshow video decoder (DXVA)

filter Y has a merit that is slightly higher than filter X, so that DXVA will get tried first by any DirectShow app.

When the DXVA filter gets loaded, it determines whether DXVA can be used and should be used based on the users hardware/software/loading rules.

If the result of the above is YES, then the filter will decode the video using DXVA. If the result is NO, then the filter will deny the graph connection, and the player will use the next available DirectShow decoder instead. That can be ffdshow, CoreAVC, DiAVC, or any other decoder that a user has installed.

User defined loading rules can be implemented very easily with a couple of checkboxes and value fields. As an example based on your preset idea:
[x]Use DXVA when video width >= [720]
This basically mean: use DXVA only for HD video, fallback to using another decoder otherwise.

I hope things are more clear now.