Encoding Warnings

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Encoding Warnings

Ruler2112
Hello everybody.  Even though I've used ffmpeg for over 20 years, this will
be my first post to the mailing list.

I get videos from a variety of sources - youtube, vimeo, DVR, DVDs I've
purchased, etc.  They're in a wide variety of different formats, many of
which my TVs/DVRs over the years have refused to play.  The volume also
varies wildly between sources - DVR is fine, but anything from outside can
either be so quiet I have to crank the volume up to max to have any chance
at hearing it or be blasted out of the room if I don't have it set on
minimum.  Because of this, I wrote a batch file to process each video.  I
simply drop the raw files in a todo folder, run the batch file, and it would
do everything from there.  The resolution/frame rate is read with MediaInfo,
calculations done internally, then video is reprocessed with ffmpeg, the
audio is dumped to a wave with ffmpeg and then had processing done on it to
standardize the volume, and the two resulting files were then remuxed with
VirtualDub.  (I know ffmpeg should have been able to do it and frankly do
not remember why I made it like this - it was 15 years ago when I wrote it
after all.)  The output has XVID video with CBR MP3 audio with large
resolutions scaled down to a maximum I specified which has played perfectly
on everything I've thrown them at.  The script has worked awesome for years.

The problem now is that the windows machine I've been running it on has died
of a faulty motherboard.  Frankly, I moved on from windows many years ago
and that one XP box was kept solely for running this program.  I'd rather
not replace it with another windows machine if I can help it, so have been
working to re-write the batch files as a perl script and utilizing ffmpeg
exclusively to do the heavy lifting.  This has gone extremely well and
everything seems to be working fine with a couple exceptions.

First, the volume standardization program was also windows only.  I
contacted the author and got the source code.  Even though I hadn't touched
C since college, adapting it to work on Linux wasn't too bad and it's now
functional. :)

Second are the ffmpeg warnings/errors.  I've spent over two days looking for
solutions to the various problems and have solved everything except a
couple.  I do not know if they're related to the version of ffmpeg being so
much newer than the one that was running on the XP machine or what, but I
don't know what else to try.  I'm hoping someone can help me iron them out.

The version of ffmpeg on the XP box (according to the output when running it
through WINE) is:

ffmpeg version N-78758-g5156578 Copyright (c) 2000-2016 the FFmpeg
developers
built with gcc 5.3.0 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads
--enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r
--enable-gnutls --enable-iconv --enable-libass --enable-libbluray
--enable-libbs2b
--enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme
--enable-libgsm
--enable-libilbc --enable-libmodplug --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg
--enable-libopus
--enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex
--enable-libtheora --enable-libtwolame --enable-libvidstab
--enable-libvo-amrwbenc
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp
--enable-libx264
--enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg
--enable-lzma
--enable-decklink --enable-zlib
libavutil 55. 19.100 / 55. 19.100
libavcodec 57. 27.100 / 57. 27.100
libavformat 57. 26.100 / 57. 26.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 37.100 / 6. 37.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100

The version on the Linux machine is:

ffmpeg version 4.3-static https://johnvansickle.com/ffmpeg/  Copyright (c)
2000-2020 the FFmpeg developers
  built with gcc 8 (Debian 8.3.0-6)
  configuration: --enable-gpl --enable-version3 --enable-static
--disable-debug --disable-ffplay --disable-indev=sndio
--disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r
--enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom
--enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype
--enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libopenjpeg --enable-librubberband --enable-libsoxr
--enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus
--enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc
--enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi
--enable-libzimg
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100


The commands the script runs are:

Step 1: Reprocess Video, 2 Pass Encoding

/usr/local/bin/ffmpeg -threads 8 -dn -i "/home/me/media/proc/input.mp4" -dn
-pass 1 -passlogfile "/home/me/media/proc/input.log" -f avi -vcodec mpeg4
-vtag XVID -maxrate 2000k -b:v 1500k -mbd 2 -bf 2 -flags -aic -cmp 2 -subcmp
2 -g 300 -an   -s 720:400 -aspect 1.7777 -vf "setdar=1.7777" -metadata
ISFT="Rulers Scripts" "/home/me/media/proc/pass1.avi"

   Output:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/me/media/proc/input.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.25.101
  Duration: 00:47:53.92, start: 0.000000, bitrate: 1037 kb/s
    Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 /
