On Mon, 5 Mar 2018, Marton Balint wrote:
On Sun, 4 Mar 2018, Tomas Härdin wrote:
tor 2018-03-01 klockan 22:41 +0100 skrev Marton Balint:
> Signed-off-by: Marton Balint <c...@passwd.hu>
---
libavformat/mxfdec.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index d4291f5dc7..70091e0dc9 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1347,24 +1347,30 @@ static int
mxf_get_sorted_table_segments(MXFContext *mxf, int *nb_sorted_segment
*/
static int mxf_absolute_bodysid_offset(MXFContext *mxf, int body_sid,
int64_t offset, int64_t *offset_out)
{
- int x;
MXFPartition *last_p = NULL;
+ int a, b, m, m0;
if (offset < 0)
return AVERROR(EINVAL);
- for (x = 0; x < mxf->partitions_count; x++) {
- MXFPartition *p = &mxf->partitions[x];
+ a = -1;
I've got a bad feeling about this -1
There is an explicit check after the loop when we actually use the value
of 'a' to see if it remained -1 or not. Other than that using this
construct (a = -1, b = count) is also used in other places throughout the
codebase for binary search.
+ b = mxf->partitions_count;
- if (p->body_sid != body_sid)
- continue;
+ while (b - a > 1) {
+ m0 = m = (a + b) >> 1;
Could overflow with a specially crafted file. But I guess it would have
to be on the order of 1 TiB.
I guess we could limit the number of partitions to INT_MAX / 2, although
it really needs a *huge* crafted file and parsing it would probably take
ages for the demuxer anyway...
It also looks like this might behave incorrectly when a=-1, b=0
That can't happen as the loop condition would be false in that case.
Will push this soon.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
