[00:09:51 CEST] <ubitux> BBB: samples.mplayerhq.hu/benchmark/testsuite1/matrixbench_lowdivx_wma.avi has color_primaries=bt470m [00:10:54 CEST] <ubitux> couldn't find anything with bt2020 [00:11:00 CEST] <ubitux> but maybe we simply don't export the meta [00:11:27 CEST] <llogan> dinux5: what are the actual errors? (use a pastebin link) altough it's probably much less priority than other stuff [00:11:50 CEST] <llogan> dinux5: also, i forgot to mention, top-posting on the mailing list is to be avoided. [00:12:08 CEST] <kierank> there isn't much (if any) bt2020 content out there [00:12:32 CEST] <BBB> wheeee cool [00:12:35 CEST] <BBB> ty again [00:12:48 CEST] <kierank> BBB: http://demo-uhd3d.com/fiche.php?cat=uhd&id=113 [00:12:53 CEST] <kierank> that is bt2020 [00:13:06 CEST] <JEEB> yeah, even broadcast specs from ARIB have a thing in there which goes "'cause we require BT.2020, this is how you convert BT.709 footage to BT.2020 correctly" [00:13:38 CEST] <BBB> the picture? [00:13:54 CEST] <BBB> ffmpeg says its bt470 [00:14:03 CEST] <kierank> ? [00:14:18 CEST] <JEEB> there's a link to a mp4 [00:14:18 CEST] <kierank> the download button on the right [00:14:57 CEST] <BBB> oooooooooooo [00:14:57 CEST] <dinux5> llogan: Sure. Right now I can tell only about one such error. [00:14:59 CEST] <BBB> duh :D [00:15:00 CEST] <BBB> sorry [00:15:08 CEST] <BBB> holy crap its 912MB [00:15:48 CEST] <ubitux> % ffprobe -v error -of flat -show_entries stream=color_space,color_primaries 'http://demo-uhd3d.com/files/uhd4k/NEO_Fire_HDR_HEVC_2160p_5994_Main10_45-100...' [00:15:50 CEST] <ubitux> streams.stream.0.color_space="unknown" [00:15:52 CEST] <ubitux> streams.stream.0.color_primaries="bt2020" [00:15:54 CEST] <ubitux> nice [00:17:14 CEST] <dinux5> under heading non doxy comments it gives /* channel meaning */ [00:17:25 CEST] <dinux5> and many comments like these [00:18:57 CEST] <cone-135> ffmpeg 03Lou Logan 07master:06eef96b69d7: fix some a/an typos [00:19:03 CEST] <dinux5> llogan : and under heading inconsistently formatted doxygen comment it gives comments within /** foo*/ [00:19:58 CEST] <ubitux> nice vp9 2560x1440 stress video to youtube-dl @ https://www.youtube.com/watch?v=er416Ad3R1g [00:23:51 CEST] <jamrial> ubitux: https://www.youtube.com/watch?v=MGyaR2sSBkA this one has 4k vp9 60fps [00:27:53 CEST] <ubitux> it looks laggy [00:28:17 CEST] <ubitux> there is a very inconsistent frame dup pattern [00:29:16 CEST] <ubitux> it looks *really* laggy [00:29:53 CEST] <nevcairiel> seems fine here, maybe your playback is just too slow? [00:30:55 CEST] <ubitux> no, try frame per frame [00:31:13 CEST] <nevcairiel> its a video game, so camera movement is never going to be perfectly smooth [00:31:22 CEST] <ubitux> literally unplayable [00:31:42 CEST] <nevcairiel> you must have rather odd definitions of unplayable, or your player is screwing up =p [00:32:05 CEST] <ubitux> unplayable as a game i mean [00:32:08 CEST] <ubitux> :) [00:44:05 CEST] <kierank> Is anyone interested in looking at my assembly to find a bug? [00:56:31 CEST] <kierank> Is there an -f raw so I can dump an encoded bitstream to a file? [00:57:47 CEST] <llogan> -f rawvideo [00:58:07 CEST] <kierank> that will work? [00:58:12 CEST] <kierank> even if it's raw encoded data [00:59:45 CEST] <kierank> seems so [01:00:12 CEST] <llogan> that's good because now i think i misread your question [01:07:31 CEST] <kierank> oh fuck it's a little endian bug [01:44:24 CEST] <kierank> wtf is svag [01:45:11 CEST] <kierank> playstation audio apparently [01:55:48 CEST] <kierank> lol netflix patching zimg [02:27:25 CEST] <Daemon404> kierank, not surprising considering it was written by a netflix guy. [02:34:55 CEST] <cone-135> ffmpeg 03James Almer 07master:d5a3578350a3: avformat/svag: fix division by zero [02:37:34 CEST] <llogan> talking about zscale, how do i use it to convert bgr0 to yuv420p? [02:58:44 CEST] <jamrial> michaelni: is a division by zero fix for a super obscure demuxer worth backporting? [02:59:33 CEST] <michaelni> jamrial, yes [02:59:50 CEST] <jamrial> ok, thanks [02:59:51 CEST] <michaelni> crash fixes are always worth backporting [03:13:16 CEST] <cone-135> ffmpeg 03James Almer 07release/3.0:7b1e020fc5ed: avformat/svag: fix division by zero [03:53:24 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07release/3.0:26d29f0c3dc2: avcodec/h264_slice: Check PPS more extensively when its not copied [03:53:25 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07release/3.0:00b54d4625b0: avcodec/diracdec: check bitstream size related fields for overflows [04:16:49 CEST] <llogan> maybe i'll write a nvenc install/use guide. finally got access to something better than my GT 240. [04:24:54 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07release/3.0:9b1b674ebefd: Changelog: update [04:26:56 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07release/3.0:fda00aa77493: doc/Doxyfile: update for 3.0.1 [04:37:30 CEST] <cone-135> ffmpeg 03James Almer 07n3.0.1:HEAD: avformat/svag: fix division by zero [06:41:29 CEST] <TheRyuu> ok saw this http://mplayerhq.hu/pipermail/ffmpeg-devel/2016-March/191195.html the hilight got buried somehow [06:48:43 CEST] <TheRyuu> I think making it dependent on enable/disable-debug is reasonable [06:50:59 CEST] <Zeranoe> Is there anything else I can do to help resolve http://trac.ffmpeg.org/ticket/4832 ? That backtrace makes me think it isn't FFmpeg, but I would like confirmation [07:42:44 CEST] <TheRyuu> patch sent to ML [14:32:45 CEST] <kierank> BBB: Have I sent you this piece of brilliance before: https://bugs.chromium.org/p/webm/issues/detail?id=701 [14:33:38 CEST] <BBB> nope [14:34:02 CEST] <kierank> my favourite bug ever [14:34:35 CEST] <kierank> "Maybe this should be fixed in VLC?" also hillarious [14:34:50 CEST] <BBB> :) [14:34:59 CEST] <BBB> I think codecs should not deal with timestamps [14:35:02 CEST] <kierank> and the guy reporting is a googler [14:35:27 CEST] <BBB> codecs are 1in 1out so you can work with poc and convert to pts in the caller in whatever precision they want (like a hashmap) [14:35:53 CEST] <BBB> but yes, nice bug :D [14:36:21 CEST] <BBB> so I wrote a new filter yesterday that seems to convert colorspaces correctly taking into account their primaries/gamma [14:36:42 CEST] <BBB> its a little slow so Ill write some integer code (and simd) [14:37:08 CEST] <BBB> I might still finish thomas patch since some people dont seem to mind fast but wrong solutions [14:38:35 CEST] <BBB> thanks for samples yesterday [14:38:48 CEST] <BBB> kierank: do you have broadcast samples that are confirmed correct for from/to testing? [14:39:00 CEST] <BBB> like, not output from -vf colormatrix, but actual reference samples from committees or so [14:39:09 CEST] <wm4> kierank: is it a timestamp range issue? [14:39:30 CEST] <kierank> BBB: the smptebars (sd) is definitely correct [14:39:31 CEST] <BBB> like, a picture like this in bt2020 10bit notation should look like this in bt709 8bit notation [14:39:45 CEST] <BBB> what is smptebars? [14:39:46 CEST] <kierank> I don't have the equipment to verify the hd bars [14:39:50 CEST] <kierank> BBB: color bars [14:39:54 CEST] <BBB> is that a filter? [14:39:56 CEST] <kierank> yes [14:39:58 CEST] <BBB> ah [14:39:59 CEST] <BBB> ok [14:40:57 CEST] <BBB> but how do you specify the colorspace? [14:41:03 CEST] <kierank> it's hardcoded in the filter [14:41:12 CEST] <kierank> (it's SD so it's bt601) [14:41:53 CEST] <BBB> right, so I need content that is confirmed identical on television so I can confirm that when I convert bt601 to bt709, it is correct [14:46:09 CEST] Action: kierank thinks [14:47:42 CEST] <wm4> in mpv we've also implemented bt2020 [14:50:13 CEST] <kierank> wm4: yes, they have an int64_t timestamp but don't allow the entire range [14:50:40 CEST] <kierank> x264 has infinite precision arithmetic for these cases [14:50:49 CEST] <kierank> (hrd) [14:54:26 CEST] <wm4> I bet ffmpeg breaks in various cases if the full bits are used [15:06:15 CEST] <ncopa> hi [15:06:33 CEST] <ncopa> it seems that the FF_SYMVER define is not used any place anymore [15:06:54 CEST] <ncopa> i suppose it can be removed now? [15:08:54 CEST] <wm4> I guess so, API users certainly can't use it [15:09:13 CEST] <ncopa> and it was broken on uclibc too [15:15:54 CEST] <ncopa> somethign like this: http://tpaste.us/AW4Y [15:20:55 CEST] <ncopa> separated the clean up commits: http://tpaste.us/3gjm [15:55:14 CEST] <kierank> Gramner: any ideas if this code be sped up more? https://github.com/kierank/ffmpeg-sdi/blob/master/libavcodec/x86/sdienc.asm [15:55:20 CEST] <kierank> apart from doing avx2 [15:56:02 CEST] <kierank> or J_Darnley if you are around [15:56:55 CEST] <Gramner> kierank: store the constants in registers. then you could also do a 3-arg pmullw [15:56:55 CEST] <durandal_1707> no its already trivial, I guess [15:57:46 CEST] <durandal_1707> tell what speed you got [15:58:20 CEST] <kierank> it's twice as fast on skylake than haswell [15:58:52 CEST] <ubitux> (missing ':' after loop label) [15:59:02 CEST] <Gramner> how large is the size? might be worth unrolling [15:59:04 CEST] <ubitux> (nasm won't like it) [16:03:37 CEST] <kierank> Gramner: 62 bytes for avx [16:03:49 CEST] <Gramner> i mean size of input [16:04:04 CEST] <kierank> ah, it's a frame [16:04:11 CEST] <kierank> so 1920*1080*2*2 [16:04:12 CEST] <Gramner> definitely worth unrolling once then [16:04:47 CEST] <kierank> I was thinking of trying to make it do 15 pixels per iteration but seems a bit tricky [16:07:33 CEST] <Gramner> could maybe do some palignr trickery if you do two iterations per loop and do one movu and one movd. that way only half the stores are unaligned [16:35:26 CEST] <Daemon404> ...... [16:35:33 CEST] <Daemon404> "To unsubscribe from this group and stop receiving emails from it, send an email to google-summer-of-code-mentors-list+unsubscribe@googlegroups.com." [16:35:45 CEST] <Daemon404> except gmail complains its not a rfc-compliant email an rejects it [16:35:49 CEST] <Daemon404> lovely. [16:36:10 CEST] <Gramner> what's non-compliant with that address? [16:36:22 CEST] <Daemon404> it isnt [16:36:29 CEST] <Daemon404> i sent the same mail a 2nd time and it worked [16:36:32 CEST] <Daemon404> maybe a gmail hiccuo [16:36:33 CEST] <Daemon404> p [16:37:18 CEST] <Daemon404> (litrally just git send a 2nd time) [16:52:46 CEST] <Daemon404> wm4, did you get a chance to look at the utstanding tep2 crap today? [16:53:44 CEST] <wm4> not yet [16:53:52 CEST] <Daemon404> ok [17:05:45 CEST] <durandal_1707> what not yet? [17:07:48 CEST] <wm4> look [17:08:31 CEST] <durandal_1707> look what? [17:08:35 CEST] <cone-308> ffmpeg 03Vittorio Giovara 07master:7888ae8266d8: cfhd: Do not initialize context size [17:08:36 CEST] <cone-308> ffmpeg 03Jovan Zelincevic 07master:b73c27151eda: avcodec/mips: Optimization synced to the newest code base. [17:09:15 CEST] <durandal_1707> finally tep2 when? [17:09:46 CEST] <wm4> when you fix all the fate tests [17:15:22 CEST] <kierank> Gramner: are there any tricks to do a variable right shift? [17:15:42 CEST] <Gramner> pmulhrsw [17:16:06 CEST] <Gramner> the v210 code in x264 (among other things) uses it [17:16:26 CEST] <Gramner> it has some limitations though [17:16:40 CEST] <Gramner> also pmulhuw [17:16:43 CEST] <flux> - [17:16:49 CEST] <flux> (oops, carry on) [17:17:24 CEST] <Gramner> the latter might be better in this case [17:18:31 CEST] <wm4> so I build the codecpar branch, and my terminal, including all of scrollback, is full of deprecation warnings in ffmpeg CLI tools [17:21:36 CEST] <Daemon404> wm4, those will be fixed in later bits [17:21:41 CEST] <Daemon404> even libav did them in separate commits [17:21:49 CEST] <Daemon404> this merge is for lavf [17:21:58 CEST] <wm4> right [17:22:10 CEST] <Daemon404> its [17:22:17 CEST] <Daemon404> it's also a good way to check API compatability* [17:22:24 CEST] <Daemon404> since the cli tools use the old api [17:22:25 CEST] <Daemon404> currently [17:22:56 CEST] <wm4> do we just convert it to the new API later, or do we keep both? [17:23:03 CEST] <nevcairiel> convert [17:27:17 CEST] <kierank> Gramner: I see, atomnuker is working on the opposite 10-bit bitpack unpack [18:40:59 CEST] <wm4> __MINGW32CE__ [18:41:06 CEST] <wm4> do we support such a configuration [18:41:12 CEST] <Daemon404> libav has such fates [18:41:15 CEST] <Daemon404> wbs runs them [18:41:19 CEST] <Daemon404> no idea if it *does* anything though [20:47:53 CEST] <kierank> Gramner: the next fun one is v210 -> bitpacked and vice versa [20:48:47 CEST] <Gramner> shouldn't those be fairly similar? [21:09:26 CEST] <fritsch> https://ffmpeg.org/doxygen/3.0/structAVSubtitleRect.html <- AVSubtitle uses the deprecated AVPicture [21:09:36 CEST] <fritsch> i am just cleaning up kodi's usage of AVPicture [21:09:50 CEST] <fritsch> and yeah - how to use AVSubtitle without running into this deprecation thingy? [21:12:06 CEST] <Daemon404> it says unused [21:12:13 CEST] <Daemon404> i assume you want to use data and linesize instead [21:13:48 CEST] <fritsch> Daemon404: exactly :-) just got it 2 seconds ago [21:13:49 CEST] <fritsch> thx much [21:15:39 CEST] <fritsch> btw. the transition was quite easy as there are replacements with av_image_fill_* [21:16:38 CEST] <fritsch> the only thing that was not that intuitive after going from AVPicture to AVFrame was the usage of av_frame_get_buffer instead avpicture_alloc [21:18:28 CEST] <wm4> we deprecated it because users kept doing broken stuff like aliasing AVPicture and AVFrame [21:19:02 CEST] <fritsch> most likely I also do that somehow unknowingly [21:19:11 CEST] <fritsch> https://github.com/xbmc/xbmc/pull/9491/commits/bc2bc5e163e2442ec121a5590106b... [21:19:50 CEST] <fritsch> it also feels a bit odd that one needs to go the av_image_* method some times and in other cases stick to the frame methods [21:21:41 CEST] <wm4> av_image_ is usually for explicitly layouted stuff [21:22:10 CEST] <wm4> e.g. they often come up if you need to pack a planar image to a continuous buffer (like win32 crap) [21:22:20 CEST] <wm4> or raw files [21:22:42 CEST] <wm4> while the main point of AVFrame is being refcounted [21:23:01 CEST] <wm4> nevcairiel: do you know about the codecpar swf failure? [21:23:29 CEST] <wm4> I see that the only way it can create an audio stream is create_new_audio_stream, and it always sets the channel count, yet ffprobe shows channels==0 [21:23:37 CEST] <wm4> how can that possibly be [21:25:52 CEST] <Daemon404> i think nevcairiel said that it was getting copied to the avctx because it wasnt updated after it was added or something [21:25:55 CEST] <Daemon404> ? [21:26:12 CEST] <wm4> actually I'm very stupid, I guess [21:26:15 CEST] <wm4> flv != swf [21:26:23 CEST] <Daemon404> lol [21:26:53 CEST] <wm4> ok the flvdec code looks much worse [21:27:11 CEST] <Daemon404> i dont think tehre are any outstanding flv issues [21:27:13 CEST] <Daemon404> only swf [21:28:23 CEST] <wm4> fate-acodec-adpcm-swf fails, and it's flv [21:28:37 CEST] <wm4> (the codec is named adpcm_swf) [21:28:41 CEST] <Daemon404> ... why is ic called swf [21:28:41 CEST] <Daemon404> oh. [21:31:06 CEST] <wm4> I guess it's nothing that can be fixed in 5 mins, so I'll stare at it again tomorrow [21:31:21 CEST] <Daemon404> i did say i need help. [21:34:26 CEST] <wm4> elenril fixed this in 09ae7b81ea2051eec2be9964296bd6ef492c6622 I think (it was not merged) [21:36:45 CEST] <Angus> Has AVFormat::destruct been replaced with AVFormat::av_free_packet? [21:37:16 CEST] <wm4> Angus: yes [21:37:23 CEST] <Daemon404> free_packet is deprecated [21:37:37 CEST] <Daemon404> wm4, im not opposed to cherry picking that commit [21:37:51 CEST] <wm4> Daemon404: well it broke something about metadata [21:38:01 CEST] <Daemon404> ? [21:38:03 CEST] <Angus> alright, thanks. [21:38:17 CEST] <Angus> oh, is free_packet also deprecated? [21:38:18 CEST] <wm4> Angus: you should use av_packet_unref [21:38:50 CEST] <wm4> and AVPacket.destruct couldn't be used directly (or shouldn't have) [21:39:15 CEST] <wm4> Daemon404: see 95daa9e09aeccf6ccef4b5c08097f6b5b581de15 (Not merged. The demuxer issues warnings when a new stream is encountered and reading the metadata requires that streams already exist.") [21:39:33 CEST] <Angus> I found this in the code I'm looking through... [21:39:34 CEST] <Angus> if (pPacket->destruct != NULL) { pPacket->data = NULL; pPacket->size = 0; } [21:39:49 CEST] <Daemon404> wm4, so... whats your opinion then on the 'fix' [21:40:15 CEST] <wm4> Angus: broken [21:40:53 CEST] <Angus> Yep, that's a memory leak if(condition is true) [21:42:04 CEST] <wm4> Daemon404: I don't know yet, we probably need to store the metadata somewhere until the AVStream is created? or provide a way for demuxers to update AVStream.codec from changed codecpars [21:42:37 CEST] <Daemon404> how does this work at all in libav then [21:43:59 CEST] <wm4> my guess is it doesn't have this code [21:44:11 CEST] <Daemon404> makes sense i guess... [21:44:48 CEST] <wm4> well I'm not sure, there's also metadata reading code, but I'll look closer tomorrow [21:45:55 CEST] <Daemon404> ok [22:02:14 CEST] <Angus> can av_read_frame(AVFormatContext, AVPacket) be called without calling av_new_packet() first? [22:04:30 CEST] <Angus> (I assume that's correct, as av_read_frame() seems to fill/initialize the AVPacket with stuff?) [22:06:19 CEST] <cone-308> ffmpeg 03Paul B Mahol 07master:4a80a6ad2129: avfilter/vf_waveform: optimize lowpass filter even more [22:16:23 CEST] <durandal_1707> BBB: I'm interested in your filter, how much is it slower than broken colormatrix? [22:16:36 CEST] <BBB> durandal_1707: speeding it up now [22:16:44 CEST] <BBB> durandal_1707: itll be a bit slower but hopefully not terribly much [22:16:59 CEST] <JEEB> there's nothing you can't cover with some nice SIMD :) [22:17:00 CEST] <durandal_1707> because? [22:17:12 CEST] <JEEB> that's also what I learned from zimg regarding proper scaling etc [22:17:46 CEST] <JEEB> and usually in our days it's better to be correct than a bit faster [22:17:57 CEST] <durandal_1707> what swscale is doing is not proper? [22:18:31 CEST] <JEEB> I'd go as far as to say that, yes [22:19:07 CEST] <JEEB> it's built in the times when speed was more important than being accurate [22:20:00 CEST] <JEEB> that said, I still use swscale for some stuff :P [22:21:55 CEST] <wm4> more importantly, it's extremely hard to tell whether libswscale does something correctly [22:22:04 CEST] <wm4> or rather, it's hard to tell what the heck it _does_ [22:22:32 CEST] <wm4> if you want to check correctness by treating it as a black box, you have to test a lot of combinations of input and output [22:26:50 CEST] <ubitux> BBB: so not going to integrate that code in sws? :° [22:26:57 CEST] <ubitux> SWS_CS_* are already there! ;) [22:27:42 CEST] <BBB> Ill show you what Ive got when its ready [22:27:57 CEST] <BBB> we can then try to re-engineer it in whatever beautiful way we want [22:28:05 CEST] <BBB> but at least I have something that works and solves my problem at hand [22:32:28 CEST] <cone-308> ffmpeg 03Paul B Mahol 07master:bf1495d9a991: doc/filters: remove false claim in sofalizer description [22:34:43 CEST] <durandal_1707> swscale design is nightmare [22:45:11 CEST] <rcombs> swscale needs its own duplicates of lavu's colorspace enum because ????? [22:48:33 CEST] <wm4> rcombs: maybe lavu didn't have them in the past, and libswscale and libavcodec were not supposed to depend on one or the other [22:48:53 CEST] <rcombs> and then they moved to lavu and nobody removed the swscale ones, I guess [22:49:26 CEST] <jamrial> rcombs: there's an audiotoolboxenc patch that fixes build failures on iOS. did you see it? [22:49:36 CEST] <rcombs> jamrial: you mean the one I sent? [22:50:59 CEST] <wm4> rcombs: well, removing the sws ones could be non-trivial, who knows? [22:51:06 CEST] Action: rcombs shrugs [22:51:18 CEST] <wm4> but feel free to submit a patch trollol [22:51:34 CEST] <jamrial> rcombs: no, the one by Crossle Song [22:52:14 CEST] <rcombs> oh, I missed that [22:52:32 CEST] <rcombs> it's nearly identical to mine, but does have one minor issue (it accidentally changes some logic) [22:53:04 CEST] <rcombs> (mine came later) [22:53:27 CEST] <jamrial> he resent it after nevcairiel pointed that out. or you mean the second one is also faulty? [22:54:04 CEST] <rcombs> the second one isn't faulty, but does duplicate code unnecessarily [22:56:29 CEST] <rcombs> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192248.html I don't have anything setup to test or debug on iOS devices, so I'm not sure what's going on here [22:58:26 CEST] <rcombs> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192249.html and I don't see this issue here [00:00:00 CEST] --- Wed Mar 30 2016