[FFmpeg-devel] [PATCH 3/3] avformat/dashenc: always attempt to enable prft on ldash mode
Thilo Borgmann
thilo.borgmann at mail.de
Wed Feb 19 16:21:50 EET 2020
Am 19.02.20 um 14:35 schrieb James Almer:
> On 2/19/2020 8:50 AM, Jeyapal, Karthick wrote:
>>
>> On 2/19/20 4:21 PM, Thilo Borgmann wrote:
>>> Am 19.02.20 um 06:18 schrieb Jeyapal, Karthick:
>>>>
>>>> On 2/18/20 9:43 PM, James Almer wrote:
>>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>>> ---
>>>>> libavformat/dashenc.c | 5 +++++
>>>>> 1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>>>>> index b910cc22d0..045d2f4df6 100644
>>>>> --- a/libavformat/dashenc.c
>>>>> +++ b/libavformat/dashenc.c
>>>>> @@ -1395,6 +1395,11 @@ static int dash_init(AVFormatContext *s)
>>>>> c->frag_type = FRAG_TYPE_EVERY_FRAME;
>>>>> }
>>>>>
>>>>> + if (c->ldash && !c->write_prft) {
>>>>> + av_log(s, AV_LOG_INFO, "Enabling Producer Reference Time element for Low Latency mode\n");
>>>>> + c->write_prft = 1;
>>>>> + }
>>>>> +
>>>> PRFT elements has a significant bitrate overhead, especially in streaming mode when each frame is a moof fragment.
>>>> In terms of percentage of stream's bitrate this overhead will be a significant % for lower bitrate streams(such as audio streams).
>>>> For any application which does not need PRFT this is an unnecessary wastage of bits.
>>>> Hence, I would advise against enabling PRFT without user control.
>>>
>>> Latest to-become spec for low latency mode declares it mandatory [1].
>> I see. Now I understand the motive behind this change.
>>>
>>> I see your point, though. What significance would this actually have, can you provide some numbers / examples?
>> Sorry. I worked on this bitrate overhead optimizations around a year back. Hence, I don’t have the numbers with and without PRFT handy.
>> But I do have the final overhead numbers (without PRFT) for an audio stream.
>> CMAF Muxer overhead (for an AAC-LC codec) by Sampling frequency
>> 16000 Hz - 14 Kbps
>> 24000 Hz - 20 Kbps
>> 32000 Hz - 28 Kbps
>> 48000 Hz - 40 Kbps
>>
>> At 48KHz, the overhead due to CMAF was 40 Kbps which was significant by itself.
>> My random guess is that PRFT would add another 10Kbps - 20Kbps. But I could be wrong here, as I don’t remember exactly.
>
> prft is a 32 byte box per dash segment, and segment duration can be
> configured. A 1 second long segment for a 96kbps 44kHz audio stream with
> a single moof/mdat pair inside is about 12kb. 32 bytes aren't going to
> affect it.
>
> The real overhead is in the CMAF fragmentation/segmentation. Each moof
> box can be in the hundreds of bytes depending on frame count. The more
> moof/mdat pairs (AKA CMAF Chunks) are used, the bigger the overhead.
> Before my recent changes the dash muxer would always make one per frame
> in streaming mode, which was excessive, especially for audio. But now
> you can customize it in various ways.
>
>>
>>> If that turns out to be actually significant, I don't know if we would prefer an override option to disable it and produce non-conformant manifests or live with the overhead.
>> Yes. Having an option to control this behavior would be useful.
The overhead being 32 bytes per segment seems negligible then.
3/3 LGTM
-Thilo
More information about the ffmpeg-devel
mailing list