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

[burek]

[00:00:46 CET] <BtbN> With the static side data type system, if it makes sense for a type of side data to appear multiple times, why not store that list or whatever it is in the structure of that type?
[00:02:30 CET] <JEEB> ah yes, found the random repo I had been linked to
[00:02:31 CET] <JEEB> https://github.com/jpoet/ffmpeg/commit/202d7c30e7173ba407f14b5b7d9f32154ce229fb
[00:02:45 CET] <JEEB> > av_frame_get_side_data_at
[00:02:56 CET] <JEEB> so not exactly iteration
[00:03:23 CET] <JEEB> and yes, now that I read this
[00:03:34 CET] <JEEB> this is just sticking N things of the same type in there :)
[00:04:25 CET] <BBB> right, thats how I did it also I think
[00:04:27 CET] <jamrial> BBB: 20%? Nice
[00:04:46 CET] <BBB> yeah 20%, and lately its been 20% against x265 veryslow also
[00:04:51 CET] <BBB> but thats because they changed their presets
[00:04:58 CET] <BBB> as you also probably saw in the MSU comparisons
[00:05:07 CET] <jamrial> no, i haven't
[00:05:09 CET] <BBB> oh
[00:05:15 CET] <JEEB> but yea, I think I'd rather have you be able to get if a type of side data is around, and then being able to iterate within them
[00:05:20 CET] <BBB> the quality diff between placebo abd veryslow is a lot bigger than it used to b
[00:05:51 CET] <JEEB> but yea, I can see the usefulness of such things
[00:05:54 CET] <BBB> JEEB: you mean not O(N^2) right?
[00:06:01 CET] <JEEB> yes
[00:06:10 CET] <BBB> thats an implementation thing but I agree on the general principle, yes
[00:06:38 CET] <BBB> reminds me of the O(n^2) vs. O(n) in codec registration
[00:06:53 CET] <BBB> its cute, but I wonder if theres a real runtime advantage to it for 99.99999999999999999999% of our users
[00:06:58 CET] <BBB> oops I ran out of floating point precision
[00:07:02 CET] <JEEB> 8)
[00:07:02 CET] <BBB> it turns out its just 100%
[00:08:08 CET] <JEEB> meanwhile I think I'm going to be adding a new side data type for AVPackets because currently the way you have to dance to see program changes is basically to loop through programs each time you have read a packet
[00:08:12 CET] <JEEB> ...which doesn't make sense
[00:08:40 CET] <JEEB> AV_PACKET_DATA_PROGRAM_UPDATE with the identifier of the program in the data
[00:09:03 CET] <JEEB> so you'd know if a program you care about got updated (and program updates don't happen each time a packet is read)
[00:09:10 CET] <BBB> BtbN: you could do that too btw, but in some cases it makes stuff fairly complicated
[00:26:06 CET] <atomnuker> btw is anyone else using git worktrees?
[00:26:34 CET] <atomnuker> its nice not to have dozens of copies of repos
[00:28:03 CET] <jdarnley> Is that a new feature or just an old obscure one?
[00:28:51 CET] <nevcairiel> git worktrees sounds interesting, i just always have m ultiple distinct checkouts =p
[00:30:31 CET] <atomnuker> jdarnley: kinda new, 2015 vintage afaik
[00:31:57 CET] <philipl> How have I not known about this?
[00:32:22 CET] <philipl> I usually work with multiple unrelated changes in one tree and try to avoid pushing the wrong ones :-P
[00:34:23 CET] <wm4> how does this work in practice?
[00:37:05 CET] <cone-775> ffmpeg 03Yusuke Nakamura 07master:3b4026e15110: avpacket: reset dst side_data fields in av_packet_copy_props
[00:37:53 CET] <atomnuker> wm4: its not very smart, you create a repo and you do git worktree add <dir> <branch> and that dir will always be in sync with the original repo's branch and vice versa
[00:38:20 CET] <atomnuker> *create a directory
[00:40:06 CET] <wm4> so the dir contains a full checkout?
[00:43:46 CET] <atomnuker> yep, though it seems to keep the state in the original repo's directory so the dir itself takes less space than a separate cloned repo
[00:44:34 CET] <jamrial> wm4: ok with memset on ffio_init_context?
[00:44:40 CET] <atomnuker> 180megs vs 70megs
[00:47:45 CET] <jamrial> i don't think a context is meant to preserve values to be reused, or that anything in libavformat actually reuses one for that matter
[00:51:23 CET] <wm4> jamrial: yeah
[00:51:53 CET] <wm4> I was just asking whether you considered that case and it seems you did
[00:52:36 CET] <wm4> atomnuker: well if you clone on the same FS, it can use hardlinks to share data, but maybe that's still worse
[00:55:28 CET] <atomnuker> yeah, it doesn't do that though, it'll need to detect accesses and replace the hardlink with a modified copy if it would
[01:00:58 CET] <cone-775> ffmpeg 03James Almer 07master:23e1bf6e5110: avcodec: remove unnecessary calls to ff_init_buffer_info()
[01:00:59 CET] <cone-775> ffmpeg 03James Almer 07master:aa6280805e21: avformat/aviobuf: zero initialize the AVIOContext in ffio_init_context()
[01:06:17 CET] <Zeranoe> Is anyone objected to remove building .lib files for Windows targets? dlltool doesn't create correct libs, and wine+lib.exe is not ideal. Providing the .def export file should be sufficient IMO
[01:06:52 CET] <jamrial> we're not using dlltool anymore, though
[01:07:12 CET] <Zeranoe> jamrial: Guess I read an old commit then.
[01:08:01 CET] <Zeranoe> Whatever is being used isn't producing correct libs
[01:08:19 CET] <rcombs> the switch from dlltool to gcc broke linking against it with gcc for me, it seems
[01:08:30 CET] <rcombs> erm, with MSVC
[01:08:44 CET] <rcombs> it links successfully, but fails to locate the symbols at runtime
[01:08:52 CET] <rcombs> works fine after reverting
[01:08:56 CET] <Zeranoe> rcombs: Seeing the same thing
[01:09:14 CET] <Zeranoe> I think just providing the def's should be fine
[01:09:26 CET] <Zeranoe> Better to do that then provide a broken lib
[01:09:31 CET] <rcombs> (just figured this out a couple days back; figured I'd report after doing some more testing)
[01:09:39 CET] <rcombs> Zeranoe: can MSVC link against just the def?
[01:09:56 CET] <rcombs> or would I have to use dlltool externally
[01:10:18 CET] <Zeranoe> no, but it's trivial to generate them with lib.exe /def:foo.def /out:foo.lib
[01:10:40 CET] <rcombs> we should do that, then
[01:10:44 CET] <JEEB> yup
[01:10:46 CET] <rcombs> or go back to dlltool
[01:10:51 CET] <rcombs> something that works
[01:11:00 CET] <Zeranoe> but using lib.exe breaks cross compiling the libs
[01:11:03 CET] <rcombs> shouldn't be the consumer's job
[01:11:19 CET] <rcombs> and we shouldn't make broken libs
[01:11:30 CET] <rcombs> I think that change came in from libav; I wonder if it broke things there?
[01:12:50 CET] <Zeranoe> Honestly I'm probably going to remove the lib files all together from the Windows builds. Who knows if different versions of MSVC produce different lib files, and I know most people just rebuild from the def to be sure it will work with their MSVC version
[01:13:50 CET] <Zeranoe> All the lib files can be generated from the def files with this: for %i in (*.def) do @for /f "delims=-" %j in ("%i") do @lib /nologo /def:%i /out:%j.lib
[01:16:11 CET] <rcombs> why does MSVC even need them anyway
[01:16:33 CET] <Zeranoe> you mean why can you link the dll directly?
[01:16:40 CET] <Zeranoe> can't*
[01:17:09 CET] Action: JEEB likes it how MSVC can link with .a files as long as you just give the linker the full file name
[01:21:06 CET] <rcombs> yeah why can't it just use the DLL
[01:21:47 CET] <rcombs> can you not tell what symbols are in a DLL by looking at it
[01:22:09 CET] <Zeranoe> no idea, dumpbin has no problem seeing them
[01:23:11 CET] <Zeranoe> I don't even know what the lib file actually contains
[01:27:12 CET] <ddo> hey everyone, i'm sure this has been asked many times before. I keep getting the "ERROR: opus not found using pkg-config" when trying to compile ffmpeg. I'm not really a developer so I'm not sure where my PATH is, i was just following the centos compile guide on ffmpeg
[01:29:45 CET] <rcombs> ddo: see #ffmpeg, but the last few lines of config.log should be informative
[04:36:11 CET] <cone-904> ffmpeg 03Jérôme Martinez 07master:fb580731c1fe: avcodec/ffv1: Support for GBRAP10 and GBRAP12
[08:13:58 CET] <gagandeep__> kierank: in cineform improvements project idea, what is meant by expected results "support reading as many features as possible"
[09:31:37 CET] <gagandeep__> guys, the cineform improvement is a project idea for gsoc. I wanted to know what was meant by // expected results "support reading as many features as possible" // 
[09:35:34 CET] <nevcairiel> You should contact the mentor directly with any questions to those tasks
[09:36:36 CET] <gagandeep__> k, i'll try contacting him again, i was disconnected so i don't know if had replied back then
[09:43:11 CET] <durandal_1707> gagandeep__: he didnt
[09:47:33 CET] <gagandeep__> durandal_1707: Thanks
[09:48:53 CET] <durandal_1707> better ask via email, as you may be in different time zone
[09:49:41 CET] <gagandeep__> k, will do
[11:06:46 CET] <kierank> Oh he's gone :(
[14:06:49 CET] <cone-185> ffmpeg 03Michael Niedermayer 07master:f26a63c4ee1b: avcodec/h264_cabac: Tighten allowed coeff_abs range
[14:06:50 CET] <cone-185> ffmpeg 03Michael Niedermayer 07master:173939259aae: avfilter/avf_avectorscope: Fix ;;
[14:06:51 CET] <cone-185> ffmpeg 03Michael Niedermayer 07master:75027066d8e8: avdevice/decklink_dec: Fix ;;
[14:09:18 CET] <JEEB> rcombs: this is possibly what you wanted with that start_at_zero thing you added before? https://github.com/jeeb/ffmpeg/commit/369a7227b0a433c94182995f3b80f5ff57165e6b
[14:09:27 CET] <JEEB> unless you had some specific logic for requiring copyts
[14:09:49 CET] <JEEB> (copyts kills wrap-around discontinuity handling it seems?)
[14:11:07 CET] <JEEB> although I'm still not exactly sure which discontinuity handling thing at which point in ffmpeg.c is supposed to handle what
[14:11:18 CET] <JEEB> that one point I poked stops the start time from being set to zero
[15:25:32 CET] <Guest2640> Hi... sorry it may be a lame question but I am fairly a newbie at open source. I have cloned the github repo of FFmpeg but I am unable to run it on windows 64 bit. I just typed the command ./configure which was in installation.md file. Am I doing anything wrong?
[15:26:32 CET] <jdarnley> Depends.
[15:26:42 CET] <jdarnley> Are you looking to compile the source code?  Running configure is the first step for that.
[15:26:52 CET] <Guest2640> Yes
[15:27:07 CET] <jdarnley> If you just want to use ffmpeg then you can download a pre-compiled exe for Windows.
[15:27:39 CET] <jdarnley> If configure ran successfully then you run make to actually compile it all.
[15:28:07 CET] <Guest2640> No when I typed ./configure it said command doesnt exist in the cmd
[15:28:12 CET] <jdarnley> Oh
[15:28:17 CET] <Guest2640> I wanted to compile it
[15:28:32 CET] <jdarnley> Well you need a bash shell to be able to run the configure script.
[15:29:02 CET] <Guest2640> Oh sorry my bad. Can I use gitbash itself?
[15:29:08 CET] <jdarnley> So that means cygwin, msys, or maybe some bundle of git has one
[15:29:15 CET] <jdarnley> yes, I think so
[15:29:27 CET] <Guest2640> Thanks a lot
[15:29:59 CET] <cone-185> ffmpeg 03James Almer 07master:8a8d0b319a9f: avutil/crypto: change length parameter to size_t on the remaining modules
[15:32:49 CET] <JEEB> hmm, do I see incorrectly or could the schannel TLS module still be broken with regards EOF handling after zero becoming !EOF?
[15:32:55 CET] <JEEB> since I see some == 0 there
[15:46:08 CET] <nevcairiel> i'm sure there is still tons of bugs because of that nonsense change
[15:49:48 CET] <JEEB> yea, I've seen reports of various modules getting stuck in a loop
[15:49:56 CET] <JEEB> but never got proper debug output
[15:50:07 CET] <JEEB> so I couldn't pin-point if it was FFmpeg or not
[16:35:11 CET] <bogdanc> do you think it's a good idea to try to replace the current cineform decoder with the official gopro's decoder?
[16:36:19 CET] <JEEB> depends on how much the missing pieces are, or if parts of it can be fitted as-is (in case the license is compatible)
[16:36:54 CET] <bogdanc> i'm not even sure what is missing or not
[16:37:02 CET] <bogdanc> i'm trying to fix a distortion 
[16:37:05 CET] <bogdanc> for some time now
[16:37:17 CET] <bogdanc> and all i can achieve is similar distortions
[16:37:30 CET] <bogdanc> also, where could i find some documentation on the current workflow of the decoding process? is there something to read?
[16:39:22 CET] <bogdanc> gopro has an open source decoder for cineform released 
[16:40:08 CET] <JEEB> you define an AVCodec and it has basically pointers towards functions like init/decode etc
[16:40:17 CET] <JEEB> and then you register it in the right places
[16:40:38 CET] <JEEB> so yes, if the API for their decoder is sane, you could make a libavcodec wrapper for it
[16:41:30 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/utvideodec.c;h=c5f553496430da71e6ade3e968208aa9203baa35;hb=HEAD#l1068
[16:41:35 CET] <JEEB> a struct like this
[16:41:52 CET] <JEEB> has some metadata, and then the functions
[16:43:44 CET] <bogdanc> you mean i should follow this coding style as a template for the new decoder, if i'll try to do it?
[16:44:26 CET] <JEEB> well, that structure is a common thing
[16:44:32 CET] <bogdanc> yeah
[16:44:43 CET] <JEEB> it's the data type that defines a decoder
[16:44:47 CET] <JEEB> and then there's one for encoders
[16:45:49 CET] <JEEB> bogdanc: also https://www.ffmpeg.org/developer.html#New-codecs-or-formats-checklist
[16:46:42 CET] <bogdanc> nice. will keep in mind
[16:47:30 CET] <kierank> bogdanc: definitely not worth replacing it
[16:47:38 CET] <kierank> the gopro decoder is not compatible with ffmpeg
[16:47:39 CET] <Nakul> Hi
[16:48:07 CET] <bogdanc> and actually, what i'm really trying to say is that i'm lost, i don't know how to approach this bug (#6675). and if someone could point me in any directions
[16:48:12 CET] <bogdanc> that would be great
[16:48:22 CET] <bogdanc> thanks for the heads up
[16:48:37 CET] <Nakul> Here I am looking for help for getting started into GSoc
[16:49:48 CET] <kierank> bogdanc: did you confirm that the raw yuv file has the line at the bottom
[16:51:39 CET] <bogdanc> https://imgur.com/EQ3Qu7M
[16:51:56 CET] <bogdanc> this is the only thing that confirms me
[16:52:11 CET] <bogdanc> there is something wrong with the last 8 pixels
[16:53:01 CET] <bogdanc> and when i export it as a non-raw format, the media players show something wrong.
[16:53:09 CET] <Guest2640> Nakul: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018    start here.
[16:55:37 CET] <bogdanc> https://imgur.com/gjfPAdc
[16:55:43 CET] <bogdanc> this is what i get on windows media player
[16:55:51 CET] <bogdanc> @kierank
[16:56:23 CET] <kierank> bogdanc: didn't i say try and view it in a raw yuv viewer
[16:56:31 CET] <bogdanc> yes
[16:56:33 CET] <bogdanc> and i did
[16:56:34 CET] <kierank> ok
[16:56:36 CET] <bogdanc> and it shows
[16:56:36 CET] <kierank> good
[16:56:51 CET] <kierank> so then look at the output loops of the functions at the bottom and see if they are broken
[16:57:05 CET] <Nakul> @Guest 2640  I went through the link and read all the info.but I am wondering what is the first thing to do
[16:58:31 CET] <bogdanc> ooh some guidance. very much thank you kierank. can i maybe where are the "output loops of the functions at the bottom" ?
[16:59:07 CET] <kierank> the transform loops through each row
[16:59:27 CET] <Guest2640> Nakul: Good. Just select a project of your choice and discuss it with related mentor. Discuss about your qualification task with the mentor directly. Also start by first building the code on your system first.
[16:59:33 CET] <bogdanc> Nakul, i suggest you choosing a project that seems closer to your knowledge, downloading the source code and trying to find out where does the code goes the wrong way
[16:59:54 CET] <kierank> vert_filter and horiz_filter
[17:00:04 CET] <bogdanc> ahhh, those you mean
[17:00:31 CET] <bogdanc> at first it seemd something wrong with the vertical filter
[17:01:04 CET] <bogdanc> and i tried to modify the code on the "i == last" 
[17:01:13 CET] <Nakul> Thanks a lot@ bogdanc and Guest 2640
[17:01:20 CET] <kierank> the i == last code is likethat
[17:01:25 CET] <kierank> because you can't read out of the frame
[17:01:31 CET] <kierank> but somethings wrong here
[17:01:45 CET] <kierank> bogdanc: the other ticket is easier i think
[17:01:53 CET] <kierank> you just have to apply the transform on every other row
[17:01:56 CET] <bogdanc> that's what i thought too ! that the mistake is here
[17:01:57 CET] <kierank> but look what the gopro code does i guess
[17:02:54 CET] <bogdanc> do you think it's the fault only of the vertical filter?
[17:03:01 CET] <kierank> don't know
[17:03:01 CET] <bogdanc> that's what i assumed at first
[17:03:09 CET] <kierank> need to compare with the (difficult to read) gopro code
[17:03:28 CET] <kierank> if it helps videolan has also posted a bounty for cineform
[17:03:39 CET] <bogdanc> yes, it helps
[17:04:33 CET] <bogdanc> at first i thought it's the vertical filter, because when i modified the "i == last" on the horizontal filter it didn't modify the distortion. only on the vertical filter it seemed to get different forms of distortion
[17:04:50 CET] <bogdanc> and i tried to somehow copy the analogy of "i == first line" 
[17:05:01 CET] <bogdanc> and modify the bits of these formulas 
[17:05:43 CET] <bogdanc> only on the vertical filter. but it's not working. or maybe i haven't found the right formula yet. i'm going to read this videolan's cineform you said
[17:05:49 CET] <kierank> well compare with what gopro does
[17:06:28 CET] <bogdanc> i'll be doing this. thanks
[17:16:40 CET] <rcombs> JEEB: so, I use copyts to mean "don't shift _output_ timestamps to start at zero"
[17:17:24 CET] <rcombs> and also start_at_zero to shift the _input_ timestamps to start at zero
[17:17:38 CET] <rcombs> (input/output meaning before/after seeking)
[18:03:44 CET] <JEEB> rcombs: yea that's the first thing there, the discontinuity "handling" skipper
[18:03:52 CET] <JEEB> it makes ffmpeg.c not shift output timestamps
[18:04:06 CET] <JEEB> because copyts means you lose the other discontinuity handlers as well
[18:04:10 CET] <rcombs> well I don't mean discontinuities, I mean at start
[18:04:19 CET] <rcombs> losing that is a bit annoying, yeah
[18:06:51 CET] <JEEB> but yea, it's funny how the initial timestamp reset nr1 is handled by one of the discontinuity handlers :P
[18:07:08 CET] <JEEB> then if you're using movenc output there's another set of timestamp reset
[18:07:29 CET] <JEEB> in the muxer
[21:16:52 CET] <durandal_1707> might write cineform encoder
[23:32:23 CET] <jamrial> durandal_1707: any reason in particular?
[23:32:29 CET] <jamrial> or just "fun project/challenge"?
[00:00:00 CET] --- Fri Feb 16 2018