[maemo-developers] Help with YV12->YUV420 converter

[From: Charles 'Buck' Krasic]

Hi Simon,

I did a simple DSP yuv->rgb converter a year (or two?) ago.

I have not looked at your code, so forgive me if I say something obvious.

The one thing that bit me was the fact that the DSP/toolchain did not 
handle access to data objects larger than 64k, due to 16 bit 
restrictions on the DSP.  My understanding is that later toolchains 
removed those limitations (although I do not know if they ever became 
freely available).   I wrote very ugly workarounds to handle cases where 
pointer values crossed 16bit boundaries.  I worked, but overall my code 
was horribly slow.  If this is news to you, I can provide more details.

-- Buck

ps there should be some messages about my DSP work in the 
maemo-developers archives.

Simon Pickering wrote:

>Hello everyone,
>
>I've been hacking together a YV12 to YUV420 converter to run on the DSP. I
>have running code, but there are some artefacts on the screen. I was hoping
>that some of you with more experience of video stuff might spot an obvious
>error.
>
>If you want to run the code, you need to make some changes to your setup
>(including a kernel patch). I'm happy to give instructions, but thought in
>the first instance more eyes looking at the output and the code might turn
>up some things I've missed.
>
>I have two images showing the sorts of visual artefacts I'm getting [1,2],
>as you can see they are different frames but very similar. The green regions
>seem to stay in those general locations. Other than that, the image looks
>quite reasonable. Any thoughts on what might cause this sort of localised
>glitching?
>
>The source video is here [3]. It was converted to a file called stream.yuv
>by the following mplayer command: "mplayer -vo yuv4mpeg comet_jupiter_1.mpg"
>
>I have checked the resultant YV12 file and there are no glitches in any of
>the planes.
>
>The DSP code is here [4] and ARM code is here [5]. The code is messy (read
>development), and un-optimised (lots of divisions of unchanging variables
>within the main loop for example). If anyone has any thoughts about
>optimisation I would be interested to hear them, but the immediate problem
>is getting it to output correctly.
>
>The ARM code takes two input arguments, a filename and a letter which
>indicates how to output the data. The case we're interested in is a letter
>code of "y" indicating that we want to do YUV420 output. Note that there is
>a typo in the ARM code [5] on line 198 (should read 45 uchars rather than
>46), however this is luckily dealt with by the code which follows so
>shouldn't cause a problem.
>
>The general code flow is: 
>ARM side construct a struct to pass to the DSP to tell it the input/output
>formats and the size of the frame; 
>ARM side read a frame's worth of data from file and place it in shared
>memory; 
>ARM side call ioctl to trigger DSP code; 
>DSP side catch ioctl in yv12_convert_rcv_tctl(), call
>yv12_convert_draw_buffer() which in turn calls convert_YV12_to_YUV420() in
>this specific case. In this function the data are copied to the framebuffer
>and converted en route. The framebuffer update is then called and it's
>output to the screen.
>
>Any thoughts, comments, etc. gladly accepted.
>
>Thanks,
>
>
>Simon
>
>P.S. If there's a comment/piece of code you don't understand it's probably
>because I've fiddled with the code so much and it got left behind. Please
>ask :).
>
>[1] http://people.bath.ac.uk/enpsgp/nokia770/dsp/PICT0050.JPG
>[2] http://people.bath.ac.uk/enpsgp/nokia770/dsp/PICT0052.JPG
>[3]
>http://hubblesource.stsci.edu/sources/video/clips/details/images/comet_jupit
>er_1.mpg
>[4]
>http://people.bath.ac.uk/enpsgp/nokia770/dsp/test-yv12-convert-and-output/N8
>x0/yv12_convert.c
>[5]
>http://people.bath.ac.uk/enpsgp/nokia770/dsp/test-yv12-convert-and-output/ar
>m/test_yv12_output.c
>
>_______________________________________________
>maemo-developers mailing list
>maemo-developers at maemo.org
>https://lists.maemo.org/mailman/listinfo/maemo-developers
>  
>