i found this in the DXVA code, and i would like
to optimize it a bit:
Then please send your tested patch (made with git
format-patch) to the development mailing list
where it can be reviewed.
I can save you the trouble though. First of all, gop_size is an
encoding parameter, and not useful here at all.
Secondly, there is unfortunately no parameter that conveys this
information that is both (1) accurate, and (2) known early enough to
be useful.
Yes, i was asking for the correctness of this assumption.
So the assumption is not correct =/
If we decode 4K video, saving four surfaces is a considerable
amount of memory. Is there a later point where we can re-set the
amount of surfaces? We can check for I-frame distances, but
this does not guarantee that we find the maximum - this may change
at any time in the stream i think.
Aside: quick check across our testing footage reported a
gop_size of 12 for all h264. where is this set when decoding, i
could not find it in the source code?
So, this cannot be "improved" really.
_______________________________________________
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
--
--------------------------------------------------------
device+context
Hendrik Wendler
Schwanseestrasse 92 99427 Weimar
Reichenberger Strasse 107 10999 Berlin
+491795230455
www.mxwendler.net
--------------------------------------------------------
_______________________________________________
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
