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

[burek]

[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