[00:00] <BBB> if its stack it should be LOCAL [00:00] <BBB> and why does vp8 go there? [00:01] <durandal_1707> well i need to double check (enabling symbols, etc...) [00:05] <durandal_1707> i just looked at x86/h264_qpel and it use DECLARE_ALIGNED for stack [00:11] <durandal_1707> actually crash is in ff_vp8_v_loop_filter16y_inner_sse2 [00:13] <durandal_1707> which doesn't make sense as that is covered by yasm [00:20] <BBB> -eneedmoreinfo [00:57] <cone-52> ffmpeg.git 03Paul B Mahol 07master:79b70e47a463: w64dec: fix skipping of unknown guids [00:58] <saste> did someone compare deshake and libvidstab? [00:59] <durandal_1707> deshake is awfull, libvidstab is little better [01:00] <durandal_1707> (from other people experience - not me) [01:01] <saste> durandal_1707, thanks [01:02] <saste> durandal_1707, is phase supposed to fix the same problem as fieldorder (but in a different way)? [01:02] <durandal_1707> i think you could search & read older irc logs... [01:03] <saste> what about the old transcode stabilizer? [01:03] <saste> i'm asking because i had a discussion with a guy about that [01:03] <durandal_1707> not at all [01:03] <durandal_1707> what guy? [01:03] <saste> i was convinced that deshake used the same algorithm [01:04] <saste> (as the transcode stabilizer) [01:05] <saste> the guy - a vlc dev [01:05] <durandal_1707> fieldorder filter changes top to bottom or vice versa (for same frame) [01:06] <saste> durandal_1707, yes [01:06] <durandal_1707> what algorithm? [01:08] <saste> durandal_1707, same algorithm == equivalent implementation/port [01:09] <durandal_1707> but what/where in codebase (i'm not on simple english class) [01:09] <durandal_1707> you mean deshake use same code as phase? [01:11] <saste> durandal_1707, what a confusion, no [01:11] <saste> i was asking if there is any relation between the transcode project stabilizer and deshake [01:12] <saste> fieldorder/phase is a separate topic [01:13] <durandal_1707> saste: i didn't looked closely at deshake/stabilizer/whatever [01:13] <GoaLitiuM> btw, any plans on supporting intel quick sync encoding? [01:15] <durandal_1707> i don't think it is on TODO list [01:15] <durandal_1707> but we do not have TODO list at all [01:19] <Compn> GoaLitiuM : someone was talking about that on the list [01:19] <GoaLitiuM> recently? [01:19] <Compn> no [01:19] <Compn> probably when it was announced [01:19] <Compn> at least that , or my memory is making up timestamps again [01:21] <durandal_1707> if it is on bug tracker, at least someone could see it have been at least requested [01:22] <durandal_1707> ah here it is: http://trac.ffmpeg.org/ticket/2591 [01:24] <durandal_1707> and there are some patches floating on fork side [03:06] <cone-52> ffmpeg.git 03Paul B Mahol 07master:3e36dc8626f4: w64dec: fix end position of summarylist guid [03:29] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:cc84f3040261: avutil/fifo: assert that theres enough data in the fifo on drain calls. [05:16] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:92b7e7b31817: avfilter/vf_yadif: reallocate frames if strides differ [11:08] <ubitux> ffmpeg -f lavfi -i testsrc -t 5 -pix_fmt yuva420p -c:v libopenjpeg -y test.avi [11:08] <ubitux> funny output ^ [11:26] <ubitux> anyone has interesting samples with alpha layer? [11:27] <Compn> i only know of that one lara shadow one [11:28] <Compn> vp6a [11:44] <ubitux> Compn: can you share? i'm interested [11:53] <ubitux> btw, don't we have a public function for: [11:53] <ubitux> int has_alpha = desc ? desc->nb_components % 2 == 0 : 0; [11:53] <ubitux> ? [13:49] <Compn> ubitux : larashadow_dl.flv [13:49] <Compn> ubitux http://samples.ffmpeg.org/FLV/flash_with_alpha/ [13:50] <ubitux> Compn: thanks [13:50] <Compn> i think someone made a command line to get it to display, using ffmpeg filter [13:50] <Compn> but i forgot the command line [13:50] <Compn> it should be in irc log [13:50] <Compn> http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2013-June/001425.html [13:51] <Compn> you were there even :) [13:51] <ubitux> it's fine [13:51] <ubitux> im using mpv -vo opengl:alpha [13:51] <Compn> what kind of samples did you want ? [13:51] <ubitux> (+xcompmgr) [13:51] <ubitux> that kind of sample :) [13:51] <ubitux> that one is fine thx [13:51] <Compn> oh ok [13:52] <Compn> ah [13:52] <cone-105> ffmpeg.git 03Anton Khirnov 07master:8aba7968dd60: vcr1: add sanity checks [13:52] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:8ba683e629bd: Merge commit '8aba7968dd604aae91ee42cbce0be3dad7dceb30' [13:52] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:164b67ca281f: avcodec/vcr1: replace redundant checks from libav (8aba7968dd604aae91ee42cbce0be3dad7dceb30) by asserts [13:52] <Compn> hows mpv going ? some people asked me about mplayer forks :) [13:52] <ubitux> it's going pretty well so far afaict [13:54] <durandal_1707> unlike mplayer it supports lavfi [13:55] <ubitux> and it's usable to watch animes too [13:56] <Compn> oooo, lavfi support [13:56] <Compn> well it was suggested to add it to mplayer, but the api was changing [14:13] <cone-105> ffmpeg.git 03Anton Khirnov 07master:5f7aecde02a9: pictordec: break out of both decoding loops when y drops below 0 [14:13] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:efb21b0a8fbc: Merge commit '5f7aecde02a95451e514c809f2794c1deba80695' [14:16] <cone-105> ffmpeg.git 03Anton Khirnov 07master:fe9bb61f9a16: pictordec: pass correct context to avpriv_request_sample [14:16] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:1eb151c501ec: Merge commit 'fe9bb61f9a16be19ad91875632c39e44b7a99a8a' [14:18] <cone-105> ffmpeg.git 03Compn 07master:8d14596bc241: riff: add 0x64 to g726 works on g726-test1.wav [14:29] <cone-105> ffmpeg.git 03Anton Khirnov 07master:fab694dd3931: lavf: move a variable declaration to the block where it's used [14:29] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:b0ba2bf8c66f: Merge commit 'fab694dd3931b1c0bc3c598c3f88b1902c14a303' [14:38] <durandal_1707> what does MP_IMGFIELD_ORDERED means? [14:47] <Daemon404> google says if MP_IMGFIELD_ORDERED is set, then teh field order is known [14:47] <Daemon404> and you can check for TFF or BFF [14:47] <Daemon404> i dont know why you would do it this way [14:47] <Daemon404> but it's shitty mplayer code... unsurprising [14:48] <nevcairiel> i would like such a flag in ffmpeg, tbh. You never know if it just defaults to bff or if the bitstream actually said so [14:48] <Daemon404> how would that make a difference? [14:48] <Daemon404> if you dont know, you have to guess anywa [14:48] <Daemon404> y [14:49] <nevcairiel> sure, but ffmpeg doesnt guess, it just defaults to tff=0 [14:49] <Daemon404> well ideally you would have two flags: one for bff, one for tff [14:49] <Daemon404> if neither is set, then you dont know [14:49] <Daemon404> a third flag is redundant [14:49] <durandal_1707> and what if both are set? [14:50] <nevcairiel> implementation is irrelevant, i just would like to identify the "unknown" case [14:50] <Daemon404> indeed [14:50] <Daemon404> durandal_1707, http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-March/024931.html [14:50] <Daemon404> this should contain all the info you need [14:50] <cone-105> ffmpeg.git 03Anton Khirnov 07master:df33a58e5311: lavf: avoid integer overflow when estimating bitrate [14:50] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:d07d54fd5603: Merge commit 'df33a58e5311ee9a64a573889b883a80e981af7b' [14:50] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:a5d67bc796e1: avformat/utils: Fix bitrate overflow check [14:51] <Daemon404> yay, the fix wasnt in the merge commit! [14:51] <Daemon404> and it has an explaation [14:51] Action: Daemon404 cheers [14:52] <nevcairiel> the original check did indeed look a bit funky [14:58] <cone-105> ffmpeg.git 03Anton Khirnov 07master:a7c1689dedd1: 4xm: check that bits per sample is strictly positive [14:58] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:bdb4ed963f7e: Merge commit 'a7c1689dedd11689edb30088d467ac03f9b8d1cf' [15:05] <cone-105> ffmpeg.git 03Anton Khirnov 07master:488b2984fece: ape demuxer: check for EOF in potentially long loops [15:05] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:50fd98b7ac4c: Merge commit '488b2984fece7ad0c2596826fee18e74aa904667' [15:07] <durandal_1707> michaelni: please, please, please stop adding your changes into merges [15:08] <nevcairiel> didnt we just discuss how he didn't? [15:09] <durandal_1707> look at last one [15:10] <nevcairiel> i see no extra changes [15:12] <Daemon404> i do [15:12] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=50fd98b7ac4c410f4413d38... [15:12] <nevcairiel> click on the diff below the 1 for the actual changes in that merge [15:13] <Daemon404> yes but the ones shown tehre are the extra ones [15:13] <Daemon404> that are in the merge itself [15:13] <nevcairiel> nope [15:13] <Daemon404> they do not match the merge [15:13] <durandal_1707> stupid git [15:13] <Daemon404> nevcairiel, then what ARE they [15:13] <cone-105> ffmpeg.git 03Diego Biurrun 07master:7df9e693a34c: cosmetics: Fix ATRAC codec name spelling [15:13] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:4cfe3b740543: Merge commit '7df9e693a34c84c698da60426c78140c950f95ed' [15:13] <nevcairiel> no idea how it decides what to show there [15:13] <Daemon404> its changes made in the merge >.> [15:14] <Daemon404> i dont know how you can see it any other way [15:15] <Daemon404> hmmm or it might be existing things? [15:15] <Daemon404> this is why i hate git's way of merging [15:15] <Daemon404> its impossible to follow [15:16] <nevcairiel> quite simply because the warning about the missing seektable was in there before the merge [15:16] <Daemon404> yes i just realized that [15:16] <Daemon404> but my point stands about git merges being a crapshoot [15:16] <nevcairiel> click the diff below the 1 [15:16] <nevcairiel> it shows the actual diff against ffmpegs parent [15:17] <nevcairiel> while 2 shows the diff against libavs parent [15:17] <Daemon404> diff1 is the diff against libav [15:17] <Daemon404> iirc [15:17] <Daemon404> diff2 is ffmpeg's diff against libav [15:17] <Daemon404> diff1 is not against ffmpeg. [15:17] <nevcairiel> diff 1 is the diff of the current version against the ffmpeg parent, diff 2 is the diff of the current version against libavs parent [15:17] <nevcairiel> the second contains all ffmpeg changes, of course [15:18] <nevcairiel> so its a "diff against libav" if you want [15:19] <nevcairiel> find a commit with clear signs of in-merge changes and confirm diff 1 behaviour, if you insist :) [15:19] <Daemon404> hmm yorue right [15:19] <nevcairiel> now what the web thing shows in the merge overview page completely escapes me [15:19] <Daemon404> "clear signs of in-merge" is an oxymoron btw [15:19] <nevcairiel> you know what i mean :P [15:20] <Daemon404> nevcairiel, my main issue is that merges make finding things in git history very hard [15:20] <Daemon404> especially bisects [15:20] <nevcairiel> yeah bisecting sucks [15:20] <Daemon404> its weird that it was designed i na way which breaks git's other features [15:20] <nevcairiel> browsing a single files history is ok'ish [15:20] <Daemon404> but it was probably only meant for the subset that the kernel uses it for [15:21] <nevcairiel> yeah two completely different branches co-existing is a odd use case [15:21] <Daemon404> not really [15:21] <Daemon404> when you consider teh pre-git definition of fork [15:21] <Daemon404> git changed that word to have different connotations [15:22] <Daemon404> as a side note: sometimes i have to fall back to good old patch/diff, because git hasb een too throroughly derped up [15:22] <Daemon404> manual patches ftw [15:23] <nevcairiel> never had that happen [15:23] <nevcairiel> usually gits 3 way merge managed to fix it, unless it was really not automatically fixable (code modified on both ends) [15:23] <pippin> I prefer rebase based workflows, leading to a linear commit history [15:24] <Daemon404> everybody does [15:24] <Daemon404> thats not suitable for this use case though [15:24] <cone-105> ffmpeg.git 03Martin Storsjö 07master:0fbda03e5cfc: movenc: Don't flush after each written packet [15:24] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:40bb950385a4: Merge remote-tracking branch 'qatar/master' [15:33] <ubitux> can avcodec_decode_video2() return EAGAIN? [15:37] <durandal_1707> aac_latm does [15:38] <av500> aac does video now? [15:38] <durandal_1707> no... but it returns [15:38] <durandal_1707> that is only EAGAIN in lavc [15:39] <durandal_1707> and i see no reason for it... [15:41] <ubitux> mmh interesting [15:41] <ubitux> well if that's for audio i don't care in my case but that's good to know [15:42] <durandal_1707> when would you use it? [15:44] <ubitux> i'm just wondering if i can error out in case of ret < 0 [15:44] <ubitux> or if i need to add a EAGAIN check [15:44] <ubitux> (in addition) [15:45] <nevcairiel> i just error out on < 0 [15:45] <nevcairiel> never found something where this doesnt work [15:45] <ubitux> yeah actually i just realize there is the got_frame thing [15:45] <ubitux> so eagain should not happen [15:47] <Daemon404> yes [15:49] <ubitux> what about the read frame? [15:49] <nevcairiel> there i handle it [15:49] <nevcairiel> not sure if it really happens [15:49] <ubitux> i remember a lot of weird cases [15:49] <nevcairiel> i think it can, depending on the underlying protocol [15:49] <ubitux> like packets of size 0 [15:49] <ubitux> and stuff like that [15:50] <Daemon404> multi-packet frames are common [15:50] <Daemon404> so are multi-frame packets [15:50] <Daemon404> ive written the The Decode Loop too many times... [15:50] <Daemon404> low level api os low level [15:50] <Daemon404> is* [15:50] <nevcairiel> i kinda like it, gives me a lot of control :p [15:50] <durandal_1707> huh? [16:00] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:a4e70918316c: avcodec/vcr1: return the actual number of consumed bytes [16:00] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:84b6451d29ec: avcodec/vcr1: simplify code, drop buf_size [16:00] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:f4e9c768d102: avcodec/vcr1: simplify code drop buf variable [16:08] <Compn> michaelni : there were some talks about moving vcr1 and other codecs out of the main mpeg code [16:08] <Compn> possibly theres some colorspace code still stuck in there as well [16:08] <Compn> maybe you know about this already [16:09] <durandal_1707> vcr1 have nothing to do with mpeg [16:10] <cone-105> ffmpeg.git 03Paul B Mahol 07master:3dd4b6ea417a: lavfi: port phase filter from libmpcodecs [16:10] <cone-105> ffmpeg.git 03Paul B Mahol 07master:916549cb1e73: lavfi/mp: remove mp=phase [16:11] <Compn> oop, i mean vcr2 :) [16:15] <Compn> only a hundred lines? blah [18:03] <soul-d> probably not entirely ffmpeg question but still since they are "lowlevel" my questions http://pastebin.com/YEv5gwg3 + current wip chart http://i.imgur.com/2IioCPk.png [18:03] <soul-d> did only get as fas finding the yuyv marker if vieuwed as hex [18:04] <soul-d> simply said i need info on fileformats to be able to actualy write that files decoder [19:03] <cone-105> ffmpeg.git 03Paul B Mahol 07master:605381281405: x86/simple_idct: use LOCAL_ALIGNED instead of DECLARE_ALIGNED [19:10] <durandal_1707> how "Relicensed to LGPL with permission by all contributors." sounds like? [19:22] <cone-105> ffmpeg.git 03Paul B Mahol 07master:771e2e59e2af: lavfi/hue: relicense to LGPL with permission by all contributors [19:26] <durandal_1707> michaelni: can you kindly give permission to relicense mptestsrc to lgpl? [19:28] <llogan> how was VDD? [19:30] <llogan> durandal_1707: why do you want to relicense? [19:31] <durandal_1707> to amuse rms [19:32] <ubitux> :D [19:32] <llogan> i don't know what rms means [19:32] <ubitux> richard stallman [19:32] <llogan> oh [19:34] Action: michaelni politely refuses to annoy anyone [19:34] <durandal_1707> :) [19:35] <llogan> i'm surprised nobody asked why before giving permission [19:35] <ubitux> lgpl is preferred [19:35] <ubitux> overall codebase is lgpl [19:35] <durandal_1707> we want to swith to AGPL [19:36] <mateo`> :D [19:38] <llogan> another " [19:38] <llogan> Is this a family-friendly mailing list?" [19:38] <llogan> in the queue from another chinese guy... [19:38] <llogan> delete [19:39] <Compn> hey llogan :) [19:39] <Compn> vdd was fun [19:40] <llogan> did you vandalize asterix statue with a ffmpeg sticker? [19:40] <cone-105> ffmpeg.git 03Dirk Farin 07master:902a5fa7228d: avformat: H265 demuxer [19:41] <llogan> oh, it's the same chinese guy. [19:41] <michaelni> i hope you didnt forget giving asterix an umbrella in that case ;) [19:42] <llogan> i was going to say since they are rain temporary then it won't cause permanent damage [19:44] <nevcairiel> michaelni: since its rather likely that the fork will also get a H265 codec id, how do you plan on handling the change in numeric id? [19:45] <ubitux> duplicate [19:45] <michaelni> yes and remap_deprecated_codec_id() [19:51] <Daemon404> what was the point of pushing that? [19:53] <durandal_1707> of hevc raw demuxer? [19:53] <Daemon404> yes [19:54] <Daemon404> theres one coming from the actual person who wrote the hevc decoder [19:54] <durandal_1707> to say: here, see! we have it! [19:54] <Daemon404> yeah pretty much [19:54] <Daemon404> seems dumb. [19:54] <Compn> trolling openhevc to implement it [19:54] <Compn> is my idea [19:55] <kierank> durandal_1707: i thought you were going to be at vdd [19:56] <Daemon404> he doesnt have a passport [19:57] <kierank> could have taken the train [19:57] <kierank> and gone through schengen countries [19:57] <durandal_1707> yes, i were, big, handsome, strong guy in top left corner [19:57] <Daemon404> if you mean https://twitter.com/flameeyes/status/374149289510838272/photo/1 [19:57] <Daemon404> then thats JEEB~ [20:02] <durandal_1707> are that all libav devs? [20:02] <JEEB> nope [20:39] <Compn> oh no, im in that picture [20:40] <Compn> durandal_1707 : i'll give you a hint. i have the big beard [20:42] <j-b> the biggest [20:43] <Compn> its going to be a challenge to catch up to rms beard [20:44] <llogan> you should do this: http://laughingsquid.com/wp-content/uploads/beard-20110516-120844.jpg [20:44] <Compn> yes, the beard championships [20:45] <cone-105> ffmpeg.git 03wm4 07master:060c6c464753: avformat/mpl2dec: handle files with CRLF linebreaks correctly [20:45] <cone-105> ffmpeg.git 03Clément BSsch 07master:493ebbd7eb08: Update copyrights where my email appears with the new one. [20:46] <Daemon404> Compn, you are no rms [20:46] <Daemon404> at least, i didnt see you eat anything from your foot [20:46] <JEEB> lol [21:22] <cone-105> ffmpeg.git 03Clément BSsch 07master:30d40c9e866b: lavfi/drawtext: add generic timeline interface and deprecate "draw". [21:27] <ubitux> ah shit, i unsubscribed my gmail address from ffmpeg-devel, so one mail from here awaits for moderation [21:27] <ubitux> sorry about that [21:31] <Compn> heh [21:31] <Compn> no worries [21:33] <Compn> ubitux: did you resubscribe ? [21:33] Action: Compn approves ubitux mail [21:34] <ubitux> i re-subscribed on my new address [21:35] <ubitux> thx Compn [21:57] Action: Compn lols about swear words post [21:58] <Compn> llogan : why not discard that one ? [22:05] <ubitux> so swscale has ppc, sparc and bfin asm, but no arm [22:05] <ubitux> erm. [22:20] <beastd> ubitux: no no, it is still spelled arm this days not erm ;) [22:21] <ubitux> that's what i missed ;) [22:24] <cone-105> ffmpeg.git 03Paul B Mahol 07master:d21e496cf5ae: lavfi/mptestsrc: use outlink->frame_count [22:38] <llogan> Compn: because he was subscribed so it went though automatically. i thought it was weird so i added a mod bit to his address. [22:38] <llogan> then i told him it was off-topic and the ML is not considered to be family friendly because it has nothing to do with families [22:41] <llogan> Compn: oh...i see he sent another. [22:43] <durandal_1707> Compn: you modded guy who trolled about swear words? [22:47] <llogan> no, i did because i didn't know if it was some sort of pre-spam probe or whatever [22:56] <gnafu> Wait, so did they think that the censorship was automated and not self-induced? [00:00] --- Wed Sep 4 2013