[davilla]

- Sort input packets ? why would you want to sort the demuxer packets ? This seems very wrong and goes against any video codec design I know of. It is very important to preserve packet order as the encoding can depends on this.

- Use pts or dts from input ? why would you do this ? avi's are the only things with suspect pts and you should be using dts for them. Aside from that, you 'should' be looking for the invalid tag in pts, if found use dts. That's dvdplayer behavior.

- Use output pts or let dvdplayer generate them ? Never let dvdplayer generate them, that's a last case fall back which requires that duration is correct and the duration you find in containers is oh so very wrong in most cases. So to gen a valid duration you have to look at dts/pts and if you are looking at those, you know the pts dvdplayer needs already.

- Use SW renderer : maybe.

- enable/disable XVID/MPEG2/VC1/VPX codecs : XVID is MPEG4 part 2, XVID means nothing. H264 is MPEG4 part 10. All these will depend on having hw codecs available and this should be know by probing.

[Koying]

La caravane passe...

Title of the thread is "experimental". Not like there are many docs on libstagefright, so I'm experimenting...
We can discuss the implementation when I will myself be satisfied with it

[davilla]

ok, C'est la vie... When it comes time for mainline inject and Elupus starts flinging trout you will understand

[bluepeter]

The rockchip device should reach me in the coming days

For the next version, I'll implement "tweaks" via advanced settings (e.g. SW renderer, XVID decoder, ...), so that we could test different settings with the same build.

One piece of friendly advice, make sure you have a decent 5v 2amp PSU as you'll suffer from total instability. I have 2 dualcore rockchip devices, UG802 4gig nand, MK802 III 8gig... the MK802-3 is proving to be the better of the two.

Regards
Peter

PS... thank you for all the work you are putting into this

[Koying]

ok, C'est la vie... When it comes time for mainline inject and Elupus starts flinging trout you will understand

Hehe... Pretty sure I'll get more than my share in the face.
But, let's at least present something working

[Koying]

device is a MiTech 10" tablet M1001

Assuming it's this: http://www.m-i-tech.de/pg.asp?id=1
It's an Allwinner A10 chip -> no libstagefright

[CruNcher]

The rockchip device should reach me in the coming days

For the next version, I'll implement "tweaks" via advanced settings (e.g. SW renderer, XVID decoder, ...), so that we could test different settings with the same build.

I think it's a good idea

Though i would really like to know why the XBMC GPU Render behavior is so different on different RK 3066 devices but implementations like MX Player or Archos GPU Renderer seem to work everywhere ?

The Crash behavior for Jacuzzis RK 3066 HDMI stick (every test sample) sounds like the same experience i had with the first version of the libstagefright support on my Tablet it's really strange that it's such a vastly different experience it definitely doesn't makes debugging this easy @ all
I mean if you take into account that the VPU library never seem to change between firmware versions (or maybe it does ? )


PS: Does under Android means utilizing the Software Renderer is only through a Hardware Overlay ?

I guess it would be the best to find out on which Hardware is postprocessing really needed to go through a GPU Renderer instead of the Direct way to the Display as it seems Android is very well able to change on the fly between GUI GPU rendered stuff if it comes up and the Video Rendered as a Hardware Overlay in the background lower layer.
I can at least see that it dynamically changes it's rendering state based on what is visible in RockChips player for example if you call up the Android interface the Hardware Overlay is lost though only just for some seconds as long as the Android GUI needs to being rendered on the GPU on top but as soon as it got rendered the Hardware Overlay is back, and subtitles get generally decoded on the Hardware Overlay without problems (pretty efficient)


PS: For RK 3066 users you can actually see if the VPU is being used also from the Kernel output you will see

vpu: power on

as the message and after playback

delayed vpu: power off...done

[jornhd]

I have two devices, a Tegra3 powered TF300 and a Minix Neo X5 with RK3066.

I don't have many HD files, but I've tested HD steams from Video Add-on NRK nett-TV and SD files (mp4) converted with Handbrake high profile.

On the TF300 all videos (both streams and files) are working very smooth. Audio is in sync.
On the RK3066 Handbrake mp4s are displayed like post #217. Network streams are choppy and audio out of sync. One 720p x264 mkv worked great.

[CruNcher]

