Colorspace for captured PAL footage?

[sverholm]

Hello to all, and thank you for a very valuable forum with loads of information and helpful and knowlegeable participants.

In short, I'm a long time lurker and (close to) first time poster. Have been lurking, off and on, for at least five years, during these years I have acquired tne necessary hardware (VCRs with line TBC, Datavideo TBC4000 (from lordsmurf) various capture cards and both Win XP/7 and mac computers.

The sources are 1.st gen PAL SVHS family videos. My workflow for this particular question has been JVC HR-S7600EU -> TBC 4000 -> Matrox MXO2 Mini, connected to an internal PCI-card in a MAC Pro 2010 with Yosemite. All relevant connections are S-video cables. Matrox utilities used as capture software, and recorded to ProRes 422HQ. I know this is not a favoured capture software, but at present it is the most stable capture chain i have managed to set-up.
No dropped frames, and i will come back in a later post to ask for comments on the result.

My question at this point stems from a discovery that has puzzled me. In Mediainfo, as well as in Hybrid, I discovered that the "Color Primaries" are noted as BT.601 NTSC. All possible settings in the capture software identifies the source as PAL, as far as I know.

The relevant colorspace settings, as reported by Hybrid, are:
<input_data name="Color" value="4:2:2"/>
<input_data name="Color Space" value=" yuv422p10le"/>
<input_data name="Color Matrix" value="smpte170m"/>
<input_data name="Color Transfer" value="BT.709"/>
<input_data name="Color Primes" value="BT.601 NTSC"/>

The question is really what possible adverse effect the NTSC reference in the Color primaries can have on the video quality, and if the other color valuses seems fair. What color values would be the right ones for a PAL ProRes file. If anybody should have any ideas how to correct the captures, I would be very grateful.

Regards
Sverre

[lordsmurf]

Quote:

Originally Posted by sverholm

I know this is not a favoured capture software,

Hardware, software, sources ... all seem fine to me, in your specific use case.

Quote:

My question at this point stems from a discovery that has puzzled me. In Mediainfo, as well as in Hybrid, I discovered that the "Color Primaries" are noted as BT.601 NTSC. All possible settings in the capture software identifies the source as PAL, as far as I know.

Interesting. I've never run into this situation.

I did some Google research, and a certain query attracted the attention of Google Gemini:

Quote:

AI Overview
While both "BT.601 NTSC" and "BT.601 PAL" refer to the same digital video color standard (ITU-R BT.601), the key difference lies in the specific color primaries used, with NTSC utilizing SMPTE-C primaries and PAL using slightly different primaries designed for the 625-line system, resulting in subtle color variations between the two when displaying the same content; essentially, they are the same standard adapted for the different analog TV systems (NTSC and PAL) with slightly different color characteristics depending on the line resolution involved.

Key points to remember:
-- Standard: Both NTSC and PAL versions are based on the ITU-R BT.601 standard.
-- Color Primaries: The main difference is the color primaries used, with NTSC employing SMPTE-C primaries and PAL using slightly different ones optimized for its 625-line system.
-- Impact: This means that the same video encoded in BT.601 NTSC might appear slightly different in color when displayed on a system expecting BT.601 PAL.

... and that assumes Gemini is accurate, and not just hallucinating.

Quote:

The question is really what possible adverse effect the NTSC reference in the Color primaries can have on the video quality, and if the other color valuses seems fair. What color values would be the right ones for a PAL ProRes file.

I'm not too sure.

Quote:

If anybody should have any ideas how to correct the captures, I would be very grateful.

I saw some discussions on Doom9 about proper colorspace conversion.

This is also related to smpte170m and bt470bg, though I'm not sure how that may alter with 4:2:2 vs. 4:2:0.

Also read this: https://forum.selur.net/thread-2838.html

I was actually going to suggest asking selur, but in that thread he said "No clue" (meaning that odd colorspace issues may be beyond his forte -- but ask anyway).

Also, from that thread:

Quote:

Quick update - I have been referred to the H273 specification which defines the format and content of the color hinting discussed above. According to this doc, the BT.601 recommendation has the following properties:

- Rec. ITU-R BT.601-7 525 (NTSC)
- BT470BG matrix
- BT.709/SMPTE 170M transfer
- BT470BG primaries

- Rec. ITU-R BT.601-7 625 (PAL)
- SMPTE 170M matrix
- BT.709/SMPTE 170M transfer
- SMPTE 170M primaries

So .... yeah.

What I'm suspecting is that some setting was not correct in the capture software, possibly on that Matrox capture box (does it have DIP?). But regardless, it seems that this can be corrected with proper conversion, likely with Avisynth (and thus inside Hybrid).

You'll need to read deeper on this, but hopefully that sets you in the right direction.

[sverholm]

Thank you for your valuable suggestions.

Firstly, I created a short capture of colour bars and ran it through Hybrid to make a deinterlaced and masked copy. By using video-compare, I discovered that the colour flag really matters, the copy did change colours, compared to the original.

I then tried to use ffmpeg to change the metadata-flag only:
ffmpeg -i input.mov -c:v copy -metadata color_primaries=bt601 output.mov
The output file was created, but no flags were changed.
I’ll have to try Hybrid/Vapoursynth conversion, or Hybrid’s capabilities to override the color-primaries flag.

Furthermore, I want to find the root-cause. In order to isolate the problem I:
- used different players
- changed the TBC to Datavideo SE-500 (yes, I know …)
- took the TBC out of the capture chain
- changed the codec to Matrox uncompressed
- Replaced the Mini with a Matrox MXO2 LE (no dip switches outside nor inside the Mini)
None of the above actions removed the NTSC flag, which leads me to believe the Matrox Vetura Capture to be the culprit.

Follow-on I will reinstall the Matrox software and try a previous release.

I’ll report back.

Sverre

[sverholm]

Update: Successful change to the metadata with the following command from Terminal:
ffmpeg -i input.mov -c copy -color_primaries bt470bg -color_trc gamma28 -colorspace bt470bg -movflags +write_colr output.mov

There are, however, still color differences between the original captured and re-flagged file and the deinterlaced and masked file from Hybrid. I haven't measured, but the differences seems to be equal before and after re-flagging.

My current conclusion is that the bt601 NTSC flag has less effect on the colors, than masking and deinterlacing the file. I have not tried further to find the root-cause, and I will not prioritize that for now.

[lordsmurf]

I always forget .... does the Matrox MX02 work with VirtualDub?

I know that's not Mac-native, but Bootcamp to Windows is possible on Intel (pre-M silicon). The 2010 should run Windows fine, though I forget which version is best (XP, Vista, 7).

[sverholm]

It should work with VDub, but I haven't managed to get my sound drivers to work. The videostream captures fine, but no sound. Most likely something to do with my Windows 7 implementation. The strange thing is that I´m able to capture sound and video with the native Matrox capture software, on the very same machine, a Lenovo W530.

On the Matrox support site they have drivers for
Mac OS X 10.7 Lion
Mac OS X 10.8 Mountain Lion
Mac OS X 10.9 Mavericks
Mac OS X 10.10 Yosemite
Windows 7 x64
Windows 8.1 x64

I got the XP drivers for MXO2 from Matrox support, some two years ago, but they were not very stable. Most likely why it is not available from the Matrox support site.

Can a Bootcamp-setup be made with XP Integral?