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

[burek]

[01:00:48 CET] <cone-086> ffmpeg 03Michael Niedermayer 07master:674cc26f257c: avfilter/vf_nnedi: Fix memleak
[01:52:18 CET] <michaelni> who maintains the dca/dts decoder code ?
[01:52:33 CET] <michaelni> there are a few issues coverity found in it ...
[01:55:41 CET] <jamrial> foo86, supposedly
[01:56:07 CET] <jamrial> he said he'd maintain it but afaik didn't send a patch to add himself to MAINTAINERS
[03:05:10 CET] <Timothy_Gu> ugh why isn't there a pmulhud
[03:11:44 CET] <michaelni> jamrial, i mailed him about a week ago about coverity but got no reply
[07:26:58 CET] <jya> michaelni: you wrote in an earlier ticket, that the best way to test if we were running LibAv or FFmpeg was to test libavcodec microversion and if it was 100
[07:27:14 CET] <jya> but in commit ae5b2c525, "foo86" made the microversion 101
[07:27:17 CET] <jya> that rather sucks
[07:27:49 CET] <jya> any reason to upgrade microversion rather than minor ?
[07:50:51 CET] <Timothy_Gu> jya: you can test MINOR >= 100
[07:51:09 CET] <Timothy_Gu> *MICRO
[07:52:51 CET] <jya> Timothy_Gu: sure... I opened ticket 5226. Problem for us is that we're riding the train and if a 2.9 version comes out with that, it will break our FFmpeg support for 12 weeks.
[07:54:20 CET] <jya> so knowing that a new version will likely come for ubuntu 16.04, our release cycle may be causing issue. so much easier to have this changed in ffmpeg :) and also document that it won't happen again (can see someone resetting to 0 the way it currently is documented)
[07:54:40 CET] <Timothy_Gu> jya: you mean you can't push a trivial patch like this to your release branch?
[07:54:50 CET] <jya> that's right
[07:55:11 CET] <jya> please don't close it as invalid without looking at the background
[07:55:13 CET] <Timothy_Gu> :(
[07:55:26 CET] <Timothy_Gu> jya: i closed it before you replied. fflogger is slow :)
[07:57:32 CET] <Timothy_Gu> regardless, I don't think it is reasonable to make sure ffmpeg doesn't bump micro for 12 weeks
[07:58:02 CET] <jya> Timothy_Gu: we should make sure it never goes under 100 though
[07:58:26 CET] <jya> so that itself that worth a ticket so version.h is documented as such
[08:01:27 CET] <jya> Timothy_Gu: I did misread the comments though :(
[08:01:31 CET] <jya> my fault
[08:01:55 CET] <Timothy_Gu> jya: i guess we can bump minor in the future, but there is no guarantee that a user won't use a version of ffmpeg that has micro that is larger than 100
[08:02:08 CET] <jya> indeed.
[08:02:27 CET] <jya> so >= 100 I can deal with.. I just want to make sure it *never* reset to 0.
[08:02:40 CET] <jya> Like is this something set in stone and known by every ffmpeg committer 
[08:02:43 CET] <Timothy_Gu> jya: no it will never be done
[08:03:15 CET] <Timothy_Gu> it has been >=100 since 2011 and will be for the foreseeable future
[08:03:26 CET] <jya> well, it has been 100 since 2011 :)
[08:03:46 CET] <jya> so assuming it was always going to be 100 was a fairly reasonable assumption 
[08:04:07 CET] <Timothy_Gu> yes 
[08:04:10 CET] <Timothy_Gu> also check https://www.ffmpeg.org/download.html#releases
[08:04:21 CET] <jya> IMHO, the changes were fairly significant, a minor bump would have been more usual
[08:05:12 CET] <Timothy_Gu> technically, yes, for this change we should have probably bumped minor
[08:06:18 CET] <Timothy_Gu> also note that libavresample's micro will never be above 100, since it is kept only for compatibility with Libav, and we don't maintain it per se
[08:07:15 CET] <wbs> jya: it hasn't "always been 100 since 2011", this wasn't the first time it has been >100 - that happens all the time. see e.g. e9e623369 and 73e4565df
[08:07:40 CET] <Timothy_Gu> and also the release page i linked
[08:07:43 CET] <jya> Timothy_Gu: we only use libavcodec and libavformat
[08:08:15 CET] <Timothy_Gu> ffmpeg-2.8.6:
[08:08:15 CET] <Timothy_Gu> libavutil      54. 31.100
[08:08:15 CET] <Timothy_Gu> libavcodec     56. 60.100
[08:08:16 CET] <Timothy_Gu> libavformat    56. 40.101
[08:08:25 CET] <jya> we had some crashes happening because someone had installed two different version of libavformat, and libavcodec.56.so was loading the wrong libavformat
[08:08:37 CET] <jya> made for some really weird traces !
[08:08:54 CET] <jya> sorry libavcodec and libavutil
[08:09:11 CET] <jya> we use our own demuxer
[08:14:38 CET] <Timothy_Gu> is it possible to emulate roundps with truncation in sse2?
[09:59:22 CET] <cone-252> ffmpeg 03Paul B Mahol 07master:4ca8879d1989: avfilter: add metadata filters
[10:06:16 CET] <ubitux>     Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709/unknown/unknown), 3840x2160, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc (default)
[10:06:17 CET] <ubitux>     Stream #0:1(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
[10:06:25 CET] <ubitux> heh, youtube is getting better at delivering decent videos
[10:07:08 CET] <ubitux> Timothy_Gu: no other comment from me, i like the idea
[10:15:30 CET] <Timothy_Gu> ubitux: cool. will push later today
[10:22:47 CET] <cone-252> ffmpeg 03Timothy Gu 07master:5f1aad68c4f5: tests: Add test for proper header guard
[11:40:55 CET] <rcombs> these Firefox guys&
[11:47:03 CET] <BtbN> Why don't they just support a defined version, and include it in their binary releases? oO
[11:47:30 CET] <nevcairiel> who knows
[11:47:37 CET] <nevcairiel> for some reason they dont want to ship any binary
[11:47:45 CET] <nevcairiel> so they have one evil hack to support everything
[11:47:49 CET] <BtbN> So no ffmpeg on windows, ever?
[11:48:00 CET] <BtbN> Not even an lgpl one?
[11:50:19 CET] <cone-252> ffmpeg 03Paul B Mahol 07master:408ea50ca6bc: avfilter/f_metadata: fix few logic errors
[11:56:25 CET] <Daemon404> what does Outreachy provide if not money?
[11:56:33 CET] <Daemon404> admin?
[11:57:00 CET] <rcombs> nevcairiel: BtbN: patents
[11:59:22 CET] <Daemon404> nevcairiel / BtbN - he's in here if you wanna argue ;)
[11:59:32 CET] <nevcairiel> i just want to make fun of them
[11:59:40 CET] <nevcairiel> i havent used firefox in years
[11:59:47 CET] <nevcairiel> not starting any time soon either
[12:00:18 CET] <Daemon404> i switched back from chrome ~2 years ago
[12:00:25 CET] <Daemon404> when chrome iddnt support highdpi correctly
[12:00:29 CET] <Daemon404> too lazy to switch back
[12:00:44 CET] <Daemon404> plus chrome is ie6
[12:01:04 CET] <durandal_1707> Daemon404: it provides devs doing merges
[12:01:15 CET] <Daemon404> ?
[12:01:26 CET] <durandal_1707> Outreachy
[12:01:37 CET] <Daemon404> how does it provide devs? they devs apply.
[12:03:52 CET] <nevcairiel> Daemon404: the only thing they do is admin yes, which really kind of limits its usefulness
[12:04:26 CET] <Daemon404> thats what i thought
[12:04:32 CET] <Daemon404> nevcairiel, where is our i/o callback api?
[12:04:47 CET] <nevcairiel> its called open_cb i think
[12:04:51 CET] <nevcairiel> same place the new one goes
[12:04:53 CET] <nevcairiel> avformatcontext
[12:05:19 CET] <Daemon404> wait....
[12:05:29 CET] <Daemon404> so out formatcontext->opaque is used for multiple things then
[12:05:40 CET] <Daemon404> while it is only documented for the avdevice garbage
[12:12:38 CET] <Daemon404> looks like ours is much less in scope
[12:12:47 CET] <Daemon404> is anyone going to rip my face off for deprecating it
[12:12:55 CET] <Daemon404> michaelni, ^ opinions
[12:12:58 CET] <Daemon404> since youre teh author
[12:13:14 CET] <nevcairiel> how old is that thing anyway
[12:13:51 CET] <Daemon404> Date:   Mon May 11 17:45:13 2015 +0200
[12:14:23 CET] <Daemon404> it's only used for mov crefs, mlvdec, and img2dec
[12:14:54 CET] <Daemon404> drefs*
[12:17:59 CET] <durandal_1707> replace with what?
[12:18:30 CET] <nevcairiel> two new callbacks for open and close
[12:19:19 CET] <Daemon404> nevcairiel, we never had two callbacks
[12:19:25 CET] <nevcairiel> i never said we did
[12:19:34 CET] <michaelni> Daemon404, ask wm4, i think he was the primary user of the callback
[12:19:40 CET] <Daemon404> wm4, ^
[12:19:48 CET] <wm4> didn't use it
[12:19:53 CET] <Daemon404> lol.
[12:19:59 CET] <wm4> (although planned to)
[12:20:04 CET] <wm4> (still plan to)
[12:20:10 CET] <nevcairiel> may'15 means it was never in a release? or did it make 2.8?
[12:20:54 CET] <Daemon404> github search for av_format_set_open_cb mostly finds avformat.def files...
[12:21:07 CET] <michaelni> its in 2.7 and 2.8
[12:21:13 CET] <nevcairiel> aw
[12:21:26 CET] <michaelni> see git branch --contains  541d75f9a0b6e1b360345e289cb44e43a39643cd
[12:21:34 CET] <Daemon404> TIL: --contains
[12:21:53 CET] <nevcairiel> i knew it exists, but i'm usually too lazy to use it =p
[12:21:58 CET] <Daemon404> i can't actually find any real project that uses it
[12:22:04 CET] <Daemon404> maybe kodi does?
[12:22:08 CET] <Daemon404> (probably not)
[12:22:28 CET] <wm4> maybe none does
[12:22:57 CET] <Daemon404> i think it's relatively safe to deprecate...
[12:23:06 CET] <Daemon404> im not quite ready to break api with libav...
[12:23:17 CET] <Daemon404> i'd rather need it compat atm
[12:28:51 CET] <durandal_1707> Daemon404: haven't you stopped doing merges?
[12:28:59 CET] <Daemon404> no?
[12:30:27 CET] <durandal_1707> Daemon404: bunch of commits are not merged
[12:30:33 CET] <Daemon404> thats nice
[12:30:43 CET] <Daemon404> i took a short break. libav only pushed like 2 commits in the meantime.
[12:30:52 CET] <Daemon404> can anyone explain what this AVIOInterruptCB stuff peppered everywhere?
[12:30:57 CET] <Daemon404> is*
[12:32:50 CET] <wm4> Daemon404: not freeze the process eternally if you really want to close the avio/avformat context
[12:33:02 CET] <nevcairiel> its for controlling timeout, yea
[12:33:10 CET] <nevcairiel> but libav has that too
[12:33:18 CET] <Daemon404> does it? ok
[12:33:34 CET] <nevcairiel> maybe not  all the same calls in all protocol code, but the same mechanism anyway
[12:33:46 CET] <Daemon404> just noticed because basically every single place that libav is usign open_cb has some whtielist opening func
[12:33:51 CET] <Daemon404> which takes that callback
[12:34:05 CET] <Daemon404> wrappers for wrappers for wrappers for wrappers <.. continue for 10 layers...>
[12:35:32 CET] <durandal_1707> should I write lua filter that exposes all lavfi internals, so you can write your own filters in lua?
[12:35:35 CET] <wm4> the callbacks needs to be passed down to every sub-context that is opened
[12:35:40 CET] <wm4> and the whitelists too
[12:35:55 CET] <wm4> durandal_1707: not before C does?
[12:37:29 CET] <durandal_1707> do not need C
[13:00:14 CET] <durandal_1707> i want to reply to mats thread, with something funny
[13:00:59 CET] <ubitux> "yes"
[13:05:33 CET] <wm4> man this hwaccel effort duplication between ffmpeg and libav is terrible
[13:05:48 CET] <wm4> now elenril wrote he has his own partial vaapi implementation
[13:07:32 CET] <Daemon404> ffmpeg doesnt exist man
[13:08:27 CET] <wm4> he actually looked at the ffmpeg ones and voiced some unclear complaints
[13:08:41 CET] <Daemon404> since i dont work on playback, i can only watch others suffering
[13:08:51 CET] <wm4> this is for transcoding too
[13:08:58 CET] <wm4> (the fabled full-hw transcode pipeline)
[13:11:49 CET] <Daemon404> i dont know why id want to do that at scale
[13:12:04 CET] <Daemon404> because i love pissin money away?
[13:12:31 CET] <wm4> everyone knows that GPUs should do all real work, how can you doubt that
[13:13:24 CET] <Daemon404> gpgpgpgpgpgpu etc
[13:21:04 CET] <nevcairiel> full hw transcode is useless because hw encoders are terrible =p
[13:22:13 CET] <Daemon404> that too
[13:29:33 CET] <cone-252> ffmpeg 03Michael Niedermayer 07master:a82ff49bb829: ffmpeg_filter: Add YUV 444 to strict_std_compliance case for mjpeg
[13:29:34 CET] <cone-252> ffmpeg 03Michael Niedermayer 07master:82d2aa2b32e8: ffmpeg_filter: Add missing pixel formats to strict_std_compliance case for ljpeg
[13:29:35 CET] <cone-252> ffmpeg 03Michael Niedermayer 07master:d94b11a72138: ffmpeg_filter: Factor get_compliance_unofficial_pix_fmts() out
[13:39:12 CET] <rcombs> nevcairiel: it's only useful on shitty consumer hardware
[13:46:16 CET] <rcombs> wm4: link to this libav vaapi work?
[13:46:21 CET] <rcombs> (I'm trying to keep track of all this)
[13:48:26 CET] <wm4> rcombs: https://lists.libav.org/pipermail/libav-devel/2016-February/074667.html
[13:48:33 CET] <wm4> the vaapi part isn't public
[13:49:09 CET] <rcombs> ah
[13:50:30 CET] <rcombs> wm4: is there a solution to the format conversion/auto-inserted scale filter thing in there
[13:51:47 CET] <wm4> don't think so
[13:51:55 CET] <wm4> ask elenril
[13:52:12 CET] <rcombs> appears afk
[14:10:55 CET] <Daemon404> michaelni, ping
[14:11:05 CET] <Daemon404> i have a question: re avio+whitelisting
[14:15:45 CET] <jkqxz> wm4:  I saw that new libav patchset and was intending to go through it more carefully soon.
[14:16:11 CET] <wm4> ok
[14:18:32 CET] <jkqxz> I'm still missing how you do the enumerate-all-possible-render-targets for initialisation, and the copy in/out setup probably needs to be a bit more refined.
[14:19:02 CET] <Daemon404> michaelni, hmm nevermind
[15:01:57 CET] <kierank> phew that ticket is ancient
[15:02:30 CET] <kierank> there really should be any more crashes with h264 and bad streams now. afaik I found them all and michaelni fixed them
[15:02:50 CET] <BBB> h264 is fairly stable yes
[15:02:56 CET] <BBB> werent most of the crashes in the mt handling?
[15:06:47 CET] <kierank> yes iirc
[15:11:16 CET] <kierank> But $bigsportingevent over the last few days was decoded with ffh264 and there were no crashes at all
[15:11:32 CET] <kierank> so at least my revision from July is solid
[15:15:07 CET] <rcombs> oh? ffh264 was used in the broadcast?
[15:15:13 CET] <rcombs> in what capacity?
[15:16:25 CET] <ubitux> well no crash with the same kind of input doesn't mean much
[15:16:31 CET] <kierank> ubitux: the input was switched a lot
[15:16:45 CET] <ubitux> yes but switch to what kind of input
[15:16:56 CET] <ubitux> i mean, it's more interesting in a situation like youtube
[15:17:00 CET] <kierank> between h264 and mpeg2 and between different h264 encoders
[15:17:01 CET] <kierank> yes ofc
[15:17:19 CET] <ubitux> where you have so many users whose purpose is to inject a maximum of insane shit
[15:17:31 CET] <kierank> Sure but going black to 20 million people is also of concern
[15:18:01 CET] <ubitux> i'd say you're pretty sure to long forever if you can handle one minute
[15:18:14 CET] <kierank> rcombs: receivers in certain territories
[15:18:26 CET] <rcombs> neat
[15:19:11 CET] <BtbN> are you talking about the superbowl stream?
[15:19:18 CET] <Daemon404> static int read_header(AVFormatContext *avctx)
[15:19:20 CET] <Daemon404> this is a gem
[15:19:39 CET] <BtbN> Tried to watch it in Kodi, and it did some weird stuff every few minutes.
[15:20:18 CET] <nevcairiel> Daemon404: how so, that could be any function in any files, those static things are generally not named very well
[15:21:18 CET] <ubitux> happens in 26
[15:21:20 CET] <Daemon404> nevcairiel, avctx is almost universally used for avcodecocntext
[15:21:38 CET] <ubitux> ah, that
[15:21:45 CET] <ubitux> issue present in mlv and tty
[15:21:45 CET] <nevcairiel> eh, type safety will protect you =p
[15:22:09 CET] <nevcairiel> using "s" for any kind of context isnt that much better
[15:22:23 CET] <nevcairiel> or just plain "ctx"
[15:22:42 CET] Action: Daemon404 thinks he finally finished the io stuff
[15:22:43 CET] <Daemon404> fate time...
[15:27:11 CET] <Daemon404> can we like, rate limit Mats?
[15:29:02 CET] <nevcairiel> that would be nice, wouldnt it
[15:36:26 CET] <Daemon404> man we have 4 sets of vsynth now?
[15:36:32 CET] <Daemon404> no wonder FATE's been so slow for me
[15:36:52 CET] <nevcairiel> 4 now? i thought 3
[15:37:07 CET] <nevcairiel> oh right we duplicated some because of lena
[15:37:12 CET] <nevcairiel> but those barely take any time for me
[15:38:20 CET] <Daemon404> theyre by far the longest part of fate for me
[15:43:09 CET] <cone-252> ffmpeg 03Anton Khirnov 07master:9f61abc8111c: lavf: allow custom IO for all files
[15:43:10 CET] <cone-252> ffmpeg 03Derek Buitenhuis 07master:bc9a5965c815: Merge commit '9f61abc8111c7c43f49ca012e957a108b9cc7610'
[16:08:02 CET] <BBB> Daemon404: --disable-encoders
[16:09:21 CET] <Daemon404> sometimes vsynth catches lavf issues
[16:09:23 CET] <Daemon404> so i dont
[16:12:02 CET] <BBB> that suggests we need more lavf tests
[16:13:20 CET] <Daemon404> is anyone super familiar with hls.c?
[16:13:35 CET] <Daemon404> help would be appreciated on merging 81306fd4bdeb5c17d4db771e4fec684773b5790f
[16:13:42 CET] <Daemon404> our hls.c seems to be 10x more complex
[16:22:36 CET] <JEEB> hmm
[16:22:58 CET] <JEEB> I wonder what of all thngs can be controlled through stdin/signals with ffmpeg cli
[16:23:07 CET] <Daemon404> ?
[16:23:40 CET] <JEEB> f.ex. if the encode was started with -re but later I can remove that flag
[16:23:44 CET] <JEEB> :D
[16:23:53 CET] <JEEB> I'll probably need to use the API for this kind of stuff
[16:24:22 CET] <Daemon404> you really can only go so far with script ffmpeg cli
[16:24:30 CET] <JEEB> yeah
[17:07:57 CET] <nevcairiel> someone should remove all of those projects that we've been carrying around for 10 GSoCs
[17:10:09 CET] <wm4> that would probably start an edit war
[17:10:39 CET] <nevcairiel> some are so old that the proposed mentors probably dont even remember anymore
[17:11:46 CET] <Daemon404> nevcairiel, people would object because then the list iwll be tiny
[17:11:50 CET] <Daemon404> and nobody has any ideas
[17:12:03 CET] <nevcairiel> and no students work on those stupid old ideas anyway
[17:12:20 CET] <nevcairiel> because they are either way too complex or not very interesting
[17:12:52 CET] <Daemon404> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016#MissingAACdecoderfeatures
[17:12:56 CET] <Daemon404> this one doesnt even exist anymore
[17:13:01 CET] <Daemon404> i think all of those got done
[17:13:03 CET] <nevcairiel> decoder
[17:13:06 CET] <nevcairiel> and no
[17:13:11 CET] <Daemon404> no?
[17:13:12 CET] <nevcairiel> 960/120 is still not supported, neither is SSR
[17:13:27 CET] <nevcairiel> no idea what BSAC is
[17:13:29 CET] <Daemon404> im pretty sure i saw someone add the window
[17:14:30 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/aacdec_template.c;h=6bc94c879a9a55bff9060814218aa921bdb39e0e;hb=HEAD#l803
[17:14:40 CET] <nevcairiel> 960 is only supported in eld streams, not in LC
[17:15:16 CET] <Daemon404> ah ok
[17:15:20 CET] <Daemon404> still doesnt seem like it could fill a gsoc
[17:18:05 CET] <kierank> Shall I start a thread about it
[17:18:35 CET] <kierank> yes I will
[17:21:48 CET] <kierank> hmm why did sending to ffmpeg-users at ffmpeg.org not work
[17:22:00 CET] <nevcairiel> isnt it ffmpeg-user
[17:22:03 CET] <kierank> oh bleh
[17:22:25 CET] <nevcairiel> outreachy actually started with a nearly empty list of tasks
[17:22:29 CET] <kierank> yes
[17:22:32 CET] <nevcairiel> or did someone copy-paste the old one over by now
[17:22:32 CET] <kierank> because I did it like that
[17:27:03 CET] <BBB> kierank: why dont you just delete the old tasks
[17:27:08 CET] <kierank> because carl
[17:27:12 CET] <BBB> screw him
[17:27:20 CET] <kierank> I emailed him about it
[17:27:22 CET] <BBB> for each newly added task, the only persont hat can add it is the mentor
[17:27:27 CET] <BBB> no mentor, no task
[17:27:34 CET] <BBB> I have a better idea then
[17:27:38 CET] <BBB> lets keep the task list as is
[17:27:41 CET] <BBB> abandon it for any future use
[17:27:45 CET] <kierank> to be fair aac encoding was an old one that actually got sorted
[17:27:48 CET] <BBB> and make a new one that is actually, you know, useful
[17:27:54 CET] <Daemon404> ok so
[17:27:58 CET] <BBB> I dont think aac encoding got sorted b/c it was on a task list
[17:28:08 CET] <Daemon404> the obvious one hasnt been added, because it has no mentor and is too hard :P
[17:28:12 CET] <Daemon404> (hevc asm(
[17:28:14 CET] <nevcairiel> BBB: atomnuker came to us through GSoC
[17:28:21 CET] <BBB> Im willing to write hevc asm
[17:28:24 CET] <BBB> but someone needs to pay me
[17:28:32 CET] <nevcairiel> 1c per instruction?
[17:28:37 CET] <durandal_1707> how much?
[17:28:40 CET] <nevcairiel> hm thats counter productive
[17:28:45 CET] <nevcairiel> you would write slow verbose code
[17:28:54 CET] <bencoh> :D
[17:29:27 CET] <BBB> any company wiht a big pocket of cash and sincere interest in hevc asm is free to contact me
[17:30:04 CET] <BBB> (Ive repeated this every few months over the past 1-2 years, and only one company ever contacted me, and they were hoping Id do it for free)
[17:30:11 CET] <Daemon404> seems unlikely
[17:30:11 CET] <nevcairiel> should ask netflix, i hear they stream in hevc these days
[17:30:12 CET] <BBB> (from which I gather there is just no interest)
[17:30:15 CET] <Daemon404> chicken/egg/patent pools
[17:30:22 CET] <j-b> BBB: how much?
[17:30:28 CET] <Daemon404> orite vlc
[17:30:35 CET] <BBB> j-b: companies can contact me, but not cheap
[17:30:46 CET] <kierank> nevcairiel: they use hw decoders
[17:30:52 CET] <j-b> that's very very vague
[17:30:52 CET] <BBB> it makes no sense to use ngo money for that
[17:31:01 CET] <BBB> it is, I dont want you to pay for my manhattanitis
[17:31:04 CET] <j-b> cheap could be 1000¬ or 100000¬
[17:31:05 CET] <BBB> its my fault, not yours
[17:31:08 CET] <nevcairiel> kierank: proper hevc hw decoders are still somewhat rare in hardware though
[17:31:19 CET] <fritsch> j-b: calculate in "time"
[17:31:20 CET] <nevcairiel> at least consumer  side
[17:31:44 CET] <ubitux> kierank: cfhd, i think you should s/av_clip_uintp2_c/av_clip_uintp2/
[17:31:45 CET] <nevcairiel> although that will probably improve this year
[17:31:57 CET] <kierank> ubitux: breaks arm because not a power of 2
[17:32:18 CET] <nevcairiel> isnt that function specifically designed for powers of 2
[17:32:19 CET] <nevcairiel> :D
[17:32:30 CET] <ubitux> ... we still haven't a proper fallback?
[17:32:48 CET] <ubitux> nevcairiel: the actual problem is the value being const or not
[17:32:54 CET] <kierank> oh wasn't a power of 2
[17:32:57 CET] <kierank> yeah was const
[17:32:58 CET] <kierank> sorry
[17:33:23 CET] <nevcairiel> ubitux: sounds like a useless limitation, just throw out some half-baked optimization that only works in some cases
[17:33:29 CET] <BBB> j-b: rough guess - review of all existing simd (sao, lf, mc) and writing missing (idct) for 8bit/10bit (thatll give you 12bit essentially for free, but nobody cares), sse2, ssse3, avx and avx2, 32bit and 64bit compat, $150k
[17:33:33 CET] <jamrial> seriously, just check av_builtin_constant_p() in the arm version
[17:33:49 CET] <jamrial> i doubt there's a compiler we support that has inline asm but not that
[17:34:06 CET] <BBB> oh I forgot intra pred
[17:34:08 CET] <fritsch> BBB: so ne year in sum
[17:34:10 CET] <BBB> anyway
[17:34:15 CET] <fritsch> s/ne/one/
[17:34:17 CET] <BBB> fritsch: I dont work hourly
[17:34:27 CET] <fritsch> companies always want a timeline
[17:34:30 CET] <BBB> fritsch: its like writing per instruction, counter incentivizing
[17:34:55 CET] <fritsch> so you could tell them: pay me for a year (150K) and after the year you have results
[17:34:57 CET] <kierank> well either we'd want hourly or we'd want per X
[17:35:09 CET] <kierank> gotta put something tangible on invoice
[17:35:18 CET] <BBB> I work per project, not per hour
[17:35:20 CET] <jamrial> it would most likely need to review and probably rewrite parts of the actual decoder. mc is kinda messy as is
[17:35:26 CET] <BBB> so the project would be what I just said
[17:35:56 CET] <fritsch> yeah - if you decide to pause your work after 3 months for 10 years :-)
[17:36:45 CET] <nevcairiel> well clearly there would be some idea of timeline on such a rpoject
[17:36:45 CET] <atomnuker> do I need to bump libavcodec MINOR/MICRO when pushing my VC-2 encoder?
[17:36:50 CET] <BBB> atomnuker: yes
[17:36:57 CET] <jamrial> minor, yes
[17:37:02 CET] <atomnuker> kthnx
[17:37:08 CET] <ubitux> nevcairiel: i think rcombs had a patch
[17:37:45 CET] <ubitux> 2015-11-05 12:13:32     rcombs  https://gist.github.com/e5c55681a10f59ec192f duplicated implementation since it would produce circular header dependencies otherwise
[17:40:31 CET] <BBB> nevcairiel: I typically add deadlines for the project as a whole. doing a deadline for particular subtasks would be fine also, but I dont provide specifications of how many hours Ill work on X, Y or Z
[17:40:41 CET] <BBB> if its not done 6 months from now, the contract will be void
[17:40:43 CET] <BBB> or so
[17:41:44 CET] <BBB> anyway, Ill keep my eyes open for companies using ffhevc for whatever
[17:42:04 CET] <Daemon404> there are plenty, but they all violate the gpl anway
[17:42:06 CET] <Daemon404> anyway*
[17:42:08 CET] <Daemon404> so no $
[17:42:58 CET] <BBB> no $ is a problem for contract work
[17:43:26 CET] <kierank> cehoyos: hello, so we were proposing to start from a clean project list for gsoc/outreachy
[17:43:33 CET] <BBB> hello carl
[17:43:36 CET] <kierank> and asking the on the ML for new ideas
[17:44:35 CET] <cehoyos> Hi!
[17:44:50 CET] <cehoyos> I am all for new ideas, I don't think starting with a new page makes much sense.
[17:45:09 CET] <cehoyos> If you believe that the current page contains bad ideas, please suggest to remove them.
[17:45:54 CET] <cehoyos> Starting with a clean page has the additional disadvantage that we would have to think of all the little things that should be part of the page, like contact information, student help etc.
[17:46:05 CET] <kierank> The problem is it's the same dated ideas
[17:46:18 CET] <cehoyos> I really don't understand why old ideas are bad?
[17:46:31 CET] <cehoyos> On the contrary, I think they get more important every year...
[17:46:33 CET] <kierank> imagine a student visiting ffmpeg gsoc every year and seeing the same thing
[17:46:39 CET] <kierank> just makes us look like a boring project
[17:46:41 CET] <kierank> that doesn't do anything new
[17:46:46 CET] <Daemon404> if nobody picked them for 5 years
[17:46:51 CET] <Daemon404> chances are nobody will
[17:47:11 CET] <cehoyos> As said; Please add new ideas, the more we have the better!
[17:47:30 CET] <cehoyos> (And more new ideas will make us look less boring iiuc.)
[17:47:51 CET] <kierank> it's better to have a few good ideas than a ton of mediocre ones
[17:48:10 CET] <cehoyos> I wonder if Stephanie agrees...
[17:48:22 CET] <kierank> "C coding skills, good x86 assembly coding skills, basic familiarity with git." too much to ask these days for example
[17:48:52 CET] <Daemon404> not these days
[17:48:54 CET] <durandal11707> C# and java
[17:48:55 CET] <cehoyos> Please add simpler tasks! But in your email - iiuc - you asked for more difficult tasks, or did I misread?
[17:48:55 CET] <Daemon404> it was always niche
[17:49:01 CET] <BBB> python
[17:49:07 CET] <kierank> no I asked for more interesting tasks
[17:49:13 CET] <kierank> the tasks we have are the same boring old crap
[17:49:21 CET] <kierank> mpeg-4 als
[17:49:22 CET] <cehoyos> More interesting than vc-1, j2k and mvc? Good luck!
[17:49:23 CET] <BBB> I do agree things like postproc optimizations are not very hot
[17:49:28 CET] <BBB> mpeg4 als isnt hot either
[17:49:30 CET] <kierank> How does this interest me as a student?
[17:49:35 CET] <kierank> that's what you need to think about
[17:49:39 CET] <jamrial> and do most of these even have mentors anymore?
[17:49:39 CET] <BBB> we need tasks that teach students about stuff theyll use in their phd
[17:49:44 CET] <BBB> for video coding, that is vp9/hevc
[17:49:47 CET] <durandal11707> port vapoursynth mvtools?
[17:49:51 CET] <BBB> for audio coding, that is likely opus or stuff
[17:49:59 CET] <BBB> I dont know what filtering research is hot these days
[17:50:05 CET] <cehoyos> Let's please stop this, it is not very constructive: Just add "hot" ideas and by itself, the boring ones will just disappear.
[17:50:08 CET] <BBB> but vc1-interlaced is not hot
[17:50:12 CET] <kierank> cehoyos: no the boring ones won't
[17:50:15 CET] <kierank> that's the problem
[17:50:16 CET] <BBB> not unless we remove them
[17:50:20 CET] <kierank> exactly
[17:50:28 CET] <BBB> stuff only disappears if it gets removed
[17:50:37 CET] <BBB> bugs dont vanish in thin air
[17:50:44 CET] <BBB> neither do uncomplated gsoc tasks in a todo list
[17:50:50 CET] <BBB> uncompleted*
[17:51:03 CET] <cehoyos> Please let's start with adding tasks, do not remove them because you don't want to work on them (if you were a student)
[17:51:15 CET] <kierank> you've just contradicted yourself
[17:51:32 CET] <cehoyos> Note that als has a mentor, some of you are not listed on the GSoC wiki (yet)
[17:51:38 CET] <Daemon404> "has:
[17:51:45 CET] <Daemon404> the mentors are copypasted year after year
[17:51:48 CET] <durandal11707> they dont want to be mentors or students
[17:51:51 CET] <kierank> copy and paste doesn't could carl
[17:51:58 CET] <kierank> count*
[17:52:07 CET] <Daemon404> e.g. ive been copypasted 3 years in a row as a mentor withotu even being consulted once
[17:52:19 CET] <Daemon404> of course nobody ever picks that project
[17:52:26 CET] <durandal11707> ok, who wants to be mentor?
[17:52:29 CET] <cehoyos> Sorry, I just started a few minutes ago: I will send mails to every single one on the list.
[17:52:40 CET] <kierank> cehoyos: don't put them on the list unless they agree
[17:52:41 CET] <cehoyos> But I wanted to tell you that for one of the projects you mentioned, we have a mentor.
[17:52:42 CET] <BBB> durandal_1707: depends on project
[17:52:43 CET] <kierank> the copy and paste is bad
[17:53:13 CET] <kierank> 4:49 PM <"BBB> we need tasks that teach students about stuff theyll use in their phd
[17:53:15 CET] <kierank> or get them jobs
[17:54:56 CET] <kierank> he-aac encoder is another task
[17:55:09 CET] <Daemon404> lol phd
[17:55:11 CET] <cehoyos> Will you mentor he-aac?
[17:55:21 CET] <kierank> no but we can find people
[17:55:30 CET] <kierank> cehoyos: it's not a  tickbox contest you know
[17:55:35 CET] <kierank> the mentor needs to be the right person
[17:55:38 CET] <kierank> not the first one you find
[17:56:26 CET] <ubitux> simple tasks are either done on a regular basis, or boring as hell
[17:56:44 CET] <ubitux> and interesting ones require skill
[17:56:49 CET] <ubitux> or involve large api redesign
[17:57:42 CET] <BBB> kierank: yeah, very true, phd or jobs
[17:58:07 CET] <BBB> hobby stuff is fine also, but I have issues with the concept that people would find vc1-interlaced interesting as a hobby
[17:58:09 CET] <kierank> cehoyos: you can copy my task from outreachy 
[18:00:21 CET] <cehoyos> Thank you, done!
[18:00:35 CET] <jamrial> BBB: i found a shitty audio only container that was used in one game a hobby once :p
[18:00:41 CET] <cehoyos> ubitux: Will you mentor a subtitle task?
[18:00:46 CET] <ubitux> no, sorry
[18:00:49 CET] <BBB> jamrial: thats not suitable as a gsoc task :-p
[18:02:58 CET] <kierank> j-b, wm4: what are your complaints that gsoc could solve?
[18:03:07 CET] <durandal11707> why is truehd encoder still task?
[18:03:14 CET] <kierank> durandal11707: because we gotta have tasks
[18:03:15 CET] <cehoyos> Do we have one?
[18:03:16 CET] <kierank> taskssssss
[18:03:33 CET] <kierank> need tasks, it's like gold dubloons
[18:03:40 CET] <BBB> lol
[18:03:46 CET] <wm4> something that a student could do...
[18:06:14 CET] <j-b> kierank: asm/hevc, outputting NV12 directly in software decoders, 
[18:06:39 CET] <wm4> what's that nv12 one for?
[18:07:10 CET] <kierank> nv12 > planar basically
[18:07:15 CET] <kierank> x264 is nv12 because it's faster
[18:07:18 CET] <kierank> and hw uses nv12
[18:07:22 CET] <j-b> yep.
[18:07:22 CET] <jamrial> a student wrote the hevc decoder. another can surely write a truehd encoder
[18:07:26 CET] <wm4> but I suppose it also needs more code
[18:07:47 CET] <j-b> not really :)
[18:07:50 CET] <kierank> jamrial: not the point. The point is hevc was appealing at the time (coool, new next-gen codec)
[18:07:55 CET] <kierank> truehd has been there for years
[18:07:57 CET] <kierank> we don't have a spec
[18:07:58 CET] <j-b> well, it's trivial to interleaving
[18:10:34 CET] <jamrial> anyway, as j-b said, assembly. hevc/cfhd/dca/aac/mp3/opus, for x86 and/or arm/aarch64
[18:10:42 CET] <BBB> encoders and decoders are completely different beasts
[18:11:01 CET] <nevcairiel> i'm not sure which is easier tbh
[18:11:15 CET] <nevcairiel> with an encoder you can just start with something naive and super inefficient
[18:11:18 CET] <BBB> I briefly looked at nv12, and the problem is youll have to rewrite much of the assembly for chroma-only
[18:11:27 CET] <BBB> MC, for example
[18:11:30 CET] <nevcairiel> with a decoder you have no choice but to support everything the spec asks for :D
[18:11:31 CET] <BBB> its really no fun at all
[18:11:49 CET] <j-b> BBB: so it's easier to reshuffle U, V planes?
[18:12:03 CET] <jamrial> nevcairiel: "whoops, unimplemented" -> return -1
[18:12:03 CET] <BBB> its certainly less code, yes
[18:12:05 CET] <jamrial> :p
[18:12:52 CET] <BBB> I can see how sao/loopfilter would be simple to do in interleaved chroma, possibly even reusing the luma code (not sure about that, just hypothesizing)
[18:13:06 CET] <BBB> but mc/intrapred and probably even inverse transform would need completely new code
[18:13:09 CET] <BBB> that is very uncool
[18:13:13 CET] <jamrial> our hevc decoder reports unimplemented features with some of the conformance suit samples, even
[18:13:17 CET] <nevcairiel> in my particular case, I can't really do zero copy for software decoding without many complicated problems, so I accepted having one memcpy, and instead of doing a plain memcpy I wrote SIMD to re-shuffle  the yuv420 -> NV12 in the process
[18:13:26 CET] <nevcairiel> its not any slower than a plain memcpy
[18:13:33 CET] <nevcairiel> so it practically comes for free
[18:13:46 CET] <BBB> uv420p->nv12 chroma reshuffling tends to be super-cheap, yes
[18:13:58 CET] <nevcairiel> now if your architecture allows zero-copy, that might be more of a problem
[18:14:12 CET] <BBB> its minimal compared to the overhead of actual decoding, really
[18:14:18 CET] <BBB> for modern codecs like h264, hevc and vp9
[18:14:42 CET] <BBB> I think for x264 thats different because of the amount of calls you do in the r/d loop, and uv interleaving halves that for chroma parts
[18:14:52 CET] <BBB> code complexity is less of an issue for encoders, its even expected
[18:14:59 CET] <BBB> but for decoders I dont know if it makes sense
[18:15:04 CET] <nevcairiel> even for x264 its a tiny gain only, but then 2% are 2%
[18:15:11 CET] <BBB> I used to be all for it, but after having tried it, I decided to give up fairly quickly
[18:15:17 CET] <cone-252> ffmpeg 03Michael Niedermayer 07master:23261e600149: sws/output: fix ordered dither threshold for mono output
[18:15:18 CET] <cone-252> ffmpeg 03Michael Niedermayer 07master:21b459e4bbfc: avformat/segment: Fix header_filename handling
[18:15:26 CET] <BBB> I dont think youd get 2% for a decoder, sadly
[18:17:22 CET] <BBB> j-b: still planning to move to canada?
[18:18:43 CET] <j-b> at some point, sure.
[18:19:29 CET] <kierank> meh
[18:22:35 CET] <cone-252> ffmpeg 03Rostislav Pehlivanov 07master:4701be7198eb: options_table: update maximum bitrate limit
[18:22:36 CET] <cone-252> ffmpeg 03Rostislav Pehlivanov 07master:ec9e87c922ad: avcodec: add a native SMPTE VC-2 HQ encoder
[18:22:37 CET] <cone-252> ffmpeg 03Rostislav Pehlivanov 07master:135460383e93: avformat: add vc2 as an allowed rawenc Dirac extension
[18:23:25 CET] <atomnuker> rejoice, a low delay, low overhead video encoder has been added
[18:24:24 CET] <atomnuker> technically not made for anything else than broadcasting stuff, but works great as a screen recoding codec
[18:27:27 CET] <wm4> that's awesome
[18:28:09 CET] <wm4> is this libschroedinger thing still needed?
[18:28:53 CET] <kierank> wm4: yes
[18:28:56 CET] <kierank> if you care about inter
[18:44:44 CET] <atomnuker> I still find the primitive quantization hilarious, it's just a left shift and a divide
[18:50:31 CET] <atomnuker> shit, fate-source fails, on it
[19:00:32 CET] <kierank> What is fate-source
[19:01:27 CET] <jamrial> checks every source file to see if they have proper copyright headers
[19:03:30 CET] <jamrial> it's also very slow. takes like a minute to finish on a core i5
[19:03:36 CET] <atomnuker> nope, I just used non-project-standard includion guards
[19:03:42 CET] <atomnuker> which is what fate-source also checks
[19:04:23 CET] <jamrial> on msys at least. it seems to spawn a lot of processes (sh, git, etc)
[19:05:03 CET] <cone-252> ffmpeg 03Rostislav Pehlivanov 07master:5669aa2a8ac5: vc2enc: use project-standard inclusion guards
[19:08:39 CET] <ubitux> having decoders output exclusively nv12 instead of yuv420p is going to have a negative impact any time filters are involved
[19:08:48 CET] <ubitux> unless you actually update most of them to support nv12
[19:10:58 CET] <nevcairiel> jamrial: on my system its not really noticeable slow, but its on a ssd, so that may help
[19:15:26 CET] <cone-252> ffmpeg 03Michael Niedermayer 07master:a73b23e3df15: avformat/hlsenc: Fix filename and options
[19:17:18 CET] <rcombs> ubitux: maybe we should have better autonegotiation there
[19:17:37 CET] <rcombs> like, decoder could output nv12 if the first filter in the chain supports it; otherwise yuv420p
[19:17:57 CET] <ubitux> sure, but keeping 2 paths in the decoder might be annoying
[19:18:42 CET] <ubitux> but after all, nv12 is annoying to deal with in filters
[19:21:05 CET] <rcombs> inherently, or just because a lot of code already targets yuv420p
[19:25:17 CET] <durandal11707> ubitux: what? first wilter will convert to what is supports, next filter uses that what first give
[19:26:17 CET] <durandal11707> *filter :)
[19:26:37 CET] <ubitux> yes but then you have a convert
[19:27:01 CET] <ubitux> so you do a roundtrip to sws when there wasn't any before
[19:32:07 CET] <durandal11707> atomnuker: copyright is ok?
[19:33:38 CET] <cehoyos> Thanks to Kierans comment, we can now guess what is meant, I still don't understand why it isn't clearly explained...
[19:33:43 CET] <durandal11707> dirac native is slooooooooooooooooooow
[19:34:03 CET] <cehoyos> Bye!
[19:34:17 CET] <atomnuker> durandal11707: decoding or encoding?
[19:34:32 CET] <durandal11707> atomnuker: decoding, vc2!=dirac
[19:35:07 CET] <durandal11707> encoding hd720 is slightly faster than realtime, decoding is nowhere realtime
[19:35:16 CET] <atomnuker> yeah, decoding is still slow as piss (~80% of the time goes just to read golomb)
[19:36:26 CET] <atomnuker> function is libavcodec/diracdec:coeff_unpack_golomb(), if anyone's interested
[19:46:05 CET] <nevcairiel> high bitrate will do that for you
[19:46:11 CET] <nevcairiel> most time spent reading the coeffs
[19:46:48 CET] <atomnuker> yeah, but it's oddly asymmetric
[19:47:06 CET] <atomnuker> writing is so fast
[19:48:48 CET] <atomnuker> then again for writing there's a LUT
[19:55:09 CET] <Timothy_Gu> durandal11707: any comments on blend asm?
[19:55:55 CET] <durandal11707> it is bit exact? whats gain?
[20:02:09 CET] <Timothy_Gu> it is
[20:02:23 CET] <Timothy_Gu> checkasm reports about 10x boost IIRC
[20:02:32 CET] <Timothy_Gu> (checkasm patch pending)
[20:02:42 CET] <Timothy_Gu> durandal11707: ^^
[20:03:22 CET] <Timothy_Gu> nop: 28.4
[20:03:22 CET] <Timothy_Gu> screen_c: 3568.5
[20:03:23 CET] <Timothy_Gu> screen_sse2: 313.0
[20:05:29 CET] <cone-252> ffmpeg 03Paul B Mahol 07master:5486d7fa91f7: avfilter/dualinput: use pts provided by framesync
[20:11:05 CET] <jrosser> someone still needs to factorise the vc2 golomb unpacking
[20:11:29 CET] <jrosser> or alterntively i need to write a paper on how to do it
[20:22:07 CET] <durandal11707> don is back and kicking!
[20:26:36 CET] <cone-252> ffmpeg 03Timothy Gu 07master:c8b1612af03b: x86/vf_blend: Move multiplying to a macro
[20:26:37 CET] <cone-252> ffmpeg 03Timothy Gu 07master:74f8d9aaef91: x86/vf_blend: Add SSE2 optimization for screen
[20:28:07 CET] <furkan> atomnuker: what's this low-delay encoder? is it possible to reduce compression (for lower CPU usage) at the expense of bandwidth for streaming over a LAN?
[20:28:32 CET] <RiCON> furkan: vc-2
[20:30:16 CET] <furkan> interesting
[20:32:58 CET] <furkan> i asked this in the main channel, but i've spent hours trying to figure out why i get this behaviour when streaming high bitrate h264 (>6Mbps) over UDP: https://www.dropbox.com/s/8s6m1ssi1wowbky/IMAG0096.jpg?dl=0
[20:33:25 CET] <furkan> there's no packet loss, no congestion, and TCP works fine... if anybody has tips on how i can debug, i'd appreciate it
[20:35:05 CET] <furkan> i'd like to make use of multicasting, with TCP that's obviously not an option
[20:54:32 CET] <jrosser> furkan: maybe counterintuitively reducing the compression will increase the cpu usage for vc-2, as the total number of bits which need to be packed/unpacked will go up
[21:03:02 CET] <furkan> interesting
[21:48:05 CET] <atomnuker> furkan: it
[21:48:26 CET] <atomnuker> furkan: it's low sense in that it can potentially only transmit parts of the image
[21:48:41 CET] <atomnuker> instead of an entire image
[21:48:57 CET] <atomnuker> so you can potentially start displaying the image as you recieve the first piece/slice
[21:50:03 CET] <atomnuker> I say potentially since you can't do that yet (libavcodec only works on whole frames, you'd need to rip the encoder out of it)
[21:50:25 CET] <Daemon404> avcodec has a way to do it line-by-line
[21:50:27 CET] <Daemon404> but not slices
[21:50:52 CET] <durandal11707> wtf avfilter_graph_parse2 two gotos
[21:51:21 CET] <wm4>  fail:end:
[21:51:22 CET] <wm4> nice
[21:51:23 CET] <atomnuker> Daemon404: nice to know
[21:51:32 CET] <wm4> Daemon404: what do you mean?
[21:51:34 CET] <Daemon404> draw_horiz_band or w/e
[21:51:51 CET] <wm4> that can output arbitrary units
[21:51:56 CET] <wm4> (I think)
[21:51:58 CET] <Daemon404> orly
[21:52:00 CET] <Daemon404> didnt know
[21:52:31 CET] <wm4> well it can output multiple lines at once
[21:52:41 CET] <wm4> which is why the function has "band" in the name
[21:52:52 CET] <Daemon404> sounds like what atomnuker wants then
[21:53:02 CET] <atomnuker> yep, exactly
[21:54:07 CET] <atomnuker> wm4: know any examples?
[21:54:53 CET] <wm4> not really... mplayer can use it lol
[21:55:00 CET] <wm4> kierank also tried to play with it once?
[21:55:18 CET] <wm4> just search for draw_horiz_band
[21:55:23 CET] <Daemon404> one crappy lossless codec i write supports it
[21:55:23 CET] <Daemon404> cant rememebr whuch
[21:55:29 CET] <Daemon404> wrote*
[21:56:55 CET] <TD-Linux> atomnuker, neat, is there any other comparable encoder in ffmpeg right now?
[21:58:25 CET] <atomnuker> TD-Linux: I guess VC-3 (dnxhd?) is in the same niche, and JPEG2000 is basically a direct competitor
[21:58:49 CET] <TD-Linux> I didn't know there was a dnxhd encoder in ffmpeg
[21:59:44 CET] <atomnuker> there is, AFAIK quite a lot of the broadcasting world uses that encoder to encode stuff to store
[22:01:00 CET] <jrosser> j2k is high computational complexity, comparitively
[22:01:05 CET] <jrosser> all that bit plane stuff
[22:02:27 CET] <gnafu> VC-3/DNxHD is basically a variant of MJPEG, right?
[22:02:33 CET] <gnafu> (To simplify it a bit, of course.)
[22:02:58 CET] Action: Daemon404 wonders what vc-4 was
[22:04:33 CET] <atomnuker> Daemon404: I did too until a few days ago
[22:04:56 CET] <atomnuker> some SMPTE invention which never got outside of a press release
[22:05:05 CET] <Daemon404> olol
[22:05:39 CET] <wm4> isn't ac-4 bitter reality?
[22:10:09 CET] <JEEB> at least the spec was posted somewhere
[22:10:27 CET] <JEEB> it's mostly a reality due to the fact that the AC-3 patents are going to run out
[22:11:33 CET] <TD-Linux> "It's hard to believe that Dolby's lossy AC-3 audio codec is nearly thirty years old"
[22:11:34 CET] <TD-Linux> no not really
[22:12:27 CET] <atomnuker> they could resort to patent evergreening
[22:13:09 CET] <atomnuker> I mean it's still used in pretty much all DVDs/BDs
[22:13:25 CET] <wm4> patent everwhat?
[22:14:26 CET] <atomnuker> "Evergreening refers to a variety of legal and business strategies by which technology producers with patents over products that are about to expire retain royalties from them, by either taking out new patents (for example over associated delivery systems, or new pharmaceutical mixtures), or by buying out or frustrating competitors, for longer periods of time than would normally be permissible under the
[22:14:28 CET] <atomnuker> law"
[22:15:12 CET] <atomnuker> so as far as I understand that, you can save your royalties by buying related but applicable patents from competitors (which for some reason you haven't bought yet)
[22:15:32 CET] <wm4> how wonderful
[22:16:49 CET] <TD-Linux> yeah I wonder what actually happened to ac-4. presumably it's not in TrueHD because it's decodeable as ac3?
[22:17:56 CET] <TD-Linux> err I meant atmos
[22:21:20 CET] <wm4> AV_PIX_FMT_GBRAP32FBE
[22:21:22 CET] <wm4> yummy
[22:21:51 CET] <nevcairiel> its floating point, do we really need LE and BE there as well
[22:22:58 CET] <wm4> I just complained about this
[22:24:20 CET] <Compn> whatever happened to NE ? :P
[22:36:04 CET] <rcombs> atomnuker: the AC-3 patents have already lasted longer than they should've since they filed some late
[22:36:21 CET] <rcombs> and then there's eac3
[23:13:40 CET] <BBB> michaelni: what is F"?
[23:13:44 CET] <BBB> michaelni: are these float formats?
[23:14:26 CET] <BBB> ah yes they are
[00:00:00 CET] --- Thu Feb 11 2016