On 2/19/2020 9:33 PM, Jeyapal, Karthick wrote:
>
> On 2/19/20 7:05 PM, James Almer wrote:
>> 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.
> Thanks for your clarification. If the prft is created only once per segment,
> then it is not a big overhead.
> I had encountered a case where pfrt was getting created once per fragment,
> and hence was worried.
Actually, you're right, it's one per fragment. My mistake. But you can
control both fragment count per segment and frame count per fragment in
the dash muxer now, and for low latency dash one fragment per segment of
about 1 second each is recommended for audio streams.
>>
>> 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".
>
> _______________________________________________
> 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".
