On Fri, Jul 8, 2016 at 2:25 AM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Thu, Jul 07, 2016 at 08:21:17PM +0200, Hendrik Leppkes wrote:
>> Reading it from any other position would result in a wrong size being
>> read, instead fallback to the re-sync mechanic in the else clause.
>> ---
>> libavcodec/h2645_parse.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
>> index 9979b63..09fbc80 100644
>> --- a/libavcodec/h2645_parse.c
>> +++ b/libavcodec/h2645_parse.c
>> @@ -258,7 +258,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const
>> uint8_t *buf, int length,
>> int extract_length = 0;
>> int skip_trailing_zeros = 1;
>>
>> - if (buf >= next_avc) {
>> + if (buf == next_avc) {
>> int i;
>> for (i = 0; i < nal_length_size; i++)
>> extract_length = (extract_length << 8) | buf[i];
>
> the > case should print some warning if it doesnt,
> same for the 2nd patch the truncation should show some warning
>
> otherwise patches LGTM
>
The second patch is really nothing to warn about, the previous logic
was just wrong, causing overreads into the next NAL in some
situations.
I can add a warning for the > case, I guess, as it should usually not happen.
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
