Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2017

1 participants
62 discussions

ffmpeg-devel.log.20171015
by burek 16 Oct '17

16 Oct '17

[00:13:44 CEST] <cone-802> ffmpeg 03Michael Niedermayer 07master:9c85329cd02e: avcodec/pafvideo: Check for bitstream end in decode_0() [00:13:45 CEST] <cone-802> ffmpeg 03Michael Niedermayer 07master:393d6fc73956: avcodec/snowdec: Check mv_scale [00:13:46 CEST] <cone-802> ffmpeg 03Michael Niedermayer 07master:cd2f69cdd63d: avcodec/dvbsubdec: Factor a few expressions out of compute_default_clut() [00:13:47 CEST] <cone-802> ffmpeg 03Michael Niedermayer 07master:963247b5f36a: avcodec/dvbsubdec: Split best score computation out of loop in compute_default_clut() [02:02:08 CEST] <cone-802> ffmpeg 03Ivan Kalvachev 07release/3.4:a11a18b284af: Fix visual glitch with XvMC, caused by wrong idct permutation. [02:02:09 CEST] <cone-802> ffmpeg 03Sasi Inguva 07release/3.4:8500de89ea91: ffmpeg.c: Fallback to duration_dts, when duration_pts can't be determined. [02:02:10 CEST] <cone-802> ffmpeg 03Michael Niedermayer 07release/3.4:35e36046f1a3: avcodec/pafvideo: Check for bitstream end in decode_0() [02:02:11 CEST] <cone-802> ffmpeg 03Michael Niedermayer 07release/3.4:46abeb1c3223: avcodec/snowdec: Check mv_scale [02:37:53 CEST] <cone-802> ffmpeg 03James Almer 07master:065581007274: configure: add pkg-config checks for libcdio/cdparanoia [02:59:48 CEST] <cone-802> ffmpeg 03Michael Niedermayer 07release/3.4:03351cce8843: Update versions for 3.4 release [14:08:39 CEST] <cone-633> ffmpeg 03Mark Thompson 07release/3.4:01e291a59245: hwcontext_vaapi: Remove use of vaExportSurfaceHandle() [14:37:30 CEST] <ubitux> ~g [14:37:32 CEST] <ubitux> oups [19:30:35 CEST] <cone-276> ffmpeg 03James Almer 07n3.4:HEAD: configure: add pkg-config checks for libcdio/cdparanoia [21:41:08 CEST] <Zeranoe> Any chance this can get merged? https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217977.html [21:47:10 CEST] <Snaggle> What is the benefit of use_pkg_config over require_pkg_config or vice versa? Is there a preferred one for finding external libraries? [21:48:51 CEST] <BtbN> Doesn't require just die if it doesn't find its stuff? [21:49:17 CEST] <BtbN> just look at the functions if you want to know the difference [21:59:14 CEST] <nevcairiel> require should usually be preferred if there is always a pc file [21:59:20 CEST] <nevcairiel> use is only for special circumstances [22:00:11 CEST] <BtbN> like if there could be multiple ones and you try them one after the other [22:34:49 CEST] <jamrial> i could use a review for the configure patchset i sent (not numbered, but it's three patches in one thread) [22:36:07 CEST] <BtbN> I'm also running in a linker error on Gentoo. But it's quite a configure invocation [22:36:31 CEST] <BtbN> Also, configure is _really_ slow there [22:36:46 CEST] <BtbN> With all those options gentoo puts there, it thinks about them for a good few minutes [22:42:51 CEST] <jamrial> most external library check problems will be gone with that patchset, since it adds lm and pthreads to global extralibs [22:46:14 CEST] <BtbN> You mean https://patchwork.ffmpeg.org/patch/5561/ https://patchwork.ffmpeg.org/patch/5562/ https://patchwork.ffmpeg.org/patch/5563/ ? [22:48:35 CEST] <BtbN> Just noticed that gentoo patches ffmpeg to build ffmpeg.c into libffmpeg.so oO [22:48:50 CEST] <BtbN> https://github.com/gentoo/gentoo/blob/master/media-video/ffmpeg/files/chrom… [22:50:10 CEST] <BtbN> hm, it's not ffmpeg.c, but all the libs linked together? [22:54:25 CEST] <BtbN> jamrial, even with your 3 patches applies, I still get libavutil/libavutil.so: undefined reference to dlopen/dlclose/dlsym [22:54:34 CEST] <BtbN> So something is missing $ldl [22:55:32 CEST] <BtbN> It happens during make of tools/ffescape [22:56:25 CEST] <BtbN> The configure line is quite something though: https://bpaste.net/show/66193e054923 [22:57:03 CEST] <jamrial> cuda, omx, nvenc, avysynth, decklink, frei0r and ladspa are listed as needing libdl [22:57:40 CEST] <BtbN> none of those are enabled in that build [22:58:40 CEST] <BtbN> ./libavutil/hwcontext_cuda.o it the culprit [22:59:39 CEST] <jamrial> cuda_deps_any="libdl LoadLibrary" [22:59:49 CEST] <jamrial> but it seems it's not being added to libavutil [23:00:18 CEST] <BtbN> Is the hwcontext_cuda stuff missing a dep on cuda? [23:00:41 CEST] <BtbN> Can you even define deps for stuff in libavutil? [23:01:34 CEST] <jamrial> i think i found what's missing [23:19:40 CEST] <jamrial> BtbN: try https://pastebin.com/HXn1NeMN [23:21:22 CEST] <BtbN> what does suggest even mean in the context of configure? [23:24:09 CEST] <BtbN> The patch doesn't apply for me [23:24:12 CEST] <jamrial> it adds the listed module's extralibs to the target module's extralibs if the former is enabled, or if it can be enabled in the process [23:24:48 CEST] <jamrial> pull new commits? it should apply with git head [23:24:53 CEST] <BtbN> I'm applying it to master after the 3 patches from the ml [23:25:17 CEST] <jamrial> ah, yeah, it clashes with those [23:25:17 CEST] <jamrial> one sec [23:26:35 CEST] <jamrial> BtbN: https://pastebin.com/sHMeiBar [23:27:17 CEST] <BtbN> that applies, lets see how the build goes [23:28:34 CEST] <jamrial> that configure line is full of pointless stuff, btw [23:28:57 CEST] <jamrial> lots of --disable-something for things that are disabled by default [23:29:05 CEST] <nevcairiel> looks like autogenerated shit from gentoo or something [23:29:18 CEST] <nevcairiel> their cpu flag handling for ffmpeg is dumb as fuck [23:29:29 CEST] <jamrial> yeah, it disables simd from four different arches, lol [23:29:32 CEST] <nevcairiel> just let ffmpeg handle it, we have runtime detection [23:30:01 CEST] <BtbN> There's a useflag for that [23:30:07 CEST] <BtbN> which should be enabled by default, but isn't [23:31:06 CEST] <thebombzen> --enable-runtime-cpudetect yea [23:31:26 CEST] <nevcairiel> that flag also doesnt do shit [23:31:34 CEST] <BtbN> Well, in ffmpeg that clearly is the default [23:31:35 CEST] <nevcairiel> you cant disable that [23:31:50 CEST] <thebombzen> then why does the option exist? shouldn't it just be removed? [23:32:10 CEST] <BtbN> Maybe just removing it would make the gentoo maintainer re-think [23:32:17 CEST] <BtbN> He only reacts when the build is broken [23:32:31 CEST] <BtbN> doesn't even care about the "sdl is unknown" warnings it spews [23:32:36 CEST] <BtbN> Because it was never updated to sdl2 [23:33:03 CEST] <nevcairiel> git ebuilds are often quite a mess [23:33:30 CEST] <BtbN> Well, in theory you continously maintain a git ebuild. And when a release comes you copy it at that time, and have your release ebuild. [23:33:53 CEST] <BtbN> But the ffmpeg maintainer in gentoo is kind of not overly interested in doing work [23:38:55 CEST] <BtbN> jamrial, no that doesn't make libavutil link against libdl [23:39:23 CEST] <jamrial> BtbN: it should [23:39:32 CEST] <jamrial> maybe it's what nevcairiel found about flatten_libs() again [23:39:49 CEST] <jamrial> too many layers of deps [23:40:52 CEST] <nevcairiel> probably the same issue [23:41:06 CEST] <nevcairiel> I should remember to ping diego about that tomorrow [23:41:28 CEST] <nevcairiel> they actually have cuda, so maybe i can make an actual example [23:41:47 CEST] <BtbN> it's only the cuda stuff in avutil [23:42:07 CEST] <BtbN> cuvid in avcodec probably has the same issue though. But the deps work there I guess? [23:42:48 CEST] Action: ubitux remembers android linker being annoying when not specifying -l* in the "correct" order and wonder if the commit will affect that [23:43:00 CEST] <nevcairiel> the issue only manifests itself if one component is used by two libraries, and that component has nested deps [23:43:24 CEST] <BtbN> so as a workaround, just adding libdl there directly should work for now? [23:44:32 CEST] <jamrial> BtbN: https://pastebin.com/iCfqyjLi [23:44:37 CEST] <jamrial> yeah, that one should work [23:44:49 CEST] <jamrial> but it's Not Ideal(tm) [23:45:53 CEST] <BtbN> Wasn't there a major bump planned soon? [23:46:23 CEST] <BtbN> (unrelated) [23:47:40 CEST] <jamrial> yeah [23:48:55 CEST] <jamrial> we're close to it in the merge queue, so i'll probably apply it as i merge it [23:49:03 CEST] <jamrial> but if merges take too long though, i'll apply it on its own since i want enough time before 4.0 is tagged to do the usual post bump cleaning [23:53:26 CEST] <BtbN> Time to merge all the libraries. Should make dependencies way easier! [23:53:55 CEST] <jamrial> if there's a time to troll in that regard, this is it :p [23:55:59 CEST] <BtbN> I don't know, why not? It would make a lot of things easier. [23:56:27 CEST] <BtbN> People who need absolutely minimal builds build them themselves anyway, and they can just disable all the components that are in other libraries now. [00:00:00 CEST] --- Mon Oct 16 2017

1 0

ffmpeg.log.20171015
by burek 16 Oct '17

16 Oct '17

[01:18:22 CEST] <Glis> Hello - anyone around I could pick the brains of? [03:22:52 CEST] <koyglreg> Why is there a 16-235 color range for TVs? [04:11:24 CEST] <CoreX> koyglreg read this https://referencehometheater.com/2014/commentary/rgb-full-vs-limited/ [04:14:14 CEST] <koyglreg> I saw that article. Maybe I missed something, but it doesn't really explain WHY TVs use 16-235, but only how and why you need to adjust your color space settings sometimes. [06:37:07 CEST] <SolarAquarion> -> Running ffmpeg configure script. Please wait... [06:37:07 CEST] <SolarAquarion> ERROR: libflite not found [06:37:24 CEST] <SolarAquarion> i have that installed [06:59:25 CEST] <titbang> do u have the dev package [08:42:48 CEST] <monoxane> right, i know you guys probably dont give a shit about mpeg-dash but theres nowhere to ask about it so ill do it here, how the hell do you make an mpd file correctly? [10:14:40 CEST] <marlenka> hi [10:16:01 CEST] <marlenka> its possible with ffmpeg do a invisible digital watermarking to video and posible read it again back? [12:45:03 CEST] <diqidoq_> marlenka: define "invisible". Do you mean transparent but existing or hidden in file/code? [12:46:19 CEST] <diqidoq_> marlenka: Regarding your use case (which I dont know) you can maybe use a subtitle track with transparency (not sure about transparency). A subtitle can later be extracted again. Just a thought to chime in. [13:32:15 CEST] <SolarAquarion> titbang: I have arch installed [13:32:33 CEST] <SolarAquarion> Although I don't see libtool files [13:35:00 CEST] <titbang> not familiar with arch [13:39:50 CEST] <SolarAquarion> titbang, basically no matter what version of flite i built i don't see the "libtool" files [14:07:40 CEST] <jonascj> Does "-vf transpose" dictate a reencode? [14:08:22 CEST] <jonascj> -vf "transpose=2" that is [14:08:36 CEST] <jonascj> It seems like something which could be done completely lossless [14:11:24 CEST] <furq> you can't apply any filters without reencoding [14:11:41 CEST] <jonascj> alright, that was how I thought it was. [14:11:43 CEST] <furq> if the container and player support it then you can rotate using container metadata [14:11:54 CEST] <furq> -metadata:s:v:0 rotate=90 or something like that [14:12:03 CEST] <jonascj> Maybe that landscape vs portrate rotation is just a simple meta data flag specifying oritientation anyway [14:12:29 CEST] <furq> if this is a phone video then that's usually just a flag, yeah [14:12:50 CEST] <jonascj> it is a phone video, and I just found an exif tag "Rotation: 270" [14:12:54 CEST] <jonascj> thanks [14:46:23 CEST] <titbang> SolarAquarion, i believe libtoolize is a standalone package [16:23:32 CEST] <SolarAquarion> titbang, i meant the things that can be "libtools" as in provide .la as in -llibflite [16:56:00 CEST] <FishPencil> Is there a way to see what SIMD optimizations are enabled for a build? [16:56:19 CEST] <BtbN> unless you disabled them: all [16:57:12 CEST] <JEEB> for x86_64 everything is built and then enabled per the capabilities of the runtime CPU [16:57:16 CEST] <JEEB> same for x86 [16:57:17 CEST] <FishPencil> BtbN: Are they dependent on the detected CPU of the compiling machine or anything? [16:57:48 CEST] <JEEB> for ARM NEON optimizations are also enabled or disabled during runtime [16:58:57 CEST] <JEEB> for MIPS and PowerPC if you build for a specific thing the SIMD gets enabled [17:00:32 CEST] <JEEB> but the most common case of "I am on intel and building for intel" has everything compatible built (some SIMD only supports 64bit x86 so for 32bit builds that won't of course be built), and then things get enabled when the library is started [17:00:45 CEST] <JEEB> so whether you build on a xeon or an atom the result should be the same :P [17:01:09 CEST] <BtbN> Unless you set a specific --cpu [17:01:16 CEST] <BtbN> or cpu=host [17:01:39 CEST] <JEEB> but that's compiler options I think? [17:01:45 CEST] <JEEB> march=native etc [17:01:55 CEST] <BtbN> yes, but it still ends up with a build that has instructions old CPUs don't have [17:01:59 CEST] <JEEB> yes [17:02:11 CEST] <BtbN> and they are not runtime-detected [17:02:31 CEST] <FishPencil> What codecs (encoder or decoder) use a lot of SIMD? I'd like to do some testing [17:02:35 CEST] <JEEB> yes, but generally people don't use that since FFmpeg's configure disables vectorization etc [17:02:44 CEST] <JEEB> FishPencil: on x86_64 VP9 and AVC (H.264) [17:02:55 CEST] <JEEB> the decoders, that is [17:03:26 CEST] <JEEB> VP9 has a lot of modern SIMD made for it because one of the FFmpeg developers decided to start selling a VP9 encoder so he needed the decoding to be fast :) [17:03:47 CEST] <Mavrik> nice [17:03:56 CEST] <Mavrik> Is VP9 used outside Google a lot? [17:04:16 CEST] <FishPencil> JEEB: Are you talking about EVE? [17:04:20 CEST] <JEEB> not really. the fun fact is how Mozilla then ripped the decoder out of libavcodec and now has that ffvp9 [17:04:29 CEST] <JEEB> FishPencil: yup [17:04:54 CEST] <FishPencil> JEEB: who was the dev lol [17:05:10 CEST] <JEEB> uhh, I'm pretty sure his name is on the blog. :D [17:05:36 CEST] <JEEB> yea, literally on its title [17:05:42 CEST] <JEEB> https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-… [17:06:39 CEST] <JEEB> Mavrik: although IIRC Netflix uses it for downloads? [17:06:46 CEST] <JEEB> now that I am reminded [17:06:52 CEST] <Mavrik> I didn't really check tbh [17:07:03 CEST] <FishPencil> Did he use FFmpeg for that? Wouldn't that violate even the LGPL [17:07:06 CEST] <JEEB> Netflix is basically all about "someone else paid these thousands of VPS already so we can just ise it" [17:07:24 CEST] <JEEB> *use [17:07:50 CEST] <furq> FishPencil: MPL2 is GPL compatible [17:08:24 CEST] <furq> actually nvm you mean EVE [17:08:59 CEST] <furq> the encoder (presumably) doesn't have any ffmpeg code [17:09:24 CEST] <furq> but if you're selling an encoder then it's probably good if you contribute to a fast decoder or nobody will buy the encoder [17:10:22 CEST] <FishPencil> And people buy it because it's actually that much better? [17:10:44 CEST] <JEEB> at least multiple vendors have been testing it according to media [17:11:09 CEST] <JEEB> mostly places that just need the better quality, and don't care that much about the extra time spent on encodes VS x264 [17:12:03 CEST] <FishPencil> AV1 needs to hurry up [17:12:31 CEST] <Mavrik> I'd say broadcast industry would grab it [17:12:42 CEST] <Mavrik> Mostly due to BW costs and the fact that libvpx can't keep to CBR worth a damn [17:13:02 CEST] <JEEB> VOD side of things is mostly interested because of no realtime requirement [17:13:07 CEST] <JEEB> broadcast usually requires realtime [17:15:30 CEST] <c3r1c3-Win> I recall seeing a video of a realtime AV1 encode from the floor of NAB this year. [17:16:30 CEST] <FishPencil> I didn't even think the spec was done yet [17:16:58 CEST] <JEEB> it still isn't [17:17:09 CEST] <JEEB> it was 100% marketing, which is what NAB is [17:17:22 CEST] <c3r1c3-Win> LOL. [17:17:41 CEST] <JEEB> c3r1c3-Win: also making an encoder fast is not really a problem :D you don't have to support all features. [17:17:55 CEST] <JEEB> a friend of mine at VDD was developing an alternative av1 encoder [17:18:09 CEST] <JEEB> and he was easily getting hundreds/thousands of frames per second [17:18:10 CEST] <c3r1c3-Win> I thought the essence part of the spec was done, it's the implementations that aren't done and some of the meta-data and container stuff that isn't done. [17:18:18 CEST] <JEEB> nah, even coding methods [17:18:28 CEST] <JEEB> they're going for the "soft freeze" at the end of this month [17:18:35 CEST] <JEEB> let me find you the VDD talk about it [17:18:36 CEST] <FishPencil> what is the proposed container [17:18:48 CEST] <JEEB> https://bambuser.com/v/6908002#t=2416s [17:18:59 CEST] <JEEB> FishPencil: they're doing mappings for all mostly utilized things I would presume [17:19:12 CEST] <furq> presumably mkv or some subset thereof [17:19:13 CEST] <c3r1c3-Win> Well it was for... Satellite/Cable transmission system (if I recall correctly). Broadcast is going h264 with ATSC3.0 [17:19:17 CEST] <JEEB> ISOBMFF (mp4) draft has been already poked [17:19:21 CEST] <furq> but yeah i assume mpegts and whatnot will all work [17:19:30 CEST] <Mavrik> What's the rationale for AV1? [17:19:31 CEST] <JEEB> Matroska will most likely get one [17:19:37 CEST] <Mavrik> Avoiding HEVC patent craziness? [17:19:40 CEST] <JEEB> Mavrik: "plan B" because HEVC licensing got out of hand [17:19:41 CEST] <furq> something like that [17:19:50 CEST] <JEEB> a lot of companies basically decided it's a good idea to have Another Thing [17:19:57 CEST] <JEEB> even if it doesn't necessarily bear fruit [17:20:11 CEST] <JEEB> also really sorry for the audio being so low with the VDD talks :P [17:20:17 CEST] <JEEB> not sure who set up the mic input [17:20:24 CEST] <JEEB> or if it was just the camera's mic [17:20:53 CEST] <Mavrik> What's the audio meant to accompany AV1? [17:20:57 CEST] <furq> probably opus [17:21:09 CEST] <Mavrik> Also do we have updated HDMI-ARC spec to carry anything that's modern yet? :P [17:21:11 CEST] <JEEB> opus most likely, which is already in MPEG-TS and there's a draft for ISOBMFF [17:21:18 CEST] <furq> av1 is mostly vp10 afaik so i assume it'll be all the same supporting stuff as vp9 [17:21:31 CEST] <JEEB> av1 is much less vp10 than how it was a year+ ago [17:21:35 CEST] <JEEB> it based on the vp10 code, yes [17:21:39 CEST] <FishPencil> Why even dev it then if we could just do vp10 [17:21:52 CEST] <JEEB> FishPencil: because multiple vendors. Google also moved from vp10 to AV1 [17:21:52 CEST] <furq> what would the difference be [17:22:06 CEST] <c3r1c3-Win> Because VP10+Thor+Dhalia is better than just VP10 [17:22:10 CEST] <JEEB> furq: basically AV1 has a lot of very good stuff from the daala and thor etc [17:22:18 CEST] <furq> i know that [17:22:21 CEST] <JEEB> ok [17:22:26 CEST] <furq> 16:21:39 ( FishPencil) Why even dev it then if we could just do vp10 [17:22:27 CEST] <furq> i meant this [17:22:37 CEST] <furq> idk why you'd want them to just make vp10 [17:22:50 CEST] <JEEB> the difference would be that less people would contribute to a standard google project VP10 [17:22:59 CEST] <furq> av1 is more or less the continuation of vp9, plus good shit from other vendors, plus you hopefully get a clean break from libvpx [17:23:41 CEST] <c3r1c3-Win> Yeah. Doesn't ilbvpx have horrible CBR and multi-threaded capabilities? ;-) [17:23:53 CEST] <JEEB> while google of course still is a big contributor, it makes a world of difference to have other vendors in there as well [17:24:24 CEST] <furq> and also you get a standard that isn't "look at the source code, but try to ignore the errata" [17:24:24 CEST] <Mavrik> Yeah, more pressure to actually to HW decode support and similar [17:24:37 CEST] <Mavrik> Although Apple forcing HEVC on people is annoying [17:24:42 CEST] <furq> fuck apple [17:25:08 CEST] <FishPencil> Apple has pretty much always been behind on these things [17:25:18 CEST] <furq> it's not behind, it's actively obstructing [17:25:59 CEST] <FishPencil> Too busy developing tiny DAC's [17:26:30 CEST] <c3r1c3-Win> JEEB: Thanks for the link. I'll have to finish watching it later (running a stream right now), but that's some interesting stuff. [17:26:50 CEST] <JEEB> c3r1c3-Win: yea, even if derf's stuff goes way over your head his stuff is generally great to listen [17:27:24 CEST] <c3r1c3-Win> Well Apple doesn't support VP9, and yet people are using it because Android (generally) supports it, along with desktop hardware (i.e. CPUs and GPUs). [17:27:39 CEST] <c3r1c3-Win> and by 'people' I really should say companies... large companies. [17:27:58 CEST] <JEEB> I only know google and maybe netflix using VP9 in any major capacity [17:28:10 CEST] <c3r1c3-Win> Hell, Safari doesn't get Youtube 4k support because of their lack of VP9 support, LOL. [17:28:16 CEST] <Mavrik> Yeah, thing is that HEVC covers pretty much all devices [17:28:19 CEST] <Mavrik> And VP9 doesn't [17:28:29 CEST] <Mavrik> So when you need to pay for encode/storage... VP9 might not make sense [17:28:53 CEST] <Mavrik> (Unless you're as big as Netflix/Google which can save money on less bandwidth) [17:29:12 CEST] <JEEB> on the other hand I've not seen too many cases where I've seen HEVC be good to go [17:29:20 CEST] <furq> does safari even get 1080p on youtube [17:29:22 CEST] <JEEB> mostly utilized because it has the 10bit decoders [17:29:29 CEST] <furq> i thought it was still restricted to the 720p http stream [17:29:39 CEST] <JEEB> not because of compression improvements [17:29:43 CEST] <furq> or did apple finally cave on supporting mpeg-dash [17:29:54 CEST] <JEEB> that was done in JS anyways, no? [17:29:55 CEST] <Mavrik> furq, noone cares because everyone watches youtube on ipad :P [17:30:27 CEST] <JEEB> because if we needed actual native DASH support in browsers chromium wouldn't play that stuff either [17:30:39 CEST] <JEEB> so now we've got all this stuff around JS fed ISOBMFF segments [17:30:50 CEST] <JEEB> (or webm segments for VP9/opus) [17:30:53 CEST] <c3r1c3-Win> I can state that the JWPlayer does DASH using JS. [17:31:13 CEST] <furq> you still need MSE for that to work in js afaik [17:31:19 CEST] <furq> and apparently iOS safari still doesn't have it [17:32:09 CEST] <FishPencil> Seems like most of the battle is getting people to actually agree, not development [17:32:12 CEST] <Mavrik> 4K YT works just fine in Safari [17:32:36 CEST] <Mavrik> Just gets delivered as H.264 [17:32:55 CEST] <Mavrik> FishPencil, that was always the battle when it comes to formats [17:33:06 CEST] <furq> yeah [17:33:22 CEST] <Mavrik> Especially when you have so many rent-seekers [17:33:33 CEST] <c3r1c3-Win> But it's kinda hard to agree when there's no code to test/spec's to build hardware against. [17:34:50 CEST] <c3r1c3-Win> I must admit it's been fun seeing HEVC start it's decent into madness and crashing and burning on the licensing front. [17:34:55 CEST] <FishPencil> We just need one line of formats that aren't gobbled up by MPEG LA to dump development in. Just imagine how nice that would be [17:36:10 CEST] <FishPencil> "one format to rule them all" [17:36:12 CEST] <BtbN> mpeg la is not the problem. [17:36:19 CEST] <BtbN> The other patent pools are. [17:36:46 CEST] <FishPencil> how about anyone who's a patent pool is a problem [17:37:21 CEST] <BtbN> mpeg la had very realistic rules and didn't get in the way of normal users. [17:37:28 CEST] <BtbN> well, still has [17:38:41 CEST] <c3r1c3-Win> I've never had a problem with them. [17:43:26 CEST] <FishPencil> Kind of a cool table https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Patent_license_t… [18:32:48 CEST] <JEEB> c3r1c3-Win: I think the "best" part is that everyone who's read the specification would agree that it's much saner and simpler at various parts than AVC. buut then the corps that decided that MPEG-LA rules wouldn't get them enough shekels :D [18:33:05 CEST] <JEEB> and yea, that whole thing then led a whole bunch of corps to have a plan B [18:33:10 CEST] <JEEB> which is what AV1 is [18:34:33 CEST] <c3r1c3-Win> and so far I'm loving AV1 on all fronts. [18:35:21 CEST] <JEEB> the problem is of course the implementation at the end of the day. hopefully we will get a proper community around whatever AV1 encoder starts looking most promising [18:35:59 CEST] <c3r1c3-Win> JEEB: Have you looked at the AV1 source (or even just the commit history)? [18:36:15 CEST] <JEEB> libaom you mean [18:36:43 CEST] <JEEB> yea, I've built it every now and then but I'm now mostly waiting for all the experiments that were picked to be enabled by default [18:37:03 CEST] <JEEB> libaom currently is very slow because it's also the R&D platform / reference [18:37:48 CEST] <c3r1c3-Win> I've only read the commit history/other's experiences with it. [19:17:43 CEST] <Fyr> guys, when I try -map 0 -c copy, FFMPEG write: unsupported codec on 0:1 mjpeg. [19:17:43 CEST] <Fyr> 0:1 - is a cover art. is there a way to make FFMPEG copy cover art? [19:19:21 CEST] <CoreX> are you trying to copy the whole thing ? [19:20:18 CEST] <Fyr> yes [19:20:31 CEST] <CoreX> -c copy should do it then [19:20:46 CEST] <Fyr> CoreX, it doesn't. [19:22:16 CEST] <furq> what are the input and output containers [19:22:35 CEST] <Fyr> input: FLAC, output: OPUS. [19:23:39 CEST] <furq> https://trac.ffmpeg.org/ticket/4448 [19:23:42 CEST] <furq> there's your problem [19:24:29 CEST] <Fyr> ='( [19:24:33 CEST] <furq> apparently opusenc will do it automatically [19:24:44 CEST] <Fyr> the developers never read the bug tracker. [19:24:57 CEST] <furq> contributions welcome [19:25:33 CEST] <Fyr> some of them even 7 years old. [19:26:04 CEST] <JEEB> well some tickets should just be closed if there is no information etc, but yes - only more or less one guy cares about the issue tracker [19:27:08 CEST] <JEEB> ffmpeg-devel is the generally read medium on both IRC and ML, but non-technical reports (which is what will mostly get onto the issue tracker) is frowned upon [19:27:42 CEST] <JEEB> I do poke at some issues on the tracker as I notice them being posted/edited on the -devel IRC channel [19:28:27 CEST] <JEEB> but those are only such that I have an interest of or happen to know :P [19:29:36 CEST] <Fyr> could you recommend a tool that converts list of files with copying full information about them, including cover art? [19:30:27 CEST] <marlenka> its possible with ffmpeg do a invisible digital watermarking to video and posible read it again back? Invisible for Human eyes (copyrights) [19:30:54 CEST] <marlenka> thx for answers [19:33:14 CEST] <ayum> Hi, When I using nvenc codec to encoding 1080p@25 fps stream, CPU used 40~50%, is it normally? [19:33:35 CEST] <JEEB> marlenka: I don't think there's a filter for that [19:33:54 CEST] <JEEB> marlenka: of course nothing stops you from making such a filter if you have a standard for that (or just using an overlay) [19:34:06 CEST] <Fyr> ayum, when I encode with NVENC, it's about 1-2%. [19:34:31 CEST] <ayum> yes, somewhere wrong [19:35:10 CEST] <ayum> used old version CUDA will it cause this problem? [19:36:43 CEST] <Fyr> ayum, do you use only the encoder or both the encoder and the decoder? [19:37:35 CEST] <ayum> @Fyr, seems my mistake. I use htop to check ffmpeg process CPU usage. it show used 50%, but entire CPU only used 6%. [19:37:50 CEST] <ayum> perhaps, 50% usage is single core? [19:38:40 CEST] <ayum> @Fyr, I think it's my mistake, sorry bother you [00:00:00 CEST] --- Mon Oct 16 2017

