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

[Jordan]

Hi everybody!

After gathering interesting and helpful information from this forum literally for years now, I came to a point where I have to ask you guys a couple of questions and thus write my first post. I acquired fairly decent skills in DVD conversion back in my old DVD-> AVI and later DVD->DVDr days ;-), but time has gone by and I did not too much follow the developments, so when I faced my current task, the conversion of old HI8 Videotapes there was a l o t of reading to do. Which I did! I put together a workflow with the aim of giving me the best possible results when transferring those old family memories into the digital world. At several steps of this workflow there arise problems or at least somehow unresolved issues/ questions on which I would like to have your advice!

I’ll lay out the workflow step by step, assigning numbers to the issues, so it will be easy to comment on them.

The 20 to 10 year old HI8 tapes are played back in the original camcorder that was used for the recording back in the days (Blaupunkt brand). Signal is passed via S-Video into Panasonic NV-GS 400 DV Camcorder and captured in realtime to the PC (Win7pro 64 bit i7quadcore 2,8 ghz HT enabled, 8gb ram) via firewire by means of Adobe Premiere pro 2.0, resulting in interlaced DV-avi files.

Q1: Color information is always stored in YV12 in these files? I ask, because sometimes I read it would be YUY2…
Assuming this, I figured it would be useful to completely stay in YV12, as target compression MPEG2/MPEG4 uses this colorformat as well.

Therefore I use cedocida and unchecked every output option but YV12. Then there is YV12 Chroma sampling…

Q2: Which is the correct Chroma sampling to be checked? Not going back to DV, so not the first one. Target compression should be MPEG4 rather than MPEG2 – a problem? Non interlaced or interlaced? At this step we are still before interlacing, so I guess “MPEG2 interlaced” is the one to go for? (read every of these options as the one to choose in other threads…)

Choosing these options the video is imported into avisynth via AviSource() , given a chromashift-correction, to be then deinterlaced with QTGMC.

--At this point I just HAVE to say: THANK YOU Vit, Didée and Co. for this AMAZING script!! I actually imported those tapes back in 2007/8 and postponed further editing because deinterlacing drove me mad and never gave results I could live with. When this time, after a night of reading, I saw the first frames of my footage properly deinterlaced, I could barely believe my eyes! Thank you, once again!!—:thanks:

As recommended, I used the HT enabled version of avisynth (by SEt) and put together a script like this (following the Multithread advises from QTGMC documentary):

SetMTMode(3, 8)
AviSource("D:\Reorganize\ORGANIZED\Homevideo\Familienfilme\(2) 8-93 bis 4-94 - Teil 1.avi")
Chromashift(C=-6)
SetMTMode(2)
QTGMC( Preset="Slow", EdiThreads=4 )
#Distributor() # This line may or may not be necessary, try removing it and see if you get more speed
crop(0,0,0,-8)
AddBorders(0,0,0,8)
trim(11795,74050)

This opened fine in VirtualDub 1.10.4. When trying to save a test-sequence I spent two days struggeling with what I call

ISSUE 3: The rendered video (uncompressed or Lagarith Lossless in YV12 mode) showed completely scrambled frames every 100-200 frames or so, sometimes accompanied by a hiss in the audio. They looked like the attached image "scrambled.jpg"

The confusing thing was, not only could none of these scrambled frames ever be seen when seeking frame-by-frame through the stream in VDub but they would magically appear at a completely different place when rendering the exact same sequence once again, leaving all the parameters untouched…

When I accidentally had a render done in direct stream copy video mode (which results in an an audio-only clip) I was able to see these scrambled frames appear on the input pane of VDub while performing the rendering. This got me thinking it might have to do something with audio demuxing and sync-keeping… so I disabled audio in the AviSource command with audio=”false”. Et voilà: no more scrambled frames. Directshowsource() did not have this problem either, but I did not want to use it because I liked the idea of staying in YV12 from the very beginning, plus I kept on reading everywhere that Avisource would be preferable due to controllability and stability issues…

While searching for a reason for the weird frame-error, I found out, that all of my DV avis had slightly off framerates: instead of 25fps they had either one of the following two values:

25.000375 or 25.000437 fps

I could not think of any scenario that could explain this finding. Adding the AssumeFPS(25) command did not solve the scrambled-frame-issue.

I ended up doing a re-mux with the audio from the original source-file at the end of the script- no bad frames here. Weird thing! The AssumeFPS(25) still active, I found the Audio running slightly (ca 2 frames) out of sync near the end of the video (one could probably live with that, but it is still annoying and bothers my perfection-seeking mind…)
The final script looks like that (I’ll admit: I tried to avoid digging too deep in Avisynth and the whole routing something back to itself thing… I extrapolated this script from what I found In threads with a similar muxing task… might be a little dirty but it does what it is supposed to do…)

