[MPlayer-dev-eng] direct rendering disabled for lavc h264

elupus elupus at ecce.se
Thu Jul 20 04:19:07 CEST 2006


Hi, 

Question.. Why is direct rendering (dr1) disabled when using lavc's h264
codec? I tried the change below, wich didn't help all that much. 

Index: vd_ffmpeg.c
===================================================================
--- vd_ffmpeg.c	(revision 19147)
+++ vd_ffmpeg.c	(working copy)
@@ -195,7 +195,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 &&
lavc_codec->id != CODEC_ID_H264)
+    if(lavc_codec->capabilities&CODEC_CAP_DR1 && !do_vis_debug)
 	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;



Then i got a "DR1 failure". Wich would indicate that lavc isn't supplying
buffer hint's or something is odd about the frametype counts, according to
the code below.

  if (!pic->buffer_hints) {
    if(ctx->b_count>1 || ctx->ip_count>2){
        mp_msg(MSGT_DECVIDEO, MSGL_WARN, MSGTR_MPCODECS_DRIFailure);


Here a go through all the work of finally setting up a fully working direct
rendering vo for the xbox, and i stumble on the most resource intensive
codec, typical :). Need every spare cpu power on the xbox to handle that
stuff. Since that check has been there for quite some time, i had hope it
had been solved in lavc. Seems odd to make that decicion there, shouldn't
that be handled by lavc itself?

On another DR note, is there any way the VO is notified of that a
MP_IMGFLAG_PRESERVE buffer need not be preserved anymore. Is that flag
cleared on draw_image perhaps? My problem is that i'm forced to always reuse
the exact same buffer (checked by the priv property of the mpi structure)
for any call to get_image where preserve is set. This shouln't be needed
after a reference frame has no outstanding references anymore. 


/Joakim





More information about the MPlayer-dev-eng mailing list