ffdshow tryouts project: Discussion & Development

[STaRGaZeR]

If you can update it ok. If not remove it.

x264 should be updated to latest, I can t update it anymore....

clsid disabled it some time ago in the hope that someone would update it. IIRC the current version in the trunk is hopelessly outdated.

I don't care about Theora really, the best thing is to remove it IMO. libavcodec handles it just fine. I'll do it. clsid, I can't update ICL10 project files, sorry about that.

I think some were changed. The biggest issue is that the format conversion inside the codec uses some tricks to be a lot faster, particularly on systems with slow FPU like ARM. Just removing them would mean that FFmpeg would get a lot slower on these systems.
And for FFmpeg speed (even on non-mainstream platforms) is most important than output resolution.
But if someone sends a patch to fix this issue, there'd probably no objections to changing the output format.

I agree with madshi, the best solution would be a compile time option. Very few lines of code to make everyone happy. Can you make those patches and send them, madshi?

[STaRGaZeR]

If you had a bugtracker anyone cared about, this wouldn't be happening...bumping bugfixes requests is the only chance to see anything happening(just like MPC).

I've asked three very skilled audio plugins coders for help and they've all told me that the ffdshow audio code was a bug feast(full of syntax errors and beginners mistakes) and a huge mess...so I guess this is not going to change anytime soon. They were even wondering how it could be working at all :confused:

ffdshow is a lost cause for studio grade audio, atm it's just a toy to watch movies in WMP...sorry for rubbing it in

Stop the presses, a freak wants studio grade stuff for free ASAP!!! :D

lol, you talk like if it were my responsability or something. I was going to fix it, but now I don't feel like it. Enjoy the wonderful 16-bit integer output, troll :)

[fastplayer]

libavcodec handles it just fine.
Yep, libavcodec seems to be the solution for every "problem" lately :D

[leeperry]

Stop the presses, a freak wants studio grade stuff for free ASAP!!! :D

lol, you talk like if it were my responsability or something. I was going to fix it, but now I don't feel like it. Enjoy the wonderful 16-bit integer output, troll :)
hehe, yeah exactly...can you please make libavcodec and the winamp2 plugins output 8int? that'd be the shiznit, and that'd make kieranrk happy too :)

I don't think I'm the troll here, but the french and british have never managed to get along nicely...that's what hundred years of history are teaching us.

3 highly skilled coders(Vincent Burel, Wingfeather and Christian Budde) said that ffdshow shouldn't even work as is...but surely you could fix it, I believe you. I really do.

[Midzuki]

I was going to fix it,

I seriously doubt that. :devil:

[STaRGaZeR]

Cool, I can own our two resident trolls in one shot :D

http://thumbnails4.imagebam.com/9980/0d2e8d99792836.jpg (http://www.imagebam.com/image/0d2e8d99792836)

Winamp works with 32-bit integer max, and there you have it working with a simple equalizer. If you want a video of it working, just let me know :)

[avih]

hehe, yeah exactly...can you please make libavcodec and the winamp2 plugins output 8int? that'd be the shiznit, and that'd make kieranrk happy too :)

I don't think I'm the troll here, but the french and british have never managed to get along nicely...that's what hundred years of history are teaching us.

3 highly skilled coders(Vincent Burel, Wingfeather and Christian Budde) said that ffdshow shouldn't even work as is...but surely you could fix it, I believe you. I really do.
Dude, take it easy, you've made your point. Please try to lower the volume of your posts and stay closer to the topic.

Thanks.

[leeperry]

Cool, I can own our two resident trolls in one shot [..]
Winamp works with 32-bit integer max, and there you have it working with a simple equalizer. If you want a video of it working, just let me know :)
What are you trying to prove exactly? You obviously set the ffdshow sound processing bitdepth higher than 16int, and the 16int off the decoder and winamp2 DSP plugin are being resampled to 32int/32fp(depending on what you chose).

I've inserted the Ozone4 bitmeter in MPC Classic between ffdshow and Reclock, and set ffdshow to 32fp:
DTS in ffdshow/libavcodec: http://thumbnails27.imagebam.com/9980/63349e99798776.jpg (http://www.imagebam.com/image/63349e99798776)
DTS in ffdshow/libdts: http://thumbnails24.imagebam.com/9980/e09c2499798781.jpg (http://www.imagebam.com/image/e09c2499798781)
DTS in ffdshow/libdts + a winamp2 DSP wrapper>VST plugin in ffdshow: http://thumbnails15.imagebam.com/9980/673bdf99798778.jpg (http://www.imagebam.com/image/673bdf99798778)

