Panasonic DMR / Avermedia Extremecap / Virtualdub refuse to capture 576i UT

[slikvik]

Hi,

I have a Panasonic DMR-EZ49V which supports 576i out on HDMI. I've now just bought an Avermedia Extremecap UVC from a recommendation on here which, according to Avermedia, Amazon Q&A, and the user on here, will capture 576i uncompressed.

I just can't get Virtualdub, or anything else, to capture interlaced. Quite honestly I'm pretty depressed about this, I've spent weeks messing around, buying and returning all sorts of hardware. If anyone can help I would be super appreciative!

Here's my Panasonic running through the Extremecap streaming to VLC. As you can see it is set to 576i. VLC is also showing 720x576 YUY2 and 25fps. I've also tried all the below steps at 50fps.

[Attachment 65502 - Click to enlarge]

This is Capture pin in Virtualdub. Again, I've tried capturing at 25 and 50.

[Attachment 65503 - Click to enlarge]

Here are the UT settings. I've also ticked Assume interlace video.

[Attachment 65504 - Click to enlarge]

What is interesting is the video preview is completely garbled (like it's too high frequency) in Vdub until I start capturing. Nevertheless, I've attached a sample of a holiday video captured at 25fps and the same scene at 50fps.


[Attachment 65507 - Click to enlarge]

Neither of these look interlaced to me. It seems the 25fps is missing fields and the 50fps is showing all 50 fields, deinterlaced. Could someone smarter than me please:

A) Confirm what you see looking at these videos.
B) What you would expect to see from interlaced capture?
C) Tell me if I've done something wrong with my DMR settings, Extremecap or Virtualdub? Should I capture at 25 with the fields weaved by the source? In the current case that's missing frames as it's already been de-interlaced by the looks of it.

[jagabo]

I was able to view the video's using AviSynth and LWLibavVideoSource("holiday-50.avi"):


[Attachment 65508 - Click to enlarge]

Both videos have already been deinterlaced. 50p has lots of frame drops. A true interlaced video would have comb artifacts whenever there was movement. Since your combo unit is supposed to be deinterlacing by "filling in the missing lines" you can restore the original interlaced frames with:

AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()

or

AssumeTFF()
SeparateFields()
SelectEvery(4,1,2)
Weave()

But the missing frames (really fields) means some frames require one, some the other. If you can get caps with no dropped or inserted frames you'll be able to use whichever one works correctly.

[slikvik]

That's what I thought, and I noticed the frame drops on 50p (I'll deal with that later!)
So that means either the Panasonic is NOT outputting 576i despite being set, the Extremecap UVC is de-interlacing, or (unlikely) I'm not setting software correctly??

The 576i option on the Panny won't show unless the device handshake allows it so the Extremecap obviously is telling the Panny it will accept it (unlike those cheap ones I had in the other thread that stop me selecting 576i in the Panny settings.) Somewhere it's being deinterlaced and I'm not sure where!

I do have cheap splitter to remove HDCP...could that be de-interlacing???

One thing is that I can now recombine fields using the scripts you gave me the other day but I wonder if you could run the 50p sample through your Top/Bottom script and tell me if you think it's TFF or BFF. I know that sound silly but I'm not sure what I'm looking at. Bottom looks sharper but with more noise, Top looks more blurred with less noise.

[jagabo]

Note, I added some text the my earlier post.

[Skiller]

It is cruical to differentiate between frame or field drops on the analog side of things, inside the Panasonic, and dropped frames that got lost between the HDMI out of the Panasonic and your hard disk (or SSD). The latter are in any case unacceptable and the former should only happen when there are damaged or unrecorded parts of the tape being played, and are thus normal to a certain degree.

Cheap basic HDMI-splitters surely have no means of deinterlacing but potentially there may be issues that have the Panasonic fall back to 576p. One reason I can think of is, unfortunately 576i and 480i via HDMI are sort of a hack due to their bandwidth being below the minimum for HDMI, and therefore work not the same way as all other modes. The pixels are repeated internally to double the bandwidth for transmission and need to be halved by the receiving device. This requires correct communication between the two and in case of error, the fallback is a safe mode such as 576p.

