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

[burek]

[00:06:29 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:3f128fc4a3fa: vf_showinfo: Simplify reporting stereo3d information
[00:06:30 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:883ce264d9ff: vf_showinfo: Display spherical properties
[00:06:31 CEST] <cone-318> ffmpeg 03James Almer 07master:69bb3f7bffa2: Merge commit '3f128fc4a3fa1ef8a87974eb5484a997a84868fe'
[00:06:32 CEST] <cone-318> ffmpeg 03James Almer 07master:0acb18d29872: Merge commit '883ce264d9ffc5bdaf477e09ee155b03339c46a6'
[00:16:27 CEST] <cone-318> ffmpeg 03Luca Barbato 07master:8c616b3b8996: avplay: Use the named syntax for buffersrc arguments
[00:16:28 CEST] <cone-318> ffmpeg 03James Almer 07master:6a426693cce0: Merge commit '8c616b3b8996bd4f9b117496b66b16cc625d7d24'
[00:18:38 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:083ea8768121: APIchanges: Update bump dates
[00:18:39 CEST] <cone-318> ffmpeg 03James Almer 07master:a60fb1f88f49: Merge commit '083ea8768121ee800893e124b08483011b798919'
[00:45:10 CEST] <cone-318> ffmpeg 03Diego Biurrun 07master:d6390090c4db: configure: Skip check for inline assembly capabilities when explicitly disabled
[00:45:11 CEST] <cone-318> ffmpeg 03James Almer 07master:4e6c85b3bae0: Merge commit 'd6390090c4dbd766b77353553d9cb4fb4fb41ebd'
[00:55:32 CEST] <cone-318> ffmpeg 03Ricardo Constantino 07master:d4f3c26b700a: rtmpproto: send swfverify value as swfurl if latter is unused
[00:55:33 CEST] <cone-318> ffmpeg 03James Almer 07master:cd541de9dc27: Merge commit 'd4f3c26b700ae847433ba3c67dc99c32bc1fd4a1'
[01:00:18 CEST] <cone-318> ffmpeg 03Sean McGovern 07master:fe6eea99efac: nsvdec: don't ignore the return value of av_get_packet()
[01:00:19 CEST] <cone-318> ffmpeg 03James Almer 07master:ce1b1f00bdbe: Merge commit 'fe6eea99efac66839052af547426518efd970b24'
[01:48:15 CEST] <cone-318> ffmpeg 03Diego Biurrun 07master:75ef91543422: configure: Disable inline assembly for PathScale compilers
[01:48:16 CEST] <cone-318> ffmpeg 03James Almer 07master:acf70639fb53: Merge commit '75ef91543422049a01b594925fcdb182ea12eb09'
[10:06:58 CEST] <korean-developer> hello ~~
[10:08:19 CEST] <korean-developer> Is there anyone who has made timelapse with FFMPEG, and know about setting PTS limited ?
[10:14:31 CEST] <korean-developer> hey~
[10:14:41 CEST] <korean-developer> is there anyone ??
[10:15:30 CEST] <JEEB> that sounds like using/developing *with* FFmpeg and not FFmpeg development
[10:15:34 CEST] <JEEB> please move to #ffmpeg
[15:38:04 CEST] <BBB> Im a little concerned that the discussion regarding FF_DEBUG_MV bump is so quiet& does everyone just think its ok to delay it with no plan to actually address it at all?
[15:39:37 CEST] <ubitux> BBB: plan would be to set up a dead line just like ffserver
[15:39:45 CEST] <ubitux> s/would/can/
[15:39:56 CEST] <BBB> thats what I proposed, but I havent had any positive reactions to that
[15:40:06 CEST] <BBB> I did get some private insults from certain people accusing me of dark magic etc.
[15:41:49 CEST] <BBB> if other people think an ffserver-style approach is ok, then I can live with that, but Id like it set in stone and agreed upon by everyone; I dont want to see another delay 6 months from now (or whenever)
[15:42:36 CEST] <BBB> also, that plan needs to be assigned to someone; if nobody is assigned, ffserver demonstrates nothing will happen and were just delaying for the sake of delaying
[15:43:13 CEST] <BBB> e.g. [insert name here] will be responsibe for doing X Y and Z so we can invoke removal of code under FF_DEBUG_MV by [insert date for next abi bump here]
[15:43:31 CEST] <BBB> without that [insert name here] part, I can guarantee you that nothing will happen adn were just delaying for no reason
[15:43:39 CEST] <BBB> in that case, the code should just go
[15:44:41 CEST] <nevcairiel> comparisons to ffserver don't really fit very well, there is actual technical reasons for wanting ffserver to go, this MV stuff doesn't harm anyone, and if it were never deprecated in the first place, noone would even care
[15:45:46 CEST] <BBB> kierank: is that true?
[15:46:07 CEST] <nevcairiel> i have not once seem anyone mention this MV stuff ever
[15:46:29 CEST] <BBB> its because nobody dares touch mpegvideo with a ten-mile pole
[15:46:46 CEST] <nevcairiel> and thats not because of MV, so, q.e.d?
[15:46:47 CEST] <nevcairiel> :D
[15:47:06 CEST] <BBB> that should be posed as a question, not a statement
[15:47:21 CEST] <BBB> is MV part of the swamp?
[15:47:32 CEST] <nevcairiel> its really not even that much code
[16:04:25 CEST] <jamrial> ubitux: ping
[16:04:40 CEST] <ubitux> jamrial: pong
[16:05:36 CEST] <jamrial> ubitux: can you give 0b9a237b23 a look?
[16:05:55 CEST] <jamrial> i don't have arm hardware to bench and choose between keeping our version or replacing it with this
[16:06:38 CEST] <ubitux> meh...
[16:07:03 CEST] <ubitux> i don't think i can do that today
[16:07:06 CEST] <jamrial> there's a 16x16 version a few commits ahead we don't have, so that one's nice :p
[16:07:20 CEST] <ubitux> is it present in checkasm?
[16:07:51 CEST] <jamrial> yeah
[16:08:06 CEST] <ubitux> mmh maybe i can give it a try tonight then
[16:08:15 CEST] <jamrial> ok, thanks
[16:11:28 CEST] <wbs> fwiw, iirc the libav version should be equivalent or faster on the cores I tested. the ffmpeg one does show some signs of support for skipping parts of the idct for a sparse one, but it didn't actually ever seem to be triggered by the calling C code
[16:12:05 CEST] <wbs> (I tried adding checkasm support for testing the partial idcts, but I wasn't able to figure out exactly what the parameter means or how it works, while it was straightforward for vp9)
[16:12:36 CEST] <wbs> and given my testing of the calling C code in hevcdec, it actually never passes such values that would make it skip something of the transform
[16:13:47 CEST] <jamrial> it's that why alexandra rewrote it?
[16:15:57 CEST] <wbs> no, that's just because she didn't know about it; at the point in the review when I noticed you had this version I tried to make sure it wouldn't be worse in some aspect; I think it should be equal or better but it's of course good to check for yourselves
[16:17:25 CEST] <wbs> I'm not totally satisfied with the code style/structure of the libav hevc idct asm, but I didn't have time to spend on making it more idiomatic and/or the way I would have written it, but the total performance should be acceptable
[17:49:44 CEST] <kierank> BBB: sorry, been on a plane, is what true?
[17:50:56 CEST] <BBB> does removing the code under FF_DEBUG_MV help in making mpegvideo more accessible for the changes youre trying to make, or do you think its ok to keep it?
[18:16:15 CEST] <jya> BBB: hi
[18:17:11 CEST] <jya> BBB: working on resyncing our copy of ffvp9, do I need to worry about the VP9 superframe filter?
[18:42:38 CEST] <nevcairiel> vp9 superframe is only needed for (re)muxing
[18:44:56 CEST] <jamrial> unless you're talking about the superframe split bsf, which is currently not being used by the decoder, but supposedly will once BBB gets on it :p
[18:45:45 CEST] <atomnuker> jya: just curious, why do you need to cut out the decoder? couldn't you just use git submodules and a configure script which only enables it?
[18:46:03 CEST] <jamrial> the parser is doing a good job in that regard for the time being
[18:47:12 CEST] <jya> atomnuker: you're assuming that ffmpeg source code provides sufficient flexibility to only include the binary portion we need (and can ship)
[18:47:16 CEST] <JEEB> atomnuker: I think they don't even use lavc *not sure though), also it might be like Fedora - that they need to get a lawyer to OK the whole code of the dependency, even if during the build only a small portion of it is enabled
[18:47:28 CEST] <jya> jamrial: the later.. so it's not used by the decoder yet... good to know
[18:48:23 CEST] <jamrial> jya: no, vp9 decoder only needs the vp9 parser for now (and "videodsp" according to configure)
[18:48:55 CEST] <atomnuker> JEEB: why would they need a lawyer? firefox isn't being sold
[18:49:09 CEST] <jya> atomnuker: now if you find a method that can automate extracting the vp9 decoder, and configure only that, then I'm all for it
[18:49:26 CEST] <jya> atomnuker: we ship binaries from the US.
[18:49:40 CEST] <jya> it has nothing to being sold or not
[18:50:20 CEST] <atomnuker> I thought you had to sell something in order to get permission for patents
[18:50:25 CEST] <JEEB> no
[18:50:46 CEST] <atomnuker> how disgustingly retarded
[18:50:50 CEST] <jya> I so wish :)
[18:51:43 CEST] <jya> damn, who came up with this idea of max_pixels in AVCodecContext.... with no functions to set it :(
[18:51:45 CEST] <atomnuker> jya: why not distribute binaries from someplace else?
[18:52:12 CEST] <jya> mozilla is a not for profit that is based in the US
[18:52:33 CEST] <atomnuker> so? your servers can be anywhere
[18:52:44 CEST] <atomnuker> you can't change the system if you blindly comply with it
[18:52:47 CEST] <atomnuker> boycot it
[18:52:54 CEST] <jya> you think the patent holders will care about that details ? :)
[18:53:24 CEST] <jya> that's exactly what we do, we don't ship code that contains patent encumbered code
[18:53:44 CEST] <atomnuker> well, you don't ship code period. you ship binaries
[18:54:03 CEST] <jya> riiiiight
[18:54:45 CEST] <JEEB> reality sucks. you're a thing in the US and even if you distro *from* somewhere else you're still a US entity distributing things. anyways, I don't think this is something a normal coder has much leeway over :)
[18:54:48 CEST] <atomnuker> just host the servers in the antarctic somehow, in some unclaimed area
[18:55:17 CEST] <atomnuker> they can't get you there, there's no government, its international waters
[18:55:55 CEST] <jya> atomnuker: yeah, because you know... a US entity (physical or moral) doing something illegal in the US in another country is known as the best way to get around the law
[18:57:31 CEST] <atomnuker> how utterly horrible
[18:57:35 CEST] <JEEB> in theory if you made Mozilla LLC only produce the source code and say, French VideoLAN Assoc would be doing the binaries and binary distribution that *might* get through something, but still
[18:57:59 CEST] <JEEB> generally simpler to just keep away from the mess and enjoy a picnic
[18:58:58 CEST] <atomnuker> yarr
[18:59:17 CEST] <atomnuker> just code whatever you want and let others distribute binaries
[18:59:33 CEST] <atomnuker> its what we do (though because we're lazy to provide official builds I think)
[19:00:49 CEST] <jya> michaelni: any chance we can have a AVSetMaxPixelCount(AVCodecContext*, int64_t); type of functions? that would allow to check at runtime if AVCodecContext needs to have max_pixels set ... (referring to your change revision 2f07830e69b )
[19:01:46 CEST] <jya> I don't see how we can make our code get around knowing if this value needs to be set or not (the major version hasn't changed so we can't detect such code)
[19:02:07 CEST] <jya> atomnuker: ffmpeg isn't based in the US
[19:02:16 CEST] <nevcairiel> either you want to set it, or you don't, i dont see how such a function would help?
[19:02:56 CEST] <michaelni> jya, you should be able to use AVOptions to set it without knowing if its in the struct or not if thats what you want
[19:03:01 CEST] <jya> nevcairiel: we load dynamically the libavcodec library at run time, we then use templates to determine which version of ffmpeg has been loaded
[19:03:14 CEST] <nevcairiel> oh right your batshit insane setup
[19:03:23 CEST] <nevcairiel> but yeah use avoptions
[19:03:53 CEST] <jya> right now we differentiate the code based on the major version, that allows to determine which avcodec.h to use for compiling the code
[19:04:22 CEST] <jya> testing if a method exists in the code is the easiest 
[19:04:43 CEST] <BBB> jya: \o/
[19:04:47 CEST] <jya> we don't have support for any of AVOptions :( we don't set things up that way... I guess we should
[19:05:06 CEST] <JEEB> yea, it's been around for a while :)
[19:05:15 CEST] <michaelni> should be simply a single call to av_opt_set_int() for setting this singe param
[19:05:28 CEST] <JEEB> yup
[19:05:45 CEST] <jya> a pity that the default of max_pixels has been set at 0... that causes current version of firefox to always fail to decode with current version of ffmpeg
[19:07:06 CEST] <nevcairiel> 0 means the feature is disabled, why would that cause any failure
[19:07:12 CEST] <jya> ubuntu 17.10 ships with 3.3.4 , that makes firefox not work with the version they ship
[19:07:18 CEST] <nevcairiel> actually, teh default is INT_MAX
[19:08:23 CEST] <jya> nevcairiel: if you initialise via AVOptions yes, avcodec_alloc_context3 returns it with a value set at 0
[19:08:55 CEST] <jya> so that always fails the test later when opening the codec calls ff_set_dimensions
[19:09:05 CEST] <kierank> BBB: can't remember, hard to check on my phone. Will check later.
[19:09:05 CEST] <jya> as av_image_check_size2 returns an error
[19:09:16 CEST] <nevcairiel> i use avcodec_alloc_context3 and it gets inited fine
[19:10:01 CEST] <nevcairiel> i checked right after that call, and its set to INT_MAX
[19:10:08 CEST] <nevcairiel> so something in your code must be bonkers if its 0
[19:10:46 CEST] <jya> we simply call avcodec_alloc_context3 
[19:10:56 CEST] <nevcairiel> with a valid codec?
[19:11:46 CEST] <jya> https://github.com/FFmpeg/FFmpeg/commit/2f07830e69b 
[19:11:49 CEST] <jya> with vp9 codec
[19:12:24 CEST] <jya> I don't see any places that would set the value at int_max there unless you called av_opt_set_int 
[19:12:51 CEST] <nevcairiel> as long as its part of the options_table.h, its defaults values are applied to the struct on creation, always
[19:13:15 CEST] <jya> nevcairiel: are you sure you're only using libavcodec here?
[19:13:21 CEST] <jya> (and libavutil of course)
[19:13:39 CEST] <jya> hmmmm... interesting
[19:13:46 CEST] <nevcairiel> how would that matter? I just call avcodec_alloc_context3, put a breakpoint right on the next line, and checked the struct
[19:13:47 CEST] <nevcairiel> and its set
[19:18:36 CEST] <nevcairiel> just make sure to pass a proper AVCodec to alloc
[20:11:03 CEST] <ubitux> jamrial: libav has a faster version, and the 10-bit version
[20:11:19 CEST] <ubitux> dunno if they are compatible (and if checkasm actually tests accuracy)
[20:11:44 CEST] <ubitux> our:
[20:11:46 CEST] <ubitux> hevc_idct_4x4_8_c: 394.1
[20:11:48 CEST] <ubitux> hevc_idct_4x4_8_neon: 126.6
[20:11:53 CEST] <ubitux> with their simd:
[20:11:59 CEST] <ubitux> hevc_idct_4x4_8_c: 384.2
[20:12:01 CEST] <ubitux> hevc_idct_4x4_8_neon: 109.2
[20:12:03 CEST] <ubitux> hevc_idct_4x4_10_c: 406.7
[20:12:05 CEST] <ubitux> hevc_idct_4x4_10_neon: 109.2
[20:12:28 CEST] <ubitux> (fluctuating due to various params)
[20:12:33 CEST] <ubitux> (also, using perf here)
[20:12:58 CEST] <ubitux> here is another run:
[20:13:00 CEST] <ubitux> hevc_idct_4x4_8_c: 389.1
[20:13:01 CEST] <ubitux> hevc_idct_4x4_8_neon: 126.6
[20:13:03 CEST] <ubitux> our ^
[20:13:07 CEST] <ubitux> hevc_idct_4x4_8_c: 389.3
[20:13:09 CEST] <ubitux> hevc_idct_4x4_8_neon: 107.8
[20:13:11 CEST] <ubitux> hevc_idct_4x4_10_c: 418.6
[20:13:13 CEST] <ubitux> hevc_idct_4x4_10_neon: 108.1
[20:13:15 CEST] <ubitux> libav ^
[20:13:30 CEST] <ubitux> so yeah, we can probably trash our versions here
[20:14:44 CEST] <ubitux> tested with http://sprunge.us/UWfP?diff
[20:15:24 CEST] <ubitux> and checkasm --bench=hevc_idct
[20:26:48 CEST] <nevcairiel> out idct prototypes should be mostly compatible, i think
[20:36:21 CEST] <jamrial> yeah, they changed the mc ones only afaik
[20:37:03 CEST] <jamrial> ubitux: will merge into my github repo so you can make sure it works before i push then
[21:00:45 CEST] <JEEB> can anyone else chime on the EOF thing, if we want to either A) leave things as they are and just break old clients with an API behavior change B) add an option for the new behavior , or C) revert the 0 != EOF thing
[21:01:25 CEST] <JEEB> because while those people that are on IRC have most likely adapted their stuff, we will have quite a bit of breakage due to this :P
[21:04:04 CEST] <BBB> ...
[21:04:18 CEST] <BBB> Ive stayed quiet lately because I have this creeping feeling that it doesnt matter
[21:04:28 CEST] <BBB> we have no rules
[21:04:39 CEST] <BBB> people just do whatever they want and will make up rules on the fly to justify their behaviour
[21:05:11 CEST] <BBB> so I dont know how to deal with it
[21:05:56 CEST] <BBB> its not about what broke, its about who broke it; if its a good person, its fine, and if its a bad person, its not fine. its all political
[21:06:13 CEST] <BBB> so Im afraid that likely (A) is your only option :(
[21:06:33 CEST] <jamrial> BBB: who broke it is a casual dev, i think, so no politics
[21:06:46 CEST] <JEEB> yea
[21:06:54 CEST] <jamrial> and it was unintended
[21:07:08 CEST] <JEEB> I'd probably go for B but I'm not sure how many places I'd have to poke to add the option
[21:07:56 CEST] <jamrial> maybe a temporary option to recover the old behavior should be added for the usual period of ~2 years, and a notice about it being removed eventually added
[21:08:32 CEST] <jamrial> basically, deprecating the old behavior and leaving a compat mode for it
[21:08:43 CEST] <JEEB> yes
[21:08:50 CEST] <jamrial> library users will nontheless have to update their code to enable said option
[21:09:04 CEST] <jamrial> then again to remove it two years from now :p
[21:09:05 CEST] <jamrial> so dunno
[21:09:45 CEST] <jamrial> is this change, unintended breakage aside, a good one? because if it doesn't really bring any worthwile benefit maybe we should just revert it
[21:11:51 CEST] <JEEB> the requirement for the change was zero-byte UDP packets which seem to be valid. originally the code was added into the UDP lavf module, but then it was requested to be moved into lavf general
[21:12:07 CEST] <JEEB> which thus broke the API behavior
[21:12:47 CEST] <nevcairiel> jamrial: i have always questioned the usefulness of the change, but apparently there is obscure  crazy things that might use it
[21:13:11 CEST] <JEEB> yes, most users don't find that stuff on their networks
[21:13:12 CEST] <nevcairiel> and re: flag, if anything it should be inverted, or its still an API break =p
[21:13:23 CEST] <JEEB> well flag to have the NEW behavior
[21:13:29 CEST] <JEEB> so that the default behavior is the old one
[21:13:33 CEST] <JEEB> that's what I meant
[21:13:35 CEST] <jamrial> yeah, probably
[21:13:35 CEST] <BtbN> It should behave as it used to, which is imo a bit broken, with some flag somewhere to flip it to sane behaviour
[21:13:36 CEST] <JEEB> opt-in for the new stuff
[21:13:47 CEST] <JEEB> BtbN: agreed
[21:14:04 CEST] <BtbN> And it should throw a depercation warning if the flag is unset
[21:14:44 CEST] <wbs> alternatively, only throw a warning if the flag is unset _and_ you return 0?
[21:15:11 CEST] <wbs> then you can write code that uses AVERROR_EOF for older lavf versions without any ifdefs for the new flag, while still running without warnings on the new lavf as well
[21:21:39 CEST] <jamrial> ubitux: https://github.com/jamrial/FFmpeg/tree/mergework
[21:51:53 CEST] <ubitux> jamrial: why not else if for bitdepth?
[21:52:12 CEST] <ubitux> i guess it's to follow libav's version
[21:52:14 CEST] <jamrial> that's how it is in the file i'm merging
[21:52:18 CEST] <jamrial> yeah
[21:52:38 CEST] <jamrial> i can change it if you want. i'm already merging it into a file with a different name after all
[21:52:48 CEST] <ubitux> src/libavcodec/arm/hevcdsp_init_arm.c:31:9: error: implicit declaration of function 'ff_hevcdsp_init_neon'; did you mean 'ff_hevc_dsp_init_neon'? [-Werror=implicit-function-declaration]
[21:55:25 CEST] <jamrial> figures
[21:55:44 CEST] <ubitux> aside from this it seems to work
[21:56:10 CEST] <ubitux> i'll have a deeper look in a moment
[21:56:12 CEST] <jamrial> ok
[21:56:19 CEST] <jamrial> pushed a fixed version, fwiw
[21:56:23 CEST] <ubitux> like, checking the prototypes and running the actual hevc tests
[21:56:59 CEST] <ubitux> if you can wait a little, i can't do it right now, probably in about an hour or two 
[21:57:21 CEST] <jamrial> sure
[22:03:12 CEST] <JEEB> jamrial: btw sorry for the quoting but I was just trying to do something about this :P
[22:08:32 CEST] <JEEB> and yes, "The road to hell is paved with good intentions"
[22:36:57 CEST] <cone-945> ffmpeg 03Carl Eugen Hoyos 07master:3c14547eb75c: lavfi/tests/filtfmts: Constify a variable.
[22:52:08 CEST] <cone-945> ffmpeg 03JULIAN GARDNER 07master:df95f145be15: lavc/dvbsub: Do not fail hard in the region block for 256-colour encoding.
[22:52:09 CEST] <cone-945> ffmpeg 03Carl Eugen Hoyos 07master:6e1654768585: lavc/dvbsub: Add the missing line separator to dvb_encode_rle8().
[22:56:28 CEST] <jbreeden> Working on developing an SVC decoder module. Unsure of the correct way to deal with frame size changes. When a different-sized frame is decoded, I update the avctx height & width, and reinitialize AVFrame, but I get the following error: https://pastebin.com/VahNYAcp . Is there something else I must do to handle size change?
[22:57:01 CEST] <JEEB> as I noted, that sounds like an avfilter issues rather than a decoding issue
[22:57:11 CEST] <JEEB> jbreeden: so you're outputting the AVFrame sizes correctly?
[22:59:09 CEST] <jbreeden> Yes. When I get the frame back from the decoder library, I use the dimensions provided by the decoder to set both the avctx->width & height and the AVFrame (void *data from decode function cast as AVFrame) width and height)
[22:59:58 CEST] <JEEB> jbreeden: then it might just be your test filter chain's stuff not being re-evaluated at each frame
[23:00:10 CEST] <JEEB> there's IIRC a parameter for that in certain filters
[23:00:50 CEST] <JEEB> jbreeden: so check if any of the filters you're using has an 'eval' option which you can change to 'frame'
[23:01:02 CEST] <JEEB> anyways, interesting that someone is having an interest in SVC :)
[23:01:21 CEST] <atomnuker> yeah, because its awful and wasn't used anywhere
[23:02:01 CEST] <jbreeden> So I'm not manually using any filters. inputting SVC over RTP, then transcode/remuxing to mpeg2 ts.
[23:14:04 CEST] <TD-Linux> I think the VP9 decoder can handle frame size changes
[23:14:16 CEST] <jbreeden> TD-Linux: Thanks, I'll check that out
[23:17:40 CEST] <ubitux> jamrial: alright, testing soon; took a while to build all that stuff on a board
[23:25:37 CEST] <jya> is ffmpeg 3.4 known to compile on windows ? I get a compilation error that stdatomic.h can't be found. It's always included, even though HAVE_STDATOMICS is 0 
[23:25:37 CEST] <jya> https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/buffer.c#L19
[23:28:20 CEST] <JEEB> jya: last I checked I could compile master on mingw-w64, MSVC I haven't tested recently
[23:28:44 CEST] <jya> JEEB: when is "last I checked" ? :)
[23:28:55 CEST] <JEEB> 41d6d62702
[23:29:05 CEST] <JEEB> also I think we have FATE machines for both mingw and MSVC
[23:29:29 CEST] <JEEB> http://fate.ffmpeg.org/report.cgi?slot=x86_32-mingw-w64-dll-windows-native&time=20171024022859
[23:29:36 CEST] <JEEB> mingw-w64 succeeded
[23:29:38 CEST] <jkqxz> It should use compat/atomics/win32/stdatomic.h, I think.
[23:29:40 CEST] <JEEB> http://fate.ffmpeg.org/report.cgi?time=20171024042436&slot=x86_32-msvc15-windows-native
[23:29:46 CEST] <JEEB> MSVC succeeded
[23:30:30 CEST] <JEEB> (with compilation, there are failing tests for MSVC)
[23:30:34 CEST] <jya> is that with mingw ?
[23:30:43 CEST] <jya> hmmmm weird
[23:30:45 CEST] <JEEB> the first one is mingw-w64 for 32bit it seems
[23:30:56 CEST] <JEEB> the latter on is 32bit MSVC
[23:31:05 CEST] <JEEB> so both windows toolchains
[23:31:18 CEST] <jya> with VS2017 that gives me "z:/build/build/src/media/ffvpx/libavutil/buffer.c(19): fatal error C1083: Cannot open include file: 'stdatomic.h': No such file or directory "
[23:31:54 CEST] <JEEB> you probably miss the compatibility header like jkqxz notes
[23:32:08 CEST] <JEEB> that gets added into the include path
[23:32:30 CEST] <jya> maybe I missed a file then
[23:33:10 CEST] <jya> I see : ./compat/atomics/win32/stdatomic.h
[23:33:21 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=7a53bc76c75e0be2a9a5bd8f9c7101b7509a7357;hb=HEAD#l6691>
[23:33:37 CEST] <jya> JEEB: thanks for the pointers
[23:33:39 CEST] <jkqxz> Is ATOMICS_WIN32 set?
[23:34:14 CEST] <jkqxz> And has the include path ended up on your compile lines?
[23:36:35 CEST] <jya> don't use configure ...
[23:36:48 CEST] <jya> pthread's stdatomic? that's curious
[23:38:58 CEST] <nevcairiel> its a last resort fallback using mutexes, not actually atomic
[23:39:14 CEST] <jya> nevcairiel: yeah, just looked at the code
[23:39:19 CEST] <nevcairiel> but any sane platform should either have C99  atomics, gcc atomics or win32 atomics
[23:45:01 CEST] <nevcairiel> jkqxz: our glorious djgpp fate box found some issues in your cbs stuff related to string format argument type mis-matches, if you want to check that out http://fate.ffmpeg.org/report.cgi?slot=x86_64-freedos-djgpp&time=20171024213751
[23:49:12 CEST] <nevcairiel> (there is also a bunch of other warnings regarding type mismatches)
[23:49:21 CEST] <jkqxz> Um, int is 16-bit there?
[23:49:33 CEST] <JEEB> it's DOS
[23:49:40 CEST] <jkqxz> How does that even work to build ffmpeg at all?
[23:49:55 CEST] <JEEB> because djgpp exists
[23:49:58 CEST] <jkqxz> s/build/run/
[23:50:07 CEST] <jkqxz> I guess building might work.
[23:50:12 CEST] <nevcairiel> it doesnt run
[23:50:13 CEST] <thardin> interesting that someone cares about it
[23:50:24 CEST] <nevcairiel> but its good for finding those format mismatches
[23:51:40 CEST] <jkqxz> The warnings are all the macro containing <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/cbs_mpeg2.c;h=d137762227330deeda155f48eb072facf2892566;hb=HEAD#l57>, which should be uint32_t to pass to that pointer.
[23:52:15 CEST] <nevcairiel> no harm in exactly using the same type the function wants, tho! :)
[23:52:39 CEST] <jkqxz> The printf ones are indeed wrong.
[23:52:57 CEST] <jkqxz> Is it building with Werror to make those mismatches actually kill it?
[23:53:03 CEST] <nevcairiel> probably
[23:53:18 CEST] <nevcairiel> that was the basic purpose to set it up, to find those
[23:53:32 CEST] <nevcairiel> -Werror=format
[23:53:34 CEST] <nevcairiel> so yeah
[23:55:06 CEST] <jkqxz> I feel like coverity or similar should catch that sort of thing.
[23:57:40 CEST] <ubitux> jamrial: as said on github, LGTM, thanks
[23:59:13 CEST] <jamrial> ubitux: ok, thanks for testing
[00:00:00 CEST] --- Wed Oct 25 2017