[FFmpeg-trac] #7199(swscale:new): Broken P010 colorspace conversion
FFmpeg
trac at avcodec.org
Fri Feb 12 22:33:08 EET 2021
#7199: Broken P010 colorspace conversion
------------------------------------+-----------------------------------
Reporter: thx4ever | Owner:
Type: defect | Status: new
Priority: normal | Component: swscale
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
------------------------------------+-----------------------------------
Comment (by Balling):
Replying to [comment:12 thx4ever]:
> i will try to decode a 10bit Samsung sample and get back as soon as
possible
So did you and what it is?
Also, I will point out that ffprobe says your attached annex b file is
yuv420p10le, not p010le.
Now I wanted to check how can you force p010le pixel_format. Now, there
can be bugs like was fixed in 04340e5e018603df5a158a5cddf81530005d8d2f.
So, checking out ffmpeg -h decoder=hevc it was strange... Like so:
{{{
Supported hardware devices: dxva2 (null) d3d11va cuda
}}}
What?? (null)? It is all good in linux. Also no pixel_formats present in
info. So I instead used
hevc_cuvid...
What was my surprise that it is now saying p010le in the output info but
it is still yuv420p10le after ffprobe.
Now, as said in description of P010, it is "like NV12, with 10bpp per
component, data in the high bits, zeros in the low bits", so it should NOT
be used in files? Dunno. It looks like it is output-only "fake" format and
P states for Perceptual Quantiser, which is HDR?? Dunno. There is some
strange vaapi presenting stuff going there:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/qv2PyTKpWVd6zJqsf3pwRO7gzci3X9OW3r2v3Kt9z1k@cp4-web-037.plabs.ch/
--
Ticket URL: <https://trac.ffmpeg.org/ticket/7199#comment:13>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list