On 6/19/23 04:14, Thilo Borgmann wrote:
Am 18.06.23 um 23:21 schrieb Leo Izen:
On 6/17/23 10:26, Thilo Borgmann wrote:
Am 17.06.23 um 16:02 schrieb Leo Izen:
On 6/17/23 04:11, Thilo Borgmann wrote:
While the yuvj pixel formats are deprecated lots of code still relies
on them to be set. Without setting a yuvj420p pixel format VP9
decoding ends up incorrectly due to auto conversion.
I oppose this on principle. If there's code that relies on YUVJ
being set, then *that code* needs to be changed so it respects the
AVFrame->color_range field. Which code is working improperly with this?
I don't like adding YUVJ stuff either. If I do
./ffmpeg -i full-range-in.mp4 -c:v libvpx-vp9 -lossless 1
lossless-out.mp4
and then comparing the frames, they are not equal. E.g. by
./ffmpeg -i full-range-in.mp4 -i lossless-out.mp4 -filter_complex
ssim -f crc -
they are not 1.0 in ssim terms.
Are you sure? I just tested a sample and found that I got exactly 1.0
in ssim terms. Do you have a link to a sample for which this fails?
IIRC I had the same impression when testing, I think I mixed up patched
and unpatched ffmpeg builds.
Anyway, happy you retest, I used
./ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 -pix_fmt
yuvj420p -color_range pc full-range-in.mp4
to generate my input sample. I cannot test myself again until Thursday,
my Laptop is not equipped with libvpx.
I used: ./ffmpeg -i input.mkv -vf libplacebo=format=yuv420p:range=pc -c
ffv1 full-range-in.mkv
I wonder if using yuv420p with pc range changes the results. Running
ffmpeg -i full-range-in.mkv by itself reports ffv1, yuv420p(pc,
progressive) as its format.
- Leo Izen
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
