HandBrake deinterlaces despite preset?

[Hanania]

My digitized, uncompressed files look just as I expect. However, compressing to FFV1 (HandBrake preset = "Preservation FFV1" and all filters = "Off") seem to result in degradation as follows:

1. While I can very clearly see the "comb pattern" in the uncompressed file, and this is what I do expect, the "comb pattern" disappears in the compressed file. It looks to me as if it has been interlaced.
2. The un-compressed file has a resolution of 720x576, while the compressed one has only 720x528. Indeed, when I open them in two instances of VLC, side by side, the latter is vertically slightly smaller.

I am digitizing for my archive, trying to leave intact whatever I can, including the interlacing (50i).

Question: What am I doing wrong?

------------------------------------------------------------------------------------
Here is my workflow. (Thanks to @aramkolt for the kind advice: https://www.digitalfaq.com/forum/vid...tml#post102762)

1.
Played back on Sony TRV67E (PAL).
TBC = ON
NDR = OFF
Input: Video8 cassettes, mono audio, PAL
Output: s-Video cable fitted with 2 male BNC connectors (for Y and C)
------------------------------------------------------------------------------------

2.
Digitized with Blackmagicdesign Mini Converter Analog to SDI.
DIP switches 4 and 5 = ON (s-Video input)
Other DIP switches = OFF
Input: the above s-Video cable
Output: BNC to BNC cable
------------------------------------------------------------------------------------

3.
Captured with Blackmagicdesign DeckLink Mini Recorder HD PCIe card.
Software: Blackmagic MediaExpress
Project video format: 625i50 PAL
Capture file format: QuickTime uncompressed 10-bit YUV
Input: the above BNC to BNC cable

Output: *.mov files
Data shown by VLC media player:
Codec: 10-bit 4:2:2 Component YCbCr (v210)
Video resolution: 720x576
Buffer dimensions: 720x576
Frame rate: 24.997694
Decoded format: Planar 4:2:2 YUV 10-bit LE
Color primaries: ITU-R BT.601 (625 lines, 50 Hz)
Color transfer function: ITU-R BT.709
Color space: ITU-R BT.601 Range
------------------------------------------------------------------------------------

4.
Compressed with HandBrake.
Preset = "Preservation FFV1"
All filters = Off
Input: the above *.mov files

Output: *.mkv files
Data shown by VLC media player:
Codec: FF video codec 1 (FFV1)
Video resolution: 720x528
Buffer dimensions: 720x544
Frame rate: 25
Decoded format: Planar 4:2:2 YUV 10-bit LE
Color primaries: ITU-R BT.601 (625 lines, 50 Hz)
Color transfer function: ITU-R BT.709
Color space: [Not reported in VLC]
------------------------------------------------------------------------------------

[Hanania]

Quote:

1. ... It looks to me as if it has been interlaced.

That was a typo. I meant:

1. ... It looks to me as if it has been de-interlaced.

[vwestlife]

How are you viewing the output? Setting the de-interlacing in VLC Media Player to "off" doesn't necessarily disable all de-interlacing. It just disables VLC's own software-based de-interlacing. Your video card could still be doing its own hardware-based de-interlacing.

Make sure Handbrake's auto-cropping is disabled. Otherwise that could be why the output has lower resolution than the input -- it sees what it thinks is a black border on your video and is cropping it off.

[Hanania]

1. You are right. I did see that VLC has three options under Video > Deinterlace, but I misinterpreted what I observed. Later, after posting my question, while viewing the video, I stopped at a fast moving frame, then I clicked "D", and voila, the telltale comb-pattern of interlacing appeared. Bottom line: HandBrake behaved as I expected; it did not deinterlace. (BTW, once I realize my mistake, I asked in a PM to the admin to delete my question.)
2. Thanks for the lead regarding the resolution issue. I checked, and I see that in HandBrake's Dimensions > Orientation and Cropping I have Corpping set to None. I assume that this is what you meant.
3. I noticed in HandBrake's Dimensions > Resolution and Scaling that if I change Anamorphic to Automatic, then Scaled Size is affected. I think that I have a good understanding of the different notions of aspect ratio, so I'll need to find whether I have to mess around with that at all. I'll deal with pixel aspect ratio when it will come to presenting video. Now I care only for not loosing information (pixels). Does this ring any bells?

Thanks

[aramkolt]

Doesn't exactly apply to the original poster since they are using PAL, but I think it is reasonable to crop 6 pixels of vertical space (usually it'd be at the bottom where head switching noise is) as Blackmagic's SDI is 720x486 when in NTSC. While 486 is technically the full height NTSC frame size, it causes a lot of aspect ratio confusion later. Other capture cards just tend to grab 480 of the 486 lines and discard a pre-defined 6 lines, usually a couple from the top (the very first line is actually a "half" line that starts midway into the line) and the rest are skipped from the bottom.

Since the lines captured can vary, this makes it so that some cards appear to capture more "head switching noise" at the bottom than others, but in reality, they are capturing the same number of lines, they are just discarding more lines from the top of the image instead of the bottom.

[vwestlife]

720x486 resolution is almost never used, because some old codecs required the resolution to be divisible by 16, so everyone agreed to change it to 480 lines. This is going back to the early 1990s when the standards for digital TV were first being established.

The same rule is why Apple software likes to stretch out 16:9 480i/480p content to a little-too-wide square pixel resolution of 864x480, while other software (like ArcSoft) sometimes squish it down to a little-too-narrow 848x480.