[00:54] <freezway> so I'm working on a music sorting program using libavformat and need to use it to read the metadata. The problem is some (poorly formed) files I have the metadata in the wrong spots. For example while a good file has the metadata inside input #0 a bad file might have it under Duration inside input#0 (as far as I can tell from ffprobe). I am currently using the metadata found under AVFormatContext->metadata [00:55] <freezway> is there a better way to do this where it'll find the metadata no matter what? [00:59] <freezway> oh whoops, sorry didn't read the /topic [02:53] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:d0004a1959ec: avcodec/kgv1dec: fix memleak, reintroduce lost decode_flush() call [04:31] <BBB> pengvado: oh wow... so... do you recommend we take this up with the yasm maintained and ask for a new release, or you think we should apply your workaround until yasm is fixed (or both), or ... I'm ok with anything really [04:34] <BBB> I guess local workaround is fastest [05:22] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:3ca7085ae2f7: avcodec: make "bitrate tolerance too small for bitrate" error more verbose [06:05] <cone-6> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n0.10.11': unknown revision or path not in the working tree. [06:05] <cone-6> Use '--' to separate paths from revisions [06:05] <cone-6> refs/tags/n0.10.11:HEAD: avcodec: make "bitrate tolerance too small for bitrate" error more verbose [08:09] <ubitux> is there any x86_64 cpu without ssse3? [08:10] <nevcairiel> yes [08:11] <ubitux> ok [08:11] <ubitux> (can you name one?) [08:11] <nevcairiel> especially AMD has been rather late with supporting SSSE3 [08:11] <ubitux> mmh [08:11] <nevcairiel> so first gen athlon64 for sure [08:11] <nevcairiel> even first intel 64 dont have it [08:11] <nevcairiel> ie. Pentium D [08:11] <ubitux> mmh okay [08:12] <ubitux> thanks [08:12] <nevcairiel> the first x86_64 cpu was released 2003, the first with SSSE3 in 2006 [08:12] <nevcairiel> you do the math [08:12] <nevcairiel> :D [09:59] <plepere> hello [12:57] <kriegerod> the build is broken, do you know? [12:57] <kriegerod> libavcodec/vc1dec.c:5185: undefined reference to `ff_intrax8_decode_picture' [12:57] <kriegerod> etc. [12:57] <Rodeo> kriegerod: FATE seems greenish http://fate.ffmpeg.org/?dsort=date [12:58] <BBB> kriegerod: make clean; configure; make [12:59] <kriegerod> hm okay, i'll reconfigure [12:59] <BBB> oh really the lpf is 99% sse2 [12:59] <BBB> that's pretty good [13:00] <kriegerod> it just didn't warn me that configure has changed as it happens sometimes [13:01] <BBB> it's also quite easy to make a sse2 mc, if anyone is interested (see vp8 for examples) [13:01] <kriegerod> is it possible to somehow detect the need for reconfigure at just `make`? [13:01] Action: BBB no build expert [13:10] <J_Darnley> Can someone help me work out why I get this error while running fate: http://pastebin.com/iuj9WAd1 [13:15] <BBB> J_Darnley: make fate-rsync [13:16] <BBB> (you're missing a sample) [13:16] <J_Darnley> I am not [13:16] <J_Darnley> I did that less than 12 hrs ago [13:19] <J_Darnley> $ ls -l /cygdrive/z/fate-samples/bmp/test1.bmp [13:19] <J_Darnley> -rwx------ 1 ???????? ???????? 1086 Mar 31 2012 /cygdrive/z/fate-samples/bmp/test1.bmp [13:21] <nevcairiel> are you sure --enable-protocol='file,pipe,md5' works? Not sure i've seen it used before.. [13:34] <BBB> J_Darnley: other alternative is that the command is crashing, try "make V=1 fate-bmp-1bit" to see what ffmpeg command it's running and run that yourself manually [13:38] <Daemon404> i dont think anyone regularily test or runs ffmpeg on cygwin at all [14:00] <J_Darnley> Daemon404: There is a cygwin machine runnig fate which successfully ran 15 hours ago: http://fate.ffmpeg.org/history.cgi?slot=x86_64-win7-cygwin-gcc-4.5.3 [14:03] <Daemon404> nifty. [14:03] <J_Darnley> nevcairiel: that is the recomended way to do it. [14:07] <ubitux> BBB: any objection to applying the lpf sse2 patch [14:07] <ubitux> ? [14:07] <BBB> not at all [14:08] <ubitux> ok [14:08] <ubitux> BBB: btw, i can't do the 4_16 and 8_16 easily [14:08] <ubitux> it's not the good way around :p [14:08] <BBB> ? [14:08] <BBB> huh? [14:08] <BBB> what does that mean [14:08] <ubitux> it's not 16 wide [14:08] <ubitux> it's 16 height [14:08] <BBB> ? [14:09] <BBB> it does 16 pixels at once, with a filter of size 4 or 8 [14:09] <ubitux> i mean it's not just disabling filter14() and filter6() [14:09] <BBB> it is [14:09] <BBB> look at the c implementation [14:09] <BBB> in c it's called 44_16 and 88_16 [14:09] <ubitux> maybe i misunderstood [14:09] <ubitux> aaah [14:09] <ubitux> ok [14:10] <ubitux> i can do those then :) [14:10] <BBB> and 84_16 and 48_16 are the mix functions which are essentially 88_16 with a fixed zero-mask for the 4-half of filter6 [14:10] <BBB> yeah sorry the c is a little tricky [14:11] <BBB> the c is basically written that way to make simd easier, but maybe that wasn't obvious because it's hidden in macros :-p [14:11] <ubitux> i was thinking about 8_16 and 4_16 [14:11] <ubitux> no 44_16 and 88_16, i guess [14:11] <ubitux> not* [14:12] <BBB> I bet you were looking at lf_8_fns(16) [14:12] <BBB> which is 16_8 [14:12] <BBB> and then 16_16 just calls 16_8 twice (in c) [14:12] <BBB> you wrote 16_16 in straight simd [14:13] <BBB> that's lf_16_fn(h, stride) [14:13] <BBB> and then the interesting parts for 44_16 and 88_16 are lf_mix_fns(4, 4) [14:13] <BBB> and the other 3 [14:13] <ubitux> yeah sorry i was confused yesterday night [14:13] <ubitux> :)) [14:15] <BBB> like I said, the c code is a little confusing [14:15] <BBB> but I do believe it makes simd faster [14:17] <cone-6> ffmpeg.git 03James Almer 07master:d2a7314f1e0d: vp9/x86: add ff_vp9_loop_filter_[vh]_16_16_sse2(). [14:38] <cone-6> ffmpeg.git 03Martin Storsjö 07master:03f2de5856ec: aviocat: Check the argv array length before reading element i+1 [14:38] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:9f3a555b84ba: Merge commit '03f2de5856ec8571fcf5f4cf6dccc713294af545' [14:44] <cone-6> ffmpeg.git 03Martin Storsjö 07master:87acd33c092a: aviocat: Add support for specifying the input duration [14:44] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:c8b99f8ad058: Merge commit '87acd33c092ab9e7d73686627e9105d99c1e4928' [15:05] <cone-6> ffmpeg.git 03Luca Barbato 07master:ff23c4e4935e: doxy: Add AVFrame to the structured modules [15:05] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:68ebf70f665b: Merge commit 'ff23c4e4935e96e62d8ff2212a1955a43add88e1' [15:09] <J_Darnley> Well my problem is that ffmpeg seems to think it is supposed to find an image sequence [15:17] <cone-6> ffmpeg.git 03Luca Barbato 07master:045654f422e7: doxy: Document better the available AVFrame flags [15:17] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:045d80076a67: Merge commit '045654f422e74be8ed09a0819d39051d67633a09' [15:20] <J_Darnley> There's no option to tell ffmpeg to not look for a pattern!? [15:29] <cone-6> ffmpeg.git 03Anton Khirnov 07master:f9cc6883a4e5: mp3enc: add an option for disabling the Xing frame. [15:30] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:5049b6a1fe52: Merge commit 'f9cc6883a4e5cf72cbfa21d17e1908a2a432f6bd' [15:45] <J_Darnley> git add -i [15:45] Action: J_Darnley swears [15:49] <ubitux> any reason yasm is prefered over nasm btw? [15:50] <JEEB> http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=a7fd9f5da062de323ae... [15:50] <JEEB> this was the original reason [15:51] <ubitux> ok [15:52] <ubitux> right now with the macro exhaustion bug, it takes 4.83s with nasm, and 39.46s with yasm [15:53] <JEEB> anyways, it seems like nasm did get a nice amount of development at least commit-wise since, and yasm mostly died out after yasm-nextgen seems to have not become A Thing [15:53] <JEEB> both should be reviewed IMHO [15:53] <JEEB> not that I have much of an idea how to test them :P [15:54] <cone-6> ffmpeg.git 03Anton Khirnov 07master:33018907bd07: mp3enc: allow omitting the id3v2 header with -id3v2_version 0 [15:54] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:58770db2ae67: Merge commit '33018907bd07b34e0e70d5ae12097265eb3734d7' [16:17] <J_Darnley> Oh screw it! I'll just use -k and hope I don't miss the changes I'm looking for. [16:18] <cone-6> ffmpeg.git 03Anton Khirnov 07master:2ce8bca51f72: avconv: print a warning when falling back to default 25fps [16:18] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:206c06d96f68: Merge commit '2ce8bca51f7264b47027f69d50dd8e49aa2fd683' [16:33] <cone-6> ffmpeg.git 03Anton Khirnov 07master:5ef11b8dcc05: yuv4mpeg: set average frame rate [16:33] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:6e2d3ba0eea1: Merge commit '5ef11b8dcc054b230deb9b20493255c14a80597d' [16:42] <Compn> ubitux : yasm was more widely installed in distros i guess [16:42] <Compn> i dont remember exactly... [16:43] <nevcairiel> there used to be more issues with nasm over the last couple years that i've paid attention then with yasm [16:43] <nevcairiel> but of course that could only be because every dev builds it for yasm [16:43] <nevcairiel> so shrug [16:43] <Compn> then we supported both because its always good to work on multiple tools... [16:43] <Compn> like multiple compilers, intel, clang, gcc [16:43] <Compn> a warning on one is an error on another [16:43] <nevcairiel> both are still supported today [16:43] <Compn> right [16:44] <cone-6> ffmpeg.git 03Anton Khirnov 07master:104a97beaffa: buffersrc: handle non-refcounted frames in av_buffersrc_add_frame() correctly [16:44] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:cd259cdaa947: Merge commit '104a97beaffa6348e6fd2c2d07d67c1402322bb3' [16:48] <michaelni> ubitux, do you have time to review ' mpegts muxer and demuxer: correct DVB teletext processing' patch from Andriy Lysnevych on ML ? [16:48] <ubitux> i'm not familiar with that area [16:49] <ubitux> ask marton maybe [16:49] <ubitux> he worked on the teletext decoder [16:57] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:c9db8694a836: avisynth: fix setting packet properties [16:57] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:f1edf881ef83: Merge remote-tracking branch 'qatar/master' [17:05] <michaelni> ubitux, ok, sent mail [17:05] <ubitux> maybe kierank or reimar know too :p [17:08] <michaelni> now if my time machine wasnt broken i could add them to CC ... [17:08] <Compn> michaelni : i have a sample that previously (back in 2008) used INMC fourcc for mpeg4 asp , but i got a sample the other day that has INMC but is h264... [17:09] <michaelni> Compn, where can i find both these samples ? [17:09] <Compn> i have the new one, but i dont seem to have the one from 2008 [17:10] <cone-6> ffmpeg.git 03Carl Eugen Hoyos 07master:ee3fc8aa864f: Fix libxvid crash on failing initialisation. [17:10] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:68ed0b6cd111: Merge remote-tracking branch 'cehoyos/master' [17:10] <Compn> i meant 'there is a codec that previously used inmc' :) [17:11] <Compn> because i cant find the old sample now :) [17:12] <Compn> my idea was to have a special decoder for unknown fourccs, and it tests the most common decoders, if it finds errors it skips to the next decoder. [17:12] <nevcairiel> you mean like probing works today? :d [17:12] <Compn> sure :) [17:12] <Compn> can we do codec probing ? :) [17:12] <Compn> on unknown fourccs ? :)) [17:14] <nevcairiel> probing is only supported for a couple codecs, but it would try to probe for those if its unknown [17:32] <Compn> i wish i could find the old sample [17:46] <Compn> michaelni : idea for noise reduction video filter based on photoshop 'average composite' , http://spreadys.wordpress.com/2013/10/14/a-few-helpful-hints/ [17:46] <Compn> wonder how well it works vs our filters [17:50] <{V}> Compn, maybe you can create a sample http://spreadys.wordpress.com/2013/07/27/inmc-codec-update/ [17:50] <{V}> (of the INMC thing) [17:53] <{V}> oh same blog. oops :) [17:53] <Daemon404> that blog is full of retarded stuff... [17:55] <wm4> "I have now placed this .dll into my SMplayer Pack and configured the codecs.conf accordingly." [17:55] <wm4> :( [17:57] <Compn> why are you sad wm4 ? [17:57] <wm4> that someone uses the horrible mplayer dshow interop code [17:57] <wm4> in 2014 [17:58] <Compn> its not like codec manufacturers provide source and c-compiled libs ;p [17:58] <wm4> they could just use a real dshow player [17:58] <Compn> {V} : pretty sure its decode-only codec but i'll take a look at it [17:59] <{V}> oh [17:59] <Compn> wm4 : he explains elsewhere on the blog why he dislikes codec installers [17:59] <Compn> common complaint is that they mess up peoples computers easily [18:00] <Compn> take over decoding , break decoding, add watermarks, etc [18:00] <Compn> upsidedown decoding :D [18:00] <Compn> of all divx video... [18:02] <Compn> {V} : Loaded DLL driver MultiCodec.dll at 10000000 . Failed to open the encoder. [18:02] <Daemon404> [16:57] <+wm4> that someone uses the horrible mplayer dshow interop code [18:02] <Daemon404> um [18:02] <Daemon404> its vfw [18:02] <Daemon404> not dshow [18:02] <Daemon404> get your shit right bro [18:02] <wm4> k [18:02] <nevcairiel> fact remains, its shit =P [18:03] Action: Compn lobbies for dll loader in ffmpeg [18:03] <Compn> bwahaha [18:03] <Daemon404> the guy seems to be pretty clueless from rading his blog [18:03] <wm4> mplayer has both [18:03] <Daemon404> he uses tools that were cool in 2001 [18:03] <Compn> Daemon404 : shh, his vb skillz are leet [18:03] <iive> The text says this is "Multi-standard video codec". so most probably it should be treated as container inside container. [18:03] <Daemon404> Compn, i like is 'video concatenator' [18:03] <Daemon404> his* [18:04] <Compn> he keeps putting h264 in avi. :\ [18:04] <Daemon404> [17:03] <@Daemon404> the guy seems to be pretty clueless from rading his blog [18:04] <nevcairiel> so many people put all kinds of shit in avi [18:04] <Daemon404> whats scary is that these are the people who can help or fuck up putting others in prison. [18:04] <Compn> yep [18:05] <Compn> comes down to 1s and 0s [18:05] <Compn> ... and mplayer's binary loader [18:05] <Compn> (dont live in america if you can avoid it) [18:06] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:ee27b113069e: avformat/riff: fix demuxing of h264 INMC [18:06] <JEEB> h.264 in avi reminds me of this guy called timecop :P [18:07] Action: Daemon404 lives in america lite [18:07] <Daemon404> you can go to jail for tweeting here! [18:07] <Daemon404> :D [18:08] <Compn> thats awesome [18:08] <Compn> at least you still have jail [18:08] <Compn> we have secret jail [18:08] <Daemon404> >implying uk doesnt [18:09] <Compn> you got a queen and a princess now or something [21:30] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:f1caaa1c6131: dnxhdenc: fix mb_rc size [21:30] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:19df5dcb4734: avcodec/dnxhdenc: check that qmax is within the supported range [21:30] <cone-6> ffmpeg.git 03João Bernardo 07master:447d71b89213: avfilter/vf_elbg: Fixed seed range of elbg filter [22:12] <wm4> michaelni: so, can Ben Boeckel's ogg tag patches be merged? [22:40] <michaelni> wm4, one of the pactches has a comment by ubitux [22:40] <michaelni> the others have issues too i think, but let me do a proper review [22:40] <ubitux> https://github.com/DarkShikari/x264-devel/commit/8a27cd68d3d6137b8a38ccef177... [22:40] <ubitux> should we pick that? [22:42] <nevcairiel> we usually backport x86inc changes to keep as close as possible to upstream [22:55] <michaelni> nevcairiel &, ubitux yes [23:09] <michaelni> wm4, ogg patches review done (or at least i think all patches got a review now) [23:10] <wm4> michaelni: thanks [23:16] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:ed7f1a5c2076: avformat/metadata: allow ff_metadata_conv() to be called with NULL saftely [00:00] --- Sat Jan 18 2014