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

[burek]

[00:45] <durandal11707> michaelni: how complicated would be adding packed yuva444? (YUVAYUVAYUVA....)
[00:46] <ubitux> llogan: fun idea, but don't ask me to do it
[00:47] <ubitux> durandal11707: you can hardsub bitmap subs, there is hack in ffmpeg to inject bitmaps into frames for overlay iirc
[00:47] <ubitux> it's even documented
[00:47] <durandal11707> ubitux: nicolas already told me hours ago
[00:48] <ubitux> time is a bitch
[00:53] <durandal11707> haha
[01:20] <BBB> ubitux: is uvpred done?
[01:20] <ubitux> wasn't it already?
[01:21] <BBB> you said you'd make a small adjustment (remove duplicae off_u/v and stride_u/v
[01:21] <BBB> )
[01:21] <BBB> otherwise it's done yes
[01:34] <ubitux> fuck
[01:34] <ubitux> my
[01:34] <ubitux> isp
[01:34] <ubitux> BBB: what message from me did you get?
[01:38] <ubitux> BBB: no changes from last time; the only differing thing is that i pass 2x the offset (and you said linesize[1]==linesize[2])
[01:38] <ubitux> but im not sure about those assumptions
[01:38] <ubitux> i dont think that hurts currently
[01:38] <michaelni> durandal11707, dunno, see comits that added other packed yuv formats
[01:39] <durandal11707> michaelni: considering how planar is hard, packed is harder
[01:47] <BBB> ubitux: yes, that, and off_uv being passed twice
[01:48] <BBB> ubitux: off_u and off_v are always the same (and they are; y/uv can be different, but u and v are always the same)
[01:48] <BBB> ubitux: but we can ignore if you feel strongly and then just take as-is so we can finish off (i.e. I'll enable inter frame fate tests and we can start working on simd/mt)
[01:49] <BBB> ubitux: because I think we're finished feature-wise now
[01:58] <durandal11707> saste: pushed that probe thing?
[01:58] <BBB> member:ubitux: yes, that, and off_uv being passed twice
[01:58] <BBB> member:ubitux: off_u and off_v are always the same (and they are; y/uv can be different, but u and v are always the same)
[01:58] <BBB> member:ubitux: but we can ignore if you feel strongly and then just take as-is so we can finish off (i.e. I'll enable inter frame fate tests and we can start working on simd/mt)
[01:58] <BBB> ubitux: because I think we're finished feature-wise now
[01:58] <BBB> ubitux: c/p from a few minutes ago
[01:59] <ubitux> i'm ok for off_[uv]
[01:59] <BBB> ok, so let's leave the stride in-place, I'll cherry-pick and then enable fate tests
[01:59] <BBB> ffvp9 done \o/
[02:01] <ubitux> not really for ref linesizes
[02:01] <ubitux> will fix in a moment, if my isp allows me
[02:01] <ubitux> BBB: done, pushed
[02:01] <ubitux> BBB: btw, did you see the decode error with the sample i pasted?
[02:03] <ubitux> done, and broken \o/
[02:03] <ubitux> BBB: try ./ffplay -noframedrop -ss 29 ~/out.webm
[02:04] <BBB> omg
[02:04] <ubitux> also, i don't know if it's a problem with the encode
[02:05] <ubitux> but there are some kind of freezes
[02:05] <BBB> can vpxdec decode it?
[02:05] <ubitux> i didn't look at all :)
[02:05] <ubitux> there are various issues with that sample
[02:05] <ubitux> but it might be related to libvpx as well
[02:05] <BBB> it seems to decode fine to me
[02:06] <cone-912> ffmpeg.git 03Michael Niedermayer 07master:259292f9d484: avcodec/mpegvideo: Dont incorrectly warn about missing keyframes
[02:06] <BBB> (w/o your patch)
[02:06] <ubitux> huh?
[02:08] <ubitux> that reminds me i need to open a ticket for the ffplay lag after a seek
[02:09] <BBB> yes libvpx and ffmpeg produce same output to me
[02:09] <BBB> ffplay has issues, tha may be a problem
[02:09] <BBB> but ffmpeg works
[02:09] <BBB> no idea what that means or anything
[02:09] <ubitux> in ffplay between 30-40 sec i get a buggy output
[02:10] <ubitux> crazy blocks all over
[02:10] <ubitux> like a complete mess
[02:10] <durandal11707> what if you use non-ffplay ?
[02:11] <ubitux> it's the same
[02:11] <ubitux> http://ubitux.fr/pub/pics/_ffpv9-ffplay-etv.jpg
[02:11] <ubitux> reproducible with ffmpeg
[02:13] <ubitux> ./ffmpeg -ss 29 -i ~/out.webm -y out.y4m && ./ffplay out.y4m
[02:17] <ubitux> the decode with libvpx is ok
[02:33] <ubitux> BBB: cant reproduce?
[02:53] <BBB> ubitux: checking
[02:53] <BBB> oh yes I can
[02:54] <BBB> ok looks like an actual bug
[02:54] <BBB> that's cool
[02:54] <durandal11707> *not
[02:55] <durandal11707> why whenever i type make: doc/fate.txt is 'rebuild'?
[02:56] <ubitux> BBB: it happens again at the end btw
[02:56] <ubitux> BBB: what do you want me to work on tomorrow?
[02:56] <ubitux> "cleanups"?
[02:56] <BBB> simd, mt, other optimizations?
[02:56] <BBB> cleanups is fine also
[02:56] <ubitux> well, it's the end of the month
[02:57] <ubitux> i'm starting my new job on monday
[02:57] <durandal11707> but is pure c bitexact?
[02:57] <BBB> durandal11707: there's some small bugs, I'm working them out, but the dsp code is bitexact yes
[02:57] <ubitux> i dont mind focusing on one or two mt function though
[02:57] <BBB> mt isn't function, mt is the whole thing
[02:57] <BBB> frame-mt, that is
[02:57] <ubitux> i meant simd sorry
[02:57] <BBB> if you look at ffvp8, it's quite trivial to see how to do it
[02:57] <BBB> ok
[02:57] <ubitux> brain is off
[02:57] <BBB> :)
[02:58] <ubitux> fuck it's 3 am
[02:58] <ubitux> i need my 12 hours sleep
[02:58] <BBB> ok
[02:58] <BBB> gnite
[02:58] <ubitux> 'nite
[03:40] <durandal11707> filter that takes 699kb in source code
[03:43] <durandal11707> and its nearest neighbor 2-4 scaler
[05:29] <cone-253> ffmpeg.git 03Michael Niedermayer 07master:20b965a1a43a: avcodec/ffv1dec: check global header version
[05:29] <cone-253> ffmpeg.git 03Michael Niedermayer 07master:547d690d6760: ffv1dec: check that global parameters dont change in version 0/1
[05:39] <BBB> ubitux: pushed your commit (sorry took a while)
[07:00] <BBB> ubitux: and yes I can reproduce the issue now, will fix (fixed another minor issue also, causing some artifacts around the borders)
[09:35] <kurosu_> BBB: how is that vp9 decoder going? feature complete, or you are avoiding implementing some kind of unusual tool? (ie do you know what is the spec coverage)
[09:37] <BBB> kurosu_: mostly there, small bugs here and there, some related to odd implementation details in libvpx that I obviously have to follow
[09:38] <BBB> kurosu_: I'm avoiding resolution changing support ATM, maybe will do that later, but for now that's not a priority
[09:38] <BBB> kurosu_: then again I'm not 100% sure if that's part of profile 0 or not :)
[09:38] <BBB> I believe it is
[09:38] <BBB> kurosu_: and obviously no simd/mt/anything yet, so it's somewhat slow
[09:39] <kurosu_> I didn't find the openhevc implementation terribly sexy; hopefully ffvp9 has a better start in that domain
[09:40] <BBB> what's openhevc?
[09:40] <BBB> is that "ffhevc"?
[09:40] <kurosu_> resolution changing? ie, you code some frames at eg half resolution? reminds me of mpeg4 reduced resolution, although I'm not sure where it belongs
[09:40] <kurosu_> BBB: yes
[09:40] <BBB> https://github.com/rbultje/ffmpeg/tree/vp9
[09:40] <BBB> ubitux is also working on it
[09:41] <kurosu_> afaik, they developped in on their own inside of that French stuff then are now trying to push it on libav
[09:41] <BBB> I thought smarter wrote it?
[09:43] <kurosu_> wasn't that only the start of it ? actually I'm maybe imagining things and I don't actually know the connection
[09:43] <kurosu_> afaik there's a French consortium trying to promote hevc through an "open" development, 
[09:43] <kurosu_> https://github.com/OpenHEVC
[09:44] <BBB> they probably work together
[09:44] <kurosu_> mostly a French university doing that work iirc
[09:44] <BBB> I don't know
[09:44] <kurosu_> I haven't quite followed either
[09:45] <kurosu_> probably you can ask smarter I guess :D
[09:45] <kurosu_> (if you wanted to know, not that I'm asking that you ask)
[11:25] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/2.0:c7ee4bc016e5: ffv1dec: check that global parameters dont change in version 0/1
[11:40] <cone-303> ffmpeg.git 03Timothy Gu 07master:40b8350b57ad: doc/encoders: reformat libmp3lame doc
[11:40] <cone-303> ffmpeg.git 03Timothy Gu 07master:e45e72f5f89e: doc/encoders: reformat and add some clarification in libtwolame doc
[11:57] <cone-303> ffmpeg.git 03Diego Biurrun 07master:a6b650118543: ppc: cosmetics: Consistently format CPU flag detection invocations
[11:57] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:09c94b57ca2c: Merge commit 'a6b650118543e1580e872896d8976042b7c32d01'
[11:57] <cone-303> ffmpeg.git 03Sean McGovern 07master:01a82f1dc544: ppc: don't return a value from a function declared void
[12:01] <smarter> kurosu_: so, https://github.com/OpenHEVC/libav is the latest version of the hevc decoder, based on what I did during the gsoc last year, improved by me and others (mostly people from IETR-INSA)
[12:06] <cone-303> ffmpeg.git 03Diego Biurrun 07master:79aec43ce813: x86: Add and use more convenience macros to check CPU extension availability
[12:06] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:f0a35623826e: Merge commit '79aec43ce813a3e270743ca64fa3f31fa43df80b'
[12:48] <cone-303> ffmpeg.git 03Diego Biurrun 07master:6369ba3c9cc7: x86: avcodec: Use convenience macros to check for CPU flags
[12:48] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:8be0e2bd43d9: Merge commit '6369ba3c9cc74becfaad2a8882dff3dd3e7ae3c0'
[12:48] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:c1913064e38c: avcodec/x86/vp8dsp: Fix cpu flag checks so they work
[12:48] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:7fb758cd8ed0: avcodec/x86/lpc: Fix cpu flag checks so they work
[12:54] <BBB> ubitux: fixed
[12:57] <ubitux> cool :)
[12:58] <cone-303> ffmpeg.git 03Diego Biurrun 07master:e998b56362c7: x86: avcodec: Consistently structure CPU extension initialization
[12:58] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:62a6052974d8: Merge commit 'e998b56362c711701b3daa34e7b956e7126336f4'
[12:59] <durandal_1707> michaelni: why you merged "convenience macros" if they do not work?
[13:05] <michaelni> durandal_1707, why do you assume that they do not work ?
[13:06] <durandal_1707> because i read 7fb758cd8ed08e4a37f10e25003953d13c68b8cd commit log
[13:08] <michaelni> "avcodec/x86/lpc: Fix cpu flag checks so they work" Fixes the cpu flag checks in x86/lpc, how does that imply that the macors defined outside x86/lpc and used in several other places, dont work ?
[13:09] <durandal_1707> it doesn't
[13:09] <durandal_1707> but why it got broken...
[13:10] <durandal_1707> they appars to work in some but not all cases...
[13:21] <cone-303> ffmpeg.git 03Sean McGovern 07master:f1f728cbe4e8: ppc: don't return a value from a function declared void
[13:21] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:05507348afa1: Merge remote-tracking branch 'qatar/master'
[13:29] <durandal_1707> ubitux: were you serious about porting hqx filters? This code takes more than 10k lines of code.
[13:30] <ubitux> i'm pretty sure it can be refactored in a few lines
[13:31] <ubitux> maybe with a lut or two
[13:31] <ubitux> someone raised a better one btw
[13:31] <ubitux> a shader based, but cant remember the name
[13:31] <ubitux> iirc another 2 letters filter unwebsearchable
[13:31] <durandal_1707> shader one could only be faster
[13:32] <ubitux> the algo was different
[13:32] <durandal_1707> also there is algo that probably generated this nonsense, but where it is ...
[13:35] <durandal_1707> about refactoring: switch takes most of lines, but i doubt i can refactor this...
[13:35] <ubitux> it's a long work
[13:36] <ubitux> durandal_1707: "xBR is better"
[13:36] <durandal_1707> xBR ?
[13:37] <durandal_1707> i think right solution is self generating code
[13:37] <ubitux> like 5xBR
[13:37] <durandal_1707> i got what 5x means...
[13:38] <ubitux> https://github.com/libretro/common-shaders/tree/master/xbr
[13:38] <ubitux> btw... https://github.com/libretro/common-shaders/blob/master/hqx/hq4x.cg
[13:43] <durandal_1707> ok that is much less lines, but how(if possible at all) can i convert this to c?
[13:46] <durandal_1707> well i dunno what half4 means
[13:47] <durandal_1707> perhaps half is 16 bit float...
[13:47] <nevcairiel> half4 is a 16-bit float, and a vector of 4
[13:47] <durandal_1707> nice
[13:48] <nevcairiel> half4x4 would be a matrix
[13:51] <durandal_1707> if i do this in pure c it would be extremly slow?
[14:15] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:b05cd1ea7e45: ffv1dec: Check bits_per_raw_sample and colorspace for equality in ver 0/1 headers
[14:33] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:4f5454d20130: avcodec/mpegvideo: reduce log level for messages about allocating frames.
[14:45] <cone-303> ffmpeg.git 03Paul B Mahol 07master:48cd1037f661: cmdutils: silence warning about incompatible pointer types
[15:04] <durandal_1707> michaelni: if you not gonna push license patch, i will
[15:10] <michaelni> if someone pushes it, please ommit:
[15:10] <michaelni> > - * Copyright (c) 2007 The Libav Project
[15:10] <michaelni> > + * Copyright (c) 2007 The FFmpeg Project
[15:10] <durandal_1707> ?
[15:10] <michaelni> libavformat/network.c
[15:11] <durandal_1707> why?
[15:11] <michaelni> because you are not the copyright holder of the file ?
[15:13] <durandal_1707> but for other files in that patch its also correct
[15:13] <durandal_1707> and for others you changed when merging
[15:14] <durandal_1707> so i'm very confused
[15:16] <durandal_1707> or this was joke...
[16:33] <cone-303> ffmpeg.git 03Carl Eugen Hoyos 07master:8fe1fb41ac28: Fix compilation with --disable-mmx.
[16:54] <BBB> ubitux: ok all fate tests (without emu-edge) pass now
[16:55] <BBB> ubitux: with emu-edge still some issues, these are relatively easy to fix, will do that later
[16:55] <BBB> ubitux: simd/mt time now
[17:16] <durandal_1707> michaelni: so you changed mind about license patch?
[17:17] <michaelni> ?
[17:18] <durandal_1707> read log
[17:18] <durandal_1707> michaelni: stop playing games with me
[17:27] <iive> michaelni: about networks.c, I don't think that libav project existed at 2007...
[17:29] <michaelni> iive, you are probably correct, but it doesnt really make a difference does it ? i mean except for the entertainment value the contradiction has
[17:30] <michaelni> durandal_1707, i read the log and i dont really know what you talk about. If its about the patch, i dint say that i will apply it nor did i say i wont, iam nt stoping you from applying it nor anyone else
[17:33] <durandal_1707> well there is always revert
[17:33] <iive> if I understand correctly, all "This file is part" are OK, as they are not part of the copyright notice.
[17:34] <iive> i mean, this file is part of ffmpeg and libav... so it is true either way.
[17:35] <durandal_1707> what about: "the ffmpeg project" vs "The FFmpeg Project"
[17:35] Action: durandal_1707 have nothing better to do
[17:37] <iive> as for network.c it should probably contain 2 copyright notices, 2007-2013 FFMpeg and whatever the first and last modification 2011-2013 libav.
[17:37] <durandal_1707> its not FFMpeg but FFmpeg
[17:38] <iive> of course it is
[17:38] <durandal_1707> and really changing that each time someone refactor code is pita
[17:39] <iive> Then 2007 FFmpeg, 2011 Libav ?
[17:39] <durandal_1707> no way, i will commit what I have
[17:40] <iive> having wrong copyright notice is indeed high amusement value, but in legal trouble it could turn into nightmare.
[17:40] <iive> then... 2013 FFmpeg, 2013 Libav ? i guess you have merged stuff in it this year.
[17:41] <iive> in/if
[17:41] <durandal_1707> so i need to update this for every file in repo (except ffmpeg only code)
[17:48] <iive> most of the files seem to have the copyright assigned to the person who wrote them. not to a project
[17:49] <durandal_1707> yes, this patch just changes This file is part of ....
[17:49] <durandal_1707> ... is free software; ... distributed in hope, etc...
[17:50] <iive> yes, so no issue. as the discussion also seems to agree.
[17:50] <iive> michael said he won't commit it, but he won't oppose it. If i got it right. and today i don't get a lot of things right.
[17:51] <durandal_1707> you are not alone
[17:55] <cone-303> ffmpeg.git 03Thilo Borgmann 07master:d814a839ac11: Reinstate proper FFmpeg license for all files.
[18:51] <durandal_1707> michaelni: i guess adding support for yuva/gbr(a) to snow is now trivial?
[19:50] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:7b47d7f75e6f: avcodec/pngdec: Fix padded alloc code with threads
[19:50] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:60fed98e6347: avcodec/pngdec: fix last_row_size type
[20:24] <cone-303> ffmpeg.git 03Paul B Mahol 07master:ea3ce0085921: wnv1: remove unused avctx from codec private context
[20:24] <cone-303> ffmpeg.git 03Paul B Mahol 07master:057dce5f21cd: kgv1dec: make decoder independent of sizeof(AVFrame)
[20:24] <cone-303> ffmpeg.git 03Paul B Mahol 07master:c04268447627: kgv1dec: remove unused avctx from codec private context
[21:43] <durandal_1707> why this again
[21:45] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:5c504e4df7b4: vformat/subtitles: check av_copy_packets return code
[21:45] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:6e1b1a27a403: avcodec/avpacket: Use av_free_packet() in error cleanups
[22:49] <cone-303> ffmpeg.git 03Lukasz Marek 07master:0b46d6f3efa7: lavu/bprint: add append buffer function
[23:23] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:86736f59d6a5: avcodec/pngdsp: fix (un)signed type in end comparission
[23:42] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/0.11:2d945ac68f7a: avcodec/pngdsp: fix (un)signed type in end comparission
[23:42] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/1.0:5bd2b24db399: avcodec/pngdsp: fix (un)signed type in end comparission
[23:42] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/1.1:a2e7fd406c5b: avcodec/pngdsp: fix (un)signed type in end comparission
[23:42] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/1.2:ddce97c7b0e4: avcodec/pngdsp: fix (un)signed type in end comparission
[23:42] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/2.0:a4522ae516b5: avcodec/pngdsp: fix (un)signed type in end comparission
[23:47] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:454a11a1c9c6: avcodec/dsputil: fix signedness in sizeof() comparissions
[00:00] --- Sat Aug 31 2013