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

burek burek021 at gmail.com
Sat Sep 13 02:05:02 CEST 2014


[00:08] <J_Darnley> I wonder if that email I just sent is verbose enough.
[00:17] <jamrial> michaelni: don't forget to cherry pick c619e14c314b44d86a8d552259afb957c0b6775d as part of the fix for ticket #3943
[00:21] <rcombs> J_Darnley++, re: transforming -- into 
[00:26] <michaelni> jamrial, backport where, and what fix ?
[00:27] Action: michaelni looks at "Commit:     Carl Eugen Hoyos <cehoyos at ag.or.at>"
[00:28] Action: michaelni looks at fflogger
[00:28] <michaelni> jamrial,  "<cone-520> ffmpeg.git Michael Niedermayer release/2.1"  <--- carl backported these not me
[00:33] <jamrial> ah, my bad. forgot to check who committed them
[00:35] <jamrial> ok, i'll do it
[00:38] <cone-722> ffmpeg.git 03James Almer 07release/2.1:fc82ba06ee87: avformat/oggparseopus: Check opus_duration() return value
[00:52] <J_Darnley> rcombs: I just decided to stick what I saw in a @code section like the many other commands
[00:55] <Timothy_Gu> ubitux, jamrial: What's the difference between the pixelutils SAD and the me_cmp sad?
[00:58] <jamrial> the pixutils one was made to remove lavc dependency to several filters
[01:06] <Timothy_Gu> jamrial: why did ubitux rewrite some asm for pixelutils instead of just using the avcodec one?
[01:06] <Timothy_Gu> Also 94865 warnings on icc WTF: http://fate.ffmpeg.org/report.cgi?time=20140911211522&slot=x86_64-linux-gnu-icc-2011_sp1.13.367
[01:09] <nevcairiel> its full of crazy wrong warnings
[01:15] <jamrial> because he also made some changes to it, like removing the MpegEncContext argument, or using separate linesizes for each source
[01:20] <BBB> see, I tought something was broken
[01:20] <BBB> I hadnt received any chats in days
[01:50] <J_Darnley> Timothy_Gu: I'll address your comments, and anyone else's, in the morning.
[01:50] <Timothy_Gu> J_Darnley: What's your time zone? I.e. what is "morning"? It's 4:50 PM here.
[01:51] <J_Darnley> +2
[01:51] <J_Darnley> utc+2 that is
[01:51] <Timothy_Gu> WTH you are awake 2:00 in the morning??
[01:52] <Timothy_Gu> But OK. Have a nice sleep!
[01:52] <J_Darnley> Yes.  I'm a lazy git out of work at the moment.
[03:26] <cone-722> ffmpeg.git 03James Darnley 07master:e3fb2b0eb7c5: docs: add example around the suggested commit message format
[03:30] <Timothy_Gu> holy shit I found an ffmpeg-0.3.2.tar.gz with timestamps from 2001
[03:33] Action: Timothy_Gu stashes that into his stash of pre-0.5 tarballs https://launchpad.net/ffmpeg/pre-0.5
[03:33] <wm4> open source archeology?
[03:58] <Timothy_Gu> yep :) haven't found 0.3, 0.3.1, and 0.3.3 though
[03:58] <Timothy_Gu> http://www.filewatcher.com/ really helps
[04:00] <wm4> and 0.1, 0.2?
[04:00] <wm4> do they even exist?
[04:00] <Timothy_Gu> nope, only up to 0.3. See Changelog
[04:01] <wm4> ah
[04:53] <jamrial> ^that ticket could be considered a missing documentation case
[04:54] <jamrial> there's apparently no x265 entry in encoders.texi
[05:01] <Timothy_Gu> jamrial: Agreed. You'll have to ping Daemon404 though
[05:02] <jamrial> i reopened the ticket and edited it to reflect this
[10:04] <wm4> ubitux: apparently "milkdrop" is the best audio visualization ever
[10:46] <ubitux> wm4: that's because you haven't seen the one from J_Darnley yet :s
[10:50] <wm4> hm
[10:52] <rcombs> ubitux: any chance you have example output?
[10:52] <ubitux> i have no idea what it looks like :)
[10:55] <rcombs> I wonder how practical it would be to port milkdrop to& not D3D
[10:56] <wm4> rcombs: there's a GL port
[10:56] <wm4> used by audacious
[10:57] <rcombs> ProjectM?
[10:57] <rcombs> (as opposed to the Melee-for-Brawl thing)
[10:59] <wm4> yes
[10:59] <rcombs> projectM-emscripten <-- wat
[10:59] <wm4> you want visualizations in the browser too
[11:00] <wm4> also you'll have to get rid of your "wat" whenever emscripten is mentioned
[11:00] <wm4> this kind of stuff is "normal" now
[13:44] <wm4> michaelni: I'm starting to think image2 patterns should be treated as a protocol
[13:44] <wm4> think: image://somethng%02.jpg
[13:44] <wm4> mplayer also does this (but with mf:// )
[13:44] <wm4> no more probe trouble
[13:58] <thardin> no a bad idea
[14:07] <thardin> not
[14:53] <michaelni> wm4, i think we should fix the bug and not connect it to a redesign that will break other things like http and ftp with image%d.jpg
[14:54] <michaelni> that is IMO apply one of the patchsets and leave  the redesign to a seperate future patchset 
[15:14] <Compn> michaelni / wm4 : yes, i agree. adding a new way ex. mf://*jpg is better than changing the old design
[15:14] <Compn> and breaking scripts :\
[16:21] <benoit-> michaelni, wm4: I'm fine with the strcmp("image2") as it seems better to rethink the design afterwards
[17:16] <ubitux> michaelni: what is the finer level values you are talking about for the ass patch?
[17:16] <ubitux> the value "3" is basically not used in libass
[17:17] <ubitux> i dupped the 2nd value, in case something come up
[17:17] <ubitux> same for the info one
[17:17] <ubitux> the previous code had a finer granularity, but it was wrong
[17:29] <ubitux> https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/ffmpeg&id=1f4d80031997a9db937582d79a2784cec846a6aa wtf
[17:29] <ubitux> any idea what's going on here?
[17:39] <nevcairiel> some dude with no clue how it works?
[17:42] <nevcairiel> they also have --enable-dxva2 in a linux build script, so ...
[17:44] <Compn> ubitux : maybe theres some disabling being done by user ?
[17:44] <Compn> and they need to force these codecs enabled ?
[17:44] <Compn> maybe its causing some build error somewhere
[17:44] <ubitux> no, it's just braindead
[17:44] <Compn> yes it looks braindead.
[17:44] <ubitux> i tried that configure line with and without
[17:44] <ubitux> the config.h is the same
[17:45] <ubitux> (except the configure line)
[17:45] <ubitux> nevcairiel: missed that...
[17:46] <ubitux> i'm wondering about --enable-pic as well
[17:46] <ubitux> and --enable-postproc which should be enabled as well
[17:47] <nevcairiel> well i have a few redundant enables in my configure as well probably, but explicit decoders and enable-dxva2 on the wrong platform is really over the top :D
[17:50] <ubitux> the guy is telling me that's for some coop with PPSSPP or something
[17:50] <ubitux> that atrac3 used to be disabled without explicit flag (wtf?)
[17:51] <ubitux> and the guy don't see anything wrong with keeping them in here
[17:51] <ubitux> ..
[18:02] <ubitux> nevcairiel: ok that's the same guy
[18:02] <ubitux> https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/ffmpeg&id=f309d90d29d6f052f750ffa7ce0455a33b13a7b0
[18:02] <ubitux> he doesn't seem to have much clue
[18:02] <ubitux> this was reverted (fortunately), but see: https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/ffmpeg&id=b20b553d74417cae5eb84fc02ab1cfa3ed653f48
[18:02] <ubitux> (the _asm part)
[18:03] <kepstin-laptop> hmm, I was under the impression that some of the ffmpeg assembly didn't work on 32bit with pic enabled, because pic required an extra register.
[18:04] Action: kepstin-laptop wasn't responsible for the arch package, of course.
[18:04] <ubitux> then maybe --enable-pic should be dropped?
[18:06] <kepstin-laptop> gentoo allows conditionally enabling pic with a use flag; I think it's required for some of the optional security-related stuff gentoo supports. But I don't think arch has anything like that.
[18:13] <michaelni> ubitux, i meant that you could do something like (AV_LOG_WARNING + AV_LOG_ERROR)/2 if you want a intermediate value
[18:13] <ubitux> ah, we can do that?
[18:13] <michaelni> yes
[18:20] <Compn> kepstin-laptop : its possible, theres an outstanding bug in gcc with ffmpeg. ehe
[18:20] <Compn> i think they closed it though :\
[18:30] <cone-305> ffmpeg.git 03Michael Niedermayer 07master:321c3cd1a97b: avformat/img2dec: reduce bmppipe probe score
[18:30] <cone-305> ffmpeg.git 03Michael Niedermayer 07master:917d14e6a20d: avformat/format: Run image2 probe again when file content data is available
[19:02] <cone-305> ffmpeg.git 03Michael Niedermayer 07master:b3fd2b175c90: avformat/img2dec: Fail probing when no data is yet available and the filename contains no number/glob patterns either.
[22:31] <J_Darnley> Oh my god!  A patch for 586 cpus?
[22:32] <iive> well, this means somebody is using it.
[22:36] <J_Darnley> Perhaps they have just finished their last fate run and seen the failure.
[22:36] <nevcairiel> you mean the first fate run since the cpu was new 20 years ago?
[22:36] <nevcairiel> :D
[22:37] <nevcairiel> it just took this long
[22:37] <J_Darnley> That is the joke I tried and failed to make. :(
[22:37] <nevcairiel> well the one change looks sensible, should disable i686 when using --cpu=i586
[22:37] <nevcairiel> the others.. i dont like
[22:55] <kepstin-laptop> hmm, I should try to get my k6-2 box up and running, I might be able to get fate running on there.
[22:57] <cone-305> ffmpeg.git 03Mikulas Patocka 07master:cdb3eee7c496: configure: Fix miscompilation for i586
[00:00] --- Sat Sep 13 2014


More information about the Ffmpeg-devel-irc mailing list