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

[burek]

[01:03] <michaelni> BBB, ubitux did you see the vp9 valgrind fate failures ? (http://fate.ffmpeg.org/report.cgi?time=20131223161213&slot=x86_64-archlinux-gcc-valgrindundef)
[01:05] <kierank> lol http://support.apple.com/kb/HT5959?viewlocale=en_US
[01:19] <BBB> michaelni: yes, ubitux told me, it looks like a bug in valgrind
[01:21] <michaelni> hmm, ok
[01:27] <BBB> I mean, the output is completely ok in fate so I find it hard to believe I'm doing something undefined there
[02:04] <cone-252> ffmpeg.git 03Carl Eugen Hoyos 07master:05c3c568dccd: Read pictures in id3v2.2
[02:21] <BBB> ubitux: patch for parallelmode=1 bug on ML, please review (and michaelni: feel free to apply when OK'ed)
[02:21] <BBB> should fix that vp9 issue on trac also
[02:21] <BBB> haven't tested, but sounded identical in scope
[02:22] <BBB> https://trac.ffmpeg.org/ticket/3228
[02:22] <BBB> that one
[02:22] <BBB> and just tested yes it fixes it
[03:42] <BBB> ubitux: and your fuzz crash also fixed, thanks for the sample
[03:42] <BBB> now off to do speed measurements for 16x16 sub-IDCTs and then on to 32x32 IDCT
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:edca16f1af63: ffserver: strip odd chars from html error messages before sending them back
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:f684bbf224df: avcodec/jpeg2000dec: check transform equality in MCT
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:93f26b79926c: avcodec/jpeg2000dec: prevent out of array accesses in pixel addressing
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:47f8497837eb: avcodec/jpeg2000dec: fix context consistency with too large lowres
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:074ebfacf40f: avfilter/ff_insert_pad: fix order of operations
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:72f1907c96b5: avcodec/avpacket/av_packet_split_side_data: ensure that side data padding is initialized
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:fce2cfbdcfbd: avcodec/utils: add some saftey checks to add_metadata_from_side_data()
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:83e4aa3e7c57: avutil/opt: initialize ret
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:bdf6e6fff41b: avcodec/jpeglsdec: check err value for ls_get_code_runterm()
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:c88bdac4605c: avformat/thp: fix variable types to avoid overflows
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:4324d7badeb6: avformat/thp: force moving forward
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:b545d11d498c: avcodec/jpeg2000dec: non zero image offsets are not supported
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:70fcea3b7761: h264: Do not treat the initial frame special in handling of frame gaps
[04:01] <cone-252> ffmpeg.git 03Kostya Shishkov 07release/2.0:3a3b5ae4c053: mpegvideo: Fix swapping of UV planes for VCR2
[04:01] <cone-252> ffmpeg.git 03Diego Biurrun 07release/2.0:6b683be641b6: mpeg12dec: Remove incomplete and wrong UV swapping code for VCR2
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:28ac4e91dcfa: avutil: rename lls to lls2
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:0cd61c7f7d10: rename new lls code to lls2 to avoid conflict with the old which has a different ABI
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:4f93400db1f2: avutil: reintroduce lls1 as the 52 ABI needs it
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:ae81a0e32de6: avcodec: move end zeroing code from av_packet_split_side_data() to avcodec_decode_subtitle2()
[04:01] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:bd9dcb411d2e: avcodec/jpeg2000dec: Check precno before using it in JPEG2000_PGOD_CPRL
[04:02] <cone-252> ffmpeg.git 03Paul B Mahol 07release/2.0:a9382fc15c15: avcodec/libopusenc: change default frame duration to 20 ms
[04:02] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:66a9edfcf677: do O(1) instead of O(n) atomic operations in register functions
[04:02] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:172f92976752: avutil/log: skip IO calls on empty strings
[04:02] <cone-252> ffmpeg.git 03Michael Niedermayer 07release/2.0:b4552cc9b8c3: update for FFmpeg 2.0.3
[04:36] <cone-252> ffmpeg.git 03Carl Eugen Hoyos 07fatal: ambiguous argument 'refs/tags/n2.0.3': unknown revision or path not in the working tree.
[04:36] <cone-252> Use '--' to separate paths from revisions
[04:36] <cone-252> refs/tags/n2.0.3:HEAD: Read pictures in id3v2.2
[05:09] <cone-252> ffmpeg.git 03Jan Gerber 07master:b2597042e5a7: avcodec/libopusdec: Set codec->delay to pre_skip not fixed value
[07:25] <ubitux> BBB: oh awesome
[07:34] <ubitux> kierank: ahah nice
[08:14] <cone-698> ffmpeg.git 03Michael Niedermayer 07release/1.1:848af79decd2: nutenc/write_index: warn if 2 consecutive keyframes have the same PTS and discard the 2nd
[08:14] <cone-698> ffmpeg.git 03Peter Ross 07release/1.2:7ba102d00814: riffenc: add option to ff_put_bmp_header to ignore extradata
[08:14] <cone-698> ffmpeg.git 03Peter Ross 07release/1.2:9f3135b30bfb: avformat/riffenc: indent
[08:14] <cone-698> ffmpeg.git 03Peter Ross 07release/1.2:fa45feefad0e: wtvenc: populate VIDEOINFOHEADER2
[08:14] <cone-698> ffmpeg.git 03Michael Niedermayer 07release/1.2:5c502e5d4141: nutenc/write_index: warn if 2 consecutive keyframes have the same PTS and discard the 2nd
[08:14] <cone-698> ffmpeg.git 03Peter Ross 07release/2.1:c3f962840793: riffenc: add option to ff_put_bmp_header to ignore extradata
[08:14] <cone-698> ffmpeg.git 03Peter Ross 07release/2.1:f27895db0f10: avformat/riffenc: indent
[08:14] <cone-698> ffmpeg.git 03Peter Ross 07release/2.1:94c3f8165c6a: wtvenc: populate VIDEOINFOHEADER2
[08:14] <cone-698> ffmpeg.git 03Michael Niedermayer 07release/2.1:b432043d556f: nutenc/write_index: warn if 2 consecutive keyframes have the same PTS and discard the 2nd
[12:08] <cone-528> ffmpeg.git 03Ronald S. Bultje 07master:4a55bffad32e: vp9: fix bug in updating of coef probabilities with parallelmode=1.
[12:08] <cone-528> ffmpeg.git 03Ronald S. Bultje 07master:acafbb4dd260: vp9: fix crash if segmentation=1, keyframe/intraonly=1 and updatemap=0.
[12:49] <ubitux> BBB: sorry, got another one :)
[12:49] <saste> ubitux, you gonna review volume patches?
[12:50] <ubitux> saste: i don't think so, unless you insist
[12:50] <saste> ubitux, i don't insist, i just ask because you was interested with the patch at some point
[12:51] <ubitux> saste: give me a minute i'll scroll review it
[12:51] <saste> as usual, i'm mostly interested in interface issues, functional bugs can be fixed later
[12:56] <ubitux> saste: i think the reconfiguration of the dsp callbacks in filter_frame() should be in the EVAL_MODE_FRAME scope
[12:57] <ubitux> i'm not motivated for a longer review now though 
[12:57] <ubitux> sorry :p
[13:00] <saste> ubitux, isn't it? set_volume() -> volume_init()
[13:04] <ubitux> in filter_frame(), aren't you doing the switch case outside the eval frame mode?
[13:05] <ubitux> also, i think you're breaking the is_writable() case
[13:06] <ubitux> in case of volume==1.0, and frame !writable, you need copy the data to the new buffer
[13:06] <ubitux> i think you break that case with the goto end thing
[13:14] <BBB> ah bah
[13:14] <BBB> ok fine
[13:15] <BBB> ubitux: wanna start reviewing the asm changes?
[13:16] <BBB> I'll measure later but they did appear slightly faster in quick overall timings (not much, 0.02 sec over 9.2 seconds total, but still, that's 0.2% or so
[13:35] <wm4> why does ffmpeg AVFrame have the number of channels (AVFrame.channels), while Libav doesn't need it?
[13:38] <saste> wm4, libav computes channels from layout IIRC
[13:38] <saste> in case layout is not known, that can be an issue
[13:40] <wm4> well, I don't think Libav are that dumb to miss this kind of essential corner case
[13:52] <saste> wm4, 23fc4dd6e7e150ea163a867dfaee2062ade90b74
[13:54] <wm4> well, whatever
[13:54] <nevcairiel> libav does indeed not support unknown channel layout
[13:55] <wm4> I noticed that my own code uses AVCodecContext.channels as fallback
[13:56] <wm4> a concept of unknown channel layouts would be helpful indeed
[13:56] <wm4> elenril wanted to add a new channel API that would include this
[13:57] <wm4> merry christmess
[14:20] <ubitux> BBB: sure
[14:20] <ubitux> are you done? :)
[14:23] <BBB> ?
[14:23] <BBB> yes
[14:25] <BBB> except for commit msg ofc
[14:25] <ubitux> i'll look tonight probably
[14:30] <saste> in what part of the code are the url options passed?
[14:30] <saste> *parsed
[14:41] <saste> uh...
[14:41] <saste> so we have some protocols which accepts options only in the url (e.g. udp), and others which allow to set the options in the context as well (e.g. tcp)
[14:43] <saste> i also like how there is no real validation, see all the uses of strtol
[14:47] <saste> nice also how the list of options supported in the url can be different from the ones supported in the context
[15:43] <ubitux> saste: do you think we could make showspectrum/showwaves output a picture of the full stream?
[15:45] <saste> i was trying that and it was somehow problematic
[15:46] <ubitux> :(
[15:46] <saste> it depends how much you can "compress" the diagram
[15:46] <saste> alternatively you can create several images and chain them
[15:47] <ubitux> in the current state?
[15:47] <saste> i'm not sure you can do it with showspectrum
[15:47] <ubitux> or with a patch?
[15:59] <saste> ubitux, in theory you can squeeze the output and tile them
[15:59] <saste> in practice there was a problem
[16:00] <saste> i don't remember exactly what was it
[17:27] <wm4> michaelni: elenril says reusing an AVFrame should not leak (ffprove AVFrame issue)
[17:40] <nevcairiel> the important extra would be clearing it before giving it back to the API
[18:34] <BugMaster> http://blog.medialooks.com/0LyGa6/ <- "The filter uses LGPL builds of FFmpeg, is available for commercial licensing and can be used in commercial applications." while using postproc which can be build only with GPL license :-|. at least all other ffmpeg libs looks like to be really compiled with LGPL license
[18:40] <Compn> BugMaster : you realize thats basically just ffdshow :P
[18:41] <BugMaster> I don't use it. I simply found link to it today and read this blog in try to find how it better than LAV Filters
[18:44] <BugMaster> and there argument is mostly is that source/demuxer/decoder filter all-in-one instead of separate entities. iirc ffdshow wasn't all-in-one in this sense (it was multiple filters in one library) but may be I remember wrongly
[18:46] <Compn> youre right it wasnt all in one
[18:46] <Compn> i mean, you had to call it 4 or 5 times to demux, decode, etc
[18:46] <Compn> i think
[18:47] <JEEBcz> ffdshow-tryouts had no demuxing capabilities
[18:47] <Compn> hmmm
[18:47] <Compn> you sure ?
[18:47] <JEEBcz> yes
[18:47] <Compn> i guess the mpcht had the demuxers
[18:47] <Compn> havent used wmp or ffdshow in years anyway
[18:48] <JEEBcz> yeah, mpc and mpc-hc had their own demuxers
[18:48] <JEEBcz> ye olde gabest filters
[18:53] <kierank> BugMaster: lol yet another "pro" thing violating the gpl
[19:00] <Compn> BugMaster : wow they claim mpeg4, h264 and mpeg2 reverse playback
[19:00] <Compn> thats a highly requested feature and rare
[19:01] <Compn> why people want reverse playback who knows :D
[19:01] <kierank> Compn: i-frame only
[19:01] <Compn> Smooth reverse playback
[19:01] <Compn> Another consequence of our design is the reverse playback feature, which is usually available for I-frame encoding formats only (without temporal compression), such as AVC-i and MJPEG.
[19:01] <Compn> With the Multi-Format Source DirectShow filter it is available for most of the supported formats including MPEG-2, MPEG-4 and H.264.*
[19:02] <Compn> i could be wrong
[19:02] <Compn> i didnt test :P
[19:02] <Compn> available for 1450 euro
[19:03] <Compn> whoaaaaaaaaaaa
[19:03] <cone-661> ffmpeg.git 03Alex Sukhanov 07master:251c96a70b0d: avformat/matroskadec: Fix start_time
[19:13] <Compn> violating because it doesnt say how to build it kierank ?
[19:13] <Compn> or providing any source ?
[19:13] <kierank> provide source
[19:17] <kierank> lots of companies troll OSS about violating patents
[19:17] <kierank> I can fight back by saying they violate (L)GPL
[19:21] <nevcairiel> such all in one things are usually rather terrible from a dshow perspective
[19:21] <nevcairiel> of course it makes stuff easier, but why bother with dshow then. :)
[19:22] <kierank> because you can get a team in india to get something working on the cheap
[19:23] <kierank> without knowing what you are doing
[19:32] <nevcairiel> i have been thinking about relicensing my stuff to lgpl since a few companies asked
[19:32] <nevcairiel> was hoping yadif relicense goes through since that's the only gpl i use in ffmpeg
[19:34] <Daemon404> nevcairiel: i dont really understand why you would have to be lgpl?
[19:34] <Daemon404> i ean theyre just going to use it in a filter graph
[19:35] <nevcairiel> they are afraid of GPL
[19:35] <Daemon404> against all logic?
[19:35] <Daemon404> "gpl doesnt affect this use"
[19:35] <Daemon404> "BUT I A AFRAID!"
[19:35] <Daemon404> s/A/AM/
[19:35] <Mavrik> uh
[19:35] <nevcairiel> and honestly i have no clue if COM stuff can be used as gpl, its a bit grey
[19:36] <Mavrik> if you link against other libraries you can quickly have tons of trouble with GPL
[19:36] <Mavrik> since it's incompatible with pretty much anything
[19:36] <Daemon404> Mavrik: a filter graph is not linking
[19:36] <nevcairiel> well you dont link
[19:36] <Daemon404> nevcairiel writes directshow filters.
[19:36] <nevcairiel> they load at runtime
[19:36] <Mavrik> ah yea :)
[19:36] <nevcairiel> indirectly through windows even
[19:36] <Mavrik> but you're right, GPL is like a bogey man for larger companies :/
[19:37] <Daemon404> depends on the comapny
[19:37] <kierank> except when they're outsourcing to india
[19:37] <kierank> indians love their --enable-gpl --enable-nonfree
[19:37] <Daemon404> some companies are ok with gplv2
[19:37] <kierank> and the company asks no questions
[19:37] <Mavrik> had to persuade one of the TV broadcasters to not do a rewrite of whole ffmpeg just because they were afraid of GPL -_-
[19:37] <Daemon404> ive ever seen one ok with gplv3
[19:37] <Daemon404> never*
[19:37] <Mavrik> even though they were their own customer :P
[19:38] <Plorkyeran> sufficiently paranoid companies won't even use GPL tools Just In Case
[19:38] <Plorkyeran> even if they're not distributing anything related to them
[19:39] <Daemon404> if your google, you rewrite everything yourself and license it as apache2
[19:39] <Daemon404> youre*
[19:39] <Daemon404> with c++-only APIs
[19:39] <kierank> lol
[19:40] <kierank> oh lord the medialooks guy is advertising it on linkedin
[19:40] <kierank> it is taking a lot for me not to troll him
[19:40] <Plorkyeran> bad C++-only APIs
[19:40] <Plorkyeran> that don't actually take advantage of anything useful from c++
[19:42] <Daemon404> Plorkyeran: yes
[19:43] <Daemon404> itll literally be exactly like a c api
[19:43] <Daemon404> but with :: instead of _
[19:43] <Daemon404> all static funcs
[19:43] <Daemon404> (is that the right term in c++?)
[19:43] <kierank> public
[19:43] <kierank> ?
[19:43] <Plorkyeran> it's because they actually want to write C
[19:43] <Plorkyeran> but C is not an approved language at google
[19:44] <Daemon404> cant even write extern "C"  for the API?
[19:44] <Plorkyeran> they could provide a C api with a c++ implementation
[19:44] <Daemon404> thats easy for them
[19:44] <Daemon404> int thing_somefunc(int a) { return thing::somefunc(a); }
[19:44] <Plorkyeran> but the issues with c++ apis don't matter for them internally
[19:45] <Plorkyeran> so I guess they just don't bother
[19:45] <Daemon404> yep....
[19:45] <Daemon404> they also do not really do releases
[19:45] <Daemon404> just always use HEAD.
[22:11] <jnvsor> Is BGR0 pixel format deprecated? If not I've found a bug
[22:11] <nevcairiel> its not
[22:11] <jnvsor> Righty then - bug report on it's way
[22:11] <nevcairiel> but how does a bug depend on that
[22:12] <jnvsor> Well I've tracked it down with gdb but the logic is a bit opaque so I wasn't sure if it was supposed to do that or not. I presumed not.
[22:17] <Daemon404> clearly it was supposed to do this, instead of that. or maybe this, then that.
[22:19] <jnvsor> sws_init_context gives a warning if the context->srcFormat changes since the start of the function. But before then it calls sws_setColorspaceDetails which calls handle_formats which calls handle_0alpha which changes the color space
[22:19] <jnvsor> or no not color space, pixel format
[22:20] <jnvsor> But since the warning says the pixel format is deprecated, and you said that bgr0 isn't, at the very least the warning is wrong
[22:29] <cone-255> ffmpeg.git 03Carl Eugen Hoyos 07master:d63e9943615f: avformat/mov: Do not compute a grayscale palette for cinepak in mov.
[22:29] <cone-255> ffmpeg.git 03Carl Eugen Hoyos 07master:691dec62011f: Allow stream-copying grayscale mov files.
[22:55] <cone-255> ffmpeg.git 03Michael Niedermayer 07master:51fed95dde7a: swscale/utils: fix wrong deprecated message with rgb0
[23:29] <cone-255> ffmpeg.git 03Michael Niedermayer 07master:bb9f55163f17: avcodec/eatgv: use av_mallocz() for frame_buffer
[00:00] --- Wed Dec 25 2013