0x31637661), yuv420p, 720x400 [SAR 80:81 DAR 16:9], 905 kb/s, 25 fps, 25
tbr, 12800 tbn, 50 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo,
fltp, 128 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
[mpeg4 @ 0x7357d40] Automatically choosing VBV buffer size of 160 kbyte
Output #0, avi, to '/home/me/media/proc/pass1.avi':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    ISFT            : Lavf58.45.100
    Stream #0:0(eng): Video: mpeg4 (XVID / 0x44495658), yuv420p, 720x400
[SAR 80:81 DAR 16:9], q=2-31, 1500 kb/s, 25 fps, 25 tbn, 25 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      encoder         : Lavc58.91.100 mpeg4
    Side data:
      cpb: bitrate max/min/avg: 2000000/0/1500000 buffer size: 1310720
vbv_delay: N/A
frame=71847 fps=220 q=2.5 Lsize=  527334kB time=00:47:53.84
bitrate=1503.2kbits/s speed=8.79x    
video:525609kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.328167%


Step 1b: Second Pass

/usr/local/bin/ffmpeg -threads 8 -dn -i "/home/me/media/proc/input.mp4" -dn
-pass 2 -passlogfile "/home/me/media/proc/input.log" -f avi -vcodec mpeg4
-vtag XVID -maxrate 2000k -b:v 1500k -mbd 2 -bf 2 -flags -aic -cmp 2 -subcmp
2 -g 300 -an   -s 720:400 -aspect 1.7777 -vf "setdar=1.7777" -metadata
ISFT="Rulers Scripts" "/home/me/media/proc/pass2.avi"

     Output:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/me/media/proc/input.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.25.101
  Duration: 00:47:53.92, start: 0.000000, bitrate: 1037 kb/s
    Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 /
0x31637661), yuv420p, 720x400 [SAR 80:81 DAR 16:9], 905 kb/s, 25 fps, 25
tbr, 12800 tbn, 50 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo,
fltp, 128 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
[mpeg4 @ 0x6784c00] Automatically choosing VBV buffer size of 160 kbyte
Output #0, avi, to '/home/me/media/proc/pass2.avi':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    ISFT            : Rulers Scripts
    Stream #0:0(eng): Video: mpeg4 (XVID / 0x44495658), yuv420p, 720x400
[SAR 80:81 DAR 16:9], q=2-31, 1500 kb/s, 25 fps, 25 tbn, 25 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      encoder         : Lavc mpeg4
    Side data:
      cpb: bitrate max/min/avg: 2000000/0/1500000 buffer size: 1310720
vbv_delay: N/A
frame=71847 fps=219 q=2.7 Lsize=  527998kB time=00:47:53.84
bitrate=1505.1kbits/s speed=8.77x    
video:526274kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.327711%



Step 2: Dump Wave file

/usr/local/bin/ffmpeg -threads 8 -i "/home/me/media/proc/input.mp4" -dn -vn
-ar 44100 -ac 2 "/home/me/media/proc/sound.avi"

Output:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/me/media/proc/input.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.25.101
  Duration: 00:47:53.92, start: 0.000000, bitrate: 1037 kb/s
    Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 /
0x31637661), yuv420p, 720x400 [SAR 80:81 DAR 16:9], 905 kb/s, 25 fps, 25
tbr, 12800 tbn, 50 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo,
fltp, 128 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Stream mapping:
  Stream #0:1 -> #0:0 (aac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, wav, to '/home/me/media/proc/sound.wav':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    ISFT            : Lavf58.45.100
    Stream #0:0(eng): Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz,
stereo, s16, 1411 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      encoder         : Lavc58.91.100 pcm_s16le
size=  495072kB time=00:47:53.88 bitrate=1411.2kbits/s speed= 474x    
video:0kB audio:495072kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.000015%


Step 3: Standardize Volume

Not performed by ffmpeg, but confirmed to work and modify the amplitude of
the wave file while keeping the same format.


Step 4: Remux Video & Audio

/usr/local/bin/ffmpeg -threads 8 -re -i "/home/me/media/proc/pass2.avi" -re
-i "/home/me/media/proc/sound.wav" -vcodec copy -acodec mp3 -b:a 128k -ar
44100 -ac 2 -use_wallclock_as_timestamps 1 -bitexact -metadata ISFT="Rulers
Scripts" "/home/me/media/proc/output.avi"

     Output:

