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

[burek]

[00:07:40 CEST] <BBB> wm4: I asked for that, but it was decided that blending on black or on checkboard pattern was good enough, because libavutil only understands black when parsing text strings or so
[00:07:41 CEST] <BBB> ???
[00:08:03 CEST] <BBB> I dont recall exactly, it was very weird
[00:08:16 CEST] <BBB> does cehoyos attend vdd btw?
[00:08:21 CEST] <BBB> it would be very useful if he did
[00:08:38 CEST] <BBB> not for flaming, but just to be able to talk these things out& some things really are better discussed face-to-face
[00:12:18 CEST] <Daemon404> he has never attended
[00:12:34 CEST] <Daemon404> i heard he is this year
[00:12:36 CEST] <Daemon404> i could be wrong.
[00:15:11 CEST] <ubitux> durandal_1707: you can wget this if you want http://b.pkh.me/sc.gnumeric
[00:15:16 CEST] <ubitux> start looking at row 57
[00:15:37 CEST] <kierank> BBB: I believe he is coming, yes
[00:15:42 CEST] <BBB> cool
[00:15:53 CEST] <ubitux> durandal_1707: i need to add more combination though
[00:15:54 CEST] <BBB> I think he reads irc logs, so ...
[00:15:59 CEST] <BBB> cehoyos: please come to vdd
[00:16:02 CEST] <BBB> please please please
[00:17:50 CEST] <wm4> you seem to expect much from vdd
[00:17:57 CEST] <ubitux> BBB: i think he plans to 
[00:20:05 CEST] <BBB> wm4: it helps to be able to talk in person
[00:20:09 CEST] <BBB> but mayeb too much, yes
[00:22:48 CEST] <durandal_1707> ubitux: can you export in saner format?
[00:23:48 CEST] <ubitux> durandal_1707: maybe http://b.pkh.me/sc.ods ?
[00:25:47 CEST] <durandal_1707> pure txt no xml
[00:26:13 CEST] <durandal_1707> csv?
[00:27:00 CEST] <ubitux> with graphs? :/
[00:27:03 CEST] <ubitux> just a sec
[00:28:35 CEST] <ubitux> durandal_1707: http://b.pkh.me/sc.txt
[00:29:10 CEST] <ubitux> i need to do absolute+neutrals and relative+reds
[00:29:16 CEST] <ubitux> but it takes some time
[01:21:18 CEST] <lglinskih> I have wrong extra "lineendings" while using fwrite to stdout on mingw+wine. How can I avoid it? michaelni told me to look at libavformat/file.c, but I couldn't figure it out =/
[01:22:17 CEST] <lglinskih> I need to open stdout in binary mode, but as I understand using freopen is not a right way
[01:25:01 CEST] <kierank> fopen( stdout, "wb")?
[01:28:46 CEST] <michaelni> lglinskih, you could use avio API to write
[01:29:25 CEST] <michaelni> or see how avio does it and use a similar solution
[01:31:06 CEST] <michaelni> avio api would be avio_open() avio_write() avio_close() or something like that
[01:31:32 CEST] <michaelni> or what kieran suggested
[01:33:20 CEST] <lglinskih> ok, thanks! I'll be back with more questions later =)
[02:02:24 CEST] <cone-042> ffmpeg 03Carl Eugen Hoyos 07master:75d9006475a1: avfilter/vf_scale: Do not skip scale if range mismatches
[02:02:25 CEST] <cone-042> ffmpeg 03Michael Niedermayer 07master:5a00c30041a4: avfilter/vf_scale: Do not skip scale if the color matrix mismatches
[02:02:26 CEST] <cone-042> ffmpeg 03Michael Niedermayer 07master:58a0b7f11435: avfilter/vf_scale: If no output color matrix is specified, use the input
[02:02:27 CEST] <cone-042> ffmpeg 03Michael Niedermayer 07master:8e05f9217ae5: swscale/utils: Split scaling if possible and yuv->yuv with different matrixes is requested
[02:02:28 CEST] <cone-042> ffmpeg 03Michael Niedermayer 07master:1acd6311a100: swscale/utils: If cascaded contexts are used forward sws_setColorspaceDetails() to the first context
[03:43:54 CEST] <satazor> Hey guys, quick question: Does ffmpeg supports adding the ogg index (to improve seek performance) when encoding to a ogg file?
[08:11:35 CEST] <atomnuker> I should start making a list of all the things the specs say and no encoder implements them
[08:12:09 CEST] <atomnuker> I haven't seen a single encoder make use of the pulses (which were very briefly described in the specs)
[08:12:27 CEST] <atomnuker> or the TNS filter directionality
[08:13:08 CEST] <atomnuker> or even using the 16th codebook as an escape to code big spectral coefficients
[08:14:27 CEST] <atomnuker> It's just making more words for anyone writing a decoder
[08:16:27 CEST] <atomnuker> s/words/work
[09:13:24 CEST] <durandal_1707> ban carl
[10:00:45 CEST] <cone-790> ffmpeg 03Timothy Gu 07master:629d4c5b4dee: avconv_opt: Add missing comma
[10:00:46 CEST] <cone-790> ffmpeg 03Hendrik Leppkes 07master:ad79fa471b6f: Merge commit '629d4c5b4deee08bf3a4f3ab45fd4f8b76d7aff3'
[10:02:17 CEST] <cone-790> ffmpeg 03Timothy Gu 07master:c23999be134b: avconv_opt: Add an option that lists all supported hwaccels
[10:02:18 CEST] <cone-790> ffmpeg 03Hendrik Leppkes 07master:80a12be10f39: Merge commit 'c23999be134bde0a0554261a9043be7dbc01de0c'
[10:08:10 CEST] <cone-790> ffmpeg 03Luca Barbato 07master:b1abd2aaf91b: vf_scale: Add an option to pass the scaler params
[10:08:11 CEST] <cone-790> ffmpeg 03Hendrik Leppkes 07master:ea1061e147d3: Merge commit 'b1abd2aaf91be249f24cb74db9c205d9e4ca9da6'
[10:08:27 CEST] <cone-790> ffmpeg 03Henrik Gramner 07master:c457bdebe7af: checkasm: Fix floating point arguments on 64-bit Windows
[10:08:28 CEST] <cone-790> ffmpeg 03Hendrik Leppkes 07master:d5911e6963c0: Merge commit 'c457bdebe7af643b380aa0f6add3cb4335d218dc'
[10:24:13 CEST] <wm4> michaelni: what is the purpose of the snow encoder/decoder
[10:24:24 CEST] <nevcairiel> encoding/decoding snow of course
[10:24:28 CEST] <nevcairiel> you ask silly questions
[10:27:58 CEST] <wm4> it's a failed experiment
[10:30:24 CEST] <wm4> or is there a way to get actually good quality with snow?
[10:30:29 CEST] <wm4> (other than default settings)
[10:30:44 CEST] <nevcairiel> its a wavelet codec, so the answer is no :p
[10:33:27 CEST] <nevcairiel> since it also supports lossless, I imagine there is a way to also do "almost lossless", but dont ask me what options do that
[12:00:31 CEST] <cone-790> ffmpeg 03Donny Yang 07master:51d4bca5a40b: avcodec/pngdec: fully support the tRNS chunk
[12:39:53 CEST] <mouni> Hi i am new to ffmpeg ,prior to start with contributing to code what should i do?
[12:43:30 CEST] <JEEB> compile ffmpeg, look at what you'd like to do or fix, start poking around, compile, make the stuff follow the code style guidelines
[12:43:39 CEST] <JEEB> and ask questions if you have them
[12:47:15 CEST] <cbsrobot>  mouni: and read http://ffmpeg.org/developer.html
[12:54:37 CEST] <Daemon404> oh man that ticket is still going
[12:55:23 CEST] <Daemon404> [09:33] <@nevcairiel> since it also supports lossless, I imagine there is a way to also do "almost lossless", but dont ask me what options do that <-- that sounds a lot like cineform/vc-5
[12:55:36 CEST] <Daemon404> near-lossless wavelet (and bayer) crsp
[12:55:38 CEST] <Daemon404> crap*
[12:56:43 CEST] <wm4> so if it isn't possible to get decent quality out of snow, and it's not used in the wild at all, why does it exist? just because it's someone's pet project?
[12:56:57 CEST] <wm4> maybe I'm a bit "cruel" here, but come on
[12:57:51 CEST] <Daemon404> usually im all for removing cruft in the way or api, but snow seems fairly benign (path of least resistance to leave it in)
[12:58:18 CEST] <wm4> Daemon404: there's a patch that makes new API depend on it
[12:58:24 CEST] <Daemon404> wut
[12:58:55 CEST] <wm4> [PATCH 1/2] avcodec: Add interface to motion estimation
[13:00:10 CEST] <Daemon404> my condolences
[13:55:16 CEST] <BBB> did anyone test the various aac encoders to back up the claim that were about as good as apple's?
[13:55:46 CEST] <BBB> (Im not familiar with how audio codecs are typically compared, but Id love to see some subjective or objective metric tests at various bitrates between these encoders, if such tests existed)
[13:56:00 CEST] <cone-790> ffmpeg 03Andreas Cadhalpun 07master:2ac5b6ce8d82: fate: use 'c' for setting the channel_layout
[13:56:08 CEST] <wm4> BBB: atomnuker should know best
[13:56:08 CEST] <kierank> BBB: well the changes only came in recently
[13:56:58 CEST] <BBB> kierank: true, but they tested them when they wrote their changes, right?
[13:57:16 CEST] <BBB> I mean, this email on the list says were comparable to apples AAC encoder at 256kbps now"
[13:57:22 CEST] <BBB> that must mean someone compared it :)
[13:57:39 CEST] <Daemon404> "at 256kbps" means next to nothing
[13:57:41 CEST] <atomnuker> BBB: at very low bitrates (sub-75kbps), depending on audio content, we're not as good as Apple's
[13:57:54 CEST] <Daemon404> what abotu normal range
[13:57:55 CEST] <Daemon404> 128
[13:58:24 CEST] <atomnuker> at 128kbps, depending on audio content and options turned on, we're basically very nearly transparent
[13:58:35 CEST] <nevcairiel> how about at LC
[13:58:44 CEST] <atomnuker> yep, I'm talking about LC
[13:58:51 CEST] <atomnuker> AAC-Main doesn't help all that much
[13:58:54 CEST] <nevcairiel> how about mpeg2 LC
[13:58:55 CEST] <nevcairiel> :D
[14:00:08 CEST] <atomnuker> you mean MPEG-2 Part 3 or MPEG-2 Part 7?
[14:01:12 CEST] <nevcairiel> 7 of course
[14:01:33 CEST] <atomnuker> anyway, by depending on audio content, I mean we're fine as long as there are no uber fast-rise-time square waves overlapped and overdriven
[14:02:23 CEST] <nevcairiel> when streaming to various devices, mpeg-4 LC features may not be supported at all times
[14:02:28 CEST] <atomnuker> because then our encoder degrades into nastyness, which IS and M/S help to reduce (by giving more bits to encode them)
[14:02:29 CEST] <nevcairiel> so no TNS or PNS
[14:03:23 CEST] <atomnuker> well, with raw AAC-LC at around 96kbps we're fine
[14:03:35 CEST] <atomnuker> Claudio's changes will improve that area quite a lot
[14:04:02 CEST] <nevcairiel> although i think TNS might actually be available in mpeg2-aac, pns definitely is not though
[14:04:41 CEST] <wm4> BBB: lol... I'm sorry
[14:06:48 CEST] <rcombs> historically it's been QuickTime >= FDK > Nero > FAAC > lavc > vo_aac, right?
[14:06:48 CEST] <Daemon404> atomnuker, ... when they finally get merged
[14:06:52 CEST] <Daemon404> in 2090
[14:06:55 CEST] <BBB> wm4: ?
[14:07:14 CEST] <wm4> BBB: cehoyos' reply just now about the snow ME issue
[14:07:23 CEST] <rcombs> so where does lavc fit in there now, when encoding in the 128~256kbps range?
[14:07:24 CEST] <atomnuker> Daemon404: heh, he told me he'd have them merged in a week back in May
[14:07:25 CEST] <wm4> he's taking it personally again
[14:07:40 CEST] <BBB> atomnuker: thats very exciting (being mostly comparable with apples at most bitrates)
[14:08:00 CEST] <Daemon404> wait wait... 4814....
[14:08:08 CEST] <Daemon404> people are seriously proposing default is checkerboard?
[14:08:21 CEST] <wm4> Daemon404: it's the shitty compromise that works for everyone
[14:08:40 CEST] <Daemon404> wm4, that depends: is color settable via clu
[14:08:42 CEST] <Daemon404> cli*
[14:08:43 CEST] <rcombs> (and then how does it compare to libmp3lame?)
[14:08:48 CEST] <BtbN> at least it makes it obvious what's going on
[14:09:19 CEST] <Daemon404> if i can set it via cli, sure, whatever
[14:09:31 CEST] <wm4> Daemon404: the blend mode is of course settable via cli
[14:09:35 CEST] <Daemon404> no the COLOR
[14:09:39 CEST] <wm4> a user probably wouldn't find it, but still
[14:09:43 CEST] <wm4> AFAIK not
[14:09:46 CEST] <Daemon404> otherwise my only options are checkerboard or broken
[14:09:48 CEST] <Daemon404> which is SHIT
[14:09:55 CEST] <Daemon404> for say, a transcoding service
[14:10:41 CEST] <BtbN> +1 for white noise instead of checkerboard
[14:10:43 CEST] <Daemon404> (i'd set it so that it looks like it does in quicktime, which is what people who upload shit would expect)
[14:10:59 CEST] <Daemon404> BtbN, i dont care what it is, but having it entirely unsettable is kidna ridiculous
[14:11:04 CEST] <atomnuker> rcombs: kamedo2 does the comparisons on that +400 comments trac ticket
[14:11:08 CEST] <atomnuker> rcombs: http://i57.tinypic.com/11l37s2.png
[14:11:55 CEST] <wm4> Daemon404: the argument is that it depends on the container or something
[14:11:56 CEST] <atomnuker> rcombs: this is with Claudio's changes only and none of mine, it'll probably be a bit better than mp3
[14:12:21 CEST] <rcombs> atomnuker: is that your guess for with both, or with just yours?
[14:12:30 CEST] <atomnuker> both
[14:12:32 CEST] <Daemon404> wm4, what argument?
[14:12:38 CEST] <atomnuker> or just mine
[14:12:40 CEST] <Daemon404> im only arguing to allow it to be settable *at all*
[14:12:41 CEST] <Daemon404> via cli
[14:12:46 CEST] <atomnuker> just mine, yeah
[14:12:47 CEST] <rcombs> nice
[14:12:48 CEST] <Daemon404> not just "broken" or "what we chose"
[14:12:53 CEST] <Daemon404> those are terrible options.
[14:13:26 CEST] <rcombs> I look forward to not having to tell people to use libmp3lame instead of lavc aacenc
[14:13:57 CEST] <BtbN> Specialy when it actualy gets non-experimental soon
[14:16:43 CEST] <atomnuker> anyway, I have to write to Claudio to see if he has the time/I help him and push the last TNS stuff and maybe sleep
[14:17:14 CEST] <nevcairiel> would be great if claudios changes get applied as well, the ticket has been cooking for way too long
[14:23:21 CEST] <BBB> Daemon404: yes, the only two options are checkerboard and black
[14:23:43 CEST] <BBB> Daemon404: I asked to make the color (black) selectable, but that was rejected because libavutil doesnt udnerstand non-black text color strings
[14:23:47 CEST] <BBB> or something ridiculous like that
[14:23:52 CEST] <BBB> and it was tons of effort to add it
[14:23:58 CEST] <BBB> so therefore, the two options are black and checkerboard
[14:24:04 CEST] <Daemon404> wut?
[14:24:18 CEST] <Daemon404> this sounds retared and/or lazy
[14:24:22 CEST] <BBB> it is lazy
[14:24:28 CEST] <BBB> using snow as avme is lazy also
[14:24:31 CEST] <BBB> I see a pattern
[14:24:58 CEST] <Daemon404> depending on what is chosen, i guess it's patch time
[14:25:04 CEST] <BBB> exporting FF_QSCALE_TYPE_MPEG1 in libavutil is also lazy
[14:25:09 CEST] <Daemon404> cant be hard to parse RRR,GGG,BBB
[14:25:12 CEST] <BBB> all this shit is lazy
[14:25:20 CEST] <BBB> we have some exceptionally lazy developers in our team
[14:25:24 CEST] <BBB> poor designers, also
[14:25:38 CEST] <Daemon404> im not one to talk about laziness
[14:25:43 CEST] <Daemon404> i send like a patch every 3 months
[14:28:52 CEST] <BBB> priceless, that next email, durandal_1707 
[14:29:51 CEST] <BBB> Daemon404: but seriously, the reason these kind of hacks exist in our codebase is because the talented developers tend to have their hands full doing Work[r][c] for BigCorp[tm], so they dont have time to scan the lists for innocent-looking patch titles that are complete hack implementations
[14:31:36 CEST] <wm4> maintaining software is hard
[14:38:55 CEST] <ubitux> so, do we have a standard way to get the mb width/height for the qp store?
[14:40:36 CEST] <wm4> "copy the IFs from mplayer code"
[14:40:45 CEST] <wm4> or maybe libpostproc
[14:41:33 CEST] <ubitux> i was looking at fspp
[14:41:38 CEST] <ubitux> and i'm afraid
[14:41:40 CEST] <ubitux> :(
[14:47:42 CEST] <Daemon404> i wonder how many times ill have to read "but who is maintaining it????" to libav-merged code
[14:48:54 CEST] <BBB> ubitux: I believe the AVFrame side data field structs for motion vectors have a block width/height int
[14:49:14 CEST] <BBB> maybe qp data has that also?
[14:49:16 CEST] <BBB> I dont know
[14:49:45 CEST] <BBB> I mean, its probably a gigantic hack that just happens to accidentally work for mpeg1/2, then someone forgot that its a hack and made it work for vp56 and later h264 came along
[14:50:00 CEST] <BBB> nobody cares about mpeg4/hevc/vp9/vc1/whatever, of course
[14:50:36 CEST] <Daemon404> BBB, you cant make people happy, the end
[14:50:43 CEST] <Daemon404> true story: people objected to splitting up mpegenccontext
[14:50:49 CEST] <Daemon404> because "having it in one place is easier"
[14:50:55 CEST] <Daemon404> (not even joking. that was said in this channel.)
[14:52:12 CEST] <ubitux> BBB: is it already exported from side data?
[14:52:33 CEST] <ubitux> qp getter gives the qp stride, the qp type (codec), and a buffer
[14:52:42 CEST] <ubitux> (qp themselves)
[14:54:37 CEST] <BBB> creating MpegEncContext is the biggest mistake in ffmpeg history
[14:54:59 CEST] <BBB> ubitux: maybe& dont know. Ill have a look
[14:55:11 CEST] <ubitux> no hurry, i'm working on it anyway
[14:55:19 CEST] <ubitux> i'll try to send a patch today
[14:55:53 CEST] <ubitux> i'm pretty sure we can make the codecview filter do cool stuff
[14:56:03 CEST] <ubitux> like, exporting the segmentation from codecs (hi vp9/hevc)
[14:57:15 CEST] <ubitux> btw, h264 can exports the qp table but doesn't; i patched locally and it works, but we probably don't want to do it by default
[14:57:24 CEST] <ubitux> which will be inconsistent with other mpeg codecs
[14:57:55 CEST] <ubitux> it needs to be exported only if it's free (i think the current qp api allows this, side data might not)
[14:57:56 CEST] <BBB> exporting segmentation would be cool, but feature parity is all we need in the short term, I think
[15:19:09 CEST] <ubitux> http://b.pkh.me/0001-avfilter-codecview-WIP-add-QP-support.patch
[15:19:18 CEST] <ubitux> i'm probably doing something wrong here though
[15:20:38 CEST] <wm4> the big reopening
[15:21:02 CEST] <ubitux> i kind of have the same results as with -debug vis_qp 
[15:21:17 CEST] <ubitux> but i probably don't have relevant samples
[15:52:26 CEST] <ubitux> durandal_1707: you remind me that i have a patch to finalize about the merge of [t]interlace...
[15:52:31 CEST] <ubitux> but indeed i forgot that license shit
[15:54:23 CEST] <ubitux> lol
[15:54:45 CEST] <ubitux> problem is still technically not solved?
[15:56:30 CEST] <iive> it is technically solved.
[15:56:52 CEST] <iive> but some people don't like the solution.
[15:57:06 CEST] <ubitux> i guess i'll have to read the thread&
[15:57:12 CEST] <wm4> only carl wants to discard the alpha plane because it's "slow"
[15:59:20 CEST] <JEEB> lol
[16:00:44 CEST] <iive> well, it is literally bikeshed problem, because everybody argues for their favorite color :)
[16:02:03 CEST] <ubitux> there is a bug in quicktime with that sample
[16:02:18 CEST] <ubitux> the fade in is way faster than what i get with mpv typically
[16:02:37 CEST] <ubitux> like, the texts almost pops
[16:04:04 CEST] <wm4> maybe the alpha blending is not linear?
[16:04:54 CEST] <wm4> can you upload the QT result?
[16:05:05 CEST] <ubitux> how can i do that? :D
[16:05:13 CEST] <ubitux> qt transcodes? :P
[16:05:18 CEST] <wm4> I've never even seen QT's UI in my life
[16:05:27 CEST] <RiCON> mpc-hc also blends to black
[16:05:29 CEST] <JEEB> yes, it does
[16:05:30 CEST] <ubitux> i also have doubt about desktop recording
[16:05:37 CEST] <ubitux> JEEB: how can i do that?
[16:05:43 CEST] <JEEB> there's an export menu or whatever
[16:05:55 CEST] <JEEB> OS X QT should have the encoding features by default
[16:06:07 CEST] <JEEB> Windows version IIRC had it only for "QT Pro"
[16:06:07 CEST] <JEEB> :D
[16:07:35 CEST] <wm4> how do you get QT?
[16:07:39 CEST] <wm4> on OSX
[16:07:44 CEST] <JEEB> it comes with the OS
[16:07:44 CEST] <ubitux> JEEB: thx, worked
[16:07:52 CEST] <JEEB> ubitux: np <3
[16:08:57 CEST] <ubitux> wm4: http://b.pkh.me/proresalphablock-test.mov
[16:09:01 CEST] <ubitux> maybe just my imagination
[16:09:12 CEST] <ubitux> i need to compare frame by frame
[16:09:30 CEST] <wm4> wow QT can't even open mkv
[16:09:42 CEST] <JEEB> of course it can't
[16:09:43 CEST] <ubitux> i like how it glitches badly with the white rectangle with the QT transcode :DDD
[16:09:49 CEST] <ubitux> so actually
[16:09:52 CEST] <ubitux> QT has the same problem
[16:09:54 CEST] <ubitux> :')
[16:10:00 CEST] <wm4> yeah
[16:10:28 CEST] <ubitux> so everything is ok
[16:10:32 CEST] <ubitux> ticket closed
[16:10:34 CEST] <ubitux> ;)
[16:11:34 CEST] <wm4> playback is still fine
[16:11:43 CEST] <wm4> only QT's exporter and thumbnailer behave different
[16:11:55 CEST] <BBB> so now libav is a failure?
[16:12:06 CEST] <BBB> I dont know how we got from snow obmc to libav failure
[16:12:10 CEST] <BBB> that was interesting
[16:12:12 CEST] <ubitux> i think carl was right from the beginning :X
[16:12:23 CEST] <ubitux> but Daemon404 has a point; the blending color should be configurable
[16:12:35 CEST] <iive> ubitux: i think everybody agrees to that
[16:12:36 CEST] <Compn> cant we just enable/disable it like gray decoding ?
[16:12:49 CEST] <iive> ubitux: now if we had somebody who cares enough to implement it...
[16:12:55 CEST] <Compn> removing gray decoding slows down decoder ... :P
[16:12:55 CEST] <BBB> Compn: noooooooooo
[16:12:57 CEST] <Compn> YES
[16:13:07 CEST] <BBB> that gray related code is so stupid
[16:13:11 CEST] <Compn> whaahhahahaha
[16:13:52 CEST] <Daemon404> it would speed up the decoder for the general case
[16:13:53 CEST] <Daemon404> one less if
[16:14:02 CEST] <Compn> benchmarks no lie
[16:14:35 CEST] <wm4> which benchmarks?
[16:16:05 CEST] <cone-790> ffmpeg 03Peter B 07master:baeb8f5f7149: tests: Renamed pix_fmts wording in ffv1 test target name to match pix_fmt parameter.
[16:23:36 CEST] <BBB> ubitux: I think michael is the best person to point you to interesting samples with delta qp (some h264 samples use that; in fact, x264 should use it by default)
[16:24:01 CEST] <ubitux> yeah for h264 i think i have some, but i need to get my patch back making it export the qp
[16:24:11 CEST] <ubitux> like i said, h264 doesn't export qp currently
[16:24:16 CEST] <ubitux> (it's a one line change though iirc)
[16:24:57 CEST] <BBB> aha
[16:24:58 CEST] <BBB> ok
[16:25:17 CEST] <ubitux> one line change but probably performance impact
[16:25:26 CEST] <ubitux> so it needs to be added with an option probably...
[16:25:33 CEST] <ubitux> unless there is a zero copy way
[16:26:37 CEST] <BBB> option is fine imo
[16:27:04 CEST] <ubitux> it will be inconsistent with other codecs though
[16:27:22 CEST] <ubitux> maybe the options needs to be at lavc level, with a "auto" mode codec specific
[16:27:40 CEST] <ubitux> starting to get a bit overengineering but well
[16:39:12 CEST] <ubitux> BBB: qp buffer is in a buffer ref
[16:39:18 CEST] <ubitux> so technically it might be free
[16:39:31 CEST] <BBB> in AVFrame
[16:39:36 CEST] <BBB> but h264 doesnt fill it by default
[16:39:37 CEST] <BBB> right?
[16:39:45 CEST] <BBB> so you need to fill it, which is an extra op per block
[16:40:39 CEST] <ubitux> per block? no it's per frame?
[16:40:46 CEST] <ubitux> it's already filled afaik
[16:41:52 CEST] <BBB> one qp buffer per frame
[16:41:56 CEST] <BBB> one qp value per block in the buffer
[17:17:18 CEST] <atomnuker> Any idea when 2.8 is going to get tagged & released?
[17:17:37 CEST] <BtbN> Soonish, most likely.
[17:52:58 CEST] <ubitux> BBB: http://pastie.org/pastes/10387677/text just this for h264
[17:53:54 CEST] <ubitux> (needs this before: http://b.pkh.me/0001-avcodec-reduce-ff_mpv_export_qp_table-parameters-sco.patch)
[17:58:16 CEST] <BBB> cool
[17:58:37 CEST] <BBB> so does this mean we can continue the qp visualization removal in lavc?
[18:01:57 CEST] <wm4> lavc has qp visualization?
[18:02:22 CEST] <BBB> I believe the history is that at some point michael used it to debug mpegvideoenc
[18:02:31 CEST] <BBB> and since then its been a stable feature in lavcodec, yes
[18:03:10 CEST] <BBB> and we cant remove it because itd be a feature regression
[18:03:31 CEST] <wm4> awesome
[18:08:34 CEST] <ubitux> BBB: my code doesn't work yet unfortunately
[18:48:33 CEST] <kierank> This particular issue could be avoided by not having an intra-library ABI,
[18:48:33 CEST] <kierank> i.e. having a single library.
[19:01:05 CEST] <wm4> kierank: wasn't this rejected multiple times
[19:01:54 CEST] <kierank> bit of a strange suggestion from nicola
[19:01:56 CEST] <kierank> s
[19:21:25 CEST] <Compn> i like single library idea
[19:21:33 CEST] <Compn> enough of this api crap
[19:21:41 CEST] <Compn> one api to rule them all
[19:21:50 CEST] <kierank> libmplayer
[19:48:14 CEST] <BBB> I dont think I have an opinion on that&
[19:56:02 CEST] <durandal_1707> libcompn
[19:58:50 CEST] <iive> i have better idea. not only one library, but also make it systemd plugin.
[20:01:51 CEST] <philipl> Then we'll get an over-opinionated maintainer for free!
[20:02:13 CEST] <philipl> GNU/Linux -> Systemd/Linux
[21:36:03 CEST] <rtogni> mc
[21:58:12 CEST] <llogan> lglinskih: good work, and good luck at university!
[22:58:43 CEST] <lglinskih> llogan: thank you! ^_^
[23:48:16 CEST] <kierank> lglinskih: good luck yes
[00:00:00 CEST] --- Tue Sep  1 2015