[FFmpeg-devel] Another H.264 decoding image corruption issue

[Michael Niedermayer]

On Fri, Jul 25, 2008 at 07:04:05PM +1200, Paul Kendall wrote:
> On Friday 25 July 2008 17:02:18 Craig Whitmore wrote:
> > > > into the clip "H264_artifacts_motion.h264"
> >
> > How can I get a copy of this file. Maybe its the same issue why mplayer
> > doesn't plays the New Zealand DVB-T streams  correctly ? (lots of
> > blockyness) (they look better with -vf pp=fd but really hides the
> > problem does fix it)
> >
> > (samples @ http://www.testmyspeed.co.nz/tests/  (the
> > c4-1.ts,test-3.ts,tv3-2.ts shows the problem  well)
> >
> > (most of the other files have problems with the LATM Encoded AAC Sound
> > which another NZer has written a "fix" for.
> >
> That would be me!
> 
> I have been keeping a close eye on the changes Michael has been doing recently 
> (thankyou for all your effort Michael). I have updated my MythTV patches 
> every night in the hopes that the interlacing problem is fixed, but to no 
> avail yet.
> 
> Michael,
> I have been reading the ITU H264 spec and going through the code at the same 
> time and I think the part that needs fixing (from the FIXME in h264.c line 
> 995) is the colocated block calculation which is from section 8.4.1.2.1 when 
> field_pic_flag is 1. Am I on the right track with my thinking? If so, I am 
> still hunting for the section of code where the calculation needs to take 
> place. Can you help me with this, please?

no, you will have to follow your hypothesis yourself.


> 
> Another thing that may be helpful for others reading the code is comments with 
> specification section numbers! Perhaps as I start to understand it I will 
> create a patch with comments which contains section numbers.

cleanup patches are welcome, If section references are welcome, that iam not
sure. There surely are places where comments refering to the spec make sense
And there are many where they do not.

Either way ALWAYS use section names NEVER numbers. Numbers change, the small
number of section numbers currently in h264.c does no longer match the
apparently intended sections. (so assuming they did in the past, the nums must
have changed)

Also keep in mind h264.c is not a litteral sentance by sentance implementation
of the spec. At least not the parts that work. They are rather equivalent
processes producing the same result for the same input as the process written
in the spec.

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- 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/20080725/862b41ff/attachment.pgp>