digitalFAQ.com Forum - First capture results, settings, advice?

digitalFAQ.com Forum (https://www.digitalfaq.com/forum/)

- Capture, Record, Transfer (https://www.digitalfaq.com/forum/video-capture/)

- - First capture results, settings, advice? (https://www.digitalfaq.com/forum/video-capture/12570-first-capture-results.html)

First capture results, settings, advice?

As of yesterday I finally had the bare minimum equipment needed (deck and capture card), so I took my first test capture last night. HS-HD2000U s-video output >> Extron s-video to BNC Y/C split cable >> Kona LHe breakout cable BNC Y/C inputs >> capturing 8-bit 4:2:2 uncompressed in Premiere Pro CS6. I think CS6 is the last version that supported my LHe. About 1GB per minute :laugh: and I'm pleasantly surprised by how it came out. I'm particularly surprised by how good the audio is when heard through reference equipment. I tested on a THX Return of the Jedi VHS that seems to be in good condition. x265 compressed it to about 1.4% of the original uncompressed size with pretty minimal quality change. Excited to keep going and start trying different settings and eventually be ready to do the home videos properly.

This setup is temporary as I just couldn't wait to get my first capture by any means necessary. I know none of this is the recommended stuff but it's just what I already have set up and am already familiar with using. After I get a TBC I'll be ready to go for real and I'll have to move on to learning about the different capturing software.

I've attached 5 screenshots of the uncompressed video and also the x265 encoded .mkv clip of it.

- - - - - - - - - - - - - - - - - - - - - - - -

Uncompressed video/audio file info:

[Video - General]
Complete name : E:\files\video\captures\rotj-01.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 1.19 GiB
Duration : 1 min 1 s
Overall bit rate : 166 Mb/s

[Video]
ID : 0
Format : 2vuy
Codec ID : 2vuy
Duration : 1 min 1 s
Bit rate : 166 Mb/s
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Bits/(Pixel*Frame) : 16.000
Time code of first frame : 08;06;40;11 / 08;06;40;11
Time code source : Adobe tc_A / Adobe tc_O
Stream size : 1.19 GiB (100%)

[Audio - General]
Complete name : E:\files\video\captures\rotj-01.wav
Format : Wave
File size : 11.3 MiB
Duration : 1 min 1 s
Overall bit rate mode : Constant
Overall bit rate : 1 537 kb/s

[Audio]
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 1 min 1 s
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 11.3 MiB (100%)

- - - - - - - - - - - - - - - - - - - - - - - -

x265 compressed video/audio file info:

[General]
Complete name : E:\files\video\encodes\rotj-test-01_x265.mkv
Format : Matroska
Format version : Version 4
File size : 17.9 MiB
Duration : 1 min 1 s
Overall bit rate : 2 434 kb/s
ErrorDetectionType : Per level 1

[Video]
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L3@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 min 1 s
Bit rate : 1 106 kb/s
Width : 704 pixels
Height : 478 pixels
Display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.110
Stream size : 8.12 MiB (45%)
Writing library : x265 8bit+10bit+12bit
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.601 NTSC
Transfer characteristics : BT.709
Matrix coefficients : BT.601

[Audio #1]
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 1 min 1 s
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Delay relative to video : -5 ms
Stream size : 4.70 MiB (26%)
Title : Stereo
Service kind : Complete Main
Default : Yes
Forced : No

[Audio #2]
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 1 min 1 s
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Delay relative to video : -5 ms
Stream size : 4.70 MiB (26%)
Title : Stereo
Service kind : Complete Main
Default : No
Forced : No

- - - - - - - - - - - - - - - - - - - - - - - -

Even though I'm not staying with this workflow I'm still interested to know how the settings and results look. I came across a ton of options for the video capture that I hadn't been able to read about yet, so some I left on the default, some I took a guess and changed.

720x480 was the smallest resolution I was able to select -- didn't see a way to enter custom resolution, not sure if it was there or not. 2vuy and the other options (I think that was for color) I wasn't sure about and left at default.

Timecode was an interesting one, there were options for using embedded LTC or VITC #1 or VITC #2 -- I was thinking to set that to VITC #1 but LTC was the default so I left it on that.

I see my 4:2:2 when uncompressed got downgraded to 4:2:0 when I compressed with x265 -- I'm thinking I probably didn't lose anything discernible there since that happened in compression and I had already gotten the original capture in 4:2:2 off the tape so I had as much info as possible.

The eventual goal is to get everything set up properly and then do the VHS home movies and save the uncompressed files on separate HDDs, while burning compressed versions to BD discs and keeping those files on the media server as well. Still a way off but it's nice to finally have captured something just to be able to look through settings and options and see how it works.

I think I'm going to try both the CGR and SMPTE options and see what the difference is. I don't know enough yet to fully comprehend this explanation as far as what the visual difference will be between the 2 different mapping schemes, other than I'd probably only want SMPTE if I were capturing from broadcast equipment or something:

Quote:

YUV<->RGB Range
( Option 1: CGR / Option 2: SMPTE )
This control mode should almost never be changed from its CGR default. This setting is only for highly-knowledgeable users that must define how color values will be mapped when doing the color space conversion—far less than 1% of all users should ever need to use it. Use this feature only for capturing YUV source into an RGB file, or to play an RGB file out to YUV. The CGR setting maps the typical YUV values to typical RGB values. For example, 8bit YUV 16 is mapped to 8 bit RGB 0, and YUV 235 to RGB 255. The ‘SMPTE’ setting for this control maps YUV into RGB using the exact YUV values. Therefore, 8 bit YUV 16 will map to RGB 16, and so forth. Only change this setting from its default if you are absolutely sure you know the benefits/consequences. This feature is not the same as a broadcast safe limiter.

Quote:

Originally Posted by mrmuy97 (Post 83966)

going to try both the CGR and SMPTE options and see what the difference is

I don't see a difference other than what I assume is a slight capturing variation from the card's ADC. CGR 1st, SMPTE 2nd.

Attachment 15014

Attachment 15015

Quote:

Originally Posted by mrmuy97 (Post 83969)

I don't see a difference other than what I assume is a slight capturing variation from the card's ADC. CGR 1st, SMPTE 2nd.

From the documentation quote in your previous post: "Use this feature only for capturing YUV source into an RGB file, or to play an RGB file out to YUV."

The test that you posted should be straight YUV -> YUV, in which case those options will do nothing.

BTW, in the OP you mentioned being unsure of the "2vuy" setting. There's nothing wrong with using this. It's uncompressed 4:2:2 @ 8-bit just like YUY2, UYVY, YV16, etc. and you can losslessly convert between any of these pixel formats. The only difference is how the bytes are stored in the file.

Quote:

Originally Posted by mrmuy97 (Post 83019)

capturing 8-bit 4:2:2 uncompressed in Premiere Pro CS6

Correction: I used Machina 4.2.1.0. Must've just been looking at Premiere settings/options when I wrote that. Haven't tested Premiere yet for comparison.

Quote:

Originally Posted by mrmuy97 (Post 83019)

surprised by how good the audio is

After some further reading on VHS audio, turns out it can be excellent quality. I had never listened to VHS audio through anything other than a cheap and awful quality VCR and TV previously. Had no idea!

Quote:

Originally Posted by mrmuy97 (Post 83019)

720x480 was the smallest resolution I was able to select

Changed to the full 486 and it grabs that CC info at the top. Have to see what shows up there on home videos instead of retail movies.

Quote:

Originally Posted by mrmuy97 (Post 83019)

2vuy and the other options (I think that was for color) I wasn't sure about and left at default.

Read up on it a bit more and switched it to "uyvy" 8-bit YUV 4:2:2. CGR and SMPTE were the options for "YUV<->RGB Range"

Quote:

Originally Posted by mrmuy97 (Post 83019)

Timecode was an interesting one, there were options for using embedded LTC or VITC #1 or VITC #2 -- I was thinking to set that to VITC #1 but LTC was the default so I left it on that.

Read up on it a bit more and found that VITC is meant for the video and LTC is for the audio, so I switched "Timecode Input" to "Embedded VITC #1 (RP188)"

Quote:

Originally Posted by mrmuy97 (Post 83019)

I see my 4:2:2 when uncompressed got downgraded to 4:2:0 when I compressed with x265 -- I'm thinking I probably didn't lose anything discernible there since that happened in compression and I had already gotten the original capture in 4:2:2 off the tape so I had as much info as possible.

I've found some noticeable changes along edges in my 2nd test capture. Screenshots attached showing the lines when uncompressed and then with x265 for comparison.

1.1 - uncompressed
Attachment 15016

1.2 - x265
Attachment 15017

2.1 - uncompressed
Attachment 15018

2.2 - x265
Attachment 15019

Quote:

Originally Posted by msgohan (Post 83970)

:smack: Thanks, that one really got away from me, shouldn't have stayed up all night :laugh:

Machina 4.2.1.0 settings for 2nd test capture, screenshot of x265 compressed capture, and x265 compressed capture attached

- - - - - - - - - - - - - - - - - - - - - - - -

Uncompressed video/audio file info:

[Video - General]
Complete name : E:\files\video\captures\anh-test-03.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 1.38 GiB
Duration : 1 min 10 s
Overall bit rate : 168 Mb/s

[Video]
ID : 0
Format : YUV
Codec ID : UYVY
Codec ID/Info : Uncompressed 16bpp. YUV 4:2:2 (Y sample at every pixel, U and V sampled at every second pixel horizontally on each line). A macropixel contains 2 pixels in 1 u_int32.
Duration : 1 min 10 s
Bit rate : 168 Mb/s
Width : 720 pixels
Height : 486 pixels
Display aspect ratio : 3:2
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 16.000
Stream size : 1.38 GiB (100%)

[Audio - General]
Complete name : E:\files\video\captures\anh-test-03.wav
Format : Wave
File size : 12.9 MiB
Duration : 1 min 10 s
Overall bit rate mode : Constant
Overall bit rate : 1 536 kb/s

[Audio]
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 1 min 10 s
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 12.9 MiB (100%)

- - - - - - - - - - - - - - - - - - - - - - - -

x265 compressed video/audio file info:

[General]
Complete name : E:\files\video\encodes\anh-test-03_x265.mkv
Format : Matroska
Format version : Version 4
File size : 26.1 MiB
Duration : 1 min 10 s
Overall bit rate : 3 109 kb/s
ErrorDetectionType : Per level 1

[Video]
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L3@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 min 10 s
Bit rate : 2 407 kb/s
Width : 704 pixels
Height : 484 pixels
Display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.236
Stream size : 20.2 MiB (77%)
Writing library : x265 8bit+10bit+12bit
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.601 NTSC
Transfer characteristics : BT.709
Matrix coefficients : BT.601

[Audio]
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 1 min 10 s
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Delay relative to video : -5 ms
Stream size : 5.38 MiB (21%)
Title : Stereo
Service kind : Complete Main
Default : Yes
Forced : No

- - - - - - - - - - - - - - - - - - - - - - - -

Attachment 15020

Attachment 15021

Attachment 15022

Quote:

Originally Posted by mrmuy97 (Post 83019)

Timecode was an interesting one, there were options for using embedded LTC or VITC #1 or VITC #2 -- I was thinking to set that to VITC #1 but LTC was the default so I left it on that.

Quote:

Originally Posted by mrmuy97 (Post 83971)

Read up on it a bit more and found that VITC is meant for the video and LTC is for the audio, so I switched "Timecode Input" to "Embedded VITC #1 (RP188)"

I meant to follow up on this setting and add a few details since I had originally questioned it and added a poorly-worded reply. I should have phrased it as "VITC is on the video track" and "LTC is on one of the audio tracks." My understanding from what I've read is that LTC and VITC carry identical timecode information, but VITC adds [1] an extra bit to indicate if timecode is synched to an external clock and [2] a few bits after that which contain a checksum. The option for "VITC #1" uses the first interlaced field of a frame, and "VITC #2" uses the second.

Every source I found mentions LTC's weak point is that timecode can be lost the slower the tape plays, and completely when paused or stopped. VITC's weakness is the opposite and timecode can be lost at very fast tape speeds. Based on this info I decided that VITC seems a bit more robust for my needs of simply playing a VHS tape straight through, and that's my preference when possible. Some of the quotes below suggest that VITC is superior. However, a consumer VHS tape may use either one -- e.g. a camcorder recording only mono audio on track/channel 1 and the LTC on track/channel 2 -- so you may not always have the VITC option. I'm only speaking here from my understanding so far of camcorder VHS home videos and am no expert by any means.

Here is a PDF I found very interesting [https://mediaarea.net/Events/2018-10...ode_final.pdf] and some quotes from it:

Quote:

Characteristics of Timecode: Three characteristics to look out for when assessing your timecode*

● Is it VITC or LTC timecode?
● Is it Drop Frame or Non Drop Frame?
● Is it Continuous or Discontinuous?

*DV Time (DV timecode captured via firewire) and DAT are not included in this timecode discussion

Quote:

Characteristics of Timecode: VITC & LTC

Longitudinal TimeCode (LTC)
● The earlier of the two timecode types
● Usually (but not always) recorded on audio track 2
● Prone to drift, read errors, and cannot be read at fast speeds.
● Listen to what LTC “sounds” like: https://www.youtube.com/watch?v=zjH0RFV206M

Vertical Interval TimeCode (VITC)
● VITC is integrated into the video track of the tape which resolves a number of problems found with LTC
● Provides indexing resolution down to the video field; this means VITC timecode can be read at all speeds the video is played back at
● Frees up the 2nd audio channel for recording

Quote:

Characteristics of Timecode: NDF & DF (it’s an NTSC thing)

● Drop Frame [DF] and Non-Drop Frame [NDF] are distinguished by the colon or semi-colon present before the frame count:
Drop Frame: HH:MM:SS;FR (01:01:01;01) Non Drop Frame: HH:MM:SS:FR (01:01:01:02)
● Simply two different ways of labeling a frame. Drop Frame timecode accommodates the 29.97fps framerate of color, introduced after the 30fps was already established for monochrome.
● “When an American TV frame-rate video production must be edited to actual clock time, Non Drop Frame timecode must be used. If staying in time with an actual clock is not important, especially on short video productions like commercials, the bastard 29.97 fps Drop Frame timecode is often used."

Quote:

Characteristics of Timecode: Continuous & Discontinuous

● Continuous timecode is an unbroken clocking moving forward from the first frame to the last.
● Discontinuous timecode occurs when a recording abruptly stops and starts again. Discontinuous timecode is common in recordings not made within strict broadcast workflows: video art, independent media, home movies

Quote:

What are the issues regarding timecode? Source recordings may have multiple timecodes: vertical interval timecode (VITC), linear timecode (LTC), and more. Some are present on purpose, others by accident; some may have good integrity and continuity, others may be discontinuous.

Quote:

When Timecode Makes U Wanna Scream

● LTC does not match VITC
● LTC is DF and VITC is NDF.
● LTC is inconsistent or garbled.
● User bit code if present is inconsistent.
● VITC changes line assignment or drops out completely in a single tape.
● Time code in the picture [BITC] does not match LTC or VITC.

Some other interesting info from [https://whitefiles.org/tec/pgs/h16f.htm] with a nice breakdown of the SMPTE coding of the timecode at the end:

Quote:

Recorders sometimes have separate heads for timecode and audio, requiring a fixed delay circuit to keep the two signals in step. Others have combination heads, such as a combined head for erasing audio and playing timecode, with another for erasing timecode and recording audio. Once again, delay circuitry is required.

- The linear audio tracks of a VHS video recorder or Compact Cassette machine aren’t suitable for LTC, mainly because of the tape jitter inherent in slow-speed tape systems.
- The frequency modulation (FM or AFM) audio ‘tracks’ that provide hi-fi sound on some types of VHS machine can’t normally be used for recording ‘over’ existing video material. Hence these tracks can’t be used to add LTC to a recording.
- The pulse code modulation (PCM) audio ‘tracks’ that provide digital sound on some types of VHS machine are also suitable for recording LTC.
- Timecode in the form of LTC can’t be copied reliably between two tape machines unless it’s processed by a timecode reader/generator, also known as a regenerator.
- You should switch off noise reduction for any audio track that’s used for recording LTC.
- Recording audio onto a tape that’s already been striped with LTC can erase the timecode.

Quote:

- Two sets of VITC data, using two pairs of lines, can exist on a single recording. The first set usually gives the time of day of the original recording, often containing discontinuities caused by editing. The second gives the programme duration, hopefully as continuous timecode.
- Some VITC equipment can’t distinguish between different sets of VITC data, making it impossible to read the required timecode when two sets of data are present.

All times are GMT -5. The time now is 08:37 AM