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

burek burek021 at gmail.com
Thu Oct 15 02:05:02 CEST 2015


[01:22:28 CEST] <cone-857> ffmpeg 03James Almer 07master:74a87ae21075: x86/vp9itxfm: fix register clobbering in ff_vp9_idct_idct_4x4_add_12_sse2
[01:43:42 CEST] <cone-857> ffmpeg 03Ganesh Ajjanagadde 07master:4c8ca76965b1: ffserver_config: check for INT_MIN before doing FFABS
[01:46:04 CEST] <cone-857> ffmpeg 03Ganesh Ajjanagadde 07master:d59bfcd11229: avformat/mov: fix integer overflow
[02:49:00 CEST] <BBB> jamrial: thanks for the fixage
[02:49:07 CEST] <jamrial> np
[04:32:30 CEST] <cone-857> ffmpeg 03Ganesh Ajjanagadde 07n2.8.1:HEAD: avformat/mov: fix integer overflow
[05:36:26 CEST] <highgod> Hi, I wan't to ask a question about hevc, I looked into the code, but I am confused how ffmpeg release reference frames in DPB?
[05:37:00 CEST] <highgod> how to check whether the frames will not be used in the following decoding?
[05:37:12 CEST] <highgod> Thanks
[06:03:49 CEST] <jamriall> highgod: if nobody replies just wait. it's early morning for most devs
[06:04:00 CEST] <jamriall> especially for those that know hevc enough to answer that :p
[07:12:18 CEST] <highgod> oh, hehe
[11:25:24 CEST] <highgod> I am confuse about the ST_FOLL list, don't konw when to release the data
[11:25:34 CEST] <highgod> about hevc
[11:27:50 CEST] <j-b> 'lo
[11:28:09 CEST] <highgod> I looked into dxva2 code for hevc
[11:28:30 CEST] <highgod> but for some video, the dxva need ST_FOLL list
[11:28:41 CEST] <highgod> I don't know when to release them
[11:28:55 CEST] <highgod> if I don't set it to dxva
[11:29:01 CEST] <highgod> the result is not correct
[11:33:25 CEST] <nevcairiel> highgod: if you have a video that fails with current ffmpeg  dxva2 hevc, i would appreciate a sample of that
[11:34:38 CEST] <highgod> nevcairiel:no, ffmpeg dxva2 hevc for the video is OK
[11:35:38 CEST] <highgod> but the our dxva2 code is not correct, so I reference the ffmpeg code. I found that ffmpeg dxva2 code set the ST_FOLL list value to the poc list, but we don't
[11:36:04 CEST] <nevcairiel> the dxva2 code doesnt directly reference the ST_FOLL list at all
[11:36:05 CEST] <highgod> so we set the list, then our code is ok, but I don;t konw when to release the surface for foll list
[11:36:31 CEST] <nevcairiel> but RefPicList needs to contain all the references, even if they are not in ST_CURR_* or LT_CURR*
[11:36:51 CEST] <nevcairiel> ie. all the refs from the DPB
[11:38:31 CEST] <highgod> nevairiel:yeah, we didn't set all refs in DPB before, just set the list0 and list1, and we fixed it by reference ffmpeg code
[11:38:52 CEST] <highgod> but how to release the foll list?
[11:39:00 CEST] <highgod> I didn't find the code
[11:39:14 CEST] <highgod> because our code does not use the foll list before
[11:39:15 CEST] <highgod> hehe
[11:39:45 CEST] <nevcairiel> from what I can see, those lists are built at the beginning of every frame from the DPB and the frame header info
[11:40:01 CEST] <nevcairiel> or maybe every slice even
[11:41:00 CEST] <highgod> for list0 and list1, we use max-ref-distance to release
[11:41:24 CEST] <highgod> but I don't konw how to release the foll list, what condition to release it
[11:41:25 CEST] <highgod> hehe
[13:18:04 CEST] <durandal_170> Ok to push adpcm psx?
[13:34:25 CEST] <cone-538> ffmpeg 03Luca Barbato 07master:00332e0a064d: wrapped_avframe: Initial implementation
[13:34:25 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:037b44a3b44e: Merge commit '00332e0a064dad866812de9162b009cbaba6f5df'
[13:38:56 CEST] <BBB> nevcairiel: both patches ok with me
[13:39:04 CEST] <BBB> nevcairiel: did you get it working already?
[13:39:18 CEST] <nevcairiel> nah, i think the driver is still lacking support
[13:39:37 CEST] <BBB> oh, I see, yes you need that too
[13:40:09 CEST] <BBB> does any of the driver claim to include support for it already?
[13:40:35 CEST] <nevcairiel> yeah it does, but it just fails with an invalid argument error when i try to use it
[13:40:38 CEST] <BBB> it looks like intel has it
[13:40:44 CEST] <BBB> oh
[13:40:45 CEST] <nevcairiel> but the spec is 5 days old, the driver is older, so who knows
[13:40:50 CEST] <BBB> :)
[13:40:52 CEST] <nevcairiel> well 7 days by now
[13:41:39 CEST] <BBB> ok, can you show the code you have so far? let me see if the proxies you made between header variables and libvpx variables is correct
[13:42:11 CEST] <nevcairiel> https://github.com/Nevcairiel/FFmpeg/commit/eba6d785f36e360ef20aa952782dcdf83ddb9c26
[13:42:42 CEST] <nevcairiel> well you wont understand the bitfields without the spec next to it i guess
[13:43:19 CEST] <nevcairiel> usually when params are wrong it just decodes garbage though
[13:43:24 CEST] <nevcairiel> not just error out
[13:43:32 CEST] <nevcairiel> so i'm somewhat convinced the driver is still broken
[13:47:50 CEST] <cone-538> ffmpeg 03Luca Barbato 07master:d00a8fd417ad: yuv4mpeg: Use the wrapped avframe pseudo-encoder
[13:47:51 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:1dd5f3340e00: Merge commit 'd00a8fd417ad20cecbc7ca17b25f352655148fb1'
[13:51:08 CEST] <cone-538> ffmpeg 03Luca Barbato 07master:b9ece15a0178: nullenc: Use the wrapped avframe pseudo-encoder
[13:51:09 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:64ceeac26a44: Merge commit 'b9ece15a01782b4f301c0c139d1d7b20f848914c'
[13:53:55 CEST] <BtbN> Is there any player yet to test the vp9 hwaccel?
[13:55:46 CEST] <nevcairiel> ffmpeg_dxva2.c works for me =p
[13:56:46 CEST] <BtbN> hm, not too usefull for the vaapi part
[13:56:59 CEST] <nevcairiel> maybe you should write the vaapi version for future testing!
[13:57:02 CEST] <nevcairiel> :D
[13:58:49 CEST] <nevcairiel> i have an updated patch for the hwaccel hooks if you are working on that though, including the get_format thing https://github.com/Nevcairiel/FFmpeg/commit/11ff5803c6a2bced1ad238ac493ce179e273381b
[13:59:01 CEST] <nevcairiel> it might misbehave if threading is enabled, i'm not quite sure
[13:59:15 CEST] <nevcairiel> (noone should use threading with hwaccel)
[13:59:44 CEST] <cone-538> ffmpeg 03Sean McGovern 07master:c1aac39eaccd: build: add Solaris symbol versioning
[13:59:45 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:fcfb66ba9b6e: Merge commit 'c1aac39eaccd32dc3b74ccfcce701d3d888fbc6b'
[14:03:07 CEST] <cone-538> ffmpeg 03Vittorio Giovara 07master:11c5f438ff83: dict: Change return type of av_dict_copy()
[14:03:08 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:b994788353ec: Merge commit '11c5f438ff83da5040e85bfa6299f56b321d32ef'
[14:04:33 CEST] <BBB> nevcairiel: vp9.c doesnt disable that with hw though, so youd need to add such a check
[14:04:41 CEST] <BBB> nevcairiel: unless that code lives in generic code already
[14:04:47 CEST] <nevcairiel> its all a big hack
[14:04:51 CEST] <BBB> thats ok
[14:04:53 CEST] <nevcairiel> i would need to check at some point
[14:04:59 CEST] <BBB> isnt half of ffmpeg a hack?
[14:05:01 CEST] Action: BBB runs
[14:05:03 CEST] <nevcairiel> the API should disallow that
[14:05:12 CEST] <nevcairiel> but some devs think its actually useful and block any such attempts
[14:05:17 CEST] <nevcairiel> naive as they are
[14:05:48 CEST] <BBB> ok, gonna drop off kids at school
[14:05:51 CEST] <BBB> will check patch after that
[14:08:08 CEST] <BtbN> nevcairiel, you mean https://github.com/Nevcairiel/FFmpeg/commit/11ff5803c6a2bced1ad238ac493ce179e273381b ?
[14:08:35 CEST] <nevcairiel> thats what i linked, isnt it :d
[14:09:34 CEST] <BtbN> huh, yes. Why did I end up somewhere else
[14:10:18 CEST] <BtbN> Is it just the vp89dxva branch, so I can base on that for now?
[14:10:32 CEST] <nevcairiel> sure
[14:10:44 CEST] <nevcairiel> note that i might do evil things to it, like rebasing
[14:11:14 CEST] <BtbN> Still easier to handle than managing the bunch of vp9 patches manualy
[14:16:58 CEST] <cone-538> ffmpeg 03Michael Niedermayer 07release/2.8:b46efcb2933c: avcodec/vp8: Do not use num_coeff_partitions in thread/buffer setup
[14:16:59 CEST] <cone-538> ffmpeg 03Carl Eugen Hoyos 07release/2.8:c2db8ebc083e: configure: Require libkvazaar < 0.7.
[14:28:24 CEST] <BBB> nevcairiel: pp->interp_filter = (h->h.filtermode > 1) ? h->h.filtermode : (h->h.filtermode == 1 ? 0 : 1); -> pp->interp_filter = h->h.filtermode ^ (h->h.filtermode <= 1);
[14:28:30 CEST] <BBB> nevcairiel: I have a todo item to do that in our decoder also
[14:28:40 CEST] <BBB> nevcairiel: libvpx does that more smartly than us
[14:28:51 CEST] <nevcairiel> they have a lookup table
[14:29:01 CEST] <BBB> the lut does the above function
[14:29:01 CEST] <nevcairiel> to translate the bitstream value
[14:29:09 CEST] <nevcairiel> you just made the enum match the bitstream instead
[14:29:10 CEST] <nevcairiel> :)
[14:29:21 CEST] <BBB> right, but that makes block decoding 1 cycle slower
[14:29:25 CEST] <BBB> 1 cycle!!!!11112233
[14:29:28 CEST] <cone-538> ffmpeg 03Alexandra Hájková 07master:16b0c929621f: avconv: Add loop option.
[14:29:29 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:9ccd90626f0e: Merge commit '16b0c929621f84983b83b9735ce973acb12723bc'
[14:29:44 CEST] <nevcairiel> (this loop option is rather broken)
[14:30:35 CEST] <durandal_170> how?
[14:30:38 CEST] <BBB> pp->StatusReportFeedbackNumber = 1 + DXVA_CONTEXT_REPORT_ID(avctx, ctx)++; -> pp->StatusReortFeedBackNumber = ++blabla(..);
[14:31:13 CEST] <BBB> I hope its the driver and not something else
[14:31:16 CEST] <BBB> which call returns the error?
[14:31:27 CEST] <nevcairiel> its always the execute call
[14:31:31 CEST] <nevcairiel> but it probably is
[14:36:15 CEST] <BBB> find returns no matches for execute"
[14:36:50 CEST] <nevcairiel> IDirectXVideoDecoder_Execute
[14:37:01 CEST] <nevcairiel> but that part is all sorts of dxva boilerplate
[14:44:52 CEST] <BBB> you should be able to test using chrome and youtube whether your driver supports it
[14:45:03 CEST] <BBB> after all, chrome supports dxva vp9 already, doesnt it?
[14:45:30 CEST] <BBB> https://groups.google.com/a/chromium.org/forum/#!msg/feature-media-reviews/BPOA-9pZj8s/KkARUm9yNQMJ
[14:45:37 CEST] <BBB> as of november 2014, it seems
[14:45:38 CEST] <nevcairiel> it uses some kind of intel home grown interface, not the official microsoft interface
[14:45:45 CEST] <BBB> oh, lol :D
[14:47:29 CEST] <nevcairiel> its possible Microsoft just adopted that same one
[14:47:34 CEST] <nevcairiel> i should boot up my haswell box
[14:50:04 CEST] <nevcairiel> my current CPU unfortunately doesnt have a integrated GPU
[14:50:10 CEST] <nevcairiel> thats the price for wanting more cores
[14:52:26 CEST] <BBB> I want more cores and a haswell
[14:52:27 CEST] <BBB> :/
[14:52:57 CEST] <cone-538> ffmpeg 03Luca Barbato 07master:34ed5c2e4d9b: avformat: Do not use AVFMT_RAWPICTURE
[14:52:58 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:1899b2579993: Merge commit '34ed5c2e4d9b7fe5c9b3aae2da5599fabb95c02e'
[14:52:59 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:435dfc15dfa9: ffmpeg: remove trailing whitespace that sneaked into the previous merge
[14:53:00 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:a34dfc93efe3: ffmpeg: add deprecation guards around remaining AVFMT_RAWPICTURE usage
[14:54:17 CEST] <cone-538> ffmpeg 03Derek Buitenhuis 07master:17e41cf36149: avcodec: Do not lock during init if there is no init function
[14:54:18 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:628174990971: Merge commit '17e41cf3614973258c24aa2452215ef7e3bfa5ed'
[14:58:16 CEST] <cone-538> ffmpeg 03Vittorio Giovara 07master:901f9c0a3298: qtrle: Properly use AVFrame API
[14:58:17 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:9c3f75c29d29: Merge commit '901f9c0a32985f48672fd68594111dc55d88a57a'
[15:01:06 CEST] <cone-538> ffmpeg 03Vittorio Giovara 07master:6fdd4c678ac1: libschroedinger: Properly use AVFrame API
[15:01:07 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:3d93ff289e04: Merge commit '6fdd4c678ac1ce0776f9645cd534209e5f1ae1e3'
[15:05:16 CEST] <cone-538> ffmpeg 03wm4 07master:6a23a34274b7: mimic: drop AVPicture usage
[15:05:17 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:8ededd583622: Merge commit '6a23a34274b747280c1e4a00ad22f97f99bbb48a'
[15:06:31 CEST] <nevcairiel> BBB: there are stores for that
[15:06:45 CEST] <BBB> these stores require this thing called money
[15:06:52 CEST] <BBB> most of my money goes to rent already :-p
[15:09:53 CEST] Action: Compn puts binary codec loader on opw page
[15:09:54 CEST] <Compn> ehe
[15:12:57 CEST] Action: wm4 shoots Compn 
[15:14:06 CEST] <nevcairiel> Compn: noone would ever want that, take it off again =p
[15:15:54 CEST] <BBB> Compn: please take that off
[15:16:00 CEST] <BBB> Compn: thats really not a good idea
[15:16:38 CEST] <BBB> Compn: before you know it, some company starts using it and we can never get rid of it again
[15:16:40 CEST] <wm4> "This task would be to copy the MPlayer binary codec loader ( mplayer/loader/ ) and get it working in FFmpeg. "
[15:16:43 CEST] <wm4> haha it's worse than I thought
[15:17:00 CEST] <wm4> Compn should become a manager or so
[15:17:11 CEST] <BBB> Compn: and Ill spend the rest of my life bikeshedding that patch and make sure it never gets in if I have to
[15:17:29 CEST] <BBB> Compn: if you thought people were against having a directory browsing api, you havent seen opposition yet
[15:17:50 CEST] <BBB> Compn: really, mplayer is good enough for people needing a dll loader
[15:18:34 CEST] <wm4> fortunately there will never ever be a mentor for this project
[15:18:46 CEST] <wm4> because nobody wants to touch this with a 100-foot pole
[15:19:02 CEST] <BBB> Compn: please, I beg you, take it off, dont give people bad ideas
[15:19:27 CEST] <nevcairiel> its a wiki, lets just take it off and tie Compn to some pole
[15:19:44 CEST] <iive> imho, the proper way would be to use wine for the loader.
[15:20:39 CEST] <BBB> nevcairiel: I dont want to get into a commit revert/reapply war
[15:20:40 CEST] <iive> also, it might be good idea to be a separate program, because most codecs are 32 bit.
[15:20:47 CEST] <BBB> nevcairiel: Id rather we all agree it should go off - including compn
[15:20:55 CEST] <iive> binary codecs, I mean.
[15:20:58 CEST] <BBB> iive: security implications also
[15:21:08 CEST] <BBB> bbl, gotta run
[15:21:10 CEST] <iive> that too.
[15:41:46 CEST] <durandal_1707> I'm volunteering for the maintainer
[15:45:35 CEST] <rcombs> I hacked together a binary codec loader once
[15:45:45 CEST] <rcombs> it was like 20 lines
[15:49:24 CEST] <wm4> rcombs: you should take a look at the mplayer code
[15:49:55 CEST] <wm4> be sure neither Compn nor objects with sharp edges are around when you do this
[15:50:23 CEST] <wm4> it's all kinds of evil and was hacked until somehow a specific set of codecs worked
[15:51:17 CEST] <rcombs> I just gave allcodecs.c a mechanism to do something like `lib = dlopen(CODEC".so"); codec = dlsym(lib, "ff_"CODEC"_decoder");` (or the Win32 equivalent) if the codec wasn't actually compiled in
[15:52:41 CEST] <Compn> arg bbb left
[15:52:56 CEST] <Compn> it says right on there "this patch may not be able to get in git master"
[15:53:04 CEST] <Compn> aka will live in a fork/branch.
[15:53:27 CEST] <Compn> (also a big company already uses binary codec loader with mencoder)
[15:53:34 CEST] <wm4> then replace "may not" with "definitely will not"
[15:53:56 CEST] Action: Compn afk
[15:54:46 CEST] <atomnuker> binary codec loaders, for the project which already supports every codec, order now
[15:57:25 CEST] <durandal_1707> it doesn't, and nobody wants to pay to re it
[16:00:18 CEST] <rcombs> in theory the practical application of binary codec loading is supposed to be around patent licensing
[16:00:56 CEST] <rcombs> but it turns out at least some patent holders won't let you license a codec to distribute as a standalone "plugin", it has to be part of a proper product
[16:05:16 CEST] <wm4> rcombs: really? wouldn't that destroy the business model of the only company who produces closed gstreamer plugins for h264 decoders
[16:05:29 CEST] <rcombs> I didn't say all patent holders
[16:06:44 CEST] <atomnuker> kierank: you got pinged in the thread again
[16:18:59 CEST] <cone-538> ffmpeg 03Ganesh Ajjanagadde 07master:6aaac24d72a7: avfilter/all: propagate errors of functions from avfilter/formats
[16:20:48 CEST] <cone-538> ffmpeg 03Ganesh Ajjanagadde 07master:bf0d2d6030c2: avfilter/formats: add av_warn_unused_result to function prototypes
[16:36:17 CEST] <cone-538> ffmpeg 03Clément BSsch 07master:c793a271d567: doc/filters: fix selectivecolor example
[16:43:11 CEST] <cone-538> ffmpeg 03Carl Eugen Hoyos 07master:1f2c474cb214: lavf/vc1dec: Autodetect raw vc-1 streams.
[17:03:39 CEST] <aballier> what's this tst.avi in git master?
[17:05:13 CEST] <ubitux> nevcairiel ^
[17:05:42 CEST] <nevcairiel> how did that happen
[17:05:53 CEST] <ubitux> nevcairiel: 9ccd90626f0ecef205faef1d25f0e3649d18e1b3
[17:06:05 CEST] <ubitux> lol :)
[17:06:13 CEST] <aballier> now everyone got your p0rn :p
[17:06:29 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:2d0a10e369f1: Remove test file that accidentally ended up in one commit
[17:06:43 CEST] <nevcairiel> its some random sample file with a defined duration i found somewhere
[17:07:06 CEST] <ubitux> "random", "somewhere"
[17:07:08 CEST] <ubitux> ;)
[17:07:48 CEST] <durandal_1707> what is it?
[17:08:51 CEST] <mateo`> #asian #blockiness
[17:22:15 CEST] <nevcairiel> mpeg4 encoder at its default is mighty fine
[17:22:28 CEST] <martijnb> that might just end up being the funniest thing that happened here all year
[17:42:02 CEST] <Daemon404> cool, pthrad_once bikeshedding done
[17:42:05 CEST] Action: Daemon404 sense aac patch
[17:42:07 CEST] <Daemon404> sends*
[17:42:12 CEST] <Daemon404> typos... \o/
[17:46:47 CEST] <atomnuker> Daemon404: ?
[17:47:04 CEST] <Daemon404> atomnuker, it's unrelated to aac encoder
[17:47:11 CEST] <Daemon404> it's just a lock-free thing
[17:47:54 CEST] <atomnuker> anticlimactic
[18:02:41 CEST] <jermy> That wiki edit reminds me - ffm2 is also a perfectly good format for concat, and supports everything, but has a seeking bug when being used as a pipe. I should send a patch or something
[18:30:01 CEST] <kierank> atomnuker: I think Kamedo2 doesn't understand what fuzzing does
[18:30:25 CEST] <kierank> the point (ofc) is not that the wav file is invalid but that it is possible to crash the encoder
[18:38:16 CEST] <J_Darnley> That particular case confuses me.  How does the invalid data make it through ffmpeg and reach the encoder?
[20:06:48 CEST] <cone-538> ffmpeg 03Ganesh Ajjanagadde 07master:55d3e9797088: avutil/intmath: use de Bruijn based ff_ctz
[20:16:00 CEST] <Daemon405> another screen codec...
[20:16:09 CEST] <Daemon405> (i heard j-b loves those)
[20:17:31 CEST] <durandal_1707> anyone can write codec that uses zlib
[20:21:36 CEST] <BBB> you can still talk him out of it
[20:23:20 CEST] <durandal_1707> you can't talk with corporations
[20:36:38 CEST] <cone-538> ffmpeg 03Zhang Rui 07master:87ff61b9abde: avutil/fifo: add function av_fifo_generic_peek_at()
[21:05:52 CEST] <cone-538> ffmpeg 03Zhang Rui 07master:6c7f289fab34: avformat/async: cache some data for fast seek backward
[21:32:10 CEST] <cone-538> ffmpeg 03Michael Niedermayer 07master:dbb03b8e47f9: ffmpeg_opt:  rename loop option to stream_loop
[23:00:34 CEST] <cone-538> ffmpeg 03Michael Niedermayer 07master:e55376a1fd5a: rtmpproto: Write correct flv packet sizes at the end of packets
[23:00:35 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:7ac4140c078d: Merge commit 'e55376a1fd5abebbb0a082aa20739d58c2260a37'
[23:01:29 CEST] <cone-538> ffmpeg 03Andrey Utkin 07master:c13485066973: httpauth: Add space after commas in HTTP/RTSP auth header
[23:01:30 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:0e4528b88e10: Merge commit 'c1348506697377b46f844339c178332e3314149a'
[23:02:09 CEST] <cone-538> ffmpeg 03Luca Barbato 07master:08377f9c3bf6: dxva: Include last the internal header
[23:02:10 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:b66a94ab539c: Merge commit '08377f9c3bf6dbe216512a2e05c9fac837b13fc0'
[23:03:00 CEST] <cone-538> ffmpeg 03Luca Barbato 07master:c53e796f8b69: thread: Provide no-op variants for pthread_once
[23:03:01 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:f05021f3f49a: Merge commit 'c53e796f8b69799b7ad6d28fbab981d37edf1bc9'
[23:06:27 CEST] <cone-538> ffmpeg 03Derek Buitenhuis 07master:d15368ee3926: h264: Run VLC init under pthread_once
[23:06:28 CEST] <cone-538> ffmpeg 03Hendrik Leppkes 07master:15db457ea8f7: Merge commit 'd15368ee3926152a3a301c13cc638fbf7a062ddf'
[23:15:48 CEST] <J_Darnley> Are we allowed to send a sarcastic reply to people who have stupid disclaimers in their emails?
[23:16:10 CEST] <JEEB> in many cases those might not be disable'able easily
[23:16:34 CEST] <JEEB> at least where I previously worked I would have had to poke some pretty derpy settings and being legally sure I could do it before I could have it removed
[23:16:45 CEST] <JEEB> which is why I never did it in the end :P
[23:16:59 CEST] <J_Darnley> I know, that's why I want to send one. :)
[23:17:02 CEST] <JEEB> :)
[23:17:05 CEST] <iive> J_Darnley: only if you use xml tag for marking the sarcasm.
[23:17:38 CEST] <J_Darnley> Can you direct me to the spec I need to follow for that?
[23:17:47 CEST] <rcombs> it's <sarc>
[23:17:59 CEST] <TD-Linux> send a multipart MIME message with the disclaimer being text/x-legalese
[23:18:01 CEST] <J_Darnley> Thanks </sarcasm>
[23:18:30 CEST] <JEEB> lol
[23:49:20 CEST] <durandal_1707> hah, don't use vlc on laptop if in Canada
[23:56:03 CEST] <durandal_1707> so nobody care for xma :(
[23:57:21 CEST] <iive> what is xma?
[23:57:32 CEST] <jamrial> don't we already have a demuxer?
[23:57:49 CEST] <jamrial> oh, it's xwma
[23:58:41 CEST] <durandal_1707> Xbox 360 audio format
[23:59:25 CEST] <durandal_1707> Actually wav with unsupported codec
[00:00:00 CEST] --- Thu Oct 15 2015


More information about the Ffmpeg-devel-irc mailing list