ffdshow tryouts project: Discussion & Development

[Leak]

Originally Posted by fastplayer

Edit: If you still have the nerves you could replace the ampersands & in the URLs with &. That should make it XHTML-compliant. Thanks!

Eeep... did I mention that I write webapps for a living? >_<

Fixed.

I guess the other pages could have some SPAN-tags removed - what's the use of nesting a <SPAN> directly inside a <P>aragraph only to set a CSS class for the text? (I'd say that the headings should use <H>-tags for WCAG-compliance, but I doubt people who install ffdshow and AviSynth are using a screenreader at the same time - stranger things have happened, though...)

np: Atom - All Notes Off (Replicant Rumba Rockers (remixed by Burnt Friedman))

[fastplayer]

Originally Posted by Leak

I guess the other pages could have some SPAN-tags removed - what's the use of nesting a <SPAN> directly inside a <P>aragraph only to set a CSS class for the text?

Bad habits... I'll look into it.

[Px]

Originally Posted by drevil_xxl

Please test my new builds.
http://rapidshare.com/files/28939785...70430.rar.html
I don't have a SSSE3 (Intel core2) cpu.I can't test if X264 is faster or not.

Video - Sin_City_x264_720p.mkv, null render

1090-clsid
User: 39s, kernel: 0s, total: 39s, real: 39s, fps: 51.1, dfps: 50.5
1125-clsid
User: 37s, kernel: 0s, total: 37s, real: 38s, fps: 52.8, dfps: 51.9
1126-gcc
User: 37s, kernel: 0s, total: 37s, real: 38s, fps: 52.8, dfps: 51.9
1126-msvc2003
User: 37s, kernel: 0s, total: 37s, real: 38s, fps: 52.8, dfps: 52.1
1126-msvc2005
User: 37s, kernel: 0s, total: 37s, real: 38s, fps: 52.9, dfps: 52.2

1126-gcc

1126-msvc2003/2005

[jidelite]

Leak, Again, I applaud you for the excellent progress you have made. My concern with your latest patched version is where you can ‘disable buffering’ – on my system it appears I cannot disable buffering when I uncheck "Apply pulldown" and set ahead and back buffers to 0 (or maybe I am but you are doing something with the frame(s) besides just spitting them out). I have used those clips that the frame duration changes from 41 ms to 33 ms as viewed on the OSD (the ones from Video Essentials and Blood Diamond) as my “torture test” for your patch and my video still stutters/freezes for a couple of sec. at the point were the frame duration changes. I have noticed that my P4 3.0 Ghz usually runs around 50-65% with my filters but at the frame duration changes it's pushed to 100% (from the OSD) which is why I probably see a longer pause. I understand that these frame duration changes can be common (be it a bad it or whatever) but they do not always go unnoticed with your patch; whereas with every unpatched version of ffdshow these same frame duration changes play fine. Now, I don’t sit and look at frame durations counts when I watch a movie but I know a pause when I see one and the only change I’ve made was to uninstall one unpatched version of ffdshow and installed your patched version. In fact, I’ve done this over and over with the same results.

Again, I’m just using ffdshow/Avisynth scripts for realtime viewing of R1 DVDs. I use TheaterTek software player and I want to sharpen my picture a little so I use the SeeSaw or LimitedSharpenFaster filter – that’s it. So far, I haven’t seen anyone else say they are experiencing a slight freezing/pausing with frame duration changes with your patch so by all means, dismiss this as a ‘user error/problem’. I guess I will continue to test and see what happens once your patch is incorporated in the ffdshow builds…

Thanks,
jidelite

[haruhiko_yamagata]

Originally Posted by Leak

*phew*

It only took me half of this afternoon, but I managed to craft a help page for my patch...

Great, your document is very clear and easy to read.

[foxyshadis]

With the blood diamond test, I see a lot of weirdness whenever Haali's is used as the splitter, framerate is halved even though timestamps are correct, and occasional non-reproduceable freezes with the MS dvd navigator and a few other splitters at 0:19, but not the internal one (so far). Since it lasts such a short time, trying to break in at the right moment has been impossible, though setting some condition might work better.

Also, great guide, but I keep trying to click on the checkboxes.

[Leak]

Originally Posted by foxyshadis

With the blood diamond test, I see a lot of weirdness whenever Haali's is used as the splitter, framerate is halved even though timestamps are correct, and occasional non-reproduceable freezes with the MS dvd navigator and a few other splitters at 0:19, but not the internal one (so far). Since it lasts such a short time, trying to break in at the right moment has been impossible, though setting some condition might work better.

Hmmm... would that be with AviSynth filtering or without?

For the record - I'm using Gabest's MPEG splitter, and the file plays through normally for me, whether I use TIVTC or not...

[Leak]

Originally Posted by jidelite

Leak, Again, I applaud you for the excellent progress you have made.

Thanks.

