[Android] [vlc-android] H264 1080p perf issue

[Hugues FRUCHET]

Here are the results on my side:

* With Rafael transcode patch:
$> adb shell am start -n org.videolan.vlc/.gui.video.VideoPlayerActivity -a android.intent.action.VIEW -d file:///mnt/sdcard/bbb_1080p.mp4
Played till end of video
$> adb logcat
W/VLC     ( 1168): [0x1e0b6e4]: stream_out_transcode stream out Decoding took 50906 ms

60s of video at 24fps => 1440 frames, 1440/50.906 = 28.28fps

So perf is lower than on your side.


* With Stagefright
$ adb shell stagefright /mnt/sdcard/bbb_1080p.mp4
thumbnailTime: 10041666 us (10.04 secs)
AVC video profile 77 and level 41
..........................................................................................$
avg. 42.44 fps
avg. time to decode one buffer 22866.01 usecs
decoded a total of 1439 frame(s).

But with Stagefright unit test, perf is not so bad.

Would be nice that we got same measurement on your side, in order to known if problem is located on decoder itself or due to how VLC uses the decoder.

What we could try is to push the stagefright utility on your device, which version of Android do you run ?


BR.
-----Original Message-----
From: Martin Storsjö [mailto:martin at martin.st] 
Sent: mardi 19 février 2013 10:03
To: Hugues FRUCHET
Cc: android at videolan.org; Rafaël Carré
Subject: RE: [Android] [vlc-android] H264 1080p perf issue

On Tue, 19 Feb 2013, Hugues FRUCHET wrote:

>
>> With this sample (including rendering of the samples, I haven't commented out the decoder_NewPicture and CopyOmx* calls), I get the following times
>> between each OMX_FillThisBuffer call:
>> D/VLC     (26367): [0x69a33c4c]: iomx decoder FillThisBuffer 0x5f51d8c0, 0x63850000 20 ms
>> D/VLC     (26367): [0x69a33c4c]: iomx decoder FillThisBuffer 0x69a367b8, 0x63552000 94 ms
>> D/VLC     (26367): [0x69a33c4c]: iomx decoder FillThisBuffer 0x5f51d8c0, 0x63850000 10 ms
>> D/VLC     (26367): [0x69a33c4c]: iomx decoder FillThisBuffer 0x69a367b8, 0x63552000 17 ms
>> D/VLC     (26367): [0x69a33c4c]: iomx decoder FillThisBuffer 0x5f51d8c0, 0x63850000 60 ms
>> D/VLC     (26367): [0x69a33c4c]: iomx decoder FillThisBuffer 0x69a367b8, 0x63552000 36 ms
>> So at this segment it's 237 ms for 6 frames, around 39 ms on average, or
>> 25 fps.
>> At another section in the same file, the average is 36 ms, or 27 fps. The file itself is 24 fps, so it is played back more than fast enough, and since > VLC plays it back at realtime speed, it will never become faster than this. So this is not a meaningful benchmark, but this phone decodes 1080p content > "more than fast enough". To get to know exactly how fast, via VLC, we'd need to hack VLC more to not throttle it to realtime.
>
> What you could do to have the decoder perf in "best effort is to use "stagefright" utility in command line, with this utility decoder is used in a mode very close to how it is used in VLC:
> - buffer output mode
> - frame copy in output to deal with inter-process exchange
> - I suppose that decoder will output NV12 as for VLC in this mode also
> Note that, as far as I have understood, in VLC there is an additional frame copy to fill display picture buffer (CopyOmxPicture)
>
> $ adb shell stagefright -m100 /mnt/sdcard/Irma-I_know.mp4
> thumbnailTime: 8000000 us (8.00 secs)
> AVC video profile 100 and level 40
> .......$
> avg. 38.26 fps
> avg. time to decode one buffer 20694.87 usecs decoded a total of 100 frame(s).
>
> -m100 option limit decoding to the first 100 frames, allowing to not wait for the end of video to have the report.

The "stagefright" testing tool isn't available on release devices so I 
can't use that for testing.

But as I said in the second mail, when I properly applied Rafaël's patch, 
I was able to decode 60 seconds of 1080p video in 35 seconds, on my 
device, using VLC.

// Martin