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

[burek]

[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 at 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