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

[burek]

[03:38:25 CEST] <Rekka> Hi! Is there a way to fix the "chunk too big" error? Here is my ffmpeg command - https://pastebin.com/vUtfaQGL ; I've already read this page - https://superuser.com/questions/1025635/ffmpeg-chunk-too-big - and tried to adjust the png file in GIMP but it still getting the same "chunk too big" error and the time it occurs keeps changing too, hence, the png file also keeps changing.
[03:52:41 CEST] <DHE> Rekka: also include the output
[03:53:09 CEST] <DHE> if it's the same as your superuser.com command, that's an error on the input. ffmpeg doesn't like a PNG part way through the sequence
[03:55:02 CEST] <Rekka> Thank you for the response @DHE. Here's the output - https://pastebin.com/bM4TQpps
[03:55:50 CEST] <Rekka> How should I fix that "ffmpeg doesn't like PNG part way through the sequence"?
[03:57:06 CEST] <cali_> Hi there.
[03:58:55 CEST] <DHE> Rekka: no idea honestly...
[04:06:31 CEST] <c3r1c3-Win> Rekka: Try sorting the directory by size and look at the smallest PNGs for a corrupt one.
[04:31:31 CEST] <tezogmix> How would the string to add look if I want to convert a 4k video file to 1080 while maintaining the aspect ratio? (3840x2160 to 1920x1080) ? The source is 16:9 at 59.940 frame rate.
[04:31:49 CEST] <tezogmix> ffmpeg -r 60000/1001 -i input.mp4 -preset veryfast -crf 20 -r 60000/1001 -c:a copy output.mp4
[04:32:07 CEST] <furq> you don't need to specify the framerate
[04:32:17 CEST] <furq> and add -vf scale=-2:1080
[04:32:18 CEST] <tezogmix> ^ I have this much. I saw in the documentation : "-vf scale=" but not sure if I would make it: "-vf scale=1920:1080" ?
[04:32:53 CEST] <tezogmix> I also saw one part mentioning "force_original_aspect_ratio" - the device limit is 1080. Oh thanks furq for replying....
[04:35:51 CEST] <tezogmix> furq, I read this post on stackexchane: https://video.stackexchange.com/questions/14907/how-to-downsample-4k-to-1080p-using-ffmpeg-while-maintaining-the-quality > the user commented "with the entire image being composed of square "tiles" as if I was magnifying 4:1."
[04:36:06 CEST] <tezogmix> In short, they entered: "ffmpeg -i orig.mp4 -vf scale=1920:1080 smaller.mp4"
[04:36:51 CEST] <tezogmix> Another responded that they had missed maybe "-crf XX -preset XXXX"
[04:37:05 CEST] <furq> lol
[04:37:29 CEST] <furq> the second to last comment on the page is the only one who noticed
[04:38:34 CEST] <furq> the guy who posted the question has a build with no libx264, so he encoded 1080p with 1-pass 200kbps mpeg4
[04:38:39 CEST] <furq> so i'm not surprised it looked like garbage
[04:38:54 CEST] <tezogmix> Oh I see. It was a dated article.
[04:39:01 CEST] <tezogmix> and older build...
[04:39:06 CEST] <furq> it's not dated, the guy just had a useless build
[04:39:17 CEST] <furq> some distro builds are like that
[04:39:27 CEST] <furq> if you have libx264 then the defaults will be more or less fine
[04:39:44 CEST] <tezogmix> My last ffmpeg update was from a few days ago.
[04:39:46 CEST] <furq> no harm in using -crf 20 though
[04:39:51 CEST] <tezogmix> for win64
[04:40:02 CEST] <furq> the zeranoe builds have everything you'd want
[04:40:48 CEST] <furq> you might want to use -vf zscale=-2:1080:f=lanczos
[04:40:48 CEST] <tezogmix> I've been playing a little with -18 and -20 for some devices and trying to see how much of a tradeoff there is between fast and veryfat presets, still a bit tough other than the obvious time difference.
[04:41:00 CEST] <furq> that'll be a bit slower but much sharper
[04:41:23 CEST] <furq> the default scale algorithm is bilinear, which is pretty soft
[04:42:26 CEST] <furq> the presets only really matter if you care about filesize
[04:42:40 CEST] <furq> -preset veryfast with a low crf will look as good as -preset veryslow with a higher crf
[04:42:48 CEST] <furq> although the exact values you'd need come down to trial and error
[04:43:39 CEST] <tezogmix> I see and good to know, these [scaling] are definitely new strings for me that you're mentioning. Are those in the official wiki docs?
[04:43:45 CEST] <furq> !filter zscale
[04:43:45 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#zscale
[04:44:01 CEST] <tezogmix> Same with attempting a downscaling of 4k to 1080.
[04:44:04 CEST] <furq> zscale is from an external lib, but the zeranoe builds include it
[04:44:12 CEST] <furq> it's generally recommended over swscale
[04:44:15 CEST] <furq> which is the builtin scaler
[04:44:17 CEST] <tezogmix> hmmm... cool.
[04:49:43 CEST] <tezogmix> I'm generally downloading the non-nightly static 64-bit windows build zip as is from : https://ffmpeg.zeranoe.com/builds/ (just realizing this might be the build you're referring to furq)
[04:50:01 CEST] <kepstin> not that there's anything really wrong with the scale filter for most use. With a 4k’1080p downscale, i'd consider using -vf scale=sws_flags=area
[04:50:59 CEST] <tezogmix> so now we have 2 suggestions :)
[04:51:27 CEST] <kepstin> well, scaling algorithms are one of those "to personal taste" kind of things
[04:54:40 CEST] <tezogmix> I can fully respect the subjectivity. My interest I suppose is what kind of output either of those strings would show. The 4k file I have is quite large and I'll try to cut a small 1-2 minute segment "ffmpeg -i input.mp4 -c copy -ss xx:xx:xx -to xx:xx:xx output.mp4" Curious what I should be looking for.
[04:57:15 CEST] <tezogmix> kepstin, does your example string "-vf scale=sws_flags=area" take longer/shorter compared to furq's "-vf zscale=-2:1080:f=lanczos" and with your string, does that portion already assume ffmpeg will convert it to 1920x1080?
[04:58:27 CEST] <kepstin> tezogmix: you still need the other options with the scale filter, so "-vf scale=w=-2:h=1080:sws_flags=area" all together
[04:59:06 CEST] <kepstin> i'd expect area to be rather faster, it's a simple average of pixel values, rather than the more complex lanczos kernel
[04:59:07 CEST] <dystopia_> what does the =area do?
[05:00:11 CEST] <tezogmix> So kepstin, something like this then? "ffmpeg -i input.mp4 -preset veryfast -crf 20 -c:a copy -vf scale=w=-2:h=1080:sws_flags=area output.mp4" Source is 3840x2160, ~8gb
[05:00:32 CEST] <kepstin> tezogmix: sure
[05:01:18 CEST] <tezogmix> I may drop the crf to 18 though like furq was mentioning rather than switching to both a fast/lower crf
[05:01:25 CEST] <dystopia_> -sws_flags spline -s 1920x1080
[05:01:30 CEST] Action: dystopia_ resizes like this
[05:05:28 CEST] <tezogmix> These are all unchartered waters for me :) My main concerns was if the output would be warped to what the source looks like. How does your resize method differ to the other suggestions from both kepstin & furq shared dystopia?
[05:05:48 CEST] <furq> it doesn't
[05:05:59 CEST] <furq> that's the same as -vf scale=1920:1080:sws_flags=spline
[05:06:23 CEST] <kepstin> tezogmix: the ffmpeg scale filters always preserve aspect ratio unless you work hard to convince them to do otherwise, so no squishing
[05:06:32 CEST] <furq> whether spline, lanczos or area is better comes down to preference
[05:06:44 CEST] <furq> and also probably the source
[05:07:07 CEST] <furq> i'd expect area to do well on an exact 2:1 downscale
[05:07:40 CEST] <furq> really the important thing is that you're not using bilinear
[05:07:42 CEST] <kepstin> tezogmix: downscaling frok 4k (3840x2160) to 1080p (1920x1080) is really simple, because it's exactly ½ the width and ½ the height. Hard to get wrong...
[05:07:50 CEST] <furq> which is the default with swscale
[05:08:00 CEST] <kepstin> furq: the default with swscale is bicubic, not bilinear?
[05:08:03 CEST] <tezogmix> Interesting comments from you all... I'm not sure what I would be visually looking for when it comes down those comparing your preferences....
[05:08:03 CEST] <furq> is it
[05:08:11 CEST] <furq> oh
[05:08:15 CEST] <furq> bilinear is the default with zscale
[05:08:17 CEST] <furq> that's stupid
[05:08:34 CEST] <furq> tezogmix: how sharp the image is
[05:08:54 CEST] <furq> bilinear will give noticeably blurry results compared to lanczos
[05:09:13 CEST] <furq> but you'd need a good eye to notice the difference between spline and lanczos
[05:09:20 CEST] <kepstin> tezogmix: just encode a section of the video (use -ss to pick a good spot, and -t to do like 10s or something), and just check the different options to see what you like
[05:09:24 CEST] <furq> yeah
[05:10:40 CEST] <furq> http://matplotlib.org/mpl_examples/images_contours_and_fields/interpolation_methods.hires.png
[05:10:44 CEST] <furq> that's upscaling but you get the idea
[05:12:08 CEST] <tezogmix> Ah I see, well that helps a lot in clarifying to use a visual sharpness as a factor to compare these 3...
[05:12:33 CEST] <tezogmix> at least for one example factor I suppose but this helps!
[05:12:39 CEST] <furq> spline, sinc and lanczos are all very similar
[05:12:54 CEST] <furq> i think swscale's spline is a bit faster
[05:13:14 CEST] <furq> it's not worth worrying too much about this really
[05:13:33 CEST] <furq> unless you pick something really bad then it's the kind of thing you'll only notice if you're looking for it
[05:13:59 CEST] <furq> obviously that doesn't stop people from spending hours writing detailed guides about picking the best scaler for mpv
[05:14:04 CEST] <furq> but those people are already dead
[05:14:07 CEST] <tezogmix> :)
[05:15:59 CEST] <tezogmix> I appreciate the huge tips and links furq, kepstin and dystopia_ - saving these for future reference!
[05:20:00 CEST] Action: james999 sniffs around for some useful links
[05:21:01 CEST] <james999> lol in that matplotlib picture the first two pictures are both labeled None
[05:21:49 CEST] <tezogmix> I can see the lanczos sharpness furq (in comparison to spline) sinc looks interesting
[05:22:49 CEST] <furq> lanczos is a variant of sinc
[05:22:59 CEST] <furq> so those will generally be almost identical
[05:23:11 CEST] <james999> they all 3 look identical to me
[05:23:26 CEST] <furq> spline is slightly more blurry in that image
[05:24:06 CEST] <tezogmix> yes spline36 is from what I'm seeing. sinc I'm doing a few double takes.
[05:24:23 CEST] <tezogmix> but seems just a tad sharper than lanczos
[05:24:31 CEST] <furq> also it's worth pointing out that you might want to use something softer if your source isn't clean
[05:24:49 CEST] <tezogmix> hmmm...
[05:24:49 CEST] <furq> really sharp resamplers will amplify any artifacts in the source
[05:25:03 CEST] <furq> if you have a nice 4k source then it's probably fine
[05:26:53 CEST] <tezogmix> Some nice features I'll need to test out with -ss + -t
[05:53:10 CEST] <Rekka> DHE: I think I solved it by removing -framerate 24 and only keeping -r 24
[06:00:04 CEST] <Rekka> DHE: Or not
[06:00:12 CEST] <Rekka> Now it's out of sync. Damn.
[06:01:50 CEST] <kepstin> Rekka: yes, using the '-r' input option will almost always cause a desync, because it completely ignores video timestamps and makes up new ones
[06:02:18 CEST] <kepstin> er, i just scrolled up to re-read your stuff
[06:02:31 CEST] <kepstin> that's not what happened at all, you're using the -r output option :)
[06:04:19 CEST] <kepstin> Rekka: yeah, you need to keep the -framerate input option (if you don't specify, the default is iirc 25, which likely isn't right).
[06:06:33 CEST] <kepstin> i have no idea how you'd do it, but you need to find which png filein your directory is corrupt and remove/replace it :/
[06:06:50 CEST] <kepstin> it should be fairly close to the frame 61563 where the encoding stopped, tho...
[06:12:56 CEST] <tezogmix> thanks again kepstin, furq & dystopia_ - leaving channel for now, have a good week!
[06:24:37 CEST] <Rekka> kepstin: Thanks for the response. But when I checked the sequence of pictures, they're not corrupt at all which is odd.
[06:25:13 CEST] <Rekka> I'm using waifu2x for it you see. But yeah, might as well re-waifu2x them again
[06:32:18 CEST] <kepstin> hmm. input frames are all the same size, right? how big are the images you're using as ffmpeg input?
[06:32:59 CEST] <kepstin> (and I dunno how well waifu2x would work on video, iirc it doesn't make any attempt to be temporally consistent, so you could get jittery edges and whatnot)
[06:53:13 CEST] <james999> is waifu2x a new kind of algorithm like sinc or lanczos?
[07:04:10 CEST] <thebombzen> james999: waifu2x is a program specifically designed to denoise and scale anime-style lineart
[07:04:34 CEST] <thebombzen> and by "denoise" I mean like removing DCT crud
[07:05:09 CEST] <thebombzen> it's not like lanczos because it's not general purpose. it's actually a machine-learning algorithm with a neural network that was trained on a bunch of data
[07:05:30 CEST] <dystopia_> you mean it watches a lot of anime :O
[07:06:12 CEST] <thebombzen> no, I mean the developers fed lots of image pairs of the form "this is the original, this is the original but with DCT crud"
[07:06:27 CEST] <dystopia_> cool
[07:06:45 CEST] <thebombzen> and via machine learning and training data it's supposed to be able to do the inverse problem of reconstructing the original image from the image with DCT cruid
[07:06:51 CEST] <thebombzen> it's the same thing with scaling
[07:07:06 CEST] <thebombzen> it's supposed to be able to reconstruct the upscaled version
[07:07:42 CEST] <thebombzen> it's better because it can assume that the original image was some sort of anime art and thus, for example, it can assume that the original image can be approximated extremely well by some form of vector graphics
[07:08:21 CEST] <thebombzen> if you try to use it on a photograph it won't work very well
[07:09:12 CEST] <thebombzen> although I have used it to take shitty-facebook-jpeg-photograph-with-black-on-white-fuzzy-text-above and remove the jpeg crud from the caption atop
[08:00:10 CEST] <Pandela> Does anyone know what "xyz12le" stands for?
[08:00:31 CEST] <thebombzen> 12le is probably 12bit little endian
[08:00:40 CEST] <thebombzen> xyz is probably the xyz colorspace, which is probably CIE 1931
[08:01:50 CEST] <Pandela> thebombzen: Oh okay, I would have never figured out the CIE 1931 part. Thanks fam
[08:02:11 CEST] <thebombzen> well CIE 1931 is usually xyY or something
[08:02:19 CEST] <thebombzen> so you should doublecheck rather than take that at face value
[08:04:13 CEST] <james999> oh yeah thanks for that link to the wikipedia on CIE 1931
[08:04:16 CEST] <james999> thebombzen
[08:04:42 CEST] <Pandela> thebombzen: I think you're right either way though haha
[08:05:49 CEST] <Pandela> xyz12le is my favorite by far when it comes to sonification and raw data. i.e pumping rawvideo with an xyz12le colorspace; through audio filters and back into ffmpeg
[08:07:43 CEST] <Pandela> Terrible quality, but heres a sample
[08:07:44 CEST] <Pandela> https://u.nya.is/gaknsm.gif
[08:09:31 CEST] <thebombzen> that doesn't sound like something I would want to use
[08:10:51 CEST] <thebombzen> and james999 I didn't link to wikipedia
[08:12:05 CEST] <james999> well perhaps not, but I did check it out anyway
[08:13:04 CEST] <james999> not a lot of books on codecs though. i did find one on SO recommended but it was a hundred bucks (!)
[08:14:17 CEST] <thebombzen> why would you want a book on codecs
[08:14:28 CEST] <thebombzen> it seems easier to just learn info on codecs in realtime
[08:14:40 CEST] <thebombzen> as in "this is the problem I want to solve, ask in #ffmpeg which codec"
[08:14:47 CEST] <thebombzen> eventually you'll learn the stuff you need
[08:14:55 CEST] <james999> sure, just thought i'd google first
[08:15:40 CEST] <james999> i'm kind of in an awkward position of getting ready to reformat my machine
[08:15:49 CEST] <james999> so i don't want to dl anymore code atm
[08:16:35 CEST] <thebombzen> "I don't want to download anymore code" seems to contradict "I'm about to wipe everything"
[08:16:44 CEST] <thebombzen> you shouldn't care about DLing more code if it's just going to disappear lol
[08:16:58 CEST] <furq> i would care about things that were going to disappear
[08:17:28 CEST] <james999> lol well i need more space and some of my stuff is corrupted i think from swapping video cards or something
[08:17:59 CEST] <james999> also i forgot password to my linux partition. T_T
[08:18:21 CEST] <Pandela> rip
[08:18:57 CEST] <Pandela> Soundsl like me, only I corrupt my shit on purpose lol
[08:19:58 CEST] <james999> Pandela: like installing from non-official repos on debian or ubuntu? i've done that
[08:20:20 CEST] <james999> The response of people in #debian was that it produces "frankendebian" - no support given!
[08:20:53 CEST] <james999> or rather, i think i was mixing packages from jesse and wheezy which is even worse
[08:21:09 CEST] <Pandela> james999: Ye, that and just running my files through a hex editor or decoding video files with incorrect codecs
[08:21:19 CEST] <thebombzen> you should just use arch
[08:21:27 CEST] <thebombzen> then you won't be surprised when shit gets corrupted
[08:21:55 CEST] <james999> hah. arch sounds scary. their wiki is so clearly and lucidly written step by step, i imagine the ways you can foobar your system must be uncountable
[08:24:12 CEST] <james999> at least my frankendebian was predictably screwed up
[08:24:41 CEST] <james999> i couldn't update packages because version mismatches everywhere after installing packages from the next version
[08:30:28 CEST] <furq> yeah don't do that
[08:30:54 CEST] <furq> just run the right version of debian to begin with
[08:31:44 CEST] <james999> well sometimes you don't know what you're doing
[08:31:59 CEST] <james999> and nobody's around. and you have some forum or website with a quick solution
[08:32:12 CEST] <james999> and then you foobar your system. %_%
[08:32:21 CEST] <furq> i hope you've learned your lesson
[08:32:23 CEST] <furq> never read forums
[08:32:54 CEST] <james999> out of date ones at least for sure
[08:33:34 CEST] <james999> and  blindly copy and pasting code in general.
[10:07:34 CEST] <SouLShocK> What's considered the best all round algorithm for downscaling 1080p to 720p? Is there even one considered best all round?
[10:07:42 CEST] <furq> no
[10:08:27 CEST] <furq> it depends on the source, how you want the output to look, how long you're happy for it to take, etc
[10:09:04 CEST] <furq> if you've got a good source, want it to look sharp and not take too long (which is pretty ordinary) then lanczos is very popular
[10:13:38 CEST] <SouLShocK> Those criteria fit my use case pretty well. Thanks
[10:25:25 CEST] <k_sze[work]> Does anybody know if it's possible to compile ffmpeg with OpenMAX IL support on Jetson TK1?
[11:08:04 CEST] <JC_Yang> how to properly cleanup stuff when using custom aviocontext?  huge amount of leaks here.
[12:28:42 CEST] <Pandela> Incorrectly decode my raw video data, S-senpai~
[12:40:41 CEST] <thebombzen> is there a way to get -vf unsharp or -vf smartblur to not change the gamma of the image?
[12:41:08 CEST] <thebombzen> I have an image which is basically blurred-black-text-on-a-white-background, and using either sharpening filter turns the background to gray
[12:43:48 CEST] <thebombzen> hm, it appears to be a bug where it doesn't intepret partial range YUV correctly
[12:44:11 CEST] <thebombzen> it works fine if you use -vf format=yuvj444p,unsharp
[12:46:00 CEST] <thebombzen> but smarblur doesn't accept yuvj444p and it'll autoinsert a format=yuv444p if you try
[13:19:41 CEST] <Mandevil> How can I tell from ffprobe output whether a clip is interlaced?
[13:19:50 CEST] <Mandevil> It doesn't seem to say.
[13:23:19 CEST] <thebombzen> things can be interlaced on a frame-by-frame basis
[13:25:11 CEST] <thebombzen> Mandevil: you can check out -vf idet
[13:25:55 CEST] <Mandevil> Let me see.
[13:27:36 CEST] <thebombzen> in particular you might care about analyze_interlaced_flag
[13:27:54 CEST] <Mandevil> I have no idea how ffprobe works to be honest.
[13:28:22 CEST] <Mandevil> I just have 1300+ clips and I need to sort progressive/interlaced apart.
[13:36:42 CEST] <Mandevil> How do I use -vf idet with ffprobe? "-vf idet" is not accepted.
[13:40:35 CEST] <furq> you don't
[13:40:37 CEST] <furq> you use it with ffmpeg
[13:44:21 CEST] <furq> http://vpaste.net/9zESv
[13:48:41 CEST] <Mandevil> furq: Hm, I was expecting some nice output like ffprobe does.
[13:50:20 CEST] <furq> ffprobe and mediainfo will only tell you if it's flagged as interlaced
[13:50:23 CEST] <furq> which is often inaccurate
[13:50:26 CEST] <Mandevil> I see.
[13:50:43 CEST] <furq> idet actually analyses the video, which is why it takes ages
[13:50:43 CEST] <Mandevil> Any idea how quickly automate the above task?
[13:50:56 CEST] <Mandevil> Short of writing actual script that will parse the output etc.?
[13:51:21 CEST] <furq> not without writing a script
[13:51:42 CEST] <Mandevil> Well, let's go write it.
[13:53:43 CEST] <Mandevil> Single frame detection: TFF:     6 BFF:     5 Progressive:   360
[13:53:45 CEST] <Mandevil> Wut?
[13:53:54 CEST] <Mandevil> There are tff/bff frames in progressive video?
[14:01:41 CEST] <furq> false positive
[14:08:12 CEST] <Mandevil> Problem is that this is extremely slow.
[14:08:19 CEST] <Mandevil> 1300 files will take a day.
[14:08:32 CEST] <furq> you can add -t 60 to only analyse the first minute
[14:08:44 CEST] <Mandevil> It's slow even on quite short files.
[14:08:52 CEST] <Mandevil> Most of the clips are sub-1 minute anyway.
[14:08:58 CEST] <furq> i'm not aware of anything more accurate really
[14:09:02 CEST] <Mandevil> Hm.
[14:09:10 CEST] <furq> or faster, rather
[14:09:38 CEST] <Mandevil> How does a player immediately know how to handle the video?
[14:09:45 CEST] <Mandevil> Or it doesn't?
[14:09:48 CEST] <furq> most players don't
[14:09:52 CEST] <Mandevil> True.
[14:09:55 CEST] <furq> players which autodetect are doing something like idet
[14:10:11 CEST] <furq> or just relying on flags
[14:10:16 CEST] <Mandevil> God damn. To hell with interlaced media.
[14:49:18 CEST] <termos> is there a best practice way to handle AVPacket's moving though a series of AVThreadMessageQueue's? not sure when I should do av_packet_unref or if av_write_frame_interleaved does this for me? it seems to, but I'm having some memory leaks
[15:00:12 CEST] <DHE> termos: av_interleaved_write_frame says "Libavformat will always take care of freeing the packet, even if this function fails."
[15:00:29 CEST] <DHE> you might need to run under valgrind or something more invasive if you're not able to track it down
[15:00:39 CEST] <termos> interesting thanks
[15:01:15 CEST] <termos> yes looking into using valgrind, but it seems to have issues with macOS 10.12 ugh :)
[15:24:36 CEST] <Pandela> Interperet my raw audio as raw video data O-Oneesan~
[15:25:56 CEST] <Pandela> https://my.mixtape.moe/xfnokr.mp3
[15:28:37 CEST] <zerodefect> Quite new to using the ffmpeg api/sdk. Having issues with understanding how to select pixel formats during media decode from file.   The media I have is DV video.
[15:29:56 CEST] <zerodefect> When I call 'avcodec_find_decoder', all is well. Except the pix_fmt   pointer within the structure is NULL
[15:30:34 CEST] <zerodefect> ...as it says in the documentation.  I'm sort of struggling where I set the pix fmt and how I determine if the format is supported?
[15:31:07 CEST] <zerodefect> Currently, I'm receiving AV_PIX_FMT_YUV422P, but I would prefer AV_PIX_FMT_YUYV422 (packed)
[15:31:45 CEST] <zerodefect> When I'm receiving, I should elaborate and indicate that I'm able to decode :)
[15:32:24 CEST] <pump> ihave a problem adding an external libx265 library because i have changed it. and now it has opencv as dependency. i have solved the dependency problem by changing x265 source cmakelists.txt. it run perfect but when i add it ffmpeg gives the same linking error. can i change configure file in ffmpeg to add dependency library on it?
[15:53:45 CEST] <zerodefect> Actually, it has me thinking. Do I need to perform a format conversion?
[16:27:29 CEST] <phishy> Curious, is there a preferred distro for fastest performance?
[16:38:59 CEST] <furq> not really
[16:39:12 CEST] <furq> certainly not for ffmpeg
[16:40:02 CEST] <kepstin> phishy: most of the performance sensitive stuff in ffmpeg and codecs is assembly code selected based on cpu support, so as long as the distro didn't break it by e.g. disabling assembly, it should be more or less the same.
[16:40:10 CEST] <phishy> I've also noticed that doing encodes on DigitalOcean SSD with a bunch of cores versus a high-powered Mac, the Mac wins out.
[16:41:59 CEST] <BtbN> Why would SSDs matter?
[16:42:02 CEST] <BtbN> encoding is CPU bound
[16:42:48 CEST] <phishy> I figured faster disks meant faster input? But yeah, overall is seems like bare-metal is faster than cloud-compute in general.
[16:42:55 CEST] <furq> i'm not surprised that an actual cpu is better than a virtual cpu
[16:43:41 CEST] <phishy> Yeah, makes sense
[16:43:58 CEST] <furq> but yeah ffmpeg does runtime cpu feature detection
[16:44:05 CEST] <furq> as does x264 and probably a bunch of other codecs
[16:44:14 CEST] <furq> so as long as you don't disable asm then it doesn't matter how you compile it
[16:44:32 CEST] <phishy> I did notice that it tried to use the 8 cores, even though top never really showed anything above 320%
[16:44:37 CEST] <furq> it also generally matters less if you're on amd64 since that guarantees at least sse2
[16:45:09 CEST] <furq> distros which still compile for i386 will have a lot of stuff which is noticeably slower than manually compiled stuff
[16:45:28 CEST] <furq> but that's not really the case with amd64 unless it's one of the rare things which benefits a lot from sse4/avx/whatever
[16:46:26 CEST] <furq> i'm sure a gentoo user will be along shortly to tell me all about their USE flags
[16:47:41 CEST] <kepstin> phishy: for DO in particular, I think you're not guaranteed full use of the cpu cores, see if your top program shows 'steal time', which is how most of the cpu you're not being allowed to use.
[16:48:01 CEST] <kepstin> (that's true of many virtual environments)
[16:48:51 CEST] <furq> digitalocean is all kvm so it should be less susceptible to oversubscription than other virtual servers
[16:49:00 CEST] <phishy> Yeah I had read some posts about arch and gentoo and people getting all excited about that. I'm also using a static build, and I was trying to run some tests to see of compiled vs static showed any noticeable difference.
[16:49:03 CEST] <furq> i still wouldn't expect to get the full performance advertised in /proc/cpuinfo though
[16:49:40 CEST] <furq> but yeah if you want 100% ricer speed then you need to use gentoo with everything compiled and optimised especially for your cpu
[16:50:07 CEST] <furq> but that rarely makes a noticeable difference, and it's a huge inconvenience compared to using binary packages
[16:50:41 CEST] <furq> it was more important back when distros were building binary packages for 386, but it's not worth it at all any more
[16:50:58 CEST] <furq> plus most "i386" distros aren't any more
[16:51:09 CEST] <furq> most of them are i686 now
[17:03:33 CEST] <kepstin> which really makes it tricky to run modern linux on my old K6 box, but that's another issue ;)
[17:05:07 CEST] <furq> iirc debian still runs on 486
[17:06:09 CEST] <furq> at least until stretch is released
[17:06:20 CEST] <furq> the K6 is still supported by jessie
[17:40:13 CEST] <celyr> furq, are you sure ? I've red that 3. kernels dropped the support to 486 or something ? Not really sure tho
[17:48:35 CEST] <priyo> hi
[17:49:46 CEST] <furq> celyr: the k6 is 586
[17:49:58 CEST] <furq> https://lists.debian.org/debian-devel-announce/2016/05/msg00001.html
[17:52:33 CEST] <priyo> I am trying to build ffmpeg 3.3 for ndk r14b but getting the following error https://pastebin.com/WVQ3yV7f
[20:18:50 CEST] <thebombzen> Pandela: you'd have the best lucky using grayscale probably
[20:19:05 CEST] <thebombzen> try intepreting pcm_s16le as gray16le
[20:19:44 CEST] <thebombzen> or even better pcm_u16le as gray16le
[20:19:48 CEST] <thebombzen> that might actually make sense
[20:32:05 CEST] <thebombzen> Pandela: this one is actually really interesting (careful, turn volume down, it maxes and clips)
[20:32:15 CEST] <thebombzen> ffmpeg -f lavfi -i testsrc,format=gbrp16le -f rawvideo - | ffplay -f u16le -ar 48000 -ac 1 -i -
[20:36:17 CEST] <Pandela> thebombzen: Ayy thats pretty rad mate. My ffmpeg doesnt let me use gbrp16le as an output pixel format though, so In used gbrp14le
[20:36:25 CEST] <Pandela> *I used
[20:36:34 CEST] <thebombzen> sounds like you should update your ffmpeg
[20:37:55 CEST] <Pandela> Apperantly :0 should probably compile from sauce instead of an apt install
[20:40:07 CEST] <thebombzen> apt? what are you on?
[20:40:49 CEST] <Pandela> Ubuntu currently
[20:41:10 CEST] <thebombzen> I figured that part out
[20:41:26 CEST] <thebombzen> I meant which version
[20:42:40 CEST] <Pandela> oh lol
[20:42:41 CEST] <Pandela> Ubuntu 16.04 LTS
[20:49:09 CEST] <Pandela> thebombzen: ffmpeg -f lavfi -i testsrc,format=pal8 -s 1280x725 -f rawvideo - | ffplay -f u8 -ar 48000 -ac 1 -i -
[20:49:28 CEST] <thebombzen> how are you generating pal8 without palettegen or paletteuse
[20:51:02 CEST] <Pandela> *shrugs* Im just using a pixel format filter. Is that normal behavior for ffmpeg?
[20:51:19 CEST] <thebombzen> I was under the impression that you couldn't without palettegen/paletteuse
[20:52:27 CEST] <Pandela> Ah okay, idunno lol. But You can use it with -pix_fmt too
[20:54:14 CEST] <Pandela> Or you could use multiple formats
[20:54:17 CEST] <Pandela> ffmpeg -f lavfi -i testsrc,format=monow -s 1280x725 -f rawvideo -pix_fmt pal8 - | ffplay -f u8 -ar 48000 -ac 1 -i -
[21:00:57 CEST] <Pandela> Welp, off to work. Squadilah!!
[21:03:46 CEST] <tmatth> this may be a tall order, but I'm having to add an anullsrc and colorsrc to my filter_complex to be able to overlay 2 videos where the 1st is shorter, otherwise both freeze when the shorter clip ends
[21:04:02 CEST] <tmatth> for reference: http://people.videolan.org/~tmatth/nonfreezing-mux/mux.sh
[21:04:18 CEST] <tmatth> and http://people.videolan.org/~tmatth/nonfreezing-mux/mux_test.txt
[21:05:01 CEST] <tmatth> normally I'd use hstack but I need to support arbitrary dimensions (e.g., Picture-in-Picture)
[22:21:07 CEST] <durandal_1707> set repeatlast to 0
[22:24:04 CEST] <Tatsh> encoding a DVD with nnedi, wondering if it's a waste
[22:24:11 CEST] <Tatsh> DVD to h264
[22:24:20 CEST] <Tatsh> waste, compared to yadif
[22:26:50 CEST] <TheWild> hello
[22:27:13 CEST] <TheWild> ffmpeg -i filename.ext -vn -acodec copy filename.???
[22:27:37 CEST] <TheWild> yeah, right. I don't know the output extension. How I can list all the formats I can convert input file to?
[22:27:42 CEST] <Tatsh> we don't know what the original file has
[22:27:48 CEST] <Tatsh> ffmpeg -i filename.ext and get the audio codec
[22:29:01 CEST] <TheWild> ah, right! It's there: Stream #0:0(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
[22:29:07 CEST] <TheWild> thanks for help.
[22:29:30 CEST] <Tatsh> if it's that then you want the matroska container right?
[22:29:45 CEST] <kepstin> tmatth: I've actually just hit a hanging bug with complex filters and overlays - what ffmpeg version are you using? can you try 3.2.x and see if it works there?
[22:30:01 CEST] <kepstin> tmatth: might be unrelated tho :)
[22:30:01 CEST] <TheWild> this time is easy, just output is filename.opus, but what if it is something I don't know extension for?
[22:30:27 CEST] <tmatth> durandal_1707: eof_pass already sets repeatlast to 0 (in vf_overlay.c)
[22:30:31 CEST] <Tatsh> there's no such thing as the exact extension for any particular codec; sometimes people use .mpeg instead of .mpg
[22:30:33 CEST] <Tatsh> and etc
[22:30:41 CEST] <Tatsh> the main thing is getting the container (if required) correct
[22:30:50 CEST] <Tatsh> the extension you set can control for that
[22:30:58 CEST] <tmatth> kepstin: i'll try with latest git, i've mostly tested 3.1.1
[22:31:05 CEST] <kepstin> TheWild: well, most codecs can be put into multiple different formats, e.g. there's no problem making a matroska (mkv) file containing opus audio only
[22:31:18 CEST] <kepstin> tmatth: ah, yeah, unrelated to my issue then :/
[22:32:05 CEST] <Tatsh> TheWild, i suggest looking on wikipedia for 'common extensions'
[22:32:14 CEST] <Tatsh> ffmpeg will more than likely support at least one of them correctly
[22:33:05 CEST] <Tatsh> also
[22:33:09 CEST] <Tatsh> ffmpeg -h muxer=<name of muxer>
[22:33:14 CEST] <Tatsh> you can use ffmpeg -muxers to get the list
[22:33:42 CEST] <Tatsh> once you do, ffmpeg -h muxer=matroska for exampl,e you get the 'Common extensions:' line
[22:34:06 CEST] <Tatsh> ffmpeg -h muxer=matroska 2>&1 | fgrep 'Common extensions'
[22:34:20 CEST] <TheWild> ffmpeg -muxers - Unrecognized option 'muxers'
[22:34:26 CEST] <TheWild> well, I might have old version.
[22:34:29 CEST] <Tatsh> you need a newer ffmpeg then
[22:34:46 CEST] <TheWild> time to update
[22:36:10 CEST] <TheWild> awesome thing
[22:36:21 CEST] <TheWild> Thank you very much Tatsh and kepstin
[22:38:56 CEST] <raboof> hi! I'm using ffmpeg on Debian and I'd like to cut a selection of a vp9 webm video
[22:39:26 CEST] <raboof> the command I'm using is 'ffmpeg -noaccurate_seek -ss 00:11:34 -t 00:19:22 -i 14_59_26.ts.webm -vcodec copy -acodec copy command_line_tools_python_mixed.mp4' and the output http://paste.debian.net/931884/ - notably 'Could not find tag for codec vp9 in stream #0, codec not currently supported in container'
[22:40:07 CEST] <raboof> the output does suggest ffmpeg was built with --enable-libvpx - what could be wrong?
[22:40:30 CEST] <kepstin> raboof: change the output filename to end in .webm instead of .mp4
[22:41:09 CEST] <raboof> lol thanks.. that was it!
[22:45:38 CEST] <TheWild> ffmpeg -i input.webm -vn -acodec output1.ogg & ffmpeg -i input.webm -vn -acodec output2.ogg
[22:45:52 CEST] <james999> fucking hell, so you can type bold and italics on irc?
[22:46:01 CEST] <james999> *what* the heck lol how do you do that
[22:46:31 CEST] <TheWild> between output1.ogg and output2.ogg there are countless differences. Why is that?
[22:46:44 CEST] <TheWild> timestamps?
[22:47:17 CEST] <raboof> james999: terminal escape sequences I presume?
[22:48:14 CEST] <TheWild> james999: https://github.com/myano/jenni/wiki/IRC-String-Formatting
[22:49:03 CEST] <raboof> oh neat
[22:50:25 CEST] <james999> I'm on mirc on windows atm though, so i don't see how to enter \x02 or whatnot
[22:50:44 CEST] <james999> maybe in a script or something. some guy just typed a single word in italics though in a sentence
[22:51:29 CEST] <james999> ^C0,3 is also looks like bash code
[22:52:49 CEST] <drv> fortune favors the bold
[22:54:13 CEST] <james999> wierd, when i hold ctrl-k a little menu pops up
[22:54:42 CEST] <james999> but it doesn't work
[22:55:22 CEST] <james999> wtf is wrong with my client!!
[22:56:07 CEST] <james999>  oh i get it now
[22:56:24 CEST] <james999> but still no italics
[22:56:35 CEST] <james999> still no italics and stuff
[22:56:53 CEST] <james999> now I have italics and stuff.
[22:57:03 CEST] <james999> looks like you were right drv!
[22:58:04 CEST] <TheWild> test
[22:59:02 CEST] <TheWild> back to my question, why my files differ?
[23:14:20 CEST] <kepstin> TheWild: when writing ogg files, the muxer choses random stream ids which are different each time it runs
[23:14:33 CEST] <kepstin> this is as recommended by the ogg specs, and helps with stuff like file concatenation
[23:16:17 CEST] <kepstin> if for some reason you need files to be the same every time, you can use "-fflags +bitexact" - but don't do that for regular encodes, the defaults are better.
[23:18:21 CEST] <excalith> hello, i have been looking for a solution about boosting quality while using ffmpeg with vidstab. i used to use profile:v high but cant make it work with vidstab. any ideas?
[23:21:33 CEST] <DHE> You can also try using -preset:v slow (or slower maybe?) for libx264 with the obvious downsides
[23:22:36 CEST] <excalith> will try now thanks, but to be sure why would profile:v  wont work anymore with vidstab?
[23:24:02 CEST] <excalith> it still looks like 480p
[23:24:09 CEST] <excalith> on 4k monitor lol
[23:24:23 CEST] <DHE> with 4k source footage?
[23:25:09 CEST] <excalith> nah, just to explain how it looks actually it is a web export
[23:29:31 CEST] <TheWild> got it. Thanks kepstin.
[23:31:27 CEST] <Tatsh> is npp a hardware specific thing or is my gentoo built copy of ffmpeg not building it in?
[23:31:32 CEST] <Tatsh> is it something in ./configure?
[23:39:54 CEST] <excalith> guys anybody managed to work ffmpeg with vidstab? we can't manage to do it. we have learned that older ffmpeg versions were buggy with vidstab, which version is stable? cant find anything on web related to his
[23:47:19 CEST] <Tatsh> doing ivtc with crop,fieldmatch,nnedi,decimate,fps=24000/1001 and only getting 28.2% speed
[23:47:24 CEST] <Tatsh> on a 480p input :/
[23:47:31 CEST] <Tatsh> 480 mixed i should say
[23:52:52 CEST] <cryptodechange> How do I do cropdetect without any rounding? (again)
[00:00:00 CEST] --- Thu May 11 2017