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

[burek]

[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-100VBR.mp4'
[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 at 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/bc2bc5e163e2442ec121a5590106b0a479a9739c
[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