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

[burek]

[00:22] <cone-174> ffmpeg.git 03Timothy Gu 07master:4703a345fb41: doc/encoders: Add documentation for libmp3lame
[01:17] <michaelni> anyone wants to review a rtp related pull request: https://github.com/FFmpeg/FFmpeg/pull/22 ? BBB, wbs ?
[03:36] <cone-232> ffmpeg.git 03Michael Niedermayer 07master:d480b36db4aa: av_d2q: Avoid llrint(), its not correctly implemented in old netbsd
[03:36] <cone-232> ffmpeg.git 03Michael Niedermayer 07master:4cf7b87551f2: av_cpu_count: factorize "detected %d logical cores" message
[09:57] <cehoyos> michaelni: I slightly misremembered / the user did not upload the png but the ffv1 file (which should make no difference):
[09:57] <cehoyos> ffmpeg -i animated_ffv1-giant-huff.mov -vcodec ffv1 ffv1.mov <- identical size
[09:58] <cehoyos> ffmpeg -i animated_ffv1-giant-huff.mov -vcodec png png.mov <- 15% bigger
[09:58] <cehoyos> ffmpeg -i animated_ffv1-giant-huff.mov -vcodec huffyuv huffyuv.mov <- output file size is 126x the size of ffv1
[09:59] <cehoyos> Is this completely unexpected or not really for a mostly white (artificial) input
[09:59] <cehoyos> ?
[11:11] <michaelni> cehoyos, its expected that huffyuv performs poorly on mostly flat artificial input
[11:31] <durandal_1707> doesn't bbox do same as cropdetect but performs worse?
[11:34] <saste_> durandal_1707, afaik bbox should be faster
[11:34] <durandal_1707> but it performs badly here
[11:35] <saste_> durandal_1707, what are you doing
[11:35] <saste_> bbox and cropdetect are different things
[11:36] <durandal_1707> what bbox does?
[11:36] <saste_> bbox computes a bounding box in the image, given a minimum value
[11:36] <saste_> it will mark the minimum box containing values > min_value
[11:37] <saste_> Calculate the smallest rectangle that will encompass the region with values > min_val.
[11:38] <saste_> which is not the same as what cropdetect computes
[11:38] <durandal_1707> yes....
[11:49] <durandal_1707> the params for drawbox could be expression, and then we could add metadata reading to expr
[11:56] <saste_> durandal_1707, yes, i had the same idea
[12:34] <cehoyos> michaelni: Thank you!
[12:36] <durandal_1707> i should really take a break from lavfi
[12:42] <ubitux> durandal_1707: you have some mp filters left to port
[12:46] <durandal_1707> not gonna happen
[12:47] <ubitux> :(
[12:48] <ubitux> durandal_1707: then work on subtitles! ;)
[12:49] <durandal_1707> i know nothing about subtitles
[12:49] <ubitux> that's good, it means you're gonna learn a lot of things
[12:50] <durandal_1707> and what is left to do?
[12:50] <ubitux> inject into lavfi
[12:50] <ubitux> make sane decoded subtitles
[12:50] <ubitux> closed captions, teletext
[12:51] <ubitux> that kind of stuff :)
[12:51] Action: durandal_1707 scared
[12:51] <ubitux> fear is the mind killer
[12:53] <durandal_1707> fear is way to survive
[12:54] <ubitux> you're going to transform into a braindead beast :(
[12:56] <ubitux> saste_: can we achieve any a/v synchronization (at least with the api) with xv output?
[12:56] <durandal_1707> nope, improve libavdevice
[12:57] <ubitux> what's the point of those outputs then?
[12:57] <cone-853> ffmpeg.git 03Paul B Mahol 07master:40a87a6a69d9: lavfi/noise: use av_image_copy_plane()
[12:57] <durandal_1707> ubitux: fun
[12:57] <ubitux> okay
[12:58] <durandal_1707> i dunno if anybody use lavd (except us)
[12:59] <ubitux> well indev are useful, at least with the cli
[12:59] <ubitux> for outdev, i'm wondering
[13:03] <durandal_1707> so there is no simd that does sums/subtrac two arrays?
[13:08] <saste_> ubitux, what kind of synchronization?
[13:08] <ubitux> saste_: timing?
[13:09] <ubitux> basically use a ffmpeg-like app as a ffplay
[13:09] <ubitux> ...or use outdev from ffplay :p
[13:10] <saste_> ubitux: when you transcode data, it could be useful to visualize it
[13:10] <ubitux> you should add an example ;)
[13:11] <ubitux> durandal_1707: i think alsa & sdl are auto detected because they are somehow required to get a useful sdl
[13:12] <ubitux> basically they can be considered essential core libs
[13:12] <saste_> also suppose that you are using multiple outputs, with xv you can show multiple outputs
[13:12] <ubitux> you can with sdl?
[13:12] <saste_> also, suppose that we implement a movie sink, we can visualize data that way
[13:12] <ubitux> ok
[13:12] <saste_> sdl only supports one window
[13:12] <saste_> also with xv you have more control
[13:13] <saste_> for example you can specify to write on the current terminal window
[13:13] <saste_> rather than creating a new window
[13:13] <ubitux> haha ok
[13:18] <cehoyos> concerning outdevs: alsa is *very* useful when testing multichannel audio (and you don't want to use WMP)
[13:19] <durandal_1707> its obvious that devs use lavd
[13:21] <cehoyos> I never tested -f alsa -f sdl - is it possible to get correct A/V sync?
[13:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:4758e32a6c48: matroska_read_seek: Fix used streams for subtitle index compensation
[13:23] <saste_> cehoyos, ffmpeg -re -i INPUT -f sdl out -f alsa ... ?
[13:26] <funman> cehoyos: i have the 2nd sample of https://trac.videolan.org/vlc/ticket/8680#comment:6 , give me your mail and i'll send it
[13:26] <funman> cehoyos: the guy sent a mail
[13:27] <cehoyos> saste: No, does not work;-(
[13:28] <cehoyos> funman: cehoyos at ag.or.at
[13:30] <funman> sent (1M)
[13:30] <cehoyos> funman: You can delete the following files from incoming (if you want): audio_silence_after* (moved to ffmpeg.org), Underworld* (not uploaded as "binary", unusable)
[13:31] <cehoyos> And fraps_flv1_decoding*
[13:33] <saste_> cehoyos, i never use the also output
[13:33] <saste_> indeed i just got a crash
[13:34] <cehoyos> Works fine here...
[13:34] <saste_> snd_pcm_close: Assertion `pcm' failed.
[13:34] <cehoyos> funman: The second even works mostly with avconv.
[13:34] <cehoyos> Concerning the first one: Did you intentionally change libavcodec on Windows vlc to broken versions? You do know that they claim their version to be exploitable?
[13:35] <cehoyos> saste: You could tell Nicolas, he used to work on the alsa device.
[13:43] <cehoyos> funman: What is Videolan ticket 8672? There is neither a sample nor an explanation so it is hard to understand if it is something we should fix...
[13:46] <durandal_1707> so how are libavcodec related stuff reported on vlc pointed to FFmpeg?
[13:50] <cehoyos> If you mean: How do we know about relavant reports? - I report them on FFmpeg trac (search for "videolan")
[13:51] <durandal_1707> so you waste day and night reading vlc bug reports?
[13:53] <cehoyos> Only some.
[13:59] <durandal_1707> could someone please benchmark noise(and blend too) slice threading on SMP cpu, just to see it's faster
[14:03] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:81be0965e362: j2k: merge Jpeg2000CodingStyle from jpeg2000
[14:03] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:c78f3e557170: j2kdec: prog_order reading from jpeg2000dec
[14:03] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:d42106c3ac14: j2k: rename a few inline functions and data tables to match jpeg2000
[14:04] <durandal_1707> so when we will drop one of them?
[14:17] <michaelni> durandal_1707, as soon as one can decode all files that the other can
[14:18] <durandal_1707> so what is missing? and is anybody working on that?
[14:19] <cehoyos> durandal_1707: Exact command lines (with fate source files) please
[14:20] <durandal_1707> ???
[14:23] <cehoyos> .. for noise and blend benchmarking
[14:24] <durandal_1707> for noise you can use anything, you just compare with different nb_threads (-threads X after -vf ..)
[14:27] <durandal_1707> ffplay -f lavfi -i smptebars=hd720 -vf noise=33:33:t -threads [1 vs 0/auto]
[14:27] <durandal_1707> i think, _if_ ffplay pass -threads .. correctly to avfiltergraph (ffmpeg does)
[14:28] <cehoyos> How do I measure performance with ffplay ?
[14:28] <durandal_1707> you just look if nothing is obviously broken
[14:28] <durandal_1707> for benchmark, you can use ffmpeg ... -f null -
[14:29] <durandal_1707> with fixed duration, and just look how much time it takes....
[14:29] <cehoyos> ffplay -f lavfi -i smptebars=hd720 -vf noise=33:33:t looks very similar here with -threads 1 and -threads 8
[14:29] <cehoyos> If you want me to do a performance test, please post a command line
[14:31] <funman> cehoyos: files removed from incoming
[14:31] <funman> cehoyos: about the ts sample, yes it worked fine for me too so i guess it was an issue with an older revision, didn't investigate more than that
[14:31] <funman> and if tickets are unclear you should ask the reporter, i have no idea what this means either :)
[14:34] <durandal_1707> cehoyos: something like: time ffmpeg -f lavfi -i smptebars=s=hd720:d=120 -vf noise=33:33:t -threads 10 -f null -
[14:42] <saste_> michaelni, the reinit command in drawtext is broken
[14:42] <saste_> i plan to replace it with several commands (text, fontsize, x, y, etc...)
[14:42] <durandal_1707> what is broken with it?
[14:43] <michaelni> saste_, sounds very complex
[14:44] <michaelni> saste_, will you do this with all filters ?
[14:44] <michaelni> i mean replace a single reinit with a command for every parameter ?
[14:44] <saste_> michaelni, reinit is only implemented in drawtext, and is not working
[14:45] <michaelni> and ?
[14:45] <saste_> also it sounds silly to reinit freetype libraries, font and all if you only want to change the text
[14:45] <saste_> also with a separate command you know what is failing
[14:45] <michaelni> you can compare with last and reinit freetype only when needed
[14:46] <michaelni> no need to make the API 10x more complex
[14:46] <saste_> michaelni, requiring all the filter parameter if you want only to change text, that is complex
[14:47] <durandal_1707> there is no api that sends commands to filter
[14:48] <durandal_1707> michaelni: wrong bytestream function is used in j2kdec (this is some copy/paste error)
[14:49] <saste_> durandal_1707, we *have* a command API
[14:50] <durandal_1707> .process_command ?
[14:51] <michaelni> durandal_1707, which line number?
[14:52] <durandal_1707> michaelni: 334:42: btw, what compiler you use?
[14:52] <michaelni> gcc
[14:52] <durandal_1707> with warnings disabled?
[14:54] <michaelni> no they are enabled, i must have looked elsewhere when building ...
[14:55] <durandal_1707> hmm, is there way to enable warnings=fail compilation for some warnings/files?
[14:55] <michaelni> saste_, and if you want to change all parameters yours is very complex
[14:56] <michaelni> durandal_1707, yes but last i looked it did not fully work with gcc
[14:57] <michaelni> saste_, and the user knows the syntax to change all for every filter
[14:57] <michaelni> he does not know the syntax per option per filter
[14:57] <michaelni> it makes a complex system more complex
[14:58] <michaelni> thats not an objection from me, just a observation
[15:01] <cehoyos> durandal_1707: No speed difference between x=1, x=2 and x=8 for time ./ffmpeg -f lavfi -i smptebars=s=hd720:d=120 -vf noise=33:33:t -threads  -vframes 10000 -benchmark -f null -
[15:02] <cehoyos> durandal_1707: No speed difference between x=1, x=2 and x=8 for time ./ffmpeg -f lavfi -i smptebars=s=hd720:d=120 -vf noise=33:33:t -threads x -vframes 10000 -benchmark -f null -
[15:02] <durandal_1707> what is your cpu?
[15:04] <cehoyos> quad core xeon with ht
[15:05] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:438c45c08a1f: j2kdec: fix used bytestream function
[15:05] <durandal_1707> and with yadif you get better results?
[15:07] <michaelni> saste_, besides with named options why cant individual parameters be changed, the syntax already supports it
[15:07] <michaelni> like text=abc
[15:08] <cehoyos> durandal_1707: No, I wonder how you are supposed to set number of threads for vf
[15:09] <durandal_1707> well, in top output, i see that number of threads changed for ffmpeg
[15:10] <saste_> michaelni, suppose that you have a complex reinit command, which sets several things
[15:10] <saste_> now a single option is not valid, how are you supposed to restore the state of the filter?
[15:11] <saste_> note that, even when reinit was working, it was crashing in case for example the font filename was wrong
[15:11] <durandal_1707> cehoyos: you can hardcode value by editing nb_threads in libavfilter/avfiltergraph.c
[15:11] <saste_> in general you should set an option, fail and restore the previous value in case it is invalid
[15:11] <saste_> this can't be easily done by simply calling reinit
[15:12] <saste_> i had the same problem with hue, and I decided that the sanest solution was to drop the reinit command
[15:13] <michaelni> saste_, it should be possible to restore the old state by reiniting with the last successfull parameter set
[15:13] <durandal_1707> well imho, the command stuff should be simple & easy to add
[15:14] <michaelni> yes
[15:14] <michaelni> all AVOptions should automatically be accessable
[15:14] <michaelni> saste_, also if you only allow changeing one option at a time you will get stuck
[15:14] <durandal_1707> and maybe flag should be added(to -filters output) for filters that support .process_command
[15:15] <michaelni> saste_, when changeing from A0,A1 to B0,B1 and A0,B1 and B0,A1 and both invalid
[15:16] <saste_> durandal_1707, not all options should be associated to a command
[15:17] <michaelni> saste_, practical example could be filetype option and filename, they need to be changed together
[15:18] <michaelni> also coordinated would need to be changed in carefully choosen order or intermediate states would be invalid, i dont like that kind of complexity resulting out of "single option change only"
[15:19] <durandal_1707> saste_: add flag to AVOption ?
[15:20] <michaelni> saste example rectange chnage: {100,100}-{150,150} -> {200,0}-{300,50}
[15:21] <durandal_1707> ok, everybody agrees on that
[15:22] <saste_> michaelni, you can set them with a single command, which should not necessarily be mapped to a single option
[15:25] <cehoyos> durandal_1707: I don't think you can set the number of filter threads from the command line, so I don't think benchmark is easily possible.
[15:26] <durandal_1707> cehoyos: top does'nt show number of threads ffmpeg use?
[15:26] <cehoyos> What would that help if you can't set it?
[15:26] <michaelni> cehoyos, myfilter=thread_type=0 can be used as a hack to disable therading
[15:26] <durandal_1707> you could than compare hard way: without patch....
[15:27] <michaelni> saste_, yes you can add complexity
[15:27] <saste_> michaelni, or you can things simple and borken
[15:27] <saste_> *you can keep things ...
[15:28] <durandal_1707> there is no: simple, working, perfect way?
[15:28] <michaelni> sure there is but noone volunteers to implemengt it
[15:28] <michaelni> just leave broken or implement very complex system
[15:29] <michaelni> FOSS as its finest
[15:30] <durandal_1707> maybe because its hard
[15:31] <michaelni> what should be implemented is a system to allow reinit with a full parameter string (and possibly the ability to set new parameters with AVOptions and seperate from the check and reinit once all options are set and consistent)
[15:32] <michaelni> there should be ideally very little or no code per filter
[15:33] <durandal_1707> isn't this just nice way to make possible do something which is otherwise normally done in scripting
[15:33] <cehoyos> durandal_1707: Is it possible that for noise, you originally wanted me to test a patch that is not committed yet?
[15:33] <durandal_1707> cehoyos: yup, patch is on ml, otherwise i can push it...
[15:35] <michaelni> durandal_1707, the script needs to interface with the filters somehow so it can chnage things
[15:35] <saste_> michaelni, the problem is that initialization is usually just done at init, you can't in general assume that initialization can be performed when the filter is already running
[15:36] <cehoyos> durandal_1707: I get some speedup (max 20%) at the cost of significant overhead over all cores (that is approximately what yadif does)
[15:36] <cehoyos> Or in other words: This slice threads costs 80 and brings you 20
[15:37] <durandal_1707> well, maybe its just yadif fault
[15:37] <cehoyos> Since it is the same with noise ?
[15:37] <michaelni> its because the implementation of threads in avfilter is broken
[15:37] <durandal_1707> i dunno, my cpu is celeron m
[15:38] <durandal_1707> i only can test that code is correct
[15:38] <durandal_1707> michaelni: but it it copy&pasted from lavc, isn't
[15:39] <michaelni> it is but flaws where added
[15:40] <michaelni> there should not be a execute call per plane for example
[15:40] <michaelni> that surely adds overhead for all therads stoping/syncing and restarting
[15:41] <michaelni> also frame threads would be faster as they can run even when filter_frame() doesnt
[15:41] <durandal_1707> but frame threads would have limited scope
[15:42] <ubitux> every filter marked with timeline generic are potentially frame-threadable and would benefit from it IMO
[15:43] <ubitux> afaict :p
[15:43] <durandal_1707> yes, ... i did not said frame threads are useless
[15:44] <durandal_1707> michaelni: execute call per plane is done in filters, this can be changed easily, but would that help?
[15:44] <cehoyos> michaelni: Ticket 2046 contains a link to an ancient patchset that includes (probably among other things) a bitstream filter that allows to change h264 properties: https://direct264.svn.sourceforge.net/svnroot/direct264/Patches
[15:46] <ubitux> btw, is anyone interested in reviewing the hald clut patchset in the next days?
[15:46] <michaelni> durandal_1707, someone would have to try, i think it would give a few % speedup
[15:46] <durandal_1707> michaelni: and that will solve all flaws or?
[15:46] <michaelni> no, its just a small easy thing to try
[15:47] <cehoyos> Correction: It is exactly one feature (changing sps on -codec copy), just for different FFmpeg versions
[15:47] <durandal_1707> guess, one more thing nobody volunters to do the _right_ thing
[15:50] <michaelni> btw if anyone has jpeg2000 files, some reference files excerzising various features and such, i would be interrested to have them so i can make sure my changes to j2k / jpeg2000 dont break anything
[15:55] <cone-853> ffmpeg.git 03Clément BSsch 07master:477f4efd0f1c: lavf/swf: remove unused assert include.
[16:01] <cone-853> ffmpeg.git 03Paul B Mahol 07master:e9c3851d6006: lavfi/bbox: use inlink->frame_count
[16:01] <cone-853> ffmpeg.git 03Paul B Mahol 07master:7aa99a69c7a4: lavfi/bbox: make min_val user configurable
[16:01] <cone-853> ffmpeg.git 03Paul B Mahol 07master:add8c63ce4dd: lavfi/bbox: timeline support
[16:01] <cone-853> ffmpeg.git 03Paul B Mahol 07master:c8e9c9275ff9: lavfi/bbox: export bbox info to frame metadata
[16:09] <durandal_1707> hmm, why script filter, couldn't existent parsing be extended for scripting?
[16:10] <durandal_1707> because the script filter would need to have own parsing, and nobody wants to play with that
[16:32] <saste_> durandal_1707, for a script filter, i mean a filter which loads and interprets a script written in X language
[16:32] <saste_> the script should contain callbacks for filter_frame(), init(), uninit() etc.
[17:01] <durandal_1707> couldn't get_unary() make use of bs(f/r) instruction?
[17:11] <kierank> michaelni: there is a j2k test suite on the itu website
[17:13] <michaelni> i probably have that already
[17:26] <BBB> michaelni: that change to ff_rtp_set_remote_url() ignores the port parameter, that's not right
[17:26] <BBB> but I'll leave to wbs, he knows that code better (or lu_zero maybe) - I understand rtsp quite well, but not rtp
[17:29] <michaelni> BBB, ok, thanks
[17:29] <michaelni> wbs, can you take a look at https://github.com/FFmpeg/FFmpeg/pull/22 ?
[17:47] <wbs> michaelni: yes, as BBB says, that commit is very much wrong. if that actually helps in some case, the caller is doing something very much wrong, because it would break every single rtsp case at least. that function is used for setting the peer hostname/port, but the change makes it ignore the port you set. so if the change helps, the caller shouldn't be calling the function at all. or alternatively, add logic to parse out ...
[17:47] <wbs> ... rtcp_port within that function just as it is done in rtp_open
[17:49] <michaelni> wbs, thanks alot, ill copy & paste that in a moment to github 
[18:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:5157ec89ef88: j2k: redesign vert_causal_ctx_csty implementation
[18:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:69b97739806f: j2k: s/getnbctxno/getsigctxno/g
[18:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:b67fe48f3418: jpeg2000/j2k: merge getsigctxno()
[18:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:e66faf71eb89: j2k: merge ff_j2k_init_tier1_luts()
[18:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:e708c7fa214d: j2k: drop disabled debug code
[18:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:da906617188a: j2k/jpeg2000: merge copyright
[18:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:ad194874ee35: j2k.h: Merges various cosmetics & unused defines
[18:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:5b4cad4a64eb: j2k.h: remove disabled debug code
[18:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:ac325f06130f: j2k.h: whitespace cosmetics
[18:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:b4013899e213: j2k: s/ff_j2k_getsigctxno/ff_jpeg2000_getsigctxno/g
[18:49] <cone-853> ffmpeg.git 03Clément BSsch 07master:b6ee25e30042: lavfi/lut3d: restore original interpolation speed.
[18:49] <cone-853> ffmpeg.git 03Clément BSsch 07master:56cea3294a7e: lavfi/lut3d: faster tetrahedral interpolation.
[19:52] <michaelni> does anyone have a recent version of the jpeg2000 spec ?
[19:52] <michaelni> the draft i have contains typos in some numbers so iam not sure what is correct
[19:53] <durandal_1707> what numbers?
[19:55] <michaelni> xcb+ycb <= 12 but xcb and ycb must be a minimum of 4 each
[19:55] <michaelni> and they are of the form 2^(2+...)
[19:57] <michaelni> so the limit is probably meant to be xcb*ycb <= 2^12 or the input before 2^ being a+b<=12
[19:57] <michaelni> but with the +2 in there its hard to guess what is the correct limit
[19:58] <durandal_1707> michaelni: you left two unused functions in j2k.c
[19:59] <michaelni> yes i know that was intended
[20:13] <durandal_1707> saste_: what mp you porting?
[20:13] <saste_> durandal_1707, mcdeint
[20:15] <durandal_1707> why PROGRSSIVE in vf_idet?
[20:20] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:5d67dfd71cfe: j2kdec: move avctx init to decode_frame
[20:20] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:bcf59b5d8f90: j2kdec: merge jpeg2000_init_static_data() from jpeg2000
[20:20] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:de90bd6c3fe4: j2k/jpeg2000: merge cosmetics and whitespace
[20:20] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:88d2dd00fe0c: avcodec/j2kdec: drop disabled debug code
[20:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:726eac1df96f: j2kdec: cosmetics from jpeg2000
[20:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:a2daf929edff: j2kdec: profile code from jpeg2000
[20:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:277691a130dc: j2kdec: merge copyright header with jpeg2000
[20:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:df3e6e5e227a: j2kdec: cosmetics from jpeg2000
[20:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:6e16321d665a: j2kdec: add AVClass
[20:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:874a06bd1f16: j2k: cosmetics from jpeg2000
[20:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:228ce3360607: j2k: add #includes from jpeg2000
[20:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:b01e61a47dd0: jpeg2000: cosmetics & restructuring from jpeg2000
[20:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:9ea242962c40: j2k: ff_j2k_tag_tree_init: check for integer overflow in alloc
[20:21] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:cb39dfb87009: j2k/jpeg2000: check cblk size
[21:35] <ubitux> random vp8 failure, nice.
[21:37] <Daemon404> BBB, ^
[21:38] Action: Daemon404 runs
[21:39] Action: durandal_1707 cosmic rays
[22:05] <saste_> ubitux, i'm reviewing hald clut stuff
[22:05] <ubitux> saste_: oh, thanks :)
[22:34] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:bd89b2b22ac7: j2k/jpeg2000: log2_prec size cleanup
[22:41] <cone-853> ffmpeg.git 03Clément BSsch 07master:b439ece51cbf: lavfi/dctdnoiz: move DC normalization out of loops.
[22:48] <ubitux> i wonder if i could avoid the double normalization for each
[22:49] <ubitux> this is way ahead my level of math unfortunately :(
[22:49] <Daemon404> i... totally misread "double normalization"
[22:50] <ubitux> in the dct and idct function, i'm doing the normalization two times
[22:50] <ubitux> one for lines, and one for columns
[22:50] <ubitux> i wonder if it's possible to make it only once
[22:51] <Daemon404> i find most 'math' is far less complicated when you implement it
[22:52] <Daemon404> but staring at formulas makes me assume the fetal position
[22:58] <durandal_1707> ubitux: have you found the source of most slowdown?
[22:59] <ubitux> dct/idct
[23:00] <ubitux> it's running it 16x16 *dct for each pixel (if you don't play with overlap
[23:00] <ubitux> so... it's kind of slow
[23:00] <ubitux> BBB suggested to import the 2d dct code from libvpx
[23:00] <ubitux> but... lazy me is lazy, and i've more important things in progress
[23:01] <ubitux> oh, a new patchset from marton, cool
[23:01] <durandal_1707> saste_: thing is filters like idet, do not need request code (and flag) at all, as it keeps reference of frame when it's filter_frame return nothing
[23:02] <durandal_1707> omg, 51 machines dissapeared in oblivion
[23:23] <durandal_1707> http://forum.doom9.org/showthread.php?t=167947
[23:30] <Compn> hmm
[23:30] <Compn> why people like 4k trailers? :P
[23:30] <Compn> eheh
[23:35] <cehoyos> durandal_1707: bitexact wrt reference decoder
[23:38] <durandal_1707> but user reported artifacts
[23:39] <durandal_1707> cehoyos: because they do not like vga trailers
[23:39] <cehoyos> typo?
[23:40] <durandal_1707> what typo? thers mny tpos
[23:40] <cehoyos> I tested the small trailer, downloading 4k now (I don't find it obvious which one he meant)
[23:40] <cehoyos> (I wasn't the one asking why people like 4k trailer, the new nvidia drivers support 4k hardware decoding)
[23:41] <durandal_1707> ahh, it was rhetoric one
[23:44] <Compn> new vidia supports 4k ? 
[23:44] <Compn> cool
[23:44] <durandal_1707> you have monitor that big?
[23:44] <Compn> no
[23:45] <Compn> i dont even have cpu that can handle it
[23:45] <Compn> i guess if i had bigger monitors i could put two big monitors together ...
[23:45] <Compn> with my dual hdmi card
[23:45] <Compn> ati radeon 5830
[23:47] <cehoyos> You can handle it with any CPU allowing PCIe
[23:47] <cehoyos> durandal_1707: Bug reproduced, will open a ticket
[23:47] <BBB> vp8 race condition?
[23:47] <BBB> that would suck, I thought I had removed them all
[23:48] <Compn> HDMI 1.4 increases the maximum resolution to 4K × 2K, i.e. 3840 × 2160p (Quad HD) at 24 Hz/25 Hz/30 Hz or 4096 × 2160p at 24 Hz (which is a resolution used with digital theaters)
[23:48] <ubitux> BBB: http://fate.ffmpeg.org/report.cgi?time=20130526192401&slot=x86_64-archlinux-gcc-threads-2
[23:48] <Compn> i'd have to get a quad-hd video card
[23:49] <BBB> fuck fuck fuck
[23:49] <BBB> ok I'll check tue
[23:50] <cehoyos> Compn: Such resolutions work fine with VGA
[23:52] <ubitux> wow the output of helgrind really is violent
[23:52] Action: ubitux looking at that test in http://fate.ffmpeg.org/report.cgi?time=20130526180913&slot=x86_64-archlinux-gcc-valgrind-threads
[23:53] <ubitux> not a good idea :)
[23:53] <durandal_1707> why everybody ignores helgrind?
[23:53] <ubitux> it is said that "it's useful" or "it's wrong"
[23:54] <ubitux> i can't tell if it's justified or not, but helgrind is definitely not happy :p
[23:54] <ubitux> "it's useless*"
[23:54] <BBB> durandal_1707: the amount of times where a problem reported by helgrind actually correlates to an actually exploitable condition - such as a crash, random write/read, etc. - is surprisingly low
[23:55] <BBB> durandal_1707: it's like running ffmpeg under a sleeping baby checker where there's a random() condition somewhere and each time it triggers - randomly - the baby checker will say "your application woke up the baby, fix it"
[23:55] <BBB> durandal_1707: it's not useful, because it's random, and nobody cares that the baby woke up
[23:55] <BBB> durandal_1707: if it was exploitable, it'd be something, but it isn't
[23:56] <durandal_1707> so its randomgrid
[23:58] <cone-853> ffmpeg.git 03Paul B Mahol 07master:e5c7bafb4444: libtwolame: add forgotten calls
[00:00] --- Mon May 27 2013