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

[burek]

[00:06] <iive> wm4: ffmpeg is trademarked, so the debian ffmpeg "deprecated" program could be considered counterfeit. I'm sure Debian people would love us if we send them C&D letter :)
[00:10] <wm4> actually that's a great idea, considering the lena crap
[00:13] <jamrial> has anyone pointed them that libav also ships the same image?
[00:13] <kepstin-laptop> jamrial: yes, that has been pointed out.
[00:14] <jamrial> I see
[00:14] <kepstin-laptop> or at least, has been mentioned in the stuff on the ffmpeg-devel list, I don't actually know if it made it to the debian folks.
[00:33] <Compn> wm4 / iive : its actually terrible idea, debian will balk at distributing ffmpeg much like the iceweasel thing
[00:34] <Compn> so its kind of screwed if you do, screwed if you dont type of situation
[00:34] <iive> i have been sarcastic... i guess the smiley at the end wasn't enough of a hint.
[00:34] <Compn> yes but wm4 wasnt
[00:35] <Compn> who was working on that message ?
[00:35] <Compn> for months and months
[00:35] <beastd> kierank: I am disappointed because of you trying to urge michaelni into attending VDD for resolving FFmpeg vs Libav. If michaelni should go to VDD than that is only to enjoy the event, interesting talks and sessions. And IIRC j-b said it at least once before that VDD is not a forum for FFmpeg nor Libav.
[00:36] <j-b> because you're a bunch of kids
[00:36] <Compn> iirc kierank suggested michael come to a meeting for years
[00:36] <Compn> so this is nothing new beastd
[00:36] <j-b> else, FFmpeg would be the center of the multimedia community like it should
[00:36] <Compn> it is the center, and theres nothing you can do about it j-b
[00:36] <Compn> otherwise everyone would have switched to libav long ago :P
[00:37] <j-b> Compn: right :)
[00:37] <Compn> j-b : remi is difficult to talk to :\
[00:37] <Compn> ehe
[00:43] <Daemon404> eh
[00:43] <Daemon404> i found remi one the easiest to talk to irl
[00:43] <Daemon404> then again, i am not a a vlc person.
[01:41] <j-b> why the hell do people push for MSVC?
[01:41] <j-b> it's slower, less maintained, less standard
[01:42] <Compn> whats the alternative ?
[01:43] <Compn> i'm seriously asking because i forgot
[01:43] <Compn> gcc + mingw/cygwin is one of them
[01:43] <Compn> i forgot what the 'standard' was now
[01:43] <jamrial> gcc? mozilla uses it for all their builds for example. even the windows ones
[01:43] <Compn> oh , they like msvc debugging 
[01:43] <Compn> theres some debugging that gdb doesnt have or something
[01:44] <j-b> gcc works fine
[01:44] <jamrial> or maybe not. these don't look like gcc flags...
[01:47] <pross-au_> gcc can output microsoft pdb debug info now?
[01:50] <Compn> theres always something the msvc people complain about gcc ;P
[01:51] <J_Darnley> All those casts remind me of c++
[01:55] <j-b> pross-au_: it can.
[01:58] Action: pross-au_ TIL
[01:58] <j-b> pross-au_: it is not very simple yet.
[01:58] <j-b> pross-au_: we're working on that.
[02:05] <kierank> Compn: http://hwcdn.net/j9t9v3v5/cds/ffmpeg.tar.gz
[02:05] <kierank> new dump from elemental
[02:06] <kierank> ubitux: ^
[02:06] <kierank> some interesting stuff in there
[02:24] <cone-440> ffmpeg.git 03Michael Niedermayer 07master:596636a474ab: avcodec/snow: check coeffs for validity
[02:54] <Compn> michaelni : want to try skype or other video chat to vdd ? we can put you on a tablet or laptop and carry it around...
[02:55] <Compn> you wont be there in person, but in spirit (or bytes) . can even do richard stallman, open video format only ? maybe livestream snow? :P
[02:56] <Compn> j-b : will google lend us some laptop or tablet ? 
[02:56] <j-b> no
[02:57] <kierank> you can use mine
[02:57] <Compn> good battery life is a plus.
[02:57] <kierank> ok then mine is out of the question
[02:57] <kierank> my battery is buggered
[02:57] <kierank> lasts about 5 mins
[02:57] <Compn> all my laptop batteries are toast 
[02:58] <Compn> buy cheap chinese one off amazon? nahh
[02:58] <Compn> well michaelni , if you make a livestream, we'll put it on a bunch of puters then. whatever puter we have lying around
[02:58] <kierank> nervous about doing that
[02:58] <Compn> use ffserver :)
[02:59] <Compn> i think it would be fun to have michael (or any other devel who wont be there in person) to video chat in
[02:59] <Compn> wheres the list of devs who are attending ?
[02:59] <Compn> or registered
[03:01] <Compn> google circle chat hahaa
[03:04] <pross-au_> oh the irony
[03:16] <BBB> hey guys can we drop one of the prores decoders now?
[03:16] <BBB> or is there a list of which is better in terms of speed, features? can someone measure that?
[03:16] <BBB> Compn: how about you
[03:20] <jamrial> huh, they are both lgpl yet one is explicitly called "prores_lgpl"
[03:20] <BBB> I think that historic
[03:20] <BBB> they started as gpl lgpl, but then the gpl got relicensed, probably for competitiveness reasons
[03:25] <pross-au_> wait, we have two encoders and two decoders!
[03:44] <Compn> BBB : since kostya has quit, probably we can just merge them. but i dont know which is faster / features etc
[03:44] <Compn> j-b : I complained about that several times, and was ignored.
[03:44] <Compn> j-b : ok, you have a problem with anonymous code ? 
[03:45] <Compn> j-b : what do you suggest we do with anony code ? delete it? ask author to fess up?
[03:45] <Compn> ask author to transfer copyright ?
[03:45] <Compn> i'm genuinely asking , devels can vote on whatever proposal...
[03:45] <j-b> either fess up, or give the right to relicensiate to the governing body
[03:45] <Compn> sounds good
[03:46] <j-b> or relicense to the simplest license
[03:46] <j-b> aka, WTFPL or BSD 2-clause
[03:47] <Compn> i'm curious about your re-licensing complaint , could you be more specific? do you mean adding copyrights from known authors when they were not present in original libav commit ?
[03:48] <Compn> or the copyright multiple at multiple.x ?
[03:48] <Compn> we could send patches to improve these things
[03:48] <Compn> even i could do it :)
[03:49] <Compn> it would be nice if , instead of complaining on mailing list, either patches or report to bug trac was used...
[03:49] <j-b> sorry, but no.
[03:49] <Compn> well i can make new bugs
[03:49] <j-b> your project is hopeless wrt copyright
[03:49] <Compn> so could you be specific
[03:49] <Compn> argh :)
[03:53] <Compn> so dont try to fix? :P
[03:55] <Compn> its mplayer all over again :P
[03:55] <j-b> example
[03:55] <j-b> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavfilter/vf_hue.c;hb=771e2e59e2afeba6f195645678645b8c874e59a2
[03:56] <j-b> "all contributors"
[03:56] <j-b> not listed
[03:56] <j-b> and when you look closely
[03:56] <j-b> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=ae60d2c877e452c623fbe8e3129326cc0e26a1da
[03:56] <j-b>  This is a port of the MPlayer hue filter (libmpcodecs/vf_hue.c)
[03:56] <j-b> right
[03:57] <j-b> and all the MPlayer contributors agreed, right?
[03:57] <j-b> they were asked, right? every single one of them?
[03:57] <Compn> durandial went over the file and i think contacted every author who had copyrightable code ?
[03:57] <Compn> have to ask him
[03:57] <Compn> the files mplayer history
[03:57] <Compn> or just the ports history
[03:58] <j-b> all the code that finished in this file.
[03:58] <j-b> all of it.
[03:58] <j-b> it's not documented who agreed
[03:58] <Compn> svn blame mplayer/libmpcodecs/vf_hue.c
[03:58] <j-b> therefore, it's useless and very likely wrong
[03:58] <j-b> Compn: but also svn log mplayer/libmpcodecs/vf_hue.c
[03:59] <Compn> michael , carl, diego
[03:59] <Compn> ok
[03:59] <j-b> etc..
[03:59] <j-b> so, those are for the licensing
[03:59] <j-b> because FFMpeg is Mplayer all-over-again
[03:59] <j-b> mostly libavfilter and the limpcodecs (sic)
[03:59] <Compn> reimar, michale , clement, diego, syrjala (7 lines)
[04:00] <Compn> +carl
[04:00] <Compn> almost the same list
[04:00] <j-b> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9e8bbe7d4d1dcd5fec491dbfbb98ed2038a7bed5
[04:00] <j-b> How the FUCK this happens?
[04:01] <Compn> this is only for license file , not the license in vf_interlaace.c 
[04:01] <Compn> as you can see from commitdiff
[04:01] <j-b> sure, it just proves that you don't care enough about copyrights
[04:02] <Compn> it just wasnt added ot LICENSE file , probably committer forgot we maintain such files still
[04:02] <Compn> or just plain forgot 
[04:02] <kierank> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=3fce13679837ce9b43b50a4843c30ee989566bf8
[04:02] <kierank> was committed as gpl
[04:02] <kierank> at least
[04:02] <Compn> right
[04:02] <jamrial> configure lists it as gpl
[04:03] <jamrial> so builds without --enable-gpl never compiled it
[04:03] <jamrial> it was simply missing from the license file
[04:03] <Compn> dont bother 
[04:03] <jamrial> that file is a bit unmaintained. it still mentions some idctmmx file that doesn't exist. and all the idct code we have is lgpl afaik
[04:04] <Compn> we finally got rid of that test idct file ? ehe
[04:04] <j-b> Compn: finally, you add the squashed code without attributions, and then the anonymous devs...
[04:05] <Compn> the authors of the squashed code were added, and BBB and (other dev i forgot now) fixed all that before commit iirc
[04:05] <Compn> for vp9
[04:05] <Compn> but you dont seem willing to listen
[04:06] <j-b> seriously, I do
[04:06] <j-b> but your attitude with copyright is a bit light
[04:07] <j-b> and all the relicensing of the filters from mplayer are very dubious
[04:07] <Compn> you dont think michael did the relicense honestly ?
[04:07] <Compn> why not just say that ?
[04:07] <j-b> Yes, I don't think so.
[04:07] <j-b> I say that, I said that and I will resay that
[04:08] <Compn> do you want reimar 's word of relicensing ?
[04:08] <Compn> or i mean, what can prove it to you ?
[04:09] <j-b> I don't know, proper documentation of the process, for a start...
[04:09] <BBB> Compn: I doubt hes talking about vp9; the orig vp9 commit clearly lists all (2) authors that contributed to the whole, and we have a historic tree available that lists the individual commits leading to that whole
[04:09] <Compn> i mean, what does proper documentation look like ?
[04:09] <BBB> Compn: I think hes talking about other crap where that is not clearly documented
[04:09] <j-b> Compn: read my blog about relicensing
[04:10] <j-b> read my commits in VLC on relicensing
[04:10] <Compn> i think i read it long time ago, let me dig it up
[04:10] <Compn> http://www.jbkempf.com/blog/post/2012/How-to-properly-relicense-a-large-open-source-project
[04:10] <j-b> and not the usual "this change is trivial, so not copyrighted"
[04:11] <j-b> why when it's relicensed, there is not the list of "all the authors that agreed"?
[04:12] <j-b> stuff like this are very bad too: http://git.videolan.org/?p=ffmpeg.git;a=search;h=f7f1f4c7ce9ce689823e13a53b694eb14cbbf6e7;s=gcocherel;st=author
[04:12] <j-b> asking people to correctly set their git name is too hard?
[04:13] <Compn> http://git.videolan.org/?p=ffmpeg.git&a=search&st=author&s=compn
[04:13] <Compn> :P
[04:13] <j-b> Exactly the same
[04:14] <Compn> of course libav has committed me sometimes > http://git.videolan.org/?p=ffmpeg.git&a=search&st=author&s=littler
[04:14] <j-b> http://git.videolan.org/?p=vlc.git&a=search&st=author&s=compn
[04:14] <j-b> http://git.videolan.org/?p=vlc.git&a=search&st=author&s=littler
[04:15] <j-b> Compn: do you have the mplayer git somewhere browsable?
[04:15] <Compn> i was pointing people to an mplayer git for a while until i realized it was mplayer2 repo :D
[04:16] <j-b> same
[04:17] <Compn> so 'videolabs' is the official vlc on android play store right ?
[04:17] <Compn> vlc for android beta
[04:17] <Compn> but no, let me look for mplayer git somewhere. there used to be a mirror. maybe its gone
[04:18] <j-b> Compn: yes it is.
[04:18] <j-b> it will be renamed soon
[04:18] <Compn> ok, because that confused me :)
[04:19] <Compn> https://github.com/pigoz/mplayer-svn , hasnt been updated in 1 year
[04:20] <j-b> https://github.com/pigoz/mplayer-svn/commit/a8065c5b042be7042c399d12eb981a7379d6cabf
[04:20] <j-b> example in point
[04:20] <j-b> did Paul contact James Crowson before doing the relicensing?
[04:20] <j-b> sure, the svn author is michael...
[04:20] <j-b> BUT, it's not the copyright holder...
[04:21] <j-b> and I took an easy one
[04:21] <Compn> that code isnt in the port
[04:21] <Compn> :)
[04:21] <Compn> yes, you mad.
[04:22] Action: Compn trolls j-b into reviewing mplayer code
[04:22] <j-b> anyway, I lost too much time on this discussion
[04:22] <j-b> but I hope you see my point.
[04:23] <j-b> and read my blog about why the "code not being present anymore" is irrelevant
[04:23] <Compn> of course, code was checked for copyrights, ported as gpl, relicensed after doing blame , and yet still complaints.
[04:23] <j-b> doing blame? I doubt it.
[04:23] <Compn> wheres your libreoffice spreadsheet ?
[04:23] <Compn> i didnt see it posted...
[04:24] <j-b> I can show you at VDD
[04:24] <j-b> the fact that you don't agree there is a problem in the way things are held just show that we will just have to disagree.
[04:24] <Compn> i agreed with you about copyrights earlier
[04:24] <j-b> You are too careless about copyrights
[04:24] <Compn> you are just mad to realize i'm not arguing with you
[04:25] <Compn> [21:45] <Compn> sounds good
[04:25] <j-b> I'm mad?
[04:25] <Compn> oh no, i've insulted . i take it back
[04:27] <BBB> Compn: any progress on prores?
[04:27] <Compn> BBB : who answered prores questions before
[04:27] <Compn> someone analyzed them
[04:27] <BBB> Compn: just measure it, take a sample of 1000 frames, run time -c:v first_decoder sample -f null -
[04:27] <Compn> :)
[04:27] <BBB> etc.
[04:27] <Compn> ok
[04:27] <BBB> then make sure they all support all sample types
[04:27] <BBB> (like, alpha, 444 subsampling, etc.)
[04:28] <Compn> and then test all known and unknown samples eh
[04:28] <BBB> no
[04:28] <BBB> all of these are covered in fate
[04:28] <BBB> fate has like 5 or 6 samples
[04:28] <BBB> so just ffplay all of them with either decoder
[04:28] <BBB> thats 10-12 ffplays of a few seconds
[04:28] <BBB> cant be that bad
[04:28] <BBB> for alpha maybe confirm its indeed there by looking specifically at the alpha data in some way
[04:29] <BBB> its a few minutes of work
[04:30] <Compn> can you force decoders with ffplay now ? i remember making feature request ...
[04:30] <BBB> if not, output to png and browse through the first 20 frames
[04:30] <Compn> j-b : heres celements , http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-August/147676.html and jeremy https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-September/147835.html
[04:31] <Compn> alpha is a pain :)
[04:32] <j-b> Compn: and the James and the jrsawa ?
[04:34] <Compn> syrjala code isnt in the port, because it has to do with colorspaces that are handled in swscale or elsehwere
[04:34] <Compn> and i told you the james patch isnt in the port code either
[04:35] <Compn> but 
[04:35] <Compn> like you say, maybe we havent dug deep enough in all of the filters
[04:35] <Compn> its possible something slipped
[04:36] <Compn> vf_hue looks pretty solid though
[04:37] <Compn> so thank you for reviewing it
[04:37] <Compn> BBB : i'm looking for prores info
[04:37] <Compn> and updating my tablet , getting it ready for trip
[04:37] <Compn> android update makes camera work again, hooray
[04:38] <Compn> running android 4.4 on a 2011 hp touchpad :)
[04:38] <j-b> We will keep disagreeing then...
[04:38] <Compn> vlc might kill my kitten! 
[04:38] <Compn> you say vf_hue still has copyright problem ?
[04:39] <Compn> because the code that wasnt in the port maybe influenced the port ?
[04:40] <Compn> or because clement , carl, diego and reimar arent listed in copyright 
[04:41] <Compn> sorry, its late, maybe i have skipped over some of your advice for copyright . i apologize
[04:41] <Compn> too much multitasking for me
[04:50] <Compn> anyways, thanks for answering my question j-b
[04:50] <Compn> will relay to durandial
[04:50] <Compn> maybe ubitux knows more about filter ports as well
[04:58] <Timothy_Gu> wm4: what was your favorite pastebin with commandline api again?
[05:08] <Compn> j-b : reviewing the anonymous code, i dont want to get any more dev arguments. there was a huge fight over prores stuff and thats where elvis presley holds copyright :\
[05:09] <Compn> j-b : so yea i agree ffmpeg has copyright problems.
[05:12] <Compn> j-b : here is ticket for vf_hue and libavfilter copyrights http://trac.ffmpeg.org/ticket/3908#ticket
[05:26] <Compn> ugh, i'm tired of the crap
[05:27] <pross-au_> of which crap do you speak
[05:31] <Compn> BBB : btw i cant do the prores stuff right now, too busy.
[08:56] <jamrial> cehoyos turning a trac ticket into a flamewar with a single comment
[09:09] <kurosu> at the moment I think kostya's encoder produces decodable yet invalid files (eg using a profile not having alpha but still encoding it)
[09:09] <vedos> i'm using youtube-dl to download stuff from Youtube... youtube-dl defaults to avconv, but can also use ffmpeg if i install it. which should i use to dump wav files out of the videos? which is more reliable and gives better sound quality?
[09:09] <kurosu> I think that's the only one having alpha, but one can probably port it from one to another (license fun)
[09:10] <kurosu> I haven't looked a lot to either, but kostya's looked nice with rate control and multithreading
[09:10] <kurosu> why not ask the author of the other encoder ?
[09:10] <ubitux> kierank: i just made a diff with the latest you send, and i see a system of lock (avpriv_{un,}lock_decodefr) which seems to be used in vc1dec to avoid a race, i see some changes in the mpeg ps parser but it might just be to resync a fix with upstream, and i see the addition of ARIB subs but only the codec id
[09:11] <vedos> kurosu: you mean avconv?
[09:11] <vedos> authors?
[09:12] <kurosu> vedos, sorry no time for anything, gotta go
[09:22] <ubitux> vedos: this is a question for #ffmpeg; also, we support only ffmpeg, here. Last, wav is lossless so there is no quality factor going on
[10:41] <wm4> what does it mean when the h264 decoder prints "mmco: unref short failure"?
[10:42] <vedos> ubitux: i read somewhere that avconv corrupted audio files for someone. that's why i'm leaning toward ffmpeg. it feels to be more better.
[10:44] <ubitux> you definitely won't hear that the tools from the libav project are more reliable here
[10:45] <wm4> I suspect if vedos uses "ffmpeg" on his installation, he'll just use the "ffmpeg" program provided by Libav, instead of ffmpeg from the ffmpeg project
[10:59] <vedos> mirsal: ffmpeg version N-63893-gc69defd Copyright (c) 2000-2014 the FFmpeg developers
[10:59] <vedos> is this the "true" version?
[11:00] <wm4> vedos: why are you highlighting apparently random people
[11:01] <wm4> but yes it's the real ffmpeg
[11:01] <wm4> (apparently an outdated git snapshot)
[11:02] <nevcairiel> just 2000 revisions out
[11:02] <nevcairiel> thats nothing!
[11:19] <ubitux> oh ffs
[11:20] <ubitux> CE creating a drama all by himself
[11:21] <nevcairiel> really wish it was possible to silence him, its not helping the situation at all
[11:22] <wm4> calling him names should do the trick (hurr)
[11:22] <nevcairiel> you can claim its only his opinion and noone elses, but that usually never works
[11:22] <ubitux> and meanwhile suggesting to --disable-opencl in x264 in the libx264 detection failure ticket
[11:24] <wm4> "There is apparently some misunderstanding regarding the word thieve (and liar): Some people seem to believe that this is meant as an insult which is of course not true. "
[11:24] <wm4> ahahaha
[11:24] <wm4> that's hilarious
[11:29] <ubitux> wm4: oh no 2011 again, please noo :(
[11:30] <ubitux> you're giving him the opportunity to rediscuss all over again the same story
[11:31] <wm4> oops
[11:31] <ubitux> http://pastebin.com/6qZDfjv0 wat
[11:32] <nevcairiel> windows batch files are fun
[11:34] <nevcairiel> can someone just make the ticket go away now
[11:37] <nevcairiel> on more constructive things, is the curl api just terrible or am I going crazy trying to understand it
[11:47] <cbsrobot> ubitux: just tell him to tell you a number before you answer with a yes or no
[11:50] <wm4> nevcairiel: AFAIK it's very terrible, yes
[12:11] <wm4> you know what would be nice? if there was something occasional contributors could run FATE with their patches applied
[12:12] <wm4> because keeping around about 1 GB of FATE samples and running the suite locally is a bit inconvenient
[12:15] <J_Darnley> Make them available via http?
[12:16] <wm4> sounds potentially helpful
[12:17] <nevcairiel> what does that change
[12:17] <J_Darnley> They don't have to keep the samples.  They just have to d/l 1G everytime they run it!
[12:18] <nevcairiel> and thats different to now, how?
[12:18] <wm4> they could get the samples for the tests they want to run, or so
[12:19] <J_Darnley> you can do that with rsync too
[12:23] <wm4> is it right that AVInputFormat.read_packet frees the packet passed as parameter with av_free on error?
[12:24] <wm4> this doesn't seem right at all
[12:38] <cone-391> ffmpeg.git 03Michael Niedermayer 07master:0daff3ce7632: avfilter/vf_mp: remove incorrect usage of AVFrame.type
[12:38] <cone-391> ffmpeg.git 03Michael Niedermayer 07master:19bf1ed1f426: avformat/id3v2: Fix "warning: unused variable uncompressed_buffer_size" if zlib is unavailable
[13:04] <Daemon404> pretty amusing the chromium guy asks if ffmpeg supports pre-c99 compilers
[13:05] <Daemon404> while using a pre-c99 msvc
[13:05] <Daemon404> (unless they upgarded finally)
[13:06] <wm4> gah
[13:07] <wm4> j-b: not sure if you're interested in that at all, but I know someone who wants to write a POSIX layer on top of native windows (and that doesn't suck to hell and back as cygwin does)
[13:07] <Daemon404> sounds doomed to fail
[13:07] <Daemon404> (yeah ill just write it... wait...)
[13:07] <wm4> he actually got fork() to work, so I'm not sure about that
[13:08] <nevcairiel> you can emulate fork, but you cant get fork "to work" :P
[13:08] <wm4> because apparently the windows kernel supports fork nativelyx
[13:08] <nevcairiel> even if thats true, going that low is a recipe for disaster
[13:08] <Daemon404> inb4 insanely unportable code
[13:08] <wm4> nevcairiel: why?
[13:08] <BBB> omg diego
[13:09] <BBB> why is he so lastwordstands
[13:09] <Daemon404> you used to work with GNOME
[13:09] <Daemon404> you tell me.
[13:09] <BBB> I left, that was probably the biggest reason
[13:09] <BBB> it was impossible to have any discussion
[13:09] <BBB> impossible
[13:10] <BBB> all these 15-year olds that think that just because you repeated yourself once more than the other, youve won the discussion
[13:10] <BBB> diego really is a 15-year old
[13:14] <nevcairiel> wm4: mostly because nothing any levels higher expects you to do it, so if you use any code that you don't control yourself, who knows what weird issues it'll cause
[13:15] <wm4> nevcairiel: that's surely true for fork, but unix has the same issue with fork specifically
[13:16] <nevcairiel> but fork on unix is a standard thing, isnt it
[13:16] <wm4> if something uses threads in the same process, using fork is already sketchy (and unless you exec right after fork, definitely buggy)
[13:17] <nevcairiel> anyhow, trying to use kernel functions that noone else otherwise uses is a good way to find problems :D
[13:17] <wm4> many win32 functions are just small wrappers around the kernel functions, and drivers use the same functions directly
[13:18] <wm4> but it gives you the chance to work around entirely broken crap like the winsock API
[13:18] <Daemon404> is stability even guaranteed?
[13:18] <Daemon404> i doubt it.
[13:19] <wm4> it probably is
[13:19] <wm4> compatibility goes back to win2k and earlier
[13:19] <nevcairiel> windows doesnt usually break API or ABI at all
[13:19] <wm4> so it'd be strange if they changed that
[13:22] <kierank> I give up. Both sides have their heads so firmly up their arses
[13:23] <wm4> sad
[13:30] <nevcairiel> i should stop trying to post on trac, its just impossible with this person around
[13:35] <wm4> what is happening to the timestamps I set on a packet in read_packet?
[13:35] <wm4> ffprobe -show_packets is reporting "pts=N/A"
[13:37] <cone-391> ffmpeg.git 03Michael Niedermayer 07master:97cebf3139cc: avformat/udp: Move variables used only with HAVE_PTHREAD_CANCEL, under the #if
[13:37] <cone-391> ffmpeg.git 03Michael Niedermayer 07master:e16b7338d877: avcodec/aarch64/h264qpel_init_aarch64: mark src as const
[13:40] <BBB> kierank: I actually feel for you
[13:41] <nevcairiel> wm4: did you set a timebase
[13:41] <wm4> nevcairiel: yes
[13:44] <durandal_1707> what is error code 139?
[13:45] <wm4> durandal_1707: use the function that converts error codes to strings?
[13:45] <Daemon404> [12:22] <+kierank> I give up. Both sides have their heads so firmly up their arses <-- great, you can join me in the 0 fucks corner
[13:45] <Daemon404> there's lots of room.
[13:46] <JEEB> aye
[13:53] <durandal_1707> what is wrong with hue relicensing?
[13:56] <cone-391> ffmpeg.git 03Michael Niedermayer 07master:140287360110: avcodec/vp3data: use more compact data types
[14:13] <cbsrobot> is there a prores sample with yuv444p10 (without alpha) ?
[14:13] <cbsrobot> i thought it is either yuva444p10 or yuv422p10.
[14:15] <cbsrobot> durandal11707: j-b rised some questions tonight, but I think vf_hue was just an arbitrary choice.
[14:18] <kurosu_> cbsrobot, not sure but the format and some software seem to handle it
[14:18] <kurosu_> http://trac.ffmpeg.org/ticket/3846
[14:21] <kurosu_> the file is converted to yuva444p10 but because the profile was left as is, the alpha wasn't encoded
[14:21] <kurosu_> the 2 tested software didn't seem to complain or decode it incorrectly, of course besides the alpha
[14:21] <kurosu_> as for an actual sample, I don't know - I've just discovered prores with that ticket
[14:21] <kurosu_> (or rather another one about a segfault)
[14:22] <wm4> so how the fuck do you compile ffmpeg in a way to make it debuggable? since ffmpeg doesn't compile with -O0
[14:22] <kurosu_> cbsrobot, fate seems to contain some tests from actual files, eg prores/Sequence_1-Apple_ProRes_with_Alpha.mov
[14:23] <nevcairiel> wm4: if you have a recent gcc, does Og work?
[14:24] <wm4> CLAGS=-Og ./configure ?
[14:24] <wm4> *CFLAGS
[14:24] <nevcairiel> --extra-cflags maybe? no idea
[14:27] <cone-391> ffmpeg.git 03Christophe Gisquet 07master:a808733675cc: proresenc_ks: allow auto-selecting profile
[14:27] <kurosu__> not sure if any of my messages went through, so there's (at least) one fate sample with alpha: prores/Sequence_1-Apple_ProRes_with_Alpha.mov
[14:28] <kurosu__> software don't seem to mind 444 content encoded with an incorrect profile
[14:28] <kurosu__> cf ticket: http://trac.ffmpeg.org/ticket/3846
[14:32] <wm4> god I'm dumb
[14:32] <wm4> of course av_new_packet() overwrites all packet fields
[14:33] <cbsrobot> kurosu__: but Sequence_1-Apple_ProRes_with_Alpha.mov seems to be yuva444p10le
[14:34] <kurosu_> sorry
[14:34] <cbsrobot> I was asking for yuv444p10 (without alpha).
[14:34] <kurosu_> I somehow managed to warp your question meaning meanwhile
[14:34] <kurosu_> I don't know of samples
[14:35] <kurosu_> the ticket seems to show software to handle it
[14:35] <kurosu_> *that handle it
[14:35] <kurosu_> I'm not sure that spec-compliant, but...
[14:40] <cbsrobot> kurosu_: it seems apple released a new prores whitepaper: https://www.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper.pdf
[14:43] <kurosu_> probably each plane sampling could be checked to force 4444 profile (which is suggested to support lack of alpha)
[14:43] <kurosu_> "In addition to supporting YC B C R or RGB 4:4:4 pixel data, the Apple ProRes 4444 XQ
[14:43] <kurosu_>  and Apple ProRes 4444 codec types [...]"
[14:47] <cone-391> ffmpeg.git 03Carl Eugen Hoyos 07master:494cbc4238db: ffmpeg: Clean up if filter initialisation failed to avoid a memleak.
[14:47] <cbsrobot> and: Like Apple ProRes 4444 XQ and Apple ProRes 4444, all Apple ProRes 422 codecs can in fact accept image samples even greater than 10 bits
[14:47] <cone-391> ffmpeg.git 03Carl Eugen Hoyos 07master:f22c24bd7a57: lavf/rtpdec_hevc: Fix compilation with -DDEBUG.
[14:47] <cone-391> ffmpeg.git 03Michael Niedermayer 07master:ce36d8088113: Merge remote-tracking branch 'cehoyos/master'
[14:53] <kurosu_> cbsrobot, yeah, that's about bitdepth, but "chroma" sampling seems to imply one or the other
[14:54] <cbsrobot> it's more like a sidenote to me (and anyone interested)
[15:09] <ubitux> < wm4> so how the fuck do you compile ffmpeg in a way to make it debuggable? since ffmpeg doesn't compile with -O0 // ffmpeg doesn't compile with --disable-optimizations?
[15:09] <wm4> ubitux: ok
[15:39] <nevcairiel> ubitux: it does, but thats still O1, which makes debugging not as easy as it could be
[15:39] <nevcairiel> which is why i'm wondering if Og works, which is only available in GCC 4.8+, but supposedly still optimizes a bit, but specifically designed for debugging
[16:33] <kurosu_> regarding the x264asm patch by bugmaster, yeah, he seemed interested in adding this when I mentioned that in #x264dev
[16:33] <kurosu_> I didn't get to test his WIP at the time, though
[16:33] <cone-391> ffmpeg.git 03Reimar Döffinger 07master:e2cd28c9265e: fft: add missing const.
[17:00] <cone-391> ffmpeg.git 03wm4 07master:b173f5c15572: oggdec: fix invalid free on error
[17:51] <cone-391> ffmpeg.git 03Paul B Mahol 07master:bd6f14582077: avformat/dfa: use avio_feof()
[18:03] <cone-391> ffmpeg.git 03Reimar Döffinger 07master:8c63a0d17114: xv.c: Add missing const to lookup table.
[18:52] <wm4> illegal file ready
[18:52] <wm4> sounds like a great marketing slogan
[18:53] <nevcairiel> What's the point of that ticket
[20:36] <cone-391> ffmpeg.git 03Luca Barbato 07release/1.1:694b7cd873f8: mpegts: Define the section length with a constant
[20:36] <cone-391> ffmpeg.git 03Luca Barbato 07release/1.1:addbaf134836: mpegts: Do not try to write a PMT larger than SECTION_SIZE
[20:36] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:a507fea70769: Merge commit '694b7cd873f8b06af109036eff1ccd741afdd28e' into release/1.1
[20:36] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:807b7388402e: Merge commit 'addbaf134836aea4e14f73add8c6d753a1373257' into release/1.1
[20:45] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:437848e37ae7: vp3: Copy all 3 frames for thread updates
[20:45] <cone-391> ffmpeg.git 03Reinhard Tartler 07release/1.1:8da037af3327: Update Changelog for v9.15
[20:45] <cone-391> ffmpeg.git 03Reinhard Tartler 07release/1.1:e86074e6ef23: Prepare for 9.15 Release
[20:45] <cone-391> ffmpeg.git 03Reinhard Tartler 07release/1.1:bd41211395fd: Re-release 9.15 as 9.16
[20:45] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:dcce698fd887: Merge commit '437848e37ae7ef73cd8101031dc570d1f009ffd5' into release/1.1
[20:45] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:f953c3c2343d: Merge commit 'bd41211395fd1f968e9f3a4746daffebea60f41e' into release/1.1
[20:57] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:e4fb53c73abe: ffv1dec: check that global parameters do not change in version 0/1
[20:57] <cone-391> ffmpeg.git 03Anton Khirnov 07release/1.1:bbd632082b18: mpegenc: limit the maximum muxrate
[20:57] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:081f4f5f56e0: Merge commit 'e4fb53c73abece15a7c5df0019df9a0371db2297' into release/1.1
[20:57] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:0a6d39791165: Merge commit 'bbd632082b18e6c5ce9c2d6be8bc260c05ae9417' into release/1.1
[21:08] <cone-391> ffmpeg.git 03Anton Khirnov 07release/1.1:8d7839fc7c52: avconv: fix the muxrate values for -target
[21:08] <cone-391> ffmpeg.git 03Anton Khirnov 07release/1.1:e1f0c41e1aa3: avconv: fix parsing the AVOptions for -target
[21:08] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:fed28fe054de: Merge commit '8d7839fc7c52574dfc22db0181b1cef9cb929910' into release/1.1
[21:08] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:946a106995bc: Merge commit 'e1f0c41e1aa37a9c166c43abf1b526c796ed7649' into release/1.1
[21:13] <cone-391> ffmpeg.git 03Luca Barbato 07release/1.1:124ec8b1303d: pulse: Add a wallclock option to be compatible with other other captures
[21:13] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:d03fd2c8052e: Merge commit '124ec8b1303d4f29b833099ce9008e31ac6d7c86' into release/1.1
[21:17] <Timothy_Gu> michaelni: are you going to release another 1.1 soon?
[21:34] <michaelni> Timothy_Gu, i planed to, yes
[21:43] <Timothy_Gu> I have a list of stuff to back port: https://gist.github.com/TimothyGu/f69b74bb24eb15e2d005 Probably not all of them apply to 1.1 but you can pick and choose.
[21:44] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:5865d599c388: avcodec/iff: check pixfmt for rgb8 / rgbn
[21:44] <cone-391> ffmpeg.git 03Christophe Gisquet 07release/1.1:11a61dd0e2b5: proresenc_kostya: report buffer overflow
[21:44] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:c58d7f9eb56a: avcodec: fix aac/ac3 parser bitstream buffer size
[21:44] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:0bf0de718524: avcodec/utils: add GBRP16 to avcodec_align_dimensions2()
[21:44] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:96d1a8f0145b: avcodec/snow: check coeffs for validity
[21:51] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:195fcbff2b64: Update for 1.1.14
[21:51] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:4ede955d864d: remove VERSION file
[21:51] <cone-391> ffmpeg.git 03Michael Niedermayer 07release/1.1:3ed4dc92284c: version.sh: Print versions based on the last git tag for release branches
[22:09] <ubitux> we should disable completely the markup in trac
[22:10] <ubitux> users are completely clueless about it
[22:10] <ubitux> having every message in a <pre> with some basic regex to match url & hashes would be more than enough
[22:11] <ubitux> or should we patch ffmpeg to print {{{ and the beginning and }}} at the end? :P
[22:11] <cone-391> ffmpeg.git 03Jon Morley 07release/1.1:552fe9b07f6b: avcodec/adpcm: Fix incorrect AVSampleFormat for sample_fmts_s16p
[22:11] <cone-391> ffmpeg.git 03Christophe Gisquet 07release/1.1:3231e7ab64ef: wavpack: report if there is no bits left
[22:12] <cone-391> ffmpeg.git 03Christophe Gisquet 07release/1.1:7f7cf051edd3: alacenc: increase predictor buffer
[22:12] <cone-391> ffmpeg.git 03Christophe Gisquet 07release/1.1:60f94f708414: alacenc: fix extra bits extraction
[22:12] <cone-391> ffmpeg.git 03Piotr Bandurski 07release/1.1:f3c8a8b087d0: avcodec/lcldec: fix decoding of YUV444 sample
[22:17] <michaelni> Timothy_Gu, backported what applied cleanly and didnt break compilation. In the future i suggest you backport the commits to release/x.y and ask me to merge/pull, thats safer than backporting what applies cleanly as ommited commits could have side effects though thats probably not common
[22:17] <michaelni> also if someone wants to maintain old release branches or a specific old release branch
[22:17] <michaelni> would be welcome ...
[22:18] <michaelni> my maintaince of them is kind of only "make release if there are some new commits somewhere like locally or from libav or from elsewhere"
[22:19] <michaelni> and backporting critical security issues of course
[23:24] <cone-391> ffmpeg.git 03Reimar Döffinger 07fatal: ambiguous argument 'refs/tags/n1.1.14': unknown revision or path not in the working tree.
[23:24] <cone-391> Use '--' to separate paths from revisions
[23:24] <cone-391> refs/tags/n1.1.14:HEAD: xv.c: Add missing const to lookup table.
[00:00] --- Sun Aug 31 2014