[FFmpeg-devel] [PATCH 3/3 v2] avformat/dashenc: always attempt to enable prft on ldash mode
James Almer
jamrial at gmail.com
Wed Feb 26 02:28:48 EET 2020
On 2/24/2020 6:54 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-02-20 17:26:00)
>> Signed-off-by: James Almer <jamrial at gmail.com>
>
> Commit message is now misleading since it will only enable prft if it's
> not disabled.
Sorry, i pushed this during the weekend. And, true. It's still
attempting but technically not always...
Which makes me realize i should mention this undocumented behavior in
the doxy.
>> ---
>> Now it can be overriden if you explicitly set write_prft to 0.
>>
>> libavformat/dashenc.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index a52cbc9113..7032adc84d 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -1394,6 +1394,12 @@ static int dash_init(AVFormatContext *s)
>> c->frag_type = FRAG_TYPE_EVERY_FRAME;
>> }
>>
>> + if (c->write_prft < 0) {
>> + c->write_prft = c->ldash;
>
> nit: !!, in case ldash becomes something else than a bool in the future
The chances for that are pretty slim, since turning a bool into an int
would be an API break (true/false would stop working from the command
line, afaik). But i can change it anyway.
>
>> + if (c->ldash)
>> + av_log(s, AV_LOG_INFO, "Enabling Producer Reference Time element for Low Latency mode\n");
>
> I'd say this should be VERBOSE, since a normal run with no unexpected
> events should produce no log output.
Sure, will change in a new commit.
>
> Otherwise LGTM.
>
Thanks, and apologies for not waiting a bit more.
More information about the ffmpeg-devel
mailing list