ffdshow tryouts project: Discussion & Development

[hoborg]

@tal.aloni

rev 3205 broke DVD menu highlighting, latest rev. is still broken in that regard.

No problem here (tested on XP and MPC-HC as player/all internal filters disabled)

[cca]

No problem here (tested on XP and MPC-HC as player/all internal filters disabled)

Not working here though, MPC-HC using libmpeg2 via ffdshow, EVR custom as renderer, rev. 3204 working just fine, everything above it doesn't highlight the menus while I move the mouse over them.

[hoborg]

BTW, i am using FFDshow Crop & Zoom filter to remove black borders from analog TV signal (MPEG-2) i have, but i noticed that will broke DVD navigation (bad position of buttons)
http://hobring.esero.net/saf/ffdshow_zoom+dvd.jpg

Is there a way how to fix it?
I was thinking about creating 2 FFDShow profiles for it, but i have no idea how to define it to be able to split MPEG-2 from TV and MPEG-2 from DVD :(

[jos99]

Casimir once implemented Access Unit parsing for H.264 and VC-1 but did not release it, see MPCVideoDecFilter.cpp >= line 1524 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/filters/transform/mpcvideodec/MPCVideoDecFilter.cpp?revision=1540&view=markup).
Interesting, would this allow live HDTV if similar code was implemented in the ffdshow DXVA decoder?

[CiNcH]

Interesting, would this allow live HDTV if similar code was implemented in the ffdshow DXVA decoder?
Kind of.. It would allow ffdshow to work together with splitter/demuxer/source filters that deliver constant size chunks of ES data and do not parse down to VC-1/H.264 bitstream level (so not exactly one Access Unit per Media-Sample is delivered). Examples of splitters that don't do it are MS MPEG-2 Demultiplexer (which is most likely used in WMC?), Elecard Demultiplexer, DVBViewer DVBSource filter,..

[hoborg]

Here is h.264 sample (http://hobring.ic.cz/HDV_0091.zip) from Samsung HD camcorder that didnt work correctly in FFDshow DXVA decoder - there is glitch every 2-3s.

MPC video decoder have same problem, Cyberlink and MS DXVA decoders work fine.

[roozhou]

mark0077,
the doubling frames bug is fixed with rev. 3211,
I updated 4 filters: DGBob, KernelBob, Yadif, Framerate Doubler.
if there are any other filters that adds frames, let me know.


DScaler?

And will you take a look at this problem (http://forum.doom9.org/showthread.php?p=1254999#post1254999)?

[deets]

Kind of.. It would allow ffdshow to work together with splitter/demuxer/source filters that deliver constant size chunks of ES data and do not parse down to VC-1/H.264 bitstream level (so not exactly one Access Unit per Media-Sample is delivered). Examples of splitters that don't do it are MS MPEG-2 Demultiplexer (which is most likely used in WMC?), Elecard Demultiplexer, DVBViewer DVBSource filter,..

fingers crossed someone is listening to this :)

[tal.aloni]

Some good news regarding DXVA:
after some research, I've discovered that there is support in DXVA 1.0 (and almost certainly 2.0) API for alpha blending in hardware.
it should be faster than current blending implementation, and I'll check it out when I'll have the time.

as a side note, I'm sorry for the latest regressions,
we had to refactor and decouple the image processing chain from the output pin, to allow more versatile usage (DXVA post processing). IMO, it also makes the code cleaner and easier to understand.

p.s.
I'll commit the avisynth related fix later, I'm waiting a confirm regarding the DVD menu related bug.

Tal

[hoborg]

DVD menu related bug - just tested DVD navigation with 3212 buid on Win7 + MPC-HC player (EVR) and it is working fine.

[clsid]

Great work Tal ;)

[mark0077]

Thanks for the fix tal aloni, but I have some problems. If I try to enable de-interlacing with yadif and enable double frame rate, hundreds / thousands of frames get dropped (reported in mpc-hc) for some content, like some mpeg2 dvds. Its frame rate stays at the non-double rated, and it seems to drop every second frame.

Its like ffdshow no longer sends it the correct framerate as output perhaps, and mpc-hc drops every other frame?

Sometimes it only happens when I enable "Process frames flagged as progressive".

[leeperry]

I'll commit the avisynth related fix later
are you referring to this? http://forum.doom9.org/showpost.php?p=1364936&postcount=10337

it didn't work well at all w/ Avisynth 2.57 MT for me....it required plugins to be recompiled w/ 2.58 and some source codes are not available to do so.

