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

[burek]

[00:00:30 CET] Action: TD-Linux 's habit of collecting retro hardware means he will never fully escape the touch of sjis
[00:00:35 CET] <RiCON> i'm not a programmer so I don't know whether it'd be easier to add support to the native decoder or updating the wrapper, so opinion on dropping the wrapper
[00:00:49 CET] <RiCON> no opinion*
[00:02:09 CET] <JEEB> I know it's not as optimized as the VFW version at least. it's not slow but there's a whole whoop-ass-load of asm in the VFW build of official ut video
[00:02:43 CET] <JEEB> the original implementation is GPL so you couldn't just take the asm from there
[00:04:17 CET] <JEEB> threading should be better on our side since the VFW version at least is limited to sliced threading - which at least in the short experiments we did was slower than image-based threading
[00:04:39 CET] <JEEB> also I think the encoder lacks support for the interlacing-specific coding mode
[00:05:24 CET] <JEEB> and then 10bit, yes
[00:06:18 CET] <Daemon404> i dont think throughput is your goal on utvideo
[00:06:29 CET] <Daemon404> it used sliced threads specifically for low delay NLE support
[00:06:33 CET] <JEEB> yeah
[00:07:14 CET] <JEEB> anyways, most of those things come from the VFW version only, so they're most probably unrelated to the hackjob of libutvideo
[00:07:56 CET] <JEEB> and yeah, as I thought
[00:07:59 CET] <JEEB> from qyot's e-mail
[00:07:59 CET] <JEEB> libutvideoenc is locked to only one prediction type, and the speed
[00:07:59 CET] <JEEB> issues in either the encoder or decoder wrapper could (probably are)
[00:08:00 CET] <JEEB> the side-effect of libutvideo not enabling the asm by default
[00:08:31 CET] <Daemon404> the asm crashes on x86_64 btw. from what i remember.
[00:09:05 CET] <JEEB> so, uh, 10bit is the only real reason except for mini's reasoning of "it makes it simpler to test against official", which isn't really true because it's not really official...
[00:09:50 CET] <Daemon404> nor is it simple
[00:10:05 CET] <Daemon404> like i said. tomorrow.
[00:10:08 CET] <JEEB> ye
[00:10:15 CET] Action: JEEB hits the sack
[00:27:30 CET] <J_Darnley> Good job sorting those files Windows!  You really know your alphabet!
[00:50:28 CET] <jya> BBB: with libvpx, you can feed pretty much any vp9 stream and if there's a change iin resolution or whatever, t happily chum along and output a different image size
[00:51:25 CET] <jya> does ffvp9 handle it as nicely (we're looking at how we can play webrtc recordings, which are just plain raw vp9 streams appended in series)
[00:55:02 CET] <Daemon404> i think youll probably get avframes with a different res
[00:55:06 CET] <Daemon404> but dont quote me
[00:59:32 CET] <iive> wm4: still wondering about the has_b_frame thing?
[00:59:55 CET] <iive> I think you are confusing few things.
[01:16:35 CET] <BBB> jya: yes
[01:16:53 CET] <BBB> jya: we have been tested with a wide variety of streams, like compiler-generated ones that trigger every branch in libvpx
[01:17:06 CET] <BBB> jya: and the output for every single one of these streams is bitexact between libvpx and ffvp9
[01:17:27 CET] <jya> BBB: so the ffvp9/8 will simply output a picture with a different size ?
[01:17:39 CET] <BBB> jya: yes (as Daemon404 said, check AVFrame->width/height)
[01:17:51 CET] <BBB> it will change between frames if the resolution changed from one frame to the next
[01:17:54 CET] <jya> excellent. thank you
[01:18:05 CET] <BBB> AVCodecContext->width/height is the output of the last decoded frame
[01:18:18 CET] <BBB> which may be entirely different than AVFrame->width/height, although its usually the same
[01:18:38 CET] <BBB> jya: our test suite also includes a few sequences that change size
[01:18:56 CET] <BBB> jya: chrome also has a few of these, you can pick whichever of them you prefer for your unit tests if you want them
[01:19:11 CET] <jya> ok
[01:29:04 CET] <jya> BBB: so looking at the AVPicture, it's a simple matter of reading width/height. What about aspect ratio ? is this something it will adjust too (checking our code we use the A/R as defined in the container and so doesn't change over time)
[01:36:41 CET] <BBB> jya: I believe AVFrame also has a sample_aspect_ratio or so
[01:37:02 CET] <BBB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html#a62f9c20541a83d37db7072126ff0060d
[01:37:07 CET] <BBB> AVRational AVFrame::sample_aspect_ratio
[01:37:34 CET] <jya> thank you for that
[01:37:42 CET] <BBB> thats the one defined in the bitstream
[01:37:55 CET] <jya> what about the offset ?
[01:38:09 CET] <BBB> what is offset?
[01:38:30 CET] <jya> let me find you sample from our regression test
[01:38:43 CET] <jya> this is something neither VLC nor Chrome display properly
[01:39:50 CET] <BBB> well thats not good
[01:39:53 CET] <jya> it's a video that defines clipping
[01:40:05 CET] <jya> it's ignored by VLC/Chrome
[01:41:17 CET] <BBB> Ive never heard of this
[01:42:55 CET] <Timothy_Gu> michaelni: ok
[01:45:19 CET] <jya> BBB: ah found it
[01:45:23 CET] <jya> this regression test: https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video/offset-1.xhtml
[01:45:37 CET] <jya> this should display a small black square
[01:45:57 CET] <jya> chrome displays a green one with the black square in it
[01:48:09 CET] <jya> ffplay does it wrong too; https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video/black29x19offset.webm
[01:48:24 CET] <jya> it's vp8 though
[01:49:35 CET] <jya> mkvinfo shows that the picture is 64x64, with display is 29x29 with a crop of (29, 4, 6, 31)
[01:50:10 CET] <Compn> what displays it correctly ?
[01:50:19 CET] <jya> firefox of course :)
[01:50:49 CET] <Compn> fair enough
[01:51:06 CET] <Compn> does ffmpeg support autocrop ? hmm
[01:51:11 CET] <cone-465> ffmpeg 03Michael Niedermayer 07master:61ea7f15094d: swscale/swscale-test: Check av_image_fill_linesizes() for failure
[01:51:28 CET] <Compn> container crop i should say. or is it vp8 cropping like h264 cropping mhmmm
[01:51:50 CET] <jya> this is why in our FFmpeg decoder, we use what we read in the demuxer to determine the display size (and AR and cropping info)
[01:52:17 CET] <jya> now to support change of resolution mid-stream, I have to rely on FFmpeg to report the right info
[02:01:29 CET] <BBB> Ive never heard of this offset thing TBH
[02:02:00 CET] <Daemon404> sounds liek container cropping... i thought webm would have not included that in its subset
[02:02:42 CET] Action: Daemon404 sleeps
[02:03:56 CET] <jya> BBB: yeah, I'm stuck between a rock and a hard place. Because if I want to pass our reftest and display that silly box properly, I have to use the dimension+offset+cropping from the container
[02:04:06 CET] <BBB> I dont see any cropping elements in the metadata when I run ffprobe
[02:04:14 CET] <BBB> I also dont see any offset elements in the vp8 header
[02:04:24 CET] <BBB> ok so its container
[02:04:27 CET] <BBB> I dont know how that works
[02:04:28 CET] <BBB> :)
[02:04:34 CET] <jya> but if I want to be able to handle the change of resolution in the VP stream, I have to use the FFmpeg dimensions which don't tell me anything about it
[02:05:02 CET] <BBB> MATROSKA_ID_VIDEOPIXELCROPB
[02:05:10 CET] <BBB> right
[02:05:14 CET] <jya> I guess I could craft a work around, such as for the first stream we use the dimensions found in the container.
[02:05:16 CET] <BBB> so I dont know how to handle it TBH :)
[02:05:23 CET] <jya> and if we detect a change, we only use FFmpeg ones
[02:05:27 CET] <BBB> the container defines it per-stream obviously
[02:05:44 CET] <BBB> but the codec/bitstream may change size per stream, hypothetically
[02:05:48 CET] <BBB> this is obviously not intended
[02:05:49 CET] <BBB> just saying
[02:05:51 CET] <jya> BBB: sure, but since it can only defines it for a single stream
[02:05:58 CET] <BBB> ?
[02:06:00 CET] <BBB> rly?
[02:06:17 CET] <BBB> it looks like matroska can do it for each video stream?
[02:06:21 CET] <BBB> in the video stream header
[02:06:21 CET] <jya> I mean, the webm has a single "element information" cluster, 
[02:06:28 CET] <BBB> (track)
[02:06:54 CET] <BBB> video cropping info is in the video track element, not information element
[02:07:07 CET] <jya> yeah, via the via PrevUID/NextUID in mkv
[02:07:11 CET] <jya> but that's not allowed in webm
[02:07:16 CET] <BBB> oh
[02:07:18 CET] <BBB> well
[02:07:22 CET] <BBB> then I dont know :D
[02:12:54 CET] <Compn> why have res changes mid stream
[02:12:55 CET] <Compn> whyyyyyyy
[02:12:59 CET] <Compn>   :P
[02:14:53 CET] <atomnuker> to make life difficult and render all init allocations useless
[02:16:50 CET] <atomnuker> well, not entirely useless, in the Daala decoder I do all the allocs in the init function but realloc my buffers if the dimensions change
[02:19:21 CET] <jya> Compn: it's used for stuff like recording a video-call stream
[02:19:38 CET] <jya> resolution changes often there depending on the network quality
[02:19:52 CET] <Compn> you dont just axe bitrate but res too ? haha
[02:20:11 CET] <jya> make seeking into those files interesting too
[02:20:32 CET] <jya> Compn: that's a fair point actually
[02:21:32 CET] <BBB> seeking doesnt change
[02:21:36 CET] <BBB> go to nearest keyframe and go from there
[02:21:44 CET] <BBB> res change does not change that
[02:21:57 CET] <cone-465> ffmpeg 03Michael Niedermayer 07master:37db3e8931f6: avcodec/libutvideoenc: Add NULL termintor to options
[02:23:01 CET] <Timothy_Gu> who handles the SSL certs for ffmpeg.org?
[02:23:40 CET] <Compn> some root
[02:23:46 CET] <Compn> either michael ? alex ?
[02:23:59 CET] <TD-Linux> Compn, modern video codecs are not scale independent, so at some point switching resolution is better
[02:24:13 CET] <Compn> of course, i'm just curious. i'm not saying anything is bad
[02:24:15 CET] <TD-Linux> and VP9 lets you switch resolution without inserting an I frame, which works quite well for videoconferencing
[02:24:18 CET] <michaelni> reimar handles the certs
[02:24:25 CET] <Timothy_Gu> ok
[02:24:30 CET] <BBB> TD-Linux: hows the files coming along? do you have an invoice for me already?
[02:25:03 CET] <TD-Linux> BBB, it's actually copying as I speak, should ship tomorrow (you'll get a tracking #)
[02:25:05 CET] <jya> BBB: finding the nearest keyframe is the tricky bit, those webm do not have cues in them
[02:25:36 CET] <llogan> Timothy_Gu: is there something wrong with them?
[02:27:17 CET] <TD-Linux> note that for cropping vp9 via RTP header extensions, this problem was solved and the crop is defined in 0-1 units
[02:27:52 CET] <TD-Linux> this might be something to bring up with CELLAR so that mkv can be fixed
[02:43:36 CET] <BBB> TD-Linux: oh, cool!
[02:44:09 CET] <BBB> jya: my stream analyzer simply scan the whole file frame-by-frame if theres no idnex
[02:45:53 CET] <BBB> TD-Linux: ty! Ill paypal you as soon as you email me the amount to transfer
[05:50:46 CET] <cone-847> ffmpeg 03James Almer 07master:b3b0ecee1550: x86/emms: empty the mmx state unconditionally on supported targets
[12:06:10 CET] <michaelni> all my fate clients are offline till 16 utc due to elektricans in the house and unpredictable power outages
[12:08:31 CET] <J_Darnley> :(
[12:08:55 CET] <J_Darnley> Those poor computersbeing deprived of precious electricity
[12:14:09 CET] <wm4> yeah, I don't understand this, I mean they don't remove all oxygen from the air when e.g. changing windows, do they?
[12:19:28 CET] <cone-481> ffmpeg 03Hendrik Leppkes 07master:a969a914f558: dca_parser: ensure frame duration matches the actual sample rate
[13:27:44 CET] <wm4> iive: I'm still confused about it, but I also made a dumb mistake in my thinking somewhere
[13:53:06 CET] <wm4> lovely cryptic error messages
[13:53:23 CET] <nevcairiel> openssl errors are fun
[13:53:52 CET] <iive> wm4:  i figured.
[13:54:00 CET] <nevcairiel> speaking of ssl, i'm somewehat amazed that my schannel support didnt crash and burn in some way
[13:55:37 CET] <wm4> nevcairiel: why would it catch fire?
[13:55:43 CET] <iive> wm4: think of it this way. B frames need past and future reference. You have to decode the future frame out-of-order and keep it.
[13:56:24 CET] <nevcairiel> wm4: dunno, its hard to get something like this right the first try
[13:56:37 CET] <iive> wm4: so if you have decoded order of:
[13:56:42 CET] <iive> I1 B B B I2
[13:56:52 CET] <iive> you get bitstream of
[13:57:03 CET] <iive> I1 I2 B B
[13:57:09 CET] <iive> you could decode it as:
[13:57:32 CET] <iive> I1 __ B B (I2)
[13:57:53 CET] <iive> if you delay by one frame you get:
[13:58:05 CET] <iive> __ I1 B B I2
[13:58:14 CET] <wm4> yeah, I understand that much
[13:58:36 CET] <iive> ok, what is that you don't understand?
[13:58:44 CET] <wm4> what I'm confused about is the relationship between has_b_frames, num_reordered_frames, and delay vs. maximum reorder
[13:59:10 CET] <nevcairiel> has_b_frames is set to num_reorder_frames if its present, but its generally not since it requires a constrained bitstream
[14:00:19 CET] <wm4> so if I understand this right, in the worst case lavc/lavf "probes" has_b_frames by trying to output 1 frame?
[14:01:14 CET] <nevcairiel> yes but its not reliable to probe it, since this value may not be constant throughout the entire stream, ie. the first gop could use less references and therefor re-ordering because the scene was simple and more didnt make sense for the encoder
[14:01:26 CET] <nevcairiel> so it could always change a bit later
[14:01:55 CET] <wm4> increasing the delay is not so bad, lavc can just not return a frame
[14:01:56 CET] <nevcairiel> the only way to have a reliable result is to use -strict 1 which assumes the maximum reordering for the allowed level
[14:02:40 CET] <nevcairiel> (of course level could also change in weird bitstreams, so there is that)
[14:04:32 CET] <iive> isn't the output of 1 frame, because the needed info is not stored in extradata, but muxed in the video stream?
[14:38:53 CET] <Daemon404> [12:56] <@nevcairiel> wm4: dunno, its hard to get something like this right the first try <-- im sure curl had many tries ;)
[15:07:30 CET] <nevcairiel> well sure, but still plenty that could go wrong porting something like that
[15:15:08 CET] <cone-481> ffmpeg 03Michael Niedermayer 07master:f89bc661b429: avfilter/af_afftfilt: Set last_expr to the default
[15:25:48 CET] <JEEB> which audio filter is the one used by -ac ?
[15:25:52 CET] <JEEB> or do I just set -ac
[15:26:02 CET] <nevcairiel> -ac uses swresample of course
[15:26:14 CET] <JEEB> yes, I know that
[15:26:16 CET] <nevcairiel> but just set -ac if you want to change number of audio samples
[15:26:23 CET] <JEEB> channels, but yes
[15:26:29 CET] <nevcairiel> ah yeah
[15:26:30 CET] <nevcairiel> typo =p
[15:26:44 CET] <JEEB> ok, I will do that then. I just had an audio filtering thing in filter_complex already
[15:26:55 CET] <JEEB> so I thought I'd just make it downmix to stereo and then do what I'm doing after that
[15:27:04 CET] <JEEB> but I guess I'll just deal with -ac 2
[15:27:54 CET] <nevcairiel> not sure if it passes the audio through lavfi for -ac or just calls swr manually
[15:29:16 CET] <nevcairiel> looks like it uses the aresample filter for all that
[15:46:22 CET] <ubitux> JEEB: you insert an aformat filter
[15:46:30 CET] <ubitux> just like you would use a format
[15:46:41 CET] <ubitux> it creates constraints, and auto scaler/resampler are inserted
[15:47:08 CET] <ubitux> aformat=channel_layouts=stereo for instance
[16:00:12 CET] <JEEB> oh right
[16:00:15 CET] <JEEB> ubitux: thanks
[16:22:07 CET] <ubitux> ffmpeg user ml is on fire
[16:23:38 CET] <wm4> how so
[16:23:53 CET] <ubitux> top posting "debate"
[16:30:32 CET] <fritsch> i just read it
[16:30:37 CET] <fritsch> i want my time back
[16:30:46 CET] <fritsch> one troll but 5 other troll feeders
[16:44:49 CET] <rcombs> I'm for team "who gives a shit"
[16:45:06 CET] <rcombs> as I am in most internet debates
[16:49:48 CET] <atomnuker> I just lit a fire and sent it off to the ML
[16:50:08 CET] <atomnuker> I suggest people to grab some popcorn and salt
[16:50:25 CET] <Daemon404> i disagree
[16:50:35 CET] <wm4> popcorn with salt?
[16:50:40 CET] <Daemon404> i think mixed code and decls is a bad coding practice.
[16:50:59 CET] <Daemon404> along with VLAs.
[16:51:22 CET] <Daemon404> (for loops, i dont mind)
[16:51:25 CET] <wm4> I'm for declaring variables where you need them, instead of letting them accumulate on the top
[16:51:38 CET] <Daemon404> block scope != top
[16:51:57 CET] <Daemon404> if you have a buttload of vars declared at the top, i argue you  have other problems
[16:53:14 CET] <J_Darnley> I've seen some code which evades that by just opening a new block.  No conditional and sometimes wrong indentation.
[16:53:55 CET] <atomnuker> yep, and that's ugly IMO
[16:54:41 CET] <atomnuker> I could probably shorten the AAC encoder by at least 150 lines if I could insert variables when I needed them and avoiding int i type declarations
[16:56:26 CET] <kierank> yes my code does that
[16:56:27 CET] <kierank> it's horrid
[16:56:34 CET] <kierank> but for the VLC reader you have no choice
[17:09:47 CET] <nevcairiel> its really not such a bad rule if you keep close attention to declare variables in the blocks that use them and not shove them all at the function start
[17:10:03 CET] <nevcairiel> the only thing thats really somewhat annoying is loop counters, as others have already mentioned
[17:14:04 CET] <BtbN> Just declare all single-letter vars as global static thread-local vars, problem solved!
[17:15:13 CET] <jamrial> ubitux: did you try andreas' patch for the lcov issue?
[17:15:25 CET] <ubitux> didn't have time yet
[17:15:34 CET] <ubitux> maybe i'm going to do it now
[17:15:51 CET] <ubitux> but i'm in the middle of sth so probably later
[17:24:30 CET] <jamrial> alright
[17:40:32 CET] <cone-481> ffmpeg 03Carl Eugen Hoyos 07master:a36c737490d9: lavf/isom: Add more code points for H264.
[18:03:37 CET] <cone-481> ffmpeg 03Paul B Mahol 07master:f862ff750b48: avfilter/vf_stack: free input pads name on uninit
[18:19:23 CET] <Timothy_Gu> llogan: wanted to ask if fate[beta].ffmpeg.org could use SSL as well
[18:19:46 CET] <nevcairiel> fatebeta should be called fatebetter
[18:19:54 CET] <Timothy_Gu> also wondering when we can start using SHA-256 certs
[18:20:00 CET] <Timothy_Gu> nevcairiel: sure
[18:21:17 CET] <nevcairiel> or you know, just replace fate already
[18:21:28 CET] <nevcairiel> i've been using it exclusively lately, anything wrong with it? :)
[18:21:41 CET] <Daemon404> i keep forgetting it exists
[18:22:02 CET] <nevcairiel> the main reason i use it is the version branch separation, release branches clutter the view on the main one so much
[18:22:11 CET] <jamrial> fatebeta is nice but it would be nicer if it also had the same top bar as the original fate
[18:22:32 CET] <jamrial> it makes spotting obvious failures easier
[18:22:34 CET] <Timothy_Gu> jamrial: i really want to migrate to a proper DB which makes querying a lot easier
[18:22:42 CET] <Timothy_Gu> and color bars etc.
[18:23:00 CET] <Timothy_Gu> but we have 654408 entries in the entire file-based "DB" so it's gonna take some time
[18:23:37 CET] <Daemon404> my main issue with both fate pages is still the dang sidebar
[18:23:44 CET] <Daemon404> it just wastes so much space and makes it hardet to read
[18:24:09 CET] <Daemon404> also it feels liek 1996
[18:24:10 CET] <Daemon404> with frames
[18:24:13 CET] <Daemon404> /minirant
[18:24:14 CET] <nevcairiel> you need a bigger screen
[18:24:14 CET] <jamrial> on a smartphone, maybe. on any decent display it's not an issue
[18:24:33 CET] <Daemon404> nevcairiel, im on a nearly-4k screen
[18:24:48 CET] <nevcairiel> then you need a lower scale =p
[18:24:57 CET] <nevcairiel> its such a small part of the entire screen
[18:25:20 CET] <Daemon404> i dont mean physically hard to read
[18:25:25 CET] <Daemon404> i mean it looks awful and cluttered
[18:26:03 CET] <Daemon404> and
[18:26:05 CET] <Daemon404> http://fatebeta.ffmpeg.org/v2.2
[18:26:11 CET] <Daemon404> clicking branches -> side bar is *gone*
[18:26:16 CET] <Daemon404> and its a big blank space
[18:26:25 CET] <Daemon404> it just looks bad.
[18:26:31 CET] <nevcairiel> its just gone in general now
[18:26:37 CET] <nevcairiel> i bet Timothy_Gu removed it :p
[18:26:44 CET] <Daemon404> lol
[18:27:50 CET] <Timothy_Gu> nevcairiel: ya working on it
[18:27:50 CET] <atomnuker> but the whole page is off-center right now
[18:27:57 CET] <Timothy_Gu> broke something instead
[18:28:06 CET] <nevcairiel> the page hasnt moved, it just blanked out the side bar
[18:30:04 CET] <Timothy_Gu> nevcairiel, Daemon404: better now?
[18:30:21 CET] <Daemon404> i like it better, of course ;p
[18:30:24 CET] <Daemon404> given my minirant above
[18:32:39 CET] <nevcairiel> i dont mind either way
[18:44:37 CET] <atomnuker> jamrial: what did the bitexact flag do?
[18:47:27 CET] <atomnuker> oh yeah, I forgot, it excluded from printing lavc's version to the bitstream
[18:54:19 CET] <cone-481> ffmpeg 03James Almer 07master:4c573f8ce961: fate: fix fate-aac-pns-encode failures on non-sse x86_32 targets
[19:13:49 CET] <Timothy_Gu> jamrial: colorful bar added
[19:13:55 CET] <Timothy_Gu> "top bar"
[19:19:07 CET] <llogan> another Thursday, another hangover. drinking is bad, kids.
[19:19:23 CET] <llogan> i should stop going to pub trivia
[19:31:18 CET] <BBB> so& stop going? :D
[19:33:39 CET] <atomnuker> humans have cosumed alcohol for over 4700 years
[19:34:02 CET] <atomnuker> can you abandon an old friend?
[19:34:53 CET] Action: atomnuker says after never having been pissed enough to blackout
[19:53:57 CET] <J_Darnley> Useless ISP!
[20:07:12 CET] <jamrial> Timothy_Gu: nice, thank you
[20:28:25 CET] <jamrial> nevcairiel: can you check/review "avcodec/dcadsp: replace intptr_t with ptrdiff_t"?
[20:39:15 CET] <nevcairiel> jamrial: i'll look at it later
[20:39:28 CET] <jamrial> ok, thanks
[20:39:55 CET] <nevcairiel> although intptr_t is likely always the wrong type when used as a function argument =p
[21:28:01 CET] <Daemon404> ;/g 54
[21:44:41 CET] <wm4> was there a decision yet whether we want to be compatible to Libav ABI
[21:44:53 CET] <nevcairiel> we dropped ABI a long time ago
[21:45:48 CET] <wm4> there's still some AV_HAVE_INCOMPATIBLE_LIBAV_ABI
[21:45:59 CET] <wm4> and useless accessors all over the place
[21:46:59 CET] <nevcairiel> feel free to send patches to remove the incompatible abi things, but the accessors are API and here to stay for a while =p
[21:47:06 CET] <wm4> in this case I want to access qp_table_buf, but YOU CAN'T
[21:47:22 CET] <nevcairiel> you are not meant to
[21:47:23 CET] <wm4> it says "Not to be accessed directly from outside libavutil", but you can't access the bufferref at all
[21:47:51 CET] <nevcairiel> its deprecated anyway
[21:48:01 CET] <nevcairiel> use the sidedata
[21:48:46 CET] <wm4> hm you're right it's inside of deprecation guards
[21:49:27 CET] <wm4> can't find the not-deprecated version though
[21:50:49 CET] <wm4> and the code setting the qp table in mpegvideo is not unside of deprecation guards
[21:50:50 CET] <wm4> such quality
[21:51:05 CET] <ubitux> av_frame_get_qp_table()
[21:51:16 CET] <wm4> ubitux: it's not refcounted
[21:51:17 CET] <ubitux> but that qp code is kinda ugly
[21:51:22 CET] <ubitux> yeah
[21:51:32 CET] <wm4> ok this is a good reason to tell the user that it's not possible to implement
[21:51:44 CET] <nevcairiel> why do you need some kind of metadata table to be refcounted
[21:52:04 CET] <ubitux> could be a side data, though relatively huge
[21:52:17 CET] <wm4> nevcairiel: because it'll cost always
[21:54:59 CET] <nevcairiel> anyway the plan is of course to move all this rather specific stuff out of generic structs, not sure someone actually finished writing the replacement for qp, but its not quite gone yet either
[22:37:17 CET] <llogan> they're still bickering in -user. maybe i'll put an end to it because i'm tired of it
[22:44:38 CET] <nevcairiel> what are they on about today
[22:45:43 CET] <BtbN> Someone has decided that top posting is way better.
[22:46:25 CET] <nevcairiel> so, a pointless thing even
[22:51:25 CET] <llogan> i put in a regex to hopefully dump it to my mod queue
[23:16:45 CET] <Daemon404> g 42
[23:27:27 CET] <gnafu> Daemon404: You're not having the best day with that, it seems.
[23:33:11 CET] <Daemon404> indeed.
[00:00:00 CET] --- Fri Feb  5 2016