'packed b-frame' support?
Philip Langdale
It seems fairly common to come across an xvid avi that uses b-frames
and where the weird 'packing' mechanism
has been used. ffmpeg has warning output and this is generally
considered horribly abusive of the format.
Now, I'd have sworn up and down that I tried files like this before
and they played correctly but now they
definitely don't. Was I imagining it? I can't think of how any of the
timestamp handling code I've written should
care. I assume that if the hardware freaks out when confronted with
such a bitstream (wouldn't be surprised)
that could lead to jerky out of sync video (frames decoded in wrong
order?). Does the hardware actually
support these bitstreams?
--phil
Philip Langdale
but it appears to work at the most fundamental level, but something goes
wrong in the end.
When I look at the output of the hardware, what I notice is that even though I
timestamped all input packets, I see a frame come out with a timestamp of 0.
Clearly, this is the second packed frame - so it seems like everything's ok - it
understands the packing and outputs all the frames.
Similarly on the input side, I see the application feed in the N-VOPs
(7 byte input
packets), so we seem to be balanced, with 1 VOP for every output
frame. Nevertheless,
it plays back the video too slowly and I struggle to understand why.
I'm assuming it's not in how mplayer handles the pts because it does
that completely
on its own (including reordering, which seems like asking for trouble)
and the software
decoded files playback correctly.
--phil
Philip Langdale
Got packed b-frames working after studying the output carefully.
Firstly, note that
the packed pair of frames is made up of a P-VOP (the future frame), followed by
a B-VOP. The packed-pair may then be followed by another B-VOP, and then the
N-VOP. To keep everything lined up, the decoded P-VOP should be returned as the
decoded output corresponding to the N-VOP.
What I see happen is the hardware spontaneously returns the P-VOP after the two
B-VOPs (this is the frame with timestamp 0) and then returns it again
in response to
the N-VOP (I get a frame with the input timestamp I assigned to the N-VOP).
So, we're showing that frame twice, and given that about 25% of our
frames are these
kinds of P-VOPs, we end up with a noticeable slow-motion effect.
I can work around this by dropping any output frame with timestamp of
0 (as I synthesize
the timestamps passed to libcrystalhd, I can guarantee that 0 will
never appear for a
legitimate reason).
it would obviously be great if this wasn't necessary, and either the
hardware would ignore
the N-VOP or only return the P-VOP frame in response to the N-VOP. I'd
prefer the second
option as we won't get the weird timestamp behaviour in that case.
--phil
Scott D. Davilla
Humm that looks very much like what VideoToolBox is doing on me with
some xvid avi. Almost exact behavior. Very odd.
Philip Langdale
>
> Humm that looks very much like what VideoToolBox is doing on me with some
> xvid avi. Almost exact behavior. Very odd.
That is weird. I assume it's using ffmpeg on the backend and the
software decoder
doesn't have this problem.
--phil
Scott D. Davilla
Correct. ffmpeg for demux and VideoToolBox for decode. With ffmepg
for demux/decode it's fine.
Philip Langdale
Maybe there's a crystal hd in the server :-)
---phil
> Correct. ffmpeg for demux and VideoToolBox for decode. With ffmepg for demux/decode it's fine.
>
>
> --
> To post to this group, send email to
> crystalhd-...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/crystalhd-development?hl=en