<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 8:17 AM, Felix Abecassis <span dir="ltr"><<a href="mailto:felix.abecassis@gmail.com" target="_blank">felix.abecassis@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2014/1/22 XilasZ <<a href="mailto:xilasz@gmail.com">xilasz@gmail.com</a>>:<br>
<div class="im">><br>
>> > I would rather take the opposite approach, can we find a device in the<br>
>> > 4.1 to 4.2 range which does not work correctly with opaque rendering?<br>
>> > Please test the Hardware Acceleration option if you have such devices!<br>
>><br>
>> That's pretty dangerous, seeing the number of crappy devices...<br>
>> And seeing the number of hi-ref-frames files people can use...<br>
><br>
><br>
> At least on my HTC One X (tegra3, android 4.2.2), we can't enable it by<br>
> default yet.<br>
> Here some tests i did, with a simple 720p h264 mkv (a show) :<br>
><br>
> - SW<br>
>   => everything plays fine, both frames and subtitles and both vouts<br>
><br>
> - HW without DR<br>
>   => it works, both frames and subtitles and both vouts, but way too slow,<br>
> probably because of slow memory and limited bandwith<br>
><br>
> - HW + DR<br>
>   => with surface vout, works from video list, but without any subtitles<br>
>           lots of "blend blend: no matching alpha blending routine (chroma:<br>
> RGBA -> ANOP)" in the logs<br>
</div>This is "normal" since the patch for subtitles hasn't been merged yet.<br>
I have a patch for simply hiding this error but it does not enable<br>
subtitles.<br>
I suggest we wait for the subtitles patch, I just have one issue left to solve.<br>
<br>
But the real question here is: are the performance better than SW in this case?<br></blockquote><div><br></div><div>Ah ok, cool then, everything is working as expected.<br></div><div>And yes, perf is way better than SW, also less battery usage.<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
><br>
>   => with opengles vout, playback starts, but the UI switchs to audio only<br>
> because vouts fails to start :<br>
>           01-22 07:50:18.251: E/libEGL(20227): EGLNativeWindowType<br>
> 0x6016f980 already connected to another API<br>
>           01-22 07:50:18.251: E/libEGL(20227): eglCreateWindowSurface:407<br>
> error 300b (EGL_BAD_NATIVE_WINDOW)<br>
>           01-22 07:50:18.251: E/VLC(20227): egl_android gl: cannot create<br>
> EGL window surface<br>
</div>These two modes are not compatible, I will submit a patch so that the<br>
OpenGL vout cannot be activated if HW+DR is picked from the list.<br></blockquote><div><br></div><div>ok.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">
><br>
>   => when starting from directoryview, it freeze when starting,  feels like<br>
> a deadlock<br>
</div>I'm confused, how is this mode different from the above one?<br></blockquote><div><br>Didn't check, but probably because directoryview opens everything through AudioService, and switch to Videoplayer is there is a vout.<br>
</div><div>Since the vout may be waiting for a surface from videoplayer, which will only be there is there is a vout in this case, it gets stuck.<br></div><div>The whole switch between audio and video is not stable, and it's not new, it's also causing weird stuff when openning from outside vlc.<br>
</div></div></div></div>