Chroma Artifacts on the right edge of some odd width 4:2:0 videos in ffplay

[Michael Niedermayer]

Summary of the bug:
How to reproduce:

./ffplay test25.nut
use the mouse to scale it up a bit to better see
and then repeatly press arrow left, each time on the right side a different
mix of colors appears

test25.nut is a mpeg4 yuv420p video with 25x25 size, infact codec and content seem not to matter

==1071990== Conditional jump or move depends on uninitialised value(s)
==1071990==    at 0x1324673: av_clip_uint8_c (common.h:208)
==1071990==    by 0x13260C3: yuv2plane1_8_c (output.c:426)
==1071990==    by 0x12FCC0D: lum_planar_vscale (vscale.c:53)
==1071990==    by 0x12F0E0A: swscale (swscale.c:498)
==1071990==    by 0x12F320A: scale_internal (swscale.c:1046)
==1071990==    by 0x12F239C: scale_cascaded (swscale.c:875)
==1071990==    by 0x12F27D4: scale_internal (swscale.c:937)
==1071990==    by 0x12F3BBD: ff_sws_slice_worker (swscale.c:1240)
==1071990==    by 0x13DC790: run_jobs (slicethread.c:65)
==1071990==    by 0x13DC866: thread_worker (slicethread.c:89)
==1071990==    by 0x694B608: start_thread (pthread_create.c:477)
==1071990==    by 0x6A85352: clone (clone.S:95)
==1071990==
==1071990== Thread 83:
==1071990== Conditional jump or move depends on uninitialised value(s)
==1071990==    at 0x1324673: av_clip_uint8_c (common.h:208)
==1071990==    by 0x132602D: yuv2planeX_8_c (output.c:416)
==1071990==    by 0x12FD038: chr_planar_vscale (vscale.c:100)
==1071990==    by 0x12F0E0A: swscale (swscale.c:498)
==1071990==    by 0x12F320A: scale_internal (swscale.c:1046)
==1071990==    by 0x12F239C: scale_cascaded (swscale.c:875)
==1071990==    by 0x12F27D4: scale_internal (swscale.c:937)
==1071990==    by 0x12F3BBD: ff_sws_slice_worker (swscale.c:1240)
==1071990==    by 0x13DC790: run_jobs (slicethread.c:65)
==1071990==    by 0x13DC866: thread_worker (slicethread.c:89)
==1071990==    by 0x694B608: start_thread (pthread_create.c:477)
==1071990==    by 0x6A85352: clone (clone.S:95)
==1071990==
==1071990== Conditional jump or move depends on uninitialised value(s)
==1071990==    at 0x1324673: av_clip_uint8_c (common.h:208)
==1071990==    by 0x132602D: yuv2planeX_8_c (output.c:416)
==1071990==    by 0x12FD09E: chr_planar_vscale (vscale.c:101)
==1071990==    by 0x12F0E0A: swscale (swscale.c:498)
==1071990==    by 0x12F320A: scale_internal (swscale.c:1046)
==1071990==    by 0x12F239C: scale_cascaded (swscale.c:875)
==1071990==    by 0x12F27D4: scale_internal (swscale.c:937)
==1071990==    by 0x12F3BBD: ff_sws_slice_worker (swscale.c:1240)
==1071990==    by 0x13DC790: run_jobs (slicethread.c:65)
==1071990==    by 0x13DC866: thread_worker (slicethread.c:89)
==1071990==    by 0x694B608: start_thread (pthread_create.c:477)
==1071990==    by 0x6A85352: clone (clone.S:95)

Regression since: c619d20906d039060efbeaa822daf8e949f3ef24

also -vf scale,format=rgb24 seems to avoid the issue

[Balling]

You are saying it is a regression but IMHO a bug with uninitialised values cannot just happen due to SDL changes of defaults in ffplay especially since a) such a bug with -vf scale=in_color_matrix=auto,format=gbrp is still there

b) ffplay was even more broken before was it not?