[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