I will have a close look at your files tonight.

[slikvik]

It is cruical to differentiate between frame or field drops on the analog side of things, inside the Panasonic, and dropped frames that got lost between the HDMI out of the Panasonic and your hard disk (or SSD). The latter are in any case unacceptable the the former should only happen when there are damaged or unrecorded parts of the tape being played, and are thus normal to a certain degree.

Cheap basic HDMI-splitters surely have no means of deinterlacing but potentially there may be issues that have the Panasonic fall back to 576p. One reason I can think of is, unfortunately 576i and 480i via HDMI are sort of a hack due to their bandwidth being below the minimum for HDMI, and therefore work not the same way as all other modes. The pixels are repeated internally to double the bandwidth for transmission and need to be halved by the receiving device. This requires correct communication between the two and in case of error, the fallback is a safe mode such as 576p.

I will have a close look at your files tonight.

This is very interesting and I was wondering if the Panasonic was falling back to 576p, but you would expect it to also change its Setting screen back to 576p. My suspicion is that the Avermedia Extremecap supports 576i INPUT (again, the Panasonic enabling the 576i option kinda confirms this, as it was greyed out on the cheap devices) but doesn't support it as an output. Possibly because these sort of devices follow the "UVC spec" which is a fairly modern Windows Camera API.... I can imagine MS wouldn't have even thought about interlaced for it!?

I'm just disappointed that the other use in this forum said it DID support this with his Panny DMR, and is now not responding to my messages to confirm my setup. Another £75 wasted.

Thanks for taking a look at the videos. Also, do you mind running the 50fps one through your script that shows Top and Bottom fields to determine if its TFF or BFF? I did it, but I'm still not sure which is the original and which is the doubled! "Bottom" looks sharper but with more noise, "Top" looks more blurred but with less noise.

[slikvik]

Interestingly, I've just installed the Avermedia software and it IS seeing the Panny as 50i, so it must be the capture device deinterlacing.

[Attachment 65543 - Click to enlarge]


...unless the Panasonic is TELLING the Avermedia is 50i but is still sending progress frames to it.

