[00:01] <wm4> looking at the code, maybe not [00:01] <pross-au> wm4: do they still forbid mp3? [00:01] <wm4> pross-au: no idea if that's a thing of the past [00:02] <wm4> Timothy_Gu: so I suppose you don't really need to, but checking it anyway might be better style [00:03] <Timothy_Gu> I am asking because there are _tons_ of unchecked avio_tell() calls in matroskadec.c [00:04] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:2a85826e5753: avcodec/vp9: Use av_malloc_array() [00:04] <cone-798> ffmpeg.git 03Christophe Gisquet 07master:6ee7681723a4: huffyuvenc: write last odd sample [00:04] <cone-798> ffmpeg.git 03Christophe Gisquet 07master:f75baa6c9b17: huffyuvdec: decode the last odd sample [00:04] <kepstin-laptop> pross-au: as of fedora 20, they still don't include mp3 decoding. [00:04] <Timothy_Gu> pross-au: at least we have Fluendo now [00:06] <wm4> Timothy_Gu: then maybe it would be better to adjust the documentation to say it never fails [00:07] <Timothy_Gu> Does it not? [00:07] <Timothy_Gu> Well this was my original question: does avio_tell() ever makes avio_seek() fail? [00:07] <Timothy_Gu> *make [00:08] <beastd> I would rather say. Think what would happen if it fails -- what would the code of the mkv demuxer do? [00:08] <beastd> Especially if it returns either error or position [00:10] <Timothy_Gu> ... do weird stuff and not demux properly? [00:10] <beastd> Might be OK to ignore errors, but only if you can say the code will still behave safe in that case. [00:12] <Timothy_Gu> For example, http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/matroskadec.c;h=8... passes a potential negative value into resync() [00:12] <Timothy_Gu> which uses the value in avio_seek(), and seek backwards instead of forwards [00:13] <Timothy_Gu> And all kinds of weird problems may appear [00:31] <beastd> Timothy_Gu: that could possibly checked inside the internal matroska_resync . also other cases are just for error messages (though i am not sure they are treated as unsigned for error output). you could also write a mail to ffmpeg-devel and ask if others have better ideas how to proceed. i would examine each instance, categorize and then do fixes if needed [00:32] <Timothy_Gu> Thanks! I am a little bit short on time right now, but I will do what you suggested once I find time. [00:33] Action: beastd too [00:34] <beastd> Will go to sleep soon. [00:39] <cone-798> ffmpeg.git 03Alexander Strasser 07master:db85d11d9d88: libavformat/ftp: Do not leak memory in routine ftp_features [01:20] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:e96109f93ce9: ffplay: use av_malloc_array() [01:20] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:1f7e6c07130c: doc/snow: remove possibly wrong todo item [01:49] Action: cbsrobot_ wonders what is so patentable in this "Dreamworks Lossy Compression" [01:50] <cbsrobot_> https://github.com/openexr/openexr/blob/master/OpenEXR/IlmImf/ImfDwaCompress... [01:50] <cbsrobot_> looks like just another jpeg implementation [01:55] <Daemon404> of course [01:55] <Daemon404> it is patented after all [01:55] <Daemon404> of course it is not novel. [01:56] Action: llogan prefers lena over flower [01:58] <wm4> so who will implement native openexr in ffmpeg? [01:59] <Daemon404> exr.c is a thing [01:59] <Daemon404> just needs the mode [02:00] <Daemon404> im impressed how large this file is [02:00] <Daemon404> for what it does... [02:12] <wm4> lol no more lena [02:17] <Daemon404> wtf is even patented in this [02:22] <llogan> the 1970's [02:22] <Daemon404> my only guess its its dumb ad-hoc quant method [02:22] <Daemon404> is* [02:26] <Timothy_Gu> Seems like Andreas forgot my copyright... [02:29] <michaelni> llogan, if you dont lie flower.pnm, suggest another image [02:29] <michaelni> maybe bikeshed.pnm ;) [02:30] <llogan> who knows...maybe i'll actually take a photo of a bikeshed [02:30] <wm4> but what color will the shed have [02:30] <wm4> *should [02:34] <michaelni> Timothy_Gu, where did he forget it ? in git or that patch ? anything i can fix ? [02:35] <Timothy_Gu> In debian/copyright [02:35] <michaelni> ahh ok, i cant help with that i think [02:35] <Timothy_Gu> Is Lena still alive? [02:36] <michaelni> dunno, she was a few years ago though AFAIK [02:52] <cone-798> ffmpeg.git 03ThomasVolkert 07master:96b2ba68c4ae: avformat/rtpdec: support for HEVC/H.265 RTP payload format (draft v6) depacketizing [03:46] <jamrial> michaelni: what libvpx version do you have? VP9E_SET_AQ_MODE is available in 1.3.0, the first one with vp9 en/decoder [04:26] <rcombs> anyone around who can tweak fflogger? It's not zero-padding color codes to 2 digits, so names that start with [0-9A-Fa-f] throw off coloring [04:27] <llogan> that's burek but he's MIA [04:27] <rcombs> and a name starting with ",2" or something (which would be pretty weird, but not unheard of) would probably screw up the background color as well [04:27] <llogan> burek021 at gmail [04:27] <rcombs> alright, I'll mail him [04:27] <llogan> thanks. [04:28] <llogan> also, i don't think you need to cc yourself to your own bug reports. i think it will automatically email you any updates [04:28] <rcombs> I'm not sure, as it varies between trackers; there was a checkbox to CC myself, so I clicked it [04:28] <llogan> no big deal. just letting you know. [04:29] <rcombs> figured it wouldn't be there if it wasn't necessary [04:29] <rcombs> yeah, gotcha [04:29] <llogan> burkes builds have been halted since 16 july. asked him twice if he could resume them. no reply, so once relaxed starts providing 32 bit builds i'll update downloads [04:30] <rcombs> 01,00hmm, is this default or not [04:30] <rcombs> nope [04:36] <rcombs> well, I won't hold my breath for a response, but sent [04:49] <michaelni> jamrial, iam not sure but ive a source tree for v1.2.0-4277-gc73e441 here so maybe that [04:53] <jamrial> ah, a git snapshot. makes sense there's stuff missing [04:53] <jamrial> we should probably update the configure check, then. make it check for VP9E_SET_AQ_MODE instead of VP9E_SET_SVC [05:53] <cone-798> ffmpeg.git 03James Almer 07master:c2c56d54ee90: configure: update libvpx_vp9_encoder check [09:23] <ubitux> michaelni: [09:23] <ubitux> Applying: tests: switch to a test image that is under public domain [09:23] <ubitux> fatal: corrupt patch at line 3322 [09:30] <ubitux> michaelni: could you make flower.pnm available somewhere? [10:27] <saste> how can I know which metadata fields are supported in a given format? [10:28] <saste> unsupported fields are simply ignored at the moment [10:48] <ubitux> saste: wm4 asked something similar yesterday [10:48] <ubitux> currently we store random tags in a given format from metadata even though they sometimes don't make sense [10:48] <ubitux> are you talking about that? [10:49] <saste> ubitux, and my answer is, there is no automatic way [10:49] <saste> ubitux, yes more or less [10:51] <saste> also I'm discovering that sometimes output metadata is silently discarded [11:10] <michaelni> ubitux, http://ffmpeg.org/~michael/flower.pnm [11:10] <ubitux> thx [11:11] <ubitux> cool ok [11:29] <nevcairiel> lena is not free to use? everyone uses it, we even used it in university :p [11:32] <ubitux> not "DFSG-free" apparently [11:33] <nevcairiel> they wouldnt accept free beer in a pub if it doesn't come with a written letter that you relinquish all rights to it [11:33] <ubitux> it seems to be potentially problematic for debian [11:34] <nevcairiel> apparently so [12:24] <cone-840> ffmpeg.git 03Diego Biurrun 07master:ab56fabe6294: vfwcap: Add fallback define for HWND_MESSAGE [12:24] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:d5ee74e57d44: Merge commit 'ab56fabe6294524e99815451ad01e4ff50c6d734' [12:34] <pross-au> a flower? [12:36] Action: ubitux sends https://www.youtube.com/watch?v=AULG4MoYxQk to pross-au with love [12:48] <J_Darnley> > vfwcap: Add fallback define for HWND_MESSAGE [12:48] <J_Darnley> > Some obsolete versions of the MinGW32 runtime (<4.0.0) lack the definition. [12:48] <J_Darnley> Wasn't that the point of dropping the fallback? [12:49] <nevcairiel> he didnt expect it to actually break anything :p [13:06] <cone-840> ffmpeg.git 03Luca Barbato 07master:a4d3c2003594: vc1: Fix the skip condition [13:06] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:ba650ea11825: Merge commit 'a4d3c20035946cbc1509aec2dc28d51c2a2f9a8e' [13:32] <Eftekhari> hi [13:34] <Eftekhari> i have ffserver, when feed is larger than 2 GB, if ffmpeg that feed the ffserver exit, re executing the ffmpeg to feed the server not working, with the error : Error reading write index from feed file '/tmp/feed1.ffm': Resource temporarily unavailable [14:13] <cone-840> ffmpeg.git 03Luca Barbato 07master:4e9e6fa99f3f: mpeg: Write H264 streams at offset 2 [14:14] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:cf0e8e7ad488: Merge commit '4e9e6fa99f3ff83cedbf6c378d62065ae419a3b9' [14:47] <durandal_1707> doesnt libav use lena? [14:51] <nevcairiel> Probably, its been part of fate for ages [14:55] <michaelni> Eftekhari, ask reynaldo / wait till he is here [15:30] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:85f0bde4f07d: avcodec/snowenc: remove out-commented assert [15:30] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:bf16872feca8: avformat/nsvdec: fix out-commented asserts so the function names exist [15:30] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:46ad2c4aeddf: avformat/utils: remove assert that tests the same condition as the if() directly above [15:42] <ubitux> lol blackberry mail [15:46] <nevcairiel> Fun [15:48] <Daemon404> what is this ridiculous lena removal patch? [15:49] <Daemon404> oh. debian. [15:49] <Daemon404> fuck them. [15:49] Action: Daemon404 sighs at freetards [15:52] <nevcairiel> They are the best kind of people [15:57] <Daemon404> let's not use Lena, the standard test image, because IT IS NOT FREE ENOUGH [15:57] <ubitux> let's hide it in a xor-ed .c [15:57] <ubitux> and generate it on the fly [15:57] <Daemon404> it seems beyond stupid to change the regression testing image for DFSG... [15:57] <Daemon404> users dont get that [15:57] <Daemon404> and the debian daemons have no internet [15:57] <Daemon404> so... [15:57] <Daemon404> (a run with just asynth/vsynth is kinda dumb) [16:00] <ubitux> i guess our packager is getting bored after a few months waiting for the ftp-masters to get the shit done [16:00] <nevcairiel> Yeah its not even distributed by debian [16:00] <nevcairiel> Whz do they care again [16:00] <nevcairiel> Why* [16:01] <ubitux> it's only present in the sources but they do actually distribute the sources [16:01] <Daemon404> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758442 [16:01] <Daemon404> freetards gonna freetard [16:01] <Daemon404> it is utterly inconsequential [16:01] <nevcairiel> We should tell them that there is hundreds of patents on the things avcodec implements [16:01] <nevcairiel> See the chaos ensue [18:48] <Daemon404> ugh [18:48] <Daemon404> i see we dont use pkg-config for e.g. vorbis either [18:48] <Daemon404> sigh. [18:58] <ubitux> wanna try to switch to? [18:58] <ubitux> ;) [18:58] <ubitux> i'm fighting for months to get it for libx264 [19:05] <Daemon404> ubitux, i dont feel like dealing with an autistic person [19:20] <Daemon404> man i feel silly [19:20] Action: Daemon404 uses -c:v libxvid [19:47] <llogan> Daemon404: why libxvid? [19:50] <Daemon404> reasons [19:50] Action: llogan leaves to have more engaging discussion with a wall [20:06] <wm4> so I guess this API mailing list idea failed... because of Libav [20:07] <Daemon404> of course [20:08] <llogan> maybe the formatting of the message was not correct [20:15] <cone-840> ffmpeg.git 03Hii 07master:604c4eab2bf6: libx264: fix -b_qfactor and -chromaoffset [20:25] <jamrial> wm4: what did you expect? they know they control the api as long as ffmpeg tries to be compatible because debian. why would they play ball unless they are forced to? [20:29] <kierank> wm4: of course because nobody talked to libav about it... [20:30] <kierank> which was my exact point [20:30] <kierank> the other day [20:30] <kierank> jamrial: they control the api because ffmpeg merges from libav [20:30] <kierank> not because of debian [20:31] <wm4> kierank: I mentioned it on irc, but nobody cared [20:31] <kierank> because it is an ffmpeg initaitve [20:32] <kierank> my point to ubitux is you have to do these things as a joint initiative [20:32] <wm4> but Libav was always blaming ffmpeg for not making a step towards cooperation [20:32] <kierank> which is would ideally be a result of a face to face conversation [20:32] <kierank> wm4: libav is blaming micahel [20:32] <kierank> which is largely true [20:33] <wm4> in this case ubitux just made a suggestion, how else would he even start a "joint initiative"? [20:33] <wm4> but Libav remained silent [20:33] <kierank> by turning up in a neutral environment (vdd) and proposing it [20:33] <kierank> ubitux was saying MLs are the best place for these things etc [20:36] <wm4> and this is your proof that it doesn't work? [20:39] <kierank> the opposite [20:39] <cone-840> ffmpeg.git 03ThomasVolkert 07master:e15824e75b55: avformat/rtpdec_h261: Fix sanity checks [20:39] <kierank> ubitux was saying all the issues could be solved on the ML and not face-to-face [20:39] <kierank> and he said what kinds of things could be discussed face to face [20:39] <kierank> i proposed an api mailing list [20:39] <kierank> he said he's send an email [20:39] <kierank> he'd* [20:39] <kierank> and he did and libav ignored it as expected [20:41] <llogan> and what did we learn here? never try. [20:41] <wm4> and you're claiming it magically works better in the real world [20:41] <j-b> ,agic [20:41] <wm4> the same where Diego's appearance could apparently silence the whole table (lol) [20:42] <j-b> wm4: tbh, being face to face improves communication. [20:42] <j-b> wm4: so, when do we start our fork? [20:42] <wm4> fork of what? [20:42] <j-b> ffmpeg :) [20:43] <wm4> yes you should totally fork it! [20:43] <kierank> I hope you say both ffmpeg and libav and avconv are deprecated [20:43] <j-b> kierank: ah, that's sure. [20:43] <j-b> kierank: I would remove a lot of things. [20:43] <wm4> like what? [20:43] <llogan> kierank: and "no longer developed anymore" [20:43] <kierank> like what? [20:44] <j-b> libavfilter, libavresmaple, libpostporc, libwsresample, libwscale [20:44] <j-b> for a start [20:44] <kierank> lol [20:44] <wm4> but not libavdevice? [20:44] <j-b> then, ffmpeg, ffserver, ffprobe and the rest [20:45] <kierank> j-b: not libavformat? [20:45] <j-b> wm4: it seems too tangled with libavformat [20:45] <j-b> kierank: idem [20:45] <wm4> and the removed stuff will actually end up in separate repos, right? [20:45] <j-b> so, a core repo with libavcode+liavformat+libavutil [20:45] <j-b> wm4: yes. [20:45] <wm4> sounds sensible [20:45] <j-b> wm4: so, the tools will not violate the internal symbols [20:46] <j-b> and libav/ffmpeg developers will finally eat their own shit about APIs [20:46] <wm4> one small problem is that you actually need all repos from the start, because the FATE depends on all the things [20:46] <j-b> and have ffmpeg and ffplay to work with 2 or 3 versions of libavcodec and libavfilter [20:46] <wm4> oooh you're cruel [20:46] <nevcairiel> I think the .v files are pretty much empty by now, at the very least [20:47] <wm4> that would force the devs to actually care about compat [20:47] <j-b> wm4: so? it's not hard to split. and use subfilter. [20:47] <j-b> oh, and tools also would split. [20:47] <nevcairiel> But it also means they can't use any new APIs, which is not very good for innovation [20:47] <j-b> Bullshit. [20:47] <j-b> it's called ifdef [20:48] <cone-840> ffmpeg.git 03Diego Biurrun 07master:4c8bd8ddb049: os_support: Adjust an outdated #endif comment [20:48] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:7206221d563e: Merge commit '4c8bd8ddb049950347a5018fecbca7ee25d48c44' [20:48] <j-b> and you should know that "innovation" is a bullshit word. [20:48] <nevcairiel> If you want half the thing not working with some old version, sure. :p [20:48] <j-b> half the things? [20:48] <j-b> exageration much? [20:49] <j-b> we manage to compile VLC with lavc HEAD and a version from debian stable. [20:49] <wm4> what j-b suggests sounds pretty much how things ideally should be [20:49] <j-b> without too much hassle [20:49] <j-b> AND, we compile against 3 forks [20:50] <j-b> so please, no "innovation blabla" BS, to hide laziness and go on abusing symbols. [20:50] <iive> 4 [20:50] <nevcairiel> There is 3 forks now? [20:50] <iive> ffmb [20:50] <j-b> and sorry, for once, I'm not smooth. [20:50] <j-b> iive: 4? [20:50] <wm4> and of course half a dozen of open or closed projects with their own changes [20:51] <j-b> yeah [20:51] <nevcairiel> Those mostly don't go revising API much [20:51] <iive> bcourdier have its own fork. gpl probably still uses the original api. [20:52] <iive> imho, if libav wanted ffmpeg to stop merging, they should relicense it as GPL only. [20:52] <j-b> and, as I said, one maintainer for each submodule. [20:52] <j-b> iive: they don't wnat ffmpeg to stop merging, they just ignore and not care about ffmpeg. [20:53] <iive> and please steamline the api. no more than 4 function. open, close, decode, encode. [20:53] <cone-840> ffmpeg.git 03Gabriel Dume 07master:56a721f02027: doc: fix a typo [20:53] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:ffa90d99fd89: Merge commit '56a721f020273d69daa8dcb0d99e42a43a0a0d4d' [20:54] <nevcairiel> I always have to grin when they talk about an issue long solved in FFmpeg but it would never even occur to them to check [20:54] <j-b> nevcairiel: indeed. [20:54] <j-b> nevcairiel: however, usually their fixes are better. [20:54] <wm4> j-b: how to make sure that the fork won't fall into obscurity from the start? [20:54] <wm4> it's hard to force others to their luck [20:54] <j-b> I have more security issues on FFmpeg than libav, for example [20:54] <iive> wm4: simply, by replaceing both libav and ffmpeg in debian! [20:55] <j-b> wm4: that's the hard part :) [20:55] <wm4> and who will do the grindwork of cherry-picking patches from ffmpeg/libav (and distributing them over 6 repos ro so) [20:55] <wm4> *or [20:55] <j-b> someone paid fulltime [20:55] <iive> you can ask michael :P [20:56] <j-b> I already said that at the time of the move to git [20:56] <j-b> and at the time of the split [20:56] <j-b> so, it has not changed. [20:56] <nevcairiel> That doesn't sound like a fun job, merging stuff for a living [20:56] <JEEB> I at one point wanted to fix a thing in the MXF (?) demuxer or so, and of course wanted to have it fixed in both, so I decided to first update it into libav and then it would flow into FFmpeg. Then I noticed that FFmpeg had widely updated that stuff. And then I learned that the backport would most probably be nope'd, so I just gave up [20:57] <JEEB> lörs laeraed [20:57] <j-b> JEEB: use VLC and the BBC demuxer [20:57] <j-b> nevcairiel: Linus does it. [20:57] <JEEB> probably a good idea [20:57] <JEEB> but at this point I don't even care [20:57] <JEEB> I will at some point finish my earthsoft dv rewrite [20:57] <wm4> j-b: actually, if you find such a person who wants to play maintainer for such a large project, you can just ask him to take over ffmpeg maintainership [20:57] <j-b> until then, more hentai playback on VLC! :D [20:57] <JEEB> (welcome to me saying this since 2013 or so) [20:58] <nevcairiel> j-b: he also has frequent outbursts at devs to balance himself [20:58] <j-b> nevcairiel: of course, but he does it correctly, with justice. [20:58] <wm4> and then we'll see if michaelni's offer is real [20:58] <j-b> wm4: as soon as I get 500k¬ per year more [20:58] <j-b> I'd hire 2. [21:03] <nevcairiel> Hrm why does vaapi need to link against something, vdpau doesn't. :( this makes distributing binaries more annoying [21:05] <wm4> because there are major vaapi api calls in the decoder [21:06] <nevcairiel> I wonder if libva is at least installed on most distros [21:06] <wm4> probably [21:06] <nevcairiel> My Debian seemed to have it on a fresh install [21:07] <wm4> even the emulation wrappers are often installed (like vdpau libva backend) [21:07] <nevcairiel> Well I'll discuss it with a colleague [21:08] <nevcairiel> I would prefer to start with vdpau myself, but we sell some hardware with an Intel GPU, so that's high on the priority list [21:09] <wm4> there's also a wrapper that emulates vdpau via libva [21:09] <wm4> and opengl [21:10] <nevcairiel> Do such wrappers work? [21:10] <nevcairiel> And work well? [21:10] <wm4> you'll have to see for yourself [21:11] <wm4> they probably incur quite some overhead [21:12] <ubitux> <+kierank> ubitux was saying all the issues could be solved on the ML and not face-to-face // no, i'm defending the point that if they can't communicate with ML, face-to-face will not solve anything [21:13] <kierank> ubitux: it's the other way round altogther [21:13] <kierank> that's my point [21:13] <ubitux> they're hiding behind this "they are autistic and can't talk face to face so we won't talk virtually" [21:14] <ubitux> and we are saying if they can't talk virtually then there is no point in trying to communicate with a worth medium (at least that's my opinion) [21:14] <kierank> no they just can ignore your emails [21:14] <kierank> whereas face to face they can;t [21:14] <ubitux> if they want to ignore the mails then they don't want to communicate [21:14] <ubitux> then there is no way i'm going to force them [21:14] <ubitux> or play their game irl [21:24] <wm4> IRL you just can turn it into a fist-fight!!!1 [21:52] <cone-840> ffmpeg.git 03Gabriel Dume 07master:0a024268261d: libxvid: K&R formatting cosmetics [21:52] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:9c41b59423bb: Merge commit '0a024268261d05ccdcf7e03c85fb78d22037a464' [22:08] <cone-840> ffmpeg.git 03Vittorio Giovara 07master:e87f5e4e5f2e: h264: fully check cropping amount from sps [22:08] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:570397c73115: Merge commit 'e87f5e4e5f2e2e36b0b7826d708cda7049877af0' [22:22] <jamrial> michaelni: did Thomas Volkert ever send the hevc rtp patch to the ml? [22:22] <jamrial> can't find it, and wanted to point him to http://fate.ffmpeg.org/log.cgi?time=20140826140938&log=compile&slot=x86_64-archlinux-gcc-ddebug [22:35] <michaelni> jamrial, dunno, there was a pull request on github [23:09] <llogan> i always forget about those [23:11] <wm4> so there are things that are reviewed (by some) and pushed, which never make it through the ML? [23:12] <llogan> https://github.com/FFmpeg/FFmpeg/pulls [00:00] --- Wed Aug 27 2014