My concern with your latest patched version is where you can ‘disable buffering’ – on my system it appears I cannot disable buffering when I uncheck "Apply pulldown" and set ahead and back buffers to 0 (or maybe I am but you are doing something with the frame(s) besides just spitting them out).

Hmmm... could you try the following?

* Download DebugView from Microsoft

* Run DebugView, go to "Edit > Filter/Highlight..." and enter "TimgFilterAvisynth:" (sans quotes) in the "Include:" box, then hit OK and probably minimize it so it won't take much extra time scrolling the output across the screen

* Add "#debug" as the very first line of your AviSynth script

* Open your media player, play the material you're having problems with until you get past one of those stutters or two

* Save the output of DebugView to a file and mail it to leak (at) gmx (dot) at

That should give us some clues as to what's happening.

I have noticed that my P4 3.0 Ghz usually runs around 50-65% with my filters but at the frame duration changes it's pushed to 100% (from the OSD) which is why I probably see a longer pause.

What happens if you strip down your script to where it doesn't use as much CPU? Could you perhaps try that?

Still, even when the timestamps fluctuate a bit the AviSynth filter shouldn't do anything special, it'll just produce similar timestamp fluctuations in the output, but it won't treat the frame any different than others or reset all buffers or anything.

By the way, what video renderer are you using?

Again, I’m just using ffdshow/Avisynth scripts for realtime viewing of R1 DVDs. I use TheaterTek software player and I want to sharpen my picture a little so I use the SeeSaw or LimitedSharpenFaster filter – that’s it.

Okay, so I don't have that player and really don't want to buy it, so could you perhaps try this in Media Player Classic as well? And, in case you're using the nVidia MPEG decoder that seems to come with TheaterTek, could you please use ffdshow's MPEG2 decoder instead?

I'm pretty sure AviSynth filtering works perfectly with ffdshow's built-in MPEG2 decoder, but I really can't vouch for other decoders...

[foxyshadis]

Originally Posted by Leak

Hmmm... would that be with AviSynth filtering or without?

For the record - I'm using Gabest's MPEG splitter, and the file plays through normally for me, whether I use TIVTC or not...

With avisynth, sorry. Tested with other combinations of apply pulldown, different filters, etc, but changing the splitter was the only thing that ever seems to cause a hiccup.

btw, this is what shows in the debug console when it happens:

[2948] TimgFilterAvisynth: Requesting frame 42 from Avisynth
[2948] TimgFilterAvisynth: Looked up frame 42, using frame 42
[2948] TimgFilterAvisynth: Frame     42:   0 back,   0 ahead; requested 42 
[2948] TimgFilterAvisynth: Delivering frame 42; 2285.616100 - 2335.666000 =  50.049900
[2948] TimgFilterAvisynth: onFlush
[2948] TffdshowDecVideoOutputPin:: DeliverBeginFlush
[2948] TffdshowDecVideoOutputPin:: DeliverEndFlush
[2948] TimgFilterAvisynth: (Re-)Initializing buffers
[2948] TimgFilterAvisynth: Passing through frame 43, 2335.666000 - 2369.032600 =  33.366600
[2948] TimgFilterAvisynth: Requesting frame 43 from Avisynth
[2948] TimgFilterAvisynth: Looked up frame 43, using frame 43
[2948] TimgFilterAvisynth: Frame     43:   0 back,   0 ahead; requested 43 
[2948] TimgFilterAvisynth: Delivering frame 43; 2335.666000 - 2369.032600 =  33.366600
[2948] TimgFilterAvisynth: Passing through frame 44, 2369.032600 - 2419.082500 =  50.049900

I'm stupid, I should have noticed this correlation earlier, ever .5-1s hang has one of these pairs.

By using something called the "Universal Open Source MPEG Splitter" I can regularly make it happen at 0:04 and 0:19.

[_xxl]

x264 is an encoder.Use virtualdub and see if 1126 is faster.ffdshow.ax compiled by MinGW GCC can't detect (S)SSE3.Please use MSVC builds.

[Leak]

Originally Posted by foxyshadis

btw, this is what shows in the debug console when it happens:
[2948] TimgFilterAvisynth: onFlush
[2948] TffdshowDecVideoOutputPin:: DeliverBeginFlush
[2948] TffdshowDecVideoOutputPin:: DeliverEndFlush
[2948] TimgFilterAvisynth: (Re-)Initializing buffers

Ugh. The other splitters I know only do a BeginFlush when you seek in the DVD navigator; that's sadly about the only way to detect that there is some seeking going on at that point in a DVD graph.

So what I do is drop all buffered frames, then start buffering again - processing and delivering the frames that had been buffered before the seek will just make things look funny and take longer.

I guess I'll have to try using Haali's splitter when I get home, but I'm not sure what I should do about this - if I ignore the DirectShow flushes navigating the DVD will get laggy.

EDIT: But I still can't figure out why it would stutter with the settings you had to have set, namely no Apply pulldown and no buffering - after all, in that case it just passes through the current frame, with no pre-buffering or anything else that would take any noticeable time (and nothing to drop, either), and as you can see the timestamps are consecutive as well...

