[FFmpeg-devel] [PATCH 3/3] avformat/dashenc: always attempt to enable prft on ldash mode

[Jeyapal, Karthick]

On 2/20/20 7:19 AM, James Almer wrote:
> 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 <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.
>> 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.
If that is the case, I would like to point out that not everybody might choose 1 second per fragment. 
Anyone interested in reduced latency and stability would go for 1 frame per fragment. 
In our tests(in production environments), 1 frame per fragment provides much smoother and stable behavior at low latency streaming than higher fragment sizes.
And in such a case PRFT will add 12Kbps overhead for a 48Khz AAC-LC stream. Hence, I suggest we keep this behavior configurable.
>
>>>
>>> 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 at ffmpeg.org
>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>>
>>>>> To unsubscribe, visit link above, or email
>>>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>>>
>>>> _______________________________________________
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel at ffmpeg.org
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>
>>>> To unsubscribe, visit link above, or email
>>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>>>
>>>
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".