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 <jamr...@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.
>>
>> -Thilo
>>
>> [1]
>> https://dashif.org/docs/DASH-IF-IOP-CR-Low-Latency-Live-Community-Review-Dec-2019.pdf
>> _______________________________________________
>> 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".
>
_______________________________________________
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".
