• 1
  • 20
  • 21
  • 22(current)
  • 23
  • 24
  • 52
libstagefright - Experimental hardware video decoding builds
Hi Koying:

Thank you for the new build. The latest build is even a little smoother than the one before, nice job.
The only video that fails to play nicely on my Nexus 7 is the hddvd.mkv sample (vc1_1080p_ap_l3_18mbps_ac3_hddvd.mkv).

Our team also ran a test on a RK3066 evaluation board, the test results are:

(FILE)
(AUDIO/VIDEO)
h264_720p_hp_3.1_600kbps_aac_mp3_dual_audio_harry_potter.mkv
- OK/OK
h264_720p_hp_5.1_3mbps_vorbis_styled_and_unstyled_subs_suzumiya.mkv
- OK/OK
h264_720p_hp_5.1_6mbps_ac3_planet.mp4
- OK/OK
h264_720p_hp_5.1_6mbps_ac3_unstyled_subs_planet.mkv
- OK/OK
h264_720p_mp_3.1_3mbps_aac_shrinkage.mkv
- OK/OK
h264_720p_mp_3.1_3mbps_aac_shrinkage.mp4
- OK/OK
h264_1080p_hp_4.1_10mbps_dts_unstyled_subs_monsters.mkv
- NO/NO
h264_1080p_hp_4.1_40mbps_birds.mkv
- NO/NO
vc1_1080p_ap_l3_18mbps_ac3_hddvd.mkv
- NO/NO
xvid_480p_as_l5_1mbps_he-aac_foreign_subs_matrix.mkv
- OK/OK

RK3066 system is Android 4.1.1, Kernel 3.0.8.

Using the native player the monsters clip (h264_1080p_hp_4.1_10mbps_dts_unstyled_subs_monsters.mkv) will play, but not with XBMC.
Maybe that's a missing part in the hardware decoding.

How to support the development? Any repository?

Best wishes,
Sebastian
Sebastian use your channels to pressure Rockchip to get some resources free for XBMC Wink

Monsters can play disabling 1 Core and falling back to Single Core VPU decoding though not 100% stable, this also works for many other streams though it's just a workaround and shouldn't be seen as a real solution.

Most stability so far you reach via the default Android Framework (Swrenderer) either Hardware Overlay or not Smile
so mostly any default app will work fine if it uses the Default Framework if it uses their own GPU Renderer it is still problematic neither MX Player nor XBMC are fully stable and can crash any time @ playback even with the 1 Core workaround it's not guaranteed stable for above 720p playback.

The VC1 and Mpeg-2 decoder as with other implemented Decoder (VPX) seem not to be accessible yet by XBMC libstagefright, thus it will fallback to Software decoding resulting in low performance playback.

