libopenh264dec: Use a newer decoding entry point function
diff mbox series

Message ID 20190125083913.76626-1-martin@martin.st
State Committed
Commit eec93e57096aa4804862d62760442380c70d489b
Headers show
Series
  • libopenh264dec: Use a newer decoding entry point function
Related show

Commit Message

Martin Storsjö Jan. 25, 2019, 8:39 a.m. 
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.
---
 libavcodec/libopenh264dec.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

Comments

Janne Grunau Jan. 26, 2019, 12:39 p.m. | #1 
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.

path itsel ok,

Janne
Martin Storsjö Jan. 26, 2019, 7:11 p.m. | #2 
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

Patch
diff mbox series 

diff --git a/libavcodec/libopenh264dec.c b/libavcodec/libopenh264dec.c
index 60e4b028ec..6adf984112 100644
--- a/libavcodec/libopenh264dec.c
+++ b/libavcodec/libopenh264dec.c
@@ -109,10 +109,18 @@  static int svc_decode_frame(AVCodecContext *avctx, void *data,
 #endif
     } else {
         info.uiInBsTimeStamp = avpkt->pts;
+#if OPENH264_VER_AT_LEAST(1, 4)
+        // Contrary to the name, DecodeFrameNoDelay actually does buffering
+        // and reordering of frames, and is the recommended decoding entry
+        // point since 1.4. This is essential for successfully decoding
+        // B-frames.
+        state = (*s->decoder)->DecodeFrameNoDelay(s->decoder, avpkt->data, avpkt->size, ptrs, &info);
+#else
         state = (*s->decoder)->DecodeFrame2(s->decoder, avpkt->data, avpkt->size, ptrs, &info);
+#endif
     }
     if (state != dsErrorFree) {
-        av_log(avctx, AV_LOG_ERROR, "DecodeFrame2 failed\n");
+        av_log(avctx, AV_LOG_ERROR, "DecodeFrame failed\n");
         return AVERROR_UNKNOWN;
     }
     if (info.iBufferStatus != 1) {