I now started testing different firmware versions still crashing but i got further in the Zelda Medley with this older Firmware though i guess it was a random thing again that it crashed some frames later

Video->Playback->Sync to Display-> Audio Clock seems to be the mode that comes *cough* randomly the furthest into the stream before it crash or freezes

im testing now all the builds and indeed the crash issues appeared later in the build history on 1080p
before it where the White Fog Rendering issues but it plays with these older XBMC builds stable @ least

Build Result

18.01 = Plays through the 1080p Zelda Medley without Crash ( with rendering issue http://forum.xbmc.org/showthread.php?tid...pid1312883 )
19.01 = same as 18.01
21.01 = same as 19.01
27.01 = same as 21.01
02.02 = sames as 27.01

WTF
it seems the results arent consistent is it not possible to just delete the XBMC version and install the new one is code left in Memory on Android without reboot, doesn't it get completely wiped out after closing and uninstalling ?
So i think i have to test each one with a uninstall old one->reboot->install new one ??
at least it seems from this experience that uninstall old one->install new one-> execute seems to take over the previous code state


again this time with uninstall/reboot

18.01 = Plays through the 1080p Zelda Medley without Crash ( with rendering issue http://forum.xbmc.org/showthread.php?tid...pid1312883 )
19.01 = Crash starting, reboots at the first 1 minute into the stream right in motion, shows some artifacting before not as heavy as the white fog though
21.01 = Crashes
27.01 = Crashes
02.02 = Crashes very fast (much earlier then above builds)

[manxam]

If you ask me - just leave the killa and birds example out of the equation. AFAIK these are encoded out of spec and don't really matter in this thread (they are just stupid!). Koying might overwrite this statement if he likes to.

Hi Koying,

On your Nexus 7, are you able to confirm that the 40Mbps 1080p Birds video is stuttering with the recent builds, or do you need a log from my Nexus 7?

As per Memphiz, the "Birds" video isn't a good example for testing as it has an excessively high bitrate for no apparent reason. You'll not find/download/create an actual movie encoded like this. I really wouldn't expect it to play properly on anything but a highly optimized decoder and XBMC's hardware decoding is still in it's infancy.

[Koying]

21.01 with Audio Clock almost it was getting really far into the stream but then crash again

A bit lost I assume you speak about zelda? Which is a 1080p?
I might have missed it. Could you link to the file, please.

[CruNcher]

21.01 with Audio Clock almost it was getting really far into the stream but then crash again

A bit lost I assume you speak about zelda? Which is a 1080p?
I might have missed it. Could you link to the file, please.

Uploading will take a little, though its a pretty standard 1080p youtube stream nothing special it's just the thing that 1080p is absolutely unstable and the only build that was really stable with 1080p was the 18.01 but that had those artfiacting @ playback but it didn't crash and playback performance was also ok, now after 18.01 the playback got artifact free but unstable and randomly freeze, crashes or reboots @ playback.


Though it seems all the 1080p results are so random that i can't reproduce them they just happen or not i tried the 18.01 build again and now i got no artifacting but it crashed though i got very far into the stream.
Such random issues though are never a good sign and hard to debug

Here it is Koying though im not really sure if it will help you @ least i hope the RK 3066 device will be of help

https://dl.dropbox.com/s/18ys53m6npnmbju...e.mp4?dl=1

[Koying]

I've received the rockchip device (a minix neo x5) and ran a quick test.
Indeed, I see that 720p is running fine but 1080p is not. From my tests, it seems getting back a 720p frame is ~5ms while getting a 1080p one is ~50ms

I've opened a thread on the minix forums and I hope those friendly guys might allow me to get access to their android sources and directly to rockchip, so that we might solve this.

[awp0]

Awesome. I've had my eye on the Neo X5 because it looks like it has the potential to be an ideal XBMC platform. Thanks for all your work on this, I'll be really excited if you get the Rockchip platform working well. Run out and sell my ATV2.

[bluepeter]

I've received the rockchip device (a minix neo x5) and ran a quick test.
Indeed, I see that 720p is running fine but 1080p is not. From my tests, it seems getting back a 720p frame is ~5ms while getting a 1080p one is ~50ms

I've opened a thread on the minix forums and I hope those friendly guys might allow me to get access to their android sources and directly to rockchip, so that we might solve this.

I think you are being rather optimistic when it comes to Rockchip, best of luck.