(I've emailed their support now but not expecting much)

[Skiller]

First thing I noticed is there is noise reduction (and as a result streaking in dark areas); you probably have the noise reduction of the Panasonic left turned on? I'd suggest you turn that off for now to minimize the Panasonic's impact on the video. The setting can be found by pressing DISPLAY on the remote (bottom row) and then go to the "Video" tab.

The 25 fps version appears to be the same as the 50 fps version, just with every other frame dropped. Indeed useless.
The 50p version looks just like the deinterlacing always does from the Panasonics. So in that regard it is fine.


Further examining the 50p version to determine which lines are original which are interpolated, using the script I posted in the other thread, I found that at the start of the video the bottom lines (of the even frames) are the original ones – until that hiccup at frame 132 where it is swapped and the top lines are then the original ones for the rest of the video.


That hiccup at frame 132 looks very much like it happened during HDMI capture because there is no tape dropout (such as a jumping picture or noise bars). This by itself is already ruining the capture.


Here's an example of what to look for when assessing whether the top or bottom lines are original.
The original lines are also always the ones which appear more detailed and sharper (and more noisy).
The top half line as well as the VHS head switch noise at the bottom also look notably blurred when looking at the interpolated lines.
Once you know where to look, it becomes quite obvious.


[Attachment 65547 - Click to enlarge]


[Attachment 65548 - Click to enlarge]



So what's the conclusion? Not sure. We need further testing. Do you have any means of connecting a TV to the HDMI-splitter? That may help narrowing things down.

[jagabo]

Here's an AviSynth script that will pick the proper field pairs:

src = LWLibavVideoSource("holiday-50.avi", cache=false, prefer_hw=2).AssumeTFF()

v1 = src.SeparateFields().SelectEvery(4,0,3).Weave().QTGMC(preset="fast")
v2 = src.SeparateFields().SelectEvery(4,1,2).Weave().QTGMC(preset="fast")
testclip = Subtract(v1.mt_edge(chroma="-128"), v2.mt_edge(chroma="-128"))

ConditionalFilter(testclip, v2, v1, "AverageLuma()", "LessThan", "126.0")

Basically, it uses mt_edge() to detect sharp edges within the two videos. Then whichever video has more sharp edges is picked. Subtract() returns an image that is flat gray at Y=126 when the two videos are identical. If v2 has more sharp edges than v1 the result of the subtraction will be less than 126.0.

A possible enhancement is to use a mt_edge matrix that specifically looks for horizontal edges (rather than the default):

[MODE]
mt_edge(mode="-10 -10 -10 20 20 20 -10 -10 -10", thy1=3, thy2=3, chroma="-128")
[/MODE]

A sample is attached. On the left is v1, the middle v2, and the right the sharper of the two frames. You can see that it properly switches from v2 to v1 at frame 130. Then back to v2 later in the video.

[Skiller]

Impressive, jagabo!
Your script turns this otherwise broken capture into a useable one.

There's still the frame drops which I hope can be cured with some optimization such as cutting the internet connection, stopping everything running in the background during capture and using a HDD to capture to that does not host the OS.


Edit: Although I don't quite understand why you first re-interlace and then deinterlace with QTGMC rather than just separating the fields, selecting every other twice (even/odd) and then compare the two?

[jagabo]

I don't quite understand why you first re-interlace and then deinterlace with QTGMC rather than just separating the fields, selecting every other twice (even/odd) and then compare the two?

I thought it would be easier to understand if I built the two possible progressive videos then selected between the two. I also thought working with progressive images might work a little better. But yes, one could work with fields, especially if one wanted interlaced video at the end (or just faster processing since two QTGMCs is pretty slow).

Keep in mind that there are four fields for each final frame so one has to decide whether to look at only one pair (and assume the other pair is the opposite) or analyzing four fields and deciding which pair is better.

[slikvik]

First of all, can I just say thank you both very much for your help.

I have some good news in that I've now recorded two 2 hour home videos with only a 2-3 dropouts each! They log as "inserted frames", not dropped frames in Vdub? It does end up inserting quite a few frames when it does happen though. "Solved it" by doing the usual of closing everything, recording to an SSD etc. So at least we know it was the capture device that was causing the drops. Ultimately I don't think that's too bad?

I also gave up trying to do 576i and just set the Panasonic to 576p.

The only noise reduction I have from the Display button on this model Panasonic is "Copy NR" which the manual states is for DVD recording. In fact, it doesn't even show up when playing a VHS. I've turned it off now anyway.

I also noticed that the Contrast on the capture settings was set lower than the default hence my sample being dark!

Anyway, I attached another capture of the same scene for you to see. Looks better and doesn't drop from what I can see


So.... back to recombining fields so I can store an untouched interlaced copy for post processing. I was going to ask if I need to recapture those two hour videos to get rid of the couple of drops - which might be impossible - but it seems jagabo's script might help avoid that by handling the field order changes. Thoughts? I don't mind a couple of drops in a two hour recording but I do care that I get a good interlaced copy.

What do I need to do to that script to get it to produce my interlaced masters?


As an aside I'm really confused by the TFF/BFF changing (and field order in general ) If a frame includes a field order and an interpolated line (created by the VCR) then how could dropped frame(s) by the capture device cause the order to change and by extension, the interpolated line being either TFF or BFF? If I cut out sections of good capture, that wouldn't cause field order to change?

[Skiller]

Keep in mind that there are four fields for each final frame so one has to decide whether to look at only one pair (and assume the other pair is the opposite) or analyzing four fields and deciding which pair is better.

To have proper interlaced video with correct field offsets, two (original) top or bottom fields should never be in a row, no matter what, therefore I suggest to always take the opposite field of the next frame without even checking. Worst case we would have a single interpolated field mixed in when there is a change in cadence (frame drop/insert). However, in lack of frame drops, this should not happen anywhere in the capture and should always be the right choice. Unless I'm missing something.

I have some good news in that I've now recorded two 2 hour home videos with only a 2-3 dropouts each! They log as "inserted frames", not dropped frames in Vdub?

That's good, we will try to extract the original interlaced video from that. No need to recapture. And yes, when we write "dropped" it includes "inserted" as well. Doesn't matter what kind it is, both are equally bad.

The only noise reduction I have from the Display button on this model Panasonic is "Copy NR" which the manual states is for DVD recording. In fact, it doesn't even show up when playing a VHS. I've turned it off now anyway.

That's most likely the setting, it's just called differently in most other Panasonics. The manual says it's for DVD recording because the engineers never thought that anyone would capture off the HDMI output, but when VHS is digitized and spit out via HDMI, the unit is doing all of the processing it would also do when it was recording to DVD, except the MPEG2 encoding and burning to DVD. Therefore this setting most likely does affect HDMI output.

Anyway, I attached another capture of the same scene for you to see. Looks better and doesn't drop from what I can see

Looks good. Much better than before.

I also noticed that the Contrast on the capture settings was set lower than the default hence my sample being dark!

The white level is very slightly too high (above 235 but not clipping at 255). Easy to fix after capture.

What do I need to do to that script to get it to produce my interlaced masters?

Let jagabo do the magic.

As an aside I'm really confused by the TFF/BFF changing (and field order in general ) If a frame includes a field order and an interpolated line (created by the VCR) then how could dropped frame(s) by the capture device cause the order to change and by extension, the interpolated line being either TFF or BFF?

Technically, there are no fields in a 50p capture and there is no field order either. But because the Panasonic's deinterlacer passes the original fields untouched and only interpolates the missing lines inbetween to make full height frames, we pretend there is a top and a bottom field in each of those 50p frames so that we can disassemble it and keep only what we want.
And the field order (TFF vs. BFF) is basically abused to do that. Do not worry about that too much.

Now the reason a frame drop or insert can mess this order up is because once the video is 50p, a drop may happen at either a former top or bottom field (now frames). On the contrary, if you capture 576i, a single frame drop would also affect one frame of course, but containing both fields (the two cannot be torn apart, unlike in a 50p capture).

If I cut out sections of good capture, that wouldn't cause field order to change?

It would change the "field order" if you cut anywhere by an uneven amount of frames. It does not if you cut an even amount of frames and only at even frame numbers.
Once the video is returned to it's native 25i state you may cut freely at any frame so I would not bother with cutting anytime before.

Edit: Then again, with jagabo's script it doesn't really matter if you cut first.

[slikvik]

That's most likely the setting, it's just called differently in most other Panasonics. The manual says it's for DVD recording because the engineers never thought that anyone would capture off the HDMI output, but when VHS is digitized and spit out via HDMI, the unit is doing all of the processing it would also do when it was recording to DVD, except the MPEG2 encoding and burning to DVD. Therefore this setting most likely does affect HDMI output.

I've turned it off now, but already captured 4 hours of footage. I guess it's possible that on this model, NR is ON all the time for playback of VHS, which is why they worded it "Copy NR" allowing you to only turn it off for DVDs. (There's also a Comb Filter setting which I've left ON).

The white level is very slightly too high (above 235 but not clipping at 255). Easy to fix after capture.

If I do decide to recapture some of these, can it be corrected at capture by lowering the contrast setting on the capture device a bit?

Let jagabo do the magic.

Hopefully! I guess I can just re-separate and weave on the last line, but it's SUPER slow as it is with the 2 hour recording I have. Would be nice if ConditionalFilter could spit out the field combined frame maybe.

Technically, there are no fields in a 50p capture and there is no field order either. But because the Panasonic's deinterlacer passes the original fields untouched and only interpolates the missing lines inbetween to make full height frames, we pretend there is a top and a bottom field in each of those 50p frames so that we can disassemble it and keep only what we want.
And the field order (TFF vs. BFF) is basically abused to do that. Do not worry about that too much.

Now the reason a frame drop or insert can mess this order up is because once the video is 50p, a drop may happen at either a former top or bottom field (now frames). On the contrary, if you capture 576i, a single frame drop would also affect one frame of course, but containing both fields (the two cannot be torn apart, unlike in a 50p capture).

It would change the "field order" if you cut anywhere by an uneven amount of frames. It does not if you cut an even amount of frames and only at even frame numbers.
Once the video is returned to it's native 25i state you may cut freely at any frame so I would not bother with cutting anytime before.

Edit: Then again, with jagabo's script it doesn't really matter if you cut first.

That is a fantastic explanation, thank you!

So, on top of hopefully getting an updated script from jagabo, there's a question of whether I should try and recapture all this footage based on A) the NR might be removed this time, B) I could tweak the white level on device (if possible) and C) I might be able to get rid of those few drops (maybe quite slim when capturing that much footage in one go). I could be overthinking this though, on what is essentially low fidelity VHS video.

Hypothetically, could I cut out the dropped frames and replace them with the missing frames from a second capture? Even if a second capture also drops frames, they wont be in the same place.

[jagabo]

Here's a script that delivers interlaced video, top field first:

function mt_hzedge(clip v, int threshold)
{
    mt_edge(v, mode="-10 -10 -10    20 20 20    -10 -10 -10", chroma="-128", thy1=threshold, thy2=threshold)
}

a = LWLibavAudioSource("holiday-50.avi", cache=false).AssumeTFF()
v = LWLibavVideoSource("holiday-50.avi", cache=false, prefer_hw=2).AssumeTFF()
src = AudioDub(v,a)

src.SelectEven().SeparateFields()
testclip = Subtract(SelectEven().mt_hzedge(5), SelectOdd().mt_hzedge(5))
v1 = src.SeparateFields().SelectEvery(4,0,3).Weave()
v2 = src.SeparateFields().SelectEvery(4,1,2).Weave().SeparateFields().Loop(2,0,0).Weave().AssumeTFF()
#v2 = src.SeparateFields().SelectEvery(4,1,2).Weave().SeparateFields().Trim(1,0).Weave().AssumeTFF()

ConditionalFilter(testclip, v2.Subtitle("v2"), v1.Subtitle("v1"), "AverageLuma()", "LessThan", "126.0")

The v1 stream is top field first. The missing field(s) from a frame drop causes v2 to be bottom field first. So it is converted to top field first by delaying or advancing it by a field. As written above it is delayed. If you want to advance instead, comment out that line and enable the next. The difference is whether you get a duplicate field at the start or end of the transition.

This script is much faster than the last one as it doesn't use QTGMC. It also includes the audio. Subtitle() is used here to make it obvious which of the two clips the final frames come from. Remove the Subtitle() calls for your final production.

Hypothetically, could I cut out the dropped frames and replace them with the missing frames from a second capture? Even if a second capture also drops frames, they wont be in the same place.

Yes you can open multiple video files and cut/paste segments in AviSynth using the Trim() filter and the "add" operator, ++. For example, to insert frame 500 of v2 into v1 at frame 1000:

Trim(v1, 0, 999)++Trim(v2, 500, 500)++Trim(v1, 1000, 0)

That first creates a clip of v1 from frames 0 to 999, then appends frame 500 from v2 to it, then appends frames 1000 to the end of v1.

[Skiller]

Excellent work, jagabo.



Regarding the Copy NR setting, I guess there is ultimately only one way to find out and that is a comparison.

The white level is very slightly too high (above 235 but not clipping at 255). Easy to fix after capture.

If I do decide to recapture some of these, can it be corrected at capture by lowering the contrast setting on the capture device a bit?

It can be corrected that way but I do not recommend it. (Also you really do not need to recapture just because of that.)
Adjusting the contrast setting on the capture device requires trial and error to get it just right and is likely to change with different tapes recorded with different equipment anyways. Plus, the risk of a slight quality loss is there compared to doing it in a more sophisticated way in AviSynth. See the problem with these controls of your capture device is, adjusting levels accurately requires a higher precision than the bit depth of the capture and then dithering that back down. The driver of your capture device would just go the easiest way and truncuate levels in the same 8 Bits per pixel precision to adjust for what you request via the contrast setting. The result is slight posterization. Although noisy VHS is very forgiving in that aspect, and it would probably not be visible, it should be avoided. Better always leave those controls at default. You want a 1:1 copy of the HDMI video on your computer.

I highly recommend you get the SmoothAdjust plugin for AviSynth and then use:

SmoothLevels(24, 1, 241, 16, 235, limiter=1, chroma=0, HQ=true)

While we are at it, the black level is a bit too high, so I corrected that as well.
There doesn't seem to be any extra detail in that particular highlight, but that's not saying this wouldn't be the case for an entire 2 hour capture.


[Attachment 65578 - Click to enlarge]

[Attachment 65579 - Click to enlarge]


Btw, that capture does look pretty good by now. Perfectly usable and proving the HDMI-route is capable of great captures – even with this obstacle of having to capture in 576p here. Great, I love it.

[oln]

Re NR, it looks like they changed the menu wording a bit from earlier models, there there is a "AV-in NR" instead of "Copy NR" but it seems the options do the same thing judging by the user manual.

There is also a "Source select(DivX)" noted in the manual under the "display" menu, which lets you change between automatic/interlaced/progressive, no idea if it has any effect though. On the older ones there was a progressive on/off setting here (and in the main setup menu) used for component output but seems this no longer has that.

I've used 576i output with the standalone and older EH57 and an older avermadia card which captures that properly as interlaced no matter the app (other than the bundled avermedia app which automatically deinterlaces, and amarectv doesn't let me select 25fps recording even though the input is still 25fps interlaced for some reason), and also with a blackmagic intensity shuttle, so I know it works with those at least. Not sure what could be causing that to not work here. Have you checked if there are any changes you can do in the bundled apps?

