Number of frames returned by vpx_codec_decode

[Kagami Hiiragi]

Hi.

I'm using libvpx library to decode VP9 video files and everything works
ok, but I don't quite get what exactly does vpx_codec_decode return.

simple_decoder.c states:

https://chromium.googlesource.com/webm/libvpx/+/a8a9c2bb45868fb9009ca1ce8e9a4d14947855a3/examples/simple_decoder.c#56
> Codecs may produce a variable number of output frames for every call to
> `vpx_codec_decode`. These frames are retrieved by the
> `vpx_codec_get_frame` iterator function. The iterator variable `iter` is
> initialized to NULL each time `vpx_codec_decode` is called.
> `vpx_codec_get_frame` is called in a loop, returning a pointer to a
> decoded image or NULL to indicate the end of list.

, but I tried several files and only get 0 or 1 frames on each
vpx_codec_decode call. On the other hand, vp9_dx_iface.c states:

https://chromium.googlesource.com/webm/libvpx/+/a8a9c2bb45868fb9009ca1ce8e9a4d14947855a3/vp9/vp9_dx_iface.c#741
> iter acts as a flip flop, so an image is only returned on the first
> call to get_frame.

Which one is correct?

Thanks.

[Brendan Bolles]

On May 8, 2015, at 8:37 AM, Kagami Hiiragi wrote:

> I'm using libvpx library to decode VP9 video files and everything works
> ok, but I don't quite get what exactly does vpx_codec_decode return.

Libvpx uses a generalized interface that supports features that may not be used by either VP8 or VP9. So codecs *may* produce a variable number of output frames, but neither VP8 or VP9 are doing that.

Actually, if you turn on multithreaded decoding right now, you may find that that you don't get any frames when you first call vpx_codec_get_frame(), and then later you may get more than one if you call it multiple times. Eventually the number of frames returned will match the number of decode calls.


Brendan

[Kagami Hiiragi]

Thanks for the answer.

In other words: without multithread decoding I will only get 0 or 1
frames on each vpx_codec_decode call and 0 means it's some sort of
invisible frame (alt frame, golden frame, etc). Am I correct?

(I'm using IVF container if that matters.)

[Brendan Bolles]

On May 8, 2015, at 11:34 AM, Kagami Hiiragi wrote:

> In other words: without multithread decoding I will only get 0 or 1
> frames on each vpx_codec_decode call and 0 means it's some sort of
> invisible frame (alt frame, golden frame, etc). Am I correct?

I don't think you'll even get that with VP9. One frame in will always give you one frame out if multithreading is off.

With VP8 you could maybe get no frame out if you decoded an alt-ref frame? Someone from Google could tell us for sure.


Brendan

[Pieter Kapsenberg]

VP9 decode will result in a displayable frame. It could be that the call actually decoded additional non-displayed frames doing so (behind the scenes), but at least one will be displayable.

[Ronald S. Bultje]

Hi,

On Fri, May 8, 2015 at 4:36 PM, Pieter Kapsenberg <pkap...@google.com> wrote:

VP9 decode will result in a displayable frame. It could be that the call actually decoded additional non-displayed frames doing so (behind the scenes), but at least one will be displayable.

I think this is only true if you use vpxdec, or more generally, it depends on the implementation of whether some layer before libvpx already tried to split the concatenated vp9 bitstream packets (libvpx allows for this).

If you use ffmpeg's matroska demuxer (I believe this is what Chrome does?), which invokes the ffmpeg vp9 parser, it will split the alt-ref frame from the following (packed-in) displayed frame and return both as separate AVFrames to the caller. The caller then invokes avcoded_decode_video on each frame separately, which (if you used libvpx for decoding, which is what Chrome does) thus invokes libvpx' decode function with only an invisible alt-ref frame, followed by a separate call with only the visible frame. The first call then returns no displayed frames.

(ffmpeg does this to facilitate frame-multithreading in ffvp9.)

Ronald

[Pieter Kapsenberg]

Ah, yes if the stream was not packaged by vpxenc that is indeed the case.

--
You received this message because you are subscribed to the Google Groups "Codec Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codec-devel...@webmproject.org.
To post to this group, send email to codec...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/codec-devel/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Kagami Hiiragi]

On 08/05/15 23:52, Ronald S. Bultje wrote:
> If you use ffmpeg's matroska demuxer (I believe this is what Chrome
> does?), which invokes the ffmpeg vp9 parser, it will split the alt-ref
> frame from the following (packed-in) displayed frame and return both as
> separate AVFrames to the caller. The caller then invokes
> avcoded_decode_video on each frame separately, which (if you used libvpx
> for decoding, which is what Chrome does) thus invokes libvpx' decode
> function with only an invisible alt-ref frame, followed by a separate
> call with only the visible frame. The first call then returns no
> displayed frames.

Ah, thanks, it makes the things clear. I used ffmpeg to remux webm into
IVF container indeed.

Just to be sure: packed frame can't contain more than one displayable
frame for the moment, right?

[Ronald S. Bultje]

Hi,

Correct.

Ronald