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

[burek]

[00:00:39 CET] <cone-711> ffmpeg 03James Almer 07master:a7a8320c4f17: avcodec/null_bsf: move the reference in the bsf internal buffer
[00:17:39 CET] <BtbN> philipl, it's taking its damn time to analyze now, but that's about to be expected
[00:17:46 CET] <BtbN> New build was submited a while ago now
[00:35:47 CET] <BtbN> People using an issue tracker as a support forum for their broken distro
[00:36:02 CET] <philipl> Such community spirit.
[00:36:37 CET] <BtbN> Well, at least it's not a Pull Request on GitHub
[00:39:02 CET] <philipl> heh
[03:16:05 CET] <atomnuker> FUCK INTEL MESA PEOPLE
[03:16:16 CET] <atomnuker> ignorant bastards
[03:16:31 CET] <atomnuker> "No, don't use this feature from the spec, you can't."
[03:16:43 CET] <atomnuker> "It works fine though, just flag support for it."
[03:16:46 CET] <atomnuker> "No."
[03:16:56 CET] <atomnuker> "The spec allows it."
[03:16:59 CET] <atomnuker> "No."
[03:18:01 CET] <atomnuker> and then goes on by saying oh why don't you use this ugly fucking hack instead of this new thing I DIDN'T KNOW ABOUT DESPITE THE FACT I WROTE A LOT OF THE DRIVER
[03:18:13 CET] <atomnuker> ITS RIGHT THERE IN THE FUCKING SPEC
[10:25:32 CET] <gagandeep> kierank: i was thinking that i should first submit the current interlaced functions that i have added (though not satisfactory output)
[10:25:48 CET] <gagandeep> kierank: and start working on proposal, what do you say?
[10:43:38 CET] <gagandeep> kierank: i have sent the interlaced decoding code that i had currently written to mailing list
[11:25:52 CET] <kierank> gagandeep: honestly the 1080 patch isn't enough to qualify
[11:26:00 CET] <kierank> i would like to see interlaced working if possible
[11:27:33 CET] <gagandeep> k, i have sent the current version of interlaced, will look into it more
[11:51:30 CET] <kierank> if there is internet on the train journey today i can help
[11:59:18 CET] <gagandeep> kierank: sure
[11:59:46 CET] <kierank> gagandeep: can you link me to where haar is used in interlaced
[11:59:50 CET] <kierank> in cfhd
[11:59:56 CET] <kierank> in the sdk
[12:10:57 CET] <gagandeep> line 26068 in Codec/decoder.c
[12:11:33 CET] <gagandeep> that is i think for the yuv422 frame and i have used printf in testcfhd to see that this particular block executes
[12:11:46 CET] <gagandeep> kierank
[12:11:58 CET] <kierank> i'm pretty sure you need to run the transform across alternating lines
[12:15:36 CET] <gagandeep> kierank: ctrl+f the function transforminverseframetorow16u in decoder.c
[12:17:37 CET] <gagandeep> then checkout the line 21986 in the same file
[12:19:06 CET] <gagandeep> kierank: no check line 22004, the last one was not gonna compile due to macro #if
[12:20:12 CET] <gagandeep> the function on this line is in Codec/temporal.c
[12:20:35 CET] <kierank> yeah it's doing some alternate row thing
[12:20:53 CET] <gagandeep> haven't i done the same thing
[12:21:34 CET] <gagandeep> thier strides are a bit different due to size of int used for pixel i think
[12:24:14 CET] <kierank> i think you are mixing up filters
[12:26:30 CET] <kierank> you replace a horizontal filter with a vertical and vice versa
[12:26:49 CET] <kierank> and also change the subbands for some reason
[12:27:12 CET] <gagandeep> subbands were for memory location
[12:27:50 CET] <gagandeep> can't we apply change the order of horizontal and vertical fiters
[12:28:00 CET] <kierank> ?
[12:30:28 CET] <gagandeep> for changing the subbands: what do you think is wrong, for the horizontal filter i am using the correct ones that will be used
[12:32:10 CET] <kierank> I also don't see where Progressive=68 comes from
[12:33:09 CET] <gagandeep> the was written in the comments is cineform sdk, that if the progress is used, the flags should be set i.e, tag 68, and if it is not used tag 68 need not be present
[12:33:58 CET] <kierank> #define SAMPLE_FLAGS_PROGRESSIVE	0x0001
[12:34:12 CET] <kierank> you don't implement it correctly then
[12:38:33 CET] <gagandeep> ahh, you mean bitwise and
[12:38:40 CET] <kierank> Yes the tag is a bitmask
[12:38:46 CET] <kierank> and you need to put it in the enum in numeric order
[12:38:52 CET] <kierank> and define the bitmask 
[12:39:29 CET] <kierank> there are also interlaced flags that do things
[12:40:57 CET] <kierank> https://github.com/gopro/cineform-sdk/blob/bf752dc51510d622ea1131dc04a0a637f601ff2b/Codec/decoder.c#L21277
[12:41:00 CET] <kierank> that looks like what we are doing
[12:41:40 CET] <kierank> two horizontals and a vertical
[12:42:39 CET] <kierank> maybe submit the tag changes on their own
[12:42:49 CET] <kierank> and then output a massage with av_ask_for sample
[12:42:56 CET] <kierank> saying please give us interlaced samples
[12:44:33 CET] <gagandeep> ?
[12:44:52 CET] <gagandeep> yup, this is the function i have pointed you to
[12:48:09 CET] <gagandeep> kierank: apart from the bitmask and interlaced flags, what is your concern regarding the filter i have written
[12:50:31 CET] <gagandeep> regarding the interlaced flags i don't think they must be causing the trouble 
[12:50:46 CET] <gagandeep> for the samples that we have
[12:52:30 CET] <gagandeep> kierank: updateCodecState has all the tag implementation
[12:52:32 CET] <gagandeep> https://github.com/gopro/cineform-sdk/blob/bf752dc51510d622ea1131dc04a0a637f601ff2b/Codec/decoder.c#L23118
[13:01:12 CET] <gagandeep> kierank, any thoughts?
[13:18:05 CET] <kierank> gagandeep: you are breaking compatibility if they decide to add more flags
[13:18:11 CET] <kierank> Just to save one line of code
[13:19:00 CET] <gagandeep> yeah,thanks for reminding me, i will add that, it was just that at that time i was more interested in finding the transform
[13:19:33 CET] <gagandeep> by the way that is the function which testcfhd uses to output our interlaced samples correctly
[13:20:44 CET] <gagandeep> if you want to see the testCFHD in examples for decoding you will need to enable a macro to output decoded ppm files
[13:21:05 CET] <kierank> I think there are errors still in your interlaced implementation
[13:21:16 CET] <kierank> I would read their code again and try and match
[13:21:34 CET] <kierank> But difficult for me to give exact info on my phone
[13:50:23 CET] <gagandeep> kierank: i think there is one more function that executes before the transforminverseframetoyuv
[13:52:37 CET] <gagandeep> kierank:https://github.com/gopro/cineform-sdk/blob/bf752dc51510d622ea1131dc04a0a637f601ff2b/Codec/decoder.c#L13612
[13:59:05 CET] <gagandeep_> kierank: nevermind, that is there i think to fill the buffer by decoding the yuv format to 16bit common which must be used to output in other formats
[14:23:57 CET] <kierank> gagandeep: you need to iterate across rows with the vertical filter
[14:24:13 CET] <kierank> iterate across columns
[14:24:15 CET] <kierank> so width
[14:24:21 CET] <kierank> gagandeep: also i don't see how you do a 2x2 transform then move to the next row
[14:24:30 CET] <kierank> surely you need to move forward two rows
[14:25:17 CET] <kierank> oh seems like you do
[14:27:21 CET] <kierank> might be a filter ordering issue
[14:28:35 CET] <gagandeep> kierank: there is also a dequantization in the horizontal filter used in the function that you are looking
[14:28:41 CET] <gagandeep> in cineform sdk
[14:28:50 CET] <gagandeep> i have not implemented that
[14:29:24 CET] <kierank> shouldn't need that
[14:29:46 CET] <gagandeep> https://github.com/gopro/cineform-sdk/blob/bf752dc51510d622ea1131dc04a0a637f601ff2b/Codec/decoder.c#L21395
[14:30:09 CET] <gagandeep> this filter is using dequantization
[14:30:57 CET] <kierank> they merge the steps
[14:33:26 CET] <kierank> gagandeep: where do you get your high/low index from
[14:34:32 CET] <gagandeep> means?
[14:34:54 CET] <kierank> the subband index
[14:36:27 CET] <gagandeep> from level 2, the subband index 0, is lowlow, index 7 is lowhigh (top right band), index 8 is highlow(bottom left band) and index 9 is highhigh
[14:37:57 CET] <kierank> my complete guess to fix the problem is to leave everything as is for progressive but do the haar transform instead of horiz_filter_clip
[14:38:08 CET] <kierank> because the haar is a kind of horizontal filter
[14:38:16 CET] <kierank> that takes two rows
[14:39:54 CET] <gagandeep> kierank: for a simplified version, the wavelet.c in examples of sdk also does what i have done
[14:40:41 CET] <gagandeep> kierank: also i had tweeted to original coder of cineform and he replied that yes haar is for vertical and horizontal is the usual filter
[14:40:58 CET] <gagandeep> tweet was i think 4 days ago
[14:41:23 CET] <kierank> haar is for vertical?
[14:41:45 CET] <gagandeep> we are using haar for temporal aren't we
[14:42:17 CET] <gagandeep> haar has just simple addition in even field and simple difference in odd field
[14:43:52 CET] <kierank> yes but i think haar takes place of horizontal transform
[14:43:52 CET] <kierank> not vertical
[14:45:02 CET] <kierank> but in your code you change all the verticals to horizontal
[14:45:02 CET] <kierank> and change all the indexes
[14:45:31 CET] <gagandeep> ok, let me try that
[14:47:14 CET] <omerjerk> Any idea which function exactly prints the error - "Update your FFmpeg version to the newest one from Git"
[14:47:32 CET] <omerjerk> "Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented."
[14:47:55 CET] <kierank> omerjerk: av_not_implemented or something like that
[14:48:26 CET] <omerjerk> can't find anything like this in the source
[14:49:07 CET] <JEEB> I think it's an AVERR define which you can err2str
[14:49:13 CET] <JEEB> which leads to that
[14:49:20 CET] <JEEB> it's most definitely in the code
[14:49:55 CET] <kierank> gagandeep: if (chroma_y_shift) height = FFALIGN(height / 8, 2) * 8;
[14:49:58 CET] <kierank> you should put that on a new line
[14:50:03 CET] <kierank> if(blah)
[14:50:06 CET] <kierank> newline
[14:54:43 CET] <JEEB> omerjerk: the actual message is in libavutil/log.c
[14:54:56 CET] <JEEB> `git grep "Update your"`
[14:55:03 CET] <omerjerk> Thanks got it!
[14:55:24 CET] <JEEB> and it seems a whole bunch of decoders call avpriv_request_sample
[14:55:33 CET] <JEEB> which seems to be the way to do it
[14:55:50 CET] <JEEB> and then they return AVERROR_PATCHWELCOME or something
[14:55:57 CET] <gagandeep> kierank: ok
[15:00:01 CET] Action: kierank afk, train internet too slow
[16:19:17 CET] <cone-797> ffmpeg 03James Almer 07master:055f60e87467: cmdutils: remove a superfluous line break
[16:19:17 CET] <cone-797> ffmpeg 03Jun Zhao 07master:edce64c9e98f: lavc/extract_extradata_bsf: support dump options.
[16:19:17 CET] <cone-797> ffmpeg 03James Almer 07master:1410454c8b0b: Partially revert "avcodec/hapqa_extract: remove the AVOption flags
[16:35:24 CET] <cone-797> ffmpeg 03James Almer 07master:ed1a750fd18f: fate: add a dca_core bitstream filter test
[18:03:35 CET] <rcombs> jamrial: I forgot to mention this but the dca_core bsf really should set the output channel layout
[18:04:13 CET] <rcombs> presumably just to input_layout | AV_CH_LAYOUT_5POINT1 (or is it side, I forget)
[18:05:41 CET] <atomnuker> jkqxz: are you going to push the lgtm'd opencl/vaapi patches soon?
[18:08:56 CET] <jamrial> rcombs: poke durandal_1707, he wrote that bsf
[18:09:07 CET] <jamrial> it shouldn't affect the output of the test i committed in any case
[18:09:20 CET] <iive> atomnuker, can i have a link to your mesa bugreport?
[18:09:39 CET] <rcombs> oh yeah
[18:24:35 CET] <cone-797> ffmpeg 03Martin Vignali 07master:32dbee4462a0: fate/hapenc : remove test which use libsnappy
[18:28:06 CET] <nevcairiel> rcombs: technically you can have somethign weird like a 6.1 core with HD bitrate extensions, but not like I have ever seen that
[18:28:29 CET] <nevcairiel> (ie. the core can have extensions in it and HD as well)
[18:28:29 CET] <rcombs> oh yeah, I forgot 6.1 DCA exists
[18:28:49 CET] <rcombs> wait, extensions _in_ the core?
[18:30:30 CET] <nevcairiel> yes, the core supports XCH to make 6.1, and X96 for samplerate extensions
[18:30:50 CET] <nevcairiel> (luckily you cant have XCH in the core and another XCH in the HD part, thats forbidden)
[18:31:48 CET] <nevcairiel> majority of HD streams dont have any core extensions
[18:31:52 CET] <nevcairiel> but its not entirely impossible
[18:33:07 CET] <nevcairiel> (and you're still constrained by the core framesize, it cant grow from the extensions)
[18:38:25 CET] <jamrial> nevcairiel: i have a sample that once filtered by this bsf it becomes dca_es 6.1, yeah
[18:42:24 CET] <durandal_1707> jamrial: is that ok?
[18:43:08 CET] <jamrial> the sample becoming dca_es 6.1 instead of 5.1 core?
[18:45:04 CET] <durandal_1707> yes
[18:47:56 CET] <jamrial> i guess?
[18:48:03 CET] <jamrial> if you look at the decoder, there seems to be a "core" extension sub stream of sorts which this bsf is not parsing
[18:49:13 CET] <jamrial> opening the filtered output using the -core_only 1 decoder option it's then effectively is detected as dca 5.1 core
[18:51:00 CET] <nevcairiel> You cannot really remove core extensions easily
[18:51:42 CET] <nevcairiel> Because you would have to change the core headers and potentially make the frames variable sized
[18:51:50 CET] <nevcairiel> Not sure when one would ever want that
[18:54:06 CET] <jamrial> nevcairiel, durandal_1707: https://0x0.st/saxF.dts if you want to check it
[19:04:29 CET] <cone-797> ffmpeg 03Diego Biurrun 07master:a5e011c8dcbf: configure: Add check_cmd() helper function to simplify some expressions
[19:04:30 CET] <cone-797> ffmpeg 03Diego Biurrun 07master:83fef16b6a8d: configure: Add check_cpp_condition() helper function to simplify some expressions
[19:04:31 CET] <cone-797> ffmpeg 03James Almer 07master:40e32f83c6a2: Merge commit 'a5e011c8dcbf6968cc60f883d33382ba46147e90'
[19:04:32 CET] <cone-797> ffmpeg 03James Almer 07master:222d4b0accaa: Merge commit '83fef16b6a8dbbcbd80d159ba3ebe818dbbb2776'
[20:26:21 CET] <kepstin> hmm, did something get messed up in the configure script? It's trying to enable tls via schannel on my linux box now, which obviously fails to build.
[20:29:35 CET] <Chloe> yep something got broken
[20:30:38 CET] <kepstin> i'm guessing this must have to do with the recent merges that changed a bunch of configure stuff?
[20:31:12 CET] <Chloe> kepstin: probably, trying to figure out what went wrong rn
[20:35:33 CET] <kepstin> I think the issue is that the merge dropped the "|| disable schannel" on the end of the check
[20:36:02 CET] <kepstin> but there might be other stuff in there too, it's a pretty big rewrite of the configure script.
[20:37:13 CET] <Chloe> check_func_headers wont be disabling it anymore
[20:40:15 CET] <kepstin> anyways, restoring the "|| disable schannel" allows me to build ffmpeg again.
[20:41:58 CET] <Chloe> I dont think those helper functions add any value, just make things more complicated. idk
[20:42:11 CET] <Chloe> I mean, check_cmd isnt even used
[20:42:33 CET] <Chloe> jamrial
[20:43:20 CET] <jamrial> let me check
[20:47:56 CET] <jamrial> yeah, the second check is never reached on linux so it's not disabled
[20:54:12 CET] <Chloe> jamrial: I think that you should still use test_cpp_condition when it's in a enabled xxx && list
[20:54:23 CET] <jamrial> yeah, i'll revert this one chunk
[20:54:30 CET] <jamrial> i'm currently testing it
[20:54:36 CET] <Chloe> or maybe when there's more than one condition
[20:54:52 CET] <Chloe> like check_cpp_condition is fine when it's the only thing, but otherwise it's just unclear
[20:55:03 CET] <Chloe> jamrial: nice ty
[20:55:22 CET] <nevcairiel> all other changes in the commit are fine, they are simple conditions
[20:55:31 CET] <jamrial> Chloe: what's the status of the avfilter rotate stuff, btw?
[20:55:49 CET] <Chloe> nevcairiel: yes
[20:56:06 CET] <Chloe> jamrial: I'm working on it right now (that's how I found out configure was broken)
[20:56:57 CET] <cone-797> ffmpeg 03James Almer 07master:c51dbc271720: configure: revert changes to the schannel check
[21:20:59 CET] <cone-797> ffmpeg 03James Almer 07master:86c7d8df95c1: avformat/codec2: don't include avcodec objects
[21:21:35 CET] <jamrial> how did that even get in
[21:24:26 CET] <thardin> strange. I'm fairly sure I tested building with --disable-everything --enable-decoder=libcodec2 etc
[21:26:24 CET] <jamrial> it does work
[21:26:33 CET] <jamrial> but it puts the object in avformat, and as such the avpriv symbols
[21:28:10 CET] <jamrial> i'm surprised nobody caught it during review
[21:29:47 CET] <thardin> wait won't they end up in the same object anyway?
[21:32:53 CET] <thardin> looked a bit ugly with ../ but the result looks like it would be the same? or.. no, separate makefiles
[21:33:28 CET] <thardin> one day I'll fully understand this build system
[21:34:58 CET] <jamrial> any object added to the OBJS-* list in avformat/makefile will end up included in avformat
[21:38:04 CET] <thardin> makes sense
[21:41:20 CET] <Chloe> thardin: 'one day I'll fully understand this build system' nice joke 
[21:45:51 CET] <sheetal> I am interested in collaborating with FFmpeg with gsoc what procedure should 
[21:46:18 CET] <sheetal> I follow to apply and get selected
[21:46:20 CET] <thardin> myeah, ./configure is 7k lines
[21:46:29 CET] <durandal_1707> sheetal: pick project, and contact mentor
[21:46:50 CET] <durandal_1707> sheetal: you need to qualify with qualification task given by your mentor
[21:47:24 CET] <durandal_1707> sheetal: some projects already have qualified students
[21:47:44 CET] <sheetal> what exactly does it mean to pick a project?
[21:48:11 CET] <sheetal> are there already projects availble?
[21:48:16 CET] <durandal_1707> sheetal: how you managed to come here? there is gsoc wiki page of FFmpeg
[21:49:02 CET] <durandal_1707> sheetal: http://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018
[21:51:28 CET] <Chloe> jamrial: seems to not just be schannel
[21:51:40 CET] <durandal_1707> :O
[21:53:24 CET] <durandal_1707> michaelni: why ffmpeg marks even png files as limited range?
[21:53:25 CET] <jamrial> Chloe: what else?
[22:04:31 CET] <Chloe> jamrial: dw, was something else
[22:38:27 CET] <Chloe> Anyone know what the issue with libcaca was?
[22:39:28 CET] <durandal_1707> huh? LOL, that is joke i wrote
[22:41:00 CET] <Chloe> durandal_1707: oh I thought something with the iteration patches broken libcaca
[22:41:03 CET] <Chloe> broke*
[22:43:22 CET] <Chloe> durandal_1707: https://github.com/eintw1ck/ffmpeg could you check the lavfi iteration stuff looks alright? Works for me, passes all of fate.
[22:44:05 CET] <durandal_1707> Chloe: ask michaelni to build it with libcaca enabled
[22:44:39 CET] <durandal_1707> how he menaged to find such stuff at first place I ask myself
[22:45:33 CET] <Chloe> michaelni: could you check the lavfi iteration stuff above? you seem to have a knack for finding very specific bugs
[22:48:37 CET] <durandal_1707> Chloe: what exact branch?
[22:51:33 CET] <Chloe> master
[00:00:00 CET] --- Sun Mar 18 2018