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

[burek]

[00:00:46 CEST] <furq> http://vpaste.net/ZVW3Z
[00:00:47 CEST] <petecouture> Going through them now
[00:00:48 CEST] <furq> something like that
[00:00:52 CEST] <thebombzen> furq: did you just read this? https://stackoverflow.com/questions/624857/finding-which-process-was-killed-by-linux-oom-killer
[00:01:28 CEST] <thebombzen> also check dmesg
[00:01:30 CEST] <furq> no i read a different so answer
[00:01:39 CEST] <furq> or unix.se rather since that question obviously doesn't belong on so
[00:01:47 CEST] <furq> .SE, not sweden
[00:01:59 CEST] <petecouture> Mar 26 18:09:06 3q-dfw-01 kernel: Killed process 2408 (ffmpeg) total-vm:2649992kB, anon-rss:1344196kB, file-rss:32kB, shmem-rss:0kB
[00:03:13 CEST] <furq> 1.3GB of rss
[00:03:21 CEST] <furq> i take it your server doesn't have that going spare
[00:03:31 CEST] <petecouture> It's not a big server no
[00:03:37 CEST] <petecouture> About 2 megs of memory
[00:03:40 CEST] <petecouture> gigs rather
[00:03:42 CEST] <petecouture> lol
[00:04:07 CEST] <furq> well if nothing else it's good that you stopped running it in node
[00:04:21 CEST] <petecouture> Needs to be run via node
[00:04:32 CEST] <furq> looks like you're off to the memory shop then
[00:04:35 CEST] <petecouture> mp4 to hls converter tool.
[00:05:30 CEST] <petecouture> Gotcha, thank you guys for your help. I'll make sure the system has more memory to run.
[00:05:38 CEST] <thebombzen> try recompiling ffmpeg with memory optimizations
[00:05:45 CEST] <thebombzen> afaik they exist
[00:05:48 CEST] <furq> what's the actual command you're running
[00:05:56 CEST] <furq> 1.3GB sounds really excessive for remuxing to hls
[00:06:03 CEST] <thebombzen> yes it does
[00:06:19 CEST] <alexpigment> yeah this sounds more like a memory *leak* than a memory deficit
[00:06:27 CEST] <furq> well maybe something else is going on
[00:06:32 CEST] <petecouture> It's processing 7 outputs at once
[00:06:36 CEST] <furq> oh
[00:06:38 CEST] <alexpigment> well
[00:06:41 CEST] <alexpigment> there's that... :)
[00:06:42 CEST] <petecouture> ;-)
[00:06:44 CEST] <furq> even then that sounds like a lot
[00:06:48 CEST] <furq> unless you're encoding
[00:06:56 CEST] <furq> if you're encoding variants then that's probably about right
[00:07:40 CEST] <furq> then again if you're running node you probably want at least 16GB anyway
[00:08:10 CEST] <petecouture> It's converting a mp4 file to 7 different bitrates and resolutions in HLS format. It's for a baseball company and 5K is the upper threshold so it is probably a memory cpu problem. It runs fine on my Macbookbut i have 16 gigs ram.
[00:08:56 CEST] <furq> most of that is probably just from decoding 5K
[00:09:10 CEST] <furq> with that said i don't know where you found a box with enough cpu to deal with that but only 2GB
[00:09:17 CEST] <furq> unless it's ok for this to take a week
[00:09:36 CEST] <petecouture> It's running on veryslow for max compression.
[00:09:49 CEST] <alexpigment> furq: you can get a stick of 2gb ddr4 even
[00:09:59 CEST] <alexpigment> never underestimate the computer parts industry
[00:10:16 CEST] <furq> well i assume by "server" he means in someone else's dc
[00:10:21 CEST] <llogan> an asian restaurant opened today next door. engage permasmell. time to move.
[00:10:36 CEST] <alexpigment> i know, i'm just joking about how something that *shouldn't* exist still does
[00:10:40 CEST] <furq> llogan: use the opportunity to grow some weed
[00:10:45 CEST] <alexpigment> lol
[00:11:00 CEST] <furq> you'll never make it as an entrepreneur with that attitude
[00:11:08 CEST] <petecouture> Thanks again for the help guys
[00:12:44 CEST] <llogan> furq: the problem is that a needle exchange also moved into the same building, so it may attact its clients wanting a hit.
[00:13:23 CEST] <furq> even better
[00:13:38 CEST] <furq> think of all the car stereos you could be rolling in
[00:14:09 CEST] <llogan> the percentage of skinny white guys with neck tats has increased exponentially
[00:14:55 CEST] <furq> living in a big city sounds pretty cool
[00:15:07 CEST] <llogan> it's not big. just shitty.
[00:17:35 CEST] <celyr> Hi
[00:17:45 CEST] <celyr> I want to cut a video, but I need two cuts
[00:17:58 CEST] <celyr> is it possibile without making 2 separate video and 1 merge then ?
[00:20:04 CEST] <Kadigan> Hey. How can I tell ffmpeg to output to /dev/null... on Windows? I don't recall what the abstract equivalent is.
[00:20:10 CEST] <furq> -f null -
[00:20:46 CEST] <Kadigan> Thanks, that worked.
[00:21:03 CEST] <Kadigan> Say, can you try answering a question that is video-related but not ffmpeg-related?
[00:21:21 CEST] <furq> sure
[00:21:58 CEST] <Kadigan> I have a video file that for some reason doesn't play well with "ffmpeg video decoder raw" -- it flashes red-tinted and green-tinted frames quite often.
[00:22:17 CEST] <Kadigan> I assume it's broken or otherwise out of spec,
[00:22:27 CEST] <Kadigan> but I'm not sure what to do about it...
[00:22:53 CEST] <Kadigan> (I use mpc-hc for playback, but in conjunction with SVP and madVR; when I use a second mpc-hc copy it plays back just fine w/o this issue)
[00:23:07 CEST] <Tatsh> i have a weird DVD and its VOBs have streams in different positions
[00:23:12 CEST] <Kadigan> ah
[00:23:17 CEST] <Kadigan> ffmpeg = ffdshow
[00:23:20 CEST] <Kadigan> I apologize
[00:23:27 CEST] <Kadigan> (the second copy doesn't use madVR/SVP/ffdshowvdr)
[00:23:29 CEST] <Tatsh> is this typical?
[00:23:40 CEST] <llogan> celyr: sure, if you use the concat filter
[00:23:42 CEST] <Tatsh> i'm using -filter_complex with the concat filter to encode to a single file, picking each stream
[00:24:07 CEST] <furq> Tatsh: if you mean multiple titles/PGCs then use tccat
[00:24:17 CEST] <celyr> llogan, but I guess I will have first to cat the original video two times with -ss and -t and then to merge them with concat ?
[00:24:24 CEST] <Tatsh> where can i get tccat?
[00:24:34 CEST] <furq> are you *nix or windows
[00:24:42 CEST] <furq> +on
[00:24:47 CEST] <Tatsh> found it
[00:24:49 CEST] <Tatsh> i'm on gentoo
[00:24:54 CEST] <Tatsh> it's the transcode package
[00:24:56 CEST] <furq> yeah
[00:25:47 CEST] <furq> that'll demux a single title/chapter/angle and output it on stdout, so you can pipe it into ffmpeg
[00:25:58 CEST] <furq> ffmpeg's handling of anything but the simplest dvds is basically worthless
[00:26:11 CEST] <Tatsh> ok
[00:26:25 CEST] <Tatsh> yea when i merged the vobs even after figuring out how to pick the channels i got a strange result
[00:26:33 CEST] <Tatsh> the audio of course was off sync in the second half
[00:27:07 CEST] <llogan> celyr: you can use (a)trim and (a)setpts filters then concat filter. but note this will re-encode everything. or use the inpoint/outpoint options for the concat demuxer if you want to try to avoid re-encoding, but you'll need to cut on a keyframe for it to work properly.
[00:27:33 CEST] <celyr> ok arab incoming lol
[00:27:47 CEST] <celyr> sorry I'm really ignorant in maens of video encoding
[00:28:40 CEST] <furq> celyr: if you're reencoding then it's something like this
[00:28:49 CEST] <furq> -filter_complex "[0:v]trim=3:7,setpts=PTS-STARTPTS[v1]; [0:v]trim=22:25,setpts=PTS-STARTPTS[v2]; [0:a]atrim=3:7,asetpts=PTS-STARTPTS[a1]; [0:a]atrim=22:25,asetpts=PTS-STARTPTS[a2]; [v1][a1][v2][a2]concat=a=1"
[00:28:59 CEST] <furq> replace 3:7 and 22:25 with your actual cut points
[00:29:13 CEST] <llogan> concat=n=2:v=1:a=1
[00:29:20 CEST] <furq> i say "iirc" because that's the last entry in my command history for "setpts" so i assume that's the one which worked
[00:29:28 CEST] <celyr> furq, No I don't want to loose quality
[00:29:45 CEST] <furq> it's a good job i didn't type all that out by hand then
[00:30:01 CEST] <celyr> furq, but I've made it easier, I made output1.mp4 and output2.mp4
[00:30:22 CEST] <llogan> furq: lucky. i can't type with my buttocks
[00:30:58 CEST] <llogan> very well at least
[00:33:45 CEST] <celyr>  ffmpeg -i "concat:output1.mp4|output2.mp4" -c copy output.mp4
[00:34:00 CEST] <celyr> this is not working, it does not concat :/
[00:34:06 CEST] <celyr> just output1.mp4 is put in output.mp4
[00:34:33 CEST] <celyr> and no error is returned too
[00:34:41 CEST] <Kadigan> Fun fact: transcoding the video w/ ffmpeg fixes it. Like I said, it's probably a badly encoded file, and ffdshow video decoder raw is probably less tolerant of such shenanigans.
[00:38:14 CEST] Action: celyr hammer his head on the wall
[00:39:52 CEST] <Tatsh> actually furq all i needed to do was use vobcopy -l
[00:40:23 CEST] <Tatsh> vobcopy assumes you're on a bad file system that does not support > 2 GiB
[00:40:26 CEST] <celyr> ok I did it I had first to transcode it
[00:42:52 CEST] <celyr> llogan, now I see what you meant by concatenating this way it creates a long still frame
[00:42:57 CEST] <celyr> long maybe .5 sec
[00:43:23 CEST] <llogan> concat protocol doesn't work with MP4
[00:43:31 CEST] <llogan> use concat filter or concat demuxer
[00:43:36 CEST] <celyr> llogan, I transcoded it to mpeg
[00:44:08 CEST] <celyr> like this ffmpeg -i file.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts  output1
[00:44:51 CEST] <llogan> why would you do that. you're encoding but you told furq you want to avoid that.
[00:45:19 CEST] <celyr> because on tha manual i read that this is lossless
[00:45:26 CEST] <furq> it is
[00:45:39 CEST] <furq> but that's remuxing to mpegts, not transcoding to mpeg
[00:45:55 CEST] <celyr> so this is ok to me
[00:46:04 CEST] <celyr> the only problem is the still frame
[00:46:16 CEST] <furq> use the concat demuxer
[00:46:27 CEST] <furq> https://trac.ffmpeg.org/wiki/Concatenate#demuxer
[00:47:03 CEST] <celyr> furq, does it work direcly with mp4 ?
[00:47:09 CEST] <furq> it should do
[00:47:14 CEST] <furq> but mpegts is generally better for that anyway
[00:47:30 CEST] <celyr> furq, but it creates that frame
[00:51:01 CEST] <celyr> now the still frame is not the first of the second video is the last of the first video
[00:51:02 CEST] <celyr> lol XD
[00:52:21 CEST] <celyr> the result is much better tho so I think I'll stick with it
[01:04:46 CEST] <flyBoi> If you could have a cloud server instance with either 1) a ton of memory or 2) an insanely fast CPU (but not both), which would be better for ffmpeg speed-wise?
[01:06:02 CEST] <llogan> flyBoi: CPU
[01:07:34 CEST] <flyBoi> llogan: should have specified: for trimming very large video files
[01:08:06 CEST] <furq> do you mean large in duration or in resolution
[01:08:18 CEST] <furq> the former usually makes no difference
[01:08:45 CEST] <furq> ofc if you're trimming without reencoding then the cpu makes no difference either. only the disk speed matters then
[01:11:30 CEST] <flyBoi> both duration and resolution. Typically 45minute videos, near ProRes quality
[01:12:26 CEST] <flyBoi> it's been a while since I've used ffmpeg- why wouldn't you reencode?
[01:12:35 CEST] <chatter29> hey guys
[01:12:50 CEST] <flyBoi> changing the file type?
[01:13:11 CEST] <chatter29> allah is doing
[01:13:16 CEST] <chatter29> sun is not doing allah is doing
[01:13:18 CEST] <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
[01:18:09 CEST] <Tauromancer> doing what? lol
[01:21:56 CEST] <llogan> Tauromancer: what the sun is not doing.
[01:23:58 CEST] <llogan> flyBoi: stream copy http://ffmpeg.org/ffmpeg.html#Stream-copy
[01:31:55 CEST] <flyBoi> llogan: Thanks! Turns out we will be reencoding, so I guess stream copy won't work
[01:33:43 CEST] <llogan> then go for the CPU option
[03:17:35 CEST] <Fenrirthviti> What exactly the swscaler message "warning: Warning: data is not aligned! This can lead to a speedloss" actually mean?
[03:18:24 CEST] <thebombzen> I think it means that certain CPUs work better if the data is aligned to certain bytes
[03:19:01 CEST] <thebombzen> i.e. a 32-bit integer starting at a pointer that's amultiple of 4 will work better with cpu artihmetic than a 32-bit integer shifted by one byte
[03:42:36 CEST] <Fenrirthviti> Gotcha.
[03:52:40 CEST] <kepstin> that message is mostly intended at developers using the library, to make sure they align their frames, but you can get it sometimes on the command line if you crop or scale to unusual offsets. nothing to do about it, it'll just be a bit slower :/
[03:53:16 CEST] <unomystEz> I have an mp3 file that is around 5 mins and I want to create an mp4 video that just shows a static image the whole duration except for time 00:00:10-00:00:30 I want to show a different image
[03:53:34 CEST] <unomystEz> is it possible without having to generate 5 mins worth of individual images (one for each frame?)
[04:02:58 CEST] <furq> unomystEz: -loop 1 -i foo.png -i bar.mp3 -shortest out.mp4
[04:03:26 CEST] <furq> oh nvm i didn't read all of that
[04:04:47 CEST] <furq> -loop 1 -i foo.png -loop 1 -i bar.png -i baz.mp3 -shortest -filter_complex "[0:v][1:v]overlay=enable=between(10\,30)[out]" -map "[out]" -map 2 out.mp4
[04:04:54 CEST] <furq> something like that
[04:05:06 CEST] <unomystEz> holy moly
[04:05:21 CEST] <furq> er
[04:05:26 CEST] <furq> -loop 1 -i foo.png -loop 1 -i bar.png -i baz.mp3 -shortest -filter_complex "[0:v][1:v]overlay=enable=between(t\,10\,30)[out]" -map "[out]" -map 2 out.mp4
[04:08:38 CEST] <unomystEz> Stream specifier ':v' in filtergraph description [0:v][1:v]overlay=enable=between(t\,10\,30)[out] matches no streams
[04:09:12 CEST] <furq> are the inputs in the right order
[04:09:15 CEST] <unomystEz> https://pastebin.com/hag1tsXh
[04:09:20 CEST] <unomystEz> I pasted the command
[04:10:18 CEST] <furq> er
[04:11:38 CEST] <furq> not sure if this is the problem but you don't actually need -loop 1 on the second input image
[04:12:52 CEST] <unomystEz> err
[04:12:57 CEST] <unomystEz> my bad, I think I was missing a -i
[04:13:04 CEST] <furq> oh
[04:13:05 CEST] <furq> yeah you were
[04:13:27 CEST] <furq> 1 sure does look like i
[04:13:50 CEST] <unomystEz> working
[04:14:23 CEST] <unomystEz> hmm, mp3 file is 7 hours long, speedup is only 3x
[04:14:25 CEST] <unomystEz> =(
[04:24:46 CEST] <furq> you probably also want -c:a copy
[04:24:54 CEST] <furq> otherwise it'll transcode the audio to aac
[04:25:06 CEST] <JoAnywhere> hi there.  Does anyone here have any experience getting ffmpeg working with a Raspberry PI?  specifically, recording audio from a USB mic (well, a USB webcam with a built in mic)
[04:25:17 CEST] <unomystEz> furq: yup I added that and it seemed to help a bit
[04:25:30 CEST] <unomystEz> furq: btw, the video looks great
[04:25:39 CEST] <unomystEz> furq: although, any idea how to make this even faster?
[04:25:41 CEST] <furq> add -tune stillimage as well
[04:25:58 CEST] <furq> and you can probably reduce the framerate
[04:26:16 CEST] <furq> add -framerate x before the first -i
[04:26:27 CEST] <unomystEz> this is for youtube, should I specify things like -v:c libx264 and -r 24?
[04:26:34 CEST] <furq> if it's going to youtube then -framerate 6
[04:26:42 CEST] <unomystEz> oh
[04:26:56 CEST] <furq> that should speed it up a lot
[04:30:03 CEST] <unomystEz> cool, it's at 5.3x now
[04:32:27 CEST] <unomystEz> thanks for your help!
[04:40:57 CEST] <JoAnywhere> OK... So I'm going to back the bus up, and compile ffmpeg for my PI (again) using this guide.. https://trac.ffmpeg.org/wiki/CompilationGuide/RaspberryPi.  I have to say, it is REALLY un-noob friendly
[04:43:48 CEST] <JoAnywhere> can anyone help me out at all?
[04:44:47 CEST] <furq> what distro are you running on your actual computer
[04:46:35 CEST] <JoAnywhere> furq, on the PI?  Latest Raspbian
[04:46:41 CEST] <furq> not on the pi
[04:46:43 CEST] <JoAnywhere> I'm just reinstalling from noobs as we speak
[04:46:45 CEST] <JoAnywhere> windows 10
[04:46:48 CEST] <furq> oh
[04:46:48 CEST] <JoAnywhere> on my PC
[04:47:08 CEST] <furq> none of that page is useful to you then
[04:47:09 CEST] <JoAnywhere> why?  I can compile it directly on the PI, so why does my PC come into play? (sorry if I am being dense)
[04:47:17 CEST] <furq> that's for cross-compiling from another (faster) computer
[04:48:04 CEST] <JoAnywhere> can I just start at the 'Compiling additional libraries needed for FFmpeg' section?
[04:48:33 CEST] <furq> if you're building on a pi then it's literally just ./configure; make; make install
[04:48:54 CEST] <furq> depending on what dependencies you care about having
[04:49:04 CEST] <JoAnywhere> I think I need the alsa library
[04:49:26 CEST] <JoAnywhere> as everytime I've built it and use -f alsa, it fails on me; saying alsa is an unknown input format
[04:49:36 CEST] <furq> install libasound2-dev
[04:49:51 CEST] <JoAnywhere> but I see this guide specifically compiles the alsa library
[04:49:58 CEST] <JoAnywhere> install with apt-get?
[04:50:01 CEST] <furq> yeah
[04:50:13 CEST] <furq> also you probably want to build ffmpeg with --enable-mmal --enable-omx-rpi so you can use the onboard hardware decoder/encoder
[04:50:45 CEST] <furq> alsa will be automatically enabled as long as you have libasound2-dev installed
[04:51:25 CEST] <JoAnywhere> so do I install that with apt-get install libasound2-dev?
[04:51:29 CEST] <furq> yes
[04:51:44 CEST] <thebombzen> I'm getting video artifacts when I try to decode a 10bit hevc video with hevc_cuvid, but not with software dec or vdpau
[04:51:47 CEST] <JoAnywhere> OK.  Once noobs has finished, I'll start being my own noob LOL and have another try
[04:51:49 CEST] <thebombzen> is that just a bug in cuvid?
[04:52:17 CEST] <JoAnywhere> do I need to go through the steps detailed around additional libraries?
[04:52:20 CEST] <furq> no
[04:52:28 CEST] <thebombzen> I can reproduce with ffplay -codec:v hevc_cuvid and also in mpv, with mpv --hwdec=cuda
[04:52:35 CEST] <JoAnywhere> was that no to me, or no to thebombzen?? :)
[04:52:36 CEST] <furq> you only need to build external libs yourself if the ones provided by your distro are old or not present
[04:52:51 CEST] <JoAnywhere> OK.  I'll have (about my 5th) try
[04:53:02 CEST] <furq> or if you're cross-compiling and your host distro doesn't have multiarch
[04:54:18 CEST] <JoAnywhere> OK.  I'll let you know how I get on
[04:54:50 CEST] <JoAnywhere> thanks for the help.  file system still extracting, so I'm a ways from trying this
[04:54:55 CEST] <furq> http://vpaste.net/uKlbc
[04:54:58 CEST] <furq> that should be all you need
[04:55:35 CEST] <JoAnywhere> but after grabbing libasound2-dev?
[04:55:43 CEST] <furq> line 1
[04:56:18 CEST] <furq> also that should be "make -j4" or else it'll be even slower
[04:56:21 CEST] <JoAnywhere> true dat LOL.. looks like it has been commented out
[04:56:26 CEST] <furq> # is a root shell
[04:56:31 CEST] <furq> i.e. sudo
[04:56:36 CEST] <JoAnywhere> so a sudo -i first?
[04:56:46 CEST] <JoAnywhere> or just a sudo for that one command?
[04:56:54 CEST] <furq> just for the ones marked with #
[04:57:15 CEST] <JoAnywhere> r'ok shaggy :)
[04:57:51 CEST] <JoAnywhere> and yep - will definately use make -j4.  Sends my PI3 into a state of thermal freak out.. but only for a while LOL
[04:58:38 CEST] <furq> you might want to do this on /tmp so it's not hitting the sd card
[04:59:07 CEST] <JoAnywhere> OK. normally I'd do it in usr/src or something?
[04:59:22 CEST] <furq> normally you'd do it in ~
[05:00:41 CEST] <JoAnywhere> lol.. every guide says something different
[05:00:46 CEST] <JoAnywhere> does /tmp do it all in RAM?
[05:00:58 CEST] <furq>  /tmp is normally mounted as a tmpfs, which is in ram
[05:01:09 CEST] <furq> you can check with `mount`
[05:01:36 CEST] <furq> although if an rpi-specific distro isn't doing that by default then you should probably throw it in the bin
[05:02:37 CEST] <JoAnywhere> haha
[05:03:03 CEST] <JoAnywhere> but the make install will end up putting it all back onto SD card?
[05:03:10 CEST] <furq> yeah
[05:03:18 CEST] <furq> that's what --prefix is for
[05:04:13 CEST] <JoAnywhere> gotcha (mostly LOL)
[05:05:26 CEST] <furq> and yeah most of the guides for this sort of thing are either written by idiots, outdated, or they just assume the worst possible set of circumstances
[05:06:14 CEST] <furq> that giant wiki page about cross compiling becomes about seven commands when i cross compile, because my host distro isn't awful
[05:08:40 CEST] <JoAnywhere> sorry, wasn't ignoring you.. just was busy doing critical setup on pi (localisation, networking, and changing pi user password)
[05:13:19 CEST] <JoAnywhere> @furq... am starting in on it now.... wish me luck :)
[05:15:51 CEST] <JoAnywhere> woot... and there is my CPU @ 100%.....
[05:34:27 CEST] <JoAnywhere> dum de dooh... still building LOL
[05:48:17 CEST] <JoAnywhere> hey furq..... YAY.  Now I don't get the alsa error
[05:48:38 CEST] <JoAnywhere> still can't record anything
[05:48:45 CEST] <JoAnywhere> coz of a different error.. LOL
[05:53:58 CEST] <JoAnywhere> furq... you still around mate?
[05:55:46 CEST] <JoAnywhere> anyone out there who can help a noob?
[05:55:48 CEST] <furq> hi
[05:56:01 CEST] <JoAnywhere> hey.... so, your guide worked... that was crazy easy
[05:56:05 CEST] <JoAnywhere> so, next problem
[05:56:23 CEST] <JoAnywhere> I go arecord -l
[05:56:27 CEST] <JoAnywhere> and get the following output
[05:56:41 CEST] <JoAnywhere> **** List of CAPTURE Hardware Devices **** card 1: VX5000 [Microsoft LifeCam VX-5000], device 0: USB Audio [USB Audio]   Subdevices: 1/1   Subdevice #0: subdevice #0
[05:57:45 CEST] <JoAnywhere> so my understanding is that this (given it is card 1, subdevice 0) this command should record audio for 5 seconds to out.wav
[05:57:59 CEST] <JoAnywhere> $ ffmpeg -f alsa -i hw:1,1 -t 5 out.wav
[05:58:04 CEST] <JoAnywhere> however, I'm getting an error
[05:58:21 CEST] <JoAnywhere> [alsa @ 0x33a7230] cannot open audio device hw:1,1 (No such file or directory) hw:1,1: Input/output error
[05:58:24 CEST] <JoAnywhere> any thoughts?
[05:58:38 CEST] <JoAnywhere> sorry.. that was hw:1,0 - not 1,1
[05:58:50 CEST] <JoAnywhere> and the error was
[05:58:58 CEST] <JoAnywhere> [alsa @ 0x3211230] cannot set channel count to 2 (Invalid argument) hw:1,0: Input/output error
[05:59:09 CEST] <JoAnywhere> thoughts?
[06:00:15 CEST] <furq> set -channels 1 before -i
[06:00:23 CEST] <JoAnywhere> hey... adding in -ac 1 seems to have fixed it..
[06:00:36 CEST] <furq> they're probably mapped to the same thing
[06:00:45 CEST] <JoAnywhere> what are mapped to the same thing?
[06:00:49 CEST] <furq> -ac and -channels
[06:01:32 CEST] <JoAnywhere> -ac = audio channels according to the man page
[06:02:09 CEST] <furq> -f alsa has its own set of options
[06:02:21 CEST] <furq> !indev alsa
[06:02:21 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-devices.html#alsa
[06:02:49 CEST] <furq> but sometimes global options like -ac will be mapped to the same thing as a private option
[06:05:14 CEST] <JoAnywhere> gotcha
[06:11:07 CEST] <JoAnywhere> furq... you are a FURQing legend !!!!
[06:11:33 CEST] <JoAnywhere> now, to get it to record video at the same time (pretty straightforward) and trigger with motion (also I think fairly straight forward)
[06:17:00 CEST] <Tatsh> hi all; i have the original interlaced source for this frame: https://i.imgtc.com/Xw6D2Wj.jpg
[06:17:17 CEST] <Tatsh> this is what it looks like after yadif is used; is there any way to not have those blocky lines?
[06:17:32 CEST] <Tatsh> any sort of filters i can try for this specific problem
[06:21:14 CEST] <furq> Tatsh: you can maybe try nnedi, but it's really slow in ffmpeg
[06:21:28 CEST] <furq> vapoursynth and qtgmc might be more useful
[06:22:08 CEST] <furq> qtgmc has some really nice stuff for repairing bad deinterlacing artifacts
[06:22:31 CEST] <Tatsh> ok
[06:22:37 CEST] <furq> you could also try yadif mode 1 if that's not what you used
[06:22:45 CEST] <furq> !filter yadif
[06:22:45 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#yadif-1
[06:22:45 CEST] <Tatsh> i only specified 'yadif'
[06:22:49 CEST] <furq> -vf yadif=1
[06:23:04 CEST] <Tatsh> one question i had also was if yadif should be applied before or after crop, etc? or does this not matter?
[06:23:10 CEST] <Tatsh> in the -vf argument
[06:23:25 CEST] <furq> it should ideally be before crop or anything else that changes the frame dimensions
[06:23:30 CEST] <Tatsh> okay
[06:23:32 CEST] <furq> generally it should be first
[06:23:38 CEST] <Tatsh> so yadif=1, or qtgmc
[06:23:43 CEST] <Tatsh> i'll try yadif=1 now
[06:23:46 CEST] <furq> yeah
[06:24:00 CEST] <furq> qtgmc is a pain to set up properly, and ffmpeg nnedi is incredibly slow
[06:24:18 CEST] <furq> like <5 fps at 480p slow
[06:26:49 CEST] <Tatsh> is qtgmc a really recent thing?
[06:26:52 CEST] <furq> you might also want to try changing the parity option to yadif
[06:27:03 CEST] <furq> although it'd probably look a lot worse than that if the field order was wrong
[06:27:04 CEST] <Tatsh> when i run idet on this video, i get mostly bottom
[06:27:14 CEST] <Tatsh> and yadif by default is top
[06:27:24 CEST] <furq> by default it's "auto" but idk what heuristic it uses
[06:27:26 CEST] <Tatsh> i tried to use parity=bff and it didn't seem to change anything
[06:27:31 CEST] <furq> fair enough
[06:27:55 CEST] <furq> i doubt it's that anyway
[06:28:17 CEST] <furq> qtgmc isn't part of ffmpeg if that was unclear
[06:28:34 CEST] <furq> it's an avisynth/vapoursynth filter that uses nnedi and some other trick stuff
[06:28:44 CEST] <JoAnywhere> hey furq, not sure if you saw my comments before - you got my shit working.. you're a legend!!!
[06:29:01 CEST] <furq> i sure am
[06:29:09 CEST] <JoAnywhere> and modest with it TROLOLOL
[06:29:36 CEST] <JoAnywhere> now, if I can just motion to trigger nicely, and fire up ffmpeg in the on_start_event section, I'll be sorted LOL
[06:30:22 CEST] <Tatsh> furq, is the normal process then to use vapoursynth and then encode that video?
[06:30:44 CEST] <furq> you filter with vapoursynth and pipe it into ffmpeg for encoding
[06:31:16 CEST] <furq> http://avisynth.nl/index.php/QTGMC
[06:32:11 CEST] <Tatsh> if this works i'll be impressed
[06:32:25 CEST] <furq> https://github.com/HomeOfVapourSynthEvolution/havsfunc
[06:32:30 CEST] <furq> the vapoursynth version is there
[06:32:46 CEST] <furq> there's a bunch of C libraries you need as well although i forget which ones off the top of my head
[06:33:08 CEST] <Tatsh> yea i already built it
[06:33:12 CEST] <furq> oh neat
[06:33:30 CEST] <furq> vapoursynth editor is useful as well fwiw
[06:44:12 CEST] <JoAnywhere> furq, I'm out of here mate.. thanks again for the help.  If I've got more grief with ffmpeg, I know where to come looking :()
[06:51:26 CEST] <Ferman> Hi everyone, has anyone tried to use ffmpeg to mosaic rtmp streams?
[07:01:27 CEST] <Tatsh> uh wow furq
[07:01:39 CEST] <Tatsh> i got it working but that was a lot of stuff to compile and install to a random prefix
[07:01:58 CEST] <Tatsh> i'm glad i use gentoo and make ebuilds or i wouldn't have gotten very far
[07:02:22 CEST] <furq> i think some distros have it all prepackaged now
[07:02:24 CEST] <furq> not mine though ;_;
[07:03:48 CEST] <Tatsh> when you use qtgmc you get double the framerate
[07:03:53 CEST] <Tatsh> 60000/1001
[07:04:05 CEST] <furq> you can set FPSDivisor=2 if you don't want that
[07:04:10 CEST] <furq> i normally do want that though
[07:04:23 CEST] <Tatsh> then on ffmpeg can you kill half the frames out?
[07:04:37 CEST] <Tatsh> or am i not seeing this correctly for what it does
[07:04:47 CEST] <furq> you can do one or the other
[07:05:25 CEST] <furq> http://avisynth.nl/index.php/QTGMC#Shutter_Speed_Motion_Blur_.2F_Frame_Rate
[07:05:35 CEST] <Tatsh> the quality is incredible
[07:05:47 CEST] <Tatsh> but on my machine i'm only getting like 1.76x compared to 6x before
[07:05:56 CEST] <furq> yeah it's still very slow compared to yadif
[07:06:01 CEST] <furq> yadif is designed for realtime playback
[07:06:23 CEST] <furq> there are presets you can use to speed it up if it's too slow
[07:06:33 CEST] <furq> it's also much faster than ffmpeg nnedi
[07:07:44 CEST] <Tatsh> i have nnedi for trying out later
[07:07:49 CEST] <Tatsh> but that was quite a trip of finding all the deps
[07:07:58 CEST] <furq> it's not really worth trying nnedi if you have qtgmc set up
[07:08:07 CEST] <furq> ffmpeg's nnedi is single-threaded
[07:08:37 CEST] <furq> vapoursynth is multithreaded and qtgmc does some other nice stuff on top of nnedi
[07:08:45 CEST] <furq> at least that's what the wiki says. i couldn't tell you what any of that is
[07:08:47 CEST] <Tatsh> thanks for the tip furq
[07:08:49 CEST] <Tatsh> this is amazing
[07:08:59 CEST] <furq> yeah i always use that for dvds
[07:09:28 CEST] <furq> yadif is fine for clean sources but it struggles with a lot of sd stuff
[07:09:57 CEST] <JoAnywhere> !leave
[07:10:55 CEST] <Tatsh> this is my setup for VHS capture https://i.imgtc.com/EXXJBzg.jpg
[07:11:12 CEST] <Tatsh> it goes into a happauge ImpactVCB-e PCIe card which has no comb filter, nor am i sure i would want one
[08:19:57 CEST] <mavi> I'm making a generic encode profile for live action upload, and i'm setting up filters as well. I'm curious does a interlacer like yadif, hurt if ran through a video that isn't interlaced? is there an option to detect if a video is interlaced and run a deinterlacer if it is?
[08:27:20 CEST] <c_14> yadif=deint=1 will only deinterlace frames that are marked as interlaced
[08:28:52 CEST] <c_14> and you can use the idet filter in front of it to try and detect interlaced frames
[09:01:59 CEST] <mavi> Would using something like this, -vf  yadif=0:-1:0 only deinterlace if the content is interlaced, or will it auto attempt to deinterlace progressive content as well?
[09:02:30 CEST] <mavi> ah just saw that, good to know.
[09:04:51 CEST] <mavi> c_14 dunno if you have experience with denoisers, but is using a ultralight setting on a denoise filter like hqdn3d=1.5:1.5:6:6 more effective than using something like nr=300 on x264?
[09:05:34 CEST] <mavi> Also are the mosquitonr filters and similiar ones any good for bitrate starved videos to remedy their artifacts, or is that just a matter of being bit rate starved?
[09:07:07 CEST] <furq> do you mean low-bitrate source or output
[09:08:34 CEST] <mavi> output
[09:08:38 CEST] <mavi> the source is decent
[09:08:42 CEST] <furq> i don't think that'll do anything then
[09:09:11 CEST] <mavi> What if the input is blocky? Due to being a webrip from a fairly old source.
[09:09:29 CEST] <furq> obviously if you have ringing in the source then it'll help
[09:09:42 CEST] <furq> but if this is some generic pipeline then i wouldn't unconditionally use it
[09:10:10 CEST] <mavi> got it. Yea it's fairly generic. It's for 720p and 480p live action videos.
[09:10:17 CEST] <mavi> all ripped from youtube.
[09:11:03 CEST] <furq> i'd probably just stick with denoising
[09:11:48 CEST] <mavi> ah I see, any specific filter recomendations for denoising? I don't mind it taking longer to encode, attempting the highest quality within a low bitrate.
[09:12:09 CEST] <furq> hqdn3d or nlmeans are probably the best ones in ffmpeg
[09:12:11 CEST] <furq> although i've not tried them all
[09:12:33 CEST] <mavi> i've tried those on handbrake a few times, I've read in the past that hqdn3d isn't as good as nlmeans
[09:12:43 CEST] <mavi> but that it's faster.
[09:12:53 CEST] <mavi> does it matter at ultralight generic settings?
[09:12:55 CEST] <furq> you can be quite aggressive with denoising without it affecting output quality too badly
[09:13:09 CEST] <furq> obviously you'll lose fine detail, but that's probably desirable at low bitrate
[09:13:34 CEST] <furq> youtube denoises the hell out of everything and it looks pretty good
[09:13:56 CEST] <robswain[m]> i'm trying to encode a set of dash representations into one mpd using ffmpeg
[09:14:33 CEST] <robswain[m]> it seems like i can transcode one representation like this: ffmpeg -y -i orb.mov -c:v libx264 -preset veryslow -x264opts keyint=126:min-keyint=126:no-scenecut -b:v 8000k -maxrate 8000k -vf scale=-1:1440 -f dash -init_seg_name init-$RepresentationID$.mp4 -media_seg_name test-$RepresentationID$-$Number$.mp4 orb-8000.mpd
[09:14:36 CEST] <robswain[m]> for example
[09:14:43 CEST] <mavi> I'm curious what other prefilters youtube uses, probably a bunch of algorithms that detect the best filters to use
[09:14:46 CEST] <furq> mavi: there's not really any right or wrong answer, it depends on what your source is and what you want from the output
[09:14:56 CEST] <robswain[m]> but how do i encode multiple representations into one mpd?
[09:15:01 CEST] <furq> run some test clips and see how they look
[09:15:10 CEST] <mavi> Currently doing so :) Thanks
[09:15:24 CEST] <furq> if there was a right answer then ffmpeg wouldn't have 12 different denoisers
[09:15:26 CEST] <furq> or however many it is now
[09:15:32 CEST] <mavi> yea for sure.
[09:18:18 CEST] <DemoniacMilk> morning!
[09:18:24 CEST] <mavi> Lol I'm on here hoping , there are some magic unicorn filters that magically makes my encodes look like amazing as lower freqencies.
[09:18:49 CEST] <mavi> after some early tests nl means looks better for my sources
[09:19:34 CEST] <furq> it's a shame ffmpeg doesn't have opencl nlmeans
[09:19:37 CEST] <mavi> Combining it with a low -nr from x264 -250 or so seems to yield decent results
[09:19:41 CEST] <furq> vapoursynth has that and it's pretty fast
[09:20:01 CEST] <mavi> there's no hardware accel on it?
[09:20:06 CEST] <mavi> That explains why it's so slow.
[09:20:10 CEST] <furq> not on that filter
[09:20:15 CEST] <furq> a couple of them can use opencl now
[09:20:22 CEST] <furq> none of the denoisers though
[09:21:11 CEST] <furq> i'm not sure -nr is really worth using if you're using a separate denoiser
[09:21:11 CEST] <mavi> wasn't nlmeans just added to ffmpeg like 6-8 months ago?
[09:21:17 CEST] <furq> probably
[09:21:27 CEST] <mavi> think it kills too much detail?
[09:21:38 CEST] <furq> shrug
[09:21:45 CEST] <furq> it just seems weird to run a good denoiser and then a worse one
[09:21:56 CEST] <furq> you're already taking the cpu hit from the good one, you might as well just turn that up
[09:22:39 CEST] <mavi> i have more testing to do, makes sense.
[09:22:41 CEST] <DemoniacMilk> is it intended/expected behaviour that setting --cross-prefix without setting --cc does not configure correctly? (uses gcc instead of cross compiler, then complains about a non-supported architecture)
[09:22:48 CEST] <mavi> probably just seeing placebo differences.
[09:22:51 CEST] <furq> DemoniacMilk: that works for me
[09:23:07 CEST] <furq> pastebin the full configure command
[09:23:07 CEST] <mavi> slightly smaller file size
[09:24:24 CEST] <DemoniacMilk> https://pastebin.com/yAkiTtua
[09:24:50 CEST] <furq> you're missing some hyphens there
[09:25:04 CEST] <DemoniacMilk> ` these?
[09:25:07 CEST] <furq> -
[09:25:34 CEST] <DemoniacMilk> oh that was because i copied it from word (for documentation)
[09:25:41 CEST] <DemoniacMilk> and it replaced -- with some weird -
[09:25:54 CEST] <furq> nice
[09:25:59 CEST] <furq> http://vpaste.net/DJ8yC
[09:26:03 CEST] <furq> fwiw that's the config on my rpi ffmpeg
[09:27:06 CEST] <DemoniacMilk> hm ye no --cc set
[09:27:15 CEST] <DemoniacMilk> lemme try
[09:31:01 CEST] <mavi> so i tested using handbrake. any idea what the nlmeans parameters on ffmpeg are? Can't find them anywhere.
[09:31:18 CEST] <mavi> Looking for ultralight and light settings, or at least a way to figure them out.
[09:31:40 CEST] <furq> !filter nlmeans
[09:31:40 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#nlmeans
[09:32:09 CEST] <DemoniacMilk> hm, interesting https://pastebin.com/SjKxnKPn
[09:33:04 CEST] <furq> i sure am glad i use a distro which packages a working toolchain
[09:33:28 CEST] <mavi> !filter nlmeans
[09:33:28 CEST] <nfobot> mavi: http://ffmpeg.org/ffmpeg-filters.html#nlmeans
[09:33:43 CEST] <mavi> thanks :)
[09:34:08 CEST] <DemoniacMilk> ooohhh, i see why
[09:34:20 CEST] <DemoniacMilk> theres an additional /arm in the path
[09:34:25 CEST] <furq> nice
[09:34:30 CEST] <DemoniacMilk> god im an idiot :D
[09:34:30 CEST] <furq> also why are you running ./configure as root
[09:35:10 CEST] <DemoniacMilk> i tink id have to change some permissions otherwise
[09:35:14 CEST] <DemoniacMilk> and didnt bother to do so yet
[09:35:40 CEST] <furq> you shouldn't if everything's in ~
[09:35:57 CEST] <furq> unless you ran some earlier step as root
[09:36:54 CEST] <DemoniacMilk> i probably did
[09:37:11 CEST] <DemoniacMilk> then again i could just change owenership of all of my home folder
[09:37:24 CEST] <DemoniacMilk> to be owned by me, because that'd be the default anyways
[09:37:44 CEST] <furq> that sounds prudent
[09:37:59 CEST] <DemoniacMilk> i dont know the word prudent
[09:38:23 CEST] <furq> http://chambers.co.uk/search/?query=prudent&title=21st
[09:39:09 CEST] <DemoniacMilk> hhaevery explanation contains a word i dont know but i think i got it :D
[09:41:03 CEST] <mavi> There seems to be a lack of people using nlmeans via ffmpeg. Only found one thread on it, and the guy is saying s=1 the lowest setting is too much.
[09:41:08 CEST] <furq> also if this is for rpi then you'll want --enable-omx-rpi --enable-mmal
[09:41:13 CEST] <furq> if not then ignore that
[09:41:41 CEST] <mavi> for the syntax, how do i fix this
[09:41:43 CEST] <mavi> -vf scale=-2:"min(ih\,480)":flags=lanczos nlmeans=s=1
[09:41:55 CEST] <furq> replace that space with a comma
[09:42:15 CEST] <furq> also you might as well do a bicubic scale
[09:42:22 CEST] <furq> it'll be faster and you're trying to lose fine detail anyway
[09:42:57 CEST] <furq> i normally use bicubic to downscale low-quality sources
[09:42:59 CEST] <mavi> I'm trying to keep detail within reason. Kind of a fine line between blurring and detail.
[09:43:26 CEST] <mavi> is lancoz supposed to be a sharp downscaler while bicubic is a bit softer?
[09:43:32 CEST] <furq> yeah
[09:43:44 CEST] <furq> lanczos and spline are the sharper ones in swscale
[09:43:52 CEST] <dystopia_> i use spline for everything
[09:44:07 CEST] <mavi> i'll give it a try, i did notice some oddly sharp lines for the lines around the face.
[09:44:41 CEST] <mavi> -vf scale=-2:"min(ih\,480)":flags=lanczos,nlmeans=s=1
[09:44:44 CEST] <mavi> like that?
[09:44:46 CEST] <furq> yeah
[09:44:55 CEST] <furq> lanczos and spline tend to amplify source artifacts if there are any
[09:44:59 CEST] <furq> although probably less so when downscaling
[09:45:06 CEST] <mavi> ah i see
[09:45:19 CEST] <mavi> im using it just for downscaling.. no real point in upscaling in a low bitrate film
[09:45:50 CEST] <furq> if this is a generic pipeline then bicubic is probably better
[09:46:09 CEST] <furq> it's your pipeline though
[09:47:52 CEST] <DemoniacMilk> Reducing images is a completely safe and rational operation. You're simply reducing precision and resolution by discarding information. Make the image as small as you want, and you have complete fidelity-- within the bounds of the number of pixels you've allowed. You'll get good results no matter which algorithm you pick. (Well, unless you pick the naive Pixel Resize or Nearest Neighbor algorithms.) (from https://blog.codinghor
[09:47:57 CEST] <mavi> It's a generic pipeline. CRF 28-30, 480p some 720p stuff, going to be doing over 5000 videos.. so want to get the setting right first
[09:48:37 CEST] <dystopia_> those crf values seem very high
[09:48:46 CEST] <furq> i wouldn't sweat too much about excessive denoising at crf 28
[09:48:52 CEST] <mavi> yea they are. It's meant for a foreign audience with crap internet
[09:48:56 CEST] <furq> you're going to be throwing a lot of detail away regardless
[09:49:10 CEST] <furq> i would probably favour heavier denoising at that kind of bitrate
[09:50:05 CEST] <mavi> if only I could wrap my head around the nlmeans settings on ffmpeg. The hq3d settings are well documented, the nlmeans settings on ffmpeg aren't. Only thing I gather is s=1 is the lowest and it goes up.
[09:50:33 CEST] <mavi> on handbrake it's straightforward and uses a set of 6 or so numbers with colons in between. ffmpeg doesn't share that system.
[10:02:07 CEST] <mavi> is bucubic better than bilinear ? been reading up on it.
[10:03:37 CEST] <DemoniacMilk> biliniear uses a 2x2 grid i think, while bicubic uses a 4x4 grid with higher priority on centered pixels
[10:03:50 CEST] <mavi> ah perfect, so bicubic retains a bit more detail?
[10:03:56 CEST] <furq> bilinear is faster but softer
[10:04:02 CEST] <DemoniacMilk> i have no idea what the results look like tho, but as bicubic requires more computing and is still around i guess it looks better
[10:04:41 CEST] <mavi> isn't spline an offshoot of bicubic? It seems to be called bicubic split in some docs.
[10:04:49 CEST] <mavi> "natural bicubic spline rescaling algorithm"
[10:05:29 CEST] <DemoniacMilk> uh, no idea :(
[10:08:51 CEST] <Azarus> hey guys
[10:10:26 CEST] <mavi> My god, the ffmpeg filter nlmeans has taken my video fps from 80 down to 4 fps lol. Wow.
[10:10:33 CEST] <Azarus> I am looking for a solution to dynamically generate rtmp streams using ffmpeg. And at the same mix images & videos. Additionaly draw text and other ui elements as an overlay
[10:10:54 CEST] <Azarus> And I am not sure if such a thing is possible with ffmpeg
[10:13:13 CEST] <Azarus> So right now, i have images generated with transparency by nodejs that i would like to put on a video stream as an overlay
[10:14:18 CEST] <Azarus> also i would like to update that image every 5-10 seconds
[10:14:27 CEST] <Azarus> And additionally i can't really get ffmpeg to continously stream the audio files over rtmp
[10:14:32 CEST] <Azarus> can someone help me out please?
[10:33:02 CEST] <mavi> Yea this is insane, the nlmeans plugin seems to be highly unoptimized on the s=1 default settings on ffmpeg nightly. Goes at 2fps, which is pretty unusable. Maybe I'm doing something wrong?
[10:40:46 CEST] <DemoniacMilk> hm ffplay is not being built, maybe im missing something? I have installed SDL and found some line in config.mak (!ffplay=yes) that i mightwant to remove the ! in?
[10:42:36 CEST] <DemoniacMilk> ah ye that worked, although it ends in SDL.h: No such file or directory
[10:57:14 CEST] <DemoniacMilk> can i read/disaply a network video stream created by ffmpeg using ffplay only or may i use ffmpeg as well?
[11:24:15 CEST] <mavi> anywhere I can submit a bug report, I doubt nlmeans should be getting 2fps, as i usually get 90. Wondering if the 3.2.4 build has different filters than the latest nightly one
[11:33:24 CEST] <DemoniacMilk> guys, i cant get ffplay to be built :(
[11:36:01 CEST] <DemoniacMilk> the cnfig log contains ffplay='yes'
[11:36:25 CEST] <DemoniacMilk> and ffplay_libs='$sdl2_libs'
[11:37:16 CEST] <DemoniacMilk> i have installed libsdl2-dev
[11:37:51 CEST] <DemoniacMilk> (on my host system tho, as im cross compiling, do i need to cross compile sdl2 as well and pass the compiled version?)
[11:39:37 CEST] <DemoniacMilk> ffplay.c:56:17: fatal error: SDL.h: No such file or directory
[11:40:48 CEST] <DemoniacMilk> after running the config, i get a warning
[11:40:54 CEST] <DemoniacMilk> WARNING: /home/lars/ti/linuxSDK/linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm-linux-gnueabihf-pkg-config not found, library detection may fail.
[11:41:08 CEST] <DemoniacMilk> maybe those two are related?
[13:16:24 CEST] <Tom_B> @jkqxz, that patch works great thanks! :) The small delay doesn't really matter and if needed I could just lower -g
[13:18:34 CEST] <mavi> So I'm trying to figure out my scale algorithm.
[13:20:19 CEST] <mavi> My current one is:  scale=-2:'min(ih,480)':flags=bicubic  but I also want to limit the width to a max of 854. So if a video has dimensions of 1050x 580 or so it would actually change to 854 width and scale accordingly or 480 height whichever is bigger
[13:20:28 CEST] <mavi> How would I go about doing this?
[14:39:38 CEST] <mavi> nvm got help at stackoverflow: scale=w='if(gt(dar,854/480),min(854,iw*sar),2*trunc(iw*sar*oh/ih/2))':h='if(gt(dar,854/480),2*trunc(ih*ow/iw/sar/2),min(480,ih))':flags=bicubic
[14:58:43 CEST] <ZeDavidT> Hi guys, I'm trying to compile ffmpeg under centos7, using 3.2.4 realease. However, even if the flag "--enable-libebur128" is available under ./configure, it seems that it's missing a library. Do you know where I can find it?
[15:09:07 CEST] <DemoniacMilk> anyone here used ffmpeg on e.g. an RPi (or any other embedded system)?
[15:09:46 CEST] <DemoniacMilk> cause i was comparing the video conversion performance of my old laptop to the embedded prcoessor
[15:09:55 CEST] <DemoniacMilk> on a ~700 frame raw video
[15:10:16 CEST] <DemoniacMilk> and my laptop finished pretty much immediately, while the embedded system converted only ~13 fps
[15:11:19 CEST] <DemoniacMilk> so im wondering if optimization / hardware accel might be used somehow
[15:14:31 CEST] <BtbN> a classic RPi is just that slow.
[15:46:28 CEST] <asda> is it possible to create an empty container with some arbitrary duration using ffmpeg?
[15:47:24 CEST] <asda> I've already tried it with a silent audio track generated by anullsrc and no video stream
[15:47:50 CEST] <asda> but can you have no streams at all and yet still have a duration?
[15:52:37 CEST] <DemoniacMilk> does anyone know a video codec with low computing requirements for encoding?
[15:53:45 CEST] <asda> DemoniacMilk: are you willing to sacrifice quality?
[15:54:33 CEST] <asda> you could use x264 with some ultrafast preset, should be fast enough
[15:54:41 CEST] <asda> but the quality will be mediocre
[15:54:57 CEST] <asda> or the file will be huge if you want acceptable quality
[15:56:36 CEST] <DemoniacMilk> quality is secondary, as long as the embedded system is able to keep up :P
[15:57:00 CEST] <DemoniacMilk> so far mpeg2 seems to be the best
[15:57:54 CEST] <DemoniacMilk> x264 needs to be added seperately i think?
[15:58:06 CEST] <DemoniacMilk> as in: is not included in the ffmpeg package?
[15:58:26 CEST] <asda> depends on the platform/distro/whatever
[15:58:37 CEST] <asda> check with ffmpeg -encoders
[15:59:07 CEST] <asda> ffmpeg -v error -encoders | grep x264
[16:00:23 CEST] <kepstin> DemoniacMilk: if you're on an rpi specifically, there's a hardware encoder on the chip which can be used. You need an ffmpeg with it enabled, then you can use the "h264_omx" encoder (iirc)
[16:01:52 CEST] <asda> kepstin: how is the quality with that encoder?
[16:02:39 CEST] <kepstin> I imagine it's similarly "not great" like any other hardware encoder, but it should be good enough if you crank up the bitrate, and it'll definitely be less cpu intensive than x264.
[16:03:44 CEST] <DemoniacMilk> hm its an AM3359
[16:03:56 CEST] <DemoniacMilk> im not sure if it has a hardware encoder but thats probably a good thing to check
[16:04:09 CEST] <DemoniacMilk> (same cpu as used b beaglebone black iirc)
[16:06:09 CEST] <DemoniacMilk> hm seems like it doesnt have taht, but a "PowerVR SGX" Graphics Accelerator subsystem"
[16:07:04 CEST] <DemoniacMilk> and a neon co processor, i htink i read some about that somewhere
[16:09:20 CEST] <asda> DemoniacMilk: if you run ffmpeg, it should say --enable-neon
[16:09:45 CEST] <asda> then it means it was built with support for the neon instructions
[16:10:13 CEST] <DemoniacMilk> i dont think i configured ffmpeg to use neon (at least if its not the default)
[16:10:37 CEST] <DemoniacMilk> but i guess i could do that
[16:16:49 CEST] <DemoniacMilk> https://pastebin.com/BzwtZmiS
[16:16:56 CEST] <DemoniacMilk> you mean it should be lising --enable-neon here?
[16:19:19 CEST] <DemoniacMilk> i just explicitly stated --enable-neon for 'configure'
[16:23:22 CEST] <asda> mine looks like this: https://spit.mixtape.moe/view/raw/52fd8a98
[16:24:34 CEST] <DemoniacMilk> ye okay so you added --enable-neon manually
[16:24:44 CEST] <asda> I didn't build it
[16:25:08 CEST] <DemoniacMilk> ah okay i need to build it myself, but it seemed like neon should be anebled by default
[16:25:24 CEST] <DemoniacMilk> at least theres a --disable-neon option
[16:26:43 CEST] <asda> well, it could be implied for some target platforms, I'm not sure
[16:26:59 CEST] <DemoniacMilk> ill see when this build finished
[16:34:00 CEST] <DemoniacMilk> ye it now says --enable-neon
[16:34:50 CEST] <DemoniacMilk> i dont see a increase i performance tho
[16:36:10 CEST] <DemoniacMilk> or do i? should have written down the old values :D
[17:50:14 CEST] <DemoniacMilk> what does ffmpeg do if neon should be used but is not available?
[17:50:36 CEST] <DemoniacMilk> does it stop or generate a log entry or soemthing?
[17:58:41 CEST] <kepstin> DemoniacMilk: I believe that for assembly optimizations, ffmpeg should by default (you can disable this with a configuration) be doing runtime cpu detection to determine which optimizations to turn on.
[17:59:06 CEST] <DemoniacMilk> i forced --enable-neon in one build and --disable-neon in another
[17:59:40 CEST] <DemoniacMilk> but i dont see any difference in performance
[17:59:47 CEST] <kepstin> also, the options on the ffmpeg configure script don't affect which optimizations the x264 encoder is built with; that's internal to the x264 library
[17:59:59 CEST] <DemoniacMilk> im not using x264 tho
[18:00:07 CEST] <kepstin> what encoder are you using?
[18:00:08 CEST] <DemoniacMilk> i tried mpeg2 i think
[18:00:24 CEST] <DemoniacMilk> and mpeg4 as well
[18:00:50 CEST] <kepstin> i wouldn't be surprised if nobody has written any neon optimizations for mpeg2/4, they're old codecs that don't see much use any more, and are rarely if ever encoded on arm
[18:01:34 CEST] <kepstin> well, mpeg2 still sees some use in tv broadcast and dvd/bd encoding, but that's something you'd do on a big workstation or dedicated server, not a little arm board :)
[18:01:41 CEST] <DemoniacMilk> okay maybe thats why
[18:02:05 CEST] <kepstin> that said, they do share some code with the jpeg encoder, i think, which is obviously still used :)
[18:02:07 CEST] <kepstin> so... :/
[18:02:34 CEST] <DemoniacMilk> i think i saw some info somewhere that x264 needs to be compiled and provided to ffmpeg as a library?
[18:03:05 CEST] <kepstin> DemoniacMilk: yes, it's an external codec library that ffmpeg can link to.
[18:03:46 CEST] <DemoniacMilk> alright ill take care of that tomorrow
[18:03:47 CEST] <DemoniacMilk> thankss a lot
[18:03:58 CEST] <DemoniacMilk> and have a nice evening (or whatever time it may be at your place)
[18:05:20 CEST] <artectrex> Hi, Telegram is violating the GPL by not updating its android source code (they use ffmpeg), correct? Would the FFmpeg maintainers consider legal action to get them to release it? Their have been numerous requests
[18:11:27 CEST] <artectrex_> Hi, Telegram is violating the GPL by not updating its android source code (they use ffmpeg), correct? Would the FFmpeg maintainers consider legal action to get them to release it? Their have been numerous requests
[18:24:58 CEST] <durandal_1707> artectrex_: nobody cares
[18:25:37 CEST] <artectrex_> Thank you for your answer.
[18:26:46 CEST] <iive> artectrex_: ffmpeg is LGPL, unless it includes something else that is gpl
[18:27:28 CEST] <artectrex_> I think they do have gpl parts, I may have been mistaken so let me check, having doubts now
[18:27:40 CEST] <JEEB> usual thing to look for is the string "--enable-gpl"
[18:27:48 CEST] <JEEB> or just enabl-gpl
[18:27:53 CEST] <JEEB> *enable
[18:28:14 CEST] <artectrex_> https://github.com/DrKLO/Telegram/blob/55463a93db95dcc450c00af3918d9bbbebf4f8c1/TMessagesProj/jni/ffmpeg/build_ffmpeg_android.sh
[18:28:19 CEST] <JEEB> of course that can also be hidden but most people don't care enough
[18:28:23 CEST] <artectrex_> enable-gpl is there
[18:28:29 CEST] <iive> artectrex_: in the past FFmpeg had persued GPL violations, we had lawyer, but that all went to hell with the hostile fork.
[18:29:12 CEST] <iive> we do merge a lot of their code too, and they are not very cooperative.
[18:29:21 CEST] <pzy> turns out no one gives a fuck about "software licensing" unless you're big enough to bully people :P
[18:29:46 CEST] <artectrex_> I would think a simple (friendly ) email to them in an official capacity would be a good nudge
[18:29:52 CEST] <pzy> or the once-in-a-decade viral shaming of some company profiting from open source work
[18:30:28 CEST] <iive> artectrex_: it's like a devorce... people don't act rationally
[18:30:53 CEST] <artectrex_> Over at /r/android people seem to be getting aware of the issue, every telegram related post has comments about the GPL violations
[18:32:00 CEST] <artectrex_> Or maybe a statement of the FFmpeg team about it, to induce this "viral shaming"? I'm sure this would go front-page on YC and/or reddit
[18:32:26 CEST] <iive> there used to be a Hall of Shame
[18:32:33 CEST] <iive> i'm not sure if it still exists
[18:32:40 CEST] <thebombzen> well keep in mind that the violation in question is "not publishing an up-to-date version of the source and instead is publishing an older version"
[18:32:55 CEST] <thebombzen> in the grand scheme of things this isn't particularly atrocious
[18:33:41 CEST] <iive> well, they do need to publish the lgpl changes to the code. If they use them without change...
[18:33:51 CEST] <thebombzen> whenever you apply some sort of action to fix a problem, you have to weigh the severity of the problem to the effort required to fix it
[18:33:58 CEST] <artectrex_> yes, well the F-droid build (which is a FOSS fork) is getting 6 months out of date and missing more and more features, including VoIP
[18:34:01 CEST] <thebombzen> in this case, the severity of the problem isn't very large
[18:34:17 CEST] <thebombzen> yes, they're violating it, but it's not worth people's time to send a lawyer after them
[18:34:33 CEST] <artectrex_> Effectively half the featureset is not there in the released code
[18:34:51 CEST] <thebombzen> that can't be right
[18:34:58 CEST] <iive> artectrex_: are they making binary releases?
[18:35:02 CEST] <thebombzen> unless the version of ffmpeg they're using is from like 2007
[18:35:05 CEST] <artectrex_> Yes, weekly at least
[18:35:52 CEST] <artectrex_> I mean by half the featureset that Telegram audio calling is not implemented in the released code, at all
[18:36:23 CEST] <artectrex_> They have Google Play releases very often though, which are binary
[18:36:36 CEST] <iive> ok, about the last source release. Can you make a build with it, that has all the featurs of the corresponding binary build?
[18:37:02 CEST] <artectrex_> No. As I said, the Video/audio calls are not implemented in it
[18:37:13 CEST] <artectrex_> Oh sorry yes
[18:37:15 CEST] <artectrex_> misread that
[18:38:56 CEST] <iive> LGPL allows you to keep your code private, but you should distribute it in a form that allows relinking with the LGPL part. e.g. in static library.a  format
[18:39:26 CEST] <iive> it's easier if lgpl is used as dynamic library.so for that case.
[18:40:30 CEST] <artectrex_> The desktop client does not have those issues, they are maintained in the open. Android client ffmpeg dir is here : https://github.com/DrKLO/Telegram/tree/master/TMessagesProj/jni/ffmpeg
[18:41:28 CEST] <artectrex_> Seems to have library.a format
[18:41:47 CEST] <artectrex_> Not that I know what that means
[18:42:32 CEST] <Fenrirthviti> Means they're not violating anything, pretty much
[18:43:34 CEST] <artectrex_> But they are using GPL parts
[18:43:59 CEST] <artectrex_> https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/ffmpeg/build_ffmpeg_android.sh#L31
[18:46:22 CEST] <voip_> Hello guys i have problem with taking UDP live stream transcode and re-stream.
[18:46:22 CEST] <voip_> Every 1-2 min. FFMPEG stops witch error: "udp @ 0x549fea0] Circular buffer overrun. To avoid, increase fifo_size URL option. To survive in such case, use overrun_nonfatal option."
[18:46:22 CEST] <voip_> Problem still exists even if i take stream with option "?fifo_size=256000".
[18:46:22 CEST] <voip_> When i run only one instance of FFMPEG, everyting is fine, and newer stops.
[18:46:22 CEST] <voip_> https://pastebin.com/YiXpEAyb
[18:50:02 CEST] <thebombzen> did you try doing what it told you to do
[18:50:11 CEST] <thebombzen> "To survive in such case, use overrun_nonfatal option."
[18:50:39 CEST] <thebombzen> also, you don't need -strict experimental with aac anymore
[18:52:14 CEST] <iive> artectrex_: can you find what gpl parts they do use. e.g. ffmpeg need enable-gpl for libx264, however the library is available under second commercial license
[18:58:43 CEST] <voip_> thebombzen, thank you so much. So my command should be like :  ffmpeg -i 'udp://224.10.10.18:6000?fifo_size=256000&overrun_nonfatal=1'    ?
[18:59:02 CEST] <thebombzen> I don't actually know where to put the overrun_nonfatal option
[18:59:09 CEST] <thebombzen> it might just be an option for ffmpeg
[18:59:37 CEST] <thebombzen> ah yes what you ahve is correct
[18:59:40 CEST] <thebombzen> documentation agrees
[19:00:04 CEST] <voip_> nieed i fifo_size=25600 also ?
[19:00:57 CEST] <thebombzen> Yes
[19:02:29 CEST] <voip_> sorry one more question :) buffer size 25600 is ok, or i should experiment and increase/decrease ?
[19:27:08 CEST] <artectrex_> iive: Well, I didn't really look into it myself, and trusted word of others, who probably trusted others who were talking out of their neck. I can't find any non-Telegram code actually under GPL in the repo, so they are probably not infringing on your rights. They still are violating the GPL by not updating their own code which is under "GPLv2 or later". I was hoping the FFmpeg project would be able to pressure them into updating their code but that
[19:27:08 CEST] <artectrex_> was probably false hope. I want to thank you guys anyways, without FFmpeg lots of software I use daily would not be what it is today. Have a nice evening/afternoon/whatever
[19:31:46 CEST] <pzy> keep fightin' the good fight!
[19:37:09 CEST] <artectrex_> I don't really know what to do now. I certainly cannot litigate, would the FSF consider (threatening) legal action for something like this? And they use OpenSSL licensed stuff, is that violated in any way by Telegram not releasing their code? Doesn't seem like it. Oh well, they'll release it eventually I guess? It's just infuriating to me that a major selling point of the app is being FOSS, and it is *not* FOSS!
[19:37:39 CEST] <artectrex_> Again, thanks a bunch, and see ya
[20:43:28 CEST] <tokage> Dark_Arc: the license problem should be resolved in a few hours https://twitter.com/durov/status/847454485882355713
[20:43:57 CEST] <tokage> but the question is how long will it take next time? :-)
[21:52:53 CEST] <alexpigment> has anyone used x262 yet?
[21:53:12 CEST] <alexpigment> also, is there a way to build ffmpeg with x262 support?
[21:59:45 CEST] <JEEB> alexpigment: x262 is pretty much dead by now
[21:59:55 CEST] <JEEB> people are instead using the mpeg2 video encoder from lavc I think
[22:00:07 CEST] <alexpigment> the one built into FFMPEG?
[22:00:10 CEST] <JEEB> yes
[22:00:17 CEST] <alexpigment> man, it's such a terrible encoder
[22:00:24 CEST] <alexpigment> i was hoping x262 was better
[22:00:44 CEST] <JEEB> in standard libavcodec tradition libavcodec's thing has quite a bit of params you need to just know to optimize it
[22:00:48 CEST] <kepstin> if you know the all the tweak options, ffmpeg's encoder is ok, but really slow :/
[22:01:09 CEST] <alexpigment> i spent almost a week last year trying to match the quality of mainconcept
[22:01:11 CEST] <kepstin> iirc it doesn't have rate distortion enabled by default, for example
[22:01:25 CEST] <alexpigment> it was just terrible, no matter what settings i used
[22:01:29 CEST] <JEEB> not sure x262 really beat lavc mpeg2 in the end, the development just stopped in favour of lavc after some things
[22:01:47 CEST] <JEEB> and I don't think lavc has a libx262 wrapper
[22:02:01 CEST] <alexpigment> kepstin: i can't recall if i messed with rate distortion last time i looked into this
[22:02:19 CEST] <kepstin> it probably wouldn't be hard to hack a lavc wrapper together, it would be mostly copy/paste of the x264 wrapper
[22:02:26 CEST] <JEEB> yea
[22:02:42 CEST] <alexpigment> well, i guess a quality comparison between the two is in order first
[22:03:06 CEST] <alexpigment> anyway, i'll take a look at all this stuff again. maybe 2017 me has a bit more information than 2016 me
[22:03:08 CEST] <kepstin> somewhere I have some notes about mpeg2 encoding with lavc, lets see what I can dig up...
[22:03:23 CEST] <alexpigment> kepstin, that would be awesome, to be honest
[22:07:22 CEST] <JEEB> I also remember the x264dev blog having some lavc parameters back when D_S did a comparison on various encoders
[22:08:53 CEST] <alexpigment> it's possible the problems i was seeing were related to trying to create strict DVD-formatted encodes
[22:08:57 CEST] <kepstin> alexpigment: https://gist.githubusercontent.com/kepstin/9d60cde1f1714657737b8bdc58d673c5/raw is the options I was using when looking at DVD-spec encoding with lavc
[22:09:02 CEST] <alexpigment> rather than a progressive HD encode, for example
[22:09:31 CEST] <alexpigment> kepstin, you are awesome
[22:09:31 CEST] <kepstin> alexpigment: with non-dvd stuff, drop the vbv options (bufsize, maxrate) and increase the bframes (-bf)
[22:09:37 CEST] <alexpigment> i'm going to take a look at these
[22:09:43 CEST] <alexpigment> yeah, it's all DVD testing
[22:09:57 CEST] <kepstin> some of those options are a bit wierd or just guesses, or silly extra-large
[22:10:00 CEST] <alexpigment> i don't recall what all params i used in the past, but this will be a good starting point
[22:10:15 CEST] <kepstin> e.g. I think -dia_size is a bit ridiculous there
[22:10:32 CEST] <kepstin> but not sure, and that option is a weird bitfield with mpeg2video
[22:10:49 CEST] <alexpigment> i'm a bit green on dia_size
[22:11:00 CEST] <alexpigment> i mean it involves motion estimation
[22:11:15 CEST] <alexpigment> but it's nothing that changes how the video is decoded or how in spec the file is, right?
[22:11:41 CEST] <kepstin> dia_size basically says how far away to look for motion vectors for optimizing the encode, but the field also encodes some details about the search algorithm in the upper bits
[22:11:49 CEST] <kepstin> so the number itself is meaningless as-is
[22:12:29 CEST] <alexpigment> k
[22:12:35 CEST] <kepstin> '784' is actually 16 (counted in macroblocks, i think), with some extra bits set.
[22:12:44 CEST] <kepstin> 16 is the max, iirc
[22:12:55 CEST] <kepstin> or at least stuff starts breaking if you set it higher
[22:13:22 CEST] <kepstin> or maybe i'm completely wrong!
[22:13:27 CEST] <kepstin> it's a weird option :)
[22:13:35 CEST] <alexpigment> k, i'll start at that, and assuming the quality is good, i'll work my way backward on removing those parameters or changing their values
[22:13:43 CEST] <JEEB> lavc lossy encoders are not known for their easy understandability :)
[22:13:54 CEST] <alexpigment> that is entirely true :)
[22:14:34 CEST] <kepstin> x264 really revolutionized video encoder usage with that preset system
[22:14:47 CEST] <alexpigment> yeah, i wasn't sure if it was the first
[22:14:51 CEST] <kepstin> turned it from a cargo cult of weird options nobody understood into "pick how fast you want it"
[22:14:51 CEST] <alexpigment> but certainly the first i knew about
[22:15:10 CEST] <alexpigment> you didn't have to be an x264 dev to know how to use it :)
[22:16:11 CEST] <kepstin> old versions of x264 suffered from the same "lots of parameters nobody understands" thing as most other encoders, the preset system was added later.
[22:16:22 CEST] <JEEB> yup
[22:16:37 CEST] <JEEB> and the defaults were set to preset medium
[22:17:30 CEST] <kepstin> (and old versions of ffmpeg made it worse, by default it set some of the options on old x264 versions to settings bad enough that there's still code to this day in x264 which makes it error out if that combination of settings is used)
[22:18:13 CEST] <alexpigment> i'm just glad that there are a lot of use-case parameters you can choose with the major codecs. like mpeg-2 has "target", x264 has bluray-compat, x265 has uhd-bd, etc
[22:18:49 CEST] <alexpigment> not that those are equivalent to presets, but at least help you easily configure a bunch of parameters you don't know about to the appropriate settings for your use case
[22:19:56 CEST] <JEEB> blu-ray compat doesn't really do much else than limit the coding in certain ways. you still have to set the level (refs) and VBV/HRD limiting
[22:21:04 CEST] <alexpigment> yeah, it's true
[22:21:15 CEST] <alexpigment> but at least there are sites that have a lot of documentation on what to set
[22:21:44 CEST] <alexpigment> i tend to use it on non-blu-ray encodes just in case i want to go back and use tsmuxer to archive it to a playable disc
[22:22:00 CEST] <alexpigment> the parameters are usually within reason enough to play on the players i've tested
[22:22:31 CEST] <alexpigment> but yeah, there's a website that i've referenced a bunch with an exhaustive list of x264 parameters for every format in the blu-ray spec
[22:24:51 CEST] <JEEB> the most limiting stuff wrt bluray-compat is something you really don't want to enable globally. it's a weird limitation of the BD spec and BD spec only
[22:25:18 CEST] <JEEB> if you're not using actual BD mastering tools that try to verify the stream then it really doesn't matter :D
[22:25:26 CEST] <kepstin> alexpigment: also see https://ffmpeg.org/faq.html#Which-are-good-parameters-for-encoding-high-quality-MPEG_002d1_002fMPEG_002d2_003f
[22:25:36 CEST] <JEEB> the HRD params are what really matters :P
[22:25:44 CEST] <JEEB> and being within level 4.1
[22:25:45 CEST] <JEEB> or so
[22:28:20 CEST] <sikilikis> anybody on that can provide assistance? Google has failed me
[22:29:05 CEST] <sikilikis> like furq since you been such a homie so far
[22:33:04 CEST] <Fenrirthviti> asking to ask is so 2005
[22:33:32 CEST] <sikilikis> lol
[22:33:47 CEST] <sikilikis> I cant be talking to the air. People will think I'm crazy
[22:34:13 CEST] <sikilikis> anyways you wanna take a crack at this?
[22:34:56 CEST] <Fenrirthviti> I have no idea, you've still given no information on the actual issue :P
[22:35:26 CEST] <Fenrirthviti> Probably start here: http://rurounijones.github.io/blog/2009/03/17/how-to-ask-for-help-on-irc/
[22:35:26 CEST] <sikilikis> https://pastebin.com/kXEtkRgf
[22:35:37 CEST] <sikilikis> commad and the log output
[22:36:05 CEST] <sikilikis> I'm live streaming to youtube. Itts looping through images, overlaying text, and playing music
[22:38:21 CEST] <sikilikis> ffmpeg version is 3.2.4 if that helps. I didn't use whatever is the latest. It's running on a raspberry pi 3
[22:39:34 CEST] <Fenrirthviti> trying to remember where the heck the list of error codes for librtmp is
[22:41:44 CEST] <Fenrirthviti> I think 32 is packet failed to read?
[22:42:48 CEST] <alexpigment> kepstin, do you combine all these mpv_flags with value:value:value ?
[22:43:11 CEST] <kepstin> alexpigment: I think you can leave them separate or put them together with +
[22:43:16 CEST] <kepstin> alexpigment: not sure :/
[22:43:18 CEST] <alexpigment> k
[22:43:23 CEST] <sikilikis> it doesnt happen immediately by the way.
[22:43:33 CEST] <sikilikis> It'll run for hours before it hits this
[22:47:39 CEST] <tmm1> anyone know if freebsd has a /dev/dri equivalent for vaapi hwaccel
[22:47:39 CEST] <Fenrirthviti> sikilikis: Error 104 occurs when connection is closed by remote end. <-- there we go
[22:47:44 CEST] <Fenrirthviti> you're being dropped.
[22:47:47 CEST] <sikilikis> by remote end?
[22:47:52 CEST] <sikilikis> wtf so its youtube's fault?
[22:50:16 CEST] <sikilikis> well shit
[22:51:28 CEST] <sikilikis> i'm googling some more and people are saying that timestamp issues are the most likely reason youtube would close the connection. Is having +getpts not enough?
[22:52:50 CEST] <alexpigment> kepstin: it's pretty funny rendering an MPEG-2 480i video at 8fps on a core i7 :)
[22:53:14 CEST] <kepstin> alexpigment: I love how there's basically no multithreading in that encoder.
[22:53:17 CEST] <alexpigment> this is a good sign though. it never took this long before with any of my settings, so i'm looking forward to some quality comparisons
[22:53:54 CEST] <kepstin> in my experience, the DVD restrictions are so awful that there's some videos that are absolutely never gonna look good :/
[22:53:56 CEST] <alexpigment> oh you're right
[22:54:14 CEST] <alexpigment> yeah, it's a pretty bad spec
[22:54:38 CEST] <alexpigment> i don't consider it a reference quality format by any means
[22:54:53 CEST] <alexpigment> blu-ray, on the other hand, they did pretty well with that as a home video format
[22:55:50 CEST] <kepstin> particularly with modern BDs using a good h264 encoder, by someone who knows how to prepare video to reduce banding, etc. it can look really good.
[22:56:04 CEST] <JEEB> yup
[22:56:11 CEST] <JEEB> unlike DVD which was bit starved from the beginning
[22:56:29 CEST] <JEEB> > 8 megabits per sec maxrate > bufsize of 1.5 or so megabits
[22:56:30 CEST] <alexpigment> yeah, even if you don't use all the allotted bitrate - most use ~20mbps - it's still better quality than anything else out there
[22:57:11 CEST] <JEEB> the least used thing in BDs is the 720p60/1.001 mode
[22:57:16 CEST] <alexpigment> yeah, 8mbps mpeg-2 wasn't even effective for one of the common uses - converting analog tapes to digital
[22:57:26 CEST] <sikilikis> what does the igndts flag do?
[22:57:30 CEST] <JEEB> alexpigment: the bufsize is what kills it
[22:57:44 CEST] <JEEB> like, if you are up to the maxrate it's like less than 1/4th of a second
[22:57:51 CEST] <alexpigment> jeeb: i've actually used the 720p60 mode quite a bit ;)
[22:58:14 CEST] <JEEB> alexpigment: I've mostly seen it on extras discs as back backgrounds for java games
[22:58:21 CEST] <JEEB> and one demoscene blu-ray I think
[22:58:21 CEST] <alexpigment> there are a handful of TV channels (ABC, FOX) that broadcast in 720p60. so i archive stuff to that spec when it comes from those channels
[22:58:38 CEST] <kepstin> what's even worse is when they put 24p content on dvds telecined and encoded as interlaced, rather than progressive with field repeat flags
[22:58:42 CEST] <alexpigment> i'd say the very least used format is 720p24
[22:58:48 CEST] <kepstin> so much efficiency loss from the interlaced encoding :(
[22:59:06 CEST] <JEEB> well that doesn't actually give you much compared to just doing 1080p24 or 1080p24/1.001 :P
[22:59:10 CEST] <alexpigment> kepstin: yeah, but it can be successfully reversed at least
[22:59:11 CEST] <JEEB> other than longer GOPs
[22:59:16 CEST] <JEEB> (´4@)
[22:59:39 CEST] <alexpigment> yeah, i'm just saying that 720p24 is somehow part of the spec. i've never seen it used once nor used it myself
[22:59:46 CEST] <alexpigment> even on bonus material, i've never seen it
[22:59:53 CEST] <kepstin> alexpigment: not always, because in some cases there's such insufficient bitrate that the fields leak into eachother :(
[23:00:12 CEST] <kepstin> so you have to filter it anyways to remove some semi-combing artifacts
[23:00:39 CEST] <JEEB> but yea, I've seen a few 3DCG things that would have been awesome in 720p60/1.001, yet it's always done in 1080p24 - some even emulating the feel of 12Hz animation
[23:00:46 CEST] <JEEB> which makes big ol' JEEB sad :<
[23:01:22 CEST] <alexpigment> kepstin: true. i do know that 480p24 with pulldown has caused issues for me in that past as a consumer. i have 100s of music video DVDs that i ripped into a sorted collection. the ones in 480p24 always caused weird playback problems when ripped from the disc. the only way around it that i found was to play them on a dvd player, then capture the signal :((
[23:02:24 CEST] <kepstin> alexpigment: modern versions of ffmpeg can actually handle the 480p24 with pulldown stuff - you use the "repeatfields" filter, then detelecine it afterwards.
[23:02:34 CEST] <alexpigment> JEEB: on that note, i hate how netflix and other streaming services do 1080p24 rather than 720p60 on a lot of stuff originally recorded in 1080i30/1080p60. unfortunately they don't care about original framerate
[23:03:39 CEST] <alexpigment> kepstin: i'll have to try that out. interestingly, the whole point of that ripping project was to have untouched MPEG-2 masters, but that pulldown problem kinda forced me into some sort of secondary encoding anyway. i'll definitely keep that one in mind
[23:05:16 CEST] <kepstin> the issue with a lot of stuff on dvd in p24 with pulldown is that it's not consistently applied - it looks like they often feed i60 into an encoder, and the encoder puts some frames in progressive if it matches a telecine pattern
[23:05:26 CEST] <kepstin> so some parts are p24 others are i60
[23:05:50 CEST] <kepstin> the repeatfields filter turns it into all i60 so you can re-do the detelecine
[23:06:34 CEST] <alexpigment> yeah, the weird part of it all is that standalone blu-ray players have no problem, but once ripped into separated vobs and played back in any software player, you'd get problems where there would be a frame that was interlaced and mixed with the previous and next frame
[23:07:01 CEST] <alexpigment> sorry, i meant standalone dvd and blu-ray players
[23:07:41 CEST] <alexpigment> but that makes sense forcing to 60i then detelecining
[23:08:28 CEST] <kepstin> well, most of the standalone dvd players output 60i anyways...
[23:08:55 CEST] <kepstin> I suppose some have "progressive scan", but they're probably running through a detelecine on the box anyways to handle dvds which weren't encoded progressive
[23:09:06 CEST] <alexpigment> i suppose so. i just didn't understand why software players were so confused by the vobs
[23:10:25 CEST] <kepstin> i think the classic mplayer/mencoder actually had some code to handle this, back in the day
[23:10:56 CEST] <mavi> Does anyone know why the nlmeans filter only goes at 2fps while the hq3d ones goes at 83 on the same pc? Is it a broken build or is it just that slow?
[23:10:58 CEST] <kepstin> until that repeatfields filter was added to ffmpeg, I kept around an old mencoder binary because it had a filter which did that ("softpulldown")
[23:11:01 CEST] <mavi> using the latest nightly version
[23:12:20 CEST] <kepstin> mavi: nlmeans is just a really slow filter (the algorithm's a lot more complex)
[23:17:03 CEST] <alexpigment> i love this message for mpeg2video encoding:
[23:17:10 CEST] <alexpigment> "Impossible bitrate constrains, this will fail"
[23:17:29 CEST] <mavi> kepstin, using handbrake it's slower but not 2fps slow. It seems like it's ffmpeg.
[23:17:35 CEST] <alexpigment> ok then, but either actually fail or don't give me the message
[23:18:16 CEST] <mavi> Via ffmpeg the hq3d filter same settings goes at 80fps, while the nlmeans=s=1 goes at 2. On handbrake it is only 20% slower than hq3d.
[23:18:51 CEST] <kepstin> mavi: huh, i thought handbrake mostly used ffmpeg filters? I guess not. It might be that the handbreak version is multithreaded and ffmpeg's isn't.
[23:18:52 CEST] <mavi> So I believe the implementation must be either wrong, or i have a nightly ffmpeg from a few days ago which has an older nlmeans filter?
[23:19:09 CEST] <mavi> Yea they do. That's why it's odd...
[23:19:19 CEST] <kepstin> there's a few ffmpeg filters that are technically correct, but with slow implementations
[23:19:24 CEST] <kepstin> nnedi has that issue too
[23:19:50 CEST] <mavi> where it's like 20x slower?
[23:20:25 CEST] <kepstin> mavi: well, first thing to do is make sure you're actually using comparable settings.
[23:20:58 CEST] <mavi> I'm using the same test file. With weak settings on both hq3d and nlmeans
[23:21:11 CEST] <mavi> Same settings for everything other than the denoise filters.
[23:22:03 CEST] <kepstin> alexpigment: yeah, that message is kinda silly. you get it when bitrate and max rate are the same and minrate isn't set (i.e. bitrate=maxrate, but you aren't doing cbr)
[23:22:31 CEST] <kepstin> alexpigment: when that really should be a perfectly valid option for "just use as much bitrate as you can, please", at least with 2-pass mode.
[23:24:21 CEST] <ChocolateArmpits> Is fifo muxer broken? I can't get it to use rtsp, it aborts with no message
[23:24:46 CEST] <mavi> btw when I use nr=300 combined with light hq3d 1.5:1.5:6:6 settings the file size and quality seems to be less than just light hq3d settings without nr300. Interesting stuff. Using it for lowbitrate crf encodes
[23:25:06 CEST] <mavi> i mean file size is bigger than just the light denoiser, and the quality is slightly less.
[23:25:21 CEST] <mavi> just using the denoiser alone yields better file sizes.
[23:25:45 CEST] <kepstin> mavi: well, let us know if you come up with a patch to make ffmpeg's nlmeans filter faster.
[23:26:02 CEST] <kepstin> (it's hasn't been touched since it was merged)
[23:26:09 CEST] <mavi> I know what you mean. Just trying to see if it's a bug or it's my build. Trying to see if anyone has similiar results.
[23:26:21 CEST] <mavi> or just a slow implementation.
[23:26:48 CEST] <mavi> I'm not a coder. I appreciate everything the ffmpeg team has done. Just troubleshooting.
[23:28:18 CEST] <alexpigment> ok, so i'm testing DVD with a 1080p60 source. part of my process is to scale down with lanczos then interlace with -vf interlace
[23:28:25 CEST] <alexpigment> it was blurry, so i disabled the lowpass filter
[23:28:47 CEST] <alexpigment> but then it gives me the warning: "Lowpass filter is disabled, the resulting video will be aliased rather than interlaced"
[23:29:06 CEST] <alexpigment> is that just written poorly/incorrectly, or am i missing something about this warning?
[23:29:15 CEST] <alexpigment> it will still be interlaced i'm pretty sure...
[23:29:16 CEST] <kepstin> mavi: just keep in mind that the nlmeans implementation in ffmpeg appears to use different parameters from that in handbreak, so they're not directly comparable because they do different things.
[23:30:00 CEST] <kepstin> mavi: given that ffmpeg is so much slower, i suspect it's using a larger search range than handbreak
[23:30:16 CEST] <kepstin> (you might be able to tweak that)
[23:30:45 CEST] <furq> nnedi being slow isn't really an issue with the filter afaik
[23:31:03 CEST] <furq> nnedi is just that slow with one thread
[23:31:10 CEST] <kepstin> furq: well, it could be faster if it was multithreaded, and some simd might help a bit
[23:31:27 CEST] <furq> libavfilter can't do frame threading at all can it
[23:31:34 CEST] <mavi> That means sense. I tried figuring out the customized settings but the documentation on it is somewhat sparse. Any ideas how to do a light denoise using custom ranges on ffmpeg's nlmeans filter?
[23:31:54 CEST] <furq> mavi: like i said, it's really not worth worrying about this if you're encoding to crf 28 anyway
[23:31:57 CEST] <furq> just use hqdn3d
[23:32:17 CEST] <mavi> I currently am :) Just trying to squeeeeze before my 5k video mass encode.
[23:32:41 CEST] <durandal_170> if you need only temporal denoiser try atadenoise
[23:32:42 CEST] <kepstin> furq: the nnedia filter can be parallelized within frames easily so the filter could spawn threads internally. no frame threading needed.
[23:32:44 CEST] <furq> you're not going to get nlmeans to run any faster without patching ffmpeg or filtering externally with vapoursynth
[23:32:56 CEST] <furq> and the latter is really not worth the effort in this case
[23:33:14 CEST] <kepstin> the ffmpeg nlmeans doesn't do temporal denoising at all, it's listed as a "todo" :)
[23:33:23 CEST] <furq> nice
[23:33:40 CEST] <mavi> yes it does seem like that is the cause. Vapoursynth seems to have the best implementation of nlmeans but yea not worth it for my current use.
[23:34:13 CEST] <mavi> well then that takes care of that potential route.
[23:34:15 CEST] <olspookishmagus> hello, I have a bunch of mp3s to which I would like to do the following in batch: 1. downmix them to mono 2. convert them from mono to stereo 3. convert them from variable bitrates to say: 96 CBR
[23:34:20 CEST] <kepstin> I assume the only reason the handbreak nlmeans wasn't copied is that someone wanted an LGPL version for ffmpeg (handbreak is GPL)
[23:34:20 CEST] <olspookishmagus> I guess that need some research
[23:35:02 CEST] <kepstin> olspookishmagus: what do you even mean by "convert them from mono to stereo"?
[23:35:37 CEST] <furq> https://github.com/VFR-maniac/VapourSynth-TNLMeans/blob/master/TNLMeans.cpp
[23:35:41 CEST] <furq> there's an MIT implementation
[23:35:56 CEST] <kepstin> olspookishmagus: keep in mind that the ffmpeg command line tool doesn't support batch/multi-file operations, so you'll have to write a shell or batch script to do that
[23:36:29 CEST] <kepstin> furq: that file header says GPL-2?
[23:36:43 CEST] <kepstin> (well, GPL-2+)
[23:36:44 CEST] <furq> oh yeah i can't read
[23:36:57 CEST] <furq> i saw a license header that wasn't two pages long and assumed it was MIT
[23:37:04 CEST] <kepstin> also it's C++ :)
[23:40:57 CEST] <thebombzen> where does the CUDA code for hevc_cuvid come from?
[23:41:08 CEST] <thebombzen> is that part of libavcodec or is that part of the cuda installation
[23:42:23 CEST] <alexpigment> olspookishmagus: are you on windows?
[23:42:53 CEST] <olspookishmagus> kepstin: take that remaining mono channel and copy it, and somehow label the first LEFT channel and the other RIGHT?
[23:42:59 CEST] <olspookishmagus> alexpigment: fortunately atm NO
[23:43:13 CEST] <olspookishmagus> alexpigment: would you suggest using foobar2000?
[23:43:18 CEST] <kepstin> olspookishmagus: ok, that's trivial to do.
[23:43:39 CEST] <olspookishmagus> https://hydrogenaud.io/index.php/topic,111695.0.html
[23:44:02 CEST] <alexpigment> olspookishmagus: i don't know too much about foobar2000. i was just going to say that i could easily help you create a batch script on windows to do that, but you're not on windows ;)
[23:44:46 CEST] <alexpigment> kepstin probably knows more about the actual command line parameters to do what you want to do anyway though
[23:46:32 CEST] <olspookishmagus> alexpigment: PowerShell? CygWin?
[23:46:41 CEST] <alexpigment> but i assume it's like ffmpeg -i yourfile.mp3 -map_channel 0.0.0 -b:a 96kbps yourfile-left.mp3 -map channel 0.0.1 yourfile-right.mp3
[23:47:04 CEST] <llogan> i was assuming something more like: https://trac.ffmpeg.org/wiki/AudioChannelManipulation#Mixbothstereochannelstostereo
[23:47:31 CEST] <kepstin> olspookishmagus: to get a simple downmix/upmix, it should be enough to specify the '-ac' option when re-encoding; '-ac 1' will downmix to mono, then '-ac 2' will duplicate mono channel to stereo
[23:47:43 CEST] <kepstin> (i.e. same data in both track)
[23:47:52 CEST] <kepstin> if you want to do it in 1 step, you'll have to use filters
[23:48:12 CEST] <alexpigment> oh i misread the original request. downmix to mono, then back to stero
[23:48:15 CEST] <alexpigment> *stereo
[23:48:16 CEST] <alexpigment> gotcha
[23:48:42 CEST] <olspookishmagus> ok thanks kepstin, alexpigment
[23:48:59 CEST] <olspookishmagus> and... sorry for breaking your converstation with my question
[23:49:11 CEST] <alexpigment> you could also use pan i think. where you just make the pan ~50% for each side
[23:49:30 CEST] <kepstin> olspookishmagus: and when encoding mp3, it will default to cbr if you just set a bitrate "-b:a 96K"
[23:49:41 CEST] <kepstin> of course, 96K mp3 is kind of awful, but that's your call ;)
[23:49:48 CEST] <olspookishmagus> what do you think on manipulating MP3 files with ffmpeg instead of avconv, lame, ... ?
[23:50:19 CEST] <kepstin> olspookishmagus: I imagine is the same as avconv, except the awesome people in this irc channel will help you ;)
[23:50:39 CEST] <kepstin> and ffmpeg uses lame to do the mp3 encoding anyways
[23:50:59 CEST] <llogan> the output from libmp3lame, which ffmpeg can use to encode to MP3, should make an exact same output as lame (assuming the same input and options are used)
[23:51:07 CEST] <olspookishmagus> oh ok
[23:51:36 CEST] <furq> i'm surprised this hasn't come up yet, but
[23:51:36 CEST] <furq> why
[23:51:48 CEST] <llogan> i was wondering as well...
[23:51:53 CEST] <olspookishmagus> kepstin: I don't have better option, my car hi-fi demands CBR on MP3s on CDs and I have bunch of youtube ripped MP3s (with youtube-dl) I want to burn
[23:51:58 CEST] <kepstin> it won't be exactly the same, since lame writes some of the headers differently, but the actual audio data will be the same
[23:52:06 CEST] <olspookishmagus> some albums are better quality but 96 kbit/s is just an example
[23:52:08 CEST] <furq> i mean if you wanted to just take one channel and upmix that to stereo, it would sort of make sense
[23:52:13 CEST] <furq> but why downmix and then upmix
[23:52:18 CEST] <kepstin> olspookishmagus: sure, but why convert them to duplicated mono channels?
[23:52:23 CEST] <llogan> i was referring to the actual audio stream, not any muxing
[23:52:43 CEST] <olspookishmagus> furq: because some info might be just on the left channel and I want it to be on both after that?
[23:52:58 CEST] <olspookishmagus> cc: kepstin
[23:54:03 CEST] <olspookishmagus> it's rare but some people like to do left to right and right to left audio tricks on music but I don't really enjoy it as I'm suffering from severe hearing loss
[23:54:13 CEST] <olspookishmagus> it's not cinema after all
[23:55:07 CEST] <olspookishmagus> llogan: what's "muxing"? do you have a dictionary of terms I can have a look at?
[23:56:09 CEST] <llogan> stuffing a muxer writes encoded packages to the output file
[23:56:28 CEST] <llogan> omit that "stuffing". somehow pasted that...
[23:57:32 CEST] <olspookishmagus> now why one would have stuffing on his clipboard? ^^
[23:57:35 CEST] <olspookishmagus> thanks llogan
[23:57:39 CEST] <olspookishmagus> or hers
[23:58:19 CEST] <kepstin> olspookishmagus: so, yeah, make a shell script loop that runs "ffmpeg -i "$INPUT" -af pan='stereo| c0 = 0.5*FL + 0.5*FR | c1 = 0.5*FL + 0.5*FR' -c:a libmp3lame -b:a 96K "$OUTPUT"
[23:58:54 CEST] <llogan> the link i pasted is still in the "clipboard". i must have typed it but instantly forgot, wrote something else, then kept typing.
[00:00:00 CEST] --- Fri Mar 31 2017