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

[burek]

[01:47:45 CET] <v`> o
[01:47:59 CET] <v`> sorry, fumblefingers
[01:49:38 CET] <v`> i'm looking at https://ffmpeg.org/ffmpeg-filters.html#Examples-19
[01:50:04 CET] <v`> specifically, "Another example for audio with whisper and explosion parts:" compand=0|0:1|1:-90/-900|-70/-70|-30/-9|0/-3:6:0:0:0
[01:50:46 CET] <v`> the "-90/-900|-70/-70|-30/-9|0/-3" part, that's the "points="?
[01:51:21 CET] <v`> does that mean "0|0" is attacks and "1:-90" is decays?
[01:51:36 CET] <v`> err, 1:-90 is decays?
[01:51:48 CET] <v`> gah sorry
[01:51:58 CET] <v`> 1|1 is decays?
[01:52:36 CET] <v`> i'm so used to pipes being terminators that it's hard to get my eyes to see that colon is terminator here
[01:56:54 CET] <v`> what does the pipe operator do there?
[01:59:17 CET] <furq> you could also write compand=attacks=0|0:decays=1|1:points=-90/-900|-70/-70|-30/-9|0/-3:soft-knee=6
[01:59:36 CET] <furq> it'd be nice if one of the examples did that
[02:00:32 CET] <furq> | is just a list separator
[02:03:14 CET] <v`> wait, so "0|0" is just like saying attacks is zero for the first channel and then the 2nd zero in "0|0" sets the remaining channels' attacks to zero too?
[02:04:44 CET] <furq> the second would be the second channel
[02:04:54 CET] <furq> if you have 5.1 then you probably need 0|0|0|0|0|0
[02:05:00 CET] <furq> i've never used that filter though so maybe just 0 works
[02:05:39 CET] <furq> If specified number of attacks & decays is lower than number of channels, the last set attack/decay will be used for all remaining channels.
[02:05:42 CET] <furq> oh right
[02:05:43 CET] <v`> i'm wondering because "If specified number of attacks & decays is lower than number of channels, the last set attack/decay will be used for all remaining channels."
[02:05:52 CET] <furq> yeah you can just use 0 then
[02:06:08 CET] <v`> wait, so,
[02:06:20 CET] <v`> is attacks=0|0 the thing to do, or,
[02:06:32 CET] <v`> is that the same as attacks=0, or...?
[02:06:36 CET] <furq> should be
[17:03:08 CET] <deltasquared> I'm currently attempting to re-encode some webm's that use vp8 for the video codec into h264 so that they play nicer with my phone's hardware decoding ability. just noticed that ffmpeg's defaults for the "slow" preset don't appear to be tolerated by my phone though at at least 720p and above.
[17:03:30 CET] <deltasquared> (being played with the stock video player on a lineageos samsung galaxy S5.)
[17:03:56 CET] <deltasquared> just going to copy the command I used and do some quick sanity ffprobe's...
[17:04:12 CET] <kepstin> the preset only indirectly affects this, and ffmpeg doesn't default to slow
[17:04:32 CET] <furq> deltasquared: -level 41
[17:04:32 CET] <kepstin> if you know what h264 profile the device supports, you can use the -profile option to tell x264 not to exceed that profile's limits
[17:04:44 CET] <kepstin> or level, yeah
[17:05:05 CET] <furq> it's pretty much always high at 4.1
[17:05:16 CET] <furq> and also i checked and it is for that phone
[17:06:32 CET] <deltasquared> kepstin: I was trying to retain source quality where possible. I guess -crf would be a better way to achieve that
[17:06:47 CET] <kepstin> deltasquared: preset affects encoding efficiency, not quality
[17:07:06 CET] <furq> setting the preset is fine, you just need to ensure it doesn't exceed the max refs for the level your hwdec supports
[17:07:18 CET] <furq> -level 41 should clamp it to the right number
[17:08:31 CET] <deltasquared> I'll try playing with that setting and see if it'll play on one video first then try the others.
[17:08:34 CET] <furq> with that said slow and slower should be fine at 720p
[17:08:43 CET] <furq> that should only be an issue at 1080p
[17:08:48 CET] <deltasquared> furq: there's a couple 1080p ones :P
[17:08:55 CET] <deltasquared> thankfully nothing higher than that
[17:09:08 CET] <deltasquared> (just as well, I only *have* a 1080p screen on the device!)
[17:09:09 CET] <furq> anything above 1080p probably won't work at all
[17:09:42 CET] <deltasquared> > 30.01 fps
[17:09:43 CET] <deltasquared> wut
[17:09:53 CET] <deltasquared> (just having a look at ffprobe output of one of the 1080p ones)
[17:10:08 CET] <kepstin> https://www.qualcomm.com/products/snapdragon-processors-801 says it's supposed to to 4k, but i wonder if that's only hevc?
[17:10:24 CET] <deltasquared> gosh, I have never tried h265 on this thing
[17:10:24 CET] <furq> yeah it normally is
[17:10:51 CET] <furq> 4k h264 needs level 5.1 iirc and basically nothing will hwdec that
[17:11:04 CET] <kepstin> also different versions of that phone use different chips, so :/
[17:11:25 CET] <kepstin> could be a snapdragon 801, snapdragon 805, or exynos 5 octa 5422
[17:12:01 CET] <deltasquared> kepstin: I have the international version (klte)
[17:12:26 CET] <kepstin> if you have the exynos version apparently it has hardware vp8 decoding
[17:12:40 CET] <kepstin> whether that actually works in the os... ? :/
[17:12:48 CET] <deltasquared> not sure
[17:12:59 CET] <deltasquared> the device gets very warm and often struggles playing anything webm
[17:13:07 CET] <furq> are you sure they're not vp9
[17:13:27 CET] <furq> i don't think youtube does vp8 for hd resolutions
[17:13:36 CET] <deltasquared> furq: hard to tell seeing how much of an asspull it is to get a linux chroot on it now with all the SELinux restrictions
[17:13:42 CET] <deltasquared> furq: not youtube.
[17:13:46 CET] <furq> oh
[17:14:02 CET] <kepstin> ffprobe would say the actual codec
[17:14:09 CET] <furq> i also don't know why anyone would use vp8 for 1080p but it's a big old internet out there
[17:14:19 CET] <deltasquared> kepstin: in the case of the videos I have here they're all vp8
[17:14:20 CET] <furq> i'm sure someone's found a reason
[17:16:10 CET] <deltasquared> furq: https://a.uguu.se/cAThGkcw6BrW_ffprobe.txt
[17:16:26 CET] <kepstin> but yeah, h264 high profile level 4.1 is a good safe option.
[17:16:33 CET] <ramiro> is there any diagram-based ui for ffmpeg and filters out there?
[17:16:51 CET] <ramiro> kind of like gst-editor (which seems to be dead for over a decade)
[17:16:56 CET] <furq> there's graph2dot but that's read-only
[17:17:03 CET] <deltasquared> ramiro: something like unity's node graph say?
[17:17:17 CET] <deltasquared> (or whatever engine that fancy shader editor belongs to)
[17:18:26 CET] <ramiro> deltasquared: interesting. yes, something like that.
[17:22:10 CET] <deltasquared> kepstin: "$input" -acodec copy -vcodec libx264 -level 41 "${input}.mp4"
[17:22:19 CET] <deltasquared> still get a "can't play this video" when copied to the device
[17:22:32 CET] <deltasquared> erm, missed the ffmpeg -i off the start of that
[17:22:58 CET] <deltasquared> kepstin: what, of the ffmpeg run? won't that mangle the terminal escape codes?
[17:23:28 CET] <kepstin> of the ffmpeg run, just need the text i don't care about colours or anything like that
[17:24:55 CET] <deltasquared> it'd help if ffmpeg wasn't insisting on writing to stderr all the time >_>
[17:27:11 CET] <deltasquared> kepstin: https://a.uguu.se/RnrmMhIAEy7Q_ffmpeg.log.txt there.
[17:27:26 CET] <kepstin> it's usually easiest to just let it run then copy/paste the text from the terminal, but you can try the "-report" option if you're using a terminal with poor copy/paste support.
[17:27:46 CET] <kepstin> (btw, if the stats line is scrolling for you, make the terminal window wider)
[17:28:03 CET] <deltasquared> copy-pasting a large chunk of text is always gonna be clumsy even with good copy-paste. I just prefer to tee it.
[17:28:12 CET] <kepstin> you're putting vorbis audio into an mp4 file, that's probably going to end with a bad time
[17:28:16 CET] <deltasquared> ...
[17:28:20 CET] <deltasquared> how did I not notice that
[17:28:23 CET] <deltasquared> D:
[17:28:27 CET] <deltasquared> FUDGE
[17:28:30 CET] <kepstin> try "-c:a aac" (that should be the default with mp4 output)
[17:28:41 CET] <deltasquared> kepstin: this thing can understand mkv so I may try that instead
[17:29:00 CET] <deltasquared> at least that way the container supports the codec (I hope)
[17:30:36 CET] <deltasquared> that appears to have worked.
[17:30:53 CET] <deltasquared> kepstin: I guess that's why you wanted the terminal output huh. even supposed programmers miss the bleeding obvious at times >_>
[17:31:01 CET] <kepstin> the video codec probably wasn't the issue all along
[17:32:02 CET] <deltasquared> kepstin: perhaps not, but using just the defaults bar -level 41 does give visually acceptable results, so I guess I'm happy for now
[17:32:07 CET] <kepstin> (honestly, i wouldn't be surprised if x264 was generating high profile level 4.1 from the start, at least on the 720p videos)
[17:32:15 CET] <furq> yeah it should have been
[17:32:31 CET] <furq> it'll be 4.1 or less unless you have more than 9 refs
[17:32:49 CET] <furq> slow uses 5 and slower uses 8
[17:32:50 CET] <deltasquared> refs in this context being...?
[17:32:53 CET] <furq> reference frames
[17:33:22 CET] <kepstin> deltasquared: you can still use the -profile and -crf options in combination with profile/level  to adjust quality and size tradeoffs, of course
[17:33:50 CET] <furq> more reference frames is better for compressibility but it means the decoder needs a bigger buffer to hold them
[17:34:11 CET] <furq> and obviously hwdec has a fixed size buffer so if you exceed that it just won't work
[17:34:33 CET] <deltasquared> what would actually happen in practice? would it just stall and/or stutter perhaps?
[17:34:40 CET] <deltasquared> (in the case you described)
[17:34:56 CET] <furq> well the max refs used by the stream is signalled in a header
[17:34:59 CET] <furq> so it would just bail out immediately
[17:35:24 CET] <furq> or more likely fall back to software
[17:36:00 CET] <deltasquared> well, in a correctly designed software stack perhaps... given the inability of the video player on this device currently to frameskip when it runs into trouble, I don't have that much faith in it
[17:36:18 CET] <furq> it's probably falling back to software and then the cpu can't keep up
[17:36:35 CET] <deltasquared> yeah but like why's it gotta stall for five secs or lock up completely :/
[17:36:39 CET] <deltasquared> something's not right in there
[17:40:52 CET] <deltasquared> re: my acodec derp, that would explain why that "lower res" video worked as well... it didn't have an audio stream to begin with. x)
[19:16:18 CET] <gp> Is anyone able to remove me from the users mailing list? I've tried a few times via the website and also by sending an unsubscribe email but no luck for about a month
[19:16:45 CET] <gp> Or able to change it to a summary of conversations I haven't participated in
[19:20:28 CET] <BtbN> There's instructions at the bottom of every E-Mail you get from the list.
[19:20:37 CET] <BtbN> Just make sure to actually send from the address that's on the list.
[19:22:50 CET] <phk> hi, i got have scale_npp filter in my ffmpeg
[19:23:10 CET] <phk> i have completed with cuda
[19:23:35 CET] <phk> and i see nvenc and cuvid encoder/decoders
[19:23:48 CET] <phk> but i dont have scale_npp
[19:24:37 CET] <phk> do i have to enable anything while compilation?
[19:28:25 CET] <phk> ffmpeg version git-2019-12-08-9f7b2b3 Copyright (c) 2000-2019 the FFmpeg developers
[19:28:25 CET] <phk>   built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-39)
[19:28:25 CET] <phk>   configuration: --enable-gpl --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-nonfree --enable-version3 --enable-pic --enable-libfreetype --enable-libfdk-aac --enable-openssl --enable-shared --enable-libass --enable-libvpx --enable-libx265 --enable-libtwolame --enable-libpulse
[19:28:25 CET] <phk>   libavutil      56. 36.101 / 56. 36.101
[19:28:26 CET] <phk>   libavcodec     58. 64.101 / 58. 64.101
[19:28:28 CET] <phk>   libavformat    58. 35.101 / 58. 35.101
[19:28:30 CET] <phk>   libavdevice    58.  9.101 / 58.  9.101
[19:28:32 CET] <phk>   libavfilter     7. 68.100 /  7. 68.100
[19:28:34 CET] <phk>   libswscale      5.  6.100 /  5.  6.100
[19:28:36 CET] <phk>   libswresample   3.  6.100 /  3.  6.100
[19:28:42 CET] <phk>   libpostproc    55.  6.100 / 55.  6.100
[19:28:44 CET] <phk> sorry pastebin isnt working
[19:38:19 CET] <phk> NVIDIA-SMI 440.26       Driver Version: 440.26       CUDA Version: 10.2
[19:40:33 CET] <gp> btbn: I have sent the unsubscribe as instructed atleast a dozen times and gotten confirmation responses. I have also logged into the mailman interface and changed my subscription settings.  But it doesn't seem to remember and I get like 20 emails some days
[19:41:19 CET] <BtbN> Sounds to me like you unsubscribed the wrong address.
[19:54:49 CET] <gp> Maybe so
[19:55:16 CET] <gp> there isn't an option for a weekly digest is there
[19:55:32 CET] <gp> ? I like to stay up on questions but I can't track the bursts of emails
[21:24:55 CET] <bencc1> I'm getting "default: No such process" error inside debian stable container when trying to capture screen and audio:
[21:25:14 CET] <bencc1> ffmpeg -f pulse -ac 2 -ar 48000 -i default -f x11grab -framerate 30 -i :0.0 -acodec aac -b:a 96k -vcodec libx264 -pix_fmt yuv420p -preset:v veryfast -crf 23 -vf fps=30 cap.nut
[21:36:15 CET] <bencc1> also getting the error when using: "ffmpeg -f pulse -i default out.wav"
[00:00:00 CET] --- Sat Dec 21 2019