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

[burek]

[00:08:21 CET] <kierank> debianuser: probably some full_chroma_imp flag you need
[00:08:22 CET] <kierank> or similar
[01:06:22 CET] <Daemon404> ... and yet not tested under perf to see if its even swscale which is bottlenecking.
[01:09:35 CET] <kierank> true
[01:24:33 CET] <debianuser> Daemon404: tested with vallgrind --tool=callgrind :) That's how I found that most time is spent in hScale16To15_c() func :)
[01:25:12 CET] <debianuser> Is there another way to find that out?
[01:26:36 CET] <debianuser> I mean is there another way to find where's the bottleneck?
[01:29:37 CET] <Daemon404> im wondering why its calling all these _c funcs instead of asm
[01:46:52 CET] <cone-618> ffmpeg 03Florian Jacob 07master:c5c4ca6bc881: lavf/libssh: support reading config from ~/.ssh/config
[01:50:15 CET] <debianuser> Daemon404: ah, i built it with --disable-yasm :) It should still be much faster, the first C implementation I found is like 5 times faster, and ffmpeg has it in ff_rgb24toyv12_c() func, it's just not using it in my case...
[01:53:19 CET] <debianuser> Basically anyone can reproduce that problem on linux: compare fps of `ffmpeg -f x11grab -r 60 -s 1280x1024 -i :0 -t 30 -f null -` and `ffmpeg -f x11grab -r 60 -s 1280x1024 -i :0 -vf format=yuv420p -t 30 -f null -` (not sure if it happens for windows, it probably does if "dshow" returns rgb too)
[02:02:54 CET] <cone-618> ffmpeg 03Christophe Gisquet 07master:2e5605f6fa0a: x86: Makefile: fix DBG parameter evaluation
[02:25:04 CET] <BBB> debianuser: why on earth would you compile with --disable-yasm
[02:29:41 CET] <debianuser> BBB: Two reasons: I don't have yasm installed :) and I want to find what makes rgb->yuv420p conversion limited to 40fps when the first C-based implementation I found does ~180fps (http://pastebin.com/2ZAR1kst).
[02:31:08 CET] <debianuser> (note: official static ffmpeg build, the one with yasm enabled, is ~40fps, naive C-based converter is ~180fps)
[02:33:09 CET] <BBB>     /* bgr24toYV12 */
[02:33:10 CET] <BBB>     if (srcFormat == AV_PIX_FMT_BGR24 &&
[02:33:11 CET] <BBB>         (dstFormat == AV_PIX_FMT_YUV420P || dstFormat == AV_PIX_FMT_YUVA420P) &&
[02:33:12 CET] <BBB>         !(flags & SWS_ACCURATE_RND))
[02:33:13 CET] <BBB>         c->swscale = bgr24ToYv12Wrapper;
[02:33:20 CET] <BBB> it sounds like the accurate_rnd flag is set
[02:33:37 CET] <BBB> or the format is inverted rgb instead of bgr
[02:36:42 CET] <BBB>     av_log(ctx, AV_LOG_VERBOSE, "w:%s h:%s flags:'%s' interl:%d\n",
[02:36:43 CET] <BBB>            scale->w_expr, scale->h_expr, (char *)av_x_if_null(scale->flags_str, ""), scale->interlaced);
[02:36:52 CET] <BBB> that log message should be able to tell you what flags are set by default
[02:36:57 CET] <BBB> (-v verbose or -v debug)
[02:37:02 CET] <BBB>  the scale filter
[02:37:12 CET] <debianuser> BBB: Maybe... Here's the debug ffmpeg output: http://pastebin.com/xsSXsmHS Is it somehow noticeable whether SWS_ACCURATE_RND is set in that output?
[02:38:13 CET] <BBB> [auto-inserted scaler 0 @ 0xbd86140] w:1280 h:1024 fmt:bgr0 sar:0/1 -> w:1280 h:1024 fmt:yuv420p sar:0/1 flags:0x4
[02:38:27 CET] <BBB> I wonder what bgr0 is
[02:38:34 CET] <BBB> maybe thats why it doesnt choose that special converter
[02:39:38 CET] <BBB> I think itd help if you could somehow capture to rgb (24bpp) instead of bgr0 (32bpp)
[02:40:09 CET] <BBB> flags=0x4 is bicubic scaling, so nothing special there
[02:40:58 CET] <BBB> yeah, we dont handle bgr0 anywhere in swscale, so it chooses the most generic codepath
[02:41:00 CET] <BBB> which is super-slow
[02:41:11 CET] <BBB> if you can somehow capture 24bpp thatll probably solve your issue
[02:42:02 CET] <debianuser> How can I select different format for x11grab? `... -f x11grab -pix_fmt rgb -r 60 -s 1280x1024 -i :0 ...` gives error "Option pixel_format not found."
[02:43:56 CET] <BBB> you could try an intermediate
[02:44:00 CET] <BBB> although thats not ideal
[02:44:24 CET] <BBB> .. -f x11grab -r .. -s .. -i .. -vf format=rgb24,format=yuv420p
[02:44:49 CET] <BBB> then at least it should use special-case functions
[02:45:51 CET] <debianuser> No, I mean I see av_log(s, AV_LOG_DEBUG, "Image r 0x%.6lx g 0x%.6lx b 0x%.6lx and depth %i\n", ... AV_PIX_FMT_RGB24 later in https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/x11grab.c, I just don't see "Image r ..." in log and not sure how to make it select different format...
[02:47:18 CET] <BBB> yeah neither do I
[02:47:24 CET] <BBB> Im not very familiar with x11grab
[02:54:47 CET] <debianuser> BBB: "-vf format=rgb24,format=yuv420p" is actually slower :) http://pastebin.com/JfZ6g0kK - 30fps instead of 40.
[03:00:10 CET] <debianuser> Ah, it has no logs because it's actually xcbgrab, not x11grab, and xcbgrab.c has no logs in the same function... 
[03:11:50 CET] <jamrial> maybe the two of them shouldn't share the .name value of "x11grab"
[03:19:11 CET] <debianuser> Just rebuilt ffmpeg with --disable-libxcb --enable-x11grab and now I see "Image r 0xff0000 g 0x00ff00 b 0x0000ff and depth 32" so it should be AV_PIX_FMT_0RGB32
[03:23:47 CET] <BBB> debianuser: well, then I guess I dont know; I think it makes sense to open a bug report or so to be able to handle bgr0 in swscale
[03:23:52 CET] <BBB> but I guess right now it doesn't
[03:27:32 CET] <debianuser> I'm trying to reproduce the XGetImage() code path... It seems that it requests AllPlanes, ZPixmap which should always return 32 bit. I'm trying to check what happens if I do 0x00ffffff,XYPixmap...
[04:28:29 CET] <debianuser> Nope, it seems that won't work that easily... XYPixmap returns bitplans, not pixels... Ok, plan b: copypaste bgr24ToYv12Wrapper into bgr32ToYv12Wrapper ("6*"->"8*", "+[345]"->"+[456]") and see what happens...
[04:53:18 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:1932f7e2eee0: avcodec/mpeg12dec: Fix undefined shift
[05:40:47 CET] <debianuser> That worked. Partially. C implementation of bgr32ToYv12Wrapper gives 50fps (which is still not 60fps, but better than 40fps asm or 20fps generic C swscale).
[05:56:41 CET] <jamrial> well, that's an interesting libpostproc patch...
[06:35:58 CET] <debianuser> In case someone wants to reproduce the slowness or look at the "patch": http://pastebin.com/zsePueme maybe someone can get 60fps from that...
[06:39:16 CET] <jamrial> consider sending that to the ml. it may get more attention that way
[06:49:08 CET] <debianuser> It's still too slow somewhy. The same function extracted into a tiny C program works 3 times faster. There must be something else that I miss.
[06:57:33 CET] <rcombs> debianuser: try saving a raw capture and doing your perf tests based on that
[07:05:42 CET] <debianuser> You mean rawvideo? Hm... that would be ~9 gigabytes, 300MBytes/sec, don't think my disk is that fast. :) It's actually easy for me to do x11grab because it takes just a few %CPU (`ffmpeg -f x11grab -r 60 -s 1280x1024 -i :0 -f null -` is fast)
[07:16:58 CET] <rcombs> debianuser: then just encode something that supports your source pix_ft
[07:17:14 CET] <rcombs> not necessarily rawvideo, just unscaled
[07:17:32 CET] <rcombs> to keep the steps separated in your perf tests
[09:17:52 CET] <ninten> hi i am having a problem in masked lz decompression anyone has any idea about it !!
[09:31:00 CET] <himangi> kierank: ping
[10:42:26 CET] <ubitux> can someone less ffmpeg related suggest luca to port aevalsrc or sine filters instead of this "atestsrc"?
[11:33:27 CET] <kierank> himangi: pong
[12:12:23 CET] <nevcairiel> Am I the only one that feels a "simple" ivtc filter is just redundant in avfilter?
[12:13:38 CET] <pross> elaborate?
[12:14:17 CET] <nevcairiel> whats the point of a "dumb" filter that expects perfect pristine input, when we already have one that can deal with perfect and imperfect input alike? :d
[12:27:41 CET] <wm4> libavformat/libssh.c
[12:27:44 CET] <wm4> this... exists?
[12:35:21 CET] <himangi> nevcairiel: one reason I can site is we need two filters as pullup is generally followed by dejudder and fieldmatch by decimate.. the already existing filters have a number of options which can make them difficult to understand/use.. they could be overwork when we have a pure telecined stream
[12:41:11 CET] <nevcairiel> so your argument is that its too hard to use? :d
[13:23:17 CET] <poste9> how can I know the dts ? pts I understand... but how can I know if my dts has to be greater or lower than my pts ?
[13:24:42 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:e5dfa4361955: avcodec/vc1_pred: Fix undefined shift in ff_vc1_pred_mv()
[13:26:10 CET] <BtbN> you can't present a picture before it has been decoded, so dts>pts makes no sense.
[13:28:01 CET] <poste9> badun tss
[13:35:09 CET] <himangi> nevcairiel: does that help answer your question?
[13:39:18 CET] <wm4> poste9: in what context?
[13:40:18 CET] <poste9> setting pts and dts after decode/scale to encode and save to file
[13:41:27 CET] <wm4> dts and pts use the same values, they're just in different order
[13:41:55 CET] <wm4> and the decoder/encoder have to do the reordering
[13:42:07 CET] <wm4> so I'd expect that an encoder simply takes a pts
[13:43:59 CET] <nevcairiel> after decoding, ie. on raw frames, dts and pts should be the same
[13:44:12 CET] <nevcairiel> but yeah, only set AVFrame->pts iirc
[13:44:38 CET] <nevcairiel> then put through encoder, and it should set AVPacket->pts and dts
[14:17:32 CET] <poste9> is there a problem copying the time base of input stream and output_frame.pts = input_pkt.pts - start_time;  before encode?
[14:17:50 CET] <poste9> its working fine here but Im afraid its gonna break sometime or something like that
[14:18:09 CET] <poste9> because I spent like 2 months trying to figure out this whole pts/dts thing and now it  looks stupid.
[14:52:07 CET] <poste9> is there a way to find out if the av_log output is from the encoder or decoder?
[14:52:31 CET] <Daemon404> ?
[14:52:36 CET] <Daemon404> av_log is always passed a context
[14:52:50 CET] <Daemon404> thats why yo usee e.g. [libx264 @ 0x<...>] Log stuff
[14:56:06 CET] <shubham04> @durandal I am intrested in the APNG project..
[14:59:40 CET] <shubham04> how should I go about exploring the topic?
[14:59:58 CET] <durandal_1707> shubham04: qualification task for you is to implement support for yuv colorspace in exr codec
[15:01:22 CET] <durandal_1707> shubham04: look at libavcodec/exr.c OpenEXR specification and samples
[15:02:55 CET] <shubham04> ok thanks 
[15:07:55 CET] <wm4> <Daemon404> av_log is always passed a context <- except when it's not
[15:08:33 CET] <Daemon404> those are tahnkfully rare
[15:08:53 CET] <ubitux> only ~1k times
[15:09:43 CET] <Daemon404> looks like 10%
[15:09:46 CET] <Daemon404> lolwoops
[15:22:44 CET] <poste9> I will share my test file its kinda good for beginners but I still have a doubt before doing it... Im droping frames when I receive a packet from the input with pts lower than the last one (I dont know why but Im getting a lot)
[15:22:56 CET] <poste9> is it a bad idea?
[15:26:41 CET] <poste9> I think the right question is... what to do when last_input_pts > current_input_pts ?
[15:32:10 CET] <Mavrik> well, depending on source
[15:32:18 CET] <Mavrik> You can try reordering them if it's a network source.
[15:32:24 CET] <Mavrik> Then you can have wraparound as well :)
[15:32:40 CET] <Daemon404> that would be a problem for teh demuxer or api layer i would think.
[15:35:18 CET] <poste9> input = camera, output = file
[15:35:50 CET] <poste9> but dropping frames doesnt look a nice thing to do
[15:36:57 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:bd4c4c868c37: avcodec/wma: Fix undefined shift in ff_wma_run_level_decode()
[15:37:12 CET] <Daemon404> not sure why a camera would produce nonmonotonic pts
[15:38:25 CET] <kierank> because it's a crap camera
[15:38:31 CET] <kierank> or the driver/library is crap
[15:38:34 CET] <kierank> or there's wraparound
[15:42:23 CET] <ubitux> ./ffmpeg -f lavfi -i "color=s=16x16,geq=r='bitand(trunc(N/256),15)*17':g='bitand(trunc(N/16),15)*17':b='bitand(N,15)*17'" -c:v libx264rgb -pix_fmt rgb24 -qp 0 -y -frames:v 4096 rgb4096.mkv
[15:42:26 CET] <ubitux> command of the day
[15:42:30 CET] <ubitux> hopefully correct..
[15:49:48 CET] <kierank> wtf two DCA patches
[15:49:54 CET] <kierank> I feel really bad for that guy
[15:51:03 CET] <j-b> yes
[15:51:08 CET] <j-b> especially since Niels is really good
[15:51:20 CET] <nevcairiel> better would be actually finishing it
[15:51:35 CET] <kierank> yeah but the spacing isn't correct nevcairiel 
[15:51:36 CET] <nevcairiel> no good being really good but not having time =P
[15:51:40 CET] <kierank> that's a blocking factor
[15:52:14 CET] <Daemon404> well also
[15:52:20 CET] <Daemon404> the guy who just mailed did a bad thing
[15:52:28 CET] <Daemon404> toilign away in an ivory tower and dumpign it all at once
[15:52:30 CET] <Daemon404> out of nowhere
[15:52:37 CET] <kierank> that's not true
[15:52:39 CET] <kierank> he's mailed before
[15:52:41 CET] <Daemon404> oh?
[15:52:44 CET] <Daemon404> i must have missed it.
[15:52:54 CET] <nevcairiel> the decoder has some broken things in it still and i would probably disable the xll decoding by default in my code until those are sorted out, but until its merged i cba to try to fix them
[15:53:36 CET] <j-b> which broken things?
[15:54:32 CET] <nevcairiel> i forget, i made some notes somewhere, and i'll probably try to fix some of those myself when its in
[16:03:07 CET] <wm4> so now there are 3 people working on separate dts implementations
[16:04:10 CET] <kierank> 3?
[16:05:24 CET] <wm4> there is also a first party implementation in D, not finished yet
[16:07:46 CET] <kierank> ah that one
[16:08:09 CET] <poste9> so... here it is... I hope someone learn something from my code but I would appreciate if someone could give some improvement tips about this code. http://stackoverflow.com/questions/28990247/what-to-do-when-last-pts-current-pts-using-ffmpeg-libs-c
[16:09:37 CET] <nevcairiel> you shouldn't use the pkt pts for timing your frames
[16:09:47 CET] <nevcairiel> you should use the info in the resulting AVFrame
[16:10:15 CET] <nevcairiel> ie. tmp_frame.pkt_pts and tmp_frame.pkt_dts
[16:10:37 CET] <nevcairiel> in the frame, the pts will be re-ordered appropriately, in the packet, the pts are out of order
[16:11:48 CET] <poste9> omg is that it? thank you!
[16:20:49 CET] <poste9> yeah but its not.. :/
[16:21:22 CET] <poste9> im  getting pkt_in.pts equals to tmp_frame.pkt_pts always
[16:22:44 CET] <nevcairiel> your source is v4l? maybe the driver is just broken then
[16:22:51 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:fa74058dd364: swscale/utils: Fix undefined shift in initFilter()
[16:23:23 CET] <poste9> pls dont encourage me to look into the v4l2 code 
[16:26:27 CET] <poste9> looks like it: https://trac.ffmpeg.org/ticket/634
[16:29:07 CET] <poste9> it really looks like the decoded frame can be P or B, is it possible?
[16:41:18 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:8c7a0932abee: avcodec/amrnbde: Fix undefined shift in decode_pitch_vector()
[16:52:07 CET] <yingming> Hi,all. I'm a student of Peking University. I'am looking for GSoC project idea. Is there any TODO features for FFmpeg hevc decoder?
[16:52:41 CET] <Daemon404> mostly asm optimizations
[16:54:54 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:8617bc6ffaa8: avcodec/golomb: Fix undefined shifts in unsigned rice decoding code
[17:03:49 CET] <yingming> Thank you for your reply, daemon404. I wrote some intrinsic SSE instructions before. Can asm optimizations for hevc decoder as my GSoC project?
[17:08:16 CET] <kierank> we don't use intrinsics but yes
[17:08:27 CET] <kierank> you need to do the qualification task
[17:08:46 CET] <nevcairiel> we currently dont have a mentor for such a project though
[17:12:59 CET] <Daemon404> yeah.
[17:15:52 CET] <yingming> Thank you, kierank and nevcairiel. I want try those asm optimization task. Can anyone be my mentor and guide me?
[17:23:24 CET] <myra> Hi, I am trying to compile pngenc.c which requires zlib.h . I have already installed zlib1g and zlib1g-dev (libs from ubuntu repo). Yet I get errors like "undefined reference to crc32" and "undefined reference to deflate". Is there any other library that I am missing ? Is this error related to zlib ? Can somebody help me with this. 
[17:42:24 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:9b2a964ceeab: avcodec/vp8: Fix undefined shifts in vp8_mc_luma()
[18:00:50 CET] <kurosu_> yingming, I'm concerned what we now miss is only inverse transforms, and they are very difficult to implement
[18:01:11 CET] <kurosu_> I'd say they are a difficult task for a gsoc
[18:01:57 CET] <kurosu_> unfortunately, one of the complexities is not having enough registers, and heavily relying on the stack, something you probably didn't look at when doing intrinsics
[18:03:11 CET] <kurosu_> I heard people were interested in having asm for other stuff, but unfortunately, I don't think they will volunteer for mentoring
[18:03:29 CET] <kurosu_> *hevc inverse transforms
[18:04:13 CET] <nevcairiel> yeah, freaking idcts
[18:04:37 CET] <nevcairiel> could build the intrapred stuff, but the speed advantage for that is minimal at best
[18:06:20 CET] <kurosu_> I have locally 4x4 and 8x8, but I'm not daring looking at anything above
[18:07:41 CET] <kurosu_> plus, >=16x16 are critical for speed, so we probably want someone really really good looking at it
[18:08:57 CET] <nevcairiel> bigger sizes so much more complicated?
[18:10:31 CET] <kurosu_> it's all like convolution, but you need a clear plan how you are going to decompose it (butterflies and the like) and deal with the subparts
[18:10:55 CET] <kurosu_> look at the openhevc code, for instance
[18:16:06 CET] <llllll> Hi everyone 
[18:16:33 CET] <yingming> Thank you for your reply, kurosu_.
[18:16:43 CET] <llllll> I am new here. Trying to be a student for Google Summer of Code
[18:18:04 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:2391e46430fa: avcodec/mpegvideo: Fix undefined shift in ff_mpv_lowest_referenced_row()
[18:20:42 CET] <yingming> It's already very late on my time zone. Bye, everyone.
[18:25:46 CET] <llllll> I am interested in working on the ALS encoder
[18:29:01 CET] <jamrial> llllll: i don't think thilo (the project mentor) is here, so send him an email so he can get you started on your qualification task
[18:31:44 CET] <llllll> ok I already did. Thanks
[18:34:43 CET] <Daemon404> i really think mentors should be required to be on irc sometimes.
[18:59:05 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:c756b3fca240: avcodec/h264dsp_template: Fix undefined shift in biweight_h264_pixels and weight_h264_pixels
[19:37:51 CET] <poste9> hey -tune zerolatency is for avformat_open_input or avcodec_open2 ?
[19:50:28 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:fd4e17fcc2b6: avcodec/mpegvideo_motion: Fix undefined shifts in mpeg_motion_internal()
[19:52:08 CET] <ubitux> > third do something evil and let the user pass an expression
[19:52:10 CET] <ubitux> damn
[19:52:17 CET] <ubitux> they really do plan to rewrite aevalsrc
[19:52:24 CET] <ubitux> please someone stops them
[19:52:25 CET] <ubitux> :(
[19:53:42 CET] <ubitux> nevcairiel e
[19:53:45 CET] <gb27> anyone who worked on exr.c file and its compression techniques
[19:59:18 CET] <cone-005> ffmpeg 03Hendrik Leppkes 07master:f36f6a608b5b: mlpdec: support major sync headers with optional extension blocks
[19:59:19 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:7cc63c4bbc72: Merge commit 'f36f6a608b5b2c17f8876195c61621c8f8607cee'
[20:02:02 CET] <jamrial> ubitux: hopefully this time they will not find a reason as to why it's not "good enough", but ultimately porting it with a different name and with other subtle changes to make it different, inconveniencing api users in the process
[20:02:07 CET] <jamrial> sort of like it happened with swresample
[20:04:16 CET] <wm4> I still don't know what happened there
[20:04:45 CET] <wm4> but I know that ffmpeg inconvenienced the API users by not enabling lavr by default
[20:06:39 CET] <cone-005> ffmpeg 03Hendrik Leppkes 07master:dc2d0e06af45: mlpdec: support TrueHD streams with an Atmos substream
[20:06:40 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:f3a35e9d599f: Merge commit 'dc2d0e06af459af9a7f91b65e0a3119acc4f1baa'
[20:10:08 CET] <jamrial> wm4: how does a configure option being enabled or disabled inconvenience api users?
[20:10:27 CET] <ubitux> jamrial: distro
[20:10:35 CET] <jamrial> every distro that ships both projects is enabling it
[20:10:54 CET] <ubitux> now yes probably
[20:14:04 CET] <jamrial> ever since the first libav version to feature avr, afaik
[20:14:47 CET] <jamrial> but for john doe compiling ffmpeg for his project having "./configure && make" building two resampling libraries is pointless
[20:15:19 CET] <klaxa> i'm trying to implement my qualification task for gsoc which is writing a proof-of-concept http server, but i'm somewhat at a loss as to where i have to insert my code. when i specify an http output where do i catch that and create server sockets and so on
[20:15:53 CET] <klaxa> i've run ffmpeg in ddd a lot and i'm still not quite sure where i have to start
[20:16:37 CET] <cone-005> ffmpeg 03Vittorio Giovara 07master:9272c965d955: matroskaenc: Fix type used for chapter timestamps
[20:16:38 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:e48ff13ba722: Merge commit '9272c965d9559a90ee64d46aebd99c117e07f7a3'
[20:18:54 CET] <wm4> jamrial: API disabled by default -> it's basically unavailable
[20:23:07 CET] <gb27> anyone who worked on exr.c file and its compression techniques
[20:25:51 CET] <jamrial> bullcrap. especially when said API is basically a must to have a programs working with both projects
[20:27:10 CET] <wm4> <jamrial> every distro that ships both projects is enabling it <- and yet ffmpeg refuses to enable it by default... _this_ is bullcrap
[20:27:22 CET] <Compn> gb27 : do a git blame and find those exr.c authors
[20:28:04 CET] <jamrial> <jamrial> but for john doe compiling ffmpeg for his project having "./configure && make" building two resampling libraries is pointless <- and what about this?
[20:29:07 CET] <cone-005> ffmpeg 03Vittorio Giovara 07master:fe99c52fa99e: mp3: Properly use AVCodecContext API
[20:29:08 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:2d37c57f3e9d: Merge commit 'fe99c52fa99e44961a09cd1324aefd492b797fc8'
[20:29:08 CET] <wm4> it's not pointless... it's important for compatibility
[20:29:38 CET] <jamrial> ffmpeg ships two resample libraries. one maintained and developed by the project itself, and another shipped for compatability's sake. if the user requires compatability with libav then he will enable the other library
[20:30:12 CET] <jamrial> if the user doesn't care about compatability, why would you then have the build system compile two resample libraries by default?
[20:31:05 CET] <wm4> why do you enable all those dozens of deprecated APIs by default if it's only for compatibility? like the libavcodec resampler
[20:32:59 CET] <jamrial> i don't know. they could be disabled as well, unless there's another reason to keep them enabled by default
[20:34:20 CET] <wm4> if I sent such a patch, it'd probably be silently ignored
[20:34:40 CET] <wm4> or rejected because mplayer uses it
[20:36:42 CET] <jamrial> that's IMO no reason to reject disabling it. but i can see people complaining about broken scripts
[20:37:38 CET] <cone-005> ffmpeg 03Vittorio Giovara 07master:bacc92b59bfa: rtpdec_vp9: Drop extra sanity check for size of input packet
[20:37:39 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:693b8f11d7fd: Merge commit 'bacc92b59bfa5d6a1f631e63e46fc1d2fb934e51'
[20:49:23 CET] <rcombs> klaxa: the TLS protocol (libavformat/tls.c) supports listening as a server instead of a client; might want to use that as an example
[20:49:48 CET] <klaxa> thanks! i will have a look
[20:50:03 CET] <rcombs> klaxa: if you want to act like that (single protocol with a "listen" arg), your code would probably go in http.c
[20:50:28 CET] <rcombs> klaxa: but it may or may not make more sense to have a separate protocol, which may or may not make more sense in a separate file
[20:51:02 CET] <klaxa> okay, i wrote an email to nicolas george a few minutes ago, also because he is the mentor for the project
[20:51:46 CET] <rcombs> then there's a high chance he knows more about this than me!
[20:52:08 CET] <cone-005> ffmpeg 03Vittorio Giovara 07master:7a76c6c4df31: configure: Enable colored output for gcc 4.9+
[20:52:09 CET] <cone-005> ffmpeg 03Michael Niedermayer 07master:2ba0ef4b15cc: Merge commit '7a76c6c4df31d1ff65464ccf3171acd57ef004eb'
[21:26:56 CET] <Fyr> guys, I recently asked about adding the most important libraries (x264, FDKAAC) into ffmpeg distribution and got the answer that it's not possible due to the license issue. now I know the solution - port all functionality of the mentioned libraries into master branch. is it diffcult?
[21:27:00 CET] <cone-005> ffmpeg 03Mans Rullgard 07release/0.10:6dd19ffd39ba: arm: dsputil: fix overreads in put/avg_pixels functions
[21:27:01 CET] <cone-005> ffmpeg 03Mans Rullgard 07release/0.10:9fa9d471a7af: arm: dsputil: prettify some conditional instructions in put_pixels macros
[21:27:02 CET] <cone-005> ffmpeg 03Mans Rullgard 07release/0.10:8152b02f33a7: arm/neon: dsputil: use correct size specifiers on vld1/vst1
[21:27:03 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:78518fb92840: Merge commit '6dd19ffd39babd651744082301d133264a30882c' into release/0.10
[21:27:04 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:6a28ae55c4fe: Merge commit '9fa9d471a7af57a62843fdae0dc36e67960c3f3d' into release/0.10
[21:27:05 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:2a4d9b9af09c: Merge commit '8152b02f33a7b939cb2c9a5f26d10cd10465d4f9' into release/0.10
[21:30:05 CET] <nevcairiel> Fyr: thats impossible
[21:30:11 CET] <Fyr> =(
[21:30:29 CET] <nevcairiel> also, you can add x264,  its GPL
[21:34:50 CET] <wm4> aren't the glorious AAC patches being merged? and aren't they supposed on par or even better than FDK?
[21:35:04 CET] <nevcairiel> its still worse
[21:35:17 CET] <nevcairiel> fdk-aac has magic psy
[21:36:07 CET] <wm4> obviously the solution is using opus instead
[21:36:44 CET] <Fyr> could be good, but my devices don't play it.
[21:37:04 CET] <cone-005> ffmpeg 03Aaron Colwell 07release/0.10:57c36de72657: vp8: avoid race condition on segment map.
[21:37:05 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:90a2359fef53: nutdec: Remove unused and broken debug function stub
[21:37:06 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:3832db122399: Merge commit '57c36de7265761dd94fb6bb4a9180011f796128f' into release/0.10
[21:37:07 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:60190d8612d1: Merge commit '90a2359fef5325f90aec0eca51b145d90ca3df7d' into release/0.10
[21:37:35 CET] <Fyr> the world would be a better place if all devices could play opus.
[21:39:15 CET] <ubitux> nevcairiel: here you have your excuse :D
[21:39:18 CET] <jamrial> maybe someone can convince apple to adopt opus for their future audio endeavors. adoption would skyrocket
[21:39:28 CET] <nevcairiel> ubitux: i didnt actually understand what he said
[21:39:37 CET] <ubitux> nevcairiel: "fuck you"
[21:43:34 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:233d1b4861e2: h264_refs: Fix debug tprintf argument types
[21:43:35 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:ce57531a8894: swscale: Remove two bogus asserts
[21:43:36 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:9858a723cbcb: elbg: Fix an assert
[21:43:37 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:c9a38ffe2ff5: Merge commit '233d1b4861e252cbc4571840e7f264e1db151c13' into release/0.10
[21:43:38 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:99ba7ee0eba5: Merge commit 'ce57531a8894d69e3da085c7c6cba45b1f133b35' into release/0.10
[21:43:39 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:9d945898523b: Merge commit '9858a723cbcb206287fd0232d74c6a0991eecdc8' into release/0.10
[21:49:58 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:d1c490448cbe: mpegvideo: remove last_picture_ptr / h264 assert.
[21:49:59 CET] <cone-005> ffmpeg 03Martin Storsjö 07release/0.10:372f742dd189: parser: Don't use pc as context for av_dlog
[21:50:00 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:ec0df23765bd: h264: Remove an assert on current_picture_ptr being null
[21:50:01 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:6c76f3dfaabd: Merge commit 'd1c490448cbe3f7715773c673e92139a7192326f' into release/0.10
[21:50:02 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:240d7a7fc209: Merge commit '372f742dd18911dc5c6552b1bb2e2ca235c5ee47' into release/0.10
[21:50:03 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:7801f3e509ac: Merge commit 'ec0df23765bd41846f66e4a4fb694779b432fc62' into release/0.10
[21:52:34 CET] <wm4> "whats important is a patchset based on and tested on FFmpeg, at least if people want a working decoder in FFmpeg"
[21:52:45 CET] <wm4> but the Libav decoder patches will be merged anyway
[21:52:45 CET] <wm4> lol
[21:54:45 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:3eed35addb46: svq1enc: Set picture_structure correctly
[21:54:46 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:2deac60a3874: adpcmenc: Calculate the IMA_QT predictor without overflow
[21:54:47 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:554fd5cd6300: ffmpeg: Clarify wording of ffmpeg --> avconv deprecation message
[21:54:48 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:82c8abb34f13: Merge commit '3eed35addb461c42471e0367bb6cd68d8ffd3aec' into release/0.10
[21:54:49 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:35e88167eaed: Merge commit '2deac60a387409dcbc7b37a8c30de89c7aeb58ac' into release/0.10
[21:54:50 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:8e37603ac961: Merge commit '554fd5cd630073b8273aa044a6bdfd6f608209e9' into release/0.10
[21:55:02 CET] <Fyr> guys, the NVENC license says that it can be distributed and changed with permission of NVIDIA. can ffmpeg ask that permission and add the code into master branch?
[21:55:03 CET] <rcombs> >still maintaining 0.10
[21:55:53 CET] <rcombs> Fyr: that doesn't sounds GPL-compatible to me
[21:58:34 CET] <kierank> 8:52 PM <"wm4> "whats important is a patchset based on and tested on FFmpeg, at least if people want a working decoder in FFmpeg"
[21:58:34 CET] <kierank> 8:52 PM <"wm4> but the Libav decoder patches will be merged anyway
[21:58:34 CET] <kierank> 8:52 PM <"wm4> lol
[21:58:35 CET] <kierank> exactly
[21:59:05 CET] <wm4> just encouraging some NIH to get an edge over Libav...
[21:59:11 CET] <wm4> (sure is classy)
[21:59:14 CET] <kierank> such leadership
[22:02:50 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:f661006f235f: doc: Fix syntax and logical errors in avconv stream combination example
[22:02:51 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:e9e7646379f9: Update Changelog for v0.8.15
[22:02:52 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:992da6b76c61: Prepare for 0.8.16 release
[22:02:53 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:c6af9e944ebe: Update Changelog for v0.8.16
[22:02:54 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:9ba0719244bf: Merge commit 'f661006f235fa58bc756610cdc76c662ac0fab5f' into release/0.10
[22:02:55 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:efdca97cf104: Merge commit 'c6af9e944ebeb336f6520f59afaebb62392fb026' into release/0.10
[22:06:30 CET] <jamrial> rcombs: blame red hat :p
[22:07:08 CET] <Daemon404> red hat does not ship any libav(
[22:07:11 CET] <Daemon404> not with rhel
[22:07:51 CET] <jamrial> https://trac.ffmpeg.org/wiki/Downstreams shows 0.10 used by red hat
[22:08:13 CET] <Daemon404> thats not redhat proper
[22:08:17 CET] <Daemon404> probably EPEL
[22:15:07 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:8637f4edeee1: x86: Add CPU flag for the i686 cmov instruction
[22:15:08 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:893b353362bc: x86: Only use optimizations with cmov if the CPU supports the instruction
[22:15:09 CET] <cone-005> ffmpeg 03Katerina Barone-Adesi 07release/0.10:b989bb7adee0: apetag: Fix APE tag size check
[22:15:10 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:a19a10a53e4a: Merge commit '8637f4edeee1a6bd18bc90740fafadd3e1b412aa' into release/0.10
[22:15:11 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:c388db185c80: Merge commit '893b353362bc220280efd8d14c4878a1cafe18a8' into release/0.10
[22:15:12 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:c1f9be99d737: Merge commit 'b989bb7adee0f3286dcaa63c5cd0753eac45f6be' into release/0.10
[22:16:07 CET] <debianuser> ubitux: they had no aevalsrc yet? Then maybe it's "we like aevalsrc, so we'll rewrite some code and use a different name so that nobody could tell that we're taking features from ffmpeg, let their head ache and think what to do and how to keep compatibility, mu-ha-ha!"
[22:18:13 CET] <ubitux> i can't tell if that's geniune malice or just obstination :p
[22:18:24 CET] <ubitux> but well, at least nev tried, which is the only thing i wanted
[22:18:56 CET] <ubitux> it doesn't matter now, it's not like it's the 100th time it happens
[22:21:56 CET] <wm4> (in both directions)
[22:22:42 CET] <ubitux> differently
[22:22:48 CET] <ubitux> we don't need to NIH stuff from libav much :p
[22:25:55 CET] <debianuser> (or maybe it's both malice and obstination...)
[22:29:02 CET] <gnafu> <@Daemon404> probably EPEL <-- I don't think so.  EPEL follows Fedora rules for what can be included, so there shouldn't be anything like ffmpeg.  And Red Hat wouldn't care about RPM Fusion (which should have a significantly newer version anyway).  I think Red Hat does actually offer and support some form of ffmpeg for customers who want it.
[22:31:49 CET] <cone-005> ffmpeg 03Diego Biurrun 07release/0.10:22103315c2a1: Add some bug references to the changelog
[22:31:50 CET] <cone-005> ffmpeg 03Anton Khirnov 07release/0.10:0ceb2dffb6ba: mov: avoid a memleak when multiple stss boxes are present
[22:31:51 CET] <cone-005> ffmpeg 03Anton Khirnov 07release/0.10:954aafaa961c: jvdec: check frame dimensions
[22:31:52 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:525689ede906: Merge commit '22103315c2a1cb2de336750c50cf6bf7c109220c' into release/0.10
[22:31:53 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:522c7c37d235: Merge commit '0ceb2dffb6ba082a8abcc57c53a14b2512f0aa48' into release/0.10
[22:31:54 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:17f094697db9: Merge commit '954aafaa961c32c655ad38fb622e8cbe249ebd5a' into release/0.10
[22:31:59 CET] <wm4> what kind of red hat rules disallow ffmpeg?
[22:32:14 CET] <nevcairiel> probably patents
[22:35:11 CET] <gnafu> Yeah, Fedora is scared of patents.
[22:35:25 CET] <debianuser> patents, fedora doesn't ship "lame" either, it's in rpmfusion
[22:35:35 CET] <gnafu> And it looks like that page is specifically referring to RPM Fusion's packages, which I didn't realize were that old.
[22:35:50 CET] <gnafu> I think RH did support some form of ffmpeg at some point in the past.
[22:36:38 CET] <wm4> great, ffmpeg fails to compile on ARM with optimizations disabled and a somewhat old toolchain
[22:37:45 CET] <cone-005> ffmpeg 03Anton Khirnov 07release/0.10:fc159ba88ea2: mmvideo: check frame dimensions
[22:37:46 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:a331e11906b1: smc: fix the bounds check
[22:37:47 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:9ae3cd6e7271: gifdec: refactor interleave end handling
[22:37:48 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:8439378f41e3: Merge commit 'fc159ba88ea2dd1fa11e4ab6af8b574fc80db454' into release/0.10
[22:37:49 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:ed69f0f72edb: Merge commit 'a331e11906b196c9a00f5ffbc45d80fcd7fe8423' into release/0.10
[22:37:50 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:caedb041a6ab: Merge commit '9ae3cd6e7271a3d6b8cd92a4d35ebb16d2e03f1a' into release/0.10
[22:58:05 CET] <Daemon404> anyway... gonna call it now
[22:58:11 CET] <Daemon404> we'll end up wth dca_niels.c
[22:58:17 CET] Action: Daemon404 goes to watch a movie
[23:00:42 CET] <cone-005> ffmpeg 03Xiaohan Wang 07release/0.10:51dd54c51aac: matroskadec: Fix read-after-free in matroska_read_seek()
[23:00:43 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:d6deed7916f7: h264_cabac: Break infinite loops
[23:00:44 CET] <cone-005> ffmpeg 03Reinhard Tartler 07release/0.10:aace8b184c86: Prepare for 0.8.17 Release
[23:00:45 CET] <cone-005> ffmpeg 03Reinhard Tartler 07release/0.10:8b1f8fb26bfe: Update Changelog for 0.8.17 Release
[23:00:46 CET] <cone-005> ffmpeg 03Federico Tomassetti 07release/0.10:905988fe1a8a: eamad: check for out of bounds read
[23:00:47 CET] <cone-005> ffmpeg 03Andreas Cadhalpun 07release/0.10:82776caf7993: rmenc: limit packet size
[23:00:48 CET] <cone-005> ffmpeg 03Anton Khirnov 07release/0.10:ec5b2f6a3859: tiff: Check that there is no aliasing in pixel format selection
[23:00:49 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:3eaef560a71f: Merge commit '51dd54c51aaca909893c9f90a4119e96ff71ffdf' into release/0.10
[23:00:50 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:60feb8543a56: Merge commit 'd6deed7916f7f52dbfc88e2fc2c43e3cfb8ee74b' into release/0.10
[23:00:51 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:7f9527d30fa9: Merge commit 'aace8b184c867875e2715b2af23fa98886f90427' into release/0.10
[23:00:52 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:cb4da0405d34: Merge commit '8b1f8fb26bfe6a4cd9f72b962b45643fa331dbe1' into release/0.10
[23:00:53 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:22377751c967: Merge commit '905988fe1a8accbc1ab93120aa4cd29252b81cce' into release/0.10
[23:00:54 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:817ed4fae9d0: Merge commit '82776caf7993221719eefbe576f851c7e52dfef9' into release/0.10
[23:00:55 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:90afa95a55a2: Merge commit 'ec5b2f6a385959048f780b4e7d3d259dc1fa8421' into release/0.10
[23:17:37 CET] <cone-005> ffmpeg 03Reinhard Tartler 07release/0.10:76435f5e4085: doc: More changelog updates for v0.8.17
[23:17:38 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:335ec616cc38: utvideodec: Handle slice_height being zero
[23:17:40 CET] <cone-005> ffmpeg 03Reinhard Tartler 07release/0.10:0e8102555960: doc: More changelog updates for v0.8.17
[23:17:41 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:9575bd6a9d4c: Merge commit '76435f5e40854567252756ea7f788958dd2cc04c' into release/0.10
[23:17:41 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:a0316589e472: Merge commit '335ec616cc38ee6206a3acebd46d01aad73d721b' into release/0.10
[23:17:42 CET] <cone-005> ffmpeg 03Michael Niedermayer 07release/0.10:509239066ad0: Merge commit '0e810255596070e2c503c5da9001f7087f71de6e' into release/0.10
[23:34:30 CET] <debianuser> heh, x11grab is faster than bmp image. :) (`ffmpeg -f x11grab -r 100 -s 1280x1024 -i :0 -f null -` is faster than `ffmpeg -loop 1 -r 100 -i black.bmp -f null -`)
[23:47:03 CET] <wm4> different format?
[23:47:16 CET] <wm4> could be RGB0 (4 bytes) vs. RGB (3 bytes)
[00:00:00 CET] --- Thu Mar 12 2015