View Single Post
Old 28th March 2019, 09:04   #17  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,545
Quote:
I try to help people, not berate them.
This is what I am trying too here, thanks johnmeyer, for your research, countless suggestions and precious time here and in other forums !

I shall prepare a comparison test across a few source tapes/players/cameras/systems/capture variants I have here,
time permitting.
At the moment it is a batch of 40mg tiny coil pairs I have to glue together, strip X-},
and glue in place, solder, measure and hope my eyes hold sight...

rarend: I vaguely remember to have bought & tested a few (3?) DV-AVI capture boxes as these became available.
Their differing results were straight dependent of the actual codec implementation, not the fact that it would be DV.
One did it right !
(The DV 4:2:0 chroma reduction being acknowledged beforehand and not further discussed withing this post)
I had to drop 2 of them, one was the Pinnacle.
Those both had poor hardware implementations of DV compression, giving visible blocks.

I seem to remember that a NEC DV chipset used in Canopus ADVC300 did it properly. (have to open it again)
(300 for me because of the added tweaking possibilities, the ADVC50 and ADVC100 used the same DV hardware encoder device I guess.)

Next faults came in by poor DV decoding.
So system players did DV chroma interpolation wrong.
I remember to have seen a player plainly repeating YV12 chroma samples for both neighbored fields.
Then came fixing the wrong chroma kernel, fixing of wrong chroma placement.
Then I found NLEs that used DirectShow (EditStudio) to deliver blocks.
Well, the 8bit-engine did its damage too, but out came blocks that the source did not have.
Reason: The implemented DV algo in XP quartz.dll indeed added blockiness.
I went to Vegas and finally that issue was solved. Native decoders.
(Later an quartz.dll update came in and with Win7 quartz.dll I could not see these blocks anymore.
Me guessing here: To avoid DV patent liabilties with Sony and to be on the safe side the MS implementation came out imperfect ?
I remember the Apple side of things (Quicktime) had the same quirks around some codec implementations,
DV being one of them, besides intentionally re-mapping sample values.
Later silent updates fixed that...Patents expired ? Could be that simple.
I did not research around those timings, somebody else may.)
Some software DV implementations come into my mind: Sony, Mainconcept, Microsoft, Cedocida, FFmpeg, Quicktime
And DV hardware: Sony, NEC, and some more.
Not all DV implementations get everything right, but it is well possible now.

Bottom line: If DV (non-pro): Avoid the Pinnacle Box and related DV hardware encoders.
(Plug-in Stick MPEG-2/MPEG-4 hardware encoders are not worth considering within the scope of this thread)

If the source chroma is poor and/or 4:2:0 anyway and one is content with 4:2:0 DV (non-pro)
and one tolerates the CUE with interlaced YV12 one may find a canopus box for cheap
(or use a DV camcorder like Sony PC-100, or the mentioned PC-120 in passthrough, same quality codec-wise.
Which the OP did.)

If one does not tolerate the CUE because he wants to get best chroma out of a interlaced source that is worth 4:2:2
and the budget allows for 200USD/€ AND USB3.0 is fully implemented on your Motherboard:
Why not have access to a 10-bit 4:4:2 uncompressed intermediate ?
You will not want to miss once you got it. Huge files of course, but we don't complain about that.
The system ate money, the learning curve ate precious lifetime already.
So with the invaluable help of a community which helps to develop Avisynth and its filters and scripts,
we intend to chain fine sampling, preprocessing,
(For interlaced sources I go the QTGMC route to double framerate almost everytime,
and now we are blessed with fluid and non-leaking chroma)
editing, compositing, postprocessing, and after all that effort: Quality was our goal, I think.

P.S: Looked at the OP's captured .avi file once again: Just viewing in MPC-BE now
Since the OP's chain is reported to have delivered good results:
Quote:
And while this particular troublesome footage is from a private VHS recording, I have had excellent results with capturing retail VHS-tapes this way.
I seem to be barking up the wrong tree here...
The source simply seems to have been recorded by/rerecorded from a poor deck.
To me it simply looks like it would be a 2nd or 3rd generation loss caused by 99€VHS to 149€VHS (to 199€VHS?),
going the composite route maybe via SCART or even worse:
PB 1st Deck PB -> Composite -> UHF modulator -> CH39 Antenna output ->
REC 2nd Deck Antenna input -> CH39 Demodulator -> Composite -> REC
so the chroma bleeding faults should be already woven-in.
Well, DV25's YV12 is adding to that by smearing chroma just across one more line.
Here I won't blame the OP's capturing chain exclusively anymore...
Playback Paused: the interlaced combs looks suspicious while reds are on the drumset !

Now Avisynth Fieldcheck in Double-PAL 50,000fps:
Within a frame 2 consecutive fields show 2 advancing moments in time.
Next frame, first field shows the same moment in time.
Now a simple temporal fieldshift mends that and delivers the 2 temporals field in one frame.
Still the content doesn't match spatially, jagged edges.
I hope to see the untouched capture here... TMF9, NL under that that Logo 1996..2002 ?
TMF9 Logo and content don't match spatially. When the logo is round, the content is jagged.
Either the shooting was in 25p and on editing shifted by one field or something went indeed wrong afterwards.
If I fieldshift temporally I get chroma field bleeding across edit borders.
Here we cannot have 4:2:0 anymore.
This develops into a nice showcase where capturing in 4:2:0 DV-AVI adds damages before repair.
A 4:2:2 capture would definitely help here !
Can be mended, no time now...
Quickglancing script: I wouldn't have come up with that one. OP, please report ;-)
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."

Last edited by Emulgator; 28th March 2019 at 13:28.
Emulgator is offline   Reply With Quote