On Mon, Aug 02, 2010 at 12:54:48AM +0200, Reinhard Nissl wrote:

Hi,

according to the specs, sei_ct_type values 0 and 2 are likely to indicate a progressive frame while 1 indicates an interlaced frame. So it looks to me like a typo, that the wrong bit is tested to derive interlaced_frame. Please see attached patch for a possible fix.

Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de

h264.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 4f3b4271f60bd5b6479bd051eac0dabd6451c29f h264_ct_type.diff Index: h264.c =================================================================== --- h264.c (revision 24643) +++ h264.c (working copy) @@ -3063,7 +3063,7 @@ }

if ((h->sei_ct_type & 3) && h->sei_pic_struct <= SEI_PIC_STRUCT_BOTTOM_TOP) - cur->interlaced_frame = (h->sei_ct_type & (1<<1)) != 0; + cur->interlaced_frame = (h->sei_ct_type & (1<<0)) != 0;

you possibly missed how the field is initialized h->sei_ct_type |= 1<<get_bits(&s->gb, 2); [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle