GNOME Bugzilla – Bug 797133
qtmux: Allow up to 1 audio sample of lateness in prefill mode
Last modified: 2018-09-13 10:52:30 UTC
See commit message
Created attachment 373621 [details] [review] qtmux: Allow up to 1 audio sample of lateness in prefill mode For 59.94 FPS, it's common to set 60000 as timescale. For that timescale, if the audio is late by as little as 0:00:00.000016666 (definitely less than one audio sample), lateness gets rounded to 1. Added a safeguard that allows lateness up to 1 sample with the specific trak's timescale, to make sure that values less than one audio sample won't break the prefill mode. What will happen in this case is that the audio will get squeezed back to the video's timestamp, which in practice means that the audio will be 0.000016666 seconds early (with the patch).
Review of attachment 373621 [details] [review]: ::: gst/isomp4/gstqtmux.c @@ +3483,3 @@ + /* allow up to 1 sample of lateness */ + trak_lateness = gst_util_uint64_scale (diff, + atom_trak_get_timescale (qtpad->trak), GST_SECOND); The timescale is not necessarily 1 sample (i.e. 1 audio sample, 1 video frame, etc: for video it usually is a 100th of a frame) but can be almost anything. I think this generally makes sense though. While you do this now not only in prefill mode (please change the commit message), there's not much point in adding such a small entry.
Created attachment 373623 [details] [review] qtmux: Allow up to 1 trak timescale unit of lateness in prefill mode For 59.94 FPS, it's common to set 60000 as timescale. For that timescale, if the audio is late by as little as 0:00:00.000016666 (definitely less than one audio sample), lateness gets rounded to 1. Added a safeguard that allows lateness up to 1 sample with the specific trak's timescale, to make sure that values less than e.g. one audio sample won't break the prefill mode. What will happen in this case is that the audio will get squeezed back to the video's timestamp, which in practice means that the audio will be 0.000016666 seconds early (with the patch).
Review of attachment 373621 [details] [review]: (obsolete)
Comment on attachment 373623 [details] [review] qtmux: Allow up to 1 trak timescale unit of lateness in prefill mode Please also mention why it's fine to ignore the <1 trak timescale units difference here. Simply because that can't possibly be represented as a timestamp/duration by the trak specific parts of the headers, so it's irrelevantly small.
Created attachment 373633 [details] [review] qtmux: Allow up to 1 trak timescale unit of lateness in prefill mode For 59.94 FPS, it's common to set 60000 as timescale. For that timescale, if the audio is late by as little as 0:00:00.000016666 (definitely less than one audio sample), lateness gets rounded to 1. Added a safeguard that allows lateness up to 1 sample with the specific trak's timescale, to make sure that values less than e.g. one audio sample won't break the prefill mode. What will happen in this case is that the audio will get squeezed back to the video's timestamp, which in practice means that the audio will be 0.000016666 seconds early (with the patch).
Review of attachment 373633 [details] [review]: commit 94f8603411d607aa125f31d48786c8bbf10eab25 (HEAD -> upstream_master, upstream/master) Author: Vivia Nikolaidou <vivia@ahiru.eu> Date: Wed Sep 12 17:24:00 2018 +0300 qtmux: Allow up to 1 trak timescale unit of lateness in prefill mode For 59.94 FPS, it's common to set 60000 as timescale. For that timescale, if the audio is late by as little as 0:00:00.000016666 (definitely less than one audio sample), lateness gets rounded to 1. Added a safeguard that allows lateness up to 1 sample with the specific trak's timescale, to make sure that values less than e.g. one audio sample won't break the prefill mode. What will happen in this case is that the audio will get squeezed back to the video's timestamp, which in practice means that the audio will be 0.000016666 seconds early (with the patch). https://bugzilla.gnome.org/show_bug.cgi?id=797133