[FFmpeg-devel] [PATCH] H.264/AVCHD interlaced fixes
Mon Feb 16 00:52:09 CET 2009
On Sun, Feb 15, 2009 at 10:56:44PM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
> > On Tue, Feb 10, 2009 at 09:36:35PM +0100, Ivan Schreter wrote:
> > [...]
> >> + ptr= ff_h264_decode_nal(h, buf, &dst_length, &consumed, buf_end - buf);
> > this effectively reads through the whole bitstream
> > obviously this is not ok and unneeded
> I've studied the code a bit more. Unfortunately, I still believe it _is_
> needed to call decode_nal,
theres a buf_size parameter, its not hard to limit that to a small number
how small? see the spec, and no its not litterally written there but each
field has some max legal value that can be used to infer max size and
from that you can infer how many bytes you need in worst case ...
> due to two reasons. First, we need to know
> _exact_ NAL unit size, otherwise it's impossible to decode NAL SEI
> correctly. Second, decode_nal also unescapes some sequences in data.
> Without that, the data cannot be read correctly as well.
> Each decode_nal() only scans as much data as really needed to decode
> this NAL.
it decodes the whole nal, and there is just 1 slice so it decodes the
> If ff_find_start_code() should be used instead to find next
> NAL (ignoring the two aforementioned problems), it would also scan
> exactly as much data. So I don't see a problem with it.
of course ANY method that scans the whole is unacceptable and i mean
unacceptable in the sense that no argument will help you, we will
not read the whole frame to extract 5 fields from the headers in the
first 20 bytes
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel