On 26/03/18 02:25, Jun Zhao wrote:
> V2: simplified the logic as Michael's review.
> 
> From 6c332c65d64977c4d6220acfb7e9db3505281f87 Mon Sep 17 00:00:00 2001
> From: Jun Zhao <mypopy...@gmail.com>
> Date: Wed, 14 Mar 2018 16:13:39 +0800
> Subject: [PATCH V2] ffmpeg_filter: enable stream_loop in HWAccel transcoding.
> 
> use the cmd: ffmpeg -y -stream_loop 1 -hwaccel vaapi -hwaccel_device
> /dev/dri/renderD128 -hwaccel_output_format vaapi -i
> input.mp4 -c:v h264_vaapi output.mp4 can get the error like:
> 
> Error while decoding stream #0:1: Invalid data found when processing
> input
> Impossible to convert between the formats supported by the filter
> 'Parsed_null_0' and the filter 'auto_scaler_0'
> Error reinitializing filters!
> Failed to inject frame into filter network: Function not implemented
> 
> the root cause is can't insert software scale filter in the hwaccel
> transcoding pipeline.
> 
> Signed-off-by: Jun Zhao <mypopy...@gmail.com>
> ---
>  fftools/ffmpeg_filter.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 877fd670e6..4e5d8fa24e 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -452,6 +452,7 @@ static int configure_output_video_filter(FilterGraph *fg, 
> OutputFilter *ofilter,
>      int pad_idx = out->pad_idx;
>      int ret;
>      char name[255];
> +    const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(ofilter->format);
>  
>      snprintf(name, sizeof(name), "out_%d_%d", ost->file_index, ost->index);
>      ret = avfilter_graph_create_filter(&ofilter->filter,
> @@ -461,7 +462,8 @@ static int configure_output_video_filter(FilterGraph *fg, 
> OutputFilter *ofilter,
>      if (ret < 0)
>          return ret;
>  
> -    if (ofilter->width || ofilter->height) {
> +    if ((ofilter->width || ofilter->height) &&
> +        (!desc || !(desc->flags & AV_PIX_FMT_FLAG_HWACCEL))) {
>          char args[255];
>          AVFilterContext *filter;
>          AVDictionaryEntry *e = NULL;
> -- 
> 2.14.1
> 

This is doing something kindof subtle, in that this check was previously 
blocking changes to the hw_frames_ctx input to the encoder.  While that works 
in some cases, it is pretty clearly documented that it isn't allowed by the 
API.  Do all existing encoders work ok with that, such that the restriction 
might be relaxed?  It's not obvious to me that QSV will work at all (though I 
haven't actually checked), and others might do something nasty if any property 
changes because they don't currently expect it.

- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to