EDIT2: The timestamps on the DebugView log entries would have been interesting... those would show where the exact pause happened.

[chros]

@haruhiko_yamagata: I don't want to hurry you, but when will be merged the DFX multichannel patch?

Thank you for your effort ...

[jidelite]

Originally Posted by Leak

Thanks.


Hmmm... could you try the following?

* Download DebugView from Microsoft

* Run DebugView, go to "Edit > Filter/Highlight..." and enter "TimgFilterAvisynth:" (sans quotes) in the "Include:" box, then hit OK and probably minimize it so it won't take much extra time scrolling the output across the screen

* Add "#debug" as the very first line of your AviSynth script

* Open your media player, play the material you're having problems with until you get past one of those stutters or two

* Save the output of DebugView to a file and mail it to leak (at) gmx (dot) at

That should give us some clues as to what's happening. ...

When I get home I will certainly try and debug this on my PC. I will try to do this on an unpatched version as well.

What happens if you strip down your script to where it doesn't use as much CPU? Could you perhaps try that?

When I strip down my script to where my OSD says I'm using about 15-20% cpu (and buffering is disabled), the pause time is definitely reduced but the OSD does show something being reset. I don't know if this makes a difference but I'm also using the mult-thread version of the avisynth.dll from tsp's MT package.

Okay, so I don't have that player and really don't want to buy it, so could you perhaps try this in Media Player Classic as well? And, in case you're using the nVidia MPEG decoder that seems to come with TheaterTek, could you please use ffdshow's MPEG2 decoder instead?

I can't blame anyone for not wanting to purchase a particular player so I will try to use MPC and I'll try to see if I can build a graph to use ffdshow's MPEG2 decoder instead...

Thanks,
jidelite

[Leak]

Originally Posted by jidelite

I will try to do this on an unpatched version as well.

That won't do much, as none of the debug output I'm looking for is printed by the unpatched version...

But if what foxyshadis wrote above is the same that happens to you then I'm not sure how to fix it - after all, the splitter in that case asks ffdshow to flush everything it has queued, and I happily oblige...

[foxyshadis]

Originally Posted by Leak

EDIT: But I still can't figure out why it would stutter with the settings you had to have set, namely no Apply pulldown and no buffering - after all, in that case it just passes through the current frame, with no pre-buffering or anything else that would take any noticeable time (and nothing to drop, either), and as you can see the timestamps are consecutive as well...

EDIT2: The timestamps on the DebugView log entries would have been interesting... those would show where the exact pause happened.

The stutter is just the scriptenvironment re-initializing itself, changing settings always causes the same lag for me; the luts for seesaw take a bit to fill, and I bet jidelite's complex script is using quite a few of them with several instances of something like MT+LSF (where each filter has to be initialized in each thread) so it's worse.

I wish debugview copied timestamps, but they were at 4.4s and 23s from the start, which didn't correspond to the video time. The first was at frame 43; it's dark but noticeable. I ran dgindex over it but since I don't deal with mpeg-2 much, I don't know what to look for to detect errors.

I'm also not sure what can be done about it. Set up some kind of conditions to just ignore it? I don't know.

[Leak]

Originally Posted by foxyshadis

The stutter is just the scriptenvironment re-initializing itself, changing settings always causes the same lag for me; the luts for seesaw take a bit to fill, and I bet jidelite's complex script is using quite a few of them with several instances of something like MT+LSF (where each filter has to be initialized in each thread) so it's worse.

Ah, but it shouldn't be doing that, and it most probably isn't, unless you get two messages about "(Re-)Starting playback" and "Freeing buffers". In all other cases (unless buffering is totally disabled), I only seek forward 1000 or so frames in the script (to make sure AviSynth doesn't re-use cached stuff), which shouldn't have that much of an impact.

The stutter with buffering turned on is most probably coming from decoding and buffering 12 frames (in TIVTC's case) before playback resumes, but of course that shouldn't (can't?) happen when it's turned off...

I gotta try to reproduce this with Haali's splitter, but first I need to test that RMAed 17" piece of monitor next to me...

np: Burnt Friedman - Fucking Long Time (Plays Love Songs)

[Fizick]

Leak, correction of doc (last phrase):

Replace:

...disable "Apply pulldown" to get the old behaviour of earlier AviSynth versions back...

By:

...disable "Apply pulldown" to get the old behaviour of earlier FFDSHOW versions back...

[Leak]

Originally Posted by Fizick

Leak, correction of doc (last phrase)

Errr... oops.

[Soulhunter]

Hey, just want to thank you all for continuing FFDShow development! :]


Thanks 'n Bye

[Px]

Originally Posted by drevil_xxl

x264 is an encoder.Use virtualdub and see if 1126 is faster.ffdshow.ax compiled by MinGW GCC can't detect (S)SSE3.Please use MSVC builds.

Ok, I'll test it on sunday.....