I understand Jeremy wants this to happen so badly, but Leak didn't find anything wrong w/ the current code I think...and when I tried sET's fix on Avisynth 2.57 MT it was giving all kind of strange problems(half-speed and so)...hope you won't mind getting Leak's version of the story before adding it to the SVN http://forum-images.hardware.fr/images/perso/sniperr.gif

[cca]

DVD menu related bug - just tested DVD navigation with 3212 buid on Win7 + MPC-HC player (EVR) and it is working fine.

Did some more tests, it refuses to work here, tried all MPC-HC renderers, zero difference. Versions earlier then 3205 consistently work right.

@hoborg

even it works for you it doesn't mean there isn't a regression somewhere, not all configs are the same, same goes for our DVDs.

EDIT: DVD menus appear to work when the DVD has moving backgrounds on the menu. Doesn't work when the menu is completely static though.

[tetsuo55]

regarding VC-1 DXVA:


we have started to imitate this behavior with rev. 3212
I would still like to implement a better solution, but it would require modifying some of the splitters involved. please go for the most accurate solution.
haali is listening too, chances are good he will join the "correct" solution.
You could open a thread here (sign in with your sourceforge account) http://sourceforge.net/apps/phpbb/mpc-hc/viewforum.php?f=2

I suggested opening a thread there with your ideas and then posting the link here and pm-ing the devs involved (casimir666, haali, ar-jar, jonasno, aleksoid... and albain,(and anyone i missed))

[dann23]

mark0077,
the doubling frames bug is fixed with rev. 3211,
I updated 4 filters: DGBob, KernelBob, Yadif, Framerate Doubler.
if there are any other filters that adds frames, let me know.

dann23,
are you referring to my beta2?
please clarify what exactly are you saying / asking.

regarding overlay / blend mode in beta 2:
I have to confess that there is some room for optimizations:

1. osd / subtitles are rendered 3 times for each frames instead of 1,
this is necessary to create opacity map without modifying or rewriting the osd / subtitles filter.

2. Right now the CPU is likely caching all overlay / blend reads and writes, this can be optimized more easily, but I don't have the time right now.

keep in mind that those optimizations are not very significant for a modern CPU (1-2%).

much more important IMO is to enable the text input pin for the DXVA decoder.

Tal

All I want to say is to make it more efficient. For example the same movie in mpc-hc takes approximately 10% from cpu (with subtitles) but using ffdshow with dxva it takes 30-40% using overlay. And about the problem with some movies I know they worked with beta2 from albain. I'll wait for next beta to see what happens and post a sample if necessary. Can you tell me what splitter are you using? Maybe this is the problem with some of the movies.

[hoborg]

EDIT: DVD menus appear to work when the DVD has moving backgrounds on the menu. Doesn't work when the menu is completely static though.

You are right, my are moving.

[tal.aloni]

Thanks for pinpointing the problem, I was able to nail it down!

a fix was commited in rev. 3214, hopefully that's the last one.

Tal

[mark0077]

:D Sweet thanks.

EDIT: Sorry thought you were replying to my de-interlacing , dropped frames problem.

[leeperry]

Thanks for pinpointing the problem, I was able to nail it down!

a fix was commited in rev. 3214, hopefully that's the last one.
any chance for a reply please concerning the avisynth "fix"? Leak didn't see anything to fix last time he checked I think if we're talking about the same thing :o

:thanks:

[tal.aloni]

mark0077
thanks for letting me know!
let me know if it's fixed with rev. 3215

dann23
we still did not implement subtitle input pin, so only external subtitles are working now (movie.srt).
we will implement the subtitle input pin in the future.

tetsuo55
I've spoken with casimir,
in m2ts: MPC assign the PTS timestamp to each frame,
haali does not.
in mkv: we're not even sure that there is a container timestamp, so neither you or haali assign the chronological value.

the only thing we can do is to ask haali to assign the PTS timestamp to vc-1 in m2ts like you do, but we would still need some check based on the container, so not much will change.

Tal

[Jeremy Duncan]

any chance for a reply please concerning the avisynth "fix"? Leak didn't see anything to fix last time he checked I think if we're talking about the same thing :o

:thanks:

