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

[burek]

[02:34:26 CEST] <cone-427> ffmpeg 03Michael Niedermayer 07master:78f6ec32a372: avformat/avidec: Fix txts fmts parsing
[02:34:26 CEST] <cone-427> ffmpeg 03Michael Niedermayer 07master:a5d849b149ca: avformat/avidec: Limit formats in gab2 to srt and ass/ssa
[02:34:26 CEST] <cone-427> ffmpeg 03Michael Niedermayer 07master:edf686f089d6: tests/fate/libavcodec: Test with all idct and dct modes supported in the test
[08:14:04 CEST] <nadermx> so if I was to change the order of this line https://github.com/FFmpeg/FFmpeg/blob/a51867ee6bc717a54ea2436e31ee626f02fdf25d/libavformat/mp3enc.c#L582  and moved it to this line https://github.com/FFmpeg/FFmpeg/blob/a51867ee6bc717a54ea2436e31ee626f02fdf25d/libavformat/mp3enc.c#L621 would in theory fix the problem since it would then write the header before it starts the mp3, or am I missing something
[11:10:04 CEST] <wm4> nevcairiel: a user is getting "Unable to decrypt message" with tls_schannel.c, any idea what could cause this?
[11:11:58 CEST] <wm4> getting this somewhere around when a new connection is opened
[11:12:15 CEST] <wm4> well, shortly after opening
[11:14:07 CEST] <nevcairiel> maybe it should log the error code for debuging purposes
[11:17:51 CEST] <nevcairiel> using schannel is q uite involved so i'm not discounting that there is a bug in there somewhere
[11:21:47 CEST] <wm4> nevcairiel: like this? http://sprunge.us/ODTQ
[11:23:12 CEST] <nevcairiel> what type is SECURITY_STATUS anyway
[11:23:16 CEST] Action: nevcairiel looks it up
[11:24:15 CEST] <nevcairiel> its long
[11:24:17 CEST] <nevcairiel> interesting
[11:25:46 CEST] <nevcairiel> i keep forgetting the rules, is it ok to cast a negative signed integer to unsigned and expect the bit patterns to just translate over?
[11:26:27 CEST] <wm4> *shrug*
[11:27:00 CEST] <nevcairiel> apparently it is
[11:27:06 CEST] <nevcairiel> so its probably ok
[11:29:59 CEST] <nevcairiel> for work I just decided to use gnutls on all platforms, its so extremely trivial to use compared to schannel (also, making  2-3 implementations didnt sound like fun)
[11:30:55 CEST] <wm4> gnutls is generally a pain to build
[11:31:04 CEST] <wm4> schannel has worked pretty well so far
[11:31:09 CEST] <nevcairiel> it was ok
[11:31:24 CEST] <wbs> openssl is even worse in one way though, majorly custom build system there
[11:31:32 CEST] <wbs> (but that's not really an option for redistribution either)
[11:31:38 CEST] <nevcairiel> i should thank wbs for pushing all sorts of projects to support gnutls/nettle instead of gcrypt, i found various patches or comments from him while dealing with this =p
[11:31:51 CEST] <wbs> \o/
[11:32:34 CEST] <wbs> well it was mostly gnutls themselves that did the push. a lot of users of gnutls had to be updated to work properly when the backend changed though; IIRC I patched curl for this case at least
[11:32:55 CEST] <wbs> (all that kind of downstream users of gnutls would have had to make the same change sooner or later in any case though)
[11:32:57 CEST] <nevcairiel> from the top of my head i at least remember curl and librtmp
[11:33:06 CEST] <wbs> ah, right, librtmp as well
[11:34:59 CEST] <nevcairiel> we actually shipped both nettle and gcrypt for a while because the person who set this up didnt really know better, so was nice to clean this all up and unify it all into nettle
[11:36:12 CEST] <wbs> setting up thread safety with gcrypt is a pain, although gnutls started abstracting that away at some point also (probably in the preparation for making their backend switchable)
[12:18:35 CEST] <cone-787> ffmpeg 03wm4 07master:016023038217: videotoolbox: log errors
[12:18:35 CEST] <cone-787> ffmpeg 03wm4 07master:3da13fd6acea: avformat/tls_schannel: log unknown error codes
[12:58:46 CEST] <nevcairiel> man pushing sure has become slow
[12:58:55 CEST] <cone-787> ffmpeg 03Martin Storsjö 07master:47c43ce36f0c: configure: Fix the msvcrt version check for mingw32
[12:59:59 CEST] <wm4> yes it has
[13:02:13 CEST] <nevcairiel> should probably push that into 3.3 as well eh
[13:04:42 CEST] <cone-787> ffmpeg 03Martin Storsjö 07release/3.3:1cbeb16187c8: configure: Fix the msvcrt version check for mingw32
[13:21:40 CEST] <pross_> sdf
[13:21:57 CEST] <pross_> wrong window ah
[15:21:44 CEST] <ubitux> we can make ps_hybrid_analysis so simple with simd it's crazy
[15:24:29 CEST] <wm4> michaelni: would you consider fixing the timestamp logic in libavformat for h264 streams, which put the second field into their own packet (which AFAIK most containers prefer)? I think utils.c's logic breaks because it assumes one full frame per packet, so it assumes that the codec delay can be applied to packets directly (to me it looks like the packet delay is variable and depends which picture structures it contains)
[15:36:31 CEST] <michaelni> wm4, i can look into it if i have a testcase for ffmpeg or ffplay. Might take a bit of time before ill look at it though, there seems an eternal stream of work i should work on
[15:44:43 CEST] <wm4> I'll look for a sample, though it hsppens with common-place TV broadcast streams
[15:47:48 CEST] <cone-787> ffmpeg 03Stefano Sabatini 07master:002dbc5a1f2a: examples/encode_video: add log
[15:47:49 CEST] <cone-787> ffmpeg 03Stefano Sabatini 07master:ddae67945854: examples/encode_video: slightly improve error reporting
[16:15:27 CEST] <cone-787> ffmpeg 03Michael Niedermayer 07master:58f8cd4ac576: avcodec/cavsdec: Fix runtime error: signed integer overflow: 59 + 2147483600 cannot be represented in type 'int'
[16:15:29 CEST] <cone-787> ffmpeg 03Michael Niedermayer 07master:a1c0d1d906d2: avcodec/pnm: Use ff_set_dimensions()
[16:15:29 CEST] <cone-787> ffmpeg 03Michael Niedermayer 07master:08cb69e870c1: avcodec/ra144: Fixes runtime error: signed integer overflow: 7160 * 327138 cannot be represented in type 'int'
[17:27:22 CEST] <kwizart> hello, is there any releases schedule for ffmpeg branches (like what is done in the kernel for long time branch and EOL branches ?)
[17:27:41 CEST] <kwizart> specifically asking for any ffmpeg 2.8.x
[17:29:48 CEST] <BtbN> every once in a while a new one is made, if it's worth it
[17:30:06 CEST] <BtbN> if no issues come up, or the release is too old to be maintained, none will come out anymore
[17:32:16 CEST] <nevcairiel> new major relases are generally scheduled every 3 month, but depending on state of development that can slip - point releases in the branches are done on as-needed basis, and branches are dropped mostly when they get way too old and/or noone is really shipping it anymore
[17:49:45 CEST] <jamrial> kwizart: 2.8.12 should be tagged/released soon
[17:50:31 CEST] <jamrial> but in any case, you should consider upgrading to a newer version. 2.8 is pretty old by now
[17:57:11 CEST] <kwizart> jamrial, thx, this is distro maintainer here (RPM Fusion for el/fedora), so newer releases are on ffmpeg 3.3
[18:40:31 CEST] <wm4> michaelni: sample, try remuxing to mkv, and once that works, remuxing mkv->mkv again: https://drive.google.com/file/d/0B3_rFvUatlX3QUpsUnM5REtmOXM/view (sorry for the shitty file hoster)
[18:41:04 CEST] <wm4> I think for the initial ts->mkv remuxing I have a half-baked shithack
[18:57:31 CEST] <durandal_1707> happy birthday
[19:52:10 CEST] <kierank> durandal_1707: thanks
[20:03:04 CEST] <J_Darnley> Does anyone have a tip for how I can force nasm to properly create "m %+ (8+i)"?
[20:03:37 CEST] <J_Darnley> It ends up as m(8+0) though m(8+7)
[20:11:08 CEST] <BtbN> was libnut recently removed from master or something?
[20:11:49 CEST] <J_Darnley> I saw the patch on the ml, so probably it was applied if you're having some trouble.
[20:11:53 CEST] <RiCON> it was
[20:11:56 CEST] <BtbN> https://travis-ci.org/FFmpeg/FFmpeg-Coverity/builds/238027709?utm_source=email&utm_medium=notification
[20:12:40 CEST] <BtbN> Guess I can remove schroedinger as well
[20:21:18 CEST] <Gramner> J_Darnley: try "%assign %%tmp i+8", then "m %+ %%tmp"
[20:21:47 CEST] <J_Darnley> Ah, basically work around the problem
[20:22:51 CEST] <Gramner> well, it'd be more like working within the boundaries of the preprocessor expansion rules I guess
[20:23:16 CEST] <Gramner> and preprocessor expansion rules always suck
[20:23:25 CEST] <J_Darnley> :)
[20:23:32 CEST] <J_Darnley> Well, that seems to work
[20:33:36 CEST] <BBB> J_Darnley: uh, thats tricky stuff, have you considered asking gramner or loren?
[20:34:09 CEST] <BBB> J_Darnley: you probably need to use xdefine or assign to explicitly generate the variable before concatenating it
[20:34:20 CEST] <BBB> J_Darnley: I believe xdefine can do it, but gramner/pengvado would know for sure
[21:29:01 CEST] <BBB> J_Darnley: have you looked at simple_idct10_template.asm?
[21:30:12 CEST] <BBB> J_Darnley: so, first of all, I wouldnt necessarily reuse the code from the assembly you wrote earlier. its not that its bad code, but its highly optimized for a specific case where you do 4 coefficients per register (mmx) and then loop twice to get both halves of the transform finished
[21:30:35 CEST] <BBB> J_Darnley: its really optimized for that case, but as such not very useful as a template for a full transform where we can do all coefs in a single reg pass (xmm)
[21:31:22 CEST] <BBB> J_Darnley: simple_idct10_template.asm deals with the assumptions that were 64bit (>8 regs), can do all coefs in a single reg (16byte/xmm) and unfortuantely is 10-bit only right now
[21:31:35 CEST] <BBB> J_Darnley: but as such it may be a good template for writing a xmm 8bit also
[21:31:39 CEST] <BBB> (or at least example)
[22:09:03 CEST] <thardin> one full week of fuzzing subtitles, no crashes uncovered
[22:51:01 CEST] <J_Darnley> BBB: Thanks.  I didn't thibk to look at the 10 bit assembly
[22:51:12 CEST] <J_Darnley> *think
[22:51:38 CEST] <BBB> its not immediately obvious that the two are related :)
[22:52:15 CEST] <J_Darnley> I should know better.  I've done the same h264 functions for both 8 and 10 bit
[22:53:07 CEST] <BBB> i think youre being too hard on yourself atm...
[23:16:22 CEST] <cone-347> ffmpeg 03Michael Niedermayer 07master:6726328f7940: avcodec/hevc_ps: Fix runtime error: signed integer overflow: 2147483628 + 256 cannot be represented in type 'int'
[23:16:22 CEST] <cone-347> ffmpeg 03Michael Niedermayer 07master:e47057e932ff: avcodec/cinepak: Check input packet size before frame reallocation
[23:16:22 CEST] <cone-347> ffmpeg 03Michael Niedermayer 07master:a47273c803ed: avcodec/wavpack: Fix runtime error: signed integer overflow: 2013265955 - -134217694 cannot be represented in type 'int'
[00:00:00 CEST] --- Thu Jun  1 2017