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

[burek]

[03:46:36 CEST] <nkk> FFmpeg stops output whenever there is concealing error (or) circular buffer overflow
[03:46:46 CEST] <nkk> can anyone please help me
[10:14:17 CEST] <pross> durandal_1707: how is the new siren decoder?
[10:40:58 CEST] <durandal_1707> pross: nowhere due to very positive reviews
[11:44:08 CEST] <cone-038> ffmpeg 03Steven Liu 07master:76ef18fd3910: avutil/dynarry.h: fix comment grammar mistakes of FF_DYNARRAY_ADD
[13:00:58 CEST] <mkver> cehoyos: What do you think of my newest verson of the hcom patch?
[13:09:17 CEST] <cehoyos> I don't think it is as readable as "/* data_size = */ avio_rb32(s->pb);" or "avio_skip() /* data_size*/" (and I don't see while read_header() has to be optimized) but others may disagree
[13:09:33 CEST] <cehoyos> s/while/why
[14:46:10 CEST] <vtorri99978666> hello
[14:46:48 CEST] <vtorri99978666> i have cross compiled ffmpeg, targetting Windows, and i see several warnings about deprecated functions which are used
[14:47:03 CEST] <JEEB> if it's stuff within the FFmpeg repo itself, it's OK
[14:47:07 CEST] <vtorri99978666> are you interested in the complete log ?
[14:47:27 CEST] <JEEB> I mean, we know there are some parts still using deprecated things, but those will get fixed/removed after the deprecation period ends
[14:47:32 CEST] <JEEB> because otherwise it would not build
[14:48:50 CEST] <vtorri99978666> ha, ok
[14:49:00 CEST] <vtorri99978666> i understand
[14:51:26 CEST] <vtorri99978666> there are other warnings
[14:51:45 CEST] <vtorri99978666> %s format not known, or warning about signed oeverflow
[14:52:14 CEST] <vtorri99978666> comparison of unsigned with < 0
[14:52:56 CEST] <vtorri99978666> array subscript beyond array bounds
[14:55:14 CEST] <cehoyos> vtorri99978666: Where is the comparison of unsigned with <0?
[14:55:20 CEST] <cehoyos> The array subscript is a gcc bug
[14:55:59 CEST] <JEEB> I think the %s format thing is a problem in hlsenc I think? some weird ifdef in there
[14:59:40 CEST] <vtorri99978666> JEEB exactly
[14:59:52 CEST] <vtorri99978666> cehoyos yes
[15:00:23 CEST] <cehoyos> The comparison is in yes?
[15:05:12 CEST] <vtorri99978666> fds[i].fd < 0
[15:05:15 CEST] <vtorri99978666> cehoyos ^
[15:05:41 CEST] <cehoyos> Would you like to tell me the filename?
[15:06:16 CEST] <vtorri99978666> more annoying : x86_64-w64-mingw32-nm fails : file format not recognized
[15:06:50 CEST] <vtorri99978666> libavformat/os_support.c
[15:06:53 CEST] <vtorri99978666> cehoyos^
[15:07:59 CEST] <vtorri99978666> cehoyos line 248
[15:08:43 CEST] <cehoyos> fd is signed here, so I don't think this can be fixed
[15:17:16 CEST] <mkver> It could be fixed with #ifdefs if one knew exactly the systems for which fd is unsigned.
[15:19:35 CEST] <cehoyos> Sounds like a bad idea (not because of the ifdefs)
[15:21:07 CEST] <mkver> And why?
[15:23:42 CEST] <cehoyos> How would you know?
[15:25:00 CEST] <mkver> Maybe it is documented for these systems?
[15:25:31 CEST] <mkver> If it is not, then the approach is not feasible.
[16:13:57 CEST] <vtorri99978666> i don't know if some people are cross-compiling ffmpeg with minw-w64 but on my computer, it is working
[16:14:01 CEST] <vtorri99978666> just fyi
[16:14:23 CEST] <JEEB> yea I think we have that in FATE
[16:14:39 CEST] <JEEB> and I do it periodically to test my own patches and mpv etc
[16:15:01 CEST] <JEEB> http://fate.ffmpeg.org/
[16:15:05 CEST] <JEEB> you can ctrl+F mingw there
[16:15:27 CEST] <JEEB> there are both 32bit and 64bit builds being done
[16:25:48 CEST] <vtorri99978666> and  with how many external libraries ?
[17:21:11 CEST] <adrian_> anyone has experience compiling ffmpeg with clang before ? how does O3 performance compare to gcc ? I also tried ./configure --cc=clang --cxx=clang++ --enable-lto and it did not work.
[17:21:15 CEST] <adrian_> thanks !
[17:23:19 CEST] <cehoyos> wrong channel
[17:23:35 CEST] <adrian_> what is the right channel ? thanks 
[17:23:55 CEST] <cehoyos> "using" in the channel title includes "building"
[17:26:12 CEST] <adrian_> there are devel and non-devel channel 
[17:26:21 CEST] <adrian_> do you suggest i go ask in the non-devel channel 
[18:46:14 CEST] <JEEB> anyone here with FFmpeg built with gnutls? seems like we're failing at TLS with facebook
[18:47:20 CEST] <JEEB> so if you get a URL through f.ex. youtube-dl (f.ex "https://www.facebook.com/downshiftaus/videos/418766325569703/" was posted to me as an example), and then try opening it through lavf it seems to fail?
[18:47:48 CEST] <JEEB> open/libressl seems to work
[18:48:38 CEST] <JEEB> got a report that it works with the same gnutls through wget so it's likely to be in our TLS wrapper
[18:48:47 CEST] <JEEB> (if someone else can replicate it)
[19:01:43 CEST] <nevcairiel> i think i saw a patch for that
[19:02:03 CEST] <JEEB> ah
[19:02:11 CEST] <nevcairiel> https://patchwork.ffmpeg.org/patch/12492/ this probably
[19:02:56 CEST] <JEEB> cheers, will have it tested :)
[19:03:12 CEST] <nevcairiel> i should probably pick that as well
[19:05:20 CEST] <JEEB> > my wireshark cap shows that mpv terminates the connection right after it tries to change the cipher suite so this patch seems to be applicable to this situation
[19:05:39 CEST] <JEEB> so it seems like cipher suite reneg is one of those error cases
[19:29:35 CEST] <JEEB> nevcairiel: I can verify that patch fixes the issue
[19:30:02 CEST] <JEEB> -33
[19:30:20 CEST] <JEEB> > I just tested with badssl and it does correctly bail out with e.g. ./ffplay https://rc4.badssl.com/
[19:30:42 CEST] <JEEB> and that seems to be a fatal error so it seems like the patch's OK
[19:34:20 CEST] <durandal_1707> than kindly reply with LGTM
[19:35:50 CEST] <JEEB> yea, I am writing it down atm
[19:39:00 CEST] <JEEB> there
[19:42:27 CEST] <JEEB> I'll let people look at it a bit and possibly respond, and if there are no further comments I'll at least pull it into master since the loop more or less looks OK to me
[19:57:58 CEST] <cone-038> ffmpeg 03Marton Balint 07master:415886588fad: doc/filters: move reference to framesync options from lut3d to haldclut
[20:15:07 CEST] <JEEB> durandal_1707: btw have you checked what sort of threading makes sense with zscale? since I think as soon as the slices become smaller the perf benefits get smaller (if at all)?
[20:15:42 CEST] <JEEB> as in, should the amount of slices be limited by a minimum height per slice
[20:16:31 CEST] <durandal_1707> width
[00:00:00 CEST] --- Sun Jun  2 2019