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

[burek]

[00:01] <cone-78> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.5.1': unknown revision or path not in the working tree.
[00:01] <cone-78> Use '--' to separate paths from revisions
[00:01] <cone-78> refs/tags/n2.5.1:HEAD: ffmpeg: Check for subtitle_out malloc failure
[00:25] <Daemon404> i love unchecked allocs you cant fix because its an API function and returns void
[00:25] <Daemon404> A+
[00:27] <ubitux> just set errno!
[00:27] <ubitux> ;)
[00:27] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:5d33142fd621: avcodec/options_table fix min of audio channels and sample rate
[00:27] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:2d39d8ffc1ac: avcodec/utvideodec: fix assumtation that slice_height >= 1
[00:27] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:01384e3dde48: avcodec/wmaprodec: Fix integer overflow in sfb_offsets initialization
[00:27] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:5284d17562f3: avformat/hlsenc: Free context after hls_append_segment
[00:27] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:6c28673cb364: avcodec/mjpegdec: Fix context fields becoming inconsistent
[00:27] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:a65573c45d34: avcodec/utils: Check that the data is complete in avpriv_bprint_to_extradata()
[00:27] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:11e5106c56a0: avcodec/flacdec: Call ff_flacdsp_init() unconditionally
[00:27] <Daemon404> ubitux, avpriv_do_elbg is a wasteland
[00:27] <Daemon404> only used by vf_elbg
[00:28] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:d723f92dbf67: avcodec/pngdec: Check IHDR/IDAT order
[00:28] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:69a92ae39711: avcodec/motion_est: use 2x8x8 for interlaced qpel
[00:28] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:71b3f64935dd: swscale/x86/rgb2rgb_template: handle the first 2 lines with C in rgb24toyv12_*()
[00:28] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:6560e61826d3: avformat/rmdec: Check codec_data_size
[00:28] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:0d5e62619706: swscale/x86/rgb2rgb_template: fix crash with tiny size and nv12 output
[00:28] <cone-78> ffmpeg.git 03wm4 07release/1.2:084102cd47ca: avformat/matroskadec: fix handling of recursive SeekHead elements
[00:28] <cone-78> ffmpeg.git 03Rob Sykes 07release/1.2:8e17d2886368: swresample/soxr_resample: fix error handling
[00:28] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:237958f8e82c: avformat/aviobuf: Check that avio_seek() target is non negative
[00:28] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/1.2:c03491d96b89: Update for 1.2.11
[00:28] <rcombs> switch to xmalloc; deprecate function; replace with version that returns int
[00:28] <Daemon404> avpriv_ dont get deprecation preiods
[00:28] <Daemon404> periods*
[00:29] <rcombs> oh, it's avpriv_?
[00:29] <rcombs> can't you just change it to int then?
[00:29] <Daemon404> no.
[00:29] <Daemon404> because its an ABI break
[00:30] <rcombs> oh, avpriv_* stuff is exposed? :/
[00:30] <Daemon404> avpriv_ means library incest
[00:31] <Daemon404> not public API, but the libav* libs abuse it
[00:31] <Daemon404> i see stefano exported it so he could use it for a posterize filter...
[00:31] Action: Daemon404 sighs
[00:31] <rcombs> well if it's only used internally, what's wrong with changing a return type
[00:32] <Daemon404> it's still an ABI break
[00:32] <Daemon404> version bumps needed
[00:32] <Daemon404> some perverts mix and match libav* versions
[00:32] <rcombs> ah
[00:32] <rcombs> sounds bad
[00:32] <iive> version bumb for all versions that use it.
[00:32] <iive> version bumb for all libraries that use it.
[00:33] <Daemon404> it's literally only used in vf_elbg
[00:33] <Daemon404> which was a stupid think to add a new avpriv_ for
[00:33] <Daemon404> thing*
[02:07] <timothy_gu> Hey guys I can help run a Haiku FATE instance. Is that useful?
[02:37] <michaelni> timothy_gu, yes
[02:41] <michaelni> the haiku client we have currently is kinda unstable so if you/someone has one that work better that would definitifely be preferrable
[02:41] <timothy_gu> michaelni: OK i'll try a test run
[02:42] <BBB> michaelni: see ML for a patch
[02:42] <BBB> I bloody hate win32
[02:44] <cone-78> ffmpeg.git 03Martin Storsjö 07master:6f4364aba9d7: mov: Fix handling of zero-length metadata values
[02:44] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:1a86e29ff0bc: Merge commit '6f4364aba9d70dc5fd9f1c88b9c03bf9ea893d40'
[02:49] <michaelni> BBB, cant see a patch, what is its subject ?
[02:50] <BBB> hm
[02:50] <BBB> gmail apparently has a new security feature
[02:50] <BBB> pushed to github instead
[02:50] <BBB> sec
[02:50] <BBB> https://github.com/rbultje/ffmpeg/commit/d6b6ddfc100a9259c5a58c4d9d8feedd75ea82d0
[02:54] <wm4> Daemon404: they rewrote one of my commits?
[02:54] <wm4> also, my real name is public, if you know where to look
[02:54] <wm4> I just don't include it in patches I post
[03:02] <timothy_gu> Ok, 2 internal compiler error already, with one "unrecognized option -pthread" per file
[03:02] <timothy_gu> *errors
[03:03] <timothy_gu> That is, with the ancient 2.95.3-haiku-2014_07_26 compiler they still keep for compatibility
[03:09] <Daemon404> wm4, google-fu indicates yes
[03:10] <Daemon404> timothy_gu, is haik ureally still on gcc2?
[03:10] <timothy_gu> Daemon404: yeah they have both gcc2 and 4
[03:10] <koda> wm4: yes, you should show more consideration towards michaelni btw
[03:11] <timothy_gu> Daemon404: testing gcc4 later
[03:11] <timothy_gu> Now there are 6 files uncompilable. Testing manually disabling them.
[03:12] <wm4> koda: as in?
[03:13] <koda> wm4: well hes going to have to merge an incompatible change, and do a manual fixup, slowing down his flow and making him lose time
[03:13] <wm4> lol
[03:13] <timothy_gu> Daemon404, wm4: Found it too. Nice scavenger hunt.
[03:13] <koda> wm4: its true :)
[03:14] <Daemon404> im gonna invoke poe's law here
[03:14] <timothy_gu> koda: pretty sure he's used to it now.
[03:14] <koda> timothy_gu: probably, but i still think his time would be much better spent doing other things
[03:15] <timothy_gu> can you disable multiple decoders like --disable-decoder=foo,bar ?
[03:17] <wm4> koda: we all think this
[03:18] <cone-78> ffmpeg.git 03Ronald S. Bultje 07master:0a7964dca5e5: vp9/x86: save one register on 32bit idct32x32.
[03:18] <BBB> ty michaelni 
[03:21] <koda> michaelni: see? even wm4 suggests stopping the merges :)
[03:21] <michaelni> BBB ty for fixing it :)
[03:21] <koda> i dont have a particular problem with those, just that the improvements or bugfixes should be shared, like a good happy foss family
[03:22] <timothy_gu> The way michaelni ignored koda is like so macho
[03:23] <wm4> koda: no
[03:23] <wm4> koda: though I thinkcherry-picking nmight be better
[03:24] <koda> timothy_gu: i like more how he ignored your question about disabling decoders :D
[03:24] <timothy_gu> Surprised gcc 2.95.3 didn't choke on the huge dca tables and hevc files, but atrac3p, cinepak, indeo2, msmpeg4
[03:24] <timothy_gu> koda: well i didn't actually ping him
[03:25] <timothy_gu> but lol
[03:25] <timothy_gu> nobody cares about haiku anyway
[03:26] <Daemon404> i think i met a guy who did once at fosdem
[03:26] <Daemon404> but he was a dev for haiku. so.
[03:26] <timothy_gu> im surprised why they always get picked for GCI
[03:27] <Daemon404> plenty of useless projects do
[03:27] <timothy_gu> but Haiku is actually a nice system for embedded stuff. It is *fast*.
[03:27] <timothy_gu> and takes little RAM
[03:27] <michaelni> koda, maybe iam missing something, but where did i ignore you ?
[03:28] <wm4> timothy_gu: wtf 2.95?
[03:28] Action: michaelni seems not successfull at following the discussion
[03:28] <jamrial> it's mostly trolling, not a discussion. not worth following :p
[03:28] <wm4> lately I had a user who accused me of not caring for users because my project didn't work with gcc 4.1
[03:29] <koda> wm4: lol
[03:29] <timothy_gu> wm4: lol
[03:29] <wm4> he was using linux
[03:29] <timothy_gu> omg
[03:29] <koda> jamrial: personally i am not trolling, i think sometimes discussing the status is a good thing
[03:29] <koda> michaelni: you didnt ignore me, but i think timothy_gu misinterpreted the flow of messages
[03:30] <Daemon404> wm4, ffmpeg only recently dropped 2.95 support
[03:30] <Daemon404> a year or two ago
[03:30] <timothy_gu> wm4: "GCC 2.95 gives Haiku binary compatibility with native legacy applications written for the BeOS.
[03:31] <wm4> oh right, beos nonsense
[03:31] <wm4> using C++ for system ABI sure turned out a great idea
[03:32] <wm4> Daemon404: I iwhs ffmpeg would drop legacy mingw support
[03:32] <michaelni> i think its more "lack of anyone using or testing ffmpeg with 2.95" than intentionally droping support
[03:32] <Daemon404> wm4, me too.
[03:32] <Daemon404> if only to discourage people form using it
[03:32] <Daemon404> from*
[03:33] <michaelni> haiku gcc 2.95 failed building ffmpeg though as long as we had a haiku client though, that isnt recent
[03:33] <timothy_gu> ok
[03:34] <timothy_gu> even the #haiku guys don't seem to care
[03:34] Action: timothy_gu installs ccache
[03:46] Action: Daemon404 stares at the msvc 
[03:46] <Daemon404> 'patch'
[03:46] Action: Daemon404 ignores till morning
[03:50] <koda> Daemon404: its already morning here
[03:52] <cone-78> ffmpeg.git 03Derek Buitenhuis 07master:402a61c9197b: snow_dwt: Don't try and free members of non-existent arrays
[03:52] <timothy_gu> yay ffmpeg links with msmpeg4, vc1, wmv* atrac3p, asv*, mpc7, cinepak, and indeo2 decoders disabled!
[03:53] <Daemon404> probably segfaults
[03:53] <Compn> aww you no liek vc1 ? :P
[03:53] <koda> but but my ideo2 movie collection :(
[03:53] <Compn> ehe
[03:53] <Daemon404> the only indeo2 videos i had came off of napster
[03:54] <Daemon404> or some fasttrack client
[03:54] <timothy_gu> I'm too young to care about Indeo 2
[03:54] <koda> uhh napster, such a long time till i heard of it
[03:54] <Compn> i think i probably picked up an rt21 file back in the day . maybe a movie trailer at 160x120
[03:55] <Compn> :)
[03:55] Action: Compn feels old
[03:55] <Daemon404> the only old file i have on hand is a .dcr
[03:55] <Daemon404> from a digimon adventure mini-cd
[03:55] <Daemon404> cirica early 00s
[03:55] <pross> whips out 'crime patrol'
[03:56] <Compn> napster was really nice in the day
[03:57] <timothy_gu> and it pops up a bunch of integer range errors and "compiler did not align stack variables. You may try recompiling using gcc >= 4.2" well
[03:57] <pross> napster. hardly old. what about 2x dubbing casette tapes
[03:57] Action: Daemon404 slaps pross with a genlock
[03:58] <timothy_gu> pross: that's what my mom did in college (she's an English major in China, and English casettes were pretty useful tools for tests)
[03:58] <pross> i was thinking c64 casettee tapes, but close enough
[03:59] <timothy_gu> now trying gcc 4.8.4
[03:59] <timothy_gu> pross: oh
[04:13] <cone-78> ffmpeg.git 03Christian Suloway 07master:92a596f13bfa: avformat/hlsenc: fix hls_write_trailer() on hls_start() failure
[04:33] <jamrial> the fate page would benefit from separating systems running master and those running stable versions
[04:34] <jamrial> as things are right now the latter feel like clutter, since most are run once every several days
[04:35] <Daemon404> you can query it as such
[04:35] <Daemon404> iirc
[05:01] <timothy_gu> jamrial: It's supported in my new fateserver but I don't have much time working on it right now...
[05:14] <timothy_gu> ffmpeg compiles alright with 4.8 with inline asm disabled. It spits out some errors about contraints not met for inline asm.
[05:14] <wm4> this is why we think inline asm is evil
[05:14] <wm4> (apparently)
[05:23] <Compn> wasnt it just ever so slightly slower than yasm ?
[05:24] <Compn> plus 'ugly' to some people
[05:24] <timothy_gu> Compn: Plus difficulty to read, plus errors on weird platforms.
[05:24] <Compn> oh yeah, it did fix compilation doing that
[05:26] <rcombs> ffmpeg is generally OK with being linked in iOS apps as long as library source and re-linkable application binaries are provided, right?
[06:04] <jamrial> Compn: it's not necessarely slower than yasm. it in fact can be faster since you can, well, inline the stuff in a function instead of having to call a separate one (like with yasm)
[06:04] <jamrial> intrinsics are almost always slower because they depend on the compiler optimizing things right
[10:28] <Elirips> Hello. Is it possible that ffmpeg logs to std-err, not std-out?
[10:28] <nevcairiel> yes, it does
[10:28] <nevcairiel> most of its output anyway
[10:29] <nevcairiel> for the simple reason that it can also output media data to stdout for piping it to another tool for example
[10:50] <Elirips> nevcairiel: ah, i see, thx
[10:54] <Elirips> Are there also static builds for ffserver available ?
[10:55] <Elirips> Or could I run the very old ffserver from debian wheezy that gets it data from a recent ffmpeg? ffmpeg v2.5 and ffserver version 0.8, is that supported?
[11:11] <cone-548> ffmpeg.git 03Paul B Mahol 07master:5f90ef66119e: lavfi: add colorlevels filter
[15:48] <cone-916> ffmpeg.git 03Michael Niedermayer 07master:16d763fa45b9: avformat/hdsenc: Use av_freep() avoid leaving stale pointers in memory
[15:48] <cone-916> ffmpeg.git 03Michael Niedermayer 07master:91ea466551c1: avformat/flvdec: Use av_freep() avoid leaving stale pointers in memory
[15:48] <cone-916> ffmpeg.git 03Michael Niedermayer 07master:b8eb8b03104a: avformat/hlsenc: Use av_freep() to avoid leaving stale pointers in memory
[16:09] <koda> saste: o/
[16:09] <saste> koda, hi
[18:30] <kierank> what's wrong with their resolution?
[18:34] <kierank> lol
[18:35] <Daemon404> i dont get what clemux carl is taking issue with
[18:35] <Daemon404> wow spectacular tab completion fail
[19:37] <cone-916> ffmpeg.git 03Michael Niedermayer 07master:3030fb7e0d41: avcodec/vmdvideo: Check len before using it in method 3
[19:37] <cone-916> ffmpeg.git 03Michael Niedermayer 07master:93a5a16f136d: avcodec/xface: correct the XFACE_MAX_* values
[19:37] <cone-916> ffmpeg.git 03Michael Niedermayer 07master:211200e0c0ef: avcodec/xface: Add asserts to limit nb_words from becoming too large
[19:44] <llogan> what parts of the license and/or checklist are they still violating? carl is not being specific (which is often the case)
[19:45] <llogan> kierank: guess how much the BL software is.
[19:51] <kierank> llogan: dunno
[19:52] <kierank> few grand
[19:52] <llogan> £25K GBP
[19:53] <kierank> fuck me
[19:53] <kierank> is it violating?
[19:53] <llogan> that may include some hardware, but I'm still unsure.
[19:54] <llogan> i haven't been able to get a copy yet, but i think i'm close. they are very careful. now i don't want to mention its name in case they make the connection
[19:54] <Daemon404> holy shit 25k
[19:54] <kierank> Daemon404: remember that guy?
[19:55] <gnafu> Better come with a complimentary compact sedan at that price.
[19:55] <Daemon404> blue lucy?
[19:55] <Daemon404> was it?
[19:55] <kierank> Daemon404: yeah
[19:55] <Daemon404> yeah.
[19:58] <llogan> kierank: Hydra at least seems to be making an effort, AFAICT. do you know what they still have to do? I'm no expert on the license.
[19:58] <llogan> H.Y.D.R.A.
[19:59] <kierank> i think carl has the belief that because they are violators they have lost the right to distribute ffmpeg
[19:59] <kierank> and so need to follow the checklist to be reinstated
[19:59] <llogan> that could scare potential legit users
[20:00] <kierank> i think there is some truth in that but ianal
[20:00] <llogan> oh, apparently the HYDRA from comics is not an acronym.
[20:02] <nevcairiel> its not, its a reference to the mythical creature
[20:26] <kierank> lol
[20:26] <llogan> i was waiting for that reply
[20:27] <JEEBcz> :D
[20:34] <kierank> that's just a threat mind you
[20:37] <ubitux> so what's the matter here?
[20:37] <ubitux> what are they violating exactly?
[20:37] <llogan> now we can expand Legal Threats
[20:37] <kierank> 6:59 PM <"kierank> i think carl has the belief that because they are violators they have lost the right to distribute ffmpeg
[20:37] <kierank> 6:59 PM <"kierank> and so need to follow the checklist to be reinstated
[20:37] <Daemon404> ^
[20:38] <Daemon404> carl just being carl...
[20:39] <ubitux> ah sorry, missed the backlog
[20:40] <cone-916> ffmpeg.git 03Lou Logan 07master:a9a3c005b889: doc/filters: fix typos and spelling errors
[20:48] <JEEBcz> someone rebased the comment history?
[20:48] <JEEBcz> ( Ÿ
[20:48] <iive> it's not like they've lost right to distribute ffmpeg. it's like if they have been count by the RIAA/MPAA in distributing song/movie. they could still be hold liable for their violation.
[20:49] <iive> count/caught
[20:51] <iive> but imho, we should never prosecute "honest mistakes" and violators that react quickly.
[20:52] <koda>  Accusations of breach are a serious matter with legal implications for all parties involved.
[20:52] <koda> wow
[20:52] <koda> tough
[20:59] <ubitux> pouhahaha
[21:00] <kierank> lol
[21:02] <ubitux> i suppose it's at least violating the 11. of the checklist?
[21:02] <ubitux> and 12
[21:02] <ubitux> and 13* i mean
[21:03] <ubitux> ah my bad it's in the pdf
[21:04] <aetas> he's able to close tickets that suggest his own company is violating compliance?
[21:05] <ubitux> 13 still seems to not be in the EULA
[21:05] <ubitux> like, it's saying you can reverse engineer the opensource parts but not the whole thing
[21:05] <ubitux> oh well, IANAL
[21:06] <kierank> Well at least that lawyer is making some money from the dick waving contest
[21:06] <JEEBcz> yes
[21:08] <ubitux> we should make contract with these lawyers
[21:08] <aetas> contract or contact?
[21:08] <ubitux> contract
[21:08] <ubitux> "let's make this dick contest for a few days, and you give us 50% of what you got from your client"
[21:08] <nevcairiel> lol
[21:09] <aetas> I wouldn't, from reading the ticket it doesn't even look like he knows for sure what his own name is
[21:09] <ubitux> :))
[21:11] <aetas> I can't believe the company owner would close a ticket against his own company, something seems slightly wrong about that
[21:20] <ubitux> akira4: indev is the "demuxer" equivalent (a device which you get things from), outdev is the "muxer" equivalent (a device which you output to)
[21:20] <ubitux> akira4: so dvd is an input device
[21:20] <akira4> yeah. I figured it out the hard way :P
[21:21] <akira4> btw, I can't figure out what to do for adding the configuration for libdvd* 
[21:21] <akira4> I mean changing the configure script
[21:21] <ubitux> in configure?
[21:21] <akira4> yep
[21:22] <ubitux> look around line 4850 first
[21:22] <ubitux> you will do something like enabled libdvdnav && require_pkg_config dvdnav ...
[21:23] <ubitux> then you look for "# indevs / outdevs" in that configure
[21:23] <ubitux> and you add a dvd_indev_deps="libdvdnav" or something like that
[21:23] <ubitux> then when you ./configure --enable-libdvdnav it should automatically enable both the library and your indev
[21:23] <ubitux> you can check that by doing grep -i dvd config.h after a ./configure
[21:24] <akira4> alright thanks.
[21:25] <akira4> Oh yeah, you said that I should use AVFormatContext.filename to open the ISO file right?
[21:25] <ubitux> yeah
[21:25] <ubitux> iirc
[21:25] <ubitux> look how openal does it
[21:26] <akira4> right. I'll check it.
[21:34] <aetas> Is it possible to change dts/pts for a video frame without having to go through decoding it and re-encoding it?  I was always curious since all the filters require some form of transcoding
[21:34] <aetas> specifically for video
[21:34] <ubitux> depends what you mean by changing them, but a few ops are possible yeah
[21:34] <ubitux> like -itsoffset or something like that iirc
[21:35] <aetas> I process a lot of video that has big gaps between the video frames and I'd like to be able to shrink them down to a maximal value without going through the lengthy process of decoding and re-encoding
[21:40] <aetas> I assumed i"d have to do something like that in code since it would normally have to be done in a filter
[21:46] <aetas> what i do right now is process an input file that has video and audio and if I find a gap between video frames, then I trim both the video and audio streams, setpts to 0 on both, and then concat each of the trims but would like to do it in runtime
[22:00] <timothy_gu> lol on carl's response
[23:05] <cone-916> ffmpeg.git 03Michael Niedermayer 07master:388160624095: avcodec/utvideodec: Fix handling of slice_height=0
[23:50] <cone-916> ffmpeg.git 03Michael Niedermayer 07master:caa7a3914f49: avformat/mov: check atom nesting depth
[23:50] <cone-916> ffmpeg.git 03Michael Niedermayer 07master:be9ce6e10a8d: avformat/mov: fix integer overflow of size
[23:50] <cone-916> ffmpeg.git 03Michael Niedermayer 07master:2a983ff7fe07: swscale: increase yuv2rgb table headroom
[00:00] --- Wed Dec 17 2014