Input #0, avi, from '/home/me/media/proc/pass2.avi':
  Metadata:
    encoder         : Rulers Scripts
  Duration: 00:47:53.88, start: 0.000000, bitrate: 1505 kb/s
    Stream #0:0: Video: mpeg4 (Advanced Simple Profile) (XVID / 0x44495658),
yuv420p, 720x400 [SAR 80:81 DAR 16:9], 1500 kb/s, 25 fps, 25 tbr, 25 tbn, 25
tbc
Guessed Channel Layout for Input Stream #1.0 : stereo
Input #1, wav, from '/home/me/media/proc/sound.wav':
  Metadata:
    encoder         : Lavf58.45.100
  Duration: 00:47:53.89, bitrate: 1411 kb/s
    Stream #1:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo,
s16, 1411 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #1:0 -> #0:1 (pcm_s16le (native) -> mp3 (libmp3lame))
Press [q] to stop, [?] for help
Output #0, avi, to '/home/me/media/proc/output.avi':
  Metadata:
    ISFT            : Rulers Scripts
    Stream #0:0: Video: mpeg4 (Advanced Simple Profile) (XVID / 0x44495658),
yuv420p, 720x400 [SAR 80:81 DAR 16:9], q=2-31, 1500 kb/s, 25 fps, 25 tbr, 25
tbn, 25 tbc
    Stream #0:1: Audio: mp3 (libmp3lame) (U[0][0][0] / 0x0055), 44100 Hz,
stereo, s16p, 128 kb/s
    Metadata:
      encoder         : Lavc libmp3lame
[avi @ 0x6611d80] 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
frame= 2196 fps=1368 q=-1.0 Lsize=   17854kB time=00:01:27.95
bitrate=1662.9kbits/s speed=54.8x    
video:16338kB audio:1375kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.798442%



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, but am not certain.  It
is being produced by the audio stream as if I encode directly to an MP3 with
no video, it says the same thing, even if I specify -ac 2 before the -i for
the wave file.  Is ignoring it being OK without causing trouble a correct
assumption?  If so, is there a way to silence the warning or should I just
live with it?  If not, could somebody point me in the right direction on how
to fix it?


     '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 one on the other hand, I am concerned about.  I've searched online and
have repeated the entire process with the following options:

'-use_wallclock_as_timestamps 1'
'-fflags +genpts'

I used the first option without '-re' before the input specifications and
later with them.  (And boy, does -re ever slow down processing!)  I tried
the second on it's own, then in conjunction with the first, first without
-re & then with it.  Everything I do results in the same warning, even
though ffmpeg is what produced the AVI being used as the video source in the
muxing process.

From the sound of it, there's something wrong that should be fixed, but I
cannot seem to figure out what it is or how to fix it.  Like I said, ffmpeg
produced the AVI file it's now complaining about & these are the same
commands that worked fine in the older version of ffmpeg that the XP box was
running.  If I mux the two files together with VirtualDub on my windows
machine at work, there are no warnings like this.  I've scoured the internet
& mailing lists and have found many people running into the same type of
warning messages, but little help other than to add one or the other of the
above options to fix it.  (Which of course does not work for me.)

Please help - these are the last issues (that I know of) which stand in the
way of getting this processing script working 100% on Linux.



--
Sent from: http://www.ffmpeg-archive.org/
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Encoding Warnings

Carl Eugen Hoyos-2
Am Fr., 26. Juni 2020 um 21:56 Uhr schrieb Ruler2112 <[hidden email]>:

> Step 3: Standardize Volume
> Not performed by ffmpeg

I am curious: Why?

[...]

> 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.)

> '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.

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.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Encoding Warnings

PaulYurt
In reply to this post by Ruler2112

> On Jun 26, 2020, at 3:56 PM, Ruler2112 <[hidden email]> wrote:
>

Guessed Channel Layout for Input Stream #1.0 : stereo

Try:  -guess_layout_max 0
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Encoding Warnings

Ruler2112
In reply to this post by Carl Eugen Hoyos-2
Hi Carl

On 06/27/20 06:11, Carl Eugen Hoyos wrote:
> Am Fr., 26. Juni 2020 um 21:56 Uhr schrieb Ruler2112 <[hidden email]>:
>
>> 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

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Encoding Warnings

