[Ffmpeg-devel] MPEG4 ISO Compliance (known problems)

Rahul Kumar kr.rahul
Thu May 4 12:46:38 CEST 2006


Hi,
   I had used bitstreams from the following links for testing:

Advanced Simple profile
1) http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_2004_Conformance_Testing/video_conformance/advanced_simple/

2)http://standards.iso.org/ittf/PubliclyAvailableStandards/c041935_ISO_IEC_14496-4_2004_Amd_1_2005_Cor_1_2005_Bitstreams.zip

Simple profile
http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_2004_Conformance_Testing/video_conformance/version_1/simple/

The ISO decoder can be downloded from:
http://standards.iso.org/ittf/PubliclyAvailableStandards/c039417_ISO_IEC_14496-5_2001_Amd_4_2004(E)_Reference_Software.zip

hope this helps

-regards,
rahul


Date: Fri, 28 Apr 2006 19:34:45 +0200
From: Michael Niedermayer <michaelni at gmx.at>
Subject: Re: [Ffmpeg-devel] MPEG4 ISO Compliance (known problems)
To: FFMpeg development discussions and patches
       <ffmpeg-devel at mplayerhq.hu>
Message-ID: <20060428173445.GC792 at MichaelsNB>
Content-Type: text/plain; charset=us-ascii

Hi

On Fri, Apr 28, 2006 at 11:35:24AM +0100, Rahul Kumar wrote:
> Hi everyone,
>   I have tried to compile the known deviations of MPEG-4 implemetation
> vis-a-vis ISO specification. Hopefully this will be of help to
> someone. Here is the list:
>
> 1) FFMPEG directly applies the equations of section 7.7.2.2 (of the
> standard), for a interlaced direct-mode macro-block. However since
> FFMPEG stores motion vectors as field motion vectors, (for field
> macroblocks  mv=mv/2), this prodoces erroneous result. I think the
> cleanest way to solve this problem would be to always store the motion
> vectors as frame motion-vectos, irrespective of the block-type, and
> perform adjustment for field-based macroblocks in mpeg_motion() or
> qpel_motion().
>

please provide a sample which isnt decoded correctly, IMHO ffmpeg
matches the spec


[...]

> 3) FFMPEG doesn't implment the 16x8 QPEL filtering for field macroblocks.
> Note the comments in qpel_motion
> ...............
>         //damn interlaced mode
>         //FIXME boundary mirroring is not exactly correct here
>         qpix_op[1][dxy](dest_y  , ptr_y  , linesize);
>         qpix_op[1][dxy](dest_y+8, ptr_y+8, linesize);
> ...........
>
> As specied in the comments, boundary mirroring isn't exactly correct
> in the above code.

true, this isnt correct and known, you can send a patch if you want, its not
very critical though as interlacing + qpel is rare and the filtering
is just slightly wrong


>
> 4) AMV calculation for 1 Warp-point is not correct. Further in the
> function mpeg4_decode_sprite_trajectory(), the reduction in number of
> wart-points
> (.........../* try to simplify the situation */..........) should not
> be tried, if ISO compliance is desired.

please elaborate on what you think is wrong exactly


>
> 5) FFMPEG doesn't detect stuffing bits at the end of each macroblock
> before trying to re-sync. A simple piece of code given below can help:
>             // skip any stuffing
>             if(s->pict_type==I_TYPE)
>             {
>                 // stuffing mb "000000001"
>                 while( show_bits(&s->gb, 9)==1)
>                     get_bits(&s->gb, 9);
>             }
>             else
>             {
>                 // no-skip, followed by stuffing mb "000000001"
>                 while( show_bits(&s->gb, 10)==1)
>                     get_bits(&s->gb, 10);
>             }
>            if(mpeg4_is_resync(s)){
> .............
> .......
> ..
> However this causes problems with DIVX streams!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

does the spec allow this at all? i cant see how, the macroblock bitstream
syntax drops stuffing MBs prior to MBs


>
>
> 6) Mismatch control is not implemented in dct_unquantize_mpeg2_intra_c()

fixed


>
> 7) The function mpeg4_decode_block() always compares
> "intra_dc_threshold" with the current qscale values, to ascertain
> whether the macroblock has DC coeff. However, but for the first coded
> Macro-block in a packet, it should use previous qscale value for this
> comparison.

fixed


PS: please provide sample mpeg4 bitstreams if you have any which show artiacts
due to any of these issues, its much easier to fix the code if a sample for
testing is available

[...]
--
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is



------------------------------





More information about the ffmpeg-devel mailing list