#10989 closed defect (fixed)
"color" video source fails to handle "size=1x1"?
Reported by: | MasterQuestionable | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avfilter |
Version: | git-master | Keywords: | color video source |
Cc: | MasterQuestionable | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
͏ ffmpeg -y -nostdin -nostats -v debug -f lavfi -i "color=#ff0000:1x1[0]; color=#0000ff:1x1[1]; [0][1]vstack,split[0][1]; [0]vflip,[1]hstack" -vframes 1 -compression_level 10 -pred none "0.png"
͏ ffmpeg -y -nostdin -nostats -v debug -f lavfi -i "color=#ff0000:1x1,format=rgb24[0]; color=#0000ff:1x1,format=rgb24[1]; [0][1]vstack,split[0][1]; [0]vflip,[1]hstack" -vframes 1 -compression_level 10 -pred none "0.png" -vframes 1 -vf "format=yuvj420p" -sws_flags spline+accurate_rnd+full_chroma_int -lossless 1 -q 100 -compression_level 6 "1.webp"
͏ It appears "color" asserts "yuv420p" pixel format: which might be problematic (in particular for writing PNG alike).
͏ Semantic-wise, it's using RGB notation representing colors: while covertly collapsed to subsampled YUV...
͏ See also:
͏ https://ffmpeg.org/ffmpeg-filters.html#color
͏ https://ffmpeg.org/ffmpeg-filters.html#split_002c-asplit
Change History (8)
comment:1 by , 8 months ago
comment:2 by , 8 months ago
͏ Run it things should be very apparent.
͏ See also:
͏ https://trac.ffmpeg.org/wiki/colorspace
͏ https://gist.github.com/Jim-Bar/3cbba684a71d1a9d468a6711a6eddbeb#420-422--and-subsampling
͏ Expected behavior (perhaps?):
͏ Similar colors represented using RGB probably shouldn't be asserted YUV (thus the covert conversion).
comment:4 by , 8 months ago
͏ Run the 2 commands; also the "size=3x3" variant for the 1st.
͏ Notice keyword "yuv420".
͏ "1.webp" as pseudo-reference demonstrating the impact.
comment:5 by , 8 months ago
Please follow https://ffmpeg.org/bugreports.html when reporting bugs, and provide the console output of your command lines.
comment:6 by , 8 months ago
͏ I try to make things as succinct as possible.
͏ It appears this somehow failed your parsing.
͏ Would you help me debugging by feedback some your parsing details? Thanks.
͏ |1| Did you ever run the mentioned command?
͏ |2| Do you read things out-of-order? (maybe even asynchronous parallel)
͏ |2.1| Or strictly blocking FIFO (First-In First-Out)?
͏ |3| Did you read the linked See also?
comment:7 by , 8 months ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in 77fc047bd91eaef615a2c36b93ee23d7d27e7d25. Used pixel format is auto-negotiated, so you can force using rgb if you want. (e.g. color=s=1x1:c=red,format=rgba).
Oops, edited commit hash to point to proper commit.
comment:8 by , 8 months ago
͏ So it appears you didn't ever run the command...
͏ "color=#ff0000:1x1,format=rgb24" alike already work before the change.
͏ As for this commit's implication... unsure. (silently corrupted to YUV 4:2:0?)
What is the expected behaviour, and what is the actual? What is the error message?