Optimal HI8 to MPEG2/MPEG4 workflow – facing a couple of problems

[Jordan]

Allright- it's getting worse! I did some testing today!

Apparently all of this has to happen while digitizing the s-video source. By thinking this through I was wondering: what does the DV cam do to convert TFF S-Video material to BFF DV material- because that is something that is often just stated as a fact. "DV is alway BFF while most other Pal signals come as TFF" ... well... okay..

Does it happen that way?:

Hi8 Camcorder outputs TFF S-video signal [T(op)-B(ottom)]-[T-B]-[T-B]...
DV cam wants do store BFF material that still is correct in terms of temporal and spatial (vertical) information and could just drop first upper field to create 25fps full resolution frames: (XXTXX)-[B-T]-[B-T]... which would mean a field shift on the temporal axis. Unfortunately it doesn't seem to be that easy...

I looked at the fields of my files by using AssumeBFF.SeparateFields(), hoping I would in the end find just the exact same fields in every test-clip (and all this confusion beeing due to some weaving issue, that could easily be reverted...)

I see two different scenarios:

1) actual image content kinda jumps up and down one line when there is not a lot of movement in the shot. In my understanding (which could be wrong...) this could be the right way for it to look like, because the fields appearing now one after the other do not actually show the same vertical information but the one that is "between the lines" of the previous (dominant) field. Some techical detail that might help: in this case, the timestamp that the HI8 Camcorder has put on the fields, does NOT move at all, but stays perfectly still in the same spot.

2) Immediately visible: the timestamp jumps up and down one line on every field. The actual image content appears to be more stable on the vertical axis, but when looking closely, you see some flickering as well.



Comparing the exact fields of these two scenarios it seems like in 1) every "first" field has been shifted upwards one line, revealing a new (mostly) black line on the bottom.
...or every other field in series 2) has been shifted downwards - but there is no 'new black line' at the top of those fields. (maybe there is still some overscan, not beeing displayed that could compensate for this on the top?!)

Honestly- I am no longer sure which would be the correct way for it to look.
Although the deinterlaced 50fps files of those test clips almost look the same, it feels like one of the scenarios would affect QTGMC's routine to interpolate the full frame in an undesirable way, because the vertical Information of the surrounding fields is not properly placed. Which is probably the reason why a direct comparison of the "same" deinterlaced frames reveals they are slighly off in the vertical axis and in the (interpolated?) details.

