In preparation for adding additional fields to the node, return
the node instead of the pts value. This requires the caller to
free the node.
Signed-off-by: Philip Langdale <philipl@overt.org>
I found another MBAFF sample where the input:output pattern is
the same as mpeg2 and vc1 (fieldpair input, individual field output).
While I'm not sure how you can output individual fields from MBAFF,
if I apply the mpeg2/vc1 handling to this file, it plays correctly.
So, this changes the detection algorithm to handle the known cases.
Whitespace will be fixed in a separate change.
Signed-off-by: Philip Langdale <philipl@overt.org>
As previously discussed, the CrystalHD hardware treats some PAFF
clips different from others; even when input fields are always in
separate packets, the hardware might return a single fieldpair for
one clip and individual fields for another.
Given the bogus flags set by the hardware, it is impossible to
distinguish these two cases without knowing about the current
picture and the next one. The hardware can usually provide the
picture number of the next picture and when that is available,
we can detect the two cases.
When it is not available, we have to guess - and find out later
if we were right or wrong.
With this change, clips will play correctly unless they are PAFF
where individual fields are returned *and* no next picture number
is available. Generally speaking, the incorrect cases arise in
the first couple of seconds of a clip as the delay calibration takes
place. Once that's set, things work fine.
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 MBAFF and PAFF content until
it's too late.
This change introduces use of the h264_parser to help bridge the
gap; it can indicate if the input data is PAFF fields or not.
With this clarity, some of heuristics can be removed from the code,
making this less convoluted.
Finally, I found an MBAFF clip that acts like non h.264 content so
I had to make allowances for that.
Note that I still cannot distinguish between two forms of PAFF,
where the hardware either returns individual fields or a field-pair.
It's not clear that there's even a spec relevant difference between
the two forms, as opposed to hardware ideosyncracies.
The Broadcom CrystalHD decoder chips provide hardware video
decoding for a number of video formats. It does so using a
memory:memory interface where a compressed bitstream is fed
in and decompressed pictures are copied out. As such, it works
independent of any graphics hardware in the system.
Features supported in this initial version:
* Support for Linux (using current drivers/library from git.wilsonet.com)
* Support for 70015 hardware
* Formats: MPEG2, MPEG4 Part 2, H.264, VC1 and DivX 3.11 (untested)
* Progressive content
* Non-H.264 Interlaced content
* H.264 MBAFF content
Features missing in this initial version:
* Support for OSX (might work - untested)
* Support for Windows
* Support for 70012 hardware
* H.264 PAFF content
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Philip Langdale