Hi
I’m trying t port yuv texture to gles2.0 render
While the code working standalone, it’s completely broken under sdl
I attached a patch to pastebin. Please help
the shader is source from cinelerra-cv.org
Can you post a patch in bugzilla so it doesn’t get lost?
https://bugzilla.libsdl.org/
Pallav Nawani
IronCode Gaming Private Limited
Website: http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768On Fri, Jun 6, 2014 at 5:00 PM, dront78 wrote:
finally I got this working like in opengl render
http://pastebin.com/mt82sMyi
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Looks good, thanks!
https://hg.libsdl.org/SDL/rev/bc5ec1b6904cOn Fri, Jun 6, 2014 at 4:30 AM, dront78 wrote:
finally I got this working like in opengl render
http://pastebin.com/mt82sMyi
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Hello,
I have a SDL2 Android app (using android-project/) using SDL2 from Mercurial on 26 May 2014. I updated my working-copy to include this fix (9 June
2014 - bb99ec3b21d8 tip) [I’m still learning Mercurial. My only exposure is through my use of SDL2. I used ‘hg id’ to get that identifier. If that
isn’t the right one, what command should I use instead?].
My app renders YUV images (decoded by ffmpeg from a mp4) and thought I’d test this patch out. When I run the app on my Samsung Galaxy Tab 10.1
(Android 4.0.4), the YUV images are scrambled (diagonal lines - multi colour). Previously, the YUV images render just fine using SDL_PIXELFORMAT_YV12.
I tried SDL_PIXELFORMAT_IYUV and see the same scrambled behaviour.
With this patch/optimisation applied, should I be handling YUV images differently? Or should this patch be transparent (e.g. just work)?
Thanks,
AlvinOn 07/06/14 15:36, Sam Lantinga wrote:
Looks good, thanks!
https://hg.libsdl.org/SDL/rev/bc5ec1b6904cOn Fri, Jun 6, 2014 at 4:30 AM, dront78 <dront78 at gmail.com <mailto:dront78 at gmail.com>> wrote:
__ finally I got this working like in opengl render http://pastebin.com/mt82sMyi _______________________________________________ SDL mailing list SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
It should be transparent and just work.On Mon, Jun 9, 2014 at 11:15 AM, Alvin Beach wrote:
Hello,
I have a SDL2 Android app (using android-project/) using SDL2 from
Mercurial on 26 May 2014. I updated my working-copy to include this fix (9
June
2014 - bb99ec3b21d8 tip) [I’m still learning Mercurial. My only exposure is through my use of SDL2. I used ‘hg id’ to get that identifier. If that isn’t the right one, what command should I use instead?].My app renders YUV images (decoded by ffmpeg from a mp4) and thought I’d
test this patch out. When I run the app on my Samsung Galaxy Tab 10.1
(Android 4.0.4), the YUV images are scrambled (diagonal lines - multi
colour). Previously, the YUV images render just fine using
SDL_PIXELFORMAT_YV12.
I tried SDL_PIXELFORMAT_IYUV and see the same scrambled behaviour.With this patch/optimisation applied, should I be handling YUV images
differently? Or should this patch be transparent (e.g. just work)?Thanks,
Alvin
On 07/06/14 15:36, Sam Lantinga wrote:
Looks good, thanks!
https://hg.libsdl.org/SDL/rev/bc5ec1b6904cOn Fri, Jun 6, 2014 at 4:30 AM, dront78 <dront78 at gmail.com <mailto: dront78 at gmail.com>> wrote:
__ finally I got this working like in opengl render http://pastebin.com/mt82sMyi _______________________________________________ SDL mailing list SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
It should be transparent and just work.
Hello, I have a SDL2 Android app (using android-project/) using SDL2 from Mercurial on 26 May 2014. I updated my working-copy to include this fix (9 June 2014 - bb99ec3b21d8 tip) [I'm still learning Mercurial. My only exposure is through my use of SDL2. I used 'hg id' to get that identifier. If that isn't the right one, what command should I use instead?]. My app renders YUV images (decoded by ffmpeg from a mp4) and thought I'd test this patch out. When I run the app on my Samsung Galaxy Tab 10.1 (Android 4.0.4), the YUV images are scrambled (diagonal lines - multi colour). Previously, the YUV images render just fine using SDL_PIXELFORMAT_YV12. I tried SDL_PIXELFORMAT_IYUV and see the same scrambled behaviour. With this patch/optimisation applied, should I be handling YUV images differently? Or should this patch be transparent (e.g. just work)? Thanks, Alvin > Looks good, thanks! > https://hg.libsdl.org/SDL/rev/bc5ec1b6904c > > > > __ > finally I got this working like in opengl render > http://pastebin.com/mt82sMyi >
Thanks for the confirmation. That’s what I thought too. I will start to dig deeper. The testgles,
testgles2 work just fine on the tablet. I will create a minimal test and see when I can figure out.
Cheers,
AlvinOn 09/06/14 15:20, Sam Lantinga wrote:
On Mon, Jun 9, 2014 at 11:15 AM, Alvin Beach <@Alvin_Beach mailto:Alvin_Beach> wrote:
On 07/06/14 15:36, Sam Lantinga wrote:
> On Fri, Jun 6, 2014 at 4:30 AM, dront78 <dront78 at gmail.com <mailto:dront78 at gmail.com> <mailto:dront78 at gmail.com <mailto:dront78 at gmail.com>>> wrote:
It should be transparent and just work.
[snip] My app renders YUV images (decoded by ffmpeg from a mp4) and thought I'd test this patch out. When I run the app on my Samsung Galaxy Tab 10.1 (Android 4.0.4), the YUV images are scrambled (diagonal lines - multi colour). Previously, the YUV images render just fine using SDL_PIXELFORMAT_YV12. I tried SDL_PIXELFORMAT_IYUV and see the same scrambled behaviour. With this patch/optimisation applied, should I be handling YUV images differently? Or should this patch be transparent (e.g. just work)? Thanks, Alvin > Looks good, thanks! > https://hg.libsdl.org/SDL/rev/bc5ec1b6904c > > > > __ > finally I got this working like in opengl render > http://pastebin.com/mt82sMyi >Thanks for the confirmation. That’s what I thought too. I will start to dig deeper. The testgles,
testgles2 work just fine on the tablet. I will create a minimal test and see when I can figure out.Cheers,
Alvin
Hello,
I have created a barebones program that uses FFMPEG to retrieve the frames from a MP4. With the YUV GLES patch I see scrambled images (attached is a
small screenshot) when I run the program on Android (device and emulator). The images display correctly on my desktop (no surprise I guess since it
uses opengl). When I compile using the previous SDL2 (w/o patch, from 26 May 2014), the images display correctly on Android (device and emulator).
With both revisions of SDL2, I create the YUV texture once using:
yuv_texture = SDL_CreateTexture(renderer, SDL_PIXELFORMAT_YV12, SDL_TEXTUREACCESS_STATIC, ffm_codec_ctxt->width, ffm_codec_ctxt->height)
and I update the YUV texture, when a frame is available, using:
SDL_UpdateYUVTexture(yuv_texture, NULL, \
ffm_frame->data[0], ffm_frame->linesize[0], \
ffm_frame->data[1], ffm_frame->linesize[1], \
ffm_frame->data[2], ffm_frame->linesize[2]
Here’s some info I have dumped using SDL2’s (w/ patch) platform functions:
libSDL: compiled with=2.0.3 linked against=2.0.3
Platform: Android Cores=2 CacheL1=128 kb System RAM=722 MB
Window: 0x1ca2598 1280x752 at 16bpp SDL_PIXELFORMAT_RGB565 Rmask=0xf800 Gmask=0x7e0 Bmask=0x1f Amask=0x0
Renderer: 0x1bab798 opengles2 SW=NO HWACCEL=YES VSYNC=YES TARGETTEXTURE=YES MaxTexure=2048x2048
Renderer: 0x1bab798 6 Available Textures
Renderer: 0x1bab798 SDL_PIXELFORMAT_ABGR8888
Renderer: 0x1bab798 SDL_PIXELFORMAT_ARGB8888
Renderer: 0x1bab798 SDL_PIXELFORMAT_RGB888
Renderer: 0x1bab798 SDL_PIXELFORMAT_BGR888
Renderer: 0x1bab798 SDL_PIXELFORMAT_YV12
Renderer: 0x1bab798 SDL_PIXELFORMAT_IYUV
Without the patch, the Renderer supports only the first 4 pixel formats. Other than that, the info is the same.
I have a suspicion that the issues is pixel format related, but was wondering if someone with more experience with OpenGLES recognises this type of
problem.
Cheers,
Alvin
-------------- next part --------------
A non-text attachment was scrubbed…
Name: yuv_opengles.jpg
Type: image/jpeg
Size: 20296 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140612/e93d2100/attachment-0001.jpgOn 09/06/14 16:33, Alvin Beach wrote:
On 09/06/14 15:20, Sam Lantinga wrote:
On Mon, Jun 9, 2014 at 11:15 AM, Alvin Beach <@Alvin_Beach mailto:Alvin_Beach> wrote:
On 07/06/14 15:36, Sam Lantinga wrote:
> On Fri, Jun 6, 2014 at 4:30 AM, dront78 <dront78 at gmail.com <mailto:dront78 at gmail.com> <mailto:dront78 at gmail.com <mailto:dront78 at gmail.com>>> wrote:
It looks like a bug that needs to be investigated. Can you report this on
bugzilla, and include a link to the full test case with any necessary data
to replicate this?
Thanks!On Thu, Jun 12, 2014 at 9:23 AM, Alvin Beach wrote:
On 09/06/14 16:33, Alvin Beach wrote:
On 09/06/14 15:20, Sam Lantinga wrote:
It should be transparent and just work.
On Mon, Jun 9, 2014 at 11:15 AM, Alvin Beach <alvinbeach at gmail.com <mailto:alvinbeach at gmail.com>> wrote:
[snip] My app renders YUV images (decoded by ffmpeg from a mp4) andthought I’d test this patch out.
When I run the app on my Samsung Galaxy Tab 10.1 (Android 4.0.4), the YUV images are scrambled (diagonal lines -multi colour). Previously, the
YUV images render just fine using SDL_PIXELFORMAT_YV12. I tried SDL_PIXELFORMAT_IYUV and see the same scrambled behaviour. With this patch/optimisation applied, should I be handling YUVimages differently? Or should
this patch be transparent (e.g. just work)? Thanks, Alvin On 07/06/14 15:36, Sam Lantinga wrote: > Looks good, thanks! > https://hg.libsdl.org/SDL/rev/bc5ec1b6904c > > > On Fri, Jun 6, 2014 at 4:30 AM, dront78 <dront78 at gmail.com <mailto:dront78 at gmail.com> <mailto:dront78 at gmail.com <mailto:dront78 at gmail.com>>> wrote: > > __ > finally I got this working like in opengl render > http://pastebin.com/mt82sMyi >Thanks for the confirmation. That’s what I thought too. I will start to
dig deeper. The testgles,
testgles2 work just fine on the tablet. I will create a minimal test and
see when I can figure out.Cheers,
Alvin
Hello,
I have created a barebones program that uses FFMPEG to retrieve the frames
from a MP4. With the YUV GLES patch I see scrambled images (attached is a
small screenshot) when I run the program on Android (device and emulator).
The images display correctly on my desktop (no surprise I guess since it
uses opengl). When I compile using the previous SDL2 (w/o patch, from 26
May 2014), the images display correctly on Android (device and emulator).With both revisions of SDL2, I create the YUV texture once using:
yuv_texture = SDL_CreateTexture(renderer, SDL_PIXELFORMAT_YV12,SDL_TEXTUREACCESS_STATIC, ffm_codec_ctxt->width, ffm_codec_ctxt->height)
and I update the YUV texture, when a frame is available, using:
SDL_UpdateYUVTexture(yuv_texture, NULL, \ ffm_frame->data[0], ffm_frame->linesize[0], \ ffm_frame->data[1], ffm_frame->linesize[1], \ ffm_frame->data[2], ffm_frame->linesize[2]Here’s some info I have dumped using SDL2’s (w/ patch) platform functions:
libSDL: compiled with=2.0.3 linked against=2.0.3
Platform: Android Cores=2 CacheL1=128 kb System RAM=722 MB
Window: 0x1ca2598 1280x752 at 16bpp SDL_PIXELFORMAT_RGB565 Rmask=0xf800
Gmask=0x7e0 Bmask=0x1f Amask=0x0
Renderer: 0x1bab798 opengles2 SW=NO HWACCEL=YES VSYNC=YES
TARGETTEXTURE=YES MaxTexure=2048x2048
Renderer: 0x1bab798 6 Available Textures
Renderer: 0x1bab798 SDL_PIXELFORMAT_ABGR8888
Renderer: 0x1bab798 SDL_PIXELFORMAT_ARGB8888
Renderer: 0x1bab798 SDL_PIXELFORMAT_RGB888
Renderer: 0x1bab798 SDL_PIXELFORMAT_BGR888
Renderer: 0x1bab798 SDL_PIXELFORMAT_YV12
Renderer: 0x1bab798 SDL_PIXELFORMAT_IYUVWithout the patch, the Renderer supports only the first 4 pixel formats.
Other than that, the info is the same.I have a suspicion that the issues is pixel format related, but was
wondering if someone with more experience with OpenGLES recognises this
type of
problem.Cheers,
Alvin
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
After performing a few experiments, the issue seems to be with padded, non-contiguous YUV data. I created the following bug entry:
https://bugzilla.libsdl.org/show_bug.cgi?id=2595
Cheers,
AlvinOn 15/06/14 17:03, Sam Lantinga wrote:
It looks like a bug that needs to be investigated. Can you report this on bugzilla, and include a link to the full test case with any necessary data
to replicate this?Thanks!
I think this is fixed, thanks. Can you confirm?On Fri, Jun 20, 2014 at 8:12 AM, Alvin Beach wrote:
On 15/06/14 17:03, Sam Lantinga wrote:
It looks like a bug that needs to be investigated. Can you report this
on bugzilla, and include a link to the full test case with any necessary
data
to replicate this?Thanks!
After performing a few experiments, the issue seems to be with padded,
non-contiguous YUV data. I created the following bug entry:https://bugzilla.libsdl.org/show_bug.cgi?id=2595
Cheers,
Alvin
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org