SetMTMode(3, 8)
Video = AviSource("D:\Reorganize\ORGANIZED\Homevideo\Familienfilme\(2) 8-93 bis 4-94 - Teil 1.avi", audio=false)
Video= Video.Chromashift(C=-6)
Video = Video.AssumeFPS(25)
SetMTMode(2)
Video = Video.QTGMC( Preset="Slow", EdiThreads=4 )
#Distributor() # This line may or may not be necessary, try removing it and see if you get more speed
Video = Video.Letterbox(0,10)
Audio = DirectShowSource("D:\Reorganize\ORGANIZED\Homevideo\Familienfilme\(2) 8-93 bis 4-94 - Teil 1.avi", video=false)
AudioDub(Video, Audio)


Okay- ignoring the audio-sync issue, this leaves me with a working script. But one thing remains that drives me mad:

ISSUE 4: The Luma Range!

I know this has been discussed over and over again and I have read a t o n about it throughout all the major videoboards and more, but it always seems to be kinda not really my point and I would be VERY grateful if some of the gurus could clarify this issue for my specific case.

I eventually managed to find a logical pathway for what is happening with my signals, but at some points it’s just based on assumptions, because I was not able to find a valid statement about this or that , which left absolutely no room for interpretation- at least from my standpoint as being new to the concept.

First of all, please set me straight here:

Can the “Full Range 0-255” be seen as – in the world of analogue TV technique – some kind of grid that is also “there” for an analogue TV set, here defined by the two extremes that are technically/physically possible, involving voltage, analogue image creation, cathode ray tubes and stuff. On this “technically possible” range, some committee found that the value of 16 was just as black as 0 but not damaging the screen and the same for white and 235. So these values where marked as the “TV Range”, while the “Full Range” was kinda present all the time…

If so, how do analogue recording devices like my old HI8 camcorder treat this issue? Is what they consider “black” stored as a value “0” on a scale that ends abruptly at “235” or are they calibrated, so their sensors output a “black” roundabout at the value of 16 on the always -in principle- present grid going from 0 to 255?

The latter seems logic to me, as I read about the phenomenon of “overshoot” and “headroom”.
In the Avisynth documentary (http://avisynth.nl/index.php/Luminance_levels) it is says:
“But in some cases your video will be stored as 0-255 YCbCr (DV is an example of this) , and no expansion is needed.”
What does this mean for the blacks and whites in the pictures? To me it sounds like “black is 0 and white is 255, and the image looks the way it is supposed to look”

Well- I played around with the histogram() command and the results are different from that! Maybe something goes wrong when digitizing the s-video signal but I get a picture like the attatchment histogram1.jpg.

Almost no signal under 16. On the other hand, there is quite some overshoot in scenes like the attatchment overshoot.jpg.

Out of curiosity I reviewed some real DV-footage (shot with the nvgs400) and this is even more irritating- what should be black seems to be located at about 32 (see DV-histogram.jpg)

I’m not sure whether this is related to the findings on the HI8 footage, but I’d be glad if someone had an explanation for that, too!

As for the range of the HI8: when scaling the range in the sense of 16->0 and 235 ->255 it seems to be oversaturated, and darker scenes tend to be muddy. So I’d rather stick to the normal look the image has when the values that can be extracted from the YV12 avi will be interpreted as being in PC range and not converted to it in the sense of 16->0, 235->255. This is in fact something I don’t quite understand- which of the following (and other…) commands does something, and what does it do to the YV12 source?

ConverttoRGB(matrix="PC.601") -- hypothetically, would this command leave the levels as they are, assuming they are in PC scale? Or is the range expanded? Would …rec.601 scale things around?

ConverttoYUY2() -- does it leave it the levels alone?

(Q5: Conversion)

The latter is important because for MPEG2 conversion I’d like to use CCE, which apparently (unlike contradicting information that from version 2.67.00.10 and higher it would natively support YV12) seems to only accept YUY2…

Is the conversion YV12 –[ConverttoYUY2()]-> YUY2 -> [YV12 (within CCE)] lossy or not? Are there just some lines being duplicated and then discarded again or does this (basically unnecessary) step worsen the image quality?

In the ‘video/mpeg video setting’ dialog, CCE offers the Luminance Levels selection 16-235 or 0-255, and we’re talking about the output here, right? What does it do to the YUY2 input (assuming this still has the original range)? Does it go “okay, YUY2 is YUV i.e. 16-235 (“normally”), let’s just leave the range as it is when 16-235 is selected and stretch it when 0-255 is selected”? Or will it leave things untouched in 0-255 mode and compress when 16-235 is selected? I know there is a bunch of formulas in the CCE manual on that, but I simply don’t get’em…

And finally:

When feeding this avs script (or one just containing Avisource(“an-intermediate-lagarith-YV12-file.avi”) ) into MeGui, will really no color conversion take place when encoding with x.264? I’m asking, because Staxrip prompted me to install a “YV12 Decoder” which I purposely avoided to have installed (xvid, ffdshow),to realize when other modules than avisynth try to interfere in the process…

Well - I guess that’s about it :-) …