1 0

ffmpeg-devel.log.20171014
by burek 15 Oct '17

15 Oct '17

[01:29:02 CEST] <cone-568> ffmpeg 03James Almer 07master:854c4e974db9: configure: add a -lstdc++ flag to the some external library checks [01:29:02 CEST] <cone-568> ffmpeg 03James Almer 07master:fa5e71a815ef: configure: add missing pthreads extralib to the libilbc check [01:29:02 CEST] <cone-568> ffmpeg 03Reino Wijnsma 07master:458783315b8f: configure: switch the libzvbi check to pkg-config [01:59:31 CEST] <cone-568> ffmpeg 03James Almer 07master:ad56e8057d8a: configure: force erroring out in check_disable_warning() if an option doesn't exists [01:59:40 CEST] <cone-568> ffmpeg 03James Almer 07release/3.4:7deb7e6acd4f: configure: force erroring out in check_disable_warning() if an option doesn't exists [04:28:59 CEST] <jamrial> right, so the librubberband issue tracker has a report about the missing -lstcd++ on static builds [04:29:09 CEST] <jamrial> reported in March 2015, and ignored since then [04:29:42 CEST] <jamrial> so we can forget it being fixed anytime soon [04:31:48 CEST] <jamrial> my email sent to the libbluray ml is in moderation limbo [04:32:52 CEST] <jamrial> so that leaves libopenmpt as the last library with a broken pkg-config file, if you don't count the dead libxavs [04:33:00 CEST] <jamrial> at least for now [09:50:05 CEST] <beauty> hello [09:50:21 CEST] <beauty> how to stress hls nginx server? [13:38:18 CEST] <ffmpeg> Good moring,how to simulate thousands of clients request? [14:16:01 CEST] <ffmpeg> Good moring,how to simulate thousands of clients request? [14:17:07 CEST] <BtbN> Just because you don't like the answer doesn't mean you should just keep asking the same question over and over. Also, stop cross-posting a non-devel question. [15:01:47 CEST] <ffmpeg> BtbN: thanks [16:04:31 CEST] <jamrial> any comment about what Jörn Heusipp mentioned regarding libstdc++ with static linking? [16:05:35 CEST] <JEEB> multiple C++ stdlibs being around (Even on linux only) make it a PITA [16:05:53 CEST] <JEEB> like, you could be using the thing that you have in llvm/clang, or the usual GNU GCC one [16:05:58 CEST] <JEEB> even mismatching them [16:06:02 CEST] <jamrial> i'm really pissed about configure having worked all this time by pure chance and pixie dust [16:06:25 CEST] <JEEB> preferably it would be the deal of the projects that are done in C++ to handle and know what they were going to be linked against [16:06:37 CEST] <JEEB> because they're the only ones that know it [16:06:50 CEST] <JEEB> of course, how you notice that is... [16:07:27 CEST] <jamrial> maybe we could probe for a c++ library somehow? and use that in checks instead of hardcoding -lstdc++ [16:07:43 CEST] <JEEB> yea, but is it really our job? [16:07:52 CEST] <JEEB> I mean, sure. upstreams don't want to fix their jack [16:08:00 CEST] <JEEB> but we're not a C++ project [16:08:25 CEST] <JEEB> if I recall correctly zimg just expects you to use lstdc++ unless you set a flag [16:08:55 CEST] <JEEB> https://github.com/sekrit-twc/zimg/blob/master/configure.ac#L55 [16:09:05 CEST] <JEEB> and then that gets put into the pc file [16:12:06 CEST] <jamrial> fucking static linking [16:12:30 CEST] <JEEB> ayup [16:12:51 CEST] <jamrial> worst part is that some library checks probably only worked if you also checked for another library before it [16:13:20 CEST] <JEEB> I consider this to be a problem, but I'm not sure if pkg-config can fix it so it will have to be fixed in the upstreams, making the required checks and noting the c++ stdlib that is used to build that specific module [16:13:37 CEST] <JEEB> and most certainly I'm not sure if *we* should be working around it [16:14:15 CEST] <JEEB> we most certainly can double our C++ checks to first try without a stdlib, and if it fails then try with the stdlib included. but does that send the right signal to the C++ projects? [16:14:45 CEST] <jamrial> no [16:14:50 CEST] <jamrial> do i revert 854c4e974d then? [16:15:22 CEST] <JEEB> as we can see from zimg, the author clearly has put the minimum amount of effort there :P so we have a precedent of a C++ upstream doing something about it [16:15:25 CEST] <JEEB> lemme se [16:15:45 CEST] <nevcairiel> clearly pkg-config is not meant for c++ projects, if it apparently cant solve it [16:16:12 CEST] <JEEB> nevcairiel: how would pkg-config know which stdlib with the project was originally built/linked against? [16:16:20 CEST] <JEEB> the project has to tell it and put the flag there [16:16:33 CEST] <JEEB> the one who generates the pkg-config file is responsible [16:17:17 CEST] <JEEB> jamrial: yea . while that might fix some things there's no way of f.ex. overriding it. so either improvement is required, or we revert it and tell people to fix their jacks [16:18:06 CEST] <JEEB> also so many projects missing the pthread lib [16:18:08 CEST] <nevcairiel> static linking and c++ requires very careful control anyway [16:18:08 CEST] <jamrial> oh wow, x265 pkg-config file doesn't list -lpthread for static builds [16:18:11 CEST] <jamrial> fuck this shit [16:18:22 CEST] <JEEB> yes, I just told someone on #ffmpeg to report it and fix it manually in his pc file [16:18:41 CEST] <jamrial> how many projects so far we found didn't add the math and pthreads library? [16:18:59 CEST] <nevcairiel> i think its rather braindead of whoever designed libm to be standalone anyway [16:19:08 CEST] <nevcairiel> shove it into the crt and solve so many issues [16:19:26 CEST] <jamrial> sure, but since it's not, just fucking add it to the .pc file if needed [16:19:45 CEST] <nevcairiel> maybe we should just link libm globally everywhere, all of our libraries link against it anyway, and solve some headaches =p [16:19:53 CEST] <jamrial> opening a ticket in x265... [16:20:04 CEST] <JEEB> cheers, since that project at least is alive unlike some others [16:20:07 CEST] <jamrial> nevcairiel: probably a good idea [16:22:25 CEST] <kurosu> and now waiting for the case where ffmpeg has to link against 2 libs that use different c++/stl libs [16:22:48 CEST] <nevcairiel> that has never been possible and will never be, at least not with static linking [16:24:39 CEST] <JEEB> yes, that case is just something you don't support [16:24:47 CEST] <JEEB> they can have their broken garbage if someone attempts [16:39:25 CEST] <jamrial> https://pastebin.com/9CvcmdXC so x265 purposely removes pthreads from libs.private [16:40:18 CEST] <ubitux> probably because it depends on the compiler? [16:40:40 CEST] <nevcairiel> static linking and big differences in compilers dont really mix anyway [16:41:01 CEST] <JEEB> yea, the only way to know is to know if you used pthreads when creating the library [16:41:18 CEST] <jamrial> ok so, we add libm_extralibs to global extralibs, and probably also pthreads_extralibs then? [16:41:30 CEST] <ubitux> it might be wise [16:41:41 CEST] <jamrial> otherwise we'll be adding them to each external library check as users report breakages [16:41:41 CEST] <ubitux> why libm btw? [16:41:46 CEST] <JEEB> such a clusterduck [16:41:50 CEST] <JEEB> ubitux: some miss that [16:42:02 CEST] <ubitux> define <some>? [16:42:02 CEST] <jamrial> ubitux: libm_extralibs evaluates to -lm or nothing, depending on system [16:42:13 CEST] <ubitux> alright, so just like pthread then [16:42:42 CEST] <JEEB> jamrial I think went through it [16:42:49 CEST] <JEEB> wrt what were missing math lib [16:42:51 CEST] <nevcairiel> pthreads might be annoying, not every of our libs links to it [16:43:16 CEST] <jamrial> true [16:43:39 CEST] <jamrial> i'll start with libm for now [17:27:05 CEST] <Zeranoe> I'm now providing macOS 64-bit builds targeting 10.10 and newer. Could I be added under the OS X download section? [17:29:10 CEST] <Zeranoe> Let me know if this request belongs on the ML. [17:32:11 CEST] <atomnuker> yeah, send a patch as usual [17:33:53 CEST] <Zeranoe> Will do [18:24:04 CEST] <jamrial> nevcairiel: avutil links to pthreads, so virutally everything else will [18:30:29 CEST] <jamrial> anyway, patches in the ml [20:36:38 CEST] <nevcairiel> what would one consider a "normal" bicubic scaler? b-spline? [00:00:00 CEST] --- Sun Oct 15 2017

1 0

ffmpeg.log.20171014
by burek 15 Oct '17

15 Oct '17

