[FFmpeg-devel] [PATCH] avcodec/v4l2: set sizeimage param for non-raw buffers [fixes #6716]

wm4 nfxjfg at googlemail.com
Wed Oct 4 21:49:31 EEST 2017


On Wed, 4 Oct 2017 19:03:12 +0200
Jorge Ramirez-Ortiz <jorge.ramirez-ortiz at linaro.org> wrote:

> On 10/04/2017 06:20 PM, wm4 wrote:
> >>>>>> Isn't this something that should be fixed in the driver?  
> >>>>> yes but it might take forever and I dont know how many other drivers might
> >>>>> need it.
> >>>>>        
> >>>>>> Why 2MB?  
> >>>>> no analysis done but seems to be enough to hold an encoded frame. Should it be
> >>>>> any bigger?  
> >>>> I could use the calculations below if a generic magic number is a problem:
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/qcom/venus/venc.c#n52
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/qcom/venus/vdec.c#n49
> >>>>
> >>>> please let me know  
> >>> Well, I don't think there's any reason why the frame size would be
> >>> limited to 2MB. I also can't tell if this is for uncompressed or
> >>> compressed frames. For uncompressed frames, you could easily compute a
> >>> good guess (the exact size depends on alignment and padding). For
> >>> compressed frames it's probably impossible.  
> >> yes this is for compressed frames
> >>  
> >>> If the kernel driver somehow can't be fixed and if this is a show
> >>> stopper, it's probably OK if this is done to unbreak it, but it should  
> >> I doubt the kernel driver will be fixed any time soon - I can try posting a
> >> patch there.
> >>
> >> But even then if it gets merged people using older kernels will have to back
> >> port to their kernels and it ends up being a pain for everyone. Since in this
> >> case userspace can easily take care of it - is a minor change- I think it should
> >> be merged in ffmpeg.  
> > So would it break for better drivers if a packet of over 2 MB is fed to
> > them?  
> 
> any good driver should encapsulate its own restrictions and not export them to 
> the client as it is the case on s5p-mfc - so drivers properly written will 
> ignore the sizeimage field.

Sounds good then.


More information about the ffmpeg-devel mailing list