[Ffmpeg-devel] Mpeg-4 playback: issues with CBR padding

[Itay Chamiel]

Hello,
 
I have stumbled into a case where an MPEG4 file is perfectly watchable
using Quicktime Player or Mpegable, but is broken under VideoLAN and
Mplayer, with complaints by ffmpeg.
 
I have uploaded it into upload.mplayerhq.hu/MPlayer/incoming/itayc . It
is named "out.mp4" and is about 5MB in size. The video was encoded by
the Prodys Mpeg-4 encoder running on a TI C64 DSP, and the result was
encapsulated into MP4 format by the mp4creator program from the mpeg4ip
package.
 
Normally, such a file plays well under anything, including ffmpeg based
players. However, there is one case which breaks ffmpeg, and not other
decoders: if the encoding is set to CBR at a high bitrate, so high that
even at the highest quality setting the encoder has no choice but to pad
the frames so they'll be large enough to fulfill the bitrate
requirements. In this example, I encoded the Foreman 352x288 clip at 4
Mbit, which is overkill and therefore most frames are padded. VideoLAN
fails to decode most of it, with messages like:
 
ffmpeg warning: header damaged
(mpeg4 at 00AF6360)
ffmpeg warning: cannot decode one frame (6899 bytes)
ffmpeg warning: slice end not reached but screenspace end (21511 left
004010, score= -52)
(mpeg4 at 00AF6360)
ffmpeg debug: concealing 396 DC, 396 AC, 396 MV errors
(mpeg4 at 00AF6360)
ffmpeg warning: header damaged
(mpeg4 at 00AF6360)

...and so on. I assume ffmpeg is supposed to be able to deal with this
padding, but perhaps the padding created by this particular encoder is
different in some way from other encoders.

I do understand that I'm supposed to get the latest SVN version before
posting here, but I hope the group will bear with me, as compiling
VideoLAN is no simple feat and I was hoping I could avoid it...

Anyway, the question is: Is this a problem with ffmpeg or with the
encoder?

Thanks,

-itay
--
Itay Chamiel
Software Engineer
Mango DSP
itayc <at> mangodsp.com