search

ffvvc / FFmpeg

VVC Decoder for ffmpeg
Other
48 stars 12 forks source link

Intra Block Copy is not implemented - Error Decoding H.266 VVC + AC3 .ts stream #187

Closed FranceBB closed 3 months ago

FranceBB commented 5 months ago

I produced the following test files internally from XDCAM-50 mezzanine files:

Currently, the only one that can be properly decoded by ffvvc is Sample1, ColorBars, as all the other ones make use of Intra Block Copy which has not been implemented yet. Upon decoding, the following message is reported:

frame 78, P( 14, 1) failed with -1163346256
Intra Block Copy is not implemented.
Your file has a feature which has not been implemented.
Decoding error: Not yet implemented in FFmpeg, patches welcome

Yes, patches are welcome, but what I can provide is the samples themselves (a tiny part of them, trimmed, of course) which you can find here (link available for 7 days): https://we.tl/t-ztfQeVjxNP

How to reproduce:

ffmpeg.exe -benchmark -i "Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts" -f null out.null
ffmpeg.exe -benchmark -i "Judas and the Black Messiah SD H266 Main10 3Mbits 25p YV12 BT601 SDR 10bit AC3 2ch 48000Hz.ts" -f null out.null
ffmpeg.exe -benchmark -i "The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts" -f null out.null

Tested on the latest master from 17-01-2024, built at 12:52. Link to the Windows 10 x64 build to reproduce: ffmpeg-N-113344-gbe4fcf027b-win64-gpl.zip

nuomi2021 commented 5 months ago

Thank you for the report. Yes. IBC is not supported yet. We are busy pushing asm code upstream. After the ALF ASM code was upstreamed, We will resume https://github.com/ffvvc/FFmpeg/pull/169

nuomi2021 commented 4 months ago

@FranceBB I have a workable version at my local. All IBC conformance clips are passed. But the code still needs some refact. Could you share the clips again? thank you

FranceBB commented 4 months ago

Hey Nuo, I'm really glad to hear that! :) Here are the clips again, link valid for 7 more days: https://we.tl/t-V57VmTYPoS

Thank you in advance on behalf of the Avisynth community. ;)

nuomi2021 commented 4 months ago

Yes, it runs smoothly on my laptop. Thank you for your excellent work on Avisynth. Although I'm not involved in fansubbing, I've greatly benefited from your contributions.

nuomi2021 commented 4 months ago

@FranceBB , please help try https://patchwork.ffmpeg.org/project/ffmpeg/patch/TYSPR06MB6433D9436D9F75AEB1A2B5D2AA562@TYSPR06MB6433.apcprd06.prod.outlook.com/

BTW, If you seek the ts file, it will have some gray frames. we can reproduce it with hevc too. Do you happen to know if it's a feature or bug in ts demuxer?

wget https://s3.amazonaws.com/x265.org/video/Tears_400_x265.mp4 && ffmpeg -i Tears_400_x265.mp4 -c:v copy tos.ts
ffplay tos.ts
FranceBB commented 4 months ago

It's a bug, it shouldn't happen. Essentially a .ts is a Transport Stream which means that it's generally used by broadcasting companies upon playout. Unlike other containers like .mp4, it doesn't store info about where keyframes are as those are only stored in the video stream. The reason why you're seeing grey frames is that when you seek to, let's say, frame 65, if that one is a P (partially predicted) or a B (bi-predicted) frame, the ffmpeg decoder won't have the reference frames to display the picture. On the other hand, if the frame you land on while seeking is an I (Intra) frame, then the picture is displayed correctly as it doesn't need any reference given that Intra is the frame containing all the blocks and macroblocks. Now, going back to the frame 65 analogy, what a proper decoder should do if you land on a frame P or B is going back to the reference keyframe of the GOP (let's say frame 61) and then use all the frames afterwards to display frame 65. By the way, to keep the seeking process from taking too long, broadcasters generally use a --keyint value equal to the frame rate, like --keyint 25 for 25fps, so that there's always a keyframe every second. ;)

Anyway, yeah, ideally this should be addressed as a future improvement in the TS ffmpeg demuxer I guess, for all codecs, not just H.266, as the same happens with H.265, H.264 and MPEG-2. I guess it's a story for another day, though, but hopefully someone will pick that up.

Needless to say, linear seeking should work, namely starting the decoding at the beginning of the file until the very end without moving back and forth.

Nomis101 commented 4 months ago

https://patchwork.ffmpeg.org/project/ffmpeg/patch/TYSPR06MB6433D9436D9F75AEB1A2B5D2AA562@TYSPR06MB6433.apcprd06.prod.outlook.com/

By the way, all samples from https://github.com/ffvvc/FFmpeg/issues/181#issuecomment-1881870997 and some others I have tested do play (ffplay) und convert (ffmpeg) without any issue with current ffmpeg and this patch set. Thanks!

nuomi2021 commented 4 months ago

🎉, thank you. @FranceBB @FranceBB

but hopefully someone will pick that up.

@FranceBB could you help report a bug to the ffmpeg bug system? The community may not know it. or have a reasonable explaining for it.

6ws commented 4 months ago

Hi @nuomi2021 I am getting hash mismatches for IBC bitstreams that are >1 min generated with vvenc. Can you reproduce?

nuomi2021 commented 4 months ago

@6ws, could you share the clip? I tried "vvencapp -i vidyo1_720p_60fps.y4m --preset faster --additional "IBC=1" -o vidyo1.266" It's no issue, maybe it did not generate an IBC block.

6ws commented 4 months ago

vvencapp -i sintel_trailer_2k_1080p24.y4m --preset fast --additional "IBC=1" -o sintel.266

MD5 mismatch occurs at frame 110.

nuomi2021 commented 4 months ago

thank you @6ws , please try https://github.com/ffvvc/FFmpeg/pull/199/commits/1f9064a3523215da0683d6d2f948cc5db14528fa

6ws commented 4 months ago

LGTM with the samples I have.

nuomi2021 commented 3 months ago

fixed by https://github.com/FFmpeg/FFmpeg/commit/49ba613146b2e36001d6fcdda0c89b2142f2bb62 close this since all things are fixed. please open a new one if you find any new issue thank you all for help on this