both libavcodec and the winamp2 DSP plugins are processed in 16int and trim the 8 least significant bits...but nice try.
Dude, take it easy, you've made your point. Please try to lower the volume of your posts and stay closer to the topic.

Thanks.
Sorry for that, I know that posting in the ffdshow thread is a waste of time. Won't happen againhttp://forum-images.hardware.fr/images/perso/the%20bloodhound%20gang.gif

[Astrophizz]

So, if I understand correctly, there is no intent to have libav dither to 16 bit?

[diizzy]

While this 16-bit int vs * float seems to get people a bit defensive I would like to ask how "inaccurate" is it really? Given that many formats except HD formats are 16-bit or even lower the degradation should be minimal or none at all nor do you really know if the encoder used a higher precision during encoding right? As far as I know most people use analogue cabling at least to the speakers you would also introduce further degradation since there's no digital correction of any kind. Also having in mind that speakers or headphones usually don't have a flat frequency curve this would sound degrade even further. While I do agree that precision is a good thing in general and that it may / may not make a huge performance impact I also understand if some say that rounding doesn't matter since the sound will get dirty on the way to your ears. Fine, audio processing should be lossless but interpolating which might happen since you have more precision (and then at some point round it) than during encode time might not be a great solution either.
Am I missing something here?

[STaRGaZeR]

What are you trying to prove exactly? You obviously set the ffdshow sound processing bitdepth higher than 16int, and the 16int off the decoder and winamp2 DSP plugin are being resampled to 32int/32fp(depending on what you chose).

http://i296.photobucket.com/albums/mm179/moistmuffin/picard-facepalm.jpg

Every option in sound processing was checked. Every option in the output section was checked. It seems you don't get that I've modified ffdshow to process winamp plugins in 24-bit (output is zeroed to 32-bit) instead of 16-bit here in my system, by changing "tons of "int16_t"/"SF_PCM16" in those sections" into something else following your own words. Too bad I couln't get 32-bit to work, everything was fine but the audio returned from the plugin was untouched. Just a FYI:

int (*ModifySamples)(struct winampDSPModule *this_mod, int16_t *samples, int numsamples, int bps, int nch, int srate)

Notice that little int bps? 16, 24, etc. etc. ;)

Sorry for that, I know that posting in the ffdshow thread is a waste of time. Won't happen again

Someone wanna bet on this? :D

[Midzuki]

Cool, I can own our two resident trolls in one shot

As Palpatine surely would say,

"Troll is a point of view".

Also, you cannot deny that many devilopers can be scientifically :) defined as "the trolls who got there first". :rolleyes:

[tetsuo55]

While this 16-bit int vs * float seems to get people a bit defensive I would like to ask how "inaccurate" is it really? Given that many formats except HD formats are 16-bit or even lower the degradation should be minimal or none at all nor do you really know if the encoder used a higher precision during encoding right? As far as I know most people use analogue cabling at least to the speakers you would also introduce further degradation since there's no digital correction of any kind. Also having in mind that speakers or headphones usually don't have a flat frequency curve this would sound degrade even further. While I do agree that precision is a good thing in general and that it may / may not make a huge performance impact I also understand if some say that rounding doesn't matter since the sound will get dirty on the way to your ears. Fine, audio processing should be lossless but interpolating which might happen since you have more precision (and then at some point round it) than during encode time might not be a great solution either.
Am I missing something here?
indeed, i want to see some scientific research done on this.

We can output the wav files and compare them right? so whats the difference?

When madshi had to prove his renderer does better chroma scaling he made a screenshot comparison, and i've seen tools that can highlight the pixels that the better scaling affects.
the same should be possible for audio, no need to involve ears or speakers. just the pure wave, is it different or not, and if so where.

[kieranrk]

just the pure wave, is it different or not, and if so where.

If you want to show better chroma upsampling then you show a picture; if you want to show better audio quality you have to do it with an audio track.

[STaRGaZeR]

Some new tests with O2 and O3:

Sample 1: Blu-ray, 1080p24, ~35Mbps

O2 --> 178,12fps
O3 --> 182,43fps

Sample 2: Blu-ray, 1080i30, ~35Mbps

O2 --> 166,9fps
O3 --> 169,9fps

Sample 3: Big Buck Bunny, 720p24, ~2,5Mbps

O2 --> 672.06fps
O3 --> 677.42fps

1-2% difference. What do you think about changing it? Binaries are ~25% smaller with GCC 4.5.1

[madshi]

While this 16-bit int vs * float seems to get people a bit defensive I would like to ask how "inaccurate" is it really? Given that many formats except HD formats are 16-bit or even lower the degradation should be minimal or none at all nor do you really know if the encoder used a higher precision during encoding right? As far as I know most people use analogue cabling at least to the speakers you would also introduce further degradation since there's no digital correction of any kind. Also having in mind that speakers or headphones usually don't have a flat frequency curve this would sound degrade even further. While I do agree that precision is a good thing in general and that it may / may not make a huge performance impact I also understand if some say that rounding doesn't matter since the sound will get dirty on the way to your ears. Fine, audio processing should be lossless but interpolating which might happen since you have more precision (and then at some point round it) than during encode time might not be a great solution either.
Am I missing something here?
First of all we're not talking about interpolation here. All we're (some of us are) asking about is to do the math as precise as possible, which in the worst case should sound equal to doing the math unprecise, and in the best case should sound noticeably better.

Next, you're saying that most non-HD formats are 16bit, which is simply not true. AC3 and DTS are non-HD formats and perfectly support 24bit encodings. There's even a DTS header field which tells you which bitdepth was fed to the encoder. And from my experience there are plenty of 24bit DTS encodings out there, and I'm not talking about DTS-HD here. For AC3 we will never know which bitdepth was fed to the encoder, but the encoder also happily encodes 24bit sources. So it's a fair guess that many studio created AC3 tracks were also created from 24bit sources.

I've done tests myself with rounding vs. dithering. Ok, I've done them at a lower bitdepth than 16bit to make the difference very easily audible and the difference was big. Of course with 16bit the difference is much smaller. But still, rounding is scientifically and mathematically worse than dithering. And libav rounds down every DTS and AC3 audio track to 16bit, no questions asked.

indeed, i want to see some scientific research done on this.
Easy, the web is full of proof that dithering is needed. E.g. this is a nice starting point:

http://www.users.qwest.net/~volt42/cadenzarecording/DitherExplained.pdf

[tetsuo55]

That document clearly shows that a 24bit (lossless?) source benefits from 24bit output or dithering over truncation.
However what kierank seems to suggest is that lossless codecs seem to expect the truncation, the encoder/decoder psy optimises the stream to not become ugly like the examples in the document.

For the argument to be settled, the same test as explained in that document should be repeated (by either side of the argument) but this time using a typical lossy sample.

[madshi]

However what kierank seems to suggest is that lossless codecs seem to expect the truncation, the encoder/decoder psy optimises the stream to not become ugly like the examples in the document.
No, I don't think that's what he meant. It would be wrong, anyway. I think what he believes is that when 16bit int sources are fed into a lossy encoder, the decoder already has noise in the lower 8bit of a 24bit signal, so the signal can be truncated/rounded without side effects. I don't agree with that at all, and the paper I linked to has a clear opinion on this, as well:

> If the signal has had any processing happen to it
> at higher bit depths then choose to add dither

This is exactly what we're talking about here: "16bit int source -> lossy encoding -> lossy decoding -> 16bit int output". This processing chain has processing steps in a higher bit depth (floating point in the case of DTS and AC3), so dithering needs to be added when converting the floating point decoding results back to int16.

Furthermore, what kieranrk conveniently ignores is that AC3 and DTS tracks were often encoded directly from true 24bit studio masters.

[fastplayer]

1-2% difference. What do you think about changing it? Binaries are ~25% smaller with GCC 4.5.1
Could these 1-2% - for example, for people with low CPU specs - mean the difference between playable and stutter? Why not switch to O2, wait a few weeks, see what reaction we get and decide then finally? As long as the people don't shout "Hang the bastards!", we're good :D
By the way, what effect has O2 vs. O3 on compile/build time?

[Reimar]

