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

[burek]

[01:39:08 CEST] <cone-912> ffmpeg 03Danil Iashchenko 07master:714da1fd898f: lavfi: Add boxblur_opencl filter
[02:23:33 CEST] <cone-912> ffmpeg 03Ruiling Song 07master:8b8b0e2cd26c: lavfi: add opencl tonemap filter
[02:23:34 CEST] <cone-912> ffmpeg 03Ruiling Song 07master:649d7ca47780: lavfi: make vf_colorspace use functions from colorspace.c
[04:36:00 CEST] <Compn> https://answers.microsoft.com/en-us/windows/forum/windows_10-networking-winpc/downloading-files-of-unrecognized-extensions-in/a193c9ae-6543-4029-8f1a-eb1cbafa720f
[04:36:02 CEST] <Compn> hah
[06:15:16 CEST] <atomnuker> jkqxz: what was I supposed to do to finish the vulkan patchset?
[06:15:27 CEST] <atomnuker> also could you please review the rest of the patches?
[08:05:21 CEST] <cone-532> ffmpeg 03Gyan Doshi 07master:deb9a04d5404: avformat/movenc: allow hdlr name field to be empty
[12:29:53 CEST] <January> Compn: it's really annoying that you have to have a microsoft account to check answers.microsoft.com
[12:45:16 CEST] <jdarnley> January: are you sure about that?  I can see that question and 3 replies.
[12:45:56 CEST] <January> jdarnley: doesnt let me past without loggin in
[12:46:41 CEST] <jdarnley> Shame.
[12:46:50 CEST] <jdarnley> > Also, it is best if you only download files, apps, and plugins from trusted sources to help protect your computer and your data on it. 
[12:46:57 CEST] <jdarnley> I trust ffmpeg more than MSFT
[12:48:35 CEST] <jdarnley> Typical user support rubbish.  "You are doing something you shouldn't be.  Please hold to sactioned actions.  Thank you."
[14:07:51 CEST] <KGB> [13FFV1] 15retokromer opened pull request #117: update link (06master...06patch-1) 02https://git.io/fWbil
[16:01:27 CEST] <mateo`> Hello there, i'm currently looking at the code handling the display matrices in lavf/mov.c: it looks like we apply the movie display matrix after the track display matrix, is it something said by the spec ?
[16:01:42 CEST] <mateo`> this behaviour has been introduced by 7010ebdf1ff7514fa505ff166fb60ce762a46b8b
[17:36:50 CEST] <cone-934> ffmpeg 03Rostislav Pehlivanov 07master:7062e4dbc824: hwcontext_internal: add ff_hwframe_map_replace
[17:36:51 CEST] <cone-934> ffmpeg 03Rostislav Pehlivanov 07master:a2613647c4f4: hwcontext_opencl: use ff_hwframe_map_replace()
[17:44:18 CEST] <atomnuker> grr, when will someone fix ffmpeg.c pre-skip handling
[17:44:19 CEST] <atomnuker> honestly
[17:44:30 CEST] <atomnuker> we're getting bugs opened once every few months
[17:44:34 CEST] <atomnuker> people are getting confused too
[17:45:05 CEST] <nevcairiel> patches go that way ->
[17:45:21 CEST] <atomnuker> don't tell me that as if I haven't tried!
[17:45:29 CEST] <atomnuker> I did try a year ago and I couldn't
[17:45:44 CEST] <nevcairiel> that guy claims it doesnt affect libopus, so what is that doing right
[17:46:29 CEST] <atomnuker> libopus handles preskip for you rather than using side data and letting users handle it
[17:46:54 CEST] <nevcairiel> doesnt the generic avcodec decoding code handle that anyway
[17:47:19 CEST] <atomnuker> no, I don't think so
[17:47:39 CEST] <nevcairiel> my avcodec decoder implementation definitely works though, and i dont have any manual handling of pre skip or endtrimming in my code
[17:47:47 CEST] <nevcairiel> no beepings
[17:48:00 CEST] <atomnuker> with that sample?
[17:48:02 CEST] <nevcairiel> but maybe ffmpeg.c specifically disables that for arcane reasons
[17:48:02 CEST] <nevcairiel> yea
[17:48:37 CEST] <atomnuker> I don't think its able to be disabled
[17:49:38 CEST] <nevcairiel> you can set AV_CODEC_FLAG2_SKIP_MANUAL to disable the automatic
[17:50:30 CEST] <atomnuker> well, ffmpeg.c doesn't set it
[17:51:23 CEST] <JEEB> I think ffmpeg.c fully looks at the starting timestamp, and if it's negative AND the output container (f.ex. wav) doesn't support negative timestamps it will laugh and start the whole thing at zero
[17:51:38 CEST] <JEEB> instead of skipping until zero PTS
[17:51:50 CEST] <nevcairiel> that might be possible
[17:52:20 CEST] <nevcairiel> although the decode.c logic seems to physically eat the samples
[17:54:15 CEST] <JEEB> ok, not sure then - I just remember that being how the ffmpeg.c behavior looked like 
[17:56:32 CEST] <atomnuker> btw jkqxz: do you have me on ignore or something?
[18:52:05 CEST] <Compn> January : really? lol
[18:52:18 CEST] <Compn> 11:56] <atomnuker> btw jkqxz: do you have me on ignore or something?
[19:07:39 CEST] <January> Compn: yeah it's super weird
[19:41:58 CEST] <cone-934> ffmpeg 03Carl Eugen Hoyos 07master:af1e70dd664e: lavc/dpx: Support 12-bit packing method b (msbpad).
[19:41:59 CEST] <cone-934> ffmpeg 03Carl Eugen Hoyos 07master:061e326b60ea: lavc/dpx: Support 10-bit packing method b (msbpad).
[22:11:29 CEST] <uau> an mpv crash that a user hit brought up that libsmbclient is not thread safe, and actually very likely to crash if used from multiple threads (it has global state that easily causes a crash if accessed from multiple threads)
[22:12:23 CEST] <uau> that makes its use in a library like ffmpeg especially questionable (since it'll conflict with libsmbclient use anywhere else in the program)
[22:27:46 CEST] <thardin> can it be plugged with mutexes?
[22:30:17 CEST] <uau> multiple uses of the ffmpeg avio layer could be fixed by a global mutex - but for a library that would not be a full solution, since the mutex could not affect uses elsewhere
[22:31:57 CEST] <thardin> just thinking a stop gap
[22:32:14 CEST] <thardin> better would of course be to fix libsmbclient
[22:33:17 CEST] <uau> for example even if mpv added a mutex workaround to make sure its own stream layer did not trigger the issue, ffmpeg using libsmbclient would likely still trigger the issue if someone tried to use a command like "mpv smb://file1.mkv --o=smb://file2.mkv"
[22:34:14 CEST] <uau> the --o means encoding the output, and since this uses ffmpeg encoders, it also uses avio output - so this would still likely cause a crash, since no one mutex would cover both the reading of file file1.mkv with mpv stream layer and writing of file2.mkv through ffmpeg
[22:35:56 CEST] <uau> looking at libsmbclient code, it seems to be a fairly thin wrapper around other samba code which does not have the thread-safety issue
[22:36:19 CEST] <uau> so from that perspective a fix should be pretty easy
[22:37:04 CEST] <uau> but on the other hand, it seems that the software i checked in debian all seems to depend on libsmbclient rather than using samba through any other API
[22:37:36 CEST] <uau> so maybe there could be some issues with the availability/standardization or whatever of the other samba libs?
[22:37:43 CEST] <JEEB> could be
[22:37:45 CEST] <uau> of course it could just be people being stupid too
[22:37:50 CEST] <JEEB> or that
[22:38:01 CEST] <JEEB> "I mean it's the client library, right?"
[23:05:37 CEST] <uau> actually it looks like libsmbclient actually implements a saner API with context variables, and internally uses that
[23:05:57 CEST] <uau> but then there's a old=compatibility wrapper that is a thin layer which adds the globals and makes it thread-unsafe
[23:06:04 CEST] <uau> and that wrapper is the only part exported???
[23:10:19 CEST] <uau> or do you have to use those weird get/set functions but can still access the functionality through those...
[23:15:15 CEST] <uau> ok seems that the ffmpeg implementation is just using the wrong API - you can access then context-using functions (though for some reason the public API hides them behind clumsy getter functions)
[23:17:59 CEST] <uau> smbc_open = smbc_getFunctionOpen(smb_context);
[23:18:24 CEST] <uau> smbc_open(smb_context, url, access, 0666);
[23:18:32 CEST] <uau> instead of current
[23:18:38 CEST] <uau> smbc_open(url, access, 0666);
[00:00:00 CEST] --- Fri Jun 22 2018