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

[burek]

[01:00] <saste> ubitux: any news with the kerndeint benchmark?
[01:21] <llogan> saste: what about "Create a simple filtergraph"?
[01:25] <saste> llogan, what is a "simple filtergraph"?
[01:26] <saste> "simple" is misleading, since what characterizes it is just 1 in and 1 out
[01:27] <llogan> i tohught it would help users know that there is a different between simple and complex
[01:27] <llogan> many users seem to think -vf is used with any number of inputs
[01:28] <llogan> which is often possible, but not really recommended, IMO
[01:28] <llogan> it was just something for you to consider, not something that i feel strongly about.
[02:34] <cone-463> ffmpeg.git 03André Pankratz 07release/1.1:3dab6e542941: lavfi/yadif: fix shorthand/option mismatch
[02:52] <Nano> is it ok to use the FFmpeg logo in my app, to visualize what its based on ?
[02:56] <Compn> is your app open source ?
[02:56] <Compn> nano
[02:56] <kierank> llogan: afterburner is default
[02:56] <Compn> nano : where would you want to use our logo ? in the about box ? does your app use ffmpeg ?
[02:56] <Compn> or on your webpage ?
[02:57] <Compn> i'm not sure who gets the answer your question Nano . maybe you will have to wait for michaelni to answer .
[02:58] <beastd> Nano: i think 2 things should be clear when looking at the logo in your app: 1) your app is not ffmpeg  2) your app is not advertised by ffmpeg
[02:58] <Nano> on the mainpage of my app, to give ffmpeg devs credit for their work.
[02:59] <Nano> sure!
[03:00] <llogan> in #ffmpeg i recommend contacting herve
[03:01] <beastd> also we should consider providing some versions of the logo that state "powered by" or "based on" or similar versions
[03:02] <llogan> we also need to get the logo under a proper license. it is currently ambiguous.
[03:02] <beastd> +1 dislike current license
[03:02] <llogan> kierank: ah, thanks. someone else added that section, but i'll update it.
[03:03] <beastd> but i wanted to contact herve and others who did art for ffmpeg and ask if they provide their work under some share-freely license with some restrictions
[03:03] <llogan> yeah, i meant to contact him about that once i become less trademark and license ignorant.
[03:03] <llogan> give me 5 years.
[03:04] <beastd> i hope i will beat you to it
[03:04] <llogan> me too
[03:05] Action: llogan has been summoned to have some beers
[03:07] <llogan> Nano: might want to request adding your project to the ffmpeg projects page...
[03:11] <Nano> yes, when it's done
[03:19] <beastd> Maybe this would be a good license suggestion for ffmpeg artwork:  http://creativecommons.org/licenses/by-nc-nd/3.0/
[03:39] <mfg> does Stefano hang aroundin here?
[03:45] <beastd> mfg: sometimes. what are you working on?
[03:46] <mfg> I fixed up the stuff he recommended I fix for HTTP cookies. I just had a question about one part I didn't think made sense
[03:48] <mfg> also, he said send the http stuff as a separate patch, so I'm worried we'll loose some of the context of the email chain.
[03:48] <mfg> but anyway, I'll just resubmit tomorrow with a note on the bit I didn't agree with.
[03:48] <mfg> ttyl
[03:49] <beastd> huh? that was quick...
[05:09] <cone-463> ffmpeg.git 03Michael Niedermayer 07master:cc548ea7a603: vc1dec: ensure cbpcy_vlc has been set before decoding a frame.
[05:09] <cone-463> ffmpeg.git 03Michael Niedermayer 07master:d9226b3717fd: mpegvideo: dont leave stale pointers in next/last picture
[10:56] <cone-384> ffmpeg.git 03Stefano Sabatini 07master:255ec768da6f: lavf/http: fix/extend option descriptions
[10:56] <cone-384> ffmpeg.git 03Stefano Sabatini 07master:0a7cd740438b: doc/protocols: document http protocol options
[10:56] <cone-384> ffmpeg.git 03Stefano Sabatini 07master:cab85051c0f0: doc/ffserver: rework introducing paragraphs of the "description" chapter
[10:56] <cone-384> ffmpeg.git 03Stefano Sabatini 07master:df018207f90b: doc/ffserver: remove paragraph in the introductory blurb
[10:56] <cone-384> ffmpeg.git 03Stefano Sabatini 07master:0edb44028284: doc/ffserver: remove painfully outdated "What do I need?" section
[11:03] <cone-384> ffmpeg.git 03Stefano Sabatini 07master:4a0d1b2159a8: doc/protocols: improve wording of a sentence in http docs
[11:43] <durandal_1707> michaelni: so you do not plant to fix ff_find_pix_fmt?
[12:04] Action: durandal_1707 just found how trac is crap
[12:16] <durandal_1707> for some reason when i run fate it loops forever for g726 test
[12:45] <durandal_1707> there should be check if two codecs use same class
[12:46] <durandal_1707> this caues infinite loop
[12:51] <durandal_1707> is g7231 entry in riff for 0x42 really correct ?
[12:52] <durandal_1707> didnt it come much longer after all lower numbers got filled up
[12:52] <nevcairiel> #define  WAVE_FORMAT_MSG723                     0x0042 /* Microsoft Corporation */
[12:52] <nevcairiel> microsoft says it is
[12:52] <michaelni> durandal_1707,  ff_find_pix_fmt ? you mean that its used in lavf ?
[12:53] <durandal_1707> nevcairiel: g723.1 != g723
[12:53] <durandal_1707> michaelni: exactly
[12:53] <durandal_1707> used in utils
[12:53] <durandal_1707> and recently in frm demuxer
[12:55] <durandal_1707> git blame is useless
[12:55] <durandal_1707> because every 5 seconds some idiot reindent code
[12:56] <nevcairiel> so use git blame -w?
[12:57] <durandal_1707> how could that help?
[12:57] <nevcairiel> it ignores whitespace
[12:57] <nevcairiel> indent = whitespace
[12:57] <durandal_1707> heh but it cant handle prefixes
[12:57] <durandal_1707> like stupid renames
[12:58] <nevcairiel> well cant have everthing
[13:00] <wm4> gitk usually is rather helpful by jumping to the surrounded context of the change, and you can select what line next to blame
[13:03] <durandal_1707> i prefer cli, so implement that in ncurses
[13:13] <cone-384> ffmpeg.git 03Martin Storsjö 07master:58b59718813b: rtp: Cosmetic cleanup
[13:13] <cone-384> ffmpeg.git 03Martin Storsjö 07master:c44784c9bb9d: rtp: Rename a static variable to normal naming conventions
[13:13] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:dda2d2974863: Merge commit 'c44784c9bb9d0ddf5d39d0dfa640816a57b8f457'
[13:18] <cone-384> ffmpeg.git 03Martin Storsjö 07master:3900d53fb1b9: rtsp: Remove references to weirdly named variables in other files
[13:18] <cone-384> ffmpeg.git 03Martin Storsjö 07master:54cb096ee455: rtsp: Remove an outdated comment
[13:18] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:e730c3a2cbc4: Merge commit '54cb096ee4558b3bfc28c2fcd6418ce82dc39fe1'
[13:22] <durandal_1707> michaelni: how adpcm with various bps can be recognized in nut?
[13:34] <michaelni> durandal_1707, codec_tag or extradata
[13:34] <michaelni> or data of packets itself
[13:35] <durandal_1707> afaik, it is not done currently that way
[13:38] <cone-384> ffmpeg.git 03Martin Storsjö 07master:f6804c3e1ba5: rtpdec: Remove a useless todo comment
[13:38] <cone-384> ffmpeg.git 03Luca Barbato 07master:f61272f0efd8: ratecontrol: K&R cosmetic formatting
[13:38] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:15daa8f9ddaf: Merge commit 'f61272f0efd80da437570aad2c40e00f9d3f4fe6'
[14:01] <cone-384> ffmpeg.git 03Rémi Denis-Courmont 07master:169fb94f0f65: pixfmt: add picture format for VDPAU
[14:01] <cone-384> ffmpeg.git 03Diego Biurrun 07master:f89466ad6fd6: Add version bump and APIchanges entry for Add AV_PIX_FMT_VDPAU.
[14:01] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:dae382b5b28d: Merge remote-tracking branch 'qatar/master'
[14:05] <durandal_1707> hmm but there is already bunch of vdpau pix fmts
[14:05] <wm4> durandal_1707: they're adding hwaccel support
[14:06] <wm4> which doesn't need pixel formats to distinguish the decoder
[14:06] <wm4> michaelni: is there any reason why some decoders decode flipped, instead of flipping the output image?
[14:07] <michaelni> wm4, which decoders?
[14:08] <durandal_1707> wm4: vdpau pix fmts already use hwaccel
[14:08] <wm4> durandal_1707: no, not the framework
[14:08] <wm4> michaelni: good question, I get it with Film_200_zygo_pro.mov, which is h263
[14:09] <durandal_1707> that is container related flag
[14:09] <wm4> looks like it
[14:09] <durandal_1707> so they are adding hwaccel support without hwaccel framework?
[14:10] <wm4> durandal_1707: no... they're making it so that the normal decoder can use it, just like with dxva/vaapi/vla
[14:10] <wm4> *vda
[14:12] <durandal_1707> isn't someting similar aready done in ffmpeg?
[14:12] <wm4> no
[14:12] <wm4> you need a special vdpau specific decoder, which works nothing like the codecs that use the proper hwaccel architecture
[14:17] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:43d6ac53f262: lavc: ff_find_pix_fmt ->avpriv
[14:17] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:db1ba2213f70: lavf: use avpriv_find_pix_fmt instead of ff_
[15:42] <cone-384> ffmpeg.git 03Paul B Mahol 07master:868ac91c8dbe: frmdec: do not abuse ff_codec_get_id()
[16:31] <kierank> "If it can not be reproduced with ffmpeg it is not ffmpeg bug."
[16:31] <kierank> that's not true at all
[16:31] <kierank> the bug i reported with yadif could not be reproduced with ffmpeg
[16:31] <kierank> but it was still a bug that got fixed
[16:32] <durandal_1707> kierank: yes, that statement was not meant to considered absolute truth
[16:32] <durandal_1707> *to be ...
[17:26] <saste> michaelni, I mean, what's the name of the binary?
[17:27] <saste> "asan" or whatever, so i don't have to google for it
[17:31] <cone-384> ffmpeg.git 03Matthieu Bouron 07master:f9eed5d7e620: lavfi/aevalsrc: try to honor specified duration
[17:37] <michaelni> saste, its clang
[17:37] <michaelni> here at least
[17:39] <saste> michaelni, ok please fix it accordingly
[17:41] <michaelni> this will only confuse readers
[17:43] <michaelni> valgrind and asan differ
[17:45] <michaelni> address sanitizer adds checks at compile time
[17:46] <michaelni> valgrind does it at runtime
[17:46] <michaelni> so anything can be run under valgrind but for address sanitizer you need to build it with a clang that supports that stuff
[17:48] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:b5d9e5d06cb6: swr: minor simplification for the noise shaping pos update
[17:48] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:68ff7d265f17: swr: use local variable for ns_errors
[17:48] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:ef7fdc8cff2c: swr: use a local variable for ns_coeffs
[17:51] <saste> michaelni, whatever, just fix the typos and commit
[17:52] <michaelni> ok
[17:52] <wm4> saste: gradfun has a nice horizontal line through the middle of the video with nv12
[17:53] <saste> wm4, possible, do you want to fix it? ;-)
[17:54] <wm4> saste: no, I concluded that gradfun simply doesn't work with nv12
[17:54] <wm4> but maybe I'm wrong
[17:54] <nevcairiel> does it claim to?
[17:54] <saste> wm4: odd height?
[17:56] <wm4> saste: no
[17:56] <wm4> nevcairiel: yes
[17:57] <wm4> saste: unrelated, can I ask how format negotiation within lavfi works?
[17:57] <saste> wm4, no
[17:57] <saste> that's trade secret
[17:57] <nevcairiel> the real answer is that noone knows
[17:57] <wm4> how does lavfi know if a filter, if it accepts a certain output format on the input pads, what formats the output pads will have?
[17:58] <wm4> query_formats seems to set format lists per pad, and doesn't involve any interaction between them
[17:58] <saste> wm4, libavfilter/filtfmts-test filter args
[17:59] <saste> the exact algo is quite complicated, and i can't give you a short explanation
[18:00] <saste> especially considering that i have to run now
[18:00] <pengvado> wm4: yeah, that's wrong. gradfun supports anything planar, not NV12.
[18:00] <saste> but if you want to force a format, the usual trick is: format=X,filter,format=X
[18:00] <wm4> saste: lavfi will insert scale filters, won't it
[18:01] <saste> wm4: only if necessary
[18:01] <wm4> does it print anywhere if it does?
[18:01] <saste> wm4, in the log (but even that could be improved)
[18:02] <saste> gotta go now, bye
[18:08] <wm4> there are funny things
[18:09] <wm4> like execution a given section of code for 3 times with no reason given, or large sections of commented code
[18:09] <wm4> *executing
[18:10] <wm4> hm maybe the filter list references have some magic meaning
[18:10] <wm4> and setting two pads to the same filter list means they always use the same format?
[18:11] <wm4> as opposed to merely supporting the same formats
[18:12] <michaelni> wm4 yes
[18:12] <michaelni> same lists means they must have the same format
[18:13] <wm4> michaelni: ah... well that's certainly surprising
[18:14] <wm4> I guess this also means that lavfi doesn't support arbitrary lists of pairs of input/output formats, or is there a trick?
[18:15] <michaelni> the goal of the format negotiation design was that it can be solved (near) optimally for arbitrary filter graphs in polynomial time
[18:15] <michaelni> graphs with arbitrary lists of pairs cant be solved in polynomial time so they are not supported currently
[18:16] <wm4> k
[18:16] <michaelni> they could be supported in small graphs optimally or non optimally with lots of scale/convert in a large graph
[18:19] <durandal_1707> lol, people pick random project that use ffmpeg and compiles it with latest ffmpeg and complains it crash
[18:20] <wm4> because ffmpeg changes its api all the time for no fucking reason
[18:20] <wm4> (almost)
[18:20] <Compn> yes, api changes are crazy
[18:20] <Compn> mostly just to look like they are doing lots of work and to mess up the code history
[18:20] <wm4> wat
[18:21] <Compn> wat
[18:21] <Compn> you dont consider renaming functions to be changing api ?
[18:21] <durandal_1707> michaelni: how to normalize floats? RI just cast them to short
[18:22] <wm4> anyway, basically it goes like this: ffmpeg devs make a mess, people see themselves forced to use the mess, ffmpeg devs try to clean up the mess and remove the old functions for no reason, people try to keep up, ffmpeg devs realize the new mess isn't so great either, etc. (you can replace ffmpeg with Libav, too)
[18:22] <wm4> which probably happens in all projects, but if your API is public, you got to hold up
[18:23] <wm4> where's the ffmpeg version of Linus Torvalds who insults people on christmas if they break ABI?
[18:23] <wm4> /rant
[18:28] <kierank> well it's more of a case that if libav api/abi changes are merged then ffmpeg needs to bump accordingly
[18:30] <michaelni> durandal_1707, normalize ? like av_float2int() ?
[18:32] <michaelni> kierank, libav did not bump for the wma audio sample format change
[18:33] <kierank> wma alone wasn't an api change, though?
[18:33] <michaelni> no
[18:33] <kierank> because you could query the sample_fmt
[18:34] <michaelni> yes, but i think apps dont
[18:34] <michaelni> otherwise they shouldnzt crash
[18:34] <michaelni> but either work or say "sample fmt not supported"
[18:35] <nevcairiel> a decoder giving you another sample format is not a API change imho
[18:35] <nevcairiel> adding a new sample format is
[18:36] <Compn> hmm
[18:36] <Compn> good question
[18:36] <michaelni> the problem is neither adding nor changing its adding AND changing to a new one
[18:36] <Compn> a decoder returns different data than what an app is used to
[18:36] Action: Compn afk
[18:36] <nevcairiel> well sure, if you add a new sample format and its not used at all, it wont cause trouble :)
[18:37] <durandal_1707> michaelni: well point is to still outputs floats, but currently output is too loud/clipped if I do not divide some number(s) with say 16384
[18:37] <nevcairiel> but someone using avcodec and assuming that one variable field is always the same value is rather risky
[18:37] <michaelni> if its just used in new decoders it also shouldnt be a problem, the new decoders just would not be supported by old apps
[18:38] <michaelni> durandal_1707, is there some spec saying something about how to scale / clip ?
[18:57] <durandal_1707> ubitux: you still did not commit patch that speedup kerdeint ?
[19:03] <durandal_1707> michaelni: i will need to look...
[19:26] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:1c14c3412ea1: dec/developer: Add Valgrind / Address Sanitizer to the patch checklist
[19:26] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:93bc0f018039: swr/noise_shaping_data: pad coeffs to multiple of 4 when they are 1 below
[19:26] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:c8737d348be5: swr: work with 4 noise shaping coeffs at a time
[19:52] <cha0s_> is anyone available to help diagnose and possibly correct an ffmpeg/winff issue?
[20:11] <cha0s_> cananyone help me find out whats going onwithmy ffmpeg/winff?
[20:27] <durandal11707> what next i should do?
[20:28] <cbsrobot> durandal_1707: what about a codec ?
[20:29] <durandal_1707> what one?
[20:29] <cbsrobot> f.ex dxv codec: http://resolume.com/download/
[20:29] <cbsrobot> lower right corner
[20:30] <cbsrobot> it hase some debug informations in it
[20:31] <durandal_1707> does it work without gpu?
[20:31] <cbsrobot> I guess not
[20:33] <durandal_1707> i think it does from QT - where it may be slow because no gpu is used
[20:34] <durandal_1707> how much is it popular?
[20:35] <cbsrobot> not popular at all
[20:35] <cbsrobot> just fun
[20:35] <cbsrobot> it seems it work even without gpu
[20:36] <cbsrobot> "The video will play in any other software but it will not be hardware accelerated."
[20:42] <durandal_1707> cbsrobot: but that codec is their selling point, if i RE they will loose job
[20:43] <cbsrobot> hmm I don't think so
[20:43] <cbsrobot> they don't sell the codec - it's for free
[20:43] <cbsrobot> but you can only use it in qt
[20:44] <durandal_1707> yes but opening it will lead to open hw acceleration
[20:44] <durandal_1707> that is main reason why it is still closed
[20:45] <cbsrobot> well I think they use it in their software and it seems to be the only one that can use that codec for hwaccel
[20:47] <cbsrobot> maybe they will also winn job
[20:47] <cbsrobot> because you can use ffmpeg to generate such files
[21:07] <saste> wm4: how can I reproduce the gradfun issue?
[21:11] <wm4> saste: use an extreme strength value
[21:45] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:754dd7e88955: dvdsubdec: use unsigned shifts to avoid shifting into the sign bit
[21:45] <cone-384> ffmpeg.git 03Michael Niedermayer 07master:2ea3f37d5f97: dvdsubenc: use unsigned shifts to avoid shifting into the sign bit
[21:57] <barque> can you compile ffmpeg with libstagefright for Android 2.3.1 using the NDK?
[21:57] <barque> or just even Android 2.3 (e.g. 2.3.3)
[22:01] <barque> anyone?
[22:17] <cbsrobot> barque: see http://fate.ffmpeg.org/
[22:20] <barque> are there compiled binaries for those tests as well? :P
[22:22] <cbsrobot> no I don't think so
[22:22] <cbsrobot> or search google for it
[22:22] <cbsrobot> not sure what project uses libstagefright
[22:22] <cbsrobot> maybe https://github.com/appunite/AndroidFFmpeg
[22:26] <barque> There's also FFmpeg4Android
[22:44] <barque> thanks for the info anyway
[22:54] <Daemon404> nevcairiel, how do you work around the broken-ass eval stuff in fate on windows
[22:54] <Daemon404> scenedetect always fails cause of it
[22:55] <nevcairiel> relative path to fate samples
[22:55] <Daemon404> i see
[22:55] <Daemon404> -_-
[23:38] <Compn> wonder if subitux is alive
[23:46] <cbsrobot> hehe
[00:00] --- Sun Jan 13 2013