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

[burek]

[01:00:16 CEST] <cone-140> ffmpeg 03Michael Niedermayer 07master:987690799dd8: avformat/utils: Update codec_id before using it in the parser init
[01:00:16 CEST] <cone-140> ffmpeg 03Michael Niedermayer 07master:21bffa93a6fc: avformat/movenc: Switch mov_write_uuidprof_tag() to avg_frame_rate
[01:00:16 CEST] <cone-140> ffmpeg 03Michael Niedermayer 07master:ed2112fb36d7: avformat/movenc: Check frame rate in mov_write_uuidprof_tag()
[02:41:49 CEST] <StevenLiu> Hi, Michael here?
[02:42:11 CEST] <michaelni> yes
[02:42:39 CEST] <StevenLiu> about deprecate local_port option, i saw you say it's bit longer
[02:43:52 CEST] <StevenLiu> why do you said that? dose that not duplicate to localport, or have some other effects
[02:47:34 CEST] <StevenLiu> or have some other consideration?
[02:48:18 CEST] <michaelni> it makes sense to deprecate one option but i would leave it supported for a while and not drop its support, that just gives pain to users who used it
[02:48:37 CEST] <michaelni> and would have their scripts or apps broken by its removial
[02:51:48 CEST] <StevenLiu> okay, I just saw there have two option with same function, so i think it's duplicate, and remove one of them by the way :-)
[02:57:36 CEST] <michaelni> its fine to mark one as deprecated and remove from documentation, also fine to remove _eventually_ but it should not be removed on the next bump, people should have time to see its deprecation and have time to update threir stuff at least. 
[03:00:03 CEST] <StevenLiu> mhmm, i saw there have no local_port option documentation, so i choose to deprecated option
[03:00:37 CEST] <cone-140> ffmpeg 03Michael Niedermayer 07master:1bda0ee53055: avutil/hwcontext_vdpau: Fix warning: "GET_CALLBACK" redefined
[03:02:05 CEST] <StevenLiu> grep -r "local_port" doc/,    no document for local_port,
[03:02:51 CEST] <StevenLiu> but grep -r "localport" doc/,    have document for localport and be used by udp protocol.
[03:05:00 CEST] <StevenLiu> or add one doc for local_port?
[11:00:17 CEST] <ubitux> any ml moderator?
[11:35:54 CEST] <Compn> ubitux
[11:36:15 CEST] <ubitux> Compn: is there no mail in queue from unregistered users? (ffmpeg-devel)
[11:36:59 CEST] <ubitux> like, from thursday
[11:37:06 CEST] <Compn> a mips mail
[11:37:24 CEST] <Compn> Size:	2234151 bytes
[11:37:24 CEST] <Compn>  	Reason:	Message body is too big: 2231906 bytes with a limit of 950 KB
[11:38:02 CEST] <ubitux> i know someone who sent 3 mails (compose+2patches) on thursday
[11:38:05 CEST] <Compn> everything else looks like spam, nothing from thursday
[11:38:11 CEST] <ubitux> ok that's strange
[11:38:17 CEST] <Compn> lou reviews mail more than once per day
[11:38:27 CEST] <Compn> so he reviewed it since thursday im guessing
[11:39:14 CEST] <ubitux> he received a mail waiting for approval
[11:39:31 CEST] <ubitux> but nothing since then
[11:39:56 CEST] <Compn> right, resend it
[11:40:38 CEST] <Compn> maybe he clicked on the link 'click here to cancel'
[11:40:42 CEST] <Compn> or whatever it is
[11:41:02 CEST] <ubitux> i doubt that, he would have done that 3 times then
[11:41:14 CEST] <Compn> maybe lou or another ml admin deleted it
[11:41:24 CEST] <ubitux> i'll wait for llogan then i guess
[11:41:37 CEST] <Compn> i dont think we can undelete something
[11:41:45 CEST] <Compn> so if its not in the queue.... its not there
[11:41:47 CEST] <ubitux> yes, but maybe there is an explanation
[11:44:58 CEST] <Compn> what was subject / patch about ?
[11:45:43 CEST] <mateo`> lavf/mov: support gopro firmware udta tag
[11:45:47 CEST] <mateo`> lavf/mov: support gopro hero moments udta tag
[11:45:49 CEST] <mateo`> Compn: ^
[11:46:16 CEST] <Compn> huh weird
[11:46:37 CEST] <ubitux> are we sure validated mails reach the ml?
[11:46:54 CEST] <Compn> which validated ?
[11:47:04 CEST] <ubitux> moderated positively
[11:47:11 CEST] <Compn> if they are in the queue and we approve them, it gets sent to ml, yeah
[11:47:21 CEST] <ubitux> yeah, but does it still work?
[11:47:34 CEST] <Compn> but... if the person has the wrong date, that mail will show up in whatever date the email was sent in.
[11:47:45 CEST] <Compn> so if they have a mail sent in 2020... it gets put in 2020 archive lol
[11:47:57 CEST] <ubitux> sure, but i would get them by mail anyway :)
[11:48:02 CEST] <Compn> is true
[11:48:16 CEST] <Compn> send a mail to ffmpeg-devel from a nonsubscribed mail and i can approve it and we'll see...
[11:49:46 CEST] <ubitux> Compn: done
[11:50:03 CEST] <ubitux> "This is a test"
[11:50:12 CEST] <Compn> Subject:	This is a test, please ignore.
[11:50:35 CEST] <ubitux> yes
[11:51:08 CEST] <Compn> seems to work
[11:51:59 CEST] <ubitux> yep, OK...
[11:54:02 CEST] <Compn> ml admins are usually pretty good about not deleting patches ;)
[11:55:02 CEST] <ubitux> so what do you think happened?
[11:56:29 CEST] <Compn> no idea
[12:00:40 CEST] <ubitux> Compn: he just resent them
[12:00:51 CEST] <ubitux> do you see them now?
[12:01:39 CEST] <Compn> yes
[12:02:18 CEST] <Compn> accepted
[12:03:31 CEST] <Compn> dont ask me where patch 1/2 is , its not there
[12:08:31 CEST] <Compn> i added that guy to auto accept :D
[12:08:44 CEST] <Compn> so if he resends patch 1/2 it should come automatically
[12:09:44 CEST] <Compn> michaelni : there is a 2mb mips email stuck in the -devel queue, what do you want done ? i'll let you figure it out.
[12:10:13 CEST] <Compn> michaelni : [PATCH 3/7] avcodec/mips: loongson optimize mmi load and store operators
[12:10:13 CEST] <ubitux> ... ?
[12:10:18 CEST] <ubitux> what
[12:10:23 CEST] <ubitux> the patch 1/2 disappeared?
[12:10:25 CEST] <ubitux> wth
[12:10:44 CEST] <Compn> ubitux : correct. it either got eaten by mailman before it gets to queue, or maybe gmail?
[12:10:59 CEST] <Compn> or maybe he didnt send it
[12:11:01 CEST] <ubitux> did you see it in moderation?
[12:11:05 CEST] <Compn> no
[12:11:07 CEST] <ubitux> he did
[12:11:09 CEST] <ubitux> i was with him
[12:11:14 CEST] <Compn> only the two mails
[12:11:14 CEST] <Compn> lol
[12:11:21 CEST] <ubitux> it's a straightforward git send email
[12:11:28 CEST] <Compn> dont ask me i just live here
[12:11:39 CEST] <ubitux> that's not serious... :(
[12:11:53 CEST] <ubitux> i mean, now i wonder how many ppl got this issue
[12:12:00 CEST] <Compn> we could check mail logs
[12:12:05 CEST] <ubitux> yeah.
[12:12:09 CEST] <Compn> michaelni could
[12:12:14 CEST] <Compn> im not sure where to look ...
[12:12:27 CEST] <ubitux> srsly i'm going to ask him to send him the patch a third time?
[12:13:11 CEST] <Compn> would be smart
[12:13:39 CEST] <Compn> its 6 am here, i'm sorry if my answers arent professional haha
[12:14:40 CEST] <Compn> and yes i agree this is serious problem, i dont like patches being missing :\
[12:15:17 CEST] <ubitux> no pb, thanks for the help
[12:15:31 CEST] <ubitux> Compn: lol now we see it twice
[12:15:51 CEST] <Compn> only patch 1/2 twice haha
[12:16:07 CEST] <Compn> the mysteries of the internet
[12:16:12 CEST] <ubitux> i made him send 1/2 a second time
[12:16:14 CEST] <Compn> ah
[12:16:23 CEST] <ubitux> with the in-reply-to etc
[12:16:38 CEST] <ubitux> well, whatever
[12:17:03 CEST] <ubitux> thanks
[12:17:13 CEST] <Compn> emails are tricky, they can go fast or they can go slow. because of various spam filters and virus scanners
[12:17:15 CEST] <Compn> no problem
[12:18:12 CEST] <Compn> why we need to switch to encrypted and signed emails... :P
[12:18:20 CEST] <Compn> no more spam, no more snoopin
[13:16:58 CEST] <BtbN> Compn, nah, the ML is just slow again it seems. Happens sometimes. I think it's some DNS thing?
[13:47:22 CEST] <Compn> BtbN : if you can explain how dns makes mails slower, i'd like to hear it :D
[13:52:54 CEST] <BtbN> Compn, same way it makes ssh logins slow
[13:53:20 CEST] <BtbN> The spam-filter does a lookup of the hostname, reverse-lookup of the IP, and some other lookups to validate the sender.
[13:53:34 CEST] <BtbN> And if DNS is broken, it runs into a timeout with every request
[14:22:40 CEST] <Compn> dns could have problems in propagation, but i havent seen this with ffmpeg server
[16:07:07 CEST] <cone-089> ffmpeg 03Steve Lhomme 07master:9b462a0b9df6: avcodec/d3d11va: use the proper slice index
[16:07:07 CEST] <cone-089> ffmpeg 03Zhou Xiaoyong 07master:50eee357eb17: configure: loongson disable mipsfpu and mipsdsp optimizations
[17:02:44 CEST] <BtbN> philipl, my Github master is now in a somewhat presentable state. review and test, specially with libnpp, welcome.
[17:03:10 CEST] <BtbN> My remote nvidia machine is offline, so I can't test-run right now, and not compile libnpp.
[17:07:56 CEST] <philipl> BtbN: nice. I'll poke around with it tonight.
[17:15:12 CEST] <philipl> BtbN: quick first observation: AVCUDADeviceContextInternal never gets allocated. so it blows up in device_init
[18:02:12 CEST] <BtbN> philipl, yes, already realized that.
[18:45:05 CEST] <BtbN> philipl, hm, there's kind of a chicken/egg problem.
[18:45:31 CEST] <BtbN> ctx->free needs to free the cuda context. But uninit, which is called first, needs to unload the function it needs to do so.
[19:29:09 CEST] <kierank> BBB: ping
[19:29:19 CEST] <BBB> pong
[20:13:09 CEST] <BtbN> philipl, fixed
[21:13:25 CEST] <philipl> BtbN: Looks logical. Will check tonight.
[00:00:00 CEST] --- Tue Oct 11 2016