[00:57:36 CEST] <tony__> Hello ladies, gents. Ive been trying to crack this one for a while with no luck. [00:57:43 CEST] <tony__> We have a screenshot (jpeg) taken from an mp4 clip, that was color-corrected using `imagemagick -modulate` (http://www.imagemagick.org/Usage/color_mods/#modulate) We are trying to capture a 1 sec. clip in the original video starting at the time where the screenshot was taken, and we would like to apply the same color corrections to the clip. [00:57:48 CEST] <tony__> Im having a hard time converting the imagemagick modulate values to something ffmpeg will understand. Per the IM docs. [modulate] takes three values & as a percentage such that 100 will make no change to an image. [00:57:54 CEST] <tony__> Im using ffmpegs -filter:v hue=h=0.12:s=1.18:b=0.96" but of course I cant use the values from IMs modulate literally. [00:57:59 CEST] <tony__> Hopefully someone can point me in the right direction here. [01:00:16 CEST] <DocHopper> SonicTheHedgehog: Turns out my compilation isn't working. I was just calling my old ffmpeg because it was globally referenced. [01:00:36 CEST] <SonicTheHedgehog> DocHopper: hah. yeah, you need to call the new one ... those pesky environment variables, eh ;( [01:00:52 CEST] <DocHopper> And when I do call the new one, nothing happens... [01:00:57 CEST] <SonicTheHedgehog> huh. [01:02:01 CEST] <DocHopper> Also, when I remove the environmental variable for my original ffmpeg, I can no longer call it locally. [01:02:27 CEST] <SonicTheHedgehog> ... going into the binary directory and invoking it from there doesn't work? [01:03:43 CEST] <DocHopper> bin? [01:04:57 CEST] <durandal_1707> tony__: you would need to find out what im uses for calculations [01:11:07 CEST] <tony__> @durandal_1707 Yeah, based on the docs in the above link, I can figure out the conversion for hue, but for brightness and saturation Im stumped. [01:11:07 CEST] <tony__> e.g. [01:11:07 CEST] <tony__> -modulate 0 <- black image [01:11:07 CEST] <tony__> -modulate 100. <- no change [01:11:07 CEST] <tony__> How could I translate that to ffmpegs expected values for the same [01:11:07 CEST] <tony__> Ffmpegs docs: Specify the saturation in the [-10,10] range. It accepts an expression and defaults to 1. [01:11:45 CEST] <durandal_1707> tony__: brightness is not saturation [01:12:37 CEST] <tony__> oops yeah. Saturation/brighness take the same value range in ffmpeg though, so it's the same conversion. [01:13:46 CEST] <durandal_1707> the same algo for im and ffmpeg may not be [04:07:49 CEST] <beauty> Could jmeter test hls video stream??? [07:45:32 CEST] <ThugAim> lets try again [07:45:55 CEST] <ThugAim> !s westworld.s01e02 [07:47:01 CEST] <ThugAim> wrong chan!!! [07:47:05 CEST] <ThugAim> ughhh [07:55:41 CEST] <Johnjay> lol... [08:32:04 CEST] <dystopia_> morning all [08:32:33 CEST] <dystopia_> im trying to capture a desktop window by following this https://trac.ffmpeg.org/wiki/Capture/Desktop [08:33:07 CEST] <dystopia_> but it errors out saying no such source [08:33:22 CEST] <dystopia_> [dshow @ 03337800] Could not find video device with name [screen-capture-recorder] among source devices of type video. [08:42:13 CEST] <dystopia_> ok it's work [08:42:18 CEST] <dystopia_> working* [08:42:33 CEST] <dystopia_> i didn't realise it was an extra application i need to install :p [10:16:53 CEST] <ffmpeg> hello [10:17:11 CEST] <ffmpeg> how to stress hls nginx server? [10:50:36 CEST] <dan3wik> Stress? [10:50:38 CEST] <dan3wik> In what way? [10:50:48 CEST] <dan3wik> DDoS or normal operation stress? [11:27:12 CEST] <ffmpeg> normal operation stress [11:27:17 CEST] <ffmpeg> DDos is ok too [11:28:01 CEST] <ffmpeg> I want to simulate thousands of client request server [12:52:48 CEST] <beauty> How to simulate thousands of clients request sever? [13:07:59 CEST] <BtbN> get thousands of clients and make them hammer the server. [13:15:41 CEST] <beauty> BtbN: that sounds great. But I only have two client machine.l [13:37:40 CEST] <ffmpeg> Good moring,how to simulate thousands of clients request? [13:38:34 CEST] <BtbN> The answer has not changed. You cannot simulate load. [13:39:14 CEST] <ffmpeg> BtbN: sorry, I offline just now. Could you answer again? [13:42:25 CEST] <ffmpeg> I have used sb_bench. [13:42:49 CEST] <ffmpeg> But it has some disadvantages [14:09:37 CEST] <Guest42470> Hello everybody! Could You give me a hint, please, I'm trying to embed a watermark in the video, made by videocam Panasonic (not sure about model), but after embedding, there are horizontal lines there time to time and if I scroll video, it hangs for few seconds, but I can hear the sound... [14:09:50 CEST] <Guest42470> Could You advice me, please, what could I do wrong? [14:12:04 CEST] <Guest42470> The command is here: ffmpeg -i 00025.MTS -i logo.png -filter_complex "[1]scale=770:183[logo], [0:v][logo]overlay=30:870" -c:v libx264 -crf 23 -c:a copy 00025-out.MTS [14:15:12 CEST] <Guest42470> I compared the video properties and source video has "Scan type: Interlaced", but the output has "Progressive", and also source has "Frame rate: 25.000", output has "Frame rate: Variable" [14:15:16 CEST] <iive> Guest42470: can't help with all issues, but most codecs don't like when image resolution is not multiple of 2. if interlaced, then lines should be minimum multiple of 4 . [14:15:49 CEST] <Guest42470> Ah, so should I just resize my png-file? [14:15:55 CEST] <ffmpeg> Good moring,how to simulate thousands of clients request? [14:16:00 CEST] <iive> scale is resizing [14:16:28 CEST] <Guest42470> I mean, to do scale parameters dividable by 4? [14:17:00 CEST] <JEEB> ffmpeg: just please stop spamming - just google "jmeter hls" [14:17:17 CEST] <iive> the video is mostly already muliple of 4 [14:22:08 CEST] <Guest42470> But I still don't understand... If the source video is 1920x1080, already encoded, and I just "replace" particular area with a watermark... Well, I understand, that the whole frame will be re-compressed again, but how to prevent such damage? [14:22:30 CEST] <kerio> i don't think there's a way [14:23:14 CEST] <ffmpeg> JEEB: yeah I have installed that. But jmeter can simulate truely? After google, I found a rechargeable jmeter. [14:23:51 CEST] <ffmpeg> I don't know if jmeter simulate truely. [14:24:15 CEST] <BtbN> again: You cannot simulate actual load from 1000 clients, without actually having 1000 clients. [14:24:24 CEST] <JEEB> if the plugin you will be using actually loads up playlists and downloads them [14:24:31 CEST] <JEEB> and acts like an actual client [14:24:40 CEST] <JEEB> then that will be quite relatively close to an actual load of a single player [14:25:15 CEST] <BtbN> you will run out of bandwidth and resources before getting even close to 1k clients [14:28:17 CEST] <Guest42470> Change image size and offset to dividable by 4 did not help at all :( [14:29:16 CEST] <BtbN> is your video interlaced? [14:29:59 CEST] <Guest42470> Source video - yes, but after processing - it's progressive [14:30:30 CEST] <BtbN> well, there you have your issue then. [14:31:39 CEST] <Guest42470> Should it be also interlaced after processing or should I specify some other options to fully and properly convert it to progressive? [14:31:54 CEST] <BtbN> I doubt the overlay filter works with interlaced images [14:31:59 CEST] <BtbN> So you'll have to deinterlace it first. [14:32:34 CEST] <DHE> or mark the output as interlaced if you prefer [14:33:20 CEST] <ffmpeg> BtbN: why so? [14:33:43 CEST] <BtbN> DHE, that won't help with the overlay filter. [14:34:25 CEST] <Guest42470> haha, it seems, I start to understand, what 1080p and 1080i means :) Thank You all, I try now :) [14:34:33 CEST] <ffmpeg> BtbN: I know that, I could beyond network limitation. [14:35:22 CEST] <ffmpeg> JEEB: do you mean what this website said? https://www.blazemeter.com/blog/how-load-test-http-live-media-streaming-hls… [14:35:36 CEST] <JEEB> ffmpeg: do your own research, it's unrelated to FFmpeg [14:35:55 CEST] <JEEB> better go ask the jmeter people if you need support [14:36:03 CEST] <JEEB> since effectively that is what you need support with [14:37:17 CEST] <DHE> load testing? that's not ffmpeg's job. it makes the video. for an HLS load test just use `ab` and tune your HTTP server appropriately [14:37:49 CEST] <JEEB> or ab if ab can simulate an HLS client [14:38:18 CEST] <JEEB> something like jmeter lets you do the full shebang if you also have an API that provides clients the playback credentials etc [14:38:36 CEST] <JEEB> but yea, out of topic here [14:39:15 CEST] <DHE> oh that's cool... [14:46:06 CEST] <Guest42470> BtbN, thank You very much, it helped me to solve 80% of the problem :) Video seems to be clear :) [14:46:53 CEST] <Guest42470> Used filter "yadif=0:-1:0" before overlaying [14:47:52 CEST] <BtbN> you should put yadif in frame doubling mode [14:48:23 CEST] <Guest42470> Oh, could You tell me, please, what does it mean or just how to do it? ;) [14:49:05 CEST] <Guest42470> The documentation looks a bit poor: https://ffmpeg.org/ffmpeg-filters.html#yadif-1 [14:49:57 CEST] <BtbN> "Output one frame for each field." [14:50:02 CEST] <BtbN> doesn't look poor to me? [14:50:37 CEST] <JEEB> yadif=mode=send_field:deint=interlaced is what you want most likely unless your content is not signaled as interlaced, in which case you want deint=all [14:50:40 CEST] <Guest42470> Ah, that's You mean :) Thank You, let me try :) [14:51:01 CEST] <JEEB> (these options do become more readable when you stop just sticking numbers without their options in there) [14:53:25 CEST] <Guest42470> Sorry, I'm not so familiar with video formats, but thank You for helping :) Just converting now, it will take a while [14:56:24 CEST] <Guest42470> Wow, now it has 50fps... But could You explain, please, what happened? The video looks the same, but says 50 fps now... [15:13:30 CEST] <Guest42470> So please, could You also help with the second problem? I don't know much about keyframes, but I noticed, some of the videos can be scrolled to any position, some - video will hang for a few seconds (until the next key frame as I understand) [15:14:04 CEST] <Guest42470> So could You give me an advice, what should I take care during the conversion to avoid such problem? [15:35:13 CEST] <Guest42470> Ok, just set "-x264opts keyint=25:min-keyint=25:scenecut=-1" - seems, it solved the problem, but now the size of the file is about 1.5x more... But as I noticed, in the source video GOP: M=3, N=12, but in the output GOP is: M=4, N=25... Is it the right direction solution or not so? [15:42:33 CEST] <suddened_vidist> Hi there! [15:42:45 CEST] <suddened_vidist> I found this page [15:42:45 CEST] <suddened_vidist> https://trac.ffmpeg.org/wiki/StreamingGuide [15:43:01 CEST] <suddened_vidist> Which seems to be outdated, cuz i wasn't able to use the "-re" flag. [15:43:25 CEST] <c_14> -re exists [15:43:29 CEST] <suddened_vidist> And so i'm still in need of a way to make my ffmpeg "simulate a grab device" [15:43:31 CEST] <c_14> Your version of ffmpeg might be outdated [15:43:50 CEST] <suddened_vidist> Ae. [15:43:51 CEST] <suddened_vidist> Aw. [15:44:09 CEST] <c_14> what os? [15:44:35 CEST] <suddened_vidist> Shindoshz. [15:44:45 CEST] <suddened_vidist> Microsoft shindoshz. [15:45:05 CEST] <suddened_vidist> Well, yea, i was sticking the flag into a wrong place. [15:45:17 CEST] <suddened_vidist> Thought it's supposed to come after -i sources. [15:45:22 CEST] <c_14> nah, before [15:52:23 CEST] <Guest42470> Could You explain, please, why should I use frame doubling mode? Is there any profit from it? [15:57:58 CEST] <c_14> Well, the alternative is throwing away half your video data [16:09:40 CEST] <Guest42470> Ouch... how is it? [16:10:07 CEST] <Guest42470> Please, could You explain a bit more detailed? :) [16:10:42 CEST] <c_14> Interlaced video uses 2 fields per frame [16:11:00 CEST] <c_14> So a 30 frames per second video has 60 fields per second [16:11:13 CEST] <c_14> If you deinterlace, you either throw away half the fields and make it 1 frame per field [16:11:21 CEST] <c_14> Or you use all the fields and get 2 frames per field [16:12:17 CEST] <Guest42470> So if after deinterlace I have 60 frames per second - is it not a problem? So is there no redundant data? [16:13:44 CEST] <c_14> It's not a problem, no [16:16:59 CEST] <Guest42470> For me a file size is a bit important though... so if I have with -crf 23 a file size like 1.5x bigger than source video... so can I reduce frame size back to 30 or just decrease bitrate with -crf option? [16:17:38 CEST] <c_14> You can pick a higher crf, sure [16:17:45 CEST] <c_14> You can also drop frames if that's more important to you [16:17:54 CEST] <c_14> (use send_frame instead of send_field) [16:18:14 CEST] <kerio> well, 60fps interlaced video doesn't really have 60 frames' worth of information per second [16:18:41 CEST] <Guest42470> Yes, this is a question - is it worth to keep 60fps [16:18:48 CEST] <kerio> interlacing is both a temporal filter and a spatial filter [16:19:02 CEST] <kerio> Guest42470: i'd say deinterlace to 60 [16:19:11 CEST] <kerio> if the frames are similar they'll compress nicely anyway [16:20:26 CEST] <Guest42470> Well, its about 45 Mb test file with 30fps and 56 Mb with 60 :) So there is a bit difference [16:21:35 CEST] <Guest42470> But well, by deinterlacing, when I send frame instead of field, aren't those fields being "welded" into one frame? [16:21:49 CEST] <Guest42470> Or mixed, how to say... [16:25:54 CEST] <JEEB> depends on the deinterlacer [16:26:11 CEST] <JEEB> if the images are pretty much the same without motion that is doable [16:26:30 CEST] <JEEB> but as soon as there is motion you will have to start separating the images and building stuff [16:27:31 CEST] <Guest42470> But is there any way to safely reduce frame rate back? [16:28:18 CEST] <Guest42470> Or the only way to reduce file size without injure the video so much - is only increase -crf? [16:28:28 CEST] <JEEB> "back" is incorrect anyways since you're dealing with 60 images (fields) per second, instead of 30 pictures (be it fields or frames) [16:28:46 CEST] <JEEB> of course you can just switch the mode to 30 pictures out from 60 fields [16:29:07 CEST] <JEEB> people just generally seem to dislike it because that way it's not as smooth as the interlaced content [16:29:23 CEST] <kerio> and also wrong [16:29:36 CEST] <JEEB> technically yes, if your idea is to keep every field in the output [16:30:08 CEST] <BtbN> I really wonder why the default is to discard half the fields [16:30:10 CEST] <kerio> what if my video alternates a full black image and a full white image at 60hz [16:30:21 CEST] <JEEB> BtbN: hysterical raisins [16:30:30 CEST] <Guest42470> Well, after deinterlacing with -crf 23 (as I understand, default value) the video track size was grown about 3 times... I try to put it to original size :) [16:30:44 CEST] <JEEB> the original size really doesn't matter since you're decoding that [16:30:51 CEST] <BtbN> lower the quality then [16:30:53 CEST] <JEEB> basically if your source was already compressed to hell [16:31:15 CEST] <JEEB> then doing that once again will not help the quality, and thus one should just forget trying to seek "the same size" [16:31:57 CEST] <Guest42470> ... yeah, I think, there is no way to make better quality than it was in source video by increasing bitrate [16:32:32 CEST] <JEEB> of course not making it better, but you are also compressing the artifacts of the original encode [16:32:51 CEST] <JEEB> + you no longer have 1920x540 60 times a second, but instead 1920x1080 60 times a second, for example [16:33:00 CEST] <JEEB> also if you use a short GOP length that will not help compression [16:34:18 CEST] <Guest42470> But I'm still curious, how does it fits all that data in the source file... [16:34:40 CEST] <BtbN> it fits less data in the original file. [16:34:48 CEST] <BtbN> You are doubling the vertical resolution. [16:36:17 CEST] <Guest42470> Oh, just tried to use -crf 30 - the file size became about the same, but the quality was degraded noticeable... [16:36:33 CEST] <Guest42470> Maybe should I interlace it back after embed a watermark? [16:37:37 CEST] <kerio> :| [16:38:04 CEST] <JEEB> Guest42470: also your original file only had the original content as source [16:38:10 CEST] <JEEB> not the additional compression artifacts etc [16:38:37 CEST] <JEEB> as I said, they are not equal 1) in the vertical resolution (you're making fields into frames), and 2) in the fact that you don't have the same source to begin with [16:38:57 CEST] <JEEB> which is why the first thing that people have to get their head around is that the initial file size Just Doesn't Matter [16:39:12 CEST] <JEEB> you're not encoding the same source, and if you're doing filtering there's even extra stuff going on [16:47:10 CEST] <Guest42470> "but you are also compressing the artifacts of the original encode" - what does it mean? Does it mean, that before video was encoded first time, it was quite smooth, but then by the first compression some areas were devostated due to lossy compression. And now the codec has no chance to recognize them as the identical area and compress again the same way? [16:47:22 CEST] <JEEB> yes [16:47:44 CEST] <JEEB> so it has gone through lossy compression once, so you not only have the content that you're trying to compress, but also the additional artifacts [16:48:03 CEST] <JEEB> plus the fact of course that since you're doing deinterlacing all the pictures have twice the height since you've moved from fields to frames [16:48:06 CEST] <kerio> just make a deinterlacer for h264 duh :^) [16:48:35 CEST] <JEEB> that makes absolutely no sense since this has nothing to do with interlacism [16:48:49 CEST] <JEEB> it's a general thing where you have already once mucked with something [16:49:17 CEST] <JEEB> and thus you stick to not re-encoding it because that would end up with less quality or larger file size [16:49:26 CEST] <JEEB> unless you get access to the actual source [17:10:15 CEST] <Guest42470> Ok, thank You very much for explaining, now I will try to experiment and look, what kind of parameters are acceptable by the produced quality :) [19:43:42 CEST] <rabbe> will rtsp give me lower latency than rtmp? [19:43:50 CEST] <rabbe> using vlc as player [20:40:02 CEST] <diqidoq> what would be the best h264 codec available under --codecs to use under linux/debian for converting dnxhd .mov to smaller mkv? Its full HD atm and I would like to scale it down to 720p. [20:40:23 CEST] <JEEB> x264 gives the best bang for the buck [20:40:43 CEST] <diqidoq> JEEB: thanks for your fast reply! [20:41:01 CEST] <JEEB> it defaults to preset medium and CRF 23 [20:41:08 CEST] <JEEB> preset is the speed VS compression thing [20:41:18 CEST] <diqidoq> JEEB: perfect for this approach! [20:41:28 CEST] <JEEB> and CRF is one of the closest to "constant quality" things we have [20:41:38 CEST] <JEEB> so I would recommend you try to encode like 2500 frames or so [20:41:56 CEST] <diqidoq> JEEB: you rock! as always! [20:41:58 CEST] <JEEB> with different presets and then after you've picked you can tweak the CRF if 23 looks bad [20:42:15 CEST] <diqidoq> JEEB: thanks a million. [20:42:17 CEST] <diqidoq> JEEB++ [20:42:25 CEST] <JEEB> you can use -ss before the input to seek to a specific position if you know that the beginning of the clip isn't good to check quality [20:42:35 CEST] <JEEB> and then -vframes 2500 is "encode 2500 frames" :) [20:42:43 CEST] <JEEB> or you can use something like -t 90 which is "encode 90 seconds" [20:43:26 CEST] <diqidoq> JEEB: yeah love this tiome features! [20:43:36 CEST] <diqidoq> s/tiome/time [20:43:41 CEST] <JEEB> :) [20:43:47 CEST] <diqidoq> :) [20:43:58 CEST] <JEEB> basically the defaults for libx264 are: -c:v libx264 -crf 23 -preset medium [20:44:07 CEST] <JEEB> do note that the CRF value's result is not the same between presets [20:44:15 CEST] <JEEB> which is why I recommend testing with a limited clip [20:44:18 CEST] <JEEB> and first pick the speed [20:44:22 CEST] <diqidoq> I see [20:44:24 CEST] <JEEB> and then the CRF value [20:44:37 CEST] <JEEB> of course if 23 looks good enough you can just use that [20:44:38 CEST] <JEEB> :) [20:46:04 CEST] <diqidoq> JEEB: For me ffpmeg should be the first lesson a film editor has to learn in school! [20:46:13 CEST] <diqidoq> :) [20:46:28 CEST] Action: diqidoq goes trying ... [20:47:31 CEST] Action: diqidoq encoding runs... [20:47:48 CEST] <diqidoq> cpu runs ... :) [20:48:38 CEST] <diqidoq> JEEB: quality is perfect. Now I have to scale down. [20:51:12 CEST] <diqidoq> How can I prevent forcig hight to scale proportional: can I simply leave out the hight? scale=720: [20:51:30 CEST] <JEEB> no [20:51:41 CEST] <JEEB> also please use the names for the parameters [20:51:52 CEST] <JEEB> scale=w=720:h=-2 for example [20:52:20 CEST] <JEEB> negative is "auto" according to the aspect ratio of input, and two means "make it divisible by two" [20:53:06 CEST] <diqidoq> JEEB: got it. smart! [20:53:53 CEST] <diqidoq> JEEB: before -c:v or after? does it matter in the convertion steps? [20:54:14 CEST] <JEEB> only before/after input matters [20:54:24 CEST] <diqidoq> I see ... [20:54:31 CEST] <JEEB> (and of course if you have multiple outputs it kind of matters where options are) [20:54:42 CEST] <diqidoq> JEEB: thank you, again, for your advices. [21:02:59 CEST] <sonbaty> hi [21:04:54 CEST] <sonbaty> its possible with ffmpeg adding to video invisible digital watermark and reading this watermark? [21:14:26 CEST] Action: sonbaty [21:26:08 CEST] Action: sonbaty hi all [21:26:27 CEST] Action: sonbaty its possible with ffmpeg adding to video invisible digital watermark and reading this watermark? [21:49:56 CEST] <ArgentineUser> Hi ! ;D [21:54:02 CEST] <sonbaty> hi [23:15:13 CEST] <Cracki> how would I query ffmpeg for options of a specific codec? I'm thinking of h264_qsv/cuvid/nvenc [23:15:23 CEST] <Cracki> (encoding specifically) [23:15:49 CEST] <BtbN> -help encoder=... [23:15:58 CEST] <Cracki> oh! thx [23:16:04 CEST] <BtbN> or codec= not 100% sure [23:16:18 CEST] <Cracki> first one [23:17:00 CEST] <Cracki> decoder/encoder/demuxer/muxer/filter [23:17:12 CEST] <Cracki> awesome thx [00:00:00 CEST] --- Sun Oct 15 2017

1 0

ffmpeg-devel.log.20171013
by burek 14 Oct '17

14 Oct '17

[00:00:26 CEST] <atomnuker> TD-Linux: apparently not in the EU, https://ffii.org/Frequently%20Asked%20Questions%20about%20software%20patents [00:00:40 CEST] <atomnuker> (under "source code privilege") [00:01:13 CEST] <atomnuker> nvm, that's for a draft, idk then [00:01:15 CEST] <ubitux> (wtf @ cthulu) [00:02:23 CEST] <BtbN> cthulu? [00:02:55 CEST] <ubitux> libav didn't know how to name a variable [00:03:09 CEST] <ubitux> cthulu = (a >= 0) + (a ^ (a >> 31)) - (a >> 31); [00:04:02 CEST] <ubitux> (i wouldn't either, but that's a strange name neverless) [00:04:22 CEST] <ubitux> though it looks like a pattern i already saw [00:04:34 CEST] <BtbN> Well, some of the code at work has various colors of magic all over the code [00:05:52 CEST] <BtbN> (a ^ (a >> 31)) - (a >> 31) certainly looks familiar. But I have no idea what it does. Some proper variable name would have been nice [00:07:07 CEST] <durandal_1707> yes, dont_rename_me [00:08:32 CEST] <BtbN> Does it just count the 1 bits? [00:09:23 CEST] <durandal_1707> also its unneeded because michaelni simplified it abd they didnt pick our change as usual [00:10:07 CEST] <ubitux> what about the reconfiguration part? [00:10:37 CEST] <ubitux> and NB_LEVELS? [00:11:00 CEST] <durandal_1707> size_t change is pointless [00:11:25 CEST] <ubitux> "reinit should dimensions change" [00:11:29 CEST] <ubitux> i'm not sure what that mean [00:11:36 CEST] <ubitux> but that part may have some value? [00:11:57 CEST] <ubitux> (missing "handle" probably) [00:13:34 CEST] <durandal_1707> nb levels is fine [00:13:44 CEST] <cone-361> ffmpeg 03Ivan Kalvachev 07master:3a6ded7cfcb3: Fix crash if av_vdpau_bind_context() is not used. [00:13:46 CEST] <durandal_1707> change* [00:15:10 CEST] <cone-361> ffmpeg 03Ivan Kalvachev 07release/3.4:7fb85ad3607a: Fix crash if av_vdpau_bind_context() is not used. [00:16:46 CEST] <cone-361> ffmpeg 03James Almer 07master:4b175913bed8: build: fix builds configured with a suffix [00:19:24 CEST] <ubitux> k, so i'll push that in a moment [00:20:34 CEST] <ubitux> jamrial: are you in the middle of a merge? [00:20:50 CEST] <jamrial> ubitux: no, i'm fixing shit from the extralibs merge :p [00:21:05 CEST] <jamrial> been doing that all day [00:25:46 CEST] <cone-361> ffmpeg 03Clément BSsch 07master:368fb74831c0: lavc/pixlet: reduce diff with Libav (cosmetics only) [00:25:47 CEST] <cone-361> ffmpeg 03Clément BSsch 07master:d1aef7d08a06: lavc/pixlet: remove unecessary intermediate nb_levels variable [00:25:57 CEST] <nevcairiel> I can make you a Mac config.mak in a bit if you still need it. Been out all evening and only on the phone [00:26:07 CEST] <ubitux> jamrial: you have all my sympathy. [00:26:19 CEST] <jamrial> nevcairiel: ok, thanks [00:26:39 CEST] <jamrial> and yeah, i'm curious about what extralibs get added to each library [00:27:06 CEST] <ubitux> durandal_1707: no opinion on the explicit i16 sat jamrial mentioned? [00:27:24 CEST] <ubitux> (line_add_sat_s16) [00:27:49 CEST] <ubitux> anyway, my job is done here [00:28:17 CEST] <durandal_1707> ubitux: well i dont think its same thing [00:28:30 CEST] <ubitux> it probably isn't yes [00:28:36 CEST] <ubitux> which one is correct? [00:29:05 CEST] <durandal_1707> maybe it will work better but its not what was in binary [00:29:46 CEST] <durandal_1707> better not merge that clip thing [00:51:56 CEST] <dylanmach1_> hello, i am having trouble compiling and making a static bin of ffmpeg on macOS from the git [00:57:51 CEST] <jamrial> dylanmach1_: can you open a ticket in https://trac.ffmpeg.org/ detailing what's wrong? [00:58:12 CEST] <dylanmach1_> sorry, sure i will try [01:01:50 CEST] <nevcairiel> jamrial: http://termbin.com/7iff1 working ./configure --enable-shared on osx [01:02:32 CEST] <jamrial> nevcairiel: you're not getting issues with avutil's hwcontext_videotoolbox module? [01:02:58 CEST] <nevcairiel> no it build fine [01:03:06 CEST] <nevcairiel> avutil also has -framework VideoToolbox [01:03:29 CEST] <nevcairiel> let me make sure and just do it again [01:03:44 CEST] <jamrial> yeah, but afaik it should also have corevideo [01:03:54 CEST] <jamrial> if anything because it's set as a dep for videotoolbox [01:05:56 CEST] <nevcairiel> i have no idea how the dep resolver works [01:06:30 CEST] <nevcairiel> avutil_extralibs includes all sorts of vaapi and vdpau stuff, but no entry for videotoolbox, maybe it should? [01:07:07 CEST] <cone-361> ffmpeg 03James Almer 07master:9c0279bc2c7b: configure: fix CoreGraphics module name [01:07:17 CEST] <jamrial> nevcairiel: no, look at avutil_suggest [01:07:19 CEST] <wm4> it definitely uses corevideo functions, though strangely no Vt ones [01:07:28 CEST] <nevcairiel> jamrial: that also includes vaapi again [01:07:33 CEST] <nevcairiel> so still not clear [01:07:33 CEST] <nevcairiel> :D [01:08:04 CEST] <jamrial> no, _extralibs includes vaapi_x11 and vaapi_drm :p [01:08:15 CEST] <jamrial> it's a mess of internal modules [01:09:21 CEST] <jamrial> avutil_suggest includes videotoolbox, videotoolbox_deps includes corevideo, coremedia and corefoundation, but they are not showing up in avutil in the end [01:09:39 CEST] <jamrial> it's like avutil is resolved first, then videotoolbox, point where it's already late [01:10:06 CEST] <nevcairiel> from what i can tell, the vdpau x11 functions for example are the only thing it actually links to [01:10:12 CEST] <nevcairiel> it doesnt link to any normal vdpau [01:10:13 CEST] <jamrial> i can just say fuck it and add corevideo, coremedia and corefoundation to avutil_suggest, but you're not getting build failures and it's weird [01:10:16 CEST] <nevcairiel> lets check vaapi [01:10:52 CEST] <jamrial> zeranoe had a build failure because avutil was not adding corevideo [01:11:05 CEST] <nevcairiel> maybe it just should be in extralibs [01:11:45 CEST] <nevcairiel> vaapi_drm_extralibs for example always includes -lva as well, so it would never be missing [01:13:34 CEST] <jamrial> nevcairiel: doing bar_suggest="foo" is the same as doing bar_extralibs="foo_extralibs" [01:14:07 CEST] <nevcairiel> apparently configure disagrees with you [01:14:14 CEST] <jamrial> really? [01:14:20 CEST] <nevcairiel> well its not doing that, is it? :D [01:14:51 CEST] <nevcairiel> also i actually finished the shared build and it fails as well, i might have done a static build earlier [01:15:02 CEST] <wm4> looking forward to the day ffmpeg uses a real build system [01:15:12 CEST] <nevcairiel> as if any of those are any better [01:15:43 CEST] <jamrial> nevcairiel: try adding corevideo coremedia and corefoundation to avutil_suggest [01:16:19 CEST] <jamrial> or their _extralibs to avutil_extralibs. both should be the same [01:16:20 CEST] <nevcairiel> apparently its not doign recursive lookups, or well, maybe its doing that in the wrong order [01:16:37 CEST] <jamrial> yeah, as i said, probably it's resolving avutil first, then videotoolbox [01:16:40 CEST] <jamrial> but it shouldn't [01:17:46 CEST] <jamrial> i'll just add those three to avutil for now, if you confirm it fixes it [01:18:25 CEST] <wm4> nevcairiel: can't be worse than trying to write recursive graph resolver algorithms in shell (which is what configure does, including emulating a stack) [01:26:07 CEST] <cone-361> ffmpeg 03James Almer 07master:4440bcf6a0cf: configure: fix pthread_cancel check [01:29:01 CEST] <cone-361> ffmpeg 03Luca Barbato 07master:abb5efca263d: configure: Fix sem_timedwait probe [01:34:24 CEST] <jamrial> jkqxz: regarding hwcontext_videotoolbox, does it really need videotoolbox? or would corevideo suffice for it? [01:34:39 CEST] <nevcairiel> jamrial: the order of expansions seems fine, but for some reason its not actually expanding the extralibs inside videotoolbox, ie it remains "videotoolbox_extralibs: -framework VideoToolbox corefoundation_extralibs coremedia_extralibs corevideo_extralibs coreservices_extralibs" [01:35:35 CEST] <jamrial> huh [01:35:39 CEST] <wm4> jamrial: corevideo is enough AFAIK [01:35:50 CEST] <wm4> only libavcodec actually calls into VT [01:36:44 CEST] <jamrial> wm4: it's currently including videotoolbox.h, so to make it corevideo only it needs a couple changes at least [01:37:21 CEST] <jamrial> nevcairiel: ah, guess those three should have an entry in some of the lists [01:37:30 CEST] <wm4> oh right [01:37:39 CEST] <wm4> that include is unnecessary, but there, d'oh [01:37:54 CEST] <nevcairiel> jamrial: it appears the final resolver doesnt support endless indirection, it seems to only do 2 levels [01:38:02 CEST] <jamrial> ah [01:38:06 CEST] <jamrial> well damn [01:38:15 CEST] <wm4> LOL [01:38:17 CEST] <wm4> why 2 [01:38:19 CEST] <jamrial> anyway, if it can be simplified to only use corevideo that would be much better [01:38:21 CEST] <nevcairiel> unless i read this wrong [01:38:38 CEST] <wm4> jamrial: I mean, it's part of the API, so it's fucked [01:38:43 CEST] <wm4> (not sure why I did this crap) [01:38:57 CEST] <jamrial> wm4: can't it be made include corevideo.h? [01:39:14 CEST] <wm4> jamrial: hwcontext_videotoolbox.h also includes it, and it's a public header [01:40:14 CEST] <jamrial> mmh, in makefile the file is listed under CONFIG_VIDEOTOOLBOX [01:40:41 CEST] <nevcairiel> lets see where this entry goes missing [01:40:41 CEST] <jamrial> so, can we just make it corevideo, or will it "break" the API? [01:41:06 CEST] <wm4> jamrial: it will "break" it, yes [01:41:19 CEST] <wm4> in theory [01:41:41 CEST] <wm4> personally I'd say the user shouldn't rely on such recursive includes [01:41:44 CEST] <wm4> *API user [01:42:16 CEST] <nevcairiel> yeah for some reason flatten_extralibs doesnt copy all the entries over for avutil, odd [01:42:50 CEST] <wm4> (also I should fix that the hwcontext_videotoolbox.h functions are missing if videotoolbox is disabled at compile time) [01:43:06 CEST] <wm4> (also I should fix that videotoolbox fucking blows up if threads are enabled in lavc) [01:44:29 CEST] <jamrial> just make it corevideo. if the user has videotoolbox, they have corevideo. it's apparently dep of the former after all [01:44:53 CEST] <wm4> definitely [01:48:47 CEST] <nevcairiel> i think i figured out whats wrong, after it processed a _extralibs entry once, it resolves one level of nesting and then removes any remaining _extralibs entries from it, because it thinks it should have already resolved those [01:48:53 CEST] <nevcairiel> and woosh it goes missing [01:49:40 CEST] <jamrial> how to fix it? [01:50:18 CEST] <nevcairiel> unclear [01:52:12 CEST] <jamrial> ok, do i add those three modules to avutil in the meantime? even if wm4 makes it use only corevideo later and if we fix flatten_extralibs [01:52:28 CEST] <jamrial> we really need to get macos shared build back up asap [01:53:49 CEST] <nevcairiel> the issue is in the flatten_extralibs function anyway, for future reference [01:54:19 CEST] <nevcairiel> perhaps it should recurse in the loop or something [01:54:55 CEST] <jamrial> sort of like check_deps does [01:55:12 CEST] <wm4> jamrial: you mean add the corevideo libs etc. directly? sure why not [01:56:17 CEST] <jamrial> wm4: configure currently adds videotoobox to avutil extralibs. i'll make it add all three deps for videotoolbox as well since those are not beign resolved because of a bug in flatten_extralibs [01:56:18 CEST] <nevcairiel> perhaps the eval assignment in the loop should just be removed, thats what clears it out [01:56:36 CEST] <nevcairiel> or hm maybe not [01:56:37 CEST] <jamrial> wm4: but after that, you could make it corevideo only [01:57:52 CEST] <nevcairiel> on second thought, the eval assignment does seem a bit fishy, maybe its trying to speed up lookups or something, but by messing with the extralibs like that, if two things reference the same _extralibs thing, they would not see the same thing [01:58:00 CEST] <wm4> jamrial: that requires a 2 year deprecation period, if going by the book [01:58:08 CEST] <wm4> how do you deprecate include statements [01:58:19 CEST] <jamrial> do they need to be deprecated? [01:58:24 CEST] <nevcairiel> just do it with th e major bump [01:58:34 CEST] <jamrial> i mean, if videotoolbox.h exists, corevideo.h will also exist [01:58:40 CEST] <jamrial> it's not like it will break anything [01:58:49 CEST] <wm4> it all depends whether we consider it part of the API or ABI or anything [02:00:54 CEST] <jamrial> nevcairiel: i'll apply https://pastebin.com/sNQMA1Vq for now, is that ok? [02:01:06 CEST] <nevcairiel> probably? [02:01:35 CEST] <wm4> if it works it's ok [02:02:00 CEST] <jamrial> unless flatten_extralibs can be fixed soon. otherwise mac users will start reporitng en masse :P [02:02:31 CEST] <nevcairiel> its weird diego shell code, who knows what exactly its there for [02:03:03 CEST] <nevcairiel> it definitely seems fishy to mess with the existing entries in such a way though [02:03:51 CEST] <nevcairiel> anyway let me test a build with that changed [02:06:20 CEST] <nevcairiel> yeah builds now [02:07:03 CEST] <jamrial> ok [02:07:06 CEST] <nevcairiel> its fascinating that videotoolbox would be the only component with double nested components which is used in more then one library [02:07:08 CEST] <winegums_> what are the common flags you use for static building? [02:07:21 CEST] <nevcairiel> and apparently libav doesnt have VT yet, so they didnt run into this issue? [02:07:32 CEST] <winegums_> i enabled static, disabled shared, and used the pkg config flag for static [02:07:38 CEST] <cone-361> ffmpeg 03James Almer 07master:34dbee9f601f: configure: explicitly list videotoolbox deps for avutil [02:08:21 CEST] <wm4> Libav still have VDA, but who still builds VDA these days [02:08:32 CEST] <nevcairiel> but no vda in avutil [02:09:36 CEST] <wm4> oh, true [02:10:13 CEST] <nevcairiel> the problem only comes up if two libraries reference the same component, and that component has two levels of nested libraries [02:10:26 CEST] <nevcairiel> nested extralibs* [02:16:28 CEST] <nevcairiel> .. and hardware stuff is probably the only things that are even shared between any libraries [02:16:56 CEST] <jamrial> nevcairiel: videotoolbox is that way because i made it that way to simplify some checks. good to know it revealed a bug :p [02:18:08 CEST] <jamrial> wm4: we also have vda, but it's going to be removed after the bump [02:18:29 CEST] <wm4> good [03:20:46 CEST] <cone-361> ffmpeg 03Kaustubh Raste 07master:27a0a8388082: avcodec/mips: Improve avc chroma avg horiz mc msa functions [03:20:47 CEST] <cone-361> ffmpeg 03Kaustubh Raste 07master:e549933a270d: avcodec/mips: Improve avc put mc 12, 32 and 22 msa functions [03:20:48 CEST] <cone-361> ffmpeg 03Kaustubh Raste 07master:e63758468c64: avcodec/mips: Improve hevc bi copy mc msa functions [03:20:49 CEST] <cone-361> ffmpeg 03Kaustubh Raste 07master:6ca821a3e775: avcodec/mips: Improve hevc uni horiz mc msa functions [03:20:50 CEST] <cone-361> ffmpeg 03Kaustubh Raste 07master:e5439e272ed1: avcodec/mips: Improve hevc uni weighted vert mc msa functions [03:20:51 CEST] <cone-361> ffmpeg 03Gyan Doshi 07master:147c1e008a7b: doc/filters: correct typo and incomplete desc. [09:39:57 CEST] <thebombzen> I think the vf_zscale wrapper is segfaulting for alignment reasons [09:40:14 CEST] <thebombzen> https://0x0.st/CQx.log [15:31:30 CEST] <cone-189> ffmpeg 03James Almer 07master:15dc897582ad: configure: list libv4l2 as an optional library for v4l2 [16:24:48 CEST] <cone-189> ffmpeg 03James Almer 07master:6b52c0b583b8: configure: add missing zlib extralibs to the libmysofa check [17:20:53 CEST] <jamrial> nevcairiel: what do you think about 81bffae368? (libav commit) [17:22:50 CEST] <wm4> so what should we do to get an actually working maintainer system [17:24:08 CEST] <jamrial> wm4: you mean the wtv patch just pinged on the ml? [17:24:21 CEST] <cone-189> ffmpeg 03Daniel Kucera 07master:feed201849b8: libavformat/wtvdec: return AVERROR_EOF on EOF [17:24:21 CEST] <wm4> I just pushed that [17:24:25 CEST] <wm4> but yes [17:24:36 CEST] <jamrial> is Peter Ross still around? [17:24:37 CEST] <wm4> in this case, the maintainer's agreement isn't even necessary [17:24:48 CEST] <wm4> last patch by him was mid 2016 [17:25:25 CEST] <jamrial> guess he didn't see the patch, then everyone else (including nicolas who reviewed it) forgot about it [17:25:50 CEST] <wm4> there's certainly no reason to wait 4 months to apply such a small fix [17:26:05 CEST] <wm4> that only frustrates drive-by contributors [17:26:23 CEST] <jamrial> true [17:27:12 CEST] <jamrial> nicolas could have pushed it himself after a bit. or someone else could have noticed it was such a small change that it didn't need the maintainer to chime in [17:28:01 CEST] <jamrial> but it didn't happen, and it got buried. it sucks, but it happens [17:28:07 CEST] <jamrial> the author could have also pinged much earlier, as well [17:28:15 CEST] <wm4> I interpret that as smug "not my problem" [17:28:26 CEST] <jamrial> no, i mean shit happens [17:28:34 CEST] <jamrial> it's one of the reasons we added patchwork afaik [17:28:36 CEST] <wm4> that too, additonally [17:28:40 CEST] <wm4> *additionally [17:28:44 CEST] <wm4> does anyone use patchwork? [17:28:47 CEST] <jamrial> since patches on the ml get buried often [17:28:54 CEST] <jamrial> almost nobody, and that's the problem [17:29:06 CEST] <wm4> clearly we should switch all development to github [17:29:23 CEST] <BtbN> so we burry issues and pullrequests instead of mails? [17:30:31 CEST] <wm4> yes (also that was sarcasm) [17:30:43 CEST] <wm4> personally I don#t think github would work for ffmpeg [17:31:31 CEST] <BtbN> It would fail because a bunch of people would refuse to work with it. [17:31:40 CEST] <jamrial> what about gerrit? [17:31:53 CEST] <BtbN> So you combine the pain of github and a mailinglist? [17:31:57 CEST] <wm4> the only time I tried gerrit I wanted to die [17:32:19 CEST] <jamrial> BtbN: everyone gets both what they want and what they hate that way :D [17:32:36 CEST] <wm4> anyway, the thing with the maintainer list is mostly a policy/organization issue [17:32:53 CEST] <atomnuker> jamrial: I hope that was sarcasm, gerrit is far far worse than mailing lists and stuff there gets buried way more often [17:33:03 CEST] <wm4> basically the maintainer list is usless [17:33:07 CEST] <jamrial> also that a lot of people mentioned there have long since disappeared [17:33:21 CEST] <jamrial> atomnuker: yes, it was [17:33:44 CEST] <BtbN> gerrit makes sense for massive things like Qt or Android that span accross multiple repos [17:36:56 CEST] <atomnuker> it really doesn't make sense for anything [17:37:18 CEST] <atomnuker> it hardly works too [17:37:47 CEST] <BtbN> How else would you manage patch review for something of the scale of Android? [17:38:47 CEST] <wm4> atomnuker: have you ever use depot-tools [17:43:10 CEST] <atomnuker> no, but seeing its a google thing for chromium only really means that's all I need to know [17:44:57 CEST] <wm4> google uses it for everything [17:45:11 CEST] <wm4> and it's an ultra-clunky POS that forces you to use git in a worse way [17:59:16 CEST] <Gramner> VGF2P8AFFINEINVQB the x86 mnemonics keep getting better [18:11:59 CEST] <wm4> kierank: "Test api-band failed. Look at tests/data/fate/api-band.err for details." [18:12:03 CEST] <wm4> kierank: it was worth it [18:13:04 CEST] <kierank> :) [18:13:05 CEST] Action: kierank happy [18:13:54 CEST] <wm4> I'd rather remove this shitty API though [18:14:01 CEST] <kierank> draw_horiz_band? [18:14:12 CEST] <kierank> we are going to use it [18:14:18 CEST] <wm4> yes... even if someone wants this for low latency or whatever, there ought to be better ways [18:14:31 CEST] <kierank> it's useful for more than low latency [18:14:38 CEST] <kierank> it's useful if you need to transform the data when it's fresh in cache [18:16:43 CEST] <wm4> I know, mplayer had an entire framework around it [18:16:46 CEST] <wm4> and now it's dead [18:26:15 CEST] <wm4> fucking wow [18:26:40 CEST] <wm4> merely calling av_frame_clone on the frame passed to draw_horiz_band and then unreffing it makes it crash [18:26:43 CEST] <wm4> something about side data shit [18:27:32 CEST] <wm4> so it's a broken piece of shit, but the theoretical corner case michaelni pointed out is still grounds to rejecting my patch [18:27:40 CEST] <wm4> michaelni: some well done trolling [18:29:32 CEST] <wm4> actually no, PECKAC, but I still feel trolled [18:42:30 CEST] <winegums_> hi all, sorry if this is a dumb question i have been stuck for a long time now and cant figure this out. I am trying to make a static bin of FFmpeg for macOS, however I cant figure out: ld: library not found for -lcrt0.o [18:50:25 CEST] <wm4> jkqxz: is there a test for the wrapped_avframe decoder? [18:50:56 CEST] <jamrial> winegums_: what's giving you that error? [18:51:22 CEST] <winegums_> thats during configure && make, want me to share configure? [18:51:37 CEST] <winegums_> ill pm it [18:54:45 CEST] <jkqxz> wm4: "Try to run kmsgrab". (There is no standalone test.) [18:55:47 CEST] <jkqxz> Muhammad Faiz (who is not here, I think?) was interested in using it to simplify some rawvideo stuff too, that could be looked at again. [18:57:14 CEST] <jamrial> this extralibs commit is really showing how all these libraries we have wrappers for don't properly list all their deps in their pkg-config file [18:57:34 CEST] <wm4> can't run kmsgrab [18:58:20 CEST] <jamrial> so many of the breakages have been cases of missing -lpthread, -lstdc++, -lz, -lm... [19:17:07 CEST] <winegums_> not sure if this relates but that seems to happen to me with x265 [19:17:17 CEST] <winegums_> ld: symbol(s) not found for architecture x86_64 [19:18:02 CEST] <winegums_> thats with using a static build of x265 [19:59:37 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/cuda/dynlink_cuviddec… i wish there was more documentation about this than those few fields [20:03:07 CEST] <FMatteo101101> Hello,....I wanted to ask if there was someone that could help me develop a certain functionality for a 2 stream merging (one live and one for a translator),....the problem I have is with the translator disconnecting [20:03:21 CEST] <FMatteo101101> and the whole thing stopping... [20:23:36 CEST] <wm4> BtbN: oh dear, so you're basically RE'ing their API? [20:24:07 CEST] <BtbN> The obvious way does not work [20:24:15 CEST] <BtbN> And I don't really have another idea [20:25:28 CEST] <Compn> FMatteo101101 : you want to hire a developer ? [20:25:44 CEST] <Compn> FMatteo101101 : feel free to ask here or on ffmpeg-devel mailing list, if you are offering to pay ... [20:25:45 CEST] <wm4> do they not have any sort of API trace tool, and some programs that actually use the cuvid filters? [20:25:59 CEST] <wm4> and why would nvidia not want ffmpeg to be able to use those filters? [20:26:16 CEST] <Compn> contract that says only nvidia can use technology ? [20:27:15 CEST] <BtbN> wm4, I'm not aware of any program using cuvid in that way. [20:27:29 CEST] <BtbN> And when googling for the enum and function names, I think nobody before ever tried [20:27:52 CEST] <FMatteo101101> Compn: ok I will write to ffmpeg-devel list and here [20:28:15 CEST] <FMatteo101101> If there is a good ffmpeg developer please write to me [20:28:32 CEST] <FMatteo101101> I am willing to put some money on the table [20:30:18 CEST] <wm4> BtbN: possibly such as proprietary nvidia tools or such [20:30:29 CEST] <wm4> of course only useful if you'd literally RE it [20:30:42 CEST] <BtbN> Using the cuda filter while decoding is easy and implemented in ffmpeg [20:30:55 CEST] <BtbN> it is putting raw YUV in and out of if that is a problem [20:32:41 CEST] <BtbN> I'm not aware of anything that might use cuvid as a pure frame filter [20:57:28 CEST] <wm4> BtbN: I'm still appalled by how we apparently have no nvidia contact, despite nvidia contributing to ffmpeg (what's even going on) [21:00:29 CEST] <BtbN> Yogender kind of is I think [21:09:45 CEST] <jamrial> wm4: you're too fast to get angry. he actually made a suggestion in another (older even) email to that same thread [21:19:13 CEST] <wm4> I just wrote another post [21:19:27 CEST] <wm4> I don't see any suggestions [21:19:34 CEST] <wm4> at least not any that work or that are not stupid [21:19:39 CEST] <BtbN> Would it really be so horrible to add an internal_opaque_ref? Just to get rid of this annoying discussion? [21:19:47 CEST] <wm4> why the fuck am I even dealing with this on a friday evening [21:20:20 CEST] <wm4> BtbN: I'll agree with it if we call the field michaelnis_bullshit [21:21:08 CEST] <BtbN> I kind of see the potential issue that this is something everyone dealing the API will have to keep in mind at all times, so some seperation there might not be bad. And it really does not seem messy to me to do so. [21:21:24 CEST] <BtbN> dealing with it internally [21:21:31 CEST] <BtbN> an API user obviously does not care [21:21:42 CEST] <wm4> you mean, like having an opaque field? [21:22:31 CEST] <wm4> the only other way I see is having a AVInternalFrame { AVFrame *frame; InternalState state; } struct [21:22:43 CEST] <wm4> but I'd like to avoid rewriting 100% of libavcodec [21:23:05 CEST] <BtbN> I mean just adding a second opaque field right next to the current one (without breaking ABI) [21:23:30 CEST] <wm4> no because we're not going to add public fields for every internal use case [21:23:43 CEST] <wm4> and strictly speaking you'd have to allow such fields for external applications too [21:23:51 CEST] <wm4> can't wait to add a mpv_internal_ref field to AVFrame [21:24:07 CEST] <wm4> because I need it and I'd like to avoid collision with other opaque_ref uses [21:24:17 CEST] <BtbN> Is the size of AVFrame part of the ABI? [21:24:22 CEST] <wm4> no [21:24:29 CEST] <wm4> not anymore [21:25:04 CEST] <BtbN> an AVFrameInternal struct that's a member of AVFrame, but not in a public header? [21:26:28 CEST] <BtbN> I'd expect that to break a lot of application that put AVFrames on the stack or something, but meh [21:26:33 CEST] <wm4> and how would you use this [21:26:40 CEST] <wm4> maybe like opaque_ref? [21:27:04 CEST] <BtbN> Just without the backup-copy you need to put back when returning the frame [21:27:56 CEST] <wm4> so what happens if within libavcodec, you use another piece of code that wants to use AVFrameInternal for its own purposes [21:29:28 CEST] <BtbN> The same that would happen with the opaque_ref field right now? [21:29:51 CEST] <wm4> yes [21:29:56 CEST] <wm4> you'd have to wrap and unwrap it [21:30:54 CEST] <BtbN> Unless you make some kind of dict there, but that starts to get messy [21:31:30 CEST] <wm4> even a dict would be messy [21:31:46 CEST] <wm4> what if the key is not unique, or you do nested things (consider nested codecs or filters) [21:32:58 CEST] <BtbN> Could make some kind of opaque_ref stack. And whoever puts something on there, has to make sure it gets put off there again [21:33:31 CEST] <wm4> that's what the patch does [21:33:54 CEST] <wm4> it's not an explicit stack, but you get a list of chained AVBufferRefs [21:37:16 CEST] <BtbN> hm, maybe do that, but in a new opaque_ref_stack field, which is required to just contain that chain, so you don't accidentially cast the wrong type? [21:38:02 CEST] <wm4> how would that improve anything? you can still "unbalance" the stack accidentally [21:38:03 CEST] <BtbN> Doesn't even need to be a buffer ref. Just a FrameDecodeData* [21:38:48 CEST] <BtbN> You don't change semantics of an existing field [21:39:18 CEST] <wm4> I don't understand [21:51:03 CEST] <BtbN> just looking through this is already confusing [21:51:15 CEST] <BtbN> but I'm not sure either solution is less confusing [21:58:15 CEST] <wm4> it's not confusing - opaque_ref within libavcodec always points to the internal thing [21:58:27 CEST] <wm4> and on frame output it's removed (and the hwaccel postproc callback is run) [21:58:54 CEST] <wm4> the main confusing thing is probably that Libav allows the user to set opque_ref in get_buffer2, so it has to be "wrapped" [22:05:09 CEST] <BtbN> So it just always expects to find a struct there, that, as its first element, has an AVBufferRef*? [22:06:00 CEST] <wm4> it only expects to find what it put there [22:06:35 CEST] <BtbN> But how do you make use of that struct? The actual usage adds fields there I guess? [22:08:07 CEST] <wm4> you mean what it's used for? [22:09:33 CEST] <BtbN> Yeah, just reading the 3rd patch again [22:10:47 CEST] <BtbN> Wouldn't just adding an AVFrameInternal internal; field to AVFrame with thise post_process fields work as well? [22:12:37 CEST] <BtbN> But I guess API misusers would screem then, as you can't have AVFrame on the stack anymore [22:12:45 CEST] <wm4> yes, but then you'd have a libavcodec-only field in AVFRame [22:13:05 CEST] <wm4> and it'd break with nested AVCodecContext instances anyway (that was something michaelni complained about with opaque_ref) [22:13:28 CEST] <wm4> you cant have AVFrame on the stack [22:15:36 CEST] <BtbN> AVFRame { AVFrameInternal *internal }; struct AVFrameInternal { AVFrameInternal *next; } and AVCodec and AVFilter can have their own AVCodec/FilterFrameInternal, as long as the first element is a *next where they build a stack if they want to add their own data. [22:17:47 CEST] <BtbN> would also allow for nested decoders/encoders to just put their own stuff in front [22:18:56 CEST] <wm4> I don't see how this would be more convenient or more robust than just rewrapping opaque_ref as the frame is transferred between boundaries [22:20:40 CEST] <BtbN> it's roughly equivalent, but does not "abuse" an opaque field that was originally intended to be used by API users [22:21:15 CEST] <BtbN> And users cannot set it in get_buffer, so safes a bit of code I guess? [22:21:30 CEST] <BtbN> well, they in theory can, but the resulting crash is their own fault [22:22:09 CEST] <wm4> the opaque_ref API user in this case is libavcodec too [22:22:22 CEST] <wm4> opaque_ref has no meaning for AVFRame/libavutil itself [22:22:34 CEST] <wm4> it's for free use by whatever uses AVFrames to do stuff [22:22:39 CEST] <wm4> which in this case is libavcodec [22:22:57 CEST] <wm4> libavcodec does this wrapping stuff merely to not conflict with the user's opaque_ref [22:23:12 CEST] <wm4> which in turn is _only_ because apparently we support it in get_buffer [22:23:42 CEST] <wm4> an AVFrameInternal would not change the situation because the user could use it [22:24:02 CEST] <BtbN> how? It wouldn't be defined in a public header. [22:24:29 CEST] <wm4> well then libavcodec can't use it [22:24:59 CEST] <BtbN> libavcodec is not allowed to include non-public headers from libavutil? [22:26:42 CEST] <wm4> well you could make it some avpriv API or whatever [22:26:59 CEST] <wm4> still not a solution [22:27:23 CEST] <wm4> you don't just add dedicated fields to generic data structures for some internal use [22:27:33 CEST] <wm4> it's enum bool {FALSE, TRUE, FILE_NOT_FOUND} design [22:28:46 CEST] <winegums_> (in reference to making static ffmpeg on macOS) I have nearly gotten everything working& most libs are now static except for some framework stuff, I compiled ffmpeg on 10.12, it works for 10.12 users but when testing on 10.9 it asks for CoreImage.framework any idea how I can make that static or build for a lower target with make? [22:31:37 CEST] <winegums_> also is there anyone here insterested in hired work around the audio codecs [22:34:49 CEST] <Compn> winegums_ : ask on ffmpeg-devel as well, not all devs are on irc [23:09:40 CEST] <atomnuker> BBB: did you start writing a decoder or are you working on an av1 encoder? [23:09:54 CEST] <BBB> its sort of the same thing TBH [23:10:08 CEST] <BBB> but right now its an encoder; I thought you had a decoder? [23:13:29 CEST] <jamrial_> he wrote a decoder for an old daala bitstream, i think [23:14:45 CEST] <atomnuker> yeah, that was a long time ago now though [00:00:00 CEST] --- Sat Oct 14 2017

1 0

ffmpeg.log.20171013
by burek 14 Oct '17

14 Oct '17

[00:49:56 CEST] <dylanmach1> hello, i am having trouble compiling and making a static bin of ffmpeg on macOS from the git [01:46:54 CEST] <DocHopper> JEEB: Working on changing some of FFMPEG's features, and now I need to start compiling. I'm looking at the guide here: https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW but it is over my head. Any more basic resources? [02:19:46 CEST] <nanke> Hello, may I ask one question about ffmpeg transcoding ? [02:29:00 CEST] <DHE> just ask your question [02:34:19 CEST] <nanke> Thank you. I am working with ffmpeg for transcoding live streams. On some live sources I have audio loss after stream being played about few hours, sometimes 3-4, sometime after 10 hours. Also sometimes audio is ok, but picture gone... If somebody can help me to solve this, I will pay for time spent on it. Thanks [03:43:04 CEST] <Johnjay> nanke: well there goes my bluff [03:43:12 CEST] <Johnjay> normally when i don't know the answer I say "I'll help you if you PAY me" [03:43:18 CEST] <Johnjay> since nobody would ever do that. XD [05:45:25 CEST] <Djuice> hello can anyone help me with this error: [05:45:27 CEST] <Djuice> -> Running ffmpeg configure script. Please wait... [05:45:27 CEST] <Djuice> ERROR: libflite not found [05:47:22 CEST] <Djuice> flite1 1.4-2 (8, 2.29) [installed] [05:52:41 CEST] <atomnuker> don't enable flite [05:54:20 CEST] <Djuice> what does flite do [05:55:31 CEST] <atomnuker> text to voice synth [05:59:58 CEST] <Djuice> thanks atomnuker [06:44:36 CEST] <pankuu> how can i compress mp4 video size [06:45:58 CEST] <pankuu> can anyone help me [08:17:34 CEST] <Johnjay> ah I just saw that guy asking about minGW compilation [08:18:19 CEST] <Johnjay> It's actually pretty easy as long as you get all the packages downloaded [08:43:49 CEST] <rabbe> does WebRTC work in iphone/ipad now? [08:57:05 CEST] <rabbe> how can i get VLC to read rtmp like ffplay -fflags nobuffer ? [09:16:55 CEST] <stevenliu> rabbe: reference->input/codec->network [09:18:51 CEST] <thebombzen> if zscale can't find a path between colorspaces, it'll segfault. is this a wrapper issue or a known zimg bug? [09:20:39 CEST] <furq> uh [09:20:48 CEST] <furq> zscale segfaults a lot but i've not had it segfault there before [09:21:06 CEST] <furq> are you passing aligned data [09:21:11 CEST] <thebombzen> ffmpeg.c, idk [09:21:22 CEST] <furq> what's the filterchain [09:22:53 CEST] <thebombzen> ffmpeg -f lavfi -i testsrc -vf zscale,format=yuv420p -f null - [09:23:04 CEST] <thebombzen> testsrc is rgb, it'll segfault unless you specify the matrix [09:23:07 CEST] <thebombzen> this command segfaults [09:23:22 CEST] <thebombzen> this does not: ffmpeg -f lavfi -i testsrc -vf zscale=matrix=709,format=yuv420p -f null - [09:23:36 CEST] <furq> fun [09:23:55 CEST] <thebombzen> however, if you specify the matrix just to be safe, it'll segfault if the in colorspace isn't tagged [09:24:01 CEST] <furq> the first one doesn't segfault here [09:24:06 CEST] <furq> it just prints no path between colorspaces a lot [09:24:17 CEST] <thebombzen> I build zimg from git master, hm. [09:24:21 CEST] <thebombzen> built [09:24:26 CEST] <furq> so do i but i've not rebuilt in a while [09:25:38 CEST] <thebombzen> nope, still segfaults if I use the Arch version [09:25:45 CEST] <thebombzen> ffmpeg is git master as well [09:28:32 CEST] <thebombzen> I'll run it through valgrind [09:37:17 CEST] <rabbe> stevenliu: huh? :) you mean in VLC settings? [09:37:29 CEST] <stevenliu> yes [09:38:08 CEST] <rabbe> under input / codecs -> demuxers -> rtp / rtsp? [09:38:31 CEST] <thebombzen> furq: valgrind reports it's an alignment issue [09:38:31 CEST] <thebombzen> https://0x0.st/CQx.log [09:38:31 CEST] <rabbe> or rtp [09:38:34 CEST] <stevenliu> maybe just chose low [09:38:37 CEST] <stevenliu> choose low [09:39:02 CEST] <furq> weird [09:39:33 CEST] <thebombzen> I'll ask in #ffmpeg-devel [09:39:52 CEST] <furq> yeah whatever that is must be new in zimg or ffmpeg [09:40:05 CEST] <furq> it doesn't happen in my freebsd ports build with the latest releases of both [09:40:30 CEST] <rabbe> which one is it, RTP or RTP/RTSP? [09:47:41 CEST] <stevenliu> mhmm, just try whatevery [09:47:42 CEST] <stevenliu> :D [09:48:13 CEST] <stevenliu> We dose not use VLC play rtmp, we use ijkplayer, flashplayer,ffplay [10:43:13 CEST] <rabbe> is it a good idea trying to force speed = 1x for realtime streaming? [10:53:06 CEST] <stevenliu> No [10:55:18 CEST] <rabbe> >1 gives me slow motion? [10:55:50 CEST] <rabbe> in the receiving end (using ffplay -fflags nobuffer rtmp://...) [10:55:51 CEST] <stevenliu> We do low latency way: cache 3 - 4 GOP on RTMPServer, When player request a rtmp stream, we send all the GOP to the player, but delete all the Audio data, and modify all the Video Data timestamp to 0,and the newest frame at the RTMPServer we modify 0 + 1/TB and send to player, then it low latency and first picture is very fast. [10:58:17 CEST] <rabbe> is that all using ffmpeg or some other software? [11:00:42 CEST] <rabbe> i want to ffmpeg to nginx and then receive on mobile device using vlc or something (preferably just the browser, but vlc is ok i guess). as realtime as i can get [11:01:35 CEST] <rabbe> i also need to record, maybe i can use the nginx functionality for that, but the video should be uploaded to a certain place somehow [11:02:31 CEST] <rabbe> realtime receivers will be inside the same wireless network [11:02:42 CEST] <rabbe> upload should be to internet [11:03:55 CEST] <rabbe> other tech than nginx is ok.. i'm open for suggestions [11:03:59 CEST] <stevenliu> My solution is ffmpeg+SRS+ffplay mobile phone:(javacv/yasea), PC (OBS/FFmpeg), Server: SRS, Player: ffplay/flashplayer/ijkplayer [11:04:50 CEST] <rabbe> javacv/yasea is javascript? [11:05:22 CEST] <stevenliu> be used to make Game(COC,c [11:06:15 CEST] <rabbe> i dont need rtmp either.. but maybe rtmp is good? [11:06:32 CEST] <stevenliu> no, javacv and yasea is SDK on mobile phone, be used to get camera, screen frame and encode to h264, get microphone audio to aac, and publish the data to rtmpserver [11:06:41 CEST] <rabbe> webrtc is supposed to be good also? [11:07:02 CEST] <rabbe> i need as little to be installed on the mobile devices as possible [11:07:15 CEST] <stevenliu> if you want low latency and little people to see the stream, maybe WebRTC+Janus/licode is better way [11:07:18 CEST] <rabbe> audio is not important [11:07:34 CEST] <rabbe> yeah, not too many viewers [11:07:51 CEST] <stevenliu> Maybe you can try use WebRTC+Janus/licode [11:08:03 CEST] <rabbe> difficult to set up? [11:08:07 CEST] <stevenliu> looks like video meeting [11:08:18 CEST] <rabbe> one-to-many style [11:08:29 CEST] <stevenliu> there have lots of documentation and blog to share the install way [11:09:16 CEST] <stevenliu> one to many style, the many's number is how many? 3? 30? 300? 3000? 30000? 300000? [11:09:17 CEST] <rabbe> free solution? [11:10:41 CEST] <rabbe> i guess no more than 3 viewers max.. one for TV maybe, then ipad or similar. then they will use the recorded material [11:11:07 CEST] <stevenliu> Ah, you can try WebRTC, [11:11:16 CEST] <stevenliu> That's free [11:11:25 CEST] <stevenliu> you can find all the project on github [11:11:44 CEST] <rabbe> you mean webrtc-experiments? [11:11:49 CEST] <rabbe> .com or something [11:12:06 CEST] <rabbe> that seemed to have some recordRTC [11:12:40 CEST] <stevenliu> https://github.com/webrtc [11:12:59 CEST] <furq> rabbe: if you want to be able to play it in the browser with low latency then webrtc is pretty much the only thing [11:13:07 CEST] <furq> rtmp needs flash and hls/dash have horrendous latency [11:15:22 CEST] <rabbe> yeah.. rtmp is working ok now if i use ffplay, but in browser i don't know.. i guess i could use vlc on mobile devices, but i haven't been able to get the same performance as ffplay -nobuffer yet [11:15:54 CEST] <stevenliu> browser? mobile phone browser? [11:15:55 CEST] <rabbe> but does iphone handle webrtc now with ios11? [11:16:05 CEST] <rabbe> i mean, anyone tried it? [11:16:41 CEST] <rabbe> yup, either mobile browser or vlc on mobile.. u have any other solutions? [11:17:27 CEST] <rabbe> i did see some rtmp player on appstore.. don't know if it exists for android [11:18:12 CEST] <rabbe> but if webrtc is a better protocol than rtmp, i'd rather use that if it works [11:18:34 CEST] <stevenliu> yes [11:19:01 CEST] <rabbe> but does webrtc specify what kind of codecs should be used? [11:19:12 CEST] <JEEB> yes, it's a limitation on top of RTP [11:19:24 CEST] <JEEB> "use RTP with this and this and this in this way and you're ok to call it WebRTC" [11:19:48 CEST] <rabbe> ok [11:20:59 CEST] <rabbe> also i will need some way of turning on and off recording.. like some rest api [11:21:24 CEST] <rabbe> solution suggestions are welcome, guys [11:23:06 CEST] <stevenliu> In China, lots of the platform use rtmp to share screen to play game, one to manyplayers number > 10000 , and lots of the platform just develop webui, all the player and server are using CDN, all the multimedia solution is standard service of CDN service.... WebRTC is used when connect one to one, to girls play games use WebRTC, and one girl shared them image to many people use rtmp [11:24:08 CEST] <rabbe> okay [11:25:42 CEST] <stevenliu> WebRTC to WebRTC to RTMP , this is the way [11:27:56 CEST] <JEEB> the problem with RTMP is that it will not be developed further [11:28:15 CEST] <JEEB> we can just standardize on X over HTTP for christ's sake if want something like that over TCP. [11:28:18 CEST] <JEEB> :) [11:28:33 CEST] <rabbe> so webrtc seems to be the way to go here? [11:28:37 CEST] <JEEB> it depends [11:28:43 CEST] <JEEB> WebRTC is for low-latency UDP scenarios [11:28:51 CEST] <JEEB> because, well, RTP is UDP [11:29:26 CEST] <JEEB> then you have a lot of infrastructure built around other TCP based protocols, which is why RTMP is often utilized for some things. it's not a technical thing, it's a "we already have this stuff around" kind of thing [11:30:16 CEST] <rabbe> yeah, the mobile device + tv (somehow) should receive the latest camera (gopro) image.. but the recording should be smooths [11:30:46 CEST] <rabbe> i guess mobile receiving could be choppy, as long as its showing realtime [11:31:02 CEST] <stevenliu> yes, RTMP is not be developed, but that is good protocol :D [11:31:05 CEST] <rabbe> but recording should be a nice video [11:32:11 CEST] <stevenliu> or try to use websocket ? [11:32:18 CEST] <BtbN> WebRTC is a mess [11:32:21 CEST] <JEEB> stevenliu: I don't think the protocol itself is good. it's just a TCP based thing that people have tooling for. I don't consider anyone actually using the messages in it, for example [11:32:25 CEST] <JEEB> BtbN: yup [11:32:26 CEST] <BtbN> good luck getting a stable solution implemented [11:32:41 CEST] <JEEB> not enough tooling and the clients don't tell you why something failed [11:32:59 CEST] <stevenliu> mhmm haha [11:33:13 CEST] <stevenliu> that is why akamai won't support flv and rtmp CDN [11:33:37 CEST] <JEEB> or well, stevenliu - what I say is that I don't think the RTMP protocol is good or bad - it's really irrelevant since you're pushing stuff over TCP, that's all basically [11:33:47 CEST] <BtbN> They won't support non-http CDN because they already have one for http, and frankensteining everything else on top of HTTP is cheaper for them [11:33:49 CEST] <JEEB> you could be doing the same without the RTMP layer if you had the tools and players [11:34:07 CEST] <stevenliu> yes, JEEB said is right [11:34:37 CEST] <JEEB> I've been doing live with VLC's HTTP output for example. it doesn't scale, but I can just connect to it with any HTTP client [11:34:51 CEST] <JEEB> and I just push MPEG-TS over the pipe [11:34:52 CEST] <JEEB> done [11:34:54 CEST] <BtbN> If said http client supports the video format [11:35:04 CEST] <BtbN> and browsers do not support anything that can be streamed in a useful manner [11:35:06 CEST] <JEEB> yes, of course. I was mostly playing with mpv/VLC [11:35:11 CEST] <JEEB> yes, I know browsers are shit in that sense :D [11:35:20 CEST] <stevenliu> whatever [11:35:22 CEST] <JEEB> XmlHTTPRequest requiring you to buffer the whole shit [11:35:38 CEST] <JEEB> not sure if websockets is better in that sense [11:41:45 CEST] <stevenliu> whatever protocol, we use rtmp or flv is just think the people have beed installed flashplayer on pc, so use it, and the people don't want install VLC plugin, so use it, now , lots of people and platform use mobile phone, we use rtmp or flv maybe just not want to change or need time, i think that need some time, and we can use http+ts to support it , maybe just history reason :D [11:45:23 CEST] <stevenliu> the people want use hevc, but the flv cannot add it, they add it into flv themselves change that to private protocol, and make it unify, or use http+ts is better :D, Whatever, the stream publisher and player is be used by themselves, so that is not important what protocol they use. [11:47:17 CEST] <rabbe> lets say the computer having the capture card will "just" need to capture the video to disk at certain times, and provide only one viewer with a live stream, can i do that with ffmpeg alone? maybe send via udp? [11:47:53 CEST] <rabbe> if i create that stream, the 'server' can also catch from that stream? [11:50:35 CEST] <JEEB> stevenliu: yup, someone just has to make a sane pick :) [11:50:46 CEST] <JEEB> and make the first clients, as flash is going down [11:52:11 CEST] <stevenliu> :D agreed [11:52:13 CEST] <notdaniel> dash+hls :P [11:52:18 CEST] <stevenliu> Noooo [11:52:37 CEST] <stevenliu> Dash and HLS have long lantency [11:55:21 CEST] <stevenliu> use to TV broadcast maybe better, but support "9U€" is not good then http+ts or flv :D, and the http+ts or flv is bad than WebRTC, but the WebRTC cannot support hugh players number, so if not use PC Browser, http+ts or mkv maybe better way? [12:26:17 CEST] <JEEB> notdaniel: yea that's not actual streaming. which is what you can want in various cases [15:14:53 CEST] <Nacht> Good lord, building x265 takes ages :/ [15:17:50 CEST] <klaxa> just like encoding a video with x265 [15:17:55 CEST] <Nacht> So true [15:19:36 CEST] <Nacht> Anyone know why I keep getting this -> ERROR: x265 not found using pkg-config [15:19:55 CEST] <Nacht> First installed it trough apt-get, now just build it myself. I def got it installed [15:20:27 CEST] <JEEB> make sure you have pkg-config installed and that you have x264 in your pkg-config search path [15:20:31 CEST] <JEEB> pkg-config --cflags x264 [15:20:33 CEST] <JEEB> pkg-config --cflags x265 [15:20:48 CEST] <JEEB> and if it isn't, PKG_CONFIG_PATH=/your/prefix/lib/pkgconfig [15:21:11 CEST] <JEEB> (that appends that directory to the pkg-config search path) [15:22:16 CEST] <Nacht> Cheers, ill have a look at that [15:26:35 CEST] <jojva> Hi. I have a stream of YUV frames of some resolution (e.g. 1920x1080) and want to encode them to a smaller resolution (e.g. 640x360). Do I have to use sws_scale for this, before I call avcodec_encode_video2, or is there a cleaner/faster way? [15:29:01 CEST] <JEEB> jojva: if your stuff is already an AVFrame, then libavfilter's scale filter is what you want [15:29:14 CEST] <JEEB> also for encoding if you are writing new code utilize the new API [15:29:26 CEST] <JEEB> jojva: this stuff https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [15:29:36 CEST] <JEEB> has the same API for audio, video and subtitles [15:29:45 CEST] <JEEB> or wait, no. not subittles [15:29:52 CEST] <JEEB> since those are not AVFrames yet [15:29:53 CEST] <JEEB> :< [15:30:05 CEST] <jojva> JEEB: I can use the scale filter from code? [15:30:11 CEST] <JEEB> yes, of course [15:30:18 CEST] <jojva> And I can't use the new API, I'm working on an embedded system [15:30:24 CEST] <jojva> JEEB: ok, thx ;) [15:30:25 CEST] <JEEB> what does that have to do with it :D [15:30:38 CEST] <JEEB> unless you are stuck with an old old version of FFmpeg [15:30:41 CEST] <JEEB> &19 [15:30:43 CEST] <jojva> exactly [15:30:50 CEST] <JEEB> my condolences then :P [15:30:58 CEST] <JEEB> I find the send/receive API nice [15:31:16 CEST] <Nacht> man, I have no clue where my pkg-config is installed :/ [15:31:32 CEST] <Nacht> ah wait, I fixed my locate [15:32:39 CEST] <jojva> JEEB: Yep I'm actually working on several version of FFmpeg at the same time, with horrible #ifdef to handle avcodec_encode_video and avcodec_encode_video2. It's a mess but I don't have a choice. And yep I love the new API it's clean I've tried it at home. :) [15:36:40 CEST] <jojva> JEEB: another question. What's the difference between libavfilter's scale filter and sws_scale? [15:36:54 CEST] <rabbe> if i send out an rtmp stream and get ~2x speed, i get slow motion at the receiving end (ffplay -fflags nobuffer). how can i fix this? [15:36:56 CEST] <JEEB> jojva: libavfilter is less error prone if you are already dealing with AVFrames [15:37:09 CEST] <JEEB> swscale is used in the background for the scale filter [15:37:16 CEST] <JEEB> it just that *you* don't have to write that code [15:37:43 CEST] <JEEB> instead you can write generic libavfilter code which will also help you with other stuff should you later require it [15:38:23 CEST] <jojva> well i've never handled libavfilter and i know sws_scale quite well. So i think the easy solution for me is the latter one. [15:44:10 CEST] <JEEB> jojva: alright :) [15:44:20 CEST] <JEEB> if you know it then sure [15:45:49 CEST] <Nacht> wth... [15:46:01 CEST] <Nacht> pkg-config --cflags x265 return my path to x265 [15:46:09 CEST] <Nacht> yet it still claims its not there [15:46:44 CEST] <JEEB> check if it can link from ffbuild/config.log [15:46:52 CEST] <JEEB> that should show the exact error it's having [15:49:09 CEST] <Nacht> threading.cpp:(.text+0x93): undefined reference to `pthread_join' [15:50:14 CEST] <Farmer-Fred> Hey y'all, I'm wondering if ffmpeg can convert video files to .AMV? [15:50:38 CEST] <JEEB> Nacht: are you per chance linking to a static build? [15:51:09 CEST] <Nacht> I am using --pkg-config-flags="--static" \ [15:51:29 CEST] <JEEB> then the pc file just lacks -lpthread :P [15:51:33 CEST] <JEEB> or something similar [15:52:03 CEST] <Nacht> I'm just following the standard Ubuntu Compilation tutorial, with added options [15:52:16 CEST] <Nacht> --enable-openssl --enable-indevs [15:52:22 CEST] <JEEB> yea, it just means that either x265 does somethign wrong or doesn't support your use case [15:52:33 CEST] <Nacht> bleh [15:52:48 CEST] <Nacht> its weird tho, I did build it with x265 in the past. [15:52:54 CEST] <Nacht> I wonder why it isnt working now then :/ [15:53:01 CEST] <JEEB> anyways, just add the flag to Libs in the pc file [15:53:03 CEST] <JEEB> for x265 [15:53:04 CEST] <JEEB> :P [15:53:08 CEST] <JEEB> or switch to shared builds [15:53:51 CEST] <Nacht> What's the difference choosing static or shared ? [15:55:46 CEST] <JEEB> shared libraries vs static. you might have to set LD_LIBRARY_PATH=/your/prefix/lib for the things to load up [15:55:47 CEST] <DHE> static binaries don't require external libraries like /lib/libz.so or other system libraries [15:56:06 CEST] <DHE> but the executable is signfnicantly larger [15:56:21 CEST] <Nacht> Ah. I see [15:56:44 CEST] <Nacht> So like building OpenSSL along, so you're not forced to use an ancient version (looking at you CentOS) [16:08:25 CEST] <Nacht> cheers JEEB, the -lpthread did the thing [16:08:54 CEST] <JEEB> basically, x265 depends on it but doesn't signal that it does [16:09:11 CEST] <JEEB> thus fixing the pc file is the best thing, and reporting the issue to x265 [16:31:09 CEST] <Nacht> Ugh, I hate building FFMPEG [16:31:15 CEST] <Nacht> takes ages, and it always ends up error'ing [16:34:20 CEST] <klaxa> really? it only takes a few minutes on my good laptop [16:34:59 CEST] <Nacht> It was just running for 30mins [16:35:04 CEST] <Nacht> Stopped on vpx :/ [16:36:53 CEST] <Nacht> Might be due to Windows Bash. [16:37:08 CEST] <Nacht> It's good, but it's not equal to an actual Ubuntu install [16:37:21 CEST] <JEEB> it seems like it gets better with 1709 [16:39:14 CEST] <Nacht> Now getting: (vpx_codec.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC [16:39:39 CEST] <JEEB> needs PIC in the library you depend on [16:39:44 CEST] <JEEB> (not FFmpeg) [16:40:10 CEST] <Nacht> It's the vpx lib [17:15:05 CEST] <kepstin> Nacht: you're trying to link a static library into a shared library, and the static library was not compiled in the correct way for that. Either build ffmpeg as static, or link to the dynamic version of the vpx lib. [18:10:09 CEST] <DocHopper> Is there a simple method for compiling the FFMPEG source code for windows? [18:12:16 CEST] <kepstin> ... last time I did it, I cross-compiled it from a linux box :) I think you'll want to grab msys2 with mingw-w64 nowadays, building ffmpeg inside the msys2 shell should be fairly straightforwards. [18:13:30 CEST] <SonicTheHedgehog> DocHopper: https://trac.ffmpeg.org/wiki/CompilationGuide see the Windows sections [18:15:57 CEST] <DocHopper> SonicTheHedgehog: I've already looked at that and it's beyond my understanding. I think I might have found a youtube video that explains. [18:16:56 CEST] <DocHopper> SonicTheHedgehog: That guide includes the phrase "Once you installed all the necessary packages (MinGW is the only strict requirement for building FFmpeg, git is required to update your FFmpeg source), you need to open a MinGW shell, change directory to where you checked out the FFmpeg sources, and configure and make FFmpeg the usual way." [18:17:09 CEST] Action: SonicTheHedgehog nods [18:17:22 CEST] <DocHopper> 8 words to explain the part I have no idea how to do. [18:17:58 CEST] <SonicTheHedgehog> in a nutshell, MinGW is a compatibility subsystem that makes Windows behave like Linux in some ways, and you need to the compilation from there [18:18:14 CEST] <DHE> that sounds more like cygwin [18:19:16 CEST] <DocHopper> Oh, so I just run the make file in a mini limux environment? [18:19:32 CEST] <DHE> I think cygwin provides a POSIX interface while mingw is more like simply porting gnu apps (including gcc) to windows. [18:19:54 CEST] <DHE> I've built full, proper GUI windows apps under mingw that don't have additional dependencies. [18:19:58 CEST] <SonicTheHedgehog> yes, that's totally true, but to avoid confusing DocHopper any further I left all that out [18:20:08 CEST] <DHE> fair enough [18:21:12 CEST] <DocHopper> SonicTheHedgehog: Thanks for watching out for me. I take steps one at a time. ^_^ [18:21:22 CEST] Action: SonicTheHedgehog nods [18:22:18 CEST] <DocHopper> Never thought this project would get so complex, or that to get FFMPEG to ignore an error I would have to edit the source code and recompile. [18:23:00 CEST] <SonicTheHedgehog> Hm, what error are you getting? Maybe there's a way around that that doesn't require you to compile your own binary? [18:23:54 CEST] <DocHopper> I would love to find that. I need ffmpeg to load a text file for an overlay that is changing 2x a second. if the file is being edited when ffmpeg is trying to read, it stops. [18:27:07 CEST] <SonicTheHedgehog> DocHopper: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=718 [18:29:03 CEST] <DocHopper> SonicTheHedgehog: I'm looking at the flags in the last post? [18:30:30 CEST] <SonicTheHedgehog> DocHopper: yeah, the last post suggests using a tee [18:34:19 CEST] <DocHopper> SonicTheHedgehog: I'll give you a brief sitrep. I'm pulling video from 2 webcams on a latte panda, merging it with a data stream from a connected serial device (Which is in a text file created and updated using python), and saving the file as a .ts so I can stream it live OTA to a remote location. [18:34:32 CEST] <SonicTheHedgehog> I see [18:35:22 CEST] <DocHopper> I'm not sure how a tee would help. [18:35:42 CEST] <SonicTheHedgehog> Hmmmmmmm [18:48:14 CEST] <DocHopper> SonicTheHedgehog: Is there an FFMPEG bot I can add this video too if people ask about compiling in the future? https://www.youtube.com/watch?v=3yhkX0uaQGk [18:49:36 CEST] <BtbN> a video? About compiling? oO [18:52:11 CEST] <DocHopper> BtbN: It's what I needed. [18:52:40 CEST] <BtbN> A video is the worst possible way for compile instructions. [18:53:14 CEST] <redrabbit> yeah [18:53:34 CEST] <BtbN> well, a pure audio recording would probably be worse [18:53:44 CEST] <redrabbit> lol [18:53:54 CEST] <redrabbit> that would be like evil [18:57:42 CEST] <DocHopper> Well, it's better than the official FFMPEG documentation for someone who has no idea what they're doing. [19:03:40 CEST] <BtbN> It's just ./configure && make for starters. [19:08:33 CEST] <kerio> BtbN: what about [19:08:36 CEST] <kerio> a sculpture [19:08:44 CEST] <thebombzen> >compilation instructions [19:08:46 CEST] <thebombzen> >video [19:08:49 CEST] <thebombzen> lmao [19:11:32 CEST] <Fenrirthviti> There isn't even any audio, it's just subtitles [19:15:58 CEST] <ayum> Hi, what's the difference between cuda and nvenc? I know nvenc is encoder, and there is a cuvid which is decoder, but what's cuda? [19:16:39 CEST] <ayum> I tried compile ffmpeg with --enable-cuda and --enable-cuvid, but it says Unknown option "--enable-cuda" [19:16:55 CEST] <ayum> I am using ffmpeg 3.0.2 version [19:20:58 CEST] <DHE> cuda is the nvidia equivalent to opencl, but there's cuda glue for the cuvid and nvenc interfaces [19:21:22 CEST] <DHE> so you can do things like decode and post-process frames on the GPU, then re-encode with nvenc all internally [19:22:45 CEST] <kepstin> note that 'cuda' usually refers to stuff running on the main gpu processor, but 'cuvid' and 'nvenc' refer to dedicated video encoder/decoder logic on the chip separate from the gpu cores. [19:23:48 CEST] <ayum> okay, thanks. If I have used nvenc codec to encoding, do I need use cuda? [19:24:28 CEST] <BtbN> 3.0 is too old for the cuda filters [19:24:47 CEST] <ayum> I will update to latest version and try it again [19:25:10 CEST] <kepstin> ayum: you can use the encoder hardware on nvidia cards without needing to use any of the other cuda functionality, iirc. [19:25:43 CEST] <ayum> @kepstin, If use cuda, can I transcoding more channels? [19:26:58 CEST] <kepstin> ayum: not sure what you mean. The number of encoder streams an nvidia card can handle is set by arbitrary driver limits on geforce cards, and the capabilities of the nvenc on quadro cards, cuda has nothing to do with it. [19:27:38 CEST] <ayum> so I can just use nvenc, it's enough, right? [19:27:57 CEST] <kepstin> if you just want to use the hardware encoder, yes. [19:29:17 CEST] <ayum> @kepstin, I known that some nvidia gpu card has session limitation, I remember GTX 980 can only open 2 session at same time. can you recommend a nvidia gpu card which has no session limitation or at least can transcoding more channels. [19:29:49 CEST] <ayum> yes, my plan is use transcoding only, no need use cuda filters I think [19:29:56 CEST] <kepstin> ayum: the session limit is done by drivers on the non-professional cards. If you want no session limits, get a midrange or higher quadro card. [19:30:26 CEST] <ayum> @kepstin, thanks [19:30:47 CEST] <kepstin> note that if you're only using the encoder, the actual gpu performance doesn't matter [19:31:17 CEST] <kepstin> most of the cards of a particular chip generation will have the same video encoder performance (minor differences depending on clocks) [19:31:51 CEST] <BtbN> Well, usually the lower end cards have a better decoder/encoder [19:31:55 CEST] <BtbN> Because they come out later [19:32:04 CEST] <BtbN> That's true for the 950 and 1050 [19:32:07 CEST] <kepstin> ayum: https://developer.nvidia.com/nvidia-video-codec-sdk#NVENCPerf has some charts showing session counts on different cards [19:32:33 CEST] <BtbN> That chart is pointless though [19:32:40 CEST] <BtbN> As you are limited to two streams anyway [19:32:49 CEST] <BtbN> unless you have a Quadro or Tesla card [19:32:58 CEST] <kepstin> that chart only lists quadro and tesla cards, yes [19:33:51 CEST] <ayum> got it, I will check above professional card price [19:36:38 CEST] <FMatteo101101> Hello [19:37:25 CEST] <FMatteo101101> I am merging 2 rtmp streams....one main stream and one stream with a translators voice to the stream [19:37:42 CEST] <kepstin> looking at the prices, a stack of quadro p2000 cards is probably the most cost-efficient way to get a bunch of nvenc sessions, if that's what you want. [19:37:52 CEST] <FMatteo101101> I am doing this on a nginx server [19:38:34 CEST] <FMatteo101101> it's working fine,....until the translators connection is lost for some reason [19:39:19 CEST] <FMatteo101101> then I have an issue reconnecting the translator,....and viewing the stream while the translator is offline [19:39:29 CEST] <FMatteo101101> can someone help me on this issue? [19:40:28 CEST] <DocHopper> SonicTheHedgehog: Thanks for your help, I successfully compiled ffmpeg from the snapshot, now it's time to start modifying things! [19:40:33 CEST] <BtbN> you'll have to re-start the merging process. [19:40:58 CEST] <FMatteo101101> is there a way to automate this process? [19:42:40 CEST] <DHE> maybe just a shell script? [19:42:49 CEST] <DHE> while true; do ffmpeg ..... ; sleep 1 ; done [19:43:01 CEST] <DHE> (works on most shells on unix) [19:45:17 CEST] <SonicTheHedgehog> DocHopper: yw, sorry had to step away for a while, but glad you got things working! :) [19:49:36 CEST] <FMatteo101101> has anyone ever managed a live stream with a translator on the other side of the world? [19:51:54 CEST] <c3r1c3-Win> FMatteo101101: Via TV broadcast, not the internet. It was fairly straight-forward, if really expensive, but doing it over the internet should be straight-forward (assuming they have an excellent connection). [19:52:25 CEST] <FMatteo101101> well I got it working..... [19:52:45 CEST] <FMatteo101101> but when the translator looses the connection I have issues reconnecting [19:55:15 CEST] <DHE> sounds like you might want something more reliable than stock ffmpeg. like making an application of your own using ffmpeg that will tolerate the loss and start either streaming stock audio, or streaming silence, or something like that until it reconnects [19:55:35 CEST] <DHE> I'm not specifically aware of something existing that does that now [19:55:57 CEST] <FMatteo101101> DHE probably you are right [19:57:16 CEST] <FMatteo101101> any ideas of someone that could help me in this task? [19:57:51 CEST] <c3r1c3-Win> FMatteo101101: Some video-able coders... and they tend to cost $$$. [19:59:19 CEST] <FMatteo101101> well....if it's reasonable pricing I could consider it [22:16:52 CEST] <tomonori_> Hi, I have a quick sync problem in the latest 3.3.4 version ffmpeg, it will show "Warning in encoder initialization: partial acceleration (4)" warning, and it seems use CPU to encoding. but In the old 3.2.4 version, quick sync encoder is works great. I want to know is it a bug in 3.3 version? [22:17:36 CEST] <tomonori_> Same problem with this ticket. https://trac.ffmpeg.org/ticket/6347 [23:10:16 CEST] <alexp> tomonori_: i ran into that same problem before [23:10:47 CEST] <alexp> in my case, it was because a monitor wasn't plugged in for the integrated graphics [23:11:09 CEST] <alexp> the difference is that earlier versions *didn't report a problem* but behaved at exactly the same speed [23:11:54 CEST] <alexp> for my case, I use a test command to see if encoding to qsv passes or fails, but since it was only a "warning", it would technically pass and use the not-worth-using partial acceleration [23:12:11 CEST] <alexp> so I just edited the source file to fail instead of warn [23:12:56 CEST] <tomonori_> @alexp, I don't have other graphical card. only integrated card [23:13:16 CEST] <tomonori_> @alexp, and if you check the CPU usage, you will found actually it using CPU encoding [23:13:22 CEST] <alexp> right [23:13:25 CEST] <alexp> and slowly, at that [23:13:32 CEST] <alexp> have you tried updating your graphics driver? [23:13:55 CEST] <tomonori_> @alexp, yes, In old version 3.2.8, the quick sync works good, CPU used only 3%, but in 3.3 CPU usage 30% [23:14:19 CEST] <tomonori_> @alexp, sorry, not. [23:14:52 CEST] <alexp> "sorry, not" = "i didn't update my graphics driver"? [23:15:27 CEST] <tomonori_> @alexp, as you known, intel media SDK depends the libva, libdrm and libmfx, If I update driver, perhaps it will cause the intel media SDK broken. [23:15:49 CEST] <tomonori_> sorry, my bad english [23:15:52 CEST] <alexp> ok, well it's possible this is just specific to linux [23:15:57 CEST] <tomonori_> I didn't upgrade the driver [23:16:03 CEST] <alexp> it works fine under windows, although that message is definitely shown in some cases [23:16:25 CEST] <tomonori_> yes, so I am still using 3.2.8 version [23:16:31 CEST] <alexp> k [23:17:22 CEST] <alexp> unfortunately, i'm not the person who can really help. i just wanted to give you some basic ideas about why it could happen. if it worked in a previous version with the same driver, then perhaps it's a bug. or perhaps it's accessing the driver differently now and requires a driver update [23:17:26 CEST] <tomonori_> I think it's the problem in intel media SDK? because the error message is show after call MFXVideoENCODE_Init() [23:18:13 CEST] <tomonori_> @alexp, thanks, I will try update driver in the later [00:00:00 CEST] --- Sat Oct 14 2017

