[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 12:51:30 EET 2020


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 your point, though. What significance would this actually have, can you provide some numbers / examples?
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.

-Thilo

[1] https://dashif.org/docs/DASH-IF-IOP-CR-Low-Latency-Live-Community-Review-Dec-2019.pdf


More information about the ffmpeg-devel mailing list