Bug 1771

The problem is that I cannot say if the said patch is backward compatible with the version of ffmpeg we have in F-15 (aka from  the oldabi branch), so we cannot support this.
If you need a newer xine-lib version, please get in touch with the xine-lib maintainer at rpmfusion.

At least for F-15, a newer updated package is in progress, ffmpeg-0.7-0.1-rc1 should hit rpmfusion-free-updates-testing soon.

Please re-open the bug if you can reproduce the problem with this version and curren xine-lib in Fedora/RPM Fusion
That been said, h264 playback works fine with others frameworks.

Thx for your report.

I have upgraded to the following packages:

xine-lib-1.1.19-6.fc15.i686
xine-lib-extras-freeworld-1.1.19-1.fc14.i686
ffmpeg-libs-0.7-0.3.20110612git.fc15.i686

and playing the same movie trailer still gives me a constant stream of errors on my console:

[h264 @ 0xac558bc0] AVC: nal size 1081873426
[h264 @ 0xac558bc0] no frame!
[h264 @ 0xac5593a0] AVC: nal size 1099422463
[h264 @ 0xac5593a0] no frame!
[h264 @ 0xac558bc0] AVC: nal size -58973994
[h264 @ 0xac558bc0] no frame!
[h264 @ 0xac5593a0] AVC: nal size 489156271
[h264 @ 0xac5593a0] no frame!
[h264 @ 0xac558bc0] AVC: nal size 683902322
[h264 @ 0xac558bc0] no frame!
[h264 @ 0xac5593a0] AVC: nal size 620896079
[h264 @ 0xac5593a0] no frame!
[h264 @ 0xac558bc0] AVC: nal size -1113112523
[h264 @ 0xac558bc0] no frame!
[h264 @ 0xac5593a0] AVC: nal size 255406545
[h264 @ 0xac5593a0] no frame!

These presumably result in dropped frames, because xine soon starts to complain that my system is too slow for this trailer.

Switching to ffmpeg-0.6.3 from F14 (recompiled for F15) fixes the problem. The only message I get on my console with 0.6.3 is:

[h264 @ 0xb1a00dc0]Cannot parallelize deblocking type 1, decoding such frames in sequential order

(In reply to comment #2)

> [h264 @ 0xb1a00dc0]Cannot parallelize deblocking type 1, decoding such frames
> in sequential order

Which CPU do you have actually ?

(In reply to comment #3)
> Which CPU do you have actually ?

Dual P4 2.66 GHz Xeons (with HT enabled). It's not a new machine, but it does play this H.264 trailer at 1280x544.

I suppose it's also possible that the bug is in xine-lib instead of ffmpeg.

Created attachment 673 [details]
First few seconds of movie trailer.

This is enough of the .mov file to reproduce the problem.

With FFmpeg-0.7.3 (ffplay), I'm getting a lot of these:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5d100013c0] stream 1, offset 0x6984e: partial file

Could you provide a link to the full file?

(In reply to comment #6)
> Could you provide a link to the full file?

I believe the following command will download it for you:

$ wget -U Quicktime/7.6.2 http://trailers.apple.com/movies/fox/xmenfirstclass/xmenfirstclass-tlr2_h720p.mov

Note that you do need to pretend to be using Quicktime...

Thanks for the link. I see no issues when playing the full trailer using ffplay from ffmpeg-0.7.3 release. I'm working on an update for F-15, so this should be fixed soon. If the issue still persists then, then it's a bug in xine-lib.

(In reply to comment #8)
> If the issue still persists then, then it's a bug in xine-lib.

Personally, I am suspecting xine-lib more and more, but you can already verify this trivially by installing the xine-ui RPM and using it to watch the trailer.

Is there a document anywhere which describes the ffmpeg API changes between 0.6 and 0.7, please? There weren't many changes made to xine-lib's ffmpeg video decoder; presumably the intention was to translate rather than to change any behaviour.

(In reply to comment #9)
> (In reply to comment #8)
> > If the issue still persists then, then it's a bug in xine-lib.
> 
> Personally, I am suspecting xine-lib more and more, but you can already verify
> this trivially by installing the xine-ui RPM and using it to watch the trailer.
> 
> Is there a document anywhere which describes the ffmpeg API changes between 0.6
> and 0.7, please? There weren't many changes made to xine-lib's ffmpeg video
> decoder; presumably the intention was to translate rather than to change any
> behaviour.
> 

Frankly, F-14 xine seems to work just fine for me. I don't have a machine with F-15 at the moment. I'll test later.

(In reply to comment #10)
> Frankly, F-14 xine seems to work just fine for me.

Well, yes. Like I said originally, I fixed the problem in F15 by taking the ffmpeg-0.6.3-1.fc14.src.rpm package and rebuilding it.

(In reply to comment #10)
> Frankly, F-14 xine seems to work just fine for me. 

Heh, I should mention that my $HOME/.xine/config file contains the following setting:

# FFmpeg video decoding thread count
# numeric, default: 1
video.processing.ffmpeg_thread_count:2

Not unreasonable, I thought, on a PC with 2 physical, hyper-threaded 2.66GHz P4 Xeon CPUs.

Revert the ffmpeg_thread_count to 1 and all the errors disappear. This setting triggers the following code in xine's decoder:

  if (this->class->thread_count > 1) {
    if (this->codec->id != CODEC_ID_SVQ3
        && avcodec_thread_init(this->context, this->class->thread_count) != -1)
      this->context->thread_count = this->class->thread_count;
  }

> Heh, I should mention that my $HOME/.xine/config file contains the following
> setting:
> 
> # FFmpeg video decoding thread count
> # numeric, default: 1
> video.processing.ffmpeg_thread_count:2

So to be clear: ffmpeg 0.6.3 works fine with this setting, but ffmpeg 0.7 chokes instead. Ouch. I don't think this is a xine bug.

(In reply to comment #13)
> So to be clear: ffmpeg 0.6.3 works fine with this setting, but ffmpeg 0.7
> chokes instead. Ouch. I don't think this is a xine bug.

ffplay -threads 2 works fine for me with that trailer. So I guess it's fixed in 0.7.3.

(In reply to comment #14)
> ffplay -threads 2 works fine for me with that trailer. So I guess it's fixed in
> 0.7.3.

The problem is not fixed, it's actually a bug in xine-lib after all. Specifically, xine-lib 1.1.19's FFmpeg decoder plugin needs the following patch to be included before multi-threaded video decoding will work again:

http://sourceforge.net/mailarchive/message.php?msg_id=27998734

(In reply to comment #15)
> Specifically, xine-lib 1.1.19's FFmpeg decoder plugin needs the following patch
> to be included before multi-threaded video decoding will work again:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=27998734

This patch has now been included in the upstream xine-lib repository for 1.1.19.

I expect the problem to be fixed with current release.