[01:12:48 CEST] <Zeranoe> Trying to find a copy of Windows XP to make sure FFmpeg works is like chasing dinosaurs... [01:13:10 CEST] <nevcairiel> the libraries at least still work fine, I would get crying users if it didnt [02:45:00 CEST] <cone-017> ffmpeg 03Michael Niedermayer 07master:5ccca4eb8e1e: avcodec/jpeg2000dec: Add some additional checking on lengthinc [02:45:00 CEST] <cone-017> ffmpeg 03Michael Niedermayer 07master:b395fd3de7da: avcodec/jpeg2000dec: add some sanity checking on newpasses [03:31:32 CEST] <cone-017> ffmpeg 03Michael Niedermayer 07master:eea92133a16e: avcodec/mqcdec: Support raw bypass and non reseting init [03:31:33 CEST] <cone-017> ffmpeg 03Michael Niedermayer 07master:dc73c7adc028: avcodec/jpeg2000dec: Fix Selective arithmetic coding bypass and Multiple codeword segments [03:42:05 CEST] <cone-017> ffmpeg 03Michael Niedermayer 07master:4af9eb4f75c3: avcodec/jpeg2000dec: Remove unused variable and argument [05:02:19 CEST] <cone-017> ffmpeg 03Michael Niedermayer 07master:1b3fbe41c517: avcodec/jpeg2000dec: Do not print a warning for RLCP [05:02:20 CEST] <cone-017> ffmpeg 03Michael Niedermayer 07master:e7adb02d3bc1: avcodec/jpeg2000dec: Do not hardcode tile part usage [05:54:31 CEST] <jamrial> ffmpeg.org seems down [05:56:03 CEST] <rcombs> resolves, but doesn't respond to ping [05:58:33 CEST] <cantstanya> is it dead? [06:04:25 CEST] <jamrial> it's back now [08:16:50 CEST] <cehoyos> nevcairiel: You are using a different mkv demuxer than FFmpeg, no? [08:17:01 CEST] <cehoyos> Could you test the sample from videolan ticket 12831? [08:17:37 CEST] <cehoyos> Is it supposed to contain more than one video stream that contains data? FFmpeg only sees one video stream with data and one without afaict. [10:54:10 CEST] <nevcairiel> cehoyos_: the ticket doesnt mention anything about a second stream, and the mkv header info also has no second video stream, just one video and one audio [10:55:26 CEST] <nevcairiel> that ffmpeg somehow finds a second clone of all the streams seems like a bug [10:58:42 CEST] <cehoyos_> nevcairiel: ffmpeg -i file sees two video streams [10:58:46 CEST] <cehoyos_> But on has no pix_fmt [10:59:02 CEST] <nevcairiel> the mkv header only has one video and audio stream [10:59:05 CEST] <nevcairiel> the extra stream is a bug [10:59:08 CEST] <cehoyos_> Old vlc (the only I tested) "mixes" two video streams visually, one of them is the one that FFmepg sees [10:59:42 CEST] <cehoyos_> So what ffplay shows is what your demuxer plays? [11:00:34 CEST] <nevcairiel> yes [11:00:37 CEST] <cehoyos_> I forgot to test mkvinfo, but I see now that it only shows one stream. [11:00:51 CEST] <cehoyos_> How can I export the video stream with mkvinfo? [11:00:53 CEST] <cehoyos_> (Sorry) [11:01:02 CEST] <nevcairiel> mkvextract is for extracting [11:02:07 CEST] <cehoyos_> I meant: How is the mkvextract syntax (in case you know it out of your head) [11:02:10 CEST] <cehoyos_> ? [11:02:39 CEST] <nevcairiel> i do not know [11:03:33 CEST] <nevcairiel> looks l ike mkvextract tracks "file.mkv" 1:video.vp9 should do it [11:04:00 CEST] <nevcairiel> or rather, 0:video.vp9 [11:04:03 CEST] <nevcairiel> apparently it starts at 0 [11:05:11 CEST] <cehoyos_> Thank you! [11:05:19 CEST] <cehoyos_> The filesizes indicate that there is nothing hidden. [11:05:24 CEST] <cehoyos_> Or at least not much [11:05:41 CEST] <nevcairiel> mkvinfo also shows no unexpected elements in the file [11:05:48 CEST] <nevcairiel> matroskadec is just broken then :D [11:08:16 CEST] <wm4> link to file? [11:08:40 CEST] <nevcairiel> https://mega.co.nz/#!owp2WAyJ!LeXcFPqE4Ap9QBwt4Zw4unmpm1UQh2ba0SK0T4UB4x4 [11:10:44 CEST] <nevcairiel> i bet the seekheads are screwed up and that confuses the parser, or something [11:14:40 CEST] <wm4> so the problem is that ffmpeg sees 2 video tracks? [11:15:05 CEST] <nevcairiel> it sees 2 video and 2 audio tracks, only the first 2 seem to actually work [11:15:20 CEST] <nevcairiel> like its parsing the segment tracks twice for some obscure reason [11:17:26 CEST] <wm4> mpv's demuxer claims that the seekhead entries don't have an ID set [11:18:18 CEST] <wm4> not sure how to interpret mkvinfo's output though [11:20:59 CEST] <nevcairiel> the id in the seekhead seems to be .. backwards [11:21:27 CEST] <nevcairiel> mkvinfo says its 0x6b 0xae 0x54 0x16 for the tracks seekhead [11:21:35 CEST] <nevcairiel> but thats the tracks id in reverse [11:21:36 CEST] <nevcairiel> :D [11:21:50 CEST] <wm4> is there a tool that dumps raw ebml? [11:21:58 CEST] <nevcairiel> mkvinfo can do it in full output mode [11:22:02 CEST] <nevcairiel> or when you use its GUI mode [11:23:28 CEST] <nevcairiel> wtf is IDMmkvlib0.1 anyway [11:23:32 CEST] <nevcairiel> the writing lib of that file [11:26:38 CEST] <wm4> ok, mpv's demuxer simply rejects the invalid IDs and disregards such seekhead entries completely [11:26:48 CEST] <wm4> while matroskadec will attempt to read them [11:27:06 CEST] <nevcairiel> matroskadec reads them, and then reads them again without the seekhead, apparently [11:27:12 CEST] <wm4> but since it uses the ID noted in the seekhead entry to avoid reading elements twice, this happens [11:28:52 CEST] <wm4> so matroska_find_level1_elem() would need the actual position of the element, and would have to use this to exclude the broken elements [11:29:02 CEST] <wm4> but in this case it'd be easier to just reject invalid IDs [11:29:20 CEST] <wm4> I mean, the IDs are not well-formed and thus are impossible [11:29:41 CEST] <wm4> I guess I'll write a patch [11:30:06 CEST] <nevcairiel> someone confused endianness when writing their mkv writer [11:30:10 CEST] <nevcairiel> but oddly e nough only for this id [11:31:30 CEST] <wm4> lol [11:31:39 CEST] <wm4> (just... how) [11:51:25 CEST] <ubitux> do we have a mechanism to know wheither an hwaccelerated frame can go through a filtergraph with or without copy, or can it be done transparently by lavfi? [11:52:21 CEST] <ubitux> like typically, if a filtergraph is composed of buffer* filters, fps, setpts, select or similar, there is no need for a copy to cpu [11:52:45 CEST] <ubitux> which is useful if you plan to encode yourself with the same accelerated mechanism, or simply reuse it directly as a gpu texture or whatever [11:53:35 CEST] <wm4> not sure what you mean [11:53:53 CEST] <wm4> copying is only needed when actually writing to the image data, which you just don't do with this type of surfaces [11:54:59 CEST] <nevcairiel> you also need to copy when reading, since this is hwaccel [11:55:41 CEST] <wm4> I think he means native filtering [11:55:53 CEST] <wm4> not reading back to the CPU [11:55:57 CEST] <nevcairiel> all his examples are filters that dont access image data at all [11:56:33 CEST] <wm4> ubitux: there's one thing you have to be extremely careful of [11:56:34 CEST] <nevcairiel> although ffmpeg.c doesnt allow you to even keep the native hwaccel format right now, it'll always copy to sysmem [11:56:54 CEST] <wm4> ubitux: you mustn't destroy the hwaccel state (or some of it) while a frame still lives somewhere [11:57:18 CEST] <nevcairiel> for dxva2 i have the frames keep a reference on the decoder object [11:57:29 CEST] <ubitux> yeah that's fine with me [11:57:30 CEST] <nevcairiel> so its at least designed "safe" [11:57:38 CEST] <ubitux> the idea is that i'm working on a player-like [11:58:00 CEST] <ubitux> which uses libavfilter (for doing convert *if necessary*, or adjust fps, or that kind) [11:58:06 CEST] <nevcairiel> you could make those filters accept the hwaccel pixfmts, but that sounds like its going to get ugly soon [11:58:11 CEST] <ubitux> and i'm adding some video accel now [11:58:27 CEST] <ubitux> so i'm wondering if i can feed these hwaccelerated frame (unusable for reading) to lavfi safely [11:58:38 CEST] <wm4> why not [11:58:54 CEST] <nevcairiel> the problem is that lavfi cannot "convert" them to normal pixfmts transparently if it needed to [11:59:05 CEST] <nevcairiel> could teach vf_scale to do that =p [11:59:25 CEST] <ubitux> right, so the other way is to know if i can be sure the filtergraph will need to read the frames or not [11:59:34 CEST] <wm4> it must be vf_scale because lavfi is too dumb to have multiple conversion filters [12:00:53 CEST] <ubitux> i don [12:00:59 CEST] <ubitux> i don't understand your last sentence [12:05:22 CEST] <wm4> ? [12:07:53 CEST] <ubitux> well, what do you mean by multiple conversion filters? [12:08:12 CEST] <ubitux> how is it impossible or complicated to have them in a filtergraph? [12:08:17 CEST] <wm4> in theory you could have something like vf_vdpautocpu [12:08:29 CEST] <ubitux> ah, yeah [12:08:36 CEST] <wm4> which reads a vdpau surface and copies it to a system memory surface [12:08:48 CEST] <wm4> but I bet it'd be hard to make lavfi insert this filter automatically [12:08:56 CEST] <wm4> because it assumes there's only vf_scale [12:09:00 CEST] <nevcairiel> you could make lavfi use that, but it would need to be hardcoded into lavfi graph building to insert it w hen needed [12:09:17 CEST] <ubitux> well we can just accept the hwaccelerated pix fmts in scale [12:09:27 CEST] <ubitux> and call the appropriate hw "convert" code [12:09:33 CEST] <ubitux> or error out if impossible [12:09:37 CEST] <wm4> (though I guess in theory AVFrame is going to need a hwaccel context field anyway, which could include a readback-to-cpu callback) [12:09:47 CEST] <ubitux> the thing is that we need to mark filter that actually need cpu data [12:09:50 CEST] <ubitux> from those who don't [12:09:59 CEST] <wm4> (which means it'd be a matter of calling the callback in vf_scale, and done) [12:10:01 CEST] <ubitux> and i was wondering if we already had that [12:10:07 CEST] <nevcairiel> we do not [12:10:11 CEST] <ubitux> ok [12:44:53 CEST] <cehoyos_> michaelni: Last commit message contained "Fixes part of Ticket 4605" - the sample is decoded bit-exact though both with jasper and libopenjpeg [12:45:05 CEST] <cehoyos_> Should the ticket be closed? [12:45:11 CEST] <michaelni> yes [12:50:03 CEST] <cehoyos_> Done [14:15:49 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:04f00022910c: configure: Disable VSX on unspecified / generic CPUs [14:15:50 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:d59a033a69c4: avformat/mpegts: recognizes and export private streams [14:18:41 CEST] <ubitux> oh, seems the vda guy is going back on the vt after my mail [14:18:47 CEST] <ubitux> heh i guess that saves me some work [14:19:14 CEST] <Daemon404> runnign ffmpeg through fbinfer [14:19:18 CEST] <Daemon404> for shits n giggles [14:19:23 CEST] <Daemon404> (im sure osmsone already did) [14:19:38 CEST] <wm4> fbinver? [14:19:41 CEST] <wm4> *fer [14:19:50 CEST] <ubitux> "A static analyzer for mobile apps"? [14:19:54 CEST] <Daemon404> it supports C [14:19:56 CEST] <Daemon404> and make [14:20:05 CEST] <wm4> so why is it targetted at mobile apps [14:20:15 CEST] <Daemon404> because it's called marketing [14:20:28 CEST] <Daemon404> seems to work on any C, java, or obj-c [14:20:40 CEST] <wm4> urgh facebook [14:21:02 CEST] <Daemon404> it's written in ocaml. [14:21:43 CEST] <nevcairiel> people actually use ocaml? [14:21:45 CEST] <nevcairiel> weird world [14:21:57 CEST] <Daemon404> well it's static analysis [14:22:01 CEST] <Daemon404> aka written by PL geeks [14:22:05 CEST] <Daemon404> aka the only people who use ML [14:22:19 CEST] <nevcairiel> heh [14:23:27 CEST] <Daemon404> wow the analysis pass is using all cpus [14:23:47 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07release/2.7:5a0862af5529: avcodec/h264_slice: Use AVFrame diemensions for grayscale handling [14:23:48 CEST] <cone-728> ffmpeg 03Andreas Cadhalpun 07release/2.7:1051c152f97c: takdec: ensure chan2 is a valid channel index [14:23:49 CEST] <cone-728> ffmpeg 03Deliang Fu 07release/2.7:665b67014f87: avformat: Fix bug in parse_rps for HEVC. [14:23:50 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07release/2.7:259bb2555b70: configure: Disable VSX on unspecified / generic CPUs [14:25:56 CEST] <Daemon404> looks like it has some errors [14:26:35 CEST] <Daemon404> http://pastie.org/private/fyepzivizriysqdas3qysg [14:26:56 CEST] <Daemon404> michaelni, ^ [14:27:00 CEST] <Daemon404> maybe you are interested [15:06:44 CEST] <ubitux> Daemon404: ah nice [15:06:46 CEST] <ubitux> thx [15:07:09 CEST] <ubitux> i'll have a look for ass_split and lut3d at least [15:07:29 CEST] <Daemon404> >ass_split [15:07:35 CEST] <Daemon404> naming. [15:07:39 CEST] <ubitux> ;) [15:09:42 CEST] <beastd> heh. IIRC the "ass" name was favored because it sounds way more funny... now we have to live with ass ;) [15:13:17 CEST] <wm4> it's derived from SSA [15:13:22 CEST] <wm4> Advanced SSA [15:13:28 CEST] <wm4> the bad jokes will live with us forever [15:16:28 CEST] <beastd> personally I would have favoured going with ssa for the naming (in comments and documentation we could have used ASS as opposed to ass when appropriate/needed). but maybe that would not have been better either... [15:17:34 CEST] <thardin> what's from with ASSA? [15:17:38 CEST] <thardin> wrong even [15:19:47 CEST] <Daemon404> ssa != ass [15:19:49 CEST] <Daemon404> @ beastd [15:19:53 CEST] <Daemon404> theyre different formats. [15:21:11 CEST] <beastd> Daemon404: no compat at all? [15:21:19 CEST] <Daemon404> theyre different syntax [15:22:27 CEST] <beastd> then i am misremembering things, i was thinking that it works more like an extension [15:24:10 CEST] <Daemon404> no [15:24:55 CEST] <wm4> it is kind of an extension, like HEVC is an extension of h264 [15:25:41 CEST] <beastd> well i do not know enough contibute to the debate: but my memory was more like it is described here: http://wiki.multimedia.cx/index.php?title=SubStation_Alpha [15:26:11 CEST] <beastd> and on another note do we support SSA (thought we do) and if yes through what component? [15:29:59 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:3dea13e710ce: avcodec/jpeg2000dec: Assert that pixel format descriptor is not NULL [15:30:00 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:ae0148ff60cb: swscale: Assert that pixel format descriptor is not NULL [15:30:01 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:80b5a1e2eee9: Mark vectors as NAN instead of dereferencing NULL pointers on malloc failure [15:32:07 CEST] <ubitux> beastd: by supporting ssa we support ass [15:32:10 CEST] <ubitux> erm [15:32:14 CEST] <ubitux> beastd: by supporting ass we support ssa [15:32:16 CEST] <ubitux> sorry [15:34:45 CEST] <beastd> well than it is kind of like i thought => my remark was ok then. anyway this was just meant as that, things already happened. no need to fight over things... [15:35:37 CEST] <Daemon404> ubitux, the file syntax is sitll diff [15:35:43 CEST] <Daemon404> ssa is not a subset of ass so to speka [15:35:50 CEST] <Daemon404> vsfilter is jus ta pile of crap that happens to work [15:36:03 CEST] <nevcairiel> its compatible enough to just work(tm) [15:36:04 CEST] <nevcairiel> :D [15:36:16 CEST] <ubitux> yeah but we support both anyway [15:36:23 CEST] <ubitux> inside ass demuxers/decoders [15:36:37 CEST] <Daemon404> i blame vsfilter for encouraging such shitty behavior [15:36:43 CEST] <Daemon404> sorry, vshitler [15:37:06 CEST] <beastd> "inside ass" <-- will it ever stop ;) [15:39:58 CEST] <beastd> Daemon404: I think I understand the point you are trying to make. I just think the component and source naming with "ssa" would have been ok. I also expressed doubt myself as it would have had other downsides. [15:41:11 CEST] <beastd> thardin: I think "assa" is just too uncommon to be better. i doubt anyone would associate SSA/ASS with it. [15:46:03 CEST] <Daemon404> ubitux, ping [15:46:08 CEST] <ubitux> pong [15:46:11 CEST] <Daemon404> -force_key_frames expr:gte(t,n_forced*3) [15:46:19 CEST] <Daemon404> ^ would this not set a keyframe every 3 sec [15:47:04 CEST] <ubitux> it should, i guess [15:47:49 CEST] <Daemon404> it's setting the first 165 frames all to I... [15:47:58 CEST] <Daemon404> (fps is ~30) [15:50:19 CEST] <thardin> beastd: ye, too late to change [15:52:07 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:8e91d9652ea5: ffmpeg_opt: Check for localtime() failure [15:52:14 CEST] <Daemon404> ubitux, any idea why? [15:52:39 CEST] <ubitux> sorry, i have none [15:52:49 CEST] <ubitux> t being invalid? [15:52:49 CEST] <nevcairiel> whats n_forced [15:53:04 CEST] <ubitux> Daemon404: try to print() inside the eval [15:53:16 CEST] <ubitux> gte(print(t),n_forced*3) [15:53:23 CEST] <ubitux> gte(t,print(n_forced)*3) [15:53:31 CEST] <ubitux> print(gte(t,n_forced*3)) [15:53:33 CEST] <ubitux> that kind of stuff [15:53:37 CEST] <Daemon404> n_forced [15:53:38 CEST] <Daemon404> the number of forced frames [15:53:41 CEST] <Daemon404> what exactly does this mean [15:53:50 CEST] <ubitux> dunno, i never used that [15:54:11 CEST] <Daemon404> i see [15:54:22 CEST] <Daemon404> the example in the man page has the same problem... [15:55:23 CEST] <nevcairiel> n_forced is presumably the number of frames that it set the keyframe flag for [15:56:31 CEST] <nevcairiel> and n the number of frames that came through in total [15:56:33 CEST] <nevcairiel> or something [15:57:41 CEST] <Daemon404> ... i think i see the issue [15:58:52 CEST] <nevcairiel> the expression you used should work fine, i think [15:58:58 CEST] <nevcairiel> maybe quote it? [15:59:42 CEST] <Daemon404> no... i have a theory [15:59:47 CEST] <Daemon404> yes... seems to be right [16:00:12 CEST] <Daemon404> yep [16:00:17 CEST] <Daemon404> non-zero start time. [16:00:25 CEST] <nevcairiel> that would break this approach [16:00:39 CEST] <ubitux> not possible to do start_time-t or something? [16:00:47 CEST] <Daemon404> ubitux, i know the start time already [16:00:49 CEST] <ubitux> i think we have a similar example for select & friends [16:00:53 CEST] <Daemon404> so i can use the other example from the man page [16:01:00 CEST] <Daemon404> -force_key_frames expr:if(isnan(prev_forced_t),gte(t,13),gte(t,prev_forced_t+5)) [16:01:04 CEST] <Daemon404> just s/13/start_time/ [16:05:14 CEST] <nevcairiel> Wonder how much screaming we would get if we just transparently removed start_time from all timestamps and set it to 0 [16:05:27 CEST] <nevcairiel> i'm sure there are some obscure use-cases which this would break, so we could never do it [16:06:54 CEST] <Daemon404> nevcairiel, ffmpeg cli does [16:07:04 CEST] <Daemon404> this was using passthrough [16:07:45 CEST] <nevcairiel> i'm talking like on a avformat level, who needs the start_time really, it would be easier on everyone if it stopped being required [16:09:57 CEST] <Daemon404> an... [16:10:03 CEST] <Daemon404> ah* [16:44:58 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:eaa86850336a: avcodec/jpeg2000dec: Do not abort if prc is outside limits [16:44:59 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:5b2f9790e6eb: avcodec/jpeg2000dec: Fallback to yuv if no matching xyz format exists [16:56:24 CEST] <nevcairiel> so much jp2k work [16:56:36 CEST] <nevcairiel> too bad its damn slow on top of everything :D [17:04:20 CEST] <ubitux> well, one step at a time :) [17:04:36 CEST] <ubitux> it's nice to see some improvements on the native decoder [17:07:08 CEST] <nevcairiel> the original author had some sse2 things in work, but he disappeared before ever submitting them [17:16:06 CEST] <ubitux> remind me of hevc [17:16:12 CEST] <ubitux> +s [17:57:11 CEST] <Daemon404> [16:16] < ubitux> remind me of hevc <-- doubly so because iirc it was a project too. [17:57:21 CEST] <Daemon404> via some org. [17:57:29 CEST] <nevcairiel> probably [17:57:43 CEST] <nevcairiel> his target for jp2k was quite narrow, ie. getting a specific dcinema profile working [17:58:00 CEST] <Daemon404> j2k is one of those files that makes me go wtf [17:58:05 CEST] <Daemon404> cause we support up to some res [17:58:14 CEST] <Daemon404> whic his just weird [17:58:20 CEST] <Daemon404> "we can decode res > XxY" [17:58:22 CEST] <Daemon404> cant* [19:13:22 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:971b37796073: avcodec/jpeg2000dec: Reduce verbosity of get_plt() [19:15:46 CEST] <cone-728> ffmpeg 03Paul B Mahol 07master:cfe8a89b0087: avfilter/vf_zoompan: support planar rgb pixel formats [19:20:12 CEST] <Zeranoe> Had to remove mfx from the Win builds to maintain support for Windows XP. [19:20:40 CEST] <BBB> that sounds awkward, why? [19:21:16 CEST] <Zeranoe> I haven't dug into mfx's code yet, but something must have forced it [19:22:42 CEST] <BBB> do you know if its enc or dec? [19:22:53 CEST] <BBB> enc does this weird thing where it includes config.h at the end of its include list [19:22:56 CEST] <BBB> which is kind of weird [19:23:48 CEST] <Zeranoe> I don't, but in all reality it might be both. I'll look [19:24:59 CEST] <nevcairiel> intels video things dont really support XP, never have. they don't even support dxva video decode on XP [19:26:11 CEST] <Zeranoe> I doubt it's better than H.264 anyway, so it's not a huge loss. [19:26:23 CEST] <Zeranoe> x264* [19:27:07 CEST] <nevcairiel> its not, but having the cpu free can be quite useful in some situations [19:27:34 CEST] <Zeranoe> Isn't it still a CPU encoder? [19:27:55 CEST] <Compn> i had a dream microsoft came and did full audits of ffmpeg and helped fix up a lot of bugs. [19:27:56 CEST] <Zeranoe> just "intel optimized" [19:27:57 CEST] <Daemon404> xp is the reason we cant have nice things [19:28:03 CEST] <Daemon404> like a reasonable win32<->pthreads bridge [19:28:16 CEST] <nevcairiel> Zeranoe: no, its for the quicksync encoding hardware [19:28:31 CEST] <Zeranoe> A [19:28:32 CEST] <Zeranoe> h [19:29:01 CEST] <nevcairiel> although intel also has a software stack for all these things, but no reason to use that [19:30:09 CEST] <Daemon404> nevcairiel, we should obviously add intel IPP support [19:30:30 CEST] <nevcairiel> to be honest some of those things are quite nice [19:30:34 CEST] <cone-728> ffmpeg 03wm4 07master:7e240f958183: matroskadec: verify seekhead IDs [19:32:10 CEST] <Zeranoe> Fun fact, XP is the 2nd most used OS http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0 [19:32:19 CEST] <Daemon404> shits i give: 0 [19:32:23 CEST] <nevcairiel> those stats are tainted [19:32:27 CEST] <Daemon404> shouldnt be encouragin its use [19:32:34 CEST] <Daemon404> yes theyre biased [19:32:45 CEST] <Zeranoe> I wont argue with that, it comes as a surprise. [19:32:48 CEST] <nevcairiel> lots of corporate shit PCs that noone really cares to update [19:33:41 CEST] <Zeranoe> Lemme look at what ffmpeg.zeranoe.com sees... [19:34:14 CEST] <cone-728> ffmpeg 03Paul B Mahol 07master:ce3bcb9479a4: doc/filters: add one more zoompan example [19:35:45 CEST] <Zeranoe> Win 7 is 61.14%, 8.1 is 28.08%, and XP is a whopping 5.18% [19:35:49 CEST] <Compn> Zeranoe : are you still unable to make builds for win2k ? [19:36:00 CEST] <Compn> or did you give up looking into that ? [19:36:13 CEST] <Compn> i think the only option would be to compile in a win2k vm ... [19:36:20 CEST] <rcombs> "Linux" as one category [19:36:25 CEST] <rcombs> also, "Mac OS X 1092" [19:36:41 CEST] <Daemon404> rcombs, yeah it should just be called "other" [19:37:43 CEST] <Zeranoe> Compn: huh [19:39:43 CEST] <Compn> do your builds work in windows98/win2k ? [19:39:54 CEST] <nevcairiel> Compn: noone cares [19:40:22 CEST] <nevcairiel> and its impossible to build a current ffmpeg for win2k without hacking the code, as its no longer supported [19:40:35 CEST] <Compn> ah [19:40:37 CEST] <Zeranoe> Compn: It was hard enough to even get a XP VM up and running, I'm gonna run from 2k [19:41:10 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:d0061e77cde5: avformat/mxfdec: Detect jpeg2000 through codec_ul too [19:44:57 CEST] <Compn> no problem then :) [20:00:59 CEST] <cone-728> ffmpeg 03PrzemysBaw Sobala 07master:c39637f36aa3: libavcodec/imgconvert.c: support left band while cropping [20:33:47 CEST] Action: jamrial votes for the next version to be ffmpeg 3, dropping pre-vista support and all the pre-SSE optimizations [20:34:39 CEST] <jamrial> clean up the codebase a bit [20:35:22 CEST] <nevcairiel> xp support is mostly the threading wrapper, thats not too much code [20:35:46 CEST] <nevcairiel> not that i care personally, but i bet some of my users would throw a hissy-fit [20:36:29 CEST] <jamrial> there's also some stuff in lavf os_support.c [20:37:18 CEST] <jamrial> structs like pollfd and related functions [20:38:58 CEST] <rcombs> we dropped XP a while ago because it was convenient [20:39:09 CEST] <rcombs> not a whole lot of whining [20:39:28 CEST] <nevcairiel> its probably only a handful users, but they like being very vocal [20:39:36 CEST] <rcombs> there's the occasional guy in the forums asking for help with $old_server_version running XP and I go "well no we don't support that" [20:40:28 CEST] <nevcairiel> but my project is also used by a lot of other projects to facilitate decoding, so i'm not sure how they would feel about dropping XP [20:41:33 CEST] <rcombs> isn't XP spelled 😝 these days [20:41:44 CEST] <nevcairiel> "box"? :D [20:42:21 CEST] <rcombs> it's an XP emoji [20:42:30 CEST] <rcombs> as in, XD with tongue stuck out [20:42:39 CEST] <rcombs> but sure that too [20:53:56 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:8b5007a31b8d: mpegvideo: Move ER functions to a separate file [20:53:57 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:58f63670e173: Merge commit '8b5007a31b8d1ddbe3661bf45a732336450b7d25' [21:05:01 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:e3d0f49abb20: mpegvideo: h263: Move all tables to a single file [21:05:02 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:218f58a16a3d: Merge commit 'e3d0f49abb20a551bf6d885f75c354d6d0bbeb9d' [21:14:09 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:e7af52a68dde: mpegvideo: rv10: Move function declaration to a separate header [21:14:10 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:b5c71fba5943: Merge commit 'e7af52a68dde9144b273a9598b60bf0f56e1323b' [21:22:48 CEST] <cone-728> ffmpeg 03Andreas Cadhalpun 07master:1189af429211: h264: update avctx width/height/pix_fmt when returning frame [21:33:42 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:f1fa1eed2abd: mpegvideo: Expand macro [21:33:43 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:dbf172e6f44d: Merge commit 'f1fa1eed2abdc8dfb0af318a43f5d293b81141bd' [21:42:29 CEST] <cone-728> ffmpeg 03Luca Barbato 07master:8606e881b02b: mpeg12: Move the vlc bits to a stand alone file [21:42:30 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:d52c5e9d75e9: Merge commit '8606e881b02bec2ac24943d22c8afe11d641fac8' [21:55:15 CEST] <cone-728> ffmpeg 03Luca Barbato 07master:64a2e844166d: eamad: Use the correct headers [21:55:16 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:5e87080f2c73: h264_weight: Fix SSSE3 biweight code with weights of 128 [21:55:17 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:85d0df0c3090: Merge commit '64a2e844166d62093b45e680874eea8bd1facf5b' [21:55:18 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:b68b5ec5136d: Merge commit '5e87080f2c73186066df0b9c43877b4af0beef3a' [22:10:28 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:b7a4127a45b7: h264_qpel: Use the correct header [22:10:29 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:63b0356274bc: Merge commit 'b7a4127a45b780d76e6b09427a3d0197c4bc1cdb' [22:34:07 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:8a78ae2d2101: segment: Check open_null_ctx() return value [22:34:08 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:449c74f629cb: Merge commit '8a78ae2d2101622fd244b99178d8bc61175c878e' [22:45:46 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:a9b2a51178ea: avconv_opt: Check localtime() return value [22:45:47 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:6cfaa51acbf7: Merge commit 'a9b2a51178ea446909015f061ab5df65e3b66bf6' [22:53:37 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:30dfc1dad428: cws2fws: Close file handles on error [22:53:38 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:e1ec9c7fb6ba: Merge commit '30dfc1dad4285e7362ce3f596d7c5d5d9b7fb33d' [23:03:05 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:a7ac1a7b9444: flv: Name an enum and use its type [23:03:06 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:00ebf89dcdeb: Merge commit 'a7ac1a7b94447f33ae95be4d6d186e2775977f91' [23:11:06 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:2d5176fad1a4: on2avc: Use the integer abs() version [23:11:07 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:fd04082af985: Merge commit '2d5176fad1a4556d209cbfb0f681712c7eada4fd' [23:21:50 CEST] <cone-728> ffmpeg 03Vittorio Giovara 07master:3b73d5c942f4: fft-test: Use the float fabs() version [23:21:51 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:2cbadf51e80a: Merge commit '3b73d5c942f44b37f0e44276ebcfd66c8b12c02d' [23:34:08 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:ea37df2d528c: avutil/imgutils: Simplify pix_fmt validity check in av_image_get_linesize() [00:00:00 CEST] --- Sat Jun 13 2015