[00:13:41 CEST] <jamrial_> nevcairiel: ok to push the first two patches from the dts express set? [00:13:54 CEST] <jamrial_> they mostly move tables around [00:14:13 CEST] <jamrial_> foo86 should have created the first patch with the -B (detect rewrites) option to make it more readable [00:34:33 CEST] <nevcairiel> i cant say i looked at them much, but if you think its fine [00:35:23 CEST] <jamrial_> those two should [01:13:18 CEST] <cone-562> ffmpeg 03foo86 07master:2df7d4fa4524: avcodec/dca: move huffman data into separate object file [01:13:19 CEST] <cone-562> ffmpeg 03foo86 07master:1fee770a1cec: avcodec/dca: move channel counter utility into dca.h [04:25:16 CEST] <cone-280> ffmpeg 03Jan Sebechlebsky 07master:0ff3489534ea: avcodec/mjpeg2jpeg_bsf: Check ff_bsf_get_packet success [12:27:03 CEST] <wm4> "mpeg2 with alpha" [12:29:10 CEST] <Compn> wm4 : dont forget "in avi" [13:23:14 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:deaf58abf236: avcodec/mjpegdec: Do not try to detect last scan but apply idct after all scans for progressive jpeg [13:24:41 CEST] <kierank> always nice to see commits without anything on the ml [13:28:09 CEST] <wm4> you have to accept that some devs are above reviews [13:29:24 CEST] <ubitux> i asked michael for that problem [13:29:35 CEST] <ubitux> i can't share the sample unfortunately [13:30:19 CEST] <ubitux> (also, he's the maintainer of that file) [13:45:34 CEST] <durandal_1707> I hate this guy job [13:53:58 CEST] <kierank> durandal_1707: ? [13:54:07 CEST] <kierank> ami_stuff [13:54:08 CEST] <kierank> ? [13:56:11 CEST] <durandal_1707> yes [14:29:30 CEST] <BBB> durandal_1707: I would hate to do his job, but Im happy hes doing it [14:29:40 CEST] <BBB> durandal_1707: I guess thats what you mean? [14:30:29 CEST] <durandal_1707> I hate bugs [14:31:02 CEST] <kierank> durandal_1707: btw I spoke to cfhd author [14:31:35 CEST] <durandal_1707> you are very lucky [14:32:36 CEST] <durandal_1707> I failed to talk with tak and optimfrog authors [14:32:58 CEST] <wm4> (not too surprising) [14:33:29 CEST] <kierank> I spoke IRL [14:37:26 CEST] <durandal_1707> wow [14:37:35 CEST] <kierank> he was a cool guy [14:37:50 CEST] <durandal_1707> was? [14:40:17 CEST] <BBB> haha [14:40:22 CEST] <wm4> durandal_1707: multimedia is a tough business [14:40:34 CEST] <BBB> kierank: arent you the cfhd author? [14:40:41 CEST] <BBB> or you mean the guy that designed the codec? [14:40:45 CEST] <kierank> the guy that made the codec [14:43:25 CEST] <BBB> is this at that las vegas conference last month? [14:43:37 CEST] <BBB> nab, I guess [14:44:27 CEST] <BBB> brb [14:49:55 CEST] <Daemon404> [13:37] <+kierank> he was a cool guy <-- was he at all involved in the 'spec' [14:50:07 CEST] <kierank> yeah he said the spec was a disaster [14:50:11 CEST] <kierank> because of smpte politics [14:50:17 CEST] <kierank> and they've given up on it really [14:50:21 CEST] <Daemon404> lul. [14:50:56 CEST] <nevcairiel> so smpte actively wants those crappy specs for some reason? [14:51:05 CEST] <nevcairiel> i thought its just the companies behind the specs being stupid [14:54:28 CEST] <wm4> what kind of politics lead to a spec disaster? [15:02:23 CEST] <Compn> buzzword warfare [15:22:02 CEST] <ubitux> so BBB posted https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-2... like nothing happened [15:23:57 CEST] <Shiz> conclusion, vp9 is still slow as shit? [15:23:59 CEST] <ubitux> BBB: you didn't even shared your blog post [15:24:13 CEST] <BBB> what did I just run in to (re: shiz) [15:24:18 CEST] <BBB> ubitux: share where? [15:24:40 CEST] <ubitux> here at least :P [15:24:49 CEST] <BBB> I wondered if it was off-topic for ffmpeg :-p [15:24:51 CEST] <Daemon404> hackew news, reddit [15:24:53 CEST] <Daemon404> probably. [15:24:57 CEST] <Daemon404> ubitux loves karma [15:25:00 CEST] <Daemon404> im sure hell post it [15:25:04 CEST] <BBB> yeah I should probably do that [15:25:04 CEST] <kierank> I look forward to when it gets on streamingmediaeurope [15:25:07 CEST] <kierank> and you get lulz questions [15:25:23 CEST] <ubitux> Daemon404: yeah, just posted on HN [15:25:28 CEST] <Daemon404> ;p [15:25:28 CEST] <BBB> where do I post it on reddit? I never know where to put this kind of stuff& r/linux? [15:25:31 CEST] <BBB> or r/webm? [15:25:35 CEST] <kierank> r/programming [15:25:40 CEST] <BBB> r/vp9 is closed as violating the terms of use (gun-related, I think) [15:25:51 CEST] <ubitux> don't worry, it will be mirrored from HN [15:26:34 CEST] <BBB> ok so I dont need to do anything [15:26:49 CEST] <Shiz> obviously r/x264 [15:26:51 CEST] <mateo`> I think it's relevant here as an encoder using it may land ? [15:26:51 CEST] <Shiz> duh [15:27:15 CEST] <Daemon404> BBB, r/programming like kierank said [15:27:20 CEST] <Shiz> i don't see that happening very soon as long as it's proprietary :p [15:27:23 CEST] <mateo`> by encoder i mean an ffmpeg one [15:27:25 CEST] <BBB> Shiz: so, as for speed, typically if I can gain 5-10% and be faster than libvpx, its not hard to simply copy relevant speed settings for higher speed modes (cpu-used) and get the same speed gains [15:27:43 CEST] <BBB> Shiz: but obviously Im trying to do better than that, so I havent published anything on that subject yet for a reason [15:28:35 CEST] <ubitux> http://www.twoorioles.com/eve-vp9-video-encoder :( [15:31:00 CEST] <Shiz> BBB: well, good luck ;p [15:39:21 CEST] <Daemon404> i wonder how long until the big G attempts to buy out [15:39:46 CEST] <Daemon404> (asusming they even care about encoeer qualiy [15:40:28 CEST] <rcombs> "15-20% better than x264" with VP_9_ [15:43:06 CEST] <wm4> BBB: so uh when will you post a patch for a lavc wrapper [15:43:16 CEST] <BBB> is that useful? [15:43:24 CEST] <Daemon404> i cant imagine it will be accepted [15:44:03 CEST] <BBB> rcombs: 15-20% at 360p, thats not bad (given that vp9/hevc are primarily focussed on 1080p/4k) [15:47:56 CEST] <wm4> well somehow I expected that to become open source, but maybe I'm completely wrong there [15:48:20 CEST] <JEEB> if you can actually pay people's salary with it ;) [15:50:45 CEST] <BBB> ubitux: I fixed the website up with a few sentences on stuff.. Ill add images later, but ... [15:50:50 CEST] <BBB> Id rather code :-p [15:50:53 CEST] <Daemon404> wm4, something that is only useful if you have a commercial sdk is probably not useful to the general punlic [15:50:56 CEST] <Daemon404> public even [15:53:21 CEST] <BBB> wm4: so & yeah, about opensource & I need to figure out ways to make opensource work with paying the rent, and most attempts at that have not been very succesful if theyre purely single software piece based [15:53:29 CEST] <BBB> wm4: so Im not directly intending to opensource it [15:57:42 CEST] <BBB> so I would really like to get comments on the visual comparisons, do you guys think theyre helpful/fair/useful/...? [15:58:08 CEST] <BBB> on-screen visual comparison is easy, but write-down visual comparisons are notoriously hard IMO [15:58:22 CEST] <Daemon404> is it possible to publish webms/mp4s [15:58:38 CEST] <Daemon404> short ones obv [15:59:26 CEST] <Daemon404> [14:34] < maseck> No multithreaded results. I'm guessing that he isn't targeting that. [15:59:29 CEST] <Daemon404> ^ btw from #daala [16:02:20 CEST] <BBB> MT is planned but not yet done, right [16:03:14 CEST] <Daemon404> maybe make a small note [16:30:34 CEST] <kierank> there were a few live vp9 encoders at nab [16:30:35 CEST] <kierank> was quite surprising [16:30:41 CEST] <Daemon404> hw? [16:30:42 CEST] <Daemon404> or sw? [16:30:56 CEST] <Daemon404> and did nay use libvpx [16:32:25 CEST] <kierank> sw i think [16:32:31 CEST] <kierank> dunno [16:39:33 CEST] <BBB> crap I should have gone to nab I guess [16:39:47 CEST] <BBB> kierank: is there a calender of video-related conferences where I should go to? [16:39:49 CEST] <Daemon404> isnt having a booth at nab expensive [16:39:55 CEST] <Daemon404> BBB, IBC is the next biggest [16:40:24 CEST] <BBB> thats around vdd right? [16:40:31 CEST] <Daemon404> right after [16:40:35 CEST] <Daemon404> or rather a week after [16:40:39 CEST] <Daemon404> i think [16:41:35 CEST] <BBB> I can visit my family/friends in NL that week, maybe [16:54:05 CEST] <Daemon404> makes sense [16:54:06 CEST] <Daemon404> ibc is .nl [17:07:26 CEST] <andrey_utkin> Hi! I find it unfortunate that there's "aspect" option for SAR in libavcodec/options_table.h, but ffmpeg_opt.c squats its name with its "aspect" option which stands for DAR. Any comments please, which solution to this would be welcome? Or is there a way to let ffmpeg CLI util know that it shouldn't parse the option, but pass it to libavcodec? I have tried "-aspect", "-aspect:v", it definitely is percepted as ffmpeg_opt.c option which sets DAR. [17:43:40 CEST] <Angus> Good morning folks [17:43:55 CEST] <Angus> Is anyone here familar with H264 byte stream? [17:44:19 CEST] <Angus> I'm running into [h264 @ 0xf9c1a0] decoding for stream 0 failed [17:44:39 CEST] <Angus> where the left is the original file, and the right is the contents being copied into AVIO Buffer: http://i.imgur.com/cZ7pYtE.png [17:45:19 CEST] <Angus> might anyone recognize what the missing bytes are? and if they are relevant to H264 decode? [17:45:57 CEST] <Angus> for reference, once the decoding for frame 1 fails, the rest of the video does play, although running into this error every frame: [NULL @ 0xf9d460] non-existing PPS 0 referenced [17:47:38 CEST] <BtbN> did you try to increase the log level? Also, not a question for this channel. [17:54:55 CEST] <Angus> BtbN: I'm writing the code to call on the FFMpeg API, the cli app isn't being used here. [17:55:07 CEST] <BtbN> still not the right channel. [17:55:53 CEST] <Angus> Oh, should I be in the regular ffmpeg channel? [18:21:49 CEST] <RiCON> BBB: the second graph in CRF says PSNR but the text implies it should be SSIM(?) [18:22:22 CEST] <BBB> yup [18:22:24 CEST] <BBB> let me fix [18:25:01 CEST] <BBB> RiCON: fixed [18:52:20 CEST] <Shiz> I'm trying to write a parser that sets some things like block_size and sample_rate, but it seems the decoder inits before that and bails out because these things... aren't set [18:52:36 CEST] <Shiz> am I doing something architecturally wrong here? the issue is that metadata like that is encoded in the individual frames [18:52:55 CEST] <Shiz> and I don't feel comfortable stuffing that stuff in the mpeg.c demux code [19:07:13 CEST] <JEEB> Shiz: I'm pretty sure the single review for that ATRAC3+ parser back in '14 was that one shouldn't set values in avcodeccontext in the parser, but rather just pass on decode'able packets to the decoder [19:09:55 CEST] <Shiz> well that's a bit of an issue considering the decoder needs these fields filled in [19:09:58 CEST] <Shiz> or it will bail [19:10:16 CEST] <JEEB> so the demuxer was setting them before? [19:10:40 CEST] <Shiz> well, nothing is setting them right now :p but yeah, in OAM stuff the demuxer sets it [19:11:03 CEST] <Shiz> oma* [19:11:17 CEST] <Shiz> see lavf/omadec.c [19:12:56 CEST] <Shiz> specifically around 'case OMA_CODECID_ATRAC3P:' [19:13:13 CEST] <JEEB> I remember poking around ATRAC3+ some time ago [19:14:41 CEST] <JEEB> I think the biggest issue is that it expects avtx->channels to be set [19:14:44 CEST] <JEEB> *avctx [19:14:56 CEST] <Shiz> it expects more to be set [19:14:58 CEST] <Shiz> but yes [19:15:12 CEST] <Shiz> OTOH, setting those valuesi n the mpeg demuxer doesn't seem like a great idea either [19:15:15 CEST] <JEEB> and yes, that's an architectural FU [19:15:46 CEST] <JEEB> Shiz: well I just looked at the init [19:16:43 CEST] <JEEB> and it only seems to require channel count to get through [19:16:49 CEST] <JEEB> init() [19:17:38 CEST] <Shiz> if (!avctx->block_align) { [19:17:40 CEST] <Shiz> also block_align [19:43:45 CEST] <kurosu> So I can confirm that the number of threads spawned considerably slows the dirac decoder on Win64 (with 32x16 slices, that's 4050 threads per image...) [19:44:01 CEST] <kurosu> running per line of slice is a 25% speed improvement for 6 cores/threads [19:47:20 CEST] <Daemon404> it is unfortunate that someone already replied to say "all of libav's code is faster anyway" [19:48:13 CEST] <kurosu> err, I didn't read or understand that from anywhere? [19:48:34 CEST] <kurosu> the decrease I was seeing was just a byproduct of that bad threading [19:48:45 CEST] <kurosu> not because of the new implementation [19:49:09 CEST] <kurosu> *new bitstream implementation [19:49:22 CEST] <Daemon404> https://lists.libav.org/pipermail/libav-devel/2016-May/076493.html [19:49:24 CEST] <Daemon404> i may have misread [19:49:33 CEST] <Daemon404> kurosu, OH, ok [19:50:17 CEST] <kurosu> well, I don't know if the golomb code becomes slower [19:50:25 CEST] <kurosu> on the fixed dirac decoder, it seems faster [19:50:31 CEST] <Daemon404> ic [19:50:42 CEST] <kurosu> so I assume Luca is right, although I haven't tested every and each codec that was ported [19:51:08 CEST] <kurosu> the easy, high bitrate ones probably are improved (confirmed with prores, dnxhd and huffyuv) [19:56:20 CEST] <kierank> kurosu: we have that in our vc2hq tree, yes [19:56:40 CEST] <kierank> it became a nightmare supporting all those ancient variants [20:02:07 CEST] <durandal_170> so they gonna port all 1000 decoders [20:04:59 CEST] <kurosu> kierank, is there only one dirac file in fate? Because I assume it doesn't cover the hq & "normal" low delay variants ? [20:05:13 CEST] <kurosu> and it would be nice having a better coverage in fate [20:05:19 CEST] <kierank> yes, we should probably add more [20:08:27 CEST] <kurosu> kierank, how can one trigger one or another profile ? [20:08:41 CEST] <kierank> use the encoder for hq [20:08:43 CEST] <kierank> the others no idea [20:10:13 CEST] <kierank> we got a bit fed up with the other variants [21:49:04 CEST] <kurosu> kierank / atomnuker, are there restrictions on dimensions with vc2? encoding 640x320 or 352x288 to drc produces content with a few random bytes [21:49:21 CEST] <kurosu> it does decode to the same content though [21:49:29 CEST] <kierank> broadcast resolutions most likely [21:49:43 CEST] <Daemon404> 'random'? [21:49:52 CEST] <kurosu> 480x270, 960x540, 1920x1080 are fine [21:50:03 CEST] <kurosu> Daemon404, different every run [21:50:11 CEST] <kurosu> ie, not good for fate [21:50:14 CEST] <kierank> dunno, non broadcast resolutions was atomnuker's bugbear [21:50:33 CEST] <kierank> and so I am not getting involved in that [21:51:38 CEST] <kurosu> I won't either then [21:51:56 CEST] <cone-273> ffmpeg 03Christophe Gisquet 07master:79e86640ff55: fate: wma: add lossless 24bits tests [21:52:20 CEST] <Daemon404> does this mean 24bit wma lossless works now? [21:52:35 CEST] <Daemon404> i have checks at work to make sure ffmpeg never decoded it (because it was insanely wrong before) [21:53:19 CEST] <kurosu> I suppose, those are files that had problems before and pinpointed various bugs [21:53:33 CEST] <Daemon404> oic [21:53:46 CEST] <Daemon404> it used to e.g. decode to almost-silence sometimes [21:53:48 CEST] <atomnuker> kurosu: I'm not seeing anything wrong at those resolutions with any pixel format [21:53:48 CEST] <Daemon404> users really hate that [21:53:50 CEST] <Daemon404> better to fail [21:56:43 CEST] <kurosu> atomnuker, ran along ffmpeg -f rawvideo -s 640x320 -pix_fmt yuv420p -threads 1 -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -i vsynth1.yuv -threads 1 -pix_fmt yuv420p -vcodec vc2 -frames 5 -strict -1 -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -y vsynth1-vc2-420p.drc && md5sum vsynth1-vc2-420p.drc && ffmpeg -i vsynth1-vc2-420p.drc -f crc - 2>&1 | grep CRC [21:57:01 CEST] <kurosu> (actually, edited line generated by fate, but you should see the idea) [21:59:39 CEST] <atomnuker> kurosu: the CRC doesn't change between runs [21:59:44 CEST] <kurosu> no [21:59:53 CEST] <atomnuker> at least on my machine [21:59:55 CEST] <kurosu> but the md5 sum of the input file does [22:00:15 CEST] <atomnuker> vsynth1-vc2-420p.drc? [22:00:33 CEST] <atomnuker> that doesn't vary either [22:01:24 CEST] <kurosu> ah [22:01:31 CEST] <kurosu> atomnuker, work in progress: https://0x0.st/NHt.patch [22:01:50 CEST] <kurosu> varies every run here with these resolutions [22:02:12 CEST] <kurosu> I don't have a memory poisoner/valgrind at hand, so can't say if it's by luck or anything [22:02:48 CEST] <kurosu> when it was failing for mov, I decided to go raw with drc but no change [22:07:11 CEST] <atomnuker> kurosu: what's the fate test name? [22:07:39 CEST] <atomnuker> ah nvm [22:07:57 CEST] <kurosu> $( make fate-list | grep vc2 ) :D [22:08:38 CEST] <kurosu> I can force the resolution but well, that's fragile [22:14:26 CEST] <atomnuker> kurosu: no reference file [22:14:58 CEST] <kurosu> run fate with GEN=1 [22:15:44 CEST] <kurosu> or I'm misunderstanding your sentence [22:19:24 CEST] <kurosu> it may fail with vsynth3 or vsynth_lena but that's not the matter atm [22:20:59 CEST] <atomnuker> nope, none of the pixel formats fail here, no matter how many times I rerun them [22:21:06 CEST] <atomnuker> valgrind doesn't say anything as well [22:21:23 CEST] <atomnuker> I'll try it again with gcc [22:21:34 CEST] <kurosu> oh, that wasn't with gcc [22:21:45 CEST] <kurosu> I'm using 5.1 and Win64 [22:21:59 CEST] <atomnuker> gcc 5.1? [22:22:16 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07master:11db7eee9b00: avformat/options_table: Add missing identifier for very strict compliance [22:22:17 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07master:9fcb59c9bc5c: avcodec/options_table: fix strict compliance constant flags to match the strict field [22:23:05 CEST] <durandal_170> Daemon404: yes, 24bit support should be working, previous hack was just evil and lazy [22:23:46 CEST] <kurosu> yeah, I don't want to bother with various people toolchains, and the one I get allows me to build Win32 binaries by just passing -m32 when needed [22:24:09 CEST] <kurosu> (using msys2, but not their toolchain) [22:24:25 CEST] <kurosu> anyway, I'll just force the resolution [22:26:07 CEST] <kurosu> https://0x0.st/NH6.patch <- should run work, but only tests 1080p [22:26:52 CEST] <kurosu> *fate should work [22:26:55 CEST] <atomnuker> nope, everything still passes with gcc 6.1 [22:27:13 CEST] <atomnuker> if you could somehow get me a valgrind log that'd be nice [22:27:31 CEST] <atomnuker> I don't have a windows system at hand to test with [22:27:36 CEST] <kurosu> I can't, Win64, and then it would be another computer then [22:27:43 CEST] <kurosu> but I'll try to see if I can reproduce [22:28:01 CEST] <kurosu> not for tonight though [22:29:18 CEST] <atomnuker> alright, thanks [22:30:14 CEST] <kurosu> what's the plans for submitting the improved dirac (lowdelay) decoder ? [22:30:20 CEST] <kurosu> *what are [22:30:41 CEST] <kurosu> atm it's not very nice that threading causes that kind of issues [22:34:17 CEST] <atomnuker> it's not yet significantly improved other than it's stable-er, decodes in rows and does the idwt in parallel [22:35:13 CEST] <atomnuker> also it supports decoding field-coded pictures (which definitely didn't use to play nice at all with the rest of the decoder) [22:36:17 CEST] <kierank> I'd like to merge it I guess as a vc2hq decoder [22:36:20 CEST] <atomnuker> the problem is that vc2 and dirac are basically the same codec and you can't really differentiate between them [22:36:25 CEST] <atomnuker> so you'd have to call the decoder from the current dirac decoder [22:36:26 CEST] <kierank> but it's a pain in the arse to say the least [22:36:39 CEST] <atomnuker> which isn't a pretty thing IMO [22:43:36 CEST] <kurosu> well the decoding in rows is a 25% speedup here [22:43:42 CEST] <kierank> yes [22:44:04 CEST] <kurosu> you can probably create a new decoder that calls the same functions, only switching on the codec name [22:44:12 CEST] <kierank> nontrivial to implement for non inra though [22:44:18 CEST] <kurosu> vc2 is intra only ie could use frame threading [22:44:56 CEST] <kierank> yes but perverse to use frame threading for a low delay codec [22:45:18 CEST] <kurosu> yes, once you have implemented (efficiently) slice threading [22:47:32 CEST] <kierank> probably easy to backport yet [22:47:38 CEST] <kierank> s [23:41:18 CEST] <kierank> lol "Resubmitting test file, commands and console as per Carlos' request." [23:59:52 CEST] <cone-273> ffmpeg 03foo86 07master:ce2f9fdb0a92: avcodec/dca: fix sync word search error condition [00:00:00 CEST] --- Tue May 3 2016