I agree with madshi, the best solution would be a compile time option. Very few lines of code to make everyone happy. Can you make those patches and send them, madshi?

While I think it's worth a try (with some convincing it might get accepted in FFmpeg), this definitely is not the best option.
What I expect the developers to want you to do is to only support float output for decoders that use float internally, but also add scale/bias options so that decoders that are capable of it will apply these to the output "for free", and then use that to implement a very fast float -> 16 bit int conversion outside the codec like the one that is currently done inside it (also means you get volume control for free).
As you can see this will be a bit of effort, just deciding on the precise design will take some time.

[madshi]

Adding scale/bias options sounds like a useful idea if you really need to squeeze out the last bit of performance on very slow hardware. But scale/bias options would also be useful if the decoders keep on outputting int16. So I don't think that changing the output data format and adding scale/bias options are (or have to be) connected in any way.

[Reimar]

Adding scale/bias options sounds like a useful idea if you really need to squeeze out the last bit of performance on very slow hardware. But scale/bias options would also be useful if the decoders keep on outputting int16. So I don't think that changing the output data format and adding scale/bias options are (or have to be) connected in any way.

Let me try to make this more clear: scale/bias is _required_ to avoid a (on some hardware massive, IIRC > 50%) performance regression for the float->int16 conversion if the decoders output native float.
That is very unlikely to be accepted by FFmpeg developers.
Selectable codec output format (either at run- or compiletime) might be accepted, but it is not an ideal solution (more a quick hack) and is likely to be treated as such during review.

[STaRGaZeR]

Could these 1-2% - for example, for people with low CPU specs - mean the difference between playable and stutter? Why not switch to O2, wait a few weeks, see what reaction we get and decide then finally? As long as the people don't shout "Hang the bastards!", we're good :D
By the way, what effect has O2 vs. O3 on compile/build time?

I can't answer that with a system like mine, but considering that 2% difference I got in all cases: if your CPU is slow and can only reach 25fps during the most CPU intensive parts you'd get 24,5fps with O2 instead. Will that be enough for stutter free playback? Not sure. However if people have that kind of perfomance there's no point in using ffdshow, they should be using a faster decoder or DXVA. I like that trial period, will do that. x64 builds use O2 BTW.

And I can't really measure compile time, I'm bottlenecked by the hard drive :p

[fastplayer]

ffdshow_installer.iss (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/bin/distrib/ffdshow_installer.iss?view=markup)
Line 326 is obsolete:
Name: "audio\mp3\mp3lib"; Description: "mp3lib"; Components: ffdshow; Flags: unchecked exclusive

[dansrfe]

This is kind of off-topic for the discussion at hand however i just want to point out that ass karoke support seems broken in ffdshow because while rendering I see tags all over the place.

[STaRGaZeR]

This is kind of off-topic for the discussion at hand however i just want to point out that ass karoke support seems broken in ffdshow because while rendering I see tags all over the place.

It's a known problem. Plus you just said it here (http://forum.doom9.org/showthread.php?p=1446306#post1446306). Don't post the same bugs over and over again, it'll only slow down the process. It'll eventually be fixed by someone.

[Midzuki]

...

can't fix it due to an unmanageably messy code...

... so it's a lost cause. WYSIWYG.

I was bored :), and so I hex-edited ffdshow.ax r3562, so that it couldn't connect anymore to Windows DVD Navigator (qdvd.dll) http://forum.doom9.org/images/icons/icon3.gif. YES!, the trick did work :) :cool: , BUT...

well, ... :rolleyes: :p

now, the "multi-purpose" pin of the raw video filter connects to the output pin of the audio processor!

:readrule: :readrule: :readrule:

http://forum.videohelp.com/attachments/3656-1285826143/ffdshow_is_insane.png

P.S.: This post is dedicated to Keiyakusha ;)

[rpm7200]

lfe crossover doesn't work with surround audio files. please fix it. i need lfe crossover.

[nevcairiel]

Hey,

i noticed the other day that the audio delay doesn't work with bitstreaming, at least not with all bitstreaming formats.
I set a delay to fix A/V sync with my TV, and it was all peachy with PCM. But when bitstreaming AC3 for example, i get no sound at all anymore.
It seemed to work when streaming DTS-HD, but not with DTS.. I can run more tests on other formats if that helps.

