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

[burek]

[00:00] <wm4> also, I myself use codec names, not the define, so the "redundant" define doesn't help me much
[00:00] <wm4> s/redundant/compatibility
[00:00] <smarter> michaelni: ah, another important issue that hasn't been resolved (afaik) is whether or not the conformance streams can be uploaded to FATE legally
[00:01] <michaelni> wm4, if you just use a name like "hevc decoder" how does the codec_id affect that ?
[00:01] <michaelni> j-b, maybe we should not and make it non experimental, no string oppinion on that
[00:02] <michaelni> strOng
[00:02] <michaelni> smarter, tell them to sue me if i upload them
[00:02] <wm4> michaelni: well, ffmpeg uses "h265" for AVCodecDescriptor.name, and I expect Libav will choose "hevc"
[00:03] <wm4> I won't be the only one affected by this, think of scripts etc.
[00:03] <j-b> like normal people will call it hevc
[00:04] Action: michaelni wonders why they dont call h.264 avc
[00:05] <michaelni> wm4, so if i change that "h265" string to "hevc" that solves the problem with 2 codec ids for you ? 
[00:06] <michaelni> i dont see a problem with that chnage ATM but i might be missing someting 
[00:06] <wm4> yes, at this point everyone could just pretend AV_CODEC_ID_H265 doesn't exist
[00:06] <wm4> *does
[00:06] <ubitux> .name = "h264,hevc" isn't supported?
[00:06] <mraulet> agree with wm4
[00:07] <BBB> you guys are totally out of your mind
[00:07] <BBB> this is a development channel for codecs and video technology
[00:07] <BBB> and you're talking about scripts and naming and indenting and ... shit man
[00:07] <wm4> uh this is a ffmpeg development channel
[00:07] <wm4> quite a different thing
[00:08] <BBB> maybe for you it is
[00:08] <BBB> not for me
[00:08] <wm4> then you're offtopic here
[00:08] <BBB> ok
[00:10] <ubitux> :')
[00:10] <beastd> data matters, algorithms matter and the color of the little bikeshed can of course be neglected for now
[00:11] <j-b> then you should vote :)
[00:11] <j-b> I vote hevc
[00:12] <mraulet> &. why not keeping the original of the decoder of those who developed it
[00:12] <j-b> because of a quick google fight
[00:12] <ubitux> mraulet: i think the original question is about retro compat with the h265 codec id added a while ago
[00:13] <mraulet> but the decoder does not exist
[00:13] <wm4> there's a hevc raw demuxer
[00:13] <mraulet> okay but it is not the same amount of code...
[00:14] <beastd> BTW are you talking about the decoder implementation name or the codec id symbolic name now?
[00:14] <ubitux> mraulet: i'm not sure you understand the issue here; and anyway, the original plan was and always is to follow compat with libav and be retro compatible
[00:15] <mraulet> all, we should be compatible with the name of the files it makes more sense
[00:15] <iive> if I understand the issue here, it is application compatibility. So it should be decided before the codec is in wider use.
[00:32] <smarter> considering there was no release of ffmpeg with AV_CODEC_ID_H265, removing it doesn't seem like a bad idea
[00:33] <smarter> anyway, feel free to release ffmpeg with a half-working hevc decoder behind the experimental flag. I hope that won't have any bad consequence.
[00:34] <smarter> as long as you don't start diverging from the libav decoder
[00:35] <cone-656> ffmpeg.git 03Michael Niedermayer 07master:87fe0bbd69bf: lavc: rename h265 to hevc, add AV_CODEC_ID_H265 with identical value for backward compatibility
[00:35] <wm4> michaelni: nice!
[00:36] <smarter> AV_CODEC_ID_HEVC       = MKBETAG('H','2','6','5'),
[00:36] <smarter> shouldn't that be 'H','E','V','C' ?
[00:36] <wm4> well, the value literally doesn't matter
[00:36] <smarter> even if it's different from libav?
[00:36] <ubitux> binary compat
[00:36] <wm4> it's just a really dumb trick to ensure ABI compatibility even if Libav adds a codec id
[00:37] <ubitux> how is that dump?
[00:37] <ubitux> dumb*
[00:37] <smarter> alright
[00:37] <wm4> smarter: Libav doesn't use tags here
[00:37] <wm4> it's a straight enum (though some codec IDs add weird offsets)
[00:39] <wm4> ubitux: if it were an enum without gaps, codec_descriptors could for example be indexed by codec id
[00:39] <wm4> and also using fourccs here is kind of confusing (because the enum values actually have no meaning)
[00:39] <ubitux> there is no better solution for abi compat afaik
[02:05] <BBB> why doesn't check_lib2 pick up --extra-ldflags=.. configure flags (or --extra-libs)?
[02:44] <BBB> oh nm I had ldflags mixed up it was picking up a wrong oen
[02:44] <BBB> weird
[07:00] <cone-130> ffmpeg.git 03Anton Khirnov 07master:df6737a55f5d: audio_mix: fix channel order in mix_1_to_2_fltp_flt_c
[07:00] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:830a567e96a2: Merge commit 'df6737a55f5dc7c0ae5272bc5fa6182836d5481c'
[07:50] <cone-130> ffmpeg.git 03Anton Khirnov 07master:9ab5f7107d2f: FATE: add lavr mixing tests
[07:50] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:de80cebdd7fb: Merge commit '9ab5f7107d2f1411e9fda6c36af64524e5ed31d1'
[08:07] <cone-130> ffmpeg.git 03Anton Khirnov 07master:364af376f343: FATE: add lavr resampling tests
[08:08] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:b35ef855a4fa: Merge commit '364af376f343d4706c4cdb7ab9fe0863994e6c01'
[08:16] <cone-130> ffmpeg.git 03Anton Khirnov 07master:66d3f5fd5ca4: lavc doxy: remove false statements about alignment requirements.
[08:16] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:29d64b1d8ebe: Merge commit '66d3f5fd5ca4cb3d09b52ad1041cd4359325a21a'
[08:26] <cone-130> ffmpeg.git 03Anton Khirnov 07master:16ea20c827ef: lavc doxy: extend/clarify avcodec_decode_audio4() doxy
[08:26] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:40ade0714110: Merge commit '16ea20c827ef2ffaf77d5e05d5cf9983689f7b2b'
[08:33] <cone-130> ffmpeg.git 03James Almer 07master:9c15ef35d404: oggparsevorbis: support official chapter extension
[08:33] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:b6ffe8afd928: Merge commit '9c15ef35d404fca2adc31276c1eedb11cf485461'
[08:58] <cone-130> ffmpeg.git 03Vittorio Giovara 07master:ed9245dba83f: oggparsevorbis: check allocations
[08:58] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:3ce0eddeab39: Merge commit 'ed9245dba83f9add60f55718b537b0af2105c60e'
[09:21] <cone-130> ffmpeg.git 03Nicolas George 07master:ecab1c77410f: oggdec: add support for Opus in Ogg demuxing
[09:21] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:8dbf98e68a9b: Merge commit 'ecab1c77410f023b437c6ed3a3281be8f039e574'
[09:46] <cone-130> ffmpeg.git 03James Almer 07master:601d6228c481: flac: move picture parsing code in a separate file
[09:46] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:92b03cf926ef: Merge commit '601d6228c4811d8971a2412a759e1a4ab775ebe8'
[09:56] <cone-130> ffmpeg.git 03James Almer 07master:c18375ec8040: oggvorbisdec: add support for embedded cover art
[09:56] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:77caa31f717a: Merge commit 'c18375ec8040a9fe0f186b2033dc975883143758'
[10:11] <cone-130> ffmpeg.git 03Vittorio Giovara 07master:fd2384f02b90: oggparsevorbis: fail on memory allocation error
[10:11] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:0c7bd3402306: Merge commit 'fd2384f02b905a106fba9222ece4ddbe2ec61937'
[10:23] <cone-130> ffmpeg.git 03Luca Barbato 07master:0cb83c563848: indeo4: Check the block size if reusing the band configuration
[10:24] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:d3850ac5b9c7: Merge commit '0cb83c563848bf8f8365e7bd30e7e6b57ef360f0'
[10:43] <cone-130> ffmpeg.git 03Luca Barbato 07master:c9ef6b09326a: indeo4: Check the inherited quant_mat
[10:43] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:43dec5ef9a36: Merge remote-tracking branch 'qatar/master'
[11:41] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:4b948dcadb8b: doc/developer: Merge license related policy items
[11:51] <cone-130> ffmpeg.git 03Paul B Mahol 07master:fa7e9f940140: avformat/vocdec: return AVERROR_EOF when EOF is reached
[13:44] <ubitux> BBB: ping
[13:45] <ubitux> i'm likely missing something obvious in the calling convention; http://pastie.org/8398856
[13:46] <ubitux> the "movq m0, [blockq+ 0]" is doing a rsi dereferencing
[13:46] <ubitux> but it's set to 0x7a0 (likely a stride value)
[13:47] <ubitux> (don't mind the c code addition, it's just a working unrolled 4x4 to use as a reference)
[13:48] <ubitux> oh god i've switched block and stride
[13:48] <ubitux> eyes crossing
[13:48] <ubitux> my bad.
[13:49] <BBB> lol
[13:54] <ubitux> weird order btw
[13:54] <ubitux> since the stride is related to block access and not dst
[13:58] <BBB> no
[13:58] <BBB> stride is for dst
[13:58] <BBB> block has no stride
[13:58] <BBB> block is just a 2d array of 32x32 int16_ts, or 4x4 int16_ts
[13:58] <BBB> so the stride of it is the size of the iadst/idct
[13:59] <ubitux> ah urm i got confused with the 1d arg
[13:59] <BBB> right, that's a different stride
[13:59] <BBB> that's not the function argument
[13:59] <BBB> maybe that's confusing indeed
[13:59] <BBB> feel free to rename :)
[13:59] <ubitux> no it's fine
[14:00] <ubitux> btw, what's the maximum number of m registers i should use?
[14:00] <ubitux> 8?
[14:00] <ubitux> m0..m7?
[14:00] <durandal_1707> depends
[14:05] <BBB> ubitux: so for mmx, m0-7
[14:05] <BBB> ubitux: for sse(xmm) or avx(ymm - not relevant yet), you have 16 on x86-64
[14:06] <BBB> so if you want portable code, use only m0-7, if you want optimal performance, use m0-15
[14:06] <BBB> for idct32x32, I don't care about x86-32, it's kind of sad but I have better tihngs to do with my free time, and x86-32 is dead
[14:06] <ubitux> i think i can do it with m0-7
[14:06] <BBB> for mc asm, it wasn't hard to keep within 8, so I used only m0-7
[14:06] <BBB> yeah idct4x4 should be possible with 8, I'd think
[14:07] <BBB> 8x8 may be harder... so give it a look, and if it looks complex, don't bother
[14:07] <ubitux> 5-6-7 are for the 3 constants, i wanted to avoid reloading
[14:07] <BBB> if it's "almost" possible, feel free to use m8 and beyond for "optional" stuff to allow %if/%else/%endif style code
[14:07] <BBB> ffvp8 does that too
[14:07] <BBB> then it works on both but still uses >8 regs on x86-64
[14:07] <ubitux> ok
[14:08] <BBB> but if the code gets too complex, just make a x86-64 only version that uses all regs
[14:08] <BBB> whatever is easiest for code writing or maintenance purposes
[14:08] <ubitux> for example SUMSUB_BA using an extra register for tmp ?
[14:08] <BBB> well, you can't just switch right?
[14:08] <ubitux> ?
[14:08] <BBB> oh wait you could
[14:08] <BBB> yes it is
[14:08] <ubitux> SUMSUB_BA can work without an extra register
[14:09] <ubitux> so i could do that to keep under 8 reg
[14:09] <BBB> right, don't feel obliged to use these macros if they make it harder to understand
[14:09] <ubitux> and i guess i could call it differently if i have extra registers
[14:09] <BBB> esp. for first versions
[14:09] <ubitux> i think it's actually simpler to use them
[14:10] <ubitux> since i would likely have used 2x the number of registers to do the same op :p
[14:18] <BBB> I'd have pointed out what you did wrong ;)
[14:30] Action: Daemon404 wonders what this cherry picking idiocy is...
[14:30] <Daemon404> why merge unfinished code
[14:31] <Daemon404> to be "first"? -_-
[14:31] <ubitux> are you refering to hevc?
[14:31] <Daemon404> yes.
[14:31] <ubitux> we're not allowed to review it?
[14:32] <Daemon404> review? sure. but i see no involvement at all from its atual authors.
[14:32] <Daemon404> and pushng before teh authors are happy with it is just retarded
[14:33] <ubitux> consider it's submitted to ffmpeg-devel so ffmpeg dev can review it
[14:33] <ubitux> no need to extrapolate further
[14:33] <Daemon404> i wonder if the review will actually make it to the authors
[14:33] <Daemon404> since they dont seem to have even been informed.
[14:33] <durandal_1707> its fork
[14:34] <BBB> question
[14:34] <BBB> it took them 2 years to get ffhevcdec into shape?
[14:37] <michaelni> Daemon404, at least 2 of the hevc authors are on this channel
[14:37] <Daemon404> as long as they actually get the review points.
[14:38] <Daemon404> it's only going to be a giant mess if ffmpeg merges it a) before theyre happy b) solely to be 'first'.
[14:39] <michaelni> Daemon404, libav seems VERY unhappy about ffmpeg merging anything especially if its something important and libav doesnt have it yet
[14:40] <Daemon404> ...
[14:40] <Daemon404> i dont see how thats at all relevant
[14:40] <Daemon404> you seriously dont see how merging incomplete coe is fucking stupid?
[14:40] <michaelni> the crying is from libav devels not so much from openhevc devels
[14:40] <Daemon404> or at least, against the athour's wishes?
[14:41] <Daemon404> openhevc is a temporary thing
[14:41] <durandal_1707> merge it before k&r
[14:41] <Daemon404> the trop so far has been "don't make your incomplete code public, or michael will merge it"... youre not exactly proving this to b untrue.
[14:41] <Daemon404> be*
[14:41] <Daemon404> er, trope.
[14:43] <ubitux> stealing free code!
[14:43] <Daemon404> ...
[14:43] <Daemon404> you people are children
[14:43] <durandal_1707> similar was with wmall, which is still incomplete
[14:43] <Daemon404> or dirac
[14:43] <Daemon404> or rememer flashv2?
[14:43] <michaelni> Daemon404, I asked the main author yesterday
[14:44] <Daemon404> what was smarter's response?
[14:44] <michaelni> and and his awnser was "sure" so that doesnt sound like is is against it being merged
[14:44] <ubitux> michaelni: make sure you address the remaining issues though
[14:44] <ubitux> (http://lists.libav.org/pipermail/libav-devel/2013-October/051938.html)
[14:45] <durandal_1707> perhaps if it get merged into ffmpeg more people will send patches?
[14:45] <ubitux> Daemon404: also, "experimental" flagged afaik
[14:46] <ubitux> ...and actually still not merged, but waiting for reviews
[14:46] <Daemon404> i mostly see this as an impatient race between children
[14:46] <Daemon404> or perhaps the quintissential youtube comment: FIRST!!!11one
[14:47] <michaelni> Daemon404, you are are a libav supporter of course you argue that libav should have it first :)
[14:47] <durandal_1707> so now we are children, when it get merged, we will become what?
[14:47] <Daemon404> michaelni, i suppose sanity
[14:47] <Daemon404> something which neither project sports.
[14:47] Action: Daemon404 is so tired of this tribalistic bs
[14:49] <durandal_1707> sorry for spam
[14:49] <michaelni> Daemon404, do something about it, for example force both projects to merge back tgether into one, if you know how to achive that
[14:50] <Daemon404> i think the term for that is the apocalypse
[14:50] <Daemon404> but it sure would be nice to go a ay without hearing some sort of childish animosity between the two
[14:50] <Daemon404> day*
[14:50] <durandal_1707> simple: ditch devs that are against it
[14:53] <michaelni> also about hevc review, review comments to the hevc patch should posibly be CCed to the openhevc developers, their emails are in the commit message anyway, that is if they arent subscribed 
[14:54] <Daemon404> the patches are mostly smarter and Paranoialmaniac
[14:54] <Daemon404> and vittoro i think
[14:54] <Daemon404> a bunch of openhevc stuff has no been brought in
[14:54] <Daemon404> such as walls of intrinsics
[15:00] <Paranoialmaniac> i don't touch image decoding process
[15:02] <Paranoialmaniac> i only contribute non-annexb format decoding
[15:03] <michaelni> Paranoialmaniac, ok if i push your patch to ffmpeg master ?
[15:03] <michaelni> ffmpeg git master branch that is
[15:04] <Paranoialmaniac> what patch?
[15:05] <michaelni> [FFmpeg-devel] [PATCH 2/7] lavf/mov: Support HEVC demuxing. AND [FFmpeg-devel] [PATCH 3/7] lavf/matroskadec: Support HEVC demuxing.
[15:06] <michaelni> of course with review comments from ffmpeg-devel taken care of
[15:06] <Paranoialmaniac> does pushing these patch make sense without the decoder?
[15:09] <michaelni> They could be usefull for remuxing, testing and should improve ffprobe output (codec name). Also its a step toward hevc support, we have to start somewhere with commiting and pushing
[15:11] <Paranoialmaniac> michaelni: i don't recommend pushing these patches. the format is still in a draft. not finalized yet
[15:15] <michaelni> Paranoialmaniac, IMHO we should support draft based files even after the specifications become final, we do similarly with mpeg4-asp for example where all kinds of pre final cases are supported in the decoder
[15:15] <Paranoialmaniac> l-smash and divx uses configurationVersion=0 which indicates a draft ver. and the draft format may be changed more.
[15:24] <Paranoialmaniac> michaelni: i dislike supporting draft files. this is similar with the reason supporting a bugged file which makes a spec-compliant file broken result
[15:26] <michaelni> spec compliant files must always be decoded correctly, and none of the pre spec support we have in mpeg4-asp should affect spec compliant files though i guess iam drifting off topic
[15:27] <michaelni> Paranoialmaniac, would you be interrested in maintaining the mkv or mp4 demuxers in ffmpeg ?
[15:27] <Paranoialmaniac> i don't know mkv
[15:27] <michaelni> ok
[15:28] <michaelni> i was asking because generally ffmpeg tries to support everything (at least when its easy and files exist in the wild)
[15:30] <michaelni> and these 2 dont have active maintainers so theres no maintainer to ask about his oppinon on possible pre spec support
[15:33] <Paranoialmaniac> i don't have much time. my hand is full by my own project
[15:34] <michaelni> "not much" is more than the current maintainers put into mp4, and this is quite sad as .mp4 is an important format
[15:34] <Daemon404> this reminds me...
[15:35] Action: Paranoialmaniac dislikes mp4 :P
[15:35] <Daemon404> at VDD, Thierry Foucu mentioned ending multiple edit list entry support
[15:36] Action: Daemon404 wonders what happened to that; would love to ditch his scripting for that edge case
[15:40] <Paranoialmaniac> i don't want to maintain unless it is a paid work or what i need
[15:42] <michaelni> Paranoialmaniac, maybe thierry would pay for it if you also implement full edit list support
[15:42] <Daemon404> michaelni, thierry told me he already wrote a patch for this
[15:42] <Daemon404> supposedly.
[15:43] <Daemon404> maybe is misheard
[15:43] <Daemon404> i*
[15:43] <michaelni> yes, i rememer too, i thought he wanted to send it to the ML
[15:43] <Daemon404> he told me he would...
[15:43] <michaelni> not sure if it was sent
[15:43] <Paranoialmaniac> edit list support is so hard...
[15:43] <Daemon404> it wasn't
[15:53] <mraulet> michaelni,  the patch on openhevc/wrapper is not needed since most of the code is reported to the patch 4/7 
[16:31] <michaelni> mraulet, what to you mean by "the patch on openhevc/wrapper" ? the "[PATCH 7/7] lavc: add libopenhevc support" ?
[16:33] <mraulet> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-October/149333.html
[16:33] <mraulet> this one is enough
[17:19] <michaelni> ubitux, Daemon404 durandal_1707, others, does anyone of you object to the hevc patch being applied ?
[17:19] Action: michaelni wishes he could just do usefull work instead of this
[17:22] <saste> michaelni, ping on [RFC] Change av_get_channel_layout() syntax
[17:22] <iive> i didn't quite get what the issue with the patch is...
[17:23] <durandal_1707> that ffmpeg would get hevc before libav
[17:23] <Daemon404> michaelni, ... have the issues ubitux linked to been addressed?
[17:23] <Daemon404> they are not small issues.
[17:24] <michaelni> ubitux, linked to the patch itself unless iam mistaken
[17:24] <Daemon404> he did not
[17:24] <Daemon404> you clearly didnt read what he linked
[17:24] <Daemon404> the hevc decoder still suffers from invali memory use, causing failures in some areas
[17:24] <Daemon404> and some frame mt 'issues'
[17:25] <michaelni> so does jpeg2000
[17:25] <iive> openhevc or elenril's hevc?
[17:25] <Daemon404> both
[17:25] <Daemon404> it has overreads etc
[17:25] <Daemon404> initially they thought it was a BE arch issue, but its not.
[17:25] <iive> mpeg2 also have overreads.
[17:25] <Daemon404> ...
[17:26] <iive> maybe we should disable it...
[17:26] Action: Daemon404 cant believe how ridiculous these arguments for merging RIGHT AWAY GODDAMMIT
[17:26] <Daemon404> gotta have it first!!!!
[17:26] <michaelni> jpeg2000 also has overreads and its not marked experimental
[17:26] <Daemon404> it alos uses unitiliazlied data
[17:26] <Daemon404> which ALSO causes failures
[17:26] <Daemon404> it is not ready to be erged
[17:26] <Daemon404> learn soem goddamn patience
[17:26] <Daemon404> -_-
[17:27] <iive> well, none of these are ffmpeg problem..., are they?
[17:27] <Daemon404> uhhhhhhh
[17:27] <Daemon404> what?
[17:27] <iive> i mean, hevc problems...
[17:27] <Daemon404> problems with code being merged into ffmpeg is not  ffmpeg's problem?
[17:27] <iive> or more specificly openhevc... 
[17:27] <Daemon404> what sort of drugs do ou do?
[17:27] <durandal_1707> if michaelni what to fix those problems, i'm ok with merge, otherwise noe
[17:27] <durandal_1707> *not
[17:28] <durandal_1707> Daemon404: libmpcodecs
[17:28] <Daemon404> durandal_1707, id rather not repeat that
[17:28] <Daemon404> ever.
[17:28] <wm4> merge mplayer's libvo to improve libavdevice!
[17:29] <durandal_1707> wm4: patchwelcome
[17:30] <iive> michaelni: are you talking about openhevc patch or merging elenril's hevc, or both?
[17:30] <michaelni> Daemon404, the link from ubitux does not link to any clear or useable bug descriptions and no hint to overreads
[17:30] <durandal_1707> iirc openhevc one is already rejected
[17:31] <iive> why?
[17:31] <Daemon404> michaelni, yes because theyre being discussed by teh actual authors of the patch
[17:31] <Daemon404> on irc
[17:31] <michaelni> and the frame threading issue thats mentioned sounds lie just a performce thing
[17:31] <iive> authors don't want ffmpeg to use it?
[17:31] <Daemon404> this is what happens when you just go and try to merge shit without the involvement of the authors
[17:31] <Daemon404> iive, no its *not done yet*
[17:31] <Daemon404> which is my point
[17:31] <iive> what is not done?
[17:31] <Daemon404> the hevc decoder!
[17:32] <Daemon404> michael just suddenly decided he wants to merge it
[17:32] <iive> x264 is not done yet, is it?
[17:32] <Daemon404> .... all of your arguments are fuckign retarded
[17:32] <Daemon404> at bets
[17:32] <Daemon404> strawmen
[17:32] <Daemon404> best*
[17:32] <michaelni> iive,  none of the authors objected 
[17:32] <Daemon404> michaelni, yes merge it *once it's fixed*
[17:33] <Daemon404> uninitialized data usage is kind of Not Cool
[17:33] <iive> Daemon404: is there bugreport for it? with a test case?
[17:33] <michaelni> the decoder would be marked as experimental
[17:33] <Daemon404> why would there be a bug report
[17:33] <Daemon404> for a WIP?
[17:33] <iive> to fix it. of course
[17:33] <michaelni> yes
[17:33] <iive> this is ffmpeg, not libav
[17:34] <Daemon404> how is this at all relevant
[17:34] <Daemon404> seriosly, do you ever have idea what the hell youre talking about, iive?
[17:34] <Daemon404> like, ever?
[17:34] <iive> Yes, I do. The problem is that you are unable to understand me.
[17:35] <iive> don't worry, you are not the only one.
[17:35] <michaelni> Daemon404, that "merge it *once it's fixed*" story is told since how long ? years ?
[17:35] <Daemon404> what exactly is teh benefit or merging in a broken decoder?
[17:36] <ubitux> decoding hevc
[17:36] <Daemon404> emphasis on broken
[17:36] <Daemon404> it relies on uninit'd data on all archs
[17:36] <Daemon404> if it works
[17:36] <Daemon404> its by coincidence
[17:36] <ubitux> michaelni: i don't really mind if that eases your work on it
[17:36] <iive> Daemon404: in essence it is cathedral vs bazaar development model. we are waiting for somebody to fix something, instead of working together to fix it.
[17:37] <iive> I got that ffmpeg is not that territorial in its philosophy.
[17:37] <ubitux> Daemon404: it's experimental, so...
[17:37] <Daemon404> again
[17:38] <Daemon404> hat is the benefit of merging
[17:38] <Daemon404> otehr than being "First"
[17:38] <ubitux> ease the work on it
[17:38] <Daemon404> what work
[17:38] <ubitux> fixing those issues?
[17:38] <Daemon404> ffmpeg has literally done nothing on it
[17:38] <Daemon404> until a few hrs ago
[17:38] <ubitux> because it was never submitted to ffmpeg-devel?
[17:38] <iive> well, this is because we've been waiting for over a year
[17:38] <iive> to be done and merged in libav...
[17:38] <Daemon404> OH NOES WE CANT DECODE ALL THE NON-EXISTENT HEVC STREAMS
[17:39] <Daemon404> the spec wast even finalized until recently
[17:39] <iive> you are aware that the mpeg4-asp decoder doesn't implement all iso14496-2 features, are you?
[17:39] <wm4> what the hell is the problem? on Libav side, the decoder is becoming ready for merge
[17:40] <Daemon404> iive, again. strawman argument.
[17:41] <iive> Daemon404: maybe it is not that you can't understand me, maybe you just don't want.
[17:54] <durandal_1707> let them cry! merge time.
[17:56] <durandal_1707> and than release 3.0
[18:00] <durandal_1707> much better than certain fork that still have fully broken decoder
[18:00] <wm4> make it 4.0, to be one step ahead
[18:07] <michaelni> Daemon404, ive decoded 2 hevc files under valgrind there are no anomalies here
[18:07] <Daemon404> iirc its only with some samples
[18:07] <Daemon404> and no, i dont have info on which
[18:08] <Daemon404> if you really feel you need to merge right goddamn now, im just going to sit back with popcorn
[18:08] Action: Daemon404 is no longer involved, disavows all knowledge, and awaits lulz
[18:09] <michaelni> its no problem to wait a day, also no problem for me to fix a few bugs, but this "ohh god dont apply that patch its not done" is very puzzling to me
[18:10] <iive> it's just fud
[18:10] <Daemon404> and waiting until a few days before its merged in libav and deciding "i must merge it right now" is puzzling to me
[18:10] <michaelni> its "few days" ?
[18:10] <michaelni> can you be more specific ?
[18:10] <iive> say a number
[18:10] <Daemon404> wat
[18:11] <Daemon404> foss had deadlines now?
[18:11] <iive> say how many days we should wait for these bugs to be fixed
[18:11] <Daemon404> im saying i dont give a fuck
[18:11] <iive> yes, 2 weeks for linux kernel.
[18:11] <Daemon404> enjyo your penis waving competitio
[18:11] <Daemon404> n
[18:11] <Daemon404> as i said
[18:11] <Daemon404> im am sitting back andd watching
[18:11] <Daemon404> i am not ivolved.
[18:11] <Daemon404> pretend im not here.
[18:12] <durandal_1707> How many k&r rounds does it take to push a patch?
[18:12] <iive> between 5 and 7
[18:14] <iive> don't forget to sort the files alphabetically.
[18:14] <kierank> Daemon404: choose your poison
[18:15] <Daemon404> kierank, ?
[18:15] <kierank> Daemon404: spacing review or dick waving contest
[18:15] <Daemon404> i chose a third option
[18:15] <Daemon404> to sit with popcorn
[18:15] <Daemon404> and watch.
[18:31] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:522f78f8eabf: avformat/oggparseopus: fix nb_headers
[18:39] <michaelni> mraulet, smarter, AFAIK you 2 are the 2 main authors of the hevc code, thus my question, should i merge it now (that is today/within a few days) or should i wait because of something (major bugs, the authors preferring that we dont merge it yet, whatever) ?
[18:56] <mraulet> we now are 3, the code has been a lot refactored by elenril
[19:02] <michaelni> i understand, and what preferrance do the 3 of you have ? merge or wait?
[19:05] <mraulet> I like consensus between people, I need to interact with them
[19:05] <michaelni> yes, of course
[19:34] <BBB> Daemon404: you really should listen more carefully to intelligent bystanders such as kierank - there is a lot of highly satirical - but true! - commonsense coming out of 'em
[19:35] <Daemon404> there's a relevant lesson from the simpsons here
[19:35] <Daemon404> http://www.youtube.com/watch?v=nhjGoaKf52s
[19:35] <Daemon404> ^
[19:36] <BBB> I like south park's morale: blame canada
[19:36] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:ac3b01a9c060: avcodec/jpeg2000dec: check transform equality in MCT
[19:42] <cone-735> ffmpeg.git 03Marton Balint 07master:b118d3e24d35: ffplay: factor out putting null packet into the queue
[19:42] <cone-735> ffmpeg.git 03Marton Balint 07master:0258e4dc8ba8: ffplay: add null packet after attached pics packet
[19:42] <cone-735> ffmpeg.git 03Marton Balint 07master:543d81a7072c: ffplay: cycle through the streams of the current program, and not every stream
[19:42] <cone-735> ffmpeg.git 03Marton Balint 07master:3130416aecc8: ffplay: add support for changing the channel by the C key
[19:42] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:ede7602cba81: Merge remote-tracking branch 'cus/stable'
[21:49] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:e54f4510aa45: avcodec/jpeg2000: zero i/f_data
[21:49] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:fe448cd28d67: avcodec/jpeg2000dec: prevent out of array accesses in pixel addressing
[22:09] <smarter> michaelni: as people said, the patch is still buggy, incomplete, and people are working on it
[22:09] <smarter> I don't think merging it in ffmpeg and marking it experimental is going to be a big problem, which is why I'm not opposed to it
[22:10] <smarter> but I don't think it's worth it (and certainly not worth the drama...)
[22:24] <cone-735> ffmpeg.git 03Paul B Mahol 07master:3fd79833e266: avformat: add ff_alloc_extradata() helper
[22:24] <cone-735> ffmpeg.git 03Paul B Mahol 07master:a807c68253b0: avformat: use ff_alloc_extradata()
[22:24] <cone-735> ffmpeg.git 03Paul B Mahol 07master:5340c3dd8d2a: avformat/westwood_vqa: s/unsigned char/uint8_t & s/unsigned int/uint32_t
[22:26] <llogan> i wonder why --compose ignored my subject.
[22:27] <ubitux> isn't git already a synonym of stupid?
[22:27] Action: durandal11707 spotted typo
[22:27] <gitarded> where?
[22:27] <gitarded> ubitux: then this (temp) nick is a double negative.
[22:29] <gitarded> durandal11707: in my x11grab doc patch?
[22:30] <durandal11707> no, in nick
[22:34] <ubitux> durandal11707: are you registered to cvslog?
[22:35] <durandal11707> you want to tell me something?
[22:35] <ubitux> i was having a look to the extradata diff
[22:35] <ubitux> and i was wondering if i could reply on cvslog
[22:35] <ubitux> but if you prefer over irc fine with me as well
[22:36] <ubitux> i have 2 things that bug me a little
[22:36] <durandal11707> what is bugging you?
[22:37] <ubitux> first is not important, but you are considering any ff_alloc_extradata as a ENOMEM error even if that function can actually raise different error code
[22:37] <ubitux> you certainly did that so the diff is less error prone so fine with me
[22:37] <ubitux> second one is the zero init of the full buffer in some cases
[22:37] <ubitux> which doesn't happen all the time with your code
[22:37] <durandal11707> and?
[22:38] <ubitux> mallocz was likely called for padding, but sometimes it might not have
[22:38] <ubitux> see for example bink
[22:38] <ubitux> what happen if less than 4 bytes are read
[22:38] <ubitux> probably relevant for a few other formats
[22:38] <ubitux> you might have some uninitialized data in some cases
[22:39] <durandal11707> well you can consider it as bug into bink
[22:39] <ubitux> in the second case, i see a AV_WL32
[22:39] <durandal11707> i can use mallocz in ff_alloc_extradata and do not bother with it ...
[22:39] <ubitux> oups no second one is fine
[22:40] <ubitux> durandal11707: yeah, probably
[22:40] <ubitux> or we could check every format
[22:40] <ubitux> or have an extra parameter for zero full zero init
[22:40] <ubitux> most extradata buffers are not so big anyway
[22:41] <ubitux> see flv as well
[22:41] <ubitux> and well, probably a bunch of others
[22:42] <ubitux> i would suggest a 0 memset, since it could introduce random uninit reads
[22:43] <wm4> uh so what's wrong with mallocz?
[22:43] <ubitux> ?
[22:43] <wm4> to clear
[22:45] <durandal11707> hurts performance
[22:45] <durandal11707> a little
[22:45] <wm4> allocating big chunks of memory with calloc() makes clearing free (because mmap(), which will be used by calloc, already clears anyway)
[22:46] <ubitux> wm4: see av_mallocz()
[22:46] <ubitux>     if (ptr)
[22:46] <ubitux>         memset(ptr, 0, size);
[22:46] <wm4> hurr
[22:46] <ubitux> it's not free in ffmpeg
[22:46] <ubitux> we can't call calloc because of alignment
[22:47] <durandal11707> there is av_calloc but it is not calloc
[22:49] <ubitux> correct thing would just be to check reads() in those formats
[22:51] <ubitux> s/would/could/
[22:57] <durandal11707> wm4: why mpv does not support gbrap16?
[22:59] <ubitux> does changing the link->frame_rate in filters affects anything?
[23:00] <ubitux> durandal11707: since decimate is adjusting the link frame_rate, is it enough for time stamping?
[23:00] <ubitux> (is your patch dropping the ts adjustment fixing the sync issue?)
[23:01] <durandal11707> dunno, the only problem would be some frames are too long displayed on screen
[23:01] <ubitux> you mean it would defeat the purpose of the ivtc process?
[23:01] <durandal11707> ubitux: for sample i have it fixes async
[23:02] <ubitux> and what's the out frame rate?
[23:02] <durandal11707> ubitux: input is ~29 out is ~25
[23:02] <ubitux> well then that's likely correct; did you check if the ts are constant in the output?
[23:03] <ubitux> ts diff*
[23:03] <durandal11707> is not constant obviously
[23:03] <ubitux> then it's not correct
[23:03] <durandal11707> but you do not change time_base ....
[23:04] <ubitux> i guess the time base needs to be adjusted as well then
[23:04] <ubitux> just like fps
[23:04] <durandal11707> ubitux: do you mean created output of what decimate returns?
[23:04] <durandal11707> i just checked what decimate returns
[23:05] <durandal11707> s/of/or
[23:05] <durandal11707> you can check yourself, there is sample on trac
[23:05] <ubitux> yeah but i was lazy
[23:05] <ubitux> or actually working on sth else
[23:06] <ubitux> but i guess ill have to put it in standby again
[23:06] <ubitux> well no, i can't stop right now, it will be a pain to start over
[23:13] <ubitux> durandal11707: if adjusting frame_rate field makes no effect, then changing the time base (and dropping the ts computation) might do the trick
[23:13] <ubitux> but now i'm curious about cases where frame_rate is inconsistent with the timebase
[23:13] <ubitux> well, i'll eventually look at this later
[23:27] <ubitux> BBB: i'm not sure i can use pmulhrsw
[23:28] <ubitux> or well, maybe i should update the multiplier for the precision
[23:31] <ubitux> i basically want this:
[23:31] <ubitux> >>> '%04x' % ((0x3a * 0x2d41 + (1<<13)) >> 14)
[23:31] <ubitux> '0029'
[23:31] <ubitux> but i have this with pmulhrsw:
[23:31] <ubitux> >>> '%04x' % ((0x3a * 0x2d41 + (1<<14)) >> 15)
[23:31] <ubitux> '0015'
[23:32] <ubitux> i'm afraid of ±1 rounding differences if i update the factor
[23:33] <ubitux> (because of too accurate rounding)
[23:40] <ubitux> so basically 0x5a82 instead of 0x2d41 do the trick for now, but i'm expecting potential problems 
[23:43] <ubitux> it looks like vp8 is doing a x2 on the source, for the same purpose
[00:00] --- Mon Oct 14 2013