[jagabo]

In addition to reversing the field order by delaying or advancing by one field, one can change the field order by shifting the frame up or down by one scan line. So instead of the above "v2" lines one could use one of these:

v2 = src.SeparateFields().SelectEvery(4,1,2).Weave().Crop(0,1,-0,-0).AddBorders(0,0,0,1).AssumeTFF()

v2 = src.SeparateFields().SelectEvery(4,1,2).Weave().Crop(0,0,-0,-1).AddBorders(0,1,0,0).AssumeTFF()

Note that these will not work if chroma is subsampled vertically (4:2:0, YV12). And, of course, it causes the picture to bounce up or down by a scan line.

[slikvik]

Thanks both, again.

I do think there might be an issue with detection certainty using jagabo's scripts, but please tell me if I'm wrong!...

Using Skiller's manual check of field order:

SelectEven()
AssumeTFF()
Top=Separatefields().SelectEven().LanczosResize(width,height).Subtitle("Top")
Bottom=Separatefields().SelectOdd().LanczosResize(width,height).Subtitle("Bottom")
Interleave(Top,Bottom)

And as you said, Skiller:

Further examining the 50p version to determine which lines are original which are interpolated, using the script I posted in the other thread, I found that at the start of the video the bottom lines (of the even frames) are the original ones – until that hiccup at frame 132 where it is swapped and the top lines are then the original ones for the rest of the video.

