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

[burek]

[00:20:00 CEST] <kurosu> well, I'm not blaming them for this - I just hope Alexandra is more interested by the technical aspect than projects' (mis)management
[00:22:04 CEST] <kurosu> In case some people want to see what it does in ffmpeg (dirac [bad] + huffyuv [good]): https://github.com/kurosu/ffmpeg/tree/gb
[00:28:36 CEST] <atomnuker> I'm not exactly liking the new bitstream API
[00:29:09 CEST] <atomnuker> are there plans to also implement put_bits into it?
[00:29:51 CEST] <atomnuker> I'm not sure what they find that doesn't make sense: you have PutBitContext and GetBitContext for whether you want to read or write bits
[00:30:01 CEST] <kurosu> the bitstream API is almost identical to get_bits, though the implementation details favor it in some cases
[00:30:19 CEST] <atomnuker> BitStreamContext doesn't imply whether you're writing bits or reading bits
[00:31:00 CEST] <kurosu> no idea about put_bits, though
[00:31:09 CEST] <kurosu> yeah, true
[00:31:31 CEST] <atomnuker> it's like they just changed the API to an API that has exactly the same functions but with a different, more ambiguious name
[00:31:38 CEST] <kurosu> then again, I'm more interested in the technical effect, not what it does to my programming
[00:33:12 CEST] <atomnuker> while the lower-level API (SHOW_BITS, SKIP_BITS, etc) was annoying to use it IIRC does speed up prores and dnxhd
[00:34:02 CEST] <atomnuker> so yeah, if the new api is faster without having to use macros directly that's fine
[00:34:19 CEST] <kurosu> the new API offers the same level of access but I only benchmarked it on huffyuv
[00:34:21 CEST] <atomnuker> but in that case they should have just removed the macros and merged the changed to e.g. get_bits
[00:34:31 CEST] <kurosu> agreed
[00:34:56 CEST] <kurosu> though in case it didn't always work, it's nice to have the 2 still available
[00:35:09 CEST] <kurosu> like it slows dirac decoding
[00:35:59 CEST] <atomnuker> are you talking about having 2 bitstream writing APIs in libavcodec?
[00:36:27 CEST] <atomnuker> that's the opposite of what anyone would want
[00:36:31 CEST] <kurosu> I think I know where you are going with this, but yes
[00:36:41 CEST] <kurosu> I'd want it just to not have speed regressions
[00:36:54 CEST] <kurosu> the gist on the implementation: don't waste your time reloading the cache when it's seldom needed
[00:37:12 CEST] <kurosu> except the extra work doesn't pay out when you actually are likely to need reloading
[00:37:22 CEST] <atomnuker> I'm working on writing a LUT-based golomb reader for dirac, so it's likely to get faster
[00:37:40 CEST] <atomnuker> it doesn't use any part of get_bits
[00:38:01 CEST] <kurosu> get_vlc2-based ?
[00:38:42 CEST] <atomnuker> nope
[00:39:04 CEST] <kurosu> so a local bitstream reading API then
[00:39:25 CEST] <nevcairiel> didnt we have lut based golomb readers already
[00:39:38 CEST] <kurosu> for the shorter codewords, yes
[00:39:54 CEST] <atomnuker> dirac uses different golomb codes
[00:40:58 CEST] <kurosu> still lut-based though, yet dissimilar to get_vlc2
[00:41:44 CEST] <kurosu> I thought there were opportunities there to decode 2+ symbols at a time there
[00:42:43 CEST] <atomnuker> well, basically, a single function to roll across each byte, and either directly outputting decoded numbers (if they're small) or reconstructing longer golomb codes (which get decoded by a riced function which needs to know their length)
[00:43:10 CEST] <kurosu> riced as in optimized or rice-golomb ?
[00:43:20 CEST] <atomnuker> optimized
[00:43:33 CEST] <kurosu> ok
[00:44:40 CEST] <kurosu> anyway, my interest in dirac was really to try out the new bitstream reading API, and I think it shows to be a case where it's slower
[00:45:14 CEST] <atomnuker> which is a good thing, if it helps to convince people we do not need to replace our current reader
[00:45:51 CEST] <atomnuker> or at least direct attention to optimize it rather than completely replace it
[00:46:24 CEST] <kurosu> well, it's most often faster so it's not black or white
[00:46:27 CEST] <nevcairiel> what I dislike the most about the change is the "need" to always replace entire APIs instead of just revising their implementation, its like everyone needs to leave their own mark on the API somewhere =p
[00:48:20 CEST] <kurosu> so how is hwaccel3 going ? :p
[00:48:38 CEST] <nevcairiel> such a thing exists?
[00:48:43 CEST] <nevcairiel> i thought someone was still working on 2
[00:48:46 CEST] <kurosu> no, I was just kidding
[01:49:17 CEST] <cone-158> ffmpeg 03Michael Niedermayer 07master:390703fcf5cd: avcodec/mpeg12dec: Do not choke on extra m704 alpha data
[01:49:17 CEST] <cone-158> ffmpeg 03Michael Niedermayer 07master:cb84c12fa2b8: avcodec/mpeg12dec: Print position in end mismatch error
[01:49:17 CEST] <cone-158> ffmpeg 03Michael Niedermayer 07master:9a499e0ae7dd: avformat/riff: add m704
[02:42:31 CEST] <hyponic> i am trying to transcode a stream and burn subtites from that stream. i just have no idea how to get it done. i have been googling for days without bein able to crack it. here is the stream: http://pastebin.com/JnpPYTx2
[04:54:48 CEST] <jamrial> atomnuker: "./ffmpeg -f lavfi -i 'sine=d=0.1' -c:a aac out.ts && ./ffmpeg -i out.ts" fails to detect the resulting file
[04:55:35 CEST] <jamrial> started with ffmpeg 3.0 according to https://ci.debian.net/packages/f/ffmpeg/unstable/amd64/
[04:57:34 CEST] <jamrial> also seems to happens with hls
[04:59:38 CEST] <jamrial> guess Andreas really just decided to quit after the whole vlc/threads debacle...
[05:14:02 CEST] <cone-349> ffmpeg 03KO Myung-Hun 07release/2.5:3b931399eb32: MAINTAINERS: add myself as an OS/2 maintainer
[05:14:02 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:a3db73c44dc7: swscale/x86/output: Move code into yuv2planeX_mainloop
[05:14:02 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:39664fb6472a: swscale/x86/output: Fix yuv2planeX_16* with unaligned destination
[05:14:02 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:e44775580f6c: avutil/pixdesc: Make get_color_type() aware of CIE XYZ formats
[05:14:02 CEST] <cone-349> ffmpeg 03Carl Eugen Hoyos 07release/2.5:d8586b7aca36: postproc: fix unaligned access
[05:14:03 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:8c40fc62ceb0: swscale/input: Fix GBRAP16 input
[05:14:03 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:0b51d15a0e57: swscale/utils: Fix chrSrcHSubSample for GBRAP16
[05:14:04 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:0438cc2bc0ee: avcodec/avpacket: clear priv in av_init_packet()
[05:14:05 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:4c6870695859: avcodec/mjpegdec: Fix decoding slightly odd progressive jpeg
[05:14:05 CEST] <cone-349> ffmpeg 03Rodger Combs 07release/2.5:b42ade51eb5b: lavf/mov: fix sidx with edit lists (cherry picked from commit 3617e69d50dd9dd07b5011dfb9477a9d1a630354)
[05:14:06 CEST] <cone-349> ffmpeg 03Boris Nagels 07release/2.5:1578642853d3: avformat/rtpenc: Fix integer overflow in NTP_TO_RTP_FORMAT
[05:14:08 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:59648ab954ca: avformat/concatdec: set safe mode to enabled instead of auto
[05:14:09 CEST] <cone-349> ffmpeg 03Martin Cracauer 07release/2.5:3433e52d48ac: avutil/channel_layout: AV_CH_LAYOUT_6POINT1_BACK not reachable in parsing
[05:14:10 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:3097c10ee341: avutil/random_seed: Add the runtime in cycles of the main loop to the entropy pool
[05:14:11 CEST] <cone-349> ffmpeg 03PrzemysBaw Sobala 07release/2.5:bbc3395a0bb0: avcodec/imgconvert: Support non-planar colorspaces while padding
[05:14:12 CEST] <cone-349> ffmpeg 03Luca Barbato 07release/2.5:55937c49df42: indeo2data: K&R formatting cosmetics
[05:14:12 CEST] <cone-349> ffmpeg 03Luca Barbato 07release/2.5:d604b84f9191: indeo2: Fix banding artefacts
[05:14:14 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:e1d771e8183a: avcodec/resample: Remove disabled and faulty code
[05:14:15 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:2cdeb2c4f87a: avcodec/mjpegenc_common: Store approximate aspect if exact cannot be stored
[05:14:16 CEST] <cone-349> ffmpeg 03Ico Doornekamp 07release/2.5:f41e7b14db22: avformat/rtpdec_jpeg: fix low contrast image on low quality setting
[05:14:16 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:7b551ba7320b: avcodec/libutvideodec: copy frame so it has reference counters when refcounted_frames is set
[05:14:18 CEST] <cone-349> ffmpeg 03Aaron Boxer 07release/2.5:eae0a6582df3: avcodec/j2kenc: Add attribution to OpenJPEG project:
[05:14:19 CEST] <cone-349> ffmpeg 03Marios Titas 07release/2.5:dc751a55e5ae: avfilter/src_movie: fix how we check for overflows with seek_point
[05:14:19 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:1e46629234aa: avcodec/bmp_parser: Ensure remaining_size is not too small in startcode packet crossing corner case
[05:14:21 CEST] <cone-349> ffmpeg 03Ivan 07release/2.5:2bb9f5d6074a: avcodec/h264: Fix for H.264 configuration parsing
[05:14:22 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:9ae85f1468f4: avcodec/avpacket: Fix off by 5 error
[05:14:23 CEST] <cone-349> ffmpeg 03Paul B Mahol 07release/2.5:72b600de29c6: avcodec/apedec: fix decoding of stereo files with one channel full of silence
[05:14:24 CEST] <cone-349> ffmpeg 03Paul B Mahol 07release/2.5:e196cd52348d: avcodec/takdec: add code that got somehow lost in process of REing
[05:14:25 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:1d3843fc939e: avfilter/vf_drawtext: Check return code of load_glyph()
[05:14:26 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:7e5e531ec68b: avcodec/ac3dec: Reset SPX when switching from EAC3 to AC3
[05:14:27 CEST] <cone-349> ffmpeg 03Jan Ekström 07release/2.5:cba830c4636a: pgssubdec: fix subpicture output colorspace and range
[05:14:28 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:fb15a0f42af3: avcodec/ttaenc: Reallocate packet if its too small
[05:14:29 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:95a8dace5cc7: avformat/ffmdec: Check pix_fmt
[05:15:06 CEST] <cone-349> ffmpeg 03foo86 07master:de28e73cce03: avcodec/dcaenc: reuse shared quant levels table
[05:15:07 CEST] <cone-349> ffmpeg 03foo86 07master:b286ff69c03e: avcodec/dcaenc: move channel reordering tables to dcaenc.h
[06:19:56 CEST] <kierank> maybe we should just revert that patch
[06:20:01 CEST] <kierank> there's enough community objection
[09:24:51 CEST] <kurosu> atomnuker, kierank, is there an issue with the threading in diracdec.c? On a 6cores machine, for 1-4 threads I get large increases in utime and real over a single thread
[09:25:08 CEST] <kurosu> I only get an improvement on "real" for 5+ threads
[09:27:04 CEST] <kurosu> also, can anyone confirm?
[09:27:23 CEST] <kurosu> On a single thread, the new bitstream api is a wash so far
[09:27:35 CEST] <kurosu> (but not the 15% decrease I was seeing)
[09:35:22 CEST] <Timothy_Gu> Dammit... deleted /etc/ just after upgrading the entire system to ubuntu 16.04 :(((
[10:00:33 CEST] <rcombs> that's recoverable, but not easily
[10:51:19 CEST] <cone-163> ffmpeg 03Paul B Mahol 07master:8f4358888f37: avcodec/wmalosslessdec: fix type for coeffs and lms_updates in cdlms struct
[11:18:57 CEST] <cone-163> ffmpeg 03Christophe Gisquet 07master:532e9370835d: avcodec/wmalosslessdec: silence a sample request
[12:00:25 CEST] <kurosu> durandal_1707, sent the samples to michaelni some time ago
[12:00:49 CEST] <kurosu> also before adding it, could you add the sample that helped detect the issue?
[12:01:17 CEST] <kurosu> *also before adding these new tests, could you add one for the sample that helped detect the issue?
[12:02:31 CEST] <kurosu> I can also send the samples as a zip file to the list (it's 81K)
[12:03:40 CEST] <durandal_1707> Yes, I have two very small samples
[12:04:28 CEST] <kurosu> that'd be nice, and I would have done it in one go, except I haven't followed at all the trac thread
[12:12:01 CEST] <nevcairiel> if you need samples uploaded to fate, i can do that as well
[12:33:18 CEST] <durandal_170> michaelni: there is some smc security bug, on Twitter
[12:35:13 CEST] <michaelni>  durandal_170 link ?
[12:36:40 CEST] <durandal_170> CVE-2016-1528
[12:37:18 CEST] <durandal_170> michaelni: ^
[12:38:26 CEST] <michaelni> i know nothing about this, where is information what this is about ?
[12:38:53 CEST] <nevcairiel> that cve is some android thing
[12:39:35 CEST] <nevcairiel> oh wait wrong one
[12:39:38 CEST] <nevcairiel> google tricked me
[12:40:07 CEST] <durandal_170> http://www.talosintel.com/reports/TALOS-2016-0043/
[12:41:18 CEST] <nevcairiel> they claim to have tried to establish contact already back in september
[12:51:22 CEST] <michaelni> Theres no mail from talos or cisco to ffmpeg-security, there is one mail from cisco to ffmpeg-devel-owner at ffmpeg.org on the  13 Jan 2016, thats long after the claimed contact
[12:53:22 CEST] <durandal_170> perhaps this was fixed?
[12:53:40 CEST] <michaelni> i belive none of the testcases they reported  in january where reproduceable when we got them
[12:55:14 CEST] <michaelni> the reply in january points to c727401aa9d62335e89d118a5b4e202edf39d905 and d99fbbf4d7e3f6abea0d052849a515730f552608  as potential fixes, our question about if they can confirm that was fixed seems not to have a reply also i cant find a reply to our question about which version they tested
[12:57:48 CEST] <michaelni> no mails in my spam folder from cisco either t seems
[13:01:22 CEST] <atomnuker> jamrial: it also happens with libfdk_aac at low bitrates
[13:03:13 CEST] <atomnuker> kurosu: can you post what you get for different number of threads?
[13:03:25 CEST] <atomnuker> also make sure your file isn't a single frame
[13:33:44 CEST] <atomnuker> jamrial: it's a ts muxer problem, since it happens with opus and vorbis as well
[13:38:33 CEST] <atomnuker> oh, carl already did something to try to fix that
[14:41:06 CEST] <kurosu> atomnuker, numbers are threads:real/utime
[14:41:12 CEST] <kurosu> master: 1:12.0/11.5  2:13.1/20.6  3:11.5/25.7  4: 7.7/23.2
[14:41:20 CEST] <kurosu> bitstream: 1:11.1/10.6  2:16.6/27.2  3:15.8/36.3  4:13.8/43.3
[14:41:53 CEST] <kurosu> so there might be a bug in the bitstream branch from my own, but the scaling even in master isn't exactly nice
[14:42:02 CEST] <wm4> I have to admit I find "bitstream_peek" a much more intuitive name than "show_bits"
[14:42:24 CEST] <kurosu> s/show_/peek_/ :D ?
[14:44:37 CEST] <durandal_170> you like typing sausages?
[14:46:00 CEST] <atomnuker> that's an odd scaling, no idea why bitstream would be slower
[14:46:26 CEST] <atomnuker> but the threading is really needed to get anywhere near realtime speed on 1080p even on a fast modern machine
[14:47:42 CEST] <kurosu> yes, but I'm wondering if there's no extra work being done
[14:48:05 CEST] <kurosu> like: init_get_bits(&slices[slice_num].gb, buf, bufsize);
[14:48:24 CEST] <kurosu> that shouldn't be bufsize but 8*bytes as far as I understand
[14:48:55 CEST] <kurosu> no consequence iirc, but 2 threads being slower is mighty weird
[14:49:04 CEST] <iive> the buffer is in bytes, so there is no need for extra operation.
[14:49:18 CEST] <kurosu> although a slice seems to be 32x32, which is a small granularity for a thread and might incur too much overhead
[14:49:42 CEST] <kurosu> iive, I'm just wondering if data is not decoded multiple times
[14:49:42 CEST] <atomnuker> the current default is 32x16 slices
[14:49:51 CEST] <kurosu> ok
[14:50:23 CEST] <wm4> clearly you should use a lock-free queue to minimize the overhead of distributing these small units to workerthreads
[14:50:28 CEST] <kurosu> I have no idea what's going on, just that those numbers sound fishy
[14:51:10 CEST] <kurosu> hence why I asked people to see if they observe similar behaviour
[14:51:44 CEST] <kurosu> doing one line of slices at a time could be another option
[14:52:07 CEST] <kurosu> but I don't think that alone can really explain those numbers
[14:52:33 CEST] <atomnuker> I do that in the "trimmed" dirac decoder I have: https://github.com/atomnuker/ffmpeg_dirac_trimmed
[14:52:35 CEST] <iive> kurosu:  perf does have statistics of caches, this might be one explanation.
[14:52:59 CEST] <atomnuker> it does one slice at a time and also does the idwt in parallel
[14:54:04 CEST] <kurosu> anyway, I don't think I want to spend much more time on vc2, my goal was just validating the bitstream reader
[14:54:32 CEST] <cone-687> ffmpeg 03Clément BSsch 07master:bbf02f7d2886: lavc: override decode return value only in case of error
[14:54:34 CEST] <kurosu> and I think I can't really make any conclusion
[14:54:47 CEST] <kurosu> the one-thread performance of the new bitstream reader is better
[14:55:54 CEST] <iive> kurosu: you might want to run the tests more times, to calculate a margin of error
[15:18:05 CEST] <cone-687> ffmpeg 03Clément BSsch 07master:9f3dd530500e: lavc/srtenc: do not emit any subrip tags with text codec
[15:29:31 CEST] <cone-687> ffmpeg 03Carl Eugen Hoyos 07master:47a11ff4574b: lavc/fic: Be less verbose for invisible cursor outside of video.
[15:31:02 CEST] <cone-687> ffmpeg 03Carl Eugen Hoyos 07master:00ffbdfb68ca: lavc/fic: Do not warn about empty cursor.
[15:40:32 CEST] <cone-687> ffmpeg 03Carl Eugen Hoyos 07master:88a849c714c1: lavf/mpegts: Return small probe score for very short transport streams.
[16:05:36 CEST] <durandal_170> why I get connection reset when pulling from git?
[16:31:10 CEST] <cone-687> ffmpeg 03Paul B Mahol 07master:423a6a099381: avformat/dsfdec: set bit_rate, fixes duration estimation
[16:31:12 CEST] <cone-687> ffmpeg 03Paul B Mahol 07master:25482d5c42cc: avformat/wsddec: set bit_rate, fixes duration estimation
[17:48:00 CEST] <rcombs> updating my application to use codecpar, and noticing that it's missing a way to get the stream's max number of ref frames and rc_max_rate
[17:48:39 CEST] <rcombs> the former seems reasonable enough just to export; the latter is a bit wonky (mpeg2video exports it instead of bit_rate)
[17:49:01 CEST] <JEEB> wait, IIRC you're  getting an avcodec context in most cases, no?
[17:49:12 CEST] <JEEB> if you're decoding or encoding
[17:49:23 CEST] <JEEB> not sure if the codecpar touches at all the general use cases
[17:49:32 CEST] <cone-687> ffmpeg 03Michael Niedermayer 07master:52623ef78546: avcodec/smc: Mark pixel pointer as const
[17:49:33 CEST] <rcombs> this is in the context of using lavf for media analysis
[17:49:54 CEST] <rcombs> just calling find_stream_info and pulling most of what that provides
[17:50:00 CEST] <JEEB> right
[17:50:38 CEST] <JEEB> I think there was a requires_decoding or so field?
[17:50:51 CEST] <JEEB> I remember looking at ffmpeg.c and it was using it
[17:51:10 CEST] <rcombs> no matches for that exact string
[17:51:11 CEST] <kurosu> durandal_170, so for another fate test, I guess the raw pcm tile one is better
[17:51:18 CEST] <rcombs> but there could be something similar
[17:51:18 CEST] <kurosu> durandal_170, which stream would that be?
[17:51:36 CEST] <rcombs> my problem is that refs and rc_max_rate are on AVCodecContext, and stream->codec is now deprecated
[17:51:36 CEST] <JEEB> rcombs: it was decoding_neede
[17:51:39 CEST] <JEEB> *needed
[17:51:55 CEST] <rcombs> (I'm not sure if properties on stream->codec that aren't in codecpar are even exported anymore)
[17:51:56 CEST] <JEEB> it's in the stream
[17:52:37 CEST] <rcombs> that's ffmpeg.c-internal
[17:52:45 CEST] <JEEB> ok, right
[17:52:46 CEST] <rcombs> not sure what it has to do with analysis
[17:53:03 CEST] <JEEB> it was just in the streams so I thought that was AVStream-specific
[17:53:05 CEST] <JEEB> sorry
[17:53:08 CEST] <rcombs> np
[17:55:28 CEST] <rcombs> hmm, yeah, the stream->codec data is filled by `avcodec_parameters_to_context(st->codec, st->codecpar);`
[17:55:38 CEST] <rcombs> so it's useless for getting data that's not actually in codecpar
[17:55:46 CEST] <rcombs> that's an API break
[18:23:21 CEST] <durandal_170> kurosu: g2-24bit.wma IIRC
[18:24:01 CEST] <durandal_170> Downloadable from ticket
[18:26:01 CEST] <kurosu> ok, I'll send an updated patch fate with that (and I guess anyone can add the file to fate-suite)
[18:45:26 CEST] <cone-687> ffmpeg 03Michael Niedermayer 07master:3187277ebb7f: avcodec/wmalosslessdec: Fix memset sizeof
[19:06:59 CEST] <nevcairiel> rcombs: rc_max_rate is exported using side data
[19:07:07 CEST] <rcombs> oh, is it?
[19:07:14 CEST] <nevcairiel> max refs is unreliable info at best and using it is probably wrong =p
[19:07:28 CEST] <JEEB> yeah
[19:07:51 CEST] <rcombs> where?
[19:12:43 CEST] <rcombs> nevcairiel: re: rc_max_rate in side data, where is that?
[19:13:11 CEST] <nevcairiel> forgot what its called, but its not like the list of packet side data iis infinte, so look at the header :D
[19:15:13 CEST] <nevcairiel> cbp something
[19:15:22 CEST] <durandal_170> so ffmpeg git will be moved to gitlab?
[19:15:54 CEST] <rcombs> closest thing I see is AV_PKT_DATA_CPB_PROPERTIES
[19:16:14 CEST] <rcombs> which afaict is for encode?
[19:21:59 CEST] <rcombs> nevcairiel: is `refs` unreliable even as an upper bound?
[19:22:33 CEST] <rcombs> (I'm probably fine dropping rc_max_rate on decode, since it was used in a field generally intended for average bitrate and thus wasn't particularly useful)
[19:32:40 CEST] <rcombs> nevcairiel: we primarily use the refs information for Roku, where older models have a hard limit of 8 ref frames (i.e. they're not-quite-compliant L4.1 decoders)
[19:34:21 CEST] <DHE> 8 frames is quite a lot. I know h264 allows up to 15 but doesn't diminishing returns set in quickly?
[19:34:34 CEST] <rcombs> DHE: L4.1 allows up to 9 for 720p video
[19:34:44 CEST] <nevcairiel> well the key argument here is that avformat is not meant to give you codec level information, but container information
[19:35:00 CEST] <rcombs> for that purpose, would you expect the refs field exported by the H.264 decoder to be sufficient as an upper bound?
[19:35:20 CEST] <rcombs> it calls the decoder and has historically exported that information from it
[19:35:38 CEST] <rcombs> (what container reports ref frame count?)
[19:36:03 CEST] <nevcairiel> it doesnt, hence its no longer provided
[19:36:27 CEST] <DHE> I don't think it's actually a stored value in the stream though. wouldn't it just be something discovered while decoding? hence a short sample would not be very reliable
[19:36:33 CEST] <DHE> or certainly not consistent
[19:36:40 CEST] <rcombs> there's a max in SPS iirc
[19:37:35 CEST] <DHE> huh... okay then
[19:38:13 CEST] <rcombs> but now I'm wondering if it's actually reliable
[19:40:43 CEST] <rcombs> generally I expect avformat_find_stream_info to report this sort of information, though it probably makes more sense to get it from the parser instead of invoking the decoder in a lot of cases
[19:42:29 CEST] <rcombs> I could call the decoder (or parser) myself, but that's additional work the consumer has to do and ends up being a regression in functionality
[19:43:23 CEST] <nevcairiel> generally we want avformat to provide container information, not any codec property, so this information no longer being available is the design going forward
[19:44:01 CEST] <rcombs> that makes enough sense, but could you imagine an additional API to do what find_stream_info does now?
[19:44:36 CEST] <rcombs> (read packets and parse or decode until all available information is exported)
[19:44:49 CEST] <nevcairiel> not likely
[19:45:07 CEST] <wm4> it would make sense to request different levels of information retrieval from lavf
[19:45:13 CEST] <rcombs> obviously the consumer can do that itself, but it's still annoying to have something that used to be done and no longer is
[19:45:28 CEST] <wm4> some API users really care only about the most basic info, some want full analyzation
[19:45:31 CEST] <rcombs> wm4: sure
[19:45:55 CEST] <michaelni> durandal_170, iam not aware of any git move, why do you think so ?
[19:46:32 CEST] <Shiz> seems rather inane
[19:47:08 CEST] <Shiz> ffmpeg already has a hosted git, why move to another one
[19:47:24 CEST] <durandal_170> michaelni: IIRC videolan is doing it
[19:47:27 CEST] <JEEB> probably videolan's gitlab was meant?
[19:47:38 CEST] <Shiz> bleh
[19:47:39 CEST] <JEEB> since they're moving their own stuff to it IIRC
[19:47:50 CEST] <Shiz> their own gl instance or gitlab.com?
[19:48:19 CEST] <JEEB> https://code.videolan.org/
[19:49:00 CEST] <Shiz> blank page :D
[19:49:09 CEST] <Shiz> oh it finally loaded
[19:49:13 CEST] <rcombs> iow everything stays the same except the web UI gets shinier
[19:49:29 CEST] <Shiz> and the urls change
[19:49:46 CEST] <Shiz> and now you can star repos!!
[19:49:57 CEST] <rcombs> stars are shiny
[19:50:50 CEST] <Shiz> i like how VLC itself isn't on there yet
[19:57:29 CEST] <jamrial_> not sure if fully move, but adding a mirror there may be a good idea
[20:01:08 CEST] <DHE> does libavfilter not support unlabeled graphs like the CLI does?
[20:14:18 CEST] <wm4> DHE: the cli uses libavfilter
[20:14:21 CEST] <wm4> so, yes
[20:31:17 CEST] <jsebechlebsky> Hello, found several strange things in av_bsf_alloc, is someone familiar with this code here?
[20:32:15 CEST] <jsebechlebsky> it's libavformat/bsf.c
[20:32:16 CEST] <durandal_170> what is problem?
[20:34:32 CEST] <jsebechlebsky> these are lines 112 - 123 in libavcodec/bsf.c: http://pastebin.com/2a0WBWbG
[20:36:07 CEST] <jsebechlebsky> it allocates the private data of size priv_data_size and then copies pointer to priv_class pointer of the filter to the data.
[20:36:59 CEST] <jsebechlebsky> So if I understand it right the priv_data field points to allocated pointer to filter->priv_class
[20:37:31 CEST] <jsebechlebsky> first issue was I was getting invalid write on line 120 when I was running noise bsf under valgrind.
[20:38:11 CEST] <jsebechlebsky> Turns out that priv_data size in noise_bsf.c is set to sizeof(int), so it obviously fails when attempting to store 64-bit pointer
[20:39:40 CEST] <jsebechlebsky> but another issue is that av_opt_set_defaults is called on that pointer (which from the documentation should be only called on structure which contains AVOptions * as first member 
[20:40:35 CEST] <jsebechlebsky> This call is also source of invalid reads/writes
[20:43:32 CEST] <jsebechlebsky> I thought maybe someone just forgotten to deallocate *ctx->priv_data, but this is also wrong since AVClass's first member is not AVOptions*. Also this allocation of pointer seems weird (why not to assign pointer directly?), but there can be a reason for that (priv_data is automatically freed at some point and we don't want the AVClass structure to be freed for example?)
[20:44:14 CEST] <jsebechlebsky> But since I feel like there are several strange issues concentrated on single place I wanted to ask if someone knows what is going on there :)
[20:46:14 CEST] <nevcairiel> the only bug i can see is that noise bsf should use sizeof(NoiseContext)
[21:16:46 CEST] <jsebechlebsky> nevcairiel: you're right that is the only problem... the reads/writes I was getting were actually accesses to another members of NoiseContext structure... and I misread the documentation on av_opt_set_defaults :)
[21:18:40 CEST] <jsebechlebsky> So sorry for a long post for a small problem :) Should I send the patch or is here someone who can push it directly to repository?
[21:36:02 CEST] <DHE> wm4: I was just trying it and got back: Invalid filterchain containing an unlabelled output pad: "aformat=channel_layouts=stereo:sample_fmts=s16;volumedetect;volume=10"
[21:36:22 CEST] <DHE> when I put in various [out1] [out2] labels it worked
[21:36:33 CEST] <DHE> this is git less than a week old
[21:38:23 CEST] <wm4> where?
[21:38:37 CEST] <wm4> are you using ffmpeg cli or API?
[21:39:22 CEST] <DHE> API
[21:39:51 CEST] <DHE> using the template from the examples to build an audio pipeline instead of video. it worked fine for one filter. I tried expanding it and ran into that
[21:40:12 CEST] <DHE> not a showstopper, but surprising
[21:42:41 CEST] <wm4> huh
[21:42:46 CEST] <wm4> let me check what I do
[21:43:46 CEST] <wm4> seems like I use avfilter_graph_parse_ptr here
[21:44:42 CEST] <wm4> and I pass an input named "in" and an output named "out" to it
[21:45:13 CEST] <wm4> oh maybe you should use , instead of ;
[21:45:22 CEST] <wm4> (not that I know what the difference is)
[21:46:16 CEST] <ubitux> ';' separate parts, ',' is for stacking filter one after another
[21:46:41 CEST] <ubitux> and yes you want to use a comma in your example
[21:46:48 CEST] <DHE> hmm... that makes sense.
[21:47:37 CEST] <wm4> ubitux: what are "parts"
[21:47:55 CEST] <ubitux> wm4: independant branches of your graph
[21:48:06 CEST] <DHE> for when your filter graph is actually complex
[21:48:22 CEST] <ubitux> like, "[a] filter1, filter2, filter3 [b]; [x] filterX, filterY, filterZ [y]"
[21:48:23 CEST] <wm4> I thought if there are no labels, the filters are chained implicitly
[21:48:40 CEST] <ubitux> here you have 2 sources [a] and [x] and two outputs [b] and [y]
[21:48:46 CEST] <DHE> it makes sense that ; and , are interpreted differently. there can be multiple inputs or outputs
[21:52:52 CEST] <DHE> yeah you're right, comma is what I did wrong
[22:25:50 CEST] <cone-562> ffmpeg 03Paul B Mahol 07master:bc2fe3622842: avcodec/noise_bsf: set correct size of .priv_data_size field
[23:02:00 CEST] <durandal_170> atomnuker: still working on ffa1?
[23:12:28 CEST] <atomnuker> durandal_170: the fun starts after I port kiss_fft's NxN dimension integer transforms
[23:12:47 CEST] <atomnuker> haven't had time to do anything those last few weeks though
[23:14:43 CEST] <durandal_170> why would use fft? Isn't it going to be lossless codec?
[23:16:03 CEST] <durandal_170> I was thinking about using lpc and arithmetic coding
[23:18:59 CEST] <atomnuker> that wouldn't buy you much gains, rice coding already small lpc coeffs and quantized errors is pretty efficient already
[23:19:34 CEST] <atomnuker> the problem is that you can't do much prediction in the time domain unless the signal is really really steady or has a sharp single tone
[23:20:56 CEST] <atomnuker> but with frequency domain you'd have quite a lot of repetition between each frame
[23:21:22 CEST] <atomnuker> at least for the lower frequencies, below maybe 5-6 khz
[23:21:59 CEST] <atomnuker> so if you had a very large frame size I was thinking of doing what you usually do with images
[23:22:07 CEST] <atomnuker> *video
[23:22:53 CEST] <atomnuker> subdivide your frame into blocks, which vary in size (you can do TF switching to switch between predicted coefficients for blocks with different sizes)
[23:23:28 CEST] <atomnuker> pick a few blocks to use as a reference to derive similar blocks
[23:24:29 CEST] <atomnuker> and yeah, I was thinking of doing the same thing flac does with the residuals to see what efficiency I would get
[23:25:13 CEST] <atomnuker> since if your residuals are really small you can't really get much better than rice coding
[23:26:20 CEST] <atomnuker> (as they'll be very uniformly spread on the frequency axis it wouldn't be worth using a contexed arithmetic coding, I think)
[23:31:27 CEST] <atomnuker> all quantization (level picked by an estimation on how expensive the residuals would be) and prediction would be done using daala's pvq
[23:32:48 CEST] <atomnuker> the huge frame size would be just temporary as it would make development easier, and would probably be replaced with P-frames further on
[23:35:45 CEST] <atomnuker> LPC would still have its place as a coding tool but in the frequency domain (like AAC's TNS), in case it's cheaper to transmit LPC coefficients to filter a block to derive a new block
[00:00:00 CEST] --- Mon May  2 2016