[FFmpeg-devel] [RFC]Nvidia VDPAU patches

Michael Niedermayer michaelni
Thu Nov 20 13:32:25 CET 2008


On Mon, Nov 17, 2008 at 01:42:40PM +0100, Carl Eugen Hoyos wrote:
> Michael Niedermayer schrieb:
> 
> [...]
> > These comments are a little low on usefull info per byte
> 
> I tried to make them shorter.
> 

> > also why are things split by profile?
> 
> ftp://download.nvidia.com/XFree86/vdpau/include/vdpau/vdpau.h
> differentiates between them and offers a function to test if a concrete
> profile is supported.

does fallback to normal SW h264 work when its not supported? if not what is
the point of all this?


[...]
> @@ -7660,6 +7712,12 @@
>          s->current_picture_ptr->qscale_type= FF_QSCALE_TYPE_H264;
>          s->current_picture_ptr->pict_type= s->pict_type;
>  
> +#ifdef HAVE_VDPAU
> +        if (avctx->vdpau_acceleration) {
> +            ff_VDPAU_h264_set_reference_frames(h);
> +        }
> +#endif

using if(ENABLE_...) syntax should be cleaner than ifdef


[...]
> +        render->info.mpeg.intra_quantizer_matrix[i] =  s->intra_matrix[i];
> +        render->info.mpeg.non_intra_quantizer_matrix[i] = s->inter_matrix[i];
> +    }
> +

> +    render->info.mpeg.forward_reference = VDP_INVALID_HANDLE;
> +    render->info.mpeg.backward_reference = VDP_INVALID_HANDLE;

vertical align


> +
> +    switch(s->pict_type){
> +    case  FF_I_TYPE:
> +        return 0; // no prediction from other frames
> +    case  FF_B_TYPE:
> +        next = (vdpau_render_state_t*)s->next_picture.data[2];
> +        assert(next);
> +        render->info.mpeg.backward_reference = next->surface;
> +        // no return here, going to set forward prediction
> +    case  FF_P_TYPE:
> +        last = (vdpau_render_state_t*)s->last_picture.data[2];
> +        if (last == NULL) { // FIXME: Does this test make sense?
> +            last = render; // predict second field from the first
> +        }
> +        render->info.mpeg.forward_reference = last->surface;
> +        return 0;
> +    }

is there a problem with always setting them? would avoid the switch ...


[...]
> +    render->info.h264.is_reference = s->current_picture_ptr->reference ? VDP_TRUE : VDP_FALSE;
> +    render->info.h264.frame_num = h->frame_num;
> +    render->info.h264.field_pic_flag = (s->picture_structure != PICT_FRAME) ? 1 : 0;
> +    render->info.h264.bottom_field_flag = (s->picture_structure == PICT_BOTTOM_FIELD) ? 1 : 0;
> +    render->info.h264.num_ref_frames = h->sps.ref_frame_count;
> +    render->info.h264.mb_adaptive_frame_field_flag = h->sps.mb_aff;
> +    render->info.h264.constrained_intra_pred_flag = h->pps.constrained_intra_pred;
> +    render->info.h264.weighted_pred_flag = h->pps.weighted_pred;
> +    render->info.h264.weighted_bipred_idc = h->pps.weighted_bipred_idc;
> +    render->info.h264.frame_mbs_only_flag = h->sps.frame_mbs_only_flag;
> +    render->info.h264.transform_8x8_mode_flag = h->pps.transform_8x8_mode;
> +    render->info.h264.chroma_qp_index_offset = h->pps.chroma_qp_index_offset[0];
> +    render->info.h264.second_chroma_qp_index_offset = h->pps.chroma_qp_index_offset[1];
> +    render->info.h264.pic_init_qp_minus26 = h->pps.init_qp - 26;
> +    render->info.h264.num_ref_idx_l0_active_minus1 = h->pps.ref_count[0] - 1;
> +    render->info.h264.num_ref_idx_l1_active_minus1 = h->pps.ref_count[1] - 1;
> +    render->info.h264.log2_max_frame_num_minus4 = h->sps.log2_max_frame_num - 4;
> +    render->info.h264.pic_order_cnt_type = h->sps.poc_type;
> +    render->info.h264.log2_max_pic_order_cnt_lsb_minus4 = h->sps.log2_max_poc_lsb - 4;
> +    render->info.h264.delta_pic_order_always_zero_flag = h->sps.delta_pic_order_always_zero_flag;
> +    render->info.h264.direct_8x8_inference_flag = h->sps.direct_8x8_inference_flag;
> +    render->info.h264.entropy_coding_mode_flag = h->pps.cabac;
> +    render->info.h264.pic_order_present_flag = h->pps.pic_order_present;
> +    render->info.h264.deblocking_filter_control_present_flag = h->pps.deblocking_filter_parameters_present;
> +    render->info.h264.redundant_pic_cnt_present_flag = h->pps.redundant_pic_cnt_present;

vertical align


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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/20081120/1de6e6be/attachment.pgp>



More information about the ffmpeg-devel mailing list