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.
> 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".
