[FFmpeg-devel] [PATCH] Enable PAFF decoding

[Michael Niedermayer]

On Fri, Oct 12, 2007 at 12:52:30PM +1000, Neil Brown wrote:
> On Friday October 12, uoti.urpala at pp1.inet.fi wrote:
> > 
> > On Fri, 2007-10-12 at 12:05 +1000, Neil Brown wrote:
> > > On Friday October 12, michaelni at gmx.at wrote:
> > > > ive not looked at the stream at all, but from what you posted these b frames
> > > > have timestamps which lay prior to the first IDR picture if that is the case
> > > > the sane solution is to drop them
> > > 
> > > In my 11 second clip there are two IDR frames.  Each is followed (in
> > > decode order) by two B frames (pairs of B fields) which should be
> > > displayed (based on picture order count) before the IDR frame.
> > > (poc numbers for fields are, in decode order, 
> > >      0, 1, -4, -3, -2, -1, 4, 5, 2, 3, ...
> > >      I  P   B   B   B   B  P  P  B  B
> > > )
> > > 
> > > If we dropped all such frames, it would be sad - even if it would be sane.
> > 
> > Is this the start of the stream or not? Usually such B frames would
> > depend on earlier frames (before -4) and so would be dropped _if_
> > decoding starts from frame 0 here, but not if we get here after decoding
> > earlier parts and have frames buffered from there.
> 
> This is the poc/type sequence both at the start of the stream and
> >from each internal IDR field (sample size = 2).
> i.e. the sequence occurs multiple times in the stream.
> 
> I cannot see anything in the spec which says anything about where
> referenced pictures should be in display order - only that P and B
> slices can reference 1 or 2 (respectively) earlier pictures in
> decoding order.
> 
> Also, as '0' is an IDR, field -4 could not possibly reference anything
> before field '0' and so must only reference fields 0 and 1.
> The spec explicitly allows negative poc numbers (section 8.2.1 sets
> the range for poc between -2^31 and 2^31-1).
> The implication of a negative poc number combined with the
> requirements that an IDR must have a poc of 0 (same section) is that
> the first negative poc must be decoded with reference only to pictures
> that are later in the display order (... unless the first negative poc
> is an I picture, which would be pointless).

yes, it seems ive mixed up h.264 with previous video standards

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071012/c86b18fa/attachment.pgp>