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

[burek]

[00:33:04 CEST] <durandal_1707> will push cri aix
[00:51:31 CEST] <Shiz> ohi
[09:09:52 CEST] <cone-122> ffmpeg 03Paul B Mahol 07master:2d720069a91b: avformat: add aix demuxer
[09:52:03 CEST] <rcombs> Daemon404: nevcairiel: got movenc moved to auto-bsf
[09:52:30 CEST] <rcombs> also, I'm adding an autobsf fflag (on by default) so things like dashenc and segment and movenc-test can turn it off
[09:52:55 CEST] <rcombs> (the actual bsf insertion is harmless, but delaying the header can be problematic)
[09:57:50 CEST] <rcombs> what version should I bump when adding a macro?
[09:58:53 CEST] <rcombs> looks like minor
[10:07:43 CEST] <nevcairiel> rcombs: Daemon404 already had that done, except it failed without such a flag so he moved it back for later
[10:08:06 CEST] Action: rcombs shrugs
[10:21:45 CEST] <rcombs> guh, but dashenc relies on mov_init running during dash_init
[10:22:07 CEST] <rcombs> for time_base reasons
[10:22:44 CEST] <rcombs> might be a good reason to expose an API to init a decoder without writing the header
[10:22:48 CEST] <rcombs> s/decoder/muxer/
[10:22:51 CEST] <rcombs> I'm good at words today
[10:23:31 CEST] <wbs> rcombs: doesn't dashenc already do that, by setting the delay_moov flag?
[10:23:39 CEST] <wbs> so it effectively doesn't write anything to the output during write_header
[10:24:59 CEST] <rcombs> it writes an initialization segment
[10:26:00 CEST] <wbs> yes, but it only does this on the first call to dash_flush
[10:27:31 CEST] <rcombs> oh, does it?
[10:27:34 CEST] <wbs> yes
[10:27:53 CEST] <wbs> in order to be able to write an edit list and all other stuff that requires you to know the first sample
[10:28:27 CEST] <rcombs> well, still has the issue of mov_write_header wanting extradata
[10:29:17 CEST] <rcombs> though it might be harmless for it to be missing at write_header time
[10:29:22 CEST] <wbs> it actually can do that later as well, look for "copy extradata if it exists" in ff_mov_write_packet
[10:29:31 CEST] <rcombs> yeah, just saw that
[10:29:33 CEST] <wbs> although I'm not sure if this strictly is permitted after codecpar any longer
[10:29:37 CEST] <rcombs> not sure how that interacts with codecparyeah
[10:31:46 CEST] <rcombs> hmm, I guess I'll assume it's fine for now and then I can change it later if need be
[10:40:04 CEST] <rcombs> gah, I definitely need that for segment though
[10:40:22 CEST] <rcombs> welp guess I'll do that tomorrow
[11:06:32 CEST] <omerjerk> Hi
[11:06:54 CEST] <omerjerk> What's the IRC handle of Thilo Borgmann ?
[11:07:12 CEST] <omerjerk> I couldn't find it on the GSoC page. 
[11:07:23 CEST] <nevcairiel> dont think he does irc
[11:07:25 CEST] <nevcairiel> best to mail him
[11:07:40 CEST] <omerjerk> ohkay.
[12:56:11 CEST] <durandal_1707> michaelni: whats needs to be done for not accepting proposal, just not mentoring it?
[13:14:40 CEST] <michaelni> if theres no mentor then a proposal cannot be accepted, also you can comment in the gsoc web interface or send a mail to the admins, i dont know why the rateing system gsoc had last year so everyone could rate proposals isnt there anymore
[13:42:18 CEST] <wm4> durandal_1707: can has a/v source filter for A/V sync testing
[13:43:03 CEST] <cone-285> ffmpeg 03Michael Niedermayer 07master:c169062073d7: swscale/utils: Remove unused variable
[13:43:07 CEST] <durandal_1707> wm4: I need more info
[13:44:09 CEST] <wm4> durandal_1707: generate some sort of audio blip that happens at the same time as a flash on the video or something
[13:44:18 CEST] <wm4> there are many test videos out there that do this
[13:44:53 CEST] <wm4> and while those test videos do the job, it'd be nice if it could be done without involving actual decoders, demuxers, and their bugs
[13:45:56 CEST] <wm4> (and sample rate and video FPS should be adjustable if possible)
[14:19:21 CEST] <cone-285> ffmpeg 03F.Sluiter 07master:3a9611d623fe: avfilter: add remap filter
[14:39:00 CEST] <durandal_1707> wm4: what frame size in samples than to pick?
[15:01:59 CEST] <ubitux> http://b.pkh.me/psy.jpg i love when i end up with glitches like this
[15:04:10 CEST] <ubitux> (should be http://b.pkh.me/nopsy.jpg ; i might have messed up a bit)
[15:45:34 CEST] <kierank> durandal_1707: that's the problem
[15:45:38 CEST] <kierank> you can't align the two
[15:55:22 CEST] <durandal_1707> one dont need to
[15:55:42 CEST] <durandal_1707> There are pts
[15:57:14 CEST] <kierank> so in the simple case of ntsc, how many samples do you make your blip when a single frame blips?
[15:57:23 CEST] <kierank> and then extend that complexity to vfr
[15:58:39 CEST] <durandal_1707> Blip starts and end with flashing frame
[15:58:41 CEST] <BBB> ubitux: nice artifact
[15:59:11 CEST] <BBB> ubitux: do you want to give my patch another full round of review? or should I ask others?
[15:59:16 CEST] <BBB> (maybe simd needs someone else to review)
[15:59:58 CEST] <durandal_1707> kierank: duration of frame
[16:00:09 CEST] <kierank> durandal_1707: which has not integer number of audio samples
[16:00:42 CEST] <durandal_1707> rounding?
[16:01:44 CEST] <kierank> then the player has to resample
[16:01:46 CEST] <durandal_1707> I'm still amazed that there's shorten in nistsphere
[16:01:53 CEST] <kierank> or drop/dup audio samples
[16:06:02 CEST] <kierank> BBB: did a bit of cosmetic asm review
[16:07:08 CEST] <BBB> \o/
[16:07:19 CEST] <BBB> wait, I dont see it
[16:07:31 CEST] <BBB> oh there it is
[16:08:10 CEST] <BBB> Ill look into variable sharing between filters, I dont remember exactly where that stands
[16:08:21 CEST] <BBB> (so yes I totally ignored that, my bad)
[16:42:30 CEST] <Daemon404> feelin' pretty good about codecpar
[16:42:40 CEST] <Daemon404> tentatively can merge on sat/sun
[16:43:07 CEST] <Daemon404> (i would have said friday, but i would then have to push the merge and hope on a plane for half a day with no wifi)
[16:49:57 CEST] <wm4> yeah that seems fine
[16:52:00 CEST] <kierank> Gramner: any more optimisations we can make for http://sprunge.us/OjTX?diff
[16:52:09 CEST] <kierank> it's doing planar 8-bit to uyvy422 10-bit
[16:52:43 CEST] <durandal_1707> Upsampling is evil
[16:58:14 CEST] <kierank> durandal_1707: why
[16:58:50 CEST] <durandal_1707> you don't do debanding
[16:59:09 CEST] <kierank> it's meant to be a bitexact conversion though
[17:00:40 CEST] <durandal_1707> It is ugly, 8bit is ugly
[17:01:43 CEST] <kierank> I agree but people send us that
[18:09:36 CEST] <Gramner> kierank: only comments I have is basically the same as the ones I wrote for planar_to_uyvy_10, but those are kind of minor stuff
[18:09:45 CEST] <kierank> ok thanks
[18:20:04 CEST] <BBB> michaelni: why would you add a format more than once, and why would you use atomics for something that could simply use a lock around the whole function since its utterly and clearly not at all performance sensitive in any way whatsoever?
[18:22:11 CEST] <kierank> different threads I guess
[18:29:51 CEST] <michaelni> BBB, as kierank says, different threads
[19:02:37 CEST] <wm4> https://twitter.com/NicolasWeil/status/717728473960333313
[19:02:58 CEST] <kierank> wm4: you read my twitter trolls right?
[19:04:23 CEST] <wm4> no
[19:04:32 CEST] <TD-Linux> kierank, I did, they were quality
[19:07:24 CEST] <JEEB> wm4: oh wow, that IP over broadcast stuff is going to ATSC as well?
[19:07:42 CEST] <JEEB> I read the Japanese spec and went to sniff some paint afterwards to brain bleach it out of my mind
[19:08:41 CEST] <TD-Linux> I have a hard time seeing the FCC accepting this for over the air at least.
[19:23:15 CEST] <BBB> michaelni: of course different threads, dude, you know Im not a 101 n00b - but why use atomics and all this hideous stuff instead of a lock around the function? is this performance critical?
[19:44:58 CEST] <cone-583> ffmpeg 03Mulvya 07master:b7a776aa7bb6: doc/filters: add drawtext example
[20:32:01 CEST] <michaelni> BBB, a lock around t could be used but it would need to be created, its possible wth AVOnce, not sure if that would be simpler, unless i miss some simpler API I was just trying to fix the bug.
[20:32:30 CEST] <BBB> what youre currently creating is one big race
[20:32:49 CEST] <BBB> I really dont think its a good idea to try and support concurrency in any realistic way between multiple threads calling register without locks
[20:32:52 CEST] <BBB> it just doesnt make any sense
[20:33:43 CEST] <Daemon404> context for this?
[20:33:54 CEST] <BBB> patch on ml
[20:34:18 CEST] <michaelni> BBB i wasnt trying to avoid a lock
[20:34:29 CEST] <Daemon404> oh
[20:34:45 CEST] <michaelni> the original code predates AVOnce
[20:35:02 CEST] <BBB> so lets not make it any worse :)
[20:40:57 CEST] <michaelni> do we have a clean &simple API to create a "once" mutex ? or its needed to hack one into existence with AVOnce ?
[20:57:35 CEST] <jamrial> michaelni: you can use static initialization, if that's what you mean
[20:58:22 CEST] <jamrial> static AVOnce once_init = AV_ONCE_INIT;
[20:58:45 CEST] <wm4> we could also extend the windows wrapper to support static initializers
[20:59:06 CEST] <wm4> but it'd probably lower performance (not sure if we can get fast and correct double-checked locking)
[20:59:17 CEST] <jamrial> it already does, for pthread_once at least
[20:59:40 CEST] <michaelni> something like PTHREAD_MUTEX_INITIALIZER would be usefull
[20:59:43 CEST] <wm4> hm or actually that isn't even needed, whether the mutex is statically initialized or not is a constant flag
[21:00:02 CEST] <wm4> the main "problem" is that unloading libavformat as dll would leak memory
[21:00:11 CEST] <wm4> (potentially)
[21:03:18 CEST] <wm4> maybe we could allocate some sort of exit handler to free the mutex...
[21:03:56 CEST] <michaelni> one problem with using new APIs in bugfixes though is that bugfixes cannot be backported
[21:03:59 CEST] <wm4> for now I'd still consider this superior to potential race conditions
[21:04:04 CEST] <wm4> ah hm
[21:05:08 CEST] Action: Daemon404 wonders how one even manages to hit this bug in normal code
[21:06:02 CEST] <michaelni> i hit it with my eyes when reviewing a pull request fro github ...  i agree that its pretty hard to hit that in actual code
[21:07:52 CEST] <jamrial> wm4: did you ever get around to use pthread_once to fix the race in crc table generation?
[21:10:27 CEST] <wm4> ah, no
[21:10:32 CEST] <wm4> that should be done
[21:25:49 CEST] <Daemon404> michaelni, what are your thoughts on merging on saturday
[21:37:37 CEST] <michaelni> I suspect waiting longer would not improve the commit much
[21:38:06 CEST] <Daemon404> i agree
[21:39:06 CEST] <Daemon404> so saturday it is.
[21:39:43 CEST] <wm4> looking at the commit message for the avconv codecpar update: "    The switch is not yet complete because the parsers and the bistream  filters do not have a new AVCodecParam-based API yet."
[21:39:44 CEST] <wm4> hurr
[21:40:01 CEST] <wm4> also adds FIXMEs to the code
[21:41:38 CEST] <Daemon404> wm4, my idea was to noop that commit and wait until the bitstream filters were merged
[21:41:43 CEST] <Daemon404> and then convert ffmpeg.c
[21:42:11 CEST] <wm4> might be a good idea
[21:42:21 CEST] <wm4> I don't think converting ffmpeg.c should be done as merge anyway
[21:42:30 CEST] <wm4> (not sure how this was handled in the pasT?)
[22:58:19 CEST] <cone-583> ffmpeg 03Paul B Mahol 07master:0c9490609d88: avformat: support shorten in nistshpere demuxer
[00:00:00 CEST] --- Fri Apr  8 2016