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

[Michael Niedermayer]

Hi

On Mon, May 08, 2006 at 10:46:25AM +0100, Rahul Kumar wrote:
> Hi,
>   My apologies for not keeping a detailed record (specially of the
> ASP bitstreams). However here are the SP-streams which were
> problematic:

[...]

> 3. jvc013.m4v 
[...]
> 6. san014.m4v

un-initialised dc-pred dir issue (fixed h263.c 1.302, 2006/03/10 18:40:41)


> 
> (base path: 
> http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_2004_Conformance_Testing/video_conformance/version_1/simple/)
> 
> Of the above the following streams
> 1. hit012.m4v	(352x288)
> 2. mit005.m4v	(352x288)
>            had skipped frames.
> Skipped frames are not handled by:
> ff_h263_decode_frame()
> {....
>    if(ret==FRAME_SKIPED)
>        return get_consumed_bytes(s, buf_size);
> }
> 
> However in case it is handled by top level wrapper then this code is
> OK. (FYI: I used a different wrapper to drive libavcodec). Note that
> the above "issue(?)" is not included in my earlier bug-report.

i dont consider not outputing identical frames a bug though i agree that
strictly its not conformat but why should the decoder output identical frames
it makes no sense, the last frame will be displayed until a new one arrives
anyway ...


> 
> Also as far as I remember mit025.m4v had the problem with stuffing
> bits and 

h263.c now contains some outcommenetd code to deal with that, i
have doubts that mit025.m4v is a valid mpeg4 stream though ...


> hit006.m4v had problem with un-initialised dc-pred dir
> (another problem which I had reported earlier but forgot to include in
> my final compilation of errors).

should be fixed in h263.c 1.302

[...]
-- 
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