IVTC of 'Castle' episode leaving blended frames (ghosting?)

[poisondeathray]

Could it be encoding? ie. HCenc? Are you seeing the dupes in vdub/avsp even before you encode it? (when you preview, make sure you do it linearly, no scrubbing - i.e. advance from frame by frame to 0-40 or so, do you see the dupes?)

The dates you provided aren't necessarily accurate - they can be changed as from when you downloaded it. I think it's more important to confirm the version#

e.g. TIVTC 1.0.5.0
e.g. My srestore script is 2.7e (not sure of the date)

Anyways, I think it was jagabo who had difficulty reproducing the same results as other people with srestore, even though he went through all his .dll's - I don't think he got to the bottom of it, maybe you could PM him

And I agree, it's not that bad with the blends , I could live with it for a TV rip

[txporter]

Yes, I see it in vdub when doing single frame advance without scrubbing. I am not sure how to get the version #s on the dll (not all of them have a version in the dll). I found another post by manono about average.dll as well and tried his link there for that plugin. I also downloaded a newer version of masktools2 from manao's website (2.0 a36). Still seeing dups.

average.dll - no version, using manono's linked dll
dgdecode - 1.5.8
masktools-25.dll - 2.0 a36
removegrain.dll - no version, using manono's link dll
yadif.dll - 1.7.0
vsfilter.dll - 1.0.1.3
tivtc.dll - 1.0.5.0
srestore.avsi - no version. will try downloading known version

update: fairly certain it was whatever version of srestore.avsi that I had. Downloaded 2.7e from here and stepping through with vdub seems to be smooth without dups now.

[poisondeathray]

If you see it in vdub before encoding, it's likely a script or plugin issue

If you open the srestore.avs (or avsi) in notepad or avsp, it will list the version

I'm using a35 for masktools, not sure if it will make a difference. I'll upload the complete zipfile

EDIT: whoops, didn't see your edit...

[txporter]

Thanks, pdr. I am 99% certain that a35 was the version of masktoolsv2 that I was using earlier. I am running another encode now and will check the results. I think it will be more inline with what you uploaded.

Yeah, checked in the header on the original version of srestore.avsi that I was using. It didn't have a version, but the downloaded one does.

Is there any reason that I can't use this same script (yadif.srestore) with all 1080i conversions (even if not from ABC HD?) or is it better to go the standard TFM.Tdecimate route with 1080i that are hard telecined and only use yadif.srestore for the mucked up ABC material? I prefer to use the same general script to cut down on my batch files, but can easily do either way.

And new encode looks good. Thanks a lot! That might be a better solution than what I was seeing with TFM.Tdecimate.

[poisondeathray]

Hold up: Using the versions I have, there is a dupe 2608-2609 when using yadif. But using a better deinterlacer (NNEDI2) seems to get rid of it. It's much slower, and might not be worth it for you

EDIT: this is weird, the next time I ran through it and checked it with yadif, it's gone ?? It might be a memory management issue with avisynth filters and cached frames. I suspect it might be ok if you do a linear encode from start to finish

As for using a general script, I don't think you can, if ABC or your local affiliate does funny business, there is no way to use a generic script and have it "perfect" for everything

Personally I would just accept the blends if this is a representative sample of what you get when you capture, they aren't that bad for a TV rip

[manono]

If I were you, I wouldn't worry about it because trying to fix it may be more trouble than it's worth and may not be entirely possible anyway.

That's what I said, isn't it? The script I came up with seemed to work on the parts I checked. As you saw, it's quite slow so I didn't check all that much.

HCenc complains about the framerate

Then you put an assumeFPS(25) at the end of the script and set the final framerate afterwards using DGPulldown. I didn't know for sure you were making a DVD and didn't know at all that you were using HCEnc.

...but I need to stretch the audio since it goes out of sync.

Then you're doing something wrong because that script doesn't change the length.

The blend is gone around frame 980 (now around 990).

It was around that area that I checked most carefully, that first blend you mentioned.

The jerkiness I noted around 2580 is still there (now around 2600).

I never checked that.

Is there any reason that I can't use this same script (yadif.srestore) with all 1080i conversions (even if not from ABC HD?) or is it better to go the standard TFM.Tdecimate route with 1080i that are hard telecined and only use yadif.srestore for the mucked up ABC material?

