On Sat, 26 Jan 2019, Janne Grunau wrote:
On 2019-01-25 10:39:13 +0200, Martin Storsjö wrote:
The "new" entry point actually has existed since OpenH264 1.4 in
2015, but with B-frames, this entry point is essential for actually
getting the right frames returned and reordered.
The name of this function, DecodeFrameNoDelay, is rather backwards
considering that it doesn't return the latest decoded frame immediately,
but actually does proper delaying and reordering of frames, but
it's the recommended decoding entry point.
The commit message is hard to parse. Something along below is imho
easier to understand:
| The "new" entry point actually has existed since OpenH264 1.4 in
| 2015 and is the the recommended decoding entry point.
|
| The name of this function, DecodeFrameNoDelay, is rather backwards
| considering that it doesn't return the latest decoded frame immediately,
| but actually does proper delaying and reordering of frames.
Thanks! That's indeed much more understandable.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