I can see this too. There is a second drop at 423, which is an even amount of 10 inserted frames, so this should remain as the same field order as before the drop: TFF?

However if I run your scripts jagabo (and you can see this is your attachment video) at the 423 drop, the script switches from v1 to v2.

In other words the original, through manually looking goes:

BFF - @133 Drop 9 frames (odd number) - TFF - @423 Drop 10 frames (even number) -TFF

The fixed version switches twice instead of once:

BFF (v2) - @133 - TFF (v1)- @423 -BFF (v2)

Apologies for questioning your good work but it's worth me double-checking if others find this thread.

EDIT: I've just ran it on a new full 2 hour capture which only had 2 drops in the whole thing, and it switches between v1 and v2 about 10 times.
Is field order changing even when there aren't drops (as detected by VDub)?

Btw, that capture does look pretty good by now. Perfectly usable and proving the HDMI-route is capable of great captures – even with this obstacle of having to capture in 576p here. Great, I love it.

I agree! Apart from solving this recombine issue it's not a bad result and will hopefully help others in the future. FYI, I did a second capture of that 2 hour video and got the inserted frames down to 13 in only two places!

[Skiller]

Regarding jagabo's script deciding differently compared to what one would expect using the manual check, you need to consider that the script needs to offset v2 by one field to work and this automatically has an impact for later frames/fields in the video. It affects all fields in v2 right from the start of the video. Therefore it no longer needs to switch as predicted when only viewed through the linear manual check.

