[00:43] <BBB> what is CNU in the init_values[] table in hevc_cabac.c? it seems to mean does not exist or has no meaning (since its for inter stuff in i-slices), but theres a real value of 154 associated with it, I wonder why [01:02] <smarter> context not used I think [01:03] <smarter> the associated value is 154 because that's what the HM uses, I don't think it matters [01:03] <BBB> Im about to wtf on cabac_init_state() [01:03] <BBB> is that also hm copypaste? [01:04] <smarter> what's wrong with it? [01:04] <BBB> I understand we hav 2 4 bit values and hardware people want to store them as such [01:04] <BBB> but we are not hardware people [01:05] <smarter> that's how it's defined in the spec, you could use tables yeah [01:05] <BBB> its obfuscated [01:05] <Daemon404> so is the spec [01:05] <BBB> nobody can figure out the meaning of these numbers [01:05] <BBB> plus its slow, to get the actual number you need multiplications, adds, shifts [01:05] <Daemon404> [00:05] <@BBB> nobody can figure out the meaning of these numbers <-- liek vp9*.c? [01:05] Action: Daemon404 runs [01:06] <BBB> vp9.c [01:06] <BBB> and ask [01:06] <smarter> it made more sense when these values where not fixed and it wasn't worth regenerating tables everytime they changed [01:06] <BBB> I actually udnerstant he vp9 spec pretty deeply [01:06] <BBB> hevc, not so much [01:06] <Daemon404> what spec [01:06] <Daemon404> i see no spec [01:06] <BBB> the one in my head :) [01:06] <BBB> fine, I agree, theres no spec [01:06] <BBB> I understand the vp9 bitstream format pretty deeply [01:06] <Daemon404> the yactually put a bitstream guide out under NDA [01:06] <BBB> ask [01:07] <Daemon404> why NDA i dunno [01:07] <Daemon404> i did ask during code review, but it was 'magic number' :P [01:07] <smarter> lawyers. [01:07] Action: Daemon404 is not actually interested [01:07] <BBB> ... [01:07] <BBB> anyway, the values in that hevc decoder that we engulfed& are & meaningless? [01:07] <smarter> the magic numbers are just probabilities that were determined based on experiments [01:07] <Daemon404> probably [01:07] <BBB> I cant make much of them, except magic :) [01:07] <smarter> both in vp9 and hevc [01:08] <Daemon404> smarter, the vp9 guide is just as bad (or worse) than vp8's [01:08] <Daemon404> or so im told [01:08] <BBB> but it seems slow to store them in 8bits and do calculations on them [01:08] <BBB> Id store them in 2x8 bits as actual offset and mltiplier [01:08] <BBB> I bet half of the qp multipliers are 1 [01:08] <BBB> but what do I know [01:08] <BBB> er& zero [01:08] <BBB> anyway [01:09] <smarter> Daemon404: I'm not convinced that MPEG-like specs are that much better [01:10] <Daemon404> at least they tend to actually match implementations. [01:10] <BBB> I just reverse engineer by reading ffmpeg code :) [01:10] <Daemon404> there is a good hevc writeup by the f265 people iirc [01:11] <Daemon404> http://www.f265.org/f265/static/txt/h265_companion.html [01:11] <smarter> I like " A short rant about the specification " [01:11] <Daemon404> yes [01:12] <BBB> is that the document thats really funny once you understand the h265 spec? [01:12] <BBB> I think I tried reading it once [01:13] <Daemon404> it contains useful translations to actual english [01:13] <Daemon404> it helped me a bit [01:15] <BBB> maybe I should sell myself off in public as (with ubitux) one of the only two people int he world that does not work at google and understands vp9 [01:15] <BBB> I wonder if thats worth any penny [01:15] <smarter> I think that guy understands vp9 alright too: http://forum.doom9.org/showthread.php?t=168947 [01:16] <BBB> shite, there goes that plan [01:17] <Daemon404> Occupation: Hardware video codec engineer [01:17] <Daemon404> (from his profile) [01:17] <smarter> Intel guy [01:18] <Daemon404> im surprised he didnt suddenly vanish under NDAs then [02:57] <kierank> smarter: mpeg specs are designed so n people can implement in secret [02:58] <kierank> whereas vp9 etc as far as I can tell is designed for people to implement in a more open atmosphere, warts and all [04:28] <cone-75> ffmpeg.git 03gerion.entrup@t-online.de 07master:f2855eb4d712: avformat/movenc: add m4b to list of ipod playable files [11:04] <cone-729> ffmpeg.git 03Carl Eugen Hoyos 07master:355121bcb5d9: lavf/mux: Fix a typo checking aspect ratios. [12:33] <nevcairiel> hrm, binutils 2.24 doesn't build with gcc 4.9.1 for me, some compile error, what a disappointment [13:10] <cone-729> ffmpeg.git 03Carl Eugen Hoyos 07master:ff9a154157ec: Add int64_t probesize2 instead of int probesize to AVFormatContext. [15:44] <cone-729> ffmpeg.git 03Nicolas George 07master:91244073fd8b: ffmpeg_filter: refuse to configure input without a decoder. [15:52] <saste> do you know if it is possible to use ffserver to stream directly from a browser? [15:52] <saste> at least using ffmpeg+ffserver+ffplay this seems possible, but things are tricky with working with browsers [15:52] <saste> for streaming i mean live video/audio [17:14] <ubitux> vf deshake question [17:14] <ubitux> there is a sad using the blocksize as height [17:14] <ubitux> this makes no sense to be because it is always 16-byte width [17:14] <ubitux> (sad[0]) [17:15] <ubitux> and btw, unless i'm mistaken sad[0] is likely the sse version [17:15] <ubitux> which can only work with aligned data [17:16] <ubitux> won't this cause troubles? [17:17] <ubitux> so 2 changes would sound relevant to me: fallback on the 8-byte width, at least for now, and then force the 8 height (or 16 height if we make a 16-byte-width working with unaligned addresses - which i'm working on) [17:17] <ubitux> does that make any sense? [17:27] <nevcairiel> kierank: i'm pondering on closed caption data from H.264 streams, didn't you talk about that some time ago? [17:32] <kierank> yes just a case of adding the same support that mpeg-2 has [17:33] <nevcairiel> does it use the same format internally? [17:35] <kierank> Similar [17:35] <kierank> See ETSI TS 101 154 [17:35] <nevcairiel> similar enough to use the same side data message? =) [17:35] <kierank> There are a couple of bytes you need to skip [17:35] <kierank> Yes [17:36] <nevcairiel> i was browsing the stuff, found the place where to hook it up in the decoder and everything [17:39] <kierank> What are you going to decode with? [17:39] <kierank> Decode the captions [17:40] <nevcairiel> so i skip the headers and just store the 3 byte * count in the side data, that seems to be what mpeg2 doe [17:40] <nevcairiel> does* [17:40] <nevcairiel> i'm not quite sure about that part yet, for now i'm hoping microsofts line21 decoder accepts the stuff [17:43] <nevcairiel> one step at a time [17:46] <cone-729> ffmpeg.git 03Diego Biurrun 07master:a8d803a320fb: vf_select: Drop a debug av_log with an unchecked double to enum conversion [17:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:7994c1cd7608: Merge commit 'a8d803a320fb08b3ad5db4fffc79abd401206905' [17:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:887d8d293fc3: avfilter/f_select: avoid using doubles for equals checks and casts to enums [17:53] <michaelni> ubitux, IIRC only one of the inputs to sad needs to be aligned [17:53] <michaelni> deshake takes steps of 16 for x [17:54] <michaelni> blocksize * 2 for y [17:55] <michaelni> but its sure possible deshake has bugs and it surely can be imroved and cleaned up [17:55] <ubitux> mmh ok i see [17:55] <ubitux> so 16 should be safe [17:56] <ubitux> yeah alright i see [17:56] <michaelni> also the ME used in libavcodec or x264 is surely alot better and faster than what deshake does [17:56] <ubitux> i was going to write 8x8 and 16x16 sad, with unaligned and aligned version [17:57] <ubitux> and i was wondering if the variable height was meaningful in any way [17:57] <ubitux> like sad 8xh and sad 16xh [17:57] <ubitux> i'm not sure i follow the concept here [17:57] <michaelni> 16x8 blocks exist in mpeg2 and h264 [17:58] <michaelni> also in interlaced 16x16 Mbs in mpeg4 [17:58] <michaelni> so 16x8 does make sense [17:58] <michaelni> iam not sure about unaligned [17:58] <ubitux> yeah alright 16x8 and 8x16 sure could be in [17:58] <ubitux> i'm just a bit uncomfortable about the need for an arbitrary height one [17:59] <michaelni> and 8x4 for chroma in 420 [17:59] <ubitux> again it's just a combination [17:59] <ubitux> not an arbitrary 8x123 [18:02] <ubitux> (afk ~1h) [18:53] <j-b> If you plan to come to VDD, I'd encourage you to register soon [19:18] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:bcbfb95b0e32: avfilter/f_select: Set var_values[VAR_KEY] correctly [19:18] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:6f622e5fcbe8: avfilter/f_select: avoid double->int in debug output [19:31] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:ba3e3311ef3f: avutil/frame: add av_frame_side_data_name() [19:31] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:547d64a49a87: ffprobe: print some basic information about avframe side data [19:43] <kierank> nevcairiel: what format does the l21 decoder take [19:44] <nevcairiel> CEA-608-B byte pair format [19:45] <nevcairiel> Or DVD GOP format, both are supposed to work [19:47] <kierank> ok [19:48] <kierank> you'll probably have to separate out the 608 [19:49] <nevcairiel> I got the stuff out of the h264 decoder, going to see about the decoding of the CCs tomorrow. Found all the specs in the Dropbox folder. :) [19:49] <kierank> well you can try it with mpeg-2 I guess [19:49] <kierank> or does it work already [19:50] <nevcairiel> It seems to work [19:50] <nevcairiel> But no way to test reliably [19:51] <wm4> a CC decoder? [19:51] <wm4> I once thought about porting the VLC one (and it even worked) [19:51] <nevcairiel> Just getting CC out of the h264 user data for now [19:51] <nevcairiel> Decoding is tomorrow [19:51] <nevcairiel> ;) [19:58] <kierank> wm4: how are going to make it fit into ffmpeg [19:58] <kierank> you could maybe do it in the parser I suppose [19:58] <kierank> and then let the decoder reorder it [19:58] <wm4> isn't that already done [19:58] <wm4> the decoder outputs CC data as side data [19:58] <kierank> no [19:58] <wm4> (yay side data) [19:58] <kierank> yeah but it's not a stream [19:59] <wm4> I was thinking libavformat could detect the CC via parser, and add dummy streams [19:59] <wm4> but the lib user has to feed back the packets from decoder to stream somehow [19:59] <wm4> but other than that detail, you could pretend CCs work like subtitle streams [20:00] <wm4> so what's needed is an API function that allows feeding CC data from the decoder to libavformat [20:01] <nevcairiel> Well if a avcodec decoder exists, API users could do the hook up manually [20:01] <wm4> yeah, that's what I'm thnking [20:01] <nevcairiel> Some containers can apparently even have cc data in streams, ie. mov [20:02] <wm4> already reordered? [20:02] <nevcairiel> I would assume so [20:02] <nevcairiel> Its like a normal subtitle stream [20:02] <wm4> sounds good [20:03] <wm4> so, for formats which have it in the video data, I'd suggest: [20:03] <wm4> 1. libavformat uses the parser to determine CC presence, and adds dummy streams [20:03] <wm4> 2. add a libavformat API that allows the user to feed back reordered CC data from the decoder to the demuxer [20:04] <wm4> 3. the demuxer outputs the dummy data as normal "subtitle" packets originating from the dummy streams [20:04] <wm4> so, expect for the user having to feed back the data, everything would appear to work like as with normal subs [20:06] <nevcairiel> Why bother with the fake stream, could just call the decoder directly [20:07] <wm4> I'm assuming this would require larger changes/hacks to the user application's architecture [20:12] <cone-729> ffmpeg.git 03Anton Khirnov 07release/2.2:f9204ec56a4c: eamad: use the bytestream2 API instead of AV_RL [20:12] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:357325603719: Merge commit 'f9204ec56a4cf73843d1e5b8563d3584c2c05b47' into release/2.2 [20:27] <cone-729> ffmpeg.git 03Reinhard Tartler 07release/2.2:12bbd819cbdf: Prepare for 10.3 Release [20:27] <cone-729> ffmpeg.git 03Martin Storsjö 07release/2.2:407912d17870: avplay: Handle pixel aspect ratio properly [20:27] <cone-729> ffmpeg.git 03Martin Storsjö 07release/2.2:b8e57113ecba: arm: Avoid using the 'setend' instruction on ARMv7 and newer [20:27] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:6135baa85bda: Merge commit '12bbd819cbdfdd2b41286c5ccabee7f5e5b6612a' into release/2.2 [20:27] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:f4e08695602b: Merge commit '407912d17870a53e8a8cc072f192cadf358bc155' into release/2.2 [20:27] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:92c497375221: Merge commit 'b8e57113ecba5494d4bf47c29634392ea5fdb17b' into release/2.2 [20:30] <cone-729> ffmpeg.git 03Reimar Döffinger 07master:04aec74f4569: mxfdec: add missing "const" to array declaration. [20:31] <cone-729> ffmpeg.git 03Reimar Döffinger 07master:1c84aad718f0: movdec: remove nonsensical snprintf. [20:45] <cone-729> ffmpeg.git 03Martin Storsjö 07release/2.2:f6b3dce952d6: librtmp: Don't free the temp url at the end of rtmp_open [20:45] <cone-729> ffmpeg.git 03Diego Biurrun 07release/2.2:01a550bda29e: vf_select: Drop a debug av_log with an unchecked double to enum conversion [20:45] <cone-729> ffmpeg.git 03Bernhard Übelacker 07release/2.2:b20a8ad619ac: video4linux2: Avoid a floating point exception [20:45] <cone-729> ffmpeg.git 03Diego Biurrun 07release/2.2:d396987c303b: fate: Add dependencies for dct/fft/mdct/rdft tests [20:45] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:f02221d65143: Merge commit 'f6b3dce952d66f87883a50d90d6e98416ee397df' into release/2.2 [20:45] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:75ff0e8c50d1: Merge commit '01a550bda29eb05fb230576e5223034974aa3396' into release/2.2 [20:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:9dc112e277fd: Merge commit 'b20a8ad619ac0e2631391b6311cc000de85d22bf' into release/2.2 [20:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:3ef8b4322cba: Merge commit 'd396987c303bdc4eea7d1a1ff6776475d9bbd9ea' into release/2.2 [21:13] <Daemon404> wm4, to answer your earlier question: you both are [21:13] <Daemon404> but he is a bigger one [21:13] <wm4> thought so [22:07] <michaelni> llogan, do we have some tweet about OPW donation need ? [23:08] <cone-729> ffmpeg.git 03Vittorio Giovara 07release/2.3:ab1ea597bd69: g2meet: allow size changes within original sizes [23:08] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:5411040802ac: tests/fate.sh: If cat *.rep fails try it with a for loop. [23:08] <cone-729> ffmpeg.git 03Janne Grunau 07release/2.3:6a250c858ebb: fate: support testing of release branches [23:08] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:c61ac696e56a: avcodec/avdct: Add avcodec_dct_get_class() [23:08] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:ea5bb5613f7f: MAINTAINERS: update list of releases i maintain [23:08] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:de9d3f22f06e: avdevice/pulse_audio_enc: use getter function for AVFrame.channels [23:13] <michaelni> Timothy_Gu, ubitux, others, should I use the 2.3 release notes in 2.3.1 or someone wants to update them ? [23:14] <ubitux> i think it should be changed [23:14] <ubitux> the release not is for the "branch" [23:14] <ubitux> no new features are added, that's just revisions [23:14] <ubitux> release note* [23:15] <ubitux> it should *not* be changed [23:15] <ubitux> meh. [23:20] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:64bbbcd7b076: update for FFmpeg 2.3.1 [23:44] <cone-729> ffmpeg.git 03Diego Biurrun 07master:a0ce85ac7de0: configure: Globally add ZLIB_CONST to CPPFLAGS if zlib is enabled [23:44] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:a99de9ca2ccb: Merge commit 'a0ce85ac7de098d3f9b53b51b77a09bad700a011' [00:00] --- Thu Jul 31 2014