YUV video to RGB image export color conversion issue

[Peter B.]

Hello,

I'm currently developing a test-video (for automatically finding  
field/frame drops in A/D converters), and I've run into a  
color-conversion issue with ffmpeg:

When extracting images from the video (yuv422p), the color values in  
the interlaced areas of the video are deviate from their original  
beyond recognition.

I've uploaded the source video [1] and the resulting images on my  
webserver, so you can more easily see what I mean:
http://download.das-werkstatt.com/pb/mthk/examples/color_problem/problem.html

I've tried to extract the images with 3 different tools:
1) ffmpeg
2) mplayer
3) virtualdub

VirtualDub exports the images as I'd expect it, whereas mplayer and  
ffmpeg don't. :(

Here's the ffmpeg call I've used:
"ffmpeg -vframes 4 -i 'testvideo_color_rectangles-YUV422P.avi'  
-pix_fmt rgb24 -f image2 '%03d.bmp'"

(It's also strange, that the resulting bitmap isn't RGB24, but BGR24)


What am I doing wrong?

Thank you very much for any hint/help.

Yours,
Pb


== References:
[1]  
http://download.das-werkstatt.com/pb/mthk/examples/color_problem/testvideo_color_rectangles-YUV422P.avi


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Кирилл Гаврилов]

Hello,

What am I doing wrong?
>
it seems to be a BUG in swscale yuv422p -> rgb conversion (probably
conversion ignores that height of U and V planes has full height as Y or
make some row disaligment).
This is NOT an error in the decoder.
I check my own yuv422p converter via GLSL with FFmpeg libraries and it works
like your images for VirtualDub.

(It's also strange, that the resulting bitmap isn't RGB24, but BGR24)
>
BMP format always stores colors in BGR order...

Check that your ffmpeg version is up-to-date, check ffmpeg BUG tracker and
similar BUG doesn't registered - do this.
-----------------------------------------------
Kirill Gavrilov,
Software designer. <[hidden email]>
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Peter B.]

Quoting ?????? ???????? <[hidden email]>:

> it seems to be a BUG in swscale yuv422p -> rgb conversion (probably
> conversion ignores that height of U and V planes has full height as Y or
> make some row disaligment).

Hm.. I've suspected that it had something to do with line-alignment. It


> This is NOT an error in the decoder.
> I check my own yuv422p converter via GLSL with FFmpeg libraries and it works
> like your images for VirtualDub.

Good to know. Thanks!


>> (It's also strange, that the resulting bitmap isn't RGB24, but BGR24)
> BMP format always stores colors in BGR order...

Ah, I see!


> Check that your ffmpeg version is up-to-date,

I've tested it with ffmpeg SVN snapshot from January 18th. Will test  
again today with the current git head.


> check ffmpeg BUG tracker and similar BUG doesn't registered - do this.

Will do.
Just wanted to make sure that it's not just a commandline syntax error  
or something like that. ;)


Thanks,
Pb
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

On 3/1/11 10:44 AM, Кирилл Гаврилов wrote:
> Hello,
>
> What am I doing wrong?
>>
> it seems to be a BUG in swscale yuv422p -> rgb conversion (probably
> conversion ignores that height of U and V planes has full height as Y or
> make some row disaligment).

No. libswscale correctly converts yuv422p -> rgb regarding plane
height/width.
If there is a bug, it's somewhere else.

[...]

--
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Peter B.]

Quoting ?????? ???????? <[hidden email]>:

> This is NOT an error in the decoder.
> I check my own yuv422p converter via GLSL with FFmpeg libraries and it works
> like your images for VirtualDub.

I've now tried to verify that it's a subsampling 422 issue - and it  
really seems to be!

I've converted the video source from yuv422p to yuv444p and *then*  
extracted the images and they were fine (see [1]).


Regards,
Pb


== References
[1]  
http://download.das-werkstatt.com/pb/mthk/examples/color_problem/problem.html
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

Hi,

On 3/2/11 12:26 AM, Peter B. wrote:

