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

[burek]

[02:44] <llogan> lol. someone seems to want a "porn" filter in #ffmpeg.
[02:52] <Compn> to filter it out, or to add porn to every fram e?
[02:52] <Compn> youtube has a porn filter i bet 
[02:53] <Compn> not sure if its manual slave labor, could be
[02:53] <llogan> i don't know. he's gone.
[03:31] <iive> Compn: you would need at least as many people to screen the videos, as the people who upload them...
[03:31] <iive> it must be automated. to some degree.
[04:50] <Compn> yes, i guess some kind of skin color detection
[04:50] <Compn> more skin = more flags
[05:34] <cone-241> ffmpeg.git 03Matthieu Bouron 07master:bbab9cceb953: lavfi/drawutils: fix typo
[09:22] <cone-899> ffmpeg.git 03Carl Eugen Hoyos 07master:c52e07bb6e91: Fix AVCI50 SPS to specify a SAR of 4:3 instead of 3:4.
[10:31] <saste> michaelni: libavutil/common.h:100:34: warning: "ASSERT_LEVEL" is not defined [-Wundef]
[10:34] <cone-899> ffmpeg.git 03Stefano Sabatini 07master:92f1bed14cef: tests/lavfi-regression: always require three parameters in do_lavfi_pixfmts()
[10:34] <cone-899> ffmpeg.git 03Stefano Sabatini 07master:172505b8bc36: lavfi: add kerndeint filter
[10:34] <cone-899> ffmpeg.git 03Stefano Sabatini 07master:014056635944: lavfi: add histeq filter
[10:38] <cone-899> ffmpeg.git 03Paul B Mahol 07master:d4211c47220c: alsdec: change channel sorting so it match reference implementation
[10:54] <durandal_1707> does libswresample supports dithering from 24/32 to 16bps?
[11:08] <ubitux> does anyone know how the "return meaningful error codes." will affect the move to lavu AVFrame and ref counter?
[11:08] <ubitux> because if it's important, we'd better start doing it our own stuff too
[11:09] <ubitux> saste: going to remove mp=kerndeint?
[11:09] <nevcairiel> ubitux: ask the master of the evil plan? :)
[11:10] <ubitux> i'm going to get stabbed
[11:10] <nevcairiel> thats a risk, true
[11:11] <wm4> more like the evil api breakage
[11:14] <ubitux> mateo`: your drawutils blending patch doesn't affect fate?
[11:16] <michaelni> saste, http://fate.ffmpeg.org/report.cgi?time=20130105100534&slot=x86_64-darwin-gcc-4.7
[11:16] <michaelni> kerndeint failure on ppc
[11:17] <ubitux> [scale @ 0x1015136c0] w:iw h:ih flags:'' interl:0
[11:17] <ubitux> i guess that's sws flags again :)
[11:24] <mateo`> ubitux: it seems it does not, i ran fate and everything goes ok
[11:24] <ubitux> so how do you reproduce the issue?
[11:25] <ubitux> it seems that part of the code is completely uncovered
[11:25] <ubitux> http://lucy.pkh.me/ffmpeg-coverage/ffmpeg/libavfilter/drawutils.c.gcov.html
[11:27] <ubitux> oh, it's in drawtext?
[11:27] <mateo`> use drawtext with box=1:boxcolor=0x000000 at 0.8:x=101, wrong colors should appear at the left/right of the box.
[11:27] <ubitux> oh it noticed that i remember, indeed.
[11:27] <mateo`> the problem is even more visible with low subsampling like yuv411p
[11:28] <ubitux> i wonder if we couldn't find font settings where it renders the same everywhere
[11:28] <mateo`> might be a good idea to add a fate test ?
[11:28] <ubitux> some kind of standard monospace font without aliasing
[11:28] <ubitux> mateo`: the problem is making the test portable
[11:29] <ubitux> font stuff can certainly behave totally differently between platforms
[11:29] <ubitux> maybe we can just print some spaces, but i'm not even sure the surface will have the same dimensions everywhere
[11:29] <ubitux> (and the test won't be really useful)
[11:31] <mateo`> ubitux: but the problem will always show up at the left side
[11:31] <mateo`> ubitux: whatever font you use
[11:31] <ubitux> yes, for that particular thing
[11:31] <ubitux> but if we're going to cover drawtext
[11:32] <ubitux> better make the test a little useful
[11:32] <ubitux> +more
[11:32] <mateo`> sure
[11:33] <saste> michaelni, why is sws bitexact flag not set?
[11:35] Action: durandal_1707 :( i get spam : ./libavutil/common.h:225:34: warning: 'ASSERT_LEVEL' is not defined, evaluates to 0 [-Wundef]
[11:36] <saste> how are sws_flags propagated to the filtergraph?
[11:36] <saste> i see that sws_flags is set in the ffmpeg commandline, but apparently it is not propagated to the filterchain
[11:37] <saste> also i'd expect to see many failures in that case, not only in kerndeint
[11:37] <saste> apart from that, i can't see much platform dependent code which may affect the result of the test
[11:38] <durandal_1707> floats
[11:40] <wm4> does it even make sense to have different swsflags for different things?
[11:40] <saste> durandal_1707, no floats are used with those parameters
[11:45] <saste> ubitux, i'll remove kerndeint if michaelni is fine with that
[11:45] <saste> as for me, i see no reason to keep it
[11:45] <ubitux> perf! :)
[11:45] <durandal_1707> if it is faster than native, i object
[11:46] <saste> durandal_1707, that's going to be pretty ridiculous
[11:46] <saste> same for tinterlace, it is broken and the absolute gain in speed is unnoticeable
[11:47] <ubitux> the question is to understand why it happens, and if it's fixable
[11:47] <durandal_1707> if it is > 5% faster than native keep it
[11:47] <saste> then since it basically only performs stride arithmetic, it is faster since the native tinterlace is more generic/less redundant
[11:48] <saste> relative efficiency is meaningless in that case
[11:48] <durandal_1707> saste: i do not talk about tinterlace
[11:48] <ubitux> do you have the same problem with kerndeint?
[11:48] <durandal_1707> if tinterlace is different filter, shure remove mp one
[11:48] <ubitux> (note: i'm also fine with removing mp=tinterlace)
[11:51] <saste> ubitux, i'm not very motivated into benchmarking mp=kerndeint/kerndeint
[11:51] <saste> i wasted already a lot of time with tinterlace
[11:52] <ubitux> :)
[11:53] <durandal_1707> really, it only takes to add 2 lines of code
[11:53] <saste> durandal_1707, it's at least three lines of code, in two different files
[11:53] <saste> so it is six lines of code in total
[11:54] <ubitux> :D
[11:55] <ubitux> doesn't sound like worth the effort!
[11:55] <ubitux> except when you know that you'll have to remove them aftwerward
[12:03] <durandal_1707> michaelni: 697b476c075a and ticket mentioned in log have nothing in common
[12:06] <cone-899> ffmpeg.git 03Paul B Mahol 07master:14d50c19dc56: w64dec: support metadata (summarylist guid)
[12:22] <cone-899> ffmpeg.git 03Michael Niedermayer 07master:f27eb1b702d8: lavu: check that assert level is defined
[12:22] <durandal_1707> michaelni: so there is case when assert level is defined?
[12:23] <durandal_1707> there is no way to fix circular shit?
[12:43] <michaelni> durandal_1707, IIRC fixing the circular stuff wasnt trivial without introducing lots of changes to libav that would make merging harder, but its a while ago that i wrote the patch
[13:05] <J_Darnley> fflogger: If you're just going to state the number of machines with failures, why not just say "10 machines have failures"?
[13:18] <michaelni> J_Darnley, ask burek
[13:21] <cone-899> ffmpeg.git 03Matthieu Bouron 07master:be0a67bd6508: lavfi/drawutils: fix blending computation in blend_line function
[13:33] <cone-899> ffmpeg.git 03Anton Khirnov 07master:dda20a6e2c0c: avprobe: also output dar/par if only defined in stream
[13:33] <cone-899> ffmpeg.git 03Anton Khirnov 07master:a5d8c9243a1d: Update release notes for the 9 release.
[13:33] <cone-899> ffmpeg.git 03Anton Khirnov 07master:b14e89b3c5e6: Prepare for 9 Release.
[13:33] <cone-899> ffmpeg.git 03Michael Niedermayer 07master:2163c8828d21: Merge commit 'b14e89b3c5e6d7f6401a2ff1e3d198fa902e988a'
[13:34] <wm4> michaelni: when they release 9, will you do a release as well? it would possibly make things less painful for those who have to support both ffmpeg and libav
[13:34] <durandal_1707> lol, why RELEASE_NOTES is stuck with 0.10 ?
[13:35] <durandal_1707> wm4: yes, release 96
[13:35] <wm4> and making sure that the pkgconf versions match
[13:41] <saste> otoh, what're release_notes useful for?
[13:41] <saste> *what's
[13:41] <durandal_1707> their relase notes files is their propaganda for all bad stuff they do
[13:57] <cone-899> ffmpeg.git 03Reinhard Tartler 07master:3f89b49b0738: finalize changelog for version 9
[13:57] <cone-899> ffmpeg.git 03Xi Wang 07master:3b81bba3bc5a: mxfdec: fix NULL checking in mxf_get_sorted_table_segments()
[13:57] <cone-899> ffmpeg.git 03Xi Wang 07master:f73f76fd202b: swscale: fix NULL checking in sws_alloc_context()
[13:57] <cone-899> ffmpeg.git 03Michael Niedermayer 07master:bb4fb7715cf7: Merge remote-tracking branch 'qatar/master'
[13:59] <saste> oh i messed the kerndeint argb test...
[14:06] <cone-899> ffmpeg.git 03Stefano Sabatini 07master:860b5c0a631a: lavfi/kerndeint: fix mismatch between declared pixel format and test
[14:24] <ubitux> is the lavfi filter_frame() merge completely done?
[14:41] <cone-899> ffmpeg.git 03Carl Eugen Hoyos 07master:6a9af925654c: Allow remaining 32bit RGB packed pix_fmts in kerndeint filter.
[14:51] <durandal_1707> can our filters do what sox effects do? like allpass
[15:42] <cone-899> ffmpeg.git 03Nicolas George 07master:305180f5259e: lavu/base64: return meaningful error code.
[17:08] <cone-899> ffmpeg.git 03Michael Niedermayer 07master:9a697cfe716e: lavu: test for broken binutils on ARM
[17:26] <cone-899> ffmpeg.git 03James Almer 07master:b7d77f8e64d5: astenc: Enable the loop flag only when needed
[17:26] <cone-899> ffmpeg.git 03James Almer 07master:6717d1a96ff2: MAINTAINERS: add myself as maintainer of lavf/astenc.c
[18:09] <mateo`> is there a simple way to duplicate an AVPacket for later use ?
[18:10] <wm4> av_dup_packet(), apparently
[18:23] <mateo`> wm4: the documentation sounds scary :)
[18:23] <nevcairiel> its one of those functions thats really rather crazy
[18:24] <wm4> how could a function to copy something be crazy?
[18:26] <mateo`> wm4: why av_dup_packet do not return a new allocated packet ?
[18:26] <nevcairiel> I think it only copies the packet if the packet uses a static buffer
[18:26] <nevcairiel> so it doesnt return a new packet
[18:26] <nevcairiel> it just copies the internal data from a static to an allocated b uffer
[18:27] <wm4> wat
[18:28] <nevcairiel> i told you its a crazy function
[18:28] <nevcairiel> some demuxers have static buffers into which they read data, and then put these static buffers into an AVPacket
[18:28] <nevcairiel> av_dup_packets only purpose is to copy that data into a freshly allocated buffer
[18:28] <wm4> hm, looks like it copies the packet contents
[18:29] <wm4> so there isn't actually a static buffer
[18:29] <wm4> but still, crazy enough
[18:30] <wm4> how ffmpeg would design strdup(): void av_dup_string(char **string);
[18:33] <wm4> ubitux: why did you use sscanf for new code?
[19:07] <cone-899> ffmpeg.git 03Michael Niedermayer 07master:f3c9d66bafde: libspeexdec: fix terminator check
[22:14] <ubitux> wm4: i guess i did, anything wrong with it?
[23:13] <cone-370> ffmpeg.git 03…0sE 07master:7e5d4fa97d28: mmf.c: Do not write metadata into the SMAF Contents Info chunk.
[23:36] <cone-370> ffmpeg.git 03Michael Niedermayer 07master:2468827c06ad: internal.h: remove start/end_frame from AVFilterPad
[23:36] <cone-370> ffmpeg.git 03Michael Niedermayer 07master:39d187545596: libavfilter/video.h: remove unused things related to the start/slice/end API
[23:41] <cone-370> ffmpeg.git 03Carl Eugen Hoyos 07master:1a34103f0f22: mmf.c: Use LIBAVFORMAT_IDENT when writing Yamaha SMAF version information.
[23:42] <cone-370> ffmpeg.git 03Carl Eugen Hoyos 07master:8bf70159dcf4: 10l: Update fate seeking reference after last commit.
[00:00] --- Sun Jan  6 2013