> On Feb 27, 2022, at 2:49 PM, Gyan Doshi <ffm...@gyani.pro> wrote:
>
>
>
> On 2022-02-27 12:04 pm, "zhilizhao(赵志立)" wrote:
>> Ping.
>>
>>> On Dec 31, 2021, at 7:36 PM, Zhao Zhili <quinkbl...@foxmail.com> wrote:
>>>
>>> When editlist is disabled, the workaournd method of shift dts to
>>> zero and increase the first sample duration doesn't work if the
>>> timestamp is larger than mp4 spec restriction (e.g., sample_delta
>>> in stts entry). Further more, it triggers get_cluster_duration()
>>> assert failure. This patch will drop large offsets between
>>> multiple tracks.
>>> ---
>>> libavformat/movenc.c | 13 ++++++++++++-
>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>>> index 0f912dd012..f5bb785b01 100644
>>> --- a/libavformat/movenc.c
>>> +++ b/libavformat/movenc.c
>>> @@ -5917,7 +5917,18 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket
>>> *pkt)
>>> * to signal the difference in starting time without an edit list.
>>> * Thus move the timestamp for this first sample to 0, increasing
>>> * its duration instead. */
>>> - trk->cluster[trk->entry].dts = trk->start_dts = 0;
>>> + if (pkt->dts + pkt->duration <= INT32_MAX) {
>>> + trk->cluster[trk->entry].dts = trk->start_dts = 0;
>>> + } else {
>>> + /* Impossible to write a sample duration >= UINT32_MAX.
>
> As per 14496-12 (2005), sample_delta is stored as
>
> unsigned int(32) sample_delta;
>
> The only restriction is that no delta shall be zero except the last sample,
> which means UINT32_MAX is allowed.
> INT32_MAX had been set as max allowed delta in mov.c since inception. See my
> recent changes in mov.c correcting that.
>
> Will this patch break remuxing of files with large deltas?
> Let's not clamp if the spec does not call for it.
Since get_cluster_duration() checks dts against INT_MAX, remove
the clamp at here can still trigger abort() after.
```
av_assert0(next_dts <= INT_MAX);
```
The prototype of get_cluster_duration() which returns int needs
to be fixed, and a bunch of places.
And then we can get regression issues: movenc.c output files with
delta larger than INT32_MAX can be dangerous, which is not the
case of mov.c demuxer.
It’s a clever trick here, by using a large sample duration to
handle start time difference between multiple tracks. Since it’s
not a standard method like editlist, I think we can turn off the
strategy safely (FFmpeg abort before the patch, so it’s already
turned off in a hard way).
What do you think?
>
> Regards,
> Gyan
> _______________________________________________
> 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".