My diff file. I made a ffdshow installer and ffdshow avisynth and resizing works with this diff file. (http://www.mediafire.com/?dnljddfjzlm)

IanB said to ignore this part of the diff file though: src/imgFilters/avisynth/TimgFilterAvisynth.h @@ -99,7 +99,12 @@, but it works for me.

[leeperry]

ok ok...well, please allow me to come whine if the patch is no workee...and I might very well not be the only one if it's as broken as the previous version I tried :o

and you guys hoping Haali to help you w/ anything...

[tetsuo55]

tetsuo55
I've spoken with casimir,
in m2ts: MPC assign the PTS timestamp to each frame,
haali does not.
in mkv: we're not even sure that there is a container timestamp, so neither you or haali assign the chronological value.

the only thing we can do is to ask haali to assign the PTS timestamp to vc-1 in m2ts like you do, but we would still need some check based on the container, so not much will change.

Talok, but that still doesnt adres the problem of mixed up frames.

[tal.aloni]

leeperry,
I was referring to a regression with rev. 3205 that I fixed regarding avisynth not delivering additional frames being created.

Jeremy Duncan refers to another issue regarding x64 compatibility (if I understood correctly).

[Jeremy Duncan]

leeperry,
I was referring to a regression with rev. 3205 that I fixed regarding avisynth not delivering additional frames being created.

Jeremy Duncan refers to another issue regarding x64 compatibility (if I understood correctly).

No no, it's for accurate frame seeking: Patch fixes incorrect timestamps, redice crashes on stop, reduce memory usage a bit.
The x64 part enables the patch to work in windows 7 64 bit.

Maybe include the diff file patch in the svn and LeePerry can try it out? :)

With these newer ffdshow trunk builds you also need to do this to get the benefit of the patch though:
Decoder options tab
Uncheck "Detect soft telecine and average frame durations"

[tal.aloni]

Maybe include the diff file patch in the svn and LeePerry can try it out? :)

I suggest you update the patch to the latest revision,
post a beta build so people can test,
also, if the patch include multiple functions (like x64 support), it's best to test and commit them one by one.

[leeperry]

leeperry,
I was referring to a regression with rev. 3205 that I fixed regarding avisynth not delivering additional frames being created.

Jeremy Duncan refers to another issue regarding x64 compatibility (if I understood correctly).
ok, thanks for the clarification!

currently w/ CoreAVC CUDA 2.0/ffdshow/avisynth, it currently jumps two frames ahead when I do frame step by step in KMP(it used to be only one frame) the first time(the following frames are OK)...but I didn't try to find the culprit, as it's really no biggy for me.
I suggest you update the patch to the latest revision,
post a beta build so people can test,
also, if the patch include multiple functions (like x64 support), it's best to test and commit them one by one.
please noone take it bad, but Jeremy's bruteforce approach to compiling software scares me a bit :o

[deets]

I hope i haven't missed a post, tried to keep up :)

would any of the devs mind commenting either way if they have any plans to make DXVA compatible with live streams. Cinch had some stuff in a post about it but i havent (unless i missed it) seen any reply.

if you don't have any plans to address this, we can let it go :)

appreciate your work and im not pushing it, just wondering if its been noted or not

[THX-UltraII]

