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

[burek]

[01:48] <saste> michaelni, could you bounce mails sent to the old mplayer.hu address?
[01:48] <saste> so my filtering rules always work, and i get emails in the right inbox
[01:49] <saste> (potentially affect more users, and the transitions happened more than two years ago)
[01:49] <saste> ^random use of plural forms
[02:01] <llogan> saste: carl still sends to mplayerhq.hu, AFAIK
[02:02] <llogan> people will send to it indefinitely until it breaks.
[02:34] <Compn>  whats the new addy again ?
[02:34] <Compn> oh ffmpeg-user at mplayerhq.hu is the old one, i geti t
[02:34] <Compn> you could just setup a filter to rename it all in mailman
[02:50] <kierank> Compn:  are you going to vdd?
[02:52] <cone-970> ffmpeg.git 03Michael Niedermayer 07release/0.10:466911f0004a: wmaprodec: tighter check for num_vec_coeffs
[02:55] <llogan> kierank: are you going?
[02:55] <kierank> yes
[02:55] <llogan> i never even knew there was an asterix park
[03:10] <cone-970> ffmpeg.git 03Michael Niedermayer 07release/0.11:2a8c3a789549: avcodec/kmvc: fix MV checks
[03:10] <cone-970> ffmpeg.git 03Michael Niedermayer 07release/1.0:24cff71d029c: avcodec/kmvc: fix MV checks
[03:10] <cone-970> ffmpeg.git 03Michael Niedermayer 07release/1.1:a1ce54ce6a5d: avcodec/kmvc: fix MV checks
[03:10] <cone-970> ffmpeg.git 03Michael Niedermayer 07release/1.2:f9c872622e84: avcodec/kmvc: fix MV checks
[03:10] <cone-970> ffmpeg.git 03Michael Niedermayer 07release/2.0:64444cd5784b: avcodec/kmvc: fix MV checks
[03:18] <durandal_1707> llogan: you going there at night?
[03:20] <llogan> i'd like to but paris is too far away and i'm about to spend all of my disposable income on a garage
[03:23] <llogan> to house my awesome 1995 Mazda Protege
[03:29] <cone-970> ffmpeg.git 03Romain Beauxis 07fatal: ambiguous argument 'refs/tags/n0.10.8': unknown revision or path not in the working tree.
[03:29] <cone-970> Use '--' to separate paths from revisions
[03:29] <cone-970> refs/tags/n0.10.8:HEAD: Support for shine 3.0.0
[03:32] <durandal_1707> llogan: just sell it
[04:14] <Compn> kierank : yes 
[04:14] <Compn> kierank : anything i should know? what kind of electrical outlets are they in france ?
[04:14] <Compn> like british , or like american? or ... something scary 
[04:15] <kierank> 230v European
[04:16] <Compn> oh scary then!
[04:23] <durandal_1707> Compn: you put you fingers into electrical outlets?
[04:24] <Compn> fingers dont fit, but any stray piece of wire or coins, sure
[04:24] <Compn> paperclips
[04:24] <durandal_1707> why are you doing it?
[04:25] <Compn> i'm just kidding
[10:19] <nlight> how do I get the AV_PIX_FMT_* of an AVCodecContext?
[10:20] <nevcairiel> AVCodecContext->pix_fmt ?
[10:25] <wm4> nlight: just look at AVFrame.format of the decoded frame you get
[10:27] <nlight> am I not guaranteed that AVFrame.format will be the same as AVCodecContext->pix_fmt?
[10:27] <nlight> sorry that I'm asking in this channel, we could move this to #ffmpeg
[10:30] <nevcairiel> in most cases it'll be the same
[10:30] <nevcairiel> there are however some cases where the format changes in the middle of decoding where there may be a slight difference in these formats due to codec delay
[10:31] <nlight> makes sense, thanks
[11:12] <cone-832> ffmpeg.git 03Michael Niedermayer 07master:9696740af715: hls: Call avformat_find_stream_info() on the chained demuxers
[11:12] <cone-832> ffmpeg.git 03Michael Niedermayer 07master:95960027a59f: Merge remote-tracking branch 'qatar/master'
[11:51] <saste> what's -fflage +genpts useful for?
[11:52] <saste> can you show a scenario when it is useful?
[12:25] <ubitux> durandal_1707: you mean lucy.pkh.me?
[12:26] <ubitux> durandal_1707: i messed up the index.html and don't remember what the content was :p
[12:39] <cone-832> ffmpeg.git 03Timothy Gu 07master:ccb212b6c3ed: libxvid: add working lumimasking and variance AQ
[12:58] <cone-832> ffmpeg.git 03Timothy Gu 07master:3b3c1ed0768a: libxvid: Add SSIM displaying through a libxvidcore plugin
[14:49] <j-b> beastd?
[14:50] <j-b> michaelni: once again, I invite you again at VDD. It would be nice if you could come, tbh.
[14:51] <j-b> saste: I would love seeing you there too
[14:52] <j-b> merbanan: siretart: Yuvi: nevcairiel: you should come too :)
[14:53] <merbanan> j-b: ok, I'll try to arrange it this evening
[14:54] <j-b> I count already 10 people mentionning "FFmpeg" as registered
[14:55] <ubitux> 11:51:05 <@saste> what's -fflage +genpts useful for?
[14:55] <ubitux> 11:52:05 <@saste> can you show a scenario when it is useful?
[14:55] <nevcairiel> j-b: sadly my schedule doesnt allow it, i'm in the US the week before and can't afford (timewise) to be gone another few days
[14:55] <ubitux> avi ’ mkv
[14:56] <j-b> nevcairiel: it's on the week-end! But I understand :)
[14:56] <saste> ubitux, then the next question, why?
[14:56] <nevcairiel> bad timing really, my august is full of things to do
[14:56] <ubitux> saste: see #1979 too
[14:57] <ubitux> saste: and #1180 eventually
[14:57] <ubitux> possibly some others
[14:58] <ubitux> saste: i think it's something like format with no pts but only dts or something like that
[14:58] <ubitux> but i'm really not familiar with that stuff
[15:03] <nevcairiel> formats that really require a pts (ie. formats with b frames) are really not all that good for avi anyway =p
[15:04] <saste> ubitux, documentation by bug tickets, interesting idea
[15:04] <siretart> j-b: I move to NYC this fall -> very short on time this year :-(
[15:05] <ubitux> saste :)
[15:05] <ubitux> saste: i have nothing better for you :P
[15:05] <ubitux> BBB: where are the vp9 specs/drafts so i can start reading them during my flight tomorrow?
[15:06] <ubitux> i don't see anything on the webm website or the libvpx repo
[16:20] <BBB> ubitux: there's none
[16:20] <BBB> ubitux: there's just the decoder source code
[16:20] <ubitux> mmh, ok
[16:21] <BBB> shall I push what I have now? it doesn't work at all, but it's a start. I hope to have working keyframes maybe by the end of next week or so (perhaps minus loopfilter)
[16:31] <durandal_1707> push where?
[16:32] <durandal_1707> saste: doing anything new?
[16:36] <BBB> ubitux: Daemon404: https://github.com/rbultje/ffmpeg/tree/vp9 very very very early code version (i.e. it doesn't work, don't bother reporting bugs etc.), but the code structure is sort of a rough start. it currently does something roughly equivalent to bitstream parsing for keyframes, and implements 4x4/8x8/16x16 intra prediction and inverse transforms. there's probably typos and mistakes all over the place, so again, it does not yet work, but 
[16:36] <BBB> start
[16:37] <BBB> ubitux: Daemon404: todos basically A) finish keyframe reconstruction (e.g. 32x32 intra pred, transform, loopfilter) B) backwards adaptivity of probabilities C) inter frame handling, D) probably more, E) simd
[16:37] <ubitux> truncated after "not yet work, but"
[16:37] <BBB> oh
[16:37] <BBB> "but it's a start"
[16:37] <ubitux> ok
[16:39] <ubitux> BBB: so how do you propose we work on this; are you going to rewrite history in that branch? do we need to rebase regularly and you'll merge in your branch?
[16:43] <BBB> whichever you want
[16:43] <BBB> I don't mind either way
[16:43] <BBB> I sent yuvi patches when we did vp8, that was kind of painful, so I'm sure github has better tools than that :)
[16:44] <BBB> there's various immediate things you can do to help, e.g. import the default tables from libvpx so we can do keyframe bitstream parsing and validate correctness (that was going to be my next step)
[16:44] <BBB> you can start reading over the loopfilter and try to understand it so we can impement it from scratch, but better
[16:45] <BBB> try to follow the style of e.g. ffvp8 or ffh264 or ffhevc in terms of allowing for simd optimization of the actual filter itself
[16:45] <BBB> you can try to implement 32x32 idct or intrapred
[16:45] <BBB> you can try to start implement interframe handling, testing that might be somewhat troublesome but that's ok for now, it doesn't have to work yet
[16:45] <BBB> if you know what it is, you can try to do bw adaptivity (that's adaptation of probabilities based on symbol occurrence in previous frame)
[16:46] <kurosu_> is ffhevc yet a good example for how to put hooks for simd ?
[16:46] <BBB> or just look at the code in general and tell me if you understand it and if it's ok
[16:46] <BBB> kurosu_: no idea, I didn't look at it
[16:46] <kurosu_> ok
[16:46] <BBB> I was hoping someone here looked at it
[16:47] <kurosu_> I partially did, but mostly to see the small issues I expected, like implementing SAO without pshufb
[16:47] <kurosu_> some code puts into dsp things that shouldn't afaik
[16:49] <kurosu_> lots of newcomers to asm around the hevc implementations I have seen, but look where you are now, so not an issue :D
[16:50] <Compn> so yeah, its probably a good idea to import the vp9 and work on it there
[16:50] <Compn> collectively
[16:50] <Daemon404> BBB, are we using github PRs?
[16:51] <durandal_1707> PRs?
[16:51] <Daemon404> pull requests
[16:51] <durandal_1707> you want to make pull request?
[16:51] <Daemon404> it's a valid way of handling merges for WIP branches
[16:51] <Daemon404> itl lall be squashed later anyway
[16:52] <Daemon404> itll all*
[16:52] <saste> itll?
[16:52] <nevcairiel> add a '
[16:52] <Compn> it'll
[16:52] <Compn> aka it will
[16:52] <durandal_1707> just do not add pull request to github.com/ffmpeg/ffmpeg
[16:53] <Daemon404> durandal_1707, this is just for bbb's vp9 branch
[16:56] <BBB> import?
[16:56] <BBB> Compn: what is import
[16:57] <BBB> Daemon404: sure, if ubitux does that also
[16:58] <Compn> oh i thought you meant work on it in ffmpeg git master:P
[16:58] <BBB> no
[16:58] <BBB> bad idea
[17:00] <ubitux> i'll follow whatever dev model you want
[17:00] <ubitux> i
[17:00] <ubitux> i'm interested in A, D and eventually E
[17:02] <BBB> ok why don't you do 32x32 idct and intra pred asembly then
[17:02] <BBB> most of that goes in vp9dsp.c
[17:02] <BBB> then I'll work on getting bitstream parsing to be correct
[17:02] <BBB> unless you want to do that
[17:02] <BBB> then we'll do it the other way around I guess
[17:02] <Daemon404> anything particular i should work on
[17:03] <BBB> what do you want to work on?
[17:03] <Daemon404> "not entropy decoding"
[17:03] <BBB> lol
[17:03] <BBB> do the loopfilter?
[17:03] <BBB> inter frame handling?
[17:04] <Daemon404> those are kind of hard to do without intra frame decoding mostly working no?
[17:08] <BBB> they all are
[17:08] <BBB> that's why I was hoping to get intra frame decoding working first
[17:08] <BBB> but I'm not that far yet
[17:09] <BBB> anyway, with some imagination you can just pretend intra frame decoding works and write a skeleton for inter frame handling
[17:09] <BBB> and then, as we finish intra frame, the references for inter frame will just become available
[17:09] <BBB> and it'll magically work
[17:10] <Daemon404> or fail miserably
[17:10] <Daemon404> :D
[17:14] <kurosu_> it would have been a great subject (or several?) for a gsoc - and a way to motivate people to work on it
[17:15] <ubitux> 17:02:20 <@BBB> ok why don't you do 32x32 idct and intra pred asembly then // sounds good to me
[17:17] <durandal_1707> just do E
[17:20] <durandal_1707> is vp9 really that good? files are 50% smaller compared to vp8?
[17:20] <ubitux> durandal_1707: i thought it was compared to h264
[17:21] <ubitux> but that might be propaganda
[17:22] <durandal_1707> also there is still opus to finish
[17:26] <saste> ramiro_, image2 muxer patch?
[17:26] <saste> uhm no i mean the image2 demuxer (documentation) patch
[17:29] <BBB> Daemon404: nah I believe in you! :)
[17:30] <BBB> durandal_1707: do a comparison?
[17:30] <BBB> I can provide parameters for vpxenc if wanted
[17:30] <BBB> I did provide them on the mailinglist and on doom9 previously
[17:30] <BBB> anyway I'll go back to doing entropy decoding of keyframes then
[17:30] <BBB> once that's done, most of keyframes should start working magically
[17:31] <Daemon404> BBB, ok
[17:31] <BBB> so you want to do inter frames?
[17:32] <Daemon404> sure... if you point me at relevant info/code
[17:32] <Daemon404> also im not starting till tomorrow -- plenty of stuff for me to wrap up at work today
[17:33] <BBB> I'll help you tomorrow then :) basically look at vp9_decodemv.c in libvpx
[17:33] <BBB> I'll look up the function names tomorrow
[17:33] <BBB> also vp9_decodframe.c
[17:34] <BBB> one does bitstream parsing, the other does actual frame/block reconstruction
[17:34] <BBB> you want to replicate their behaviour (functionally), but do it faster, better and more ffmpeg-style
[17:51] <Daemon404> this thread about raising the av_log level is epic
[18:06] <ubitux> AV_LOG_BIKESHED, with rainbow colors
[18:06] <ubitux> and everyone will be happy
[18:07] <wm4> ubitux: are you "back"?
[18:07] <ubitux> no, my plane is tomorrow morning
[18:07] <ubitux> i'm just wandering around on the internet right now, gonna disconnect soon
[18:07] <wm4> ok
[18:08] <ubitux> typically if you ask me sth about subtitles, i detach immediately
[18:08] <Daemon404> fetal position?
[18:09] <ubitux> :)
[21:16] <saste> wbs, lavu/opt: make av_opt_get() return NULL in case a string is not set
[21:19] <durandal_1707> saste: did we spent all money?
[21:49] <cone-293> ffmpeg.git 03Andrey Utkin 07master:a8f171151f0f: file: Add 'blocksize' option
[21:49] <cone-293> ffmpeg.git 03Andrey Utkin 07master:681ad3a5b696: Document new 'blocksize' option of 'pipe' protocol
[22:03] <cone-293> ffmpeg.git 03Paul B Mahol 07master:76e27b1d0594: smacker: make code independent of sizeof(AVFrame)
[22:03] <cone-293> ffmpeg.git 03Paul B Mahol 07master:451b2ca1b434: indeo2: make code independent of sizeof(AVFrame)
[22:03] <cone-293> ffmpeg.git 03Paul B Mahol 07master:02fe531afefa: mss2: make code independent of sizeof(AVFrame)
[22:03] <cone-293> ffmpeg.git 03Paul B Mahol 07master:ff1c13b133d5: mss3: make code independent of sizeof(AVFrame)
[22:03] <cone-293> ffmpeg.git 03Paul B Mahol 07master:678431d3f2c5: jv: make code independent of sizeof(AVFrame)
[22:03] <cone-293> ffmpeg.git 03Paul B Mahol 07master:fe3755124953: sunrastenc: do not set avctx->coded_frame
[22:03] <cone-293> ffmpeg.git 03Paul B Mahol 07master:69fe25cdca7c: lclenc: remove unused code
[23:38] <saste> formatting, will ever end?
[23:38] <saste> and why people don't find nothing more creative to do
[23:45] <durandal_1707> creativity is hard
[00:00] --- Thu Aug  1 2013