[Android] [vlc-android] H264 1080p perf issue
Hugues FRUCHET
hugues.fruchet at st.com
Tue Feb 19 09:35:50 CET 2013
> 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.
I come back to you soon on the result I have on http://albin.abo.fi/~mstorsjo/bbb_1080p.mp4
-----Original Message-----
From: Martin Storsjö [mailto:martin at martin.st]
Sent: lundi 18 février 2013 20:43
To: android at videolan.org
Cc: Hugues FRUCHET; Rafaël Carré
Subject: Re: [Android] [vlc-android] H264 1080p perf issue
Hi again,
On Mon, 18 Feb 2013, Martin Storsjö wrote:
> On Mon, 18 Feb 2013, Hugues FRUCHET wrote:
>
> Please do note that VLC will not try to play things back faster than realtime
> by default - or does the patch from Rafaël make it decode as fast as
> possible? - After trying to apply the changes from the previous mail and
> trying to play back a video, it still plays back at normal speed.
Sorry, I miscompiled things when trying to test it. Now it actually does
try to play things back at full speed, as it should - then it does make
sense.
> One 1080p H264 sample I can share is
> http://albin.abo.fi/~mstorsjo/bbb_1080p.mp4.
With Rafaël's patch, I can play back this 60 second sample in 35628 ms, so
it can play back 1080p content at over 41 fps at average, with all the
extra overhead incurred by VLC.
// Martin
More information about the Android
mailing list