The missing field(s) from a frame drop causes v2 to be bottom field first. So it is converted to top field first by delaying or advancing it by a field.

I just examined the output of the script using holiday-50.avi (first sample with several frame drops/inserts) very carefully, field by field, and after each change between v1 and v2 the resulting output yields the original fields without a doubt (except during frame drops, because at least one field is missing for that time). I could not detect any signs of deinterlacing or interpolation outside the frame drops. No jittery top half line, no blurring. The decisions the script makes are the right ones, even if it does not seem relatable looking at it through the manual check.

EDIT: I've just ran it on a new full 2 hour capture which only had 2 drops in the whole thing, and it switches between v1 and v2 about 10 times.
Is field order changing even when there aren't drops (as detected by VDub)?

Maybe. Possibly analog frame drops that the Panasonic has to deal with internally do play a role in this. I would not worry about it too much.

[Eric-jan]

A converter with HDMI passthrough will also help to strip hdcp and handshaking, i have this working with a DVB-T2 tuner, any output will work for interlaced mode

[jagabo]

There is a second drop at 423, which is an even amount of 10 inserted frames, so this should remain as the same field order as before the drop: TFF?

However if I run your scripts jagabo (and you can see this is your attachment video) at the 423 drop, the script switches from v1 to v2.

Using both Skiller's manual check method and my own, I'm seeing two changes of cadence using the holiday-50.avi video from the first post in this thread. I see an obvious drop between frames 413 and 414 along with a field order change (top is better before, bottom is better after). I don't see anything change at or around frame 423 or anywhere after.

