[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