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

[burek]

[00:01] <llogan> saste: i probably won't be able to attend #gsoc IRC on april 19
[00:05] <durandal11707> some machines have time/date off
[00:18] <Compn> saste : aurel 
[00:18] <saste> Compn, why, what happened to him?
[00:19] <Compn> i remember aurel had trouble with ass stuff , dont remember details
[00:19] <Compn> llogan: the last #gsoc wasnt all that useful > http://www.ffmpeg.org/~compn/gsoc.txt
[00:21] <j-b> Compn: what did it say?
[00:22] <Compn> [12:46] <carols> i think you could slightly improve a couple things for next year, but overall, 
[00:22] <Compn>   this was just not enough space
[00:22] <Compn> [12:47] <carols> we really are just trying to make space for new orgs this year.
[00:23] <Compn> which is the answer given to most all the projects that showed up
[00:23] <Compn> (which is kinda strange they had an irc for something they could have put in an email)
[00:29] <jojva> new orgs like gcc, opensuse, wine...
[00:30] <j-b> twitter
[00:30] <j-b> wordpress.com
[00:30] <jojva> fuck i'm mad at this situation, I need someone accountable, who's responsible for this fail
[00:30] <ubitux> saste: ok, reviewing.
[00:33] <llogan> j-b: twitter. i was perplexed at that one.
[00:35] <llogan> jojva: remember? we agreed it was the Sopwith Camel.
[00:36] <ubitux> saste: i think you sent the wrong patch
[00:40] <jojva> llogan: what are you talking about ?
[00:41] <jojva> (i probably wasn't here when this camel was referred to)
[00:42] <llogan> the airplane logo
[00:42] <saste> ubitux: i split x/y from enable
[00:43] <saste> add a misc typo, but the patch looks correct otherwise
[00:43] <ubitux> ok
[00:43] <ubitux> i didn't realize there was two patches
[00:44] <ubitux> i'm tired i believe.
[00:44] <ubitux> saste: i've already reviewed most of the code, consider LGTM
[00:45] <saste> ubitux, ok thanks
[00:47] <jojva> llogan, oh the airplane, right
[00:48] <Compn> jojva : they mean 'new orgs to gsoc'
[00:48] <Compn> not 'new orgs created in last 6 months'
[00:49] <jojva> Compn, i know, i only quoted organizations that weren't new to gsoc
[00:53] <jojva> anyone knows where i can find the bibtex for itu's h264 N
[00:53] <jojva> ?
[00:53] <gnafu> I was really hopeful Rockbox would get picked up and someone would sign up to work on Opus optimization :-P.
[00:56] <llogan> saste:  web/documentation: mention ff*-all pages LGTM
[00:56] <llogan> RE: your latest comments
[00:57] <saste> llogan, you mean with ff* and ff*-all on separate lines?
[01:02] Action: Compn afk bbl
[01:08] <llogan> saste: yes
[01:25] <saste> llogan, a bit ugly?
[01:25] <saste> suggestions are welcom
[01:25] <saste> e
[01:30] <llogan> saste: hmm..yeah, looking at code and then at the actual page doesn't always translate well in my head.
[01:30] <llogan> it's not that bad, but i'll think about how it can be displayed nicer
[01:39] <saste> llogan, maybe a table?
[01:43] <jojva> dec 19, 2000 : libav github repo is created. Why ? there weren't any frictions at that time right ?
[01:44] <llogan> libav is another way of saying FFmpeg libraries.
[01:46] <jojva> ok
[01:47] <llogan> and that is ~10 years before the fork
[01:48] <llogan> and the fork using the name "libav" has been utterly confusing to the general population...
[01:49] <llogan> i didn't know github was around then
[01:49] <llogan> ah, it wasn't
[01:50] <llogan> and git initial release was 2005
[01:51] <j-b> http://www.google-melange.com/gsoc/org/google/gsoc2013/bioconductor so high quality
[01:54] Action: llogan read it but didn't understand/remember one word
[01:55] <jojva> i like bioinformatics
[01:55] <jojva> it'd be my third project desire after ffmpeg and any music player like banshee or rhythmbox
[02:05] <saste> j-b: time to run your own Summer Of Code
[02:06] <saste> call it JBSoC
[02:07] <saste> we should do the same (when we have money)
[04:12] <Zeranoe> This might be a little off topic here, but I'm trying to debug FFmpeg so I can fix that moov atom error. I have a non optimized, unstripped ffmpeg.exe and a working copy of gdb. I can get ffmpeg to give the "moov atom not found" error in gdb, but it isn't crashing so I'm not sure how to find whats going wrong.
[04:13] <Compn> gdb is for crashes 
[04:14] <Zeranoe> Compn: It cannot be used to find FFmpeg errors?
[04:14] <Compn> that error sounds like the demuxer couldnt find the moov atom
[04:14] <Zeranoe> Compn: Correct
[04:15] <Compn> i think you can use gdb or valgrind to find the error if you set breakpoints
[04:15] <Compn> but i dont know how to do that.
[04:16] <Zeranoe> What is a good way to go about fixing these types of errors then?
[04:16] <Compn> ok let me see here
[04:16] <Compn> it only happens on 32bit mingw ffmpeg ?
[04:16] <Zeranoe> yes
[04:16] <Compn> and only with that 4.7gb file ?
[04:16] <Zeranoe> I can provide anything you need
[04:17] <Zeranoe> Compn: Not only, there are a few others but they are large as well, so I was inclined to think it was a size issue. I haven't tried shrinking with dd yet
[04:17] <Compn> imo it sounds like your ffmpeg builds arent reading past the 4gb limit ...
[04:17] <Compn> there is a patch to mingw from sherpya 
[04:17] <Compn> that never got applied upstream
[04:18] <Zeranoe> that reads larger than 4gb?
[04:18] <Compn> yes
[04:18] <Compn> let me see if i can find it
[04:18] <Zeranoe> -D_LARGEFILE_SOURCE is seen in config.log
[04:19] <Compn> are you using mingw-w64  or plain mingw.org mingw ?
[04:19] <Compn> to compile
[04:19] <Zeranoe> mingw-w64
[04:19] <Compn> hmmm
[04:21] <Zeranoe> Compn: I'll try shrinking with dd and see if it reads it then
[04:23] <Compn> you cant cut a .mov because the stupid headers are at the end of the file
[04:23] <Compn> :D
[04:23] <Zeranoe> Any ideas how I can narrow this down?
[04:25] <Compn> got any big avi files ?
[04:25] <Compn> or mkv
[04:25] <Compn> try seeking to past 4gb in those with ffmpeg
[04:25] <Compn> that will tell you if your ffmpeg build is stuck at 4gb limit
[04:27] <Zeranoe> Compn: I don't but I can use a 64-bit build to create a large file with ffmpeg, correct? 
[04:27] <Zeranoe> could I just loop a video till the size adds up to 5gb?
[04:28] <Compn> yes
[04:28] <Compn> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-January/040079.html
[04:28] <Compn> theres the thread discussing this
[04:30] <Compn> ok found the patch
[04:30] <Compn> http://mplayerhq.hu/pipermail/mplayer-dev-eng/2007-January/048904.html
[04:32] <Compn> mingw said it was committed in 2008 i think
[04:33] <Zeranoe> Compn: So in theory mingw-w64 should have no issue handling large files
[04:33] <Zeranoe> Compn: command ideas to create 5gb file?
[04:35] <Compn> mencoder -oac copy -ovc copy 1gbmovie.avi 1gbmovie.avi 1gbmovie.avi 1gbmovie.avi 1gbmovie.avi -o 5gbmovie.avi
[04:37] <Zeranoe> I'm on windows and don't have mencoder, I'm thinking I'll just reconvert the mov file to a mpeg4 file
[04:37] <Compn> download mencoder from sherpya
[04:38] <Compn> http://oss.netfarm.it/mplayer-win32.php
[04:38] <Compn> if you have just plain .mpeg files, you can cat those together
[04:38] <Compn> maybe
[04:40] <Zeranoe> Compn: Is there a loop option for FFmpeg? I have a 1gb avi, just want to -c:v copy it 5 times?
[04:48] <Compn> Zeranoe : concat 
[04:49] <Compn> in the ffmpeg manual , look it up
[04:49] <Compn> i never used it , so i dont know command line :\
[04:49] <Compn> but i'd like to learn 
[04:49] <Compn> if you figure it out lemme know
[04:49] Action: Compn kinda distracted
[04:49] <Zeranoe> Compn: Ended up dumping rawvideo, added up the size pretty quick
[04:50] <cone-623> ffmpeg.git 03Michael Niedermayer 07master:5fbf9c12aa0d: avfilter/vf_noise: fix build without mmx*inline
[04:52] <Compn> rawvideo good yeah
[04:59] <Compn> Zeranoe : so can you seek past 4gb on your raw file ?
[05:00] <cone-623> ffmpeg.git 03Marton Balint 07master:325846aac0ae: ffplay: set time_base of audio filter buffer src
[05:00] <cone-623> ffmpeg.git 03Marton Balint 07master:0b24e341ed75: ffplay: handle audio buffersink output properly with buffering filters
[05:00] <cone-623> ffmpeg.git 03Marton Balint 07master:5dacf7b1ab40: ffplay: fix indentation
[05:00] <cone-623> ffmpeg.git 03Marton Balint 07master:85b9bf5693c8: ffplay: simplify video pts calculation
[05:00] <cone-623> ffmpeg.git 03Michael Niedermayer 07master:93e8fcb94b1a: Merge remote-tracking branch 'cus/stable'
[05:02] <Zeranoe> Compn: Yes... 
[05:02] <Zeranoe> So it can't be file size now?
[05:08] <Compn> hmm
[05:10] <Compn> is it a problem in the mov probe ?
[05:11] <Zeranoe> I'm not sure, I think it might be the toolchain because that other user reported success for 32-bit. Normally compiler issues will crash the exe though
[05:13] <Compn> Zeranoe : did you ever fix the win2k ffmpeg dll link ?
[05:14] <Compn> i mean , compiling against winxp dlls , means cant use ffmpeg on win2k :\
[05:17] <Zeranoe> I haven;t had a chance to look into that yet
[05:17] <Compn> difficult one to pin down, for sure
[09:38] <KnightRiderRetro> hi devs
[09:39] <KnightRiderRetro> it seems recent commits to ffplay has caused a weired bug in ffplay
[09:39] <KnightRiderRetro> causing to to play audio longer than it should
[09:39] <KnightRiderRetro> totally messing up the displayed clock
[09:40] <KnightRiderRetro> i have a sample to demonstrate it with recent builds
[09:40] <KnightRiderRetro> if anyone wann have a look at it
[09:54] <ubitux> KnightRiderRetro: please open a ticket
[09:55] <ubitux> the ffplay maintainer is not on irc
[09:56] <KnightRiderRetro> ubitux: ok
[10:12] <durandal_1707> michaelni: can you tell me story behind ow filter?
[10:18] <durandal_1707> what of this: ttp://wiki.multimedia.cx/index.php?title=Libavfilter_Shortcomings is still valid?
[10:35] <ubitux> durandal_1707: error reporting should be done
[10:35] <ubitux> filter help is done iiuc
[10:36] <ubitux> but that page is lacking some
[10:37] <durandal_1707> like?
[10:40] <ubitux> timeline, and a bunch of useful filters
[10:45] <durandal_1707> timeline?
[10:45] <durandal_1707> and what is bunch of useful filters?
[10:46] <ubitux> timeline: being able to simply make filters apply in a range of time/frames
[10:46] <ubitux> useful filters: good fft 2d/3d denoisers, motion interpolation based filters, etc
[10:46] <ubitux> that kind of stuff; see old Derek thread
[10:46] <durandal_1707> etc is not helpful
[10:47] <ubitux> that's a good start; check the mail for more
[10:47] <durandal_1707> the only point i remmebmer from Derek thread is no scripting
[10:49] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-October/132031.html
[10:49] <ubitux> see the section before the conclusion
[10:53] <durandal_1707> select filter should really support more formats
[10:54] <ubitux> it supports them all
[10:55] <ubitux> as long as you don't have scene detection active
[10:55] <durandal_1707> but scene detection could support more?
[10:56] <ubitux> should be possible yes
[10:58] <durandal_1707> we don't have filter that separate fields?
[10:58] <ubitux> "field" should do it
[10:59] <ubitux> i'd be curious about the parameters required for field,tinterlace to be equivalent to the passthrough
[10:59] <ubitux> without messing pts, aspects, et
[10:59] <ubitux> etc
[10:59] <durandal_1707> so field is same as SeparateField from that flame?
[11:00] <ubitux> i think so
[11:02] <durandal_1707> next filter i gonna write: separaterows, separatecolumns
[11:02] <durandal_1707> or i should call it just row/column?
[11:04] <durandal_1707> they have weave filter
[11:04] <durandal_1707> also SelectEvery is just our select, isn't it?
[11:07] <durandal_1707> ubitux: actually separate files, does not dump other half of frames :)
[11:07] <durandal_1707> *fields
[11:09] <durandal_1707> i could add option to filed filter instead of creating new filter
[11:13] <durandal_1707> also swapfields is same as calling 3 functions
[11:13] <durandal_1707> but i belive this can be made much faster
[11:16] <ubitux> durandal_1707: i don't understand what you said about seperate fields
[11:16] <ubitux> durandal_1707: the idea of such filter is to do something like that afaik: field, foobar, tinterlace
[11:17] <durandal_1707> ubitux: separatefields produce 2x frames at 2xFPS
[11:17] <durandal_1707> field filter just dump half of fields
[11:17] <ubitux> mmh
[11:17] <ubitux> i thought it was splitting the top and bottom fields in a dedicated frame
[11:17] <mateo`> someone is talking about separate fields :D
[11:18] <ubitux> :)
[11:18] <ubitux> durandal_1707: maybe we should add an option to vf field
[11:18] <durandal_1707> nope
[11:18] <ubitux> ?
[11:18] <durandal_1707> more filters - better
[11:18] <ubitux> well...
[11:19] <ubitux> i don't think that's really better
[11:19] <ubitux> field is really small and has not much purpose
[11:19] <durandal_1707> then adding mode option with values : extract & separate ?
[11:20] <ubitux> possibly yes
[11:20] <durandal_1707> than what about generic ones like separaterows/columns?
[11:20] <ubitux> what's the point of separatecolumns?
[11:21] <durandal_1707> same as for fields but this time for N columns
[11:21] <ubitux> fields separation is useful
[11:21] <durandal_1707> point is to have it, because *synth have it
[11:21] <ubitux> avisynth has seperate column filter?
[11:22] Action: ubitux wonders if this is a joke
[11:22] <durandal_1707> http://avisynth.org/mediawiki/SeparateFields
[11:22] <ubitux> sounds completely useless, but well, do as you please :p
[11:23] <durandal_1707> ubitux: mplayer tfields is similar to synth one
[11:23] <durandal_1707> we dont have tfields here for some lucky reason
[11:24] <durandal_1707> it have some strange interpolation....
[11:25] <durandal_1707> reverse of separate* is weave
[11:25] <ubitux> tinterlace? :p
[11:26] <durandal_1707> much simpler
[11:26] <durandal_1707> http://avisynth.org/mediawiki/Weave
[11:26] <durandal_1707> i mention all this filters because you gave me that link
[11:26] <ubitux> i was trying to achieve such thing with field, tinterlace the other day
[11:26] <ubitux> it wasn't working that well
[11:26] <ubitux> now i understand why
[11:26] <ubitux> :D
[11:27] <ubitux> durandal_1707: but yeah, seperate/join fields will be useful
[11:27] <durandal_1707> as an option to filter or new filter?
[11:27] <ubitux> as you wish
[11:27] <durandal_1707> or field should really be named extractfield
[11:28] <durandal_1707> i could make field do join & separate
[11:29] <ubitux> field=extract, field=join, field=separate ?
[11:30] <durandal_1707> nope first arg it type: top/bottom - usefull only if you separate/join to 2
[11:30] <durandal_1707> anyway it already have hardcoded explicit description
[11:30] <durandal_1707> so i create new filter
[11:30] <ubitux> ok
[11:31] <durandal_1707> adding bit monolitic filters (as I experienced with jfmeter/phaserscope) only gives headeaches
[11:31] <durandal_1707> *big
[11:32] <ubitux> what happens to them btw?
[11:32] <durandal_1707> enotime
[11:33] <Bor0> why is it that for some videos I get is->ic->duration/1000000LL > is->video_current_pts at the end of the video, instead of them being equivalent?
[11:33] <Bor0> the difference is about 0.8
[11:36] <durandal_1707> flaming list with invalid statement like we do not have SelectEvery funcionality is just trolling
[11:37] <durandal_1707> what about that alphamerge/extract user question on ml?
[11:46] <durandal_1707> i gonna write smptehdbars too
[11:46] <durandal_1707> so much filters to write, so much little time
[11:51] <cone-905> ffmpeg.git 03Martin Storsjö 07master:bc0522dffacb: h264pred: Add a few missing const declarations for ff_cropTbl derived pointers
[11:51] <cone-905> ffmpeg.git 03Andrew Van Til 07master:350ad50bf45d: lavf: Use RTP_MAX_PACKET_LENGTH instead of 1500
[11:51] <cone-905> ffmpeg.git 03Andrew Van Til 07master:0e729b2290cf: rtpdec: Increase max rtp packet size to 8192
[11:51] <cone-905> ffmpeg.git 03Martin Storsjö 07master:fc792308c5ae: srtp: Include rtpdec.h for RTP_MAX_PACKET_LENGTH
[11:51] <cone-905> ffmpeg.git 03Michael Niedermayer 07master:4e0130faed10: Merge remote-tracking branch 'qatar/master'
[11:53] <michaelni> durandal_1707, story behind vf_ow ? dunno, its one of several filters that was implemented and yeah maybe someone used it maybe not
[16:40] <cone-724> ffmpeg.git 03Michael Niedermayer 07master:c03dc44070cd: msmpeg4: fix asm code in ff_msmpeg4_pred_dc()
[16:40] <cone-724> ffmpeg.git 03Michael Niedermayer 07master:b4eb06d32535: msmpeg4: ignore negative DC overflow
[16:40] <durandal_1707> there is yet another color space issue on trac
[17:21] <durandal_1707> ubitux: shouln't it be possible to do same funcionality as separatefields with split and 2 field filters and some other filter that would put them back together?
[17:21] <ubitux> possibly, but that might be a pain to use
[17:22] <durandal_1707> because separatefilds would do same as field it will write it into same file
[17:24] <durandal_1707> but one frame may have hight different than next one, what to do in such situation?
[17:24] <durandal_1707> *height
[17:25] <durandal_1707> eg. if hight is not multiple of 2
[17:25] <ubitux> reject?
[17:32] <Compn> you mean resolution change ?
[17:32] <Compn> oh no field stuff , nm
[17:35] <Compn> michaelni : re that wmv2 bug. how long did it take you to figure out which piece of optimization (mmx / sse / asm) was causing the problem? and is there an easy way to only use the c-version or asm-version of a codec , or must it be recompiled ? also has anyone ever made a test to see if the various cpu optimizations or asm versions are identical to the c-versions ?
[17:36] <durandal_1707> Compn: no, no and no
[17:37] <Compn> i ask because i wonder if it would make it easier for us bug testers to find the problem , so devs dont have to spend so much time testing
[17:37] <durandal_1707> Compn: become dev
[17:38] <Compn> durandal_1707 : yes, but i'm trying to say... only michael can figure out that bug. even other devs would take a while to pin it down
[17:38] <Compn> but if we had some easy way to try different optimizations of the same codec (i guess just have multiple ffmpeg binaries?) 
[17:40] <Compn> i will try to write a debugging document for ffmpeg bugs
[17:40] <Compn> what to try first, next, last
[17:42] <durandal_1707> Compn: ask michaelni to setup remote desktop
[17:42] <durandal_1707> than just watch what he does :)))
[17:42] <durandal_1707> alternative take a trip to michaelni 
[17:43] <nevcairiel> Compn: ffmpeg has a -cpuflags option which you can use to tell it which asm to use (if it was compiled with runtime cpu detect)
[17:43] <michaelni> Compn, "-cpuflags 0 " works in some cases, others --disable-asm will disable asm
[17:43] <michaelni> hmm nevcairiel was quicker :)
[17:43] <michaelni> in this case here -cpuflags wouldnt have worked and --disable-asm would have been needed
[17:44] Action: michaelni goes afk
[17:45] <durandal_1707> for how long?
[17:45] <Compn> nevcairiel / michaelni : ok thanks for answers . i will write them into a doc on the wiki :)
[17:51] <durandal_1707> if frame is not writtable, is it allowed to change its members(h,w,...) ?
[17:55] <durandal_1707> why i did not get review for latest telecine?
[17:56] <ubitux> durandal_1707: did you check the html of your doc?
[17:57] <ubitux> typically the example patterns part
[17:57] <durandal_1707> no i don't have that installed
[17:58] <ubitux> i think it will be broken
[17:58] <ubitux> the \n won't appear
[17:58] <ubitux> it's possible it will be the same with the manpages actually
[17:59] <durandal_1707> so how to force them?
[17:59] <ubitux> @example or @table i'd say
[18:00] <ubitux> while at it you could fix the broken ident for the tc->temp alloc check
[18:01] <durandal_1707> heh
[18:02] <ubitux> return is prefixed with too much spaces
[18:03] <durandal_1707> yea, i know, i think you did not understand "heh" part
[18:03] <ubitux> ah, sorry
[18:03] <ubitux> ok last thing (sorry review over irc): you don't need to copy all the outlink settings in config_output()
[18:04] <ubitux> i did it in decimate because of multiple output
[18:59] <nevcairiel> how annoying, when avformat uses a parser, the parsing process eats AVPacket side_data
[19:10] <durandal_1707> nevcairiel: it should not
[19:11] <nevcairiel> but it does
[19:11] <nevcairiel> at least when you tell it not to merge it into the bitstream
[19:12] <nevcairiel> (because i want it in my demuxer, and not forwarded to the decoder)
[19:15] <durandal_1707> ubitux: ok, now i would like to get LGTM
[19:16] <durandal_1707> btw, this is not that complicated like cinepak encoder
[19:20] <DimStar> Hi all... I know the topic is lame.. but I'm fighting some legal systems... and was wondering which part of ffmpeg are 'known' to be 'discussable' in some countries... and which parts are 'safe'.
[19:22] <durandal_1707> DimStar: if you sell binary with patents you need to pay to patent holder - basically what law of such country say
[19:22] <ubitux> durandal_1707: if you did the above changes i have nothing to add
[19:23] <durandal_1707> interesting: libopus >= libfdk_aac >= libvorbis >= libmp3lame > eac3/ac3 > libfaac >= libtwolame > aac > mp2 > wmav2/wmav1 > vorbis > libvo_aacenc 
[19:23] <DimStar> durandal_1707: yes.. that is known.. but I was wondering if 'all' libs in ffmpeg tree are covered by patents (like swscale for example)
[19:23] <DimStar> the various mpeg codecs are easy to answer.
[19:23] <kierank> everything is covered by patents
[19:23] <durandal_1707> even colors
[19:24] <ubitux> even patents
[19:24] <DimStar> ok... I guess this is making a point ad absurdum... 
[19:24] <kierank> DimStar: what parts of ffmpeg do you want to use
[19:25] <DimStar> kierank: swscale is the one on my radar for now...
[19:25] <kierank> probably patented
[19:25] <nevcairiel> in short, its impossible to say what is patented and what is not, there are huge court battles from the big companys because even they can't agree, and we're lot lawyers anyhow
[19:25] <nevcairiel> s/lot/not/
[19:26] <DimStar> nevcairiel: understood...
[19:26] <DimStar> and yes, of course, this all black magic...
[19:26] <DimStar> I know for example that various distributions consider 'libavutil' as safe...
[19:26] <nevcairiel> it probably isnt
[19:26] <kierank> probably crc is patented somehow
[19:26] <kierank> and tons of other things
[19:27] <nevcairiel> it contains an implementation of aes and crc, some of those things are bound to be patentet
[19:27] <nevcairiel> *patented
[19:28] <DimStar> you mean like http://www.google.com/patents/US7577899 for CRC? Seems nobody gives a hoot about this... :)
[19:29] <DimStar> so, I'd assume if swscale is 'as safe as libavutil' it might be ok.. (if it's as unsafe as mpeg codecs, it's not so easy)
[19:29] <nevcairiel> it contains upscaling algorithms and whatnot, those are probably also patented
[19:30] <michaelni> a xor b is patented too
[19:30] <nevcairiel> the way i see it, screw software patents and just continue working, even if you would re-write swscale from scratch, you would end up violating some patent
[19:30] <nevcairiel> this is why software patents are so bad =p
[19:31] <DimStar> nevcairiel: I don't care much for them.. but as a packager for a distribution, I have to see what the sponsor (american based) agrees to.
[19:31] <DimStar> as said: libavutil was acceptable for them..
[19:32] <michaelni> libswscale should be similar to libavutiil but thats just my oppinon
[19:32] <DimStar> michaelni: ok.. that is already a statement :)
[19:33] <kierank> the rgbyuv stuff is heavily patented
[19:34] <nevcairiel> as soon as you get into actual video area, its a minefield
[19:34] <michaelni> kierank, might be, but are the patents valid and does the patent holder actual do anything with them
[19:35] <kierank> more likely that aes/crc i think
[19:35] <kierank> av500 has a patent
[19:35] <DimStar> michaelni: right.. THAT is exactly where it comes down to.. MPEG LA is active.. rgbyuv seems not to be really doing much.
[19:35] Action: kierank is scared of av500
[19:35] <kierank> mpeg-la is only active at the large scale
[19:36] <DimStar> kierank: which unfortunately linux distributions are at the moment..
[19:38] <ubitux> [PATCH 17/17] cmdutils: allow -h filter=<name> to print information about a filter.
[19:38] <ubitux> oh boy.
[19:38] <kierank> DimStar: not really
[19:38] <kierank> small fry by mpeg-la standards
[19:38] <nevcairiel> didnt the mpeg-la even say that h264 for example is free to be used for such cases?
[19:38] <kierank> no
[19:39] <kierank> mpeg-la said free web streaming does not incur a fee
[19:39] <nevcairiel> oh right, so pages like youtube dont have to pay
[19:39] <kierank> yeah
[19:41] <nevcairiel> the way i see it, as long as people that produce hardware compatible with mpeg-la stuff pay, they'll probably remain happy :p
[19:46] <michaelni> kierank, also another point if theres a real issue with yuvrgb then it also affects SDL, theora and jpeg
[19:46] <kierank> michaelni: of course
[19:46] <kierank> but i am talking in relatives compared to libavutil
[19:47] <michaelni> hmm, ok misunderstood you slightly then
[20:12] <ubitux> so, no more review for ivtc & decimate ?
[20:12] <ubitux> also, i guess no one except nicolas will comment on the ass/ssa patch?
[20:13] <ubitux> btw, last ping on libquvi
[20:26] <louiz> what about libquvi?
[20:27] <llogan> louiz: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-April/141690.html
[20:27] <louiz> thank you
[21:49] <cone-724> ffmpeg.git 03Clément BSsch 07master:1043cb8e80e2: lavc/ass: use bprint API in ff_ass_add_rect().
[22:04] <ubitux> oh ffs
[22:04] <ubitux> i failed at reply again
[22:05] <ubitux> no wonder no one is replying
[22:06] <nevcairiel> michaelni: there is a h264 performance regression after 644092c8e8892f4f7e44a01b83487b398cafeb5a, on my system a interlaced file using frame threading goes from 52fps to 38 fps (that particular file doesn't multi-thread very well in the first place, it seems)
[22:07] <nevcairiel> i'll open a ticket i guess
[22:07] <Compn> whoa , big drop
[22:08] <nevcairiel> in percentage, yes =P
[22:08] <Compn> do we have any fate tests for speed regression ?
[22:09] <nevcairiel> no
[22:09] <Compn> would be hard with shared cpu and virtualization and such
[22:10] <iive> even harder with multithreading.
[22:10] <nevcairiel> yeah this seems like a threading regression
[22:10] <nevcairiel> not single-threaded
[22:11] <nevcairiel> progress report related
[22:14] <nevcairiel> now i first need to figure out what the option to  benchmark ffmpeg was, or carl yells at me in the ticket
[22:22] <ubitux> btw, still no one to write the cool matroska features in our demuxer?
[22:51] <ubitux> it's about colors, so i guess i can paste it here: http://theoatmeal.com/comics/mantis_shrimp
[22:52] <ubitux> (at least the beginning, a little.)
[23:16] <saste> ubitux: ping on overlay
[23:16] <saste> enable and process patches
[23:16] <ubitux> saste: i ok'ed it on irc :p
[23:17] <saste> ubitux, you can't never be sure with irc
[23:17] <saste> splice is almost ready
[23:17] <ubitux> will it work correctly with tons of frames ?
[23:18] <saste> ubitux, can't say...
[23:18] <saste> caching logic proved to be quite tricky, as expected
[23:22] <saste> ubitux, what about the select branch patch?
[23:22] <cone-724> ffmpeg.git 03Michael Niedermayer 07master:62a1181015c2: h264: wait for missing slices only on frames
[23:22] <ubitux> does the select branch patch makes any sense without splice?
[23:23] <saste> ubitux, why not?
[23:23] <ubitux> well, extra complexity for nothing
[23:23] <ubitux> i mean i have a hard time figuring out a use case
[23:23] <saste> for example you can do: select=...:branch=1 [out], showinfo, nullsrc
[23:24] <ubitux> also, if splice has undefinied behaviour with large amout of frames, it kind of defeat its original purpose, aka timeline editing
[23:24] <ubitux> saste: and what's the point?
[23:24] <ubitux> dumping info about the rejected frames?
[23:24] <saste> yes
[23:24] <ubitux> does that make any sense? :D
[23:25] <ubitux> if it's for debugging, you can just not() the expression
[23:25] <saste> or you want to keep the not selected frames for whatever reason
[23:25] <saste> for example if you want to implement if else if else logic
[23:26] <saste> it can be implement with split and two selects, but it's not as convenient
[23:26] <ubitux> i'm still not convinced of a use case :p
[23:26] <ubitux> i'd better discuss it if you find splice useful enough and consider it worth inclusion
[23:27] <ubitux> so anyway, again, the x/y expr in overlay LGTM, and the enable as well
[23:42] <durandal11707> ubitux: why you think pts would not be correct?
[23:43] <ubitux> dunno, 1 or even low fps video?
[23:43] <ubitux> small tb i mean
[23:44] <ubitux> i mean this +1 is only valid in a very specific case of tb and fps matching, no?
[23:44] <ubitux> typically with mpeg stream for example, that will likely be inaccurate
[23:45] <ubitux> (and you need some set fps such as in telecine)
[23:45] <ubitux> unless i'm missing something?
[23:46] <durandal11707> shit
[23:46] <ubitux> sorry :p
[23:56] <durandal11707> ubitux: when you push your filters?
[23:56] <ubitux> which ones?
[23:56] <ubitux> ivtc & decimate?
[23:56] <durandal_1707> yes
[23:56] <ubitux> i don't mind but i got almost no review
[23:56] <durandal_1707> so i can push mine 2 at same time
[23:58] <ubitux> durandal_1707: also, i'm thinking of waiting after the avoption merge
[00:00] --- Wed Apr 10 2013