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

[burek]

[01:15:44 CEST] <cone-965> ffmpeg 03Timo Rothenpieler 07master:665c05f7cb70: configure: Fail if CUDA enabled but not found
[01:48:44 CEST] <BtbN> wow, merging even a single trivial commit is a pain.
[01:59:28 CEST] <jamrial> where?
[02:08:05 CEST] <BtbN> Already sorted it, cherry-picking was a bit easier than merging.
[02:08:22 CEST] <BtbN> Want to mess with this a bit: https://git.libav.org/?p=libav.git;a=commit;h=07a844f32ebb78503981df017fa3ebfedb75fe1c
[02:09:23 CEST] <nevcairiel> merging is hard because it requires everything to be merged in order
[02:09:30 CEST] <nevcairiel> getting single commits, thats what cherry-pick is for
[02:09:53 CEST] <BtbN> Pushing that single one would mess with the merges though?
[02:38:50 CEST] <BtbN> Great: "In the current version, the cuda context MUST be created from a D3D device, using cuD3D9CtxCreate function."
[02:38:54 CEST] <BtbN> So much about that
[02:41:46 CEST] <BtbN> http://docs.nvidia.com/cuda/video-decoder/ says otherwise... so the docs in their headers are outdated i guess? oO
[02:42:21 CEST] <jamrial> BtbN: you can send a patch based on a libav commit to the ml for review and apply it. once it comes out in the merge queue it will simply get no-op'd
[02:42:49 CEST] <BtbN> I primarily want this because it gives downloading of CUDA frames.
[02:43:17 CEST] <BtbN> I'm fine with keeping it in my own branch for now.
[02:43:36 CEST] <BtbN> Those two patches are probably somewhat controversial
[05:03:36 CEST] <cone-192> ffmpeg 03Michael Niedermayer 07master:8f2a1990c06d: avcodec/diracdec: check bitstream size related fields for overflows
[08:10:05 CEST] <midgetspy> Could somebody please do me a favor and forward http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192207.html to the thread author (me, nic at wolfeden.ca)? I mistakenly thought I'd receive replies to my thread without being subscribed to the list, now I've subscribed but I can't figure out how to reply to that thread without having received the message originally. Thanks.
[10:15:58 CEST] <cone-702> ffmpeg 03Matthieu Bouron 07master:308d3ed5aa3a: lavc/mediacodec: use ternary operator to set slice-height value
[10:32:00 CEST] <Gramner> midgetspy: click on the e-mail address mailto link at the top of that page to reply with the correct headers
[10:53:20 CEST] <cone-702> ffmpeg 03Paul B Mahol 07master:ff982e02b547: avcodec: add dca core extraction bsf
[10:56:32 CEST] <nevcairiel> durandal_1707: you should really wait until someone reviews your code before pushing it, its only been about half a day and its the easter holidays...
[10:57:06 CEST] <durandal_1707> its trivial code
[10:57:44 CEST] <durandal_1707> jamrial have tested it
[10:58:32 CEST] <durandal_1707> so only name can be changed if you prefer something else...
[11:51:26 CEST] <ethe> michaelni: coc looks fine now
[12:17:27 CEST] <JEEB> wow
[12:17:43 CEST] <JEEB> just noticed the dict API change
[12:18:59 CEST] <Mavrik> The one with duplicate key support?
[12:22:27 CEST] <JEEB> yeah, or well the thread about it
[12:23:04 CEST] <JEEB> > someone voices concerns > still pushed purely based on time (´4@)
[12:23:56 CEST] <Mavrik> Yeah that's... fun.
[12:24:10 CEST] <Mavrik> I'm now looking at the mediacodec patch... and I see much fun with AllWinner and MediaTek crap in the future.
[12:24:15 CEST] <JEEB> yeah
[12:24:19 CEST] <JEEB> I chuckled when I saw that
[12:25:10 CEST] <nevcairiel> thats why mediacodec is crap
[12:25:14 CEST] <nevcairiel> its api gets violated so much
[12:25:40 CEST] <JEEB> also how things fail is completely dependant on the layer implementing it
[12:25:48 CEST] <Mavrik> I think it's quite telling about the skill of Google devs that we got API to check for number of HW decoders in Android N :P
[12:26:24 CEST] <JEEB> I totally understand why things have their own profile/level checks before passing stuff to the hwdec at all
[13:30:26 CEST] <ubitux> mmh
[13:30:39 CEST] <ubitux> i'm thinking of using av_codec_get_pkt_timebase() in lavc/ccaption_dec
[13:30:47 CEST] <ubitux> instead of avctx->time_base
[13:30:54 CEST] <ubitux> which seems to do the trick in the codecpar branch
[13:31:02 CEST] <ubitux> would this be ok?
[13:49:30 CEST] <ubitux> ooh i can do much better
[14:17:18 CEST] <ubitux> huh, one patch didn't reach the ml
[14:17:56 CEST] <ubitux> ah now it did
[14:20:15 CEST] <ubitux> Daemon404: ccdec fixed in codecpar
[14:22:03 CEST] <JEEB> nice
[14:22:54 CEST] <ubitux> (as soon as the patch on the ml are applied and cherry-picked back into codecpar)
[14:39:17 CEST] <durandal_170> BBB: whar have you done with colomatrix filter?
[14:39:29 CEST] <BBB> context?
[14:40:09 CEST] <durandal_170> BBB: patches on ml
[14:40:40 CEST] <BBB> I didnt do anything, someone else sent patches and Im commenting on them, right?
[14:40:46 CEST] <BBB> like, review
[14:40:53 CEST] <BBB> and I havent approved any yet, have I?
[14:45:15 CEST] <durandal_170> BBB: guy said that he will not work on it anymore
[14:45:26 CEST] <BBB> yeah I just noticed that
[14:45:32 CEST] <BBB> how about I finish the patch?
[14:45:47 CEST] <BBB> his approach was mostly OK, I can do the templating and DSPization myself
[14:45:57 CEST] <durandal_170> you mentioned something about simd
[14:46:12 CEST] <JEEB> also you can test it against the zscale filter which also has colorspace conversions between, say, BT.709 and BT.2020
[14:46:31 CEST] <durandal_170> so just go ahead and finish it
[14:46:33 CEST] <BBB> ok, so, a few things
[14:46:37 CEST] <BBB> durandal_170: yes boss
[14:46:51 CEST] <BBB> A) I am not testing against zscale, I want external libs to die, especially libxyz ones
[14:46:57 CEST] <BBB> I fundamentally dont believe in them
[14:47:03 CEST] <BBB> I dont want to install crap like that on my system
[14:47:08 CEST] <JEEB> ok
[14:47:20 CEST] <BBB> B) colormatrix is fundamentally broken, it doesnt convert between RGB spaces
[14:47:21 CEST] <durandal_170> BBB: I'm not your boss
[14:47:38 CEST] <BBB> i.e. it assumes that all matrix coefficients between XYZ/RGB are equal between colorspaces, which they are not
[14:47:45 CEST] <BBB> not to mention gamma differences
[14:48:10 CEST] <BBB> C) ideally all of this would live in swscale, if it wasnt for the fact that swscale is rotten as hell
[14:48:13 CEST] <JEEB> zimg basically replaced swscale in vapoursynth
[14:48:17 CEST] <BBB> so& more constructively
[14:48:20 CEST] <durandal_170> mpv have code that does it correctly
[14:48:21 CEST] <JEEB> which is what zscale uses
[14:48:37 CEST] <BBB> I have a lot of code that corrects the XYZ/RGB issue
[14:49:04 CEST] <BBB> its not finished but I guess I should just finish it
[14:49:43 CEST] <BBB> it would still make it a two-stage process to convert from any to any, youd need both swscale as well as colormatrix
[14:49:50 CEST] <BBB> but at least it does the theoretically correct thing
[14:49:55 CEST] <JEEB> yeah
[14:50:07 CEST] <BBB> at some point years ago I wrote a complete scaling library that replaced swscale to do all of this in one place
[14:50:12 CEST] <BBB> I actually called it avscale also :-p
[14:50:15 CEST] <BBB> but that name is taken now
[14:50:38 CEST] <JEEB> well that never saw the light of day as far as I've seen so people made their own things for that
[14:50:46 CEST] <BBB> but I forgot where I put that code. it was pretty good but particular optimized paths were not as fast (by design) as swscale and fixing that would involve lots of hacks, so I eventually lost interest
[14:51:04 CEST] <BBB> and now I dont remember where it is anymore
[14:51:15 CEST] <BBB> I might have deleted it& I probably have backups but I cant be bothered
[14:51:18 CEST] <JEEB> and in the end zimg seemed to be the least retarded and generic
[14:51:59 CEST] <BBB> what you want is a any-range | any-colorspace | any-size < to > any-range | any-colorspace | any-size, right?
[14:52:21 CEST] <JEEB> the author is a troll of course, so I can understand not wanting anon32 code on one's machine :D  (also he seems to be against enabling x86 SIMD by default for whatever reason)
[14:52:25 CEST] <BBB> with optimal precision, least rounding artifacts, little intermediates, etc.
[14:53:35 CEST] <JEEB> https://github.com/sekrit-twc/zimg but yeah, this seems to do the general cases
[14:54:01 CEST] <BBB> so you want to use zscale? or you want to extend colormatrix? or you want to rewrite avscale?
[14:55:22 CEST] <JEEB> I would at this point say that it should be looked into if zimg could be used or just taken into FFmpeg on the longer run. on the shorter run I guess fixing colormatrix could be a good thing
[14:56:03 CEST] <JEEB> and my original comment regards testing against zscale meant that you could check the results against it if you wanted - without any further meaning :P
[14:56:16 CEST] <JEEB> since "hey, there's another filter that can do that stuff probably too"
[14:56:50 CEST] <BBB> I dont think we should take zimg
[14:57:02 CEST] <JEEB> yeah, it's basically herecy due to C++
[14:57:02 CEST] <BBB> zimg is just another swscale piece of shit that will end up being unmaintained and hated
[14:57:25 CEST] <JEEB> ok
[14:57:30 CEST] <BBB> well c++ doesnt help either :-p
[14:57:34 CEST] <BBB> let me start with colormatrix
[14:57:58 CEST] <BBB> shall I work on top of thomasz patches?
[14:58:11 CEST] <BBB> its only fair we attribute him for the work he did, I mean, he did put in quite some effort it seems
[14:58:16 CEST] <JEEB> yeah
[14:58:42 CEST] <BBB> but so, a funny thing about colormatrix is that youre alreading seeing its design limitations: every colorspace needs new functions
[14:58:43 CEST] <Gramner> I've never looked at the swscale source code, what's the problem with it? poor design, or just generally code quality issues?
[14:58:45 CEST] <BBB> its not generic at all
[14:58:54 CEST] <BBB> Gramner: why dont you have a look :-p
[14:59:07 CEST] <BBB> I recommend starting with the rgb2yuv or yuv2rgb code paths
[15:00:22 CEST] <BBB> I recommend trying to figure out the difference between (or the need for) SWS_FULL_CHR_H_INP and _INT, and then figuring out where yuv/rgb conversion coefficients are stored, how a user sets them and when they are honoured vs. when they are not (bonus points if you can do this for the mpegrange/fullrange flag)
[15:00:32 CEST] <kierank> BBB: colormatrix is gpl so maybe not the best place to start
[15:00:38 CEST] <BBB> ???
[15:00:40 CEST] <BBB> really
[15:00:43 CEST] <BBB> I didnt know that
[15:00:58 CEST] <kierank> iirc yes because it came from avisynth origianlly
[15:01:07 CEST] <BBB> ok so thats not happening then
[15:01:11 CEST] <BBB> let me start from scratch
[15:01:18 CEST] <BBB> I can probably rewrite it in a few minutes
[15:07:10 CEST] <durandal_170> I wanted to rewrite it too
[15:07:30 CEST] <durandal_170> using mpv as reference
[15:09:52 CEST] <durandal_170> it uses primaries for constructing matrix
[15:10:36 CEST] <durandal_170> It's smile matrix operations
[15:10:44 CEST] <durandal_170> *simple
[15:41:20 CEST] <kierank> J_Darnley: ping
[15:44:04 CEST] <kierank> https://www.irccloud.com/pastebin/Q5chYDZK/
[15:44:12 CEST] <kierank> is it possible to SIMD that?
[15:49:03 CEST] <J_Darnley> oh my, 10-bit packing
[15:49:04 CEST] <nevcairiel> looks possible, although maybe not incredibly efficient
[15:49:06 CEST] <J_Darnley> maybe
[15:49:17 CEST] <J_Darnley> someone did manage to write it for v210
[15:49:30 CEST] <kierank> yeah but v210 has some level of alignment
[15:49:34 CEST] <kierank> raw 10-bit doesn't
[15:49:39 CEST] <J_Darnley> oh
[15:50:00 CEST] <J_Darnley> yes 2 bits of padding for every 3 samples
[15:51:13 CEST] <kierank> I also don't need to worry about interleaving chroma actually because the actual pixelformat is uyvy422-10bit
[15:51:19 CEST] <kierank> but I don't want to add that to libavutil
[15:56:10 CEST] <kierank> I guess I should do it in groups of 15 bytes
[15:56:36 CEST] <kierank> 120-bits so 12x 10-bit words
[16:14:12 CEST] <Daemon404> ubitux, cool
[16:22:03 CEST] <midgetspy> Gramner: Thanks, I did see that link but in Outlook and gmail it didn't set my In-Reply-To header correctly and I couldn't find any way to force it. Forwarding the actual message preserves the In-Reply-To/References headers which should work.
[16:32:56 CEST] <wm4> ubitux: heh, I think your timebase patches would break mpv?
[16:33:37 CEST] <wm4> it doesn't copy the whole avcodeccontext from an AVStream, only select fields
[16:34:57 CEST] <durandal_170> kierank: have you tried zoneplate source filter?
[16:35:56 CEST] <kierank> I will do it at work
[16:40:34 CEST] <ubitux> wm4: what would break?
[16:40:39 CEST] <ubitux> ccaption?
[16:41:01 CEST] <ubitux> or the legacy timing?
[16:41:29 CEST] <wm4> I'm not sure
[16:41:46 CEST] <ubitux> i mean which patch you think is going to break?
[16:42:06 CEST] <wm4> currently my code sets the AVCodecContext.time_base
[16:42:19 CEST] <wm4> if your patch changes it to pkt_timebase, wouldn't that break?
[16:42:38 CEST] <wm4> at the very least it'd error-out
[16:43:29 CEST] <ubitux> pkt_timebase is already used everywhere in the subtitles rescaling
[16:43:52 CEST] <ubitux> do you set AVCodecContext.time_base to sth different than the stream tb?
[16:44:04 CEST] <wm4> which stream tb
[16:44:09 CEST] <ubitux> stream->time_base
[16:44:26 CEST] <wm4> I send packets with timestamps according to AVCodecContext.time_base if you mean that
[16:45:57 CEST] <ubitux> when a demuxer create a new stream and set the timing info, it seems to actually set the pkt_timebase
[16:46:00 CEST] <ubitux> this is what i use now
[16:46:22 CEST] <wm4> well I'm not using the API like ffmpeg.c does...
[16:46:42 CEST] <ubitux> sure, but, what timebase value are you setting then?
[16:46:52 CEST] <wm4> AVCodecContex.time_base
[16:46:59 CEST] <ubitux> yes but to what value?
[16:47:04 CEST] <wm4> 1/1000
[16:47:09 CEST] <ubitux> ah
[16:48:23 CEST] <ubitux> why :(
[16:48:29 CEST] <wm4> why not?
[16:48:39 CEST] <wm4> I think I even asked whether it's right to set time_base
[16:49:38 CEST] <ubitux> are you still using the old ass timing or you switched that?
[16:49:48 CEST] <wm4> still the old one
[16:49:52 CEST] <ubitux> mmh
[16:50:12 CEST] <wm4> (no reason to switch until I actually get all timings in the correct time base)
[16:50:33 CEST] <ubitux> so, so far, it seems there is only 2 remaining usage of avctx->time_base for subtitles
[16:50:47 CEST] <ubitux> and that's the 2 things i changed in these patches
[16:51:34 CEST] <ubitux> (1. the timing rescale for the deprecated ass payload 2. ccaption dec)
[16:51:44 CEST] <ubitux> everything else is using pkt_timebase
[16:52:05 CEST] <ubitux> it's strange that you get it working as expected with 1/1000
[16:52:54 CEST] <wm4> why is it strange?
[16:53:15 CEST] <ubitux> because most of the subtitles code is using pkt_timebase
[16:59:08 CEST] <ubitux> wm4: typically for bitmap subs your avctx->time_base will be ignored for instance
[16:59:22 CEST] <ubitux> (afaict)
[17:00:18 CEST] <wm4> that's because they either pass through the timestamp, or use a fixed timebase
[17:00:33 CEST] <wm4> the only place where I have this problem are subtitle converters
[17:01:32 CEST] <kierank> J_Darnley: seems to be possible in the same way as v210
[17:02:02 CEST] <kierank> load, copy, variable shift (pmullw), pxor
[17:02:07 CEST] <kierank> 4:01 PM <"kierank> J_Darnley: seems to be possible in the same way as v210
[17:02:42 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/4M1Ff8nt/
[17:02:49 CEST] Action: kierank writes enterprise simd
[17:05:20 CEST] <J_Darnley> good
[17:05:36 CEST] <J_Darnley> and sorry for the disconnects
[17:05:59 CEST] <J_Darnley> This is the level of service my ISP provides during "business hours"
[17:10:25 CEST] <kierank> going to be headache inducing though
[17:10:29 CEST] <kierank> three loads for every store
[17:10:40 CEST] <kierank> loads of 128*3 bits to write 120bits
[17:12:52 CEST] <wm4> just wondering, would it be easier to generate such code with a script?
[17:13:47 CEST] <kierank> dunno maybe
[17:14:25 CEST] <kierank> a two loads per store, not so bad
[17:46:04 CEST] <cone-033> ffmpeg 03Paul B Mahol 07origin/release/3.0:HEAD: avcodec: add dca core extraction bsf
[17:49:11 CEST] <atomnuker> michaelni: which branch do I backport the aacenc fixes for 3.0.1?
[17:49:53 CEST] <michaelni> to release/3.0, also use cherry-pick -x so the hash from the source commit is in it
[17:58:52 CEST] <cone-033> ffmpeg 03Ganesh Ajjanagadde 07release/3.0:7c2576e15d32: lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value
[17:58:53 CEST] <cone-033> ffmpeg 03Reimar Döffinger 07release/3.0:1cbe4ff2acdd: aacenc: avoid double in quantize_bands.
[17:58:54 CEST] <cone-033> ffmpeg 03Reimar Döffinger 07release/3.0:b176ab055691: aacenc_utils: Use temporary variable.
[17:58:55 CEST] <cone-033> ffmpeg 03Ganesh Ajjanagadde 07release/3.0:f281cb4ea93d: lavc/aacenc_utils: replace powf(x,y) by expf(logf(x), y)
[17:59:46 CEST] <cone-033> ffmpeg 03Rostislav Pehlivanov 07release/3.0:6cb5bbc66024: Changelog: update for 3.0.1's aacenc optimizations
[18:02:08 CEST] <kierank> Gramner: are the variable shifts in avx2 any good?
[18:02:24 CEST] <kierank> instead of pmullw (2^n)
[18:03:56 CEST] <Gramner> they accomplish the same thing essentially in most cases, assuming the shift amount is constant
[18:04:12 CEST] <Gramner> they're useful if you have calculated shift amounts though
[18:05:30 CEST] <cone-033> ffmpeg 03Rostislav Pehlivanov 07release/3.0:f01919b57af0: vc2enc: correctly zero out coefficient array padding
[18:05:31 CEST] <cone-033> ffmpeg 03Rostislav Pehlivanov 07release/3.0:3d9ebfd27264: Changelog: update for 3.0.1's vc2enc fixes
[18:08:56 CEST] <Angus__> Is anyone here familar with struct URLProtocol?
[18:10:03 CEST] <cone-033> ffmpeg 03Paul B Mahol 07master:c2bbcf16077b: avfilter/vf_waveform: optimize 16bit lowpass filter
[18:20:37 CEST] <ubitux> Daemon404: so mov is supposed to be fixed?
[18:21:04 CEST] <ubitux> binsub-movtextenc is still failing, i'm wondering if the issue is within mov or the encoder
[18:21:16 CEST] <ubitux> or maybe demux/decoder
[18:22:15 CEST] <Daemon404> ubitux, i bet it is the same as all the other mov failures
[18:22:17 CEST] <Daemon404> fiel atom
[18:22:27 CEST] <Daemon404> nevcairiel explained it a few days back.
[18:22:36 CEST] <ubitux> ok i'll grep my logs
[18:22:38 CEST] <ubitux> thx
[18:23:33 CEST] <ubitux> it seems to be in the tkhd atom though
[18:23:55 CEST] <Daemon404> ubitux, easy way to check is to use boxdumper
[18:23:58 CEST] <Daemon404> and diff outout
[18:24:01 CEST] <Daemon404> thats what i did
[18:24:22 CEST] <Daemon404> boxdumper oldfateoutput.mov > src.txt
[18:25:04 CEST] <JEEB> yeah, boxdumper is quite useful
[18:25:06 CEST] <Daemon404> you could simply be seeing the atom size changes due to nesting
[18:26:14 CEST] <ubitux> lol, it's width/height
[18:27:30 CEST] <ubitux> so width/height are missing for the subtitles track
[18:27:39 CEST] <ubitux> meh.
[18:28:28 CEST] <Daemon404> er what?
[18:30:33 CEST] <ubitux> the original mp4 has a tx3g stream with width=400 height=60
[18:30:41 CEST] <ubitux> when transcoding, this information is now lost
[18:30:51 CEST] <ubitux> maybe codecpar->{width,height} are copied only for video?
[18:31:01 CEST] <nevcairiel> check the code and add it if needed
[18:31:03 CEST] <nevcairiel> its possible
[18:31:11 CEST] <nevcairiel> subtitle support is pretty limited in libav afterall
[18:42:20 CEST] <BtbN> Hm, if I cherry-pick a new file from libav, do I keep their file-header, or do I replace it with the ffmpeg one? (Keeping license and author of course)
[18:42:37 CEST] <Daemon404> :%s/Libav/FFmpeg/
[18:42:59 CEST] <Daemon404> since the file is now a part of a different project
[18:43:14 CEST] <ubitux> can we get done with codecpar asap? :(
[18:43:39 CEST] <Daemon404> ubitux, after subtitles, most of what's left is slightly over my head
[18:43:51 CEST] <Daemon404> like voc
[18:44:23 CEST] <ubitux> we're now 150+ commits behind
[18:44:37 CEST] <Daemon404> behind libav?
[18:44:38 CEST] <Daemon404> or ffmpeg?
[18:44:54 CEST] <ubitux> libav has 150+ commits not merged
[18:45:11 CEST] <ubitux> in ffmpeg
[18:45:16 CEST] <Daemon404> wm4 / nevcairiel - can we hunker down then?
[18:45:32 CEST] <Daemon404> i really am not capable of figuring out one or three of some stuff
[18:45:41 CEST] <nevcairiel> i dont see how the number of commits makes any difference
[18:45:55 CEST] <nevcairiel> 30 of those are cleanup of svq3, etc
[18:46:08 CEST] <Daemon404> sure
[18:46:13 CEST] <Daemon404> but i still would lik to get tep2 done
[18:46:18 CEST] <Daemon404> it haunts me
[18:46:30 CEST] <nevcairiel> like I said the other day, libav prepared for this over months, dont expect to get it done quickly
[18:46:41 CEST] <Daemon404> there's a difference bteween not doing it quickly
[18:46:43 CEST] <Daemon404> and nothing for weeks
[18:50:25 CEST] <Daemon404> booting my dev vm for ffmpeg, will hack on some stuff
[18:52:10 CEST] <ubitux> st->codecpar->{width,height} are properly set in the demuxer, but aren't in the muxer
[18:52:15 CEST] <ubitux> any idea where that information could be lost?
[18:52:39 CEST] <nevcairiel> it translates to avctx in between, check the translation code, like Daemon404 said, its probably not set for subtitles
[18:52:51 CEST] <nevcairiel> (or copied for that matter)
[18:53:30 CEST] <nevcairiel> its in avcodec/utils.c
[18:53:55 CEST] <ubitux> ah, perfect
[18:53:57 CEST] <ubitux> thanks
[18:54:45 CEST] <nevcairiel> Daemon404: there is a few "simple" open questions, like what happens with has_b_frames, could introduce a new element with a more appropriate name in codecpar that conveys the decode delay information that has_b_frames previously included
[18:55:06 CEST] <Daemon404> i thought we agreed on that
[18:55:15 CEST] <Daemon404> but there's als oa bunch of work unrelated to bframes
[18:55:25 CEST] <nevcairiel> i dont remember anyone agreeing, just people throwing around ideas
[18:55:35 CEST] <Daemon404> im perfectly fine with some sort of delay entry
[18:55:41 CEST] <Daemon404> i thought wm4 was too
[18:56:03 CEST] <nevcairiel> fiel will  probably be annoying
[18:56:18 CEST] <Daemon404> i know
[18:56:26 CEST] <nevcairiel> could add some ugly hack to check avctx
[18:56:32 CEST] <nevcairiel> under deprecation guards
[18:56:41 CEST] <Daemon404> because we change stream-level stuff after alreadfy muxing some packets, if i understand?
[18:56:47 CEST] <nevcairiel> yes
[18:56:56 CEST] <nevcairiel> which kind-of works for mov since it writes headers at the end
[18:56:59 CEST] <Daemon404> we could queue some packets after reading some in ffmpeg.c
[18:57:03 CEST] <Daemon404> and then set it
[18:57:06 CEST] <Daemon404> and then write the header
[18:57:18 CEST] <nevcairiel> any changes to ffmpeg.c would be bad
[18:57:22 CEST] <nevcairiel> breaks api still for anyone else
[18:57:34 CEST] <Daemon404> that's only true if the api was actually validand documented
[18:58:18 CEST] <nevcairiel> you could also just ignore it then, as it fixes itself when ffmpeg.c siwtches to codecpar
[18:58:35 CEST] <Daemon404> does it?
[18:58:39 CEST] <nevcairiel> of course
[18:58:56 CEST] <Daemon404> i did switch field_order to codecpar (you had me revert it), but i didnt fix it
[18:58:58 CEST] <nevcairiel> the problem only exists because the compat code that generates codecpar is only run once
[18:59:06 CEST] <Daemon404> right
[18:59:10 CEST] <ubitux> is it ok to copy sar in addition to width/height for subtitles?
[18:59:28 CEST] <wm4> never seen sar applied to subtitles
[18:59:34 CEST] <Daemon404> ubitux, if it's in codecpar, i dont see why it would be wrong.
[18:59:35 CEST] <wm4> (although the _video_ sar might matter)
[18:59:37 CEST] <Daemon404> but yeah what wm4 said
[18:59:40 CEST] <nevcairiel> Daemon404: thats because https://github.com/dwbuiten/FFmpeg/commit/435bc7ff51c9bba5bd475486ab8c45417b38e7d8 was wrong in many ways. ;)
[18:59:58 CEST] <Daemon404> it's reverted ;)
[19:00:02 CEST] <nevcairiel> i know
[19:00:08 CEST] <nevcairiel> but it didnt fix anything because you switched it only half
[19:00:09 CEST] <Daemon404> this is also why i said i need help
[19:00:28 CEST] <Daemon404> for now, ill ignore fiel then
[19:00:34 CEST] <ubitux> even for bitmaps?
[19:00:37 CEST] <nevcairiel> would be nice to get those fails out of the list
[19:00:40 CEST] <Daemon404> true
[19:00:49 CEST] <Daemon404> but i am not qualified to fix ffmpeg.c
[19:00:54 CEST] <Daemon404> as you have shown.
[19:01:01 CEST] <ubitux> anyway, i fixed binsub-movtextenc, thanks for the hints
[19:01:30 CEST] <Daemon404> ill take a look at the ogg one
[19:01:33 CEST] <Daemon404> which i am sure ill regret
[19:01:34 CEST] <nevcairiel> maybe it would be best to just add some magic code movenc to re-read fiel from the deprecated avctx before writing headers
[19:01:35 CEST] <Daemon404> because ogg
[19:02:01 CEST] <nevcairiel> slightly ugly but preserves behavior
[19:02:04 CEST] <Daemon404> nevcairiel, under deprecation guards?
[19:02:07 CEST] <nevcairiel> of course
[19:02:15 CEST] <Daemon404> i am not opposed
[19:02:22 CEST] <Daemon404> since it is then deprecated properly
[19:02:24 CEST] <nevcairiel> anyway dinner time
[19:02:31 CEST] <nevcairiel> i might have time to work on things tomorrow
[19:02:34 CEST] <Daemon404> ok
[19:02:36 CEST] <nevcairiel> nto tonight  tho
[19:02:39 CEST] <Daemon404> i have time all week.
[19:02:48 CEST] <Daemon404> i can dedicate some work time to it.
[19:03:30 CEST] <Daemon404> i will add movenc.c stuff today then
[19:03:48 CEST] <Daemon404> then most of the failures left will be odd one-offs
[19:03:49 CEST] <Daemon404> i think.
[19:04:46 CEST] <ubitux> oh it fixed sub2video too
[19:04:53 CEST] <Daemon404> :)
[19:06:08 CEST] <Daemon404> ubitux, btw do you mind helping out with merges once tep2 is in, to get caught up
[19:06:15 CEST] <Daemon404> a good chunk of them will just be monkey work
[19:06:17 CEST] <ubitux> yes
[19:06:38 CEST] <Daemon404> there's a few important ones
[19:06:44 CEST] <Daemon404> hwaccel stuff
[19:06:45 CEST] <ubitux> i'm in holiday tomorrow and the day after
[19:06:54 CEST] <ubitux> but i suppose codecpar won't be in?
[19:06:56 CEST] <ubitux> :(
[19:07:17 CEST] <Daemon404> probably not, but if we can make fate pass, maybe nevcairiel will get motivated again
[19:07:20 CEST] Action: Daemon404 runs
[19:07:51 CEST] <ubitux> wm4: can you check if the ccaption patch (only) is breaking something for you?
[19:07:58 CEST] <wm4> btw. one thing I noticed about fate is that not all it testes and expects is actually sane
[19:08:12 CEST] <wm4> ubitux: git branch?
[19:08:14 CEST] <ubitux> for the legacy rescaling i might just make a fallback to pkt timebase if avctx tb isn't set
[19:08:19 CEST] <Daemon404> wm4, yes thats why i updated several tests
[19:08:24 CEST] <ubitux> wm4: will push somewhere, just a moment
[19:08:25 CEST] <Daemon404> the reslt after codecpar was *more* correct
[19:10:06 CEST] <ubitux> wm4: https://github.com/ubitux/FFmpeg/compare/ccaption-tb
[19:17:06 CEST] <ubitux> keeping our HEAD chunks from fate-wtv-demux test makes fate pass here 
[19:17:11 CEST] <ubitux> so i'll commit that
[19:17:15 CEST] <wm4> ubitux: still seems to work
[19:17:36 CEST] <Daemon404> ubitux, HEAD chunks?
[19:17:59 CEST] <Daemon404> merge conflict in the fate test?
[19:18:03 CEST] <ubitux> http://sprunge.us/iXfe
[19:18:10 CEST] <Daemon404> ok
[19:18:14 CEST] <Daemon404> if HEAD is fine, it's not a problem
[19:18:51 CEST] <ubitux> wm4: cool; i'm going to pick the 2nd commit and ask you to try if it breaks; if it does i'll try to amend something and ask for a test again
[19:18:53 CEST] <ubitux> if you don't mind
[19:19:23 CEST] <Daemon404> nevcairiel / wm4 / ubitux - btw, i am assumign we will just noop all the 10ish+ commits after the TEP2 commit in libav which are switching e.g. avconv to codecpar
[19:19:27 CEST] <Daemon404> since well do that
[19:19:48 CEST] <ubitux> ?
[19:19:56 CEST] <Daemon404> avconv: convert to codecpar
[19:19:59 CEST] <Daemon404> commits like that
[19:20:08 CEST] <Daemon404> not useful to us, sinde we'll have to fix it ourselves
[19:20:09 CEST] <wm4> I don't think they'd apply anyway
[19:20:14 CEST] <Daemon404> exaxtly
[19:21:13 CEST] <ubitux> you don't want to fix ffmpeg.c in the avconv.c merge?
[19:21:37 CEST] <Daemon404> ubitux, im fine with fixing it in a spearate merge
[19:21:44 CEST] <Daemon404> but im saying i can noop the libav ones.
[19:21:55 CEST] <Daemon404> because it wont even been close to a clean merge
[19:22:03 CEST] <ubitux> sounds weird not to do it in the merge commit
[19:22:08 CEST] <ubitux> wm4: can you try https://github.com/ubitux/FFmpeg/compare/sub-time-base ?
[19:22:11 CEST] <Daemon404> maybe
[19:22:26 CEST] <Daemon404> ubitux, we can still push the lavf commit/merge first
[19:22:32 CEST] <Daemon404> it helps us make the branch less... hge
[19:22:33 CEST] <Daemon404> huge
[19:22:36 CEST] <ubitux> yes ofc
[19:22:50 CEST] <ubitux> btw, you'll have to squash everything before doing a rebase or a re-merge
[19:23:01 CEST] <ubitux> (because i cherry-picked stuff from master)
[19:24:10 CEST] <Daemon404> im going to make a new branch based off HEAD and cherrypick/squash stuff
[19:24:16 CEST] <Daemon404> once it builds/works
[19:24:30 CEST] <Daemon404> probably a 1-3 hrs work
[19:25:45 CEST] <wm4> ubitux: cc_dec: packet time base not set
[19:26:01 CEST] <wm4> ubitux: same for any other text subtitle format
[19:26:16 CEST] <ubitux> but it worked with the commit in cc?
[19:26:18 CEST] <ubitux> strange
[19:26:30 CEST] <ubitux> but OK, let me try something then
[19:31:19 CEST] <ubitux> wm4: can you pull & retry?
[19:31:34 CEST] <ubitux> it will prefer pkt_timebase over avctx->time_base though
[19:31:59 CEST] <ubitux> (if set)
[19:32:17 CEST] <wm4> ubitux: appears to work
[19:32:21 CEST] <ubitux> ok
[19:32:29 CEST] <ubitux> do you think i should test for avctx->time_base instead?
[19:32:58 CEST] <wm4> don't know, some other API user might have set both to different values?
[19:33:08 CEST] <wm4> this was never a well-defined API
[19:33:16 CEST] <ubitux> you think other people managed to make subtitles work?
[19:33:18 CEST] <ubitux> @_@
[19:39:26 CEST] <Daemon404> nevcairiel, fiel stuff is all passing now.
[19:40:14 CEST] <Daemon404> i think all of vsynth* works now
[19:40:15 CEST] <Daemon404> running it.
[19:40:42 CEST] <kierank> Prores spec is out
[19:40:53 CEST] <Daemon404> spec or "spec"
[19:42:55 CEST] <ubitux> timestamps are now set in fate-mxf-demux, should we just keep that change?
[19:43:13 CEST] <Daemon404> i mean, that sounds better to me
[19:43:29 CEST] <Daemon404> also: yes, all of the vsynth tests pass
[19:43:30 CEST] <Daemon404> \o/
[19:44:30 CEST] <ubitux> http://sprunge.us/XZFK basically this (after keeping our local chunks)
[19:44:57 CEST] <Daemon404> that looks more correct me
[19:45:18 CEST] <ubitux> the reason it mismatch with libav change is because we have F=0x0 in the output
[19:45:20 CEST] <ubitux> afaict
[19:45:25 CEST] <Daemon404> ah
[19:45:28 CEST] <Daemon404> yeah, ship it,
[19:47:37 CEST] <ubitux> done
[19:48:51 CEST] <ubitux> exact same thing with fate-nc-demux
[19:49:11 CEST] <ubitux> http://ubitux.fr/pub/pics/fate-nc-colordiff.png
[19:49:16 CEST] <ubitux> so going to ship it as well
[19:52:12 CEST] <wm4> huh why does the diff not render this minimally
[19:52:17 CEST] <Daemon404> ?
[19:52:40 CEST] <wm4> I mean, the CRC is highlighted twice, but it doesn't change
[19:53:26 CEST] <nevcairiel> probably only stops highlights on spaces
[19:53:32 CEST] <nevcairiel> and this adds a , after the crc
[19:54:09 CEST] <ubitux> same for fate-lmlm4-demux, pushed
[20:01:38 CEST] <Daemon404> fate-movenc fixed
[20:01:42 CEST] <Daemon404> it was all expected changes
[20:02:01 CEST] <Daemon404> nevcairiel / wm4 - what is concat in the fate list?
[20:02:04 CEST] <Daemon404> i dont see a concat test
[20:02:56 CEST] <nevcairiel> there is various concat tests
[20:03:36 CEST] <nevcairiel> concat-demuxer-extended-lavf-mxf etc
[20:04:30 CEST] <Daemon404> hmm ok
[20:04:51 CEST] <Daemon404> ubitux,     ffprobe_*- just codec_time_base differs
[20:04:56 CEST] <Daemon404> i wasnt sure what to do about this
[20:11:33 CEST] <omerjerk> Hi everyone.
[20:12:30 CEST] <omerjerk> So i need to perform Masked LZ Decompression at a place in ALS decoder.
[20:13:02 CEST] <omerjerk> is by any chance this algorithm already present somewhere in the ffmpeg codebase ?
[20:13:23 CEST] <omerjerk> else I'll need to write it myself.
[20:19:14 CEST] <michaelni> ubitux, http://sprunge.us/XZFK <-- the mpeg4 in this is not marked as low_delay so dts==pts at least from codec level would be wrong
[20:23:52 CEST] <Daemon404> michaelni, even if it is intar-only?
[20:23:54 CEST] <Daemon404> intra*
[20:29:40 CEST] <Daemon404> hmm, where are audio timestamps set during demux?
[20:29:45 CEST] <Daemon404> for packets
[20:32:44 CEST] <Daemon404> nevcairiel, the concat failures are the same as the ffprobe ones (concat tests use ffprobe output)
[20:32:55 CEST] <nevcairiel> it seemd more broken before
[20:33:06 CEST] <Daemon404> yeah before i fixed the rest
[20:33:14 CEST] <Daemon404> now it's just codec_time_base beign reported as 0/1
[20:33:27 CEST] <Compn> hmm wasnt there some kind of file analyzer out there
[20:33:27 CEST] <michaelni> Daemon404, intra only doesnt matter the VO type does for non coded low_delay, we arent checking that though currently and assume all VOs can contain B frames
[20:33:35 CEST] <Compn> i thought someone wrote it ... maybe kierank
[20:34:01 CEST] <Daemon404> nevcairiel, any opinion on ffprobe "codec timebase" output?
[20:34:11 CEST] <Compn> theres a couple of forensic mpeg4/h264 file analyzers out there too. they count frame numbers and scan for mpeg frame startcodes etc
[20:34:33 CEST] <Daemon404> let's see.
[20:37:45 CEST] <Daemon404> think i might know what to do
[20:43:15 CEST] <Daemon404> woo fixed
[20:57:28 CEST] <Daemon404> nevcairiel, concat and ffproeb fixed.
[20:57:44 CEST] <Daemon404> i think theres not a ton left to fix for fate now
[20:59:11 CEST] <Daemon404> nevcairiel / ubitux  / wm4 - do you mind if i trim down the etherpad to now have 9000 fied things in it?
[20:59:35 CEST] <nevcairiel> i wanted to trim the todos anyway to only open items
[20:59:40 CEST] <Daemon404> ok
[21:09:09 CEST] <Daemon404> done
[21:24:57 CEST] <cone-135> ffmpeg 03Kirill Gavrilov 07master:f3ec8ac0f422: lavc/mediacodec: fix zero stride for OMX.allwinner.video.decoder.avc
[21:28:13 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:a55c953ef00c: avfilter/af_sofalizer: allow user to setup custom virtual speakers positions
[21:34:18 CEST] <ubitux> Daemon404: sure
[21:35:04 CEST] <ubitux> michaelni: ah...
[21:35:21 CEST] <ubitux> so i should revert these commits?
[21:37:06 CEST] <ubitux> michaelni: so it's actually supposed to be NOPTS?
[21:38:49 CEST] <ubitux> ah you sent a patch
[21:40:03 CEST] <michaelni> my patch improves low_delay (and thus has_b_frames) setting for mpeg4, the values posted where wrong for low_delay=0 / has_b_frames=1
[21:40:35 CEST] <michaelni> my patch is very unlikely to fix whatever problem caused the quoted values
[21:41:12 CEST] <michaelni> it fixes a long standing mistake on the mepg4 header interpretation 
[21:41:47 CEST] <michaelni> mpeg4 header -> low_delay/has_b_frames -----libavformat---> timestamps
[21:41:55 CEST] <Daemon404> nevcairiel, not much left, mostly the stuff you explained to be re: voc and swf. take a look tmr if you have time.
[21:42:00 CEST] Action: Daemon404 forgets exactly what to fix
[21:42:24 CEST] <kierank> BBB: so prores doesn't specify a specific idct
[21:42:27 CEST] <Daemon404> michaelni, i think the idea is to add a delay field into codecpar
[21:42:28 CEST] <kierank> which is very interesting
[21:42:44 CEST] <BBB> is prores defined at all?
[21:43:16 CEST] <michaelni> Daemon404, yes, something with a sane name that does what has_b_frames_ does now is needed
[21:43:21 CEST] <kierank> BBB: yes spec released today
[21:45:25 CEST] <jamrial> great oportunity to clean our duplicate decoders and encoders. whichever ended up being closer to spec shall stay :p
[21:45:37 CEST] <JEEB> woah, spec for prores
[21:45:42 CEST] <JEEB> my head just blew
[22:03:33 CEST] <Daemon404> whyone know which func audip timestamps are generated in for packets?
[22:03:35 CEST] <Daemon404> anyone*
[22:09:55 CEST] <kierank> JEEB: a reference implementation too
[22:11:40 CEST] <JEEB> and just a year or two ago it was all "proprietary stuff only for proper licensors, do not steal"
[22:12:36 CEST] <kierank> it still is
[22:12:45 CEST] <JEEB> :D
[22:12:48 CEST] <kierank> they will threaten you if you implement it
[22:13:11 CEST] <JEEB> sounds like dolby, although I only know that dolby goes against non-licensed payware distributors
[22:13:15 CEST] <Compn> they threatened everyone who was using ffmpeg prores iirc :D
[22:13:28 CEST] <Compn> in a commercial setting that is
[22:20:17 CEST] <Daemon404> ok wm4 / nevcairiel / ubitux - ive done literally all i can do now without help, so please do have a look at a thing or two and hit me up.
[22:20:28 CEST] <Daemon404> etherpad is updated - not much left
[22:28:56 CEST] <wm4> will look tomorrow if I can do anything
[22:29:09 CEST] <Daemon404> ok
[22:47:13 CEST] <durandal_170> all demuxers not present in libav where converted?
[22:57:28 CEST] <BtbN> hm, this CUVID decoder might prove difficult if not impossible. At least without pulling the frames to system memory right in the decoder.
[22:58:10 CEST] <BtbN> The frames need to be mapped/unmapped to cuda surfaces, so the frames would need some kind of custom cleanup
[22:58:31 CEST] <BtbN> And CUVID also only allows a certain number of mapped output frames, which might be only exactly one
[23:00:23 CEST] <ubitux> durandal_170: git grep -- '->codec[^p_]' libavformat still has a few match
[23:01:27 CEST] <ubitux> chromaprint, electronicarts, ffm{dec,enc}, libnut, microdvdenc, mov*, mux, nut{dec,enc}, oggdec, sdp, and utils
[23:05:25 CEST] <BBB> this sucks so much
[23:05:34 CEST] <BBB> Im trying to do some colorspace conversion tests
[23:05:49 CEST] <BBB> and I have no content which is actually marked for anything else than colorspace unknown trc unknown and primaries unknown
[23:06:04 CEST] <BBB> why does software suck so much?
[23:06:25 CEST] <kierank> BBB: parkjoy sources i think are done correctly
[23:07:08 CEST] <kierank> kinda big though
[23:07:08 CEST] <BBB> is there a x264-encoded source somewhere?
[23:07:14 CEST] <BBB> like, I only need a few frames
[23:07:32 CEST] <Shiz> go to nyaa, pick literally anything
[23:08:11 CEST] <BBB> nyaa?
[23:09:00 CEST] <ubitux> nyaa.eu
[23:09:09 CEST] <ubitux> or .se
[23:09:17 CEST] <JEEB> lemme see if my bt.709=>bt.2020 thing had colorimetry info
[23:09:24 CEST] <BBB> pff...
[23:09:39 CEST] <BBB> I need something sfw
[23:09:50 CEST] <BBB> and illegal torrents that are not porn are not sfw just because they are not porn
[23:10:08 CEST] <ubitux> i can check my samples
[23:10:12 CEST] <ubitux> is that info exported by ffprobe?
[23:10:23 CEST] <JEEB> and ffmpeg as well IIRC
[23:10:25 CEST] <BBB> should be in the frame, yes
[23:10:45 CEST] <ubitux> what field?
[23:10:49 CEST] <JEEB> ok, so I have my Japanese rugby sample
[23:11:01 CEST] <JEEB> it's MPEG-TS so you can grab the first N megabytes of it
[23:11:40 CEST] <BBB> that would be wonderful
[23:11:45 CEST] <ubitux> - ffprobe -v error -of flat -show_entries stream=color_space,color_range ~/samples/big_buck_bunny_1080p_h264.mov       
[23:11:47 CEST] <ethe> JEEB: I have a raw of the Japan Vs South Africa game lying about somewhere
[23:11:47 CEST] <ubitux> streams.stream.0.color_range="tv"
[23:11:49 CEST] <ubitux> streams.stream.0.color_space="bt709"
[23:11:51 CEST] <ubitux> so stuff like this?
[23:11:53 CEST] <BBB> yes
[23:11:56 CEST] <JEEB> https://kuroko.fushizen.eu/samples/Japanese_Rugby_Game-4K_Channel.ts
[23:12:00 CEST] <JEEB> this is BT.2020
[23:12:31 CEST] <BBB> holy shit that is big
[23:12:39 CEST] <BBB> how much do I need?
[23:12:41 CEST] <ubitux> BBB: http://b.pkh.me/classics-in-lego-26.jpg
[23:12:42 CEST] <ubitux> bt470bg
[23:12:59 CEST] <Shiz> nice prompt
[23:13:16 CEST] <ubitux> it's a red   on error :X
[23:13:17 CEST] <JEEB> BBB: it's MPEG-TS so a dozen megabytes or so should be OK even with that bit rate
[23:13:24 CEST] <BBB> [hevc @ 0x7ff931833000] SPS 0 does not exist
[23:13:26 CEST] <BBB> ...
[23:13:31 CEST] <JEEB> https://kuroko.fushizen.eu/samples/bt2020_to_bt709.mp4
[23:13:37 CEST] <JEEB> downscaled and bt.709
[23:13:58 CEST] <JEEB> BBB: well yeah it was not cut exactly on an IRAP
[23:14:13 CEST] <BBB> ah cool that works
[23:14:16 CEST] <BBB> ty
[23:14:27 CEST] <ubitux> streams.stream.1.color_space="smpte170m"
[23:14:30 CEST] <ubitux> do you want this one?
[23:14:52 CEST] <ubitux> http://b.pkh.me/PSDOP.mp4
[23:15:11 CEST] <BBB> JEEB: can you downscale the 4k one to lower resolution and cut the first few seconds out? Id love a bt2020 sample also
[23:15:25 CEST] <BBB> ubitux: ty, downloading also
[23:15:37 CEST] <BBB> now I need to figure out how lavfi works again
[23:15:56 CEST] <ubitux> so what do you have now, bt709, bt470bg, smpte170m?
[23:16:45 CEST] <BBB> just smpte170m and bt709
[23:17:03 CEST] <ubitux> you have bt470bg with the jpg
[23:17:21 CEST] <BBB> oh right
[23:18:32 CEST] <BBB> so I guess I need bt2020 and smpte240m then
[23:18:36 CEST] <BBB> that should be about it
[23:18:43 CEST] <ubitux> look for some
[23:23:49 CEST] <ubitux> BBB: did you check fate samples?
[23:27:58 CEST] <BBB> not yet, no
[23:28:05 CEST] <BBB> I checked a handful of h264 conformance samples
[23:28:10 CEST] <BBB> and theyre all unknown afaics
[23:28:21 CEST] <ubitux> can't find anything matching bt2020|smpte428|smpte240m|bt470m|film
[23:28:25 CEST] <ubitux> (so far)
[23:29:02 CEST] <ubitux> oh there is one with fcc in fate
[23:31:33 CEST] <ubitux> BBB: fate-samples/ea-mpc/THX_logo.mpc
[23:31:36 CEST] <ubitux> for fcc
[23:31:47 CEST] <BBB> cool! ty
[23:32:30 CEST] <BBB> so can anyone explain to me how format negotiation works in lavfi?
[23:32:38 CEST] <cone-135> ffmpeg 03Lou Logan 07master:cd76eb8f4adb: lavd/dshow_crossbar: remove trailing whitespace
[23:32:38 CEST] <ubitux> yes
[23:32:40 CEST] <ubitux> magically
[23:32:43 CEST] <BBB> lets say Im writing a filter that changes colorspace from bt2020 to bt709 or so
[23:33:03 CEST] <BBB> Im assuming the frame->color_primaries etc. fields are writable by me in the output frame, right?
[23:33:14 CEST] <BBB> where output frame is the thing received from ff_get_video_buffer
[23:33:22 CEST] <BBB> so, how do I set format?
[23:33:33 CEST] <durandal_170> Yes
[23:33:41 CEST] <BBB> lets say my filter is bitdepth-agnostic, and my input frame is yuv420p& how do I set the output to yuv420p12?
[23:33:56 CEST] <BBB> (assuming I have some property bitdepth in my filter)
[23:34:07 CEST] <durandal_170> query_formats
[23:34:08 CEST] <BBB> (which maps to the variable s->bit_depth)
[23:34:15 CEST] <BBB> what does query_formats do?
[23:34:59 CEST] <ubitux> it specifies which pixel format you support as input and output
[23:35:11 CEST] <BBB> but what if I dont care what the input is?
[23:35:25 CEST] <ubitux> then you only set the output one
[23:35:36 CEST] <BBB> like, I want to say input can be yuv420p10, 12 or 8, but output is yuv420p10 because the user said so
[23:35:40 CEST] <BBB> oh
[23:35:51 CEST] <BBB> how do I do that?
[23:35:59 CEST] <ubitux> but then it means you're suppose to support any pixel format, right?
[23:36:03 CEST] <BtbN> well, you most likely still want to define a range of supported input formats? Otherwise RGB and stuff would also be valid
[23:36:32 CEST] <BBB> right, so the input will be a list like various filters have
[23:36:35 CEST] <BBB> and the output will be 1
[23:37:38 CEST] <BBB> I see ff_set_common_formats
[23:37:44 CEST] <BBB> does that set it on input and output?
[23:38:23 CEST] <ubitux> yes
[23:38:31 CEST] <durandal_170> yes
[23:39:51 CEST] <durandal_170> see zscale/scale filters
[23:45:43 CEST] <ubitux> BBB: if you have a db of samples, you can try find samples -type f -exec ffprobe -v 0 -of flat -show_entries stream=color_space,color_primaries {} \; -print > colorspace.log
[23:45:48 CEST] <ubitux> and grep stuff in that
[23:45:49 CEST] <cone-135> ffmpeg 03Marton Balint 07master:99f2a59c2f29: avcodec/utils: fix packet duration of frames with discarded paddings
[23:46:03 CEST] <ubitux> i'm running this on my stuff, will see if sth comes up
[23:47:42 CEST] <ubitux> i should write a script create a sqlite db based on ffprobe output
[23:47:56 CEST] <ubitux> so we can do fun queries to find particular type of samples
[23:49:35 CEST] <BBB> ok the filter format setting works now, nice
[23:57:00 CEST] <dinux5> what to do to remove doxy and non doxy comment error message in patcheck ?
[00:00:00 CEST] --- Tue Mar 29 2016