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

[burek]

[00:01] <cone-710> ffmpeg.git 03Jean First 07master:7fc73d9ab781: rmdec: fix compiler warning for uninitialized variables
[00:44] <burek> too bad ffmpeg does not implement anything like commercial licenses or something.. that way it would be able to gather funds for paid developers in needed areas, such as ffserver for example
[01:00] <durandal_1707> burek: bullshit
[01:03] <kierank> JEEB: fdk-aac is not lgpl compliant
[01:04] <JEEBsv> orly? I thought it was mostly the you cannot take money from this clause that made it not GPL compliant
[01:04] <kierank> no
[01:05] <JEEBsv> LGPL on the other hand gives much more leeway, but if not then not
[01:05] <kierank> the clause that mandates a patent licence is an additional restriction to the (l)gpl
[01:05] <kierank> the commercial one is quite clear imo
[01:05] <JEEBsv> ah
[01:05] <kierank> the commercial one says you cannot licence fdk-aac under a commercial licence
[01:05] <kierank> i.e you pay money and get software rights
[01:05] <kierank> but the lgpl gives you those rights anyway
[01:06] <kierank> irrespective of whether you charge for distribution
[01:06] <JEEBsv> yeah
[01:07] <JEEBsv> had mostly not noticed the patent thingy, and IIRC it wasn't really brought up during the "does this really need nonfree" discussions
[01:07] <burek> durandal_1707, that's a perfect argument :)
[01:08] <burek> ffserver is lacking a developer for a long time now btw
[01:09] <kierank> because there are better tools for streaming
[01:09] <kierank> like vlc
[01:10] <burek> better tools that are developed by people who ignore the segfault in the latest git for 3 days
[01:10] <burek> although ive provided several logs for it
[01:11] <burek> even narrowed down exact commit...
[01:11] <kierank> that's because nobody uses it
[01:11] <kierank> if people used it, it would get fixed
[01:11] <burek> lol :)
[01:11] <burek> never mind
[01:11] <burek> im just wasting time
[01:11] <durandal_1707> "better tools that nobody uses"
[01:11] <wm4> so ffserver is kind of like using ffplay as video player?
[01:12] <beastd> burek: cool down.  3 days is not that long.
[01:12] <ubitux> wm4: ffserver is pretty nice, and ffplay as well :)
[01:12] <ubitux> IMO :p
[01:12] <JEEBsv> they're nice as proofs of concepts, I guess :)
[01:13] <ubitux> no, they are useful tools
[01:16] <durandal_1707> ffmpeg nice, but is just hack, dont use it
[01:16] <wm4> all correct, except the "nice" part
[01:24] <ubitux> "ffserver is pretty"?
[01:27] <Compn> yeah vlc to stream something... until you want to actually watch the stream, and find out no other program can actually play vlc's streams
[01:27] <Compn> hunt for a format and protocol that will work, eventually giving up and starting up ftp or http daemon...
[01:28] Action: Compn isnt bitter at all
[01:28] <wm4> can't everyone just use vlc?
[01:28] <Compn> playback only! :P
[01:28] <wm4> ffmpeg's codec should be merged into vlc as well, because it has a better architecture
[01:29] <wm4> *codecs
[01:29] <Compn> what
[01:29] <Compn> vlc uses libavcodec...
[01:29] <Compn> or you mean ... the entire tree like mplayer does ?
[01:29] <JEEBsv> heh, I remember watching certain VLC-streamed mpeg-ts-in-http (H.264/AAC) streams with mplayer2/mplayer just fine...
[01:30] <Compn> this was a few years ago, before computer was fast enough to decode something and encode h264 in realtime ...
[01:30] <wm4> Compn: it was an attempt at trolling, suggesting that all codecs should be ported to be native vlc modules
[01:30] <Compn> oh, yeah vlc reinvents some wheels
[01:30] <Compn> french jerks!
[01:31] <JEEBsv> my capbox can only handle 320x180 H.264 re-encoding of Japanese DTV so I can't do proper private streams yet :/
[01:33] <JEEBsv> (I could almost just handle that with just re-streaming the 1seg, but meh)
[01:33] <JEEBsv> (low frame rate is the derp of 1seg)
[01:48] <cone-710> ffmpeg.git 03Michael Niedermayer 07master:4f927542fbf6: h264_direct: silence several warning: assignment from incompatible pointer type"
[01:48] <cone-710> ffmpeg.git 03Michael Niedermayer 07master:2eab1a178ca4: imgconvert: dont depend on default return type for get_color_type()
[01:48] <cone-710> ffmpeg.git 03Michael Niedermayer 07master:2ad1eb190781: imgconvert: fix 2 "discards const qualifier from pointer target type"
[01:48] <cone-710> ffmpeg.git 03Michael Niedermayer 07master:169dfe320d3a: lcldec: fix zlib const pointer warning
[01:50] <ubitux> -vf 'split[x][y]; [x]field=top,pad=iw:ih*2[t]; [y]field=bottom[b]; [t][b]overlay=0:h'
[01:50] <ubitux> e
[01:51] <wm4> readable
[01:51] <ubitux> irony?
[01:51] <wm4> definitely
[01:51] <Compn> whats that do
[01:51] <Compn> split fields from interlaced ?
[01:52] <ubitux> display even fields and below the odd ones
[01:52] <ubitux> wm4: looks pretty readable to me :p
[01:52] <Compn> switch field order
[01:53] <iive> I like it.
[01:53] <wm4> ubitux: looks like gibberish
[01:53] <ubitux> :/
[01:53] <ubitux> i could add spaces
[01:54] <ubitux> -vf 'split[COPY1][COPY2]; [COPY1] field=top, pad=iw:ih*2 [TOP]; [COPY2] field=bottom [BOTTOM]; [TOP][BOTTOM]overlay=0:h'
[01:54] <ubitux> would that be better?
[01:54] <wm4> I can see the future: people will create command lines with thousands of characters, and everyone who has to maintain the graph parser or who is still on #ffmpeg to give user support will hate you
[01:55] <wm4> but that's just my lowly opinion, now excuse me
[01:55] <ubitux> seriously it doesn't look like that hard to understand when you have the basic concepts
[01:55] <iive> ubitux: no. it is worse. now you use space as separator for 2 different things.
[01:55] <ubitux> yes
[01:56] <ubitux> iive: it's hard to improve when it's already perfect
[01:57] <iive> ubitux: new lines :)
[01:58] <ubitux> yep :)
[01:58] <Compn> wm4 : i'm curious what your proposed idea of controlling filters is 
[01:58] <ubitux> lua
[01:58] <Compn> xml scripts
[01:58] <Compn> :P
[02:14] <michaelni> lua parsing a xml script in a virtual machine written in java script running in firefox ;)
[02:20] <ubitux> welcome in the future
[02:21] <ubitux> Single frame detection: TFF:152 BFF:152 Progressive:1313 Undetermined:700
[02:21] <ubitux> :(
[02:28] <ubitux> is poll_frame still needed?
[02:44] <iive> -vf [in1->]split[->a][->b];  [a->],field=top,pad=iw:ih*2,[->top];  [b->],field=bottom,[->bottom]; [top->][bottom->]overlay=0:h'
[02:45] <iive> does this look better? at least it marks what is input and what is output.
[02:49] <ubitux> you should use ’ and  instead; this ascii notation could suggest it's part of the syntax
[02:51] <iive> it is
[02:55] <ubitux> i would prefer e and - instead btw
[03:04] <iive> this is not really an argument.
[03:07] <iive> the arrows help indicate what chain is input and what is output.
[03:08] <ubitux> yes but e are cute
[03:09] <iive> ubitux: trolling is not your thing.
[03:10] <ubitux> :(
[03:10] <ubitux> anyway, does anyone have any idea why in the vf idet, in uninit() the two final av_log shows a different behaviour: first one never displays the context pointer thing
[03:10] <ubitux> ?
[03:10] <ubitux> Single frame detection: TFF:4 BFF:5 Progressive:39 Undetermined:80
[03:10] <ubitux> [Parsed_idet_0 @ 0x28fd5e0] Multi frame detection: TFF:0 BFF:22 Progressive:106 Undetermined:0
[03:11] <ubitux> that's a bit ugly :(
[03:11] <ubitux> using -nostats from ffmpeg doesn't help
[04:24] <ubitux> [Parsed_idet_0 @ 0x2008880] Telecine score: 47%
[04:25] <ubitux> not really efficient :p
[05:13] <cone-710> ffmpeg.git 03Michael Niedermayer 07master:67c1acf2346b: lavc/utils: fix 'warning: missing braces around initializer'
[05:13] <cone-710> ffmpeg.git 03Michael Niedermayer 07master:fceeac984735: vc1dsp: fix pointer type warnings
[05:13] <cone-710> ffmpeg.git 03Michael Niedermayer 07master:b36745339df0: libswscale/swscale-test: fix some const correctness
[07:47] <highgod> Hi all,I want to ask what's the procedure followed by ffmpeg community for acceptance? Thanks
[07:53] <ubitux> your patch is still all broken
[07:55] <highgod> Hi, I rewrite a patch again,and send it to ffmpeg devel,thanks.
[07:56] <highgod> reference to vda_h264_dec
[07:56] <highgod> today
[08:11] <highgod> Hi, @ubitux, do you mean the patch I submit today? hehe. Can you say more details? I will correct it. Thanks
[08:22] <ubitux> highgod: start reading this: https://www.ffmpeg.org/contact.html
[08:23] <ubitux> also: your coding style is a complete nonsense, you're mixing CLRF, and the patch you inline (why are you attaching it two times?) is completely broken by your mailer
[08:24] <highgod> OK,thanks
[12:01] <cone-835> ffmpeg.git 03Stefano Sabatini 07master:e06c1475810c: lavfi/aresample: fix style
[12:01] <cone-835> ffmpeg.git 03Stefano Sabatini 07master:955c7c7bc69a: doc/resampler: extend docs for min_comp and min_hard_comp options
[14:04] <mateo`> hi there ! i'm currently looking at libavfilter/drawutils.c blend_line function, i can't figure out what is the purpose of the left and right parameters and the code it triggers, can someone help me ?
[14:08] <Compn> probably ubitux knows what thats about
[14:08] <Compn> but i dont think hes alive right now mateo`
[14:09] <Compn> mateo` : if you figure it out or ubitux says something, make sure someone writes a comment in the source ;)
[14:11] <mateo`> Compn: then i guess i'll have to wait or try harder to understand (i just don't get why the computations are different for the right and left case than in the for loop)
[14:13] <mateo`> Compn: and indeed more documentation on this piece of code would be great :)
[14:25] <iive> seems like it have somehting to do with subsampling, it probably antialiases the most left and the most right pixels
[14:27] <durandal_1707> burek: why you censor irc logs?
[14:28] <cone-835> ffmpeg.git 03Michael Niedermayer 07master:075eaf8d6afc: vc1dsp: fix the warning fix, make it work with --disable-asm
[14:30] <burek> durandal_1707, please be more specific when you state something like that
[14:31] <durandal_1707> burek: do you censor irc logs?
[14:32] <burek> durandal_1707, what is your problem?
[14:33] <burek> tell me what's wrong and ill take a look but avoid asking such kind of questions insinuating im doing something like that on purpose
[14:34] <burek> and no, of course im not censoring anythin, why would i do that?
[14:34] <Compn> lol why you guys fighting ?
[14:35] <Compn> burek : maybe an irc log is missing or timestamps are off
[14:35] <durandal_1707> burek: then you send same message multiple times, and i replied on 2nd one ..?
[14:36] <burek> i don't know what are you talking about, and i can't (still) read minds, sorry...
[14:37] <durandal_1707> don't worry, you said you don't censor so I trust you
[14:38] <Compn> what irc log message is missing durandal_1707 ?
[14:38] <durandal_1707> nothing really important (i dont have any real evidence....)
[14:39] <burek> oh.. i see.. you're talking about this
[14:39] <burek> [00:46:58] <burek> too bad ffmpeg does not implement anything like commercial licenses or something.. that way it would be able to gather funds for paid developers in needed areas, such as ffserver for example
[14:39] <burek> yes i sent it 2 times
[14:39] <durandal_1707> lol
[14:39] <burek> because 1st time nobody even cared to respond
[14:40] <nevcairiel> the response to that is easy: its impossible =P
[14:41] <Compn> what is your definition of commercial license
[14:41] <michaelni> sure its possible if *GPL == commercial license
[14:41] <Compn> i thought it was a joke
[14:41] <Compn> few people sell ffmpeg ...
[14:41] <burek> well, it's certainly better than durandal_1707's answer :)
[14:41] <Compn> quite a few, that is
[14:41] <michaelni> you can even sell GPL licenses i suspect :)
[14:42] <michaelni> you just cant keep the guy buying it from doing the same
[14:42] <nevcairiel> i guess it always depends what you want to do. LGPL permits using it just fine in commercial software as long as they obey to the license properly
[14:42] <Compn> people sell gpl linux ?
[14:42] <Compn> unheard of!
[14:42] <nevcairiel> but creating a "full" commercial license is impossible without ever contributor aggreeing :p
[14:43] <nevcairiel> every*
[14:43] <Compn> redhat was sold in computer stores, in .. boxes?
[14:43] <Compn> :P
[14:43] <nevcairiel> selling phyiscal media of gpl software is explicitly allowed
[14:43] <nevcairiel> as long as its only the cost of the media
[14:43] <Compn> wha
[14:43] <Skyler_> it's funny, corecodec has actually been asked multiple times "oh, you have a commercial license for x264!  do you have one for ffmpeg?"
[14:43] <Compn> theres no limitation like that lol
[14:43] <Skyler_> because companies really really want to be able to pay money for things that are already free
[14:44] <Skyler_> (we have to tell them no obviously, but)
[14:44] <Compn> Skyler_ : by commercial license i'm guessing you mean 'combined license from various patented codec companies'
[14:44] <Skyler_> no, I mean non-(l)gpl code license
[14:44] <Skyler_> i.e. they pay money, they get something that doesn't have the evil brand of richard stallman on it or whatever scares them
[14:45] <Compn> ehe
[14:45] <Compn> could always try a relicensing run again
[14:45] <Skyler_> they usually fully know that we can't possibly give them patent licenses on these things, especially things like AC3 audio
[14:45] <Skyler_> probably not possible with something as huge as ffmpeg
[14:45] <Compn> contact all authors , draft up a contract
[14:45] <Skyler_> and lgpl is really good enough, I think
[14:46] <Compn> :P
[14:46] Action: Compn trolling much
[14:46] <wm4> <nevcairiel> selling phyiscal media of gpl software is explicitly allowed
[14:46] <wm4> <nevcairiel> as long as its only the cost of the media
[14:46] <wm4> uh what
[14:46] <wm4> that would be new to me
[14:46] <wm4> I think you're confusing this with source distribution
[14:47] <wm4> if you request the source, they're allowed to mail it physically instead of providing a download
[14:47] <burek> considering a lot of people around the world are using ffmpeg (commercially) it might be a good idea to find a way to motivate them to contribute/donate/something to ffmpeg, so that we could rent a programmer to fix some things nobody wants to spend time on
[14:47] <nevcairiel> possibly. 
[14:47] <Compn> anyone else think there is some concerted effort to FUD RMS ? e.g. microsoft trying to kill OSS by FUD opensource ?
[14:47] <Compn> especially its 'leaders' ....
[14:47] <wm4> then you can demand a free - but only what the media/transportation costs
[14:47] <nevcairiel> not that selling open source ever works, considering i can just go and re-ditribute it on the net
[14:47] <wm4> however, you're free to sell GPL software otherwise, and demand as much money as you wish
[14:47] <wm4> you still have to give out the source on demand for free, though
[14:48] <Compn> yeah redhat isnt a successful company at all
[14:48] Action: Compn wonders if nevcairiel is paying attention
[14:48] <nevcairiel> RedHat lives on giving enterprise support for their stuff
[14:48] <nevcairiel> not by selling the stuff itself
[14:48] <Compn> got me there i guess
[14:50] <nevcairiel> on the matter of RMS, personally i think some of the so-called opensource "leaders" like RMS are just fanatics and harm opensource as much as they help it
[14:50] <wm4> yeah, RMS just made open source popular and created one of the most popular open source licenses
[14:50] <wm4> WHAT HAS RMS EVER DONE FOR US?
[14:50] <wm4> now insert a comment about toe jam
[14:51] <wm4> because toe jam is a valid argument
[14:52] <wm4> I guess it's quite normal that the "ideologists" become unpopular as soon as what they fought for becomes commonly acceptable
[14:52] <nevcairiel> i dunno, i think some parts of GPLv3 is whats bad with opensource, and many people agree on that
[14:53] <nevcairiel> note that these parts only moved into v3, not earlier versions
[14:53] <Compn> the v3 stuff you dont agree with is the secret encryption/keys/patent stuff ?
[14:54] Action: Compn forgets what the big deal was , been a while
[14:54] <Compn> not important
[14:54] <Compn> anyone going to help the dxva guy with his patch ? 
[14:55] <Compn> i'd like to see ffmpeg policy change to help new patch authors instead of just telling them to read developer documentation and get it perfected ...
[14:55] <Compn> course there probably arent many windows devs using dxva2
[14:56] <nevcairiel> Personally i think the patch should be declined as a whole because simply wrapping a hwaccel into a decoder seems like the wrong approach, but thats just me
[14:56] <wm4> nevcairiel: btw. what's all that h264 parsing stuff in your directshow wrapper? doesn't libavformat normally take care of this?
[14:56] <nevcairiel> what parsing stuff specifically?
[14:56] <burek> how about creating a book on ffmpeg (for users and for developers) and selling just that book? :)
[14:57] <wm4> nevcairiel: for example in avcodec.cpp (haven't looked too closely at that code, nor do I understand most of it)
[14:59] <nevcairiel> there is two things really happening there, the first is parsing of the SPS to figure out the bitdepth and chroma format and if the stream may contain interlaced frames (because i need to know earlier then avcodec would tell me), and after a seek i manually look for keyframes to avoid garbage frames
[15:00] <wm4> hm, I suppose that has mostly to do with DirectShow requirements not matching what ffmpeg does?
[15:01] <nevcairiel> i cant exactly rely on having a avformat demuxer before my decoder, there could be any other demuxer and just my decoder being used
[15:01] <nevcairiel> so i need to get information wherever i can
[15:02] <wm4> ok, thanks
[15:09] <burek> -probesize         <int>   .D... set probing size
[15:09] <burek> is this in milliseconds, megabytes, kylobytes..?
[15:09] <wm4> bytes
[15:09] <wm4> I guess?
[15:09] <nevcairiel> bytes
[15:10] <burek> ok, thanks
[15:17] <michaelni> nevcairiel, if you are against the patch completely you should reply and explain why its bad (and how the goals of the submitter could otherwise be solved if theres sufficient knowledge and possibility to do that)
[15:20] <cone-835> ffmpeg.git 03Janne Grunau 07master:1f4ea4e068f1: mpegvideo: initialize videodsp with correct pixel depth
[15:20] <cone-835> ffmpeg.git 03Michael Niedermayer 07master:39d178806d91: Merge remote-tracking branch 'qatar/master'
[15:34] <durandal_1707> but there is already similar code in tree
[15:34] <nevcairiel> Two wrongs dont make a right
[15:34] <wm4> what code?
[15:36] <durandal_1707> decoder for hwaccel
[15:37] <durandal_1707> it seems silly that users of lavc would need to write own wrapper for hwaccels
[15:38] <wm4> what decoder is there? I only know of VDA
[15:38] <durandal_1707> and now is dxva want to be same
[15:38] <wm4> and VDA apparently always requires reading the data, and can't draw the image buffer directly on the GPU
[15:39] <wm4> at least that's what a mac user told me
[15:43] <nevcairiel> i wouldn't have accepted the VDA decoder because there already was a HWAccel at the time
[15:43] <wm4> I mean, exposing that as hwaccel isn't useful
[15:44] <wm4> it just requires more useless code on the application side, with no advantages
[15:44] <nevcairiel> i think dxva is the only hwaccel which is somewhat complicated, all others don't require all that much setup from the user
[15:44] <wm4> (if the decoded image really does not reside inside the GPU RAM)
[15:44] <wm4> what others are there? vaapi?
[15:44] <wm4> vdpau is separate
[15:45] <nevcairiel> it uses the same hardware as dxva and other hwaccels, so at one point the image is on a hardware surface, but sure, the API could just copy it back itself
[15:45] <nevcairiel> i cant really say i know or care about macs
[15:45] <nevcairiel> and yeah, vaapi is the only other alternative
[15:54] <iive> nevcairiel: everybody is free to sell any gpl software for any price they want.
[15:54] <nevcairiel> yes, we covered that :P
[15:57] <iive> yeh... quite a lot of backlog...
[16:00] <Compn> wrapping it as a decoder would allow forex mplayer to use it :)
[16:00] <Compn> i think anyways
[16:01] <wm4> for some GPUs it would probably be slower
[16:02] <nevcairiel> only recent intel gpus get any kind of useful speed out of dxva, but funny enough, dxva in ffmpeg is broken on latest intel gpus :P
[16:02] <nevcairiel> i was meaning to send patches for that..
[16:04] <Compn> dxva2 that is
[17:22] <cone-835> ffmpeg.git 03Clément BSsch 07master:915d7487d774: lavfi/idet: remove unecessary poll_frame callback.
[17:22] <cone-835> ffmpeg.git 03Clément BSsch 07master:43cbd4406ea6: lavfi/idet: support named parameters.
[17:22] <cone-835> ffmpeg.git 03Clément BSsch 07master:a7f0af1b9aeb: lavfi/idet: remove unecessary context assignment.
[17:22] <cone-835> ffmpeg.git 03Clément BSsch 07master:d155abd1fcaa: lavfi/idet: remove unused assert include.
[17:31] <cone-835> ffmpeg.git 03Michael Niedermayer 07master:a2349dc3f0a4: vf_idet: fix type of stats
[18:25] <durandal_1707> what should i add to histogram filter?
[18:35] <ubitux> durandal_1707: overall histogram?
[18:36] <ubitux> per component histogram?
[18:36] <ubitux> (like drawing in red the histogram of red, on the right the histogram of green, and again on the right the histogram of blue)
[18:37] <ubitux> another suggestion: make the histogram take eval() for the w/h
[18:37] <durandal_1707> that can be done already by calling it 3 times and using other filters
[18:38] <ubitux> so we can re-use the input width & height
[18:38] <durandal_1707> elaborate
[18:40] <ubitux> ./ffplay -f lavfi -i testsrc -vf "split[x][y]; [x]pad=iw:ih*2[a]; [y]histogram=size=320x240[b]; [a][b]overlay=0:h"
[18:41] <ubitux> instead -> histogram=w=iw:h=ih
[18:42] <Compn> saste / ubitux : is it possible to play two subs at once, one on top , one on bottom with filters yet ?
[18:43] <Compn> diff sub files
[18:43] <ubitux> you can't do positionning
[18:43] <ubitux> but you can play two at once yes
[18:43] <Compn> cant do pos, why nooooo
[18:43] <ubitux> oh well, if the srt or ass has position info it will work :p
[18:43] <Compn> yay
[18:43] <durandal_1707> ubitux: it doesn't make sense to support various size, you use scale for that
[18:43] <ubitux> subtitles=a.srt,subtitles=b.srt
[18:43] <ubitux> :p
[18:44] <Compn> -vf subtitles ? 
[18:44] <Compn> thanks :))))
[18:44] <ubitux> Compn: yes
[18:44] <saste> Compn, you specify the position in the subtitle files
[18:44] <Compn> yeah i understand that
[18:44] <Compn> thats fine
[18:51] <ubitux> saste: ping on lavfi; do you need help?
[18:51] <saste> ubitux, about what?
[18:52] <ubitux> about start_frame/draw_slice/end_frame, about sink buffers
[18:52] <ubitux> it's currently quite messy
[18:52] <saste> ubitux, what's the problem with sink buffers in the first place?
[18:52] <ubitux> and hard to follow
[18:52] <Compn> are we going to be able to use ffplay -vf help to get a list of filters on the command line ? :)
[18:52] <saste> i tried to avoid to read code after the merges, thus i don't get depressed all the time
[18:53] <ubitux> saste: our sink buffer filters (and likely some other filters) are still using cur/out/tmp buf
[18:53] <ubitux> s/tmp/src/ sorry
[18:54] <ubitux> anyway, we need to remove start_frame/draw_slice/end_frame and src/cur/out buf
[18:55] <ubitux> and since "the evil plan" is on its way, it would be wise to do it soon
[18:58] <ubitux> saste: basically the idea is to drop all the ff_*_frame() functions from lavfi/video.[ch]
[18:59] <ubitux> except for ff_inplace_start_frame, the 3 other are a bit harder
[18:59] <ubitux> they need to be merged into ff_filter_frame()
[18:59] <ubitux> same thing for audio
[18:59] <ubitux> this will result in dropping AVFilterLink->{src,cur,out}_buf
[18:59] <ubitux> but to do so we also need to remove the usage from the filters
[19:00] <ubitux> (now that we moved all the filters to ff_filter_frame() it should be easier, but there are still usage of the link->*_buf)
[19:03] <Compn> blargh
[19:03] <Compn> whats up with zeranoe's builds not updating for a month
[19:06] <Compn> No such filter: 'subtitles'
[19:09] <Compn> stupid old builds
[19:10] <ubitux> :)
[20:01] <durandal_1707> michaelni: the fix for duration in wav is just hack, because nothing in format spec dictates that 0xffffffff is invalid chunk size
[20:16] <cone-835> ffmpeg.git 03Paul B Mahol 07master:c46cfedf0927: build: mp filter does not depend on postproc anymore
[20:21] <saste> anyone is going to review my segment patches?
[20:27] <durandal_1707> what they are doing?
[20:37] <ubitux> oh, data uri protocol mmh
[20:37] <ubitux> good idea
[20:39] <nevcairiel> the use of that seems rather limited
[20:40] <nevcairiel> but i guess it can help third party applications with a memory buffer that needs parsing
[20:40] <durandal_1707> wow, what a burst of patches lately
[20:56] <saste> what's data uri good for?
[20:56] <cone-835> ffmpeg.git 03Michael Niedermayer 07master:47e7f57a4b14: mjpegdec: factor handle_rstn() out
[20:56] <cone-835> ffmpeg.git 03Michael Niedermayer 07master:5ff8ca1f04e7: mjpegdec: Handle RSTn in progressive jpegs
[20:56] <cone-835> ffmpeg.git 03Michael Niedermayer 07master:011169cd41ec: mjpegdec: handle the occurance of rstn emulation
[20:58] <ubitux> saste: some http based formats/protocols tend to store binary data like this
[20:58] <ubitux> HDS for instance&
[21:03] <llogan> damn...it's still 45F/8C in my office. shitty old building.
[21:05] <ubitux> sounds like a good temperature to me
[21:16] <durandal_1707> ubitux: you have g+?
[21:19] <ubitux> durandal_1707: i activated it recently for something, why?
[21:19] <ubitux> (i'm not using it at all)
[21:20] <durandal_1707> i added u to my circles
[21:21] <ubitux> i'm more comfortable into squares
[21:33] <cone-835> ffmpeg.git 03Clément BSsch 07master:33e0eb510912: lavfi/video: remove unused ff_inplace_start_frame().
[21:33] <cone-835> ffmpeg.git 03Clément BSsch 07master:5673a0102ae1: lavfi/decimate: remove usage of link->cur_buf.
[21:33] <cone-835> ffmpeg.git 03Clément BSsch 07master:a612e86ea65e: lavfi/deshake: remove usage of link->cur_buf.
[21:33] <cone-835> ffmpeg.git 03Clément BSsch 07master:3b870f973ec1: lavfi/scale: remove usage of link->cur_buf.
[21:33] <cone-835> ffmpeg.git 03Clément BSsch 07master:4cd724daeec3: lavfi/tile: remove usage of link->{cur,out}_buf.
[21:33] <cone-835> ffmpeg.git 03Clément BSsch 07master:ceee4407e3fc: lavfi/tile: small align cosmetics.
[21:35] <durandal_1707> saste: you use type_priority_list array only to get numer of elements in it
[21:36] <beastd> durandal_1707: no, i think it is for selecting preference concerning stream type
[21:37] <durandal_1707> but i see no code that do that
[21:37] <beastd> i think that code is too complicated/large for what it does. it might also contain a bug if my assumptions hold
[21:38] <saste> durandal_1707, oh i'm stupid
[21:38] <durandal_1707> so why 90% of ops here are lurkers and do not review stuff on ml
[21:38] <durandal_1707> michaelni: deop them
[21:38] <ubitux> haha
[21:39] <ubitux> who cares :)
[21:39] <ubitux> is there some review needs where i could help?
[21:39] <beastd> if you are talking about me, i am just at the moment trying to review that code
[21:40] <durandal_1707> review of evertyhing patches, existing code, etc, ...
[21:41] <beastd> saste: are you reworking that patch now?
[21:42] <saste> yes will do in a few minutes
[21:42] <durandal_1707> beastd: don't worry
[21:42] <beastd> I never worry!
[21:42] <beastd> (Now that was a lie.)
[00:00] --- Thu Dec 27 2012