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

[burek]

[00:13:58 CEST] <alexpigment> Is VP8 just really slow, or do you need to specify a number of threads to optimize the speed?
[00:14:18 CEST] <sfan5> both
[00:14:48 CEST] <alexpigment> well, is there a way to safely specify a number of threads that fail or perform poorly on a system with less cores?
[00:14:50 CEST] <atomnuker> won't help, libvpx is single threaded unless you tile (and reduce quality)
[00:14:56 CEST] <alexpigment> ah
[00:15:01 CEST] <alexpigment> well, that solves that :)
[00:15:30 CEST] <alexpigment> thanks for the info
[00:18:03 CEST] <Asuran> try -threads 16
[00:18:16 CEST] <Asuran> but after you use -c:v libvpx or what it is
[00:19:37 CEST] <Asuran> and dont use more then -threads 16
[00:22:35 CEST] <TD-Linux> alexpigment, also you can set the encoder speed with -speed
[00:22:39 CEST] <TD-Linux> higher number = faster
[00:23:33 CEST] <alexpigment> if I use -threads 16, is there a downside to using that on, say, a dual-core processor
[00:23:46 CEST] <alexpigment> also, if I use -speed, does it reduce the quality?
[00:24:06 CEST] <alexpigment> i mean I assume it does in the same way the -preset options work for x264
[00:33:24 CEST] <furq> i don't think libvpx supports any multithreading for vp8
[00:33:34 CEST] <furq> tile-columns and row-mt are vp9 only
[00:34:11 CEST] <alexpigment> ok, i'll put it on my list tomorrow to look into this further
[00:34:15 CEST] <alexpigment> thanks for the suggestions and info guys
[01:01:01 CEST] <Chimaera> good evening - I have an issue compiling ffmpeg that I was hoping someone could help with
[01:04:13 CEST] <Chimaera> I'm compiling on raspbian jessie, based on this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu mainly in order to add x.265 and libfdk_aac support
[01:04:57 CEST] <Chimaera> the libraries compile fine, with the exception of needing to build x.265 for arm-linux instead of linux
[01:05:59 CEST] <Chimaera> the issue comes with running the configure script for ffmpeg itself: I get "ERROR: x265 not found using pkg-config" and a look in ffbuild/config.log shows "In file included from /tmp/ffconf.QcxrG88q/test.c:1:0:
[01:06:03 CEST] <Chimaera> /home/pi/ffmpeg_build/include/x265.h:29:18: fatal error: cstdio: No such file or directory #include <cstdio>
[01:08:06 CEST] <furq> there is really no reason to have libx265 on a raspberry pi
[01:09:47 CEST] <Chimaera> furq: I have a use-case that needs it
[01:10:20 CEST] <iive> encoding is slow on PC, on arm it would be much slower.
[01:10:32 CEST] <iive> you don't need libx265 for decoding.
[01:12:29 CEST] <iive> on the problem...  if you are compiling on rpi itself, why do you need to specify cross-compile targets?
[01:13:00 CEST] <iive> one would expect that cstdio would be in a system path
[01:17:00 CEST] <Chimaera> I'm transcoding and if it's slow that's fine
[01:17:23 CEST] <Chimaera> on the compile I'm just working with the default scripts that come with the source packages
[01:18:04 CEST] <iive> sorry i'm of no use.
[01:18:32 CEST] <iive> maybe somebody will know. keep around.
[01:18:40 CEST] <Chimaera> that's fine :) thanks for responding anyway
[01:18:40 CEST] <Chimaera> *nod*
[01:18:56 CEST] <iive> you are most likely missing some -I/usr/*/include/
[01:19:26 CEST] <Chimaera> I got this to work a while back on a first gen pi but my notes on that are somewhat cryptic at this point
[01:19:36 CEST] <iive> see if compilation of x265 have produced pkg-config file, it's probably libx265.pc
[01:20:14 CEST] <iive> it should have the proper includes.
[01:21:18 CEST] <iive> x265.pc is the one on my system
[01:22:03 CEST] <Chimaera> yeah, all the compiled files are there for x265
[01:22:36 CEST] <iive> you can copy the x265.pc file manually to a location where ffmpeg configure could find it.
[01:22:46 CEST] <c_14> just export PKG_CONFIG_PATH
[01:23:02 CEST] <c_14> are you building statically?
[01:23:11 CEST] <c_14> then you'll need --extra-pkg-config-flags=--static or somethnig
[01:23:35 CEST] <c_14> check if the output of pkg-config --libs --cflags x265 seems sane
[01:29:09 CEST] <Chimaera> c_14: that's all there in the configure invocation for ffmpeg
[01:29:41 CEST] <c_14> no clue, can you upload the first and last 50 lines of your config.log to a pastebin service?
[01:39:08 CEST] <Chimaera> c_14: http://skynet.ie/~dobrien/ffmpeg_config.txt
[01:42:27 CEST] <c_14> how did you install x265?
[01:47:35 CEST] <Chimaera> per instructions here: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[01:48:00 CEST] <Chimaera> with the exception that I built from the x265/build/arm-linux
[01:53:42 CEST] <c_14> that should work
[01:53:50 CEST] <c_14> no clue, sorry
[01:54:20 CEST] <Chimaera> ok, thanks for looking :)
[02:15:30 CEST] <utack> can i interest someone in a video where ffmpeg color conversion seems to go wrong? or is that expected, when not using zscale and to be ignore?
[02:16:23 CEST] <utack> oh well i better not do that...might even be the play messing it up. not sure
[02:16:37 CEST] <Asuran> which codec?
[02:17:18 CEST] <Asuran> Chimaera, get archlinux or some repo with more updated ffmpeg for ubuntu
[02:18:16 CEST] <utack> left=source, right=after ffmpeg scaling and  libx264 encoding https://i.imgur.com/7nZdrjm.jpg
[02:18:48 CEST] <utack> i am not even sure, the colors on the left look wrong actually, maybe it is the play and ffmpeg is doing the right thing
[02:18:55 CEST] <utack> player
[02:19:09 CEST] <Asuran> Chimaera, https://bitbucket.org/multicoreware/x265/issues/125/x265-not-found-using-pkg-config if i dont get it wrong static compile fixes it? did you static compiled it?
[02:19:43 CEST] <Asuran> i read recently a warning about yuv color conversion to blame to x265
[02:19:49 CEST] <Asuran> maybe its same, try other codec
[02:22:00 CEST] <furq> utack: if you're not using zscale, i think you need the colorspace filter for correct bt.2020 to bt.709 conversion
[02:22:14 CEST] <utack> oh okay. manually add it in there?
[02:22:19 CEST] <utack> thanks, i will look into it
[02:23:01 CEST] <furq> or you could just leave it as bt.2020
[02:23:09 CEST] <furq> iirc -vf colorspace=bt2020 will do that
[02:24:35 CEST] <utack> pretty weird choice for the input material i must say, but i guess i can leave it yes
[02:24:49 CEST] <utack> colorspace filter worked
[02:24:51 CEST] <utack> thanks
[02:25:31 CEST] <utack> especially since phone uses 709 for non 4k material
[02:25:41 CEST] <furq> it's weird that it's using that for 8-bit yuv
[02:26:00 CEST] <furq> i don't know shit about colourspaces but i thought you needed 10bpp for bt.2020
[02:26:12 CEST] <furq> or 10bps rather
[02:34:01 CEST] <utack> huh, i just checked what the players on the phone think of it. https://i.imgur.com/Nc28qtV.jpg
[02:34:14 CEST] <utack> if the screenshot can be trusted, not the same thing as mpv
[02:35:32 CEST] <utack> mpv on phone however shows the red'ish tint again
[09:26:00 CEST] <luc4> Hello! Anyone who knows if ffmpeg supports armv8 cortex-a53 build?
[15:12:39 CEST] <JC_Yang> I need some suggestions on int64 to AVRational conversion, is there any supported methods to do so?
[15:59:22 CEST] <DHE> JC_Yang: it's just a struct with 2 fields. although I'd be worried since they're not 64-bit fields.
[15:59:27 CEST] <DHE> JC_Yang: what are you doing exactly?
[16:01:27 CEST] <alexpigment> when encoding in VP8, does anyone know if there's a way to make -threads automatically set to the number of real CPUs minus 1?
[16:01:51 CEST] <JEEB> yes, if you add a patch for that
[16:01:56 CEST] <JC_Yang> my brain was frozen, I've found my way out, thank u. What I need is to multiply a pts to a time base, I do it with pts * timebase.num / timebase.den now... it's simple
[16:02:07 CEST] <JEEB> and yea IIRC the default value libavcodec passes there will just mean "1 thread" in libvpx
[16:02:22 CEST] <JEEB> kind of surprising (or maybe not) that no-one fixed that ever :P
[16:02:25 CEST] <alexpigment> yeah, it definitely only uses 1 thread by default
[16:02:39 CEST] <alexpigment> but if you set threads too high, the system stops responding
[16:02:44 CEST] <JEEB> libavcodec/libvpx*.c I guess :P
[16:02:53 CEST] <alexpigment> i was hoping there was an easy way to set it automatically
[16:03:01 CEST] <alexpigment> anyway, i'll look into it. thanks JEEB
[16:03:02 CEST] <JEEB> yes, patch the libvpx wrapper :D
[16:03:40 CEST] <alexpigment> <-- not a developer, but I'll see what I can do. perhaps I can look at x264 and see what -threads 0 does and try to simulate that
[16:03:50 CEST] <alexpigment> *with -threads 0, i mean
[16:04:04 CEST] <alexpigment> glah, too early to type or read. need coffee :)
[16:04:05 CEST] <JEEB> I think libx264's auto value matches libavcodec's or so
[16:04:12 CEST] <JEEB> so "it just works"
[16:04:19 CEST] <JEEB> I think default was either 0 or -1
[16:04:33 CEST] <JEEB> libvpx just happens to interpret the value otherwise than all the other encoders :D
[16:04:49 CEST] <alexpigment> that sounds about right
[16:06:11 CEST] <JEEB> libavcodec/libvpxenc.c it seems
[16:06:35 CEST] <JEEB> you can see what the wrappper passes through if you enable -v debug it seems
[16:06:53 CEST] <JEEB> as I can see logging like g_threads: xxxx
[16:06:55 CEST] <JC_Yang> I just encountered weird link errors, tons of undefined references when link to ffmpeg static libs, I simply can't spot the bug, any suggestions?
[16:07:19 CEST] <alexpigment> yeah, i'm seeing cfg->g_threads,
[16:07:25 CEST] <alexpigment> i have no idea what to do with it though
[16:07:47 CEST] <JEEB> wait why is it setting the threads after dump_enc_cfg
[16:07:48 CEST] <JEEB> ?!
[16:07:56 CEST] <JEEB> enccfg.g_threads      = avctx->thread_count;
[16:08:04 CEST] <JEEB> this is *after* dump_enc_cfg(avctx, &enccfg);
[16:08:09 CEST] <alexpigment> oh yeah, i'm seeing that now
[16:08:21 CEST] <JEEB> and the thing logging things is the dump_enc_cfg
[16:08:28 CEST] Action: JEEB scratches his head
[16:08:43 CEST] <JEEB> it does the thing, but yunno :D
[16:08:48 CEST] <JEEB> you logged the parameters
[16:08:53 CEST] <JEEB> and *then* you set things?
[16:08:54 CEST] <JEEB> :D
[16:09:07 CEST] <alexpigment> to be fair, -threads [int] does do something
[16:09:11 CEST] <JEEB> yes
[16:09:16 CEST] <alexpigment> so it's not useless if that's what you're implying
[16:09:19 CEST] <JEEB> but it probably wouldn't modify the logging
[16:09:34 CEST] <JEEB> no I just see the dump_enc_cfg being called before the values are set
[16:09:43 CEST] <JEEB> thus you do not set the threads in the -v debug output
[16:09:44 CEST] <JEEB> I think
[16:09:48 CEST] <JEEB> unless some magick is happening
[16:12:36 CEST] <JEEB> I wonder if libavcodec or libavutils already has code to duplicate the auto thread stuff
[16:12:54 CEST] <JEEB> or if libvpx has its own value for "auto"
[16:12:57 CEST] <alexpigment> well, I know that -threads 0 does nothing to improve speed
[16:13:03 CEST] <alexpigment> in the command line
[16:13:07 CEST] <JEEB> yes, because zero isn't auto in libvpx
[16:13:16 CEST] <alexpigment> you think -1 might be auto
[16:13:17 CEST] <alexpigment> ?
[16:13:33 CEST] <alexpigment> nope
[16:13:56 CEST] <JEEB> no idea
[16:14:02 CEST] <JEEB> you'd have to ask #vp8 or so
[16:14:10 CEST] <alexpigment> k
[16:14:10 CEST] <JEEB> which IIRC is the libvpx dev channel
[16:14:25 CEST] <alexpigment> i'll go and bug those guys then :)
[16:14:58 CEST] <holgersson> Hi! Do you know what a typical video codec for .avi files for mobile DVD players is? I tried mpeg2 and 4 and h264 so far, but all players complain they cant play the video.
[16:15:03 CEST] <JEEB> I see some code for counting a thread count internally in pthread_frame.c
[16:15:48 CEST] <JEEB> holgersson: there's no standard for that. you probably have more luck with creating mp4 files with H.264 and AAC (level 3, main profile - LC AAC) and testing that out
[16:16:05 CEST] <JEEB> -level 3.0 -profile:v main I think with -libx264
[16:16:09 CEST] <JEEB> *-c:v libx264
[16:16:23 CEST] <JEEB> of course older things just don't support AVC/H.264
[16:16:25 CEST] <holgersson> JEEB: Thanks, Ill try. However, many players say they can play AVI. Whatever this means :D
[16:16:30 CEST] <JEEB> it's a container
[16:16:36 CEST] <JEEB> in other words it means absolutely nothing
[16:16:42 CEST] <JEEB> container is something you put streams into
[16:16:57 CEST] <JEEB> so you have a video stream and an audio stream, for example
[16:16:58 CEST] <holgersson> I know, but most containers have typical defaults, lets take ogv
[16:17:15 CEST] <JEEB> well ogv is an OGG specific thing :D although they try to say that they support other things as well
[16:17:21 CEST] <alexpigment> don't most DVD players play DivX/XviD?
[16:17:34 CEST] <JEEB> alexpigment: yes but let's not go there, finding parameters that work is surprisingly hard
[16:17:47 CEST] <JC_Yang> why so many undefined references?  any suggestions?
[16:17:50 CEST] <JEEB> at least with AVC/H.264 if you find the profile and level
[16:17:56 CEST] <JEEB> you're pretty golden
[16:18:03 CEST] <alexpigment> eh, i doubt it. -c:v xvid 640x[whatever] -c:a mp3
[16:18:15 CEST] <holgersson> alexpigment: Ill try that first, thanks
[16:18:17 CEST] <JEEB> I ain't supporting that :D
[16:18:27 CEST] <JEEB> also it's libxvid and liblamemp3
[16:18:29 CEST] <JEEB> I think
[16:18:34 CEST] <alexpigment> oh right ;)
[16:18:37 CEST] <holgersson> JEEB: Im sure one HW Ill test is too old for h264
[16:18:42 CEST] <alexpigment> can you tell i haven't used those in a while?
[16:18:47 CEST] <JEEB> holgersson: my condolences
[16:19:15 CEST] <alexpigment> holgersson: my two cents, try xvid+mp3 inside an avi with a frame size no bigger than 640x480
[16:19:22 CEST] <JEEB> the "specs" for streams with MPEG-4 Part 2 (which is what the libavcodec mpeg4 encoder and the libxvid encoder encode) are really bad
[16:19:37 CEST] <JEEB> with AVC/H.264 it gets more clear
[16:19:38 CEST] <holgersson> Ò Ill try this, and tel you how it went ;)
[16:19:45 CEST] <JEEB> you have a profile, which is "features used"
[16:19:59 CEST] <JEEB> and then you have a level, which is "decoder requires <this> much memory to decode this stream"
[16:20:03 CEST] <alexpigment> JEEB: have you seen many DVD players that support H.264/AAC? I've never seen one
[16:20:09 CEST] <alexpigment> seems like a bad place to start
[16:20:21 CEST] <JEEB> unfortunately I'm really out of that thing
[16:20:25 CEST] <JEEB> not my finesse :D
[16:20:38 CEST] <JEEB> I don't want to touch devices that can't do AVC/H.264
[16:20:43 CEST] <alexpigment> back in the early 2000s, DivX/XviD support was almost ubiquitous
[16:20:48 CEST] <JEEB> I know, unfortunately
[16:20:56 CEST] <JEEB> unfortunately because it was never really standardized like AVC/H.264
[16:21:07 CEST] <JEEB> as in, there was a standard but various features out of the ASP profile just weren't supported
[16:22:13 CEST] <alexpigment> i haven't done any testing on this, but it seemed to play any downloaded XviD movie rips of the time ;)
[16:22:25 CEST] <alexpigment> if that file was 700Mb, the file would play
[16:22:36 CEST] <JEEB> yea encoder features were really stripped in most cases :D
[16:22:41 CEST] <alexpigment> i don't doubt it
[16:22:54 CEST] <JEEB> so there were "best practices" I guess
[16:23:02 CEST] <JEEB> if you wanted to support those plastic toys
[16:23:29 CEST] <alexpigment> yeah, I think the ripping groups had guidelines. the quality was crap, of course
[16:23:52 CEST] <JEEB> that's something you can never fix tho, they're fighting for who gets the thing out first :P
[16:24:23 CEST] <JEEB> later with x264-based rules they just standardized on certain CRF value ranges and "preset has to be slower than X"
[16:24:51 CEST] <alexpigment> easy enough
[16:25:04 CEST] <iive> x264 was really well polished
[16:25:08 CEST] <alexpigment> -tune film, -crf 20, -preset medium = good to go
[16:25:34 CEST] <alexpigment> although I guess I personally use CRF 18 for everything
[16:25:43 CEST] <alexpigment> and I encode in interlaced a lot
[16:25:47 CEST] <JEEB> for me it defines by content and resolution
[16:25:56 CEST] <JEEB> for example 720p animation being 19.5 for some reason in veryslow
[16:26:00 CEST] <JEEB> :V
[16:26:14 CEST] <alexpigment> sounds fine to me
[16:26:26 CEST] <alexpigment> animation compresses like crazy
[16:26:28 CEST] <JEEB> yup
[16:26:44 CEST] <alexpigment> you might as well bump the CRF down (and the preset down if you have the time)
[16:26:55 CEST] <alexpigment> veryslow is usually too slow for my taste though
[16:27:15 CEST] <iive> a lot of x264 developer were anime fans too :D
[16:27:16 CEST] <JEEB> the speed is plenty fast nowadays :D
[16:27:32 CEST] <iive> 's
[16:27:43 CEST] <alexpigment> i suppose so. i just stick with medium because i'm old and stubborn
[16:27:45 CEST] <JEEB> I wish libx265 would be worth the time I'd need to utilize with it
[16:28:04 CEST] <JEEB> alexpigment: well it doesn't really remove the quality as long as you poke the CRF
[16:28:07 CEST] <alexpigment> i have a sneaking suspicion that x265 isn't going to catch on anytime soon in th emainstream
[16:28:27 CEST] <JEEB> they just haven't gotten their coding tools optimzied :P
[16:28:28 CEST] <alexpigment> JEEB: yeah, that's why I go for CRF 18 (or sometimes 16)
[16:28:40 CEST] <JEEB> I mean, people have disabled >16x16 CTUs
[16:28:45 CEST] <JEEB> and gotten better visual results
[16:28:51 CEST] <JEEB> same for some other tools
[16:28:56 CEST] <JEEB> which in theory should be useful
[16:29:23 CEST] <JEEB> a lot of the new stuff is optimized for PSNR I guess
[16:29:35 CEST] <JEEB> which means less visible artifacts but more blur etc
[16:29:47 CEST] <alexpigment> yeah that's true
[16:29:49 CEST] <alexpigment> :(
[16:30:29 CEST] <alexpigment> I rip a lot of music videos from TV (I collect music videos, which I guess is weird), and even though my cable company compresses the hell out the signal, it's still better than, say, youtube
[16:30:59 CEST] <alexpigment> if not only because the macroblocks from mpeg-2 are more pleasing than the soft (but also macroblocky) look of those YouTube MPEG-4 encodes
[16:31:22 CEST] <alexpigment> which I think speaks to your point about the PSNR optimization
[16:31:42 CEST] <JEEB> well 'tube has its own things related to how they optimize
[16:31:51 CEST] <JEEB> for youtube quality was really never a thing they valued
[16:31:57 CEST] <alexpigment> that is very true
[16:32:09 CEST] <alexpigment> frame rates were never valued either, sadly
[16:32:15 CEST] <JEEB> if they could get something out faster while not having too much artifacts that would be herped and derped at by the general public they'd do that
[16:32:41 CEST] <alexpigment> I just don't get why there isn't a 480p60 / 576p50 option
[16:32:58 CEST] <alexpigment> considering the majority of broadcast history would fit into those two camps once deinterlaced properly
[16:34:00 CEST] <alexpigment> so you either lose half of the motion at 480p30, OR you get bad frame cadence because they simply went from 480i30 > 480p30
[16:35:08 CEST] <iive> hum.... i've been quite happy with youtube h264 encodes.
[16:35:12 CEST] <alexpigment> some days I wish my eyes/brain weren't so sensitive to quality issues, but whatever. I find YouTube nearly unwatchable
[16:35:33 CEST] <iive> on the other side, h265 encodes of MeGusta are simply attrocious
[16:35:55 CEST] <iive> 720p is as blurry as upscaled SDTV
[16:35:56 CEST] <alexpigment> not familiar with MeGusta
[16:36:31 CEST] <alexpigment> iive: anyway, YouTube is wayyy worse than something like Vimeo
[16:37:19 CEST] <alexpigment> and of course, Blu-ray makes YouTube look like a complete worthless joke
[16:37:49 CEST] <iive> are you sure the video you don't like are h264? because youtube/google like to push their vp9 stuff.
[16:37:56 CEST] <alexpigment> positive
[16:38:26 CEST] <JEEB> `youtube-dl -F "URL"`
[16:38:32 CEST] <JEEB> can let you do proper comparisons
[16:38:50 CEST] <iive> yep :)
[16:39:59 CEST] <iive> also, I think i've heard that youtube do a quick & dirty encode and then if video is on high demand, do a better quality .
[16:39:59 CEST] <alexpigment> yeah, I usually download the source for music videos which I can't get elsewhere
[16:40:24 CEST] <holgersson> JEEB, alexpigment: "-map 0:0 -map 0:1 -c:v libxvid -c:a mp3 test.avi" works =)
[16:40:32 CEST] <alexpigment> nice
[16:40:34 CEST] <JEEB> 'grats
[16:40:44 CEST] <holgersson> Its really ugly compared to the source, but thats just fine tuning
[16:40:57 CEST] <alexpigment> yeah you need to set a bitrate of course
[16:41:02 CEST] <holgersson> Last time I tried mpeg4 encoder which didnt work
[16:41:04 CEST] <JEEB> you can just lower the quantizer or do 2pass bit rate based encoding
[16:41:04 CEST] <alexpigment> or a quality factor I guess
[16:41:15 CEST] <JEEB> holgersson: probably just up to the parameters :D
[16:41:20 CEST] <JEEB> alexpigment: ughhh it's not *quality*
[16:41:22 CEST] <JEEB> it's quantizer
[16:41:48 CEST] <alexpigment> JEEB: apologies, I get the two mixed up
[16:42:19 CEST] <holgersson> However -- thanks you two, you saved someones present :D
[16:42:51 CEST] <JEEB> holgersson: I don't remember the exact range of sane values for libxvid, but try -q:v 4 or so?
[16:43:09 CEST] <JEEB> raise the number for higher compression, lower for more bits used
[16:43:33 CEST] <alexpigment> JEEB: this is going to be on DVD media presumably, so isn't -q:v probably less than ideal?
[16:43:47 CEST] <alexpigment> i'd worry about the bitrate spiking over 10Mbps
[16:44:04 CEST] <JEEB> right
[16:44:30 CEST] <alexpigment> from my xvid days back in the day, I recall that good bitrates were between 2Mbps and 4Mbps
[16:44:37 CEST] <alexpigment> assuming space isn't an issue
[16:45:06 CEST] <alexpigment> (for DVD resolution content)
[16:48:21 CEST] <holgersson> I dont remember DVD resolution, but the source material came from an old video casette cam corder and got digitialised to 640x480, 1629 kb/s, 24.97 fps, 25 tbr, 24.97 tbn, 49.94 tbc and some pcm audio line.
[16:49:24 CEST] <alexpigment> yeah, that's DVD resolution
[16:49:28 CEST] <alexpigment> effectively
[16:49:52 CEST] <alexpigment> 640x480 is the square pixel version
[16:50:41 CEST] <alexpigment> do you happen to know if the source file is interlaced or progressive?
[16:51:13 CEST] <alexpigment> i mean the tape itself is interlaced, but it seems to have been captured in a format that might not be interlaced
[16:52:04 CEST] <alexpigment> also, I just noticed the fps is 24.97. is that a typo or is it actually 24.97 rather than 29.97?
[16:53:14 CEST] <holgersson> alexpigment: I copynpasted from ffmpegs output.
[16:53:23 CEST] <alexpigment> weird
[16:53:48 CEST] <holgersson> How can I check if its interlaced?
[16:54:19 CEST] <alexpigment> I usually check that with Mediainfo
[16:54:27 CEST] <alexpigment> lemme refresh myself on using ffprobe
[16:56:24 CEST] <alexpigment> ffprobe -v error -show_streams [input file]
[16:56:30 CEST] <alexpigment> look for the line "field order"
[16:56:41 CEST] <alexpigment> this isn't 100% reliable, but it's reliable enough
[16:57:12 CEST] <holgersson> alexpigment: The cam is not mine and someone (other) else converted the analog output with some digitalizer black box, and I dont know anything about this one. Neither am I sure that the file I have is *really* the naked output of that digitalizer box.
[16:57:59 CEST] <alexpigment> yeah, the specs were a little weird with the frame rate, which is why I asked. I can't tell if it's meant to be NTSC or PAL or perhaps one of those hybrid variants
[16:58:33 CEST] <alexpigment> it's like the opposite of PAL-M or something
[16:59:00 CEST] <holgersson> I have no "field order" :D
[16:59:25 CEST] <alexpigment> ok, well let's hope it's progressive :)
[16:59:28 CEST] <holgersson> If it helps I - and the camera - are in/from Germany, and IIRC NTSC and PAL were a bit region specific.
[17:00:00 CEST] <alexpigment> yeah, a german camera should be pal
[17:00:17 CEST] <alexpigment> would I would be expecting a true source of 720x576 @ 25fps
[17:01:00 CEST] <alexpigment> or if it were converted to square pixels, 768x576 or similar
[17:02:08 CEST] <alexpigment> at any rate, I don't think most DVD players enforce any kind of standards on DivX/XviD, so you're probably fine
[17:02:11 CEST] <holgersson> OK. Maybe the file I used as source is pre-converted and scaled to run on DVD players, just with the wrong codec.
[17:02:47 CEST] <alexpigment> possibly
[17:02:48 CEST] <holgersson> However, thats just speculation -- Ill just ask later today ;)
[17:03:18 CEST] <alexpigment> no worries - I just wanted to make sure you wouldn't run into any quality or compatiblity issues while you're at it
[17:03:33 CEST] <alexpigment> if it looks good to you, that's all that really matters
[17:11:59 CEST] <Mandevil> Hello, can I reindex an AVI file? I tried ffmpeg -c copy, but it reindexes only half the source file, for some reason.
[17:49:32 CEST] <newuser> Hi there, is there any GUI for the FFmpeg that allows concatenation of video clips without using the command line?
[18:00:02 CEST] <Mandevil> Hm, funny using '-c:a -an' instead of '-c copy' made it work.
[18:15:29 CEST] <kepstin> Mandevil: uh..? "-c:a -an" makes no sense, "-an" is not an audio codec. Did you just use "-an" by itself?
[18:16:08 CEST] <kepstin> Mandevil: if that fixed the issue, then the problem is that your avi file probably has audio and video tracks which are different lengths, like the audio was half the length of the video
[18:16:45 CEST] <kepstin> the behaviour of players when the audio runs out but video keeps going is... a bit unpredictable, but it's not unexpected that you wouldn't be able to seek to the later parts.
[18:18:03 CEST] <kepstin> Mandevil: if you want to keep the audio track, try using "-af apad -shortest"; that'll extend the audio with silence, and make it the same length as the video track. This requires re-encoding the audio of course (can't use -c:a copy)
[18:19:43 CEST] <Mandevil> kepstin: Sorry -c:v -an
[18:20:30 CEST] <kepstin> "-c:v -an" doesn't make any sense either, "-an" isn't a video codec..., I assume you used "-c:v <something> -an" ?
[18:20:49 CEST] <Mandevil> -an means "discard audio", as far as I know.
[18:20:58 CEST] <nicolas17> yes, but -c:v is supposed to be followed by a codec
[18:21:01 CEST] <Mandevil> At least that's what it does for me.
[18:21:05 CEST] <kepstin> yes, but -c:v takes an argument, which is the codec name
[18:21:14 CEST] <Mandevil> nicolas17: Sorry.... "-c:v copy -an"
[18:21:23 CEST] <nicolas17> whole different thing :)
[18:21:24 CEST] <Mandevil> Excuse, I'm just having slow day or something.
[18:21:32 CEST] <kepstin> Mandevil: ok, my other comments above stand :)
[18:21:57 CEST] <Mandevil> I don't really need the audio.
[19:07:50 CEST] <ChocolateArmpits> If I use --disable-encoders and --enable-encoder=encoder does ffmpeg compile only the specified encoder ?
[19:12:52 CEST] <JEEB> should be pretty quick to test :P but as far as I know many people use configuration parameters like that
[19:13:06 CEST] <JEEB> the configure script will output enabled encoders afterwards
[19:25:15 CEST] <tdr_>  /nick tdr
[19:54:39 CEST] <alphabitcity> Is it possible to use ffmpeg to draw a dynamic overlay on a video that changes color based on the time? e.g. the overlay is red in the morning and white in the evening
[19:56:24 CEST] <alphabitcity> hm seems like there's an enable flag that can handle that. sorry/thx!
[20:27:11 CEST] <DHE> ChocolateArmpits: basically yes. you can also specify multiple encoders with --enable-encoders=mpeg2video,libx264,libvpx etc. You can also use wildcards like --enable-encoders=pcm*
[20:27:26 CEST] <ChocolateArmpits> cool
[20:28:33 CEST] <DHE> and yes, I also use this feature EXTENSIVELY for a low profile build that only outputs in formats I need and only the filters I use
[20:28:43 CEST] <DHE> (libavfilter is quite large if you don't restrict it like this)
[21:29:06 CEST] <alphabitcity> Does anyone happen to know of a good tutorial/place to start for writing custom libav filters for ffmpeg?
[21:30:43 CEST] <durandal_1707> alphabitcity: what filter you want to write?
[21:31:19 CEST] <alphabitcity> @durandal_1707: need a filter that writes a 32x32 dynamic watermark to videos .. the watermark is based on the current timestamp
[21:33:07 CEST] <durandal_1707> look at some docs in docs directory
[21:33:34 CEST] <alphabitcity> ok, will look there..thank you!
[21:33:37 CEST] <durandal_1707> if you need any help just ask on #ffmpeg-devel
[21:50:13 CEST] <alexpigment> weird, I was doing some 4k H.264 encoding with QSV, and I noticed my system is bogged down pretty heavily
[21:50:32 CEST] <alexpigment> someone was mentioning the other day that QSV has a software fallback
[21:50:39 CEST] <alexpigment> does it just silently go into that mode?
[21:55:18 CEST] <JEEB> alexpigment: I wouldn't be surprised if it did
[21:55:41 CEST] <JEEB> I mean, nvidia's driver wouldn't tell you it was doing SW VC1 decoding with GTX 9600 either
[21:58:48 CEST] <alexpigment> yeah, i think this happens when I do 4k; there's a message about partial HW acceleration
[21:58:58 CEST] <alexpigment> which, frankly, is way slower than x264
[22:04:05 CEST] <kepstin> on linux, I *think* the vaapi interface to qsv doesn't support any of the sw or partial sw fallback modes, so it'll fail rather than use them.
[22:04:15 CEST] <JodaZ> does anyone know if i can on demand segment encode content with ffmpeg? like generate compatible HLS/DASH segments individually, on demand - instead of a whole stream sequentially
[22:04:33 CEST] <kepstin> I assume the intel media sdk library includes a whole set of software encoders/decoders.
[22:06:28 CEST] <alexpigment> kepstin: I don't suppose you know of a way to force it to fail on Windows, do you?
[22:10:22 CEST] <JodaZ> alexpigment, "DXVA Checker" might help you control it
[22:10:36 CEST] <alexpigment> what do you mean "Control it" exactly?
[22:10:39 CEST] <kepstin> it looks like the ffmpeg side could be changed to check for the 'partial acceleration' warning and fail in that case.
[22:10:46 CEST] <kepstin> but that's about it
[22:11:10 CEST] <JodaZ> alexpigment, i have used it to disable hardware accelerated video decoding before, DXVA is the windows api for that kinda stuff
[22:11:22 CEST] <alexpigment> yeah, I guess I don't see the point of partial acceleration. it's slower and less efficient than x264
[22:11:33 CEST] <alexpigment> I've familiar with DXVA
[22:11:53 CEST] <kepstin> JodaZ: we're talking about encoding, not decoding, and using qsv via hardware-specific libraries, not a generic interface like dxva
[22:11:56 CEST] <alexpigment> I just didn't know if you were implying that you could use DXVA checker to prevent Intel from falling back to its software encoder
[22:12:10 CEST] <furq> JodaZ: i don't think you can do that
[22:12:20 CEST] <furq> you can pregenerate the chunks and generate a manifest for a subset on demand
[22:12:24 CEST] <furq> but only for webm dash afaik
[22:12:41 CEST] <furq> !muxer webm_dash_manifest
[22:12:41 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#webm_005fdash_005fmanifest
[22:13:18 CEST] <kepstin> JodaZ: are you thinking of something like generating the m3u8 playlist in advance, then having each individual .ts file generated the first time it's requested?
[22:13:28 CEST] <JodaZ> kepstin, exactly
[22:13:40 CEST] <kepstin> JodaZ: sure, it's possible in theory, but you'd be writing a custom app to do it using ffmpeg libraries.
[22:14:31 CEST] <kepstin> and you'd have to use really fast/low latency encoder settings to make playback actually work smoothly
[22:17:25 CEST] <ttpure> hey guys. I have a 6k movie (6240x2700). is there any way i can split it into two movies efficiently, where each movie has half of the screen size (3120x2700) ?
[22:18:17 CEST] <ttpure> i don't want to crop twice. seems a waste
[22:18:17 CEST] <JodaZ> furq, is chunk_start_index the relevant option to select the subset or how does it work?
[22:43:05 CEST] <kepstin> ttpure: I don't really see how there's any way to avoid cropping twice, at least when using ffmpeg. You can do that all in a single ffmpeg command to save from decoding the video twice, though.
[22:44:10 CEST] <ttpure> i thought so too
[22:44:47 CEST] <ttpure> but if there was a filter that when reading each frames put them into two outputs, that would be awesome
[22:45:52 CEST] <holgersson> alexpigment: Hi again,  just for the record: these videos I asked earlier came are natively from this converter box.
[22:46:56 CEST] <alexpigment> holgersson: gotcha. I guess it's either not PAL-friendly or just isn't following specs in general
[22:46:57 CEST] <kepstin> ttpure: you mean https://www.ffmpeg.org/ffmpeg-filters.html#split_002c-asplit ?
[22:46:58 CEST] <kepstin> :)
[22:47:34 CEST] <alexpigment> holgersson: but again, if it looks good to you, it doesn't matter too much. I've come to learn that when something looks "wrong" to me, it usually looks fine for 99% of other people
[22:47:53 CEST] <kepstin> ttpure: hmm, I'd have to check, but I think split actually shares buffers by reference between both frames, and crop doesn't actually modify the buffer (it only adjust pointers& values in the avframe), so that should be fairly efficient.
[22:49:03 CEST] <holgersson> alexpigment: Well, the physical source is that old that even *there* are already glitches -.- But whatever, the conversion doesnt seem to decrease the quality much more (just increase the file size, as h264 is quite efficient.. *sigh*).
[22:49:25 CEST] <holgersson> alexpigment: And yes, if it works its fine.
[22:50:07 CEST] <ttpure> kepstin: that would make it great!
[22:52:41 CEST] <alexpigment> guys, correct me if I'm totally off base in this assumption: aren't most (all?) HDTVs these days inherently "NTSC" (60Hz)?
[22:53:36 CEST] <alexpigment> In other words, aren't "PAL" HDTVs just NTSC TVs with some extra hardware to convert 25/50fps videos to play better at 60hz?
[22:53:38 CEST] <kepstin> alexpigment: depends a lot on the underlying panel, but I would expect they're normally using scalers and multisync panels which could run at either 60Hz (or a multiple) or 50Hz (or a multiple)
[22:54:22 CEST] <kepstin> many better tvs also have proper 24Hz modes, too
[22:54:37 CEST] <alexpigment> kepstin: well, I guess to ask my question more directly: if I have a 1080p60 video, can I be reasonably certain that any PAL HDTV that can play a 1080p50 video can also play that 1080p60 video without issue (if not perfectly)?
[22:55:15 CEST] <alexpigment> I'm implying that the video player is in the TV, of course
[22:55:57 CEST] <Asuran> https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio "For AAC-LC: libfdk_aac > aac NOTE: as of 2017 this is no longer necessarily the case. The built in aac encoder is quite good." how good is it?
[22:56:00 CEST] <kepstin> alexpigment: pretty much any TV nowadays will accept either 50Hz or 60Hz signals without issue, and play both correctly. As for using a player built-in to the tv rather than one connected via hdmi... uh...? who knows.
[22:56:07 CEST] <The_8472> alexpigment, most likely.
[22:56:28 CEST] <alexpigment> OK, thanks guys
[22:56:36 CEST] <The_8472> if the player is meant to play random video files you could find on the web they could be of any framerate, so it has to deal with that situation
[22:56:42 CEST] <ChocolateArmpits> Asuran, good for anything above 128kbps
[22:56:55 CEST] <Asuran> ok thx
[22:57:04 CEST] <ChocolateArmpits> anything lower and you should really consider something better, like libfdk
[22:57:24 CEST] <Asuran> i wonder why -strict experimental doesnt seem to add the ability to use opus in mp4? compared to the mp4 register thingy opus is format accepted?
[22:57:37 CEST] <alexpigment> The_8472: that's a good point. I guess I wanted to know if my assumption is correct that a 1080p60 video will appear more smooth on a PAL HDTV than a 1080p50 video
[22:57:49 CEST] <furq> Asuran: it's not implemented yet
[22:57:59 CEST] <alexpigment> The_8472: but as far as actual compatibility, your point is pretty spot on
[22:58:01 CEST] <Asuran> thx then
[22:58:04 CEST] <furq> or if it is, your ffmpeg is too old
[22:58:29 CEST] <The_8472> alexpigment, you said "(if not perfectly)", which made it sound more like a compatibility than a quality question.
[22:58:40 CEST] <furq> yeah, your ffmpeg is too old
[22:58:42 CEST] <furq> it works here
[22:58:48 CEST] <kepstin> alexpigment: I suspect it really varies based on the tv manufacturer. They might run the built-in player at a fixed 60Hz mode, or a 120Hz mode, or have it vary...
[23:01:22 CEST] <kepstin> and someone might have forgotten to turn off the high-framerate thing on the tv, and it'll ruin everything with motion interpolation ;)
[23:02:03 CEST] <Asuran> furq, its 3.3.2
[23:02:11 CEST] <furq> weird
[23:02:15 CEST] <furq> i'm on 3.3 and it works here
[23:02:30 CEST] <furq> oh nvm i'm an idiot
[23:02:55 CEST] <furq> pro tip: smptebars is not an audio source
[23:05:21 CEST] <Asuran> furq, -c:v libx265 -preset slow -crf 24 acceptable?
[23:05:37 CEST] <furq> shrug
[23:05:39 CEST] <furq> i've never used x265
[23:05:52 CEST] <Asuran> i tend now cuz vp9 lacks of smp
[23:06:06 CEST] <Asuran> i hope av1 will do it better
[23:06:14 CEST] <alexpigment> The_8472: I just meant play at true 1080p60 rather than some sort of interpolated mode to fit in at 50hz on a PAL tv
[23:06:43 CEST] <alexpigment> kepstin: you might be right
[23:06:54 CEST] <kepstin> alexpigment: the thing you have to remember is that the actual internal scaling & panel hardware is basically the same worldwide for modern tvs; they might have region specific analogue connectors or tuners, but that's pretty much it.
[23:07:05 CEST] <alexpigment> right, that was my thought
[23:07:10 CEST] <The_8472> alexpigment, that depends on your TV. check the spec sheet whether its panel supports more than refresh rate.
[23:07:54 CEST] <alexpigment> The_8472: *my* tv is NTSC, and I don't have access to any PAL TVs for testing. I just have some anecdotal evidence that my theory is correct
[23:09:35 CEST] <The_8472> alexpigment, there is no universal law that forces all tvs to act the same way. some can switch display framerates, some must interpolate to a fixed framerate.
[23:11:44 CEST] <alexpigment> The_8472: i agree with that. the latter scenario is what I'm wondering about. do all PAL TVs that *don't* switch just internally operate at 60hz and do frame interpolation to handle PAL content correctly?
[23:13:00 CEST] <kepstin> I'd hope not, given how awful frame motion interpolation looks in general
[23:13:06 CEST] <holgersson> alexpigment: I get way more image artefacts in the converted avi containers, even with -q:v 1 (originally tried with -q:v3, which seems more than OK).
[23:13:12 CEST] <The_8472> alexpigment, you mean 50Hz?
[23:13:29 CEST] <kepstin> I wouldn't be surprised if some just run the panel at a higher fixed rate and just have timing jitter.
[23:14:21 CEST] <alexpigment> The_8472: no, I'm wondering if PAL TVs that don't switch natively just run at 60Hz and have some sort of hardware to handle the PAL content in some sort of semi-intelligent way (or perhaps the TV just ends up sucking, even)
[23:14:43 CEST] <The_8472> alexpigment, why would you call it a PAL tv if it runs at 60Hz instead of 50?
[23:15:20 CEST] <alexpigment> The_8472: well, it would have a PAL tuner and possibly some sort of PAL frame interpolation hardware in it too
[23:15:31 CEST] <alexpigment> but I would still call it a PAL TV
[23:16:42 CEST] <The_8472> well, that would be crazy. of course some shitty product like that might exist. but no, normally you would not expect that kind of thing
[23:17:09 CEST] <The_8472> of course we can play the "how bad could implementations possibly get and still somewhat work" game all day
[23:17:46 CEST] <alexpigment> the other game we could play is "how bad does judder have to be before someone cares", and we can play that game easily at any of our parents' houses
[23:18:16 CEST] <alexpigment> people are just not that discerning
[23:18:48 CEST] <alexpigment> I mean I watch telecined content all the time on my 60hz TV and it doesn't even bother me, really. I realize 50>60 is worse in theory, but still
[23:19:15 CEST] <The_8472> i'm just saying your questions are too broad. the product space is large.
[23:19:25 CEST] <alexpigment> Yeah, I realize this
[23:19:26 CEST] <The_8472> some do the right thing, some don't.
[23:19:38 CEST] <alexpigment> I was just hoping someone knew the dirty truth about HDTVs
[23:20:17 CEST] Action: kepstin has some ... contacts in the tv industry who've been to hdmi plugfests
[23:20:39 CEST] <kepstin> but that's just from the hdmi interface side, I know nothing about the actual panels :)
[23:21:01 CEST] <alexpigment> kepstin: well if you're ever having a drink with one of those friends, it may be worth asking them :)
[23:21:24 CEST] <kepstin> all I know about the hdmi side is that getting the stuff certified is such a pain that they do the minimal no. of hardware implementations - just one chip for all regions, rather then multiple variations.
[23:21:32 CEST] <alexpigment> "industry friend, is it true that all PAL TVs are just NTSC TVs in disguise?" ;)
[23:21:56 CEST] <alexpigment> well, HDMI is a lot easier to do that I'd image
[23:21:59 CEST] <alexpigment> *imagine
[23:22:11 CEST] <kepstin> but the hdmi interface can run at many different clock rates, and whether the scaler and panel actually run at the same rate... ? :/
[23:22:20 CEST] <alexpigment> you just have to make sure it delivers the top tier feed you're spec'd for
[23:22:36 CEST] <alexpigment> I suppose so
[23:23:11 CEST] <alexpigment> I don't know how much the HDMI interface actually cares about different signals. I'll have to take your word for it
[23:46:16 CEST] <Chimaera> Asuran: I have finally solved my compile issue - instead of manually compiling the x265 library, I downloaded and manually installed the .deb for libx265-dev from jessie-backports
[23:46:35 CEST] <Asuran> Chimaera, ok
[23:46:53 CEST] <Asuran> Chimaera, good choice i guess cuz compile yourself implies problems on distro not less times
[23:47:21 CEST] <Asuran> and you can downlad pkg src and compile from this yourself with custom options
[23:48:25 CEST] <Chimaera> I just need to document this for next time
[23:53:44 CEST] <JodaZ> Chimaera, grab a static build ;)
[23:55:20 CEST] <Chimaera> JodaZ: where's the fun in that? ;)
[23:59:22 CEST] <JodaZ> the fun is in it working every time
[00:00:00 CEST] --- Sat Jul  1 2017