Moritz Barsnick
On Mon, Jun 29, 2020 at 10:44:04 -0400, Jim wrote:
> 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,

It does.

> and then apply that scaled volume adjustment to the entire file.

This makes this a two-pass operation, which your external tool probably
also does. ffmpeg can analyze first:

$ ffmpeg -i INPUT -map 0:a -af volumedetect -f null -

and will find the absolute maximum of the first audio channel. Take the
max value from the log (something like "max_volume: -18.1 dB"[*]), and
use that value for an additionally inserted "volume" audio filter in
your conversion.

$ ffmpeg -i INPUT [...] -af volume="18.1 dB",otherfilters OUTPUT

You thus only have an additional input analysis step.

[*] Documentation says this will not cause any clipping, though I don't
know what the behaviour is, if the volume is massively different across
channels. I *believe* the maximum is safe to use (while the average is
also an average across channels, by some kind of mixdown).

> same question in my searching for a solution to this same message - this
> is the first time I've read this.

(I personally find this confusing as well.)

> (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! :) :) :)

We like happy people. :-)

Cheers,
Moritz
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Encoding Warnings

Moritz Barsnick
On Mon, Jun 29, 2020 at 17:18:51 +0200, Moritz Barsnick wrote:
> $ ffmpeg -i INPUT -map 0:a -af volumedetect -f null -
>
> and will find the absolute maximum of the first audio channel.

I meant: of the first audio *stream*. Sorry.

Moritz
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Encoding Warnings

Carl Eugen Hoyos-2
In reply to this post by Ruler2112
Am Mo., 29. Juni 2020 um 16:44 Uhr schrieb Jim <[hidden email]>:

> >> 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

You do realize that FFmpeg offers neither a "windows version" nor
a "Linux" version but only source code?

> interesting is your explanation... out of curiosity, what ancient
> software are you referring to?  (Not really important - just curious.)

I wanted to answer "I don't remember" but I just realized that the
Home Theatre System "Sony DAV-DZ340K" is probably among
them.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Encoding Warnings

FFmpeg-users mailing list
In reply to this post by Ruler2112


