FATE failures: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
Line 4: Line 4:


=== H.264 ===
=== H.264 ===
I've briefly analyzed MR3_TANDBERG_B and it appears that the first 41 frames are bitexact. After 42 frames there is a reset of POCs, and we drop all frames after that with a POC smaller than the POC of before the POC reset, causing a total of 41 frames to be dropped. A patch to fix this is pending.
MAIN/MR2_TANDBERG_E.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal
MAIN/MR3_TANDBERG_B.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal


tandberg 4/5 have large codec delays because of misordered frames, and the delay jumps randomly within the file. We don't preroll well enough to know the correct delay in advance and so at each point where we return a frame too far ahead in the future, we drop the preceeding frames once we get around to decoding them because we've already passed that point in units returned to the application. The correct solution for these would be to increase delay dynamically whenever we encounter a gap until either we're at max-delay, or until we've resolved the gap. almost certainly, max-delay should be settable in user applications so we can disable it for live/low-latency purposes. Q: should we return old frames also? The user may want to reorder himself (although this doesn't make much sense). Fate currently uses -strict 1 as a workaround for these samples, which simply forces codec-delay to 16. This is not the correct solution.
tandberg 4/5 have large codec delays because of misordered frames, and the delay jumps randomly within the file. We don't preroll well enough to know the correct delay in advance and so at each point where we return a frame too far ahead in the future, we drop the preceeding frames once we get around to decoding them because we've already passed that point in units returned to the application. The correct solution for these would be to increase delay dynamically whenever we encounter a gap until either we're at max-delay, or until we've resolved the gap. almost certainly, max-delay should be settable in user applications so we can disable it for live/low-latency purposes. Q: should we return old frames also? The user may want to reorder himself (although this doesn't make much sense). Fate currently uses -strict 1 as a workaround for these samples, which simply forces codec-delay to 16. This is not the correct solution.

Revision as of 12:07, 1 March 2012

Although FATE can appear green, in fact many of the samples in FATE are not bit-exact.

The following samples are not bit-exact.

H.264

tandberg 4/5 have large codec delays because of misordered frames, and the delay jumps randomly within the file. We don't preroll well enough to know the correct delay in advance and so at each point where we return a frame too far ahead in the future, we drop the preceeding frames once we get around to decoding them because we've already passed that point in units returned to the application. The correct solution for these would be to increase delay dynamically whenever we encounter a gap until either we're at max-delay, or until we've resolved the gap. almost certainly, max-delay should be settable in user applications so we can disable it for live/low-latency purposes. Q: should we return old frames also? The user may want to reorder himself (although this doesn't make much sense). Fate currently uses -strict 1 as a workaround for these samples, which simply forces codec-delay to 16. This is not the correct solution.

MAIN/MR4_TANDBERG_C.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal
MAIN/MR5_TANDBERG_C.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal

Other samples from the H264 conformance suite that don't play back correctly

FMO:

MAIN/FM1_FT_E.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal
MAIN/FM2_SVA_C.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal
MAIN/FM1_BT_B.h264 ... JF ( yuv420p @  176x144 /  25  fps) not equal

For this one, we output only 12 of a few hundred-or-so frames, unanalyzed beyond that:

MAIN/sp1_bt_a.h264 ... JF ( yuv420p @  176x144 /  25  fps) not equal

Looks like garbage, unanalyzed beyond that:

MAIN/H26L/BitstreamExchange/sp2_bt_b.h264 ... JF ( yuv420p @  176x144 /  25  fps) not equal

Cropping:

MAIN/CVFC1_Sony_C.jsv ... JF ( yuv420p @  338x274 /  25  fps) not equal

Looks like CAVLC-444 isn't completely implemented:

PP/PPCV444I-7.264 ... JF ( yuv420p @  48x80 /  25  fps) not equal
PP/PPCV444I4_Mitsubishi_A.264 ... JF ( yuv420p @  48x48 /  25  fps) not equal
PP/PPCV444I5_Mitsubishi_A.264 ... JF ( 50 fps @  25 tbr /  25  fps) not equal
PP/PPCV444I6_Mitsubishi_A.264 ... JF ( yuv420p @  48x48 /  25  fps) not equal
PP/Professional_profiles/PPCV444I1_Thomson_A.bits ... JF ( 50 fps @  25 tbr /  25  fps) not equal
PP/Professional_profiles/PPCV444I2_Thomson_A.bits ... JF ( 50 fps @  25 tbr /  25  fps) not equal
PP/Professional_profiles/PPCV444I3_Thomson_A.bits ... JF ( 50 fps @  25 tbr /  25  fps) not equal

Missing 14-bits support:

PP/PPH444I4_Mitsubishi_A.264 ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/PPH444I5_Mitsubishi_A.264 ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/PPH444I6_Mitsubishi_A.264 ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/PPH444P6_Mitsubishi_A.264 ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/PPH444P7_Mitsubishi_A.264 ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/PPH444P8_Mitsubishi_A.264 ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/PPH444P9_Mitsubishi_A.264 ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/Professional_profiles/PPH444I1_Thomson_A.bits ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/Professional_profiles/PPH444I2_Thomson_A.bits ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/Professional_profiles/PPH444I3_Thomson_A.bits ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/Professional_profiles/PPH444P1_Thomson_A.bits ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/Professional_profiles/PPH444P2_Thomson_A.bits ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/Professional_profiles/PPH444P3_Thomson_A.bits ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/Professional_profiles/PPH444P4_Thomson_A.bits ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/Professional_profiles/PPH444P5_Thomson_A.bits ... JF ( 25 fps @  25 tbr /  25  fps) not equal

FMO + 14-bits:

PP/PPH444I-7.264 ... JF ( 25 fps @  25 tbr /  25  fps) not equal
PP/PPH444P-10.264 ... JF ( 25 fps @  25 tbr /  25  fps) not equal