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

[burek]

[00:52:23 CEST] <BBB> lots of ffmpeg devs in that demuxed conference speaker schedule :-o
[00:53:01 CEST] <JEEB> yup
[00:53:07 CEST] <JEEB> some promising talks
[01:33:08 CEST] <Compn> the talks are very informative :)
[01:33:16 CEST] <Compn> fun audience participation sometimes :)
[02:27:21 CEST] <tdjones> What is the preferred way for me to send additional patches based off previous commits already sent to the mailing list? I don't want to spam the ML with patches that don't change for each time there is additional commits in the series, but I'd like to provide as much time as possible for comment before the end of GSoC.
[02:28:08 CEST] <atomnuker> tdjones: reply to the original patch emails you send with a v2
[02:28:21 CEST] <atomnuker> you can supply git send-email with their message ids
[02:28:31 CEST] <atomnuker> though you'll need to send them one at a time
[02:29:27 CEST] <tdjones> You want me to resend them all with v2, even if there are just 2 separate additional patches included?
[02:29:51 CEST] <tdjones> If I'm understanding you correctly
[02:30:31 CEST] <atomnuker> tdjones: no, just the ones you want to replace
[02:31:33 CEST] <tdjones> I'm not replacing any, they are additional patch files based as if the previous commits were HEAD but have no other relation
[02:31:36 CEST] <atomnuker> (you can also just reply to them with new attached .patch files)
[02:31:42 CEST] <atomnuker> oh
[02:32:15 CEST] <atomnuker> just send them directly (if you want you can specify the original root email's message id so they appear under the same thread)
[02:32:31 CEST] <tdjones> Alright, just wanted to check. Thanks
[02:37:28 CEST] <tdjones> atomnuker: If you or any of the GSoC admins here have the time to verify that my gsoc submission post is acceptable, I'd greatly appreciate it. https://tjones879.github.io/blog/gsoc-2017/
[02:37:54 CEST] <tdjones> Just some time before the final deadline
[03:18:19 CEST] <cone-349> ffmpeg 03Vitaly Buka 07master:8c2bb10ddfef: avcodec/utils: Fix signed integer overflow in rc_initial_buffer_occupancy initialization
[03:18:19 CEST] <cone-349> ffmpeg 03Vitaly Buka 07master:4a404cb5b90b: avformat/mov: Fix signed integer overflows with total_size
[03:18:19 CEST] <cone-349> ffmpeg 03Vitaly Buka 07master:eca2a49716ae: avformat/aviobuf: Fix signed integer overflow in avio_seek()
[11:08:03 CEST] <zetax> hi, where can I get more info about this? I wanna look into if I could help "Currently its in development and only implements the CELT part of the codec. Its quality is usually worse and at best is equal to the libopus encoder." https://ffmpeg.org/ffmpeg-codecs.html#opus
[11:08:44 CEST] <kierank> ask atomnuker 
[11:09:21 CEST] <zetax> atomnuker: see question about .opus above
[11:18:52 CEST] <wm4> man I hate libavformat's probing so fucking much
[11:19:13 CEST] <wm4> now it's an excuse for hardware decoders not to parse and export certain bitstream data, like colorimetry data
[11:19:30 CEST] <nevcairiel> how is that related
[11:19:32 CEST] <wm4> because libavformat does that anyway by calling back into libavcodec! trollol
[11:19:47 CEST] <wm4> nevcairiel: they rely on the libavformat data
[11:20:07 CEST] <nevcairiel> so tell them they're full of shit and avcodec decoders should be standalone =p
[11:20:28 CEST] <wm4> just what is mentally wrong with these hardware decoder people that they can write entire decoders with hardware support, but fail at things this simple, like a bit of parsing
[11:20:54 CEST] <nevcairiel> how is that any decent design, hey we rely on someone else giving us these information, if they don't, well, tough!
[11:21:39 CEST] <nevcairiel> (also, thats why i like actual hwaccels, they just work with all sorts of crazy metadata)
[11:22:17 CEST] <wm4> yeah
[13:28:24 CEST] <wm4>     if (fctx->next_decoding > (avctx->thread_count-1-(avctx->codec_id == AV_CODEC_ID_FFV1)))
[13:28:26 CEST] <wm4> just what
[13:28:40 CEST] <BBB> hahahahaha
[13:28:46 CEST] <BBB> Ive posted that a few times also
[13:28:57 CEST] <BBB> theres a few of them in different places, also
[13:28:59 CEST] <BBB> anyway
[13:29:04 CEST] <BBB> good luck fixing the unfixbal
[13:29:07 CEST] <BBB> unfixable
[13:29:44 CEST] <BBB> wm4: about your patch for mingw, I personally dont really like getter functions, but if the public API already uses that then it makes sense to reproduce that in the private API, so I wouldnt loudly object to it (I still dont like it)
[13:31:06 CEST] <wm4> alternative solutions: remove all avpriv variables (unfixable), make libs buildable as single DLL/so (seems more realistic)
[13:31:37 CEST] <BBB> we could also use dllexport/import correctly
[13:31:52 CEST] <BBB> (although highly unlikely anyone actually wants to do the work required for that)
[13:32:22 CEST] <wm4> that seems very hard
[13:32:25 CEST] <BBB> it is
[13:32:27 CEST] <wbs> would it work just the way we do it for msvc right now though?
[13:32:30 CEST] <BBB> but Ive seen some libs do it correctly
[13:32:35 CEST] <wm4> wbs: only for MSVC
[13:32:37 CEST] <BBB> so its not impossible
[13:32:45 CEST] <wm4> wbs: mingw doesn't support it this way
[13:32:52 CEST] <wbs> wm4: ah, bummer
[13:32:58 CEST] <nevcairiel> its not that hard, the effort is just exaggerated because we have 10 individual libs, instead of just one
[13:32:59 CEST] <wm4> BBB: it's extremely hard for us, though
[13:33:04 CEST] <BBB> I suppose
[13:33:20 CEST] <BBB> Im not telling you to do it :-p Im saying your patch is probably fine
[13:33:28 CEST] <wm4> unless maybe you define 10 av_export and av_import symbols, for each lib
[13:34:02 CEST] <nevcairiel> yeah you need one av_export per library, so av_export_avcodec etc
[13:34:05 CEST] <wm4> err, no av_import symbols, just av_export would have to switch between dllimport/export depending on context
[13:34:09 CEST] <wm4> yes
[13:34:30 CEST] <wm4> within libavcodec, av_export_avcodec would map to dllexport
[13:34:36 CEST] <wm4> and outside to dllimport
[13:34:56 CEST] <nevcairiel> thats how you're supposed to do it, just that this is typically with one library, not ten
[13:35:04 CEST] <wm4> or maybe a special export header
[13:35:21 CEST] <BBB> its not that much code honestly
[13:35:24 CEST] <BBB> its just super-tedious
[13:35:25 CEST] <iive> it's possible to remove all avpriv, by duplicating them in each library and not sharing/showing them.
[13:35:34 CEST] <wm4> libavcodec/exports.h, which contains "#undef av_export #define av_exprt ..." and then hope for the best
[13:35:37 CEST] <BBB> nobody likes doing tedious work
[13:35:39 CEST] <iive> since they are all constants
[13:37:19 CEST] <wm4> can we have the following policy: if someone wants to add new avpriv variables, he has to go through a klingon pain stick ritual involving all other ffmpeg developers
[14:57:50 CEST] <wm4> when can we get rid of the J bullshit pixfmts? got another bug due to them
[00:00:00 CEST] --- Thu Aug 24 2017