> On 29 Jun 2020, at 15:44, Jim <[hidden email]> wrote:
>
>  (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 think you would like the loudnorm filter that incorporates ebur-128 adjustments.
It can run as two pass or one pass (useful for live streaming) and adjusts the audio levels to maintain the specified levels.
An example would be -af loudnorm=I=-23:TP=-1.0:LRA=11
This sets the average loudness at -23LUFS (this is pretty standard for UK TV) the True Peak value as -1.0dBfs and the loudness range shows the distribution of loudness throughout the programme.

LUFS is great because it is based on perceptual loudness and not just sample values.

Have fun
Adam
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Encoding Warnings

Ruler2112
In reply to this post by Carl Eugen Hoyos-2

On 06/29/20 17:39, Carl Eugen Hoyos wrote:
> 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
> You do realize that FFmpeg offers neither a "windows version" nor
> a "Linux" version but only source code?
>
I absolutely do understand that Carl.  I am sorry - should have phrased
it differently.  'Windows version' = the older version that I had
running on the computer that recently died which ran the windows xp
professional operating system, the full version of which was reported in
my original post:

ffmpeg version N-78758-g5156578 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.3.0 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads
--enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r
--enable-gnutls --enable-iconv --enable-libass --enable-libbluray
--enable-libbs2b
--enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme
--enable-libgsm
--enable-libilbc --enable-libmodplug --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg
--enable-libopus
--enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex
--enable-libtheora --enable-libtwolame --enable-libvidstab
--enable-libvo-amrwbenc
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp
--enable-libx264
--enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg
--enable-lzma
--enable-decklink --enable-zlib
libavutil 55. 19.100 / 55. 19.100
libavcodec 57. 27.100 / 57. 27.100
libavformat 57. 26.100 / 57. 26.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 37.100 / 6. 37.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100



When I said 'Linux version', I was referring to the newer version I am
running on the Linux machine:

ffmpeg version 4.3-statichttps://johnvansickle.com/ffmpeg/   Copyright (c)
2000-2020 the FFmpeg developers
   built with gcc 8 (Debian 8.3.0-6)
   configuration: --enable-gpl --enable-version3 --enable-static
--disable-debug --disable-ffplay --disable-indev=sndio
--disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r
--enable-gnutls --enable-gmp --enable-libgme --enable-gray
--enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf
--enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband
--enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis
--enable-libopus --enable-libtheora --enable-libvidstab
--enable-libvo-amrwbenc --enable-libvpx --enable-libwebp
--enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d
--enable-libxvid --enable-libzvbi --enable-libzimg
   libavutil      56. 51.100 / 56. 51.100
   libavcodec     58. 91.100 / 58. 91.100
   libavformat    58. 45.100 / 58. 45.100
   libavdevice    58. 10.100 / 58. 10.100
   libavfilter     7. 85.100 /  7. 85.100
   libswscale      5.  7.100 /  5.  7.100
   libswresample   3.  7.100 /  3.  7.100
   libpostproc    55.  7.100 / 55.  7.100



What I should have said was: "Interesting that this warning is not
present in ffmpeg version N-78758-g5156578 running on a windows xp
operating system yet is on ffmpeg version 4.3-static running on Ubuntu
Linux 20.04, each with the above reported compilation options & versions
of the related libraries, when operating on identical files."  I
apologize - did not realize that using shorthand as I did would cause
confusion.

I've no idea how N-78758-g5156578 compares with 4.3-static as far as age
goes, other than it's older because I've been running it for years.  
(And this is assuming it's not something to do with the underlying
operating system and not ffmpeg itself.)  I am curious as to why the
older version doesn't issue a warning that the newer version does, but
it's not important either.

Jim
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Encoding Warnings

Ruler2112
In reply to this post by Moritz Barsnick

On 06/29/20 11:18, Moritz Barsnick wrote:

> On Mon, Jun 29, 2020 at 10:44:04 -0400, Jim wrote:
>> 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,
> It does.
>
>> and then apply that scaled volume adjustment to the entire file.
> This makes this a two-pass operation, which your external tool probably
> also does. ffmpeg can analyze first:
>
> $ ffmpeg -i INPUT -map 0:a -af volumedetect -f null -
>
> and will find the absolute maximum of the first audio channel. Take the
> max value from the log (something like "max_volume: -18.1 dB"[*]), and
> use that value for an additionally inserted "volume" audio filter in
> your conversion.
>
> $ ffmpeg -i INPUT [...] -af volume="18.1 dB",otherfilters OUTPUT
>
> You thus only have an additional input analysis step.
>
> [*] Documentation says this will not cause any clipping, though I don't
> know what the behaviour is, if the volume is massively different across
> channels. I *believe* the maximum is safe to use (while the average is
> also an average across channels, by some kind of mixdown).
>
>> same question in my searching for a solution to this same message - this
>> is the first time I've read this.
> (I personally find this confusing as well.)
>
>> (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! :) :) :)
> We like happy people. :-)
>
> Cheers,
> Moritz
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

> On 29 Jun 2020, at 15:44, Jim<[hidden email]>  wrote:
>
>   (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 think you would like the loudnorm filter that incorporates ebur-128 adjustments.
It can run as two pass or one pass (useful for live streaming) and adjusts the audio levels to maintain the specified levels.
An example would be -af loudnorm=I=-23:TP=-1.0:LRA=11
This sets the average loudness at -23LUFS (this is pretty standard for UK TV) the True Peak value as -1.0dBfs and the loudness range shows the distribution of loudness throughout the programme.

LUFS is great because it is based on perceptual loudness and not just sample values.

Have fun
Adam



I would like to say that the progress this project has made since I
initially wrote this script is absolutely amazing!  When I first wrote
my processing script, I wanted to simply down-sample the audio from n
channels to stereo and transcode to MP3 - no volume manipulation at
all.  (The DVR I had at the time would totally freak if I threw audio at
it with more than 2 channels.)  There were many people complaining about
it at the time, but no real solutions.  I had to use a 2-step process -
dump to stereo wave and then encode to MP3 - because ffmpeg refused to
reduce the number of channels in an audio stream.  (Having to do this
2-step process combined with my continual frustration with the volume of
various files is what led me to work out the maximization of the volume
throughout each file.)  Now, ffmpeg has the ability to do everything
itself!  I know it's been several years, but still... excellent work
guys - very impressive. :)

Jim

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".