Difference between revisions of "FATE failures"

From MultimediaWiki
Jump to navigation Jump to search
(H.264)
(H.264)
Line 5: Line 5:
 
=== H.264 ===
 
=== H.264 ===
  
Unanalyzed, look roughly OK but not bitexact. 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.
+
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.
 
  MAIN/MR2_TANDBERG_E.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal
 
  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/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.
 
  MAIN/MR4_TANDBERG_C.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
 
  MAIN/MR5_TANDBERG_C.264 ... JF ( yuv420p @  176x144 /  25  fps) not equal

Revision as of 17:03, 26 November 2011

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

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.

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.

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