On 21/08/13 01:30, Martin Storsjö wrote: > On Tue, 20 Aug 2013, Luca Barbato wrote: > >> On 20/08/13 16:49, John Stebbins wrote: >>> On 08/20/2013 07:10 AM, Martin Storsjö wrote: >>>> On Mon, 19 Aug 2013, John Stebbins wrote: >>>> >>>>> From: Clément Bœsch <[email protected]> >>>>> >>>>> The old method doesn't work when moov is relocated to beginning of >>>>> file >>>>> --- >>>>> libavformat/movenc.c | 12 +++++++++--- >>>>> 1 file changed, 9 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c >>>>> index 6df84f6..0fc173a 100644 >>>>> --- a/libavformat/movenc.c >>>>> +++ b/libavformat/movenc.c >>>>> @@ -82,15 +82,21 @@ static int64_t update_size(AVIOContext *pb, >>>>> int64_t pos) >>>>> return curpos - pos; >>>>> } >>>>> >>>>> +static int is_co64_required(const MOVTrack *track) >>>>> +{ >>>>> + if (track->cluster[track->entry - 1].pos + track->data_offset >>>>> > UINT32_MAX) >>>>> + return 1; >>>>> + return 0; >>>>> +} >>>> I didn't check right now, but does this need a check for entry>0, or >>>> are we positive that it won't ever be called in that case? >>> >>> ahh, yes, this could possibly be called with entry == 0 when >>> fragments are enabled. >>> update attached. >>> >> >> so in the end we got >> >> track_pos = 0; >> >> if (track->entry > 0) >> trac_pos = track->cluster[track->entry - 1].pos + track->data_offset; >> >> >> if (FFMAX(pos, track_pos) > UINT32_MAX) >> ... >> >> I'll bake the patch tonight if you want =) > > We actually don't need to check whether pos is larger than UINT32_MAX, > it's literally the cluster[i].pos + data_offset value that will be > written, that must fit into 32 bit - previously the pos check was just > done lazily since pos was always bigger than that in that setup. > > John's latest version of the patch looks good, I'll push it tomorrow > unless there's something else I missed.
Looks like I missed it and did myself one (not pushed yet since I'm rebuilding to fate-check I didn't botch since it is this late) lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
