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

[burek]

[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%20Practices/Rp219-2002.pdf
[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%20Guidelines/Eg01-1990_archive.pdf
[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/925ee44364a7bce58e2ac5bac91077ce0a75d883
[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.html
[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