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

[burek]

[00:21] <michaelni> BBB-work, why the CODEC_FLAG_BITEXACT in " vp3: use hpeldsp instead of dsputil for half-pel functions." ?
[00:21] <michaelni> is it intended or typo ?
[00:40] <cone-892> ffmpeg.git 03Stefano Sabatini 07master:8bb5680d9040: cmdutils: improve feedback in case of not found option
[00:40] <cone-892> ffmpeg.git 03Stefano Sabatini 07master:1019cef329b5: ffprobe: support codec options
[00:40] <cone-892> ffmpeg.git 03Stefano Sabatini 07master:92ca292766b2: lavc: extend documentation for skip_idct, skip_loop_filter, skip_frame options
[00:40] <cone-892> ffmpeg.git 03Stefano Sabatini 07master:a3233e9d7ab4: lavfi/fieldorder: remove unused headers and commented define
[00:40] <cone-892> ffmpeg.git 03Stefano Sabatini 07master:aeac1dae29d5: lavfi/fieldorder: add support to named options
[00:45] <BBB-work> michaelni, intended - see my reply
[00:45] <BBB-work> michaelni, but it's a good question and I'm not sure this is the cleanest way to do it
[00:56] <cone-892> ffmpeg.git 03Anton Khirnov 07master:bdd1567c355a: lavc: remove disabled FF_API_CODEC_ID cruft
[00:56] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:e664f48b97f2: Merge commit 'bdd1567c355a8092e7746ef99e831d579e34fa6a'
[00:56] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:cfc1efc77c7a: avcodec: assert that old codec ids match new
[01:05] <michaelni> BBB-work, its ok then, its actually quite clean for what its intended to achive
[01:18] <ubitux> saste: as you know i'm not a native speaker but in "support to named options", shouldn't the "to" be a "for" or something?
[01:18] <ubitux> (or nothing)
[01:19] <saste> ubitux, i believe "support for named options" is more correct indeed
[01:21] <cone-892> ffmpeg.git 03Anton Khirnov 07master:adfa53d67c7a: lavc: remove disabled FF_API_VDA_ASYNC cruft
[01:21] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:d469fa192395: Merge commit 'adfa53d67c7a3318157ea9d95e8bdcfb77139452'
[01:22] <wm4> is all of TEP merged now?
[01:32] <bcoudurier> TEP ?
[01:32] <wm4> the evil plan
[01:32] <wm4> aka referenced counted AVFrame
[01:33] <ubitux> wm4: it should mostly done, michael is still keeping up with the merge delay right now, but most of it is in afaik
[01:33] <ubitux> it's still a bit chaotic :P
[01:34] Action: saste wonders what is the codename for 1.2
[01:35] <ubitux> "before the storms begins"
[01:38] <michaelni> saste, btw one of the doc/examples doesnt work anymore
[01:38] <saste> ubitux, i thought something similar, "quiet" before the "tempest"
[01:38] <saste> assuming that the next libav release will contain the word "evil" we should opt for "good" instead
[01:39] <saste> michaelni, which one?
[01:39] <cone-892> ffmpeg.git 03Vittorio Giovara 07master:2eaa3663fda7: avplay: enable only when SDL 1.2 is found
[01:39] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:b94df21a5164: Merge commit '2eaa3663fda750dac66d41fe8541a8744d5563a4'
[01:40] <wm4> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/avfiltergraph.h;h=3965412803740083e89060cccacbf88881d9fda4;hb=HEAD#l167
[01:40] <wm4> http://git.libav.org/?p=libav.git;a=blob;f=libavfilter/avfiltergraph.h;h=62308982d05a18751a11971dacc7ef132f27cc2f;hb=HEAD#l135
[01:40] <wm4> nice.
[01:40] <wm4> so I guess you're supposed to use avfilter_graph_parse2
[01:41] <llogan> why was it called, "the evil plan"?
[01:41] <wm4> llogan: maybe because it throws everything into chaos and confusion
[01:43] <saste> michaelni, will fix it tomorrow
[01:44] <cone-892> ffmpeg.git 03Clément BSsch 07master:02a6b06d9ea0: avpacket: do not copy data when buf ref is available.
[01:44] <michaelni> saste, ok thx
[01:44] <wm4> the thing above is particularly funny because both ffplay.c and avplay.c use the "incompatible" function, avfilter_graph_parse... or did I overlook something?
[01:45] <bcoudurier> michaelni, was your frame threaded encoding patch standalone ?
[01:46] <bcoudurier> best feature that happened since frame threaded decoding !
[01:46] <saste> bcoudurier, wanna to mentor a gsoc task?
[01:46] <bcoudurier> saste, sure
[01:46] <llogan> saste: "by" in "divisible by" seems odd, but now i read it too many times... english is hard; let's go shopping.
[01:46] <michaelni> hmm i dont remember what it depended on or what not
[01:46] <highgod> Hi,I want to ask a question,Can codec get the filter names when run ffmpeg.exe?And can filter get codec names when run ffmpeg.exe?Because I want make a pipeline that all the datas stay in GPU when run dxva2 and OpenCL filter,Thanks
[01:47] <saste> bcoudurier, anything related to ffserver would be very appreciated
[01:47] <ubitux> wm4: yes this was changed last year
[01:47] <bcoudurier> wow, I just sent my first email in ffmpeg-devel since a year
[01:47] <ubitux> wm4: in 6119b23a3662d1e106cdf69ef3171b2e7e1d495c
[01:47] <saste> llogan, "divisible by", where are you reading from?
[01:47] <bcoudurier> saste, oh my I don't think I'm able to :/
[01:48] <wm4> ubitux: maybe you and l. should update the *play API usage, because it's the only thing anyone could possible learn how lavfi is to be used
[01:48] <llogan> bcoudurier: welcome back
[01:48] <wm4> ubitux: and the way it is now is actively misleading, and the old functions should be removed
[01:48] <llogan> saste: cropdetect "Set the value which the width/height should be divisible by."
[01:49] <ubitux> wm4: iirc, despite the name, avfilter_graph_parse2() is not supposed to deprecated avfilter_graph_parse()
[01:49] <ubitux> i remember telling anton about this (saying the 2 was supposing a new version)
[01:49] <ubitux> of course i got ignored as usual
[01:49] <saste> llogan, are you a native English speaker?
[01:50] <llogan> yes, in theory.
[01:50] <wm4> ubitux: uh so what am I supposed to use
[01:50] <ubitux> wm4: please raise your concern on ffmpeg-devel (or open a ticket), seems saste is a bit busy
[01:50] <ubitux> wm4: and mention 6119b23a3662d1e106cdf69ef3171b2e7e1d495c
[01:50] <saste> i just added a verb in the sentence, suggest what should read  better
[01:51] <wm4> ah I see now that the functions are quite different
[01:52] <wm4> I guess I have two choices: add a ifdef, or add more obscure API usage
[01:52] <michaelni> btw, anyone knows if ffplay works with SDL 1.3 ?
[01:52] <saste> highgod: "Can codec get the filter names when run ffmpeg.exe?" what do you exactly mean?
[01:52] <saste> what do you mean by "filter names"?
[01:53] <saste> the name of the internal (libavfilter) filters?
[01:53] Action: ubitux hasn't sdl 1.3 here
[01:53] <michaelni> iam asking because the check in configure checks for <1.3 
[01:54] <ubitux> does 1.3 exists?
[01:54] <michaelni> i dont know
[01:54] <llogan> saste: eh, it's fine... sorry for the noise.
[01:54] <michaelni> but if not then the check is even more wrong
[01:54] <highgod> @saste:for example I use the command "ffmpeg -vcodec h264 -i input -vf deshake output",can h264 know the filter name and filter can know the codec name?
[01:54] <wm4> SDL 1.3 identifies as 2.0, btw.
[01:55] <cone-892> ffmpeg.git 03Xi Wang 07master:5d639b2b4a6d: vf_pad: fix a & instead of && typo
[01:55] <cone-892> ffmpeg.git 03Anton Khirnov 07master:e2c297412066: vorbisdec: do not leak the first frame.
[01:55] <cone-892> ffmpeg.git 03Anton Khirnov 07master:98cec5c84fef: ratecontrol: remove an unused variable
[01:55] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:047c5e177ae0: Merge commit '98cec5c84feff34e04428de4a86836a83657ae5e'
[01:55] <saste> highgod, that is the name of the filter used in the commandline?
[01:55] <saste> highgod, no, because decoding and filtering levels are supposed to be completely decoupled
[01:56] <ubitux> michaelni: just as wm4 says; http://www.libsdl.org/hg.php
[01:56] <ubitux> 1.2 and 2.0
[01:56] <saste> you may find some hacks involving metadata, but the next question is why do you need that for?
[01:57] <llogan> bcoudurier: feel free to add anything you'd like to mentor to http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013
[01:58] <wm4> ubitux: I don't really understand why 6119b23a3662d1e106cdf69ef3171b2e7e1d495c is needed, and l. does just fine without it
[01:58] <highgod> @scaste:I add a dxva2 patch for decode and OpenCL filter,I want that if use the dxva2 decoder and OpenCL filter,The data can stay in GPU without copy to CPU.
[01:58] <ubitux> wm4: the v2 wasn't available at that time
[01:58] <saste> llogan, please suggest better wording on ML, going to sleep in a few minutes
[01:58] <ubitux> wm4: and the api most likely considered unstable when done
[01:59] <wm4> "when done"? what?
[01:59] <saste> highgod, in theory we support direct rendering, so that no memcpy should be required (in case no conversions are done)
[02:01] <llogan> saste: it's now fine with me as is after re-reading again.
[02:02] <cone-892> ffmpeg.git 03Anton Khirnov 07master:669cc0f364d6: lavc: fix get_buffer() compatibility layer for audio.
[02:02] <cone-892> ffmpeg.git 03Janne Grunau 07master:e3232f34312f: svq1: use av_frame_free to free refcounted frame
[02:02] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:ff3e8564c440: Merge commit 'e3232f34312f8187094c875445683277ed0c209d'
[02:03] <highgod> @saste:I mean that the when use dxva2 decoder and OpenCL filter, I will copy the data from GPU to CPU after decode and pass it to OpenCL filter and then copy the data to GPU to use the OpenCL filter. If I know the fiter is OpenCL filter, then I can avoid the copy operation,hehe
[02:03] <wm4> somehow I think all this stuff doesn't belong into libavfilter and so on
[02:04] <wm4> you'Re committing horrible sins because of you constrained view of libav* as helpers for the ffmpeg command line tool
[02:05] <ubitux> wm4: what do you propose?
[02:05] <wm4> put it somewhere else
[02:05] <ubitux> the avfilter_graph_parse?
[02:06] <ubitux> sounds pretty appropriate to belong into lavfi to me
[02:06] <wm4> no, I mean the OpenCL thing
[02:06] <saste> highgod: "I will copy the data from GPU to CPU" -> why this?
[02:06] <wm4> but, uh, if you want to see how tom separate filter description language and filters, take a look at vapoursynth
[02:06] <saste> a decoder request a buffer, fills it and then it pass around to the next layer
[02:06] <ubitux> wm4: ah, sorry.
[02:07] <saste> you're not supposed to do any memcpy, as is the framework which deals with that
[02:07] <cone-892> ffmpeg.git 03Janne Grunau 07master:08149b2b3908: wmapro: unref skipped frames
[02:07] <cone-892> ffmpeg.git 03Janne Grunau 07master:684e3d2e1ce9: ra144: check buffer size before requesting a buffer
[02:07] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:e5949cc12a7a: Merge commit '684e3d2e1ce96625eeef63f2564aab66f6715d05'
[02:07] <wm4> saste: isn't he talking about special GPU API surfaces vs. normal pixel data?
[02:08] <saste> basically if the dxva2 decoder returns a decoded buffer from the GPU, the same buffer will be passed to the filtering layer (unless some conversion is done)
[02:08] <saste> but i'm not familiar with such architecture, so i'm possibly misunderstanding your question
[02:09] <highgod> @saste:oh yes,but the next filter maybe CPU filter,in this case, the data should be copied to CPU,so the decoder don't know whether to copy the data.
[02:09] <wm4> you could add dxva support to libswscale
[02:10] <saste> is the CPU supposed to work on GPU data?
[02:10] <saste> or do you need a special API for that?
[02:10] <llogan> michaelni: "As qualification you have to do some work that demonstrates your understanding of MVC and that is a subpart of the whole MVC implementation."
[02:11] <llogan> i don't understand the "and that is a subpart of the whole MVC implementation" phrase
[02:11] <llogan> what is "that"?
[02:11] <highgod> wm4:I add the dxva support in codec to decode h264,vc1,wmv3,mpeg2,hehe.
[02:12] <cone-892> ffmpeg.git 03Janne Grunau 07master:fc8406d01ed5: avframe: copy reordered_opaque in copy_props
[02:12] <cone-892> ffmpeg.git 03Hendrik Leppkes 07master:d6d369bf1370: atomic: prefer gcc builtins over win32 atomics, if available.
[02:12] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:150de78d7c9c: Merge commit 'd6d369bf1370999896500ae7eb5b9447ab635a3d'
[02:13] <highgod> @saste:Yes,maybe,If dxva2 decoder can know the filter type, it can save copy operation time
[02:13] <wm4> in theory, you'd want to pass GPU surface handles as AVFrame, right?
[02:14] <michaelni> llogan, the student should do a part of the work he would have to do in summer to show that he is capable of doing the work
[02:14] <Daemon404> hey ubitux 
[02:14] <saste> highgod, again, i don't think the decoder *is supposed to know* which filters will be used next
[02:14] <saste> but see reply from wm4
[02:14] <Daemon404> is there a way to force ffprobe to output info for undecoable frames with -show_frames or -show_packets
[02:14] <Daemon404> i.e. leading b frames in the 1st gop
[02:14] <wm4> so you need to extend the libavfilter pixel format negotiation to the decoder
[02:15] <wm4> basically, answering the question "what format should the decoder pass to the filter chain"
[02:15] <saste> Daemon404, maybe play with the codec options
[02:15] <saste> i just added support to them
[02:16] <saste> not sure it's possible though
[02:16] <wm4> but from what I've heard even libavfilter hackers don't seem to understand entirely how this filter negotiation works
[02:16] <wm4> s/filter/format
[02:16] <Daemon404> saste, how recent?
[02:16] <saste> Daemon404, 1 hour ago
[02:16] <Daemon404> lawl
[02:16] <Daemon404> is it in master?
[02:16] <saste> sure
[02:16] <Daemon404> ok
[02:17] Action: saste go to bed
[02:18] <llogan> michaelni: yes, i understood that.
[02:19] <highgod> can I use a frame data,for example frame->data[5] to save the surface?but if the decoder don't know the filter type, it will not know whether to do the copy data.
[02:22] <Daemon404> wow ffmpeg build has a shitload of warnigns now
[02:24] <BBB> Daemon404: op_pixels_func int -> ptrdiff_t mismatches afaics
[02:25] <Daemon404> lots of pthreads too
[02:25] <Daemon404> huh
[02:25] <Daemon404> saste forgot how to tell me how to actually USE codec options...
[02:26] <Daemon404> (in ffpobe)
[02:26] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1019cef329b508f0a9033b355cc18bf8026caf31 <-- how very useful
[02:26] <Daemon404> no hint how ot set them at all
[02:26] <Daemon404> if even possible
[02:27] <BBB> you mean pthread.c the frame threading wrapper?
[02:27] <Daemon404> yea
[02:27] <BBB> well that's not a surprise ffmpeg's deviated quite a lot from libav's and (sorry guys) most of these changes aren't very bright
[02:28] <BBB> e.g. h264-specific code in pthread.c
[02:28] <ubitux> Daemon404: just like other tools? with -c/-codec?
[02:29] <Daemon404> nope
[02:29] <Daemon404> it's -skip_frame
[02:29] <Daemon404> which is listed NOWHERE
[02:29] <Daemon404> relatign to ffprobe
[02:29] <Daemon404> whatsoever
[02:29] <Daemon404> (certanly not in -h)
[02:29] <ubitux> doc/ffmpeg-codecs.texi:@item skip_frame @var{integer} (@emph{decoding,video})
[02:29] <ubitux> ?
[02:30] <ubitux> if it's a codec option, then just as an input option?
[02:30] <Daemon404> there is nothing to indicate ffprobe can take tehse options
[02:30] <Daemon404> anywhere.
[02:30] <ubitux> right, just like the other tools
[02:30] <Daemon404> -_-
[02:31] <Daemon404> that makes it OK?
[02:31] <michaelni> BBB, if you have ideas (or better patches) how to improve the code, pthreads or other, they are surely welcome
[02:31] <Daemon404> ubitux, -skip_frame none sitll doesnt output leading bframes
[02:31] <Daemon404> (for first gop)
[02:31] <michaelni> but most of the ugly code probably is needed for some bugfix or feature
[02:31] <BBB> michaelni: maybe in Q2-Q3... right now I have other things to finish unfortunately
[02:32] <michaelni> ok
[02:32] <BBB> there was a case of incomplete nal parsing in the h264 decoder, causing it to call finish_setup too early
[02:32] <BBB> that caused a crash
[02:32] <BBB> your pthread.c check for h264 worked around that
[02:33] <Daemon404> michaelni, do you perhaps know the codec optio to force mpegvideo to output leading (undecodable) bframes?
[02:36] <Daemon404> ot at least a way to figure out how many were dropped...
[02:36] <ubitux> Daemon404: indeed -skip_frames doesn't appear in ffprobe -help full
[02:36] <ubitux> while it does in ffmpeg -help full
[02:36] <Daemon404> hmm
[02:36] <michaelni> Daemon404, the decoder should if it can decode them return them 
[02:37] <michaelni> iam not sure theres a flag to force this if the cant be correctly decoded
[02:37] <Daemon404> i just want to find out how any exist really
[02:37] <michaelni> the frame reordering of mpeg1/2/4 is quiet simple
[02:37] <Daemon404> i know
[02:38] <michaelni> it should be easy to figure out from what goes inm what comes out and the timestamps or so
[02:38] <michaelni> or AVFrame.*opaque or something else
[02:38] <Daemon404> timestamps are not preserved afaik
[02:38] <Daemon404> dts matches display order instead of codec order
[02:38] <Daemon404> which is kind of fucked up
[02:39] <Daemon404> it leads me to believe were making teh dts up
[02:39] <Daemon404> out of nowhere
[02:39] <Daemon404> before it hits ffprobe's output
[02:40] <Daemon404> in fact
[02:40] <Daemon404> pts == dts all the time
[02:40] <Daemon404> according to ffprobe
[02:40] <Daemon404> regardless of reordering
[02:41] <llogan> ubitux: i meant this channel...
[02:41] <Daemon404> which makes absolutely no sense
[02:41] <ubitux> llogan: http://wiki.multimedia.cx/index.php?title=Special:Upload here you go too.
[02:43] <llogan> thanks
[02:47] <cone-892> ffmpeg.git 03Anton Khirnov 07master:0517c9e09809: lavc: remove disabled FF_API_AVCODEC_RESAMPLE cruft
[02:47] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:d3edc65dd1e5: Merge commit '0517c9e098092709397cc522c59fa63c83cc81be'
[02:58] <highgod> Hi,How to speed up / slow down a video using ffmpeg?
[02:59] <ubitux> setpts filter
[02:59] Action: ubitux would like to have some formats-level filters
[03:00] <Daemon404> ah crap
[03:00] <Daemon404> hmm...
[03:00] Action: Daemon404 ponders to self
[03:04] <cone-892> ffmpeg.git 03Anton Khirnov 07master:de27d2b92fa9: lavc: remove disabled FF_API_LIBMPEG2 cruft
[03:04] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:1f27053b91e4: Merge commit 'de27d2b92fa97deb2856d18e9f5f19586ce45a0f'
[03:05] <highgod> @ubitux:thanks
[03:09] <ubitux> can anyone fix the ff* tools names in the trac?
[03:09] <ubitux> the components have caps in them
[03:09] <ubitux> "FFplay" "FFprobe" etc
[03:10] <ubitux> to avoid various confusions i think it would be wise to remove them
[03:16] <ubitux> highgod: feel free to upvote https://ffmpeg.org/trac/ffmpeg/ticket/2350
[03:17] <highgod> @ubitux:Ok,thanks
[03:20] <Daemon404> wm4, your lavfi commit message is lovely.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:9628e5a4acb0: hpeldsp: add half-pel functions (currently copies of dsputil).
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:d1293512cfd5: vp3: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:704c9874a385: vp56: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:4b642ab19b5a: indeo3: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:af1e3dfb9eaf: bink: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:04a75bb74f5d: interplayvideo: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:cc5d17e02640: mimic: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:46523897774c: svq1: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:4ba5dbc0e4dc: mpegvideo: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:05dd583426db: svq3: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:771ba8f206e2: snow: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:b42d594c85d4: svq1enc: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:e0a8f315911c: mjpeg: use hpeldsp instead of dsputil for half-pel functions.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:3ced55d51c2e: Move x86 half-pel assembly from dsputil to hpeldsp.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:89f16ded9b74: Move ppc half-pel assembly from dsputil to hpeldsp.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:de99545f4641: Move arm half-pel assembly from dsputil to hpeldsp.
[04:18] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:e9e608ad5804: Move bfin half-pel assembly from dsputil to hpeldsp.
[04:19] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:a0565a2b656f: Move sh4 half-pel assembly from dsputil to hpeldsp.
[04:19] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:6802c701063e: Move sparc/vis half-pel assembly from dsputil to hpeldsp.
[04:19] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:94b77678dcdf: Move alpha half-pel assembly from dsputil to hpeldsp.
[04:19] <cone-892> ffmpeg.git 03Ronald S. Bultje 07master:f536df99feb7: dsputil: remove hpel functions (moved to hpeldsp).
[04:19] <cone-892> ffmpeg.git 03Michael Niedermayer 07master:12fe78a77bf5: vp56: remove unused variable
[04:48] <BBB> yay
[05:09] <ubitux> shit, i just wrote something useful
[05:10] <Daemon404> i hate it when that happens
[05:11] <ubitux> it actually scares me a lot
[05:12] <ubitux> i'm always afraid someone is doing the exact same thing at the same time
[05:24] <ubitux> shit, it even works
[06:58] <ubitux> -nostats is broken
[06:59] <ubitux> didn't stefano changed something about that recently?
[06:59] <ubitux> seems it was only the doc
[07:13] <ubitux> mmh maybe that's just the recently added 8bb5680
[07:13] <ubitux> might just be a print issue
[07:31] <cone-434> ffmpeg.git 03Clément BSsch 07master:19c41c6d8ef6: opt: re-enable memleak fix for duplicated options.
[07:52] <ubitux> bcoudurier: btw, when moving to the new fate machine, maybe you should consider upgrading fate; it seems to be used as a spurious argument by some ppl from the fork
[08:03] <ubitux> wm4: want to make a contest of the one with the most warnings?
[08:03] <wm4> why does anton want to break api all the time
[08:03] <wm4> what the fuck is up with useless changes like renaming everything anyway?
[08:04] <wm4> this just causes work and stress for everyone
[08:04] <wm4> seriously, fuck
[08:05] <wm4> like the CodecID->AVCodecID change, or the impending PIX_FMT change (which is half-way done, the most terrible kind of done)
[08:06] <av500> If you don't go forward, you go backwards
[08:06] <nevcairiel> a library like this should namespace all its symbols, it makes perfect sense to ensure that this is the case
[08:06] <ubitux> wm4: you're not going to win the warnings contest if you complain here
[08:06] <nevcairiel> and tbh, migrating is trivial
[08:07] <wm4> nevcairiel: as long as you don't have anyone who wants to use your software with old ffmpeg/libav releases
[08:08] <nevcairiel> there is plenty old versions with both symbols
[08:08] <nevcairiel> its not like you need a recent git head to use the AV prefixed variants
[08:08] <nevcairiel> and honestly, i would say screw them, if they want to update one part of the software but not the other, they are just asking for issues
[08:09] <wm4> that is true
[08:09] <wm4> but if you have only a handful of users, you're careful about pissing them off
[08:10] <ubitux> libav has less users than they seem to think
[08:10] <nevcairiel> its still silly to expect a recent version of your software to work with an ancient libav/ffmpeg
[08:10] <ubitux> since no one seems to be reporting issues at them about things they break
[08:11] <ubitux> ("no is using the feature we broke a while ago, let's drop it!" happens often)
[08:11] <av500> just stop pulling from libav
[08:11] <av500> solved :)
[08:11] <ubitux> no one*
[08:11] <wm4> is "ancient" just a release before the current release? because I'm getting lots of these issues with l. 8.x vs. 9.x
[08:11] <nevcairiel> well all of the debian and buntu world uses libav, dont they
[08:11] <ubitux> av500: that would make them too happy
[08:11] <av500> so you are pulling out of spite :)
[08:11] <wm4> official debian uses libav, but debian has a popular repo (dmo) which actually uses ffmpeg
[08:12] <ubitux> nevcairiel: that's true for "stable" versions, i was mostly refering to power users using git/recent versions
[08:13] <ubitux> is the v9 even packaged?
[08:13] <ubitux> or they're still in 0.8?
[08:14] <wm4> most distros cause you pain due to 2 things: 1. they insist on dynamic linking (forcing every package to use the same libav* versions), and 2. they provide old versions of libav* because newer ones typically break lots of programs due to API-changes
[08:16] <ubitux> nevcairiel: recently, they were saying "feature XXX is broken since one year and no one noticed", which means it was likely broken after 0.8 got released, so actually no one noticed because no one is using libav git
[08:16] <ubitux> the only libav users are debian/buntu lambda users, and gstreamer victims
[08:16] <wm4> "gstreamer victims" lol
[08:17] <wm4> why do gstreamer folks insist on libav anyway?
[08:17] <wm4> maybe being compatible to two versions is too much work? (I could understand that)
[08:17] <ubitux> they just got brainwashed by various proselytism most likely
[08:17] <nevcairiel> i recently tried to build my app against libav for giggles, i was amazed how much many differences there are these days that made it not work
[08:18] <nevcairiel> s/much//
[10:49] <cone-434> ffmpeg.git 03Philip Langdale 07master:21dc9b194f68: CrystalHD: Port to ref-counted frame API.
[11:06] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:bbaa4432e2bf: vc1dec: remove unused variables
[11:06] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:a8c077732598: Revert "Merge commit '0517c9e098092709397cc522c59fa63c83cc81be'" bring the old audio resampling API back
[11:07] <nevcairiel> sometimes forcing change is the only way to bring change
[11:10] <michaelni> nevcairiel, true, but always breaking/droping API is quite annoying. 
[11:10] <michaelni> for user apps that is
[11:11] <nevcairiel> but what will motivate them to update to new APIs? in the end, you sit on layers of old API and your workload increases because some user apps are lazy bums :)
[11:12] <michaelni> i suspect in this case its not much work to maintain
[11:13] <michaelni> but yes you have a point
[11:13] <durandal_1707> ubitux: does internal get_buffer already provide some logging?
[11:14] <nevcairiel> the question is if its obvious enough that its deprecated and soon to be removed, maybe they just dont notice this?
[11:15] <durandal_1707> but that code is extremly slow and bunch of other stuff
[11:30] <wm4> if ffmpeg cared about its (API) users, they'd just emulate deprecated API (separate enough so it's no maintainance burden)
[11:31] <wm4> if the old API is stable and the new API is also stable, you'd never have to touch the code again, in theory
[11:32] <nevcairiel> emulation is sometimes rather problematic if the semantic changes a lot
[11:35] <cone-434> ffmpeg.git 03Anton Khirnov 07master:fcb07e8b332b: lavc: remove disabled FF_API_MMI cruft
[11:35] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:5753e3490696: Merge commit 'fcb07e8b332bbd6f9558bff98ff5102c5f2d8252'
[11:36] <wm4> it's probably not always feasible, but often enough it appears deprecated things are removed as soon as possible, even though removing them wasn't really necessary (of course I might be wrong, uninformed, or short-sighted, and maybe a bit mean to demand to maintain these old things forever, but still)
[11:37] <durandal_1707> when lavfi device will be ported to refcounted frames?
[11:37] <nevcairiel> saste posted a patch on the ML
[11:38] <durandal_1707> wm4: if something get removed too soon, anyone can complain here and it will be eventually reverted
[11:39] <durandal_1707> what about those pkt->destruct deprecations warning messages?
[11:40] <durandal_1707> does new frames in libavfilter still have qp table?
[11:52] <cone-434> ffmpeg.git 03Paul B Mahol 07master:b3b46cd74e9f: bktr: add missing #include for av_gettime()
[12:01] <cone-434> ffmpeg.git 03Anton Khirnov 07master:3bcdf8dcb989: lavc: remove disabled FF_API_SNOW cruft
[12:01] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:feccf2f6b747: Merge commit '3bcdf8dcb9891ffe49b6398d0e2c02f1712d8f00'
[12:01] <durandal_1707> nobody cares for h264 valgrind warnings?
[12:03] <nevcairiel> that depends, are those memleaks or unintialized reads?
[12:03] <nevcairiel> (and are they new?)
[12:03] <durandal_1707> michaelni: are you sure that is right thing to do with avcodec.h?
[12:04] <durandal_1707> any video codecs qtrle is now broken
[12:04] <durandal_1707> *above qtrle
[12:05] <durandal_1707> not counting that it was not compatible long ago when libav removed codec id and ffmpeg still keep it
[12:05] <nevcairiel> there was an ABI bump
[12:05] <durandal_1707> major?
[12:05] <nevcairiel> yes
[12:05] <durandal_1707> when?
[12:05] <nevcairiel> yesterday or so?
[12:06] <durandal_1707> i want to remove some codec too
[12:06] <nevcairiel> maybe two days ago
[12:06] <nevcairiel> ABI is still considered unstable i guess
[12:06] <nevcairiel> major is 55 now, so any ABI breaking changes, do them now =P
[12:07] <michaelni> "i want to remove some codec too" <-- we should try to stay as much API/ABI compatible with libav as possible so as not to make life for use apps any harder than needed
[12:07] <michaelni> also we should try to stay compatible with previous ffmpeg as much as possible for the same reason
[12:08] <nevcairiel> the bump requires people to recompile anyway, so ABI does not need to stay compatible to old ffmpeg at least
[12:09] <nevcairiel> as long as API is compatible thats easy enogugh to do
[12:10] <cone-434> ffmpeg.git 03Anton Khirnov 07master:d6ed604cf4ca: lavc: remove disabled FF_API_IDCT cruft
[12:10] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:b13cd2d86763: Merge commit 'd6ed604cf4ca86ed345125b26eb5bdeea6d6bf68'
[12:10] <michaelni> nevcairiel, true
[12:18] <cone-434> ffmpeg.git 03Anton Khirnov 07master:0a7c4daf469d: lavf: remove disabled FF_API_CLOSE_INPUT_FILE cruft
[12:18] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:ed80427e0ef5: Merge commit '0a7c4daf469d4ac447fb822fe78337f62f4c04e6'
[12:20] <cone-434> ffmpeg.git 03Paul B Mahol 07master:ac45921a6b9d: lavc: remove disabled 8SVX_RAW cruft
[12:21] <durandal_1707> nevcairiel: new, fate was not that much yellow before
[12:21] <durandal_1707> i hope i fixed most of red part
[12:22] <nevcairiel> some red on ppc seems trivial to fix
[12:22] <nevcairiel> but  have no ppc
[12:22] <nevcairiel> but i have no ppc*
[12:23] <nevcairiel> hm but its so damn trivial i might send a patch anyway
[12:28] <cone-434> ffmpeg.git 03Anton Khirnov 07master:c7e044c61bb0: lavf: remove disabled FF_API_APPLEHTTP_PROTO cruft
[12:28] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:1c60956c8037: Merge commit 'c7e044c61bb08b3a6e1e8063e8f4449c88b01201'
[12:34] <cone-434> ffmpeg.git 03Anton Khirnov 07master:435c2a31ad5e: lavf: remove disabled FF_API_READ_PACKET cruft
[12:34] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:256e1f7bdfb0: Merge commit '435c2a31ad5eead20eda1152097f60c3bfa22847'
[12:41] <cone-434> ffmpeg.git 03Anton Khirnov 07master:32e5194969e0: lavf: remove disabled FF_API_INTERLEAVE_PACKET cruft
[12:41] <cone-434> ffmpeg.git 03Anton Khirnov 07master:7b486ab13bfc: lavf: remove disabled FF_API_AV_GETTIME cruft
[12:41] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:06a83505992d: Merge commit '7b486ab13bfcfa88a7cd92586de50e49966ec292'
[12:45] <durandal_1707> hmm why is gif failing on openbsd?
[12:46] <durandal_1707> looks only for 4.* gcc
[12:48] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:acbd14bc7e24: avformat: postpone API removials where the functions are trivial wrapers
[12:56] <cone-434> ffmpeg.git 03Anton Khirnov 07master:85a5bc054c12: lavf: remove disabled FF_API_R_FRAME_RATE cruft
[12:56] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:b2e0c9dd34f5: Merge commit '85a5bc054c1290699ccbf5799ba6c4e2fbcc3530'
[13:03] <cone-434> ffmpeg.git 03Anton Khirnov 07master:19cac8e30141: mpegvideo: remove useless references to h264 and svq3
[13:03] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:f45fdb123f39: Merge commit '19cac8e301419dcde31526d15196a952ddf2c4c7'
[13:12] <cone-434> ffmpeg.git 03Anton Khirnov 07master:ee8704916de7: mpegvideo: reindent
[13:12] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:df4517106a3c: Merge commit 'ee8704916de79158da8a48a9ea5be819e83d23ba'
[13:17] <cone-434> ffmpeg.git 03Carl Eugen Hoyos 07master:f1b716c79b95: avframe: Copy buffer type in copy_props.
[13:17] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:72ad824a8623: Merge remote-tracking branch 'cehoyos/master'
[13:22] <cone-434> ffmpeg.git 03Anton Khirnov 07master:07054015cfe7: mpegvideo: remove FMT_H264
[13:23] <cone-434> ffmpeg.git 03Anton Khirnov 07master:f08fefc4d099: h264: remove a useless svq3 condition
[13:23] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:6c3e4e391dc8: Merge commit 'f08fefc4d099f2a1f2e3a6db3d340537e601f762'
[13:33] <cone-434> ffmpeg.git 03Anton Khirnov 07master:c2597c5a0a08: h264_refs: cosmetics, reformat
[13:33] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:87d263a122f6: Merge commit 'c2597c5a0a08526493abb9bc9544b61a290fe20f'
[13:39] <cone-434> ffmpeg.git 03Anton Khirnov 07master:887d31d45591: vf_gradfun: fix uninitialized variable use
[13:39] <cone-434> ffmpeg.git 03Anton Khirnov 07master:d0a863ac891e: vf_hqdn3d: fix uninitialized variable use
[13:39] <cone-434> ffmpeg.git 03Anton Khirnov 07master:555000c7d5c1: h264: check that DPB is allocated before accessing it in flush_dpb()
[13:39] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:8bcebf9e4a48: Merge commit '555000c7d5c1e13043a948ebc48d2939b0ba6536'
[13:44] <cone-434> ffmpeg.git 03Anton Khirnov 07master:fce68c935548: pthread: unref the decoded but not returned frames on close.
[13:44] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:8ded1718bdf5: Merge commit 'fce68c93554803801c32c1b20509bfa8d496b02a'
[13:52] <cone-434> ffmpeg.git 03Janne Grunau 07master:a2816230c5c0: avframe: call release_buffer only if it is set
[13:52] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:bb3823d45710: Merge commit 'a2816230c5c0a8fc72bc0163b7d21a96b194d87a'
[13:58] <cone-434> ffmpeg.git 03Luca Barbato 07master:202c2acc40a6: vda: remove async decoder leftovers
[13:58] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:a62fced39482: Merge commit '202c2acc40a6de8758b44ab3f5c85ab250079734'
[14:07] <cone-434> ffmpeg.git 03Diego Biurrun 07master:8f10f1a6dc0d: anm: Get rid of some very silly goto statements
[14:07] <cone-434> ffmpeg.git 03Diego Biurrun 07master:a4472ac01e86: Add informative messages to av_log_ask_for_sample calls lacking them
[14:07] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:849f015406e7: Merge commit 'a4472ac01e86f9fae5adb9034f2777b86a9c5480'
[14:41] <cone-434> ffmpeg.git 03Luca Barbato 07master:a8b6015823e6: dsputil: convert remaining functions to use ptrdiff_t strides
[14:41] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:db4e4f766c07: Merge commit 'a8b6015823e628047a45916404c00044c5e80415'
[14:41] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:019b378d90e0: vc1: fix int/ptrdiff_t mismatches
[14:46] <cone-434> ffmpeg.git 03Luca Barbato 07master:37cb3b180a1d: matroskadec: request a read buffer for the wav header
[14:46] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:11d62fc9bea7: Merge commit '37cb3b180a1dc3d6f123f68e0806585ebc2578b6'
[14:54] <michaelni> hmm, cone doesnt seem to like | in the commit message?
[14:54] <michaelni> remote:     (commit.author, commit.logmsg) = metainfo.split("|")
[14:54] <michaelni> remote: ValueError: too many values to unpack
[15:12] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:7ff3bfd584a7: exr: silence warning "libavcodec/exr.c:351:9: warning: variable ret set but not used"
[15:12] <cone-434> ffmpeg.git 03Michael Niedermayer 07master:c3bb2f729633: dsputil_mmx: remove unused variables
[16:07] <cone-434> ffmpeg.git 03Hendrik Leppkes 07master:9ae6ba288368: dsputil: remove deprecated dsp_mask usage
[16:07] <cone-434> ffmpeg.git 03Hendrik Leppkes 07master:2035cc35953c: lavu/frame: copy all frame properties in av_frame_copy_props
[16:07] <cone-434> ffmpeg.git 03Hendrik Leppkes 07master:e4c5e08f60fd: lavu/frame: av_frame_make_writable: set the channels on the new frame.
[16:32] <BBB> nevcairiel: since you're cleaning dsputil, interested in removing dct_bits? it's never used (only h264 sets it, but h264 doesn't use any of the dsp functions that depend on dct_bits)
[16:33] <BBB> nevcairiel: as an effect of that, I feel we can delete maybe 10-20 functions in total through the templating
[16:33] <BBB> which would be a good gain in terms of binary waste
[16:52] <nevcairiel> BBB: i really only fixed the build because it used something that didnt even exist anymore
[16:52] <ubitux> 14:54:53 <@michaelni> remote:     (commit.author, commit.logmsg) = metainfo.split("|")
[16:52] <ubitux> 14:54:59 <@michaelni> remote: ValueError: too many values to unpack
[16:52] <ubitux> split("|",1)?
[16:55] <michaelni> ubitux, its not my script nor under my control
[16:56] <ubitux> i never remember the name of the guy, thresh?
[16:56] <michaelni> yes
[16:56] <ubitux> did you ask him?
[16:57] <michaelni> no, but ive seen something similar mentioned on the vlc channel i think a while ago so i thought its known but then i wonder why it hasnt been fixed
[16:58] <michaelni> but better to ask thresh just to be sure he is aware of this issue
[16:59] <ubitux> i've just asked him
[16:59] <michaelni> ok thx
[17:30] <nevcairiel> michaelni: do you know what AVCodecContext->metadata is for? it seems unused (except being set and freed), and causes some issues with mem leaks or double frees because it takes an avframes metadata out of the refcounted frames context
[17:30] <nevcairiel> i removed the setting and freeing and the member from avcodeccontext, and nothing seems to miss it
[17:30] <nevcairiel> and the comment indicates its only internal, so i would like to deprecate or even remove it entirely
[17:44] <michaelni> nevcairiel, about AVCodecContext.metadata, best ask ubitux
[17:45] <nevcairiel> ubitux: ^^ ? :)
[17:46] <ubitux> iirc it was were the metadata was allocated
[17:46] <ubitux> the pointer was kept so when free-ing the frame was destructed there was no memleak
[17:47] <nevcairiel> current code only frees it, and copys the pointer from AVFrame
[17:47] <ubitux> (each decode process was free-ing it, as well as the codec close)
[17:47] <ubitux> this was done when there was no av free frame
[17:47] <durandal_1707> that is little insane
[17:47] <ubitux> adding allocated stuff in av frame was not possible
[17:47] <nevcairiel> so it really has no use, and can go, because avframes have proper memory management now
[17:48] <ubitux> so we added in the codec context, and made the frames point on it
[17:48] <nevcairiel> right now its actually the cause of leaked memory (or double frees)
[17:48] <nevcairiel> i'll send two patches to resolve those then
[17:48] <durandal_1707> why each frame cant have own metadata?
[17:48] <ubitux> nevcairiel: yes it should not be necessary anymore
[17:48] <nevcairiel> durandal_1707: it can now
[17:49] <durandal_1707> so plase fix that insanity
[17:49] <nevcairiel> so whats the opinion on remove vs deprecate? it was documented as internal and ABI is still wide-open .. just remove c ompletely? :d
[17:49] <durandal_1707> ABI open - do whatever you want
[17:51] <michaelni> remove
[17:51] <nevcairiel> patches sent
[17:51] <nevcairiel> fixes a few valgrind memleaks
[17:52] <nevcairiel> if the lavd/lavfi conversion gets in, it should make the leak list a lot shorter in total
[17:52] <ubitux> nevcairiel: i'll have a look to that patch in the next hour
[18:01] <j-b> wow, some people still care about lxf?
[18:06] <durandal_1707> dirac is not ported to refcounted frames?
[18:20] <nevcairiel> ubitux: but the lavfi device still only outputs AVPacket, how else would it transport metadata?
[18:23] <ubitux> how come does it currently work for video without that call then?
[18:23] <nevcairiel> you removed the call and it still worked?
[18:23] <nevcairiel> i shall try this
[18:23] <ubitux> i don't remember removing it, but it doesn't look present anymore
[18:24] <nevcairiel> i still see it
[18:24] <nevcairiel> in decode_video2 and decode_audio4
[18:24] <ubitux> i'm blind.
[18:26] <ubitux> <@durandal_1707> ubitux: does internal get_buffer already provide some logging? // i don't know
[18:26] <ubitux> why do you ask?
[18:31] <durandal_1707> ubitux: because of patch that adds it to single place and removes it from bunch of others, making binary little smaller
[18:32] <durandal_1707> iirc you removed internal log and added generic one ....
[18:40] <durandal_1707> showwaves is leaking memory
[18:40] <durandal_1707> few mbs per second
[18:41] <durandal_1707> is this bug in ffplay or filter?
[18:44] <durandal_1707> ubitux: i lost one minute with your nonsense reply, please read what your write at least once before sending it :-/
[18:47] <ubitux> durandal_1707: sorry about that
[18:49] <ubitux> durandal_1707: about the get_buffer logging, i don't understand your concern about an already existing logging
[18:49] <ubitux> i just moved the logging from decoder specific to the generic one
[18:49] <durandal_1707> it's no concert, it just making sure no double log happens
[18:49] <ubitux> if the generic one is already doing some, then it will be added to it, just like it is currently
[18:49] <durandal_1707> afaik there was already one
[18:50] <durandal_1707> but for custom get buffer it was not gives iirc
[18:50] <ubitux> not for everything at least
[18:51] <ubitux> it shouldn't change current behaviour anyway
[18:51] <durandal_1707> yes, so i'm just making sure you fixed those ugliness
[18:51] <ubitux> i didn't change more than required in the patch
[18:51] <ubitux> so if logging is currently duplicated, it will still be duplicated after the patch
[18:51] <ubitux> no more, no less
[18:52] <ubitux> (except possibly for decoders without the av_log already)
[18:54] <durandal_1707> hmm. i thougt log was present, but i cant find it right now
[18:56] <ubitux> i think the buffer_hints thing can be removed from crystalhd decoder
[18:57] <durandal_1707> yes it should
[19:00] <ubitux> locally fixed
[19:00] <ubitux> will be in my next push
[19:10] <ubitux> any comment on the permission filters?
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:c82bb2815b8f: lavfi/aresample: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:dda59d9adcfa: lavfi/asetnsamples: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:1b0d0e6b7274: lavfi/atempo: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:44f3d217997f: lavfi/aevalsrc: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:00a13a9cdbfa: lavfi/anullsrc: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:60bd8c11b631: lavfi/concat: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:df5be5e27575: lavfi/avfilter: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:27ce858c9861: lavfi/showspectrum: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:bdbdadbaff6f: lavfi/buffersrc: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:05854f5505f5: lavfi/movie: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:f32fee570aa4: lavfi/alphamerge: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:fe6077d90203: lavfi/cellauto: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:227a4b63f5d2: lavfi/life: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:afa0b90803f1: lavfi/mandelbrot: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:bce2e97a16a2: lavfi/mptestsrc: raise filter_frame() error.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:e7279638e855: lavfi/thumbnail: remove unecessary poll_frame() callback.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:1ec94b0f066f: lavc: factorize ff_{thread_,re,}get_buffer error messages.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:20dab078e6ea: lavc/crystalhd: remove now unecessary buffer_hints.
[19:11] <cone-434> ffmpeg.git 03Clément BSsch 07master:de3e0ab35f5e: lavfi/delogo: remove sscanf and rely on av_opt_set_from_string() only.
[19:43] <ubitux> hey saste 
[19:44] <ubitux> saste: i'm going to take your eval volume patch and add the evalonce option, unless you want to do it (very) soon
[20:17] <cone-434> ffmpeg.git 03Hendrik Leppkes 07master:84bf1cbef911: avcodec: remove AVCodecContext->metadata
[20:17] <cone-434> ffmpeg.git 03Hendrik Leppkes 07master:febd78e9044f: lavu/frame: free frame metadata when unrefing a frame.
[20:30] <saste> ubitux, hardly before the weekend
[20:30] <saste> feel free to pick the patch, sorry
[20:30] <ubitux> will do tonight then
[20:30] <ubitux> no worry
[20:31] <ubitux> saste: you can repent yourself by reviewing the (a)perms patch if you want
[20:31] <ubitux> ;)
[20:31] <ubitux> (and buzz me if you need some reviews as well)
[20:39] <llogan> where's the ffmpeg logo with a pope hat?
[20:40] <cone-434> ffmpeg.git 03Stefano Sabatini 07master:ae732640ab34: lavfi/cropdetect: add support for named options
[20:43] <ubitux> huh?
[20:44] Action: ubitux just saw diego talking about pope as well and wonder what's going on
[20:44] Action: ubitux think of http://2.bp.blogspot.com/_h9uf0k8PQjo/TLGlO1aK1-I/AAAAAAAAAAM/T8PPFf8zVkM/s1600/pope-are-you-ready-to-rock.jpg every time pope is mentioned
[20:44] <llogan> heh. good one.
[20:45] <gnafu> According to Google, it seems boogie2988 is the new pope.
[20:46] <llogan> ubitux: a new old guy was empopinated today.
[20:48] <Compn> wheres diego talking about pope ?
[20:49] <llogan> <enter K&R formatting nite and bible joke>
[20:49] <llogan> *nits
[20:59] <ubitux> Compn: on the fork chan
[21:11] <saste> uhm i foresee more lavfi churnup incoming...
[21:22] <ubitux> michaelni: thresh is going to fix the | thing
[21:30] <michaelni> ubitux, good
[22:00] <saste> not bad
[22:23] <ubitux> saste: btw
[22:23] <ubitux> a recent patch from you added some error messages
[22:23] <ubitux> when using OPT_BOOL option in tools
[22:23] <ubitux> for instance -nostats
[22:24] <ubitux> saste: you can reproduce with ./ffmpeg -nostats -f lavfi -i testsrc=d=1 -f null - 
[22:24] <ubitux> Could not find option 'nostats' in any of the FFmpeg subsystems (codec, format, scaler, resampler contexts)
[22:28] <cone-434> ffmpeg.git 03James Darnley 07master:0735b5088055: yadif: restore speed of the C filtering code
[22:28] <cone-434> ffmpeg.git 03Hendrik Leppkes 07master:edcc51fb8e15: tiff: fix handling of metadata with refcounted frames
[22:28] <cone-434> ffmpeg.git 03Hendrik Leppkes 07master:3c7f66997215: lavfi/avcodec: cleanup includes
[22:28] <cone-434> ffmpeg.git 03Hendrik Leppkes 07master:ed69c69a016e: lavfi/avcodec: fix API version checks
[22:31] <saste> ubitux, funny
[22:31] <saste> my patch only added a log, the problem was already present
[22:32] <saste> BTW i suppose the plan is to get rid of libavfilter/avcodec.h at this point, no?
[22:33] <ubitux> no idea
[22:39] <saste> also if you move the option to the end there is no warning
[22:54] <ubitux> mmh got some memory errors here..
[22:55] <saste> did you discard things?
[22:55] <ubitux> http://pastie.org/6479379  does this inspire someone?
[22:56] <ubitux> saste: mmh?
[22:56] <saste> ubitux, silly joke, please discard it
[22:56] <ubitux> @_@
[22:56] <ubitux> mmh i wonder if it's not some kind of missing frame init somewhere
[22:57] <ubitux> meh i wanted to fix something else and i come accross this
[22:58] <ubitux> oh good libav is affected as well.
[23:06] <saste> michaelni, do you know out of your mind what is a safe mantissa size?
[23:07] <saste> ubitux, maybe you want to have a look at the examples patches (they are sweet and simple)
[23:07] <saste> tested with valgrind
[23:08] <ubitux> saste: i'll when i'm done with my current problem
[23:08] <ubitux> (or if you want to review *perms filter to motivate me)
[23:08] <ubitux> i should be done with my current problem in an hour or two
[23:17] <llogan> ffmpeg-user unsubscribe rage.
[23:17] <michaelni> saste, i dont think C makes strict gurantees on it
[23:17] <michaelni> bit it should be 52 bit or so IIRC
[23:18] <saste> michaelni, i'll simply omit in the docs i think
[23:18] <saste> the issue is implied by the fact that double -> int conversion is done
[23:19] <llogan> 1337 subscribers on devel today
[23:20] <saste> llogan, how many downloads?
[23:20] <saste> what about web access stats?
[23:22] <llogan> saste: i dont have shell access to the web server to figure that out
[23:23] <ubitux> ffmpeg.org down?
[23:23] <llogan> all signs point to "yes"
[23:24] <ubitux> :(
[23:25] <llogan> i guess i won't clear the pending moderator requests then
[23:31] <llogan> ubitux: back up
[23:31] <ubitux> good thx
[23:36] <wm4> enabling hardware decoding is still broken, isn't it?
[23:36] <wm4> at least I haven't seen a commit that fixes it
[23:37] <michaelni> wm4, i saw crystalhd and vdpau fixes
[23:47] <ubitux> the uninit valgrind issues with h264 are very annoying to debug problems :(
[23:53] <wm4> was it decided yet what happens to qscale_table?
[23:55] <wm4> just tested it, vdpau is still not enabled by default (it used to be)
[00:00] --- Thu Mar 14 2013