Some arguments (like --luma-nr) seem to be ignored when using tbc-video-export

[Mikewando]

Checklist

• I have searched the issues page for any duplicate issues open or closed and confirmed that this bug has not been reported before.
• I have tested the issue with the current build.
• I have attached log files, uploaded sample data, and commands used so that the issue can be easily reproduced by the developers.

Bug Description

It seems that setting --luma-nr has no effect when using tbc-video-export. I have not tested every option, but I assume other options could have a similar issue if the root cause is a mismatch between argparse configuration and subsequent usage.

Steps to Reproduce

I'm using the windows build, but I imagine it's similar on linux.
Using a laser disc tbc I noticed that even though I specified --luma-nr 1.0 the --dry-run reveals that ld-chroma-dcoder is invoked with --luma-nr 0.0 and indeed live runs yield a noisy video no matter what luma-nr is set to.

.\tbc-video-export.exe --luma-nr 1.0 --dry-run example.tbc example.mkv
tbc-video-export 0.1.0b2

Input TBC:     example.tbc
Output Files:  example.mkv
Log Files:     Disabled

Video System:  NTSC   TBC Type:     Composite (CVBS) Chroma Decoder: NTSC2D
Total Fields:  1254   Total Frames: 627              Export Mode:    Luma + Chroma (combined)

Profile:       ffv1_10bit (FFV1 yuv422p10le, FLAC)
Frame Type:    Interlaced (Top Field First)



Step 1
ld-dropout-correct (COMBINED)
C:\Users\mike\Downloads\decode_suite_full\decode\ld-dropout-correct.exe -i example.tbc --input-json example.tbc.json --output-json nul [PIPE_OUT_LD-DROPOUT-CORRECT_COMBINED]

ld-chroma-decoder (COMBINED)
C:\Users\mike\Downloads\decode_suite_full\decode\ld-chroma-decoder.exe --luma-nr 0 -p y4m -f ntsc2d -t 16 --input-json example.tbc.json [PIPE_IN_LD-DROPOUT-CORRECT_COMBINED] [PIPE_OUT_LD-CHROMA-DECODER_COMBINED]

ffmpeg (COMBINED)
C:\Users\mike\Downloads\decode_suite_full\decode\ffmpeg.exe -hide_banner -loglevel error -progress pipe:2 -threads 16 -nostdin -hwaccel auto -color_range tv -thread_queue_size 1024 -i [PIPE_IN_LD-CHROMA-DECODER_COMBINED] -filter_complex [0:v]null,setfield=tff[v_output] -map [v_output] -timecode 00:00:00:00 -framerate ntsc -aspect 4:3 -color_range tv -colorspace smpte170m -color_primaries smpte170m -color_trc bt709 -pix_fmt yuv422p10le -c:v ffv1 -coder 1 -level 3 -context 1 -slices 24 -slicecrc 1 -g 1 -c:a flac -compression_level 12 -attach example.tbc.json -metadata:s:t:0 mimetype=application/json example.mkv

Expected Behavior

The --luma-nr specified when invoking tbc-video-export is used when it invokes ld-chroma-decoder.

Actual Behavior

The --luma-nr for ld-chroma-decoder is always 0.0

Environment

• Decode version: https://github.com/oyvindln/vhs-decode/releases/tag/0.2.3
• Operating System: Windows 10

[harrypm]

@Mikewando This should have been made on the tbc-video-export repo, but while I am here @JuniorIsAJitterbug

[JuniorIsAJitterbug]

This will be fixed in the next beta.

I had restricted the use of --luma-nr to the luma decoder instance without any consideration for CVBS/LD, oops.

[harrypm]

@Mikewando as this issue has now been patched.

https://github.com/JuniorIsAJitterbug/tbc-video-export/releases/tag/v0.1.0b3

I'll close this issue, thanks for bringing it to attention!