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

[burek]

[00:30:19 CEST] <kierank> do I dare suggest dropping hscale_fast_bilinear_simd
[01:06:27 CEST] <cone-461> ffmpeg 03Michael Niedermayer 07master:0c015aa95c2d: avcodec/tableprint_vlc: Do not define functions to nothing
[01:06:28 CEST] <cone-461> ffmpeg 03Michael Niedermayer 07master:374cf93548d1: avformat/asfdec: do not define print_guid() to nothing
[01:06:29 CEST] <cone-461> ffmpeg 03Michael Niedermayer 07master:3e14ed05f1de: avformat/internal: always check arguments of hex_dump_debug()
[01:13:31 CEST] <BBB> kierank: but its runtime generated simd!!112
[01:13:38 CEST] <BBB> kierank: how often have you seen that :-p
[01:20:06 CEST] <cone-461> ffmpeg 03Michael Niedermayer 07master:223a85985393: swresample/dither_template: Do not define macro functions to nothing
[01:50:22 CEST] <cone-461> ffmpeg 03Michael Niedermayer 07master:bc6f84fff741: avdevice/dshow_capture: avoid #ifdef, use ff_dlog() for dshowdebug()
[02:57:45 CEST] <cone-461> ffmpeg 03Carl Eugen Hoyos 07master:b453e7684279: lavc/qdrw: Also support real-world qdraw images.
[02:57:46 CEST] <cone-461> ffmpeg 03Carl Eugen Hoyos 07master:2279de6eca12: lavf/img2dec: Autodetect qdraw images.
[02:57:47 CEST] <cone-461> ffmpeg 03Michael Niedermayer 07master:5f2b4a2f6a13: Merge remote-tracking branch 'cehoyos/master'
[04:12:12 CEST] <cone-461> ffmpeg 03Michael Niedermayer 07master:21b30947f2ca: swscale/x86/hscale_fast_bilinear_simd: Fix variable names in comments
[05:18:05 CEST] <cone-461> ffmpeg 03Michael Niedermayer 07master:9253cc496a50: avcodec/diracdec: Replace default_bsep[] by multiplication
[09:00:04 CEST] <yvear> does we support dts hd ma decoding now?
[09:00:12 CEST] <yvear> *do
[10:09:14 CEST] <yvear> if so, it's not working for me. it's not detecting any channel > 6, being decoded as 5.1 is all it will do
[10:09:22 CEST] <yvear> can anyone confirm?
[10:10:15 CEST] <Gopu> hello can i send the patch as a attachement(git format-patch )? 
[10:34:46 CEST] <wm4> Gopu: yes
[10:35:10 CEST] <nevcairiel> we prefer git send-email though
[10:46:04 CEST] <Gopu> OK Thanks 
[12:02:40 CEST] <BBB> michaelni: do you want new patchset on ML or is on github only OK for you?
[13:07:50 CEST] <michaelni> BBB, the new vp9 fate tests fail on qemu mips
[13:08:05 CEST] <BBB> Im shocked :-p
[13:08:23 CEST] <BBB> I assure you I didnt write mips code
[13:09:06 CEST] <BBB> do you have any furhter info? Like a backtrace or something?
[13:09:14 CEST] <michaelni> wait, let me retest, i maybe did something silly
[13:09:40 CEST] <michaelni> but it was wrong results no crash
[13:09:49 CEST] <BBB> hm...
[13:10:12 CEST] <michaelni> no, still are failing
[13:10:21 CEST] <BBB> confused
[13:10:56 CEST] <BBB> I dont have qemu
[13:11:04 CEST] <BBB> do you know which patch in the set causes it to fail?
[13:11:30 CEST] <BBB> or wait, you said new ones
[13:11:35 CEST] <BBB> so the existing ones are fine?
[13:11:41 CEST] <BBB> its because its BE
[13:11:44 CEST] <BBB> the test results are LE
[13:11:45 CEST] <michaelni> these are failung: fate-vp9p2-20-10bit-yuv420, fate-vp9p2-20-12bit-yuv420 fate-vp9p3-20-10bit-yuv422 fate-vp9p3-20-10bit-yuv444 fate-vp9p3-20-12bit-yuv422 fate-vp9p3-20-10bit-yuv440 fate-vp9p3-20-12bit-yuv444 fate-vp9p3-20-12bit-yuv440
[13:11:48 CEST] <BBB> and Im not converting it
[13:11:54 CEST] <BBB> let me see how h264/hevc do that
[13:12:31 CEST] <michaelni> yes BE/LE is likely, ist what its most of the time when mips fails
[13:14:31 CEST] <BBB> testing a fix...
[13:20:07 CEST] <BBB> michaelni: fix pushed to github
[13:20:18 CEST] <BBB> (basically force -pix_fmt, similar to what h264 tests do)
[13:34:27 CEST] <cone-277> ffmpeg 03Ronald S. Bultje 07master:98f7f0f7e83f: lavu: add yuv440p10/12 pixfmts.
[13:34:28 CEST] <cone-277> ffmpeg 03Ronald S. Bultje 07master:57f970a7046f: lavc: add yuv440p10/12 formats to aligned pixfmt list.
[13:34:29 CEST] <cone-277> ffmpeg 03Ronald S. Bultje 07master:711d8812adc1: swscale: add yuv440p10/12 pixfmts.
[13:34:30 CEST] <cone-277> ffmpeg 03Ronald S. Bultje 07master:5c600d74aa4d: fate: add/update reference files for 440 addition.
[13:34:31 CEST] <cone-277> ffmpeg 03Ronald S. Bultje 07master:01e59d48ed1a: vp9: add profile 2/3 to exported profiles.
[13:34:32 CEST] <cone-277> ffmpeg 03Ronald S. Bultje 07master:346ce5da197b: vp9: parse profile 2/3 bitdepth in frame header.
[13:34:33 CEST] <cone-277> ffmpeg 03Ronald S. Bultje 07master:b224b165cbbb: vp9: add keyframe profile 2/3 support.
[13:34:34 CEST] <cone-277> ffmpeg 03Ronald S. Bultje 07master:23ba4538f9d7: vp9: add inter-frame profile 2/3 suport.
[13:34:35 CEST] <cone-277> ffmpeg 03Ronald S. Bultje 07master:b8077d7a3b7b: vp9: add profile 2/3 fate tests.
[13:34:36 CEST] <cone-277> ffmpeg 03Ronald S. Bultje 07master:2293ec6ab300: libvpxdec: add 440 pixfmts.
[13:34:37 CEST] <cone-277> ffmpeg 03Michael Niedermayer 07master:b28d5c49f7e5: Merge remote-tracking branch 'rbultje/vp9-profile23-wip'
[13:48:13 CEST] <BBB> \o/
[14:01:57 CEST] <Compn> another pixfmt ! :P
[14:01:57 CEST] <Compn> ehe
[14:12:42 CEST] <kierank> Compn: https://github.com/bcoudurier/FFmbc
[14:21:50 CEST] Action: Compn does not know the significance of ffmbc on github
[14:27:56 CEST] <kierank> there is git now
[14:27:59 CEST] <kierank> there was not in the past
[14:29:13 CEST] <nevcairiel> now that we actually have a clear changelog .. how does that LGPL -> GPL rule go .. I can just fork LGPL and make it GPL, but does that then truely prohibit any backporting to the  LGPL project? because if it does, someone should really teach the fsf that they are idiots
[14:32:10 CEST] <michaelni> Daemon404, is "0507 11:17 Gopu Govindaswa ( 10K) [FFmpeg-devel] [PATCH] avcodec/libx265: use x265 Multi-library Interface to query the API" ok to apply ?
[14:32:20 CEST] <thardin> nevcairiel: ask a lawyer
[14:33:25 CEST] <thardin> but of course the author of any patches to a project are free to choose whichever license they want, as long as it doesn't clash with the license of the original code
[14:34:02 CEST] <nevcairiel> but the "original" code was LGPL, someone just invoked this one rule that you can also license LGPL code as GPL
[14:34:21 CEST] <thardin> so take the code from the original lgpl source
[14:34:42 CEST] <nevcairiel> the point is about backporting patches inside this GPL project
[14:35:50 CEST] <thardin> hm.. is there line/character grained licensing?
[14:38:40 CEST] <thardin> this also reminds me of how libav tends to take patches from ffmpeg, rewrite them and claim ownership (like some of my mxfdec patches)
[14:38:59 CEST] <thardin> or rather, git changes their ownership (I think)
[14:39:09 CEST] <nevcairiel> its easy to blame git
[14:39:12 CEST] <BBB> nevcairiel: yes you can do that
[14:39:18 CEST] <BBB> nevcairiel: and yes its obviously bad faith to do so
[14:39:25 CEST] <nevcairiel> but its even easier to keep ownership intact when porting patches =p
[14:39:32 CEST] <BBB> but I mean, were talking about bcoudurier here
[14:39:33 CEST] <BBB> so...
[14:40:23 CEST] <BBB> and the reimplementing of ideas between ffmpeg and libav is just a massive waste of manpower
[14:40:31 CEST] <BBB> rgardless of the legal implications (or lack thereof)
[14:42:35 CEST] <kierank> but.but.but code cleanliness
[14:42:50 CEST] <thardin> muh indentation
[14:43:21 CEST] <thardin> all I know is dual review processes are a burden
[14:54:50 CEST] <cone-277> ffmpeg 03Michael Niedermayer 07master:a6153977df6d: avcodec/vp9dsp: Replace assert by av_assert0()
[14:54:51 CEST] <cone-277> ffmpeg 03Michael Niedermayer 07master:cc77bb09e430: avcodec/x86/vp9dsp_init: Fix mix of declaration and statement
[15:12:47 CEST] <BBB> kierank: so supposedly, code cleanliness leads to better end user experinece, right? I mean, eventually
[15:13:00 CEST] <BBB> like, its faster, less bugs, less security issues, more features, easier development
[15:13:01 CEST] <BBB> irght?
[15:13:06 CEST] <BBB> so, if thats true
[15:13:16 CEST] <BBB> then how come libavs vp9 decoder is a piece of shit compared to ffmpeg's?
[15:13:43 CEST] <BBB> because clearly, libavs is much better indented than ffmpegs
[15:58:42 CEST] <nevcairiel> that whole premise only works when you actually have manpower left to do all these things after the indenting =p
[15:59:54 CEST] <BBB> admittedly, its a lot of reindenting
[16:00:19 CEST] <BBB> fortunately, indenting adds massive value to your ohloh linecount stats
[16:37:15 CEST] <cone-277> ffmpeg 03James Almer 07master:aa70801aaf40: ripemd: move ripemd{256, 320} into separate functions
[16:53:39 CEST] <cone-277> ffmpeg 03Shivraj Patil 07master:7174df44fe7b: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for HEVC uni copy, uni horizontal and uni vertical mc functions
[16:54:55 CEST] <nevcairiel> i'm somewhat fascinated that someone really wants to decode hevc on a mips device
[16:55:06 CEST] <nevcairiel> arent they all butt-slow mini SoCs
[16:55:32 CEST] <wm4> yeah, that seems strange
[16:55:45 CEST] <wm4> maybe some bad interacting with the marketing dept.?
[17:07:01 CEST] <yvear> can anyone confirm 7.1 dts hd ma decoding works in the current build? only reading as 5.1 for me
[17:08:05 CEST] <nevcairiel> you need to pass an option to enable it, ie "-disable_xll 0" or something like that, i forgot the exact wording, but apart from that its also not quite perfect
[17:08:16 CEST] <nevcairiel> if you want a more reliable decoding, build ffmpeg with libdcadec instead
[17:08:41 CEST] <wm4> also, if you want to use the libdcadec ffmpeg wrapper, you need to explicitly open that decoder, since the builtin one is preferred
[17:08:58 CEST] <nevcairiel> or do what i do, and disable it at built-time =P
[17:10:10 CEST] <yvear> wm4, +nevcairiel, my windows build says --enable-libdcadec
[17:10:55 CEST] <nevcairiel> then you need to pass something like -c:a libdcadec to make use of it
[17:11:03 CEST] <yvear> even ffprobe reads as 5.1, doesn't recognize 7.1
[17:11:07 CEST] <yvear> ok
[17:13:29 CEST] <wm4> yvear: libavformat might still use the builtin decoder, but you can simply ignore the info it exports, and use what you get in the AVFrame instead
[17:13:55 CEST] <nevcairiel> that reminds me that I was meaning to send my patch for the dts parser
[17:23:14 CEST] <yvear> +nevcairiel, wm4, ah, ok it still defaults to old decoder. must do   ffmpeg -c:a libdcadec -i file.dts outfile   when will it default to new decoder?
[17:24:06 CEST] <wm4> probably never, because ffmpeg always prefers internal decoders over external ones
[17:24:41 CEST] <j-b> Do we have test cases for the failures?
[17:24:50 CEST] <j-b> of the internal one?
[17:25:38 CEST] <nevcairiel> i gave some to libav, and i stopped caring shortly after since i have a free, open, bitperfect and complete decoder now =p
[17:27:13 CEST] <yvear> aww :( then will our internal decoder support full DTS-HD MA decoding soon? since we have the code and see how it's done
[17:27:32 CEST] <nevcairiel> doubtful
[17:31:31 CEST] <yvear> I mean, if there is code that works better and is open source, and we already use it as an optional decoder.. why do we not default to it? it couldn't be a license thing right?
[17:31:56 CEST] <yvear> or is it?
[17:49:05 CEST] <JEEBsv> yvear: so far it seems OK license-wise, and we do already have some kind of X > Y things regarding decoders/encoders, IIRC
[17:57:16 CEST] <cone-277> ffmpeg 03Andreas Cadhalpun 07master:584cc1ade10a: aacsbr: break infinite loop in sbr_hf_calc_npatches
[18:41:07 CEST] <yvear> hmm, is it possible to set decoder per stream?
[18:46:44 CEST] <nevcairiel> yes
[18:54:11 CEST] <yvear> +nevcairiel, with a .mkv containing h264, 7.1 dts-hd ma, and ac3, doing   ffmpeg -c:a:0 libdcadec -i file.mkv   only shows 5.1 dts. it doesn't apply decoder
[18:54:41 CEST] <nevcairiel> ignore what it says, just check what it actually decodes
[18:55:42 CEST] <nevcairiel> also check that the stream index is actually the correct one
[19:04:52 CEST] <yvear> +nevcairiel, yes it's not decoding 7.1 with libdcadec just normal 5.1
[19:06:33 CEST] <yvear> +nevcairiel, it works when not in a container though
[19:09:34 CEST] <cone-277> ffmpeg 03Tom Butterworth 07master:873d7e0e6326: avcodec/s3tc: fix decoding when dimensions are not a multiple of 4
[19:14:49 CEST] <Daemon404> michaelni, one change, and it needs to be fixed so it isnt malformed
[19:15:03 CEST] <Daemon404> [16:47] <@muggs> Daemon404: looking at his last patch, you can remove the !api check after x265_api_get(0); when you request 0 it always returns an API structure pointer.
[19:15:06 CEST] <Daemon404> [16:53] <@muggs> X265_BUILD 57 has the api request forwarding feature in it.
[19:15:09 CEST] <Daemon404> ^
[19:20:16 CEST] <cone-277> ffmpeg 03Michael Niedermayer 07master:daea3209693f: avcodec/txd: Fix input size checks for dxt1/3 for dimensions % 4 != 0
[19:21:44 CEST] <michaelni> Daemon404, ok, please tell the patch author not me, or should i forward it to the ML ?
[19:24:53 CEST] <Daemon404> michaelni, i told him during my first revieew... he ignored it
[19:25:07 CEST] <Daemon404> ill reply after dinner today
[19:25:10 CEST] <Daemon404> (was on a plane to berlin)
[19:25:26 CEST] <Daemon404> actually, ill just fix it by hand later.
[19:26:39 CEST] <michaelni> ok, thanks
[22:54:48 CEST] <rcombs> oh hey, an fflogger bug
[22:59:40 CEST] <wm4> rcombs: easiest way to check... write a patch, check if it works, if it does, look at the spec, if there's nothing suspicious, send a patch
[23:02:19 CEST] <rcombs> wm4: I may or may not do that
[23:03:54 CEST] <cone-940> ffmpeg 03Michael Niedermayer 07master:a7dd933b811b: avcodec: Add av_packet_side_data_name()
[23:03:54 CEST] <cone-940> ffmpeg 03Michael Niedermayer 07master:5f0ebe865c42: ffprobe: Use av_packet_side_data_name() to find the side data name
[23:03:54 CEST] <cone-940> ffmpeg 03Michael Niedermayer 07master:43e94d5af48b: avcodec/g2meet: Use init_get_bits8()
[23:03:54 CEST] <cone-940> ffmpeg 03Michael Niedermayer 07master:b1b0baa3d6a3: avcodec/g2meet: Check init_get_bits8() return value
[23:25:04 CEST] <cone-940> ffmpeg 03Tom Butterworth 07master:288dc5b4a118: avcodec/s3tc: fix alpha decoding when dimensions are not a multiple of 4
[23:36:08 CEST] <cone-940> ffmpeg 03James Almer 07master:e0a403e1c284: vp9: add missing changelog and APIchanges entries for new VP9 profiles
[23:53:59 CEST] <rcombs> >Dependent substream decoding is not implemented
[23:54:08 CEST] <rcombs> do we still need a sample of that^
[23:54:13 CEST] <rcombs> because I apparently have one
[23:58:01 CEST] <cone-940> ffmpeg 03James Almer 07master:28eaf46da904: doc/APIchanges: fill missing versions and hashes
[00:00:00 CEST] --- Fri May  8 2015