[FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.

[Michael Niedermayer]

On Thu, Jul 23, 2015 at 06:59:54PM +0300, Ivan Uskov wrote:
> Hello Michael,
> 
> Thursday, July 23, 2015, 6:29:13 PM, you wrote:
> 
> >> +        } else {
> >> +            bs.Data       = avpkt->data;
> >> +            bs.DataLength = avpkt->size;
> >> +        }
> 
> MN> Does this mean that each packet will be memcpy-ed ?
> MN> this would slow things down
> Exactly not. Copying uses only for quite rare case when decoder does
> not consume several bytes at tail packet tail. Then these bytes copied
> into fifo. Next time these bytes usually are totally consumed with new
> packet and only reference to packets uses in general decoding.
> For several test streams I'm observing that 2-3 bytes copying appear
> only at begin of decoding, for first 5-10 frames.
> >> -    do {
> >> +    while (1) {
> >>          ret = get_surface(avctx, q, &insurf);
> >>          if (ret < 0)
> >>              return ret;
> >> +        do {
> >> +            ret = MFXVideoDECODE_DecodeFrameAsync(q->session, avpkt->size ? &bs : NULL,
> >> +                                                  insurf, &outsurf, &sync);
> >> +            if (ret != MFX_WRN_DEVICE_BUSY)
> >> +                break;
> >> -        ret = MFXVideoDECODE_DecodeFrameAsync(q->session, avpkt->size ? &bs : NULL,
> >> -                                              insurf, &outsurf, &sync);
> >> -        if (ret == MFX_WRN_DEVICE_BUSY)
> 
> >> -            av_usleep(1);
> >> +            av_usleep(500);
> 
> MN> looks like a unrelated change,
> MN> should be in a seperate patch with explanation
> These lines (new decoding loop) are absolutely necessary to consume all
> available data in packets. Else data not consumes and input_fifo uses all
> the time with wrong frames sequence output (duplicates and drops).
> 

> The reason of replacing of av_usleep(1) to av_usleep(500) is
> following: I believe it is bad idea to ask hardware 1000000 times per
> second if it is busy, especially in main decoding loop.
> Peak qsv decoding performance is about 2000 fps when destination is GPU memory.
> For system memory the performance is less then 1000fps usually. So delay in 500microseconds (i.e. 0.5 ms)
> is much more appropriate.

> I can move it to separate patch but since main decoding loop totally
> re-designed possible it can be applied as?

i think it should be split, as it would allow very easy regression
testing with bisect, of the change in the future


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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150724/76663b27/attachment.sig>