Opened 13 months ago
Last modified 13 months ago
#10595 open defect
photocd file fails to decode
Reported by: | ami_stuff | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | git-master | Keywords: | photocd |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
https://telparia.com/fileFormatSamples/image/pcd/maddog.pcd
./ffmpeg -i maddog.pcd -y out.jpg ffmpeg version N-112164-gcb26b85953 Copyright (c) 2000-2023 the FFmpeg developers built with gcc 11 (Ubuntu 11.4.0-1ubuntu1~22.04) configuration: libavutil 58. 25.100 / 58. 25.100 libavcodec 60. 27.100 / 60. 27.100 libavformat 60. 13.100 / 60. 13.100 libavdevice 60. 2.101 / 60. 2.101 libavfilter 9. 11.100 / 9. 11.100 libswscale 7. 3.100 / 7. 3.100 libswresample 4. 11.100 / 4. 11.100 Input #0, image2, from 'maddog.pcd': Duration: 00:00:00.04, start: 0.000000, bitrate: 867942 kb/s Stream #0:0: Video: photocd, yuv420p(pc, bt709/bt709/iec61966-2-1), 3072x2048, 25 fps, 25 tbr, 25 tbn Stream mapping: Stream #0:0 -> #0:0 (photocd (native) -> mjpeg (native)) Press [q] to stop, [?] for help [vist#0:0/photocd @ 0x55c65327b900] Decoding error: Invalid data found when processing input [swscaler @ 0x55c6532b5140] deprecated pixel format used, make sure you did set range correctly [vost#0:0/mjpeg @ 0x55c653280380] No filtered frames for output stream, trying to initialize anyway. [vost#0:0/mjpeg @ 0x55c653280380] No information about the input framerate is available. Falling back to a default value of 25fps. Use the -r option if you want a different framerate. Output #0, image2, to 'out.jpg': Metadata: encoder : Lavf60.13.100 Stream #0:0: Video: mjpeg, yuvj420p(pc, progressive), 3072x2048, q=2-31, 200 kb/s, 25 fps, 25 tbn Metadata: encoder : Lavc60.27.100 mjpeg Side data: cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: N/A [vist#0:0/photocd @ 0x55c65327b900] Decode error rate 1 exceeds maximum 0.666667 [out#0/image2 @ 0x55c65327be80] video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown [out#0/image2 @ 0x55c65327be80] Output file is empty, nothing was encoded(check -ss / -t / -frames parameters if used) frame= 0 fps=0.0 q=0.0 Lsize=N/A time=N/A bitrate=N/A speed=N/A Conversion failed!
Change History (13)
comment:1 by , 13 months ago
Version: | unspecified → git-master |
---|
comment:2 by , 13 months ago
comment:4 by , 13 months ago
Status: | new → open |
---|
Yep. Other pcd files work great (except for color management, but whatever).
comment:6 by , 13 months ago
Replying to Elon Musk:
Here it decodes always same colors.
Which are wrong colors. I told you years ago it uses xvYCC, not sRGB transfer. It is like you cannot read the English language.
comment:7 by , 13 months ago
MPV displays correct colors, better one then that app that converts it to rgb ppm.
FFplay does not support most of colorspace stuff.
comment:8 by , 13 months ago
MPV displays correct colors
No. You need PQ to correctly show the colors, as the content is HDR and WCG (both outside 100 nits and BT.709 primaries).
Change that to AVCOL_TRC_IEC61966_2_4. Part 4, not 1. Then implement correct quantisation: linear RGB values are from -0.20 to 2.00, while nonlinear RGB' are from -0.43357 to 1.402278, where reference white (perfect, non-fluorescent, white-reflecting diffuser in the original scene) is 1.0, just like in BT.709. That is done by a different MATRIX THAT IS NOT just avctx->colorspace = AVCOL_SPC_BT709; and avctx->color_range = AVCOL_RANGE_JPEG.
There is also a matrix from and to sRGB in Windows XP source code that leaked. Again, I told you all that 3 years ago. Open your eyes: https://trac.ffmpeg.org/ticket/5923#comment:7
comment:9 by , 13 months ago
Your entry is again, wrong, and full of errors.
Your understanding of this subject is pretty invalid.
Otherwise you would post patch(es) to solve this already.
comment:10 by , 13 months ago
Continue denying reality and not seeing a patch in that issue that implements own ff_yuv2rgb_coeffs.
comment:11 by , 13 months ago
You ARE denying reality, BTW. (On the left image from https://r0k.us/graphics/kodak/kodim23.html on the right original PCD converted to PNG with sRGB chunk https://www.math.purdue.edu/~lucier/PHOTO_CD/IMAGES/.)
comment:13 by , 13 months ago
decoder outputs in yuv not rgb.
That is why the code changes happen in pixfmt.h and https://trac.ffmpeg.org/attachment/ticket/5923/ycc.diff
And what software decodes it?