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

[burek]

[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