[FFmpeg-user] Encoding Warnings

Jim Ruler2112 at charter.net
Mon Jun 29 17:44:04 EEST 2020

Hi Carl

On 06/27/20 06:11, Carl Eugen Hoyos wrote:
> Am Fr., 26. Juni 2020 um 21:56 Uhr schrieb Ruler2112 <Ruler2112 at charter.net>:
>> Step 3: Standardize Volume
>> Not performed by ffmpeg
> I am curious: Why?
> [...]

AFAIK, ffmpeg does not have the ability to analyze the volume of every 
sample throughout an audio file, find the greatest amplitude, calculate 
the adjustment needed to make the loudest part of the file the maximum, 
and then apply that scaled volume adjustment to the entire file.  (While 
this doesn't equalize the volume or eliminate all volume-related 
inconsistencies, it does make the loudest part of each video the same 
and is the best solution I've found; I don't have to re-adjust my volume 
when playing ~95% of the files run through this script.)  I've never 
seen anything about this in the documentation & frankly, it seems like 
it's something esoteric enough to be out of scope for the project.  Am I 
wrong in this regard?

>> The two lines that are concerning to me are:
>>       'Guessed Channel Layout for Input Stream #1.0 : stereo'
>> Of course it's stereo - I jump dumped it to a 2-channel wave in the step 2!
>> :)
>>   I'm guessing that I can safely ignore this one
> Obviously.
> (The wav standard does not require writing the channel layout for some
> mono and stereo files and we don't do it to maintain compatibility with
> ancient software that fails if the information is present.)

Interesting that this warning is not present in the windows version of 
ffmpeg yet is on Linux.  Any idea why that would be?  Even more 
interesting is your explanation... out of curiosity, what ancient 
software are you referring to?  (Not really important - just curious.)

>> 'Timestamps are unset in a packet for stream 0. This is deprecated and
>> will stop working in the future. Fix your code to set the timestamps
>> properly'
> This warning is not meant for you and you cannot fix it.

Huh???  If it's not intended for the user and there's no way for the 
user to fix it, I assume it must be a warning specifically for 
developers.  As such, why would it be printed without having some flag 
turned on to print debug warnings???  Never saw it when using the older 
windows version I was running and have found a LOT of people with the 
same question in my searching for a solution to this same message - this 
is the first time I've read this.

An idea just popped into my head... if someone involved with organizing 
the ffmpeg project reads this, you might want to start an 'error code' 
database where people could copy/paste the error they received and it 
would provide them information like this.  It would certainly lighten 
the volume of repeated questions/problems to the mailing list and other 
forums.  I pride myself on finding & fixing problems myself and only ask 
for help when I see no other choice; I'm glad I gave up on this when I 
did!  A search of the mailing list archives for "timestamps are unset in 
a packet" came back with over 70 hits, and that doesn't include hits 
from all the other different forums I found.  (Hopefully, each of those 
people didn't waste as much time as I did chasing a problem they had no 
hope of fixing.)  I'm sure other errors are even more commonly repeated; 
a database of error messages could help reduce such repetition.  Just an 

> For future questions: Please understand that posting excerpts of the
> console output is not acceptable, always post the command line(s)
> together with the complete, uncut console output.

The output of the commands was complete except for version & library 
information, which were identical for every command.  Please accept my 
apologies for not repeating the same information every time - I was just 
trying to shorten an already lengthy message by putting the version 
information once and eliminating redundant information throughout the 
rest of the message.

Thank you so much for your response Carl.  The information you provided 
means that my script to reprocess video files on Linux is complete!  
(Assuming I don't run into anything weird when processing different 
video formats in the future of course. ;) )  I'm happy, happy, happy 
about that! :) :) :)


More information about the ffmpeg-user mailing list