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

[burek]

[00:43:18 CEST] <cone-640> ffmpeg 03Michael Niedermayer 07master:8efaee3710ba: avformat/oggparseopus: Check that granule pos is within the supported range
[00:43:19 CEST] <cone-640> ffmpeg 03Michael Niedermayer 07master:ea791c080dd5: avformat/utils: Check bps before using it in a shift in ff_get_pcm_codec_id()
[01:03:52 CEST] <kierank> jamrial: oddly, no
[01:12:21 CEST] <jamrial> kierank: ok, going to push it then. thanks
[01:32:30 CEST] <cone-640> ffmpeg 03Felt, Patrick 07master:fce75131229b: avdevice/decklink_dec: Convert decklink input module to use codecpar
[01:34:49 CEST] <cone-640> ffmpeg 03foo86 07master:6c44696b3d50: avcodec/dca: add DTS Express (LBR) decoder
[03:12:08 CEST] <cone-640> ffmpeg 03James Almer 07master:b2244fa0a624: avcodec/rscc: check input buffer size for deflate mode
[03:17:15 CEST] <cone-640> ffmpeg 03James Almer 07release/3.0:8dce66d33d41: avcodec/rscc: check input buffer size for deflate mode
[03:34:01 CEST] <cone-640> ffmpeg 03Rodger Combs 07master:d645182227e8: lavfi/drawutils: support NV12 and NV21
[04:22:12 CEST] <cone-640> ffmpeg 03Chris Cunningham 07master:542f725964e5: libavformat/oggdec: Free stream private when header parsing fails.
[04:36:31 CEST] <cone-640> ffmpeg 03James Almer 07master:c8c14d0ffc51: aarch64/synth_filter: fix compilation
[09:39:36 CEST] <BtbN> Anyone with knowledge about h264, what could h264Config.outputBufferingPeriodSEI/outputPictureTimingSEI do? I'm getting some reports that enabling those causes propper CBR padding, which doesn't make much sense to me.
[09:40:06 CEST] <nevcairiel> it should just emit the SEIs, not change anything else
[09:40:28 CEST] <nevcairiel> or so the option names sound
[09:41:34 CEST] <BtbN> Yeah, that's what I think. But aparently, without it, in CBR mode, it causes CBR padding.
[09:41:53 CEST] <BtbN> Or disables CBR padding, rather.
[09:42:04 CEST] <BtbN> Is there any downside to just enabling it?
[09:42:20 CEST] <BtbN> Should just be a few extra fields in the bitstream?
[10:14:55 CEST] <nevcairiel> maybe it thinks to itself that without these SEIs its not a fully compliant CBR bitstream either way, so no point producing the CBR padding which is just overhead
[10:15:29 CEST] <BtbN> So can I safely just enable those flags, or do they cause issues in some modes?
[10:26:46 CEST] <nevcairiel> its probably fine if running in CBR, but who knows if something might barf on that
[10:52:44 CEST] <cone-199> ffmpeg 03Timo Rothenpieler 07master:3a9df7dfec89: avcodec/nvenc: Generate bufferingPeriod/pictureTiming SEI
[11:47:08 CEST] <atomnuker> michaelni: how come av_crc_init() wants a polynomial with the highest power stripped yet with !CONFIG_HARDCODED_TABLES av_crc_get_table() uses the standard representation?
[12:00:35 CEST] <kierank> atomnuker: are you sure it's using the standard representation
[12:02:14 CEST] <atomnuker> [AV_CRC_32_IEEE]    = { 0, 32, 0x04C11DB7 }, the polynomial is as it's defined
[12:03:15 CEST] <kierank> there's a leading 1 iirc
[12:03:49 CEST] <kierank> the polynomial is x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1.
[12:06:02 CEST] <atomnuker> huh, that x^32 power is missing from 0x04C11DB7
[12:06:35 CEST] <atomnuker> it's correct then
[12:07:07 CEST] <kierank> yes that's the point
[12:42:57 CEST] <michaelni> atomnuker, if it didnt then it would not be possible to use polynomes as large as the type (with uint32 31bit would be max, with uint64, 63 would be max)
[12:47:19 CEST] <atomnuker> michaelni: think it's possible to use av_crc with non-standard widths, like 18 bits?
[12:48:11 CEST] <atomnuker> because the polynomial I have is 18 bits
[12:48:57 CEST] <atomnuker> and that for (c = i, j = 0; j < 8; j++) loop in av_crc_init makes me suspicious that it assumes a power of two #bits for the polynomial
[12:54:05 CEST] <michaelni> atomnuker, it should work with non mod 8 bits, but someone needs to test if it actually does work, i just dont see why it wouldnt
[12:55:48 CEST] <michaelni> if you find a case that doesnt work, please tell me / provide a testcase that fails, im interrested to see / know 
[12:59:11 CEST] <wm4> nevcairiel: do you think we could use SRW locks on Windows to get non-leaking, statically initializable mutexes?
[13:00:45 CEST] <cone-199> ffmpeg 03Timo Rothenpieler 07master:c921ca9b5d27: avcodec/nvenc: Write buffPeriod/picTime SEI in both CBR modes
[16:13:52 CEST] <jamrial> nevcairiel: msvc doesn't like a struct in dca_lbr, can you look at it?
[16:15:17 CEST] <nevcairiel> this type of inline declaration and init is probably not supported
[16:15:32 CEST] <nevcairiel> looks odd from a style perspective as well
[16:16:13 CEST] <nevcairiel> i can try to rewrite it a bit later
[16:19:19 CEST] <cone-199> ffmpeg 03Diego Biurrun 07master:330177b50842: build: Group declarations for hw-accelerated de-/encoding separately
[16:19:19 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:ce3037ac8ee7: Merge commit '330177b508420a553083df94f22cbd5142de0f4a'
[16:19:43 CEST] <jamrial> nevcairiel: ok, thanks
[16:22:27 CEST] <jamrial> speaking of which, tried to write fate tests for them using the samples foo86 provided, and the difference between x87 and sse math was pretty big
[16:22:32 CEST] <jamrial> creating the ref pcm file with x87 then running fate with an sse build required a fuzz >250 to pass for the 5.1 sample
[16:22:59 CEST] <jamrial> whereas a fuzz of 1 was enough the mono and stereo samples
[16:23:05 CEST] <nevcairiel> that doesnt sound r ight
[16:23:21 CEST] <jamrial> lfe_iir_c() in dcadsp.c is at fault
[16:26:23 CEST] <nevcairiel> hm odd the msdn docs list such a type of declaration as valid
[16:26:31 CEST] <jamrial> nevcairiel: http://pastebin.com/U2WqhmGA see if you can reproduce it whenever you have time
[16:27:05 CEST] <jamrial> try initialialize the struct with { 0 } instead of { }?
[16:27:11 CEST] <nevcairiel> thats the first thing itried
[16:27:52 CEST] <nevcairiel> even removing the init still fails
[16:28:22 CEST] <nevcairiel> .. what doesnt it like
[16:30:36 CEST] <nevcairiel> oh i compiled and edited different files
[16:31:36 CEST] <nevcairiel> yeah changing the init to 0 helps
[16:32:11 CEST] <Daemon404> merging this test split hting is such tedium...
[16:32:58 CEST] <jamrial> Daemon404: as i said i can help you with the modules they don't have if you want
[16:35:11 CEST] <Daemon404> jamrial, sure can you work on that now?
[16:35:21 CEST] <Daemon404> im current going through and doing the ones that we do have
[16:35:26 CEST] <Daemon404> currently*
[16:35:32 CEST] <jamrial> yeah
[16:35:56 CEST] <cone-199> ffmpeg 03Hendrik Leppkes 07master:27506aceda81: avcodec/dca_lbr: explicitly initialize structs with zero
[16:36:17 CEST] <jamrial> create a branch in your github with your current work and i'll push there like we did for codecpar
[16:38:08 CEST] <Daemon404> jamrial, i dont have a branch
[16:38:10 CEST] <Daemon404> im mid merge
[16:38:20 CEST] <jamrial> ah
[16:38:42 CEST] <Daemon404> i dont have a list of stuff we do have but they dont
[16:38:45 CEST] <Daemon404> that would be helpful
[16:41:25 CEST] <jamrial> Daemon404: http://pastebin.com/d1SNA1vd
[16:42:21 CEST] <Daemon404> ... that is a lot
[16:42:37 CEST] <Daemon404> can you start work? you dont need a branch
[16:42:44 CEST] <Daemon404> just cp file.c file-test.c
[16:42:47 CEST] <Daemon404> and edit the two
[16:42:57 CEST] <Daemon404> the grunt work is what takes the longest
[16:46:21 CEST] <jamrial> alright
[17:29:09 CEST] <Daemon404> jamrial, finished the ones in the merge
[17:29:14 CEST] <Daemon404> shall i push it to a branch for you
[17:29:39 CEST] <jamrial> yeah
[17:29:54 CEST] <jamrial> i'm also done with libavutil modules
[17:30:23 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/tree/testprogs
[17:30:33 CEST] <Daemon404> please poke me when you are done
[17:30:54 CEST] <jamrial> looks like there's also some libavcodec testprogs we do that they don't
[18:10:45 CEST] <wm4> ubitux: more subtitle crap https://trac.ffmpeg.org/ticket/5539
[18:11:04 CEST] <ubitux> yep i had this one or a similar
[18:11:27 CEST] <ubitux> in the huge db of subs
[18:11:45 CEST] <ubitux> i saw some with just "->" too
[18:39:43 CEST] <jamrial> Daemon404: pushed
[18:47:57 CEST] <Daemon404> jamrial, ok cool
[18:48:01 CEST] <Daemon404> ill check after dinner
[19:40:00 CEST] <atomnuker> ping Gramner, look at PM whenever you have the time
[19:40:29 CEST] <kierank> Meh just post it in the channel
[19:40:42 CEST] <kierank> How can we make slow crc fast
[19:40:51 CEST] <atomnuker> https://0x0.st/NhF.c
[19:40:56 CEST] <atomnuker> the test program
[19:41:02 CEST] <atomnuker> ask me if someone needs a test file
[19:41:41 CEST] <iive> the kernel have a number of fast crc implementation, including ones using special instructions
[19:45:36 CEST] <kierank> slow crc is slow :(
[19:46:57 CEST] <jamrial> kierank: if you only need the standard crc32 to be fast, you could try to write an asm version using the sse4 crc32 instruction
[19:47:16 CEST] <kierank> Nope a special crc
[19:47:29 CEST] <jamrial> then dunno :p
[19:48:00 CEST] <kierank> atomnuker: https://matt.sh/redis-crcspeed
[19:48:11 CEST] <kierank> Looks similar to michaelni's approach
[19:48:12 CEST] <jamrial> make sure to set CRC_TABLE_SIZE to 1024 if  you're using a custom crc that's no defined in crc.h
[19:51:10 CEST] <atomnuker> yeah, that's michael's approach basically, extended to 32 bits
[19:52:13 CEST] <kierank> Might be doable for us except the interleaving hurts
[19:52:31 CEST] <atomnuker> sadly our crc is 18 bits wide and our data is 10, so can't fit 2 into the CRC
[19:53:58 CEST] <kierank> Might have to yasm it then for our big loop
[19:54:01 CEST] <kierank> Eugh
[19:54:55 CEST] <atomnuker> wouldn't work that well since we'd have to carry it over in a separate register between lines
[19:55:45 CEST] <Daemon404> jamrial, ok looking
[20:07:06 CEST] <Daemon404> jamrial, seems good
[20:07:08 CEST] <Daemon404> fate builds and passes
[20:07:53 CEST] <Daemon404> just doing a readthrough for e.g. copyright headers
[20:10:33 CEST] <jamrial> already fixed that in one of the commits i pushed
[20:11:06 CEST] <jamrial> at least those covered by fate-source
[20:11:30 CEST] <Daemon404> yeah i see that
[20:11:37 CEST] <rcombs> what's this CRC for anyway
[20:11:42 CEST] <rcombs> who uses an 18-bit CRC
[20:13:41 CEST] <cone-199> ffmpeg 03Diego Biurrun 07master:d12b5b2f135a: build: Split test programs off into separate files
[20:13:43 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:96d616052b3d: Merge commit 'd12b5b2f135aade4099f4b26b0fe678656158c13'
[20:14:49 CEST] <cone-199> ffmpeg 03Martin Storsjö 07master:798845ce7e5b: testprogs: Add missing libm.h includes
[20:14:50 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:4f173d055c3a: Merge commit '798845ce7e5b7fdd17c7269c5d267fb487d9c46f'
[20:15:31 CEST] <cone-199> ffmpeg 03Martin Storsjö 07master:b8e899f4bf5f: mmaldec: Use imgutils.h for copying frames
[20:15:32 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:f4c88eef95e6: Merge commit 'b8e899f4bf5f09900aa71552112d32a5566b6baf'
[20:17:07 CEST] <kierank> rcombs: hardware
[20:19:56 CEST] <cone-199> ffmpeg 03Martin Storsjö 07master:e8919ec486a5: libavcodec: Add H264/MPEG4 encoders based on OpenMAX IL
[20:19:56 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:0e3872322082: Merge commit 'e8919ec486a5559fdcf366e347be0656d904a87f'
[20:23:41 CEST] <cone-199> ffmpeg 03Martin Storsjö 07master:f1cd9b03f3fa: omx: Add support for broadcom OMX on raspberry pi
[20:23:42 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:e330ab0fb7cb: Merge commit 'f1cd9b03f3fa875eb5e394281b4b688cec611658'
[20:24:40 CEST] <cone-199> ffmpeg 03Martin Storsjö 07master:1bb56abb9b37: omx: Add support for zerocopy input of frames
[20:24:41 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:ec1d8abfb9bf: Merge commit '1bb56abb9b37bd208a66164339c92cad59b1087b'
[20:26:40 CEST] <cone-199> ffmpeg 03Martin Storsjö 07master:9d4d9be538fa: libavcodec: Document that encoders may use the framerate field in AVCodecContext
[20:26:42 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:75a1fc0376cc: Merge commit '9d4d9be538faa537440fff37d3b7ecf322911a55'
[20:39:28 CEST] <cone-199> ffmpeg 03Anton Khirnov 07master:d7abe900c3d3: FATE: add an H.264 test with invalid reference lists
[20:39:29 CEST] <cone-199> ffmpeg 03Anton Khirnov 07master:18019f8cb966: FATE: add an H.264 test with unescaped extradata
[20:39:30 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:bc3d2f25783a: Merge commit '18019f8cb9663dd1032c65aa453eaec18d641905'
[20:41:08 CEST] <cone-199> ffmpeg 03Mark Thompson 07master:f6b85523692b: vaapi_encode: Refactor slightly to allow easier setting of global options
[20:41:09 CEST] <cone-199> ffmpeg 03Mark Thompson 07master:6e8f66fc932b: vaapi_h264: Add constant-bitrate encode support
[20:41:10 CEST] <cone-199> ffmpeg 03Mark Thompson 07master:69b06ed42809: vaapi_encode: Add support for codec-local options
[20:41:11 CEST] <cone-199> ffmpeg 03Mark Thompson 07master:9629701ce9de: vaapi_h264: Add -qp option, use it to replace use of -global_quality
[20:41:12 CEST] <cone-199> ffmpeg 03Mark Thompson 07master:fcf536b13014: vaapi_h264: Add encode quality option (for quality-speed tradeoff)
[20:41:13 CEST] <cone-199> ffmpeg 03Mark Thompson 07master:f70e4627933b: vaapi_h265: Add constant-bitrate encode support
[20:41:14 CEST] <cone-199> ffmpeg 03Mark Thompson 07master:92fdea37477b: vaapi_h265: Add -qp option, use it to replace use of -global_quality
[20:41:15 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:8ed427f9f92f: Merge commit '92fdea37477b5a2d1329e5ef0773e24473fa8f12'
[20:41:19 CEST] <Daemon404> <_<;
[20:41:27 CEST] <JEEB> cone decided to spam
[20:42:58 CEST] <BBB> do we have a avfilter that gives me the dc per frame?
[20:43:10 CEST] <BBB> like, I want to detect dark and light scenes in a particular video
[20:45:32 CEST] <cone-199> ffmpeg 03Anton Khirnov 07master:5e1a3ea3ba7b: lavc: move the vaapi encoders further down in the list of codecs
[20:45:34 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:ed8bacfb5ca8: Merge commit '5e1a3ea3ba7bb0c71d931e93e60fb75f51b0cc1a'
[20:46:35 CEST] <cone-199> ffmpeg 03Anton Khirnov 07master:a0f469da744d: hwcontext: initialize sw_format in av_hwframe_ctx_alloc()
[20:46:37 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:c71c3b9ff4f1: Merge commit 'a0f469da744db83db32f3fe13186ee4aa2bc7dc5'
[20:46:41 CEST] <durandal_1707> BBB: dc is ?
[20:47:17 CEST] <Daemon404> dc coefficient
[20:47:18 CEST] <Daemon404> i assume
[20:51:04 CEST] <BBB> yes
[20:51:08 CEST] <BBB> but of the whole image, not 1 block
[20:51:18 CEST] <BBB> average of dc coefficients over whole image is fine also
[20:52:05 CEST] <durandal_1707> still dc is what? 
[20:53:27 CEST] <Daemon404> of the dct of the whole image
[20:55:00 CEST] <durandal_1707> not done.. I guess Dct stuff is only in lavc
[20:55:19 CEST] <kurosu_> why go through a dct, it's just average of pixels * constant
[20:55:50 CEST] <fritsch> thought exactly the same
[20:57:03 CEST] <kurosu_> isn't there an histogram filter or pixel stats or some such, with some post processing that might do it
[20:57:59 CEST] <kurosu_> but histogram is overkill compared to psadb + paddd over an image
[21:09:40 CEST] <cone-199> ffmpeg 03Michael Niedermayer 07master:bf29794022db: avcodec/dca_lbr: Fix "warning: missing braces around initializer"
[21:09:40 CEST] <cone-199> ffmpeg 03Christophe Gisquet 07master:9ca16bdd3f04: lossless audio dsp: unroll
[21:23:55 CEST] <michaelni> Daemon404, "make testprogs" is broken
[21:24:26 CEST] <michaelni> make: *** [libavfilter/drawutils-test] Error 1
[21:24:27 CEST] <michaelni> make: *** [libavcodec/avfft-test.o] Error 1
[21:28:05 CEST] <Daemon404> checking
[21:28:36 CEST] <michaelni> avfft is just a missing include mem.h
[21:28:50 CEST] <Daemon404> michaelni, does fate not build these programs?
[21:28:59 CEST] <michaelni> apparently not
[21:29:03 CEST] <michaelni> make fate passed here
[21:29:06 CEST] <Daemon404> yeah same
[21:29:12 CEST] <Daemon404> i thought fate would have built them all
[21:29:14 CEST] <Daemon404> guess not...
[21:33:05 CEST] <michaelni> "make check" should run "all alltools examples testprogs fate"
[21:33:29 CEST] <Daemon404> was not aware of that before
[21:37:06 CEST] <jamrial> drawutils should be added to fate, i guess
[21:37:45 CEST] <jamrial> like every other testprog
[21:38:17 CEST] <Daemon404> jamrial, looks like it wasnt converted
[21:38:24 CEST] <Daemon404> because we didnt see it in fate
[21:38:37 CEST] <jamrial> yeah
[21:39:35 CEST] <jamrial> i wonder why it's part of testprogs but was never added to fate, like avfilter's formats
[21:41:34 CEST] <Daemon404> no idea
[21:44:12 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:64fbf2f03e4e: avfft-test: Add missing mem.h include
[21:44:13 CEST] <cone-199> ffmpeg 03Derek Buitenhuis 07master:f693184557e4: Split drawutils test out into separate file
[21:44:15 CEST] <Daemon404> michaelni, fixed
[21:44:31 CEST] <Daemon404> testprogs works
[21:44:57 CEST] <michaelni> thx
[22:05:26 CEST] <mateo`> sorry for the mistake in my email, the neon version of the resampling function is actually faster.
[22:27:05 CEST] <fritsch> https://bugzilla.gnome.org/show_bug.cgi?id=766050#c5 <- gb is alive - nice :-)
[22:29:32 CEST] <wm4> just not interested in ffmpeg anymore
[22:30:13 CEST] <fritsch> don't think so ...
[00:00:00 CEST] --- Thu May 12 2016