You don't really want to use SRestore unless you have to because it doesn't field match as a true IVTC does. It always gives you back bobbed fields.

[txporter]

If I were you, I wouldn't worry about it because trying to fix it may be more trouble than it's worth and may not be entirely possible anyway.

That's what I said, isn't it? The script I came up with seemed to work on the parts I checked. As you saw, it's quite slow so I didn't check all that much.

Yes, I was just trying to figure out why it was better than the simpler yadif.srestore(23.976) that poison had posted.

HCenc complains about the framerate

Then you put an assumeFPS(25) at the end of the script and set the final framerate afterwards using DGPulldown. I didn't know for sure you were making a DVD and didn't know at all that you were using HCEnc.

Not making a DVD. Just pushing the re-encoded video back to my Tivo. I tend to use MPEG2 encodes a lot still because it (TivoHD) has playback issues with h.264 material at less than 25fps (I had a post about shimmering subtitles in the past that dealt with this).

...but I need to stretch the audio since it goes out of sync.

Then you're doing something wrong because that script doesn't change the length.

This could very easily have been my fault. I updated my mux batch file to use 24.2fps before I thought through your script.

Is there any reason that I can't use this same script (yadif.srestore) with all 1080i conversions (even if not from ABC HD?) or is it better to go the standard TFM.Tdecimate route with 1080i that are hard telecined and only use yadif.srestore for the mucked up ABC material?

You don't really want to use SRestore unless you have to because it doesn't field match as a true IVTC does. It always gives you back bobbed fields.

Ok, good information. I will just have to test to see whether the TFM.Tdecimate or yadif.srestore versions are more watchable. Frankly, they are probably both fine. Thanks for your thoughts.

[edDV]

ABC is part of Disney. Disney, Family Ch and Toon also do variable 720p frame rates with animations. ESPN is mostly live 720p/59.94 fps but many commercials are frame repeated 23.976p.

I talked to a friend that used to work at Belo. He recalls the reason for converting the ABC feed was to standardize all local news operations to 1080i. Belo operates regional cable news networks for Texas and the Pacific Northwest. All the regional stations contribute and share locally produced news and magazine type shows. 1080i was used for interoperability.

Belo's Texas Cable News Channel (TXCN) is a joint operation of these Belo owned stations

KVUE-DT (abc) Austin
WFAA-DT (abc) Dallas
KHOU-DT (cbs) Houston
KENS-DT (cbs) San Antonio
with additional material from
WWL-DT (cbs) New Orleans

Belo's Pacific NW Cable News Channel (NWCN) also operates all 1080i but has no ABC or Fox affiliates there.

Belo also owns KMSB (Fox) in Tucson but runs that 720p.

[txporter]

ABC is part of Disney. Disney, Family Ch and Toon also do variable 720p frame rates with animations. ESPN is mostly live 720p/59.94 fps but many commercials are frame repeated 23.976p.

I talked to a friend that used to work at Belo. He recalls the reason for converting the ABC feed was to standardize all local news operations to 1080i. Belo operates regional cable news networks for Texas and the Pacific Northwest. All the regional stations contribute and share locally produced news and magazine type shows. 1080i was used for interoperability.

Belo's Texas Cable News Channel (TXCN) is a joint operation of these Belo owned stations

KVUE-DT (abc) Austin
WFAA-DT (abc) Dallas
KHOU-DT (cbs) Houston
KENS-DT (cbs) San Antonio
with additional material from
WWL-DT (cbs) New Orleans

Belo's Pacific NW Cable News Channel (NWCN) also operates all 1080i but has no ABC or Fox affiliates there.

Belo also owns KMSB (Fox) in Tucson but runs that 720p.

Well, I guess that Time Warner has done me a favor by setting the CCI byte to copy once on nearly all of its channels (except those also broadcast OTA). The only disney station that I can download and edit material from is ABC.

[edDV]

Off topic but related to Belo.

A.H. Belo (AHC) a newspaper company, spun off its TV stations into a separate company Belo Corporation (BLC) in 2007. The BLC stock dropped from ~$10 down to below $1 during last year's crash. I bought some of this high class junk stock starting at $1.50. Today it has climbed back to ~$7.

The other TV station group stocks have had similar wild swings. They fluctuate with advertising spending.