1 0

ffmpeg-devel.log.20171012
by burek 13 Oct '17

13 Oct '17

[00:03:37 CEST] <wm4> BtbN: except software [00:03:48 CEST] <wm4> nvidia supports no wayland etc. [00:04:09 CEST] <BtbN> So far I never felt an immediate need for Wayland, so I don't care. [00:04:17 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:db869f4ea440: fate: Add build-only targets to FATE [00:04:18 CEST] <cone-265> ffmpeg 03James Almer 07master:85e2fe628183: Merge commit 'db869f4ea4405fb8f9736e5ecdca70f77621a28e' [00:05:01 CEST] <durandal_1707> nvidia added own stuff for wayland... [00:05:31 CEST] <BtbN> Nvidia is working on a new API for Wayland initialization stuff [00:05:32 CEST] <BtbN> slowly [00:06:03 CEST] <atomnuker> not just nvidia [00:06:18 CEST] <wm4> BtbN: which means? [00:06:28 CEST] <BtbN> There eventuall will be Wayland [00:06:56 CEST] <atomnuker> but by then nvidia would have paid the price and no one would be left to care [00:07:05 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:5ff3b5cafcc6: build: Add pthreads to list of avutil extralibs [00:07:06 CEST] <cone-265> ffmpeg 03James Almer 07master:7d2882bf52a6: Merge commit '5ff3b5cafcc685b6936d16602b0f80aa09a95870' [00:08:08 CEST] <wm4> what's the planned API? is it better than the EGLstreams BS? [00:08:59 CEST] <atomnuker> probably, this is the git repo: https://github.com/cubanismo/allocator [00:09:08 CEST] <BtbN> nvidia and mesa are working on it [00:09:18 CEST] <BtbN> GBM isn't exactly good either. It's just what is already there. [00:10:23 CEST] <wm4> "Capabilities Set Math" oh god what [00:11:06 CEST] <BtbN> well, you kind of need that black magic [00:11:28 CEST] <TD-Linux> it's a C API rather than a kernel API which I have mixed feelings about [00:11:51 CEST] <BtbN> But all that stuff is in userland? [00:12:46 CEST] <TD-Linux> oh yeah nevermind, got it mixed up with something else [00:33:55 CEST] <jamrial> ubitux: ping [00:34:02 CEST] <ubitux> jamrial: pong [00:34:11 CEST] <jamrial> your fate clients are failing [00:34:35 CEST] <jamrial> ubitux: nevermind, i think i found why [00:36:53 CEST] <ubitux> it's the null() thing? [00:37:13 CEST] <ubitux> like, missing the concat close? :p [00:37:41 CEST] <jamrial> yeah :p [00:41:53 CEST] <cone-265> ffmpeg 03James Almer 07master:ef7766befde5: fate: add missing closing bracket [00:46:18 CEST] <cone-265> ffmpeg 03Ganesh Ajjanagadde 07master:7bfda7d157eb: intmath: add faster clz support [00:46:19 CEST] <cone-265> ffmpeg 03James Almer 07master:19d57ca62e71: libavutil: add av_mod_uintp2 [00:46:20 CEST] <cone-265> ffmpeg 03Paul B Mahol 07master:aba5b94859ef: Add Apple Pixlet decoder [00:46:21 CEST] <cone-265> ffmpeg 03James Almer 07master:37caed777472: Merge commit 'aba5b94859ef1cb8f517dc64bce86a3021316ae8' [00:48:47 CEST] <ubitux> jamrial: sources are different between libav pixlet and ours [00:48:56 CEST] <jamrial> BtbN: what do you think of 3303f86467? (libav commit) [00:49:07 CEST] <ubitux> it seems to be mostly random spaces as usual, but you may want to reduce the diff [00:50:15 CEST] <jamrial> ubitux: ah ok. I usually just skip them when it's a port from ffmpeg, but you're right, better reduce diff if possible [00:50:31 CEST] <ubitux> no, you really need to check everytime [00:50:54 CEST] <ubitux> because they have a bad habit of shuffling the code all the time when cherry picking [00:51:15 CEST] <ubitux> the other way around is less problematic since you can trust the person doing the port [00:51:52 CEST] <jamrial> i see at first glance it uses the new bitstream reader [00:52:10 CEST] <ubitux> there are type changes too [00:52:11 CEST] <jamrial> gonna be a pain to find real changes [00:52:23 CEST] <jamrial> size_t again [00:53:40 CEST] <ubitux> one thing you have to be careful is that they sometimes cherry-pick the original commit but not the fixes that happened later [00:53:53 CEST] <ubitux> so you have to be careful about not reverting changes we did... :p [00:55:12 CEST] <jamrial> yeah, heh [00:55:53 CEST] <jamrial> in this case they did squash all the fixes up to that point into the first commit [01:02:43 CEST] <jamrial> they added a variale named cthulu [01:03:20 CEST] <wm4> who is they [01:03:24 CEST] <wm4> or do you mean THEM [01:04:46 CEST] <jamrial> whoever cherry picked and changed parts of this decoder [01:04:54 CEST] <jamrial> probably koda [01:05:41 CEST] <wm4> you could probably ask koda [01:08:44 CEST] <jamrial> it's a temp variable to hold a value. i just found the name funny [01:29:37 CEST] <cone-265> ffmpeg 03Sasi Inguva 07master:2b006ccf8318: ffmpeg.c: Fallback to duration_dts, when duration_pts can't be determined. [01:29:38 CEST] <cone-265> ffmpeg 03Ivan Kalvachev 07master:9054439bad33: Fix visual glitch with XvMC, caused by wrong idct permutation. [03:26:21 CEST] <cone-265> ffmpeg 03James Almer 07master:734ed3893110: configure: fix dependencies for v4l2_indev [03:30:46 CEST] <jamrial> ubitux: two bugs we didn't detect so far :p [03:35:13 CEST] <atomnuker> BBB: why did vp9 have both SEG_LVL_SKIP and the mbmi skip flag to signal skipping? [03:35:45 CEST] <BBB> some people thought itd be fun to skip at the segment level so it would take Even Less Bits [03:36:07 CEST] <BBB> there was some data that it helped reduce bitrate of akiyo (240p) at 40ish dB PSNR by a few percent (to 20kbps or so) [03:36:35 CEST] <atomnuker> but you always signal an mbmi->skip flag too [03:36:38 CEST] <BBB> also static content [03:36:54 CEST] <BBB> yes, but SEG_LVL_SKIP forces a reference, a motion vector (zeromv) and a skip flag [03:36:58 CEST] <BBB> so it does everything at once [03:37:20 CEST] <BBB> or actually, the reference is a separate feature [03:37:22 CEST] <BBB> but still [03:37:33 CEST] <atomnuker> yeah but you still code a skip flag [03:37:43 CEST] <BBB> SEG_LVL_SKIP + SEG_LVL_REFERENCE would mean no coded flags in the block apart from the seg_id [03:37:46 CEST] <BBB> nope [03:38:00 CEST] <BBB> with these two seg features, you dont code any bits in the block data [03:38:02 CEST] <BBB> nothing at all [03:38:06 CEST] <BBB> its entirely static [03:38:16 CEST] <BBB> but no coded bits in the block data (afaicr) [03:38:45 CEST] <BBB> other than the seg id of course, which for static data would be update_map=0, which means even that isnt coded, which means its free [03:38:47 CEST] <atomnuker> I guess things did change because in av1 you read a segment_id and then you immediately read the skip flag (always) [03:39:02 CEST] <BBB> maybe that changed in av1; in vp9, its dependent on the seg feature [03:39:18 CEST] <atomnuker> wow [03:39:43 CEST] <jamrial> they used results from a test on a 240p sample at ~20kbps to agree on a feature for a codec meant for 2k and 4k video? [03:40:13 CEST] <atomnuker> ...all their internal test samples were low res [03:41:32 CEST] <BBB> vp9block.c:143 [03:41:34 CEST] <BBB> b->skip = s->s.h.segmentation.enabled && [03:41:35 CEST] <BBB> s->s.h.segmentation.feat[b->seg_id].skip_enabled; [03:41:37 CEST] <BBB> if (!b->skip) { [03:41:37 CEST] <BBB> int c = td->left_skip_ctx[row7] + s->above_skip_ctx[col]; [03:41:38 CEST] <BBB> b->skip = vp56_rac_get_prob(td->c, s->prob.p.skip[c]); [03:41:41 CEST] <BBB> so it looks like that changed in av1 [03:42:38 CEST] <atomnuker> yeah, that's definitely changed [03:42:48 CEST] <atomnuker> did vp9 have temporal segid prediction too? [03:42:55 CEST] <BBB> yes [03:43:04 CEST] <BBB> please fix that, I want spatial prediction in av1 [03:43:13 CEST] <BBB> I would like* [03:44:10 CEST] <atomnuker> patch is for review on gerrit, removes temporal prediction but still needs some code management crap [03:44:26 CEST] <BBB> ok, cool [03:44:43 CEST] <atomnuker> and to figure out what to do not to signal a segment id on skipped blocks [03:45:01 CEST] <BBB> what about loopfilter delta? [03:45:10 CEST] <atomnuker> (it works, but blocks get blurred, looks like the encoder still uses a segment id for something so there's a desync) [03:45:32 CEST] <BBB> probably loopfilter delta [03:45:55 CEST] <atomnuker> yeah, I meant skip a segment id if none of the segments contain anything but seg_lvl_alt_q [03:46:12 CEST] <BBB> ah ok [03:46:28 CEST] <BBB> that seems a weird case to optimize for TBH [03:46:36 CEST] <BBB> in most cases you want lf lvl to adjust along with q [03:46:49 CEST] <BBB> but if you have a use case for it, go ahead, of course [03:47:03 CEST] <atomnuker> not really [03:47:53 CEST] <atomnuker> derf's idea was to use another block's q (non-skipped) or use some default value [03:48:21 CEST] <BBB> sounds like its worth trying at least, sure [03:52:17 CEST] <atomnuker> I am/was considering starting to write an av1 encoder myself but I'm not happy with what it settled for (it lacks exotic things) [03:52:47 CEST] <atomnuker> well, except obmc, it has that though its limited afaik [03:53:29 CEST] <atomnuker> I'd rather do ffv2 with full on exotic things [03:54:41 CEST] <atomnuker> so lapping, stockwell transforms instead of dcts, obmc, pvq, dering and whatever else I could think of [03:56:03 CEST] <atomnuker> using stockwell transforms would have solved daala's NP hard problem of block size selection with lapping because you could use a fixed block size and instead subdivided [03:57:24 CEST] <atomnuker> (since they're partly spatial/frequency domain yet are cheap-ish to compute..ish) [04:31:44 CEST] <djfk> hello [04:32:10 CEST] <djfk> how to simulate client request different video stream? [09:06:59 CEST] <Zeranoe> A commit in the last day seems to have broken building for macOS. Trying to find what exactly buy bisect isn't working. [09:09:27 CEST] <Zeranoe> 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 perhaps [09:17:38 CEST] <Zeranoe> Yeah something in 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 that's a huge commit too [10:02:40 CEST] <nevcairiel> Zeranoe: you'll need to be more specific, i did a ./configure && make just now, and it finished fine [10:04:09 CEST] <Zeranoe> nevcairiel: It's with gnutls, before that commit the frameworks were included: -framework CoreServices -framework CoreGraphics -framework VideoToolbox -framework CoreImage -framework AVFoundation -framework AudioToolbox -framework AppKit [10:04:39 CEST] <Zeranoe> It looks like gnutls needs at least CoreServices [10:06:59 CEST] <BtbN> jamrial, 3303f86467 is a no-op. NV_ENC_PARAMS_RC_2_PASS_VBR is a deprecated rc mode(http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/nvenc/nvEncodeAP…. [10:07:14 CEST] <BtbN> And the first hunk with qmin/qmax was applied to ffmpeg quite a while ago already. [10:07:49 CEST] <BtbN> In a slightly different fashion, but with the same effect [10:07:58 CEST] <BtbN> Came as a patch from nvidia iirc [10:09:14 CEST] <nevcairiel> Zeranoe: all of those services are still included here [10:10:06 CEST] <nevcairiel> please open a trac ticket with full log output and everything, and a minimal configure commandline to reproduce it [10:10:16 CEST] <Zeranoe> nevcairiel: do you have extralibs ? [10:13:52 CEST] <Zeranoe> It doesn't look like that matters anyway. You're seeing the frameworks during configure at the gnutls check (check_gnutls_global_init) ? [10:14:04 CEST] <nevcairiel> additionally, gnutls is included through pkg-config, if it needs anything special, its .pc file should include that [10:14:46 CEST] <Zeranoe> I agree, but it seems to be confused with what it needs [10:18:01 CEST] <nevcairiel> I also cannot find any reference to gnutls needing that on the web [10:19:02 CEST] <Zeranoe> Not sure, but my configure fails without extralibs="-framework CoreServices" at gnutls [10:20:00 CEST] <Zeranoe> https://paste.ubuntu.com/25723363/ [10:23:47 CEST] <nevcairiel> what does the .pc file for gnutls look like, exactly? [10:26:17 CEST] <Zeranoe> https://paste.ubuntu.com/25724985/ [10:27:28 CEST] <BtbN> jamrial is not even here... [10:30:42 CEST] <nevcairiel> should definitely open a ticket with gnutls if they require linkage to something but the .pc doesnt specify it [10:33:11 CEST] <nevcairiel> the osx keychain support in gnutls is "relatively" new (only 6 months, only in 3.5.x and above) [10:36:35 CEST] <Zeranoe> Getting https://paste.ubuntu.com/25725030/ now nevcairiel [12:44:17 CEST] <cone-612> ffmpeg 03Carl Eugen Hoyos 07master:ce508f0bcc37: lavc/proresdec2: Do not mix variable declaration and statement. [12:47:47 CEST] <wm4> is libavutil missing a dep on opencl? [13:07:12 CEST] <funman> it's missing a dep on all the hw stuff afaik [13:10:56 CEST] <wm4> supposedly it regressed with 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 [13:28:04 CEST] Action: JEEB thinks about adding a flag to the mpegts demuxer to "handle the timestamp funkiness for me, thank you" [13:28:19 CEST] <JEEB> handling it in each darn client just seems like duplicated effort :| [13:29:45 CEST] <wm4> like what? [13:29:59 CEST] <JEEB> timestamps can go backwards and libavformat will just export those timestamps as-is [13:30:27 CEST] <JEEB> there's the usual round-going which is normal because of the 33bit int [13:30:36 CEST] <JEEB> and then there's just stuff going backwards etc [13:31:03 CEST] <JEEB> this is why upipe exports multiple timestamps [13:31:14 CEST] <JEEB> one for those who want the original coded timestamp of input [13:31:31 CEST] <JEEB> one for those who just want the timestamp after de-MPEG-TS'ization [13:31:43 CEST] <JEEB> which would be constantly rising properly and all that jazz [13:31:55 CEST] <JEEB> and then one for the reception time stamp [13:57:53 CEST] <nevcairiel> i might use such a mode if it existed and is reliable [16:00:58 CEST] <jamrial> BtbN: saw your reply in the logs, thanks [16:03:53 CEST] <jamrial> wm4: ping [16:03:59 CEST] <wm4> jamrial: pong [16:05:43 CEST] <jamrial> wm4: does https://pastebin.com/cy8s8zn3 fix the opencl on avutil thing you mentioned? [16:06:14 CEST] <wm4> haven't tested it myself, can do later [16:06:19 CEST] <wm4> isn't that missing vdpau [16:06:38 CEST] <wm4> hm maybe that's dlopened [16:07:09 CEST] <jamrial> wm4: no, it's using vdpau_x11 though [16:08:18 CEST] <wm4> I remember some murky problems with this (months/years long before) [16:33:12 CEST] <jamrial> nevcairiel: can you post a sample config.mak from a default macos build? [16:33:12 CEST] <wm4> ok, as expected I can't reproduce the issue [16:34:15 CEST] <jamrial> wm4: what issue? [16:36:09 CEST] <BBB> atomnuker: regarding SEG_LVL_SKIP [16:36:15 CEST] <wm4> the one I mentioned before (user report is here https://github.com/mpv-player/mpv/issues/4977) [16:36:17 CEST] <BBB> static int write_skip(const AV1_COMMON *cm, const MACROBLOCKD *xd, [16:36:18 CEST] <BBB> int segment_id, const MODE_INFO *mi, aom_writer *w) { [16:36:19 CEST] <BBB> if (segfeature_active(&cm->seg, segment_id, SEG_LVL_SKIP)) { [16:36:20 CEST] <BBB> return 1; [16:36:26 CEST] <BBB> atomnuker: doesnt that suggest av1 still has the behaviour vp9 had also? [16:37:01 CEST] <wm4> jamrial: the test program fails with "err: /usr/lib/libavutil.so.55: undefined reference to `clEnqueueUnmapMemObject'" [16:37:23 CEST] <wm4> (and a bunch of other missing cl* refs) [16:37:42 CEST] <jamrial> does the change i posted above fix it? or you mean you can't evne reproduce the failure anymore? [16:42:50 CEST] <atomnuker> BBB: no, look in e.g. read_intra_frame_mode_info() in av1/decoder/decodemv.c [16:43:16 CEST] <atomnuker> first it reads mbmi->segment_id and then mbmi->skip [16:43:55 CEST] <wm4> jamrial: I can't reproduce the failure without the patch [16:44:24 CEST] <jamrial> are you enabling opencl? it's afaik not autodetected [16:44:29 CEST] <wm4> asked the user to try the patch [16:44:30 CEST] <wm4> no [16:44:41 CEST] <wm4> this is just a basic linking test [16:44:51 CEST] <wm4> #include <libavcodec/version.h> [16:44:51 CEST] <wm4> int main(int argc, char **argv) [16:44:51 CEST] <wm4> { int x[LIBAVCODEC_VERSION_MICRO >= 100 ? 1 : -1]; return 0; } [16:45:03 CEST] <wm4> + using the .pc file cflags/libs [16:45:13 CEST] <jamrial> ah, so the user must have a build with opencl enabled [16:45:18 CEST] <wm4> probably [16:47:20 CEST] <BBB> atomnuker: see code for read_skip [16:47:22 CEST] <BBB> static int read_skip(AV1_COMMON *cm, const MACROBLOCKD *xd, int segment_id, [16:47:23 CEST] <BBB> aom_reader *r) { [16:47:24 CEST] <BBB> if (segfeature_active(&cm->seg, segment_id, SEG_LVL_SKIP)) { [16:47:25 CEST] <BBB> return 1; [16:47:33 CEST] <BBB> so it doesnt actually read any bits from the bitstream if the seg feature is active [16:47:38 CEST] <BBB> afaics [16:58:44 CEST] <atomnuker> oh, didn't notice that [16:59:11 CEST] <atomnuker> still I don't like it because its niche, isn't it? [17:05:26 CEST] <wm4> jamrial: oh, it actually uses libavcodec.pc only [17:13:34 CEST] <wm4> jamrial: ok, I can reproduce, and your patch doesn't fix it [17:13:56 CEST] <wm4> jamrial: the bug is when linking something that uses libavcodec only with libavcodec's .pc file, if opengl is enabled in ffmpeg [17:15:33 CEST] <wm4> I don't see an opencl lib anywhere in the .pc files or in the .so's [17:16:28 CEST] <wm4> oh, make clean + rebuild and your patch fixes it [17:18:05 CEST] <wm4> jamrial: yeah, it adds opencl as dependency to the avutil .so, so push it [17:23:20 CEST] <jamrial> wm4: yeah, opencl is libavfilter and libavutil only for now. i missed the latter [17:23:22 CEST] <jamrial> will push, thanks [17:24:48 CEST] <wm4> Libs.private still doesn't have opencl in it, not sure if that's an issue (and I didn't try a static build) [17:29:40 CEST] <cone-361> ffmpeg 03James Almer 07master:25bd2f4f368a: configure: add missing OpenCL dependency to libavutil [17:47:45 CEST] <wm4> jamrial: user reports some more issues, with a set of switches https://github.com/mpv-player/mpv/issues/4977#issuecomment-336173090 [17:47:59 CEST] <wm4> could be similar issues [18:01:33 CEST] <jamrial> wm4: the user just confirmed the opencl fix solved it [18:01:51 CEST] <jamrial> which is great, because the example configure line he posted enables a shitload of things [18:02:04 CEST] <jamrial> meaning all those are alledgedly working as intended [18:02:49 CEST] <wm4> jamrial: yeah, apparently now everyting is fixed [18:03:05 CEST] <wm4> I thought the user had these problems after your fix, but that was not the case [18:07:49 CEST] <jamrial> curious, though. that configure example enables libxavs and that one is supposedly failing [18:08:04 CEST] <jamrial> haven't pushed the fix for that yet since michaelni hasn't confirmed if it works for him [18:38:22 CEST] <nevcairiel> Maybe his xavs is without pthreads on a platform which doesn't require explicit libm [18:38:54 CEST] <jamrial> could be [18:40:58 CEST] <nevcairiel> That people still bother with xavs however [18:41:11 CEST] <cone-361> ffmpeg 03Ganapathy Kasi 07master:3303f86467ef: nvenc: Remove qmin and qmax constraints for nvenc vbr [18:41:12 CEST] <cone-361> ffmpeg 03James Almer 07master:65c11f1bbac6: Merge commit '3303f86467efa99f23c670707f5be094cc9ce547' [18:41:28 CEST] <nevcairiel> It's a cheap knockoff of h264, and the encoder is probably half x264 as well [18:43:46 CEST] <jamrial> the library hasn't been updated since like 2011 as well [18:44:38 CEST] <jamrial> the latest news in the website is "ffmpeg supports libxavs", even. it's like they made it in and said job done :p [18:44:52 CEST] <wm4> are there any files using it in the wild [19:02:13 CEST] <jamrial> nevcairiel: what i asked above, can you post an example config.mak from macos? [19:08:43 CEST] <jkqxz> wm4: A lot of China. Chinese kit all has it in hardware, too - Allwinner and Rockchip SoCs support it, say. [19:09:16 CEST] <jkqxz> No idea about encoders for it, though. [19:10:30 CEST] <wm4> https://0x0.st/CBu.jpg [19:15:06 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:6eef263aca28: x86: Merge align directives into SECTION_RODATA declarations where possible [19:15:07 CEST] <cone-361> ffmpeg 03James Almer 07master:b78bb51a7cdd: Merge commit '6eef263aca281fb582e1fa3d841ac20ef747a252' [19:21:02 CEST] <cone-361> ffmpeg 03James Almer 07master:6fb580e7d3c4: configure: fix libxavs check [20:00:37 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:808ef43597b1: build: Explicitly set 32-bit/64-bit object formats for nasm/yasm [20:00:38 CEST] <cone-361> ffmpeg 03James Almer 07master:e4ad3e6f6449: Merge commit '808ef43597b1e3d6e69a5b9abe2237c8ddb97b44' [20:05:15 CEST] <cone-361> ffmpeg 03Vittorio Giovara 07master:b44bd7ee7f7d: pixlet: Fix architecture-dependent code and values [20:05:16 CEST] <cone-361> ffmpeg 03James Almer 07master:c54431354a36: Merge commit 'b44bd7ee7f7d834c1e22b5f33674393e5c0267c5' [20:46:08 CEST] <ubitux> durandal_1707: http://b.pkh.me/0001-lavc-pixlet-reduce-diff-with-Libav-cosmetics-only.patch [20:46:22 CEST] <ubitux> there are a bunch of other changes you may or may not want to pick [20:46:33 CEST] <ubitux> such as free/reinit code [20:46:48 CEST] <ubitux> pict_type/color_range/key_frame setting earlier [20:47:01 CEST] <ubitux> sorry, later* (might be a local change they didn't pick) [20:47:08 CEST] <ubitux> various type changes [20:47:20 CEST] <ubitux> hardcoding NB_LEVELS everywhere instead of using a variable [20:47:46 CEST] <ubitux> and aside from the bitstream api, that should be all [20:50:23 CEST] <jamrial> ubitux: unexpected fallout of the extralibs merge: people using custom --extra-ldflags that worked purely by chance because global extralibs added things said custom extra-ldflags were missing [20:51:26 CEST] <jamrial> this merge is revealing a lot of poorly planned configure lines, haha [20:51:41 CEST] <wm4> is it even possible to properly "plan" configure lines [20:51:59 CEST] <jamrial> wm4: not adding random --extra-ldflags for components already detected by configure is a good start [20:52:08 CEST] <wm4> most time I have to do this I can come up with some BS that just barely works and that reviewers are content with [20:52:27 CEST] <wm4> oh you mean configure user invocation? [20:52:30 CEST] <jamrial> yeah [20:52:49 CEST] <ubitux> jamrial: yeah, i think that's a good thing [20:54:17 CEST] <jamrial> ubitux: sure, but please help me explain that to the guy in the ml without him having go mad because the script that worked until now is not working anymore because it probably wasn't correct :P [20:54:33 CEST] <ubitux> tessarek ? [20:55:08 CEST] <jamrial> yeah. he seems to run mac nightlies [20:55:17 CEST] <jamrial> wm4: ^ [20:55:26 CEST] <jamrial> he kinda needs to use git master [20:58:06 CEST] <wm4> seems silly to get mad about occasional instability in git master, and also to use git master for something that should "just work" [21:06:07 CEST] <jamrial> mmh, it appears libbluray does use freetype2 if configured as such [21:07:35 CEST] <jamrial> so if the check is not including bzip2 and zlib for him (both freetype2 deps) then it means pkg-config was not called with --static, or maybe that he lacks a .so for freetype2 [21:08:35 CEST] <ubitux> isn't pkg-config supposed to raise all the static flags if only the static .a is available? [21:09:07 CEST] <wbs> ubitux: there's no such rule, but some projects (like libav/ffmpeg) try to produce such pkg-config files [21:09:08 CEST] <jamrial> i have no idea [21:09:32 CEST] <wbs> there's the pkg-config flag --static as well, which includes those parts; but as a user of pkg-config you can't know if only static libraries are available or not [21:09:58 CEST] <ubitux> but pkg-config knows, so it should raise the --static ones, no? [21:10:06 CEST] <wbs> no, pkg-config doesn't know anything [21:10:24 CEST] <wbs> it's up to the build system of the library that produces the .pc file [21:10:54 CEST] <wbs> whether they even knew and/or cared to promote the .private parts into the public part, if only installing static libs [21:10:56 CEST] <ubitux> mmh, right, so if the project is built with static only it should generate the proper .pc [21:11:04 CEST] <wbs> exactly [21:11:13 CEST] <ubitux> yeah right, i remember figuring that out a while ago [21:11:27 CEST] <wbs> since not all libs do this correctly, in vlc they've got a script which you can run on pkg-config files that fixes this, if you know you've got a static-only build [21:12:19 CEST] <jamrial> so, at least on msys2's package, libbluray.pc has "-lfreetype" as Libs.private instead of having freetype as a package depencency [21:12:43 CEST] <wbs> jamrial: that doesn't really make much of a difference [21:13:04 CEST] <wbs> normally they would put such dependencies into the Depends.private, or what you call it [21:13:08 CEST] <jamrial> even if freetype2 depends on things loke bzip2? [21:13:18 CEST] <wbs> ah, right [21:13:24 CEST] <jamrial> s/loke/like [21:13:47 CEST] <wbs> yes, using package dependecies is better if that dependency also is a potentially static library with further recursive deps [21:14:07 CEST] <ubitux> shouldn't we do that as well for our deps? [21:14:47 CEST] <jamrial> i'm guessing tessarek is missing .so files for some libraries [22:30:57 CEST] <Rathann> hi [22:31:31 CEST] <jamrial> hi [22:37:55 CEST] <cone-361> ffmpeg 03James Almer 07master:4226c57b2b1f: configure: add missing libfontconfig and libfreetype dependencies to showcqt filter [22:41:14 CEST] <jamrial> ubitux: thanks btw for the pixlet cosmetics [22:54:23 CEST] <ubitux> np, it was the easy part [22:56:42 CEST] <jamrial> what did you do wiht the av_clip? [22:56:44 CEST] <jamrial> skipped it? [22:57:17 CEST] <ubitux> what about it? [22:58:45 CEST] <jamrial> their version added an av_clip in a function that we don't have [22:59:06 CEST] <jamrial> i guess you skipped it since it was not a cosmetic change? [22:59:20 CEST] <ubitux> didn't notice anything related to av_clip [23:00:30 CEST] <jamrial> look in line_add_sat_s16() in their version, which was split off lowpass_prediction() [23:03:35 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:003124ebf4a0: build: Fix logic of clock_gettime() check [23:03:36 CEST] <cone-361> ffmpeg 03James Almer 07master:583003670f24: Merge commit '003124ebf4a05f1347c74104216887ddd2e5aad4' [23:04:17 CEST] <ubitux> ah that, yeah it's functionnal changes [23:04:20 CEST] <ubitux> i didn't include that [23:09:36 CEST] <ubitux> i'm still waiting for comments from durandal_1707, and he will probably take over it for the functionnal part [23:10:11 CEST] <durandal_1707> i dont like these cosmetic changes [23:12:02 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:51411eb7ffba: build: Special-case handling of SDL CFLAGS [23:12:03 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:f54037da8af2: build: Make x86 assembler commandline-selectable [23:12:04 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:57b753b445e2: build: Prefer NASM assembler over YASM [23:12:05 CEST] <cone-361> ffmpeg 03James Almer 07master:fb934f23e1b7: Merge commit '57b753b445e23363c997a8ec1c556e0b0f6e9da3' [23:12:44 CEST] <durandal_1707> mostly because they are pointless [23:13:24 CEST] <jamrial> ubitux: i'd not bother renaming the get_bits variables from b to bc. those lines will still differ from libav since they use the new bitstream reader [23:13:32 CEST] <jamrial> durandal_1707: they help with merges [23:15:53 CEST] <cone-361> ffmpeg 03Carl Eugen Hoyos 07master:c87bb9c04af8: lavc/ppc/fft_init: Fix compilation on ppc64le with --disable-vsx. [23:24:10 CEST] <Rathann> w00t, it looks like FDK AAC is now almost free: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [23:25:24 CEST] <jamrial> Rathann: can we remove the nonfree dep then? [23:25:30 CEST] <durandal_1707> no [23:25:39 CEST] <jkqxz> What licence does this version have? [23:25:56 CEST] <Rathann> the forked source with SBR, TNS and some other stuff stripped is considered free by RH legal [23:27:00 CEST] <kierank> Rathann: what BS [23:27:07 CEST] <atomnuker> " No other AAC implementations (regardless of copyright license) are permitted in Fedora at this time." <- pricks [23:29:15 CEST] <Rathann> jkqxz: not any of the standard ones [23:30:17 CEST] <Rathann> however, the problematic clause (that the (copyright) license only covers compliant AAC implementations, a use case restriction) appears to have been removed from the original FDK AAC license [23:32:23 CEST] <durandal_1707> lets sue them! [23:32:57 CEST] <Rathann> durandal_1707: huh? what for? [23:33:20 CEST] <kierank> Rathann: the problem is "You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized [23:33:21 CEST] <kierank> by appropriate patent licenses." [23:33:40 CEST] <kierank> i guess if redhat legal think the stuff isn't patented then perhaps fine [23:35:57 CEST] <Rathann> kierank: yes, apparently they do think so now [23:36:46 CEST] <kierank> maybe we should do the same [23:36:53 CEST] <kierank> have a special --enable-heaac build [23:37:32 CEST] <Rathann> your call, I'm just here to give the news ;) [23:38:06 CEST] <Rathann> and working on reviewing the package to get it into Fedora [23:38:26 CEST] <atomnuker> kierank: wouldn't help, redhat want the source code to not contain patents _too_ [23:38:39 CEST] <atomnuker> they go to great lengths for that [23:38:52 CEST] <kierank> the source code? [23:38:53 CEST] <kierank> huh [23:38:59 CEST] <kierank> oh [23:39:01 CEST] <kierank> blimey [23:39:04 CEST] <kierank> that's dumb [23:39:13 CEST] <Rathann> atomnuker: this is about the fork at https://cgit.freedesktop.org/~wtay/fdk-aac/log/?h=stripped2 [23:39:18 CEST] <Rathann> not the original fdk-aac [23:39:54 CEST] <Rathann> as I said earlier, some stuff is stripped (probably the parts RH legal thinks are covered by some unexpired patents) [23:41:20 CEST] <Rathann> kierank: remember RH is US-based, so they're subject to dumb US patent law and courts [23:41:46 CEST] <Rathann> so they don't want to distribute anything that's patented [23:41:54 CEST] <Rathann> including source code [23:43:23 CEST] <jkqxz> michaelni: Ping cbs patchset again? (Or shall I resend the full set?) [23:43:54 CEST] <wm4> distributing source code that contains patented algorithms is legally no problem [23:44:23 CEST] <wm4> (other than the hysteric fact that algorithms can't be patented even in the US) [23:52:37 CEST] <TD-Linux> US patent law (along with the EU I believe) makes no distinction between source code and binaries [23:53:00 CEST] <ubitux> durandal_1707: it's to help you figuring out the remaining functionnal changes [23:53:22 CEST] <ubitux> durandal_1707: as you can see there are a bunch of stuff that may be interesting to us [23:53:33 CEST] <durandal_1707> i dont care [23:53:49 CEST] <ubitux> k [23:54:17 CEST] <ubitux> well then, patch dismiss, do as you please [23:54:52 CEST] <durandal_1707> ubitux: no you can apply it im not dictator [23:55:06 CEST] <ubitux> it's your code and you're maintaining it [23:55:14 CEST] <ubitux> no? [23:55:47 CEST] <durandal_1707> no, i dont care for cosmetics ., just dont break decoder [23:56:22 CEST] <ubitux> i only imported the cosmetics so you can care about the functionnal changes [23:56:31 CEST] <ubitux> i'm not qualified to make functionnal changes to that code, so i won't [23:57:33 CEST] <durandal_1707> whatever, i picked what was usefull already [23:59:09 CEST] <ubitux> http://b.pkh.me/pixletdiff.html [23:59:14 CEST] <ubitux> this is the diff post cosmetics [00:00:00 CEST] --- Fri Oct 13 2017

