[00:17:10 CEST] <llogan> durandal_1707: i mentioned that trip as soon as i found out about it. [00:44:17 CEST] <cone-813> ffmpeg 03Gregor Riepl 07master:d970f7ba3124: ffserver: fixed deallocation bug in build_feed_streams [03:19:34 CEST] <AndrewMock> Are there plans to support DTS' embedded downmix coefficients? (Not just the generic ac3 spec ones) [03:36:40 CEST] <jamrial_> AndrewMock: afaik that's currently supported [03:38:33 CEST] <AndrewMock> oh dang [03:38:41 CEST] <AndrewMock> -ac 2 does that or? [03:59:06 CEST] <jamrial_> AndrewMock: no, -request_channel_layout as input file option [03:59:25 CEST] <AndrewMock> nice THANK YOU [04:00:41 CEST] <jamrial_> any 6.1 or 7.1 stream will have a 5.1 downmix, but they rarely have stereo downmix [04:01:10 CEST] <jamrial_> if there's no stereo downmix, it will instead output the 5.1 one [08:45:25 CEST] <phucnguyenv> hello [11:04:50 CEST] <BtbN> andrey_turkin, are you sure that CUDA abstraction is worth it? Enabling cuda makes ffmpeg non-free and non-redistributable anyway, so you build it on the system with CUDA and very likely the nvidia driver installed. [11:10:42 CEST] <andrey_turkin> It has a use in my situation (where we have some machines with GPUs and some without GPUs and we'd really like to keep the same build for both). I guess there are others with same needs [11:11:25 CEST] <andrey_turkin> Regarding non-free and non-redistributible - I am not sure why it is has to stay that way [11:11:43 CEST] <andrey_turkin> given as nvenc is no longer considered non-free [11:12:06 CEST] <nevcairiel> nvenc headers are licensed as MIT now [11:12:12 CEST] <nevcairiel> cuda headers are still proprietary [11:12:37 CEST] <andrey_turkin> right, but nvenc found a way around that, right (just "reimplement" required bits in ffmpeg) [11:13:17 CEST] <andrey_turkin> whole ffmpeg API use just needs 2-3 more definitions to be compilable without CUDA headers [11:30:53 CEST] <BtbN> if you can get rid of the cuda.h dependency entirely, then the non-free could be dropped, yes. [11:31:20 CEST] <BtbN> Oh, what I also noticed: I don't think you need to check for LoadLibrary/dlopen in the enabled cuda part in configure. [11:31:25 CEST] <nevcairiel> that sounds like it might turn out rather ugly though, as contrary to nvenc, the cuda stuff is used in various files [11:31:57 CEST] <andrey_turkin> well the definitions go into cuda_api.h and everything else uses it [11:32:22 CEST] <nevcairiel> i would probably find that not really good to have in ffmpeg [11:32:36 CEST] <BtbN> just add $ldl to extralibs, like nvenc does. [11:32:52 CEST] <nevcairiel> we shouldnt litter our code with re-implementations of proprietary headers [11:33:20 CEST] <nevcairiel> if some definitions are hidden in a single C file that uses them fine, but an extra header seems rather ugly [11:34:37 CEST] <nevcairiel> as such, i really dont like having something like cuda_api.c/h, which in turn is even public API, since its in avutil and used from avfilter and avcodec [11:35:17 CEST] <andrey_turkin> not public but cross-library [11:35:30 CEST] <nevcairiel> anything thats cross-library is practically public [11:37:17 CEST] <nevcairiel> even if its avpriv, its part of the ABI, and as such prone to the same ABI/API change limitations as any public API [11:37:25 CEST] <andrey_turkin> Either we have to make ffmpeg builds with cuda support non-free, non-redistributable and require 1+Gb download in order to build that support in; or we need to add something similar to cuda_api.h; or we need to place same code all over the place [11:37:27 CEST] <nevcairiel> so one would have to have a really convincing argument to add that [11:38:39 CEST] <andrey_turkin> I'd be happy to hear any ideas how to achieve same result more cleanly [11:38:45 CEST] <andrey_turkin> I don't have any [11:38:50 CEST] <nevcairiel> maybe we just shouldn't [11:39:03 CEST] <nevcairiel> there are plenty of external libraries that impose some sort of limitations [11:39:09 CEST] <nevcairiel> we can't re-implement the headers for all of them [11:42:01 CEST] <BtbN> I'm against the patch as long as it doesn't drop any external dependencies on cuda.h, as it's entirely pointless otherwise. [11:42:06 CEST] <andrey_turkin> I can't really argue cuda is a big deal until ffmpeg can do something useful with it without libnpp. [11:42:40 CEST] <BtbN> And even then I think it's questionable if re-implementing larger parts of cuda.h in ffmpeg is desirable. [11:43:02 CEST] <andrey_turkin> I was going to send another patch to do just that when I got some feedback on first one [11:44:01 CEST] <BtbN> keeping CUDA non-free seems like the right thing in the first place. I'm not even sure if the CUDA runtime even still counts as a system library for the GPL. [11:44:27 CEST] <andrey_turkin> basically only missing type (beyond those defined in nvenc.c) is CUDA_MEMCPY2D [11:45:01 CEST] <andrey_turkin> any plans to bring CUDA runtime into play? For now it is just driver API [11:45:18 CEST] <nevcairiel> well for now, but you say yourself cuda is not very helpful in ffmpeg, and once someone starts implementing extra features, you'll start to re-implement a lot more of CUDA API [11:47:05 CEST] <nevcairiel> and for license purposes, you are not allowed to look at cuda.h and copy its contents [11:47:49 CEST] <andrey_turkin> you are allowed to look in the documentation and reimplement it [11:48:09 CEST] <andrey_turkin> mingw, reactos and wine guys all manage [11:48:46 CEST] <BtbN> Doesn't that depend on the license the documentation is released under? [11:49:33 CEST] <nevcairiel> those are dedicated projects to doing such things - if you want to re-implement a OSS header in a separate project feel free, i'm just saying its not something I feel suitable for ffmpeg [11:50:59 CEST] <andrey_turkin> ok then; if this looks like a bad idea to you guys so be it [11:53:57 CEST] <BtbN> andrey_turkin, regarding your local situation, the CUDA SDK contains a shim library that has all the CUDA exports, just copy that around internaly alongside ffmpeg. [11:55:00 CEST] <BtbN> For me those are in /opt/cuda/lib64/stubs [11:55:35 CEST] <andrey_turkin> I'll just keep the patch in place for my needs ) [11:55:50 CEST] <andrey_turkin> I wonder how come NVidia relicensed nvEncodeAPI.h ? [11:56:04 CEST] <nevcairiel> because j-b asked [11:56:28 CEST] <andrey_turkin> if they can do the same for dynlink_cuda_cuda.h it would be wonderful [11:56:28 CEST] <nevcairiel> maybe they'll do the same with cuda at a later point [11:58:11 CEST] <BtbN> I don't have that file in my CUDA SDK? [11:58:16 CEST] <andrey_turkin> it would be even better if they made better interoperability between opencl and nvenc/nvcuvid [11:58:24 CEST] <andrey_turkin> it's in nvenc SDK [11:58:27 CEST] <BtbN> that's not going to happen. [11:58:35 CEST] <j-b> andrey_turkin: because I can be an annoying person. [11:58:41 CEST] <nevcairiel> nvcuvid is unsupported at this point anyway [11:58:52 CEST] <nevcairiel> they didnt even bother to update it for 10-bit decoding [11:59:13 CEST] <BtbN> Kind of a shame, as there is no other comparable decode api [11:59:50 CEST] <BtbN> But Nvidia is never going to care more for OpenCL than barely acknowledging that it exists. [12:00:10 CEST] <andrey_turkin> looks that way [12:01:42 CEST] <BtbN> Until very recently the OpenCL stuff in ffmpeg didn't work on nvidia, because they didn't support OpenCL 1.1 [12:02:22 CEST] <andrey_turkin> you mean 1.2? I think 1.1 was supported for a while not [12:02:23 CEST] <nevcairiel> nvidia didnt support 1.2 for a long time, but 1.1 should've been fine [12:02:39 CEST] <BtbN> Oh, yeah, whatever ffmpeg needs. Might have been 1.2. [12:02:59 CEST] <BtbN> I hope that with EGL/Wayland and stuff there will be some way to initialize vdpau without X. [12:03:06 CEST] <BtbN> preferable on a headless machine [12:03:34 CEST] <BtbN> Or a refresh of CUVID [13:33:53 CEST] <andrey_turkin> wow that's a big patchset [13:49:36 CEST] <omerjerk> Hi everyone. [13:49:45 CEST] <omerjerk> I have a question regarding the SoftFloat api [13:50:09 CEST] <omerjerk> I want to use this av_cmp_sf function - https://www.ffmpeg.org/doxygen/2.2/softfloat_8h_source.html#l00095 [13:50:43 CEST] <omerjerk> I want to compare whether my SoftFloat is eqal ro 0.f or not [13:50:54 CEST] <omerjerk> Is it even possible with this ? [13:51:12 CEST] <omerjerk> Else I'll have to think of some other logic in my code. [13:58:07 CEST] <omerjerk> Also, what's the proper way to get the sign bit in SoftFloat ? [14:32:09 CEST] <cone-681> ffmpeg 03Anton Khirnov 07master:44d16df41387: h264_parser: eliminate H264SliceContext usage [14:32:10 CEST] <cone-681> ffmpeg 03Hendrik Leppkes 07master:2dc954e0bd54: Merge commit '44d16df413878588659dd8901bba016b5a869fd1' [16:32:48 CEST] <cone-681> ffmpeg 03Michael Niedermayer 07master:281caece46c4: avfilter/avfiltergraph: Clear graph pointers in ff_filter_graph_remove_filter() [16:44:15 CEST] <vade> hello. Is the newer codecpar API, using send / recieve + frame / packet API stable for use? Ive successfully ported / implemented a decoder - but my encoder is failing. I am using what was the latest GIT commit on github - since im wanting HWAccell encode for OS X via the h264_videotoolbox encoder. [16:45:47 CEST] <rkern> Does it give you an error message? [16:46:56 CEST] <vade> hi rkern - no, I suspect the issue is on my end. Inspecing packets I recieve from the encoder - they appear to have data (ie - non null values) and the only errors I get are stating that the encoder needs more frames - which obviously stops once it has enough data to begin to vend output packets to me [16:46:56 CEST] <ubitux> michaelni: "no i dont know if someone uses it with 1000 filters" i remember someone doing thousands of drawbox instance of something (one per frame) [16:48:01 CEST] <vade> rkern: Ive read some migration documentation, and per suggestion I create my own AVCodecContext which I configure via setting values on my created output video streams codecpar, and then initialize the codec context via avcodec_parameters_to_context [16:48:29 CEST] <vade> I used the old pattern that was warned against, which was using the streams -> codec directly. But that did result in output frames. [16:48:37 CEST] <michaelni> ubitux, interresting [16:48:56 CEST] <vade> (to be clear, that working encoder output was via the old API) [16:49:49 CEST] <vade> I imagine I am somehow not linking either my CodecContext, or my stream to my output format - but I cant seem to deduce where or why. Is there anything else one needs other than manually making a codec context and ensuring it matches your created streams codecparam settings? [16:49:50 CEST] <ubitux> michaelni: well, it was pure madness but there is a ticket somewhere [16:50:16 CEST] <ubitux> michaelni: http://trac.ffmpeg.org/ticket/5222 [16:52:44 CEST] <rkern> vade: when I setup the AVCodecContext first, and copy it to the AVStream.codecpar with avcodec_parameters_from_context() it works. [16:54:25 CEST] <vade> rkern: are there any samples using the new API ? [16:55:42 CEST] <durandal_1707> ubitux: somethng michaelni changed? [16:56:52 CEST] <ubitux> durandal_1707: i was replying to one of his remark mentioning that probably no one is doing a filtergraph with 1k filters [16:57:16 CEST] <ubitux> in one of the recent patchset on the ml [16:57:19 CEST] <durandal_1707> He is wrong [16:57:43 CEST] <vade> Oh rkern - interesting. So you init your codec context, and then you set up the codec context, and then you migrate your codec contexts settings to your output streams codec params? To be clear? [17:00:23 CEST] <rkern> vade: right, set the parameters such as width and height, open the codec, then copy it to codecpar. [17:00:38 CEST] <rkern> for encoders anyway [17:02:32 CEST] <vade> thanks rkern - ill let you know shortly. very much appreciate that input. [17:14:33 CEST] <vade> rkern: interesting - libx264 works, but it seems like the video toolbox encoder doesnt [17:14:42 CEST] <vade> h264_videotoolbox [17:15:29 CEST] <vade> your note appears to have been the key though, thank you! [17:15:57 CEST] <rkern> ok, so you were setting the values in codecpar first? [17:16:15 CEST] <vade> exactly. [17:16:30 CEST] <rkern> I'll try it out [17:16:34 CEST] <vade> I was setting up my stream, and then configuring my AVCodecContext by calling the context from params call [17:16:48 CEST] <vade> thank you again for your input - I really appreciate it :) [17:17:18 CEST] <vade> also as per the h264_videotoolbox encoder, ive yet to try any private codec options, so I might need to do additional configuration on it [17:18:47 CEST] <vade> also apologies if I drop out - internet here is shoddy. [17:22:01 CEST] <vade> rkern: ah, I noticed a subtlety [17:22:22 CEST] <vade> I need to have also have called avcodec_open2 prior to avcodec_parameters_from_context [17:22:35 CEST] <vade> otherwise my stream is unhappy [17:44:14 CEST] <rkern> vade: copying from the context to codecpar is best. The encoder may set certain values when it's opened (such as has_b_frames). [17:45:43 CEST] <vade> ah yea. Makes sense [17:46:31 CEST] <vade> ive configured my contexts and open them prior to calling avcodec_parameters_from_context and all seems well. I still cant get the h264_videotoolbox to output however [18:00:17 CEST] <rkern> vade: are you using OS X or iOS? [18:00:27 CEST] <vade> rkern: OS X [18:01:58 CEST] <cone-681> ffmpeg 03Håvard Espeland 07master:9c43703620a8: avcodec/proresdec2: Add support for grayscale videos [18:04:00 CEST] <vade> rkern: I think I see the issue [18:05:19 CEST] <vade> the pixel format returned by the AVCodec* that x264 returns is AV_PIX_FMT_YUV420P, whereas when I request a videotoolbox I get AV_PIX_FMT_VIDEOTOOLBOX as the only entry. Is that something to be concerned about? [18:06:48 CEST] <rkern> You can use AV_PIX_FMT_VIDEOTOOLBOX, AV_PIX_FMT_NV12, or AV_PIX_FMT_YUV420P [18:06:56 CEST] <vade> oh. I lied. Sorry. Yea. I just saw that [18:07:03 CEST] <vade> sorry im playing catch-up. Apologies. [18:10:20 CEST] <vade> do you have h264_videotoolbox running on OS X rkern ? [18:11:16 CEST] <rkern> I haven't tried it with the new avcodec_send_frame()/avcodec_receive_packet() API [18:12:23 CEST] <vade> how would I go about submitting a bug report on this? I feel like if x264 is working in my current code, but h264_videotoolbox isnt, it might be somethign in h264_videotoolbox ? is that fair ? [18:12:44 CEST] <vade> *something [18:15:22 CEST] <rkern> vade: you can submit a bug at trac.ffmpeg.org. Please include a minimal code sample if possible. [18:16:45 CEST] <nevcairiel> sounds to me like you are better suited asking in a user help context first, it sounds to me like you are not quite sure if you are using everything correctly either way [18:16:53 CEST] <vade> Thanks for all the help rkern - onel ast q - via the old API to have h264_videotoolbox working, did you have to submit any particular flags to the encoder or private options? [18:17:00 CEST] <vade> nevcairiel: this is indeed true :) [18:17:01 CEST] <nevcairiel> please note that this channel is for development of ffmpeg, and not for help using it [18:17:41 CEST] <vade> Ah, apologies. I rarely got in-depth API help on #ffmpeg, I was unclear if this was dev *using* the API, or dev for FFMPEG and is APIs only. [18:20:19 CEST] <nevcairiel> for the new decode API, most people have probably not switched to using it yet [18:20:43 CEST] <vade> yea ive not seen any real examples. How new is it ? Im fairly new to FFMPEG dev over-all [18:20:51 CEST] <nevcairiel> but I don't think it should cause anything to bug out that worked with the old one [18:20:59 CEST] <nevcairiel> couple months [18:21:38 CEST] <nevcairiel> one of these days I should switch to using it myself ;) [18:21:40 CEST] <vade> Oh, im 99% sure its on my end, ha :) [18:22:34 CEST] <vade> Id be up for possible submitting some examples of using it - its actually fairly clean once you deduce how to set it up. the new API makes a lot of sense decoupling sending packets / recieving frames. [18:23:06 CEST] <nevcairiel> indeed, its pretty simple [18:25:48 CEST] <vade> ok, one last q - do I need any flag other than setting up a codec via avcodec_find_encoder_by_name("h264_videotoolbox") to enable HWAccell with the new API? [18:28:35 CEST] <rkern> No, hw is the only option unless you set a flag to allow a software encode (it will still use hw if available). I've jumped in #ffmpeg if you have any other questions. I'm looking at OS X with the new API now, but iOS works fine with it. [18:28:58 CEST] <vade> thanks so much. Apologies for being off topic. I very much appreciate all of your input. [18:31:39 CEST] <Compn> wonder how long steam has been distributing libavcodec/libavformat/libswscale ;P [18:31:56 CEST] <Compn> really are on every computer ever :P [18:37:59 CEST] <RiCON> at least since in-home streaming [19:48:37 CEST] <esdwdftty> I don't know, you (developers) know about it or not. I came across this, I show this information. I have a AMD and a maximum avx1. https://software.intel.com/en-us/articles/avoiding-avx-sse-transition-penalt... [20:02:35 CEST] <nevcairiel> esdwdftty: we avoid these problems by explicitly zeroing the upper part of the registers when transitioning [20:03:00 CEST] <nevcairiel> (ie. method 3 they mention) [20:05:13 CEST] <esdwdftty> ok [20:26:42 CEST] <rcombs> nevcairiel: is that ar issue fixed in the libc or in binutils? [20:26:56 CEST] <nevcairiel> in mingws mkstemp [20:26:59 CEST] <nevcairiel> so i gues slibc [20:27:29 CEST] <rcombs> apparently they downgraded binutils to 2.25 a couple months back [20:27:46 CEST] <rcombs> and I needed 2.26 for my application [20:28:11 CEST] <rcombs> so I guess we'll have to build binutils 2.26 against the new libc [20:30:30 CEST] <nevcairiel> what does 2.26 offer? [20:33:17 CEST] <BBB> nevcairiel: I thought it was a combination of 1/2 and 3 [20:33:23 CEST] <BBB> nevcairiel: between functions, its 3 [20:33:34 CEST] <BBB> nevcairiel: within functions, if avx, everything is vex, else everything is non-vex [20:33:39 CEST] <BBB> which is 1/2 [20:33:39 CEST] <nevcairiel> is suppose we use vex encoding when appropriate, yes [20:36:00 CEST] <BBB> kierank: is that a protest-IWNA? [20:36:06 CEST] <kierank> no [20:36:33 CEST] <kierank> it is an IRL stuff iwna [20:36:51 CEST] <BBB> alrighty [21:01:08 CEST] <somebody_useless> Hi Guys, how do you record sample input video? I need to record some sample input clips and supply them to my open TRAC ticket, however I can't get the two recommended methods do not work. [21:01:09 CEST] <somebody_useless> mplayer --dumpstream produces garbage video that's barely visible but is missing most of the picture data [using mpegts input stream video]. [21:01:09 CEST] <somebody_useless> AVIOCAT wont compile due to physically missing C library files (in libaviutil folder). [21:01:09 CEST] <somebody_useless> Thanks! [21:10:16 CEST] <Compn> whats the input somebody_useless ? [21:10:21 CEST] <Compn> i mean , http? dvb ? [21:10:41 CEST] <Compn> hardware /dev/stream ? [22:06:08 CEST] <somebody_useless> compn, sorry! Thanks for responding. It's mpegts [22:09:30 CEST] <somebody_useless> compn, we're receiving the mpegts stream via multicast from our receivers and transcoding the mpeg2ts to mpeg4ts for WAN transport (to our customers). I need a way to record the multicast mpegts video footage; however I have not yet been able to do so. I can record the raw packet data using python but this is likely not acceptable (as was my ffmpeg and cvlc recordings) [22:09:58 CEST] <somebody_useless> I recognize that this is not the general support chat, but I really want to help your team find the problem :) [22:10:59 CEST] <somebody_useless> [I'm interested in the entire input stream and not just the video.] [22:17:16 CEST] <kierank> multicat [22:50:54 CEST] <somebody_useless> kierank! THANKS!!!!!!! [00:00:00 CEST] --- Sat May 28 2016