[00:13] Action: Compn has idea for ffmpeg website banner with drone flying in the sky [00:14] <Compn> http://farm9.staticflickr.com/8150/7318030594_62ec2381cf_z.jpg [00:14] <Compn> possibly with droney [01:00] <llogan> i suppose i could have reverted instead... [06:22] <Zeranoe1> Can FFmpeg with with reentrant? [07:26] <ubitux> huh audio example doesn't reconstruct packets either [07:26] <ubitux> broken examples finally reported [09:22] <ubitux> kierank: i don't understand what you suggest in the vp9 4x4 [09:23] <ubitux> m4 is 64 bits [09:25] <kierank> It's 128 bits, no? [09:25] <nevcairiel> if its sse, it should be [09:26] <ubitux> mmh i assumed it was 64 because all my ops rely on this being 64 [09:26] <nevcairiel> in sse those names map to the xmm registers [09:27] <ubitux> mmh [09:27] <ubitux> i guess i could do simplify that then [09:27] <ubitux> since this code does not work with mmx anyway [09:28] <ubitux> but then the number of xmm registers is wrong in the prototype [10:01] <saste> how is -faststart still relevant nowadays? [10:01] <saste> which players are affected by that? [10:01] <saste> at least with ffplay/vlc i see no difference in playback startup time [10:01] <ubitux> some flash players and httpd with no range request [10:01] <ubitux> i guess [10:02] <saste> thanks [10:17] <durandal_1707> remove unused function from vp8 ? when ? [10:19] <ubitux> ? [10:28] <saste> Doom9 Forums Compromised [10:28] <saste> why do we have such a news on our page?? [10:28] <durandal_1707> because of Compn [10:28] <durandal_1707> Compn: you did not sent it for review [10:29] <durandal_1707> i'm for removing that [10:30] <durandal_1707> ah it is already done [10:32] <cone-828> ffmpeg.git 03Anton Khirnov 07master:c9a13a289d0e: lavc: remove old unused audio conversion functions. [10:32] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6bf4edec27de: Merge commit 'c9a13a289d0e1607387854127476813a1ee3d34b' [10:33] <nevcairiel> michaelni: the old audio api was not part of the public API, its header not installed .. do things really use that? [10:33] <durandal_1707> michaelni just have nostalgia for that code [10:34] <durandal_1707> same for libmpcodecs [10:35] <saste> why wasn't it ifdeffed? [10:35] <durandal_1707> it is awkward to support old stuff when even examples do not work with current code [10:35] <durandal_1707> examples should be part of fate [10:38] <cone-828> ffmpeg.git 03Paul B Mahol 07master:66518f6feb95: avcodec/cook: use av_freep() [10:38] <durandal_1707> afaik applications already need to be updated... [10:41] <saste> but yes it was not even public API [10:41] <saste> and i doubt it is much tested [10:41] <durandal_1707> but people use it like mplayer [10:42] <saste> michaelni, when do you schedule to drop that API? [10:42] <saste> keeping all APIs indefinitively is not realistic [10:43] <saste> anyway keeping it for the new release is senseful [10:43] <nevcairiel> we just had a new release :D [10:43] <michaelni> nevcairiel, i dunno, there are some hits by google to some random pieces of code using it [10:44] <nevcairiel> should at least put a deprecation tag on it so people know to migrate [10:44] <michaelni> yes [10:45] <michaelni> saste, i dunno, i guess we can remove it when someone posts a patch that removes it and there is consensus on its removial on ffmpeg-devel [10:45] <saste> or drop it at the next bump [10:45] <durandal_1707> michaelni: you ever had contact with people that actually tried to use new release with old api stuff? [10:45] <michaelni> or there is some strong technical need to remove it [10:45] <saste> if we want to help projects misusing internal API [10:46] <durandal_1707> technical need: it doesnt help anyone at all [10:47] <saste> but i don't mind, i'll probably send a drop-at-the-next-bump patch later [10:47] <durandal_1707> if you do not forget [10:47] <saste> what should i forget? [10:47] <durandal_1707> to drop it at next bump [10:48] <saste> you missed the cheesy humor in my reply [10:50] <michaelni> durandal_1707, yes i got mails from people who tried to build olf code with new ffmpeg [10:58] <durandal_1707> michaelni: me too, and does keeping above help them? [11:05] <saste> talking about serious stuff, what's the name of the new release? [11:05] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:e36231969af5: avcodec/audioconvert: deprecate API [11:07] <durandal_1707> saste: the 2.2 one? [11:09] <saste> no the 2.1 one [11:12] <durandal_1707> saste: isn't in on web? [11:13] <saste> ah ok [11:13] <saste> "Fourier", cool [11:14] <cone-828> ffmpeg.git 03Anton Khirnov 07master:feeafb4adabd: lavf: do not export av_register_{rtp,rdt}_dynamic_payload_handlers from shared objects [11:14] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:d3e13250a030: Merge commit 'feeafb4adabd5c17de1738ed9962e40892b20edb' [11:28] <ubitux> http://pastie.org/pastes/8439685/text [11:28] <ubitux> is it me or the installed libs are extremely weird? [11:28] <ubitux> +sizes [11:39] <saste> what's so weird? [11:40] <saste> encoder options are arcane... [11:41] <ubitux> saste: .a is 116M, .so 7M for libavcodec [11:41] <Daemon404> saste, only only in the src =p [11:41] <ubitux> similar for the others [11:42] <Daemon404> those all look correct [11:42] <ubitux> ok [11:44] <saste> Daemon404, how do you explain that? [11:45] <Daemon404> expain what? [11:45] <saste> the difference in size [11:45] <Daemon404> debug info, actually linking it [11:45] <Daemon404> etc [11:45] <saste> isn't debug info contained in .so files as well? [11:46] <ubitux> also it seems to be grabbing the lib installed on my system somehow [11:46] <ubitux> something is fishy :( [11:47] <saste> for example b_strategy [11:48] <saste> it is used only by the mpeg encoders, with values (0, 1, 2) which are not documented anywhere [11:48] <Daemon404> saste, just symbols afaik [11:48] <saste> and used by other libs (libxvas and libx264) to bind wildly related stuff [11:50] <saste> and the git blame for that code obviously shows K&R cosmetics [11:51] <durandal_1707> what K&R did? [11:52] <saste> the revision before was a split [11:52] <ubitux> try with -w, but in case of line breaks you're doomed [11:53] <durandal_1707> Kidnap & Ransom [12:06] <cone-828> ffmpeg.git 03Anton Khirnov 07master:cd43ca0443a2: lavfi: do not export the filters from shared objects [12:06] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:325f6e0a97c9: Merge remote-tracking branch 'qatar/master' [12:07] <saste> michaelni, any hope to have an explanation of b_strategy and b_sensitivity? [12:13] <michaelni> b _strategy is used by 3 different encoders [12:18] <michaelni> you could use the description from x264 --b-adapt probably [12:18] <michaelni> 0:disabled, 1:fast, 2:optimal [12:19] <saste> michaelni, libx264, libxavs, mpegvideo encoders [12:19] <saste> ok, will see what i manage to do [12:23] <ubitux> BBB: any reason we should prefer the mmx registers over the xmm ones since we are using ssse3? [12:24] <nevcairiel> sometimes it makes sense to use mmx when your data is too small for xmm [12:24] <nevcairiel> no idea if thats the case here [12:37] <durandal_1707> nice, now i can not call filters directly [12:39] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:069ceea7da66: timefilter: Fix typo in allocation failure message [12:48] <BBB> ubitux: usually mmx instructions are slightly faster than xmm, so if you don't use the space, mmx is better [12:49] <ubitux> i see, ok [12:49] <BBB> ubitux: see http://www.agner.org/optimize/instruction_tables.pdf [12:50] <BBB> but usually best to just try and see [12:50] <BBB> if it can be done in xmm using full register width, that's usually better, unless it involves tons of shuffling and moving data around [12:51] <saste> mateo`, can you have a look at some of these: http://ffmpeg.org/trac/ffmpeg/tags?q=%27osx%27&ticket=on [12:51] <Daemon404> it's too bad pengvado's brain was never dumped to a pdf (re: asm) [12:53] <BBB> yeah that would be useful sometimes [12:53] <BBB> I'm still wondering why I'm pretentious [12:53] <BBB> but I'll worry about that later [12:54] <mateo`> saste: i don't have time at the moment, but i'll take a look at it after doing a proper review of the iSight patch [13:03] <ubitux> so, libvpx still has no threaded encoding? [13:04] <ubitux> mmh... how long did it take last time i encoded 40 sec of video? [13:04] <ubitux> 7-8 hours? [13:05] <durandal_1707> in perfect scenario you would with threading lower that to 1 hour [13:09] <saste> mateo`, sure [13:09] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:a483aae7d8bc: h264: Check all allocations [13:12] <BBB> ubitux: someone needs to send them a patch I think [13:12] <BBB> I'll add frame-mt sometime soon to ffvp9 [13:15] <durandal_1707> what about slice-mt? [13:15] <durandal_1707> 'slice' [13:15] <BBB> tile [13:15] <BBB> I'll do that too, but later [13:15] <BBB> frame-mt is more important [13:15] <BBB> as long as we don't support effective er, we're useless for realtime purposes [13:15] <BBB> and then tile-mt isn't very useful [13:30] <ubitux> BBB: they don't plan to make a decent encoder? [13:30] <ubitux> because, isn't it the only one encoder available? [13:31] <durandal_1707> writing anything decent is hard [13:31] <ubitux> well, i mean usable [13:32] <ubitux> if it takes days to make a few minutes encode, no one is going to use it [13:33] <durandal_1707> writting usable lossy encoder is much harder [13:34] <ubitux> oh i didn't say it was easy ofc [13:35] <durandal_1707> i could speculate more about reasons, but i find that ugly [13:55] <ubitux> do we have a hwaccel doing encoding? [13:56] <nevcairiel> no(t yet) [14:00] <ubitux> anyone working on such thing? [14:00] <ubitux> or interested to? [14:02] <nevcairiel> i might, and luca expressed some interest as well [14:03] <nevcairiel> but for myself, it'll be next year [15:26] <durandal11707> K&R needs concentration [15:29] <durandal11707> huh isn't code in lavc/mdec doing simply swap with loop, instead of using dsp [15:29] <saste> wm4: do you want to review my sws filter patch? [15:29] <saste> otherwise i think i'll commit it, if i don't change mind [15:33] <durandal11707> Don is reseting the history [15:42] <saste> michaelni, if I set bf=-1 it will crash the mpeg4 encoder [15:42] <saste> bf=-1 is actually useful only to let libx264 to leave the default value [15:44] <saste> ffmpeg -i matrixbench_mpeg2.mpg -codec:v mpeg4 -an -bf -1 -y out.mp4 [16:07] <saste> bb73cda2 => fix libx264, breaks everything else [16:07] <ubitux> yes but who cares about other codecs anyway? [16:20] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6103faaa51d2: matroskaenc: fixed display width / height calculation for stereo mode [16:20] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:ce55e667facb: avcodec/mpegvideo_enc: check that max_b_frames is not negative [16:30] <saste> michaelni, thanks [16:45] <wm4> saste: where is it? [17:27] <wm4> are there any webm vp9 samples around? [17:40] <Daemon404> wm4, in FATE [17:40] <Daemon404> in the wild? havent seen any [17:43] <wm4> I see [17:43] <kierank> Daemon404: yotube [17:43] <kierank> youtube* [17:43] <Daemon404> iirc youtube wasnt doing vp9? [17:44] <kierank> yes they were [17:44] <Daemon404> 'were'? [17:44] <Daemon404> as in they stopped? [17:46] <wm4> vp9 over dash, it's like a dream come true [17:47] <Daemon404> does this dream involve whips and leather [17:48] <wm4> and lawyers, yes [17:56] <ubitux> wm4: i generated one with libvpx [17:56] <ubitux> do you want it? [17:56] <wm4> ubitux: sure [17:56] <wm4> I actually just want to test demuxing [17:56] <ubitux> http://lucy.pkh.me/samples/vp9/ [17:57] <wm4> and the fate samples are naturally extremely short [17:57] <ubitux> this one is 40 sec [17:58] <ubitux> i'm currently generating a slighty longer one [17:58] <ubitux> but it will take a few days [17:58] <ubitux> :) [17:59] <wm4> this one worked nicely [18:01] <wm4> which surprises me, because my demuxer accidentally doesn't pass extradata to the decoder [18:01] <nevcairiel> vp9 has extradata? [18:01] <wm4> apparently not :) [18:03] <Daemon404> 'a few days' [18:03] <Daemon404> sounds usable [18:03] <ubitux> well [18:03] <ubitux> it's 5k frames after all [18:03] <ubitux> :D [18:04] <ubitux> 5k frames, 5 days [18:04] <Daemon404> [17:03] <@Daemon404> sounds usable [18:04] <ubitux> ;)) [18:04] <wm4> and I can't find the webm/vp9 spec [18:04] <Daemon404> ahahahahahahahahaHAHAHAHAH [18:04] <JEEB> > vp9 > spec [18:04] <JEEB> ahoy! [18:04] <wm4> I expected this reaction [18:04] Action: JEEB gives wm4 a friendly hug [18:05] <ubitux> well you've become pretty demanding [18:05] <ubitux> remember when all codecs needed to be reversed? [18:05] <ubitux> @_@ [18:05] <wm4> lol [18:05] <Daemon404> sure [18:05] <Daemon404> just dont have google sell it to me as 'open' [18:06] <nevcairiel> its only not open if such a document exists, but is not published [18:06] <nevcairiel> if it doesnt exist, you have no reason to complain [18:06] <nevcairiel> you get the same info they work off =P [18:07] <Daemon404> http://guru.multimedia.cx/chrome-droppings/ [18:09] <Compn> wm4 : i think BBB didnt write a spec. there is only code [18:09] <Compn> not that it was his codec in the first place :) [18:09] <Compn> ehe [18:09] <wm4> at least webvtt in webm had some specs [18:10] <wm4> and webvtt is a google thing too [18:10] <nevcairiel> its a trivial format, not sure what webm specs it needs [18:10] <nevcairiel> no extradata, no nothin' [18:10] <Daemon404> [17:10] <+wm4> and webvtt is an abomination [18:10] <Daemon404> ftfy [18:11] <wm4> well I'm sure surprised how little hevc and vp9 need from the demuxer [18:11] <wm4> webvtt and opus are so complicated in this respect [18:12] <nevcairiel> hevc will need dealing with extradata, although if everything is muxed sanely you just need to copy it 1:1 [18:12] <Daemon404> thats not a safe assumption [18:12] <Daemon404> esecially for 'pro' stuff [18:12] <nevcairiel> and of course there is the open intra refresh problem and seeking, but that was never solved for h264, so doubtful thats going to change much :P [18:13] <nevcairiel> of course there will be some oddball format that invents their own extradata [18:13] <nevcairiel> but for the mainstream things, ts/mkv/mp4, its easy [18:13] <Daemon404> nut! [18:14] <Daemon404> ubitux, does vp9 actually have a real release yet [18:14] <Daemon404> because they fucked that up and changed stuff due to bugs [18:14] <wm4> isn't nut = "use ffmpeg internals lol" [18:20] <smarter> Daemon404: the closest thing to a release is http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=shortlog;h=refs/heads/st... [18:20] <Daemon404> we all saw how that turned out... [18:20] <smarter> if you care about encoding, you should use master for now [18:21] <Daemon404> well i was going to run it on a more powerful box [18:21] <Daemon404> because 1k frames per day is insane [18:25] <smarter> use --cpu-used=1 if you don't already [18:25] <Daemon404> what exactly does that o [18:25] <Daemon404> do [18:25] <smarter> it's the speed setting [18:25] <Daemon404> ive never touched vp9 before this very instant [18:25] <smarter> 0 is the slowest/best [18:25] <smarter> 5 is the fastest/worst quality [18:25] <Daemon404> right im more interested in 0 [18:26] <Daemon404> all the current hevc encoders are crap, may as well add vp9 into the mix [18:26] <smarter> 1 should be ~5% worse than 0 and much faster [18:27] <smarter> I use this command-line, but I think some flags are now no longer needed because the default became more sane: "./vpxenc ~/samples/parkjoy.y4m -o /dev/null --good --cpu-used=1 --target-bitrate=16000 --end-usage=vbr --auto-alt-ref=1 --fps=30000/1001 -v --minsection-pct=5 --maxsection-pct=800 --lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=360 --min-q=4 --max-q=60 --arnr-maxframes=5 --arnr-strength=3 -p 2 --codec=vp9" [18:29] <Daemon404> i was going to test with a bunch of real world sources [18:29] <Daemon404> broadcasts, masters, etc [18:30] <smarter> have fun :p [18:31] <Daemon404> side note: this is for personal curiosity, not profession [18:31] <Daemon404> al [18:31] <Daemon404> 301KB/s [18:31] <Daemon404> woooo fast [18:40] <cone-828> ffmpeg.git 03Stefano Sabatini 07master:61c1f2cb1e7e: doc/muxers: add definitory line for the MOV/MP4/ISMV muxer [18:40] <cone-828> ffmpeg.git 03Stefano Sabatini 07master:9fa0dccca649: lavc: extend documentation for the "bf" option [18:40] <cone-828> ffmpeg.git 03Stefano Sabatini 07master:d4ac3e593481: lavc/mpegvideo_enc: fix typo [18:51] <saste> what's the status of the internal aac encoder? [18:52] <saste> do you support the claim in https://trac.ffmpeg.org/wiki/AACEncodingGuide [18:52] <saste> fdk_aac > libfaac > aacenc? [18:52] <Daemon404> saste, that is correct [18:52] <Daemon404> right now [18:52] <Daemon404> that epic bug tracker thread i still ongoing [18:52] <Daemon404> and nothing has been pushed [18:52] <Daemon404> is* [18:52] <saste> so it seems [18:55] <wm4> saste: can you hint me where the swscale filter posts are? [18:56] <saste> wm4: [FFmpeg-devel] [PATCH] swscale: Support setting filters through AVOptions [19:11] <nevcairiel> anyone know how well ffmpeg interleaves ts streams? [19:16] <burek> llogan, im not sure, i'll check.. probably the devel machine ran out of electr. power [19:18] <burek> it's highly unreliable :( i need to migrate it to another, but i need to find some spare time to do so.. [19:21] <llogan> burek: convert it to gasoline/petrol [19:24] <burek> +1 :) [19:37] <ubitux> did something happen with the consulting page or whatever? [19:37] <ubitux> i had 4 consulting requests in 4 days [19:37] <ubitux> first time i see this [19:38] <ubitux> <@Daemon404> ubitux, does vp9 actually have a real release yet // i'm not following libvpx development at all [19:42] <cone-828> ffmpeg.git 03Clément BSsch 07master:8d55362fd0d4: avformat/avisynth: re-add trailing \n. [19:48] <cone-828> ffmpeg.git 03Luca Barbato 07master:dcd3eda6cb88: configure: Move gcc-only -W option where it belongs [19:48] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:df69af4ee1bc: Merge commit 'dcd3eda6cb8884beeb67ef5eb61b4bb6b01d29ea' [19:56] <cone-828> ffmpeg.git 03Luca Barbato 07master:e78913052263: configure: Provide an hardened toolchain option [19:56] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6c5f17e738a5: Merge commit 'e78913052263af80855590659fb0f705e8f13c8a' [19:58] <saste> ubitux: same happened to me [19:58] <ubitux> saste: ok :) [19:58] <saste> it is called the autumn wakeup [19:59] Action: saste saste is doing (very little) boring paid work [19:59] <kierank> because it's the end of DST? [20:01] <saste> kierank, probable, less time to do outdoor fun stuff [20:03] <nevcairiel> nonsense, just gotta start earlier! [20:06] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:327c439f811a: timefilter: Handle memory allocation failure [20:06] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:42bf156e132b: Merge commit '327c439f811a89d774db9a86f72951d295193e5f' [20:08] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:25c7db7cc99d: avio: Check for memory allocation failure of private data [20:08] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:e166b82dd483: Merge commit '25c7db7cc99d74fe6fb56a6fd52c9b5f1591e448' [20:21] <wm4> saste: I hope my "review" isn't too negative... [20:23] Action: saste is used to too negative review [20:24] <wm4> btw. what is eval.h included for? [20:25] <saste> wm4, av_strtod [20:25] <wm4> ok [20:26] <wm4> why is that needed instead of just strtod()? [20:32] <saste> indeed it is probably unneeded [20:33] <saste> but it was in michael's patch, and I didn't think about it [20:36] <wm4> depends on michael's reply then [20:37] <cone-828> ffmpeg.git 03Anton Khirnov 07master:4eb49fdde8f8: lavf: remove unreliable timestamp guessing heuristic [20:40] <ubitux> BBB: i'd like to work on 8x8 before applying 4x4 [20:41] <ubitux> we can probably factor some things, and it's easier to move things around randomly when it's still not upstream [20:41] <ubitux> the optim is not worth being pushed right now for overall decode anyway [20:41] <wm4> huh, that commit has no merge record? [20:42] <ubitux> wm4: it's re-applied [20:42] <wm4> oh [20:42] <ubitux> wm4: it wasn't merge (see merge commit message) [20:42] <ubitux> now that the abi is solved, i guess it can be applied [20:43] <michaelni> wm4, my reply ? where what ? [20:43] <michaelni> wm4, yes, nevcairiel sugested id just apply and wait [20:44] <michaelni> IIRC [20:45] <wm4> michaelni: about the swscale filter as avoption patch [20:46] <michaelni> iam fine with any form of *strtod for it [20:46] <ubitux> http://pastie.org/8440873 lol [20:46] <saste> wm4, yes there is no point into using av_strtod I think [20:47] <wm4> michaelni: well, about more general issues too [20:48] <michaelni> what issues ? [20:49] <wm4> well, read my mail... [20:53] <michaelni> ok read it, what should i do now ? [20:53] <wm4> well, do we really need the change? [20:53] <michaelni> iam not sure [20:54] <wm4> or maybe at least the syntax should be extended to support common cases? [20:54] <wm4> *use cases [20:54] <michaelni> there could be support for things like gauss(1.2) [20:55] <michaelni> there could be support for things like combining vectors per convolution gauss(1.2)|shift(123), shouldnt be hard to implement but iam also dont want to overdesign this [20:57] <michaelni> sws_convVec() <-- for convolution [20:59] <cone-828> ffmpeg.git 03Anton Khirnov 07master:8b64c2ba0382: lavc: add a dummy field to AVStream to preserve ABI compatibility for avconv [20:59] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:249cc58c3ada: Merge commit '8b64c2ba0382892cad9e1a5ba601696d4cbb4d04' [21:11] <saste> wbs, willing to review libfdk_aac docs? [21:37] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:15b1b0887466: avutil/opt: fix flags check on non x86 [21:45] <cone-828> ffmpeg.git 03Anton Khirnov 07master:c872d310cd9c: avconv: stop accessing AVStream.parser [21:45] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:0460b9bb3e34: Merge commit 'c872d310cd9c605e5f994ad8ac79dc72303c0d29' [21:50] <Zeranoe1> Can FFmpeg be run with reentrant? [21:58] <michaelni> what do you mean by "with reentrant" ? [22:00] <Zeranoe1> I guess is it possible to do re entrance with FFmpeg? [22:01] <michaelni> you can call a decoder while another decoder works yes [22:02] <cone-828> ffmpeg.git 03Diego Biurrun 07master:9510d7689e23: fate.sh: Allow non-fast-forwards when updating sources [22:03] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:a8fe8d4fe986: Merge commit '9510d7689e236f6a4748795604fba427c130d0ad' [22:03] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:0999b1db3c1a: tests/fate.sh: run git reset only when fetch succeded [22:03] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:7f4fd72f81b7: tests/fate: fix fate on branches different from origin/master [22:12] <saste> cc1: warning: unrecognized command line option "-Wno-maybe-uninitialized" [22:12] <saste> uh? [22:14] <ubitux> this was moved to gcc specific case today iirc [22:14] <ubitux> so if you don't have gcc that's normal i'd say [22:15] <ubitux> or maybe that's a really old gcc? [22:15] <nevcairiel> the option is pretty new in gcc, too [22:15] <nevcairiel> 4.7 i think [22:15] <ubitux> ah? ok [22:15] <ubitux> well the warning shouldn't be disabled anyway [22:15] <nevcairiel> imho its more wrong then right [22:16] <nevcairiel> gcc doesnt do a very good job tracking that [22:16] <ubitux> better have 9 false positive and 1 true match, than no issue found [22:16] <ubitux> also as you said it's recent, and meant to be improved i suppose [22:16] <nevcairiel> since we need the off option, it must be default enabled in some way [22:23] <ubitux> nevcairiel: looking at your benchmark, it's fun how vc1 is so slow [22:24] <ubitux> even though there are quite some optim available [22:24] <nevcairiel> well, its not threaded [22:24] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:58d13cea307e: h264: Check all allocations [22:24] <ubitux> aah, that's it then [22:24] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:845086149b15: Merge commit '58d13cea307e776664dae711608b358dd4b84fff' [22:25] <nevcairiel> although i disabled mt for mpeg4 as well [22:25] <nevcairiel> still does 400 fps [22:26] <ubitux> maybe a scale filter comes into play or sth? [22:26] <nevcairiel> nah its just that slow [22:26] <ubitux> ok, fun :p [22:26] <nevcairiel> was tested with my own software, it doesnt auto-insert stuff [22:26] <ubitux> ok :) [22:28] <nevcairiel> i dont usually use the vc1 decoder, i use microsofts binary decoder because its 5x faster [22:28] <nevcairiel> but i thought for the benchmark it wouldnt hurt [22:42] <cone-828> ffmpeg.git 03Ingo Brückl 07master:8fbb0979da8e: build: remove pointless condition [22:42] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6b312143793b: Merge remote-tracking branch 'qatar/master' [22:51] <cone-828> ffmpeg.git 03Anssi Hannula 07master:f86387b6c2b1: lavf/spdifdec: fix demuxing of AAC in IEC 61937 [23:09] <Compn> nevcairiel : vc1 binary 5x faster than ffvc1 ? [23:09] <Compn> is the binary threaded ? [23:09] <nevcairiel> among other things, yes [23:10] <Compn> comparing threaded binary to threaded ffvc1 wonder what speed diff is [23:10] <nevcairiel> there is no threaded ffvc1 [23:10] <Compn> ah [23:10] <Compn> one of the codecs that wasnt threaded ? [23:12] <Compn> http://trac.ffmpeg.org/ticket/1885 [23:12] <Compn> i see [23:12] <kierank> oh ffv1 isn't intra [23:32] <michaelni> what is preferred for iSight, autodetect or disabled by default ? [00:00] --- Wed Oct 30 2013