1 0

ffmpeg.log.20171012
by burek 13 Oct '17

13 Oct '17

[00:04:42 CEST] <Johnjay> what's the significance of using 10 bits for HEVC? [00:05:29 CEST] <durandal_1707> more colors, no banding... [00:05:31 CEST] <JEEB> 10bit improves compression if nothing else [00:06:12 CEST] <JEEB> it was already useful in AVC, but unfortunately nothing supported it except for mainconcept's sw decoder (which made playback of 10bit with flash possible, funny enough) [00:07:42 CEST] <TD-Linux> due to increased transform accuracy, it's less useful for AV1 and VP9 [00:07:46 CEST] <TD-Linux> it still gives you a percent or two [00:08:05 CEST] <alexpigment> as durandal said, 10-bit gets rid of most visible banding. a lot of people's brains are just trained to accept it, but gradients look AWFUL in all 8-bit video, which is most of the video industry at this point [00:08:53 CEST] <alexpigment> of course, bandwidth starving 8-bit video doesn't help gradients either, but unfortunately that's the norm [00:23:54 CEST] <toblorone> Hi this is probably off topic, but someone in the math channel suggested i ask here [00:23:57 CEST] <toblorone> dumb question: I'm implementing some image processing stuff, and I'd like to filter out a certain frequency band in the time domain. I know I can do this using a convolution, but I'm not sure how i'd go about designing the kernel. [00:36:42 CEST] <DocHopper> JEEB: Is there a way to sync FFMPEG with the system clock? That might allow me to get by without needing atomic updates. [01:17:08 CEST] <DocHopper> Can FFMPEG choose which .txt file to drawtext from based on the .txt's file number? [01:19:43 CEST] <JEEB> I think at that point I recommend you take a read of drawtext's source code. it's under libavfilter/vf_drawtext.c I guess? [01:22:20 CEST] <DocHopper> Thanks! [01:22:41 CEST] <DocHopper> Even just editing drawtext so if the file it is empty it retains the last value, but continues trying to read. [01:26:06 CEST] <DocHopper> JEEB: Sorry for noob questions, bust that's within ffmpeg? [01:30:23 CEST] <JEEB> DocHopper: yes [01:30:31 CEST] <JEEB> FFmpeg consists of multiple libraries [01:30:53 CEST] <JEEB> ffmpeg.c is just one of the API client tools that come with the code [01:31:51 CEST] <DocHopper> So I'll need to grab the source code, right? [01:55:23 CEST] <DocHopper> JEEB: Wow, there is a lot of stuff in FFMPEG! Looks like it throws at least 2 errors when the file can't be read, and only one comes from vf_drawtext.c [01:55:53 CEST] <JEEB> DocHopper: yes, yes there is :) [01:56:05 CEST] <JEEB> the libraries are very far-reaching [01:56:36 CEST] <DocHopper> JEEB: Any clever methods of tracking down file interactions? [02:48:29 CEST] <FishPencil> Any ideas why I'm getting this error when compiling FFmpeg with gnutls on macOS? https://paste.ubuntu.com/25723363/ [02:58:29 CEST] <c3r1c3-Win> Not the correct version of GNUtls? Or trying to link to the wrong one? [02:59:09 CEST] <FishPencil> Is 3.5.15 supported? [02:59:35 CEST] <c3r1c3-Win> I don't know the answer to that one. [04:32:31 CEST] <djfk> how to simulate client request different video stream? [07:12:41 CEST] <nate> Well, that's uh, really nice that firefox no longer warns you when updating that certain plugins won't work anymore [07:12:56 CEST] <nate> whoop wrong channel lol [07:13:13 CEST] <nate> was one click off [14:29:15 CEST] <pankaj_> can anybody help me to compress mp4 videos [14:29:42 CEST] <pankaj_> i have using [14:29:42 CEST] <pankaj_> -f mp4 -vcodec h264 -acodec mp2 -threads 4 [14:29:56 CEST] <pankaj_> and -acodec mp2 [14:31:35 CEST] <pankaj_> here is my code https://pastebin.com/d3H1B7RB [14:36:02 CEST] <ritsuka> what's the problem? [14:36:11 CEST] <ritsuka> by the way, you should use aac instead of mp2 [14:39:37 CEST] <pankaj_> thanks for reply ritsuka [14:40:08 CEST] <pankaj_> already try acc [14:40:29 CEST] <pankaj_> other option [14:41:33 CEST] <Sharkigator> yeah, but what is the output? [14:44:43 CEST] <relaxed> pankaj_: https://trac.ffmpeg.org/wiki/Encode/H.264 [14:53:46 CEST] <pankaj_> Sharkigator getting same size video [14:54:07 CEST] <Sharkigator> and what do you expect? [14:55:25 CEST] <pankaj_> small size then real mp4 file [14:56:31 CEST] <Sharkigator> did you look at the link by relaxed? [14:56:52 CEST] <pankaj_> yes but not fond any help [14:57:28 CEST] <pankaj_> can you send me any help full link or any help [14:57:29 CEST] <pankaj_> ? [14:57:44 CEST] <Sharkigator> if you want a smaller size, you'll have to choose a slower encoding preset or choose a lower quality [14:57:57 CEST] <Sharkigator> and it is a full link [14:59:13 CEST] <Sharkigator> you can for example do -preset slower -crf 27 [14:59:33 CEST] <Sharkigator> the higher the crf, the lower the quality and the smaller the file [15:10:21 CEST] <pankaj_> Sharkigator not getting help with this [15:10:40 CEST] <pankaj_> can you send me any example link [15:10:50 CEST] <Sharkigator> what are you getting? [15:11:11 CEST] <pankaj_> same file [15:11:25 CEST] <Sharkigator> does it tell you any error? [15:11:52 CEST] <pankaj_> no [15:12:11 CEST] <pankaj_> i' trying with 10,55,736 bytes files size [15:12:21 CEST] <Sharkigator> did you try using different crf values? [15:13:01 CEST] <pankaj_> yes superfast,slow [15:13:30 CEST] <Sharkigator> and what is the log output of ffmpeg? [15:16:44 CEST] <pankaj_> not check [15:16:59 CEST] <Sharkigator> ? [15:16:59 CEST] <pankaj_> how can i check this [15:17:14 CEST] <Sharkigator> you run it in the commandline? [15:18:42 CEST] <Sharkigator> or how do you run ffmpeg? [15:20:51 CEST] <pankaj_> using php file on server [15:21:24 CEST] <pankaj_> exec("ffmpeg -i input -c:v libx264 -preset fast -crf 22 -c:a output); [15:21:38 CEST] <Sharkigator> then try it locally first [15:22:22 CEST] <Sharkigator> or find a way to get the stderr from that process [15:25:43 CEST] <beauty> hello [15:26:12 CEST] <beauty> how to play video using ffplay without image and audio [15:26:20 CEST] <beauty> just simulate process [15:27:26 CEST] <pankaj_> beauty check this https://www.ostechnix.com/20-ffmpeg-commands-beginners/ [15:28:28 CEST] <beauty> it doesn't have what I need [15:30:46 CEST] <Sharkigator> can't you run ffmpeg with a null output? [15:30:49 CEST] <Sharkigator> ffmpeg -i input -f null - [15:37:49 CEST] <beauty> Sharkigator: I want to simulate player process [15:38:00 CEST] <Sharkigator> does it not work? [15:38:09 CEST] <beauty> Using ffmpeg will exit quickly [15:38:13 CEST] <paveldimow> Hi guys, does anyone can recommend transport protocol that can be used to achieve the lowest latency possible? I know of RTMP, is there anything else supported by FFmpeg? [15:38:53 CEST] <beauty> For example, a video of 5 min ,using ffplay , it's for 5min,but using ffmpeg few seconds [15:39:13 CEST] <Sharkigator> you can add the -re flag for that [15:39:31 CEST] <Sharkigator> then it will decode it at playback speed i think [15:41:09 CEST] <beauty> Sharkigator: it seems work [15:41:36 CEST] <Sharkigator> i still don't know why you would want to do that [15:46:44 CEST] <beauty> I want to simulate multi clients request nginx server. [15:48:49 CEST] <beauty> Sharkigator: Is there better server stress test tools? [15:49:03 CEST] <Sharkigator> i don't know [15:52:44 CEST] <beauty> thanks [15:56:12 CEST] <redrabbit> you can always give the link [16:13:09 CEST] <beauty> ffmpeg -re -i input.mp4 -f null - 2> /dev/null & [16:13:29 CEST] <beauty> why does this command not work? [16:14:05 CEST] <JEEB> don't throw away the stderr first of all so you can see? [16:17:17 CEST] <beauty> JEEB: I can't see, could you show me? [16:25:25 CEST] <beauty> why ffmpeg process in background running, but cpu usage is 0? [16:25:31 CEST] <celyr> beauty, ffmpeg -re -i input.mp4 -f null - [16:26:28 CEST] <beauty> I want ffmpeg process to be in shell background. [16:42:18 CEST] <beauty> I have solve it [16:42:47 CEST] <beauty> so how to make ffmpeg not to decode data? [16:52:10 CEST] <vbnunes> hello all [16:52:21 CEST] <relaxed> beauty: use screen/tmux or ffmpeg -i ... 2>log.txt </dev/null & [16:53:18 CEST] <beauty> thank [16:53:22 CEST] <beauty> I have solved [16:53:58 CEST] <vbnunes> I'm trying to stream a STANAG video+data to a tcp port using ffmpeg with a STANAG video on loop, which resets the timestamps to current time [16:54:59 CEST] <vbnunes> i'm doing this by reading from a playlist but I cannot reset the timestamps [16:56:53 CEST] <vbnunes> ffmpeg -re -f concat -safe 0 -i playlist.txt -map 0:0 -map 0:2 -c copy -f mpegts tcp://something:1234 [16:57:08 CEST] <vbnunes> can anyone help? [17:23:55 CEST] <subli> vbnunes: since this place is pretty dead. YOu could try the VLC development channel (also on freenode) [17:24:10 CEST] <subli> It's very active [17:24:59 CEST] <subli> #videolan [17:36:46 CEST] <vbnunes> thanks subli [19:23:34 CEST] <doublya> Building ffmpeg against Cuda9.0, getting ERROR: libnpp not found [19:25:24 CEST] <BtbN> doublya, update your ffmpeg. [19:25:32 CEST] <doublya> thanks! [19:26:02 CEST] <BtbN> Isn't that fairly obvious of a solution? [19:55:52 CEST] <kwizart> hello, any reaction on this https://www.phoronix.com/scan.php?page=news_item&px=Fedora-FDK-AAC ? (will you make fdk-aac free now that fedora(-legal) consider this to be legal item ? [19:56:15 CEST] Action: kwizart is going to dinner, but will be around for comments later tonight or tommorrow [19:57:06 CEST] <JEEB> kwizart: IIRC the only problem with fdk-aac was that it was incompatible with (L)GPL and thus you couldn't match it with anything else [19:57:11 CEST] Action: JEEB goes read [19:59:15 CEST] <JEEB> kwizart: because debian/ubuntu also distribute fdk-aac but they don't link it against such things specifically [19:59:28 CEST] <JEEB> gstreamer is a special case because you aren't linking, it's run-time plugin based stuff [20:05:22 CEST] <BtbN> A lot of distributions distribute fdk-aac, and there is nothing that prevents them, they are not linking to it. [20:05:35 CEST] <BtbN> But fdk-aac is clearly not L/GPL compatible [20:05:49 CEST] <JEEB> yes [20:06:06 CEST] <JEEB> the point of putting A and B together is where the non-distributability comes in [20:07:43 CEST] <BtbN> I wonder why fdk-aac in fedora is such a big deal. They definitely also ship ffmpeg, which has an aac decoder and also a very decent encoder since recently. [20:17:25 CEST] <JEEB> BtbN: fedora doesn't shit FFmpeg tho [20:17:32 CEST] <JEEB> *ship [20:17:41 CEST] <JEEB> it prefers small chunks of code they can review [20:17:45 CEST] <JEEB> which doesn't work with FFmpeg [20:17:56 CEST] <JEEB> even if they disable things the legal team needs to be OK with *all* of the code base [20:18:06 CEST] <JEEB> which is why FFmpeg getting officially packaged is highly unlikely [20:18:15 CEST] <JEEB> rpmfusion will of course havei t [20:20:19 CEST] <BtbN> that sounds highly impracticel [20:20:28 CEST] <BtbN> So they don't have any popular multimedia software? [20:20:36 CEST] <BtbN> Or do they just build everything without ffmpeg support? [20:20:47 CEST] <JEEB> I think VLC isn't packaged, either [20:20:52 CEST] <JEEB> among other things [20:21:16 CEST] <JEEB> basically for AC3 they ripped out the AC3 thing from libavcodec I think [20:21:29 CEST] <JEEB> for MP3 they of course took that old library no longer remembers [20:21:34 CEST] <JEEB> mp123 was it? [20:22:00 CEST] <JEEB> I actually asked about just building FFmpeg with components disabled, but they told me that the whole thing would have to be lawyer-OK'd [20:39:37 CEST] <pxl> Hey! anyone in here know if you can use ffmpeg to get the SPS and PPS for a .ts fragment? Trying to make a tool to generate DASH ISO-BMFF manifests [20:55:22 CEST] <BtbN> it definitely can. But I'm not sure if there is a public API for it [20:55:35 CEST] <BtbN> It can just generate DASH for you though. [21:30:54 CEST] <kerio> wasnt fedora just redhat linux without redhat [21:39:01 CEST] <JEEB> kerio: no, it's the development branch of red hat [21:39:16 CEST] <kerio> they must have a big testing team ;o [21:39:34 CEST] <JEEB> basically fedora is what then becomes with time into RHEL [21:39:40 CEST] <JEEB> and centos is the RHEL fork [21:39:48 CEST] <JEEB> which rebuilds all the packages without red hat references [21:40:44 CEST] <tdr> eh rebuilds them sure, not so much removing all the references [21:42:12 CEST] <JEEB> https://wiki.centos.org/FAQ/General#head-c52e59ddb12b54379688ce386b0ffafc18… [21:42:51 CEST] <JEEB> basically they remove it where it's required [21:54:57 CEST] <doublya> building from ffmpeg master branch. Having a issue with kvazaar: kvazaar/src/threadqueue.c:410: undefined reference to `pthread_join' [21:57:01 CEST] <DHE> something's gone wrong in your configure script. you can work around with --extra-ldflags=-pthread [21:57:32 CEST] <JEEB> anyways, kvazaar is not FFmpeg [21:58:20 CEST] <DHE> ah, it's their internal code doing that and not ffmpeg's [21:59:28 CEST] <JEEB> yup [22:06:10 CEST] <doublya> strange. I needed to link -lm for libmp3lame as well [22:08:34 CEST] <mulander> anyone else gettin a 504 when trying to register an account on trac? [22:12:00 CEST] <mulander> nvm, worked on 2nd try [22:25:52 CEST] <doublya> with ffmpeg master branch, v4l2 is not an enabled indev [22:27:19 CEST] <doublya> The only thing suspect in the config.log is libv4l2='no' [22:32:16 CEST] <kepstin> doublya: it's not enabled by default, are you using '--enable-libv4l2' on configure? [22:34:22 CEST] <doublya> Thanks, must be a change from the older version I was using. I added the flag. Not the linker can't find libv4l2 [22:35:06 CEST] <doublya> I have libv4l-dev package installed [00:00:00 CEST] --- Fri Oct 13 2017

