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

[burek]

[01:49:04 CEST] <Tom012> Hello people. Is it possible to add support to detect an encrypted file and print an error message?
[01:52:40 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.1:206129843857: videodsp: don't overread edges in vfix3 emu_edge.
[01:52:41 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.2:beaf2728cea1: videodsp: don't overread edges in vfix3 emu_edge.
[01:52:42 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.3:f6006295c037: videodsp: don't overread edges in vfix3 emu_edge.
[01:52:43 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.4:d3af86c867c7: videodsp: don't overread edges in vfix3 emu_edge.
[01:52:44 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.5:11579f7e4e99: videodsp: don't overread edges in vfix3 emu_edge.
[01:52:45 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.6:743d6a2782ca: videodsp: don't overread edges in vfix3 emu_edge.
[01:52:46 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.7:131f2c366e40: videodsp: don't overread edges in vfix3 emu_edge.
[01:52:47 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.8:6616762134e1: videodsp: don't overread edges in vfix3 emu_edge.
[01:55:38 CEST] <c_14> Tom012: what kind of encryption are we talking about here. For the most part, the purpose of encryption is to make something indistinguishable from random data, so unless it's explicitly tagged as encrypted, no.
[01:56:43 CEST] <Tom012> c_14: I mean copy protected vob and m4v files. 
[01:58:39 CEST] <c_14> Assuming they're properly tagged (and they should be otherwise proprietary software wouldn't be able to play them either, it should be possible (I don't know anything about the related format specs though.)
[02:01:45 CEST] <c_14> Looks like there might already be a ticket open for it https://trac.ffmpeg.org/ticket/4016
[02:04:20 CEST] <J_Darnley> Sure, I think that works for mp4 because the content of its "frames" are what is encrypted
[02:04:56 CEST] <J_Darnley> but isn't VOBs with CSS protects just all encrypted?
[02:15:30 CEST] <BBB> do we have infrastructure now to force the use of bitstream filters when muxing?
[02:15:54 CEST] <BBB> I thought someone wrote that a while ago
[02:15:57 CEST] <BBB> was that applied?
[02:16:10 CEST] <J_Darnley> I'm not sure.
[02:16:19 CEST] <J_Darnley> I remember the patch and the discussion.
[02:17:22 CEST] <J_Darnley> I don't see it in my cvslog messages though
[02:22:45 CEST] <wm4> rcombs has a patch
[02:22:49 CEST] <wm4> not applied yet I think
[02:23:18 CEST] <rcombs> sitting on the ML
[02:23:30 CEST] <rcombs> I don't think anyone has explicit problems with any of it though
[02:37:47 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:2ee51ef259e6: avfilter/vf_deshake: use a void * comparator for consistency
[02:39:05 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:94f333f9dcfb: avutil/tree: improve documentation for av_tree_find, av_tree_insert
[02:40:16 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:7c8fcbbde3a2: avutil/tree: add additional const qualifier to the comparator
[02:35:34 CET] <BBB> rcombs: quite the contrary, I love the concept of it
[02:35:39 CET] <BBB> rcombs: Id love for it to go in
[02:35:48 CET] <BBB> rcombs: does it just need review? any explicit concerns that need to be resolved?
[02:37:35 CET] <rcombs> BBB: another review pass certainly wouldn't hurt
[02:38:47 CET] <rcombs> there was one concern about whether or not we should allow allocations in AVOutputFormat::init
[02:39:11 CET] <rcombs> and the favorite solution seemed to be to add a `deinit` cleanup function
[02:40:54 CET] <rcombs> which would also let you close a muxer without actually writing the trailer
[02:41:03 CET] <rcombs> (useful in error cases, or in weird situations like segment.c)
[02:42:12 CET] <rcombs> but that's kinda tangential
[02:44:33 CET] <BBB> kind of, yes
[02:44:38 CET] <BBB> ok Ill look at the review
[02:45:09 CET] <rcombs> thanks
[05:18:59 CET] <Timothy_Gu> weryuijokp532aq6w44qyugiytrd
[05:19:41 CET] <Timothy_Gu> sorry it's my younger brother
[05:20:04 CET] <Timothy_Gu> no its' not
[05:20:12 CET] <Timothy_Gu> itfs me
[05:20:19 CET] <Timothy_Gu> i love u
[05:20:32 CET] <Timothy_Gu> homecoming?
[05:20:53 CET] <Timothy_Gu> respond
[05:20:57 CET] <Timothy_Gu> please
[05:22:04 CET] <Timothy_Gu> sorry again. somebody hacked my machine physically. control now restored
[05:24:39 CET] <Timothy_Gu> hi
[05:24:45 CET] <Timothy_Gu> shit
[05:24:57 CET] <Mark__> wtf is wrong with this guy
[05:25:11 CET] <Mark__> who made him mod
[05:25:45 CET] <Mark__> amirite
[05:39:01 CET] Action: rcombs rebuilds an MP4 index by searching for 00 00 00 02 09
[07:32:25 CET] <atomnuker> hm, not sure how I missed the ridiculously long fabsf() vs FFABS() thread on the ML
[07:34:45 CET] <atomnuker> a nice compromise would be to use C11's awesome generics to determine type and pick the usual for ints or fabsf() for floats
[07:36:53 CET] <atomnuker> but being in the (C)90's has its upsides and downsides
[07:40:54 CET] <atomnuker> or you know, the best and easiest way is to just use fabs(f)() directly in the code which is what the AAC encoder does
[09:29:56 CET] <nevcairiel> noone wanted to rewrite the macro, it always was about replacing usage of FFABS with fabs(f) in float code
[10:05:19 CET] <durandal_1707> my stuff is trivial to review
[11:36:59 CET] <JEEB> was it possible to set -v debug only for specific things?
[12:14:41 CET] <cone-463> ffmpeg 03Paul B Mahol 07master:6f3ba23ae0d4: avformat: add xvag demuxer
[12:14:41 CET] <cone-463> ffmpeg 03Paul B Mahol 07master:1f36b43c280d: doc/general: update after recent additions
[12:40:53 CET] Action: Daemon404 prods wm4
[12:41:28 CET] <wm4> ow
[12:42:14 CET] <Daemon404> i think perhaps you may have a differing opinion re: locales
[12:42:18 CET] <Daemon404> to nicholas
[12:42:31 CET] <wm4> oh, potential flame again?
[12:42:40 CET] <Daemon404> s/flame/bikeshed/
[12:42:51 CET] <Daemon404> nothing inflamatory pls
[12:43:46 CET] <Daemon404> i am not against saying "stuff may not work unless locale=C" or something, however we ought to not set it.
[12:43:53 CET] <Daemon404> (i cant tell which nicholas is adocating(
[13:08:41 CET] <wm4> holy fuck claws-mail is in one of its fuckup periods where it scans the entire mail dir, and can't send emails
[13:09:08 CET] <Daemon404> eh
[13:09:12 CET] <Daemon404> thunderbird does this periodically
[13:09:18 CET] <Daemon404> as well.
[13:09:21 CET] <Daemon404> dont know why.
[13:09:40 CET] <wm4> the log keeps showing "** IMAP error on imap.gmail.com: FETCH error"
[13:09:56 CET] <wm4> could blame gmail
[13:10:06 CET] <wm4> on the other hand, claws' network code seems to be the worst ever
[13:11:02 CET] <Daemon404> you havent looked at irssi's then
[13:19:54 CET] <wm4> #define ALIGN (HAVE_AVX ? 32 : 16)
[13:20:00 CET] <wm4> this is in libavutil/mem.c
[13:20:12 CET] <Daemon404> but why
[13:20:16 CET] <wm4> so what happens if you compile lavu with AVX disabled, but lavc with AVX enabled?
[13:20:20 CET] <Daemon404> why not just always 32
[13:20:30 CET] <wm4> gotta go faster?
[13:20:36 CET] <Daemon404> [12:20] < wm4> so what happens if you compile lavu with AVX disabled, but lavc with AVX enabled? <-- how is this even possible
[13:20:46 CET] <wm4> they're completely different libs, formally
[13:20:48 CET] <J_Darnley> Why waste 16 bytes on alignment when you don't need it?  </s>
[13:24:53 CET] <Gramner> I wonder if aligning to 64 instead of 32 would actually improve cache hit rate since you'd always start on the beginning of a cache line
[13:25:14 CET] <Gramner> for modern cpus with 64-byte cache lines that is
[13:26:39 CET] <Daemon404> interesting idea...
[13:29:05 CET] <kierank> Gramner: what about THPs as well then
[13:29:20 CET] <rcombs> setting the locale in a lib is definitely super rude
[13:30:50 CET] <Gramner> kierank: what about it?
[13:31:07 CET] <kierank> well if you're aligning to 64, might as well do the THP stuff as well
[13:31:15 CET] <kierank> on linux at least
[13:32:11 CET] <Gramner> might want to consolidate mallocs as well in that case
[13:32:31 CET] <Gramner> no idea how many mallocs are done in typical use cases with ffmpeg
[13:32:37 CET] <kierank> not sure you can do that with buffer referencing
[14:09:54 CET] <cone-463> ffmpeg 03Paul B Mahol 07master:f7751a5e5368: avformat/aiffdec: give friendly message if compressed codec tag is unsupported
[15:08:18 CET] <cone-463> ffmpeg 03Ganesh Ajjanagadde 07master:c7131762c021: all: add const-correctness to qsort comparators
[15:15:58 CET] <cone-463> ffmpeg 03Ganesh Ajjanagadde 07master:104f8ea873ad: version.sh: add note that ffversion.h is auto-generated
[15:21:36 CET] <cone-463> ffmpeg 03Ganesh Ajjanagadde 07master:9bc3d3355f66: avcodec/huffman: replace qsort with AV_QSORT
[15:38:00 CET] <cehoyos> durandal_1707: Will you upload the sample?
[15:38:48 CET] <durandal_1707> no, first pay me
[15:39:06 CET] <cehoyos> So the ticket can be closed?
[15:40:18 CET] <durandal_1707> No, I'm uploading, arent you smart?
[15:41:24 CET] <durandal_1707> first failed because of nonsense limit
[15:41:25 CET] <cehoyos> I just couldn't know if you forgot to upload, that's why I asked...
[15:55:50 CET] <cehoyos> Did you already fix it or may I?
[15:56:39 CET] <wm4> ubitux: didn't you say you're doing something into direction of async API?
[16:03:48 CET] <durandal_1707> cehoyos: no, go ahead and fix it if you can
[16:07:20 CET] <cehoyos> I'll send a patch in a moment.
[16:25:36 CET] <ubitux> wm4: yes, work in progress
[16:27:17 CET] <wm4> ubitux: hm, into what direction is it going?
[16:28:29 CET] <durandal_1707> cehoyos: I have encoder/decoder if you want to re it
[16:30:47 CET] <cehoyos> That seems unnecessary: I just had to set "st->codec->extradata[14] = 224;" and bps has to be set.
[16:31:09 CET] <cehoyos> The waveformatex header sets bps to 16, all our wmapro samples have 24.
[16:31:16 CET] <ubitux> wm4: one async context, wrapping async "readers" (user set a pull packet callback, generally associated with a format context but can be anything), wrapping async codecs (user set push frame callback)
[16:31:33 CET] <cehoyos> The decoder needs the value, I set it to 24 but I don't know if 16 could be "more correct".
[16:32:02 CET] <ubitux> thread at every levels, and possibility for accel such as vtb to call the user callback themselves; and in standard codecs, it will be called post decode
[16:33:09 CET] <cehoyos> Patch sent.
[16:33:49 CET] <wm4> ubitux: not the API we discussed?
[16:34:09 CET] <durandal_1707> cehoyos: does it sounds louder if you change it?
[16:34:23 CET] <cehoyos> Where did you get the demuxer from?
[16:34:30 CET] <cehoyos> Not sure...
[16:35:58 CET] <ubitux> wm4: i'm trying to abstract more actually
[16:36:08 CET] <ubitux> and i'm not fond of the query granularity
[16:36:25 CET] <ubitux> i need to implement it myself to see if my model is viable so nothing more to propose so far
[16:36:39 CET] <ubitux> i'll probably realize soon if it's flawed
[16:36:46 CET] <nevcairiel> too much abstraction adds overhead, if i have to pass through 3 layers of threads to get to my decoded frame, thats bad =p
[16:36:48 CET] <wm4> if there's really a packet pull callback, it sounds hard to deal with in general
[16:36:50 CET] <cehoyos> 16 (as in the waveformatex header of the xwma file) is louder.
[16:37:10 CET] <wm4> (have to block it until the demuxer is ready, if the queue got empty, etc.)
[16:38:05 CET] <ubitux> i want to try it out, we'll discuss the details when i'm comfortable with what i wrote
[16:38:29 CET] <wm4> ok
[16:39:43 CET] <durandal_1707> cehoyos: what demuxer?
[16:41:10 CET] <cehoyos> You wrote above that have a "encoder/decoder", I thought you meant a demuxer...
[16:41:15 CET] <cehoyos> that you have
[16:41:27 CET] <cehoyos> We have a decoder in libavcodec anyway.
[16:44:47 CET] <durandal_1707> one from ms
[16:46:17 CET] <cehoyos> Perhaps you can compare which loudness is more similar to ms?
[16:53:39 CET] <BBB> Daemon404: I believe there was resistance from e.g. mru back in the days to making it 32 for everyone, since then arm would suffer for x86 (and admittedly, it makes no sense to have 32byte alignment on arm systems, and theres something to say to always using 16byte on these systems)
[16:53:52 CET] <durandal_1707> cehoyos: the ms one is louder
[16:53:58 CET] <BBB> Daemon404: as for x86 always using 32byte, yes, perhaps, I guess nobody cared
[16:56:30 CET] <durandal_1707> cehoyos: 16 is more correct
[16:57:36 CET] <durandal_1707> now if this can be found in xwma bitstream is another question
[17:08:26 CET] <cehoyos> Changed locally to "st->codec->extradata[ 0] = st->codec->bits_per_coded_sample;"
[17:15:23 CET] <durandal_1707> ok
[17:31:28 CET] <cone-463> ffmpeg 03Michael Niedermayer 07master:65ffca9f803a: avutil/tree: Document the guaranteed ordering of compare arguments for av_tree_find()
[17:38:28 CET] <cone-463> ffmpeg 03Carl Eugen Hoyos 07master:6498b34bba8c: lavf/xwma: Support wmapro.
[17:38:40 CET] <cehoyos> Pushed, thank you!
[17:46:02 CET] <cone-463> ffmpeg 03Ganesh Ajjanagadde 07master:bbd6bc6bd088: avutil/tree: clean up pointer incompatibility warnings
[17:48:07 CET] <BBB> rcombs: I looked briefly at the patches, I think its fine, but the memleak after init should probably be fixed, yes
[17:51:56 CET] <wm4> ./libavfilter/af_amerge.c:35:#define SWR_CH_MAX 64
[17:52:01 CET] <wm4> ./libswresample/swresample-test.c:34:#define SWR_CH_MAX 32
[17:52:03 CET] <wm4> what
[17:52:15 CET] <JEEB> wat :D
[17:52:22 CET] <wm4> ./libswresample/swresample.h:130:#define SWR_CH_MAX 32   ///< Maximum number of channels
[17:52:46 CET] <nevcairiel> swresample_internal.h defines it to 64 again =p
[17:53:18 CET] <wm4> ./libswresample/swresample_internal.h:28:#define SWR_CH_MAX 64
[17:53:20 CET] <wm4> yep
[17:53:30 CET] <wm4> the API enforced limit seems to be lower than 64
[17:53:32 CET] <nevcairiel> you can blame carl for that last one, apparently he bumped it in july
[17:54:25 CET] <nevcairiel> and nothing on the ML to be found on the why
[17:54:31 CET] <durandal_1707> cehoyos is here :)
[17:54:41 CET] <wm4> ah, looking into swresample.h, it's guarded by #if LIBSWRESAMPLE_VERSION_MAJOR < 1
[17:54:44 CET] <wm4> (wat)
[17:55:20 CET] <nevcairiel> i suppose the max is not meant to be part of the API anymore?
[17:55:27 CET] <wm4> probably
[17:56:24 CET] <nevcairiel> should remove the public header line then, its dead code anyway now
[17:59:14 CET] <wm4> oh I get it, init fails because lavu has std channel layouts only up to 8
[18:00:01 CET] <wm4> or something else
[18:05:08 CET] <kierank> wm4, j-b, others: any formats you care particularly about fuzzing
[18:05:28 CET] <kierank> the formats I care about h264, h264s, mp2audio, vp9 seem ok
[18:05:54 CET] <wm4> if there's an attacker, he could use anything libavcodec supports (and which happens to be enabled), so I have no opinion
[18:07:04 CET] <kierank> I don't care about attackers per se, more about corrupt data causing a crash
[18:08:54 CET] <durandal_1707> flv, there are some crashes already reported on libav tracker
[18:17:18 CET] <cehoyos> nevcairiel: Please search the mailing list, it's all there, I have to go sorry
[18:21:38 CET] <kierank> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/mem.c;h=323b18311bd2a31b4c13938c385f9d0f912de208;hb=HEAD#l95
[18:21:44 CET] <kierank> what's going on with this if(size)?
[18:24:45 CET] <BBB> kierank: its really true
[18:24:52 CET] <BBB> kierank: I filed a bug about that on apples ML at some point
[18:24:53 CET] <wm4> nice indentation
[18:24:58 CET] <BBB> kierank: it was obviously never addressed
[18:25:00 CET] <kierank> BBB: yeah I meant the indentation
[18:25:07 CET] <BBB> oh that, not sure, someone was lazy
[18:25:11 CET] <BBB> maybe me
[18:25:13 CET] <BBB> who knows
[18:25:14 CET] <kierank> looks weird, that's all
[18:25:23 CET] <wm4> the whole function looks "weird"
[18:25:32 CET] <BBB> the whole function is weird
[18:25:47 CET] <wm4>  155 #if CONFIG_MEMALIGN_HACK
[18:25:47 CET] <wm4>  156     //FIXME ...
[18:26:02 CET] <wm4> (nice one... if hack then fixme)
[18:28:13 CET] <wm4> fucking hell
[18:28:29 CET] <wm4> channel layouts should be uint64, but swresample's options treat it as int64
[18:28:36 CET] <wm4> and reject it if bit 63 is set
[18:29:12 CET] <BBB> hahahahahahhahahah
[18:32:58 CET] <wm4> does anyone happen to have a file with more than 8 channels?
[18:37:07 CET] <durandal_1707> there are brstm ones somewhere
[18:37:44 CET] <durandal_1707> and you can create them with aevalsrc
[18:41:29 CET] <wm4> durandal_1707: how?
[18:41:45 CET] <wm4> it wants a channel layout
[18:42:07 CET] <durandal_1707> just give number?
[18:42:38 CET] <Tom01> Hello people. Would it be possible to add copy-protection-detection to ffmpeg? I don't know if there is a copy-protection flag in vob or m4v files.
[18:42:50 CET] <wm4> durandal_1707: 'aevalsrc=1:channel_layout=16' results in "Audio: pcm_f64le, 44100 Hz, 1 channels (BL),"
[18:43:35 CET] <durandal_1707> you need to give 16 expressions
[18:43:39 CET] <wm4> ...
[18:43:50 CET] <wm4> and how?
[18:44:00 CET] <wm4> oh, | as separator
[18:44:11 CET] <wm4> still gives mono
[18:44:20 CET] <nevcairiel> layout 16 is not 16 channels though
[18:44:31 CET] <nevcairiel> try "16c" or something like that
[18:44:39 CET] <durandal_1707> hmm c16?
[18:45:04 CET] <nevcairiel> 16c means 16 channel, while 16 is just one channel, back left as t happens
[18:45:12 CET] <nevcairiel> (0x10)
[18:45:24 CET] <durandal_1707> ok
[18:46:34 CET] <durandal_1707> anyway bunch of fileters will reject unknown layouts
[18:47:23 CET] <durandal_1707> I changed few filters to accept anything
[20:44:42 CET] <wm4> michaelni: if you want, I could look into adding such an UINT64 AVOption type?
[21:01:34 CET] <cone-463> ffmpeg 03Nicolas George 07master:559603dae1f6: lavfi/drawutils: add const to blending mask.
[21:44:04 CET] <thardin> there, hopefully this alexis fellow can make sense of my mxfdec feedback
[21:45:56 CET] <Daemon404> make sense of mxf?
[21:45:58 CET] <Daemon404> unlikely.
[21:47:28 CET] <thardin> we can try
[21:47:48 CET] <thardin> but the mxf gods require offerings
[21:48:43 CET] <Daemon404> in the form of xml?
[21:55:22 CET] <thardin> some XSLT would be a fitting tribute
[22:16:48 CET] <michaelni> wm4, sure, if you like
[22:52:09 CET] <cone-463> ffmpeg 03Clément BSsch 07master:6b5412cbfa55: avutil/opt: print more meaningful default flags values
[23:23:46 CET] <BBB> ubitux: thanks for that :)
[23:30:52 CET] <ubitux> BBB: yw :)
[00:00:00 CET] --- Mon Oct 26 2015