Which is for vc1_1080p_ap_l3_18mbps_ac3_hddvd.mkv around 10 fps with the ffmpeg decoder, not playable
CruNcher, once I know a way to contribute to libstagefright and also if XBMC gets confirmed for our product I'm more than happy to assign someone on this.
(2013-02-20, 10:00)KingOfSand Wrote: Is there anything I have forgotten?
Yes. You have forgotten to read beyond point 1) in the original post.
Proper status:
  • Sources
    As a reminder, the sources of the builds are XBMC master + this PR: https://github.com/xbmc/xbmc/pull/1832. I've updated the OP to make this clear.

  • VC-1
    I could not get it to work on any of the device I have. There is probably some metadata I should send before decoding, but even AOSP uses a proprietary lib for demux, "libwvm.so". I' ll need help on this one (like the sources of libwvm.so if available) or VC-1 will be a no-go.

  • rk3066
    For those not following, the Rockchip OMX components crash hard when trying to HW decode non-MOD16 height vids, both in h264 and in MP4. E.g. a 1080 or 406 height video will crash, while 416, 576, 800, 816, 1040 will work fine.
    The MiniX guys who provided me with a device will try to get me in contact with Rockchip.

  • Blacklisting
    I've started blacklisting problematic components. For now:
    • MP4 on tegra3: Unreliable. Fails to decode some vids late in the process, too late for proper fallback to SW decoding.
    • Non MOD16 height vids on Rockchip (see above)

  • Advanced settings
    At least for the duration of tests (don't shoot, davilla Wink ), I've added some advanced settings tweaks.
    The "use...codec" are self-explanatory. The "useswrenderer" one uses the SW rendering method if some want to try it.
    In my tests, it only works fine for 720p on Tegra3.

    Code:
    <advancedsettings>
    ...
      <video>
        <stagefright>
          <!--  -1 is default, 0 is never used this codec, 1 is always use this codec, bypassing blacklist -->
          <useavccodec>-1</useavccodec>
          <usevc1codec>-1</usevc1codec>
          <usevpxcodec>-1</usevpxcodec>
          <usemp4codec>-1</usemp4codec>
          <usempeg2codec>-1</usempeg2codec>

          <useswrenderer>false</useswrenderer>
        </stagefright>
      </video>
    ...
    </advancedsettings>
(2013-02-20, 09:39)sebastianroth Wrote: ... and also if XBMC gets confirmed for our product I'm more than happy to assign someone on this.
And your product is?

Not sure what you mean by "gets confirmed", either. The libstagefright method is supposed to be a common denominator for all android devices. Up to the SoC manufacturer to provide proper OMX components or they won't get H/W acceleration in XBMC (unless they develop it themselves like Pivos/AmLogic did).

They're shooting themselves in the foot if they don't...
(2013-02-20, 12:20)Koying Wrote: And your product is?

Not sure what you mean by "gets confirmed", either. The libstagefright method is supposed to be a common denominator for all android devices. Up to the SoC manufacturer to provide proper OMX components or they won't get H/W acceleration in XBMC (unless they develop it themselves like Pivos/AmLogic did).

They're shooting themselves in the foot if they don't...

"Gets confirmed" means that my company decides to use XBMC as the primary media center component.
In that case we'd have a partner to prepare the basics of the Android system including drivers and could instruct them to develop on libstagefright as well.

Right now we have the RK3066 board which works in acceptable quality with the builtin drivers in Android.
One interesting detail maybe:
The movie "h264_1080p_hp_4.1_10mbps_dts_unstyled_subs_monsters.mkv" doesn't play well in XBMC, extremely slow etc - but works well with the native player / drivers.

The product is a tablet device. I can post details once it's released. :-)

Anyhow I'll let you know if I encounter any driver files or anything that looks similar.
Koying sebastian is from NextBase Multimedia Car Solutions i guess they preparing their own tablet with their own in car branded experience instead of just car mounts for Apple and Co Wink

PS: Sebastian whoever had this idea for the "Race Promo" (Products tested safety advantages) please slap him for me those 2 racing fathers with their kids on the backseat jesus what did the guy think ?
(2013-02-20, 12:31)sebastianroth Wrote: The movie "h264_1080p_hp_4.1_10mbps_dts_unstyled_subs_monsters.mkv" doesn't play well in XBMC, extremely slow etc - but works well with the native player / drivers.
Well, of course, they're using their own closed-source player with undisclosed direct access to the SoC, I assume...

(2013-02-20, 12:31)sebastianroth Wrote: The product is a tablet device. I can post details once it's released. :-)
Wouhou, big secret! Another rebranded chinese clone!
Sorry for the sarcasm, couldn't resist Wink
(2013-02-20, 12:44)Koying Wrote: Well, of course, they're using their own closed-source player with undisclosed direct access to the SoC, I assume...

I don't think that this has a lot todo with it as practically every standard Android app produces these results as long as it uses the default Framework Wink
Rockchip seems completely CTS conform in their Android implementation @ least for H.264 Hardware acceleration
Koying, many thanks for all your work!

My (small) research contribution:

VC-1
libwvm is a proprietary codec by Widevine, which is a Google company. Here is their webpage and contact information: http://www.widevine.com/contact.html
I think you're unlikely to get any source code, but hopefully they will answer a technical question.

Also, Cyanogen distributions ship with libwvm, so would it not be possible to use it for XBMC as well (if needed)?

MP4 - Tegra3
Is it possible to turn on all available cores and only do software decoding (until the hardware decode works)?
Can you say what's causing the issue -- so maybe we could help track down a solution?
(2013-02-20, 17:11)Alchete Wrote: My (small) research contribution:
Thanks for your research.

(2013-02-20, 17:11)Alchete Wrote: VC-1
libwvm is a proprietary codec by Widevine, which is a Google company. Here is their webpage and contact information: http://www.widevine.com/contact.html
I think you're unlikely to get any source code, but hopefully they will answer a technical question.

Also, Cyanogen distributions ship with libwvm, so would it not be possible to use it for XBMC as well (if needed)?
They probably handle DRM as well. We cannot use it as such, because we have our own demuxer.

(2013-02-20, 17:11)Alchete Wrote: MP4 - Tegra3
Is it possible to turn on all available cores and only do software decoding (until the hardware decode works)?
Can you say what's causing the issue -- so maybe we could help track down a solution?
Actually, MP4 decoding works very fine in SW on tegra3. It's just for the sake of completeness.
It just says "coding method not supported" or equivalent. Not much hope on the decoding side, but it would be good to be able to differentiate the problematic ones to increase granularity.
(2013-02-20, 08:39)Koying Wrote:
(2013-02-19, 21:36)psycon Wrote: Tried the new build. I have tested a few HD streams and they work fine but SD streams do not play properly at all, all i get is audio, subs, and garbled picture.
Please state your device.
You might have done so previously, but I don't feel like searching the 37 pages of the thread ;-)

sorry. mk809.
(2013-02-20, 17:41)Koying Wrote: Actually, MP4 decoding works very fine in SW on tegra3. It's just for the sake of completeness.
It just says "coding method not supported" or equivalent. Not much hope on the decoding side, but it would be good to be able to differentiate the problematic ones to increase granularity.
I believe Tegra3 is supposed to support MP4, so it's an interesting issue.

I found the libstagefright source, to track down the exact error message. This may already be included in XBMC? Or, I'm sure you've seen it already.

https://android.googlesource.com/platfor...right/mp4/
(2013-02-20, 18:15)Alchete Wrote: I found the libstagefright source, to track down the exact error message. This may already be included in XBMC? Or, I'm sure you've seen it already.
That's the demuxer for the mp4 container. Not to be confused with the mp4 codec. AFAIK, the HW decoders are always closed-source.
  • 1
  • 20
  • 21
  • 22(current)
  • 23
  • 24
  • 52

Logout Mark Read Team Forum Stats Members Help
libstagefright - Experimental hardware video decoding builds10