1 0

ffmpeg-devel.log.20171011
by burek 12 Oct '17

12 Oct '17

[00:00:29 CEST] <nevcairiel> isnt value 13 sRGB (AVCOL_TRC_IEC61966_2_1) - IEC 61966-2-1 (sRGB or sYCC) [00:03:29 CEST] <durandal_1707> srgb is supported already [00:04:51 CEST] <wm4> nevcairiel: hm right [00:04:56 CEST] <wm4> we use that too [00:05:09 CEST] <wm4> could use a nicer alias I guess [00:17:22 CEST] <nevcairiel> for that matter, that one is already hooked up in vf_zscale [00:18:28 CEST] <thebombzen> I had no idea that sRGB was IEC 61966-2-1 [00:18:42 CEST] <thebombzen> maybe srgb as an alias, or at least add that to the documentation [00:21:22 CEST] <nevcairiel> technically it is in the docs, at least the header and the doxygen [00:32:32 CEST] <llogan> thebombzen: feel free to mention it in filters.texi if you like [00:32:49 CEST] <thebombzen> yea tha'ts what I meant. [00:33:16 CEST] <thebombzen> I'll patch filters.texi to say "note: iec61966-2-1 is another name for sRGB." [00:33:40 CEST] <thebombzen> unless it's actually added as an alias [00:34:20 CEST] <nevcairiel> that seems weird and non-standard, should just write "IEC 61966-2-1 (sRGB or sYCC)" in there like in the header file and the 23001-8 spec [00:39:48 CEST] <thebombzen> that works, although the filters don't have descriptions [00:41:59 CEST] <llogan> an alias doesn't seem like a bad idea to me [01:11:48 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:e38f280fece3: avcodec/mpeg4videodec: Use 64 bit intermediates for sprite delta [01:11:50 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:127a362630e1: avcodec/mpeg_er: Clear mcsel in mpeg_er_decode_mb() [01:11:50 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:bdee75a4e750: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_53iL0() [01:11:51 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:c20f4fcb74da: avcodec/ffv1dec: Fix out of array read in slice counting [01:11:52 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:56822b074b50: avcodec/mips: preload data in hevc sao edge 135 degree filter msa functions [01:11:54 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:af9433b1d687: avcodec/mips: Improve avc bi-weighted mc msa functions [01:11:54 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:b59323cb72c5: avcodec/mips: Improve avc chroma hv mc msa functions [01:11:55 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:662234a9a22f: avcodec/mips: Improve avc put mc 21, 23 and 02 msa functions [01:11:56 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:eadb91164324: avcodec/mips: Improve hevc uni-w horiz mc msa functions [01:11:57 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:ff53f4dc2dd8: avcodec/mips: Improve avc uni copy mc msa functions [01:11:58 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:832fc05a9bc7: avutil/frame: Fix project name [01:11:59 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:ed8ff608b2b4: doc/APIchanges: Update [02:43:37 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:e1de9eab3a43: Bump minor versions for branching 3.4 [02:43:38 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:92ae4ab56d0d: doc/APIchanges: Add 3.4 cut point [02:43:39 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:74d2bbb70dbe: avcodec/opusenc_psy: Fix mixed declaration and statement [02:43:40 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:7bec3f78da25: avcodec/rkmppdec: check wether typo [02:44:25 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07release/3.4:HEAD: avcodec/rkmppdec: check wether typo [02:54:38 CEST] <Zeranoe> What is the primary FFmpeg source repo? http://git.videolan.org/?p=ffmpeg.git https://git.ffmpeg.org/ffmpeg ? The videolan one looks slightly newer [02:56:02 CEST] <Zeranoe> Actually they look the same now [03:01:00 CEST] <jamrial> Zeranoe: both are "official", and are always in sync (maybe with a bit of a delay) [03:02:56 CEST] <Zeranoe> Alright... If I was to pick one which would it be? [03:03:44 CEST] <michaelni> best to pick what is on our download page [03:06:23 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:80154b1b3a0a: Bump version for master after 3.4 branchpoint [03:06:24 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:e4d5310a507d: RELEASE: update for git after 3.4 branchpoint [03:44:07 CEST] <atomnuker> michaelni: what name is 3.4 going to have? [03:51:12 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07release/3.4:b1ec41a64f2d: add release notes based on release 3.3 [03:52:19 CEST] <michaelni> atomnuker, the one that was suggested (cantor) [03:54:45 CEST] <atomnuker> cool [15:31:28 CEST] <jamrial> ubitux: did you have time to test the merge? [15:32:07 CEST] <jamrial> i'm mainly interested in being sure the macos stuff still works, but general testing with assorted external libraries would also be nice [15:41:31 CEST] <ubitux> jamrial: check_apple_framework VideoToolbox "-framework CoreFoundation -framework CoreMedia -framework CoreVideo" [15:41:34 CEST] <ubitux> this looks weird [15:41:51 CEST] <ubitux> those are extralibs for the decoder (or encoder), not for the framework itself [15:42:30 CEST] <ubitux> i can't really test as i won't have access to a macos for about 2 wks [15:42:49 CEST] <jamrial> ubitux: they are currently set as videotoolbox_extralibs [15:43:04 CEST] <jamrial> that's why i moved them to the check [15:43:48 CEST] <jamrial> i can make them extralibs for the decoder/encoder if you prefer. that'll be cleaner as well [15:43:58 CEST] <jamrial> what about CoreImage? [15:44:23 CEST] <ubitux> ah indeed that's probably a mistake then [15:44:56 CEST] <ubitux> jamrial: every framework/dependency is supposed to be independent from each other [15:45:06 CEST] <jamrial> ok, will make them extralibs for the modules then [15:45:11 CEST] <ubitux> but our codecs/filters may require more of them [15:46:12 CEST] <ubitux> what is this libfreetype change? [15:46:57 CEST] <ubitux> ah actually you're fixing a bunch of inconsistencies [15:47:19 CEST] <jamrial> the first argument for require/check/use_pkg_config needs to be the same name as the configure module [15:47:26 CEST] <jamrial> yeah [15:48:35 CEST] <jamrial> ubitux: there are a lot of videotoolbox modules. hwaccels, encoders... do you know which extralib is for which? [15:49:10 CEST] <ubitux> you should probably keep the current behaviour, we can fix it later [15:49:16 CEST] <ubitux> i didn't realize it was already kinda wrong [15:49:27 CEST] <jamrial> ok [15:50:15 CEST] <ubitux> --disable-autodetect --enable-libxcb [15:50:20 CEST] <ubitux> grep LIBXCB config.h [15:50:23 CEST] <ubitux> is this on purpose ^ ? [15:50:39 CEST] <ubitux> http://sprunge.us/fAgE [15:50:54 CEST] <ubitux> maybe that's because of your recent change [15:51:29 CEST] <ubitux> LIBXCB_{SHM,SHAPE,XFIXES} to 1 doesn't matter if LIBXCB is 0 [15:51:42 CEST] <ubitux> but the other way around is kinda problematic [15:52:15 CEST] <jamrial> what's the expected behavior of that command line? [15:52:49 CEST] <ubitux> LIBXCB{,_SHM,_SHAPE,_XFIXES} to 1 [15:52:54 CEST] <jamrial> and wouldn't xcb will compile if those three are 0 but libxcb 1? they are not listed as dependencies of libxcb [15:53:40 CEST] <ubitux> i would say that you want either libxcb and all its sub deps, or none of them [15:53:48 CEST] <ubitux> but not a custom subset [15:54:00 CEST] <ubitux> (unless you don't have them on your system ofc) [15:54:47 CEST] <ubitux> we should probably hide libxcb-{shm,shape,xfixes} but well [15:54:50 CEST] <jamrial> ubitux: disable autodetec does a disable_weak on every autodeted module. and every libxcb check is done only after an enabled libxcb_* check [15:55:27 CEST] <ubitux> it's just kinda weird to have to do enable every libxcb component when you actually want it [15:55:40 CEST] <ubitux> anyway, can be changed later, i guess [15:56:11 CEST] <jamrial> did this change recently? i don't think i altered how these were detected [15:57:20 CEST] <ubitux> i this shm/shape/xfixes were at 1 with --disable-autodetect --enable-libxcb [15:57:23 CEST] <ubitux> i think* [15:58:13 CEST] <ubitux> i'm going to do a few more test [15:58:15 CEST] <ubitux> +s [15:58:41 CEST] <ubitux> did you test lavfi with its optionnal deps? [16:00:14 CEST] <jamrial> which ones? external libraries? [16:00:49 CEST] <ubitux> if you have filters like afir, lavfi will depend on lavc [16:01:21 CEST] <ubitux> look for the bunch of prepend avfilter_deps ... in the configure [16:02:21 CEST] <ubitux> i think these are supposed to show up at some point, somewhere in the build... i don't remember the details [16:02:29 CEST] <ubitux> maybe in the .pc? [16:02:44 CEST] <jamrial> in config.mak, avfilter_FFLIBS [16:03:05 CEST] <jamrial> and yeah, looks like prepend() still adds the library deps just fine [16:04:02 CEST] <ubitux> they're not supposed to show up in the pc file? [16:06:09 CEST] <jamrial> yes, they also show up there [16:07:05 CEST] <ubitux> as Libs? [16:07:43 CEST] <jamrial> in the requires: line [16:08:04 CEST] <jamrial> with minimum required version and such [16:08:55 CEST] <ubitux> but aren't you supposed to have them in the link as well? [16:10:03 CEST] <ubitux> like, ok you require the other libraries to be installed, but when linking against libavfilter, if it depends on libavcodec for some filter you will also have to raise that flag [16:10:15 CEST] <ubitux> maybe that's not the case currently though.. [16:13:05 CEST] <ubitux> seems pkg-config understands the current state [16:13:08 CEST] <jamrial> the .pc file looks the same as before except it now lists only the avfilter extralibs (the point of this patch, basically) [16:13:09 CEST] <ubitux> you can ignore my comment [16:13:10 CEST] <jamrial> but since it mentions dependency on the other libraries, linking by using pkg-config should still work the same [16:13:58 CEST] <ubitux> yeah i tried pkg-config --static --libs libavfilter and it works pretty much fine after post merge [16:14:06 CEST] <ubitux> anyway [16:14:10 CEST] <ubitux> i don't see any obvious problem [16:17:04 CEST] <ubitux> jamrial: you are waiting to apply this after the release? [16:17:12 CEST] <ubitux> or the release is already branched out? [16:17:32 CEST] <jamrial> yeah, it's branched out so there's nothing holding this merge [16:17:46 CEST] <jamrial> other than making sure it works :p [16:18:11 CEST] <ubitux> yeah i'm not sure about the macos stuff, but i can't test [18:00:50 CEST] <jamrial> ubitux: pushed a version that's a bit cleaner with the macos stuff [19:36:26 CEST] <jamrial> ubitux: why is there a videotoolbox_encoder module in configure? it's not used anywhere in the tree and it seems to just add indirection to the whole dep checking process for h264_videotoolbox_encoder [19:38:37 CEST] <ubitux> jamrial: yeah it's an indirection; but typically you for hevc_videotoolbox_encoder you would depend on it too [19:38:38 CEST] <wm4> is it for when other codecs might be added? [19:38:51 CEST] <ubitux> and that would prevent from expliciting again all the deps of the common vt enc code [19:39:05 CEST] <jamrial> ah, yeah, that's true [19:39:16 CEST] <ubitux> (that is, currently, dep on vt framework and its encode function) [19:39:36 CEST] <ubitux> btw, what are these suggest thing? [19:39:38 CEST] <ubitux> :D [19:40:21 CEST] <jamrial> "add it to my list of things i use/depend on if it's enabled, but don't if it's not", or something like that [19:40:36 CEST] <ubitux> mmh. ok [19:42:17 CEST] <jamrial> so, since coregraphics, applicationservices and coreservices are all optional and check_lib() doesn't add everything to global extralibs anymore, i need to state what modules have use for them [19:53:59 CEST] <thebombzen> re: earlier sRGB alias. Is there a way to add option aliases easily, or would I just do something like this? https://0x0.st/CbJ.log [19:54:18 CEST] <thebombzen> (+ appropriate filters.texi documentation, of course) [20:49:34 CEST] <durandal_1707> thebombzen: just add entry with same option but different name [20:49:53 CEST] <thebombzen> so in other words exactly what I posted in my 0x0.st log? [21:25:16 CEST] <atomnuker> jamrial: vega really doesn't look bad here - http://www.guru3d.com/articles_pages/asus_radeon_rog_rx_vega_64_strix_8gb_r… [21:25:28 CEST] <atomnuker> its around 200 quid cheaper than a 1080ti here too [21:34:52 CEST] <nevcairiel> its also quite a bit slower then a 1080ti, its more inline with a 1080 [21:35:17 CEST] <nevcairiel> (looking at a benchmark at 1080p thats likely CPU bound is not very useful, fwiw) [21:36:28 CEST] <atomnuker> a 1080 is around 70 quid less expensive, I'd say that's a small price to pay for good linux support [21:36:54 CEST] <atomnuker> (also it has 4x4 sad instructions!) [21:37:22 CEST] <atomnuker> (though you'll likely need to write raw asm to get to those) [21:38:45 CEST] <wm4> asm on GPUs? wut [21:38:53 CEST] <wm4> even spir-v is way way higher level [21:39:13 CEST] <wm4> so you'd need to write driver-specific code using driver-specific APIs [21:42:34 CEST] <TD-Linux> nvidia has PTX, their """raw""" asm [21:42:54 CEST] <nevcairiel> amd calls it "AMDGCN assembly" [21:43:29 CEST] <TD-Linux> AMD's is a bit different in that they actually define the binary format that the GPU executes [21:50:08 CEST] <atomnuker> there's llvm support for compiling instinsic-like code to opencl kernels though [21:51:29 CEST] <atomnuker> its a matter of time before spriv is extended to support arbitrary raw instructions though [21:54:22 CEST] <Compn> why cpu faster at computing than the cpu haha [21:54:27 CEST] <Compn> er gpu faster* [21:54:28 CEST] Action: Compn runs [22:49:56 CEST] <cone-265> ffmpeg 03Marton Balint 07master:58143b15adda: configure: remove libdl dependency from libndi_newtek [22:53:12 CEST] <cone-265> ffmpeg 03Marton Balint 07release/3.4:c8642473e0b3: configure: remove libdl dependency from libndi_newtek [22:58:26 CEST] <jkqxz> michaelni: Do you have any more comments on the cbs series? [23:16:30 CEST] <jamrial> michaelni: all your openbsd fate clients are failing with "ffmpeg: cannot execute - Permission denied" [23:20:51 CEST] <jamrial> maybe ff6de6b180 is at fault [23:23:22 CEST] <jkqxz> strip there doesn't mark the target as executable? [23:25:04 CEST] <jamrial> could be. cp+strip does, but strip alone does not [23:26:27 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:7cb1d9e2dbbe: build: Fine-grained link-time dependency settings [23:26:28 CEST] <cone-265> ffmpeg 03James Almer 07master:6dfcbd80ad44: Merge commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63' [23:30:10 CEST] <durandal_1707> haha Compn haha [23:33:38 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:fde7ee8710e9: x86: hevc: Add missing colons after assembly labels [23:33:39 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:58407b4d74c9: configure: Fix typo in objcc default setting [23:33:40 CEST] <cone-265> ffmpeg 03James Almer 07master:9244524177b5: Merge commit '58407b4d74c99e30dbd40fe468c69dbd25ea4255' [23:35:37 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:4d1f7e8bc751: build: Skip generating .version files when cleaning [23:35:38 CEST] <cone-265> ffmpeg 03James Almer 07master:f6a959adff30: Merge commit '4d1f7e8bc7516e6b7b15f754af4a665b3f8af79e' [23:38:56 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:d1d6230ea3dd: build: Add "build" shorthand target that depends on all compile targets [23:38:57 CEST] <cone-265> ffmpeg 03James Almer 07master:5adc1f14f91b: Merge commit 'd1d6230ea3dd2c34bcd121f958706f3177f8d8c5' [23:41:54 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:39e208f4d475: build: Generalize yasm/nasm-related variable names [23:41:55 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:3c0efbd03349: build: Allow generating dependencies as a side-effect of assembling [23:41:56 CEST] <cone-265> ffmpeg 03James Almer 07master:9908eac21866: Merge commit '3c0efbd03349ae68d3a25a082222652a102e3fd4' [23:46:09 CEST] <BtbN> The Vega64 uses like 150-200W more, for the same performance as a 1080. That's a big "no thanks" right there. [23:47:10 CEST] <atomnuker> now now its clearly faster than a 1080 [23:47:59 CEST] <BtbN> it's slightly faster, in some benchmarks [23:48:05 CEST] <BtbN> And uses a lot more power, in all of them [23:48:30 CEST] <BtbN> It even uses a lot more power than a 1080Ti, which is significantly faster than the Vega [23:49:18 CEST] <BtbN> And the price difference between the Vega64 and a 1080Ti is just 100¬ [23:50:06 CEST] <BtbN> The only reason I could possibly think about buying a Vega GPU is to support AMD. But in every technical aspect it looses to nvidia. [23:51:14 CEST] <jamrial> or if you're a miner [23:53:16 CEST] <BtbN> even then I doubt the extreme power consumption of those cards makes them worth it [23:55:09 CEST] <atomnuker> its not *that* bad, the vega still pulls ahead in some benchmarks [00:00:00 CEST] --- Thu Oct 12 2017

