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

burek burek021 at gmail.com
Wed Nov 25 02:05:03 CET 2015


[02:19:41 CET] <cone-240> ffmpeg 03Carl Eugen Hoyos 07master:66378f70ab77: lavf/rawenc: Recognize more extensions to encode raw hevc.
[03:20:32 CET] <cone-240> ffmpeg 03Michael Niedermayer 07master:e4bfc726cd9c: avfilter/vsrc_mandelbrot: Fix speed regression
[03:36:00 CET] <cone-240> ffmpeg 03Timothy Gu 07master:7c91b3021c7a: imgutils: Use designated initializers for AVClass
[03:36:01 CET] <cone-240> ffmpeg 03Timothy Gu 07master:e1a214cadf92: avformat/rawvideodec: Rework packet size calculation
[03:36:02 CET] <cone-240> ffmpeg 03Timothy Gu 07master:12a419dacb47: avformat/v210: Check width and height
[03:47:28 CET] <Timothy_1u> Seems like my Haiku FATE station died...
[03:47:34 CET] <Timothy_1u> some weird disk issue
[08:43:32 CET] <ubitux> michaelni: yeah it doesn't happen all the time it seems; i'm wondering if it's because one of my disk is dying/dead
[08:44:19 CET] <ubitux> i'm waiting for ffbox0 to be handled back so i can move all my stuff from my old box to this new one (less pain than requesting a disk swap)
[10:13:14 CET] <ubitux> https://gcc.gnu.org/gcc-6/changes.html interesting new warnings
[10:55:10 CET] <michaelni> ubitux, iam not sure that finding a 2nd server (we have only ffbox + the bulgarian one atm, the other donator stoped replying) and things being copied/moved/setup will happen quicker than a disk failure
[10:56:27 CET] <michaelni> also i hope you have backups
[11:05:18 CET] <michaelni> ubitux, also IIUC if you have a disk failure on your private box and dont want to ask for a disk swap, you could just get a 3rd server from hetzner, move things over and drop the failig one. I really would not wait on anything involving volunteers doing work quickly
[11:14:43 CET] <BtbN> Hetzner is realy uncomplicated with failed disks.
[11:14:56 CET] <BtbN> Had that happen three times so far, allways was resolved in a matter of minutes.
[11:49:18 CET] <ubitux> michaelni: yeah i have backup for the little that matters
[11:49:35 CET] <ubitux> BtbN: ok. well i disconnected the drive and requested a new one
[11:49:49 CET] <ubitux> my fate instances are down for now, waiting for a disk replacement
[11:50:02 CET] <BtbN> just make sure you have something that listens on acpi shutdown signals
[11:50:11 CET] <BtbN> I forgot that the first time they had to shut my machine down
[11:50:37 CET] <ubitux> i just shut it down myself
[11:50:46 CET] <ubitux> fate instances can wait
[11:56:41 CET] <ubitux> BtbN: wow. 15 minutes
[11:56:44 CET] <ubitux> new drive installed
[11:56:46 CET] <ubitux> :)
[11:57:14 CET] <BtbN> Check smart before you do anything with the disk.
[11:57:23 CET] <BtbN> Unless you paid, you might get an even worse one
[11:59:08 CET] <ubitux> can't be worse than a disconnected one
[11:59:38 CET] <BtbN> It can
[11:59:52 CET] <BtbN> The first time they replaced a disk the new one was so bad that smart was unable to communicate with it anymore
[12:00:16 CET] <BtbN> Not that it wasn't propperly connected. It was just broken
[13:38:04 CET] <BBB> I have to admit, I feel somewhat uncomfortable giving voting rights to some people that are really not involved with ffmpeg development at all
[13:38:11 CET] <BBB> (or ffmpeg at all, for that matter)
[13:39:02 CET] <BBB> people that manage our infrastructure should get voting rights, theres little doubt about that, but people that manage other infrastructure and just happen to stuff a bit of ffmpeg in there also, and thats their only involvement, I have reservations about that
[13:39:16 CET] <BBB> as valuable as it is, that does not make you part of a core voting committee, IMHO
[13:50:00 CET] <TimNich> As someone who probably spends more time keeping an eye on the infrasturcture, with half an eye on developments in the mxf area I would not be offended if that did not qualify me to vote on matter pertaining to project direction. But if  that direction required a change in infrastructre I would at least like the oportunity to put any points I may have.
[13:53:22 CET] <TimNich> If the committee gets to large, it will probably also tend to get bogged down more easily.
[13:53:58 CET] <Compn>  the real question is when did BBB become so paranoid? :P
[13:54:52 CET] <Compn> lot of paranoid people here actually
[13:55:12 CET] <TimNich> Just becasue he's paranoid doesn't mean theyre not out to get him. ;P
[13:55:23 CET] <iive> what is he paranoid about?
[13:55:29 CET] <Compn> shh, you'll ruin our secret plan to vote BBB off the island.
[13:56:29 CET] <Compn> http://www.urbandictionary.com/define.php?term=voted+off+the+island
[14:02:45 CET] <iive> yeh... politics
[14:06:33 CET] <atomnuker> BBB: ugh, gmail f'd up and I ended up replying to your email instead of michael's, disregard it
[14:12:53 CET] <ubitux> o
[14:13:04 CET] <ubitux> i'd wait for the comittee to be needed at least once
[14:13:10 CET] <ubitux> before we had dozens of people
[14:13:31 CET] <ubitux> voting comittee ` developers
[14:14:06 CET] <iive> yeh...
[14:14:16 CET] <iive> what is going on with libav negotiations?
[14:15:28 CET] <ubitux> michaelni: disk is replaced & resynced, system updates done, ccache cache cleared, and i started again the fate instances; tell me if you see the issue happening again in the next hours/days
[14:15:54 CET] <ubitux> iive: what negotiations?
[14:16:13 CET] <iive> for uniting both projects
[14:16:24 CET] <ubitux> no idea
[14:17:40 CET] <iive> i thought that is one of the main reason for forming the committee.
[14:18:01 CET] <ubitux> erg second disk is also dying
[14:21:40 CET] <Compn> iive : ask j-b
[14:26:41 CET] <Daemon404> some of the people on this list contribute less and are around less than me... and IMO, I definitely *do not* deserve a vote, so i'm perplex how some of these people do
[14:26:45 CET] <Daemon404> i havent even heard of some of these names
[14:35:23 CET] Action: Daemon404 pokes j-b re: mfx
[14:42:31 CET] <BBB> iive: nothing, afaik
[14:42:43 CET] <BBB> iive: ask j-b, hes the boss :)
[14:43:23 CET] <BBB> Compn: I dont think Im paranoid, plus dont forget Im only voicing an opinion, we dont need unanimous agreement to include more developers, just a majority
[14:43:34 CET] <BBB> Compn: so if enough people disagree with me, its simple to overrule me
[14:52:38 CET] <cone-989> ffmpeg 03Anton Khirnov 07master:fb8753ada231: qsvenc: factor out common options
[14:52:39 CET] <cone-989> ffmpeg 03Derek Buitenhuis 07master:9c35b8e21954: Merge commit 'fb8753ada23189076bdf903c1c001c0ca8287fae'
[14:55:00 CET] <Daemon404> nevcairiel, ... you need to do the next merge. there are conflcuts in the next commit, with stuff you added in a previous merge, that i do not understand.
[14:55:10 CET] <Daemon404> (866a4174dba066780c7be1ebdaa0152161cdf3e0 being the merge)
[19:14:43 CET] <nevcairiel> Daemon404: will have to wait until next week then, kinda on vacation
[19:20:15 CET] <llogan> is it normal that opusdec shows 48000 as the audio rate for something that was encoded at different rate? ffmpeg -f lavfi -i sine=r=16000:d=1 -c:a libopus 16000.opus && ffmpeg -i 16000.opus
[19:20:20 CET] <kierank> llogan: yes
[19:20:35 CET] <kierank> but iirc it is written somewhere the original sample rate
[19:21:14 CET] <llogan> ham, ok. i thought it was something like that but i was feeling too lazy to read n stuff.
[19:22:02 CET] <llogan> s/ham/hmm/
[19:29:15 CET] <nevcairiel> opus can only encode at 48000 iirc
[19:30:11 CET] <kierank> yeah
[19:31:45 CET] <llogan> the output of ffmpeg -h encoder=libopus confused me.
[19:33:30 CET] <nevcairiel> if you feed it 16k content, maybe it only uses silk in opus and skips the celt, thats why it accepts lower rates
[19:37:09 CET] <kierank> iirc it'll resample internally
[19:50:01 CET] <durandal_1707> can I get fast review?
[19:50:26 CET] <JEEB> 
[19:50:39 CET] Action: JEEB ducks in the corner
[19:54:29 CET] <TD-Linux> opus can encode and decode at some fixed lower rates, the only reason to do so is if your audio hardware also runs at a lower rate to save computation
[22:53:08 CET] <cone-173> ffmpeg 03Michael Niedermayer 07master:4ea4d2f438c9: avcodec/h264_slice: Limit max_contexts when slice_context_count is initialized
[23:56:29 CET] <peloverde> Daemon404: https://www.youtube.com/channel/UCIc_DkRxo9UgUSTvWVNCmpA/videos
[00:00:00 CET] --- Wed Nov 25 2015


More information about the Ffmpeg-devel-irc mailing list