FATE failures - Revision history

Elenril: /* Other samples from the H264 conformance suite that don't play back correctly */ cropping is supported now

2013-04-24T15:49:32Z

Other samples from the H264 conformance suite that don't play back correctly: cropping is supported now

← Older revision		Revision as of 08:49, 24 April 2013
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:

Ronald S. Bultje: /* H.264 */

2012-03-01T19:07:24Z

H.264

← Older revision		Revision as of 12:07, 1 March 2012
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.

Ronald S. Bultje: /* H.264 */

2011-11-27T00:25:06Z

H.264

← Older revision		Revision as of 17:25, 26 November 2011
Line 9:		Line 9:
	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. 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).		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/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

Ronald S. Bultje: /* H.264 */

2011-11-27T00:18:03Z

H.264

← Older revision		Revision as of 17:18, 26 November 2011
Line 9:		Line 9:
	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.		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).
	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

Ronald S. Bultje: /* H.264 */

2011-11-27T00:03:44Z

H.264

← Older revision		Revision as of 17:03, 26 November 2011
Line 5:		Line 5:
	=== 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.		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/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

Ronald S. Bultje: /* H.264 */

2011-11-27T00:03:29Z

H.264

← Older revision		Revision as of 17:03, 26 November 2011
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

Ronald S. Bultje: /* H.264 */

2011-11-20T04:34:02Z

H.264

← Older revision		Revision as of 21:34, 19 November 2011
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~~. MR4_TANDBERG_C sets has_b_Frames to 14 after the poc reset at that point~~.		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.
	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

Ronald S. Bultje: /* H.264 */

2011-11-20T04:21:58Z

H.264

← Older revision		Revision as of 21:21, 19 November 2011
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.		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. MR4_TANDBERG_C sets has_b_Frames to 14 after the poc reset at that point.
	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

Ronald S. Bultje: /* H.264 */

2011-11-20T00:37:06Z

H.264

← Older revision		Revision as of 17:37, 19 November 2011
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, ~~so assuming~~ a ~~delay~~ of ~~1, it seems we don't handle~~ POC ~~resets. We should first output the remaining pre-~~reset ~~pictures~~, ~~but instead we output the new ones. There's more defects after that, we only output 259~~ frames~~, JM outputs 300~~.		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.
	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

Ronald S. Bultje: /* H.264 */

2011-11-20T00:03:01Z

H.264

← Older revision		Revision as of 17:03, 19 November 2011
Line 5:		Line 5:
	=== H.264 ===		=== H.264 ===

	Unanalyzed, look roughly OK but not bitexact:		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, so assuming a delay of 1, it seems we don't handle POC resets. We should first output the remaining pre-reset pictures, but instead we output the new ones. There's more defects after that, we only output 259 frames, JM outputs 300.
	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