1 0

ffmpeg.log.20171011
by burek 12 Oct '17

12 Oct '17

[00:24:42 CEST] <storrgie> I have an ignorant noobish question... I'm trying to figure out how to record 20-60 machines visual and audio outputs while they are playing a game. I am OK to record this to their local disk and retrieve it later. When I asked some colleges about this they suggested things like Shadowplay and OBS as solutions... I was thinking, doesn't ffmpeg have desktop capture? Is there any glaring (e.g performance) reason that I should avoid trying to [00:24:42 CEST] <storrgie> figure out how to use ffmpeg to do this? [00:25:34 CEST] <JEEB> ffmpeg doesn't have heavily optimized screen capture inputs [00:26:01 CEST] <storrgie> so there would be a performance impact? We have pretty beefy machines but they are being taxed pretty hard to play this game [00:26:04 CEST] <JEEB> shadowplay just uses nvidia's internal APIs which bypasses the usual capture APIs at all [00:26:24 CEST] <JEEB> it's the internal GPU stuff and straight to the hardware decoder chip [00:26:33 CEST] <JEEB> *encoder chip [00:26:54 CEST] <storrgie> I believe that there was some preliminary testing that concluded that shadowplay resulted in some form of degraded performance (which surprised me), and OBS was considered better... but I figured it would be using the same underlying subsystems as ffmpeg would be using [00:27:59 CEST] <JEEB> OBS has various ways of encoding as well and it has a custom hooking thing [00:28:18 CEST] <JEEB> behind the scenes I'm pretty sure that it uses FFmpeg's libraries to multiplex the output [00:28:25 CEST] <JEEB> and possibly for encode after capture [00:28:39 CEST] <JEEB> but the capture part is the primary thing that can bog you down [00:28:47 CEST] <JEEB> together with the possible RGB to YCbCr conversion [00:29:51 CEST] <storrgie> so, I might be being reductionist forgive me, your gutfeel is that this isn't a good bath to examine [00:33:11 CEST] <storrgie> sorry, isn't a good idea to examine ffmpeg as a solution for capturing audio/video during gaming [00:41:03 CEST] <Mavrik> No, ffmpeg is a horrible idea for gaming capture [00:41:08 CEST] <Mavrik> There's a reason you have dedicated GPU APIs to do that [00:41:09 CEST] <storrgie> ok thanks [00:41:41 CEST] <storrgie> now i'm wondering if there is a programmatic way to drive shadowplay... and despising windows [00:41:42 CEST] <Mavrik> You'll be starving the game itself of bus bandwidth and CPU [00:42:03 CEST] <Mavrik> https://developer.nvidia.com/capture-sdk [00:42:07 CEST] <Mavrik> It's one google away. [00:42:23 CEST] <storrgie> I'd never heard of this [00:42:27 CEST] <Mavrik> Or you can just use nVidias broadcasting software. [00:42:34 CEST] <storrgie> I was hung on shadowplay directly, or GFE [00:44:00 CEST] <storrgie> Mavrik, when you say 'broadcasting software' do you mean shadowplay? [00:44:11 CEST] <Mavrik> No idea whats it called these days [00:44:20 CEST] <storrgie> I think thats what its called now [00:44:27 CEST] <storrgie> however I'll dig into capture-sdk [00:44:28 CEST] <storrgie> thanks [00:44:36 CEST] <Mavrik> I think Steam has its own solution using their APIs [00:44:38 CEST] <Mavrik> And bunch of others [00:44:59 CEST] <Mavrik> Might wanna check it before you spend weeks reinventing the wheel [00:59:14 CEST] <Emerica> I there a way to change the PTS spacing in an encode? I've added B frames to a mpegts, upon doing so my analyzer find the PTS spacing to be over 700ms by about 66-67ms [01:01:40 CEST] <llogan> Dealing with the broadcast anal-yzer cartel, eh? [01:03:06 CEST] <llogan> buy this analyzer so it can tell you it's "wrong" then but our muxer so it will do it right. Only $7000 USD each. [01:09:14 CEST] <DHE> pfft. I've seen real broadcasts well over 1000 ms [02:55:59 CEST] <kevinn> DHE: you online by anychance? I have a follow up to my question from yesterday [02:59:36 CEST] <DHE> sadly not. but it's a big room [03:02:06 CEST] <kevinn> Okay, well I am having a bit of trouble with latency. Per JEEB's suggestion earlier I can confirm that the frame I pass into libav from x264 is a keyframe that should be immediately decodable. However libav doesn't let me immediately decode it. It only lets me decode it after I send another frame with another picture in it. [03:02:28 CEST] <kevinn> So I think now I just have libav misconfigured somehow [03:05:20 CEST] <Tanner_> Hello. Does ffmpeg currently support webrtc as an output? Perhaps using openwebrtc signalling server? [03:05:57 CEST] <Tanner_> If not, is it on the roadmap for future support? [06:05:32 CEST] <lindenk> Hey, has anyone used ffmpeg for screen recording? For some reason, my fps slowly but consistently drops the further into the recording it gets. My CPU doesn't seem to be struggling either (I've even tried giving it more threads). Is there some bottleneck that I'm not thinking about? [06:18:10 CEST] <akkad> low memory? slow disk? [06:34:52 CEST] <teratorn> lindenk: what OS? [06:36:21 CEST] <lindenk> arch linux. I'm pretty sure it's not a slow disk, it's the second fastest m.2 drive out there running on a 4 pci lanes and can normally write stuff faster than /tmp (well almost) [06:36:54 CEST] <teratorn> could be xorg being terrible [06:37:21 CEST] <lindenk> actually, I just tried another recorder and that seemed to work, maybe it's a codec or something? [06:37:48 CEST] <teratorn> what do you mean another recorder? [06:38:06 CEST] <lindenk> I tried simplescreenrecorder from the arch repos [06:38:24 CEST] <lindenk> and it seemed to record at 60 fps without a problem [06:38:26 CEST] <teratorn> ah [06:39:04 CEST] <teratorn> well there you go [06:39:10 CEST] <teratorn> actual software for doing a thing works better [06:39:11 CEST] <lindenk> the weird thing is ffmpeg reported it was doing pretty well with specifically mp4, but the actual video was definately not the right fps [06:39:34 CEST] <lindenk> well, I suppose so. I guess I just wanted a cli tool for it though, and ffmpeg is pretty common on everything [06:40:10 CEST] <teratorn> i've never seen it do x11 screen recording well [06:40:22 CEST] <teratorn> but that doesn't mean it can't [06:40:55 CEST] <lindenk> maybe I should make that wayland switch at some point [06:42:14 CEST] <teratorn> we all should, eventually [08:08:39 CEST] <kepstin> wayland... doesn't really have any api for screen recording at all, though. [08:08:50 CEST] <kepstin> (some compositors have built-in recording support) [08:26:06 CEST] <Johnjay> you can't record the desktop in wayland...? [10:06:45 CEST] <thebombzen> in theory you could use kmsgrab with wayland but it requires an iGPU [10:58:38 CEST] <brendan_> Hey there. Quick question. I'm using the zeranoe build of ffmpeg to transcode using h264_qsv. Do I need to install the Intel Media Server Studio Essentials on every machine that I want to use this on? It's a large download (~900MB). If that is required... is there a lightweight redistributable? [11:03:37 CEST] <sim590> I have those two commands http://paste.debian.net/990145/ which I'd like to join together. In one, I try to record internal audio monitor (which I have set to default in pulseaudio) and in the second, I record my desktop and microphone. [11:04:01 CEST] <sim590> The thing is that I don't achieve to join the two audio recording together in one command. [11:05:16 CEST] <sim590> does it have to do with the fact that I try to use both alsa and pusle? [11:22:13 CEST] <sim590> I have added -map 0 -map 1 -map 2 and I get: [11:22:14 CEST] <sim590> Stream mapping: [11:22:16 CEST] <sim590> Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264)) [11:22:18 CEST] <sim590> Stream #1:0 -> #0:1 (pcm_s16le (native) -> mp3 (libmp3lame)) [11:22:20 CEST] <sim590> Stream #2:0 -> #0:2 (pcm_s16le (native) -> mp3 (libmp3lame)) [11:22:37 CEST] <sim590> But, I don't both sound inputs at the same time. [11:48:54 CEST] <nvz> can I (more quickly than total transcode) just transcode only the audio portion of a video file. I have some files that are AVI(MP4/XVID w/ A52/AC3) and the bluray/media player I'm using only seems to support (from manual) MP3, WMA, PCM, Dolby Digital, DTS for audio on avi containers I'd just like to convert as painlessly as possible the audio to mp3 [11:49:16 CEST] <JEEB> yes [11:49:40 CEST] <JEEB> -c copy (set all other streams to 'copy') -c:a ENCODER <settings> [11:49:47 CEST] <JEEB> *set all streams to copy [11:50:00 CEST] <JEEB> and the second is "override encoder for audio to ENCODER" [11:51:07 CEST] <nvz> so something like ffmpeg -c copy -c:a mp3 video.avi [11:51:42 CEST] <nvz> it'd still need to create a new file I would imagine, cant be done in place? [11:53:35 CEST] <JEEB> can't be done in-place, yes [11:53:55 CEST] <JEEB> so ffmpeg -i input.avi -c copy -c:a libmp3lame -b:a 192k out.avi [11:54:10 CEST] <JEEB> (I think that's how the mp3 encoder is called) [11:54:43 CEST] <nvz> I'm more familiar with mplayer/mencoder but ffmpeg seems to be the thing to use these days figured I'd ask rather than try wing it [11:55:03 CEST] <JEEB> you can check the exact name of encoder a la `ffmpeg -codecs |grep mp3` [11:55:35 CEST] <JEEB> or actually `ffmpeg -encoders |grep mp3` [11:55:39 CEST] <JEEB> that limits it to encoders :) [11:55:45 CEST] <nvz> oh, ok. I'm gonna set some presets in winff I guess to formats specified in this device's manual [11:56:31 CEST] <nvz> so if I encounter any other files in the future that have been encoded in an incompatible format I can more easily fix em [11:56:51 CEST] <JEEB> there's also ffprobe for probing files [11:56:58 CEST] <JEEB> so you can even script things :D [11:57:04 CEST] <nvz> oh really? I was wondering about that [11:57:06 CEST] <JEEB> ffprobe -show_streams -of json file [11:57:13 CEST] <JEEB> outputs the streams in the file as JSON [11:57:43 CEST] <nvz> hmm.. never parsed json in bash, sounds more like a job for python [11:57:49 CEST] <JEEB> yes, definitely [11:57:57 CEST] <JEEB> from json import loads as parse_json [11:58:08 CEST] <JEEB> then take the stdout and pass that to parse_json and you get a dictionary :) [11:58:26 CEST] <JEEB> for stream in streams [11:58:36 CEST] <nvz> I'm vaguely familiar, wrote a little json app to grab xkcd images as a ay to familiarize with it [11:58:39 CEST] <JEEB> *for stream in dictionary.get("streams") [11:58:55 CEST] <JEEB> and that lets you loop over the streams :) [11:59:12 CEST] <JEEB> oh, and you probably want show_format [11:59:17 CEST] <JEEB> which also shows the container [11:59:40 CEST] <nvz> yes definately because the player seems to have different support of codecs for different containers [11:59:53 CEST] <sim590> Ah I get it! Both audio end up in the container, but not mixed in in a single track. That's even better. [12:00:07 CEST] <nvz> according to its manual anyhow, which from experience I know not to take mfg manuals on these kinda things as gospel :P [12:00:50 CEST] <JEEB> yea. thankfully anything modern will take H.264 and AAC in mp4 [12:01:02 CEST] <JEEB> mostly just a case of profile support and level being <=4.1 [12:01:09 CEST] <JEEB> profiles = features [12:01:27 CEST] <JEEB> usually I limit to high profile, level <= 4.1 [12:01:43 CEST] <Mavrik> 4.1 is up to 1080p ? [12:01:59 CEST] <nvz> well in my experience they are really picky these bluray players with the build in media player.. they have odd requirments for bitrates, framerates, etc [12:02:36 CEST] <JEEB> Mavrik: I usually don't think of devices that could do more, if I know they do I just feed shit at them :P [12:02:51 CEST] <JEEB> nvz: blu-ray requires you to support up to 40mbps/40mbps [12:02:57 CEST] <JEEB> *latter to 40 megabits [12:03:01 CEST] <JEEB> which most things just don't hit [12:03:07 CEST] <JEEB> and level 4.1 | high profile [12:03:18 CEST] <Mavrik> Yeah, just clearing it up [12:03:30 CEST] <Mavrik> 4.1 is reasonable yea :) [12:03:30 CEST] <JEEB> of course the non-blu-ray parts can be limited weirdly more than the actual BD playback :P [12:04:16 CEST] <nvz> I didn't test this file on mine, I'm just reorganizing some files for my neighbor who has a Smasung BD J5100 which seems to have mor features than my LG BP145 and his list said to just delete this file he wasnt real concerned about it but my computer plays it find and the only discrepency I see between what vlc tells me and what the manual pdf says is that it doesnt support A52/AC3 with avi [12:04:28 CEST] <nvz> mine however would play such a file if only the audio was the problem [12:04:37 CEST] <nvz> it'd just have no audio playback [12:05:16 CEST] <nvz> I've even seen mine say "may" be incompatible on files then they work fine despite the error on playback [12:05:56 CEST] <JEEB> with AVIs and such it's much more problematic [12:06:07 CEST] <JEEB> since it's usualyl mpeg-4 part 2 and all that jazz [12:06:18 CEST] <JEEB> I generally tend to limit myself to relatively not insane stuff [12:06:39 CEST] <JEEB> MP4 container, H.264 video and AAC audio (although I've already verified AC-3 / DTS both work) [12:10:44 CEST] <nvz> well in this case I didn't encode any of this stuff I'm just sorting files for him, into folders and he marked some files he said didn't play and I just figured if it wont take too long I can ix rather than remove them [12:10:57 CEST] <nvz> *fix [12:11:38 CEST] <nvz> he wanted me to rip all his movies and he has a ton of em.. hundreds undoubtedly.. and I just pirated em instead.. its faster :P [12:11:44 CEST] <Mavrik> Yeah, I also keep to non-insane stuff [12:12:04 CEST] <Mavrik> MP4 with H.264 (although I keep audio in DD/AC3 due to SPDIF limits) [12:12:46 CEST] <nvz> I'd got him into this idea cause I was over there and he was saying he was running out of space to store all his dvds, and I mentioned he could get a hdd and use it on his bluray player, then I thought about how f'n long it'd take to rip all those [12:14:31 CEST] <nvz> the quality would certainly have been more consistant as well as the filesize, but I think it was worth the time tradeoff to wind up with a few odd files [12:18:19 CEST] <furq> nvz: does the tv not support mp4 [12:18:33 CEST] <furq> it'd be quicker to just remux to mp4 if it does [12:23:59 CEST] <nvz> according to the manual it supports AVI (V:Mp4v3,h264; A:mp3,wma,pcm,dts,dolby) MKV(V:VC-1AP,h264; A:mp3) mp4(V:m4v,h264;A:wma) mpg(V:mpg1,2,h264 A:mp1,2) as well as wmv which I have no intention of using [12:25:14 CEST] <nvz> I figured it'd be quicker to just keep everything the same and just change the audio track since its the only thing I notice that seems incompatible [13:26:04 CEST] <fx159159> Hey, does someone here have experience with programatically transcoding from dshow into another format and how "audio_buffer_size" affects the generation of frames/avpackets? [13:27:04 CEST] <fx159159> I encode into opus which by default has a frame duration of 20ms, my code only produces audioframes/packages around every 20ms when audio_buffer_size is set to 20ms, otherwise the audio stutters [13:27:26 CEST] <fx159159> the ffmpeg cli is fine with an audio_buffer_size of 50 and still puts out an audio frame every 20ms [13:29:45 CEST] <fx159159> Also I'm using QtAV as a wrapper between qt/c++ and ffmpeg libs [15:11:02 CEST] <arpu> hi on ffmpeg master what hardware encoder for nvidia and h264 should i use h264_nvenc , nvenc or nvenc_h264 ? [15:46:39 CEST] <BtbN> arpu, the name that's not deprecated. [15:47:02 CEST] <arpu> BtbN, how can i see what is deprecated? [15:47:19 CEST] <BtbN> It throws a big warning if you pick one that's deprecated. [15:53:30 CEST] <fx159159> Does ffmpeg buffer packets internally when reading from dshow? [16:12:06 CEST] <arpu> BtbN, thx [16:28:41 CEST] <fx159159> Say for example I get a AVPacket from av_read_frame with duration of 50000 but my codec outputs 20000 frames, does the codec split automatically? I'm using opus [16:51:02 CEST] <sagax> hi all! [16:51:44 CEST] <sagax> i record video like this - ffmpeg -y -video_size 1280x800 -framerate 30 -f x11grab -i :0.0 -strict -2 -qscale 0 "$name".flv [16:52:09 CEST] <sagax> but how to set position video? like as 1280x800+100+100 ? [16:53:50 CEST] <jkqxz> Append to the display name as "+X,Y". [17:00:20 CEST] <sagax> how to do this? [17:01:05 CEST] <sagax> x11grab -i :0.0+100+100 ? [17:02:44 CEST] <jkqxz> Second '+' should be ','. [17:02:44 CEST] <sagax> x11grab -i :0.0+100,100 [17:02:48 CEST] <jkqxz> Yes. [17:02:53 CEST] <sagax> got it, thanks [17:07:37 CEST] <SpeakerToMeat> Hello peoples [17:08:23 CEST] <SpeakerToMeat> Question, is there any way to concat and mux two sets of files at once? let's say I have 1.mov and 2.mov with a single stream of video each and 1.wav and 2.wav with a single stream of audio each, can I concat 1+2 of each set and mux them into output at once? [17:08:49 CEST] <SpeakerToMeat> I think maybe with graphs but not sure how to use them fully yet [17:08:50 CEST] <Mavrik> Probably yeah [17:13:58 CEST] <Johnjay> yes using filter_complex. but it's... very complex! [17:14:37 CEST] <kepstin> for this case, it shouldn't be that bad, actually. Is the audio in 1.wav synced with the video in 1.mov and same for 2.wav and 2.mov? [17:14:39 CEST] <DHE> https://ffmpeg.org/ffmpeg-filters.html#concat It's not THAT bad. check the examples [17:15:05 CEST] <kepstin> should just be a matter of putting the inputs in the right order and using -filter_complex with a single concat filter if that's the case [17:15:44 CEST] <DHE> for split files, maybe two concat filters like the second example suggests. [17:16:35 CEST] <DHE> actually never mind that since you need to select your streams anyway [17:19:42 CEST] <SpeakerToMeat> kepstin: It is [17:44:19 CEST] <Emerica> @logan /DHE (PTS spacing) No , not dealing with $7000 analyser software (ewww) , I have scripts to check files against ETR-290 [17:46:24 CEST] <DHE> wut? [17:46:56 CEST] <DHE> oh... [17:46:59 CEST] <Emerica> Yesterday: Is there a way to change the PTS spacing in an encode? I've added B frames to a mpegts, upon doing so my analyzer find the PTS spacing to be over 700ms by about 66-67ms [17:47:13 CEST] <Emerica> and you said you've seen them over 1000 I think [17:47:27 CEST] <DHE> yeah. on real broadcasts [17:47:55 CEST] <DHE> I have a monitor that checks our multicast-based feeds (I work for a telecom that does TV) and I've seen that happen [17:48:07 CEST] <Emerica> llogan was mentioning the expensive software, I got sick of that stuff lol [17:48:50 CEST] <Emerica> Yeah, I'm taking another stab at an ffmpeg approach, it's been a few years, last time the ac3 was failing so we went back to muxing with manzanita [17:50:27 CEST] <Emerica> Pretty close to replicating the ts structure now and having it stay compliant, things just get pushed out a little if I attempt to use B frames [17:56:10 CEST] <alexp> Anyone have any word on progress with AMD VCE on Windows? [19:17:26 CEST] <kevinn__> Hi all, I am having a bit of trouble with libav. Specifically av_parser_parse2. I have tried passing it a single IDR frame encoded with x264 but it never returns renderable data (even though the IDR frame should be renderable by itself). It is important to note that it does become renderable when I pass it in another frame, but it should be immediately renderable. [19:17:37 CEST] <kevinn__> Any help would be SO greatly appreciated [19:54:47 CEST] <subli> I've done lots of subtitle extraction but this one I won't understand :( [19:54:53 CEST] <subli> "Stream #0:12 -> #0:0 (dvd_subtitle (dvdsub) -> ass (ssa))" [19:55:06 CEST] <subli> "Only SUBTITLE_ASS type supported." [19:55:34 CEST] <subli> Nvm [19:55:41 CEST] <subli> They're all dvd_subtitles [19:56:03 CEST] <subli> I was just trying to figure out my VLC wouldn't play my .ssa subtitles... [20:21:15 CEST] <Hopper__> Okay, finished my python program to update the data file I will be adding to my ffmpeg stream. Sadly the atomic method of updating my file doesn't appear to actually be atomic. [20:21:48 CEST] <Hopper__> Is there a way I can get FFMPEG to ignore when a text file can not be read? [20:25:10 CEST] <thebombzen> Hopper__: what do you mean? ffmpeg does not check read permissions on a file before reading from it. if it can't read from it, it'll just print an I/O error and exit [20:25:30 CEST] <thebombzen> however, Python can do this, so why can't you just check in Python [20:29:00 CEST] <Hopper__> I am using https://docs.python.org/3/library/os.html#os.replace which says it is an atomic file operation. [20:29:25 CEST] <Hopper__> So I was hoping there might be a simple way to ignore the error in FFMPEG instead. [20:35:34 CEST] <Hopper__> thebombzen: Is that what you are referring to? [20:36:11 CEST] <thebombzen> well if the file is not readable, you can't exactly ignore that and read it anyway [20:38:02 CEST] <kepstin> Hopper__: hmm, you're on windows, right? That function would work properly on linux, ffmpeg would either read the old file or new file :/ [20:40:24 CEST] <kepstin> Atomic file replacement on windows is hard, but you might be able to find some python libraries that can do it with a little googling. [20:40:32 CEST] <Hopper__> Ugh... [20:40:55 CEST] <Hopper__> kepstin: Thanks, I'll poke around for a windows library. [20:43:19 CEST] <kepstin> hmm, although it looks like if you're using python 3.3 or later, the os.replace *should* work on windows [20:45:10 CEST] <kepstin> you have to be using ntfs, and the temp file has to be on the same drive/filesystem as the detination, of course. [20:57:06 CEST] <Hopper__> kepstin: I meet all those requirements and I'm still getting failures. [21:46:53 CEST] <alexpigment> does anyone recall off the top of their head if main 10 x265 encoding is considerably slower than main profile (8-bit) [21:46:54 CEST] <alexpigment> ? [21:47:18 CEST] <alexpigment> this encode is taking a long time and if it's the 10-bit part, i'll kill it and start an 8-bit encode instead [22:10:56 CEST] <kepstin> 10bit is slower in x264, fwiw, i would expect that also to be true for x265 [22:11:17 CEST] <JEEB> x265 is still slow in any case compared to AVC encoding [22:14:01 CEST] <alexpigment> yeah, I just decided to let it keep going [22:14:28 CEST] <alexpigment> Since I was already 33% of the way or so, I didn't want to restart unless it was *significantly* slower compared to 8-bit [22:14:40 CEST] <alexpigment> thanks for the info though [22:15:13 CEST] <alexpigment> and yes, x265 is slow as hell :) i'm only doing this to test GPU-acclerated decoding on various cards [22:15:20 CEST] <alexpigment> otherwise, i'd be sticking with good ol' x264 [22:15:29 CEST] <JEEB> I should do my next encoding test one of these days [22:15:51 CEST] <JEEB> to see if you can findally get some good things from x265 other than in very low bit rate scenarios where you get artifacts [22:16:33 CEST] <alexpigment> I mean I'm sure x265 is great, but it's just not ready for prime time in terms of streaming content delivery, which is the whole point of x265 imho [22:16:59 CEST] <alexpigment> if you're not trying to stream or otherwise keep file sizes really small, you would just use x264 and eat the additional bitrate costs [22:17:50 CEST] <JEEB> well even with network transfer limited stuff the use case where I've so far seen gains from x265 is basicaly "so low that you get major artifacts on both sides" [22:17:55 CEST] <JEEB> where x265 just ends up having less [22:18:02 CEST] <alexpigment> right [22:18:03 CEST] <JEEB> I am not aiming at that level in any case [22:18:13 CEST] <alexpigment> I mean I still think the same applies to any new video codec [22:18:20 CEST] <alexpigment> H.264 was the same thing [22:18:26 CEST] <JEEB> not really [22:18:31 CEST] <JEEB> mpeg-4 part 2 to AVC [22:18:39 CEST] <JEEB> I mean sure, at first there was less psychovisual optimization [22:18:47 CEST] <JEEB> but already circa 2007-8 you had pretty darn good results [22:19:03 CEST] <JEEB> CABAC and stuff just helps a crapload [22:19:06 CEST] <alexpigment> well, the point I'm making really is just that it's being used in really low bandwidth situations to justify a new standard [22:19:14 CEST] <alexpigment> even though higher bitrates of the older standards are just as good [22:19:58 CEST] <JEEB> well no, I don't mismatch standards and encoders like that. I believe that you can actually optimize an encoder to improve on top of the previous gen stuff on higher bit rate scenarios as well. it's all dependent on where the effort is put [22:19:59 CEST] <alexpigment> I can barely watch anything on YouTube because they're under this impression that 2-3mbps 1080p H.264 is "OK" [22:20:28 CEST] <JEEB> with HEVC it's just that a lot of the new tools seem to be really easy to optimize for PSNR :P [22:20:41 CEST] <kevinn__> Does libav determine whether or not to allow a x264 frame to render based on time stamp? I am having trouble getting just one single x264 IDR frame to render... And if libav does take time into account how to I make it stop doing that? [22:20:42 CEST] <JEEB> and x265 doesn't have enough people who care about that stuff to do psychovisual optimizations [22:20:45 CEST] <alexpigment> yeah, I guess I was really just talking about H.265 rather than the encoder itself, but yes, I see your point [22:20:58 CEST] <JEEB> that's the issue with projects that don't have a wider community around them [22:21:04 CEST] <JEEB> like libvpx and x265 [22:21:12 CEST] <JEEB> vpx has GOOG, x265 has mcw [22:21:16 CEST] <JEEB> and that's pretty much it :P [22:21:39 CEST] <JEEB> that said, x265 *is* the least bad HEVC encoder on the market right now. so as a sales tool it's working [22:21:49 CEST] <JEEB> (probably, I have no info on MultiCoreWare's income) [22:23:47 CEST] <alexpigment> whatever encoder Adobe Premiere uses is actually pretty fast and the results are fine at the bitrates I used [22:24:12 CEST] <alexpigment> I would assume they're one of the bigger players in the H.265 creation market [22:24:52 CEST] <JEEB> I wouldn't be surprised if that was either a hw encoder, or libx265 [22:25:00 CEST] <JEEB> although I guess adobe is still with mainconcept? [22:25:10 CEST] <JEEB> mainconcept/divx I tested in 2013 I think? [22:25:17 CEST] <JEEB> it was... bad, then [22:25:28 CEST] <JEEB> and since then it's just :effort: to test it [22:25:39 CEST] <JEEB> alexpigment: also it's not like you can't make x265 faster [22:25:48 CEST] <JEEB> set the preset to something faster and it can go faster [22:26:57 CEST] <alexpigment> JEEB: true, I haven't tested the presets' relative speeds in a while [22:27:14 CEST] <alexpigment> I think I just remember that as the presets get faster, you lose the whole point of using it over x264 [22:27:29 CEST] <JEEB> E_NOT_SURPRISING, but not like you were comparing then either [22:27:39 CEST] <alexpigment> Admittedly, I don't know. I don't personally believe in the H.265 standard and so I don't use it for my own personal use ever [22:27:39 CEST] <JEEB> you just noted that you wanted more speed with HEVC, so that way you could get it [22:27:58 CEST] <JEEB> I like the standard but I don't see it being relevant for my use cases yet [22:28:18 CEST] <JEEB> as in, the used time and the result don't match :P [22:28:33 CEST] <JEEB> at this point I'm waiting for AV1 to get frozen [22:28:47 CEST] <alexpigment> oh, i didn't need more speed earlier. I just wanted to make sure whether I should stop my current encode and change settings, or let it finish out because I was already 33% into it. If someone said it was 2x faster or more to do 8-bit, I would have aborted [22:29:12 CEST] <JEEB> I've only encoded 10bit with x265 anyways, there IMHO isn't a real reason to not use 10bit with it [22:29:19 CEST] <JEEB> since pretty much all hwdecs support 10bit even [22:29:32 CEST] <alexpigment> computers struggle with it though [22:29:43 CEST] <alexpigment> which is why it's a really confusing standard ;) [22:29:55 CEST] <JEEB> because the decoder is slow, yes. although 1080p worked for me I think even on my Core 2 Duo [22:30:14 CEST] <alexpigment> well at least on Windows 7, the files don't really play correctly at all [22:30:30 CEST] <JEEB> --hwdec=dxva2-copy with mpv WorksForME [22:30:41 CEST] <JEEB> and if swdec no params needed [22:30:54 CEST] <JEEB> and mpv pretty much is on top of libavcodec [22:31:13 CEST] <JEEB> also libavcodec has all those test files in the FATE test suite :P [22:31:21 CEST] <JEEB> so if the decoder was borked, it would be noticed [22:31:22 CEST] <alexpigment> maybe the problem is that Windows 7 doesn't correctly push you to hardware for 8-bit and software for 10-bit [22:31:30 CEST] <alexpigment> (if the hardware doesn't support main 10) [22:31:32 CEST] <alexpigment> brb [22:31:42 CEST] <JEEB> Windows 7 doesn't come with hw decoders by default, it's more likely something else in your chain [22:32:12 CEST] <JEEB> I recommend checking a build from https://mpv.srsfckn.biz/ with --hwdec=dxva2-copy [22:32:38 CEST] <JEEB> (and there pretty much are *no* windows/lunix hwdecs that don't support 10bit HEVC if they support HEVC at all) [22:38:43 CEST] <alexpigment> back [22:39:02 CEST] <alexpigment> pretty sure nvidia, intel, and amd all have generations of GPUs that do HEVC 8 but not HEVC 10 [22:39:28 CEST] <JEEB> as far as I know nvidia at least doesn't [22:39:34 CEST] <JEEB> I have both 9 and 10 series stuff [22:39:37 CEST] <JEEB> and 8 series didn't support it [22:39:40 CEST] <alexpigment> Feature Set E versus F [22:39:44 CEST] <alexpigment> https://en.wikipedia.org/wiki/Nvidia_PureVideo [22:40:21 CEST] <JEEB> > partial decoding [22:40:28 CEST] <JEEB> yea, makes sense since itšs not actual hwdec [22:40:48 CEST] <alexpigment> Intel has the same thing on some cards [22:40:56 CEST] <JEEB> yes, I know. not counting those into hwdec [22:40:57 CEST] <alexpigment> Braswell at the very least [22:41:10 CEST] <alexpigment> I think we're probably talking about different things [22:41:19 CEST] <alexpigment> I'm just saying hardware that is programmed to decode the formats [22:41:29 CEST] <JEEB> well, it's pretty dang clear that that is not that [22:41:31 CEST] <alexpigment> at any rate, this is all academic ;) [22:41:41 CEST] <JEEB> it's using the GPU side of things to try and accelerate something [22:41:53 CEST] <JEEB> while most if not all of the actual decoding is done on the cPU [22:41:59 CEST] <JEEB> at least with intel it was pretty much the CPU [22:42:04 CEST] <JEEB> so calling that hwdec is rather... [22:42:18 CEST] <JEEB> not even sure if those are exported through DXVA2 [22:42:23 CEST] <alexpigment> I mean they do keep it locked down to the GPU in a way [22:42:37 CEST] <JEEB> the gpu doesn't have the hardware to decode those formats [22:42:43 CEST] <JEEB> don't try to wiggle around [22:42:43 CEST] <alexpigment> Intel's chips that don't have HD Graphics don't have decoder or encoder capabilities [22:42:45 CEST] <JEEB> it either has or doesn't [22:43:35 CEST] <JEEB> it's as if I was saying my goddamn GTX 9600 from 2008 had VC-1 hwdec. yes, it would work with nvidia's own decoding API, but it was not hwdec in the least [22:43:36 CEST] <alexpigment> also what do you mean by "those formats"? [22:43:43 CEST] <JEEB> HEVC [22:44:10 CEST] <alexpigment> so my Nvidia 1060 doesn't fully decode HEVC on the GPU? [22:44:24 CEST] <JEEB> it does, you were trying to bring up goddamn motherfucking feature level E into the play [22:44:37 CEST] <alexpigment> oh right. I didn't know where you were going with that [22:44:42 CEST] <JEEB> by trying to say that there's PC hwdecs that don't handle 10bit [22:44:59 CEST] <alexpigment> I understand what you're saying now [22:45:11 CEST] <alexpigment> I'll take your word for it on those feature sets [22:45:16 CEST] <JEEB> you don't have to [22:45:22 CEST] <alexpigment> I just did [22:45:25 CEST] <JEEB> just see the fucking wikipedo article you linked [22:45:59 CEST] <JEEB> I think some ARM things might have had hwdecs that couldn't do 10bit [22:46:11 CEST] <JEEB> but already in 2015 a lot of them did, and that number only went up [22:46:30 CEST] <JEEB> because with HEVC and the whole HDR meme 10bit finally hit prime time [22:47:24 CEST] <alexpigment> right [22:47:37 CEST] <JEEB> and thus, I have pretty much noted that it makes no sense to HEVC without 10bit (Ž4@) [22:47:50 CEST] <JEEB> if you use HEVC at all, that is [22:48:15 CEST] <alexpigment> fair enough [22:48:32 CEST] <alexpigment> at the very least, 10-bit support wasn't always there [22:48:47 CEST] <alexpigment> either it came through an update or a latter generation in the case of some (non-nvidia) cards [22:48:49 CEST] <JEEB> I agree with ARM SoCs for that [22:48:53 CEST] <JEEB> but not PCs [22:48:58 CEST] <alexpigment> k [22:49:25 CEST] <JEEB> because PCs never had ACTUAL HWDEC that didn't support 10bit (at least in the major producers that you noted, AMD|nvidia|intel) [22:49:47 CEST] <JEEB> the half-hwdec usually is limited to the vendor-specific APIs too [22:50:03 CEST] <JEEB> well, even less since I bet they couldn't run a lot of stuff on the GPU parts [22:50:26 CEST] <JEEB> (as in, there is no ASIC so they have to use the actual shaders) [22:57:41 CEST] <jkqxz> Um, no. Intel in Braswell and Skylake, and AMD in GCN 3, had 8-bit but not 10-bit H.265 decode. [22:58:17 CEST] <JEEB> jkqxz: are those actual hwdecs, though? [22:58:19 CEST] <JEEB> that was my point [22:58:30 CEST] <jkqxz> Yes. [22:58:48 CEST] <JEEB> so they are actual ASIC-based not software-backed commonly dxva2-usable hwdecs? [22:58:52 CEST] <jkqxz> Yes. [22:58:56 CEST] <JEEB> huh [22:59:10 CEST] <JEEB> although wasn't braswell just mentioned as a CPU-based hybrid? [22:59:12 CEST] <jkqxz> There were shader versions for Haswell and Broadwell, which are... not good. [23:30:31 CEST] <DocHopper> kepstin: After lots of tinkering, it appears that atomic updates are impossible with python in windows. [23:32:17 CEST] <DocHopper> Anyone here have a good idea of how to get a live text stream on a live video? [23:35:51 CEST] <JEEB> your own API client [23:40:35 CEST] <alexpigment> [reading rest of convo from earlier] [23:41:04 CEST] <alexpigment> as I mentioned other desktop vendors did the same thing, although it's unclear if AMD's 10-bit HEVC support came from a second generation or from a later update [23:41:14 CEST] <alexpigment> Intel definitely had a generation of only 8-bit support though [23:41:30 CEST] <alexpigment> again, this is really just academic at this point - not trying to get into arguments about it ;) [23:42:43 CEST] <DocHopper> JEEB: There is really no integration between FFMPEG and any other programs/languages? [23:43:12 CEST] <durandal_1707> yes. C [23:44:19 CEST] <DocHopper> Is there a good source of documentation on this? [23:44:28 CEST] <JEEB> yes, doc/examples for example [23:44:31 CEST] <JEEB> and then there's the doxygen [23:44:48 CEST] <JEEB> like https://ffmpeg.org/doxygen/trunk/group__lavf__decoding.html [00:00:00 CEST] --- Thu Oct 12 2017

1 0