-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable cutout in chroma decoder #572
Comments
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. |
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. |
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? |
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. |
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. |
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 |
I shall reopen this then :) |
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?
or is this issue a duplicate of #704 ? @atsampson - can you comment? I'd like to close this if possible. |
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... |
A bit more thought about how to implement this... I'd like to remove the options above, and just have a 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 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 (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...) |
Having With Current horizontal Export commands Ideal output Issue QuoteThought I would reference Issue 60 on vhs-decode repo Currently, the commands available only allow for vertical video area adjustment image output-wise, as 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.
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. |
Any chance to implement 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 🙂 |
#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. |
This ticket is intended to suggest adding a switch to disable video overscanning during chroma decoding.
The text was updated successfully, but these errors were encountered: