> -----Ursprüngliche Nachricht----- > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag > von Hendrik Leppkes > Gesendet: Donnerstag, 22. Oktober 2015 17:56 > An: FFmpeg development discussions and patches > Betreff: Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session > control and internal allocation > > On Wed, Oct 14, 2015 at 11:47 AM, Hendrik Leppkes <h.lepp...@gmail.com> > wrote: > > On Wed, Oct 7, 2015 at 7:07 PM, Ivan Uskov <ivan.us...@nablet.com> > wrote: > >> Hello wm4, > >> > >> Wednesday, October 7, 2015, 7:40:45 PM, you wrote: > >> > >> w> There's no automagic way to get this done. > >> > >> w> Hardware accelerators like vaapi and vdpau need the same thing. > >> w> These have special APIs to set an API context on the decoder. > Some > >> w> APIs use hwaccel_context, vdpau uses av_vdpau_bind_context(). > >> > >> w> The hwaccel_context pointer is untyped (just a void*), and what > it > >> w> means is implicit to the hwaccel or the decoder that is used. It > >> w> could point to some sort of qsv state, which will have to be > >> w> explicitly allocated and set by the API user (which might be > ffmpeg.c). > >> So if I will implement something like ffmpeg_qsv.c (using > ffmpeg_vdpau.c as > >> example) and extend the hwaccels[] into ffmpeg_opt.c by > corresponded > >> qsv entries it would be the acceptable solution, correct? > >> > >> w> For filters there is no such thing yet. New API would have to be > >> w> created. For filters in particular, we will have to make sure > that > >> w> the API isn't overly qsv-specific, and that it is extendable to > >> w> other APIs (like for example vaapi or vdpau). > >> Ok, if VPP could be the issue I would like to get > working direct > >> link qsv_decoder-qsv_encoder first. > >> > > > > Libav has a patch that does exactly this, allow direct QSV->QSV > > transcoding with help of some utility code in ffmpeg.c/avconv.c You > > might want to look at that instead of re-inventing it. That'll help > > make everyones live easier, as I'll just merge it when the time > comes, > > and the codebases don't diverge too drastically. > > > > This functionality has been merged now. It works for some samples. > You can try to use it with a command line like this: > > ffmpeg -hwaccel qsv -c:v h264_qsv -i h264.ts -c:v h264_qsv output.mkv > > This will transcode using a QSV->QSV pipeline, no copying to system > memory, and about 2.5x faster on my IVB laptop. > > However, its broken on a lot of more complex H264 files, you'll get > errors like get_buffer() failed - this is because our qsvdec behaves > rather strangely, and instead of buffering input data when needed, it > buffers output surfaces, which is not ideal, since it bloats up the > memory usage an the number of surfaces required explodes into infinity. > I know how to fix it - just restore the decoder to the same buffering > model as it originally used, buffer input data instead of output > surfaces. Unless someone else wants to fix it, I'll simply do it in the > next week or so.
Hi Henrik, Let me know if you need help to fix that, sounds like a good chance to learn more about the workflow. But, this could also result in extra work to double check my code. So, what do you think ? Best, Sven > > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
