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

[burek]

[02:03:54 CEST] <cone-674> ffmpeg 03Devin Heitmueller 07master:9e21ba3dc340: avdevice/decklink: Fix compile breakage on OSX
[06:30:36 CEST] <philipl> BtbN: Could you verify the current state of the mpv PR still works correctly on windows? I think it's finally done. Thanks!
[06:44:23 CEST] <qwefytuoityty> have encoder av1? VLC have decoder av1? aom, but, now youtube encode file through AV1?
[06:50:05 CEST] <Compn> hmm where is lou
[06:50:19 CEST] <Compn> remind him we should move some old news to old news page. ffmpeg news getting long
[06:50:46 CEST] <Compn> news page goes back to 2013 :D
[10:43:57 CEST] <BtbN> philipl, builds and works fine still
[13:15:42 CEST] <uau> that above ticket #7446 is caused by libx264 using strtok, which is not threadsafe
[13:16:27 CEST] <uau> (not sure if any of the people caring about that are here though...)
[13:17:50 CEST] <atomnuker> echo $LD_LIBRARY_PATH = /usr/local/lib -> ffmpeg -> library mismatch
[13:17:59 CEST] <atomnuker> LD_LIBRARY_PATH=/usr/local/lib ffmpeg -> all ok
[13:18:04 CEST] <atomnuker> wat
[13:18:25 CEST] <JEEB> uau: cheers. I can comment on the ticket regarding that.
[13:18:53 CEST] <BtbN> So libx264.c just wrongfully has FF_CODEC_CAP_INIT_THREADSAFE set then.
[13:19:07 CEST] <nevcairiel> there is already a patch on the ML that explains that
[13:19:25 CEST] <uau> BtbN: well it really is more buggy than that
[13:19:36 CEST] <uau> strtok is not safe if the process has any other threads whatsoever
[13:19:43 CEST] <uau> so not really appropriate for a library
[13:19:49 CEST] <uau> locking around init won't fix that
[13:19:54 CEST] <nevcairiel> can only blame x264 for that, nothing we can do about that
[13:20:25 CEST] <BtbN> If x264 only uses it during init, that should fix it
[13:20:33 CEST] <BtbN> If it uses it at runtime, well...
[13:20:43 CEST] <BtbN> not much ffmpeg can do about it
[13:20:58 CEST] <JEEB> I guess it's the key/value parameter parsing
[13:20:59 CEST] <nevcairiel> the point is that some othre thread entirely unrelated to x264 may also use strtok
[13:21:02 CEST] <nevcairiel> and break it
[13:21:08 CEST] <JEEB> yes
[13:21:13 CEST] <nevcairiel> whoever designed strtok should get banned from development, really
[13:21:16 CEST] <BtbN> Any sane other thread should use the thread safe variant of strtok
[13:21:16 CEST] <JEEB> anyways, that is an issue in x264
[13:24:27 CEST] <uau> nevcairiel: which mailing list do you mean btw? i tried searching for strtok on ffmpeg-dev but found no matches
[13:25:09 CEST] <uau> hmm maybe it was too limited by time
[13:25:16 CEST] <JEEB> ffmpeg-devel has a patch from marton
[13:25:28 CEST] <JEEB> "avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag"
[13:25:37 CEST] <JEEB> > Libx264 uses strtok which is not thread safe. Strtok is used in
[13:25:54 CEST] <JEEB> https://patchwork.ffmpeg.org/patch/10724/
[13:29:16 CEST] <uau> ok too new then, i didn't fetch new messages before searching...
[13:30:32 CEST] <JEEB> also TIL strtok_r
[13:30:49 CEST] <JEEB> and FreeBSD has strsep(3) it seems
[13:45:08 CEST] <BtbN> https://github.com/mirror/x264/search?utf8=%E2%9C%93&q=strtok&type= weird
[13:48:10 CEST] <BtbN> param_parse is using strtok_r
[13:48:56 CEST] <BtbN> but nothing else is
[13:49:33 CEST] <JEEB> yea, ratecontrol.c uses strtok_r already
[13:50:04 CEST] <JEEB> and it already has a thing to replace strok_r with strtok if someone is unfortunate enough to not have strtok_r
[13:51:24 CEST] <BtbN> it should be trivial to fix it up to use it everywhere
[13:51:58 CEST] <JEEB> yea
[13:52:22 CEST] <nevcairiel> unless the report in question was actually from a system that doesnt have strtok_r
[13:53:06 CEST] <JEEB> seemed to be just a usual GCC-based system
[16:42:08 CEST] <philipl> BtbN: thanks!
[19:37:06 CEST] <j-b> jamrial: so, around 270 lines? Not too bad.
[22:50:20 CEST] <philipl> BtbN, nevcairiel: Posted an updated patchset for the 444 stuff with expanded discussion of pix fmt situation. Let's please get a decision.
[23:26:33 CEST] <philipl> BtbN: thanks for reviewing
[00:00:00 CEST] --- Sun Oct 21 2018