[FFmpeg-user] H.264 single access unit decoding

[Alexandre Ferrieux]

On 29/03/2011 19:17, Robert Sitan wrote:
>
>
>  > Date: Tue, 29 Mar 2011 15:22:53 +0200
>  > From: alexandre.ferrieux at orange-ftgroup.com
>  > To: ffmpeg-user at ffmpeg.org
>  > CC: lmodern at hotmail.com
>  > Subject: Re: [FFmpeg-user] H.264 single access unit decoding
>  >
>  >
>  > Your sequence contains an AUD, SPS/PPS, 3 SEIs and a single SLICE.
> Possibly this slice is not decodable in a standalone
>  > manner.
>
> How come it is decodable by the JM decoder?

Dunno, maybe a bug or marginal difference between ffmpeg and JM. That's why

>
>
>  > NALU(9) 2
>  > NALU(7n1) 27
>  > NALU(8n1) 4
>  > NALU(6) 5
>  > NALU(6) 5
>  > NALU(6) 5
>  > NALU(1n1) 57266
>  >
>  > To clarify, please post a longer sequence that ffmpeg can decode.
>
> Here's a longer sequence that is perfectly decodable by ffmpeg:
> http://www.megaupload.com/?d=VYLEC9PD

Yes. Too bad this one is not a superset of the other :/

> However, the idea is to decode the minimum number of images and hence
> the reasoning behind my question.

Here is the analysis of the new sequence:

	NALU(9) 2
	NALU(7n1) 27
	NALU(8n1) 4
	NALU(6) 5
	NALU(6) 5
	NALU(6) 5
	NALU(1n1) 29354
	NALU(12) 158
	NALU(9) 2
	NALU(6) 5
	NALU(6) 5
	NALU(1n1) 21805
	NALU(12) 27
	NALU(9) 2
	NALU(6) 5
	NALU(6) 5
	NALU(1) 14767

What I did was feed this NALU-by-NALU to ffplay. And consistently with my suggestion, the first slice is not enough, and 
the image is displayed only after the second one.

To proceed, please provide a consistent set of samples: a short and a long one, the short being a prefix of the long, 
and the short being verified to decode correctly in JM.

-Alex