Is field order changing even when there aren't drops (as detected by VDub)?[/I]

VirtualDub doesn't know what's happening before the capture device. Given your setup there certainly could be field drops that VirtualDub cannot detect.

[oln]

EDIT: I've just ran it on a new full 2 hour capture which only had 2 drops in the whole thing, and it switches between v1 and v2 about 10 times.
Is field order changing even when there aren't drops (as detected by VDub)?

Maybe. Possibly analog frame drops that the Panasonic has to deal with internally do play a role in this. I would not worry about it too much.

COuld be wrong but never seen any drops/insert on a dvd recorder or standalone TBC causing the field order to change (or capture card for that matter), I think they probably operate with frames. Only reason it could possibly occur here is since we're dealing with 50fps here.
EDIT:
Are there multiple "cards"/devices showing up in virtualdub by any chance? Sometimes you get multiple input paths showing up in the device selection. Does changing frame rate in the avermedia app have any effect elsewhere?

[jagabo]

COuld be wrong but never seen any drops/insert on a dvd recorder or standalone TBC causing the field order to change (or capture card for that matter), I think they probably operate with frames. Only reason it could possibly occur here is since we're dealing with 50fps here.

Keep in mind that analog interlaced video is transmitted as fields, not frames. So a device that performs a double rate deinterlace (25i to 50p) could easily skip or dup a field of the source. One would hardly notice this unless one was looking for it.

[slikvik]

Thanks again the both of you. I've now captured about 6 hours of home video. I've also processed them all through jagabo's recombiner script so I can keep some masters. I'll trust your expert opinions on the script switching fields so often. Towards the end of that original sample above, the top fields still look sharper to me on the wallpaper and shirt pattern, but the end result of the your script (progressive version), looks great so all good I think! I will post some final results soon, but I do have a few final questions if that's okay!?

1) I'm using UT YUY2 4:2:2 compression all the way through, so is it okay/correct to a) Capture, then b) do jagabo's weave script to keep as a master, and finally c) do the edge trimming and colour balance together?

2) THIS MIGHT BE AN ISSUE. There's so many damn settings that I just noticed that my color depth output is set to 24 Bit RGB. Reading the help, I think my captures are safe as this doesn't seem to affect capture mode (where both my device and UT are set to YUY2)? But when I ran the weave script in full processing mode (UT YUY2) and saved the new avi, would it have gone through an unnecessary conversion from YUY2 source, to RGB output, to YUY2 final? Do I need to redo them? Not a massive issue if I do as it didn't take too long.