beta ffdshow: link (http://www.mediafire.com/?mmdmjm2klwm)

Is there also a x64 version link?

[tal.aloni]

some updates:
1. I can't get DXVA hardware alpha blending to work yet, I'll keep trying. (getting E_FAIL from the driver)

2. software overlay mode: it seems that most of the cpu consumption is dedicated to the high quality drawing method I implemented.
I'll try to write a faster method for overlay, I might leave the current method as "Overlay - High Quality".

p.s.
since hardware alpha blending requires conversion to AYUV 32, (and calculating an alpha mask), it would be a safe to assume software overlay would (after optimizations) be faster then hardware alpha blending.

[HeadlessCow]

Is it something that's only supported on certain cards?

[tal.aloni]

I don't really know, it's part of the specs, so it should be supported on every modern DXVA 1.0 device.

I have an nvidia GPU as well, so I can test it as well later.

[DigitalDeviant]

Starting sometime after rev. 3204, IVTC via avisynth make the video stutter extremely bad. I've tried severl versions through to the latest, 3217, and the last working version seems to be 3204.

[CruNcher]

there are still artifacts tal.aloni (Nvidia) compared to MPC-HCs decoder :(
also if i try to close the video now libavcodec.dll crashes im using xhmikosr current 3219 build :(

[tal.aloni]

there are still artifacts tal.aloni (Nvidia) compared to MPC-HCs decoder :(
you mean when seeking, right?


also if i try to close the video now libavcodec.dll crashes im using xhmikosr current 3219 build :(
since which revision? this might be related to ffmpeg. (please provide more details, I've tested this build and I don't any any issue)

[XhmikosR]

Everything seems to work as usual for me too. I've also updated my GCC to v4.4.3.

[dann23]

I made some test using dxva and haali splitter, divx mkv splitter and matroska splitter from mpc-hc website.
With haali I can play all the movies. No artifacts.
With divx all the movies play but many artifacts.
And with matroska splitter some of the movies don't play. Just black screen. And some artifacts. Also I found that if using matroska splitter and the movie has mpeg2 video in it, it won't play.
The test was on windows xp with ati 3850. Also I want to mention that using beta2 from albain has no problem with matroska splitter. The problem appeared after that build.

Edit.
Some artifacts also appear with haali but very rarely.

[CruNcher]

you mean when seeking, right?
Nope after a while of playback with this 60 FPS stream most other streams are ok no problem with MPC-HC DXVA and this 60 fps stream you can find it some pages back WipeOut 1080p 60 FPS PS3 Main L 4.1 Gameplay trailer


since which revision? this might be related to ffmpeg. (please provide more details, I've tested this build and I don't any any issue)

i didn't tried different revisons yet one moment ;) i find it out but it was happening very recently maybe the 2 last builds i give you the exact build when it appeared mom :)

the crash problem appeared between 3212-3217

3212 = ok (file close in MPC-HC)
3217 = libvcodec.dll crash on exit (file close in MPC-HC)
3219 = libavcodec.dll crash on exit (file close in MPC-HC)

sorry i don't have any other builds to test

[tal.aloni]

sorry i don't have any other builds to test

http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca95e79d7d0540e1e1

old builds > generic > page 2

let's narrow it down to a build, ok?

[clsid]

I had a similar crash on exit problem yesterday when updating the ffmpeg-mt code. After a lot of trial and error I discovered it was related to some members of the struct H264Context (in h264.h), namely list_count/list_counts/ref_count. Just their order mattered for whether it crashed or not. So there may be some kind of alignment issue.

[tal.aloni]

Hey Guys,
It turns out I didn't take into account situations where frames are removed from the source (courtesy of avisynth filter),
to support this, I made another slight change to ffdshow: frames won't be delivered if the image filter does not eventually return S_OK.

however, for various reasons, some filters might not return the proper value.
I'm posting a beta so we could identify the problematic filters / settings before I commit, if you're getting black screens / missing frames, please let me know which filter / config is the cause.

Thanks!
Tal

build:
http://iknowu.net/files/public/ffdshow/Decoupling/ffdshow_rev3220_20100123-HonorProcessSampleReturnValue.exe

patch:
http://iknowu.net/files/public/ffdshow/Decoupling/3220-HonorProcessSampleReturnValue.patch

Edit:
found first problem: DGBob.

[BatKnight]

I came across with this same situation and instead of copying other's words, I prefer to quote someone that already tested and provided the results:


- Build number: 20100112 (updated to the last one just to be sure. Previously I used 20091209 and before that another older one that I forgot, but I confirm the behaviour is identical).
- Sources: MP2, MP3, AC3, DTS, some TrueHD test files (marketing material from Dolby), 24-bit FLAC (I normally use madFlac but forced ffdshow for this test) and a 24-bit LPCM track (Blu-ray).
- Config: I use ffdshow only for decoding. All processing plugins are unchecked.
For the test I only change the various int and float output formats in the "Output" section. I tried changing the allowed sample formats in the "Processing" section and it didn't change the results, so leeperry is right: this only affects processing.

Results:

1. everything checked:
- AC3 and DTS: libavcodec 16 int, liba52/libdts 32 float
Everything fine here: the ones that can output float do and libavcodec that is limited to 16 int outputs 16 int.
- MP2 and MP3: libavcodec and mp3lib 16 int, libmad 32 int
libmad doesn't want to output float. I think I've read here that 32 int has higher precision than 32 float, however the decoder surely must compute float values as the algorithm output even if it wants to output int afterwards, right? So libmad shouldn't gain anything outputting 32 int here, right? (I presume it doesn't work in 64 float internally). Weird.
EDIT: I've found on the official website that MAD natively outputs 24 int, so it falls under the same case as TrueHD, FLAC and LPCM: it outputs 24 int and then ffdshow does something with it, now is it padding or converting?
- TrueHD: 32 int. Doesn't make sense as it's not a lossy codec and the source is 24-bit at best so it doesn't gain anything by outputting at higher int precision, on the contrary.
- 24-bit LPCM: 32 int. Makes even less sense than TrueHD as it doesn't have anything to decode, so it's just a useless conversion by ffdshow here.

2. everything checked except 32 int:
TrueHD, LPCM, FLAC and madlib now output 16 int, even though 24 int and 32 float (which should in theory be the best choice for for madlib) (EDIT: MAD actually outputs 24 int) is enabled. Go figure...

3. only 16 int and 24 int checked:
This is to test liba52 and libdts when they can't output float, and they prefer to output 16 int rather than 24 int.

Now I have different possible conclusions:

1. there is absolutely no logic in ffddshow decoders. Some inside libavcodec (AC3 and DTS) are able to output 16 int even if something higher is checked, others always output the best (liba52 and libdts), and others always output the highest precision available even if the source is lossless and of lower precision. And none will output 24 int except when it's the only option available, even the lossy codecs, which could in theory gain something by outputting at 24 int as it would mean smaller rounding errors than 16 int.

2. ffdshow does a transparent internal conversion from what the decoder really outputs to the output format it considers best, without informing the user.
This would explain why everything is output at 32 int, but then wouldn't explain why ffdshow considers 16 int to be better than 24.
And obviously, some decoders (e.g. AC3 and DTS in libavcodec) would be able to bypass this conversion.

3. ffdshow pads 24 int to 32 int.

Now my part:
Would it be possible for ffdshow to output the same format as the input in lossless codecs and try to ouput 32bit float (and fallback to 32bit int or 24bit int, etc) in lossy codecs?
Because as you see in el Filou's point 1 and 2, ffdshow isn't making the most correct choices.

Bat

[Mr VacBob]

I had a similar crash on exit problem yesterday when updating the ffmpeg-mt code. After a lot of trial and error I discovered it was related to some members of the struct H264Context (in h264.h), namely list_count/list_counts/ref_count. Just their order mattered for whether it crashed or not. So there may be some kind of alignment issue.

It needs to be list_counts, ref_counts, list_count, like it already is, or mt will crash much earlier than when exiting. Or is this something else?

[clsid]

Yes, it works OK with the order that is in your git tree. That order is also used in ffdshow's copy of ffmpeg-mt. I initially used the order that is used in regular ffmpeg. That was when I got the crashes.

Is my assumption correct that this is an alignment issue? Or this there some other hidden bug?

[Mr VacBob]

It's because mt does a memcpy() of some fields between threads, and that one was added in the middle of one of them upstream. But it's not appropriate to copy that one (it's a pointer to a per-frame table) so I moved it up in the context rather than splitting the memcpy up.

[CruNcher]

http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca95e79d7d0540e1e1

old builds > generic > page 2

let's narrow it down to a build, ok?

the crash started with 3217

yep 3223 still crashing

you do File->Close in MPC-HC and bye bye libavcodec.dll crashes it's not bad as the playback is over but it didn't happen before 3217

bigger problem though is that this 60 FPS sample is artifacting with ffdshow DXVA when with MPC-HC DXVA its fine :(

[tal.aloni]

CruNcher, I'll review the modifications again.

also, there is again problem with AviSynth filter, I'm working on it.

Tal

[Jeremy Duncan]

I suggest you update the patch to the latest revision,
post a beta build so people can test,
also, if the patch include multiple functions (like x64 support), it's best to test and commit them one by one.

3223 build and patch (http://www.mediafire.com/?n4jjdwzwylz)

With these newer ffdshow trunk builds you also need to do this to get the benefit of the patch though. At least for mvtools2 frame doubler:
Decoder options tab
Uncheck "Detect soft telecine and average frame durations"
So if somebody says the patch doesn't fix their problem I would ask them if this is unchecked or not. It may be it only needs to be unchecked for mvtools2 frame doubler, but I don't check every plugin and option so I don't know.

I updated the ffdshow wiki: link (http://ffdshow-tryout.sourceforge.net/wiki/devel:building)

[albain]

I came across with this same situation and instead of copying other's words, I prefer to quote someone that already tested and provided the results:



Now my part:
Would it be possible for ffdshow to output the same format as the input in lossless codecs and try to ouput 32bit float (and fallback to 32bit int or 24bit int, etc) in lossy codecs?
Because as you see in el Filou's point 1 and 2, ffdshow isn't making the most correct choices.

Bat

It depends also on codecs capabilities : for example libavcodec AC3 decoder is able to output 16 bits only, so you'll get 16 bits whatever you check. Same thing for DTS.
This is the reason why liba52 and libdts are better for AC3/DTS decoding and this is indeed the reason why we keep them inside FFDShow

About libavcodec TrueHD, I think that it is able to output 32 bits.

About FFDShow output logic, I am not very familiar with it but I know that for example if you let 16 bits check, you will get 16 bits only.
Try to test with 24 or 32 bits only

Also there is the windows mixer that should be set to output this sample format.