Difference between revisions of "FATE failures"

From MultimediaWiki
Jump to navigation Jump to search
 
(11 intermediate revisions by one other user not shown)
Line 4: Line 4:


=== H.264 ===
=== 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:
FMO:
Line 9: Line 15:
  MAIN/FM2_SVA_C.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
  MAIN/FM1_BT_B.h264 ... JF ( yuv420p @  176x144 /  25  fps) not equal
Unanalyzed, but look roughly OK (i.e. may be a bug in my script):
MAIN/MR2_TANDBERG_E.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal
MAIN/MR3_TANDBERG_B.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal
MAIN/MR4_TANDBERG_C.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal
MAIN/MR5_TANDBERG_C.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal


For this one, we output only 12 of a few hundred-or-so frames, unanalyzed beyond that:
For this one, we output only 12 of a few hundred-or-so frames, unanalyzed beyond that:
Line 21: Line 21:
Looks like garbage, unanalyzed beyond that:
Looks like garbage, unanalyzed beyond that:
  MAIN/H26L/BitstreamExchange/sp2_bt_b.h264 ... JF ( yuv420p @  176x144 /  25  fps) not equal
  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:
Looks like CAVLC-444 isn't completely implemented:

Latest revision as of 08:49, 24 April 2013

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

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