[RESOLVED] Best way to decimate...

Support forum for DGDecNV
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: Best way to decimate...

Post by magic144 »

I have uploaded these elementary stream files:-
test.264, testhuffy.264
to the shared folder too... this is my "stuttering" output (pre-mkv) and "smooth" output (pre-mkv)
you can also compare these with yours
interestingly, testhuffy.264 is bigger...

when stepping through test.264 in DGIndexNV, I note the following pairs of frames between which there is no apparent motion of the moon
{34,35}, {36,37}, {39,40}, {41,42}, {44,45}, {46,47}, {49,50}, {51,52}, {54,55}, {56,57}, {59,60}, {61,62}, {64,65}, {66,67}

whereas in my smooth output, testhuffy.264, there is a fluid constant motion when stepping through.
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: Best way to decimate...

Post by magic144 »

thanks for posting your file

this exhibits exactly the stuttering I am describing - see my previous post for the breaks in fluidity I describe (your encode matches frame-for-frame)

grab my testhuffy.264 file (output of METHOD 1) and compare
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Best way to decimate...

Post by admin »

I want you to use AVISource() and not DirectShowSource().
DAE avatar
Didée
Posts: 22
Joined: Wed Oct 27, 2010 2:19 pm

Re: Best way to decimate...

Post by Didée »

Groucho2004 wrote:You should use official Avisynth releases for troubleshooting, not experimental MT versions.
If you're pedantic, not even the official 2.5.8 is safe for testing. IIRC, Srestore was developped in Avisynth 2.5.6. Given the tricky nature of the script (conditional environment / scriptclip), you can't be sure that it works 100% correctly in 2.5.8 ... :?
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: Best way to decimate...

Post by magic144 »

as far as I'm aware, this version of avisynth.dll is what was installed by the 2.58 installer (stable)
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Best way to decimate...

Post by admin »

If you use Avisynth MT I'm out of here. I do not guarantee anything with that and won't work on any issues if it is used.

Nevertheless, I do see the problem with vanilla Avisynth. I did a subtract on the test.avs output and the test.264 and I see the issue.

So I simply encoded again with HCEnc. That way the issue does not occur. I monitored the frame number requests seen by DGDecodeNV and they were identical for the AVC and the MPEG2 encodings (and also for playing in VirtualDub). So I tentatively conclude that x264 is responsible.
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: Best way to decimate...

Post by magic144 »

Just to repeat myself, I've never gone out of my way to install some test/experimental version of AviSynth. It's vanilla 2.58 as far as I know.
Here's the md5...
f498e945211157e0063ce9ed6e679f1d *avisynth.dll

Now then,
AVISource gives me the same temporal stuttering!
(I had to enable Huffyuv decoder in ffdshow's VFW codec... is this what you use?)

so if you're saying that AVISource is more reliable than DirectShowSource, that's a bit (a lot) annoying, since DirectShowSource seems to give a better result.
DAE avatar
Didée
Posts: 22
Joined: Wed Oct 27, 2010 2:19 pm

Re: Best way to decimate...

Post by Didée »

That was only theoretical. I've used Srestore with good success under both 2.5.8.5.MT and 2.6.MT. (Of course without actually using multithreading - that's technically impossible with Srestore.)

Problems that I see here are:

1) it's the very beginning, which is always critical. The start is just black, then the moon starts moving *very* slowly. Srestore might have problems to snap onto the correct pattern.

2) Conditional-Environment-scripts are highly sensible to out-of-order frame requests. Such might occur because of the rather big read-ahead that x264 is doing.


To be on the safe side, you could try adding buffers both on the input side and on the output side:

Code: Select all

DGsource("video30s.dgi")
changefps(last,last,true) # small readahead buffer for Srestore
bob(0,0.5)
s=reduceby2()
Srestore(frate=25.0,speed=-1,dclip=s)
RequestLinear(rlim=X, clim=X) # set 'X' a bit larger than x264's RC-readahead (MB-tree)
return(last)
See if this helps. It won't do any harm, at least.

+ + +

On another note - it's really a joy to simply drop this source in DGDecNV, and be up & running, without any problems whatsoever!

(Needed to jump through a few loops before my DS-Player wanted to play the darn VC-1 sample. And also, quite funny to see eff-eff-something dying inglorious deaths when you try to feed it with this video...)
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: Best way to decimate...

Post by magic144 »

@DG
you're right - HCenc DOES make test.avs work (whaaaat?!?!?!)
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Best way to decimate...

Post by admin »

