Performance of VP8 decoder with single partition

[sapthagiri]

Hi, In vp8 encoder side, i can create number of partitions based on
the number of cores available in the system. But in decoder side how
can i ensure that, the vp8 stream has more or equal number of
partitions with the number of cores available in the system.
Lets say, i want to give a data sheet for the vp8 decoder, then what
assumptions i can consider for the number of partitions case.
My worry is, we are not able to use wave front order for the
prediction, idct & deblocking in case of single partition in the vp8
decoder even we have a multi core system.
Please help me to understand in this regard.

Thanks,
Sapthagiri

[Oleksij Rempel]

In current libvpx you do not need to worry about count of cores, it
will find count of core by itself. Option threads is actually maximum
limit, it will not force more threads then core available. It is true
for decoder and encoder. You can set threads=255 but decoder has a
hard coded limit = 8. I assume maximum what you will need with HD
resolution is 4.

[sapthagiri]

I am talking about single partition with multiple cores available.
libvpx creates only one thread for it (main thread). So i am not able
to use my remaining cores for decoding even there is a possibility of
wave front order for prediction, idct & deblocking.
Can we have a assumption that, all the vp8 streams have multiple
partitions in future?

Thanks,
Sapthagiri

[Oleksij Rempel]

It is interesting question. I would like to know it too.
I can say only for gstreamer. If libvpx will not provide it by
default, gstreamer will not provide it too. Since increasing number of
partitions and number of threads by encoding, increase file size,
gstreamer will use safe option.
I made here short test:
i created 1000 frames with size 640x480 and encoded it with speed=1
-rw-rw-r-- 1 lex lex 4685264 Apr 16 16:05 test_norm.mkv
here i added threads=2
-rw-rw-r-- 1 lex lex 4686442 Apr 16 16:06 test_thread.mkv
here token-parts=1
-rw-rw-r-- 1 lex lex 4691198 Apr 16 16:07 test_thread_p1.mkv
and token-parts=2
-rw-rw-r-- 1 lex lex 4700171 Apr 16 16:07 test_thread_p2.mkv

I assume, for longer videos this difference will be bigger.

[John Koleszar]

Multipartition encodes have an overhead of 3 bytes per frame per
partition beyond 1. So for 8 partitions, 1000 frames, 7*3*1000 = 21000
bytes, which is consistent with the numbers you show below.

As a decoder, you can't make any assumptions about how many partitions
an input stream will have.

> --
> You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
> To post to this group, send email to webm-d...@webmproject.org.
> To unsubscribe from this group, send email to webm-discuss...@webmproject.org.
> For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.
>

[Måns Rullgård]

sapthagiri <sapthagir...@gmail.com>
writes:

> I am talking about single partition with multiple cores available.
> libvpx creates only one thread for it (main thread). So i am not able
> to use my remaining cores for decoding even there is a possibility of
> wave front order for prediction, idct & deblocking.

The libav decoder supports multi-threaded decoding of any input, and
it's much faster than libvpx. If its LGPL licence is acceptable to you,
you'd be better off using it.

--
M�ns Rullg�rd
ma...@mansr.com