[Sebastiii]

Hey,

i noticed the other day that the audio delay doesn't work with bitstreaming, at least not with all bitstreaming formats.
I set a delay to fix A/V sync with my TV, and it was all peachy with PCM. But when bitstreaming AC3 for example, i get no sound at all anymore.
It seemed to work when streaming DTS-HD, but not with DTS.. I can run more tests on other formats if that helps.

I also remark this when i use reclock, but without it, it's ok :)
Doesnt know what happen lol.

[v0lt]

You can add support for FOURCC 'png '? It is used in the mov-files. I used the same decoder, which decodes the "PNG1" and "MPNG". I substituted the FOURCC in the splitter, but it's not the best solution.

mov-png_example (http://www.mediafire.com/?dtglgex8vonk89d)

I wanted to do the same "jpeg" (ffdshow_mediaguids.h, section //quicktime), but do not completely understand how to add changes in TglobalSettings.cpp.

[dansrfe]

@ Midzuki
How do I do the same thing you did with the ffdshow audio processor outputting to raw?

Thanks!

[Midzuki]

@ dansrfe:

1) patch a copy of ffdshow.ax ;
2) unregister the original ffdshow.ax ;
3) hide the original ffdshow.ax in a temp folder,
move the modified .ax into ffdshow's folder ;
4) register the patched .ax file ;
5) start playing a DVD with MPC,
then press the pause button ;
6) run Graphstudio, press CTRL + G, click "Connect" ;

N.B.: I configured MPC to "prefer" ffdshow audio processor, since its default merit status is "DO_NOT_USE".

P.S.: Several weeks ago, Keiyakusha tried to convince that "it would be very bad" if ffdshow had dedicated standalone filters, without shared capabilities & settings.
Now, let's see whether he will change his mind. :)

[Keiyakusha]

Not really. I don't have anything against "dedicated" filters or something. I just don't want to see things like subtitles rendering removed from raw filter functionality.

[Gleb Egorych]

As I understand, revsion 3608 reverts 3589, i.e. mpeg decoders are now integer again.

[clsid]

Nope, they are still float.

[Gleb Egorych]

For example, all changes made in mpegaudiodec.c with 3589 are reverted with 3608. But seems these changes are relevant to disabled decoders and don't touch float decoders.

[hoborg]

MOV PCM problem

Hi.
I have problem with playback of few MOV files from Canon IXUS 200 IS.
It play in wierd slow motion in graphstudio - 2.5FPS.
If i disable audio, it play just fine.
Here is graph:
http://forum.team-mediaportal.com/attachments/codecs-external-players-55/69069d1286133179-saf-v5-00-experimental-based-ffdshow-dxva-decoder-mvi_1878.jpg
MP4Splitter.ax rev.1.4.2646.0, FFDshow 3608

MPC MPA audio decoder play it without any issue too on both machines.

