[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
idea.
> 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! :) :) :)
Jim
More information about the ffmpeg-user
mailing list