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

[burek]

[00:05] <BBB> michaelni: have you tested h264 w/ and w/o edges (i.e. w/ and without draw_edges) lately (since I optimized ff_emulated_edge_mc)?
[00:06] <BBB> michaelni: it's the last dsp function (not counting er)
[00:07] <BBB> michaelni: I'd very much fancy killing it
[00:09] <michaelni> Any tests i did where in the distant past i think
[00:10] <BBB> hm ok I'll do some testing
[00:10] <BBB> on vp8, not using draw_edge was never slower and sometimes faster
[00:10] <BBB> (only tested on x86 ofc)
[00:10] <BBB> I think the same would hold for arm also though
[00:11] <ubitux> yay blend filter.
[00:11] <ubitux> Paul is on steroids recently
[00:12] <nevcairiel> i think he is on a mission to kill mpcodecs
[00:12] <ubitux> yes, that's good, but afaict blend is not related to it :)
[00:12] <ubitux> same for all the awesome audio filters
[00:21] <Compn> gasp!
[00:21] <Compn> hes gone!
[00:21] <Compn> :p
[00:31] <cone-485> ffmpeg.git 03Paul B Mahol 07fatal: ambiguous argument 'refs/tags/n0.8.13': unknown revision or path not in the working tree.
[00:31] <cone-485> Use '--' to separate paths from revisions
[00:31] <cone-485> refs/tags/n0.8.13:HEAD: lavfi/noise: switch to AVLFG noise generator
[00:34] <BBB> yeah h264 is definitely faster with -flags +emu_edge on x86
[00:34] <BBB> (on cathedral)
[00:34] <BBB> so same as vp8
[00:34] <BBB> I'll kill draw_edges - fun fun fun
[00:53] <cone-485> ffmpeg.git 03Michael Niedermayer 07master:54b2bddd22fb: v4l2: try to fix build on BSD
[01:09] <cone-485> ffmpeg.git 03Mans Rullgard 07release/0.7:b102d5d97dae: h264: allow cropping to AVCodecContext.width/height
[01:09] <cone-485> ffmpeg.git 03Mans Rullgard 07release/0.7:0054d70f23ed: mov: set AVCodecContext.width/height for h264
[01:09] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07release/0.7:c497d71a026a: Clarify that -passlogfile has a different syntax when used with -vcodec libx264.
[01:10] <cone-485> ffmpeg.git 03Ronald S. Bultje 07release/0.7:9a5e81235e62: dxva2: include dxva.h if found
[01:10] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07release/0.7:8582e6e9a3ce: Fix muxing mjpeg in swf. (cherry picked from commit 7680d99b4302e476076cc1b8f2567f47c2aaef4d)
[01:10] <cone-485> ffmpeg.git 03Anton Khirnov 07release/0.7:a60eb6ef12df: ffmpeg: fix -force_key_frames
[01:10] <cone-485> ffmpeg.git 03Kostya Shishkov 07release/0.7:0173a7966b33: vc1dec: add flush function for WMV9 and VC-1 decoders
[01:10] <cone-485> ffmpeg.git 03Janne Grunau 07release/0.7:f31170d4e7f9: nuv: check RTjpeg header for validity
[01:10] <cone-485> ffmpeg.git 03Janne Grunau 07release/0.7:8812b5f16410: imgconvert: avoid undefined left shift in avcodec_find_best_pix_fmt
[01:10] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:899d95efe12f: mpegvideo: Don't use ff_mspel_motion() for vc1
[01:10] <cone-485> ffmpeg.git 03Anton Khirnov 07release/0.7:77d43bf42d76: lavf: don't segfault when a NULL filename is passed to avformat_open_input()
[01:10] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:b6ba39f931a8: alsdec: check opt_order.
[01:10] <cone-485> ffmpeg.git 03Mina Nagy Zaki 07release/0.7:b6c5848a1f8f: lavfi: avfilter_merge_formats: handle case where inputs are same
[01:10] <cone-485> ffmpeg.git 03Justin Ruggles 07release/0.7:61ece4137298: vorbisenc: check all allocations for failure
[01:10] <cone-485> ffmpeg.git 03Alex Converse 07release/0.7:d6e250abfc36: vorbis: Validate that the floor 1 X values contain no duplicates.
[01:10] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:e28814e0e16c: Merge remote-tracking branch 'qatar/release/0.7' into release/0.8
[01:10] <cone-485> ffmpeg.git 03Diego Biurrun 07release/0.7:7b91e52eb9fd: x86: Require an assembler able to cope with AVX instructions
[01:10] <cone-485> ffmpeg.git 03Clément BSsch 07release/0.7:80b8dc30dc96: lavc/ass_split: check for NULL pointer in ff_ass_split_override_codes().
[01:10] <cone-485> ffmpeg.git 03Mans Rullgard 07release/0.7:a2ae183a382f: h264: allow cropping to AVCodecContext.width/height
[01:10] <cone-485> ffmpeg.git 03Kostya Shishkov 07release/0.7:e39fc137aeac: vc1dec: add flush function for WMV9 and VC-1 decoders
[01:10] <cone-485> ffmpeg.git 03Anton Khirnov 07release/0.7:d3e2f35f7add: bmpdec: only initialize palette for pal8.
[01:10] <cone-485> ffmpeg.git 03Max Lazarov 07release/0.7:0892a6340f86: eval: fix swapping of lt() and lte()
[01:10] <cone-485> ffmpeg.git 03Martin Storsjö 07release/0.7:a81c1ea2eb66: h263: Add ff_ prefix to nonstatic symbols
[01:10] <cone-485> ffmpeg.git 03Janne Grunau 07release/0.7:99008ba3667a: rv34: use AVERROR return values in ff_rv34_decode_frame()
[01:10] <cone-485> ffmpeg.git 03Mina Nagy Zaki 07release/0.7:10c244cc89e8: lavfi: avfilter_merge_formats: handle case where inputs are same
[01:10] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:7a0ff7566b66: avsdec: Set dimensions instead of relying on the demuxer.
[01:10] <cone-485> ffmpeg.git 03Aneesh Dogra 07release/0.7:42c3a3719b05: bytestream: add a new set of bytestream functions with overread checking
[01:10] <cone-485> ffmpeg.git 03Anton Khirnov 07release/0.7:4c849c69910c: dfa: check that the caller set width/height properly.
[01:10] <cone-485> ffmpeg.git 03Kostya Shishkov 07release/0.7:2d63f9b4effc: dfa: add some checks to ensure that decoder won't write past frame end
[01:10] <cone-485> ffmpeg.git 03Kostya Shishkov 07release/0.7:c0df6a24ce9e: indeo: check custom Huffman tables for errors
[01:10] <cone-485> ffmpeg.git 03Kostya Shishkov 07release/0.7:601fa565823b: indeo: clear allocated band buffers
[01:10] <cone-485> ffmpeg.git 03Kostya Shishkov 07release/0.7:3c0f84402b2b: indeo: check for invalid motion vectors
[01:10] <cone-485> ffmpeg.git 03Janne Grunau 07release/0.7:8148833193c6: indeo5: prevent null pointer dereference on broken files
[01:10] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:aa097b4d5fd4: indeo5: check tile size in decode_mb_info().
[01:10] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:44da556815fc: lagarith: check count before writing zeros.
[01:10] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:4a636a5e4368: wmaprodec: check num_vec_coeffs for validity
[01:10] <cone-485> ffmpeg.git 03Anton Khirnov 07release/0.7:05f5a2eb62db: avidec: use actually read size instead of requested size
[01:10] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:6996a2f79689: cavsdec: check for changing w/h.
[01:10] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:e3e369f6962c: alsdec: Check that quantized parcor coeffs are within range.
[01:10] <cone-485> ffmpeg.git 03Thilo Borgmann 07release/0.7:1b48a426a96f: alsdec: Fix out of ltp_gain_values read.
[01:10] <cone-485> ffmpeg.git 03Mans Rullgard 07release/0.7:7e070cf2025f: alsdec: remove dead assignments
[01:10] <cone-485> ffmpeg.git 03Thilo Borgmann 07release/0.7:9474c9302844: alsdec: fix number of decoded samples in first sub-block in BGMC mode.
[01:11] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:aa45b90804ab: alsdec: Check k used for rice decoder.
[01:11] <cone-485> ffmpeg.git 03Reinhard Tartler 07release/0.7:642d758a2d82: Update RELEASE file for 0.7.7
[01:11] <cone-485> ffmpeg.git 03Piotr Bandurski 07release/0.7:fe9cbf582b09: tiffdec: Use the correct height field.
[01:11] <cone-485> ffmpeg.git 03Anton Khirnov 07release/0.7:9f8071245491: ivi_common: check that scan pattern is set before using it.
[01:11] <cone-485> ffmpeg.git 03Luca Barbato 07release/0.7:700fb8c8dd06: vp56: make parse_header return standard error codes
[01:11] <cone-485> ffmpeg.git 03Luca Barbato 07release/0.7:7fd7950174f9: vp56: release frames on error
[01:11] <cone-485> ffmpeg.git 03Sami Pietila 07release/0.7:bfbff1c7483c: vp8: reset loopfilter delta values at keyframes.
[01:11] <cone-485> ffmpeg.git 03Luca Barbato 07release/0.7:f3f22f183fa2: yuv4mpeg: reject unsupported codecs
[01:11] <cone-485> ffmpeg.git 03Justin Ruggles 07release/0.7:3d0c9c9af687: flacenc: ensure the order is within the min/max range in LPC order search
[01:11] <cone-485> ffmpeg.git 03Reinhard Tartler 07release/0.7:ce8910d861c1: h264: Fix parameters to ff_er_add_slice() call
[01:11] <cone-485> ffmpeg.git 03Luca Barbato 07release/0.7:4ede95e69cf9: vp6: properly fail on unsupported feature
[01:11] <cone-485> ffmpeg.git 03Janne Grunau 07release/0.7:10ff052c6013: lavf: avoid integer overflow in ff_compute_frame_duration()
[01:11] <cone-485> ffmpeg.git 03Alex Converse 07release/0.7:b143844ea0f6: aacdec: Fix an off-by-one overwrite when switching to LTP profile from MAIN.
[01:11] <cone-485> ffmpeg.git 03Janne Grunau 07release/0.7:5fa739e685bc: h264: enable low delay only if no delayed frames were seen
[01:11] <cone-485> ffmpeg.git 03Luca Barbato 07release/0.7:08d9fd611eac: ppc: always use pic for shared libraries
[01:11] <cone-485> ffmpeg.git 03Janne Grunau 07release/0.7:4457e6137d83: h264: check sps.log2_max_frame_num for validity
[01:11] <cone-485> ffmpeg.git 03Victor Lopez 07release/0.7:884a9b0d298a: h264: fix sps parsing for SVC and CAVLC 4:4:4 Intra profiles
[01:11] <cone-485> ffmpeg.git 03Justin Ruggles 07release/0.7:a39c6bf1b878: alacdec: do not be too strict about the extradata size
[01:11] <cone-485> ffmpeg.git 03Martin Storsjö 07release/0.7:808187965570: rtsp: Recheck the reordering queue if getting a new packet
[01:11] <cone-485> ffmpeg.git 03Dale Curtis 07release/0.7:55065315caf1: Fix uninitialized reads on malformed ogg files.
[01:11] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:391e0fc6c90c: roqvideodec: check dimensions validity
[01:11] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:af343f5cddc5: eamad: fix out of array accesses
[01:11] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:2cac35086c9e: vqavideo: check chunk sizes before reading chunks
[01:11] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:e6ac11e41734: aacdec: check channel count
[01:11] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:41eda870483f: pngdec/filter: dont access out of array elements at the end
[01:11] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:377fabc9e687: Update for 0.8.13
[01:11] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:7378101d4102: Merge branch 'release/0.8' into release/0.7
[01:14] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.7:f86da592c339: update for 0.7.14
[01:23] <llogan> saste: are you interested in administering an application to GSoC this year?
[01:24] <saste> llogan, if there are no other volunteers
[01:25] <saste> possibly, i'd prefer to just act as co-administrator
[01:26] <ubitux> @_@
[01:31] <llogan> i can help format/cleanup/prettify the ideas list at least...
[01:34] <llogan> should we continue to use multimedia.cx, or use the trac wiki this time? .cx is more of an actual wiki, but it might look nice to use our own domain
[01:35] <saste> llogan, you can already start to do it
[01:35] <saste> i'm biased towared multimedia.cx, because of stricter access policy
[01:35] <llogan> shit. responsibilities...
[01:35] <saste> we don't want to let random j. hacker to edit the page just before review
[01:36] <llogan> multimedia.cx is fine with me as long as whoever needs to edit it can get access. does it still depend on mike?
[01:36] <saste> llogan, i think so
[01:36] <saste> we should probably ask him before
[01:37] <llogan> good idea. i can do that.
[01:37] <saste> then we could simply copy the 2012 page to a new one, and let candidate mentors edit the proposed tasks
[01:37] <llogan> ok
[01:38] <llogan> i'll try to do that later today or tomorrow if i hear back from mike
[01:39] <saste> llogan, thanks
[01:46] <cone-485> ffmpeg.git 03Ronald S. Bultje 07master:c63f9fb37a7b: h264: don't store intra pcm samples in h->mb.
[02:08] <ubitux> what is cathedral?
[02:09] <BBB> a sample clip often used for profiling in this community
[02:10] <ubitux> where can i find it?
[02:10] <Compn> oh 
[02:10] <Compn> that clip
[02:10] <Compn> raw yuv 
[02:10] <BBB> google for cathedral-beta2-400extra-crop-avc.mp4
[02:10] <ubitux> thx
[02:11] <BBB> it's somewhere on mplayersamples or whatever that site is called
[02:11] <BBB> but I'm too lazy to find it
[02:12] <ubitux> http://samples.ffmpeg.org/V-codecs/h264/cathedral-beta2-400extra-crop-avc.mp4
[02:12] <ubitux> thx :)
[02:12] <BBB> tadaah
[02:13] <Compn> what? 
[02:13] <Compn> dont use the compressed version :P
[02:14] <ubitux> oh, never saw this diablo-elephant-dream animation
[02:14] Action: ubitux looking for a higher res now
[02:16] <Compn> http://samples.ffmpeg.org/raw-video/
[02:16] <Compn> well foremans in there
[02:18] <ubitux> looks like there are some other interesting stuff on platige.com
[02:55] <ubitux> oh, seems libav realized they broke another codec with cosmetics
[02:56] <ubitux> mmh, already fixed in ffmpeg.
[02:59] <ubitux> actually, michaelni merged it properly
[03:02] <Compn> we're not supposed to talk/troll/complain about libav, apparently
[03:02] <Compn> :P
[03:02] <ubitux> who told this?
[03:02] <Compn> that guy daemon404 who complains about ffmpeg development 
[03:02] <ubitux> yes but he ragequited so that's ok
[03:03] <Compn> lol
[03:03] <ubitux> anyway, it's just that i find very funny when Diego is saying Michael is merging blindly, while he is actually fixing the crap he introduce with his cosmetics madness
[03:05] <Compn> i'm curious how they arent breaking fate ?
[03:09] <BBB> you know, svq3 is a very elaborate format
[03:09] <BBB> it looks simple, but isn't
[03:10] <BBB> it uses hpel, tpel, for example
[03:10] <BBB> and has many coding modes
[03:10] <BBB> code coverage of the sample in fate is likely in the 50% range
[03:10] <BBB> in terms of functional coverage, not lines of code
[03:11] <ubitux> in term of LoC it's about 70%
[03:11] <ubitux> http://lucy.pkh.me/ffmpeg-coverage/ffmpeg/libavcodec/svq3.c.gcov.html
[03:12] <ubitux> and it seems the broken code was exactly in the non-covered area
[03:13] <ubitux> (~L564)
[03:13] <BBB> there you go
[03:13] <BBB> so one could say that we need more fate coverage
[03:13] <BBB> (not that I care)
[03:15] <Compn> svq3 is tied into h264 heavily
[03:15] <Compn> or was
[03:16] <Compn> BBB : i like your .2percent speedups :)
[03:20] <BBB> it still is
[03:20] <BBB> this is more cleanup than speedup, strictly speaking
[03:20] <BBB> but thanks anyway
[03:56] <BBB> isn't draw_horiz_band utterly broken for h264?
[03:56] <BBB> (unless SLICE_FLAG_CODED_ORDER is set)
[03:56] <BBB> michaelni: ^^
[04:04] <michaelni> BBB, it does look broken, i wonder why noone reported an issue
[04:38] <BBB> michaelni: I can only imagine nobody is using it
[04:38] <BBB> can we unshare that between mpeg and h264?
[04:38] <BBB> it makes no sense to share after my last patch, there's virtually no code shared at all
[05:50] <highgod> Hi,all,I want to ask a question. I use the hwaccel and software both decode the same h264 video to yuv. I want to ask that are the both yuv file are the same? totally?
[05:56] <Compn> you want to compare each file ?
[05:57] <Compn> use ffmpeg with the framemd5 , i think
[05:57] <Compn> if they are exact, the md5 should match
[05:57] <Compn> ffmpeg -i file.yuv -f framemd5
[06:02] <Compn> ffmpeg -i file.yuv -f framemd5 out.txt that is
[06:02] <Compn> highgod : it work for you ?
[06:02] <Compn> michaelni : are you going to review the dxva2 patch? i dont think anyone else is 
[06:02] <highgod> No,I use dxva2 and ffmpeg software decode the same h.264 video to yuv,but the two files is mismatch in some bits
[06:03] <Compn> highgod : if you are using ffmpeg to decode using dxva2, cant you directly use -f framemd5 ? just to make sure the yuv part isnt adding additional bug
[06:04] <Compn> are some frames the same ? is it one type of frame that causes problems? like b-frame or p-frame or i-frame ?
[06:04] <Compn> and are you sure you are using single thread h264 software decoder ? i think multithreaded h264 decoder will cause slight differences when decoding
[06:05] <BBB> no it won't
[06:05] <Compn> oh ok, was that fixed ?
[06:05] <BBB> multithreaded h264 is entirely bitexact for all test sequences
[06:05] <Compn> good :)
[06:05] <BBB> I fixed that before it was ever merged in either tree
[06:05] <Compn> its hard to remember all of these bugs 
[06:06] <BBB> you can test it locally
[06:06] <BBB> make THREADS=2 fate-h264
[06:06] <Compn> yeah well i could do that
[06:06] <BBB> if that passes, all sequences are bitexact
[06:06] <Compn> or i could go to sleep
[06:06] Action: Compn sleeps
[06:06] <BBB> fate.ffmpeg.org does it every day
[06:06] <BBB> http://fate.ffmpeg.org/report.cgi?time=20130218001421&slot=x86_64-archlinux-gcc-threads-16
[06:12] <highgod> I just use the merge tool to compare the two yuv
[06:31] <BBB> you'd want to use jm to decode the h264 file and check which is correct
[06:32] <highgod> sorry,I tested use ffmpeg -s 1920x1080 -i ./testfile/output.yuv -f framemd5 out.txt, and ffmpeg -s 1920x1080 -i ./testfile/output_dxva2.yuv -f framemd5 out_dxva2.txt.all the same
[06:32] <highgod> 10frames
[06:32] <highgod> I will test more frames
[06:38] <highgod> I test all the 912 for my video,all the md5 code is the same
[06:39] <BBB> then they are identical
[06:44] <highgod> @BBB: the orignal code I implement modified the pthread code, is it can cause the difference? the difference happened on my orignal code. the patch version I tested just now is OK
[06:44] <BBB> I don't know, I didn't see the patch
[06:44] <BBB> messing with pthread is a bad idea in general, unless you know what you're doing
[06:44] <BBB> (I know what I'm doing, so I know how much a bad idea it is)
[06:46] <highgod> hehe,yes.Thanks
[11:11] <ubitux> durandal_1707: about the ffmpeg -help full, i was wondering if it didn't go in infinite loop or something, because of the cross references
[11:11] <ubitux> like it does for instance when you have several filters with the same class
[11:16] <durandal_1707> ubitux: doesn't happen
[11:17] <ubitux> okay, good
[11:17] <durandal_1707> i dont see cross reference
[11:17] <ubitux> seems valgrind is not happy since a little while
[11:17] <durandal_1707> ?
[11:17] <ubitux> durandal_1707: i was refering to multiple options refering to the same flags
[11:17] <ubitux> (my valgrind remark is unrelated)
[11:17] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20130218023828&slot=x86_64-archlinux-gcc-valgrindundef
[11:17] <ubitux> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-valgrindundef
[11:18] <ubitux> i guess d2a25c4032ce6ceabb0f51b5c1e6ca865395a793 is the cause
[11:19] <ubitux> i wonder if libav finally added a real valgrind instance to spot these
[11:20] <ubitux> ah yeah, there is one, in the yellow as well.
[11:20] <michaelni> Compn, did you ask fenrir ? he is the author of libavcodec/dxva2* ...
[11:31] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:39bec05ed42e: qdm2: check array index before use, fix out of array accesses
[11:31] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:f7d18deb73d1: vqavideo: check chunk sizes before reading chunks
[11:31] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:488f87be8735: roqvideodec: check dimensions validity
[11:31] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:96008082dbd3: Merge commit '488f87be873506abb01d67708a67c10a4dd29283'
[11:36] <durandal_1707> ubitux: i gonna write lua filter if none will, using eval is slow and unfriendly
[11:39] <durandal_1707> ubitux: guess what this does: ffmpeg -f lavfi -i color=c=white:size=720x480 -i INPUT -filter_complex "blend=all_expr=B*(if(gte(T\,10)\,1\,mod(T\,10)/10))+A*(1-(if(gte(T\,10)\,1\,mod(T\,10)/10)))"
[11:59] <ubitux> fade? :)
[11:59] Action: ubitux trying
[12:05] <ubitux> yeah e
[12:06] <cone-967> ffmpeg.git 03Luca Barbato 07master:0b70fb1d518c: dsputil: convert remaining op_pixels_func
[12:06] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:f88f7b86a962: Merge commit '0b70fb1d518cbd796545fd6eef02772cd0d892c7'
[12:14] <cone-967> ffmpeg.git 03Diego Biurrun 07master:56632fef65c0: libopencore-amrnb: cosmetics: Group all encoder-related code together
[12:14] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:4ff0e63a015a: Merge commit '56632fef65c0cb6946ed3648ded3d7b82e5c5c17'
[12:19] <cone-967> ffmpeg.git 03Diego Biurrun 07master:e6bda9a9fd86: libopencore-amr: Conditionally compile decoder and encoder bits
[12:19] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:ab213b5360e8: Merge commit 'e6bda9a9fd86505927a2e095e495eae104860701'
[12:26] <cone-967> ffmpeg.git 03Diego Biurrun 07master:8837f4396a1a: libopencore-amrwb: Make AMR-WB ifdeffery more precise
[12:26] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:2220f13d8227: Merge commit '8837f4396a1a458a0efb07fe7daba7b847755a7a'
[12:34] <cone-967> ffmpeg.git 03Diego Biurrun 07master:870a0c669e53: build: The libopencore-amrnb encoder depends on audio_frame_queue
[12:34] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:4b7c81c3e059: Merge commit '870a0c669e536d56c6325d84f65e34c53792398e'
[13:00] <cone-967> ffmpeg.git 03Luca Barbato 07master:aa11cb79318b: build: make audio_frame_queue a stand-alone component
[13:00] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:82e82fa2e5bb: Merge commit 'aa11cb79318baa3415d553424ba378f6c62e1f9b'
[13:11] <cone-967> ffmpeg.git 03Matti Hamalainen 07master:7f3624dc81a1: svq3: unbreak decoding
[13:11] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:0789374ed39a: Merge remote-tracking branch 'qatar/master'
[13:19] <divVerent> haha, I have the very oppposite bug... so maybe this regression fixes my issue :P
[13:19] <divVerent> I just couldn't figure out why -vn doesn't prevent album art from being copied, and also could not find a -map_metadata option to do this
[13:22] <divVerent> BTW, I have four features I cannot "really" enable in ffmpeg... is this normal?
[13:22] <divVerent> http://paste.debian.net/235197/
[13:22] <divVerent> frei0r and libopencv only really can be used with ffmpeg if they are built without ffmpeg support, or we get a cycle :P
[13:22] <divVerent> (yes, I know, cycles can actually be worked around, but not when packaging software)
[13:23] <divVerent> libflite and libilbc apparently don't work, any idea about these? as in, which version of these is ffmpeg known to work with?
[13:24] <divVerent> I noticed these when making an arch linux PKGBUILD that tries to enable virtually everything :P
[13:25] <divVerent> the cycle can be resolved when dynamically linking by first building ffmpeg without the dependency, building the dependency with ffmpeg support, then building ffmpeg with it
[13:25] <divVerent> just can't apply this to packaging
[13:25] <divVerent> just find it funny that ffmpeg supports using libraries that in turn depend on ffmpeg in the usual configurations :P
[13:27] <ubitux> libflite is very recent afaik
[13:27] <ubitux> ask saste when he's back
[13:28] <ubitux> divVerent: btw, don't want your name in the showspectrum copyright?
[13:28] <ubitux> not that is has much legal value in comparison to the git history, but well
[13:30] <divVerent> ubitux: don't care much for that, my changes aren't that big
[13:30] <divVerent> the infrastructure in there is not by me, I only did the drawing part
[13:31] <divVerent> so for my taste, the git history's info alone is ok
[13:31] <divVerent> if you want to add me to the file, go ahead, though
[13:35] <ubitux> ok :)
[13:36] <cone-967> ffmpeg.git 03Clément BSsch 07master:f894246304b3: lavf/showspectrum: add divVerent in the (c) for his recent work on the filter.
[13:36] <divVerent> yes, in retrospect, I should have added that... it's better for ffmpeg to have clean copyright notices, even on minor changes... one too many is better than one too little
[14:09] <durandal_1707> ubitux: so you have no opinion on lua filter?
[14:11] <ubitux> i would be happy to have a lua filter, but actually i think what is lacking is not a lua filter, but a lua filtergraph architecture
[14:11] <ubitux> typically if you want to script an editing scenario
[14:12] <ubitux> basically, a "lua binding" for the lavfi api
[14:12] <durandal_1707> and how it should be implemented?
[14:12] <ubitux> i have no idea
[14:15] <durandal_1707> ubitux: not as filter that does filtergraph?
[14:18] <ubitux> might be interesting
[14:18] <durandal_1707> or ffmpeg script
[14:19] <durandal_1707> ?
[14:20] <ubitux> i'm not sure
[14:20] <ubitux> you should look for common workflow in the anime ripping world
[14:20] <ubitux> we talked about a while ago about that stuff
[14:21] <ubitux> it was things like detect the interlacing (so calling filters and analyze results), then do some processing, maybe do some ad cutting in the middle, or change the de-interlacing method for the op/ed part
[14:22] <ubitux> whatever the solution, imo, this kind of operation should be solvable easily
[14:22] <ubitux> you can imagine processing some filters on part of the video too
[14:23] <ubitux> anyway, that's what the lua scripting should be used for
[14:23] <ubitux> that might be different from what you originally had planned though (aka a geq-like in lua)
[14:23] <durandal_1707> what? no
[14:23] <ubitux> ah i misunderstood then, sorry
[14:24] <durandal_1707> lua filter would just create filtergraph using own stuff
[14:24] <durandal_1707> because using eval for if/else is slow and ugly
[14:25] <durandal_1707> and idea is that "lua filter" would take input as file script
[14:25] <durandal_1707> (i do not use ed for programming ....)
[14:26] <ubitux> a script.lua?
[14:26] <ubitux> that reminds me there was some security concerns about this
[14:27] <ubitux> (about accessing any FFmpeg C functions from a user PoV)
[14:27] <durandal_1707> isn't that implementation problem
[14:27] <ubitux> maybe
[14:28] <durandal_1707> doesn't avisynth/vapoursynth do just that?
[15:14] <ubitux> no idea, i never used that
[15:26] <cone-967> ffmpeg.git 03Ronald S. Bultje 07master:51513b98d62d: h264/svq3: stop using draw_edges.
[15:26] <cone-967> ffmpeg.git 03Ronald S. Bultje 07master:71ae8d50b283: x86/dsputil: fix compilation when h263 decoder/encoder are disabled.
[15:31] <durandal_1707> so in the end ffmpeg logo on web page is strange
[15:48] <Compn> durandal_1707 : you should see mplayer's scriptable 'run' command if you want security trouble ... :)
[15:50] <durandal_1707> that just execute shell?
[15:59] <Compn> yea run sudo rm -rf /
[16:02] <Compn> michaelni : thanks for looking out for mplayer compilation :
[16:02] <Compn> :)
[16:14] <durandal_1707> michaelni: ffmpeg -ss 3 -i /tmp/1.nut gives assertion if nut is ffv1 video with single frame
[17:26] <cone-967> ffmpeg.git 03Paul B Mahol 07master:1f4ab61b746b: lavc/cdxl: clear palette before reading it
[17:31] <BBB> does anyone have qemu-system-arm set up on his system and want to test a series of patches for me?
[17:37] <av500> or a real ARM system
[17:37] <av500> they exist....
[17:37] <BBB> that would be nice also
[17:37] <BBB> anyone?
[17:42] <michaelni> I still have that old beagle board that neither thilo nor me could get fully working with fate, its not fun to use but should do for a single fate test (compared to all fate tests which it just doesnt seem to pass without failing somehow)
[17:43] <michaelni> i dont recommand that though if theres any other solution
[17:44] <cone-967> ffmpeg.git 03Paul B Mahol 07master:85921499c747: cdgraphics: set palette to zero too
[17:44] <michaelni> but if you or another ffmpeg devel wants the board iam happy to put it in a box and send it ...
[17:47] <BBB> I have enough arm devices if I wanted to run fate myself
[17:47] <BBB> I dont' :)
[17:47] <BBB> they're all a pain
[17:49] <BBB> e.g. current version (http://pastebin.com/x4Rcd4RD) may fix arm, but I'm not sure
[17:49] <BBB> it would take me many hours to hook up any arm device and run a test; so if anyone has arm set up, that would be a lot quicker
[18:07] <cone-967> ffmpeg.git 03Paul B Mahol 07fatal: ambiguous argument 'refs/tags/n0.7.14': unknown revision or path not in the working tree.
[18:07] <cone-967> Use '--' to separate paths from revisions
[18:07] <cone-967> refs/tags/n0.7.14:HEAD: cdgraphics: set palette to zero too
[18:09] <durandal_1707> ^ can something be done with this failure?
[18:10] <michaelni> durandal_1707, talk with thresh
[18:11] <BBB> yeah and qemu setup doesn't work either on mac
[18:11] <BBB> bah
[18:12] <BBB> slightly better version: http://pastebin.com/EDT4BWV8
[18:12] <BBB> still untested, but maybe it works
[18:12] <av500> one will never know...
[18:12] <BBB> I s'pose
[18:13] <BBB> I believe one of my computers has an android sdk installed somewhere, and I was able to connect to my phone at least at some point for some testing
[18:15] <durandal_1707> michaelni: anyway, I did not touched 0.7.14 and i dot plan to, also i dont see it in web interface
[18:18] <michaelni> durandal_1707, yes, cone has a bug with tags it posts nosnense, thresh and j-b are cones masters, ask them what is wrong with code / if it can be fixed
[18:19] <michaelni> s/code/cone/
[18:20] <michaelni> the repo is always fine / unaffected its just what is printed to IRC thats a bit off
[19:04] <durandal_1707> are there files/samples where stereo3d filter is useful
[19:04] <durandal_1707> i plan to port this filter
[19:08] <durandal_1707> michaelni: gonna fix that assert in nut or should i fill bug?
[20:14] <durandal_1707> -filter_complex "showwaves=mode=line:size=976x240[out3],split[one][two],[one]histogram=mode=waveform:waveform_mode=row:display_mode=overlay[out1],[two]pad=976:720[out2],[out2][out1]overlay=720:0[x],[x][out3]overlay=0:480"
[20:19] <ubitux> does it work?
[20:19] <ubitux> (doesn't seem so here for unknown reason)
[20:20] <durandal_1707> what error you get?
[20:20] <ubitux> "Open inputs in the filtergraph are not acceptable"
[20:21] <ubitux> but i'm not using filter_complex here
[20:21] <durandal_1707> you should
[20:21] <durandal_1707> thought i dunno what that error means
[20:21] <durandal_1707> i display it with ffmpeg sld muxer
[20:21] <durandal_1707> *sdl
[20:22] <ubitux> oh good idea the ffmpeg sdl
[20:22] <durandal_1707> ffplay is in bad shape
[20:22] <ubitux> will try, after i figure out the problem
[20:27] <ubitux> it's strange..
[20:27] <durandal_1707> blend=all_expr=if(eq(mod(X\,2)\,mod(Y\,2))\,A\,B)
[20:33] <ubitux> ok get it.
[20:45] <ubitux> Open inputs in the filtergraph are not acceptable. Orphan inputs: "in" "(null)"
[20:45] <ubitux> erm.
[20:46] <ubitux> actually, just "(null)"
[20:50] <ubitux> durandal_1707: ./ffplay -f lavfi "amovie=niea7-op.mp3,showwaves=mode=line:size=976x240,split[waves1][waves2]; [waves1]split[a][b]; [a]histogram=mode=waveform:waveform_mode=row:display_mode=overlay[hist]; [b]pad=976:720[padded]; [padded][hist]overlay=720:0[over]; [over][waves2]overlay=0:480"
[20:50] <ubitux> is that the same?
[20:50] <ubitux> maybe a split=3 would make more sense
[20:52] <ubitux> so ./ffplay -f lavfi "amovie=niea7-op.mp3,showwaves=mode=line:size=976x240,split=3[a][b][c]; [a]histogram=mode=waveform:waveform_mode=row:display_mode=overlay[hist]; [b]pad=976:720[padded]; [padded][hist]overlay=720:0[over]; [over][c]overlay=0:480"
[21:01] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:695a766bff4c: ff_read_timestamp: check stream_index before using it as array index
[21:01] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:6cd650dbd2be: ff_gen_search: Fix finding the maximum timestamp in a really small file
[21:01] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:e39821a65e42: nutenc: only write an index if there are syncpoints
[21:04] <durandal_1707> michaelni: what? seek does not return -1 any more for lavf-ogg?
[21:05] <durandal_1707> :)
[21:11] <michaelni> yes it matches asf/mpg in that now
[21:11] <michaelni> or nut
[21:18] <cone-967> ffmpeg.git 03Paul B Mahol 07master:480ddf2bc9c0: lavfi/histogram: overlay display mode for levels histogram mode
[21:50] <Compn> durandal_1707 : youtube outputs some 3d stuff ,like side-by-side samples
[21:50] <Compn> stereo3d can convert between side by side, top/bottom, and red/blue (amongst a bunch of other colors for analgylph 3d)
[21:50] <Compn> also frame interleaved or something
[21:50] <Compn> probably
[21:53] <durandal_1707> and there is sample, with which filter is used?
[21:55] <durandal_1707> i can use any video, but would like to have one where output will make more sense
[21:57] Action: durandal_1707 should probably google it
[22:05] <Compn> durandal_1707 : oh, well you take a side by side and use stereo3d to convert it to red/blue i guess
[22:05] <Compn> i think i wrote examples on the wiki
[22:05] <Compn> one sec
[22:06] <Compn> oh no
[22:06] <Compn> i wrote this one
[22:06] <Compn> http://wiki.multimedia.cx/index.php?title=How_to_make_a_3d_movie_with_ffmpeg
[22:06] <Compn> this page has mencoder options > http://www.mtbs3d.com/phpbb/viewtopic.php?f=27&t=4521
[22:07] <Compn> er page 3 of that does > http://www.mtbs3d.com/phpbb/viewtopic.php?f=132&t=4521&start=30
[22:31] <cone-967> ffmpeg.git 03Ronald S. Bultje 07master:e2789d3e3399: split out ff_hwaccel_pixfmt_list_420[] over individual codecs.
[23:05] <wm4> what is the state of a demuxer after a failed av_seek_frame()?
[23:05] <wm4> in particular, what does av_read_frame() return?
[23:10] <wm4> I think it_'s reproducible with ffplay and a .flac file
[23:11] <wm4> hit the cursor down and cursor left keys at the same time a few times at the beginning of the file
[23:11] <wm4> and you get errors like [flac @ 0x9106220] invalid sync code
[23:11] <wm4> and it only happens after "error while seeking" is printed
[23:12] <saste> llogan, any news from mike?
[23:14] <llogan> saste: no reply yet.
[23:14] <llogan> although i would like to get started on it soon
[23:15] <durandal_1707> on what?
[23:17] <wm4> hm I guess a ticket will generate more attention
[23:17] <llogan> i asked him about using his wiki again for the GSoC idea list and if he didn't mind keeping up with any new requests for edit permissions
[23:18] <michaelni> wm4, the state after failed seek is undefined (that is how it is currently, not neccesarily what we want it to be)
[23:18] <durandal_1707> llogan: you need permisison to edit gsoc page?
[23:18] <wm4> michaelni: well, it appears for some formats it works, and for some (flac) it doesn't
[23:19] <wm4> michaelni: and by "works" I mean unconditionally resetting the decoder, and then calling av_read_frame() and feeding that to the decoder
[23:19] <durandal_1707> flac use generic seek
[23:19] <llogan> durandal_1707: you need an account to edit http://wiki.multimedia.cx ...or maybe an account with editing permissions, either way mike has to manually do something
[23:19] <michaelni> wm4, reset is easy the hard part is to be in the same state as before the failed seek was attempted
[23:20] <wm4> michaelni: so I would suggest: seeking before start of the file -> clamp seek position to 0 (and always succeed seeking), and seeking past the end of the file => return EOF (and let av_read_frame() return EOF too)
[23:20] <michaelni> llogan, you can just use trac wiki
[23:21] <llogan> i know, and i like the trac wiki for the most part, but saste mentioned that a more strict permission might be good in this case
[23:21] <llogan> last minute troll vandalism, etc
[23:22] <durandal_1707> trac wiki can't have finer permissions?
[23:22] <michaelni> can be done somehow AFAIK but i dunno how
[23:23] <llogan> probably, but michael has better things to deal with
[23:23] <llogan> if i don't hear from him by tomorrow i'll just use our wiki.
[23:25] <durandal_1707> i could do it...
[23:32] <saste> http://trac.edgewall.org/wiki/TracFineGrainedPermissions
[23:32] <saste> so yes it is possible
[23:32] <wm4> how can I seek with "ffmpeg" again?
[23:32] <durandal_1707> wm4: only once -ss
[23:33] <saste> i have no objection into using our wiki if we can implement dev-only access on the gsoc page
[23:33] <wm4> ok... that's not enough
[23:34] <durandal_1707> saste: it appears doable, but from friendly
[23:34] <durandal_1707> *far
[23:36] <saste> durandal_1707, what do you mean, unfriendly towards whom?
[23:36] <durandal_1707> the trac
[23:37] <saste> gsoc page should be edited only by candidate mentors or developers
[23:37] <saste> there is no much point into allowing a random user to edit it
[23:38] <saste> we never did like that in the past years
[23:41] <durandal_1707> i mean cofiguring finer permissions for trac are unfriendly.
[23:42] <durandal_1707> llogan: why you plan to put for gsoc?
[23:43] <durandal_1707> *what
[23:43] Action: durandal_1707 needs to sleep
[23:44] <llogan> i was going to copy most of last year's and let interested devs/mentors edit it. then i was going to make sure it is formatted well and in a good layout before google views it
[23:44] <llogan> scrolling marquees, page counter, some flash, gifs, etc.
[23:45] <durandal_1707> flash?
[23:45] <llogan> bad joke
[23:45] <llogan> durandal_1707 needs to sleep more
[00:00] --- Tue Feb 19 2013