Disable cutout in chroma decoder

[Zcooger]

This ticket is intended to suggest adding a switch to disable video overscanning during chroma decoding.

[simoninns]

Can you specify what the output is expected to be here? afaik there is no overscanning in the chroma decoding; it outputs video according to the timing detailed by the PAL or NTSC standards.

[happycube]

Yup. My personal philosophy is when it's in RGB and pcm, it's out of ld-decode's domain - ffmpeg can crop overscan, and it may vary according to the content.

[Zcooger]

Good example of such image: Otherwise it's RGB, but cropped by the color decoder. It's VHS but in case of composite video you can usualy see color burst too here. So this ticket aims for colourised and uncropped frames out of comb processor.

[atsampson]

What are you planning to do with this output? It'd be possible to make the cropping in ld-chroma-decoder configurable, but do you want the area outside the active region to contain the (nonsense) results of chroma decoding (which would slow down the decoding and mean dealing with a couple of edge cases we don't currently have to handle), or do you just want it to be black with the active region in the right place relative to the input signal?

[Zcooger]

Mainly for inspection of nonsense color information, quality control (to check if everything is fine with decoding) and for demonstration purposes: Current setup for cropping could be configurable and I'd really appreciate --nocrop switch for it. Processing speed does not matter that much for this case.

[simoninns]

I'm really of the opinion that this is unnecessary complexity - you can view the uncropped PAL/NTSC easily in ld-analyse and I don't think it's work making ld-chroma-decoder more complex for. @atsampson - if you think otherwise please reopen and implement.

[atsampson]

I'd actually quite like an option to adjust the active area but for the opposite reason - I usually want output without padding - so it should be possible to support this too. I can understand now why Zcooger wants it and being able to decode off-locked samples does seem reasonable for debugging/demo purposes.

[Zcooger]

I was/am overscan hater despite the fact it's not exactly overscan but chroma decoder does similar thing that capture cards do. It may actually replace overpriced studio monitors with cross pulse switch (15:10): https://youtu.be/HEXLlqJQ7Oc

[simoninns]

I shall reopen this then :)

[simoninns]

I can see a bunch of options in the decode for specifying start and end lines - so I'm guessing this issue is already solved?

 --ffll, --first_active_field_line <number>  The first visible line of a
                                              field. Range 1-259 for NTSC
                                              (default: 20), 2-308 for PAL
                                              (default: 22)

  --lfll, --last_active_field_line <number>   The last visible line of a field.
                                              Range 1-259 for NTSC (default:
                                              259), 2-308 for PAL (default: 308)

  --ffrl, --first_active_frame_line <number>  The first visible line of a
                                              frame. Range 1-525 for NTSC
                                              (default: 40), 1-620 for PAL
                                              (default: 44)

  --lfrl, --last_active_frame_line <number>   The last visible line of a frame.

or is this issue a duplicate of #704 ?

@atsampson - can you comment? I'd like to close this if possible.

[atsampson]

Please leave it open for now - those options allow you adjust the active area vertically but not horizontally, and I'd like to revisit this once the line number conversion stuff is finished...

[atsampson]

A bit more thought about how to implement this...

I'd like to remove the options above, and just have a --full-frame option, where the help is something like "Decode and output the full frame, not just the active area (warning: may cause artefacts at edges of active area)".

The challenge for implementation is that most of the decoders assume that they can access a few samples beyond the active area both horizontally and vertically -- this is why the options above don't let you get too close to the edge of the frame. At present, each SourceField has its own array of composite data for that field. However, SourceFields are always read in contiguous groups, and there's already a mechanism for reading additional fields at the start and end, and padding with black fields at the ends of the input file.

So one approach would be to allocate a single large array for the group of fields, representing the complete set of composite samples for those fields (taking care with 4fSC PAL field length etc.), and give each SourceField a pointer into it. That way, when a decoder tries to read outside the bounds of a field, it'll just get samples from the previous or next field - which should do the right thing in terms of chroma-decoding off-locked video.

(You could also use this to get rid of the current logic for replacing out-of-active-area lines with dummy black lines in the decoders - just blank out those lines in the input data instead. We'd need to measure this to see which is more efficient...)

[harrypm]

Having --full-frame (when working) would be ideal, but for more practical or scripted outputs to be in-line with standard captures (it saves around 20~45mbps of bitrate) having horizontal adjustments, either way, would be valuable.

With Current horizontal Export commands

Ideal output

Issue Quote

Thought I would reference Issue 60 on vhs-decode repo

Currently, the commands available only allow for vertical video area adjustment image output-wise, as --full-frame is broken.

However, this does not cover 100% of active picture output in some cases and can be left or right-side biased so having these 2 commands implemented would be ideal.

--horizontal_positon_left --hpl

--horizontal_positon_right --hpr

The pixel range would be 0-16 left & 0-12 right.

Description: Adjusts the horizontal plane of rendered video area, which is useful if the tape image signal is not centred.

[tvasenin]

Any chance to implement --full-frame option or --hpl + --hpr pair anytime soon?

At the moment, most of my captures are not centered correctly, and sometimes the active area is also wider than 922 px (or rarely even than 928 px), and I'm a bit tired to manually adjust json 🙂

[harrypm]

890 adds basic abbilitys to adjust the framing horizontally via simply altering the json values feed to the chroma-decoder but does not have safe boundrys set so can crash the ld-analyse application.

It should also be noted, ld-dropout-correct only covers the active video area also.