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

[burek]

[00:08:06 CET] <shahriman> Is it possible to set camera parameters using the v4l2 device? From reading the code, it seems to me not possible today. But correct me if I am wrong.
[00:08:28 CET] <shahriman> I am referring to libavdevice/v4l2.c 
[01:57:07 CET] <cone-442> ffmpeg 03Rainer Hochecker 07release/2.4:5e4ec87720a6: avformat/utils: estimate_timings_from_pts - increase retry counter, fixes invalid duration for ts files with hevc codec
[02:06:21 CET] <cone-442> ffmpeg 03Claudio Freire 07n2.4.12:HEAD: AAC encoder: fix OOB access in search_for_pns
[02:10:45 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:e5d771c84dea: avfilter/avf_showfreqs: avoid wasteful pow
[02:10:46 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:82f3d47b4f79: doc/developer: misc minor fixes
[02:35:05 CET] <cone-442> ffmpeg 03Andreas Cadhalpun 07release/2.8:2e54b8c379ba: mjpegdec: consider chroma subsampling in size check
[02:35:06 CET] <cone-442> ffmpeg 03Michael Niedermayer 07release/2.8:4608cc176b34: avutil/mathematics: Fix division by 0
[02:35:07 CET] <cone-442> ffmpeg 03Michael Niedermayer 07release/2.8:a9c721da12e3: avformat/matroskaenc: Check codecdelay before use
[02:35:08 CET] <cone-442> ffmpeg 03Rainer Hochecker 07release/2.8:5e105aca0145: avformat/utils: estimate_timings_from_pts - increase retry counter, fixes invalid duration for ts files with hevc codec
[04:43:30 CET] <Compn> argh\
[04:43:40 CET] <Compn>  my first wild vp9 sample   (from youtube)
[04:43:51 CET] <Compn> old media player doesnt have the codec yet haha
[04:44:24 CET] <J_Darnley> Does your fridge need a software update to play it?
[04:44:44 CET] <Compn> lol
[09:52:59 CET] <cone-185> ffmpeg 03Paul B Mahol 07master:45938f0301a8: avfilter/x86/vf_maskedmerge: move %define out of .nextrow
[10:12:20 CET] <ubitux> shahriman: yes, through avoptions
[10:12:45 CET] <ubitux> ffmpeg -h demuxer=v4l2
[11:45:50 CET] <ubitux> what is the point of ff_mutex_*?
[11:46:02 CET] <ubitux> it seems unused except in lavu/buffer.c
[13:37:19 CET] <nevcairiel> ubitux: you mean the defines for pthread functions? I have no clue why they were needed .. I suppose you can use them without worrying that threading may not be available, since they just eval to empty them
[13:54:21 CET] <cone-185> ffmpeg 03Ganesh Ajjanagadde 07master:08a96708a504: lavfi/vf_overlay: fix unitialized pointers
[14:02:53 CET] <cone-185> ffmpeg 03Ganesh Ajjanagadde 07master:bd3409f52a05: lavfi/vf_alphamerge: fix unitialized pointers
[15:25:54 CET] <durandal_1707> :(
[15:26:33 CET] <philipl> BtbN: Well, stuck my oar in on the nvEncodeAPI.h licensing discussion. Fun times.
[16:03:38 CET] <cbsrobot_> durandal_1707: I tried to make a useful output from the itur468 filter but did not succeed yet
[16:05:20 CET] <cbsrobot_> I'll try to find files where I know their itur486 value and see if I can get a meaningful output
[16:07:36 CET] <durandal_1707> its in metadata
[16:08:17 CET] <durandal_1707> use adrawgraph to visualize it
[16:10:25 CET] <durandal_1707> max value I get when playing white noise
[16:10:59 CET] <durandal_1707> see also jnoisemeter
[16:11:19 CET] <durandal_1707> If you are on linux
[16:11:22 CET] <cbsrobot_> yeah I saw it - but I want to compare it
[16:19:10 CET] <durandal_1707> so could you get jnoisemeter to display something?
[16:19:48 CET] <shahriman> <ubitux> ffmpeg -h demuxer=v4l2 <-- doesn't look like it support camera control, e. g. exposure.
[16:20:07 CET] <shahriman> Am I missing something?
[16:21:11 CET] <ubitux> if that's what you meant by parameters then i guess yeah
[16:23:46 CET] <shahriman> Hmm I see. What would you call it?
[16:24:30 CET] <ubitux> dunno; but parameters could have been refering to resolution and such
[16:26:50 CET] <shahriman> It is supported by V4L2, along with some other controls. Any thoughts on what's the best way to support such settings when available in the camera?
[16:27:28 CET] <shahriman> V4L2 supports things like ISO, exposure, scene mode and some other such stuff. Of course not all camera implements all of them.
[16:27:58 CET] <shahriman> all camera drivers*
[16:31:32 CET] <ubitux> well, add avoptions for each maybe
[16:32:52 CET] <durandal_1707> you want to change it on the fly?
[16:33:39 CET] <shahriman> The camera I am working with does support changing it on the fly (Without reopening the avdevice), but I don't strictly need it.
[16:34:02 CET] <shahriman> To be honest, the only control that I am interested in is scene mode.
[16:36:50 CET] <durandal_1707> than just modifi code and add options
[16:59:41 CET] <BtbN> philipl, i think it's more of an "i don't want that header in ffmpeg" discussion. I realy don't see an issue license wise.
[17:01:06 CET] <nevcairiel> I don't even understand from what standpoint Andreas is arguing, the strictest most literal obedience to the GPL overlords?
[17:08:23 CET] <thardin> relying no dlopen() seems a bit suspect
[17:10:17 CET] <nevcairiel> I wonder how things like libva would ever be allowed to exist then, they are open-source libraries designed to interface with drivers, which can be and are closed source
[17:10:42 CET] <thardin> it's a general solution
[17:13:50 CET] <thardin> let's see if I have this right: the wrapper is MIT but the actual .so file is proprietary?
[17:14:00 CET] <nevcairiel> yes
[17:14:09 CET] <BBB> Compn: see? you too are overtakn by the powers of vp9 now
[17:14:13 CET] <thardin> so lgpl compatible but obviously not gpl compatible
[17:14:31 CET] <BBB> only if you distribute them together
[17:14:38 CET] <nevcairiel> if that would be obvious, we wouldnt have the discussion
[17:14:44 CET] <nevcairiel> the .so is not distributed with ffmpeg
[17:15:04 CET] <nevcairiel> it comes from the nvidia graphics driver, which the distribution installs for you
[17:15:41 CET] <thardin> feels like something that ties into the general deblobbing discussion
[17:16:24 CET] <nevcairiel> its one of these clauses in the GPL that don't actually benefit the projects using GPL, but just the OSS overlords that want to make closed source hard =p
[17:16:35 CET] <thardin> you'd be encouraging the spread of nonfree software
[17:18:06 CET] <thardin> but then again, with this kind of thinking software should refuse to run on hardware with a single bit of nonfree code. which is kind of difficult :]
[17:19:00 CET] <nevcairiel> anything closely related to hardware has a big chance of being involved with some sort of closed source
[17:19:08 CET] <nevcairiel> be it firmware, drivers, uefi, what have you
[17:19:12 CET] <nevcairiel> microcode even!
[17:19:25 CET] <thardin> iirc the general approach is "play nice if there's a proprietary solution already. else go full GPL for maximum capitalist tear extraction"
[17:20:15 CET] <nevcairiel> in this case, a closed source app could just use the header and have all the features
[17:20:19 CET] <nevcairiel> while our gpl ffmpeg cannot
[17:20:24 CET] <nevcairiel> clearly seems like thats not wanted, is it?
[17:20:40 CET] <thardin> yeah, probably a case where you'd want to be pragmatic
[17:20:59 CET] <Daemon404> that's not the rms way
[17:21:09 CET] <thardin> you'd be surprised
[17:21:14 CET] <nevcairiel> nvidia went out of their way to fix the license of the header from proprietary to MIT
[17:21:28 CET] <nevcairiel> after j-b lobied them for it
[17:23:20 CET] <thardin> would this kind of thing belong in the kernel?
[17:24:21 CET] <thardin> oh, and can't it be called via libva?
[17:26:20 CET] <nevcairiel> Its an encoding interface, libva encoding sucks
[17:27:29 CET] <kierank> michaelni: can we commit the first in my big dirac patchset
[17:27:33 CET] <kierank> and see what happens to fate?
[17:28:21 CET] <thardin> ic
[17:34:03 CET] <TD-Linux> thardin, yeah though there is some userspace buffer management happening there too iirc
[17:48:23 CET] <kylophone> Finishing up another filter...
[17:48:29 CET] <kylophone> This one has a lookahead.
[17:48:32 CET] <thardin> hm. because it feels like something that should be handled "further up"
[17:48:47 CET] <kylophone> As far as I can tell, the request_frame() callback happens after each filter_frame().
[17:49:06 CET] <kylophone> Since this filter has a lookahead, there is still a buffer I need to push after AVERROR_EOF. 
[17:49:20 CET] <kylophone> Should these extra samples be added to *outlink inside the request_frame() callback?
[17:49:31 CET] <kylophone> I'm assuming that trying to detect AVERROR_EOF by calling ff_request_frame() inside of filter_frame() is a bad idea.
[17:49:36 CET] <kylophone> Any ideas?
[17:50:45 CET] <michaelni> kierank, sure, first is ok the next few are ok too, didnt review all yet but that doesnt mean iam against any
[17:53:06 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:9553689854d6: diracdec: Move strides to bytes, and pointer types to uint8_t.
[17:57:09 CET] <Daemon404> kierank, got bored of cfhd? ;)
[18:30:23 CET] <Compn> kierank : so did they change cfhd from the time of those old binary codecs to today? 
[18:30:30 CET] <Compn> maybe just added more bits.
[18:30:33 CET] <kierank> yeah more fields
[18:31:40 CET] <Daemon404> did they bump a version field or something
[18:40:11 CET] <kierank> no they have a tag/value structure
[18:40:35 CET] <Daemon404> ah
[18:49:06 CET] <kierank> for vc-5 they just added more tags
[18:49:17 CET] <Daemon404> and changed some codebooks?
[18:50:26 CET] <kierank> they used one of the many codebooks in cfhd
[19:25:12 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:3f07f12f65e5: diracdec: Template DSP functions adding 10-bit versions
[19:30:26 CET] <durandal_1707> kylophone: call filter_frame from request_frame
[19:31:58 CET] <kylophone> durandal_1707: Oh, nice. Thanks.
[20:11:33 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:3bb6ce1af9d9: diracdec: Rename lowdelay_subband to decode_subband because it is shared with HQ profile
[20:18:29 CET] <Daemon404> kierank, british rail price -_-
[20:18:50 CET] <Daemon404> a eurostar ticket to brussels, return, is cheaper than a ticket to devon from london, *with* a railcard
[20:19:34 CET] <kierank> yeah
[20:19:46 CET] <kierank> try booking devon to brussels
[20:19:51 CET] <kierank> it's possible on the eurostar site
[20:19:52 CET] <Daemon404> i have once
[20:19:59 CET] <Daemon404> ah in one ticket?
[20:20:01 CET] <Daemon404> never tried it
[20:20:10 CET] <kierank> yeah it's better that way
[20:20:14 CET] <kierank> because if your first train is delayed
[20:20:20 CET] <kierank> you are entitled to be moved
[20:20:22 CET] <Daemon404> makes sense
[20:20:42 CET] <Daemon404> also it's now cheaper to fly from london city than train
[20:20:49 CET] <Daemon404> too bad the schedule is meh
[20:33:38 CET] <Daemon404> the excessive gets are due to the way mp4 handles tracks
[20:33:46 CET] <Daemon404> you may have to seek for every packet read
[20:33:53 CET] <Daemon404> depending on how packets are stored in the file
[22:04:22 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:9f374c59061b: diracdec: Make slice parameters common between lowdelay and future hq profile
[22:27:31 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:8dcc99dc684d: diracdec: Extract version parameters
[22:38:08 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:8eb6acef928d: diracdec: Support new extended quantiser range
[22:40:09 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:8880ca230738: diracdec: Store version major/minor flags
[22:42:30 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:7424a6d0a589: diracdec: Read picture types by using parse_code
[22:47:26 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:cdf8c9038ddb: diracdec: Replace dirac parse codes with better ones
[23:14:23 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:3652dd5d0cee: diracdec: Fix FPE on invalid low_delay data
[23:52:31 CET] <cone-185> ffmpeg 03Rostislav Pehlivanov 07master:d8f13e783a55: diracdec: remove duplicate codeblock decoding
[00:00:00 CET] --- Fri Dec 11 2015