[00:03:15 CEST] <jamrial> ubitux, BBB: win64 disass of clamp_mv in vp8.c is currently like this: http://pastebin.com/d0gZihxK, and with av_clip_int16 it becomes http://pastebin.com/FPn7cGtG [00:03:49 CEST] <jamrial> i'm thinking that sse2 packss instructions are going to be faster. that's an awful amount of branches [00:03:55 CEST] <BBB> yeah [00:03:57 CEST] <BBB> thats a lot of code [00:04:50 CEST] <jamrial> of course that's after forcing the function to not be inlined, but still [00:06:33 CEST] <ubitux> i suppose it doesn't help if you drop the -fno-tree-vectorize? (yeah i'm making an obsession about this) [00:09:57 CEST] <jamrial> doesn't look like [00:22:28 CEST] <jamrial> ubitux, BBB: same function with an av_clip_int16 implemented with packssdw looks something like this http://pastebin.com/dUxYT8bn [00:23:18 CEST] <BBB> you do two packssdws [00:23:20 CEST] <BBB> you only need one [00:23:26 CEST] <BBB> (it can do both mvs at once) [00:23:59 CEST] <BBB> and ubitux has a point maybe were obsessing too much :-p [00:24:30 CEST] <jamrial> i'm doing one packssdw per av_clip_int16, and there are four of those in clamp_mv right now [00:24:31 CEST] <jamrial> heh, maybe [00:28:42 CEST] <philipl> WOOO fixing bugs [00:33:35 CEST] <BBB> theres no reason clipmv has to use clip_int16 [00:33:47 CEST] <BBB> it can use a custom clip implementation on x86 that does something AWESOME [00:33:54 CEST] <BBB> (I mean this is all just for testing right?) [01:02:42 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:028c59c17b14: avcodec/jpeg2000dec: Fix high bit depth branch sample shift [01:02:43 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:12ba1b2b4d55: avcodec/jpeg2000dec: Check that coords match before applying ICT [01:02:44 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:074159ed70ac: avcodec/jpeg2000dec: Fix subsampled decoding [01:06:37 CEST] <cehoyos> mcihaelni: Which example do you mean? [01:07:21 CEST] <cehoyos> There are several open tickets containing samples that can be decoded with libopenjpeg but not the native decoder, link in ticket 3619 [01:07:43 CEST] <cehoyos> To the best of my knowledge, there is no j2k sample that decodes correctly with the native decoder. [01:08:07 CEST] <cehoyos> For any non-testing use, the native decoder is useless: Why should it be the default if libopenjpeg was enabled? [01:08:54 CEST] <michaelni> i meant the example provided by the reporter of the ticket [01:09:03 CEST] <cehoyos> The only reason there are only a handful of related tickets open, is that I don't open more tickets: There are already enough open. [01:09:09 CEST] <michaelni> also libopenjoeg does not decode it here [01:10:22 CEST] <cehoyos> This is ridicilous: I always request a sample and one was given, but the ticket isn't about a sample: It is about a non-working experimental decoder being the default even if a working decoder is available. [01:12:21 CEST] <cehoyos> I just tested decoding the sample from the ticket with libopenjpeg and it works fine here. [01:12:40 CEST] <michaelni> iam sure you have a more recent libopenjpeg [01:13:19 CEST] <michaelni> i can reopen the ticket if you like but i dont know which sample libopenjpeg decodes better [01:13:29 CEST] <cehoyos> Decoding is bitexact here. [01:13:32 CEST] <cehoyos> with libopenjpeg [01:14:09 CEST] <cehoyos> Decoding is not-bitexact (nona) with the native decoder. [01:14:59 CEST] <michaelni> was that ever reported ? [01:15:10 CEST] <cehoyos> It decodes every single sample better because there is no sample for which the native decoder works correctly (afaik) [01:15:42 CEST] <cehoyos> Yes, there is a ticket that states that our native decoder does not work for any sample and that it therefore should not be the default if libopenjpeg is enabled: [01:15:46 CEST] <cehoyos> Ticket 3619 [01:15:53 CEST] <cehoyos> There is also a mailing list thread. [01:16:06 CEST] <cehoyos> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/177508 [01:16:33 CEST] <cehoyos> And sinse the patch was not accepted, I sent a new one today (because of the Debian discussion: They need such a patch and one for aac) [01:16:54 CEST] Action: michaelni doesnt get it [01:17:05 CEST] <michaelni> i fix 2 long standing bugs and get flamed [01:17:13 CEST] <cehoyos> Our decoder was and is experimental and does not work for any sample, sorry. [01:18:01 CEST] <cehoyos> And while I would have been thankful if we had a capable GSoC student for j2k, there is none and I don't think you will be able to make our decoder work with a few patches (unfortunately) [01:18:13 CEST] <cehoyos> There was not even a mentor iirc. [01:19:57 CEST] <michaelni> how can i reproduce the issue that it is not bitexact ? [01:20:55 CEST] <michaelni> keep in mind libopenjpeg does not work here so i cant compare to it [01:26:39 CEST] <cehoyos> ./ffmpeg -threads 1 -i matrixbench_mpeg2.mpg -vframes 1 -f framecrc - [01:26:51 CEST] <cehoyos> ./ffmpeg -threads 1 -i matrixbench_mpeg2.mpg -vframes 1 -vcodec libopenjpeg -format j2k test.j2k [01:27:06 CEST] <cehoyos> ./ffmpeg -vcodec jpeg2000 -i test.j2k -f framecrc - [01:27:19 CEST] <cehoyos> ./ffmpeg -vcodec libopenjpeg -i test.j2k -f framecrc - [01:30:20 CEST] <michaelni> libopenjpeg does not work for decodiing here, i dont really trust it to work for encoding bitexactly [01:31:18 CEST] <cehoyos> Afaiu, we both agree that very old libopenjpeg does not work. [01:31:25 CEST] <michaelni> yes [01:31:32 CEST] <cehoyos> I tested with a three year old version and it works fine. [01:31:54 CEST] <cehoyos> If you believe this makes a difference, I can test 1.4 [01:32:12 CEST] <cehoyos> But I honestly don't understand what difference this would make. [01:37:05 CEST] <michaelni> i dont think testing 1.4 really would help [01:37:47 CEST] <michaelni> ubunto 12.04 ships 1.3 [01:38:19 CEST] <Compn> lol ubuntu fail then [01:38:38 CEST] <michaelni> so does ubuntu 14.04 if iam not looking at the wrong box [01:38:50 CEST] <Compn> probably not even high bit jp2k supported then [01:42:48 CEST] <jamrial> so what's the issue here? the last couple commits fixed decoding of one kind of j2k samples, but there are still more that can't be decoded? [01:43:24 CEST] <cehoyos> openjpeg 1.4 works fine here: Is bitexact for the matrixbench command line you provided [01:43:41 CEST] <cehoyos> There is no sample that decodes correctly with the native j2k decoder afaik [01:46:17 CEST] <jamrial> the one from the fate test does [01:46:24 CEST] <jamrial> and apparently so does the 420 sample from ticket 2871 now [01:46:58 CEST] <jamrial> unless they are not supposed to look like this [01:47:08 CEST] <cehoyos> The samples from ticket 2871 do not show artefacts now. [01:48:21 CEST] <jamrial> so the native decoder does work with some samples then [01:48:36 CEST] <cehoyos> You are right, the fate sample is decoded correctly, I wasn't aware. [01:49:27 CEST] <cehoyos> ffmpeg -i fate-suite/lena.pnm out.j2k is not decoded bit-exact though [01:49:46 CEST] <cehoyos> Same for the first frame of matrixbench [01:50:44 CEST] <jamrial> the native decoder may use float dsp [01:52:44 CEST] <cehoyos> Ticket 2871 samples also decode bitexact now, the sample from ticket 2792 does not work. [01:53:51 CEST] <cehoyos> Same for ticket 2586 [01:55:47 CEST] <cehoyos> Samples from ticket 1211 is not bitexact yet. [01:59:24 CEST] <cehoyos> 2872 is not bitexact yet (but no more artefacts). [02:01:43 CEST] <cehoyos> Sample from ticket 2869 does not work yet. [02:25:04 CEST] <cone-068> ffmpeg 03Rodger Combs 07master:ecefce41d9f9: lavf/tls_securetransport: fix SNI support when not verifying [02:25:05 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:7c9fcdfabd4c: avcodec/jpeg2000dec: Fix some 5/3 bitexactness issues [02:51:07 CEST] <jamrial> mmh, those psnr values look worse now [02:55:47 CEST] <michaelni> yes, but its just testing our encoder against our decoder so thats not a reliable way to test [02:56:00 CEST] <michaelni> unless we would know that our encoder is correct [02:56:55 CEST] <jamrial> ah ok [04:32:53 CEST] <jamrial> michaelni: some of your freebsd fate clients have their clocks wrong [04:33:21 CEST] <jamrial> for example http://fate.ffmpeg.org/report.cgi?time=20150604005949&slot=x86_32-debian-kfreebsd-gcc-4.1 which says it was run on June 3 using a commit that's only two hours old [04:36:53 CEST] <michaelni> should be fixed [11:44:34 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:e1009665759d: avcodec/x86/h264_weight: handle weight1=128 [11:45:35 CEST] <ubitux> ok, i'm really confused by all this apple crap [11:45:52 CEST] <ubitux> can anyone enlight me on the purpose to support both vda and videotoolkit? [11:46:11 CEST] <ubitux> vda seems to be implemented and available on osx [11:46:20 CEST] <ubitux> but obviously it's not available on ios (fuck you apple) [11:47:00 CEST] <ubitux> where you are supposed to use videotoolbox [11:47:31 CEST] <ubitux> but videotoolbox might actually be available on osx (didn't check but assuming vda is a wrapper over videotoolbox as i read...) [11:47:43 CEST] <wm4> ubitux: videotoolbox used to be a private API [11:47:43 CEST] <ubitux> so what would be the reason to prefer vda over videotoolbox? [11:47:52 CEST] <ubitux> yeah, but it's been about 3 years now [11:47:54 CEST] <wm4> but I think they're moving towards making it public (or it already is) [11:48:01 CEST] <wm4> and VDA is just a wrapper around VT [11:48:10 CEST] <wm4> so the answer is, no reason to prefer VDA (anymore) [11:48:10 CEST] <ubitux> right, so far that's my understanding [11:48:15 CEST] <ubitux> OK [11:48:33 CEST] <ubitux> so it makes sense to have videotoolbox and wipe vda? [11:48:52 CEST] <wm4> yeah [11:48:53 CEST] <ubitux> or is there benefits/features of vda over vt? [11:48:54 CEST] <wm4> I'd say so [11:49:04 CEST] <ubitux> ok [11:49:10 CEST] <wm4> except that VDA is part of the public API in FFmpeg [11:49:29 CEST] <ubitux> yeah sure i mean other than our retro compat issues [11:49:33 CEST] <wm4> (so not killing it immediately might make sense) [11:49:39 CEST] <ubitux> and eventually compat with things before vt was public [11:49:43 CEST] <wm4> is there someone working on VT support? [11:49:50 CEST] <ubitux> probably me [11:50:03 CEST] <ubitux> i mailed the guy who submitted a patch 2.5 years ago [11:50:15 CEST] <wm4> (I wonder what VDA actually does...) [11:50:23 CEST] <ubitux> (who is actually the vda maintainer) [11:50:35 CEST] <wm4> we have a VDA maintainer? [11:51:04 CEST] <ubitux> [~/src/ffmpeg]- grep -i 'vda\*' MAINTAINERS [11:51:05 CEST] <ubitux> vda* Sebastien Zwickert [11:51:20 CEST] <ubitux> apparently :p [11:51:27 CEST] <ubitux> he's the one who submitted a VT patch [11:51:52 CEST] <wm4> btw. using VDA from ffmpeg is absolutely trivial now [11:51:55 CEST] <wm4> can this be kept with VT? [11:53:35 CEST] <ubitux> probably [11:55:15 CEST] <nevcairiel> is VT available on all relevant versions of OSX, ie. those were VDA is available today? [11:55:22 CEST] <nevcairiel> For me, I would care about 10.7+ [11:55:52 CEST] <ubitux> "This patch adds support of VideoToolbox to the HWAccel infrastructure. [11:55:54 CEST] <ubitux> VideoToolbox framework became public since MacOS 10.8. [11:55:56 CEST] <ubitux> " [11:56:22 CEST] <nevcairiel> if there is a distinct advantage in using VT over VDA, i guess I could sell not supporting 10.7 [11:57:13 CEST] <rcombs> VT also includes encoding [11:57:22 CEST] <rcombs> or, I'm pretty sure it does [12:01:57 CEST] <ubitux> https://github.com/eugeneware/ffmpeg-progress-stream lol [12:02:06 CEST] <ubitux> > Generate a stream of progress events from the stderr stream of ffmpeg [12:02:34 CEST] <ubitux> (note: we have a -progress option) [13:34:31 CEST] <cone-815> ffmpeg 03Rodger Combs 07master:e60b018c7416: lavf/segment: add an option to allow breaking on non-keyframes [14:53:33 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:b6ee1912f98d: avcodec/jpeg2000dec: Handle Psot = 0 [15:54:31 CEST] <kierank> lglinskih: hello [15:56:47 CEST] <av500> http://blogs.windows.com/buildingapps/2015/06/05/using-ffmpeg-in-windows-app... [15:58:02 CEST] <lglinskih> kierank: hi! [15:58:07 CEST] <kierank> how's it going? [16:10:05 CEST] <BBB> av500: omg [16:10:12 CEST] <BBB> I see pigs flying, theyre everywhere [16:10:32 CEST] <nevcairiel> its a terrible managed c++ api though =( [16:10:43 CEST] <BBB> FLYING PIGS! [16:10:55 CEST] <BBB> who cares thats is C++, THEY FLY!!!! IN THE AIR!!! [16:11:09 CEST] <nevcairiel> i dont care that its c++, i care that its managed code [16:11:15 CEST] <nevcairiel> managed c++ is so ugly [16:11:19 CEST] <nevcairiel> use c# if you want managed :( [16:11:35 CEST] <BBB> BUT THEY FLY!!! [16:11:57 CEST] <BBB> ok fine if you care that flying pigs are managed, then I wont make a big deal about it, but .. I mean .. THEY FLY! [16:12:17 CEST] <nevcairiel> its the new microsoft, now with flying pigs, ffmpeg, and ssh support [16:14:51 CEST] <wm4> "We have released a set of Compilation Instructions for a WinRT compatible build of FFmpeg." [16:14:54 CEST] <wm4> they have? [16:14:57 CEST] <wm4> THEY? [16:15:12 CEST] <nevcairiel> they tried to push some evil long document as a patch into the repository some tiem ago [16:15:26 CEST] <nevcairiel> it was full of bad advice and generally in the wrong place, but shrug [16:15:38 CEST] <wm4> so I guess that means MS is suggesting the use of MSYS2 [16:16:11 CEST] <nevcairiel> unfortunately, yes [16:19:01 CEST] <BBB> https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT [16:19:09 CEST] <BBB> that is an insanely long document [16:19:33 CEST] <nevcairiel> mostly because there is lots of duplication between the different compiling methods [16:19:39 CEST] <lglinskih> kierank: I got ill a little bit, so yesterday and today I sleep a lot.=/ I give up with makefiles for now. So I'll start with fixing my flac test and writing new tests. [16:20:33 CEST] <kierank> ok [16:20:46 CEST] <lglinskih> should I start with test for H264? [16:24:47 CEST] <kierank> yes [16:25:39 CEST] <lglinskih> ok [16:32:31 CEST] <kierank> you'll need to write an independent version of framemd5 [16:32:40 CEST] <kierank> but that's not too hard [16:45:15 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:45db92180693: avcodec/jpeg2000dec: Add placeholder for PLT parsing [16:45:16 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:44327cbc9a8c: avcodec/jpeg2000: Disable special case for JPEG2000_QSTY_SI [16:47:52 CEST] <Daemon404> BBB, they tried to put that + a stupid .bat in our repo [16:47:53 CEST] <Daemon404> i rejected it [16:47:57 CEST] <Daemon404> for obvious reasons [16:48:21 CEST] <BBB> I missed that [16:48:22 CEST] <BBB> fun though [16:48:41 CEST] <Daemon404> [15:31] <@Daemon404> im also a little miffed they made no mention of the work wbs, bbb, etc did for the windows / winrt support [16:48:44 CEST] <Daemon404> [15:31] <@Daemon404> which was massive [16:48:47 CEST] <Daemon404> [15:31] <@Daemon404> "hey look what ms did!" [16:48:49 CEST] <Daemon404> ^ related [16:48:58 CEST] <BBB> I missed that too :-p [16:49:15 CEST] <BBB> anyway, Im happy ms finally admits their bubble is dead and theyre coming out of zombieland into the real world [16:49:22 CEST] <Daemon404> indeed [16:49:24 CEST] <BtbN> "Set the following environment variables" uhm, ok oO [16:49:36 CEST] <Daemon404> their compiler uses them [16:49:42 CEST] <Daemon404> it;s standard ms [16:49:49 CEST] <Daemon404> including the massive copypasta [16:49:54 CEST] <BtbN> I'm more concerned about the incredibly long stuff that follows [16:49:55 CEST] <Daemon404> with confusing or no explanations [16:50:18 CEST] <Daemon404> thats how you breed the cargo-cult win32 developer [16:50:28 CEST] <Daemon404> this line does magic. [16:50:53 CEST] <Daemon404> also i doubt all that kind of crap is needed... there is a winrt fate instance [16:51:17 CEST] <BtbN> hm, that copy&paste is that long because it reads registry keys and builds the PATHs from that [16:51:35 CEST] <BtbN> there are some version specific ones a bit further down, they look not that bad [16:51:55 CEST] <BtbN> But why isn't there some file you can just source? [16:52:02 CEST] <BtbN> Or is the windows shell not able to source stuff? [16:52:06 CEST] <nevcairiel> there is [16:52:11 CEST] <nevcairiel> no idea why they dont use them [16:52:17 CEST] <Daemon404> yeah. [16:52:29 CEST] <Daemon404> thats how all the fate instances work [16:53:12 CEST] <BtbN> MS developers not knowing their own stuff :/ [16:53:59 CEST] <nevcairiel> they do seem to use them, at least they mention the shortcut in the start menu [16:54:12 CEST] <nevcairiel> but that should make the setup of the env vars redundant [16:54:13 CEST] <nevcairiel> oh well [16:54:18 CEST] <nevcairiel> i dont set them up manually [16:54:38 CEST] <nevcairiel> i just go like, "call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86_amd64" [16:54:46 CEST] <Daemon404> yeah [16:54:48 CEST] <nevcairiel> can probably not hardcode the path somehow =p [16:55:15 CEST] <nevcairiel> maybe the store libs are not included in any of the batch files? [16:55:17 CEST] <nevcairiel> idunno [16:55:50 CEST] <Daemon404> that would be pretty stupid [17:11:10 CEST] <gnafu> Speaking of pigs flying: http://www.washingtonpost.com/news/morning-mix/wp/2015/06/09/2200-piglets-se... [17:12:47 CEST] <gnafu> Thanks, Microsoft! Now 300-400 piglets are dead. [17:13:56 CEST] <Daemon404> mmmm pork [17:19:54 CEST] <cone-815> ffmpeg 03Rodger Combs 07master:4b082bc2419d: doc/muxers: document new break_non_keyframes option [17:29:14 CEST] <michaelni> Does anyone want to write release notes for 2.7 ? [17:35:03 CEST] <cone-815> ffmpeg 03Janne Grunau 07master:fb1473080223: aac_parser: add required padding for GetBitContext buffer [17:35:04 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:5f48a73bb099: Merge commit 'fb1473080223a634b8ac2cca48a632d037a0a69d' [17:42:15 CEST] <cone-815> ffmpeg 03Janne Grunau 07master:09447f2b0faf: ac3_parser: add required padding for GetBitContext buffer [17:42:16 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:840465ebf979: Merge commit '09447f2b0fafac6d9565aab82a4c5f16fc99ee5e' [17:47:47 CEST] <ubitux> so, we still do not have any doc about hwaccels? [17:48:14 CEST] <ubitux> i see the pattern <codec>_<accel>_{decoder,hwaccel} [17:48:34 CEST] <Daemon404> g 42 [18:08:39 CEST] <cone-815> ffmpeg 03Janne Grunau 07master:210921722bf8: imc: add required padding for GetBitContext buffer [18:08:40 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:551813a963b2: Merge commit '210921722bf828b3b895ebcbc34374e6c4452c6f' [18:16:48 CEST] <wao813> whois [18:17:34 CEST] <wao813> Hi, I am trying to package h264 encoded data to file, but seeing following error, anyone knows what to do? [18:17:38 CEST] <wao813> [h264 @ 0x7fc014012000] missing picture in access unit with size 73 [18:18:02 CEST] <wao813> [h264 @ 0x7fc014012000] no frame! [18:18:37 CEST] <cone-815> ffmpeg 03James Almer 07master:b380337020e2: mpjpegdec: don't try to alloc an AVIOContext when probe is guaranteed to fail [18:18:38 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:962654f25137: Merge commit 'b380337020e271c5431aa8ef8f8e9dfda5e919b2' [18:30:47 CEST] <cone-815> ffmpeg 03Luca Barbato 07master:b14086ca38ef: mkv: Correctly report the latest packet had been flushed [18:30:48 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:dac7b2780264: Merge commit 'b14086ca38efa1a86cb0f0c6aa147b05f698877b' [18:55:50 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:32b1131fc16e: avformat/oggenc: Fix return code in case of flushing [18:55:52 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:dbbb31e5bb88: avcodec/jpeg2000: remove unused variable [20:17:15 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:adbe1d7de446: avcodec/libopenjpegdec: Mark as experimental if <= 1.3 [20:17:16 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:6bf8d9e1649d: fate: Force jpeg2000 decoder for dcinema [20:44:47 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:0916938a8dfa: avcodec/jpeg2000dec: Fix gain regression with gray16 [21:10:10 CEST] <cehoyos> Anybody with a long history? wm4 reported a dca/dts sample from samples.ffmpeg.org that prints "sample requested" when decoded with FFmpeg - I forgot which sample it was... [21:10:46 CEST] <wm4> http://samples.ffmpeg.org/evob/Subtitle-sample.evo [21:10:56 CEST] <nevcairiel> evo uses dts? [21:11:18 CEST] <nevcairiel> i thoughts eac3 is the evo-level madness [21:11:30 CEST] <cehoyos> thank you [21:11:31 CEST] <wm4> well this file does [21:11:50 CEST] <wm4> the file has vc1/dts/eac3/ac3 [21:11:52 CEST] <wm4> all the good stuff [21:11:58 CEST] <nevcairiel> evo is primarily vc1 [21:12:05 CEST] <nevcairiel> thank god hd-dvd didnt make it [21:12:05 CEST] <nevcairiel> :D [21:12:49 CEST] <JEEBsv> :D [21:24:16 CEST] <jamrial> didn't hd-dvd use h264? [21:24:47 CEST] <jamrial> i remember back in the early years hd-dvd was h264 and some blu-rays were mpeg2, even [21:24:50 CEST] <nevcairiel> the same formats as BD are supported [21:24:58 CEST] <nevcairiel> vc1, h264 and mpeg2 [21:25:11 CEST] <nevcairiel> but i've seen most hd-dvds using vc1 for some reason [21:25:49 CEST] <nevcairiel> similarly, it often uses eac3, despite also supporting the typical blu-ray audio formats like ac3, truehd, dts, dts-hd [21:28:42 CEST] <nevcairiel> the terrible part about evo is that it encodes 24p video using 3:2 soft pulldown flags, and appropriate timestamps [21:28:54 CEST] <nevcairiel> its a terrible format, so much dvd legacy left in it [22:21:17 CEST] <cone-815> ffmpeg 03Vignesh Venkatasubramanian 07master:34ae98a77189: lavf/webm_chunk: Remove AVFMT_ALLOW_FLUSH [22:43:22 CEST] <jamrial> so about 130 warnings when compiling ffmpeg with gcc 5.1 are bogus (-Warray-bounds) [22:43:41 CEST] <nevcairiel> i still didnt bother getting gcc 5.1 [22:43:53 CEST] <nevcairiel> i dont trust first releases of a new line [22:44:14 CEST] <philipl> I can't believe they haven't run out of warnings to add after all this time. [22:44:18 CEST] <jamrial> they got fixed anyway. not backported to gcc5 branch yet but will before gcc 5.2 is released [22:44:36 CEST] <Daemon404> so 12 months from now [22:44:54 CEST] <nevcairiel> i wonder where gcc 4.9.3 disappeared to, it was originally scheduled for like march/aprilk [22:44:56 CEST] <nevcairiel> -k [22:44:57 CEST] <jamrial> you can always just compile a snapshot from the gcc5 branch :p [22:45:15 CEST] <jamrial> some distros do that and never bother with actual releases [22:45:28 CEST] <Daemon404> i look forward to -Wfalse-warn [22:45:39 CEST] <Daemon404> "warning: previous warning may be false" [22:50:20 CEST] <philipl> heh [22:56:41 CEST] <cone-815> ffmpeg 03Simon Thelen 07master:83307a32eb0c: libavutil/channel_layout: Correctly return layout when channel specification ends with a trailing 'c'. [23:15:56 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:6ddb109b9096: doc/APIchanges: Add 2.7 separator [23:15:57 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:a5f44bc4460b: doc/APIchanges: fill in missing stuff [23:15:58 CEST] <cone-815> ffmpeg 03Michael Niedermayer 07master:3a99f6e79fa3: Changelog: Add 2.7 entry [23:23:18 CEST] <cone-815> ffmpeg 03Andreas Cadhalpun 07master:58995f647b5f: sonic: set avctx->channels in sonic_decode_init [23:47:31 CEST] <cone-815> ffmpeg 03Andreas Cadhalpun 07release/2.7:HEAD: sonic: set avctx->channels in sonic_decode_init [00:00:00 CEST] --- Wed Jun 10 2015