[Ffmpeg-devel-irc] ffmpeg.log.20160911
burek
burek021 at gmail.com
Mon Sep 12 03:05:01 EEST 2016
[00:09:20 CEST] <APNG> durandal_170, but does it support chunking?
[00:10:01 CEST] <durandal_170> APNG: chunking?
[00:10:03 CEST] <APNG> not sure if "chunking" is the right name for it
[00:10:25 CEST] <APNG> https://github.com/apngasm/apngasm/issues/55
[00:10:47 CEST] <APNG> Enverex, I'm just someone promoting APNG
[00:12:32 CEST] <ianbytchek> durandal_170: hey. been playing with paletteuse a little further. came across a problem. am i missing something obvious? https://cl.ly/1r2V273T3m0P
[00:13:22 CEST] <ianbytchek> durandal_170: seems like the palette is being written over and palettegen uses some leftovers or something like that.
[00:13:50 CEST] <ianbytchek> durandal_170: the first frame is white. second looks perfect. from third onwards there're artifacts.
[00:14:57 CEST] <durandal_170> ianbytchek: using latest ffmpeg master ?
[00:15:43 CEST] <durandal_170> APNG: apng encoder supports blend modes, that's why its slow
[00:15:50 CEST] <ianbytchek> durandal_170: nope, checked a few days ago, seemed like the same code. will try now.
[00:16:10 CEST] <APNG> durandal_170, o
[00:16:19 CEST] <APNG> durandal_170, same for the decoder?
[00:16:30 CEST] <durandal_170> it should be fixed in master
[00:16:47 CEST] <APNG> does the decoder use hardware acceleration when available?
[00:16:58 CEST] <durandal_170> APNG: yes, it should be 100% supported
[00:17:23 CEST] <APNG> then why's it so slow? D: at least when used with mpv...
[00:17:37 CEST] <durandal_170> APNG: what? PNG with hw acceleration? Nope
[00:17:46 CEST] <APNG> (granted, I was trying to open a 2GB APNG...)
[00:17:58 CEST] <APNG> durandal_170, nah, just the inter-frame/blend modes stuff
[00:18:01 CEST] <durandal_170> APNG: encoder is slow
[00:18:13 CEST] <APNG> hmm
[00:18:30 CEST] <APNG> please don't tell me mpv tries to decode each frame individually
[00:18:32 CEST] <APNG> .-.
[00:18:32 CEST] <durandal_170> APNG: 4k apng?
[00:19:08 CEST] <APNG> durandal_170, nah, 1080p, but 1 hour long
[00:19:37 CEST] <durandal_170> and its slow for decoding?
[00:20:01 CEST] <BtbN> why would you use APNG for a 1 hour 1080p video?
[00:20:02 CEST] <APNG> wait
[00:20:03 CEST] <APNG> nah it was less than 1 hour
[00:20:03 CEST] <APNG> but w/e
[00:20:03 CEST] <APNG> it was 60FPS tho
[00:20:03 CEST] <APNG> durandal_170, yeah ffmpeg can't keep up with the 60FPS I guess
[00:20:26 CEST] <APNG> BtbN, eh I was trying to get it under 2MB
[00:20:33 CEST] <BtbN> with PNG? oO
[00:20:57 CEST] <BtbN> Isn't APNG just essentialy mjpeg with pngs?
[00:21:06 CEST] <durandal_170> this is like some gif guy other day
[00:21:27 CEST] <APNG> yeah
[00:21:27 CEST] <APNG> so I could upload it to imgur
[00:21:27 CEST] <APNG> then I put a "normal" image as the first frame and anyone on firefox or safari gets rickrolled
[00:21:40 CEST] <durandal_170> APNG is just gif replacement
[00:22:27 CEST] <BtbN> it will be huge, if it doesn't have some kind of inter-frame-coding.
[00:22:30 CEST] <APNG> durandal_170, zero-length frames are great for compression, but it takes forever to bruteforce all of them...
[00:23:08 CEST] <APNG> BtbN, yeah I sometimes wish APNG had coroutines :/
[00:23:37 CEST] <BtbN> All the image-hosting sites switched to gifv anyway
[00:23:41 CEST] <BtbN> which is just mp4
[00:24:34 CEST] <APNG> and interpolation (you can use adam7, but every frame still loads in order?! why not adam7 the frame order?! uh, right, adam7 is 2D...)
[00:25:05 CEST] <APNG> (why doesn't mp4 support frame order interpolation?!)
[00:25:13 CEST] <APNG> (oh how I hate buffering :/)
[00:26:13 CEST] <APNG> here's a blogpost-ish on why everything sucks https://gist.github.com/SoniEx2/34472e8e6ba3a9e900336235f805d5a6
[00:26:43 CEST] <strongcoffee> BtbN, they 'switched' to it in that they output/re-encode to it but don't allow uploading directly to mp4/webm unfortunately
[00:26:58 CEST] <strongcoffee> well, gfycat does
[00:27:23 CEST] <BtbN> They do support APNG uploads though! So you can get your lossless quality up there
[00:27:37 CEST] <strongcoffee> absolutely :p
[00:27:50 CEST] <APNG> gfycat is a soundless video hosting site, not an image hosting site...
[00:28:01 CEST] <strongcoffee> though I don't believe Chrome even display the animated frames
[00:28:12 CEST] <strongcoffee> Firefox does
[00:28:14 CEST] <BtbN> they will convert the APNG to givf
[00:28:20 CEST] <BtbN> which is mp4 with h264
[00:28:31 CEST] <strongcoffee> they will? Wouldn't it be treated as a regular png?
[00:28:31 CEST] <BtbN> *gifv
[00:28:51 CEST] <BtbN> They excplicitly advertise APNG upload support next to PNG, so I think it's aware of the animations.
[00:29:07 CEST] <strongcoffee> hmm, TO THE TESTMOBILE
[00:31:36 CEST] <APNG> most ppl use chrome
[00:31:36 CEST] <APNG> I don't *want* the animation to show up in chrome
[00:31:36 CEST] <APNG> I wanna be able to post rickrolls on reddit and not get banned for it
[00:31:36 CEST] <APNG> (just hide it behind a harmless PNG)
[00:32:21 CEST] <strongcoffee> nope, imgur just treats it as a regular image upload
[00:33:48 CEST] <strongcoffee> though the image I uploaded was 80px wide so perhaps larger APNGs are re-encoded? Not sure. Can say they don't accept APNGs with the .apng extension.
[00:34:25 CEST] <BtbN> it needs to be larger than a certain threshold iirc
[00:45:58 CEST] <BtbN> How do I enable the apng encoder? Which library does it need? It's not zlib aparently.
[00:47:46 CEST] <APNG> Depends On : alsa-lib bzip2 fontconfig fribidi gmp gnutls gsm lame libass libavc1394 libbluray libiec61883 libmodplug libpulse libsoxr libssh libtheora libva libvdpau libwebp netcdf opencore-amr openjpeg opus schroedinger sdl speex v4l-utils xvidcore zlib libvidstab.so=1.1-64 libvorbis.so=0-64 libvorbisenc.so=2-64 libvpx.so=4-64 libx264.so=148-64 libx265.so=87-64
[00:47:50 CEST] <APNG> good question
[00:47:57 CEST] <APNG> :/
[00:49:44 CEST] <APNG> that was `pacman -Si ffmpeg` btw
[00:51:59 CEST] <c_14> BtbN: should be zlib and huffyuvencdsp
[00:52:19 CEST] <BtbN> huffyuvencdsp is just selected by it, it's not an external dependency
[00:52:25 CEST] <c_14> ye
[00:52:39 CEST] <BtbN> I am building with zlib, but I still don't get the apng encoder.
[00:52:40 CEST] <c_14> It should be there if you have zlib and don't --disable- stuff
[00:53:57 CEST] <c_14> Check config.log ?
[00:54:58 CEST] <BtbN> zlib just silently failed, even though --enable-zlib was specified...
[00:55:08 CEST] <c_14> yes
[00:55:20 CEST] <c_14> All the autodetected ones will silently fail
[00:55:34 CEST] <durandal_170> strange
[00:55:54 CEST] <BtbN> they shouldn't if they are --enabled
[00:55:57 CEST] <BtbN> but they do
[00:56:45 CEST] <durandal_170> why it fails?, zlib is standard lib
[00:57:24 CEST] <c_14> BtbN: I think it was mentioned recently on the ml that it was due to a deficiency/limitation in the configure code
[00:58:09 CEST] <BtbN> It should be moderately easy to fix. Will see if I can come up with a non-destructive way to do that
[00:58:22 CEST] <BtbN> durandal_170, because I don't have zlib development files on cygwin aparently.
[01:27:45 CEST] <deweydb_> :)
[01:27:54 CEST] <deweydb_> anyone wanna tell me what i'm doing wrong here: http://termbin.com/308n
[01:28:06 CEST] <deweydb_> 1000s of "deprecated pixel format used, make sure you did set range correctly"
[01:29:10 CEST] <c_14> Don't worry about it. That's been deprecated for years and nobody's bothered to go around and fix it.
[01:30:22 CEST] <deweydb_> can i run the command to suppress this error? i don't want my logs full of that
[01:31:50 CEST] <deweydb_> nm, i'll just skimp it out.
[01:32:05 CEST] <deweydb_> different question. how do i do these zoom pan filters without such jittery results
[01:32:06 CEST] <deweydb_> https://ffmpeg.org/ffmpeg-filters.html#Examples-92
[01:32:08 CEST] <c_14> grep is your friend
[01:32:27 CEST] <deweydb_> all of these examples result in super jittery results
[01:32:28 CEST] <c_14> No clue, never used zoompan sorry.
[01:32:36 CEST] <deweydb_> darn
[01:32:47 CEST] <deweydb_> its SOOOO much faster than dvd-slideshow's zoompan
[01:32:55 CEST] <deweydb_> just need to figure out how to make it suck less
[01:33:06 CEST] <c_14> it shouldn't jitter though (probably)
[01:34:11 CEST] <c_14> It does jitter
[01:35:08 CEST] <c_14> deweydb_: https://superuser.com/questions/1112617/ffmpeg-smooth-zoompan-with-no-jiggle ?
[01:35:39 CEST] <deweydb_> command: http://termbin.com/d0ef input: https://dl.dropboxusercontent.com/u/39497/1472750391027_SU1HXzA3NjUuSlBH.JPG output: https://dl.dropboxusercontent.com/u/39497/zoomout.mp4
[01:35:47 CEST] <deweydb_> oh, just noticed you posted link
[01:35:50 CEST] <deweydb_> reading..
[01:36:49 CEST] <deweydb_> ohhhh
[01:36:58 CEST] <deweydb_> neato! thats the same hack that dvd-slideshow uses
[01:37:01 CEST] <deweydb_> i should have thought of that
[01:39:09 CEST] <deweydb_> ( http://dvd-slideshow.sourceforge.net/wiki/FAQ_Kenburns ) -H (Beta) Render a higher-quality video. This uses the default dvd resolution and keeps all other output parameters the same, but enables some pixel-sampling methods that make the scroll effect look better at very slow velocities. This will make dvd-slideshow take up to 4x longer to process the scroll effect. Only applied when needed; the output will explain if it
[01:39:09 CEST] <deweydb_> is being used.
[01:42:13 CEST] <deweydb_> hmmmm still looks like a camera man with serious turrettes
[01:43:28 CEST] <c_14> Well, there is the deshake filter
[01:43:37 CEST] <c_14> as well as the vidstabdetect and vidstabtransform filters
[01:58:43 CEST] <deweydb_> omg
[01:58:46 CEST] <deweydb_> i'm retarded.
[01:58:56 CEST] <deweydb_> i was still viewing the output video from what i sent earlier
[01:59:04 CEST] <deweydb_> when i thought i was viewing the newly generated video
[01:59:11 CEST] Action: deweydb_ facepalms
[02:01:23 CEST] <deweydb_> O.O
[02:01:24 CEST] <deweydb_> c_14
[02:01:28 CEST] <deweydb_> you're my hero!!!
[02:01:34 CEST] <deweydb_> i've been stuck on this for....way too long.
[02:01:36 CEST] <deweydb_> thank you!
[02:02:30 CEST] <c_14> np, not that I did much
[02:05:08 CEST] <deweydb_> c_14 is there any other way i could supress "deprecated pixel format used, make sure you did set range correctly" maybe by specifying a particular pixel format in the command? its just that the ffmpeg output gets piped directed into supervisor logs, and i don't reaaaly want to write middleware to limit that one line.
[02:06:36 CEST] <c_14> You could convert from full to limited range, but that's meh
[02:07:14 CEST] <c_14> I guess it wouldn't make a big difference if you don't need full-range output for some reason
[02:07:31 CEST] <c_14> just add -pix_fmt yuv422p before zoomout.mp4 (and after .jpg)
[02:08:25 CEST] <deweydb_> worked for me.
[02:20:45 CEST] <s0126h> what is best lossy audio codec
[02:23:22 CEST] <c_14> best is (very) subjective
[02:23:28 CEST] <c_14> Probably either AAC or Opus
[02:24:29 CEST] <s0126h> everybody knows mp3 use file extension .mp3 what file extension does aac use
[02:24:43 CEST] <s0126h> why is it all over the place
[02:25:10 CEST] <deweydb_> aac is often included as part of a stream in a multi stream media container file.
[02:25:19 CEST] <s0126h> deweydb_ so can mp3
[02:25:34 CEST] <deweydb_> correct, but you don't call a video an .mp3
[02:25:47 CEST] <s0126h> right, but i am talking about aac only file
[02:26:29 CEST] <deweydb_> no clue, i guess it would be aac, but its uncommon, because for playback of audio only mp3 is more common. nobody listens to their mp3s with VLC
[02:26:31 CEST] <c_14> aac is usually either in an isobmf format (mp4) or raw aac (.aac)
[02:27:04 CEST] <s0126h> nobody listens to their mp3s with VLC : says who
[02:27:11 CEST] <deweydb_> says my grandma
[02:27:32 CEST] <s0126h> i listen to mp3 with vlc
[02:28:16 CEST] <deweydb_> well she's single, maybe you want her number?>
[02:28:42 CEST] <s0126h> ??
[02:28:51 CEST] <s0126h> no idea why you said that
[02:29:20 CEST] <s0126h> if you claim nobody listen to mp3 with vlc , then what do they use
[02:30:31 CEST] <s0126h> c_14 why is it all over the place when mp3 is always mp3
[02:31:27 CEST] <c_14> I wouldn't say it's all over the place, 99% of the time you'll find lone aac audio/music streams in isobmf with the extension .m4a
[02:31:31 CEST] <c_14> It just doesn't have to be
[02:31:59 CEST] <s0126h> c_14 lol, see it's all over the place, because earlier you said it's either aac or mp4, NOw you are saying it's .m4a
[02:32:10 CEST] <c_14> m4a is mp4
[02:32:13 CEST] <c_14> It's just a different name
[02:32:21 CEST] <s0126h> mp4 = video+audio container
[02:32:29 CEST] <s0126h> like mkv
[02:32:36 CEST] <c_14> yes
[02:32:46 CEST] <c_14> It's just a container it can hold audio-only streams just fine
[02:33:02 CEST] <s0126h> yes you can .mkv with mp3 audio only stream too
[02:33:05 CEST] <s0126h> have*
[02:33:13 CEST] <s0126h> but nobody does that
[02:33:26 CEST] <furq> what's your point
[02:33:40 CEST] <s0126h> why is mp3 always .mp3 but aac = all over the place
[02:33:47 CEST] <furq> it isn't
[02:34:08 CEST] <s0126h> furq it is, since c_14 gave 3 different answers
[02:34:18 CEST] <furq> no he didn't
[02:34:25 CEST] <furq> he gave two answers and nobody uses one of those
[02:34:41 CEST] <s0126h> huh
[02:34:47 CEST] <c_14> "nobody"
[02:34:53 CEST] Action: c_14 knows at least a handful of people that do
[02:34:54 CEST] <s0126h> [17:26] <c_14> aac is usually either in an isobmf format (mp4) or raw aac (.aac)
[02:35:05 CEST] <furq> raw aac doesn't support metadata, so that's pretty much useless
[02:35:09 CEST] <s0126h> 17:31] <c_14> I wouldn't say it's all over the place, 99% of the time you'll find lone aac audio/music streams in isobmf with the extension .m4a
[02:35:20 CEST] <furq> mp4 and m4a are the same, as was already explained
[02:35:38 CEST] <s0126h> furq does raw mp3 support metadata?
[02:36:20 CEST] <furq> it didn't before id3 became a thing
[02:36:32 CEST] <furq> you might remember id3 as being the awful garbage metadata format
[02:36:43 CEST] <furq> not that mp4's is much better
[02:36:52 CEST] <s0126h> garbage or not, does raw mp3 support metadata ?
[02:37:31 CEST] <furq> i feel like i just answered that
[02:37:38 CEST] <s0126h> okay fair enough
[02:37:47 CEST] <s0126h> and raw aac cannot support metadata at all?
[02:37:51 CEST] <furq> no
[02:37:54 CEST] <s0126h> i see
[02:38:01 CEST] <furq> if you want metadata then you mux it into a container
[02:38:05 CEST] <s0126h> furq that might be the answer to my original question then
[02:38:27 CEST] <s0126h> since mp3 is always .mp3 since it supports meta data
[02:38:44 CEST] <s0126h> and aac is all ove the place because it doesn't support meta data
[02:38:44 CEST] <furq> probably
[02:38:48 CEST] <furq> but which metadata
[02:39:02 CEST] <furq> does it have id3v1 tags, id3v2 tags, apev2 tags, or some combination of the three
[02:39:36 CEST] <s0126h> any of them
[02:40:08 CEST] <furq> also i guess technically raw mp3 doesn't support metadata because id3 isn't an actual standard
[02:40:11 CEST] <s0126h> furq it took a while, but i got my answer
[02:40:14 CEST] <furq> emphasis on "technically" there
[02:40:50 CEST] <s0126h> i wonder why they couldn't add id3v1 on raw aac
[02:41:09 CEST] <furq> because that would be shit
[02:41:17 CEST] <furq> if you want metadata then use a container
[02:41:41 CEST] <s0126h> i wonder how id3v1 can be added to mp3 without using container then
[02:41:50 CEST] <furq> id3v1 is just 128 bytes at the end of the file
[02:42:12 CEST] <s0126h> furq i understand that you find id3v1 sucks but it's better than nothing
[02:42:41 CEST] <furq> do you have some kind of allergy to mp4
[02:42:48 CEST] <s0126h> no
[02:43:17 CEST] <furq> raw streams shouldn't have metadata
[02:43:22 CEST] <s0126h> but i do like that mp3 is always .mp3 but i don't like that aac is all over the place
[02:44:24 CEST] <s0126h> furq you don't see many mp3-audio inside a .mp4/mkv container
[02:45:24 CEST] <s0126h> mp3audio only*
[02:46:21 CEST] <c_14> https://dl.c-14.de/t/then_what_is_this.mp4
[02:46:35 CEST] <furq> i mean technically that's not many
[02:46:59 CEST] <c_14> Should I start making many more?
[02:47:06 CEST] <s0126h> furq lol
[02:47:27 CEST] <furq> listen to your heart
[02:47:28 CEST] <s0126h> furq did you use ffmpeg to creaet that
[02:47:50 CEST] <furq> yes, and then i uploaded it to c_14's server and made him link it
[02:48:04 CEST] <s0126h> i see
[02:48:28 CEST] <s0126h> furq any idea what deweydb_ is talking about.. nobody listens to their mp3s with VLC
[02:48:40 CEST] <furq> yeah that's wrong
[02:48:44 CEST] <furq> he should have said "nobody with any sense"
[02:49:17 CEST] <s0126h> well if content maker uses .mp3 then you have choice
[02:49:30 CEST] <s0126h> example podcaster
[02:52:54 CEST] <s0126h> didn't know raw aac doesn't support metadata.
[02:53:58 CEST] <s0126h> flac/ape seem to support metadata
[02:57:48 CEST] <s0126h> writing application Lavf57.48.100
[02:57:59 CEST] <s0126h> why can't it say writing appliation ffmpeg
[02:59:19 CEST] <c_14> It could, but that wouldn't be useful information.
[03:00:26 CEST] <s0126h> why do you say that? and are you saying Lavf57.48.100 = useful information
[03:01:41 CEST] <c_14> Lavf refers to libavformat which is the library in ffmpeg responsible for mixing files, 57.48.100 is the major/minor/micro version of the library.
[03:03:18 CEST] <s0126h> Writing application : HandBrake 20160909221116-058fc01-master 2016091001
[03:03:18 CEST] <s0126h> Writing library : Lavf56.1.0 / Lavf56.1.0
[03:03:37 CEST] <s0126h> c_14 maybe you are right
[03:05:31 CEST] <s0126h> is mp4 container different than .mov container?
[03:06:31 CEST] <c_14> mildly, the basic format is the same thing but there are some minor differences (that usually don't matter too much)
[03:07:02 CEST] <c_14> i.e. some codecs are only registered for mov and not for mp4
[03:07:26 CEST] <s0126h> by registered? do you mean compatible?
[03:07:38 CEST] <c_14> yes
[03:08:40 CEST] <deweydb_> gah sometimes deciphering ffmpeg documentation makes my brain hurt
[03:09:02 CEST] <deweydb_> https://ffmpeg.org/ffmpeg-filters.html#Examples-92
[03:09:06 CEST] <deweydb_> x,y Last calculated x and y position from x and y expression for current input frame.
[03:09:15 CEST] <deweydb_> x and y of last output frame of previous input frame or 0 when there was not yet such frame (first input frame).
[03:09:17 CEST] <deweydb_> px,py
[03:09:28 CEST] <deweydb_> what is the difference between px and x ?
[03:09:41 CEST] <deweydb_> they both seem to indicate the previous calculated value?
[03:10:05 CEST] <deweydb_> err a better link would have been https://ffmpeg.org/ffmpeg-filters.html#zoompan
[03:10:12 CEST] <c_14> x is for the current frame, px is for the previous frame
[03:10:41 CEST] <deweydb_> hmmm ok but when was it calculated then, if it is for the current frame?
[03:10:47 CEST] <deweydb_> i'm still missing something here.
[03:11:16 CEST] <c_14> when the filter receives the frame before it begins processing it
[03:12:01 CEST] <deweydb_> ok. maybe i should loop back here. i want a way that i can zoom in on a certain x,y pixel value. based on the x,y pixels of the original image.
[03:12:17 CEST] <deweydb_> so say, zoom in on 50,102
[03:12:33 CEST] <deweydb_> the problem is if i set x=50:y=102
[03:12:55 CEST] <deweydb_> it doesn't actually do this, because 50px means something different for every step in to the zoom. because the input frame dimensions change.
[03:13:03 CEST] <deweydb_> if i understand this correctly.
[03:14:31 CEST] <c_14> calculate the position as a percentage of the original width/height and then use that percentage
[03:14:51 CEST] <c_14> Like how the examples use 50% for x and 50% for y
[03:15:48 CEST] <c_14> That, or recalculated the x,y position according to the previous x,y position taking zoom into account
[03:16:02 CEST] <deweydb_> ok thanks, i think that makes sense.
[03:18:35 CEST] <strongcoffee> you could practically build a decent video editor from ffmpeg's filters
[03:19:04 CEST] <strongcoffee> I mean, front end editor
[03:19:19 CEST] <deweydb_> heh i guess, but man, it was brutal getting crossfades working nicely.
[03:19:45 CEST] <deweydb_> i actually ended up writing a python module that wraps ffmpeg a bit. and generates the ffmpeg syntax
[03:20:28 CEST] <deweydb_> also, there are some undesirable effects from scaling (video length) with crossfading on small sections (re-encoding parts that don't need to be).
[03:20:32 CEST] <c_14> If you're going to be doing somewhat complicated stuff with filters/filtergraphs scripting it is the best bet
[03:20:41 CEST] <deweydb_> so you really gotta run ffmpeg a lot of times, and make the small clips, then concat it all
[03:21:27 CEST] <deweydb_> but i do admit ffmpeg is pretty fast. not really sure how it compares ot other video editors though, i'm sure they are also heavily optimized.
[03:43:12 CEST] <deweydb_> c_14 can you humour me for a moment and help me understand this command: zoompan=z='min(zoom+0.0015,1.5)':d=700:x='iw/2-(iw/zoom/2)':y='ih/2-(ih/zoom/2)' which is supposed to zoom in on the center of the image. First of all, i modified this command to: zoompan=z='min(zoom+0.0015,1.5)':d=700:x='($xTargetPercent)*iw-(($xTargetPercent)*iw/zoom)':y='($yTargetPercent)*ih-(($yTargetPercent)*ih/zoom)' where $xTargetPercent and
[03:43:13 CEST] <deweydb_> $yTargetPercent are injected by my script.
[03:43:42 CEST] <deweydb_> if we look at the original command though, i find it very confusing, specifically this part: x='iw/2-(iw/zoom/2)':y='ih/2-(ih/zoom/2)'
[03:44:27 CEST] <deweydb_> if i am reading this correctly, say the original image is 640x480, on the first frame we set x = 640/2 - 640/1/2
[03:44:31 CEST] <deweydb_> which would be 0 ?
[03:44:52 CEST] <deweydb_> shouldn't it be 320?
[03:45:09 CEST] <deweydb_> where does x start from, i mean, its a frame of the video, so is it the upper left, the center? bottom right?
[03:45:44 CEST] <deweydb_> when i run my modified version of this, using the script, it 'sort of' zooms in on the target, but its off a bit.
[03:50:28 CEST] <deweydb_> command: http://termbin.com/cvus input: https://dl.dropboxusercontent.com/u/39497/1472750391027_SU1HXzA3NjUuSlBH.JPG output: zoomout.mp4 explain of command: i'm targeting the date stamp in the image, as seen here: https://dl.dropboxusercontent.com/u/39497/coordinates.png
[03:50:44 CEST] <deweydb_> ooops, output: https://dl.dropboxusercontent.com/u/39497/zoomout.mp4
[03:51:07 CEST] <deweydb_> so according to photoshop, the center of that datestamp is at: 546,412
[03:51:15 CEST] <deweydb_> the image is 640x480
[03:51:49 CEST] <deweydb_> so i used: 546/640 = 0.853125 for $xTargetPercent
[03:52:37 CEST] <deweydb_> and 410/480 = 0.85416666
[03:53:25 CEST] <deweydb_> but in the video, it doesn't really zoom in on that datestamp, it leaves a large area beneath it unseen, while having a bigger focus on the area above it (i.e. not centred around it)
[03:56:23 CEST] <deweydb_> https://dl.dropboxusercontent.com/u/39497/expected%20result%20vs%20actual%20result.png
[03:58:52 CEST] <deweydb_> OK RUBBER DUCK
[03:59:00 CEST] <deweydb_> i think i just got it by explaining it to myself
[03:59:01 CEST] <deweydb_> lol
[08:06:11 CEST] <strongcoffee> deweydb_, this channel is sometimes good for that ;)
[09:46:06 CEST] <wallbroken_> hi
[09:46:12 CEST] <wallbroken_> do you know webM?
[09:58:31 CEST] <relaxed> wallbroken_: https://trac.ffmpeg.org/wiki/Encode/VP9
[10:02:17 CEST] <wallbroken_> relaxed, do you know youtube-dl?
[10:15:36 CEST] <strongcoffee> wallbroken_, you could ask the question then see if anyone knows
[11:39:49 CEST] <wallbroken_> unable to find point GetNumaNodeProcessorMaskEx in KERNEL32.dll
[11:39:51 CEST] <wallbroken_> what?
[14:29:21 CEST] <JEEB> Lokie: usually people grab win64 binaries from http://ffmpeg.zeranoe.com/builds/
[14:29:32 CEST] <Lokie> yea I followed the link from the main site
[14:29:39 CEST] <JEEB> I build my own, but that's just because I have everything ready for it.
[14:30:01 CEST] <JEEB> that should have zscale available as well, which is a much higher quality scaler than the default swscale
[14:30:10 CEST] <Lokie> I would have to ask: is your own "better" or includes more stuff than zeranoes? if then would you mind sharing it?
[14:30:25 CEST] <Lokie> if you have a static build
[14:30:36 CEST] <JEEB> no, I build with much less stuff and I don't distro them usually :P
[14:30:43 CEST] <furq> the main reason for people to build their own is to add non-free components
[14:30:46 CEST] <furq> which means they're not distributable
[14:30:55 CEST] <JEEB> I actually don't enable fdk-aac so it's not that
[14:31:08 CEST] <Lokie> ok :)
[14:31:13 CEST] <JEEB> it's just that I've gotten used to doing compiles and thus I know exactly what I'm getting
[14:31:22 CEST] <Lokie> fair enough!
[14:32:11 CEST] <JEEB> also was there any reason you were forcing the thread count @ https://p.lokie.eu/h1Ep7QGkUCIr.txt
[14:32:24 CEST] <JEEB> by default libx264 picks amount of cores * 3 / 2
[14:32:38 CEST] <Lokie> ah didn't know
[14:32:41 CEST] <Lokie> I use a hexacore
[14:32:49 CEST] <Lokie> so -5 seemed a good idea
[14:33:01 CEST] <Lokie> you mean 2/3 ?
[14:33:21 CEST] <JEEB> ((num of cores) * 3) / 2
[14:33:23 CEST] <DHE> there's two sets of threads x264 uses, at least. there's the main encoding threads, and there are some lookahead threads. (lookahead can also be offloaded to a GPU or disabled)
[14:33:40 CEST] <JEEB> so more or less 1.5 times the core count
[14:33:53 CEST] <JEEB> in general you shouldn't have to care about it
[14:33:55 CEST] <Lokie> hm
[14:33:59 CEST] <Lokie> ok
[14:34:00 CEST] <furq> Lokie: 9 threads with 6 cores, or 18 with HT
[14:34:00 CEST] <Lokie> dled
[14:34:07 CEST] <furq> but yeah trust it to do its thing
[14:34:52 CEST] <DHE> unless you have specific CPU usage/availability needs, go with the defaults. and even then there are alternatives like affinity
[14:35:19 CEST] <JEEB> ffmpeg -i input.mov -c:v libx264 -crf 26 -preset slow -level 41 -maxrate NUMBERk -bufsize NUMBERk -vf zscale=PARAMETERS (see documentation) -c:a aac -b:a NUMBERk out.mp4
[14:35:37 CEST] <JEEB> zscale should take similar parameters to scale, but do a better job
[14:35:43 CEST] <furq> is there any value to setting -level
[14:35:45 CEST] <JEEB> and generally for internet video you want to set maxrate and bufsize
[14:35:52 CEST] <JEEB> furq: yes, nowadays it limits the amount of refs
[14:36:00 CEST] <DHE> furq: in theory it shoudl scale down the refs or warn if you overshoot the limits
[14:36:19 CEST] <JEEB> yeah, it does the ref limitation nowadays since someone complained
[14:36:32 CEST] <JEEB> and yes, libx264 puts out a warning message if your MB rate etc go over it
[14:36:47 CEST] <JEEB> not maxrate/bufsize because that's completely separate in libx264, though
[14:36:51 CEST] <furq> oh that's nice
[14:36:55 CEST] <DHE> the level is (mainly) a function of resolution, framerate, and number of refs. the last is the only configurable x264 option
[14:37:13 CEST] <furq> well yeah i know it ignores the first two
[14:37:29 CEST] <JEEB> it doesn't ignore them, it's just a thing that comes from your input :P
[14:37:55 CEST] <JEEB> and there is actually the maxrate/bufsize stuff as well, but libx264 was designed not to care about those unless you specifically say it to limit itself to some maxrate/bufsize
[14:38:10 CEST] <furq> it doesn't make any attempt to correct them
[14:38:18 CEST] <furq> which is good because that would almost certainly be worse
[14:38:21 CEST] <Lokie> D:\Encoding\auto\test>..\..\enc\ffmpeg\bin\ffmpeg.exe -i FHD0168.MOV -c:v libx264 -vf zscale=Key=value -c:a aac -b:a 128 FHD0168-1.mp4
[14:38:22 CEST] <JEEB> why would it, it's just an encoder
[14:38:24 CEST] <Lokie> does that look sane?
[14:38:36 CEST] <Lokie> ofc I have yet to google zscale settigns
[14:38:39 CEST] <JEEB> Lokie: you need to add the k to the -b:a
[14:38:46 CEST] <JEEB> otherwise it's bits per second
[14:38:51 CEST] <JEEB> 128k is 128 kilobits
[14:38:53 CEST] <Lokie> makes sense
[14:39:07 CEST] <JEEB> zscale docs are at https://www.ffmpeg.org/ffmpeg-all.html#zscale
[14:39:17 CEST] <JEEB> but since the options should be the same as with scale mostly
[14:39:35 CEST] <DHE> is zscale CPU heavy compared to sws?
[14:39:50 CEST] <Lokie> yea I am already reading it
[14:39:58 CEST] <JEEB> it surely doesn't cut as many corners but it's still very fast
[14:40:03 CEST] <Lokie> it would be nice if it had 1-2 examples per setting
[14:40:51 CEST] <Lokie> -vf zscale=width=720
[14:40:52 CEST] <JEEB> I think the zimg author did some swscale/zimg benchmarks where zimg came out faster while doing TheRightThing, but I'm not sure if the zscale filter replicates that or if those numbers are fully correct
[14:41:08 CEST] <Lokie> I am not sure how I should put height=-1
[14:41:13 CEST] <Lokie> or if it's needed
[14:41:23 CEST] <Lokie> well
[14:41:28 CEST] <Lokie> the other way around
[14:41:35 CEST] <furq> DHE: it's marginally slower in my experience but not enough to care about
[14:41:47 CEST] <JEEB> yeah, the correctness matters more IMHO
[14:41:51 CEST] <furq> ^
[14:42:01 CEST] <JEEB> also you need format=yuv420p after the zscale since you're doing video for internets
[14:42:15 CEST] <JEEB> so -vf "zscale=STUFFF,format=yuv420p"
[14:43:28 CEST] <furq> Lokie: you probably want -vf zscale=720:-2 or maybe zscale=720:-2:f=spline16
[14:43:37 CEST] <furq> it's unlikely you'll ever need to use any of the other options
[14:43:47 CEST] <JEEB> yeah, unless the input video lacks metadata
[14:43:56 CEST] <JEEB> but that's worth a try basically
[14:44:21 CEST] <Lokie> if you don't mind the order is width:height right?
[14:44:33 CEST] <furq> the order is as specified in the docs
[14:44:42 CEST] <Lokie> and -2? I read -1 means calculate from the other value while respecting aspect ratio
[14:44:55 CEST] <furq> -2 does the same thing but gives you a mod2 value
[14:45:13 CEST] <DHE> x264 will refuse a resolution that's an odd number
[14:45:45 CEST] <JEEB> with 4:2:0 both width and height have to be modulo 2
[14:46:13 CEST] <Lokie> so since I am resizing to 720p from 1080p: D:\Encoding\auto\test>..\..\enc\ffmpeg\bin\ffmpeg.exe -i FHD0168.MOV -c:v libx264 -vf zscale=-2:720:f=spline1 -c:a aac -b:a 128k FHD0168-1.mp4
[14:46:14 CEST] <JEEB> 4:2:2 gives you leeway in height, and 4:4:4 removes the requirement altogether, but those unfortunately aren't usually an alternative :)
[14:46:23 CEST] <furq> if you want 720p then that's right
[14:46:47 CEST] <JEEB> Lokie: also don't forget the format (and you'll probably need to add quotes around the filter chain)
[14:46:47 CEST] <furq> except you forgot a 6
[14:46:49 CEST] <Lokie> and I should add the yuv flag for better support on browsing
[14:47:09 CEST] <Lokie> oh
[14:47:18 CEST] <JEEB> it's a separate "filter" that comes after zscale which is a way to dictate to the filter that you want that format as output
[14:47:28 CEST] <JEEB> which is kind of weird but that's how it seems to work
[14:47:58 CEST] <Lokie> when you say don't forget the format?
[14:48:10 CEST] <furq> -vf zscale=-2:720:f=spline16,format=yuv420p
[14:48:16 CEST] <Lokie> ah
[14:48:27 CEST] <JEEB> and as I noted, you probably will nee to quote that string of things :)
[14:48:27 CEST] <furq> you probably won't need quotes around that but never say never
[14:48:28 CEST] <Lokie> should I try without the format=yuv420p first?
[14:48:33 CEST] <JEEB> no
[14:48:50 CEST] <JEEB> better make sure you get the format you want instead of guessing
[14:48:56 CEST] <furq> yeah if the input is yuv420p then it'll make no difference
[14:49:01 CEST] <furq> or 4:2:0 rather
[14:50:55 CEST] <Lokie> source is: https://p.lokie.eu/K2XGXVXVxrrs.txt
[14:51:24 CEST] <Lokie> so not needed
[14:52:20 CEST] <JEEB> well, that format doesn't do anything if the format is already that
[14:53:06 CEST] <Lokie> hm sec something funky went with the static build dl
[14:55:12 CEST] <Lokie> no quotes were needed
[14:55:55 CEST] <Lokie> weird there is no progress bar?
[14:56:21 CEST] <JEEB> there should just be a status thing that shows how far you are in a stream
[14:56:29 CEST] <JEEB> the length of input is not necessarily known
[14:56:46 CEST] <Lokie> https://i.lokie.eu/t/FnBepclTMYBw.png
[14:57:04 CEST] <Lokie> outside those errors I don't see something
[14:57:09 CEST] <furq> the bottom line
[14:57:55 CEST] <Lokie> ah the time keeps increasing almost linearly
[14:58:01 CEST] <Lokie> so I thought it is time running :p
[14:59:57 CEST] <Lokie> and I can normally use -preset slow -crf 22 to control "quality"
[15:00:29 CEST] <DHE> ... oh goddammit, zscale doesn't build on centos6
[15:00:47 CEST] <JEEB> I thought RHEL/CentOS had packages for newer toolchains?
[15:01:18 CEST] <JEEB> developer packages or whatever
[15:03:11 CEST] <DHE> not just gcc, it's also autoconf
[15:03:38 CEST] <relaxed> my builds have zscale :)
[15:03:59 CEST] <DHE> I have custom mods to ffmpeg
[15:04:56 CEST] <JEEB> that reminds me I will have to re-push my patches to the mailing list. last time it ended with a minor test having to have its hash changed, at which point I didn't have time for that
[15:51:54 CEST] <archibald__> guys, can packet pts have a negative value and what does it mean when packet has negative Dts value?
[15:55:22 CEST] <JEEB> negative pts usually means that the sample is supposed to be not output
[15:55:48 CEST] <JEEB> like encoder delay with audio formats
[16:00:41 CEST] <archibald__> hmm, what about dts, i have files with pts/dts like this:
[16:00:47 CEST] <archibald__> p: 2 3 4 5 6 ...
[16:00:51 CEST] <archibald__> d: -2 -1 0 1 2 ...
[16:32:14 CEST] <cuba_> 7
[16:42:31 CEST] <Asaf> Hi, trying to play an mp3 in a browser (using web api) but it's very choppy, same way with mp2 worked great, so guess the problem is with the bit reservoir. is there a way to disable it?
[16:43:18 CEST] <Asaf> the doc says : reservoir Enable use of bit reservoir when set to 1. Default value is 1. LAME has this enabled by default, but can be overridden by use --nores option.
[16:44:14 CEST] <Asaf> but "--nores" doesn't exists. can set "-libmp3lame -reservoir 0", but it doesn't seems to do anything...
[17:00:28 CEST] <Asaf> hi that's my command : http://pastebin.com/g7uR17yK
[17:01:44 CEST] <Asaf> it might be working even, as if using different option it will fail, this command works, but there is a small chop every chunk played
[17:02:29 CEST] <Asaf> if concating the chunks and only then decoding those i get a smooth audio, that's why i think it's the bit reservoir....
[17:02:37 CEST] <Asaf> the command itself as pasted do work
[17:24:04 CEST] <Weasel[DK]> I grab'ed some videos from an old DV-cam into DV files. Now i want to add some metadata like date of recording and such. But until now i failed. Last i tried the ffmpeg -i in.dv -metadata creation_time 2006-01-29 out.dv
[17:24:42 CEST] <Weasel[DK]> running ffprobe on the output file does not show the expected metadata..
[17:35:42 CEST] <Lokie> really silly question but I prefer to know for sure. Changing the priority on the process of ffmpeg to lower or of another program to higher can't affect the encoding right?
[18:12:05 CEST] <Chloe> Lokie: I dont think it should affect quality
[21:40:01 CEST] <limbo_> Is there any way to use ffmpeg to combine multiple inputs into one output, or to cut multiple sections from a video into a single output.
[21:40:32 CEST] <limbo_> e.g. encoding seconds 3-7 and 22-25 into a 7 second output.
[21:43:04 CEST] <furq> limbo_: https://ffmpeg.org/ffmpeg-filters.html#trim and https://ffmpeg.org/ffmpeg-filters.html#atrim
[21:48:49 CEST] <furq> limbo_: http://vpaste.net/Uceyi
[21:48:51 CEST] <furq> something like that
[21:48:57 CEST] <limbo_> so, I'd have to trim to the outer bounds of the section I want and then use atrim to remove the internal parts?
[21:49:27 CEST] <limbo_> ok. Got it.
[21:49:47 CEST] <limbo_> what about combining multiple sources?
[21:50:02 CEST] <furq> how do you mean
[21:52:20 CEST] <limbo_> If I have two videos e.g. vid1.mp4 vid2.webm, is it possible to cocatinate them together using ffmpeg?
[21:52:46 CEST] <furq> use the concat filter
[21:53:05 CEST] <furq> you'll need to ensure that they're the same resolution/framerate etc
[21:55:50 CEST] <limbo_> If they are not, is it still possible?
[21:56:51 CEST] <furq> well you're reencoding so they can be whatever framerate/resolution you want
[22:29:29 CEST] <kepstin> the output video will have to have have the same resolution throughout, so you might have to resize/pad/crop the videos while concatenating them.
[22:40:11 CEST] <TwinTailed> Hi. Why do I get an av_send_frame() error only when the packet is of H264 codec? If it was another codec (aac for example, or AVI), packet is written successfully. Here is my code: http://pastebin.com/W2C19xZK
[22:41:19 CEST] <limbo_> kepstin: I know. Does ffmpeg chose one of the input resolutions/framerates predictably, or will I have to do it explicitly? (Or add a rezise filter to each file)
[22:42:41 CEST] <furq> limbo_: the last one
[00:00:00 CEST] --- Mon Sep 12 2016
More information about the Ffmpeg-devel-irc
mailing list