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

[burek]

[00:00:58 CEST] <arinov> hi there
[00:06:02 CEST] <arinov> is there a way to add realtime audio waveform to the bottom of source video file?
[00:07:52 CEST] <tytan> this guy explains it well youtube.com/watch?v=M58rc7cxl_s
[00:09:42 CEST] <kepstin> arinov: sure, with a complex filter chain. You'd send the audio track to the 'showwaves' filter, which converts it to a video stream, then use the overlay or vstack filters or something like that to composite it with the video.
[00:11:08 CEST] <arinov> it seems i have a quest for a week now) thanks!
[00:11:15 CEST] <kepstin> arinov: that said, there's probably tools out there other than ffmpeg that'll might give fancier looking results, ffmpeg's audio visualization stuff is fairly basic.
[00:11:36 CEST] <kepstin> but it's doable :)
[00:12:18 CEST] <arinov> i need it because i want upload my tracks and my scheduler must do all the works automated, i will get it later
[00:12:30 CEST] <kepstin> (also check showspectrum and showfreqs, which are related but show different things about the audio)
[00:12:36 CEST] <arinov> so in automation case i see no variants except ffmpeg
[00:12:51 CEST] <tytan> you can specify colors with hex values
[00:13:16 CEST] <tytan> if you use two complementig colors for each channel you get a white wave where the channels are the same. nice effect
[00:15:07 CEST] <kepstin> i don't think the audio visualization filters do transparent output normally? You might want to use the "blend" filter to render the result over your background, something like addition mode might look good.
[00:15:19 CEST] <arinov> yeah, i need time to build argument list first
[00:15:43 CEST] <arinov> i know ffmpeg can split the video and add something
[00:15:54 CEST] <arinov> i also know it can build realtime waveform
[00:16:36 CEST] <arinov> so i just need to add the waveform into video with audio track 80/20 approx
[00:16:39 CEST] <arinov> so i think ffmpeg is ok with this
[00:17:47 CEST] <tytan> have a nice day everyone
[02:51:33 CEST] <baffled> Hi folks: I'm hoping someone could give me a clew where to check on a message I'm getting when playing flac files after converting from 'ape'
[02:51:49 CEST] <baffled> The message is: [flac @ 0x7f3269c4b6e0]Got unexpected packet after EOF
[02:53:11 CEST] <baffled> I'm using mplayer to play the flac file after converting from 'ape to 'flac and then splitting with shntool. I get the message continuously on all the flac files although the hex address changesw from file to file.
[02:53:56 CEST] <baffled> I used ffmpeg -i file.ape file.flac and ffmpeg file.ape -map 0:0 file.flac
[02:54:17 CEST] <baffled> The result is the same.
[02:54:53 CEST] <baffled> Mplayer plays the 'ape' file with no odd messages.
[02:56:50 CEST] <relaxed> baffled: pastebin.com the command and output
[03:02:46 CEST] <baffled> relaxed: http://ffmpeg.pastebin.com/ gives me a host not found message.
[03:04:13 CEST] <relaxed> https://pastebin.com/
[03:15:49 CEST] <baffled> Okay here's the pastbin link https://pastebin.com/JAXmE6vM
[03:22:26 CEST] <relaxed> You snipped some of ffmpeg's output. Which ffmpeg version? So it plays fine? You just alarmed at the message?
[03:25:08 CEST] <baffled> Ah, sorry my screen's only 64 lines.  it's version 4.0.2-2 debian sid. I can past either here or pastbin the entire header if you like.
[03:26:51 CEST] <relaxed> does it play/sound fine?
[03:27:40 CEST] <relaxed> try playing it with mpv, mplayer's successor
[03:27:41 CEST] <baffled> Yeah, it plays great it's just those scrolling messages.
[03:32:12 CEST] <baffled> Ah okay ht....Yeah, it plays but I'm getting errors: [ao/alsa] Error received from snd_pcm_avail (-77, File descriptor in bad state)!
[03:32:15 CEST] <baffled> (Paused) A: 00:00:07 / 00:37:00 (0%)
[03:32:42 CEST] <baffled> It still plays just fine.
[03:35:58 CEST] <relaxed> I've noticed those lately too- it has nothing to do with the file
[03:36:50 CEST] <relaxed> I think the eof message is probably an mplayer bug
[03:37:56 CEST] <baffled> I'd try ffplay but it seems to want to demand a display even with the -vn flag.
[03:45:27 CEST] <baffled> Thanks relaxed mpv worked just fine if I let a piece play straight through, so it probably is an mplayer bug.
[03:49:16 CEST] <relaxed> you're welcome
[08:28:59 CEST] <pingufan> Good morning.
[08:30:43 CEST] <pingufan> Can somebody, please help me?  I have here a .ts stream with distorted aspect ratio and want to scale it to 1280x720.  My ffmpeg scales up to 720 lines, but always keeps the wrong aspect ratio.
[08:34:58 CEST] <pingufan> In a first run I crop away black borders (video has black borders on all four sides) and store it as h264 in a new .mkv file.  This file plays correctly (with distorted video)
[08:35:36 CEST] <pingufan> I use this command:    ffmpeg -y -i "/goliath/filme/filmarchiv/Unterhaltung/Unternehmen Petticoat.mkv" -vf crop=512:464:106:56 -c:v libx264 -tune film cropped.mkv
[08:37:07 CEST] <pingufan> The resulting video is:   Stream #0:0: Video: h264 (High), yuv420p, 512x464
[08:37:38 CEST] <pingufan> Now i need to stretch 512x464 --> 1280x720
[08:38:52 CEST] <pingufan> All descriptions I find show how to do it, but it does not work as it should.
[08:40:12 CEST] <pingufan> This is what I currently try:    ffmpeg -y -i cropped.mkv -video_size 512x464 -c:v libx264 -crf 22 -x264-params keyint=25 -movflags +faststart -tune film -vf scale=1280x720 test.mkv
[08:43:01 CEST] <pingufan> Can somebody, please, help?
[08:44:39 CEST] <furq> pingufan: get rid of that intermediate file and use -vf crop=512:464:106:56,setsar=1,scale=1280:720 on the original file
[08:46:58 CEST] <pingufan> Again height now too much. width seems to be 1280.
[08:47:18 CEST] <furq> pastebin the command and full output
[08:47:37 CEST] <pingufan> But the viveo has height of entire screen (My screen is 1920x1200.
[08:49:10 CEST] <pingufan> https://pastebin.com/DLPgrUSA
[08:49:46 CEST] <pingufan> I started a conversion, pressed then "q", and made the copy/paste
[08:50:43 CEST] <furq> try setdar=1 instead
[08:50:44 CEST] <furq> or both
[08:51:43 CEST] <pingufan> No difference (in both cases)
[08:53:25 CEST] <furq> oh
[08:53:30 CEST] <pingufan> Stream #0:0: Video: h264 (High), yuv420p, 1280x720 [SAR 18:29 DAR 32:29], SAR 116:187 DAR 1856:1683, 50 fps, 50 tbr, 1k tbn, 100 tbc (default)
[08:53:30 CEST] <furq> move setsar=1 after scale
[08:54:12 CEST] <pingufan> ffplay shows me 1280x720, but it is not displayed in that size and aspect when I try to pay.
[08:54:16 CEST] <pingufan> play
[08:54:50 CEST] <pingufan> squeezed horizontally
[08:56:10 CEST] <pingufan> do you want to see a screenshot?
[08:56:33 CEST] <BtbN> it is playing it according to the SAR and DAR.
[08:57:14 CEST] <furq> pingufan: like i said, move setsar=1 after scale
[08:57:29 CEST] <furq> -vf crop=512:464:106:56,scale=1280:720,setsar=1
[08:58:28 CEST] <pingufan> (y)    Now it is correct.
[08:59:01 CEST] <furq> also add -c:a copy unless you actually want to reencode the audio
[09:00:50 CEST] <pingufan> In scenes with higher motion I see horizontally staggered edges.
[09:02:29 CEST] <pingufan> Does this come from upscaling or interlacing?
[09:03:56 CEST] <pingufan> seems to come from interlacing (or looks like that).
[09:06:47 CEST] <pingufan> I placed yadif as first video filter. This solved it.
[09:07:14 CEST] <pingufan> Thank you so much for your helping.
[11:00:49 CEST] <keglevich> hey all... I'm searching for a compiled version of ffmpeg (x86 or x64) for windows with pthreads enabled? Is there an option to get a link to a working build, no matter which version?
[11:01:28 CEST] <BtbN> There are no pthreads on Windows. It will alaways be emulated to win32threads anyway
[11:02:47 CEST] <Mavrik> Yeah, that's a rather strange requirement.
[11:02:52 CEST] <keglevich> I compiled one myself (v4.0.2) with --disable-s32threads, but I have a strange issue... no matter which value I set for bitrate UPD output parameter, the output UDP speed is always 1.3 - 1.4mbit/s, and the stream crashes after about 10secs with "cannot allocate memory" fatal error... If I run that same build without "bitrate" output parameter, it works just fine
[11:02:56 CEST] <Mavrik> If you really need that, run the linux ffmpeg inside WSL ?
[11:03:28 CEST] <keglevich> I need pthreads build on windows as it can produce almost perfect CBR, using additional UDP output parameters
[11:03:34 CEST] <BtbN> And what makes you think that's related to pthreads?
[11:03:37 CEST] <keglevich> with w32threads version it seems impossible
[11:03:48 CEST] <BtbN> Again, there are no pthreads on Windows
[11:04:10 CEST] <keglevich> strange is...when I have another service enabled on same system (tightvnc service for instance), the bitrate parameter is accepted ok and works at expected bitrate value
[11:04:18 CEST] <keglevich> I don't have an explanation for this
[11:05:49 CEST] <keglevich> btbn: you say there are no pthreads on windows... what then --disable-w32threads does? I compiled a working version, but it works strange
[11:06:47 CEST] <keglevich> or let me ask another way...is there an option then to somehow use UDP output parameters with w32threads version? Or maybe somehow else achieve to have pefect UDP output?
[11:06:56 CEST] <keglevich> ffmpeg -re -i 1.mp4 -g 50 -c:v libx264 -preset veryfast -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -ac 2 -b:a 192k -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316&bitrate=2600000"
[11:07:21 CEST] <Foaly> i guess that option would then disable threading
[11:07:30 CEST] <keglevich> this is the command I'm using...without bitrate UDP ourput parameter, the stream is not "perfect" CBR, it has some spikes and bursts all the time (about +- 10%)
[11:09:09 CEST] <keglevich> with "bitrate" output parameter, stream is nice CBR, but only works if there is some other TCP/UDP service running on the same system (like tightvnc service for instance)... on a clean install OS, it'll run at about 1.4mbit/s and crash after 10secs... I know this is super strange
[11:09:23 CEST] <keglevich> I tried on 10+ different PC's, different OS's
[11:10:30 CEST] <keglevich> that's why I'm searching for another build with w32-threads disabled for windowd so I can at least compare the behaviour
[11:12:11 CEST] <BtbN> udp.c has some pthread specific code it seems
[11:12:19 CEST] <BtbN> that just does not work on Windows, due to lack of pthreads.
[11:13:27 CEST] <BtbN> No idea if some pthread emulation can serve the same purpose, you'll have to try that yourself.
[11:15:10 CEST] <keglevich> BtbN: you have any clue why this strange behaviour I was writing about abowe?
[11:15:40 CEST] <BtbN> Likely unrelated to threads
[11:16:05 CEST] <BtbN> Blame the Windows network stack, or your firewall
[11:16:27 CEST] <keglevich> is there maybe another option to make as good as possible CBR with w32threads build?
[11:16:44 CEST] <keglevich> firewalls disabled, tried 5+ different NIC's, different OS's
[11:24:27 CEST] <ilushka4> hey fella, it's not public
[11:37:38 CEST] <durandal_1707> ilushka4: ?
[11:38:01 CEST] <ilushka4> durandal_1707, for some reason, I have a rtsp(mms) stream which I can run with windows media player, but cannot run it with ffmpeg (first tried it with ffmpeg-python and then ffplay). I was trying the query: .\ffplay.exe -i "mms://foobar" -f rtsp, but it returns 400 Bad request
[11:43:27 CEST] <furq> BtbN: mingw includes a pthread emulation library nowadays
[11:43:29 CEST] <furq> winpthreads iirc
[11:43:46 CEST] <furq> idk why that would behave differently to just native win32 threads though
[11:44:26 CEST] <BtbN> furq, because udp.d, and a bunch of other ffmpeg code, has pthread-only code, so with win32threads it's disabled
[11:44:29 CEST] <BtbN> *.c
[11:44:54 CEST] <keglevich> furq: by using w32threads version there's no option to use "bitrate" output UDP parameter
[11:45:08 CEST] <furq> oh
[11:47:17 CEST] <keglevich> as well as some other UDP parameters...pthreads is required to use them
[11:47:33 CEST] <BtbN> Use Linux
[11:47:48 CEST] <BtbN> If all else fails, use WSL. It definitely has pthreads.
[11:48:00 CEST] <keglevich> what is WSL?
[11:48:15 CEST] <furq> https://docs.microsoft.com/en-us/windows/wsl/about
[11:48:19 CEST] <furq> windows 10 only
[11:48:35 CEST] <keglevich> ah ok...linux again
[11:48:58 CEST] <furq> it's not that difficult to build ffmpeg
[11:49:07 CEST] <furq> especially if the only external lib you need is x264
[11:49:37 CEST] <keglevich> building is not that big of an issue...bigger issue is that I use an win-based app which uses ffmpeg to UDP output
[11:50:13 CEST] <keglevich> casparcg...uses shared ffmpeg libs, runs on windows
[11:54:14 CEST] <furq> is that not open source
[12:00:41 CEST] <keglevich> casparcg is opensource...but I use it in conjunction with another app which is windows only...also there's more, it has to run on windows anyway
[12:05:37 CEST] <furq> well i meant that you can build it with whatever build of ffmpeg
[12:07:53 CEST] <keglevich> hmm...I'm confused...if I build ffmpeg on linux and use shared libs with windows version of casparcg...will it work?
[12:11:41 CEST] <furq> if you cross-compile ffmpeg on linux, sure
[12:11:49 CEST] <furq> as long as you can build casparcg with mingw
[12:16:24 CEST] <keglevich> casparcg is built with visual studio 2010
[12:16:44 CEST] <keglevich> as far as I know...and it requires redistirbutable .net 2010
[12:41:53 CEST] <RoundHash> I have a sequence of JPG images that I'm trying to convert to a h264 video using "ffmpeg -r 60 -i %05d.jpg -i audio.wav -c:v libx264 -c:a aac video.mp4", but it comes out darker than the input images, anyone able to point me in the right direction here?
[12:42:05 CEST] <RoundHash> As an example #0b0b0b is converted to #000000 and #1d1d1d goes to #0f0f0f
[12:43:20 CEST] <furq> RoundHash: -vf colorspace=irange=jpeg:range=mpeg
[12:45:34 CEST] <RoundHash> I'll give it a go, thanks. What's actually happening that's making the colours change?
[12:47:57 CEST] <furq> actually i forgot ffmpeg will default to full range output if the source is jpeg
[12:48:01 CEST] <furq> so i'm guessing your player doesn't like that
[12:48:05 CEST] <furq> try just -vf format=yuv420p
[12:49:16 CEST] <RoundHash> Ha, yeah, you're right. Cool, thanks. So, it's a problem converting between an RBG colour space int he JPEG to a YUV one on the other side?
[12:49:18 CEST] <furq> basically jpeg normally uses full range colour values (0-255) and mpeg normally uses limited range (16-235)
[12:49:55 CEST] <RoundHash> Oh right, that's kinda interesting, is that just for compression?
[12:53:38 CEST] <RoundHash> So, that seems to have worked, but I seem to be getting quite significant artifacts now in the block colour (https://ibb.co/jrq5Oe), whereas I wasn't before
[12:54:35 CEST] <furq> that screenshot is blank, but it's probably from using 4:2:0 instead of 4:4:4
[12:54:45 CEST] <furq> you can use yuv444p but that'll make the video much less compatible
[12:55:00 CEST] <furq> a lot of devices will only play yuv420p
[12:55:43 CEST] <furq> also iirc the 16-235 thing is some legacy thing to provide a buffer between the maximum value and 255, which is used for ntsc sync
[12:56:06 CEST] <RoundHash> It is all one dark grey, but if you look carefully you can see the artifacts I'm talking about.
[12:56:30 CEST] <furq> oh right
[12:56:39 CEST] <furq> that's probably not the problem then
[12:56:50 CEST] <RoundHash> Can you see what I mean?
[12:56:55 CEST] <furq> yeah
[12:57:05 CEST] <furq> you might want to try playing it in mpv
[12:58:34 CEST] <RoundHash> I don't have that installed, but (I should have mentioned) that screenshot is from VLC, just tried it in ffplay and it's similar, but the artifacts seem less fine grained.
[13:01:40 CEST] <RoundHash> So, you said that this is an MPEG thing, squashing the values to 16-235, I'm definitely not a AV geek, but isn't MPEG different than H.264?
[13:03:16 CEST] <RoundHash> Or is it the container format that's messing with it? I has (perhaps incorrectly) assumed that H.264 would be how the video is encoded and the MPEG-4 bit was just how the file was put together and wouldn't affect the actual content of the audio/video?
[13:10:58 CEST] <furq> h264 is one of many mpeg codecs
[13:11:19 CEST] <furq> although a lot of non-mpeg codecs use limited range as well
[13:11:36 CEST] <furq> limited and full range are sometimes called mpeg and jpeg range because that's where you're most likely to find them
[13:13:50 CEST] <RoundHash> Oh, I see (should have Googled MPEG first)...
[13:16:29 CEST] <RoundHash> Seting the bitrate to 12Mbps helps, bit it's just grainy now
[13:55:28 CEST] <Zexaron> Hello
[13:56:00 CEST] <Zexaron> got a bunch of photos each month I take of infrastructure projects, tedious to resize, seems like I need some kind of a script
[13:56:38 CEST] <Zexaron> maybe ffmpeg can do it instead of going manually in photoshop, or photoshop script, shouldn be easy with batch right?
[13:56:49 CEST] <furq> yeah but don't ask me how to write it on windows
[13:57:14 CEST] <Zexaron> heh, I did a lot of linux in the past month due to huge maintenance and hardware issues
[13:57:22 CEST] <furq> in bash it'd be for f in *.jpg; do ffmpeg -i "$f" -vf scale=123:456:flags=lanczos "${f%.*}_scale.jpg"; done
[13:58:09 CEST] <Zexaron> but this is too small of a thing for me to run linux, it's not professional more like amateur enthusiast, I got a few 10-20 per week or less
[13:58:28 CEST] <furq> it shouldn't be that hard to translate that into batch
[13:58:38 CEST] <furq> but i have spent my entire life avoiding using batch and i'm not stoppingnow
[13:59:15 CEST] <furq> fwiw on windows you could use something like irfanview's batch processing
[13:59:25 CEST] <Zexaron> Honestly it's not that bad, not like it's unstable or buggy, it may just be lack of features, but I never needed (probably never figured out they exist) so I kinda have a different idea
[13:59:45 CEST] <Zexaron> I'm familiar with that, use it for DDS files, since I do gaming/moddding/dev
[14:01:25 CEST] <Zexaron> furq: Oh great, batch rename/resize/convert, quite impressive, I never knew about that thing wow, thanks
[15:42:50 CEST] <ilushka4> where can I see the log file? I'm trying to run ffplay with rtsp stream, but it retrns 400 Bad Request. Windows media player runs it though
[15:45:04 CEST] <Mavrik> ffplay -v verbose (or -v debug)
[15:45:10 CEST] <Mavrik> is your best bet
[15:45:16 CEST] <Mavrik> ffmpeg doesn't create logs
[15:54:28 CEST] <RoundHash> What does -qp do, I can't see it in the man page or on the ffmpeg x264 page, is it documented anywhere? Something to do with quality? I just set it to 0 and all my nasty artifacts have gone, but the file size is quite a bit larger
[15:54:57 CEST] <pagios> Hello, does anyone know of any cloud providers other than AWS that provides instant docker images provisioning? Like i can spawn an instance in a matter of seconds , run it for 2 or 3h and then close it, i can spawn 100 isntance docker and close after few hours and get charged accordingly. Can anyone point me to such providers?
[15:55:23 CEST] <Mavrik> RoundHash: QP is a landmine you should never use :)
[15:56:06 CEST] <Mavrik> It tweaks internal quantization parameters but it also prevents them from being adjusted to match frame complexity.
[15:56:20 CEST] <Mavrik> Essentially making sure you have some frames that will look like arse and some that will waste way too much bytes to be stored.
[15:56:23 CEST] <Mavrik> Use CRF instead.
[16:00:52 CEST] <RoundHash> Mavrik: I had tried that, but I was getting grainy video out, even with it set to 0. Just tried again though, with a different input format of the same video and it's looking better. Fingers crossed I have the right combination of options now
[16:01:18 CEST] <Mavrik> You should probably never set it to 0 either.
[16:01:23 CEST] <Mavrik> Can you tell me what are you trying to achieve?
[16:01:38 CEST] <RoundHash> Yeah, I was just going for the extreem to see if it worked.
[16:01:59 CEST] <Mavrik> 24 is the default I think
[16:02:04 CEST] <Mavrik> With ~18 being overkill for most
[16:02:05 CEST] <Mavrik> :)
[16:02:13 CEST] <furq> 23, but yeah
[16:02:14 CEST] <Mavrik> (lower = better quality at larger filesize)
[16:02:16 CEST] <RoundHash> Yeah, I had read that somewhere. I'm just trying to convert an image sequence (previously JPEG, now PNG) to a H.264 video.
[16:02:20 CEST] <furq> 18-20 are "normal" values
[16:02:39 CEST] <RoundHash> I was talking to furq earlier about it
[16:02:45 CEST] <furq> it probably looks better at qp/crf 0 because lossless is always 4:4:4
[16:03:10 CEST] <RoundHash> I switched out my input images from jpeg to png, which has helped with the colour issues too, so that's something
[16:03:27 CEST] <Mavrik> Screencaps?
[16:03:40 CEST] <RoundHash> Sure, one sec.
[16:03:56 CEST] <Mavrik> As in, you're trying to encode screen captures? :)
[16:04:59 CEST] <RoundHash> Oh, sorry.
[16:05:12 CEST] <RoundHash> No, it's a video sequence rendered from Blender
[16:05:31 CEST] <furq> it wouldn't surprise me if it was just jpeg compression artifacts that were just more obvious in the video
[16:05:58 CEST] <RoundHash> I'm using PNG now, so shouldn't be that (you'd hope :p)
[16:06:24 CEST] <RoundHash> I was half way to creating a screenshot anywa, so I continued with the before and after lol: https://ibb.co/jcajie
[16:06:42 CEST] <RoundHash> raw PNG on the left, video on the right
[16:07:30 CEST] <RoundHash> This is the command: ffmpeg -r 60 -i %05d.png -c:v libx264 -crf 15 -preset veryslow video.mp4
[16:08:05 CEST] <Mavrik> That looks as fine as it can :)
[16:08:26 CEST] <Mavrik> What's the output you get from ffmpeg when you run that?
[16:08:42 CEST] <RoundHash> Maybe I'm being too picky now lol, but if I get Blender to output "ffmpeg video", I get a much crisper output. Still uses H.264 and MP4
[16:09:01 CEST] <RoundHash> You mean text or video output?
[16:09:06 CEST] <Mavrik> text :)
[16:09:24 CEST] <RoundHash> One sec.
[16:11:09 CEST] <RoundHash> https://pastebin.com/jaVs6R8X
[16:11:19 CEST] <RoundHash> Had to re-run it, lost it in my scrollback
[16:11:25 CEST] <ilushka4> I have no idea why my rtsp stream won't work. Here is the log: https://paste.ee/p/PilXq
[16:11:31 CEST] <ilushka4> I think maybe it's something with codecs?
[16:11:59 CEST] <Mavrik> RoundHash: hmm, ...  rc=crf mbtree=1 crf=23.0 ...
[16:12:31 CEST] <Mavrik> your ffmpeg seems to pass 23 as crf to x264? :)
[16:13:23 CEST] <RoundHash> Ah, damn it, I re-ran the wrong command... or pasted the wrong output... :/ *ahem* I'll check
[16:15:55 CEST] <RoundHash> Ok, pasted the wrong output. Take 2: https://pastebin.com/kC3BrNxv
[16:24:58 CEST] <RoundHash> Mavrik: Any thoughts on things I can try to get it looking cleaner?
[16:26:48 CEST] <Mavrik> Nothing looks different from my side, so no idea what would cleaner mean.
[16:26:56 CEST] <Mavrik> Did you check if your PNG source is fine?
[16:27:22 CEST] <RoundHash> Yeah, that was the image on the left of the screenshot I posted earlier, it's as clean as a whistle
[16:28:02 CEST] <RoundHash> I'm currently resorting to trawling through the blender source code to see if I can find how they're running ffmpeg. I'd really rather not though lol
[16:40:35 CEST] <Foaly> RoundHash i think you are looking for this: https://github.com/dfelinto/blender/blob/master/source/blender/makesdna/DNA_scene_types.h#L133
[16:42:13 CEST] <RoundHash> Nice find, thanks. I've also just found a flag --debug-ffmpeg that you can run blender with to make it dump all the usual ffmpeg stuff to the terminal. Just starting to look through it now!
[16:44:47 CEST] <RoundHash> If anyone is interested, this is the output from Blender: https://pastebin.com/bbHd1khy
[16:45:17 CEST] <RoundHash> with the --debug-ffmpeg flag
[16:51:21 CEST] <RoundHash> If anyone knows what the relevant settings are in that list I'd be happy to listen ha. Currently trying to find the flags to set those options...
[16:53:39 CEST] <Foaly> ?
[16:55:18 CEST] <RoundHash> Sorry, which bit didn't make sense?
[16:58:42 CEST] <Foaly> what options do you want to set?
[17:00:45 CEST] <RoundHash> Whichever ones will stop my video looking grainy. Blender outputs the video fine (log: https://pastebin.com/bbHd1khy), so I was going to just copy the options that it set, but there are loads and they don't directly map to command line args, so I was hoping that if someone knew which ones were relevant, then they could let me know so I woulnd't have to go through the pain of finding out
[17:08:59 CEST] <RoundHash> Narrowed it down to these options at least: https://pastebin.com/Gq20ZRYL
[17:24:50 CEST] <Mavrik> none of this should make video look grainy :/
[17:27:35 CEST] <RoundHash> Maybe something on the input side that's transforming the PNG?
[17:32:41 CEST] <RoundHash> I just tried creating a preset with as many of the options Blender spat out in as I could (more than half weren't valid apparently) and not much changed sadly :(
[17:38:36 CEST] <RoundHash> Ok, so not a great idea to try, but I just ran ffmpeg with -c:v copy (no no H.264) (PNG image sequence in) and it spat out a 1GB file for about 1000 frames and it was still grainy
[17:39:18 CEST] <RoundHash> So, something to do with the mp4 container? or the way the PNGs are being handled?
[17:39:34 CEST] <RoundHash> At least I know it's not the H.264 settings now
[17:40:34 CEST] <Foaly> are the still frames in your video grainy?
[17:40:40 CEST] <RoundHash> Yeah
[17:41:25 CEST] <Foaly> idk, does ffmpeg put them losslessly in an mp4 if you feed it pngs?
[17:41:40 CEST] <Foaly> also, you could try to convert the video back to pngs, and see if they look fine
[17:41:57 CEST] <Foaly> might be something wrong with whatever you use to display the video
[17:42:11 CEST] <RoundHash> Yeah, could give that a go. I'm just using VLC
[17:43:37 CEST] <RoundHash> Just tried using avi as the container and it comes out grainy, so I guess that means it's not the codec or the container that's messing with me, must be something on the input side
[17:44:32 CEST] <Foaly> are the pngs fine?
[17:44:56 CEST] <Foaly> and are you sure it compresses lossless?
[17:46:45 CEST] <RoundHash> I'm pretty sure, yeah. Blender says "Compression: 15%", but it says lossless when you hover over, so I assume it's doing what it says it is...
[17:49:29 CEST] <Foaly> nah, i mean when you compress with ffmpeg
[17:49:36 CEST] <Foaly> pngs are always lossless
[17:50:50 CEST] <RoundHash> Oh, I'm not sure then, the command I'm using is: ffmpeg -r 60 -i %05d.png -c:v libx264 -crf 15 video.avi
[17:52:14 CEST] <Foaly> i guess that should be fine
[17:52:46 CEST] <RoundHash> This is my most recent output. Input PNG on the left, output H.264 (crf = 15) AVI on the right: https://ibb.co/gAFy9K
[17:54:31 CEST] <Foaly> probably container does not make a difference, but have you tried mkv instead?
[17:55:07 CEST] <Foaly> also, if you convert back to png with ffmpeg, does that look the same?
[17:55:33 CEST] <RoundHash> I've tried mp4 and avi, but I'll give mkv a try. I'm good to just change the file extension to change the container, though, right?
[17:55:47 CEST] <RoundHash> Haven't tried converting to and from yet, will give it a go in a sec
[17:55:51 CEST] <Foaly> i guess
[17:56:40 CEST] <RoundHash> Yeah, same grainy with the MKV too
[17:56:59 CEST] <Foaly> but i'd say that grain would qualify as dithering
[17:57:22 CEST] <Foaly> maybe that's just because of the transformation from/to RGB
[18:00:15 CEST] <RoundHash> What does that though, if it's not the codec or the container? I'll try that conversion to and from now.
[18:00:55 CEST] <kepstin> you could consider using 10bit h264, or tweaking the aq-mode setting to the mode that biases for higher quality in dark scenes
[18:01:09 CEST] <kepstin> (by default x264 lowers quality in dark stuff since it's less visible)
[18:02:11 CEST] <RoundHash> I think we've ruled out an H.264 problem, as I've tried with with "copy" and still get the same results, so thinking that it's somewhere else in the pipeline. Thanks for the suggestion though
[18:03:02 CEST] <kepstin> if you see the same thing with copy mode with the png images (and copy mode actually worked), then the original png images were the issue
[18:03:59 CEST] <kepstin> or the player, I suppose :/
[18:05:34 CEST] <kepstin> could be that it's losing gamma information, too, maybe it's reading the pngs as srgb but blender's outputting them with different gamma?
[18:05:55 CEST] <RoundHash> I have the original PNG images and they look pretty crisp (left in the screenshot I posted https://ibb.co/gAFy9K), so I don't think it's that. I'm using VLC on Linux, might be that, but I feel like is something else.
[18:05:57 CEST] <kepstin> note that blender's renderer is really tweakable, and if run with settings that don't do enough samples it tends to produce grainy results, which could be made more visible if gamma is incorrect
[18:08:04 CEST] <kepstin> your screen shot there just shows a flat black area and another flat black area for me, I can't really tell any difference unless I zoom in. The true bar in the middle make it hard to check if the levels are the same (different levels could indicate a gamma problem)
[18:08:41 CEST] <RoundHash> I'm just using the video sequence editor, not cycles, so sampling isn't it. It was screen captured footage, imported into blender, messed about with and then rendered as a PNG sequence. It could definitely be enhancing artifacts from the previous encoding though if it is loosing gamma info
[18:09:59 CEST] <RoundHash> Any idea how to go about debugging that though?
[18:10:54 CEST] <kepstin> try using ffmpeg to convert one png frame to a bmp or something and see if they look the same when opened in a color-profile-aware image editor
[18:14:07 CEST] <RoundHash> Foaly: Just tried converting to H.264 (crf 15) MP4 back to PNG and the grain is kept in the output sequence too :/
[18:14:22 CEST] <RoundHash> kepstin: Right, will give that a shot, thanks :)
[18:15:37 CEST] <kepstin> the artifacts I see in your screenshot appear to have levels of only ±1 in the luma, and looks like typical mpeg quantization noise. I wouldn't expect them to be visible unless you're on a poorly calibrated monitor :/
[18:16:19 CEST] <kepstin> note that the left side of your screenshot isn't perfectly flat, but has some scattered darker pixels throughout.
[18:16:50 CEST] <kepstin> I couldn't see them on either side until I adjusted the levels in the image to enhance the contrast.
[18:17:44 CEST] <kepstin> using -aq-mode 3 might improve it slightly when doing lossy h264 encoding.
[18:18:13 CEST] <kepstin> on an lcd screen, variance in backlight or pixel quality is likely to be more visible than these artifacts.
[18:19:01 CEST] <RoundHash> I haven't ever calibrated my monitors, so I guess that's similar to being poorly calibrated lol. Yeah, I did spot the darker pixels too. The right side is much more visible on my monitors.
[18:19:40 CEST] <RoundHash> I'm not sure how it can be a problem with H.264 if even when I'm not using it, I get the same issue
[18:20:12 CEST] <RoundHash> I did just try to do a straight PNG -> PNG conversion with ffmpeg and there was no noise there, I'll try to BMP
[18:20:48 CEST] <kepstin> alright, so it's probably being introduced by the rgb ’ yuv conversion combined with the full range to limited range conversion
[18:21:03 CEST] <kepstin> maybe some dithering is added in there
[18:21:39 CEST] <RoundHash> PNG -> BMP is fine too
[18:21:57 CEST] <kepstin> you should avoid converting between rgb and yuv wherever possible, since that is a lossy conversion. (assuming both are 8bit)
[18:22:26 CEST] <RoundHash> Alright, makes sense, so can I just preserve my RGB colour space in the video then?
[18:22:27 CEST] <kepstin> my guess is that when exporting directly from blender, it might send yuv straight to the encoder, rather than doing yuv -> rgb (png) -> yuv (in ffmpeg)
[18:22:43 CEST] <kepstin> x264 can encode rgb, but very few players can decode it.
[18:23:43 CEST] <RoundHash> Right, ok, so this sounds pretty unavoidable then if I'm going to have an RGB step in there, I need to see if I can output in YUV somehow and maybe that'll help
[18:25:12 CEST] <RoundHash> Thanks for your help with this, kepstin, really appreciate it
[18:25:28 CEST] <RoundHash> and everyone else for that matter
[18:26:32 CEST] <kepstin> RoundHash: if you can't use blender to encode directly, the second best option is probably to have blender output to a high quality or lossless yuv video format, and then you'd do your final encode based on that.
[18:28:54 CEST] <RoundHash> I would use blender to encode directly, it just has a habbit of crashing on me during the process, which is quite frustrating! Yeah, I think some formats can be appended to if it does crash half way through, so that might be an option
[18:33:20 CEST] <kepstin> yeah, mp4 is bad for that. mkv is usually readable after a crash during encoding.
[18:35:08 CEST] <RoundHash> I'll definitely give it a try. I have to go now though, but thanks for all the help again!
[18:54:01 CEST] <keglevich> ffmpeg -re -i 1.mp4 -g 50 -c:v libx264 -preset veryfast -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -ac 2 -b:a 192k -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316"
[18:54:51 CEST] <keglevich> running the command above gives somehow CBR UDP multicast stream, but it's not perfect (lots of bursts, spikes, etc.), nothing similar to those generated by hardware encoders...is there anything I can do to improve it?
[19:40:01 CEST] <Essadon> How do I combine a slideshow of GIF images with timestamps and the sound of a mp4 file?
[19:44:54 CEST] <vlt> Essadon: For the second part of your question you could just add the mp4 file to your list of inputs: `ffmpeg -i ... -i the.mp4` and then use -map.
[19:45:56 CEST] <Essadon> I have one mp4 file
[19:45:59 CEST] <Essadon> Not several
[21:20:27 CEST] <azaki> anyone know is there's a feature freeze approaching soon? it seems releases trend around april and october, so i imagine that ffmpeg 4.1 should be on the way soon?
[21:21:38 CEST] <Woodpecker> I have a question. I am downloading some music to serve as background music in an audiobook. I need the song volume to be consistent throughout, thus flattening the peaks and valleys. What do I call this process? Its not normalization, is it?
[21:23:03 CEST] <durandal_1707> background music should not be distraction
[21:23:18 CEST] <Woodpecker> yep.
[21:24:11 CEST] <durandal_1707> then just mix it with fixed low volume
[21:35:24 CEST] <BtbN> azaki, ffmpeg doesn't do feature freezes.
[21:35:42 CEST] <BtbN> A release is just cut when it's roughly time and no big issues are outstanding.
[21:39:38 CEST] <kepstin> Woodpecker: that you're talking about is normally called dynamic range compression. There's a few different ways to do it. You might consider using ffmpeg's "loudnorm" filter, which can adjust an audio track to stay within set loudness limits.
[21:41:04 CEST] <Woodpecker> kepstin: thank you so much. That sounds perfect
[21:44:04 CEST] <kepstin> Woodpecker: or depending on the audio in question, something simpler with faster attack like the compand filter might work for you.
[22:02:31 CEST] <ChocolateArmpits> Can itsoffset and loudnorm filter introduce gradual audio delay?
[22:03:07 CEST] <durandal_1707> should not
[22:03:37 CEST] <ChocolateArmpits> I'm feeling this may be a very obscure bug
[22:04:00 CEST] <durandal_1707> how to reproduce?
[22:04:33 CEST] <ChocolateArmpits> well currently I have two inputs, video is from an ip cam, audio is from a directshow device
[22:04:54 CEST] <ChocolateArmpits> I haven't toyed with conventional files for this
[22:05:48 CEST] <ChocolateArmpits> if I add loudnorm to the audio filter chain before aresample=44100:async=1 for the audio input that uses itsoffset, the audio gets gradually delayed
[22:06:02 CEST] <ChocolateArmpits> if however I specify loudnorm after aresample, then it seems to work fine
[22:06:55 CEST] <durandal_1707> probably because audio pts are not continuous
[22:07:43 CEST] <ChocolateArmpits> Additionally I specify -use_wallclock_as_timestamps for the both the audio and video inputs, so they stay synchronized
[22:17:49 CEST] <kepstin> yeah, use_wallclock_as_timestamps will introduce discontinuities into the audio timestamps
[22:18:05 CEST] <kepstin> which aresample can fix
[22:18:27 CEST] <ChocolateArmpits> kepstin, hmm I assume wallclock uses system timer?
[22:18:55 CEST] <kepstin> yeah, which might run at a different rate from the timer of the adc used to record the audio originally
[22:19:18 CEST] <kepstin> so the timestamps on the audio packets won't exactly match the sample rate that the audio is labelled with
[22:19:51 CEST] <kepstin> The aresample filter will automatically stretch/squeeze the audio to match the timestamps
[22:20:36 CEST] <ChocolateArmpits> interesting
[22:20:39 CEST] <GuiToris> hello, relaxed, ChocolateArmpits it's just a little feedback, I reencoded the original videos with level 4.1 and now it works on our TV
[22:20:47 CEST] <kepstin> (or at least it can, if you set the async= option on it)
[22:20:50 CEST] <ChocolateArmpits> GuiToris, nice
[22:21:28 CEST] <ChocolateArmpits> kepstin, yeah I'm using it
[22:22:04 CEST] <GuiToris> one of you said I'll get smaller filesize if I reduce noise. I know it's a subjective question, but is there any better denoiser than hqdn3d?
[22:22:25 CEST] <GuiToris> I found tons of denoisers
[22:22:45 CEST] <ChocolateArmpits> GuiToris, there are better ones, surely, but not a lot will work realtime or faster
[22:23:00 CEST] <kepstin> GuiToris: bm3d is a new denoise filter since the last time i looked at the filter list, it might be interesting to test.
[22:23:15 CEST] <GuiToris> I'll take a look
[22:23:45 CEST] <kepstin> (i'd expect it to be fairly slow, it appears to do motion compensated temporal denoising)
[22:24:00 CEST] <GuiToris> I went through all the denoisers that I found in the list and they were quite similar but hqdn3d
[22:24:04 CEST] <GuiToris> -I used defaults-
[22:24:51 CEST] <GuiToris> speed is not a problem, I don't have to sit here while it encodes
[22:25:34 CEST] <kepstin> tweaking the settings on a denoiser that works well is probably where you'd want to look next, if you've tried a bunch of different denoisers already
[22:25:52 CEST] <ChocolateArmpits> kepstin, is it related to this? https://github.com/HomeOfVapourSynthEvolution/VapourSynth-BM3D
[22:26:07 CEST] <ChocolateArmpits> I've used this vapoursynth filter, good results but slow as balls
[22:26:55 CEST] <kepstin> i'd expect it to probably be a port of that filter, yeah.
[22:27:24 CEST] <GuiToris> do I need to create a video just to compare different denoisers? You said it may have some motion tracking things, I guess it won't work if I only make PNG files
[22:27:52 CEST] <ChocolateArmpits> GuiToris, input shouldn't matter at all
[22:28:04 CEST] <ChocolateArmpits> of course in every comparison the source should be exactly the same
[22:28:15 CEST] <GuiToris> I meant ffmpeg -i input -vf bm3d -frames 1 output.png
[22:28:53 CEST] <GuiToris> I find it much easier to compare images than videos
[22:29:22 CEST] <ChocolateArmpits> GuiToris, if we believe the filter is a port of a vapoursynth filter, then bm3d is a spatial filter only
[22:29:40 CEST] <ChocolateArmpits> so single frame comparisons shouldn't be error prone
[22:30:07 CEST] <ChocolateArmpits> V-BM3d that's only available through vapoursynth however does both that and temporal as well
[22:30:48 CEST] <kepstin> GuiToris: for any temporal ("3d") denoising filter, you'd want to give it multiple frames
[22:31:41 CEST] <kepstin> it looks like the ffmpeg bm3d filter has the functionality of the V-BM3d vapoursynth filter, from looking at the options. not entirely clear tho.
[22:32:28 CEST] <GuiToris> so does this make more sense : ffmpeg -i input -t 3 -vf bm3d -crf 0 temp.mp4 ; ffmpeg -ss 2 -i temp.mp4 -frames 1 image.png?
[22:33:01 CEST] <kepstin> i could be wrong tho, hmm.
[22:35:01 CEST] <GuiToris> No such filter: 'bm3d'
[22:35:29 CEST] <kepstin> ah, i probably am wrong. I guess it is the spatial-only bm3d stuff, it doesn't have the extra options that v-bm3d adds
[22:35:34 CEST] <ChocolateArmpits> GuiToris, guess it's a recent filter, what's your version?
[22:35:36 CEST] <kepstin> I bet it's only in git master.
[22:35:56 CEST] <GuiToris> ffmpeg 1:4.0.2-2
[22:36:58 CEST] <GuiToris> when I went through the list I came across this error message a few times, there might be several new filters then
[22:37:56 CEST] <GuiToris> if it's not bm3d then, do you agree that hqdn3d is a good denoiser?
[22:42:49 CEST] <durandal_1707> hqdn3d is old crap
[22:43:05 CEST] <durandal_1707> nlmeans and/or bm3d
[22:44:09 CEST] <GuiToris> I don't have bm3d yet, I'll check nlmeans
[22:44:24 CEST] <durandal_1707> do not use defaults for bm3d for best results, read carefully documentation
[22:44:39 CEST] <durandal_1707> also bm3d is currently spatial only, same as nlmeans
[22:44:56 CEST] <durandal_1707> temporal version use much more memory
[22:45:39 CEST] <ChocolateArmpits> kepstin, back to that audio delay thing, would it be fair to assume that whatever ADC is there, generates more samples per time frame than needed?
[22:45:39 CEST] <GuiToris> I have nlmeans, well it's definitely not a fast filter
[22:46:01 CEST] <GuiToris> thank you for your suggestion durandal_1707
[22:46:54 CEST] <kepstin> ChocolateArmpits: any time you have to deal with different clocks, one will always run faster or slower than the other one (giving the result in this case of too many or not enough samples per frame)
[22:48:20 CEST] <ChocolateArmpits> ok thanks, this clears it up, I guess I have to be more aware of hardware behind the scenes
[22:48:23 CEST] <durandal_1707> GuiToris: check also atadenoise, it is fast and simple, only temporal denoiser
[22:48:48 CEST] <GuiToris> thanks durandal_1707 :)
[22:50:30 CEST] <kepstin> ChocolateArmpits: this is why many video players run their video frame timing off the audio clock - they send samples to the sound card, then update the video frame after the appropriate amount of audio has been played.
[22:51:30 CEST] <kepstin> (although good players like mpv have a bunch of different timing modes, especially to handle stuff like playing judder-free video on e.g. a 24000/1001hz display output)
[22:54:29 CEST] <GuiToris> out of curiosity, do you have bm3d filter?
[22:55:45 CEST] <durandal_1707> GuiToris: me? yes, i ported filter to lavfi
[22:55:59 CEST] <kepstin> I haven't rebuilt my git ffmpeg since it was added, so I don't hev it yet :)
[22:57:17 CEST] <GuiToris> I see, I should work on it
[22:57:37 CEST] <kepstin> hmm. on a side note, I was thinking of adding an option to the fps filter that would make it repeat the last input frame indefinitely, does anyone else think that would be useful?
[22:58:10 CEST] <kepstin> it's a small enough code change I guess i should just post it for review :)
[00:00:00 CEST] --- Sat Oct  6 2018