Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Strange quantization error in waveform #451

Closed
iamdamosuzuki opened this issue Sep 27, 2017 · 19 comments
Closed

Strange quantization error in waveform #451

iamdamosuzuki opened this issue Sep 27, 2017 · 19 comments

Comments

@iamdamosuzuki
Copy link

I found a file that creates a strange waveform in QCTools. It looks like the values are quantized, instead of being evenly spread out across all of the available values. Videos containing similar content from similar materials do not display this issue. I thought maybe it was form an 8-bit to 10-bit upres, but the Bit Plane Noise Slice filter ruled that out. Any ideas?

dance_01

dance_02

dance_03
@kieranjol
Copy link
Contributor

kieranjol commented Sep 27, 2017 via email

@kieranjol
Copy link
Contributor

kieranjol commented Sep 27, 2017 via email •
edited
Loading

@richardpl
Copy link
Contributor

Typical for no real 10bit content but just badly upconverted one.

@kieranjol
Copy link
Contributor

@richardpl I'm glad that you verified this.i didn't know if a dodgy 8bit to 10bit upscaling was a cause of this. I think what puzzled me was that the ninth and tenth bits didn't just have padded zeroes.

@kieranjol
Copy link
Contributor

kieranjol commented Sep 27, 2017 via email

@iamdamosuzuki
Copy link
Author

Crazy! This was a VHS transfer going S-Video into a BlackMagic 4K Extreme card

@kieranjol
Copy link
Contributor

kieranjol commented Sep 27, 2017 via email

@iamdamosuzuki
Copy link
Author

I used a Sony SVO-5800, which has a built in TBC. Other tapes transferred on that deck have been fine, I'm totally confounded haha!

@dericed
Copy link
Member

dericed commented Sep 28, 2017

Is it the same issue, when you use mpv or ffplay directly with the waveform filter?

@dericed
Copy link
Member

dericed commented Sep 29, 2017

So thinking that this is not a qctools error, but just an error that qctools reveals. Ping to @richardpl as this reminds of an earlier thread about having a filter report metadata that quantifies disparity of neighboring sample values in a histogram (which would reveal when a video is normalized, badly upscaled, or instances of error concealment in some early digital tapes).

@kieranjol
Copy link
Contributor

kieranjol commented Sep 29, 2017 via email

@iamdamosuzuki
Copy link
Author

Yeah I think it's definitely some sort of digital signal chain error. What's weird is that the 9th and 10th bit have data in them (not just padded zeroes), but that it appears to be bad data.

@kieranjol
Copy link
Contributor

kieranjol commented Sep 29, 2017 via email

@iamdamosuzuki
Copy link
Author

I found the issue on my end. It was caused by using the S-Video input on a DPS 475. The Component and CAV inputs work just fine however. Wild!

@kieranjol
Copy link
Contributor

kieranjol commented Sep 29, 2017 via email

@CSchloss385
Copy link

We use SDI here at CUNY TV and I actually just checked a few of our files and I saw a similar pattern in the waveform. I also see weird values represented in the histogram. So I guess there is still an issue related to playing a Betacam SP in a Digibeta deck? I might run some tests where I disable the proc amps to see what the histogram looks with and without the proc amps enabled. Definitely interested in reading your blogpost about his issue @kieranjol

@bturkus
Copy link
Contributor

bturkus commented Sep 29, 2017 via email

@kieranjol
Copy link
Contributor

Hey, sorry for the bump - I might write something about all this finally, but my colleague @wendriftwood and I were looking into this again today and figured that a way to check for this in an automated way is to analyse the xml file and check if certain Y/U/V values are divisible by 4, which should (though I'd imagine not always) give a sense of padding. It's been working well so far anyhow.

Here's just the test sketch we knocked up - we're not really XML parsing, just looking through the XML as if it's a textfile for the moment.

#!/usr/bin/env/ python
import sys

def main():
    source = sys.argv[1]
    if source.endswith('.xml'):
        print(' - OK, we will use %s as the source' % source)
        with open(source, 'r') as xml_file:
            lines = xml_file.readlines()
        for line in lines:
            if 'ULOW' in line or 'YLOW' in line or 'YMAX' in line:
                value = int(line.split()[2].split('.')[0].split('=')[1].replace('"', ''))
                if not value % 4 == 0:
                    print value    
    else:
        print(' - NOT XML - THIS SHOULD BE AN XML FILEEEEEE')
        sys.exit()    
        
if __name__ == '__main__':
    main()

@iamdamosuzuki
Copy link
Author

Kieran this is such a great idea! thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@richardpl @dericed @kieranjol @iamdamosuzuki @CSchloss385 @bturkus