I’m sorry, this became such an enormous post.. thank you for reading it, and again thanks for all the awesome stuff you guys developed!!

Cheers!

[ChiDragon]

Q1: Color information is always stored in YV12 in these files? I ask, because sometimes I read it would be YUY2…

PAL DV is always YV12.

Therefore I use cedocida and unchecked every output option but YV12.

Sounds good.

Q2: Which is the correct Chroma sampling to be checked? [...] At this step we are still before interlacing, so I guess “MPEG2 interlaced” is the one to go for?)

Yes I agree.

ISSUE 3: The rendered video (uncompressed or Lagarith Lossless in YV12 mode) showed completely scrambled frames every 100-200 frames or so, sometimes accompanied by a hiss in the audio.

I guess the most obvious place to start troubleshooting random errors with a multithreaded script is to fall back to regular single-threaded Avisynth.

When I accidentally had a render done in direct stream copy video mode (which results in an an audio-only clip)

Unless something changed with VirtualDub, Direct Stream Copy mode shouldn't cause you to lose video.

instead of 25fps they had either one of the following two values: 25.000375 or 25.000437 fps

[...] I ended up doing a re-mux with the audio from the original source-file at the end of the script- no bad frames here. Weird thing! The AssumeFPS(25) still active, I found the Audio running slightly (ca 2 frames) out of sync near the end of the video (one could probably live with that, but it is still annoying and bothers my perfection-seeking mind…)

If I calculated properly, +1 frame desync every 38 mins for the worst of those two values you gave sounds correct.

Can you paste a MediaInfo log of one of these files that's giving you bad frame rates?

ISSUE 4: The Luma Range!

[...] On this “technically possible” range, some committee found that the value of 16 was just as black as 0 but not damaging the screen and the same for white and 235. So these values where marked as the “TV Range”, while the “Full Range” was kinda present all the time…

I don't understand the scenario you are presenting here but it doesn't seem accurate.

Ignore what you "should" be receiving from the camera, because you just aren't. Use ColorYUV's off_y and gain_y options to move and scale your luma such that black hovers around 16 and white peaks around 235.

ConverttoRGB(matrix="PC.601") -- hypothetically, would this command leave the levels as they are, assuming they are in PC scale? Or is the range expanded? Would …rec.601 scale things around?

PC.601 doesn't scale (regardless of whether the values actually "are in PC scale" -- it has no way of knowing and that is why you must specify). Rec.601 does.

ConverttoYUY2() -- does it leave it the levels alone?

When the source is YUV (including YV12), yes. When the source is RGB you have the matrix parameters as above.

(Q5: Conversion)

Is the conversion YV12 –[ConverttoYUY2()]-> YUY2 -> [YV12 (within CCE)] lossy or not?

Lossy.

[Ghitulescu]

Issue #3 - how did you find out?

The fps is 25Hz with quite a good precision.
However, the audio is unlocked, that means it can be ahead or after, even oscillating, for a max. 1/3 of a frame.
Maybe this is the reason why you have this fps, probably the software used to find it out uses also the audio for determining the duration, then fps=duration/frames.

[Jordan]

Hey!
Thank you for your answers!

I guess the most obvious place to start troubleshooting random errors with a multithreaded script is to fall back to regular single-threaded Avisynth.

I'm afraid you're right :/. I was actually going to try that in the first place, but just ripping all the MT -commands out of the script caused virtualdub to crash with the SEt 2.6 HT avisynth.dll in the sysWOW64 directory. I don't remember why I did not change it back to original 2.58, but in fact I did not... So I did not find out until today that doing so does indeed "solve" that problem! No bad frames here with a simple script like that:

AviSource("D:\Reorganize\ORGANIZED\Homevideo\Familienfilme\(2) 8-93 bis 4-94 - Teil 1.avi")

QTGMC( Preset="Slow")

