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

[burek]

[00:10:05 CET] <BBB> atomnuker: I dont see the problem with using mutexes, I mean, were talking about codec registration, which happens a 100 times in the application lifetime; did you know we decode 100s of coefficients per block, of which we have 100s per frame, of which we have 100s per stream in a sequence, of which we have many in a media file, of which many may be processed during the lifetime of an application? atomic codec registrati
[00:10:05 CET] <BBB> reasonable person would quality as premature optimization - but hey, who am I, I know nothing about codecs or speed, right?
[00:14:12 CET] <nevcairiel> in reality those registers functions are never going to be an issue anyway
[00:14:24 CET] <nevcairiel> an external api user can't realistically call them with any valid values
[00:14:35 CET] <nevcairiel> and avcodec_register_all etc use pthread_once
[00:19:46 CET] <nevcairiel> basically, if we just were to make them private, noone would miss them, and all would be solved
[00:23:10 CET] <nevcairiel> using a static mutex even with pthread_once to init is still has the bad aftertaste of "leaking" the mutex, since it can never be freed
[00:23:31 CET] <JEEB> yup
[00:28:13 CET] <iive> can't we use pthread_once for avfilter_register_all too?
[00:28:56 CET] <nevcairiel> it uses that
[00:29:40 CET] <nevcairiel> but theoretically avfilter_register is public api and could be called from any thread at any time ... even if noone is ever going to do so, but shrug
[00:46:01 CET] <cone-761> ffmpeg 03Tristan Matthews 07master:f6161fccf8c5: rtsp: only break on parse_rtsp_message on error
[00:46:02 CET] <cone-761> ffmpeg 03James Almer 07master:dae6d27aa0b0: Merge commit 'f6161fccf8c5720ceac1ed1df8ba60ff8fed69f5'
[00:51:10 CET] <cone-761> ffmpeg 03Mark Thompson 07master:7bf3f380466e: cbs: Add padding to slice data allocations
[00:51:11 CET] <cone-761> ffmpeg 03Mark Thompson 07master:5a6707e49b77: cbs_mpeg2: Fix marker_bit type
[00:51:12 CET] <cone-761> ffmpeg 03James Almer 07master:f750a0bcfea9: Merge commit '5a6707e49b7710f48d658b2f2591b9a6337fb9b7'
[00:58:55 CET] <cone-761> ffmpeg 03Jun Zhao 07master:e7adf2250b43: vaapi_h265: Enable VBR mode
[00:58:56 CET] <cone-761> ffmpeg 03Jun Zhao 07master:4b57f064477c: vaapi_h264: Fix VUI max_dec_frame_buffering
[00:58:57 CET] <cone-761> ffmpeg 03Mark Thompson 07master:e171022c24c4: vaapi: Make the decode profile matching more explicit
[00:58:58 CET] <cone-761> ffmpeg 03Mark Thompson 07master:6679654efe15: vaapi_h264: Add named options for setting profile and level
[00:58:59 CET] <cone-761> ffmpeg 03Mark Thompson 07master:3ff8fbbf5a7b: vaapi_h265: Add named options for setting profile and level
[00:59:00 CET] <cone-761> ffmpeg 03James Almer 07master:7a10541109cc: Merge commit '3ff8fbbf5a7bc40c09db74d4952364997fd3c611'
[01:01:10 CET] <SortaCore> why does av_dict_parse_string have in docs you *may* need to free the returned dict?
[01:04:16 CET] <cone-761> ffmpeg 03Alexandra Hájková 07master:7993ec19af39: hevc: Add hevc_get_pixel_4/8/12/16/24/32/48/64
[01:04:17 CET] <cone-761> ffmpeg 03James Almer 07master:dd1ecf093c0f: Merge commit '7993ec19af394fdc58ec64165bc0b12619543a5d'
[01:04:18 CET] <cone-761> ffmpeg 03James Almer 07master:bad51e928718: doc/libav-merge: add a line about the skipped HEVC MC arm functions
[01:23:18 CET] <BBB> nevcairiel: I think thats a good idea
[01:23:27 CET] <BBB> nevcairiel: but Im sure someone uses it now that it was public one day
[01:24:04 CET] <cone-761> ffmpeg 03Kieran Kunhya 07master:a83a03af9a84: libavcodec: Move ff_print_debug_info2 to mpegutils.c
[01:24:05 CET] <cone-761> ffmpeg 03Kieran Kunhya 07master:918de766f545: h264dec: Remove mpeg4video.h header dependency
[01:24:49 CET] <JEEB> BBB: sure, but I don't think it worked properly without hacks?
[01:24:57 CET] <JEEB> since you couldn't make your own codecs
[01:25:03 CET] <JEEB> (without private symbols)
[01:29:45 CET] <BBB> JEEB: I dont know, I think if it only uses external libs, it may be possible
[01:29:54 CET] <BBB> JEEB: e.g. something like libvpx can possibly be done outside
[01:29:59 CET] <BBB> I Dont know though, never tried
[01:30:20 CET] <SortaCore> on another separate note, last year libx264 still used codec instead of codecpar, is that still a problem?
[01:32:43 CET] <JEEB> BBB: and here I thought there were definitions that were private ff_ prefixed that were required for an "external" AVCodec etc being registered
[01:39:08 CET] <BBB> JEEB: I guess I dont know either :( ohwell
[01:39:14 CET] <BBB> but atomics, right?
[01:39:16 CET] <BBB> because why not
[02:23:25 CET] <atomnuker> durandal_1707: today, today? my alarm clock, I'm flying
[03:09:14 CET] <rcombs> so, I need to expose FF_CODEC_PROPERTY_CLOSED_CAPTIONS on AVStream, presumably via codecpar
[03:10:29 CET] <rcombs> should I just add a "properties" field to codecpar and copy that field out? (the only other property is "lossless", which also isn't implementation-specific)
[03:16:23 CET] <jamrial> that was suggested before but rejected
[03:16:32 CET] <jamrial> adding a properties field, i mean
[03:37:02 CET] <rcombs> why?
[03:39:08 CET] <jamrial> the properties it defines are supposedly not stream parameters or something like that
[03:39:40 CET] <jamrial> it was a long time ago, back when we were trying to get ffmpeg.c to work with codecpar
[03:39:41 CET] <rcombs> it defines 2 things: "is lossless", and "contains closed captions"
[03:40:03 CET] <rcombs> I guess you could argue those are really _packet_ parameters?
[03:41:03 CET] <rcombs> but they're definitely not _implementation_ parameters, which would make sense to keep solely on AVCodecContext
[04:25:49 CET] <cone-670> ffmpeg 03Steven Liu 07master:08d28ee1823a: avformat/hlsenc: move init operations from write_header to init
[04:42:54 CET] <cone-670> ffmpeg 03James Almer 07master:c7a5e80f569d: avcodec/libvpx: remove disabled code
[05:15:19 CET] <daksh> I am new here. I want to start contributing to ffmpeg, where do I start?
[05:15:38 CET] <Compn> daksh : do you have c programming skills? :)
[05:15:49 CET] <daksh> Yes, I do :D
[05:15:53 CET] <Compn> nice
[05:16:02 CET] <daksh> And I know git too 
[05:16:27 CET] <Compn> you can start with bugs at http://trac.ffmpeg.org , or subscribe to the ffmpeg-devel mailing list and ask for projects to work on ?
[05:16:31 CET] <Compn> or maybe review some patches there 
[05:16:54 CET] <Compn> just testing if patches build helps
[05:17:23 CET] <daksh> I will try and do some of the things that you mentioned
[05:17:53 CET] <daksh> I was looking forward to GSoC'18. So I wanted to explore this organisation and contribute first :)
[05:18:09 CET] <Compn> ah, that is a great way to start gsoc :)
[05:19:20 CET] <daksh> What about you? You are a regular developer here?
[05:19:58 CET] <Compn> somewhat , i do irc and mailing list stuff
[05:20:05 CET] <Compn> sometimes bug tracker and reviewing patches
[05:20:20 CET] <daksh> Oooh nice! 
[05:20:46 CET] <daksh> There is no Issues tab in https://github.com/FFmpeg/FFmpeg ? :\
[05:21:26 CET] <Compn> we were around before github, so we use videolans servers 
[05:22:02 CET] <daksh> Oooh, wow
[05:22:20 CET] <daksh> Do you have any tags for simple bugs? Just so that I can get started?
[05:22:49 CET] <Compn> haha no, thats the problem i think, there is no one who organizes bugs based on complexity
[05:23:23 CET] <Compn> i know this makes it more difficult for new developers to join in. i am trying to think of solutions for this
[05:24:09 CET] <daksh> Oooh, I see
[05:24:37 CET] <daksh> Why don't you guys also have Issues on GitHub now? I guess that would make it much easier for new users to find it (Sorry if this suggestion is stupid)
[05:24:51 CET] <daksh> Could you refer some bug to me? That I can test
[05:24:59 CET] <Compn> its not sstupid,  we get quite a few people who want github stuff
[05:25:02 CET] <Compn> sure let me see
[05:26:15 CET] Action: Compn digging
[05:29:23 CET] <Compn> daksh : http://trac.ffmpeg.org/ticket/6863
[05:29:46 CET] <Compn> daksh : if you want to try connecting an external lib into our makefile and codecs so we can decode / encode with it ?
[05:30:03 CET] <Compn> difficulty could be high or low depending on how weird the sdk api is
[05:31:23 CET] <daksh> Compn: I have almost no clue about codecs and this. Also, I am not very comfortable with makefiles. Is there an easier task? Or rather first something that I just have to check?
[05:31:36 CET] <Compn> sure
[05:31:40 CET] <Compn> give me a min
[05:32:20 CET] <daksh> Sure
[05:35:05 CET] <Compn> ah i was looking at open bugs, need to look at ne wbugs only
[05:36:22 CET] <Compn> daksh : http://trac.ffmpeg.org/ticket/6890
[05:36:32 CET] <Compn> you could hunt down the string and find out how to replace it
[05:38:17 CET] <daksh> "Applying option ab (audio bitrate (please use -b:a)) with argument 160k." is the string to be replaced to?
[05:39:28 CET] <Compn> "Applying option b:a (video bitrate (please use -b:v)) with argument 160k."
[05:39:36 CET] <Compn> should be replaced to
[05:39:44 CET] <Compn> "Applying option b:a (audio bitrate (please use -b:a)) with argument 160k."
[05:40:39 CET] <daksh> Sure, I will try and find that :)
[05:40:40 CET] <daksh> THank you
[05:40:41 CET] <Compn> looks like a copy paste typo
[05:40:53 CET] <Compn> you could also verify the bug is there with latest git master 
[05:41:01 CET] <Compn> no problem :)
[05:41:25 CET] <daksh> Though I do not understand what the error message means (and I do not need to understand it, to fix it )
[05:41:57 CET] <daksh> But how do I learn things like these?
[05:44:23 CET] <Compn>  i guess you can start by reading the docs , http://ffmpeg.org/ffmpeg-all.html
[05:44:30 CET] <Compn> careful its a long document
[05:44:40 CET] <Compn> shorter portions here http://ffmpeg.org/documentation.html
[05:44:47 CET] <daksh> Huge :P
[05:44:57 CET] <daksh> having a look at it
[05:45:04 CET] <daksh> and a couple of more questions if you dont mind
[05:45:10 CET] <Compn> sure
[05:46:14 CET] <daksh> 1. I have ffmpeg already installed (I am using a MacOs). If I type 'ffmpeg' on the terminal then it shows the options. So yes it is there. Now how to I develop along with that. Is there a virtual environment kind of thing that I have to make or do I uninstall this and install the development version? How? 
[05:46:56 CET] <Compn> oh you need a build environment i think
[05:47:01 CET] <daksh> 2. The process of submitting patches doesn't seem straight forward as I have seen in other places, where they use github PRs. I saw that you guys don't do that. Do I have to mail it? o.O
[05:47:16 CET] <Compn> git has a feature called git send email
[05:47:24 CET] <daksh> Umm, what is a build environment? Do you have a webpage regarding this?
[05:47:40 CET] <Compn> so you set it up with git, type git send email and it mails the patch to the mailing list :)
[05:47:52 CET] <Compn> let me see... i dont think we have a guide ourselfs
[05:48:26 CET] <daksh> But then how is the review process and all? Maybe you guys want me to change somethings in the patch. So how is the communication done then?
[05:48:33 CET] <Compn> oh we do, https://trac.ffmpeg.org/wiki/CompilationGuide/macOS
[05:48:35 CET] <Compn> read that ! :)
[05:48:52 CET] <Compn> the communication is done on the mailing list
[05:48:59 CET] <Compn> (emails)
[05:49:31 CET] <daksh> Thanks thanks :D
[05:51:44 CET] <Compn> i know it can be difficult to learn a new system , but it will be an experience! maybe you will like it better than github? nahhh 
[05:52:06 CET] <daksh> Hehe xP
[05:52:46 CET] <daksh> I dont think the answer I was looking for is at https://trac.ffmpeg.org/wiki/CompilationGuide/macOS, although it is pretty helpful, it does not tell me how to do I simultaneous install
[05:53:26 CET] <daksh> I mean, can I develop on another `build environment` kind of thing, rather than having/removing my system wide ffmpeg installation
[05:54:02 CET] <Compn> ah well when you build ffmpeg in homebrew , just do a "make" not "make install" , this means you can run that new ffmpeg by typing ./ffmpeg. where ffmpeg without the ./ will run the normal system installed version
[05:54:20 CET] <Compn> so yes, multiple simultaneous versions
[05:54:28 CET] <Compn> just have to have different directories of ffmpeg 
[05:55:02 CET] <Compn> there are a lot of terminal things you have to learn about using a command line program , it takes a while :)
[05:55:29 CET] <daksh> Well a journey it is!
[05:55:30 CET] <Compn> with xcode that is
[05:55:33 CET] <Compn> not homebrew ...
[05:55:42 CET] <Compn> sorry i got it mixed up, been a while since i compiled on osx
[05:55:46 CET] <daksh> Yeah I was just about to ask you that
[05:56:14 CET] <Compn> looks like homebrew will install it system wide, probably not what you want
[05:56:45 CET] <Compn> more stuff in our wiki https://trac.ffmpeg.org/wiki
[05:57:28 CET] <daksh> Yeah, that is not what I want. I already have a system wide installed version. I want a separate one inside the directory 
[05:58:25 CET] <Compn> after you get xcode setup, grab the dependencies and git ffmpeg pull , just do make not make install. when you get to that step anyways, its a lot of steps
[05:58:59 CET] <daksh> https://trac.ffmpeg.org/wiki/CompilationGuide/macOS I was looking at that, so what I can understand from it. I will first need to install dependencies (which I guess I could do with brew(?)).. Aahhh I see
[05:59:24 CET] <daksh> I see I see
[05:59:32 CET] <daksh> ./configure; make. Thats it
[05:59:38 CET] <daksh> Sure, I will try that out in a bit :D
[05:59:38 CET] <Compn> yep
[06:00:08 CET] <Compn> take your time, dont get too discouraged if you run into problems, and write down problems and what works... we can use that to improve our documentation  / wiki
[06:01:03 CET] <Compn> it can be hard for us to write documentation because we have taken for granite all of the tweaks and skills we have learned
[06:01:19 CET] <Compn> r&m joke 
[06:03:40 CET] <Compn> daksh : its late here, i must be going soon. other people might be on later...
[06:04:41 CET] <Compn> daksh : there is also #linux or #help channels here on irc if you get stuck. or you can ask questions about compiling ffmpeg in #ffmpeg too of course
[06:05:15 CET] <Compn> we try to separate the developing and bugs/compiling talk to different channels so we dont get lost
[06:06:07 CET] <Compn> daksh : what country are you from ? 
[06:32:51 CET] <daksh> I am from India
[06:33:05 CET] <daksh> Compn: Sure, Good night :)
[06:40:22 CET] <Compn> night night
[08:48:48 CET] <daksh_> I want to use ffmpeg in Python2 to extract audio from a video. How do I go about it? Is there some reliable python library for ffmpeg or should I run a terminal command using python?
[08:51:32 CET] <wm4> probably best to invoke ffmpeg CLI as process, because the ffmpeg API is very low level
[08:51:39 CET] <wm4> anyway this is a question for #ffmpeg
[09:02:11 CET] <daksh_> wm4: I tried asking in #ffmpeg, did not get any response. So I thought it might have belonged here. Sorry 
[09:10:02 CET] <wm4> technically this channel is for development of ffmpeg, not a #ffmpeg fallback channel
[09:17:24 CET] <daksh_> wm4: My apologies
[10:34:05 CET] <kwizart> hi there, is there a way to schedule commit 9dde6ab06c48f9447cd16f39bee33569cddb7be4 in master for older branches ? (at least 3.3x and later)
[10:34:22 CET] <kwizart> fedora27 at least seems affected by this
[10:34:49 CET] <kwizart> apparently it missed the 3.4.1 train, sorry for reporting that late
[10:48:14 CET] <JEEB> but fedora 27 doesn't have FFmpeg at ll?
[10:48:27 CET] <JEEB> so this is most likely rpmfusion or something
[10:48:34 CET] <kwizart> of course it has, it's just not redistributed by Red Hat
[10:48:50 CET] Action: kwizart is the rpmfusion project coordinator indeed
[10:49:18 CET] <JEEB> and yea, I agree that if that applies to 3.3 it should be back-ported
[10:49:37 CET] <wbs> that patch should apply to any maintained branch
[10:49:58 CET] Action: JEEB just doesn't know what branches are "maintained" in FFmpeg
[10:50:44 CET] <kwizart> I think maintained branches are down to 2.8 ? we are using 2.8 for Enterprise Linux (RHEL, CentOS, etc)
[10:51:21 CET] <kwizart> but there: 1/ we don't have such recent binutils, 2/ we don't build for arm(v7,v8) at all
[10:51:54 CET] <kwizart> despite we might be in the future
[11:25:08 CET] <durandal_1707> michaelni: im more and more convinced that current behaviour of color range paatch is correct
[11:27:01 CET] <durandal_1707> michaelni: the alternative is add color range to format conversion, so whenever it changes, it will auto insert scale filter to convert between different color ranges
[11:27:26 CET] <durandal_1707> so even more conversions
[11:51:15 CET] <durandal_1707> michaelni: if you dont have more arguments than i would be happy to apply patch set
[11:51:51 CET] <nevcairiel> doesnt it have to convert between color ranges, or it may end up being the wrong one?
[12:00:21 CET] <wm4> durandal_1707: anyway I appreciate that you try to get rid of that crap
[12:02:12 CET] <durandal_1707> nevcairiel: so you saying that color range should be added to filter format negotiation?
[12:03:21 CET] <nevcairiel> why not? its part of it now through the J type.  If a filter doesn't support full range (for some reason, perhaps math would overflow or whatever), then it should not receive full range, or the result will be wrong
[12:04:43 CET] <nevcairiel> although range is generally an annoying topic, as some pixel formats are inherently full range by default (ie. rgb)
[12:09:57 CET] <wm4> all parameters should be part of negotiation
[12:10:11 CET] <wm4> the fact that lavfi currently only supports pixfmt and video size is entirely backwards
[12:10:28 CET] <wm4> and as one of the few API users, mpv actually suffers from it
[12:11:47 CET] <nevcairiel> luckily i always refused to do much filtering
[12:11:55 CET] <nevcairiel> only do deint, thats simple
[12:11:59 CET] <nevcairiel> same in/out format, done
[12:12:41 CET] <wm4> heh
[12:14:11 CET] <durandal_1707> please stop fucking bullshit bikesheding and provide aactual solutions
[12:14:31 CET] <durandal_1707> why it must be arrray?
[12:17:44 CET] <wm4> because other things (like pixfmt) is an array too
[12:17:53 CET] <cwilson_> Hi guys, I was just trying to upload some files to the FTP server at upload.ffmpeg.org but I can't  connect. Is anyone else having trouble with it?
[12:18:12 CET] <wm4> if we ever add correct handling of colorspace flags etc., those will be arrays too
[13:16:08 CET] <durandal_1707> why was fucking custom parameters setup for some filters was increased from 7 yo 8?
[13:16:27 CET] <durandal_1707> this is pure fucking shit
[13:17:03 CET] <durandal_1707> it is hidden by merge commits
[13:17:18 CET] <durandal_1707> who increased number?
[19:10:39 CET] <kierank> so, why can't I use fate reliably?
[19:11:52 CET] <wm4> you can't?
[19:11:54 CET] <JEEB> is there issues with it?
[19:12:06 CET] <wm4> does that refer to failing randomly or what?
[19:12:58 CET] <kierank> yes
[19:13:34 CET] <kierank> https://www.irccloud.com/pastebin/z9GhfAdT/
[19:14:21 CET] <wm4> looks evil
[19:14:35 CET] <JEEB> :<
[19:14:49 CET] <JEEB> so after some frame delay all are different
[19:14:51 CET] <nevcairiel> never seen random h264 tests fail
[19:14:55 CET] <kierank> Test api-flac failed. Look at tests/data/fate/api-flac.err for details.
[19:15:00 CET] <nevcairiel> with threads?
[19:15:02 CET] <JEEB> that IIRC is threaded as well
[19:15:09 CET] <JEEB> so I will guess that's got something to do with threads
[19:15:22 CET] <kierank> api-flac passes now
[19:15:26 CET] <kierank> tests just randomly fail
[19:15:35 CET] <JEEB> that's bad
[19:15:36 CET] <wm4> bad hardware?
[19:15:47 CET] <kierank> nope
[19:16:10 CET] <JEEB> the last threading related thing I remember is the atomics stuff
[19:16:15 CET] <JEEB> before that I don't remember
[19:17:46 CET] <kierank> Test vsynth1-dnxhd-4k-hr-lb failed. Look at tests/data/fate/vsynth1-dnxhd-4k-hr-lb.err for details.
[19:18:00 CET] <nevcairiel> are you sure its not hardware
[19:19:19 CET] <kierank> no errors in dmesg
[19:19:36 CET] <wm4> what's the fate invocation?
[19:20:07 CET] <kierank> make fate  SAMPLES=fate-suite/
[19:20:22 CET] <kierank> obe at obe:~/ffmpeg-kk$ ./ffmpeg
[19:20:22 CET] <kierank> ffmpeg version N-89461-g918de76 Copyright (c) 2000-2017 the FFmpeg developers
[19:20:22 CET] <kierank>   built with gcc 4.8 (Ubuntu 4.8.5-2ubuntu1~14.04.1
[19:20:41 CET] <nevcairiel> not even parallel make or any threading? definitely not seeing any of that here or on any fate box i run
[19:22:03 CET] <kierank> nope
[19:24:37 CET] <wm4> strange CPU with unusual feature combination?
[19:27:05 CET] <kierank> Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz
[19:35:39 CET] <SortaCore> welp windows is now working properly after the update
[20:03:36 CET] <nevcairiel> actually it isnt, it just builds again
[20:28:30 CET] <jamrial> nevcairiel: just revert the commit that added atomics to the codec locking mechanic
[20:28:52 CET] <jamrial> it wasn't even needed or part of the work to remove lavu atomic wrapper usage
[20:30:17 CET] <wm4> anyway, the emulation for the cas function is still broken?
[20:30:49 CET] <jamrial> nobody touched the c11 wrappers, so yes
[20:31:24 CET] <wm4> and the breaking case was the only case these cas functions were used
[20:31:44 CET] <wm4> that means if someone tries to use them again we'll have the same situation again
[20:31:57 CET] <jamrial> probably
[20:32:09 CET] <jamrial> also, it's been almost two months now since the bump. we need to decide when the unstable abi period ends
[20:32:34 CET] <wm4> why do we need a stable ABI in what is a dev branch
[20:34:15 CET] <jamrial> good question. although i don't think we ever waited until the first post bump release was tagged before
[20:36:36 CET] <wm4> IMO it'd be much simpler if we only froze ABI in release branches
[20:44:10 CET] <JEEB> kierank: I haven't looked yet, but did upipe have nice code regarding making <the randomness you can get out of MPEG-TS> into monotonically rising timestamps?
[20:47:10 CET] <kierank> Yes but quite complex modular arithmetic
[20:47:25 CET] <JEEB> ok, that's fine. it gives me hope
[20:47:42 CET] <JEEB> (hope is the first thing on the path to destruction, anyways)
[20:48:22 CET] <kierank> I would imagine vlc does the same thing
[20:49:08 CET] <JEEB> most likely
[21:03:10 CET] <nevcairiel> wm4: the cas functions are fine for pointers, or if you need them for anything else, make the type intptr_t, but considering the only cas f unction we had in the old avutil stuff was for pointers, its probably fine.
[21:04:22 CET] <wm4> the cas emulation can't work because it's not c11 compatible
[21:04:38 CET] <nevcairiel> it can work on any pointer-sized variables just fine
[21:04:48 CET] <wm4> it can only work for intptr_t itself
[21:04:50 CET] <nevcairiel> it just fell apart here because it was the wrong size argument
[21:05:25 CET] <nevcairiel> casts dont show up in assembly, so its fine =p
[21:06:09 CET] <wm4> well if the compiler doesn't eat you for strict aliasing violation, and you don't mind the ugly warnings, sure
[21:06:26 CET] <nevcairiel> there are no warnings for conversion of pointers to intptr_t
[21:06:34 CET] <nevcairiel> thats the point of that type, you can convert pointers to it
[21:07:50 CET] <wm4> wat
[21:08:03 CET] <nevcairiel> but perhaps you should ask courmisch what he was thinking when he wrote that, he is usually the first one to scream aliasing violations
[21:08:03 CET] <wm4> intptr_t* is incompatible to void**
[21:08:23 CET] <wm4> yeah, not sure how he could write that
[21:08:47 CET] <SortaCore> isn't sizeof(type *) == sizeof(void *)?
[21:09:08 CET] <wm4> it's still a strict aliasing violation
[21:09:33 CET] <nevcairiel> we violate those everywhere anyway
[21:09:44 CET] <wm4> not really
[21:09:51 CET] <wm4> av_freep was a big one
[21:10:05 CET] <wm4> but that got solved with technically correct nonsense
[21:10:36 CET] <nevcairiel> which shows that the entire topic is basically nonsense
[21:10:37 CET] <wm4> uint8_t might not be unsigned char in theory, so it could break on implementations which make that a separate type I guess
[21:11:14 CET] <wm4> I still sometimes confuse the av_freep argument, so I think that function has a very real toll on readability etc.
[21:23:14 CET] <cone-448> ffmpeg 03Hendrik Leppkes 07master:fd542b6f2026: Revert "libavcodec/utils.c: simplify avcodec locking with atomics"
[21:37:12 CET] <nevcairiel> hm, i wonder if the recent msvc2017 update causes rmdec to miscompile for some reason, i get odd failures
[21:38:04 CET] <BtbN> working as intended (tm)
[21:38:17 CET] <nevcairiel> they introduced a bunch of new optimizations in that update
[21:38:19 CET] <nevcairiel> so who knows
[21:40:42 CET] <wbs> nevcairiel: I'm looking at 2 broken tests for arm64 in the 15.5 update as well; haven't confirmed whether they're bugs in the code or in the compiler yet
[21:41:21 CET] <nevcairiel> some weird audio te sts have been failing for ever in 2017, i have been meaning to fully review that
[21:41:29 CET] <nevcairiel> but so busy lately
[21:41:31 CET] <wbs> right, those aren't in libav
[21:42:25 CET] <nevcairiel> guess i never got around to setting up 2017 libav boxes, only 2013 and 2015 there, maybe i should update the 2013 one
[21:46:04 CET] <jamrial> gcc trunk (what will be in 8) is also currently miscompiling something
[21:46:07 CET] <jamrial> http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-experimental&time=20171205042952
[21:46:15 CET] <jamrial> probably the filter in question, owdenoise
[21:47:06 CET] <jamrial> i have no idea how to make a working testcate to report this, and gcc bugzilla dislikes reports that say things like "download and compile ffmpeg, download 1gb of samples, then run this test"
[21:47:33 CET] <jamrial> at least it's a filter and not the flac decoder, like with gcc 4.9
[21:56:06 CET] <tmm1> jkqxz: so was it decided that hwaccels should have both AV_CODEC_HW_CONFIG_METHOD_AD_HOC and AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX
[21:58:57 CET] <nevcairiel> if they support both, then they should
[22:20:07 CET] <wm4> applies to mediacodec
[22:29:57 CET] <jkqxz> tmm1:  Yes.  The ff_get_format() code rejects the method if it's not present there.
[22:30:45 CET] <jkqxz> While we would like Very Naughty People (such as nevcairiel) to update their code, the old API is technically there still for quite a while.
[22:44:23 CET] <cone-448> ffmpeg 03Paul B Mahol 07master:cbd524b26cd8: avfilter/avfiltergraph: remove ugly dead code
[22:45:48 CET] <nevcairiel> i like my code, it works and gives me a maximum of control
[22:46:42 CET] <nevcairiel> i'm sure there would be a range of regressions if i change it
[22:50:41 CET] <tmm1> in mateo`'s patch he added a new AVCodecHWConfigInternal entry for HW_DEVICE_CTX.. that should be the same as bitwise-or together right?
[22:55:20 CET] <cone-448> ffmpeg 03Lou Logan 07master:555119bd7625: doc/filters: re-arrange options for testsrc family
[00:00:00 CET] --- Tue Dec 12 2017