[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