[00:02:06 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07release/2.4:4dc0fbb13c33: x86: cavs: Remove an unneeded scratch buffer [00:02:07 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07release/2.4:e4e64f2fea0a: avcodec/x86/cavsdsp: remove unneeded tmp [00:02:08 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07release/2.4:95cf5e83a750: Merge commit '4dc0fbb13c33b4e5bdb766652f4daf900ccc952f' into release/2.4 [00:26:53 CEST] <cone-741> ffmpeg 03Roman Savchenko 07master:e85d91da48cf: avformat/avienc: Correct possible dereference of null [01:47:13 CEST] <llogan> michaelni: isn't flac lpc_coeff_precision range from 0-15, not 1-15 as mentioned in your recentish flac doc commit? i can fix if it is incorrect [01:53:40 CEST] <michaelni> llogan, i think 0 is not valid [01:54:25 CEST] <llogan> i just noticed it when looking at "ffmpeg -h encoder=flac" [01:56:32 CEST] <cone-741> ffmpeg 03Roman Savchenko 07master:e5d1152ccc30: avcodec/mpegvideo: Check pointer when allocation fail [01:56:33 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:d860084c50c3: avcodec/mpegvideo: Reset bitstream_buffer_size on allocation failure [01:56:34 CEST] <cone-741> ffmpeg 03Hendrik Leppkes 07master:b7a0b303d982: dxva2_hevc: fix 32x32 scaling lists [01:57:40 CEST] <michaelni> llogan, its stored as x-1 so 0 cant be stored [02:03:18 CEST] <llogan> i guess i was confused...as per tradition. [02:03:51 CEST] <llogan> got to go pick up the mutt... [02:31:30 CEST] <rcombs> michaelni: wm4: hmm, do we want to turn on verification by default for Secure Transport? [02:32:05 CEST] <rcombs> I figured we'd want to leave it off until Win32, Linux, and OS X can all do it reliably, but I don't have a particularly compelling reason for that [03:21:34 CEST] <michaelni> rcombs, when / how often does verification fail ? [03:21:51 CEST] <michaelni> its safer to leave it on and give the user the option to turn it off [03:22:39 CEST] <rcombs> michaelni: verification fails if the server presents an untrusted certificate [03:23:17 CEST] <rcombs> your browser, e.g., would respond to that situation by refusing to continue the connection, or possibly prompting the user for permission to continue insecurely [03:23:43 CEST] <michaelni> yes, we should do similarly IMO [03:23:47 CEST] <Daemon404> i wager youll have angry users if you outright fail [03:24:02 CEST] <rcombs> there'd still be an option to turn it off either way [03:24:22 CEST] <Daemon404> sure but it means that the 3 have different default behavior [03:24:25 CEST] <rcombs> just like in your browser, except you have to set it at the CLI instead of being prompted about it [03:24:30 CEST] <Daemon404> platform specific no less [03:24:33 CEST] <rcombs> yeah, that's my vague concern [03:24:43 CEST] <Daemon404> a lot of peopel dev on os x, deploy on linux [03:24:46 CEST] <Daemon404> (unfortunately) [03:24:56 CEST] <rcombs> I think we should definitely do this when we've got verification working reliably everywhere [03:25:15 CEST] <rcombs> ("verification working reliably" means "we can reliably find a list of trusted CAs") [03:25:30 CEST] <michaelni> yes, the CAs must eb found [03:25:56 CEST] <rcombs> that's what most other CLI/library software with TLS support does [03:26:38 CEST] Action: Daemon404 thinks the concept of CAs is stupid anyway [03:26:45 CEST] Action: Daemon404 puts on his tinfoil hat [03:26:51 CEST] <rcombs> Daemon404: you're not wrong [03:27:10 CEST] <rcombs> but CA verification is probably better than no verification [03:27:47 CEST] <rcombs> I've got that patch to add a CA bundle search very similar to curl's, so that should get us to the same point there as OS X [03:28:19 CEST] <rcombs> that just leaves Windows, for which an schannel tls.c implementation is required [03:28:51 CEST] <Daemon404> i think it shouldnt be too hard if you look how curl does it [03:29:15 CEST] <Daemon404> curl code is probably a better doc than msdn when it comes to schannel... [03:29:22 CEST] <rcombs> yeah (I referenced curl for the securetransport one as well) [03:29:44 CEST] <rcombs> but rcombs and Win32 go together like oil and water [03:30:26 CEST] <rcombs> so I'm standing over here hoping someone else handles that bit [03:31:01 CEST] <Daemon404> i was planning to revive my nss patch [03:31:08 CEST] <Daemon404> but NSPR is so crap i might not [03:36:42 CEST] <cone-741> ffmpeg 03Hendrik Leppkes 07master:c7bd6a54af1b: dxva2_hevc: re-write reference frame handling [09:45:59 CEST] <j-b> 'morning [09:50:01 CEST] <durandal_1707> good morning [11:03:03 CEST] <thardin> are there any players that do gapless playback? [11:04:27 CEST] <thardin> vlc doesn't seem able to [11:09:01 CEST] <wm4> mpv can in theory, for audio files [11:21:50 CEST] <thardin> gotta give that a shot then [11:22:20 CEST] <TimNich> thardin: are you only interested in audio? [11:31:32 CEST] <cone-788> ffmpeg 03Martin Storsjö 07master:78efc69e7c99: rtmpdh: Make sure ret is initialized in the nettle version of bn_hex2bn [11:31:33 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:392832fc3ab1: Merge commit '78efc69e7c990226f4b913721ef1b308ca5bfa04' [11:34:17 CEST] <thardin> TimNich: well, I see no reason to make it work for both [11:34:42 CEST] <thardin> at my new work we made a system that does this for all media. out of necessity really, but still [11:35:14 CEST] <TimNich> istr that clementine and amarok have a gapless setting, thats all. [11:35:37 CEST] <thardin> it's not hard to spin off a pthread that does all probing and sets of conversion buffers etc beforehand [11:36:12 CEST] <TimNich> what to do about padded frames at the end though? [11:36:37 CEST] <nevcairiel> the format needs to support gapless playback and indicate metadata for those, otherwise you can do what you want and it will never be perfect [11:37:08 CEST] <nevcairiel> of course you can try anyway and hope the padding isnt too obvious =) [11:38:01 CEST] <thardin> well, start with formats that can do sample precise stuff ofc [11:38:18 CEST] <thardin> but even with mp3 and such you can still cut stuff so the blocksize doesn't become an issue [11:38:34 CEST] <cone-788> ffmpeg 03Martin Storsjö 07master:127d813bcb57: rtmpdh: Fix a local variable name in the nettle/gcrypt codepath [11:38:35 CEST] <cone-788> ffmpeg 03Martin Storsjö 07master:9f1b3050d9e3: rtmpdh: Check the output buffer size in the openssl version of dh_compute_key [11:38:36 CEST] <cone-788> ffmpeg 03Martin Storsjö 07master:0508faaa11bf: rtmpdh: Pass the actual buffer size of the output secret key [11:38:37 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:4c0b30b07a81: Merge commit '127d813bcb5705202b7100cf1eccd1e26d72ba14' [11:38:38 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:beecbe13a2ea: Merge commit '9f1b3050d9e31e9283d818f3640f3460ac8cfb5b' [11:38:39 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:fbeb3fa999e8: Merge commit '0508faaa11bf7507ffdd655aee57c9dc5a8203f4' [11:38:57 CEST] <thardin> say if you're dumping CDs or vinyl to raw wave, then cutting them up [11:39:43 CEST] <nevcairiel> well if you control the encoding anyway, might as well just write the metadata [11:40:05 CEST] <thardin> that too. mp3 has stuff for that nowadays, right? [11:42:02 CEST] <nevcairiel> it does [11:45:23 CEST] <thardin> I guess I'll look into it if I get around to messing around with that stuff [11:45:34 CEST] <wm4> yeah, I even implemented it for lavf (decoding only) [11:50:12 CEST] <cone-788> ffmpeg 03Martin Storsjö 07master:063f7467e4d1: rtmpdh: Add fate test for the DH handshake routine [11:50:13 CEST] <cone-788> ffmpeg 03Martin Storsjö 07master:8016a1bd3b60: rtmpdh: Remove an unnecessary check in the gcrypt/nettle dh_compute_key [11:50:14 CEST] <cone-788> ffmpeg 03Martin Storsjö 07master:e9e86d9ef637: rtmpdh: Create sufficiently long private keys for gcrypt/nettle [11:50:15 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:48e02e258c42: Merge commit '063f7467e4d14ab7fe01b2845dab60cc75df8b53' [11:50:16 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:42a6a3841868: Merge commit '8016a1bd3b60e917e1b12748dd80c06c3462c286' [11:50:17 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:4b8b3efb1e40: Merge commit 'e9e86d9ef637f5a600c76b352ffe5a82b71b25d1' [12:16:51 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:e1b001956843: avformat/mov: Avoid float usage in yuv_to_rgba() [12:30:53 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:3331213e2ac5: avformat/concatdec: Enable auto_convert by default [12:53:15 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:14bc57044224: avformat/movenc: avoid floats in width/height/aspect ratio computations [13:07:44 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:061a592b9cb0: avformat/movenc: Check that track_width_1616 fits within the available 32bit before storing it [13:07:45 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:f86e7c5d00cc: avcodec/ac3_parser: Avoid floats in bitrate computation [14:14:25 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:403940de241e: avcodec/mpegvideo: Use FFSWAP to exchange pointers [17:01:07 CEST] <rcombs> anyone know if AUD NALs should be inserted when muxing HEVC in MPEG-TS? [17:50:51 CEST] <Timothy_Gu> nevcairiel: do you know why http://fatebeta.ffmpeg.org/log/x86_32-msvc11-windows-native/20150529110728/c... has so many weird warnings? [17:51:24 CEST] <nevcairiel> thats from the pre-processor [17:51:30 CEST] <nevcairiel> just ignore any warnings in that build [17:51:43 CEST] <Timothy_Gu> What do you mean? [17:52:14 CEST] <Timothy_Gu> Do we preprocess sources separately? [17:52:20 CEST] <nevcairiel> vs2012 needs a special pre-processor to mangle the source so it can compile it [17:52:26 CEST] <nevcairiel> it doesnt produce the cleanest code in the world [17:52:38 CEST] <nevcairiel> it lines headers for example [17:52:41 CEST] <nevcairiel> inlines* [17:52:45 CEST] <Timothy_Gu> oh yeah c99toc89 [17:52:54 CEST] <nevcairiel> vs2013 compiles without that [17:52:56 CEST] <Timothy_Gu> okay that makes sense [17:53:02 CEST] <nevcairiel> once vs2015 is out, i'll probably shut down the 2012 box [19:16:29 CEST] <BBB> omg poor souls that still use c99toc89 [19:21:14 CEST] <Compn> pretty smart way to avoid having to fork c89 code, just make a script to convert it all first [19:39:31 CEST] <cone-028> ffmpeg 03Andreas Cadhalpun 07master:153639cb9cfa: mov: fix DTS calculation for samples with negative stts duration [20:12:42 CEST] <philipl> nevcairiel: Your fix didn't help my code pass the scaling list samples, but I suspect I've got a separate problem that's messing those up. [20:13:45 CEST] <philipl> I'm looking at the RPS samples right now, and I see something particularly weird. Taking the RPS_A sample specifically, I end up decoding the second frame as *identical* to the first. As in, I save all frames as pngs from ffmpeg and they have the same md5 sum. [20:14:24 CEST] <philipl> I can verify that they have different vdpau surfaces associated with them, so I don't think that's the problem. [20:14:53 CEST] <philipl> And of course, past that point everything looks wrong for unsurprising reasons. [20:27:13 CEST] <BBB> Compn: well, yeah, Im one of the crazies that wrote it ;) [20:27:17 CEST] <BBB> Compn: I still feel bad about it [20:27:43 CEST] <BBB> Compn: about as bad as I feel about having copied mplayer (or was it xine? dont remember)s dll loader and make a gstreamer plugin out of it >10 yrs ago [20:28:14 CEST] <BBB> that was before I learned how to RE :-p [20:34:03 CEST] <cone-028> ffmpeg 03Nedeljko Babic 07master:e374405d8e82: libavutil: Cosmetic changes to fixed_dsp file. [20:54:27 CEST] <cone-028> ffmpeg 03Ingo Brückl 07master:083b1a32d530: build: add configure option pkgconfigdir [21:30:59 CEST] <cone-028> ffmpeg 03Michael Niedermayer 07master:bedb5d587b5f: configure: Fix showcqt fft dependancy [22:05:44 CEST] <cone-028> ffmpeg 03Rodger Combs 07master:f24d92badadc: lavf/tls: Support Secure Transport [22:51:39 CEST] <Compn> BBB : just think how many people were helped by your work and forget how hacky it is :P [22:54:19 CEST] <BBB> I fear for their sanity [22:55:21 CEST] <nevcairiel> the more important fact is that the mere existance of that tool may have played a part in the next msvc version supporting enough c99 to build it ouf of the box [22:58:29 CEST] <BBB> yeah, thats a nice thought... [22:58:33 CEST] <BBB> I hope its true [22:58:43 CEST] <BBB> will be impossible to prove, but ohwell [22:58:55 CEST] <nevcairiel> j-b likes to believe it [22:59:29 CEST] <BtbN> The C99 to C89 converter, or what tool? [22:59:39 CEST] <nevcairiel> yes [23:10:45 CEST] <wm4> rcombs: nice [23:14:58 CEST] <rcombs> \o/ [00:00:00 CEST] --- Sat May 30 2015