[01:58] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:ce994a03f5e2: avformat/movenc: make AVStream easier to access [01:58] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:713dcdbfcbaa: avformat/movenc: set pretty compressor name for XDCAM [01:58] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:e4d45673ca02: avformat/movenc: set XDCAM codec tag correctly [12:14] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:8c0687abdf64: avfilter/vf_removelogo: use av_freep() for saftey [12:14] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:8c582d1b2213: avfilter/vf_removelogo: fix offset for accessing pixels above and below [12:14] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:eedfee12c608: avfilter/vf_removelogo: fix pixel pointer so it points where its intended [12:14] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:aeddc6e3a552: avfilter/lavfutils: fix memleak of avpacket [13:43] <durandal_1707> ubitux: i think decimate should not change pts at all, i would just leave that to fps/setpts/settb filters [14:02] <iive> it would just cause stutter, people would not know to insert setpts filter. [14:05] <durandal_1707> iive: decimate from libmpcodecs does not change pts [14:06] <iive> but this filter doesn't work like decimate from mpcodecs, iirc [14:07] <durandal_1707> from functionality point it drops random frames which decimate do too [14:07] <iive> nope [14:08] <iive> lavf decimate drops one of N frames, mp decimate drops only frames that are similar. [14:09] <durandal_1707> iive: and to what would you set pts? [14:10] <iive> lavf decimate is frame reduction filter, that tries to drop the least different frame. so it is natural it changes the pts accordingly. [14:10] <durandal_1707> but to what? [14:11] <iive> I think it is used as a second stage in inverse telecine filter. [14:11] <iive> or rather... ivtc chain. [14:12] <iive> but i'd better let ubitux explain it. [14:13] <durandal_1707> i didn't ask that.... [14:14] <cone-157> ffmpeg.git 03Martin Storsjö 07master:a52b5a5a07b0: riff: Add a mapping for VP6A [14:14] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:23c8a3353bd9: Merge remote-tracking branch 'qatar/master' [14:19] <cone-157> ffmpeg.git 03Lukasz Marek 07master:7b1640c4a6e9: avdevice/pulse_audio_enc: fix stream index [14:19] <cone-157> ffmpeg.git 03Lukasz Marek 07master:e1fb3143bb3a: avformat/ftp: fix possible deadlock [14:19] <cone-157> ffmpeg.git 03Lukasz Marek 07master:3a92ee595316: avformat/ftp: add log regarding passive mode failure [14:19] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:8de021fabe3a: Merge remote-tracking branch 'lukaszmluki/master' [14:42] <xlinkz0> is ffserver no longer maintained? [14:43] Action: Compn looks at maintainers [14:45] <xlinkz0> what does Compn see? [14:47] <Compn> looks unmaintained, yep [14:48] <Compn> some people working on it slowly [14:48] <xlinkz0> thanks [14:53] <michaelni> xlinkz0, do you want to maintain ffserver or why do you ask ? (no ffserver sadly doesnt have a dedicated maintainer currently) [14:59] <xlinkz0> sadly I don't have experience in C server coding [15:00] <xlinkz0> and practically zero with libav so couldn't even if I wanted to [15:01] <xlinkz0> if I can't find anything open source that works for what my employer demands I think I'll make something with boost asio [15:28] <Compn> xlinkz0 : whats your employer need ? [15:28] <Compn> sounds like some kind of stream server [15:32] <xlinkz0> we need rtsp restreaming for a couple of cameras [15:33] <xlinkz0> that is, take rtsp stream from camera and resend it to potentially thousands of people [15:33] <Compn> ah [15:33] <Compn> not sure how many connections ffserver can handle [15:33] <Compn> there are opensource rtsp servers [15:33] <Compn> good luck [15:33] <xlinkz0> thanks [15:42] <michaelni> Compn, iam not aware of a fundamental connection limit in ffserver, it would be interresting if someone tested it with thousands of connections [15:43] <Compn> :) [15:43] <xlinkz0> i would've tested it but since i can't get it to work :\ [15:44] <Compn> try with ffmpeg first [15:44] <Compn> er nevermind [15:55] Action: michaelni wonders why noone wants to maintain ffserver [16:04] <durandal_1707> because code reviewers [16:06] <durandal_1707> kierank: what you disagree about (hd) colorbars? [16:06] <kierank> the same thing that was on the mailing list [16:06] <kierank> you can't convert them to correct 709 yuv [16:08] <durandal_1707> so what colorspace must be set? [16:10] <kierank> hd is 709 [16:10] <kierank> but you can't get them like that [16:10] <kierank> because swscale only supports 609 [16:10] <kierank> 601* [16:24] <michaelni> what exactly does sws not support ? [16:26] <durandal_1707> 709 colorspace [16:26] <michaelni> grep for 709 in libswscale/yuv2rgb.c, its there [16:28] <michaelni> same with libavfilter/vf_scale.c [16:54] <Compn> kierank : we want to see a failing command line [16:55] <Compn> then we can fix it or show how to do it [16:57] <kierank> michaelni: rgb -> yuv [16:57] <kierank> the colourbars are rgb [16:59] <durandal_1707> you mean colourbars produced by filter? [17:02] <michaelni> git log --grep rgb2yuv libswscale [17:02] <michaelni> seems to suggest that sws supports user specified yuv for rgb2yuv [17:02] <michaelni> yuv TYPE that is [17:06] <kierank> durandal_1707: yes [17:06] <kierank> so you need to calculate the filter coeffs your self [17:06] <kierank> ok [17:06] <durandal_1707> filter output is in yuv [17:11] <cone-157> ffmpeg.git 03Paul B Mahol 07master:1d8ce109e91d: avfilter/vf_separatefields: do not reset pts to 0 [17:11] <kierank> draw_bar is in rgb no? [17:13] <durandal_1707> kierank: do you have colors values in yuv(709 colorspace)? [17:16] <kierank> https://dl.dropboxusercontent.com/u/2701213/Specs/SMPTE/Recommended%20Practi... [17:41] <ubitux> durandal_1707: and what would that setpts filter be set to? [17:42] <ubitux> decimate is used to drop frames in order to reach a particular frame rate [17:47] <durandal_1707> ubitux: ok, than you fix async [17:51] <ubitux> well, i don't know how what's the correct behaviour [18:12] <kierank> btw Compn to answer your old question full range sucks because there's nowhere for filter overflow to go [18:12] <kierank> or underflow [18:32] <Compn> ok :) [18:32] Action: Compn hasnt a clue [18:32] Action: Compn afk [19:08] <durandal_1707> kierank: same colors/colorspace is used in smptebars? [19:08] <kierank> no, smptebars is 601 [19:08] <kierank> sd = 601, hd = 709 [19:19] <durandal_1707> but it use same numbers? [19:24] <kierank> no [19:32] <durandal_1707> kierank: so smptebars should use bt470bg? [19:32] <kierank> yes [19:33] <durandal_1707> do you have spec of smptebars that gives 8-bit numbers like for hd version? [19:39] <kierank> dunno [19:39] <kierank> there are many types of SD bars [19:44] <durandal_1707> those are from EG 1-1990 [19:44] <kierank> https://dl.dropboxusercontent.com/u/2701213/Specs/SMPTE/Engineering%20Guidel... [19:45] <kierank> probably from 1990 it'll be in mV [20:49] <cone-656> ffmpeg.git 03Paul B Mahol 07master:cfc9a4c732af: avfilter/vsrc_testsrc: smpte(hd)bars: use yuv directly [21:00] <kierank> durandal_1707: thanks will try next week [21:01] <durandal_1707> i cant spot difference [21:01] <durandal_1707> actually there is difference, yellow in mpv looked more orange before [21:35] <durandal11707> huh: /* TODO: implement AV_CODEC_ID_RAWAUDIO */ [21:39] <wm4> it'd odd how raw audio has one decoder per format, while raw video has a single decoder [22:00] <durandal11707> it would be odd that wav demuxer returns raw audio [22:01] <durandal11707> i guess you could add virtual rawaudio decoder [22:01] <durandal11707> but how would you separate signed/unsigned/float? [22:02] <durandal11707> by adding extradata? [22:02] <durandal11707> this would just complicate -c copy ... [22:06] <wm4> dunno, do like video formats and add every audio format ever? [22:07] <wm4> or it could be yet another avcodeccontext field, similar to samplerate etc. [22:08] <durandal11707> i see no reason for it [22:11] <durandal11707> you could use ff_get_pcm_codec_id [22:33] <cone-656> ffmpeg.git 03Paul B Mahol 07master:fd54f700720a: avformat/avr: use ff_get_pcm_codec_id() [23:11] <smarter> michaelni: I don't think it makes sense to have a wrapper to openhevc in ffmpeg [23:12] <smarter> openhevc is used by the IETRE people to experiment on the decoder without having to care about the rest of libav, but this is irrelevant to most people [23:13] <smarter> everything of interest they do is ported to https://github.com/OpenHEVC/libav [23:13] <smarter> (s/IETRE/IETR/) [23:14] <smarter> to add to the confusion, the branch which will actually be merged into libav is http://git.khirnov.net/cgit.cgi/libav/log/?h=hevc_upstream [23:14] <smarter> it removes some features which are not ready or can't be accepted (intrinsics mostly) and should be kept in sync with https://github.com/OpenHEVC/libav [23:22] <smarter> and I don't think merging the libav hevc decoder now is a good idea since it's still in flux [23:24] <mraulet> I agree with smarter (you shouldn't make a wrapper to openhevc git) you should rather use libav [23:25] <michaelni> mraulet, libav is a fork of ffmpeg, we dont "use" libav [23:25] <michaelni> about the openhevc wrapper, ok understood [23:26] <mraulet> ok you can copy paste hevc related files then from openhevc then [23:27] <michaelni> yes possible or apply the patch i ported today libav [23:27] <michaelni> i just wonder whats the difference and [23:28] <mraulet> from? [23:28] <michaelni> betweem that patch and openhevc/hm10.0 [23:29] <michaelni> i assume that hm10.0 is where development happens ? [23:29] <mraulet> wpp and tiles --> parallel tools from hevc [23:30] <mraulet> They are not included in the patch [23:30] <mraulet> and as smarter said on the IRC (intrinsics are not included in the patch) [23:30] <smarter> michaelni: what libav branch/patch is your patch based on? [23:31] <michaelni> smarter, the patch that was posted today to libav [23:31] <michaelni> libav-devel [23:31] <mraulet> so my comments are relevant to this patch [23:32] <smarter> michaelni: okay, so it's a snapshot of http://git.khirnov.net/cgit.cgi/libav/log/?h=hevc_upstream [23:33] <iive> if I understand correctly, havc is not yet merged in libav, is it? [23:33] <michaelni> ok, so i should merge that patch and not copy files from some git (that is assume noone on the ML objects) [23:34] <smarter> iive: it isn't [23:34] <iive> and the patch in question is posted to libav-dev in order to use standalone havc codec, isn't it? [23:35] <smarter> iive: I'm not sure what you mean [23:36] <iive> i mean, openhavc is standalone codec, isn't it? [23:36] <ubitux> hevc* iive [23:36] <iive> my bad. [23:36] <smarter> ignore openhevc, it's a sandbox for people to experiment with :) [23:36] <mraulet> it does have what I need to decode hevc streams [23:37] <smarter> this patch: http://lists.libav.org/pipermail/libav-devel/2013-October/051938.html is a *Work In Progress* patch to add an hevc decoder to libavcodec [23:37] <michaelni> the patch does decode hevc, yes, i tested it of course before posting :) [23:38] <smarter> it does, it could also set your machine on fire, no guarantee. [23:38] <iive> this applies to any *gpl software [23:38] <michaelni> also may i add someone of you to our MAINTAINERs file for hevc* when its merged ? [23:38] <wm4> so, why not just merge the libav hevc patch as soon as it lands in their git head? [23:38] <smarter> wm4: that sounds reasonable [23:38] <iive> btw, I think that x264 also started as sandbox... [23:39] <wm4> also please, only one codec ID/define for hevc [23:39] <wm4> (now is the chance to fix) [23:39] <ubitux> too late i presume [23:39] <ubitux> (see patch 1) [23:39] <michaelni> wm4, too late [23:39] <michaelni> H265 is already i there [23:39] <wm4> then change it [23:39] <ubitux> it's duped [23:40] <ubitux> see patch 1 [23:40] <smarter> yes, you should have taken a look at the wip hevc patch before merging an hevc demuxer into ffmpeg... [23:40] <wm4> patch 1 just says "Some developers have choosen to use AV_CODEC_ID_HEVC, so we need that to be compatible" [23:40] <wm4> which has 0 info [23:40] <ubitux> what info? [23:40] <wm4> information [23:40] <ubitux> ... [23:40] <ubitux> information about what? [23:40] <smarter> wm4: the libav HEVC decoder has been using AV_CODEC_ID_HEVC since it's creation more than a year ago [23:40] <wm4> what developers, why can't it be changed, etc. [23:41] <wm4> smarter: I'm arguing for dropping AV_CODEC_ID_H265 [23:41] <smarter> wm4: I'm just providing context :) [23:41] <wm4> ok [23:41] <wm4> anyway, this will turn into a mess without doubt [23:41] <wm4> fix it now and reduce the pain for everyone [23:42] <wm4> well, could also try to convince Libav to use H265, but that'd be even harder [23:42] <ubitux> won't happen [23:42] <mraulet> HEVC is the general name [23:43] <iive> isn't h264 named AVC? [23:44] <mraulet> ... [23:44] <michaelni> about waiting for hevc to hit libav, that doesnt seem reasonable honestly. The patch is there, it works, it was trivial to port and i assume there are user who would want to use it [23:45] <ubitux> any idea what they are waiting for? [23:45] <mraulet> no [23:45] <BBB> I bet you it has to be reindented 20 times [23:45] <smarter> ubitux: http://lists.libav.org/pipermail/libav-devel/2013-October/051938.html lists some of these things [23:45] <wm4> the latest patch iteration (re?)added multithreading [23:45] <BBB> for optimal diego performanc [23:45] <BBB> hi smarter [23:45] <smarter> security is also an issue [23:45] <smarter> hi BBB :) [23:46] <BBB> still liking it over there? [23:46] <smarter> yep! [23:46] <BBB> good [23:46] <ubitux> smarter: ok, looks like a few things might be important [23:47] <michaelni> its marked as experimental in my patchset so it wont be used without user interaction thus security should not be an issue [23:47] <BBB> ubitux: how's 4x4idct going? [23:47] <ubitux> BBB: slowly progressing, i worked a little on it today [23:47] <mraulet> michaelni, you should add this to read ts [23:47] <mraulet> https://github.com/OpenHEVC/libav/commit/925ee44364a7bce58e2ac5bac91077ce0a7... [23:47] <BBB> cool [23:47] <iive> my theory is that libav want to keep havc out of ffmpeg and the only way to do that is to not merge it themselves. ;) [23:48] <ubitux> BBB: i'll give you a report tomorrow at the end of the day [23:48] <smarter> HEVC-In-MKV is also not standardized yet, merging now would impose a de facto standard [23:48] <ubitux> iive: why do you insist on writing havc? :P [23:48] <wm4> didn't the mkv guys come to a conclusion? [23:48] <iive> did I said hevc is bad name? [23:48] <smarter> wm4: I'm not sure. JEEBsv ^ ? [23:49] <iive> i confuse it with avc... that's why... [23:49] <mraulet> it works on divx mkv files and others [23:49] <michaelni> mraulet, thx, merged to my local hevc-wip branch [23:49] <wm4> http://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.htm... [23:49] <michaelni> cant push to master as theres no HEVC codec id yet [23:50] <llogan> opus in mkv didn't seem to make any issues before, AFAIK&IIRC (what is the situation on that anyway?) [23:50] <michaelni> smarter, about mkv, please reply to the patch on ffmpeg-devel [23:50] <michaelni> with that so people know [23:51] <j-b> DivX is not using the standard mkv [23:51] <mraulet> j-b: ok [23:52] <mraulet> at least the current implementation works for ts and mp4 [23:52] <mraulet> I can confirm it on all samples I have [23:52] <smarter> michaelni: I'm not really qualified to talk about mkv [23:53] <j-b> mraulet: mp4 is not standardised, AFAIK [23:53] <mraulet> hmmm you can consider it as standardized [23:53] <j-b> and "almost" is not a standard [23:53] <mraulet> the latest draft does not have any changes [23:53] <j-b> _draft_ [23:54] <mraulet> then you can postpone all :-) [23:54] <mraulet> ^^ [23:54] <michaelni> btw, who cares if a demuxer supports something that is not standarized ? [23:54] <j-b> noone [23:54] <j-b> well, one day, MP4 people will stop being a bunch of suckers... [23:55] <michaelni> for a muxer yes, sure we dont want to create invalid files but for a demuxer that doenst make sense [23:55] <j-b> but that is not for now [23:55] <j-b> michaelni: you have to support the current mp4 one and the DivX [23:55] <j-b> but they are not the final standards [23:56] <michaelni> we should support everything that exists on the demuxer & decoder side ideally [23:56] <kierank> 22:45:31 <"BBB> for optimal diego performance -> lol [23:59] <michaelni> wm4, about the codec id, what is the problem with 2? (yes i prefer just 1 too but i cant add "now" the one that libav will be adding at some point in the future beause i dont know the future) [23:59] <j-b> michaelni: but then, why keep the decoder as experimental? [23:59] <wm4> michaelni: one more shitty ifdef for libav vs. ffmpeg [00:00] --- Sun Oct 13 2013