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!!—

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]

Originally Posted by Jordan

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]

Originally Posted by Jordan

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.

Originally Posted by Jordan

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.

Originally Posted by Jordan

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.

Originally Posted by Jordan

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.

Originally Posted by Jordan

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.

Originally Posted by Jordan

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.

Originally Posted by Jordan

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.

Originally Posted by Jordan

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

Yes.

Originally Posted by Jordan

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.

Originally Posted by Jordan

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.

Originally Posted by Jordan

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).

Originally Posted by Jordan

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]

Originally Posted by Jordan

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).

Originally Posted by Jordan

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]

Originally Posted by Jordan

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).

Originally Posted by Jordan

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]

Originally Posted by Jordan

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().

Originally Posted by Jordan

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]

Originally Posted by Jordan

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]

Originally Posted by 2Bdecided

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