• Philip Langdale's avatar
    CrystalHD: Improve detection of h.264 content. · ae7a4a15
    Philip Langdale authored
    As previously discussed, the CrystalHD hardware returns exceptionally
    useless information about interlaced h.264 content - to the extent
    that it's not possible to distinguish most MBAFF and PAFF content until
    it's too late.
    
    In an attempt to compensate for this, I'm introducing two mechanisms:
    
    1) Peeking at the picture number of the next picture
    
    The hardware provides a capability to peek the next picture number. If
    it is the same as the current picture number, then we are clearly dealing
    with two fields and not a frame or fieldpair.
    
    If this always worked, it would be all we need, but it's not guaranteed
    to work. Sometimes, the next picture may not be decoded sufficiently
    for the number to be known; alternately, a corruption in the stream may
    cause the hardware to refuse to return the number even if the next
    intact frame is decoded. In either case, the query will return 0.
    
    If we are unable to peek the next picture number, we assume that the
    picture is a frame/fieldpair and return it accordingly. If that turns
    out to be incorrect, we discard the second field, and the user has
    to live with the glitch. In testing, false detection can occur for
    the first couple of seconds, and then the pipeline stabalizes and
    we get correct detection.
    
    2) Use the h264_parser to detect when individual input fields have
    been combined into an output fieldpair.
    
    I have multiple PAFF samples where this behaviour is detected. The
    peeking mechanism described above will correctly detect that the
    output is a fieldpair, but we need to know what the input type was
    to ensure pipeline stability (only return one output frame per input
    frame).
    
    If we find ourselves with an output fieldpair, yet the input picture
    type was a field, as reported by the parser, then we are dealing with
    this case, and can make sure not to return anything on the next
    decode() call.
    
    Taken together, these allow us to remove the hard-coded hacks for
    different h.264 types, and we can clearly describe the conditions
    under which we can trust the hardware's claim that content is
    interlaced.
    Signed-off-by: 's avatarPhilip Langdale <philipl@overt.org>
    ae7a4a15
crystalhd.c 36.6 KB