magic144 wrote:AVISource gives me the same temporal stuttering!
That is the result I was expecting.
(I had to enable Huffyuv decoder in ffdshow's VFW codec... is this what you use?)
No, I just installed Ben's original VFW codec. Ben's site is mirrored at my site. It's a great browse if you've never looked in there.
so if you're saying that AVISource is more reliable than DirectShowSource, that's a bit (a lot) annoying, since DirectShowSource seems to give a better result.
Ah well, there's the rub. I don't know for sure what's going on here yet. Didée's point about the x264 lookahead suggests a viable cause of the observed discrepancies. Still investigating...
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Best way to decimate...

Post by admin »

Didée wrote:On another note - it's really a joy to simply drop this source in DGDecNV, and be up & running, without any problems whatsoever!

(Needed to jump through a few loops before my DS-Player wanted to play the darn VC-1 sample. And also, quite funny to see eff-eff-something dying inglorious deaths when you try to feed it with this video...)
Yeah, what's up with that? You'd think someone could understand a simple thing like VC-1 interlacing. Or maybe no-one wants to spend the bucks on the standard? These streams are pretty common now. Maybe the FFers are too busy having coups and stabbing each other in the back.
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: Best way to decimate...

Post by magic144 »

@Didee
didn't seem to make a difference I'm afraid
(what's the significance of s?)
tried it with bob and yadif, same stutter
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Best way to decimate...

Post by admin »

Can we get some debug output from srestore, to monitor its pattern lock in the various cases?

My hypothesis is that we are seeing a difference of lock in srestore at the start of the stream, as Didée suggests. I don't think there is any evidence to suggest that DGDecNV is doing anything wrong here. In fact, maybe no-one is doing anything wrong per se. Maybe this is just a limitation of srestore when used in a complex environment where orders of frame requests, DirectShow quirks, etc., can be significant.
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: Best way to decimate...

Post by magic144 »

I don't know much about srestore, I'm afraid.
I think it was Sharc who first suggested its use to me when I first started looking at this disc. This very painful disc!
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Best way to decimate...

Post by admin »

I was addressing Didée about the debug output.

What disk is it, BTW?
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: Best way to decimate...

Post by magic144 »

Doctor Who
Series 5
1st Episode - "The Eleventh Hour"
(Canadian - or at least North American - Retail, BD)
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: [OPEN] Best way to decimate...

Post by magic144 »

so out of interest,
what does a software player like PowerDVD do when it plays back such material on a PC monitor and uses hardware deinterlacing (i.e. from Nvidia in this case) - does it have its own decimation algorithm built-in? or is there some mode whereby it can get the hardware to give it back a stream with dupes removed??
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: [OPEN] Best way to decimate...

Post by admin »

Marking resolved as all evidence points to idiosyncracies of srestore.
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: [RESOLVED] Best way to decimate...

Post by magic144 »

That's too bad :-(
I guess the only way to reencode this stuff is to retain the interlacing then...
(which also means resizing is out of the question)

Thanks for giving it your attention.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: [RESOLVED] Best way to decimate...

Post by admin »

magic144 wrote:(which also means resizing is out of the question)
No it doesn't.
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: [RESOLVED] Best way to decimate...

Post by magic144 »

Oh, I thought you had to deinterlace in order to resize effectively?

How does one resize an interlaced stream (whilst maintaining the 'lacing)? Is it a special feature of DGDecNV, or is there a special AviSynth script/function?
DAE avatar
magic144
Posts: 25
Joined: Sat Feb 19, 2011 2:53 pm

Re: [RESOLVED] Best way to decimate...

Post by magic144 »

Sure - I even saved some post info from Scharfis_Brain from your rationalqm.us forum a long time ago...
(this was a specific example to do with resizing interlaced 16:9 LB -> 16:9 anamorphic, but anyway)

I believe the spirit of the idea was from Mug Funky a while back...

Code: Select all

mpeg2source("blah.d2v") 
crop(0,72,0,-72) # crop away borders 
TDeint(mode=1,type=3) # use a smart bob-deinterlacer with Edge Directed Interpolation like Faroudja does. 

bicubicresize(width,576) # resize 432 -> 576 
converttoyuy2() # needed for proper re-interlacing 
assumeTFF() # set the wished output field order 
separatefields().selectevery(4,0,3).weave() #reinterlace
it relies on a bobber to try and take care of most of the damage the resizer will do to the interlaced field resizing

I just meant it cannot be perfect... but I'm beginning to learn that I need to compromise on more things in DV every year :-)
Post Reply