<p>On Oct 13, 2011 9:12 AM, "Drabner" <<a href="mailto:drabner@zoobe.com">drabner@zoobe.com</a>> wrote:<br>
><br>
> It seems I have found the reason for the weird behaviour.<br>
> It is this line:<br>
><br>
> *//---------------------------------------------------------*<br>
> memcpy(textureDest,<br>
>      [b]_videoFrames->GetFrames()[_videoFramesPassed]->data[/b],<br>
>      4*640*360);<br>
> *//---------------------------------------------------------*<br>
><br>
> Instead of using ->data of the AVFrame*, you have to use ->data[0], at least<br>
> when using PIX_FMT_ARGB. data itself is only a pointer to four streams or<br>
> layers or whatever of picture data. And the linesize of AVFrame tells you<br>
> where to look for the data, it also points to four streams/layers.</p>
<p>Good!</p>
<p>The data/data[0] choise is confusing. But usually it causes a compiler warning. Didn't you notice one</p>
<p>> Of course, you have to find this out on your own and waste a day with it.<br>
> Gotta love the clarity of the library if you've not studied video codecs ;)<br>
><br>
> However, I still have a problem of some sort...<br>
> The video is blue. As if the B value is always too high. It works well when<br>
> I fill every pixel of the picture like this:<br>
><br>
> *//------------------------------------------- --------------*<br>
> int videoSrc[640*360] = {0};<br>
> for (int i = 0; i < (640*360); i++)<br>
> {<br>
>   uint8_t* pixel =<br>
> (uint8_t*)(_videoFrames->GetFrames()[_videoFramesPassed]->data[0]+i*4);<br>
>   videoSrc[i] = D3DCOLOR_ARGB(pixel[0],<br>
>                  pixel[1],<br>
>                  pixel[2],<br>
>                  pixel[3]);<br>
> }<br>
> memcpy(   textureDest, videoSrc, 4*640*360);<br>
> *//---------------------------------------------------------*</p>
<p>Most likely, this is the reverse byte order in ARGB. Try BGRA format in scale.</p>
<p>Cheers,<br>
Alex</p>
<p>> Yeah I know, you could skip that last memcpy and fill textureDest directly<br>
> within the loop.<br>
> But anyway... Obviously, this goes kinda heavy on the performance compared<br>
> to just one simple memcpy.<br>
><br>
> If anyone has an idea what's going on there, I'd be grateful :)<br>
><br>
> --<br>
> View this message in context: <a href="http://libav-users.943685.n4.nabble.com/Converting-mpg-file-to-ARGB-frames-tp3894271p3900749.html">http://libav-users.943685.n4.nabble.com/Converting-mpg-file-to-ARGB-frames-tp3894271p3900749.html</a><br>

> Sent from the libav-users mailing. list archive at Nabble.com.<br>
> _______________________________________________<br>
> Libav-user mailing list<br>
> <a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>
> <a href="http://ffmpeg.org/mailman/listinfo/libav-user">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
</p>