[Attachment 65601 - Click to enlarge]

[Skiller]

1) I'm using UT YUY2 4:2:2 compression all the way through, so is it okay/correct to a) Capture, then b) do jagabo's weave script to keep as a master, and finally c) do the edge trimming and colour balance together?

In my opinion, yes you can absolutely use UT YUY2 4:2:2 for all of that.

I think my captures are safe as this doesn't seem to affect capture mode (where both my device and UT are set to YUY2)?

Correct, it does not affect capture (unless you deliberately turned on filtering in capture mode).

But when I ran the weave script in full processing mode (UT YUY2) and saved the new avi, would it have gone through an unnecessary conversion from YUY2 source, to RGB output, to YUY2 final?

Yes, when in full processing mode and with those in/out settings in your screenshot that is exactly what happens and you do not want that. If you aren't using any filters in VD, just use "Fast recompress" mode. This avoids any conversion (at least inside VD) and is also the fastest mode.

Setting output format to YUY2 would also avoid a conversion, but it should be a bit faster to use fast recompress mode if you don't use any filters in VD.

Do I need to redo them?

Yes, I suggest you redo it to have proper masters without an unnecessary RGB conversion.

[slikvik]

Thanks mate, appreciate the fast response.

[slikvik]

I highly recommend you get the SmoothAdjust plugin for AviSynth and then use:

SmoothLevels(24, 1, 241, 16, 235, limiter=1, chroma=0, HQ=true)

While we are at it, the black level is a bit too high, so I corrected that as well.
There doesn't seem to be any extra detail in that particular highlight, but that's not saying this wouldn't be the case for an entire 2 hour capture.

Sorry Skiller, could you explain why/how you have the input_low and input_high set to 24 and 241?

[Skiller]

With a frame that has both the darkest and the very brightest spots, you want the histogram roughly touching both the left and right edges, but nothing entering the two brown pillars (except some minor overshoot/noise is OK).

You can use the histogram like this:

Histogram("Classic") #not for YUY2, needs planar such as YV16

For the values I chose...
Input_low at 24 is actually somewhat conservative (meaning there is still some space in the histogram to the left side, before the brown pillar), but that's because I know video cameras of that time, at very low light levels like in the sample clip, usually raise the black level artificially on purpose. Thus, if one were to use a higher value (resulting in darker shadows and the histogram expanding more to the left) there is a good chance it is clipping the shadows in well exposed shots such as under sunlight where the camera did not raise the black level (you should double check that using the histogram and a well exposed shot).

For input_high I chose 241 because a higher value, which would bring highlights down even more, would make the highlights no longer appear white (too strong of a correction). If you use 250 or so in place of 241 you will find the highlights appear somewhat dirty looking and may have color tinges and look too dark.
Also, at least in the test clip, there was nothing to be gained beyond 241.
A value between 235 and 241 on the other hand would not be sufficient to bring the highlights down enough in order to compress the histogram on the right side to move big chunks of "super whites" out of the brown pillar.

Anything inside the brown pillars is potentially clipped during playback, that's why it is important to address it.

[jagabo]

Note that with limited range YUV video:

Y=16 (just to the right of the left yellow bar of the histogram()*) is defined as black, R=G=B=0. That level should display as full black on at TV. Anything below 16 is illegal and may not display properly (in most case they will all display as full black even though they should be darker).

Y=235 (just to the left of the right yellow bar of the histogram()*) is defined as full white, R=G=B=255. That should display as fulll white on the TV. Anything over 235 is illegal and may not display proper (in most cases they will all display as the same shade of white as 235).


* Technically, those aren't histograms but waveform graphs. Waveform graphs are what you see on an oscilloscope when the brightness of the scanlines is transformed to height of the wave. The displayed waveform is the ~average of the waveform of all scanlines of the frame. Since video images are scanned left to right the waveform is usually horizontal, not vertical. You can get a horizontal waveform graph with TurnRight().Histogram().TurnLeft(). If you don't understand yet, this post may help: https://forum.videohelp.com/threads/340804-colorspace-conversation-elaboration#post2121568