> Quoting ?????? ???????? <[hidden email]>:
>
>> it seems to be a BUG in swscale yuv422p -> rgb conversion (probably
>> conversion ignores that height of U and V planes has full height as Y or
>> make some row disaligment).
>
> Hm.. I've suspected that it had something to do with line-alignment. It
>
>
>> This is NOT an error in the decoder.
>> I check my own yuv422p converter via GLSL with FFmpeg libraries and it
>> works
>> like your images for VirtualDub.
>
> Good to know. Thanks!
>
>
>>> (It's also strange, that the resulting bitmap isn't RGB24, but BGR24)
>> BMP format always stores colors in BGR order...
>
> Ah, I see!
>
>
>> Check that your ffmpeg version is up-to-date,
>
> I've tested it with ffmpeg SVN snapshot from January 18th. Will test
> again today with the current git head.
>
>
>> check ffmpeg BUG tracker and similar BUG doesn't registered - do this.
>
> Will do.
> Just wanted to make sure that it's not just a commandline syntax error
> or something like that. ;)

Indeed, there is something weird going on. Please submit a bugreport
following: www.ffmpeg.org/bugreports.html

--
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Peter B.]

Quoting Baptiste Coudurier <[hidden email]>:
> Indeed, there is something weird going on. Please submit a bugreport
> following: www.ffmpeg.org/bugreports.html

Done. ;)

Title: 'yuv422p -> rgb color conversion is incorrect'
https://roundup.ffmpeg.org/issue2632

I can imagine that this affects all image extractions from yuv422p  
material, or not?

Thanks,
Pb



_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Кирилл Гаврилов]

>
> I can imagine that this affects all image extractions from yuv422p
> material, or not?
>
You have a synthetic images (row color interlaced), I don't think that on
regular images result will be so different...

-----------------------------------------------
Kirill Gavrilov,
Software designer.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Peter B.]

Quoting ?????? ???????? <[hidden email]>:
>> I can imagine that this affects all image extractions from yuv422p
>> material, or not?
>>
> You have a synthetic images (row color interlaced), I don't think that on
> regular images result will be so different...

For regular video footage, you're right.
In the end, it depends on the content, since for example generated  
overlays (e.g. text, effects, etc.) often produces completely  
different colors between fields.

However, you're right: for regular images, it's bearable. ;)

Regards,
Pb
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

On 03/02/2011 07:45 AM, Peter B. wrote:

> Quoting ?????? ???????? <[hidden email]>:
>>> I can imagine that this affects all image extractions from yuv422p
>>> material, or not?
>>>
>> You have a synthetic images (row color interlaced), I don't think that on
>> regular images result will be so different...
>
> For regular video footage, you're right.
> In the end, it depends on the content, since for example generated
> overlays (e.g. text, effects, etc.) often produces completely different
> colors between fields.
>
> However, you're right: for regular images, it's bearable. ;)

Try the attached patch.

--
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Peter B.]

Quoting Baptiste Coudurier <[hidden email]>:
> Try the attached patch.

Wow! That was fast.
Thank you very much. It works!

I've applied your patch to the "git-ff1efc5" revision.
I've tested the yuv422p -> rgb24 conversion and it now works as  
expected. Great!

Additionally, I've also tested yuv444p again, and also yuv420p as  
source - just to see that there are no regression side-effects  
introduced. ;)

I've also added the new/correct output images to my comparison page  
[1], in case someone wants to check for him/herself.


Again, thank you very much..

Regards,
Pb


== References:
[1]
http://download.das-werkstatt.com/pb/mthk/examples/color_problem/problem.html


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Peter B.]

Hello,

I just wanted to ask the current status of this issue, since I saw that
the problem still exists in the current git version.

I have tested the patch suggested by Baptiste Coudurier and I'm using it
extensively without problems. Is there anything I could do to help
getting that fix into trunk? :)
e.g. re-post this issue on ffmpeg-devel?

Thanks and regards,
Peter B.


Baptiste Coudurier wrote:

> On 03/02/2011 07:45 AM, Peter B. wrote:
>> Quoting ?????? ???????? <[hidden email]>:
>>>> I can imagine that this affects all image extractions from yuv422p
>>>> material, or not?
>>>>
>>> You have a synthetic images (row color interlaced), I don't think
>>> that on
>>> regular images result will be so different...
>>
>> For regular video footage, you're right.
>> In the end, it depends on the content, since for example generated
>> overlays (e.g. text, effects, etc.) often produces completely different
>> colors between fields.
>>
>> However, you're right: for regular images, it's bearable. ;)
>
> Try the attached patch.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Peter B.]

Baptiste Coudurier wrote:
> Try the attached patch.
oops. sorry for top-posting previously.

Peter B.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user