[MPlayer-dev-eng] [Patch, MacOSX] mplayer H.264 playback

admin major4 at mac.com
Tue Sep 7 01:58:23 CEST 2004


Hello,

In case it had not reached this list, please consider for commit the 
following patch posted by Michael on ffmpeg-devel which fixed a bug 
preventing mplayer H.264 playback on Mac OSX.

Thank you

----->

From: Michael Niedermayer <michaelni at gmx.at>
To: ffmpeg-devel at lists.sourceforge.net
Subject: Re: [Ffmpeg-devel] [BUG, MacOSX] H264 playback
Reply-To: ffmpeg-devel at lists.sourceforge.net

--Boundary-00=_gdNOBZYnX3SQKJc
Content-Type: text/plain;
   charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi

> mencoder CVS (with recent h264 patches) with x264 rev 46 on Mac OSX
> 10.3 (big endian, 7450 altivec) correctly encodes H.264 streams (though
> the AVI format is a little awkward for h.264.. it would be nice to add
> support for libavformat muxers in mencoder, or at least mp4).
>
> However, the encoded streams, while perfectly playable on other systems
> (tested by Loren Merritt), are not playable on Mac OSX with mplayer &
> libavcodec of Sep 2, 2004. The issues mostly arise when the image size
> is DVD size (720x576). The image is almost entirely replaced by solid
> gray, and mplayer repeatedly outputs the following errors:
>
> DR1 failure   0.1 A-V:  0.179 ct:  0.008    3/  3   0%  0%  0.0% 2 0 0%
> [h264 @ 0x5ab500]get_buffer() failed (stride changed)
> [h264 @ 0x5ab500]illegal short term buffer state detected
> *** [vo] Exporting mp_image_t, 720x576x12bpp YUV planar, 622080 bytes
> [h264 @ 0x5ab500]get_buffer() failed (stride changed)%  0%  0.0% 3 0 0%
> [h264 @ 0x5ab500]illegal short term buffer state detected
> [h264 @ 0x5ab500]get_buffer() failed (stride changed)%  0%  0.0% 4 0 0%
> [h264 @ 0x5ab500]illegal short term buffer state detected
>
> Using -lavdopts vismv=2 the image is perfectly normal (apart from a
> thin gray band at the bottom of the screen) but performances are highly
> affected.
does the attached patch fix this?
if not, does ffplay work?

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();  (violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent 
#5,905,535)
buf[i]= qp - buf[i-1];    (violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & 
http://petition.ffii.org/eubsa/en

--Boundary-00=_gdNOBZYnX3SQKJc
Content-Type: text/x-diff;
   charset="iso-8859-1";
   name="patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="patch"

Index: vd_ffmpeg.c
===================================================================
RCS file: /cvsroot/mplayer/main/libmpcodecs/vd_ffmpeg.c,v
retrieving revision 1.131
diff -u -r1.131 vd_ffmpeg.c
--- vd_ffmpeg.c	2 Sep 2004 16:52:13 -0000	1.131
+++ vd_ffmpeg.c	3 Sep 2004 20:40:48 -0000
@@ -188,7 +188,7 @@
      if(vd_use_slices && 
(lavc_codec->capabilities&CODEC_CAP_DRAW_HORIZ_BAND) && !do_vis_debug)
  	ctx->do_slices=1;

-    if(lavc_codec->capabilities&CODEC_CAP_DR1 && !do_vis_debug)
+    if(lavc_codec->capabilities&CODEC_CAP_DR1 && !do_vis_debug && 
lavc_codec->id != CODEC_ID_H264)
  	ctx->do_dr1=1;
      ctx->b_age= ctx->ip_age[0]= ctx->ip_age[1]= 256*256*256*64;
      ctx->ip_count= ctx->b_count= 0;

--Boundary-00=_gdNOBZYnX3SQKJc--


--__--__--

Yes, the patch fixed the issue. Thank you




More information about the MPlayer-dev-eng mailing list