But of course with a significant decrease of speed. I played around with the values X,Y and M in the MT-Commands (see QTGMC Thread http://forum.doom9.org/showthread.php?t=156028), but this had no effect on the scrambled frames.

As the audio=false command in Avisource() helped to get rid of these frames, I guess my final 'workaround-remux-script' is a reasonable solution- alternatively I might just go for separate scripts for audio and video encoding or demux the audio via direct stream copy for further editing, what do you think?

Speaking of
Unless something changed with VirtualDub, Direct Stream Copy mode shouldn't cause you to lose video.

- you're right! I just tried it again and it did generate uncompressed video. That is strange, because I am sure it did not last time (happened several times) - which led my to believe, the use of a filter like QTGMC somehow wasn't compatible to 'direct stream copy'. I could not reproduce it now, though.

Ignore what you "should" be receiving from the camera, because you just aren't. Use ColorYUV's off_y and gain_y options to move and scale your luma such that black hovers around 16 and white peaks around 235.

Yes- I'll try that and see if I like it better- the given range interpreted as PC seems quite acceptable in the end, though.

Here is the MediaInfo Log of the original file I've been working on:

General
CompleteName : D:\Reorganize\ORGANIZED\Homevideo\Familienfilme\(2) 8-93 bis 4-94 - Teil 1.avi
Format : AVI
Format/Info : Audio Video Interleave
Format_Commercial_IfAny : DVCPRO
Format_Profile : OpenDML
FileSize/String : 19.7 GiB
Duration/String : 1h 33mn
OverallBitRate_Mode/String : CBR
OverallBitRate/String : 30.3 Mbps
Recorded_Date : 2010-01-18 00:24:35.000

Video
ID/String : 0
Format : DV
Format_Commercial_IfAny : DVCPRO
CodecID : dvsd
CodecID/Hint : Sony
Duration/String : 1h 33mn
BitRate_Mode/String : CBR
BitRate/String : 24.4 Mbps
BitRate_Encoded/String : 28.8 Mbps
Width/String : 720 pixel3
Height/String : 576 pixel3
DisplayAspectRatio/String : 4:3
FrameRate_Mode/String : CFR
FrameRate/String : 25.000 fps3
Standard : PAL
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bit3
ScanType/String : Interlaced
ScanOrder/String : BFF
Compression_Mode/String : Lossy
Bits-(Pixel*Frame) : 2.357
StreamSize/String : 18.7 GiB (95%)

Audio
ID/String : 1
Format : PCM
Format_Settings_Endianness : Little
Format_Settings_Sign : Signed
CodecID : 1
Duration/String : 1h 33mn
BitRate_Mode/String : CBR
BitRate/String : 1536 Kbps
Channel(s)/String : 2 channel2
SamplingRate/String : 48.0 KHz
BitDepth/String : 16 bit3
StreamSize/String : 1023 MiB (5%)
Alignment/String : Alignment_Aligned
Interleave_Duration/String : 80 ms (2.00 video frames2)

Issue #3 - how did you find out?

The only software to specify the framerate that accurate was VLC. VirtualDub for instance would round to 25.000 for the original file, or 50.001 after framerate was doubled because of QTGMC deinterlacing.

For a deinterlaced testfile MediaInfo would not round, but give

FrameRate/String : 50.000 fps3


Thanks for the input so far, and hopefully someone has some ideas concerning the remaining encoder-related questions, too.

[TheSkiller]

ISSUE 3: The rendered video (uncompressed or Lagarith Lossless in YV12 mode) showed completely scrambled frames every 100-200 frames or so, sometimes accompanied by a hiss in the audio. They looked like the attached image "scrambled.jpg"[/url]
I sometimes have this issue too, using QTGMC in MT mode (SEt's MT) and it drove me nuts. The only solution I found is running the whole script single threaded. It's odd because I can run very complex scripts (such as TemporalDegrain) in MT mode 2 without problems but with QTGMC I get scrambled frames exactly like yours every now and then.


While searching for a reason for the weird frame-error, I found out, that all of my DV avis had slightly off framerates: instead of 25fps they had either one of the following two values:

25.000375 or 25.000437 fps
I have had very slight deviations in total audio length compared to total video length capturing VHS via a DV Camcorder (causing a sync-offset of exactly the same length). It seems this happens to you as well but your capture software tries to compensate this by adjusting the frame rate which leads to these off standard frame rates. It should ensure video and audio stay in sync. However, I would highly recommend trying Scenalyzer Live for capturing and ticking the "Keep audio in sync" option. This way I never had only the slightest sync error or framerate oddities (exactly 25 fps).
I was using WinDV before which is great for capturing MiniDV but with analog passthrough I had the mentioned problem.



Can the “Full Range 0-255” be seen as – in the world of analogue TV technique – some kind of grid that is also “there” for an analogue TV set, here defined by the two extremes that are technically/physically possible, involving voltage, analogue image creation, cathode ray tubes and stuff. On this “technically possible” range, some committee found that the value of 16 was just as black as 0 but not damaging the screen and the same for white and 235.
Not exactly but close. A CRT TV with properly adjusted brightness setting will display a range of 0 IRE to approx. 110 IRE. In digital video terms this equals the range of 16-255. What about 0-16? Well, if you turn up the brightness on purpose those can be seen as well, but it's wrong because there should be nothing to see and everything is tuned to have black at 16.
Anything a good chunk below 16 could theoretically be interpreted as a sync pulse, hence you will very rarely have signal below 16, unlike whites where it's quite different and very common to have signal above 235.
Especially with consumer footage of any kind (even with modern cameras) there are super whites (>235/>100 IRE) which you don't want to miss. Since there's no hard limit preventing the CRT from displaying these, they display as if they were in legal range. You don't even notice.


If so, how do analogue recording devices like my old HI8 camcorder treat this issue?
The CCD sensor will capture and keep values as bright as 255 and the rest of the camera records them in analogue to tape. Exactly this will be played back as well. So basically the camcorder doesn't bother at all.


or are they calibrated, so their sensors output a “black” roundabout at the value of 16 on the always -in principle- present grid going from 0 to 255?
Yes.


What does this mean for the blacks and whites in the pictures? To me it sounds like “black is 0 and white is 255, and the image looks the way it is supposed to look”No, your black is at 16 (or very close), and your white is at 255. This is the range you would want to see on a computer display scaled to the computer's 0-255 (see below).

This is normal and to be expected from a recording made with home equipment.



Out of curiosity I reviewed some real DV-footage (shot with the nvgs400) and this is even more irritating- what should be black seems to be located at about 32 (see DV-histogram.jpg)In this case black is not black because either the maximum dynamic range the CCD can capture was exceeded or the electronics made it brighter so that no detail in those dark shadings gets lost (look very closely, there's detail, it's not just a flat grey area).




ConverttoRGB(matrix="PC.601")
This keeps the entire range of 0-255 in YV12 and converts it to 0-255 RGB. Like you've learned now, this will leave the original blacks at 16 which will look washed out on a computer screen where black should be at 0. Super whites are kept. So you would want to have it followed by

Levels(16,1,255, 0,255, false)

to make things look correct on a computer display.


ConverttoRGB(matrix="Rec601")
Takes the legal range from your YV12 source (16-235) and outputs it as 0-255 RGB. In your case, since there are super whites, this is undesireable because they get lost. For video with standard levels this is exactly what you want to use.


ConverttoYUY2() -- does it leave it the levels alone?Yes.


The latter is important because for MPEG2 conversion I’d like to use CCE, which apparently (unlike contradicting information that from version 2.67.00.10 and higher it would natively support YV12) seems to only accept YUY2…Correct, you need YUY2. CCE never natively accepted YV12. I you feed YV12 anyways it will be converted by whatever codec on your system happens to be responsible for this. You definitely don't want this because you never know what's happening.




Is the conversion YV12 –[ConverttoYUY2()]-> YUY2 -> [YV12 (within CCE)] lossy or not? Are there just some lines being duplicated and then discarded again or does this (basically unnecessary) step worsen the image quality?It's lossy. I'm facing this issue all the time (YV12 video that I need to encode in CCE), but there's an easy and well tested solution by me.

Add this to the end of your script and make sure to encode interlaced in CCE (no automatic detection).

ConverttoYUY2(chromaresample="point", interlaced=true)
MergeChroma(PointResize(width, height, 0, 2))


This will simply duplicate chroma lines to make up for YUY2. CCE does not know this and scales it down to YV12 again using a regular resizer in interlaced mode. As a result there will be no chroma smear, it's lossless. It's basically as if CCE supported YV12 natively. If you use a regular resizer for the YV12->YUY2 conversion, say ConvertToYUY2(interlaced=true), there would be some chroma smear, albeit I'm pretty sure it's really hard to see with Hi8 footage because the chroma bandwidth of Hi8 is much lower than it's pretty good luma bandwidth.

It's very important to have CCE's interlace option set to interlaced, not "auto-detect", because this setting affects which chroma resize is performed – interlaced or progressive.



In the ‘video/mpeg video setting’ dialog, CCE offers the Luminance Levels selection 16-235 or 0-255, and we’re talking about the output here, right?
It's the input range (output is always ought to be 16-235), but don't worry about it. Always leave it at 16-235 and the input range will be kept as is and nothing will be discarded (0-255).




When feeding this avs script (or one just containing Avisource(“an-intermediate-lagarith-YV12-file.avi”) ) into MeGui, will really no color conversion take place when encoding with x.264? Unfortunately I cannot help you with this because I never used MEGui...

[Jordan]

Thank you for this informative reply!

It seems this happens to you as well but your capture software tries to compensate this by adjusting the frame rate which leads to these off standard frame rates.

Interesting thought! I did all my capturing with either Premiere pro 1.5 or Premiere pro 2.0- you'd think a product like that can handle that rather simple task (if it's really just writing the digital data via firewire to disk...), so I'd never occured to me this oddity might be caused by the capturing software. I did not have a lot of time to experiment these days, but I'll give Scenalizer a try.

What is strange though is, that every single of a total of about ten DV-avi files (being of different lenghts) has either one or the other of the two mentioned framerates.

It's lossy. I'm facing this issue all the time (YV12 video that I need to encode in CCE), but there's an easy and well tested solution by me.

Add this to the end of your script and make sure to encode interlaced in CCE (no automatic detection).

Code:

ConverttoYUY2(chromaresample="point", interlaced=true)
MergeChroma(PointResize(width, height, 0, 2))

This will simply duplicate chroma lines to make up for YUY2. CCE does not know this and scales it down to YV12 again using a regular resizer in interlaced mode. As a result there will be no chroma smear, it's lossless. It's basically as if CCE supported YV12 natively. If you use a regular resizer for the YV12->YUY2 conversion, say ConvertToYUY2(interlaced=true), there would be some chroma smear, albeit I'm pretty sure it's really hard to see with Hi8 footage because the chroma bandwidth of Hi8 is much lower than it's pretty good luma bandwidth.

It's very important to have CCE's interlace option set to interlaced, not "auto-detect", because this setting affects which chroma resize is performed – interlaced or progressive.

That was exactly the info I was looking for! I knew, I read something like that before, but I was not able to find it again.
Although I must admit, that I do not entirely understand how the 'interlaced' option deliveres the desired result, and- don't I end up with an MPEG2 stream flagged as 'interlaced' although it is actuelly progressive?

Always leave it at 16-235 and the input range will be kept as is and nothing will be discarded (0-255).

Uhm- sorry I don't get it... why?

[TheSkiller]

Although I must admit, that I do not entirely understand how the 'interlaced' option deliveres the desired result, and- don't I end up with an MPEG2 stream flagged as 'interlaced' although it is actuelly progressive?
Isn't your video you intend to encode in MPEG2 interlaced? I was assuming it because camcorder footage almost certainly always is interlaced unless you shot it on purpose in 25p mode at the time (if the camcorder has such option).

In CCE you have three interlacing options:
- auto detect [with some threshold to enter]
- interlaced
- progressive

This setting does two things. First, it determines whether or not a flag inside every GOP of an MPEG stream is set or not (it's the "Frametype progressive" flag). And second, more importantly, it also determines which of these will be used inside CCE to downsample our "fake" YUY2 to YV12 again:


ConvertToYV12(interlaced=false)
ConvertToYV12(interlaced=true)
(Of course CCE doesn't use AviSynth, but this is what happens internally.)

Now the thing is, with interlaced video and our fake YUY2 you cannot use ConvertToYV12(interlaced=false) to undo and restore it to YV12 losslessly. The auto detect settings would try to do this with GOPs where there is no interlacing (movement), a static shot on a tripod for example. It would result in broken chroma.

Progressive setting of course is completely wrong with interlaced video, it would produce badly broken chroma everywhere.

That's why it really should be set to interlaced (auto detect is the default I think).



Uhm- sorry I don't get it... why?This setting actually has only one purpose. It's meant to be used in the very rare case of full range YUY2 video, where black really is at 0 and white at 255. Based on this setting CCE will then take action and compress the range to 16-235 so that the output is in legal range.

If you leave this setting on 16-235 CCE assumes the input range is already 16-235, so nothing needs to be done. CCE would encode the incoming range as is without changing it, even if it is not 16-235 but, like in your case, 16-255. CCE doesn't care or enforce legal range. That's up to you.

That being said, I would advice you to compress your super whites into legal range using AviSynth before encoding. It's no problem to encode MPEG2 with super whites but PC playback and many DVD-players will clip those, that's why it's preferrable to compress your range from 16-255 to 16-235.

[Jordan]

Isn't your video you intend to encode in MPEG2 interlaced?

Well the original DV-avi conatining the HI8 footage is indeed interlaced, but at the point where it is going to be encoded to MPEG2 or MPEG4 it has been passed through the QTGMC deinterlacing script and is thus 50fps progressive.

Would a chromaresample-tweak like that also be possible with progressive frames? Because that is what I think I read somewhere on the net- rather by chance and not realizing how useful this might be later on...

If you leave this setting on 16-235 CCE assumes the input range is already 16-235, so nothing needs to be done. CCE would encode the incoming range as is without changing it, even if it is not 16-235 but, like in your case, 16-255. CCE doesn't care or enforce legal range.

Ok, got it.

[ChiDragon]

Why would you ever want to encode 50p MPEG-2? Are you aware that you can't create a DVD like that?

[Jordan]

Ah sorry- I do want to keep the (smoother) 50 fps for the MPEG4 encoding- for a DVD I would add the SelectEven() command (as suggested in the QTGMC documentary)

[ChiDragon]

I think taking 50Hz material and creating a 25p DVD is goofy, but whatever floats your boat.

[TheSkiller]

but at the point where it is going to be encoded to MPEG2 or MPEG4 it has been passed through the QTGMC deinterlacing script and is thus 50fps progressive.Well, just re-interlace it then. For DVD that is, because you cannot store 50p on DVD. This will re-interlace 50p to 25i (also called 50i).


AssumeTFF()
SeparateFields().SelectEvery(4,0,3).Weave()
Edit: Maybe better use AssumeBFF(), because the original DV video was BFF to begin with. It may not make any difference but this way you would keep the original lines instead of the QTGMC interpolated ones (more or less).


Would a chromaresample-tweak like that also be possible with progressive frames?
Yes, this would be used for progressive video and progressive option in CCE selected:

ConverttoYUY2(chromaresample="point", interlaced=false)
MergeChroma(PointResize(width, height, 0, 1))

Note that not only interlaced has changed to =false but the chroma alignment correction in MergeChroma changed from 2 to 1 also.

However, keep in mind typical camcorder footage will look just wrong deinterlaced to 25p. You're better off re-interlacing it.

[Jordan]

Okay- honestly guys, you kinda lost me here!

Serious question, because if there is a good reason for it, I obviousely must have misunderstood the technical stuff in the background:

Why would I want to re-interlace?!
The whole aim of this was to -once and forever- get rid of it and generate flatscreen (PC, TV) -displayable footage without combing artifacts. This is why I let QTGMC chew on it for hours - to have it eventually come up with pleasing progressive footage in which this relict from analogue tv technique has been "removed" "as good as possible", and hopefully better than it ever could be removed by means of any realtime-filter implemented in a software-player or standalone dvd player (or probably rather the tv-sets attached to them) , as those - as far as I understood- just discard, blend or roughly interpolate stuff, because no other device than a CRT Monitor would actually benefit from the original idea behind interlacing: preserving vertical resolution while saving bandwith and still providing smooth motion. As far as I understood, any device that is not natively based on a line-based image creation will have to employ some kind of work-around.

The footage I am working on will most probably never be viewed on a CRT again, so deinterlacing foor good seemed reasonable to me. Besides - if I wanted to go for interlaced MPEG2 I could have just encoded the original avi- no need for hours of QTGMC calculations then...
or am I missing something here?

ConverttoYUY2(chromaresample="point", interlaced=false)
MergeChroma(PointResize(width, height, 0, 1))

cool- thanks, I'll try that.

[TheSkiller]

Besides - if I wanted to go for interlaced MPEG2 I could have just encoded the original avi- no need for hours of QTGMC calculations then...
or am I missing something here?
No, that's correct, but didn't you also – in addition to a DVD – wanted to make a 50p MPEG4? So QTGMC was no waste, although strictly for a DVD MPEG2 it was not necessary.


Well, just try it and put the video in 25p on your DVD. You will probably find it looks stuttery and feels tiring to watch such video in 25p... It'll look very different from native 25p sources which were filmed with special techniques and appropriate shutter speeds.

Think of it like this: you are throwing away half (yes, half) of the temporal information originally recorded by using SelectEven().

The whole aim of this was to -once and forever- get rid of it and generate flatscreen (PC, TV) -displayable footage without combing artifacts.You may very well do just that, but not with DVD compatible MPEG2, but with your 50p MPEG4 encode.


See, DVD is meant to store video in a digital form which is compatible with it's original analogue counterpart. Hence it is only capable of what traditional SD TV is capable of.

[ChiDragon]

realtime-filter implemented in a software-player or standalone dvd player (or probably rather the tv-sets attached to them) , as those - as far as I understood- just discard, blend or roughly interpolate stuff

Ironically, your 25p solution would discard half of the original information. I've never heard of a standalone DVD player or TV that upscales by discarding or blending, though I suppose some Chinese junk must be on the market out there somewhere.

There are tons of players and TVs that do a poor job at interpolation, but they still create 50p video.

[Jordan]

Think of it like this: you are throwing away half (yes, half) of the temporal information originally recorded by using SelectEven().

Ok. I am aware of that - and it is true that this is undesirable, especially in shots with a lot of motion. The thing is, when I started digitizing the tapes a couple of years ago I actually encoded one of them to interlaced MPEG2 and burnt it to DVD without further processing (as mentioned above, basically beacause I did not find a satisfying deinterlacing solution). Although motion was nice and smooth, I was disappointed by the lack of detail in the image and the "reduced vertical information"-look, which is why I dropped the project back then...
I must admit though, most of the comparisons where done on my PC screen with softwareplayers like powerDVD or VLC rather than on the standalone TV/DVD-player...

I don't want to fire up an emotional discussion about whether interlacing is "good" or "bad"
...although I obviousely am not its biggest fan ;)...

I just want the stuff to "look good" - be it on the PC screen or the TV, and if keeping the frames in their original interlaced state is the way to go for the standalone combination TV+DVD this may be surprising (and somewhat frustrating) to me but still hold true if in the end the subjectiv viewing experience (when sitting a couple of meters away from the TV) would be more disturbed by stuttery motion than by the lack of detail/sharpness in the image when being compared to the QTGMC results...
Frankly, I did not think of that in the first place...

Anyway- in the end the MPEG4 version is more important to me, and as no DVD-standard restricions apply, the QTGMC 50fps version should be fine here.

Actually I only whish to create the DVD versions for the sake of completeness as I want to give them to my parents who probably feel more comfortable with the handling of a "classic DVD" - plus I'm not sure about the mediaplayer capabilities of their rather old standalone DVD player ;)

... So maybe I'll give an interlaced encoding another go, but first I'll try and check some x.264 encoded files on the standalone player... maybe in the end it's easier (and less time consuming...) to just buy them a new standalone player and forget about the whole DVD encoding...

[2Bdecided]

I doubt you'll be back to read this, but...

If the only reason you are deinterlacing is for progressive encoding (i.e. you're not doing any processing or restoration after deinterlacing) then any interlaced encoding should normally be done before deinterlacing. Deinterlacers are not perfect - they all add their own "look" to the footage. You will damage the footage slightly by deinterlacing and then re-interlacing. It's not a lossless process (QTGMC has a lossless option for this reason, but my advice would be: don't use the lossless option because it makes the 50p result worse).

You should certainly fix the luma range with like...
levels(0,1.0,255,2,235,coring=false)
...as superwhites are routinely clipped by PCs and many modern TVs. Don't use the matrix=PC.601 and/or matrix=Rec601 to try to deal with 16-255 video because that's not what it's designed for.

In most home movies, you will still have colours that are out of range, but it's harder to fix those.

Cheers,
David.

[Jordan]

Sure- I'm still here! But I'll admit, I did not focus too much on the project recently... too busy following the WorldCup ;)

Thanks for your post. In fact, an interlaced DVD version is no longer planned. My parents got themselfs a fancy new bluray player that plays back 50fps MPEG4 just fine :)

As for the levels- I considered leaving them as they are in the end, but I'll try the levels command.

[HaydenField000]

You should certainly fix the luma range with like...
levels(0,1.0,255,2,235,coring=false)
...as superwhites are routinely clipped by PCs and many modern TVs. Don't use the matrix=PC.601 and/or matrix=Rec601 to try to deal with 16-255 video because that's not what it's designed for.


Can you please point me towards more helpful documents/instructions on how to use levels? Thanks! :)

[Jordan]

Hey guys- it is me again!

When finally coming back to the project to finish processing the last tapes, I came to realize something very strange, that I need to ask your opinion on!

The first tapes were captured using adobe premiere, which (as mentioned in the original post) ended me up with slightly off framerates (25.000375 or 25.000437 fps), and I was told to try Scenalyzer Live. It did indeed give me exactly 25 fps.

Today I had to re-capture one of the original tapes and out of curiosity I captured the same scene three times to see If the images will look exactly the same or if there is any change to the appearance of grain/noise (as I read some people capture their tapes 10 times and overlay them as some sort of noise reduction because the actual image information does not move while some of the noise does in every instance and so in the end is less visible/clearly defined).

It turned out that the frames of the 25fps interlaced dv avi did not look the same, but the fields could appear in different constellations. Its hard to describe- I'll attatch an image! The three instances on the left were captured using scanalizer, the one on the right is the original adobe premiere capture. There seem to be those two ways the frame can look.

When beeing deinterlaced using qtgmc the new frames do only almost look the same- seems one of them is shifted one line. In the second image I layerd a stripe of the "identical "post-interlace" frame over the other. The arrows indicate where you can see the shift.

Big question: How can that be?!

Must be due to my setup: Hi8 Camcorder passed through MiniDV camcorder via s-video and captured realtime via firewire to pc.

I always thought the DV camcorder receives static 25fps with a exactly reproducable line-pattern (interlaced image), but apparently they both mess with fields in a way these different outputs can result- well... by cance?!

Other suggestions? Any way to influence this, to get the exaced same 25fps material over and over to try and pull off the overlay thing (as the noise does seem to move)?

Thanks :)

[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 (http://forum.videohelp.com/threads/362252-seeking-recommended-hi8-capture-guide-using-hardware-mentionned?p=2303959&viewfull=1#post2303959) 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 (http://lurkertech.com/lg/video-systems/#computer):
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 (http://www.dvmp.co.uk/digital-video.htm) 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:
http://s30.postimg.org/96injq6rl/T2_FS_PAL_halflines.jpg

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.