On 9/1/2020 1:14 PM, Derek Buitenhuis wrote: > On 01/09/2020 17:11, James Almer wrote: >> Oh, you mean how it worked with mfra_size being declared as an int32_t. >> I was just mentioning why there was a <= 0 check for it. And I guess >> because no mfra box parsed by lavf was ever bigger than ~2gb, so it >> never failed. >> But yes, it was a bug that you're fixing in this set. > > Yep, apologies if I was not clear. > >> (For that matter, size could in theory also be a 64bit integer according >> to the spec). > > It cannot, as far as I can tell. The 'size' entry in the mfra box is a > separate > member from the normal box size, and is always 32-bits, so that you know to > seek to END-4.
Right, this is a field in mfro and not the mfra Box size. Nevermind then. > > - Derek > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