Here video is sample (http://forum.team-mediaportal.com/attachments/codecs-external-players-55/69020d1286097641-saf-v5-00-experimental-based-ffdshow-dxva-decoder-mvi_1878.zip)

Media info:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L4.1
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 4s 566ms
Bit rate mode : Variable
Bit rate : 23.1 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.837
Stream size : 12.6 MiB (97%)
Language : English
Encoded date : UTC 2010-10-03 10:07:35
Tagged date : UTC 2010-10-03 10:07:35
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M

Audio
ID : 2
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : sowt
Duration : 4s 566ms
Bit rate mode : Constant
Bit rate : 705.6 Kbps
Channel(s) : 1 channel
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Stream size : 393 KiB (3%)
Language : English
Encoded date : UTC 2010-10-03 10:07:35
Tagged date : UTC 2010-10-03 10:07:35

The strange thing is, that it seems this problem only affect realtek sound cards, home i have SoubBlaster, and it play just fine.

[dansrfe]

Works fine on my side with ffdshow latest build, madVR latest build, and MPC-HC 32-bit latest build.

[hoborg]

Works fine on my side with ffdshow latest build, madVR latest build, and MPC-HC 32-bit latest build.

I was able to reproduce this issue on Intel Atom and Realtec HD audio. At home it is working fine C2D+Audigy4.

No idea what can causing it, but if i use MPC MPA audio decoder, it is working fine, so must be something in FFDshow.

[Atak_Snajpera]

@devs
Possible bug in h.264/avc decoder
Haali Media Splitter + ffdshow r3572 (libavcodec / ffmpeg-mt with 1-4 threads) = corrupted image
Haali Media Splitter + ffdshow r3572 (DVXA enabled) = no corruption

http://i51.tinypic.com/oi92c8.jpg

sample
http://www.mediafire.com/?4z2as0yjvnjoage

[augur]

hi,
since rev.3501 (3500 works fine) when I'm seeking fast (holding & sliding the cursor) with mpc-hc, it crash.

After many tests, i've found that this is caused by the AC3 encoding option (16, 32 & 32 float are ok), absolutely nothing else is activated (i used 48000hz inputs since resample was desactivated).

On the MPC side, i've found that if i disable his filters (avi & mp3 for my tests) it works again.
Going back to previous versions didn't do anything (last try:1.3.1896)

sorry for my poor english & testing abilities :rolleyes:, and thanks for all your work.

system: XP sp3. ffdshow x86 regular & icl11

edit: doesn't seem to crash with multichannels tracks (tried ac3,truehd, dts(hd), lpcm)

[XhmikosR]

@clsid: rev3610 broke ffmpeg-mt. It's crashing with every h264 video I've tried while rev3609 works fine.

[clsid]

Should be fixed in 3611.

[dansrfe]

ffdshow does not render pgs subtitles from a .ts file at all. Internal mpc renderer with EVR-CP renders it fine. Also I want to bump the broken karaoke ssa support in ffdshow problem. Please give some sort of eta of when these problems can be expected to be fixed. Thanks again ffdshow devs. :)

[LigH]

I have a problem with ffdshow expanding the height of the video, repeating lower lines, if it is not MOD 16. But it does that in a rather strange way.

- ffdshow_rev3611_20101006_xvidvideo-ru_x86_icl11
- mpc-homecinema.1.4.2667_(x86)_msvc2010

both from xvidvideo.ru; this effect happened with earlier versions too.

At first I usually had disabled all internal decoders and splitters of MPC-HC where useful, to allow decoding via ffdshow. But it appears that the MPC-HC internal decoder does the same as ffdshow.

The media info dialog in MPC-HC (Shift+F10; Details) shows the following values, depending on ffdshow or MPC-HC wether or not using DXVA for decoding H.264:

a) if DXVA decoding for H.264 is enabled: General { Video size = 640 x 368 }; stream list { Video: MPEG4 Video (H264) 640x360 25.00fps [Video] } -- at least MOD 16
b) if DXVA decoding for H.264 is disabled: General { Video size = 640 x 372 }; stream list { Video: MPEG4 Video (H264) 640x360 25.00fps [Video] } -- not even MOD 16?!

Test files: MP4 (http://www.holzon.de/test/00003_5s.mp4) or MKV (http://www.holzon.de/test/00003_5s.mkv) (same content, ~330 KB each)

http://www.holzon.de/test/00003_5s.png

P.S.: DGIndexNV 2026 and 2030 warn "Stream specifies cropping" (for the MKV) and report the "coded size" as 640x384 (even MOD 32).

[jmone]

Can I confirm a comment in some MADFLAC threads that FLAC decoding in FFDSHOW is only 16-Bit (eg 24-Bit source material is decoded to 16-Bit).
Thanks
Nathan

[magic144]

any chance the DXVA filter can be made to produce the same output as the software-only filter in the following respect...

for interlaced material,
output colorspace - e.g. NV12 only
set interlace flag in output media type

I find this is essential when watching e.g. some Concert Blu-Rays.

just wondering if it's possible!
also could the DXVA filter be somehow rolled into the main filter such that it can be chosen based on a profile rule?
(and is there any way of creating a profile rule to distinguish interlaced from non-interlaced content??)

[Gleb Egorych]

Can I confirm a comment in some MADFLAC threads that FLAC decoding in FFDSHOW is only 16-Bit (eg 24-Bit source material is decoded to 16-Bit).
Thanks
Nathan
Since FLAC decoding in ffdshow is done by libavcodec, the output is indead 16-bit.

[jmone]

Thanks - so all 24-Bit sources using libavcodec (eg True-HD) is also only 16bit. Any plans to support 24-bit?
Thanks
Nathan