As I said, the deinterlaced video looks surprisingly satisfying as for the underlying field-mess and I probably would have not even realized all this, but now I checked all the DV captures I have done so far and found out, that the behaviour of the fields even switches between scenario 1) and 2) several times within one hour of film within a big dv-avi file (often, but not necessarily after a two-field blocky, pink DV glitch in a dark area while there is a cut in the original HI 8 footage.

As this is obviously not being transferred the way it should be, it frustrates me quite a lot, and I would be glad if someone would come up with a good explanation for all that, and a way to fix it!

Thanks a lot!

[smok3]

Probably some sort of TBC in analog domain would help here. As for the easier way, try some capturing using a Digital8 player (if accessible), which would eliminate the s-video path.

Quote from wikipedia

Most, though not all, Digital8 camcorders can play back analogue Video8 and Hi8 tapes.

[Jordan]

Hey- thanks for the reply! Maybe a TBC could indeed solve that- I have been thinking about that as well, but my knowledge of the analogue video world is very limited... But other than this specific error, there do not seem to be other problems that a TBC would typically fix, like jitter- none of that at all! Overall imagequality is surprisingly good after 22 years except for some noise. It might also be probably be rather difficult to gain acces to one of those Electronic Design TBC-Enhancers (or similair models), which might do the job. Renting them (at least here in Germany) seems to be difficult.
A Digital8 Camcorder would be easier to get, so I might give those a try, although I read somewhere, that they tend to overdrive the brightness...

I once again looked at the fields, and I am pretty sure that every second field is shifted downwards one line in the respective parts of the film. As I said there are those cuts where the behaviour just flips from one field to the other.

[ChiDragon]

Could you post some unprocessed video clips somewhere showing the issue? Trying to decipher what you mean from text alone is pretty tough.

[Jordan]

Sure! Here is a DV-avi demo clip that shows it.

http://depositfiles.com/files/zp150w8ok

This is actually live footage from the HI8 cam captured via SVideo through my miniDV cam. I tried to reproduce the error by toggeling record mode on the HI8 cam on/off to see if the normal image distortions that happen at this very moment and/or the brief absence of signal on the svideo port would trigger the miniDV cam to change digitizing behaviour. It did indeed work (sometimes- sometimes not). The behaviour in this clip is identical to what happens in the tape footage.
But be aware: you can only see that "something is wrong" once you separate the fields with an avisynth script like

AviSource("demo.avi", audio=false)
AssumeBFF.SeparateFields()

Now skipping through the frames (thus fields now) that the appearance changes. Most notably because the timestamp/on-screen text jumps up and down at first and then stays perfectly calm. If not displayed (like in some of the footage) it becomes difficult to determine which of the scenarios is present.As mentioned, by comparing different captures of the exact same footage (first scene on one of the tapes) with both possible behaviours (as in aboves demofile) by means of an overlay in photoshop and even in premiere, you could see that, say, field "A" is identical in both clips while field "B" is obviously shifted in the vertical axis.
At first I thought, the version where the timestamp does NOT move is the correct one. To take my miniDV Camcorder out of the equation, I now rented a Canoups ADVC 300 for a week. Although it seems to have some issiues of its own (apparently duplicating frames to keep audio in sync... but who knows what the miniDV cam does...) it seemed to be a reasonable choice because it has a built-in Line Time Base Corrector (see above)
Turns out that every Canopus-capture I analysed by separatefields() behaved like the beginning of the demo.avi (date jumping up and down). No variation no matter what kind of cut in the footage, date keeps on jumping, so I now assume that THAT is the way it is supposed to look. Can someone approve that?

BTW, as the two images I ment to attatch in the first place still seem to be pending approval I will upload the somewhere else, so here they are:

(google photos...)

https://goo.gl/photos/izxyjKbKC4BHuQUZ7

https://goo.gl/photos/XHbdWqpB1oziZXnSA


In case we agreed, that the canopus-captures are correct as for the vertical information of every field and a deinterlacing using QTGMC would have the desired source to generate the best-possible result (...as interpolation can now integrate the correct spacial information from corresponding lines of the neighbouring [before/after] fields), one could probably regard the problem as solved...


...but: I bricked the Hi8 camcorder today

Tried to make it play a tape that must have gotten kinda sticky over the years. The camera stopped playback several times and I had to take the tape out and manually forward it a little bit, until it eventually refused to load the tape again (towards its end)... and I wouldn't let go, trying it several times in frustration. Lucky enough, I was able to capture most of that precious tape (using the canopus) in pretty good- to excellent quality. But after this 'act of brutality', the camcorder now has a huge tracking problem - I tried a tape that normally played-back fine, and it had big hissing bars in the Image and no audio at all. Even worse: the tape gets physically damaged at one of the edges by the playback process... Dammit!
Silly as I was, not all the tapes where canopus-captured before, so for some of them I'm somewhat back where I started... just without a proper playback unit...

Again, all of this is in the end due to my perfectionism (but then- I quess that is what it's all about for a lot of people in this forum ), also the "incorrect" frames with one field shifted give decent results after QTGMC, it just bothers me, that it would probably be even better if the fileds position was correct. So I wonder: what are my options with the material that I have already digitized?

First thought was, that there must be an avisynth way to separate fields and shift the contents of every second field downwards one line and then weave again, leaving me with a quasi-correct file missing one line - which is probably in the letterboxed overscan anyway... But as far as I understood this is not possible while staying in YV12, is it? Would I have to Upsample to 4:2:2 and afterwards back to YV12 (destination format is MPEG4)? So degrade qualiy by two colorspace conversions? Or could it be done losless by duplicating and discarding lines? I still have my troubles grasping these things in the details ...

So I would appreciate your suggestions! Thanks for reading another loong post...!

[smok3]

The camera stopped playback several times and I had to take the tape out and manually forward it a little bit, until it eventually refused to load the tape again

I was told that the old tapes should be forwarded and rewind-ed before actual playback (Yes, the whole tape).

[Jordan]

yea- I know. I tried, but that wasn't possible either. Doing it manually (some passages- not the whole tape) was no big deal though... it moved quite normal most of the time. but at some point it seemed like the backside of the tape wouldn't want to slide "around the corner" ... around the plastic edge of the cassette itsself. It went off the spool with no problem (so no sticking layers on the spool or sth)

[ChiDragon]

For what it's worth, I did stumble across a post that seems to mention the same or similar issue with converting using a Digital8 camcorder.

I still don't think I can fully decipher your post #21, but I agree with you that the capture where the camcorder's OSD is NOT in the same spatial position in each field is correct (i.e. the one that "jumps up and down" is correct).

In the second part of demo.avi, that "new (mostly) black line on the bottom" that you noticed is one clue that the video is captured incorrectly according to the DV specs.

PAL DV:

System 625-50

Field 1: line 23 to line 310
Field 2: line 335 to line 622

The active 576-line area of 625-line analog video begins with the half-line 23 and ends with the half-line 623. (I believe the reason it looks like less than half is that this "half" measurement includes all of the horizontal blanking that precedes it.) Your field 2 ends in the half-line, so it's 336-623. But it's being stored in the location of 335-622. Meaning, this field has been spatially shifted one line up with respect to the other field.

Because all fields in your capture contain blackness in the top line anyway, to correct the error you'd be better off shifting up field 1 to match rather than shifting down field 2. Not that losing that little half-line would be a huge loss anyway...

You'll have to convert to 4:2:2, but I defy you to be able to pick out any degradation when the source of your color is Hi8 with a chroma resolution of about 30 TV Lines.

[Jordan]

I stumbled over that post as well, but as far as I understood that guy is talking about "shifting" fields in the temporal axis- pretty much what I was speculating about in my 'cryptical post 21'
-dropping the first top-field to make that frames bottom field the new bottom field of the then first BFF-frame.

Thanks for approving which of the scenarios is the correct one. I'll admit though, you lost me when it came to the half-lines. Today, I won't have have the time to really read through the documents you've linked, but I will.

In the end it seems to be pretty irrelevant if one line gets lost- I'd probably rather shift down field 2, because the overall spacial position of the image is restored to where it is in the parts that are not broken- sometimes the change happens although there was no cut in the footage, so no visible problem that could have triggerd it.

Another thought on upsampling: as the chroma Information is far less accurate than the luma, and in the end covering rather an area of the the image, than matching the actual luma pixels- would shifting the luma plane alone, and leaving the chroma in place to avoid up-and downsampling be an option? can it be done at all? Or would that be completely silly?!

Could you give me a hint on how to design a script that allows me to edit the fields independently? Probably it comes down to SeparateFields() and then edit every second frame? I tried to do some research here, but did not really find a satisfying solution here... My avisynth knowledge is rather 'problem-oriented' ... and I guess I'm missing the big bicture here, to see the most obvious way to do it. All I came up with was sth like separate the fields , generate two paths, selecting even and odd frames, giving one of them the processing and in the end interleave and finally weave them But I totally would not be able to raealize that within a single script ...
So any help would be appreciated!

[ChiDragon]

Half-lines at top and bottom of frame as seen on a TFF DVD:

Originally Posted by Jordan

Another thought on upsampling: as the chroma Information is far less accurate than the luma, and in the end covering rather an area of the the image, than matching the actual luma pixels- would shifting the luma plane alone, and leaving the chroma in place to avoid up-and downsampling be an option?

Then your chroma won't be positioned with the correct fields.

You've got the gist of how to write such a script, but the only advantage of manually writing it is that you could keep one of the fields in YV12 directly while the other is converted and shifted. But there is no visible benefit to that. Just download ReverseFieldDominance, IMO.