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

[burek]

[00:10] <Compn> hooo boy
[00:10] Action: Compn approves a flame from debian devel
[00:11] <kierank> I don't even understand that email
[00:11] <Compn> kierank : its classic debian double-speak
[00:12] <Compn> the same reason why xine (with libavcodec) was in debian for years but mplayer (with libavcodec) was rejected 
[00:12] <Compn> very very old "mplayer rejection" 
[00:12] <J_D> Everything in debian is old
[00:12] <J_D> I don't know why people care about it
[00:13] <Daemon404> some of us run servers
[00:13] <Compn> yeah, and you want 10 year old openssl bugs :)
[00:13] <Compn> ehe
[00:13] <Daemon404> you dont need 10 year old bugs
[00:13] <Daemon404> there are penty of new ones too
[00:13] <kierank> Daemon404: in b4 use gentoo
[00:13] <J_D> I'm sure a lovely old server is good
[00:13] <J_D> but I hate it as a user
[00:14] <Daemon404> so dont use it
[00:14] <J_D> I try not to
[00:14] <kierank> Compn: actually yes Debian did that to x264
[00:14] <kierank> They picked some ancient version because it was more stable
[00:15] <Daemon404> x264 is not suitable to be packaged
[00:15] <kierank> Not understanding one point of a new version is to fix bugs
[00:15] <Daemon404> full stop
[00:15] <J_D> Instead of ranting further I will just be quiet.
[00:15] <wm4> that mail by Mr. Allbery is rude
[00:15] <wm4> does he even have a fucking clue
[00:15] <kierank> Daemon404: why
[00:16] <Daemon404> kierank, it (used to) break api and abi constantly, no releases, etc
[00:16] <Daemon404> unless you like rebuilding stuff constantly
[00:16] <wm4> I don't understand why something as simple as x264 needs to break abi all the time
[00:17] <Daemon404> it doesnt anymore, obv
[00:17] <Daemon404> since dev is more or less "done"
[00:19] <Daemon404> ok i just read that debian guy's email
[00:19] <Daemon404> ... rofl
[00:19] <Daemon404> what sort of drugs do these people do
[00:20] <Daemon404> " I'm glad that FFmpeg takes security
[00:20] <Daemon404> seriously, but what FFmpeg needs is to *have fewer security bugs*."
[00:20] <Daemon404> yes, just code less bugs
[00:21] <Daemon404> such an easy solution!
[00:23] <kierank> wm4: it's because of obscure features
[00:23] <kierank> Unless you want the api to be x264_set_opt
[00:24] <wm4> would probably be better... I only loathe such APIs for core things
[00:26] <J_D> I wonder, would you have to pass quantiser offsets as a string?
[00:51] <wm4> "It would be nice, if everyone, including you, would refrain from posting such flamebaits on debian-devel."
[00:52] <wm4> he's posting that only now...
[00:52] <wm4> "Indeed it's getting late, because the FFmpeg package has been waiting in the NEW queue for more than 3 months."
[00:52] <wm4> debian...
[01:25] <BBB> the whole thread is kinda funny
[01:26] <BBB> let me tell you guys, if you all used gerrit, you wouldnt fight so much anymore"
[01:26] <J_D> ubitux: are you still around?
[01:26] <BBB> if libav just stops reviewing and ffmpeg makes less experimental stuff, youll all get along again"
[01:26] <Daemon404> BBB, my favourite is still "just write less bugs"
[01:26] <BBB> true
[01:26] <BBB> theyre all quite monumental
[01:31] <kierank> Daemon404 and wm4: you have made my day
[01:33] <Daemon404> kierank, i dont really know how to react to his reply
[01:33] <Daemon404> it's surreal.
[01:34] <kierank> ask him to translate what he said to english
[01:34] <kierank> "and putting systems in place that let the computer do
[01:34] <kierank> lots more security sanity checking for you"
[01:36] <j-b> Statistically, more features means more bugs and more security issues
[01:37] <wm4> > * Don't write bugs.  
[01:37] <wm4> That's a really bad way of avoiding security bugs.
[01:38] <wm4> ^ ok that really is a strange mail
[01:38] <Daemon404> i wondered what drugs he was on
[01:38] <Daemon404> then i noticed he wrote a lot of kerberos stuff
[01:38] <Daemon404> krb5 etc
[01:38] <Daemon404> ALL the drugs
[01:39] <Daemon404> in any case
[01:39] <Daemon404> i am simply not going to reply
[01:39] <Daemon404> i dont feel like arguing on the internet right now
[01:39] <Daemon404> not for something liek this.
[01:40] <wm4> one should troll them with the debian valgrind disaster
[01:40] <wm4> (although openssl or what it was could be blamed for that equally)
[01:41] <BBB> oh kerberos
[01:41] <BBB> kerberos is wonderful
[01:42] <BBB> & if youre on drugs
[01:42] <BBB> anyway, Im gonna say that bugs dont happen in our relevant decoders (h264, vp8), these are well-tested, -maintained, safe etc.
[01:42] <BBB> our RE code isnt always so good& especially stuff that was REed early on and basically just dumped x86 assembly back into C
[01:43] <BBB> nowadays we tend to do better
[01:43] <Daemon404> enjoy your internet arguments
[01:43] <Daemon404> it's likely not worth anyone's time IMO
[01:43] <BBB> Im not getting into any
[01:43] <J_D> ubitux: let me know, somehow, if you object to me putting 680 MiB of test files on that laptop and if you have a preferred time for when I can do this.
[01:43] <BBB> I wasnt gonna post it
[01:43] <BBB> just saying it here
[01:43] <Daemon404> o ok
[01:52] <jamrial> J_D: If you mean the fate test suit, it's already there
[01:52] <jamrial> ah, missed him
[01:56] <kierank> 12:40 AM <"wm4> one should troll them with the debian valgrind disaster --> haha
[01:57] <Daemon404> i would point out all the *grind and *san instances we run
[01:57] <Daemon404> or well, all of FATE
[01:57] <Daemon404> but i cant be arsed
[02:00] <BBB> I also see theres this whole libav subtrhead that is not cced to ff-devel?
[02:00] <BBB> better would be an auto-fuzzed based on fate to test for crashes
[02:00] <Daemon404> the amount i care about it is so little that i have not bothered to even look.
[02:00] <BBB> lol
[02:00] <BBB> anyway
[02:00] <BBB> yeah
[02:00] <BBB> who cares
[02:01] <Daemon404> i used to run an instance that would randomly fail allocs
[02:01] <Daemon404> but there were so many unchecked allocs, it got boring
[02:10] <BBB> yeah its mostly a theoetical thing here
[02:10] <BBB> we do something on 80% of allocs if they fail
[02:10] <BBB> but the something is rarely actually tested
[02:11] <wm4> from a security perspective it might be better to abort() in av_malloc if allocation fails
[02:13] <Compn> wow that raa guy email is hard to read
[02:13] <Compn> :D
[03:11] <iive> to be honest, I'm starting to think that debian wants some cold hard cash in order to let ffmpeg in
[07:09] <msca> are there any lossless hardware encoders for audio streams?
[07:09] <msca> and any hardware for high density parallel stream decode?
[09:52] <Case> I have been testing WMA Lossless recently and it seems to me that ffmpeg's decoder fails to decode every single WMAL file incorrectly. Tens of thousands of samples are missing from the end of the file
[11:29] <cone-824> ffmpeg.git 03Timothy Gu 07master:32c712f1437b: vidstabutils: fix indentation
[11:49] <cone-824> ffmpeg.git 03Nicolas George 07master:4f3e2f107b63: ffprobe: add -show_data_hash option.
[12:52] <cbsrobot> kurosu_: ping
[13:21] <nevcairiel> someone should port the intrinsic hevc idct's from openhevc to yasm, i applied them as-is and it improved speed by over 50%, i was like, wow :d
[13:22] <nevcairiel> (but i suck too much at yasm to do it myself)
[13:23] <wm4> compile, disassemble? :D
[13:23] <JEEB> lol
[13:24] <beastd> intrinsics re ;D
[13:25] <nevcairiel> wm4: can just get the compiler to give me a assembly output, but yeah, thats ugly :D
[13:28] <nevcairiel> i should run fate on the intrinsics and just keep em in my fork
[13:48] <ubitux> michaelni: no need to review the usage of bdiff thing, i'll probably drop that, sorry (i think i said it in one of the reply)
[13:49] <ubitux> michaelni: i'm interested in the asm review though
[13:52] <ubitux> thx :)
[14:33] <J_Darnley> ubitux: did you see my question from severa hours ago?
[14:33] <J_Darnley> *several
[14:33] <ubitux> yes, feel free to sync the fate samples
[14:34] <J_Darnley> They're not the fate samples but files I was using to test here.
[14:34] <ubitux> yeah sure go ahead
[14:35] <J_Darnley> will do
[14:43] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:cabcd8ff66ef: avformat/movenchint: use av_freep() for safety
[14:43] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:afe23e430e2d: vcodec/rpza: print mismatching size in case of error
[14:43] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:b6c9266722d7: avcodec/rpza: fix +- error
[14:47] <kurosu_> nevcairiel, yeah, I also have the sao applied too
[14:48] <kurosu_> I'm most often basing my benchmark on those because current status is not representative of a future good reference
[14:48] <nevcairiel> how much does the sao do?
[14:48] <kurosu_> I don't remember, probably 5-10%
[14:48] <nevcairiel> hm might just try it
[14:50] <kurosu_> going to rebase before pushing to github
[14:51] <kurosu_> cbsrobot, pong ?
[14:52] <kurosu_> the openhevc guys were contracted for maybe 2 years, an plepere should quit around october iirc
[14:52] <nevcairiel> more time to work on yasm then!
[14:54] <kurosu_> I'm not sure plepere is that found of it - most asm in openhevc is first intrinsics (then get ported to yasm if they can spare the effort)
[14:55] <kurosu_> https://github.com/kurosu/ffmpeg/commits/hevc_mt <- with some working yet useless patches too
[14:55] <kurosu_> iirc, ~110fps with 6 cores on 1080p
[14:56] <nevcairiel> that seems slow
[14:56] <kurosu_> yeah :(
[14:56] <kurosu_> most time is spent on cabac though
[14:56] <kurosu_> but that's a 4yo 6 core too
[14:56] <kurosu_> per core, my laptop is like 40% faster
[14:57] <kurosu_> HEAD is probaly around 60
[14:57] <kurosu_> on the 6 cores
[14:58] <kurosu_> note: manual commits, run configure with --extra-cflags="-msse4.2"
[15:01] <nevcairiel> yeah, that part is annoying, in my idct change i added a bunch of gcc pragmas to enable it only for that particular file
[15:01] <nevcairiel> i think its stupid, msvc manages to build intrinsics without optimizing the whole code base
[15:04] <kurosu_> it's possible with ffmpeg, but the build system needs to be modified, and that's a fruitless effort, given asm maintainers don't want to have intrinsics
[15:04] Action: Daemon404 is reminded to update yasm to 1.3
[15:04] <kurosu_> last time I tried, intrinsics were giving me some unneeded moves
[15:04] <Daemon404> kurosu_, wouldnt that depend on teh compiler / version used too
[15:05] <kurosu_> yes, but that was at least 4.6
[15:05] <kurosu_> if not 4.8
[15:05] <kurosu_> might also have been PEBKAC
[15:05] <nevcairiel> i didnt want to mess with the build system, so I just went with pragmas
[15:05] <kurosu_> I'm thinking in x264asm then I have to translated in intrinsics
[15:06] <nevcairiel> they require 4.8 i think, but what do i care
[15:06] <kurosu_> nevcairiel, indeed, like my extra cflags hack
[15:07] <Daemon404> kurosu_, the few times ive done asm, x264asm seemed less annoying than intrinsics
[15:07] <Daemon404> but i was also only targeting one OS on oen arch.
[15:08] <kurosu_> x264 alleviates a lot of work, but you still have to bother with a bit of abi
[15:08] <kurosu_> in particular if you optimize reg usage
[15:08] <Daemon404> kurosu_, i was only targeting x86_64 linux
[15:08] <Daemon404> that eased most of that pain
[15:09] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:94f60b65446b: avcodec/h264_mb: fix grayscale only decoding with weighted prediction
[15:09] <kurosu_> well, the optimizaton isn't possible with intrinsics most of the time anyway so that's self-inflicted pain
[15:09] <nevcairiel> intrinsics are just easy, especially if you have a lot of variables to work with, and try targeting 32-bit as well
[15:09] <kurosu_> on the other hand, hevc instrinsic code on 32bits yield little to no improvement iirc
[15:10] <nevcairiel> the idct seemed to help on 4k content
[15:10] <kurosu_> but it was some time ago when there wasn't asm for even mc
[15:10] <kurosu_> I bet it does seeing how the 32x32 transform must be prevalant
[15:11] <nevcairiel> i didnt benchmark 32-bit th o
[15:12] <kurosu_> I haven't either, but you can imagine there's a whole lot of nothing to code for 4K
[15:13] <kurosu_> btw, my comment about intrinsics 32bits was on the mc only
[15:22] <J_D> (wtf was that?)
[15:22] <J_D> I'll ask again incase my message didn't go through...
[15:22] <J_D> Where's the "master" source for the open hevc code?
[15:23] <Daemon404> https://github.com/OpenHEVC/openHEVC
[15:27] <J_Darnley> Bloody github!  What's wrong with black text?
[15:29] <kurosu_> https://github.com/OpenHEVC/openHEVC/tree/hevc_rext even
[15:30] <cdecl_xyz> hello, i have questions regarding libswscale and how to do proper colorspace conversion (full range -> smpte range). is this the right place?
[15:30] <cdecl_xyz> i see, it must be #ffmpeg i guess. nevermind
[15:31] <cone-824> ffmpeg.git 03Christophe Gisquet 07release/2.3:9794727ccd24: proresenc_kostya: remove unneeded parameters
[15:31] <cone-824> ffmpeg.git 03Christophe Gisquet 07release/2.3:60bfa9154d00: proresenc_kostya: report buffer overflow
[15:31] <cone-824> ffmpeg.git 03Justin Jacobs 07release/2.3:59d98fc05078: avformat/matroskadec: Check avpriv_new_chapter() for failure
[15:31] <cone-824> ffmpeg.git 03Christophe Gisquet 07release/2.3:35738e589847: proresenc_kostya: properly account for alpha
[15:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/2.3:10c2d22ba195: avcodec/mjpegdec: Support AV_PIX_FMT_YUV420P16 with upscale_h
[15:32] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/2.3:4f187f0af13b: avformat/mpegts: Use differential score for analyze()
[15:32] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/2.3:3b6bde3b3de4: avcodec/h264_mb: fix grayscale only decoding with weighted prediction
[15:32] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/2.3:bc259185cb69: Update for FFmpeg 2.3.3
[15:32] <J_Darnley> kurosu_: it looks like github points you to the branch anyway
[15:33] <kurosu_> J_Darnley, ok
[15:47] <J_Darnley> blimey!  only 196 MiB!
[15:49] <cone-824> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.3.3': unknown revision or path not in the working tree.
[15:49] <cone-824> Use '--' to separate paths from revisions
[15:49] <cone-824> refs/tags/n2.3.3:HEAD: avcodec/h264_mb: fix grayscale only decoding with weighted prediction
[17:30] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:c285db74f647: avformat/utils: do not wait for packets from discarded streams for genpts
[17:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:f70ee7d14fcf: avcodec/dvdsub_parser: never return 0 when the input isnt 0
[17:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:454f6c622c45: avcodec/dvdsub_parser: Check buf_size before reading 32bit packet size
[17:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:b4632cec7401: avcodec/dvdsub_parser: print message if packet is smaller than the packet size field
[17:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:ca232ff9b0af: avformat/tee: flip assigment direction
[17:31] <cone-824> ffmpeg.git 03Anton Khirnov 07release/1.2:f712d3669e2e: cdgraphics: do not return 0 from the decode function
[17:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:abc1fa7c5a1d: avcodec/iff: check pixfmt for rgb8 / rgbn
[17:31] <cone-824> ffmpeg.git 03Luca Barbato 07release/1.2:61a51598e343: lavc: move put_bits_left in put_bits.h (cherry picked from commit afe03092dd693d025d43e1620283d8d285c92772)
[17:31] <cone-824> ffmpeg.git 03Christophe Gisquet 07release/1.2:18342848f7fa: proresenc_kostya: report buffer overflow
[17:32] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:ab4e54f6f6b3: update for 1.2.8
[17:33] <michaelni> anyone wants to update th changelog for 1.2.8 ? if not ill do it later today 
[18:23] <michaelni> BBB, you are listed as http maintainer in MAINTAINERS, do you still maintain it ? iam asking as there are 2 patches from nicolas on the ML
[18:48] <p0nce> hi
[18:48] <p0nce> is endianness defined for y4m high bitdepth?
[18:49] <p0nce> currently I read/write y4m frames as is, I wonder if the format mandates one form
[18:51] <wm4> good question... libavformat's demuxer seems to always use native endian (?)
[18:52] <wm4> that doesn't sound right
[18:53] <wm4> same for encoding
[18:53] <p0nce> I have the same question about shifting bits to the right or the left of the 16 available bits in a sample
[18:54] <wm4> AFAIK formats like AV_PIX_FMT_YUV420P10 require you shift bits to get to 16 bit
[18:55] <wm4> +to
[18:59] <p0nce> ok, thanks
[19:00] <p0nce> it would help if C420p10 would become C420p10LE or C420p10BE
[19:39] <Compn> p0nce : reading yuv4mpegdec.c , it doesnt look like high bit 10/12/16 are defined one way or the other
[19:39] <Compn> which makes sense, as you can use LE or BE if you want
[19:40] <Compn> some formats require LE or BE , i know mov does it sometimes
[19:41] <Compn> libavformat/yuv4mpegenc.c also doesnt require LE or BE 
[19:42] <Compn> wm4 : its because the decoder handles both, so theres no reason to use LE or BE formats in the (de)muxer 
[19:42] <Compn> would just needlessly complicate things
[19:42] <Compn> and if you arent using lavc .... too bad.
[19:42] <Compn> :)
[19:50] <kurosu_> see libavutil/pixfmt.h
[19:52] <Compn> kurosu_ : what file explains the direction (left or right) of the shifting ?
[19:59] <BBB> michaelni: oh, rly? well I know the code..
[19:59] <BBB> michaelni: I can look, weblink to patches?
[20:00] <BBB> michaelni: oh, those, both ok
[20:06] <michaelni> BBB, thx, forwarded your approval to the ML
[20:06] <michaelni> i guess i could have just applied them instead, well doesnt matter much i guess
[20:06] <Compn> BBB : you want to be listed as maintainer of http ?
[20:07] <Compn> continued to be listed*
[20:07] <BBB> sure
[20:07] <BBB> I know the code
[20:07] <Compn> k :)
[20:07] <Compn> just making sure you werent listed erroneously
[20:07] <BBB> nah
[20:07] <BBB> I just didnt remember
[20:13] <p0nce> Compn: ok so let's suppose I write a y4m decoder, I would have to detect endianness?
[20:13] <BBB> is the idct order v/h) in hevc wrong"?
[20:16] <Compn> p0nce : um. 
[20:18] <BBB> fionag: do you know anything about this?
[20:18] <Compn> p0nce : possibly yes. i think the only difference you'd get is swapped uv though (red / blue colors switched)
[20:20] <p0nce> Compn: do you mean UV order also isn't defined in y4m?
[20:20] <p0nce> I would assume Y then U then V
[20:22] <Compn> no i mean if you decode LE or BE incorrectly, its usually the u and v gets swapped...
[20:22] <p0nce> ok
[20:22] <Compn> the uv order is defined by the colorspace used, which can be those formats listed in the dec/enc files
[20:23] <kurosu_> Compn, no idea, but pixdesc.[ch] contains the data on how to manipulate the data
[20:23] <Compn> i think you maybe confused on codecs, colorspaces and endianness 
[20:23] <kurosu_> I was only looking at it yesterday when trying to add some RGB3N format with N=10/12
[20:23] <Compn> yuv4mpeg only uses one codec iirc. which is raw yuv
[20:24] <Compn> then it can use any colorspace of raw yuv , which defines the amounts per bit of Y U and V planes (8bit 10/12 bit) and the endianness (byte structure, LE/BE)
[20:25] <Compn> i'm not really the one to be asking about codecs and colorspaces,  but i think the above is correct.
[20:25] <p0nce> ok, was just confused that endianness is to be guessed
[20:27] <BBB> kurosu_: you may know
[20:27] <Compn> i think the endianness check is only 10 or 20 lines of code. i could be wrong
[20:27] <BBB> kurosu_: http://x264dev.multimedia.cx/archives/486 point 5, idct ordering; is hevcs wrong?
[20:44] <ubitux> i missed some stuff in the comments of that post
[20:44] <ubitux> > Interlacing is a pretty clever compression method
[20:46] <JEEB> whom shall I cut?
[20:47] <BBB> interlacing is pure crap
[20:47] <BBB> its just a blast from 50 years ago and somehow we forgot to erase it
[20:48] <ubitux> hevc has no interlacing?
[20:48] <JEEB> yeah, you can just encode the fields separately
[20:48] <JEEB> and note that you're coding fields
[20:50] <cone-824> ffmpeg.git 03Piotr Bandurski 07master:a3329a09f934: avcodec/lcldec: fix decoding of YUV444 sample
[20:50] <cone-824> ffmpeg.git 03Nicolas George 07master:481cbc5ad578: lavf/http: fix cookie parsing.
[20:50] <cone-824> ffmpeg.git 03Nicolas George 07master:4bebce06175a: lavf/http: remove special case for cookies attributes.
[20:50] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:3d40ba3d8127: Merge remote-tracking branch 'cigaes/master'
[21:13] <fionag> BBB: what do you mean by wrong?
[21:13] <BBB> fionag: http://x264dev.multimedia.cx/archives/486 point 5
[21:14] <BBB> not wrong, just wrong
[21:14] <fionag> ohhhh.  I don'tknow what order they did it in
[21:14] <BBB> the wrong one :(
[21:15] <fionag> aw :<  that does slightly surprise me since H.264 had it "right"
[21:15] <BBB> indeed
[21:15] <fionag> but not *too* surprising since they don't seem to think very hard about software implementations
[21:42] <iive> BBB: actually interlace is worse than that. e.g. mpeg4 asp had it almost removed, there was only MB interlace support.
[21:43] <cone-824> ffmpeg.git 03Luca Barbato 07master:96ce6d6f119a: doc: Add more information in the README
[21:43] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:eb706575baa6: Merge commit '96ce6d6f119a16e489941c629a2805204322b717'
[21:44] <iive> the problem is that it popped up back, when they needed a trade back, that would cut bandwidth/decoding in half, by sending only half the data.
[21:44] <iive> tradeoff
[00:00] --- Mon Aug 18 2014