linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] H.263 bitstream syntax error ; an FFMPEG probl


From: Francois-Xavier KOWALSKI
Subject: Re: [Linphone-developers] H.263 bitstream syntax error ; an FFMPEG problem?
Date: Tue, 07 Mar 2006 10:33:36 +0100
User-agent: Thunderbird 1.5 (X11/20051201)

Comments inlined below.

Simon Morlat wrote:

Hello,

I had a look at ffmpeg code and here's what I saw.

When UFEP=1, ffmpeg considers that there is an optional PLUS PTYPE bitfield.


This is correct, according to the H.263 specification. The presence of PLUSPTYPE indicates exactly that the bitstream is H.263+ or H.263++.

PLUSPTYPE consists in an optional part (OPPTYPE) and a mandatory part (MPPTYPE).

The 2 values allowed for UFEP are 0 (no PLUSPTYPE) and 1 (PLUSPTYPE present).

Here is an extract of the h263_decode_pict_header():

[...]

Maybe UFEP=1 is not in H283+ baseline ?


Correct. For example, the custom source format is allowed only when PLUSPTYPE.

The H263 encoding function behaves like this :

int ufep=1;

/* H.263v2 */

/* H.263 Plus PTYPE */

put_bits(&s->pb, 3, 7);

put_bits(&s->pb,3,ufep); /* Update Full Extended PTYPE */

if (format == 7)

put_bits(&s->pb,3,6); /* Custom Source Format */

else

put_bits(&s->pb, 3, format);

put_bits(&s->pb,1, s->custom_pcf);

put_bits(&s->pb,1, s->umvplus); /* Unrestricted Motion Vector */

put_bits(&s->pb,1,0); /* SAC: off */

put_bits(&s->pb,1,s->obmc); /* Advanced Prediction Mode */

put_bits(&s->pb,1,s->h263_aic); /* Advanced Intra Coding */

put_bits(&s->pb,1,s->loop_filter); /* Deblocking Filter */

put_bits(&s->pb,1,s->h263_slice_structured); /* Slice Structured */

put_bits(&s->pb,1,0); /* Reference Picture Selection: off */

put_bits(&s->pb,1,0); /* Independent Segment Decoding: off */

put_bits(&s->pb,1,s->alt_inter_vlc); /* Alternative Inter VLC */

put_bits(&s->pb,1,s->modified_quant); /* Modified Quantization: */

put_bits(&s->pb,1,1); /* "1" to prevent start code emulation */

put_bits(&s->pb,3,0); /* Reserved */

put_bits(&s->pb, 3, s->pict_type == P_TYPE);

put_bits(&s->pb,1,0); /* Reference Picture Resampling: off */

put_bits(&s->pb,1,0); /* Reduced-Resolution Update: off */

put_bits(&s->pb,1,s->no_rounding); /* Rounding Type */

put_bits(&s->pb,2,0); /* Reserved */

put_bits(&s->pb,1,1); /* "1" to prevent start code emulation */


The problem is here (in MPPTYPE): these 3 bits are supposed to be 001, but the outcome does not seem to be Ok (it is 101). Look at the analysis of the stream:

----------H.263+ : MANDATORY PLUS PTYPE----------
pict_type: 000(0)
reference_picture_resampling_mode: 0(0)
reduced_resolution_update_mode: 0(0)
rounding_type: 0(0)
rtype: 0(0)
reserve, reserve, spare: 101(5) <= should be 001(1)
The spec says:

> – Bit 6 Rounding Type (RTYPE) (see 6.1.2);

> *– Bit 7 Reserved, shall be equal to "0";

> – Bit 8 Reserved, shall be equal to "0";

> – Bit 9 Equal to "1" to prevent start code emulation.*


What is really puzzling is that the green code above seems to be correct...

A+
-- 
Francois-Xavier "FiX" KOWALSKI     /_ __  Tel:+33 (0)4 76 14 63 27
OpenCall Business Unit -- OCBU    / //_/  Fax:+33 (0)4 76 14 51 62
Media-Processing Engineering        /     http://www.hp.com/go/opencall
                               i n v e n t

reply via email to

[Prev in Thread] Current Thread [Next in Thread]