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

[burek]

[00:08:48 CET] <iive> this kind of reminds me.
[00:08:59 CET] <iive> how about pushing the aac patch
[00:09:22 CET] <iive> the thread looks long dead. there are probably no cleanups coming in near future
[00:09:38 CET] <iive> and the patch is already major improvement over the current state.
[00:11:45 CET] <wm4> more merging patches without asking its author?
[00:12:02 CET] <rcombs> apparently the author is breaking it up and intends to send it soon
[00:14:29 CET] <BtbN> "ffplay /tmp/amovie1.zip//amovie.srt" uhm
[00:16:26 CET] <iive> rcombs: oh, he is back? that's good news. I was under the impression he had vanished for almost a year.
[00:32:34 CET] <nevcairiel> iive: he already send a few patches  a couple weeks ago
[00:34:26 CET] <wm4> shit I replied to nicolas george
[00:34:42 CET] Action: wm4 prepares mentally for flamewar
[00:42:21 CET] <kierank> wm4: hahaha
[00:49:50 CET] <wm4> 2 others already agreed with me that it's a bad idea, so maybe not
[00:52:36 CET] <pross> 'wm4' would make a good separator. nobody uses that in their filenames
[00:53:10 CET] <wm4> excellent idea, you get the ffmpeg design award
[00:53:16 CET] <wm4> (my sarcasm is the strongest)
[00:54:58 CET] <pross> '::' also, but its too c++shy
[00:56:07 CET] <wm4> anyway, you can't pretend files-in-zip-files are normal local paths, because there's nothing you could use to separate the path of the .zip and the zip entry
[00:57:12 CET] <iive> you can change the semantics :)
[00:57:59 CET] <rcombs> zip://<path to file>/<URI-encoded zip entry>, and assume the last path component is that URI-encoded zip entry?
[00:58:05 CET] <rcombs> (or better yet don't do this)
[00:58:48 CET] <iive> rcombs: how do you find where <path to file> ends and URI starts?
[00:58:51 CET] <BtbN> Why does it have to be some automagic url format? Can't it be in an input option, or a query string parameter?
[00:59:02 CET] <wm4> for a zip:// protocol, you merely need to pick a semi rar separator, and URL-escape the zip path
[00:59:11 CET] <wm4> *semi rare
[00:59:24 CET] <wm4> so if the separator happens in the zip filename, it's escaped
[00:59:36 CET] <rcombs> iive: last path component is the zip entry
[00:59:50 CET] <wm4> zip can store directories
[00:59:51 CET] <rcombs> iive: all components before that are the path to the actual file
[00:59:59 CET] <rcombs> wm4: right, thus the escaping
[01:00:12 CET] <iive> rcombs: what escaping?
[01:00:14 CET] <rcombs> but dammit why am I coming up with implementation plans for a _bad idea_
[01:00:16 CET] <wm4> then you'd escape the /, that'd be awkward
[01:00:17 CET] <rcombs> iive: URI?
[01:00:29 CET] <BtbN> zip:///some/path/to/some.zip?f=some/file.mkv
[01:00:32 CET] <iive> rcombs: can you give me example?
[01:00:35 CET] <wm4> (you could just do what vlc and mpv do but don't tell anyone)
[01:01:00 CET] <BtbN> (you could also not do it at all and leave it to actual media players)
[01:01:39 CET] <wm4> but ffmpeg must have all the things
[01:01:57 CET] <pross> BtbN: but i want to be able to pull my zips over http. precisely. all the things.
[01:02:00 CET] <iive> of course... something about duplication.
[01:02:23 CET] <wm4> ideally there'd be a good library for reading zip, rar, etc.
[01:02:33 CET] <wm4> application just would have to wire them up
[01:02:38 CET] <wm4> no reason to add that stuff to ffmpeg
[01:02:54 CET] <iive> isn't there one already?
[01:03:21 CET] <wm4> this has the advantage that ffmpeg doesn't need to make up strange conventions like zip://, and applications won't have to bend backwards to fit these conventions into their own code
[01:04:08 CET] <wm4> also I can guarantee that virtually nobody will use ffmpeg zip support with the current conventions
[01:04:15 CET] <wm4> (too hard to "discover")
[01:04:54 CET] <pross> wm4: i don't think it should be an explicit protocol. ffmpeg should magically detect the zip/rar/etc header
[01:05:03 CET] <wm4> and then what
[01:05:23 CET] <pross> open the first file, _or_ open the user specified file/wildcard
[01:05:28 CET] <wm4> heh
[01:06:11 CET] <pross> much the same way we treat multiple streams in a multmedia file
[01:06:19 CET] <iive> btw, isn't there something like libfuse?
[01:06:25 CET] <wm4> that's... not a good comparison at all
[01:06:41 CET] <rcombs> &yeah, not really
[01:06:50 CET] <rcombs> iive: yeah, that's a less-insane place to do this
[01:08:30 CET] <pross> ./ffplay dvd.iso
[01:08:36 CET] <wm4> anyway, spoiler: vlc and mpv treat rar files as playlists with URL-like entries, which seems to be a relatively sane approach
[01:09:47 CET] <wm4> so a rar file can both be opened directly, and there's also a safe way (i.e. not clashing with local paths) to refer to rar entries
[01:11:02 CET] <kierank> this should all be handled higher than libavformat
[01:11:16 CET] <wm4> yeah
[01:12:15 CET] <wm4> IMHO one problem is that the ffmpeg libs are pretty low level, but people want to think of it as general media framework (and more), and end up forcing higher level things on the wrong abstraction level just to get it into ffmpeg
[01:12:39 CET] <wm4> but the worse problem is that some devs want "everything" in ffmpeg because it's their project
[01:12:49 CET] <BtbN> Does ffmpeg even have the concept of a playlist?
[01:13:16 CET] <kierank> no
[01:13:18 CET] <kierank> it's a low level library
[01:13:43 CET] <wm4> and that's why we have things like the concat demuxer...
[01:14:04 CET] <beastd> BtbN: I don't think so, but I think having a playlist concept in ffmpeg would be a good thing.
[01:14:09 CET] <rcombs> wm4: well, it wouldn't be absurd to have some of this stuff in ffmpeg if we had some higher-level wrapper libs
[01:14:31 CET] <BtbN> beastd, not realy. ffmpeg isn't a "make_media_player();" library.
[01:15:07 CET] <wm4> maybe it would be a good thing, but not in libavformat or whatever
[01:15:08 CET] <beastd> BtbN: I cannot follow your argument.
[01:15:10 CET] <rcombs> which could have some things that are currently in lavf but don't really fit there (2 concats, plus one in lavfi!), and some boilerplate that currently lives in ffmpeg.c
[01:16:33 CET] <pross> "FFmpeg is a collection of libraries and tools to process multimedia content such as audio, video, subtitles and related metadata."
[01:16:47 CET] <beastd> not sure playlists would be part of lavf, i only said that the concept of playlists would be useful to ffmpeg tools at least
[01:16:59 CET] <rcombs> beastd: yeah, that seems reasonable
[01:17:23 CET] <rcombs> but it seems there's consensus that the trend of putting such things in lavf isn't great
[01:17:41 CET] <iive> mkv segments...
[01:17:42 CET] <rcombs> and stuffing it in ffmpeg.c is useless for& anyone not using ffmpeg.c
[01:17:46 CET] <rcombs> iive: yup
[01:18:08 CET] <BtbN> Maybe a new library, which operates on a higher level?
[01:18:14 CET] <rcombs> BtbN: that's what I just said
[01:18:56 CET] <rcombs> iive: there's been some talk about how those would be pretty tricky to do purely within lavf, and how that's not really a place that makes sense to have them anyway
[01:19:13 CET] <wm4> mkv segments would be a pretty good candidate for something more higher level
[01:19:16 CET] <rcombs> so one alternative proposed has been to have lavf export them as metadata
[01:19:17 CET] <iive> rcombs: and I agree with that
[01:19:26 CET] <wm4> (although we could just do what the haali demuxer does, ugh)
[01:19:28 CET] <rcombs> and to have the consumer handle the splicing
[01:19:43 CET] <rcombs> but that'd mean every consumer would have to handle that, and that's no fun
[01:19:55 CET] <rcombs> and it'd mean ffmpeg.c would grow
[01:20:00 CET] <wm4> also, the boilerplate to setup a demuxer/decoder/format conversion is terrible
[01:20:05 CET] <rcombs> wm4: yup
[01:20:17 CET] <rcombs> so having some intermediate library would make sense
[01:20:25 CET] <wm4> but it's one of the most common things an API user wants, so what if a high level lib would do it
[01:20:33 CET] <iive> rcombs: so libffmpeg for the win
[01:20:38 CET] <rcombs> iive: pretty much
[01:20:41 CET] <wm4> anyway, somewhat afraid we would end up with a gstreamer clone
[01:20:54 CET] <rcombs> optimally, I think ffmpeg.c should be quite small
[01:21:07 CET] <BtbN> If it's not using glib, it's worth it. I just realy don't like that stuff.
[01:21:28 CET] <rcombs> just a little CLI wrapper around the libs
[01:22:05 CET] <wm4> I don't know, ffmpeg.c does fucked up things like stream copy
[01:22:08 CET] <rcombs> wm4: what does the haali demuxer do? Just start grabbing packets from the segment file's corresponding streams?
[01:22:59 CET] <iive> imagine the fun if the outside files use entirely different codec :)
[01:23:01 CET] <wm4> rcombs: youhttp://git.1f0.de/gitweb?p=ffmpeg.git;a=blob;f=libavformat/matroskadec_haali.c;h=e3320fd12947a018bc5c7f4138b783fe96e5efea;hb=HEAD
[01:23:03 CET] <beastd> rcombs: basically that is saying to make the libs smarter or to nerve ffmpeg tools .  TBH I think the truth is somewhere inbetween.
[01:23:05 CET] <wm4> oops
[01:23:09 CET] <wm4> http://git.1f0.de/gitweb?p=ffmpeg.git;a=blob;f=libavformat/matroskadec_haali.c;h=e3320fd12947a018bc5c7f4138b783fe96e5efea;hb=HEAD
[01:23:29 CET] <iive> n8 ppl
[01:23:34 CET] <wm4> (that's only some of the code, there are other files)
[01:23:40 CET] <iive> have fun.
[01:23:41 CET] <beastd> n8 iive
[01:24:53 CET] <nevcairiel> thats really not "what the haali demuxer" does, thats mostly what my demuxer does .. the haali code it uses is a pretty low-level parser
[01:28:37 CET] <wm4> oh, ok
[01:29:05 CET] <wm4> I have no idea what the differences are between your code and the original haali filter
[01:30:28 CET] <wm4> though, it does pretend a mkv file with ordered chapters is like a linear file, right? i.e. handles this on the demuxer level
[01:30:34 CET] <nevcairiel> yes
[01:32:05 CET] <nevcairiel> the only haali code is in MatroskaParser.c/h (ie. http://haali.su/mkv/MatroskaParser.zip, modified quite a bit to this date), and its only a low level parser for single mkv files, the code that stitches them together for the virtual timeline is all mine
[01:32:36 CET] <wm4> heh, fun
[01:33:50 CET] <nevcairiel> it started out as a pretty basic mkv demuxer back when ffmpegs was even more terrible, but now it has so many extra features .... :d
[01:34:28 CET] <pross> speaking of stuffing FFmpeg, i must return to AV_SAMPLE_FMT_DSD
[01:34:50 CET] <wm4> dsd is evil
[01:36:06 CET] <pross> and investigate bayer optimisation (at least somebody is using that)
[01:36:11 CET] <wm4> nevcairiel: though it's sad that everyone has to have their own mkv demuxer
[01:36:15 CET] <pross> dsd is placebo
[01:36:32 CET] <pross> aureal comfort for those with too much money
[01:39:25 CET] <nevcairiel> dsd is so annoying, all the audiophools treat it like its the holy grail
[01:48:44 CET] <pross> nevcairiel: its theorectically superior, no silly bit-depths to mess with
[01:57:47 CET] <kierank> h264 is in need of heavy fuzzing
[01:59:15 CET] <kierank> error: [av] Changing field mode (3 -> 1) between slices is not allowed
[01:59:15 CET] <kierank> error: [av] decode_slice_header error
[01:59:15 CET] <kierank> error: [av] Changing field mode (3 -> 1) between slices is not allowed
[01:59:15 CET] <kierank> error: [av] decode_slice_header error
[01:59:15 CET] <kierank> error: [av] Changing field mode (3 -> 1) between slices is not allowed
[01:59:15 CET] <kierank> error: [av] decode_slice_header error
[01:59:15 CET] <kierank> Segmentation fault (core dumped)
[03:02:07 CEST] <kierank> ah finally got it to segfault again
[03:04:15 CEST] <jamrial> isn't google fuzzing everything 24/7?
[03:09:09 CEST] <kierank> gimme a second and I'll open a ticket
[03:26:13 CEST] <cone-706> ffmpeg 03Anton Khirnov 07release/2.4:a219add4e8e2: hevc: make the crop sizes unsigned
[03:26:13 CEST] <cone-706> ffmpeg 03Anton Khirnov 07release/2.4:a529f6648ed4: hevc: zero the correct variables on invalid crop parameters
[03:26:13 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:4bc7996dcbcd: Merge commit 'a219add4e8e2d3192d99d6c6efe97ec7c429c5ad' into release/2.4
[03:26:13 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:7bce99216f74: avcodec/hevc_ps: More complete window reset
[03:26:13 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:6e835eb2dd52: Merge commit 'a529f6648ed450f7e846a0e704a0a3260aaa4b62' into release/2.4
[03:34:10 CEST] <cone-706> ffmpeg 03Anton Khirnov 07release/2.4:9cef65434e5e: h264_ps: properly check cropping parameters against overflow
[03:34:11 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:b7c8a1fbbd0b: webp: ensure that each transform is only used once
[03:34:12 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:8e7eb268758d: Merge commit '9cef65434e5e5ffbd4a856ce7ae9c067dec039b7' into release/2.4
[03:34:13 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:53fa0d370cbb: webp: ensure that each transform is only used once
[03:34:14 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:51b0d7675c34: Merge commit 'b7c8a1fbbd0b6ac0b096ef0402dee440ff27ecb7' into release/2.4
[03:41:25 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:1ee7f2d77e36: avformat/idcin: Use 64bit for ret to avoid overflow
[03:41:26 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:2046275aaffa: avformat/gxf: Use 64bit for res to avoid overflow
[03:41:27 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:81ee3385ee14: avformat/mvdec: Use 64bit for ret to avoid overflow
[03:41:28 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:8f65bedbaff4: avformat/wtvdec: Use 64bit for ret to avoid overflow
[03:41:29 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:5169df2122f6: avformat/vqf: Use 64bit for ret to avoid overflow
[03:41:30 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:093e3f4d5b90: avformat/omadec: Use 64bit for ret to avoid overflow
[03:41:31 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:88c06ca25149: avcodec/x86/mlpdsp_init: Simplify mlp_filter_channel_x86()
[03:41:32 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:3167bba15ec3: avcodec/a64multienc: use av_frame_ref instead of copying the frame
[03:41:33 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:acfe143736d8: avcodec/a64multienc: don't set incorrect packet size
[03:41:34 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:584d90b277d8: avcodec/a64multienc: initialize mc_meta_charset to zero
[03:41:35 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:37941c03b73d: avcodec/a64multienc: fix use of uninitialized values in to_meta_with_crop
[03:41:36 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:35a79bdf7df7: avcodec/a64multienc: simplify frame handling code
[03:41:37 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:9dc686815554: avcodec/a64multienc: Assert that the Packet size does not grow
[03:41:38 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:2dde6d5d367e: swscale/utils: More carefully merge and clear coefficients outside the input
[03:41:39 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:49543062280c: avcodec/snowdec: Fix ref value check
[03:41:40 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:ba59d9212869: avcodec/h264: Only reinit quant tables if a new PPS is allowed
[03:41:41 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:ca663f79e95f: avcodec/zmbv: Check len before reading in decode_frame()
[03:41:42 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:e8a44b8387e3: avcodec/hevc_ps: Sanity checks for some log2_* values
[03:41:43 CEST] <cone-706> ffmpeg 03James Cowgill 07release/2.4:198aa9fabde1: mips/acelp_filters: fix incorrect register constraint
[03:41:44 CEST] <cone-706> ffmpeg 03Dyami Caliri 07release/2.4:bcbae2d95fc5: Fix buffer_size argument to init_put_bits() in multiple encoders.
[03:41:45 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:f33a2ea2eea7: avformat/adxdec: check avctx->channels for invalid values
[03:41:46 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:6fbd897caba6: avformat/bit: check that pkt->size is 10 in write_packet
[03:41:47 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:2ec6a7a1e048: avformat/bit: only accept the g729 codec and 1 channel
[03:41:48 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:eceea69567ac: swscale/utils: clear formatConvBuffer on allocation
[03:41:49 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:d42540499c51: avutil/imgutils: correctly check for negative SAR components
[03:41:50 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:ddffbf720a84: avcodec/utils: use correct printf specifier in ff_set_sar
[03:41:51 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:a80b38d7d248: avformat/flvenc: check that the codec_tag fits in the available bits
[03:41:52 CEST] <cone-706> ffmpeg 03Steve Lhomme 07release/2.4:2a6f0c7e077e: fix VP9 packet decoder returning 0 instead of the used data size
[03:41:53 CEST] <cone-706> ffmpeg 03Stefano Sabatini 07release/2.4:99de009e97d0: doc/protocols/tcp: fix units of listen_timeout option value, from microseconds to milliseconds
[03:41:54 CEST] <cone-706> ffmpeg 03Ronald S. Bultje 07release/2.4:54d40b7c459e: vp9: fix segmentation map retention with threading enabled.
[03:41:55 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:9821cf9e6e6e: avcodec/utils: Align YUV411 by as much as the other YUV variants
[03:41:56 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:ee820d051273: avcodec/opusdec: Clear out pointers per packet
[03:41:57 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:7470003e80d7: avcodec/opusdec: Fix delayed sample value
[03:41:58 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:23666f0e229e: doc: avoid the incorrect phrase 'allow to'
[03:41:59 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:6a671797d769: avcodec/tiff: move bpp check to after "end:"
[03:42:00 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:d81150929d35: ffmdec: fix infinite loop at EOF
[03:42:01 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:443fc852034b: ffmdec: make sure the time base is valid
[03:42:02 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:820b84d0658a: ffmdec: limit the backward seek to the last resync position
[03:42:03 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:770094752528: avcodec/options_table: remove extradata_size from the AVOptions table
[03:42:04 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:7b3d8ae32d29: roqvideoenc: set enc->avctx in roq_encode_init
[03:42:05 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:de2f46c59dad: asfenc: fix leaking asf->index_ptr on error
[03:42:06 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:8639c37d2b54: avcodec/012v: Check dimensions more completely
[03:42:07 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:f11afe6bc654: avcodec/012v: redesign main loop
[03:42:08 CEST] <cone-706> ffmpeg 03Andreas Cadhalpun 07release/2.4:f45f3f99a4d9: ac3dec_fixed: always use the USE_FIXED=1 variant of the AC3DecodeContext
[03:42:09 CEST] <cone-706> ffmpeg 03Christophe Gisquet 07release/2.4:40dab4505031: ac3_fixed: fix out-of-bound read
[03:42:10 CEST] <cone-706> ffmpeg 03Christophe Gisquet 07release/2.4:691f9dee0060: ac3_fixed: fix computation of spx_noise_blend
[03:42:11 CEST] <cone-706> ffmpeg 03Christophe Gisquet 07release/2.4:b9b56ded7dd4: eac3dec: fix scaling
[03:42:12 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:e168db3eaef0: avformat/mov: Use sizeof(filename) instead of a literal number
[03:42:13 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:e0975c31f188: avformat/mov: Check for string truncation in mov_open_dref()
[03:42:14 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:17e6d249b702: avformat/mov: Disallow ".." in dref unless use_absolute_path is set
[03:42:15 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:760c384f7db4: avcodec/dnxhddec: Check that the frame is interlaced before using cur_field
[03:42:16 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:2049d95f2fee: avcodec/hevc_ps: Check cropping parameters more correctly
[03:42:17 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07release/2.4:539172c85b13: avcodec/msrledec: restructure msrle_decode_pal4() based on the line number instead of the pixel pointer
[04:03:43 CEST] <cone-706> ffmpeg 03Matthieu Bouron 07master:573a77a1b6f5: libavdevice/avfoundation: add framerate and video size options
[04:03:44 CEST] <cone-706> ffmpeg 03Matthieu Bouron 07master:c908cae74cd1: libavdevice/avfoundation: add capture_cursor option
[04:16:04 CEST] <cone-706> ffmpeg 03Matthieu Bouron 07master:021b02375181: libavdevice/avfoundation: add capture_mouse_clicks option
[04:16:05 CEST] <cone-706> ffmpeg 03Matthieu Bouron 07master:cf16b459a873: libavdevice/avfoundation: use pts/dts provided by the CMSampleBuffer API
[06:16:04 CEST] <cone-706> ffmpeg 03James Almer 07release/2.2:0b51e0baea31: avutil/cpu: add missing check for mmxext to av_force_cpu_flags
[06:16:05 CEST] <cone-706> ffmpeg 03James Almer 07release/2.4:e74ad9035f3e: avutil/cpu: add missing check for mmxext to av_force_cpu_flags
[06:16:06 CEST] <cone-706> ffmpeg 03James Almer 07release/2.5:b46840475ed6: avutil/cpu: add missing check for mmxext to av_force_cpu_flags
[06:16:07 CEST] <cone-706> ffmpeg 03James Almer 07release/2.6:037d6cf5806e: avutil/cpu: add missing check for mmxext to av_force_cpu_flags
[12:15:32 CEST] <cone-443> ffmpeg 03wm4 07master:c48456166e95: lavc: add MMAL hardware decoder wrapper
[12:15:32 CEST] <cone-443> ffmpeg 03Michael Niedermayer 07master:268ff17cb785: Merge commit 'c48456166e95648719a8be8f8613f9dee98205c1'
[12:40:01 CEST] <cone-443> ffmpeg 03Hendrik Leppkes 07master:6fe2641d6e41: lavc: add profile define for DTS Express
[12:40:02 CEST] <cone-443> ffmpeg 03Michael Niedermayer 07master:97a407f696ae: Merge commit '6fe2641d6e410b7bc203138fa97e1118b411f16d'
[13:11:32 CEST] <cone-443> ffmpeg 03Hendrik Leppkes 07master:72025ac36c74: lavc: add libdcadec decoder
[13:11:33 CEST] <cone-443> ffmpeg 03Michael Niedermayer 07master:93704e09c77e: Merge commit '72025ac36c740f031d7e413041fdfe97087c83c4'
[13:26:55 CEST] <cone-443> ffmpeg 03Carl Eugen Hoyos 07master:7de0fefeb5b3: lavf/gif: Add an option max_gif_delay to limit the frame duration.
[13:26:56 CEST] <cone-443> ffmpeg 03Carl Eugen Hoyos 07master:d371471c59ba: Fix make checkheaders if libmfx is not available.
[13:26:57 CEST] <cone-443> ffmpeg 03Carl Eugen Hoyos 07master:b3673f341491: lavc/h264_refs: Fix compilation with -DTRACE.
[13:26:58 CEST] <cone-443> ffmpeg 03Michael Niedermayer 07master:81487781e739: Merge remote-tracking branch 'cehoyos/master'
[13:41:33 CEST] <cone-443> ffmpeg 03Rodger Combs 07master:bcf44c91c309: libavformat/hls: add an option to start from a given segment in a live stream
[14:00:51 CEST] <wm4> michaelni: what's the legal basis for changing the Libav copyright header to read "FFmpeg" (plus changing some of the legalese in that license header)?
[14:03:42 CEST] <michaelni> wm4, what are you talking about ?
[14:04:08 CEST] <nevcairiel> wm4: that line is not really a fixed part of the license
[14:05:35 CEST] <wm4> michaelni: new file in Libav -> license header is changed on merge
[14:06:45 CEST] <nevcairiel> it should always  be the current project name, anything else is just stupid confusing
[14:22:57 CEST] <michaelni> wm4, no copyright statements have been changed by us, if any where by mistake please post detailed information about which that was to the mailing list, preferrably with a patch. The project name of FFmpeg is FFmpeg, so thats what the files should use as project name. I think most other FOSS project do likewise
[14:52:11 CEST] <cone-443> ffmpeg 03Rodger Combs 07master:481f0f153ac3: libavformat/segment: don't leave the list pb open when not in use
[15:06:54 CEST] <michaelni> kierank, ubitux; Yayoi should do some qualification task if she wants to be accepted in Outreachy.
[15:07:03 CEST] <kierank> she is doing one
[15:07:14 CEST] <michaelni> ok perfect
[17:13:55 CEST] <michaelni> kierank, wm4; Mariusz posted a patch to bump version for the directory API, if you still want changes done to it, please tell him. if not ill apply it
[17:14:28 CEST] <kierank> where
[17:14:33 CEST] <wm4> what, does the API become official after the bump?
[17:14:46 CEST] <kierank> it's bloat
[17:42:26 CEST] <ninten> durandal_1707,  ping
[17:46:41 CEST] <durandal_1707> ninten: pong
[18:01:36 CEST] <cone-175> ffmpeg 03Rodger Combs 07master:7b060a96ad8a: libavformat/segment: add an option to write the header to a separate file
[18:01:36 CEST] <cone-175> ffmpeg 03Donny Yang 07master:68ede913d033: png: Return slightly more meaningful error codes
[18:09:17 CEST] <ninten> durandal_1707,  if our input sample is floating then in alsSpecificConfig the floating int must be high right !! 
[18:11:07 CEST] <ninten> so i am giving input as floating sample and trying to check the value of floating int and still it is giving that floating point not implemented 
[18:11:55 CEST] <durandal_1707> ninten: what it stores?
[18:12:43 CEST] <ninten> durandal_1707,  if input is floating sample then floating int in alsSpcConfing must be 1
[18:13:22 CEST] <durandal_1707> remove check for missing float implementation
[18:14:01 CEST] <ninten> durandal_1707,  http://pastebin.com/ARbi15ag
[18:16:36 CEST] <durandal_1707> what I already said
[18:17:48 CEST] <ninten> durandal_1707,  how to remove this !!
[18:20:08 CEST] <durandal_1707> ninten: search for text message in decoder
[18:24:12 CEST] <ninten> durandal_1707,  ohh got it thanks !!!
[18:28:07 CEST] <cone-175> ffmpeg 03Donny Yang 07master:e7ba79dc4e39: png: Calculate pixel format information only once
[18:41:31 CEST] <cone-175> ffmpeg 03Donny Yang 07master:9573737dfbe5: png: Only init zlib once
[18:59:01 CEST] <kierank> trac is broken
[19:01:00 CEST] <kierank> oh it's just slow
[19:06:52 CEST] <michaelni> kierank, in the "[FFmpeg-devel] [PATCH 1/4] lavf: add directory listing API" thread
[19:07:11 CEST] <michaelni> wm4, yes it becomes "official" after the bump
[19:14:07 CEST] <cone-175> ffmpeg 03Rodger Combs 07master:de2aaf1a2a14: lavf/segment: Mark output contexts as non-seekable when applicable
[19:18:55 CEST] <CamilaSouto> Hi Kieran, could you please assign task for me at https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015-Qualis, please?
[19:20:36 CEST] <CamilaSouto> kierank
[19:21:08 CEST] <kierank> I think you can edit it yourself
[19:30:57 CEST] <kierank> 3 segfaults in h264 today
[19:30:57 CEST] <kierank> :)
[19:31:31 CEST] <CamilaSouto> I see, I thought I was not able to do that. So the task can be to: Write test to decode a H264 and add it to test suite?
[19:31:54 CEST] <kierank> CamilaSouto: yes
[19:34:00 CEST] <CamilaSouto> OK! thanks!
[19:38:40 CEST] Action: kierank goes to the supermarket and waits for the next crash
[19:45:17 CEST] <BBB> having fun kierank? :)
[19:45:41 CEST] <kierank> a little bit of packet loss on the link and it's segfault central
[19:45:47 CEST] <kierank> oh and again :)
[19:46:03 CEST] <wm4> just packet loss?
[19:46:03 CEST] <kierank> how to reproduce I'm not sure though :(
[19:46:08 CEST] <kierank> yes
[19:46:20 CEST] <wm4> saving all packets to disk and replaying doesn't work?
[19:46:42 CEST] <wm4> sounds like some sort of really basic fuzzing should catch these things
[19:47:48 CEST] <kierank> (gdb) print h->cur_pic_ptr
[19:47:48 CEST] <kierank> $1 = (H264Picture *) 0x0
[19:47:50 CEST] <kierank> lovely
[19:56:59 CEST] <kierank> so there's an error in decoding slices but the slice is still decoded again
[19:57:00 CEST] <kierank> wtf
[22:17:32 CEST] <cone-915> ffmpeg 03Luca Barbato 07master:ff7adead0a66: udp: Fix pkt_size management
[22:17:32 CEST] <cone-915> ffmpeg 03Michael Niedermayer 07master:83443505090d: Merge commit 'ff7adead0a667e606f5a41dca591f074f9ff2f32'
[22:17:32 CEST] <cone-915> ffmpeg 03Michael Niedermayer 07master:d0059281e6a6: avformat/udp: Remove (harmless) duplicated pkt_size entry from AVOption table
[22:26:10 CEST] <rcombs> what makes nvenc require nonfree? AFAICT libcuda is under the Apache 2.0 license?
[22:26:37 CEST] <nevcairiel> apparently the header uses a corporate license, and using the header alone supposedly makes the entire binary nonfree
[22:35:03 CEST] <BtbN> libcuda isn't uses though.
[22:35:05 CEST] <BtbN> *d
[22:35:12 CEST] <rcombs> BtbN: it's loaded with dolmen
[22:35:18 CEST] <rcombs> *dlopen
[22:35:30 CEST] <BtbN> Yes, but that's just the runtime library.
[22:36:40 CEST] <BtbN> https://developer.nvidia.com/nvidia-video-codec-sdk-license-agreement that's why it's non-free.
[22:38:25 CEST] <rcombs> what a mess
[22:41:47 CEST] <BtbN> Just a commercial license that makes it non-free.
[22:42:08 CEST] <j-b>  * This source code and/or documentation ("Licensed Deliverables") are
[22:42:08 CEST] <j-b> * subject to NVIDIA intellectual property rights under U.S. and
[22:42:09 CEST] <j-b> * international Copyright laws.
[22:42:31 CEST] <j-b>  * These Licensed Deliverables contained herein is PROPRIETARY and
[22:42:31 CEST] <j-b> * CONFIDENTIAL to NVIDIA and is being provided under the terms and
[22:42:31 CEST] <j-b> * conditions of a form of NVIDIA software license agreement by and
[22:42:32 CEST] <j-b> * between NVIDIA and Licensee
[22:42:44 CEST] <j-b> reproduction or disclosure
[22:42:44 CEST] <j-b> * of the Licensed Deliverables to any third party without the express
[22:42:44 CEST] <j-b> * written consent of NVIDIA is prohibited.
[22:42:52 CEST] <j-b> it's hard to be less non-free
[22:44:40 CEST] <nevcairiel> the question is what you really distribute by just using the header in your binary, it seems rather obscure to me, but IANAL of course
[22:45:25 CEST] <j-b> It depends on what is in the header
[22:45:33 CEST] <BtbN> Without clarification from nvidia noone will know for sure.
[22:45:41 CEST] <BtbN> In the header itself is another license though
[22:45:52 CEST] <BtbN> that in some points is more permissive and in others more restrictive.
[22:45:56 CEST] <j-b> BtbN: no, this is from the headers
[22:46:10 CEST] <j-b> but in the nVidia case, it's pretty obvious, that distributing the code from the header is not OK
[22:46:24 CEST] <j-b> it has some non-trivial numbers and structs
[22:46:52 CEST] <j-b> bitmasks and GUID
[22:47:36 CEST] <BtbN> imo nvidia should just re-license that header. They seem to be interested in people using it. Specialy as they tried to get it into ffmpeg themselves.
[22:47:58 CEST] <j-b> and they won't do it, because they want to protect their "IP"
[22:48:47 CEST] <jamrial> BtbN: sounds like their dev teams and legal department don't talk often, then
[22:49:08 CEST] <BtbN> If they talk at all.
[22:49:46 CEST] <BtbN> My attempts to communicate with them have all failed so far.
[22:51:24 CEST] <j-b> US companies are always afraid of their lawyers
[22:51:39 CEST] <j-b> their lawyers take the decisions, and are not "advisors"
[22:52:15 CEST] <BtbN> They propably just do that license to be safe for all possible things that could happen.
[22:52:30 CEST] <BtbN> But at the same time give everyone a hard time who actualy cares about the license.
[22:53:18 CEST] <j-b> "The appeals court reversed the district court on the central issue, holding that the "structure, sequence and organization" of an API was copyrightable."
[22:53:20 CEST] <BtbN> I still think the compiled binary could be distributed without issues though. But who knows for sure.
[22:53:25 CEST] <j-b> Federal Circuit Court of Appeals
[23:05:56 CEST] <wm4> <BtbN> imo nvidia should just re-license that header. They seem to be interested in people using it. Specialy as they tried to get it into ffmpeg themselves. <- and we should have rejected it
[23:16:10 CEST] <kierank> wm4: ffmpeg and reject 
[23:16:11 CEST] <kierank> lol
[23:30:48 CEST] <BtbN> The nvidia patches were basicaly rejected.
[23:31:09 CEST] <BtbN> They tried to avoid the license issue with an integrated wrapper library.
[23:31:17 CEST] <BtbN> Which changed nothing about it.
[00:00:00 CEST] --- Mon Mar 30 2015