repeat-field and random access - slight bug?

[Mug Funky]

i'm using latest DGdecode from doom9 (1.4.8).

i noticed that when refreshing a script in virtualdubmod (ie f5 from the script editor view), sometimes the wrong picture comes up for 1 field. i tracked it down to (i think) a repeat-field issue, where avisynth is asking for that exact field (via bob() or a deinterlacer), and it's returning a repeat of the last field decoded (in the refresh case, that'd be the first frame).

this doesn't affect encoding, but random access, so it's not a major issue. however, if one scrubs video for long enough on a soft-pulldowned clip it will no doubt show some random fields.

i have a 5mb clip i can reproduce on, but i suspect it can be reproduced on any clip with repeat field flags.

script is simply:


mpeg2source("soft-pulldowned-file.d2v")
assumetff()
bob()

[neuron2]

Please describe the exact sequence of operations that causes a wrong frame to be displayed.

I assume you are aware that if your project has Honor Pulldown Flags set, then you will get combed frames in the script output (soft pulldown -> hard pulldown). So you'd expect to see mixed fields "sometimes".

[Mug Funky]

it's not a matter of mixed fields - i'm encoding hybrid stuff, so force film is not an option

sequence of operations (roughly):

1. make a d2v :)
2. load it in an avs, and add "assumetff().bob()" or assumebff, of course.
3. (here's the sketchy part) skip through in virtualdubmod and find a frame that's probably a repeat field
4. open script editor and hit f5 when VDM's playback head is on the suspect frame
5. if, when the script is refreshed, you're actually looking at the first frame (usually black), then repeat step 3 from another frame.

there used to be an ftp in your sig, but i'm not sure if i'm set up on this machine for that anyway :) i might have a shot at rapidshare or some free host... it's been a while since i posted a sample :) but anyhoo, i have a sample with a frame number that reproduces the issue.

[neuron2]

Yes, please provide the clip.

[Mug Funky]

sorry about the delay (weekend... file was at work)

http://rapidshare.de/files/36040540/trinity_blood_opening_chunk.m2v

this script gives a green 1st frame when loaded.

mpeg2source("E:\buggy video\trinity blood opening chunk.d2v",idct=7,cpu=0)
assumetff()
bob()

trim(126,0)

[neuron2]

this script gives a green 1st frame when loaded Yes, you've found a bug in random access with RFF present. I have fixed it in my local build and will release a new beta this evening. Thank you for pointing this out.

[neuron2]

OK, please try DGMPGDec 1.4.9 beta 3 and let me know your results.

http://neuron2.net/dgmpgdec/dgmpgdec149b3.zip

[Mug Funky]

seems to work now :)

thanks for the new build!

i'd been getting odd frames before, but thought it was my script messing me around (still a few bugs in that...)

[Mug Funky]

hmm. looks like i spoke too soon - there still seems to be some oddness going on with RFF's. this time it seems to be occuring around scenechanges, and the consequence is a frame (or 2-3) with reversed fields.

i've also discovered that using scriptclip to switch between a couple of clips counts as random access, so this behaviour is showing up on encodes.

i'm guessing the scenechange thing is hitting scenechanges due to a pattern change being detected in my auto-ivtc script (it'll be switching between IVTC'd and regular bobbed clips, causing a random access i suppose.

using regular bob and VDM's "refresh script" (f5) will do the same thing - seeking to just before the problem frame and right on it produces different results.

once i figure out how to reliably reproduce this with a simple script i'll upload another sample and script for you.

[neuron2]

once i figure out how to reliably reproduce this with a simple script i'll upload another sample and script for you. Waiting patiently...

[Mug Funky]

okay, to save time i used the same clip i already sent you.

loadplugin("C:\Program Files\AviSynth 2.5\plugins\dgmpgdec149b3\DGDecode.dll")

mpeg2source("E:\buggy video\trinity blood opening chunk.d2v",idct=7,cpu=0)

assumetff()

bob()

reverse()

this should give you several "jerks" when played back. same happens when stepping through.

[neuron2]

Yup. There's something fishy going on. This one will take a while as I need to review all the navigation code again. Thanks for pointing it out.

[neuron2]

It turns out my fix for your first issue in this thread was wrong. Please try DGMPGDec 1.4.9 beta 4, which hopefully fixes everything.

http://neuron2.net/dgmpgdec/dgmpgdec149b4.zip

The cause of your initial problem was that a field of one GOP was being pulled down into the next GOP. But only the second GOP was decoded, so the pulled-down field was invalid. I now detect this and decode the previous GOP first (as for leading B frames).

Your second problem was caused by my previous fix to your first problem. :)

[Mug Funky]

thanks heaps for that - i've updated and i'll get back to you if there's any more oddnesses (that aren't my own fault :)).