-
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: Philip Langdale <philipl@overt.org>
ae7a4a15