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

[burek]

[00:00:58 CET] <cone-319> ffmpeg 03Michael Niedermayer 07master:b910c6ca562a: configure: fix zlib dependancy of tdsc
[00:00:59 CET] <cone-319> ffmpeg 03Michael Niedermayer 07master:b14de8e6895c: avcodec/utils: use atomic operations on entangled_thread_counter
[01:48:31 CET] <cone-319> ffmpeg 03Michael Niedermayer 07master:e16592c42e87: swresample/resample: Fix undefined shifts
[04:42:43 CET] <cone-319> ffmpeg 03Andreas Cadhalpun 07master:7b05b5093ea6: ac3dec_fixed: always use the USE_FIXED=1 variant of the AC3DecodeContext
[11:43:10 CET] <michaelni> Timothy_Gu, how is the fate server rewrite going ? do you maybe want to mentor in GSoC a project to finish it ? I kind of miss the ability to show results specific to a branch like release/1.2 in the current fate we are using
[11:56:23 CET] <kurosu_> michaelni, I'm on the eac3 stuff, found a first error, but the numbers still don't make sense compared to the float values, so I'm continuing
[11:57:55 CET] <kurosu_> also 5.1 is still completely screwy
[11:59:11 CET] <michaelni> i had tested with csi_miami_stereo_128_spx.eac3 yesterday and things looked reasonable didnt think 5.1 would be different
[11:59:50 CET] <kurosu_> unless I got the command-line wrong or tiny_psnr has an issue, the same sample in 5.1 is garbage
[12:08:23 CET] <kurosu_> there's actually an out-of-bound read in that code
[12:35:44 CET] <kurosu_> fixed for stereo, maxdiff down to 1 and stddev to 0.12
[12:50:22 CET] <kurosu_> michaelni, also fixes 5.1 cases
[12:50:25 CET] <kurosu_> *case
[13:05:46 CET] <ramiro> Timothy_Gu, aren't you still a student? you could probably apply for gsoc as well
[13:12:25 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:c3bf52713a84: x86: xvid_idct: port MMX iDCT to yasm
[13:12:37 CET] <nevcairiel> FP is a confusing term to  use
[13:12:42 CET] <nevcairiel> Floating Point .. Fixed Point .. FP
[13:12:43 CET] <nevcairiel> :d
[13:13:22 CET] <ubitux> FfmPeg
[13:27:11 CET] <Daemon404> nevcairiel, i always read it as functional programming...
[13:53:08 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:4eb4451be191: x86: dct-test: fix compilation for prores
[13:53:09 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:8200575d8494: x86: dct-test: evaluate prores idct avx version
[13:53:10 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:decd5193e1d4: x86: xvid_idct: merged idct_put SSE2 versions
[13:53:11 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:15ce160183c6: x86: xvid_idct: SSE2 merged add version
[14:26:38 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:b0834400608b: ac3_fixed: fix out-of-bound read
[14:26:39 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:c4bf3833f466: ac3_fixed: fix computation of spx_noise_blend
[14:26:40 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:0c3339f4bd7a: eac3dec: fix scaling
[14:41:15 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:4f53eaaafa2d: ffmdec: limit the backward seek to the last resync position
[14:41:16 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:313492c0bd69: avcodec/options_table: remove extradata_size from the AVOptions table
[14:41:17 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:e407615129a5: roqvideoenc: set enc->avctx in roq_encode_init
[14:41:18 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:f8bb156fa1f8: avcodec/012v: Check dimensions more completely
[14:41:19 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:e75bb490ca39: avcodec/012v: redesign main loop
[14:41:20 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:7a3ff7fb814b: ffmdec: make sure the time base is valid
[14:41:21 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:a15ceebb6f2a: avformat/asfdec: Use 64bit ret to avoid overflow
[14:41:22 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:107738051393: avformat/idcin: Use 64bit for ret to avoid overflow
[14:41:23 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:2ee4b48c9b72: avformat/gxf: Use 64bit for res to avoid overflow
[14:41:24 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:c4b5b3309ca9: avformat/mvdec: Use 64bit for ret to avoid overflow
[14:41:25 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:c5c39132b4a3: avformat/vqf: Use 64bit for ret to avoid overflow
[14:41:26 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:2bb09b714ab6: avformat/omadec: Use 64bit for ret to avoid overflow
[14:41:27 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:1a396d1ee0d6: avcodec/x86/mlpdsp_init: Simplify mlp_filter_channel_x86()
[14:41:28 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:baa1738f9918: avcodec/a64multienc: use av_frame_ref instead of copying the frame
[14:41:29 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:5c4dc00c3a6d: avcodec/a64multienc: don't set incorrect packet size
[14:41:30 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:e29761b1c850: avcodec/a64multienc: fix use of uninitialized values in to_meta_with_crop
[14:41:31 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:d125abfa7487: swscale/utils: More carefully merge and clear coefficients outside the input
[14:41:32 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:c4d250abcaf7: avcodec/snowdec: Fix ref value check
[14:41:33 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:ec7c1cd73319: avcodec/h264: Only reinit quant tables if a new PPS is allowed
[14:41:34 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:c80398513204: avcodec/zmbv: Check len before reading in decode_frame()
[14:41:35 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:a3cd26aa33ed: avcodec/hevc_ps: Sanity checks for some log2_* values
[14:41:36 CET] <cone-251> ffmpeg 03James Cowgill 07release/2.2:b9d09fb8c999: mips/acelp_filters: fix incorrect register constraint
[14:41:37 CET] <cone-251> ffmpeg 03Dyami Caliri 07release/2.2:265ad094a8cb: Fix buffer_size argument to init_put_bits() in multiple encoders.
[14:41:38 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:3193f4d3f2a6: avformat/adxdec: check avctx->channels for invalid values
[14:41:39 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:3183c2078105: avformat/bit: check that pkt->size is 10 in write_packet
[14:41:40 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:4e11780b85f8: avformat/bit: only accept the g729 codec and 1 channel
[14:41:41 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:e32e1e3a4fe0: swscale/utils: clear formatConvBuffer on allocation
[14:41:42 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:97fb0b210931: avformat/flvenc: check that the codec_tag fits in the available bits
[14:41:43 CET] <cone-251> ffmpeg 03Steve Lhomme 07release/2.2:7ed19bd337ea: fix VP9 packet decoder returning 0 instead of the used data size
[14:41:44 CET] <cone-251> ffmpeg 03Stefano Sabatini 07release/2.2:6155d5d98b1b: doc/protocols/tcp: fix units of listen_timeout option value, from microseconds to milliseconds
[14:41:45 CET] <cone-251> ffmpeg 03Ronald S. Bultje 07release/2.2:77e8bd8ce62a: vp9: ignore reference segmentation map if error_resilience flag is set.
[14:41:46 CET] <cone-251> ffmpeg 03Ronald S. Bultje 07release/2.2:2cde388aeabc: vp9: fix segmentation map retention with threading enabled.
[14:41:47 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:2e5579bbb4f8: avcodec/utils: Align YUV411 by as much as the other YUV variants
[14:41:48 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:917ce36a2067: doc: avoid the incorrect phrase 'allow to'
[14:41:49 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:d8a8b3948c29: avcodec/tiff: move bpp check to after "end:"
[14:41:50 CET] <cone-251> ffmpeg 03Vittorio Giovara 07release/2.2:5537faaf19d3: aic: Fix decoding files with odd dimensions
[14:41:51 CET] <cone-251> ffmpeg 03Andreas Cadhalpun 07release/2.2:88cc4a405a46: ffmdec: fix infinite loop at EOF
[15:22:59 CET] <cone-251> ffmpeg 03Michael Niedermayer 07release/2.2:0746f5035e7b: Update for FFmpeg 2.2.14
[15:54:24 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:73ebbfdff0bb: ac3dec: cosmetics
[16:31:41 CET] <kurosu__> michaelni, anyway, the eac3 spx decoding seems far from correct
[16:31:56 CET] <kurosu__> Using the nero decoding as reference: stddev: 1170.11 PSNR: 34.96 MAXDIFF:11519
[17:33:09 CET] <cone-251> ffmpeg 03Michael Niedermayer 07master:a48b24e5ebdb: avcodec/wmadec: Fix undefined shift in wma_decode_block()
[17:36:37 CET] <Daemon404> moving over my msvc static analysis today 
[18:06:21 CET] <kierank> what an awful awful patch
[18:07:00 CET] <kierank> that's everything that's wrong with ffmpeg
[18:07:06 CET] <kierank> no review, not tested
[18:07:20 CET] <Daemon404> the one i linked?
[18:07:23 CET] <kierank> yes
[18:07:29 CET] <Daemon404> :D
[18:07:34 CET] <j-b> which one?
[18:07:40 CET] <kierank> j-b: https://trac.ffmpeg.org/ticket/4367
[18:07:52 CET] <j-b> ah, yes
[18:07:59 CET] <j-b> I wondered why this was even merged
[18:08:04 CET] <j-b> it does not work a shit
[18:08:12 CET] <kierank> it's not as if it was sent to the ml to be reviewd
[18:08:24 CET] <Daemon404> im sure carl will close the report as invalid soon enough
[18:08:27 CET] <Daemon404> and all will be well.
[18:11:14 CET] <kurosu__> kierank, I imagine it was tested, but on a testset nowhere near sufficient
[18:11:24 CET] <kierank> kurosu__: read the commit message
[18:11:25 CET] <kurosu__> actually, is there even someone with both the knowledge and the legal ability to review and/or improve the offending patch?
[18:11:35 CET] <kierank> "Not checked if its actually lossless"
[18:12:10 CET] <kurosu__> well, he doesn't have the binary decoder at hand, and just listened it was sounding at least ok
[18:12:20 CET] <kurosu__> but yes, the original ticket should not have been closed
[18:12:57 CET] <kurosu__> I mean, we shouldn't have merged half of the reverse engineered audio codec I bet
[18:13:13 CET] <kurosu__> the spx stuff I was looking at, dts and co are probably nowhere near ok
[18:13:13 CET] <Daemon404> this one had some debug binaries at least 
[18:13:19 CET] <Daemon404> from lindows
[18:13:25 CET] <Daemon404> back when they licensed the wma sdk
[18:13:34 CET] <Daemon404> or was it linspire at the time...
[18:17:14 CET] <Daemon404> ................
[18:17:30 CET] <philipl> hah. He did it because you told him to :-)
[18:17:47 CET] <Daemon404> it was a dupe i guess
[18:18:53 CET] <kurosu__> I think CE is right here, it is indeed duplicate, but I thought the original bugreport had been closed
[18:19:28 CET] <Daemon404> yes
[18:19:30 CET] <Compn> isnt it better to have code in one repo than to have multiple devels try to debug it seperately and duplicate work ?
[18:19:41 CET] <Daemon404> what has that got to do with anything?
[18:19:53 CET] <kurosu__> well, then, at least mark it experimental or something
[18:20:08 CET] <Daemon404> i argue that this output is so broken, it should nto even be enabled
[18:20:37 CET] Action: Compn reads the commit
[18:20:39 CET] <Compn> interesting :P
[18:21:48 CET] <Compn> oh 24bit wmal is two commits
[18:21:55 CET] <Compn> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=4327088da355509b9f97e4bdb658456ee56de72b
[18:23:23 CET] <kurosu__> the commit you pasted was broken anyway, and I suspect you shouldn't use 16bitsx16bits->32bits for >16 bits
[18:23:36 CET] <Compn> kurosu__ : patch welcome ;)
[18:23:48 CET] <kurosu__> Compn, patch already sent by myself and applied
[18:23:59 CET] <Compn> :)
[18:24:01 CET] <kurosu__> for the broken part, at least
[18:24:03 CET] <Compn> right
[18:24:15 CET] <Compn> i dunno the answer :)
[18:24:19 CET] <Compn> keep fixing bugs 
[18:24:23 CET] <kurosu__> it's weird, because I can't find why I think I discussed with Michael about this, and he told me the samples he tested on sounded ok
[18:24:39 CET] <Daemon404> there are tons of samples which dont
[18:24:44 CET] <Daemon404> the other ticket which carl linked has a lot
[18:25:08 CET] <Compn> bunch of decoders that have samples which break our decoders
[18:25:18 CET] <Compn> if we didnt merge any broken decoders ... we wouldnt have any decoders at all :P
[18:25:29 CET] Action: Compn responding to kurosu__ not Daemon404
[18:25:35 CET] <Daemon404> well in this case it's "breaks with literally every sample i can find"
[18:25:47 CET] <Compn> Daemon404 : should we have a disclaimer that ffmpeg decoder might not be correct or bitexact ?
[18:25:54 CET] <Compn> somewhere in our docs ? i think so.
[18:26:00 CET] <Daemon404> it is a *lossless* decoder
[18:26:05 CET] <Daemon404> and it wasnt even tested if its lossless
[18:26:08 CET] <Daemon404> nor reviewe.d
[18:26:12 CET] <Compn> i mean for all decoders.
[18:26:22 CET] <Compn> encoders, etc
[18:26:31 CET] <Daemon404> that would be an incorrect disclaimer
[18:26:35 CET] <Daemon404> and also irrelevant for lossy audio codecs.
[18:26:54 CET] <kurosu__> well, anyway, Compn is right, patch welcome - though I really wonder if it well ever happen
[18:27:02 CET] <kurosu__> thought that's what I thought about dca xll
[18:27:07 CET] <kurosu__> *though that's
[18:27:12 CET] <Daemon404> kurosu__, i cant fix it, but i can put it under strict -2
[18:27:16 CET] <Daemon404> where it belongs
[18:27:25 CET] <kurosu__> I'd agree to this
[18:27:36 CET] <Compn> i dont care what strict is used.
[18:27:59 CET] <kurosu__> that's the best compromise between not lulling people into thinking it's mostly ok, and still allow more testing
[18:28:26 CET] <Daemon404> it's pretty thoroughly proven broken ;)
[18:29:07 CET] <kurosu__> that's what happening with dca xll too?
[18:29:14 CET] <kurosu__> *what's
[18:29:28 CET] <kurosu__> not the broken, the experimental, I mean
[18:31:07 CET] <thamburan> I did a project in python using ffmpeg. I'd like to contribute to ffmpeg. Where to start
[18:31:51 CET] <Daemon404> thamburan, well what do you want to contribute?
[18:34:16 CET] <Compn> thamburan : review code and fix things, fix bugs on trac, review patches on mailing list... where would you like to start ?
[18:35:00 CET] <thamburan> I'm a CS student specializing in security. But i also have interests in multimedia. I'm good at reviewing code and finding bugs.
[18:36:04 CET] <Compn> thamburan : are you doing this for gsoc or just for fun ? i ask because theres a lot of students running around and we're in gsoc right now...
[18:37:04 CET] <Daemon404> doesnt sound like a gsoc student
[18:37:20 CET] <thamburan> I'm happy if i can do it via GSoc, but anyways i'm intersted in he project
[18:38:53 CET] <Daemon404> there's not really "a place to start"
[18:39:04 CET] <Daemon404> either you have something you want to add/do, and you can send a patch
[18:39:07 CET] <Daemon404> or you can check the bug tracker
[18:39:08 CET] <Daemon404> i suppose.
[18:41:45 CET] <thamburan> thanks. happy to see a lot of people behind this project.
[18:49:24 CET] <Compn> thamburan : check the gsoc ffmpeg wiki page
[18:49:30 CET] <Compn> maybe pick a project (dont pick apng lol)
[18:49:35 CET] <Compn> and then go from there
[18:49:37 CET] <ramiro> thamburan, since you're specialising in security, you could also try finding bugs related to that. for example looking for crashes on fuzzed data or just manually inspecting random snippets of code
[18:49:37 CET] <Compn> or something
[18:49:48 CET] <Compn> but we are always happy to see more contributors :)
[18:54:23 CET] <thamburan> :) thanks
[19:00:30 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:5d38c628b0a8: ppc: libswscale: use LOCAL_ALIGNED instead of DECLARE_ALIGNED
[19:18:09 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:98cccdd91c9a: ppc: lavc: use LOCAL_ALIGNED instead of DECLARE_ALIGNED
[19:25:25 CET] <kurosu__> michaelni, yeah about LOCAL_ALIGNED + static, I'm still rerunning fate after rebasing with the recent commits
[19:27:30 CET] <kurosu__> dct-test never happened to be built with any fate test run I ever launched
[19:31:45 CET] <kurosu__> welp, I'm dropping the ball on eac3 spx, it's way too difficult to follow when a line of computation actually merges several parts of the specs
[19:48:01 CET] <michaelni> "make testprogs" builds dct-test
[20:24:29 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:238db7cc56be: x86: lavc: use LOCAL_ALIGNED instead of DECLARE_ALIGNED
[20:26:20 CET] <ramiro> michaelni, in lavformat/mov.c:mov_open_dref() it's possible to open any file in the filesystem, by abusing ref->nlvl_from and opening ../../../{...}/etc/passwd or whatever
[20:27:02 CET] <ramiro> the file will be treated as a mov, so it likely error out in parsing, but anyways. if you know the exact location of another mov file in a computer you're attacking, you can still open it
[20:50:59 CET] <michaelni> ramiro, do you have a suggestion on how to avoid this ? this is AFAIK how mov dref works
[20:51:39 CET] <michaelni> also the file would need to  be downloaded first for this to work i think
[21:05:54 CET] <michaelni> do we have a sample that uses dref ?
[21:07:28 CET] <Daemon404> i have some at work probably...
[21:07:39 CET] <Daemon404> Paranoialmaniac probably has some too
[21:10:09 CET] <Paranoialmaniac> url-type dref sample is included in conformance testing files: ISO/IEC 14496-4:2004 Amd 24 2008 Conformance Testing
[21:10:28 CET] <Paranoialmaniac> it is freely available
[21:29:17 CET] <ubitux> damn, this query_formats thing is annoying
[21:29:26 CET] <ubitux> i can't decide what to do
[21:29:56 CET] <ubitux> even this this &err idea looks kind of clumsy
[21:46:52 CET] <michaelni> Paranoialmaniac, thanks!
[21:58:41 CET] <cone-251> ffmpeg 03Christophe Gisquet 07master:3814f92fd77f: lavc: use LOCAL_ALIGNED instead of DECLARE_ALIGNED
[21:58:42 CET] <cone-251> ffmpeg 03Michael Niedermayer 07master:21a53dd08dce: avformat/mov: Use sizeof(filename) instead of a literal number
[21:58:43 CET] <cone-251> ffmpeg 03Michael Niedermayer 07master:8003816e1619: avformat/mov: Check for string truncation in mov_open_dref()
[22:56:43 CET] <cone-251> ffmpeg 03Mark Reid 07master:43cafb956e29: libavformat/mxfdec: export user comments metadata
[23:47:33 CET] <cone-251> ffmpeg 03Michael Niedermayer 07master:a994fc39b3fc: avcodec/utils: mark codec argument as const in ff_lock_avcodec()
[00:00:00 CET] --- Sun Mar 15 2015