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

Wed Jun 10 02:05:02 CEST 2015

[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-applications/
[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-set-loose-on-ohio-highway-after-truck-overturns/
[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