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

[burek]

[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/compile 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