[00:15] <cone-709> ffmpeg.git 03Michael Niedermayer 07release/0.10:c8857308f60c: smacker: remove av_clip_int16() [00:15] <cone-709> ffmpeg.git 03Michael Niedermayer 07release/0.11:1b0028a3c5c0: smacker: remove av_clip_int16() [00:15] <cone-709> ffmpeg.git 03Michael Niedermayer 07release/0.9:0147e9f7c64b: smacker: remove av_clip_int16() [00:15] <cone-709> ffmpeg.git 03Michael Niedermayer 07release/1.0:0428594f4788: smacker: remove av_clip_int16() [00:15] <cone-709> ffmpeg.git 03Michael Niedermayer 07release/1.1:6f585f1e66ff: smacker: remove av_clip_int16() [00:15] <cone-709> ffmpeg.git 03Michael Niedermayer 07release/1.2:5f64a7a6252f: smacker: remove av_clip_int16() [00:21] <cone-709> ffmpeg.git 03Xidorn Quan 07master:5a65fea655fb: avutil/frame: continue to process bufs even if some are empty [03:38] <ubitux> yay finally fixed the 3d lut. [03:42] <ubitux> http://lucy.pkh.me/l3d/3dlut-in.jpg ’ http://lucy.pkh.me/l3d/3dlut-out.jpg [03:43] <ubitux> the effect is pretty nice [11:20] <cone-957> ffmpeg.git 03Luca Barbato 07master:8aa3500905fe: mjpeg: Validate sampling factors [11:20] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:f57a7ac9b8e0: Merge commit '8aa3500905fec6c4e657bb291b861d43c34d3de9' [11:33] <cone-957> ffmpeg.git 03Luca Barbato 07master:a030279a67ef: ljpeg: use the correct number of components in yuv [11:33] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:3b071a4390f0: Merge commit 'a030279a67ef883df8cf3707774656fa1be81078' [11:42] <cone-957> ffmpeg.git 03Diego Biurrun 07master:c209d0df657f: fate.sh: add support for build-only FATE instances [11:42] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:877cae6effef: Merge commit 'c209d0df657f172f42d9bafbcdfa02dfb14f6965' [12:01] <cone-957> ffmpeg.git 03Luca Barbato 07master:cfbd98abe82c: mjpegdec: validate parameters in mjpeg_decode_scan_progressive_ac [12:01] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:6ef7b6af6be0: Merge commit 'cfbd98abe82cfcb9984a18d08697251b72b110c8' [12:08] <cone-957> ffmpeg.git 03Kostya Shishkov 07master:03ece7b0404f: proresdec: simplify slice component offsets handling [12:08] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:1d8b1f0e5110: Merge remote-tracking branch 'qatar/master' [12:30] <ubitux> durandal_1707: i don't remember if i linked that you http://www.ipol.im/pub/art/2012/lps-pae/ ? [12:30] <ubitux> for a potential new histeq [12:34] <durandal_1707> ubitux: tried already, seems same as histeq [12:34] <ubitux> ok [13:02] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:a90baa63c33f: add YUVJ411P [13:02] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:b60a65ee2d5d: mjpegdec: fix AV_PIX_FMT_YUVJ411P handling [13:04] <durandal_1707> michaelni: have you looked at fraps decoding error, its seems your commit caused such regression? [13:52] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:1d7e6a6bde73: avcodec/bitstream: print vlc length in error case. [13:52] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:b9ea6a84143a: avcodec/huffman: use named identifer for the bits constant [13:52] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:b1bbd715d8c4: avcodec/huffman: increase bits constant [14:04] <durandal_1707> hflip and vflip can use timeline too [14:23] <durandal_1707> using AV_NE( AV_PIX_FMT_YUV420P9BE, AV_PIX_FMT_YUV420P9LE ), is pointless, just AV_PIX_FMT_YUV420P9 is enough [15:04] <ubitux> should we make the source filters "pause" (frame repeat) with the timeline? [15:05] <durandal_1707> instead of filter that does same? [15:07] <ubitux> durandal_1707: ? [15:07] <ubitux> common filter with timeline: enable=0 ’ input frame dup [15:07] <ubitux> source filter with timeline: enable=0 ’ repeat last frame [15:07] <ubitux> would that make sense? [15:15] <durandal_1707> no as, there can be filter that repeats X frame N times [15:21] <ubitux> https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.9.3 [15:21] <ubitux> "cpufreq / intel_pstate: fix ffmpeg regression" [15:21] <ubitux> woot [15:21] <ubitux> "This fixes a performance regression of approximately 30%" [15:21] <ubitux> fear [15:22] <ubitux> durandal_1707: why not [15:22] <nevcairiel> apparently ffmpegs threading model is evil [15:22] <ubitux> durandal_1707: but do you think that would be simpler? [15:22] <ubitux> nevcairiel: you have more info on this? [15:22] <nevcairiel> only what it says in the commit message [15:38] <ubitux> durandal_1707: do you plan to add vflip/hflip timeline? [15:40] <durandal_1707> ubitux: no [16:15] <cone-957> ffmpeg.git 03Clément BSsch 07master:b8a9876a8b20: lavfi/yadif: add timeline support. [16:22] <ubitux> michaelni: any plan for a 1.3? [16:22] <ubitux> Changelog is starting to get hugez [16:23] <durandal_1707> wait one year [16:26] <MicroSend> hello all [16:27] <MicroSend> Your little help me on ffmpeg, I would like to know the command to enoyer a live audio stream from a microphone to one IP address [16:28] <MicroSend> Your little help me on ffmpeg, I would like to know the command to send a live audio stream from a microphone to one IP address [16:29] <cbsrobot> MicroSend: please ask on #ffmpeg [16:30] <jshanab> I posted on the ffmpeg irc, but traffic there seems primarily to be for users of ffmpeg and not developers using libavcodec in an application. I am updateing to the newest libavcodec (Zeranoe win32 shared) and the avcodec-55.dll fails to load with the error "The procedure Entry point SymGetOptions could not be found" It looks to be the correct dll and I have linked to the correct lib(s) [16:34] <jshanab> Does this mean the Zeranoe are built against a version of windows not supported on my machine? Bad build? [16:38] <durandal_1707> jshanab: i think the best place is to ask on zeranoe forum [16:40] <jshanab> Well. Maybe i had better just build it. --if I can build on linux,ios,android and croos, I can probably build on windblows ;-) [16:42] <nevcairiel> SymGetOptions is a debug function, it shouldnt be part of any release build really, sounds like the build is screwed up [16:52] <jshanab> I build debug. But it is ok to use release dlls? I always get that confused when in dll hell [16:55] <Compn> jshanab : arent the debug dlls like 30x larger ? [16:56] <Compn> but yes ask on zeranoe forum [17:00] <jshanab> I know debug and release use seperate heaps and mixing can be dangerous, I just don't have all the rules memorized. I much prefer the GCC style handling of debug, but I am cross platform and haveto get it working on windows too. They provide the def files, I wonder if I need to re-create the import libs [17:57] <jshanab> Regenerating all libs seems to work. The .lib in the package are debug and the dlls are release I think [17:59] <nevcairiel> zeranoe import libs are most likely created by dlltool instead of lib.exe, so they don't work 100% correctly anyway [18:05] <jshanab> Too bad there isn't just a decent CmakeList. Then cross compileing,differnt versions of VS, linux,mac,windows and packaging could all be handled [18:39] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:66f5790d7bc2: seek-test: make duration user configurable [19:54] <cone-957> ffmpeg.git 03Paul B Mahol 07master:dbb49a653971: vp3: zero allocated tables [21:08] <wm4> why was AV_PIX_FMT_YUVJ411P added? aren't the J variants deprecated? [21:08] <iive> j is for jpeg and usually indicates full range. [21:08] <iive> is there now another way to indicate it? [21:11] <wm4> yes [21:11] <wm4> the color range [21:11] <wm4> I suppose the J format was added only because lavfi doesn't pass along the color range and color space [21:11] <wm4> but maybe you should rather fix lavfi instead of adding new hacks [21:12] <wm4> this would be a nice opportunity to do this [21:12] <saste> wm4, no lavfi is completely unrelated, J variants predate libavfilter inception [21:13] <wm4> well, now the J variants are useless, because you have the color range [21:13] <wm4> quoting pixfmt.h: AV_PIX_FMT_YUVJ420P, ///< planar YUV 4:2:0, 12bpp, full scale (JPEG), deprecated in fa [21:13] <wm4> vor of PIX_FMT_YUV420P and setting color_range [21:14] <wm4> for some reason, the patch for AV_PIX_FMT_YUVJ411P doesn't add "deprecated" though [21:14] <iive> could it be artifact from fork merge? [21:14] <wm4> ok maybe the new format wasn't added for lavfi, and I was assuming things [21:14] <wm4> iive: not all bad things are because of the fork [21:16] <iive> not all, but most. [21:16] <durandal_1707> so same can be say for gbrp it same as yuv444p but color range instead of rgb is yuv [21:16] <wm4> durandal_1707: I agree [21:17] <ubitux> how is the color range supposed to be handled in yuvj pix formats? [21:17] <wm4> maybe the difference is large enough here to justify a new format, though [21:17] <iive> is that color range or color format? [21:17] <ubitux> i mean, what can be done about it? [21:17] <ubitux> do we have a thread or an issue about that? [21:17] <wm4> ubitux: simple... don't use J formats, use color ranges everywhere [21:17] <wm4> ubitux: libswscale actually handles J formats and color ranges (mostly) correctly [21:20] <ubitux> so we would need to update all the codecs to use the YUV[^J] pixel formats [21:20] <durandal_1707> until J formats are removed, it should not matter much [21:20] <ubitux> and then what else? [21:21] <ubitux> how would the color range simplify anything btw? [21:21] <wm4> ubitux: maybe update lavfi to use color range [21:21] <durandal_1707> but libswscale is only part that slows things down [21:21] <ubitux> that means a lot of work [21:21] <ubitux> a lot of filters are just working on full range [21:21] <wm4> well, it wasn't my idea to mark these formats as deprecated [21:22] <ubitux> or some filters might work only in a limited range [21:22] <ubitux> so it might make query_formats much more complex [21:22] <ubitux> than just adding the yuvj versions [21:22] <ubitux> (or removing them) [21:22] <wm4> well, decide what you want [21:23] <wm4> remove the "deprecated" comment or something [21:23] <wm4> at least be consistent about it [21:23] <durandal_1707> query_formats would need addition of color spaces (like sample rates/ layouts /sample formats for audio) [21:24] <durandal_1707> and packed yuv support in liswscale is not that brilliant [21:24] <wm4> what does packed yuv have to do with it? [21:24] <durandal_1707> the libswscale would need lot of refactoring [21:24] <wm4> libswscale already supports color ranges... [21:25] <durandal_1707> color ranges is nonsense hack [21:29] <iive> what kind of refactoring do you have in mind? [21:31] <durandal_1707> iive: have you ever had look into libswscale? [21:32] <iive> durandal_1707: is that rhetorical question? [21:33] <durandal_1707> i find that there it to many pixel format [21:33] <durandal_1707> the 9/10/12/14 variants are worst examples [21:34] <iive> you mean, there are too many pixel formats? [21:34] <durandal_1707> yes [21:35] <iive> and how would you refactor it? get rid of the formats altogether? [21:35] <durandal_1707> but that is far from biggest libswscale issue [21:36] <durandal_1707> i would split layouts from color space [21:38] <iive> you mean planar vs packed? [21:39] <durandal_1707> i mean packed yuv444 = packed rgb [21:41] <iive> how so? [21:43] <cone-957> ffmpeg.git 03Stefano Sabatini 07master:2210003b7f57: lavfi/geq: add aliases for RGB options [21:43] <nevcairiel> because it doesnt matter if the bits are yuv or rgb [21:43] <cone-957> ffmpeg.git 03Stefano Sabatini 07master:a8d98377b168: lavfi/geq: prefer symbolic constants [21:43] <nevcairiel> its the same memory layout [21:44] <durandal_1707> yes, but that is less important, there are far more imporant things to be done first [21:46] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:376e89e280fd: j2kdec: s/decode_packets/jpeg2000_decode_packets/ [21:46] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:0ab0ed2b8609: j2k: Rename structs to be more similar to jpeg2000dec [21:46] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:78c7bff04ac5: avcodec/j2k: rename J2K_ constants to JPEG2000_ [21:46] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:069ede298116: jpeg2000dec: Check ncomponents and tile dimensions [21:57] <cone-957> ffmpeg.git 03Michael Niedermayer 07master:81bec0ace422: avutil/pixfmt: add forgotten deprecated to YUVJ411 [22:15] <durandal_1707> awwww, #75 bug fixed [22:15] <ubitux> saste: for geq, i meant replacing "plane == 1 || plane == 2" with "plane == U || plane == V" [22:18] <cbsrobot> ubitux: did you have time for the true peaks ? [22:18] <ubitux> not yet :p [22:19] <ubitux> sorry :) [22:19] <ubitux> ETOOMUCHTHINGSTODO [22:19] <durandal_1707> ffmpeg related? [22:19] <ubitux> yeah, mostly [22:19] <cbsrobot> yeah ebur128 [22:19] <ubitux> durandal_1707: didn't you see my various pending patches? [22:20] <cbsrobot> and about the line_spacing for subtitles - is there another important option to add ? [22:20] <ubitux> oh right i forgot to reply [22:23] <cbsrobot> maybe the ass_font_hinting - but not sure it is really necessary [22:23] <ubitux> i'd say at least half of the settings could be mapped [22:25] <durandal_1707> why apad supports timeline? [22:31] <ubitux> durandal_1707: to pad up to a certain limit? [22:32] <cone-957> ffmpeg.git 03Clément BSsch 07master:39dc1bc90fa7: lavfi/(a)showinfo: use link frame counter instead of local counter. [22:37] <durandal_1707> ubitux: one can't enable timeline with vflip/hflip as they accepts no options [22:51] <cone-957> ffmpeg.git 03Paul B Mahol 07master:f98dbc7311a3: lavu/opt: check if class is NULL too [22:56] <michaelni> saste, ubitux theres a vf_drawtext pull req: https://github.com/FFmpeg/FFmpeg/pull/18 [23:15] <ubitux> michaelni: i'm going to look at this [23:16] <michaelni> ubitux, thx [23:23] <ubitux> what the guy is trying to do is simply a text=%{e:n+123} [23:23] <ubitux> but... that doesn't seen to work right now [23:28] <ubitux> oh that's my stupid shell. [23:28] <ubitux> or maybe a parsing issue somewhere else [23:29] <ubitux> arg, the ':'.. :( [00:00] --- Wed May 22 2013