[Ffmpeg-devel-irc] ffmpeg.log.20190219

[burek]

[05:11:25 CET] <kepstin> giaco: if you already know what adjustment you want to make to the volume, then you can use the volume filter to apply it
[05:12:04 CET] <kepstin> e.g. "this should be 3dB louder than it currently is", then use `-af volume=3dB`
[05:15:06 CET] <kepstin> if you don't know what the input loudness is, and you want it normalized to a certain reference loudness, then it gets a bit more complicated.
[10:52:10 CET] <andrey_utkin> Does anybody have an opinion on which terminal font looks best on a screencast video after aggressive video compression as used by Youtube etc?
[14:20:54 CET] <DHE> andrey_utkin: if it's a mostly static image, the compression should still preserve a good sharp image at sufficient resolution
[15:47:35 CET] <faLUCE> Hello. I compiled ffmpeg 4.x on linux but ffplay was not added. What do I have to check in ./configure ?
[15:48:09 CET] <DHE> probably need SDL installed, with the -dev or -devel package
[15:52:43 CET] <faLUCE> DHE: but should I add sdl in the configure of ffmpeg as well, or is it automatically checked?
[16:12:48 CET] <DHE> should be automatic, but it needs to find SDL to be able to build ffplay
[16:14:21 CET] <faLUCE> DHE: I see. I think it should be added an option lile "enable-ffplay" or so. Each time I have this issue, and after months I don't remember which was the trick
[16:14:41 CET] <faLUCE> (when I recompile ffmpeg)
[16:16:49 CET] <JEEB> then use --disable-autodetect and specifically enable sdl?
[16:16:54 CET] <JEEB> s/enable/require/
[16:17:10 CET] <JEEB> which is --enable-sdl
[16:17:22 CET] <faLUCE> JEEB: it would be clearer (IMHO) if there's a specific option for ffplay
[16:18:44 CET] <JEEB> I think there might even be since there's an example of --disable-ffplay
[16:18:54 CET] <JEEB> so the other way
[16:20:33 CET] <faLUCE> disable-ffplay doesn't help in understanding that- There should be --enable-ffplay (default: NO)
[16:20:42 CET] <faLUCE> and then an error if sdl is not found
[16:20:52 CET] <faLUCE> this much clearer
[16:21:55 CET] <JEEB> feel free to make a bug report
[16:22:07 CET] <JEEB> on the trac
[16:22:14 CET] <faLUCE> I'll do
[17:09:23 CET] <faLUCE> I got this warning from libx264:  [libx264 @ 0x5565050987c0] MB rate (1200000000) > level limit (16711680)   ...  which field of AvcodecContext could I set for avoiding it? I tried with ctxt->bit_rate but did not solve
[17:12:52 CET] <kepstin> faLUCE: you've set a level that's incompatible with the video frame size/framerate
[17:13:13 CET] <kepstin> so you either have to increase the level (or maybe just leave it unset if you don't need it), or reduce the frame size / framerate
[17:14:45 CET] <kepstin> oh, wow, that's the limit for level 6.2, which should be good for 4k video at 300fps
[17:15:01 CET] <kepstin> there's something wrong with some of your other parameters if that's not working :/
[17:15:41 CET] <faLUCE> kepstin: maybe gopsize?
[17:15:44 CET] <kepstin> it could be that your frame timestamps or timebase are incorrect, so the encoder is seeing a much higher framerate than expected
[17:17:36 CET] <faLUCE> kepstin: DEFAULT_BITRATE, GOPSIZE=10, H264_ULTRAFAST, H264_DEFAULT_PROFILE, H264_DEFAULT_TUNE
[17:18:11 CET] <kepstin> the problem is not bitrate or gop size or anything in the encoder parameters
[17:18:34 CET] <kepstin> the problem is that the encoder thinks the volume of pixels (well, macroblocks) it's encoding per second is too high
[17:18:48 CET] <kepstin> which indicates that you likely have an issue with timestamps or timebases
[17:19:20 CET] <faLUCE> I see, I have to check better
[17:25:49 CET] <kepstin> an example of this sort of problem would be if you're outputting to mkv - the ffmpeg mkv muxer has a fixed timebase of 1/1000 - if you set the encoder to use the container timestamp but forgot to convert the timestamps, then the encoder might see a framerate that looks 100s of times too high.
[17:53:10 CET] <faLUCE> kepstin: I used  mVideoEncoderCodecContext->time_base = AV_TIME_BASE_Q;
[17:53:34 CET] <faLUCE> (and ts muxer)
[17:53:46 CET] <faLUCE> (mpegts)
[17:53:48 CET] <kepstin> well, that's probably wrong.
[17:53:59 CET] <faLUCE> why?
[17:54:15 CET] <kepstin> I'd recommend setting the encoder muxer to the timebase from the container, to avoid having to do multiple conversions
[17:54:36 CET] <JEEB> MPEG-TS will anyways set itself to 90k
[17:54:37 CET] <kepstin> and don't forget to rescale frame timestamps to the correct timebase before sending frames to the encoder
[17:54:56 CET] <JEEB> you can't expect even if you set the time base before that the muxer will actually be capable of doing that
[17:55:12 CET] <JEEB> so after writing the header and initializing, just rescale
[17:55:27 CET] <JEEB> according to the muxer AVStream's time base
[17:55:53 CET] <kepstin> i think you might have to do a manual step to pass the muxer's time base to the encoder still? not sure
[17:56:20 CET] <JEEB> you have to set the time base anyways (or at least attempt to)
[17:56:45 CET] <JEEB> encoder's time base I would recommend being what you need. the conversions aren't bad anyways as long as you never skip them
[17:58:57 CET] <kepstin> hmm, but if you set encoder timebase to the muxer/avstream timebase, then the dts/pts values should be good right out of the encoder - i could imagine people forgetting to scale dts and getting weird issues due to that :)
[17:59:21 CET] <giaco> kepstin: late thanks for your answer
[18:00:11 CET] <giaco> well, yes, my requirements wants me to amplify the processed audio on the fly, without double pass and without knowing in advance the desired change in db. Is that possible?
[18:01:28 CET] <kepstin> giaco: yep. https://www.ffmpeg.org/ffmpeg-filters.html#loudnorm can operate in 1-pass mode, with a target loudness set in LUFS.
[18:03:45 CET] <kepstin> giaco: for a live streaming use case, it should be as simple as setting the `I` option on that filter to the desired loudness, and sticking an aresample filter after it to convert back to a reasonable sample rate (48K or 44.1K probably)
[18:06:13 CET] <faLUCE> JEEB: kepstin, so what is the appropriate time_base for h264 ? (variable frame rate)
[18:06:33 CET] <JEEB> whatever is good enough for you
[18:06:54 CET] <giaco> kepstin: I'd surely make a mess before getting the command line right. Would you be so gentle to drop a ffmpeg cmd considering mono PCM s16le 44100 in stdin and mp4 (or whatever) as output, same rate?
[18:07:09 CET] <kepstin> faLUCE: pick something that works for you, then try setting it on the output stream (muxer), and then check what the muxer actually returned, and use that
[18:07:27 CET] <kepstin> faLUCE: and *scale* to that.
[18:07:55 CET] <giaco> ffmpeg -f s16le -ar 44100 -ac 1 -i pipe:0 -map 0 .... -f lame out.mp3
[18:08:45 CET] <kepstin> giaco: take your existing command line, add `-af loudnorm=I=-18,aresample=44100`
[18:09:06 CET] <kepstin> replace the -18 with a value to taste (-18 is the reference level used for replaygain, fwiw)
[18:09:27 CET] <giaco> kepstin: thanks
[18:11:26 CET] <faLUCE> can I use a time base which is higher than the max framerate I can expect? for example:  mVideoEncoderCodecContext->time_base = (AVRational){1,200};
[18:11:39 CET] <faLUCE> and then rescale the pts according to it?
[18:12:49 CET] <giaco> kepstin: I'm pasting my whole cmd. It is working but I'm learning and I'm looking for any valuable suggestion from experts. Thanks
[18:12:58 CET] <giaco> ffmpeg -f s16le -ar 44100 -ac 1 -i pipe:0 -map 0 -af loudnorm=I=-18,aresample=44100 -c:a libopus -b:a 64000 -vbr on -compression_level 10 -frame_duration 20 -packet_loss 0 -application audio -cutoff 0 -f dash -strict -2 stream.mpd
[18:15:38 CET] <kepstin> giaco: fwiw, all of the options "-vbr on -compression_level 10 -frame_duration 20 -packet_loss 0 -application audio -cutoff 0", you're just setting them all to the default values
[18:15:47 CET] <kepstin> so you might as well just remove them
[18:16:33 CET] <giaco> kepstin: yes, but I'm playing with them so I prefer to leave them there waiting for some more tuning
[18:16:56 CET] <kepstin> opus internally does its own sample rate handling, it doesn't preserve sample rate. the recommended input rate to the opus encoder is 48000
[18:17:10 CET] <kepstin> (so change the aresample to 48000)
[18:19:18 CET] <giaco> I'd have never spotted that this fast :D thank you
[18:22:40 CET] <kepstin> giaco: regarding the opus settings - the only reason to change -compression_level is if you're really cpu limited on encoding/decoding, the default is max. I recommend not touching the frame_duration option - using a value other than 20 disables some of the encoding modes. The packet_loss setting is useless with dash, since it's served over tcp and can't lose packets.
[18:23:50 CET] <kepstin> the cutoff option generally shouldn't be used, the opus encoder has automatic cutoff configuration based on selected bitrate, but if you're right on the edge it might be useful as a tradeoff adjustment.
[18:24:17 CET] <kepstin> recent opus can do wideband at ridiculously low bitrates, which is pretty cool :)
[18:25:51 CET] <kepstin> with aac-lc encoders at low bitrate (libfdk_aac in particular), the cutoff option is often useful because the default is kinda low; depending on audio content you might prefer the artifacts of a higher cutoff vs the muddiness of a lower cutoff.
[18:26:47 CET] <giaco> I'm very impressed by opus performance
[18:27:12 CET] <giaco> I've been fighting to it for this application
[18:27:29 CET] <giaco> I know that opus in dash is experimental, but it works to me
[18:31:11 CET] <faLUCE> kepstin: from what I see, it should be useless to set a timebase for a variable frame rate, on the encoder. But ffmpeg wants it in each case. So I set it as AVRATIONAL {1,12} . And the problem disappeared
[18:32:09 CET] <kepstin> faLUCE: the encoder needs to know the timebase that the input frames are on if you want to use any bitrate controls
[18:32:32 CET] <kepstin> how can it know how many bits to allocate per frame if it doesn't know how many frames were in any given second?
[18:33:03 CET] <faLUCE> kepstin: it can now it if I set ctxt->bit_rate
[18:33:52 CET] <kepstin> faLUCE: that's "bits per second". so how does the encoder go from that value to "bits per frame" unless it knows how long each frame is?
[18:34:29 CET] <kepstin> faLUCE: you should set the timebase on the encoder to the same timebase that the frames your sending to the encoder have pts set relative to
[18:34:33 CET] <kepstin> then everything will work
[18:35:18 CET] <faLUCE> kepstin: given that I don't know the framerate, I set it to AVRATIONAL{1,100), which corresponds to a high framerate
[18:35:34 CET] <kepstin> faLUCE: timebase has nothing to do with framerate
[18:36:12 CET] <kepstin> faLUCE: you set timebase to a value such that pts * time_base = time_when_frame_displays_in_seconds
[18:37:51 CET] <kepstin> so if your frames have pts values "1, 30, 600", and your timebase is 1/5000, then your frames will be displayed at 0.002s, 0.06s, and 1.2s
[18:38:02 CET] <kepstin> er, timebase is 1/500 for that example
[18:38:02 CET] <faLUCE> kepstin: I set the pts, for each frame, in this way:   dateTimeNow.tv_sec * 1000000000 + dateTimeNow.tv_nsec;
[18:38:31 CET] <kepstin> faLUCE: ok, then your timebase is 1/1000000000
[18:38:45 CET] <faLUCE> kepstin: this is AV_RATIONAL_Q
[18:38:52 CET] <faLUCE> but it's too high for H264
[18:39:56 CET] <kepstin> you mean AV_TIME_BASE_Q?
[18:40:02 CET] <faLUCE> kepstin: yes, sorry
[18:40:33 CET] <faLUCE> (anyway, it doesn't matter... its' a timebase for the h264 encoder, not for the muxer)
[18:40:36 CET] <kepstin> that should be fine, check to make sure that the frames have the pts values you expect
[18:41:07 CET] <faLUCE> kepstin: if I set AV_TIME_BASE_Q I got the warning before I produce frames
[18:41:17 CET] <kepstin> what warning?
[18:41:18 CET] <faLUCE> I got it soon after allocating the codec context
[18:41:57 CET] <faLUCE> [libx264 @ 0x5565050987c0] MB rate (1200000000) > level limit (16711680)
[18:42:26 CET] <kepstin> that's printed before you try encoding any frames?
[18:42:42 CET] <faLUCE> kepstin: yes
[18:42:55 CET] <faLUCE> kepstin: note that I can encode, stream and mux all correctly
[18:43:07 CET] <faLUCE> but I want to avoid this strange warning
[18:43:45 CET] <faLUCE> kepstin: all the timestamps are  ok. as you saw, I compute them with date time and use AVRATIONAL_Q
[18:44:11 CET] <kepstin> hmm.
[18:44:13 CET] <faLUCE> but it seems that x264 doesn't want this resolution
[18:44:23 CET] Action: kepstin checks the x264 adapter code to see if there's anything obvious
[18:44:53 CET] <faLUCE> kepstin: maybe I could scale by 10 or 100 both the timebase and the pts
[18:45:00 CET] <faLUCE> so to avoid this warning
[18:45:27 CET] <kepstin> I normally recommend setting the encoder timebase to the value from the muxer, and then rescaling to that before sending frames to the encoder.
[18:45:50 CET] <kepstin> which would likely also work around this issue, if the problem is just that the timebase is too big for some precision inside x264
[18:46:02 CET] <faLUCE> kepstin: I use multiple muxers
[18:46:20 CET] <faLUCE> then I though about scaling both AV_TIMEBASE_Q and  timestamps
[18:46:25 CET] <kepstin> ah, encode once, then mux multiple times? that would be a pain then
[18:46:31 CET] <faLUCE> (thought)
[18:46:57 CET] <faLUCE> it's not a pain, I use a different timebases for each muxer
[18:47:19 CET] <kepstin> well, it means you don't have a single common timebase for all muxers
[18:47:26 CET] <faLUCE> exactly
[18:47:38 CET] <faLUCE> in fact the encoder's timebase is not strictly necessary
[18:47:54 CET] <faLUCE> but it could be useful if I record raw h264
[18:48:00 CET] <kepstin> hmm. so the libx264 wrapper sets the "fps" config on the x264 encoder to (time_base.den / time_base.num * avctx->ticks_per_frame)
[18:48:08 CET] <kepstin> that's probably what's causing the message
[18:48:29 CET] <faLUCE> kepstin: [17:28] <BugMaster|work> also you may need to set "ticks_per_frame"
[18:49:03 CET] <faLUCE> but what do I have to set for "ticks_per_frame" ?
[18:49:09 CET] <kepstin> yeah, setting ticks_per_frame based on an estimate - even a wild guess - of the framerate would probably be good enough
[18:49:45 CET] <faLUCE> kepstin: I don't know the framerate... it's variable
[18:50:17 CET] <faLUCE> kepstin: note that I did not have this warning on the previous version of ffmpeg or x264
[18:51:53 CET] <kepstin> this warning is printed inside x264 - all its saying is that "given the framerate you've told me as cfr, the amount of data being encoded would be too high for the selected level"
[18:52:12 CET] <faLUCE> kepstin: then I have to set vbr in some way
[18:53:14 CET] <kepstin> so yeah, in your case I guess you could just ignore it. Alternately set the ticks_per_frame value to something that you expect the input probably won't exceed, or reduce the timebase (you don't really need nanosecond accuracy anyways, no container can store that)
[18:53:45 CET] <kepstin> the only thing setting ticks_per_frame here would do is supress this warning, it shouldn't have any effect on the actual encoded video.
[18:54:17 CET] <faLUCE> kepstin: reading the API, about ticks_per_frame:   "Set to time_base ticks per frame. Default 1, e.g., H.264/MPEG-2 set it to 2."
[18:54:50 CET] <faLUCE> but the problem is that x264 believes it's cfr, while it's vbr
[18:56:08 CET] <kepstin> x264 defaults to vfr input, ffmpeg only overrides that to cfr mode if you enable the bluray compat option
[18:56:32 CET] <faLUCE> then why it thinks it's cfr ?
[18:56:43 CET] <kepstin> the input is working fine, the only issue is the warning about the level, which appears to be based only on what the input framerate is set to
[18:56:56 CET] <kepstin> so yeah, just ignore the warning.
[18:57:06 CET] <faLUCE> do you think it's a bug?
[18:57:21 CET] <faLUCE> I did not set any framerate
[18:57:40 CET] <kepstin> not really - you haven't set a framerate, so it can't possibly calculate a meaningful value there. ffmpeg guess makes a guess based on timebase, really.
[18:58:09 CET] <faLUCE> so, a workaround could be setting a high framerate...
[18:58:19 CET] <faLUCE> ?
[18:58:37 CET] <faLUCE> (I don't like this warning, I want to clear it)
[18:58:53 CET] <kepstin> a workaround could be setting the ticks_per_frame to something so that the i_fps values sent to x264 are something reasonable, then it won't show the warning.
[18:59:58 CET] <faLUCE> kepstin: this->mVideoEncoderCodecContext->ticks_per_frame = 100;         it works but I don't understand if 100 is reasonable
[19:00:39 CET] <faLUCE> what if I change the encoder's params? (profile, tune etc)
[19:01:46 CET] <faLUCE> another workaround is setting the timebase to a lower resolution
[19:01:55 CET] <faLUCE> (maybe)
[19:02:19 CET] <kepstin> the ticks per frame is basically saying "one frame is ticks_per_frame * time_base long" (or alternately, "the framerate is 1/ (ticks_per_frame * time_base")
[19:02:52 CET] <kepstin> i wonder if there's a way to just disable the level checking completely in x264
[19:03:55 CET] <faLUCE> from what I see this is stuff concerning cfr
[19:03:59 CET] <faLUCE> not vbr
[19:04:08 CET] <kepstin> faLUCE: anywayse, the warning itself is meaningless for your usecase, and can be ignored. The whole levels concept makes no sense unless your content is cfr (or at least has a known maximum framerate)
[19:04:28 CET] <faLUCE> I know it's meaningless, but I want to remove it
[19:04:42 CET] <kepstin> if you have a known maximum framerate, then just calculate a ticks_per_frame based on that, and you're done.
[19:04:44 CET] <faLUCE> it's annoying to view it while running my library
[19:05:00 CET] <faLUCE> maximum framerate is 100
[19:06:02 CET] <kepstin> if you know a max framerate, then set ticks_per frame to 1/(maxrate*time_base)
[19:06:29 CET] <faLUCE> time_base is expressed as AV_TIMEBASE_Q
[19:06:50 CET] <faLUCE> then 1/(100 * ...? )
[19:06:53 CET] <kepstin> equivalently, with integer math, ticks_per_frame =  time_base.den / max_framerate
[19:07:01 CET] <faLUCE> ok thanks
[19:07:04 CET] <faLUCE> let's try
[19:07:10 CET] <kepstin> and add a * time_base.num on the end in case that's ever a value other than 1
[19:07:19 CET] <kepstin> which is unlikely in your use case, but still
[19:11:22 CET] <kepstin> hmm. not sure if I got that quite right, maybe that should be a /time_base.num at the end - need to check the math there :0
[19:11:57 CET] <kepstin> (pretty much the only time you see a time base numerator other than 1 is when dealing with ntsc cfr content, where the numerator is 1001)
[19:12:45 CET] <faLUCE> kepstin: with your previous formula I obtained  ticks_per_frame = 10000
[19:16:13 CET] <kepstin> `ticks_per_frame = time_base.den / max_frame_rate / time_base.num` is the correct formula
[19:16:31 CET] <kepstin> (you'll still get 10000 with AV_TIME_BASE_Q)
[19:16:44 CET] <faLUCE> yes
[19:17:12 CET] <faLUCE> anyway, thanks for all (btw: what a pain for a so strange warning...)
[19:17:39 CET] <faLUCE> I think this is a bug
[19:19:00 CET] <kepstin> kind of a tricky bug, if so. x264 can't print this warning unless it knows the expected framerate in advance, and in full vfr mode, ffmpeg doesn't have any field with the expected frame rate stored.
[19:19:15 CET] <kepstin> x264 can't print the warning correctly*
[19:19:25 CET] <faLUCE> I agree
[19:19:51 CET] <faLUCE> but I think that the default for x264 is cfr
[19:20:00 CET] <faLUCE> so it seems a ffmpeg bug
[19:20:03 CET] <kepstin> no, it correctly defaults to vfr input
[19:20:18 CET] <faLUCE> uhmmmm
[19:20:39 CET] <kepstin> ffmpeg is setting the "expected framerate" that x264 uses to check level limits based on the timebase, since it doesn't have any better value available for vfr stuff.
[19:20:52 CET] <kepstin> but the actual video encoding and rate control is all correctly vfr
[19:21:08 CET] <kepstin> the warning does nothing except tell you that x264 couldn't verify the level
[19:21:33 CET] <faLUCE> no, the warning says that it's uncorrect level
[19:21:47 CET] <faLUCE> maybe x264 people should change the msg?
[19:23:28 CET] <faLUCE> now, closed this issue, is there an #ifdef which I can use in order to check if the library's version is > than 4.x ?
[19:23:30 CET] <kepstin> it doesn't say incorrect level anywhere? Just that one of the parameters of the input video would exceed the limit that the selected level has
[19:24:19 CET] <faLUCE> coming back in 15 mins
[19:29:05 CET] <kepstin> hmm. i think this can be improved in the ffmpeg side, actually. The x264 wrapper could check the `framerate` field on the  encoder context, and if it's set to the special value 0/1 which is used to explicitly indicate vfr, then it can set the x264 i_fps fields to 0, which will disable this limit check.
[19:31:35 CET] <kepstin> https://git.videolan.org/?p=x264.git;a=blob;f=encoder/set.c;h=07a1261e180d001feb26b12d9179c7734ee979e6;hb=refs/heads/master#l852 appears to be where this warning is printed
[19:33:18 CET] <kepstin> that's not a typical or documented usage of the framerate field, but it could work for this use case.
[20:22:35 CET] <kepstin> oh, never mind, that doesn't work. setting i_fps to blank values means x264 will use the default of 25fps internally
[21:24:37 CET] <Abbott> I am getting "Automatic encoder selection failed for output stream #0:0. Default encoder for format mp3 (codec png) is probably disabled. Please choose an encoder manually." but didn't I manually specify an encoder with -c:a libmp3lame if that was in my command?
[21:26:09 CET] <Abbott> Stream #0:0: Audio: flac, 44100 Hz, stereo, s16, in this case
[21:28:16 CET] <JEEB> Abbott: you should probably pastebin the full log but I kind of expect the thing to be the album art or so
[21:35:55 CET] <Abbott> okay, one sec
[21:39:55 CET] <Abbott> JEEB: http://dpaste.com/1V8JNVD.txt
[21:40:16 CET] <JEEB> yup
[21:40:43 CET] <JEEB> it's trying to push the JPEG from the flac into the mp3
[21:41:32 CET] <Abbott> How would I tell it to strip the embedded album art?
[21:42:59 CET] <JEEB> there was an option for that but I don't remember it exactly
[21:43:13 CET] <furq> -vn
[21:43:35 CET] <JEEB> well yes, that's one way
[21:43:42 CET] <JEEB> that just disables video in output
[21:51:00 CET] <Abbott> sweet, -vn seems to do it. I encoded a lot of music with a find ... -exec ffmpeg .... command, so will adding -n be a good way to ensure I don't re-encode stuff I already did? Or is that not how -n works
[21:51:44 CET] <JEEB> no, it's not that
[21:53:37 CET] <Abbott> so the files that failed because of the embedded artwork didn't get outputted to the dest directory, but the ones that didn't have artwork did. -n says "don't overwrite dest file if it exists," so wouldn't that mean it would skip over files that have already encoded?
[21:55:55 CET] <JEEB> ok, there was an alternative to -y?
[21:55:57 CET] <JEEB> then maybe
[21:56:05 CET] <JEEB> I thought you were gathering something out of -vn towards just -n
[21:58:24 CET] <Abbott> oh, no. I just stumbled upon -n the other day on accident cause i was looking for something like a --dry-run flag (I since found -f null)
[21:58:30 CET] <Abbott> but now I figure it's good for this application
[22:03:49 CET] <Hello71> I think -n also returns non-zero if the output exists
[22:04:13 CET] <JEEB> quite likely
[00:00:00 CET] --- Wed Feb 20 2019