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