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

[burek]

[04:23:11 CEST] <cone-498> ffmpeg 03Michael Niedermayer 07master:196cfc278d2b: avformat/utils: use av_codec_g/set_lowres()
[05:05:38 CEST] <rcombs> looks like somebody at apple accidentally &'d a `const void*` to pass it to as an arg of the same type in AudioToolbox
[11:00:59 CEST] <omerjerk> hey, so I've a 32 bit integer. uint32_t return_val;
[11:01:10 CEST] <omerjerk> I need to assign the bits of this to a float.
[11:01:32 CEST] <omerjerk> And I'm doing it like this - float tmp = *(float*) &return_val;
[11:01:54 CEST] <omerjerk> but when I compile, the compiler gives out the warning - warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
[11:02:16 CEST] <omerjerk> So, I wanted to ask is there any other util function available in ffmpeg to do what I'm doing ?
[11:02:41 CEST] <jkqxz> memcpy()
[11:03:06 CEST] <wm4> aren't there libavutil functions for this
[11:03:44 CEST] <wm4> intfloat.h
[11:04:23 CEST] <omerjerk> Thanks jkqxz. I totally forgot about that.
[11:04:32 CEST] <omerjerk> wm4: let me have a look.
[11:05:30 CEST] <omerjerk> oh yes.
[11:05:32 CEST] <omerjerk> there is av_int2float
[11:05:32 CEST] <cone-755> ffmpeg 03Paul B Mahol 07master:9149e9c0baae: avcodec/apedec: fix decoding of stereo files with one channel full of silence
[11:05:33 CEST] <omerjerk> thanks.
[11:05:35 CEST] <omerjerk> I'll use it.
[11:13:05 CEST] <BtbN> that sounds odd, what is that needed for?
[13:39:48 CEST] <wm4> found a site that hosts broken mkv files produced by libavformat as "samples for testing": http://www.sample-videos.com/
[13:40:12 CEST] <JEEB> lol
[13:40:58 CEST] <wm4> |   + Name: ENCODER at 617
[13:40:58 CEST] <wm4> |   + String: Lavf53.24.2 at 627
[14:08:35 CEST] <nevcairiel> how broken are they
[14:09:25 CEST] <wm4> both the 1MB and 50MB samples start with negative timestamps (like -2 seconds for video), the 50MB one doesn't have an index entry for the start of the video
[14:09:38 CEST] <nevcairiel> well 53 is ages ago
[14:10:12 CEST] <nevcairiel> no index for timestamp 0 is oddly enough a common enough problem
[14:10:29 CEST] <nevcairiel> luckily also easily enough remedied in a demuxer
[14:10:56 CEST] <wm4> haven't seen many of such cases
[14:11:13 CEST] <wm4> my favorite broken file is one that has no packets flagged as key frames (produced by lavf of course)
[14:11:23 CEST] <wm4> and libavformat has a hack to handle such files
[14:11:28 CEST] <wm4> which also breaks seeking in valid files
[14:11:41 CEST] <wm4> I should send a patch to revert that
[14:34:42 CEST] <Daemon404> what is the use of this mastering metadata for mkv anyway
[14:34:47 CEST] <Daemon404> archiving?
[14:35:33 CEST] <wm4> not sure
[14:36:14 CEST] <wm4> I'm confused about how it's set/exported though
[14:36:41 CEST] <Daemon404> it's also not spec-final
[14:36:57 CEST] <wm4> that patch seems like quite a horrible way to make it settable from ffmpeg CLI
[14:37:21 CEST] <Daemon404> yes
[14:51:29 CEST] <nevcairiel> its the same ugly syntax x265 cli uses
[14:52:04 CEST] <nevcairiel> but yeah presumably its for storing hdr video where this info isnt in the bitstream, ie part of CELLAR I assume
[14:52:14 CEST] <nevcairiel> but the spec was not finished
[14:52:22 CEST] <Daemon404> hmm neat i see marton ported ffplay
[14:52:26 CEST] <Daemon404> \o/
[14:52:35 CEST] <nevcairiel> the patch looks trivial enough  as well
[14:52:38 CEST] <Daemon404> yea
[14:53:00 CEST] <nevcairiel> looks like it still used st->codec before, but it kept a reference in another struct
[14:53:07 CEST] <nevcairiel> which made creating a new context for it trivial
[14:53:11 CEST] <Daemon404> right
[14:53:18 CEST] <Daemon404> im working on ffprobe today
[14:53:27 CEST] <Daemon404> ive already merged antons initial changes requried to support codecpar
[14:53:30 CEST] <Daemon404> and they worked fine
[14:53:44 CEST] <Daemon404> some stuff in ffprobe will be under deprecation guards
[14:53:49 CEST] <Daemon404> liek codec_time_base
[14:54:41 CEST] <Daemon404> it doesnt look too hard though
[14:54:44 CEST] <Daemon404> seems only ffmpeg.c will be
[15:49:35 CEST] <Daemon404> almost done ffprobe
[15:49:36 CEST] <Daemon404> -            "codec_time_base": "1/25",
[15:49:36 CEST] <Daemon404> +            "codec_time_base": "1/51200",
[15:49:41 CEST] <Daemon404> only thing i have left to fix
[15:49:47 CEST] <Daemon404> (this is under deprecation guards)
[15:50:38 CEST] <Daemon404> i dont know if this is fixable, since it no longer uses st->codec to decode
[15:51:29 CEST] <Daemon404> oh.. hmm think i might know
[15:51:39 CEST] <wm4> wth. is codec_time_base
[15:52:25 CEST] <Daemon404> hmm nope
[15:52:31 CEST] <Daemon404> wm4, i have been askign this for YEARS
[15:52:49 CEST] <Daemon404> and yeah i cant figure out how to 'fix' this output
[15:52:49 CEST] <nevcairiel> its the fps in the bitstream, if any
[15:53:01 CEST] <Daemon404> nevcairiel, this is a nut file with rawvideo
[15:53:04 CEST] <Daemon404> it doesnt bloody have one
[15:53:22 CEST] <nevcairiel> nut is special, it stores this value somewhere
[15:54:01 CEST] <nevcairiel> you could add a hack under deprecation guards to assign your decode context time_base from st->codec
[15:54:23 CEST] <nevcairiel> or just accept it
[15:54:31 CEST] <Daemon404> the decode context timebase is 0/1
[15:54:33 CEST] <Daemon404> when i print it
[15:54:49 CEST] <nevcairiel> how did it work before then
[15:54:59 CEST] <Daemon404> i have no idea
[15:56:53 CEST] <Daemon404> everything else in ffprobe is working
[15:57:02 CEST] <Daemon404> i saw libav just completely removed codec_time_base printing
[15:57:12 CEST] <Daemon404> i'd prefer that too but people would bitch
[15:57:25 CEST] <Daemon404> although those people would almost certainly be using ffprobe wrong
[15:59:33 CEST] <Daemon404> would it help if i pasted my WIP patch
[16:11:20 CEST] <Daemon404> GRRRR
[16:11:24 CEST] <Daemon404> ffmpeg.org is down again
[16:11:29 CEST] <Daemon404> 2nd day i na row
[16:11:42 CEST] <Daemon404> or rather extremely slow
[16:12:10 CEST] <Zeranoe> After some testing I found that a MinGW build of FFmpeg is roughly 25% faster than a MSVC one of the same version. I don't know if this is due to pthreads vs w32threads, but I did find the initial results interesting...
[16:13:02 CEST] <Daemon404> that depends masisvely on which codec
[16:13:09 CEST] <Zeranoe> mpeg4 in this case
[16:13:43 CEST] <Zeranoe> And why does it massively depend on the codec?
[16:14:02 CEST] <Daemon404> because msvc does not have inline asm
[16:14:07 CEST] <Daemon404> and only some codecs use it
[16:14:34 CEST] <jamrial> Zeranoe: how does pthreads/w32threads relate to this? you can use either of the two with mingw
[16:15:25 CEST] <Zeranoe> jamrial: Because the MinGW build used pthread and the MSVC used w32thread. I don't know the speed comparison between the two
[16:15:59 CEST] <Daemon404> nevcairiel, ugh
[16:16:01 CEST] <Daemon404>             //err = avcodec_parameters_to_context(ist->dec_ctx, stream->codecpar);
[16:16:04 CEST] <Daemon404>             err = avcodec_copy_context(ist->dec_ctx, stream->codec);
[16:16:06 CEST] <Daemon404> ^ fixes codec_time_base output
[16:16:08 CEST] <Daemon404> but pure WTF
[16:16:20 CEST] <Daemon404> something sure is funky
[16:16:38 CEST] <Zeranoe> Daemon404: inline ASM might be a clue. Do you know a codec that would be a fair comparison?
[16:18:40 CEST] <jamrial> then just compile with mingw + w32threads to make a (maybe) fairer comparison
[16:19:08 CEST] <nevcairiel> mpeg4 is riddled with  inline asm, thats expected
[16:19:24 CEST] <nevcairiel> with h264 the comparison shrinks, but gcc builds are still faster
[16:19:55 CEST] <nevcairiel> w32threads dont really cost you performance
[16:21:34 CEST] <Daemon404> nevcairiel, i figured it out
[16:21:50 CEST] <Daemon404> st->codec->framerate wasnt copied when creating a new stream context
[16:21:58 CEST] <Daemon404> this somehow makes its way to time_base later
[16:21:59 CEST] <Daemon404> a bit wtf
[16:22:07 CEST] <Daemon404> guess ill add taht copy under deprecation guards
[16:23:30 CEST] <Zeranoe> I was considering providing MSVC builds, but I don't really see the benefit if it's so much slower
[16:23:57 CEST] <Daemon404> Zeranoe, the only benefits are being able to debug in msvc's debugger, and static linking with msvc projects
[16:24:15 CEST] <Zeranoe> Debugging was the main drive
[16:24:38 CEST] <Zeranoe> But I don't think it offsets that performance gap
[16:25:10 CEST] <nevcairiel> people that want to debug build their own builds
[16:25:29 CEST] <Daemon404> you would think so... but...
[16:25:37 CEST] <Daemon404> a lot of people just dl Zeranoe's build and link to it
[16:25:40 CEST] <Daemon404> (usually illegally)
[16:25:52 CEST] <Zeranoe> Or complain to me about wanting a MSVC build
[16:25:58 CEST] <Zeranoe> then build it themselves
[16:26:23 CEST] <Zeranoe> This is also why I don't provided static libs
[16:28:42 CEST] <Daemon404> wm4, ping. did you add these: gaplessinfo-itunes1 / gaplessinfo-itunes2
[16:28:48 CEST] <wm4> no
[16:28:54 CEST] <Daemon404> damn ok
[16:29:16 CEST] <Daemon404> one frame changed info when i converted ffprobe.c
[16:29:20 CEST] <Daemon404> -frame|pkt_pts=2112|pkt_dts=2112|best_effort_timestamp=2048|pkt_duration=960|nb_samples=960
[16:29:23 CEST] <Daemon404> +frame|pkt_pts=2048|pkt_dts=2048|best_effort_timestamp=2048|pkt_duration=1024|nb_samples=960
[16:29:55 CEST] <wm4> maybe the timestamp adjustment code is disabled due to not setting pkt_timebase?
[16:30:18 CEST] <Daemon404> ah pkt_timebase...
[16:30:48 CEST] <Daemon404> i can add a copy for that under deprecation guards... but... eh...
[16:30:59 CEST] <Daemon404> should i really need to copy from st->codec? is it too dumb?
[16:31:29 CEST] <wm4> pkt_timebase should be the same as the AVStream timebase
[16:31:39 CEST] <wm4> because it's the timebase packet timestamps use
[16:32:02 CEST] <Daemon404> ah.. good
[16:32:10 CEST] <Daemon404> in this new model of ffprobe, each stream has its own decoder context
[16:32:13 CEST] <Daemon404> so it should be doable
[16:32:41 CEST] <Daemon404> yes using that fixes it
[16:33:40 CEST] <Daemon404> fate all passes now
[16:38:29 CEST] <cone-755> ffmpeg 03Anton Khirnov 07master:ba357e98691e: avprobe: switch to codecpar
[16:38:30 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:9080dc7f0742: Merge commit 'ba357e98691ee4fe1a503b8830c0050be4127475'
[16:39:29 CEST] <cone-755> ffmpeg 03Anton Khirnov 07master:dbb43b8b83b0: avpacket: properly reset data/size in av_packet_move_ref()
[16:39:30 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:9a98ddcf1b30: Merge commit 'dbb43b8b83b097585ec255ec638b61e359ebea77'
[16:42:02 CEST] <cone-755> ffmpeg 03Luca Barbato 07master:ce9d7da76504: qsv: Move down the implementation query
[16:42:03 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:6e2ca814857b: Merge commit 'ce9d7da7650473f580dcce8c9f8550ea532aa6bd'
[16:42:43 CEST] <cone-755> ffmpeg 03Diego Biurrun 07master:73ff983e8dd2: fft: x86: cosmetics: Drop silly comments, add comment, whitespace
[16:42:44 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:d496d52d029a: Merge commit '73ff983e8dd22ccee166403d0bbbc9c1cd543622'
[16:43:19 CEST] <cone-755> ffmpeg 03Diego Biurrun 07master:97aec6e75ef3: fft: arm: Drop unnecessary #include, add missing ones
[16:43:20 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:197fa698c6cf: Merge commit '97aec6e75ef36ed0402653519daa8e1fc8ddb555'
[16:45:03 CEST] <cone-755> ffmpeg 03Diego Biurrun 07master:4c297249ac0f: rdft: arm: Split RDFT initialization into a separate file
[16:45:04 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:2605967f7eb5: Merge commit '4c297249ac0f513a610a62691ce96d6b62f65b94'
[16:58:28 CEST] <cone-755> ffmpeg 03Diego Biurrun 07master:f6ccee9bed92: fate: fft: Split DCT/FFT/MDCT/RDFT tests into separate targets
[16:58:29 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:05e4783c2910: Merge commit 'f6ccee9bed92c09799777c1dfb2b2772763e0e83'
[16:59:58 CEST] <cone-755> ffmpeg 03Mark Harris 07master:4d13bcceb9a1: sdp: fix opus sprop-stereo fmtp syntax
[16:59:59 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:aa9517583ea1: Merge commit '4d13bcceb9a1820f8e9b2c89e00816d3db41b716'
[17:11:31 CEST] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=1a094af638281295bf087945923d258b5acd1ab1 <-- barf
[17:12:04 CEST] <Daemon404> gonna be a pita
[17:12:55 CEST] <nevcairiel> thats diego in a nutshell =p
[17:12:56 CEST] <BBB> as long as theres two projects, every major refactoring in them is a pain for us
[17:13:07 CEST] <BBB> Id almost say that thats the whole summary of their existence
[17:13:07 CEST] <Daemon404> this isnt major
[17:13:13 CEST] <Daemon404> its just annoying
[17:13:18 CEST] <Daemon404> i wouldnt. just diego's.
[17:13:19 CEST] <BBB> stop merging it
[17:13:29 CEST] <BBB> stop merging diegos commits
[17:13:38 CEST] <Daemon404> then every actual useful commit becomes 100x harder to merge
[17:14:11 CEST] <durandal_1707> what don touched this time?
[17:14:47 CEST] <Daemon404> the refactoring is actually more correct, in this case
[17:15:38 CEST] <durandal_1707> oh looks like lot of work
[17:15:47 CEST] <kierank> why does he want to extract fft from mdct
[17:15:56 CEST] <nevcairiel> dont ask why diego does things
[17:15:58 CEST] <nevcairiel> he just does
[17:17:20 CEST] <BBB> michaelni: in ffh264, Im looking at stuff like MB_TYPE_PnLn where n is 0 or 1 (in {b,p{,_sub}}_mb_type_info) - what does the P stand for?
[17:28:21 CEST] <Daemon404> BBB, i think having to rescale with swscale is a problem with ffmpeg.c, not individual muxers
[17:28:26 CEST] <Daemon404> re: framehash
[17:28:40 CEST] <BBB> I thought that got fixed in ffmpeg.c?
[17:28:56 CEST] <BBB> I recall discussing that with michaelni a while ago and theres a way for ffmpeg.c to not force rescaling of all frames to the same size
[17:29:46 CEST] <nevcairiel> i think the problem is that rawvideo doesn't really have a way to signal resolution changes to a rawvideo muxer
[17:29:57 CEST] <nevcairiel> since it has no frame-level metadata
[17:30:20 CEST] <nevcairiel> you could try to use the wrapped_avframe dealy, maybe that allows it
[17:35:13 CEST] <michaelni> BBB, IIRC P stands for partition
[17:35:14 CEST] <jkqxz> BBB:  Pn is the partition being referred to by the particular element?  (PxLy - partition x uses reference list y, etc.)  Those appear to be tables 7-11 to 7-18 in H.264.
[17:35:35 CEST] <jkqxz> Not sure how that is mapping to four-partition macroblocks, though.
[17:35:35 CEST] <BBB> so why is it only p0 and p1 even in case of split (pcnt=4)?
[17:36:44 CEST] <michaelni> the case for 4 is handled differently in the bitstream and data structures
[17:37:23 CEST] <BBB> I see, ok
[17:37:37 CEST] <Daemon404> damn, crash with converted ffprobe...
[17:37:40 CEST] <Daemon404> debuggin
[17:37:57 CEST] <BBB> each 8x8 subblock can have different refs, but each 4x4 uses the same refs within the parent 8x8, right?
[17:38:07 CEST] <BBB> (or 4x8, or 8x4)
[17:38:24 CEST] <michaelni> IIRC yes
[17:38:38 CEST] <BBB> ty
[17:46:51 CEST] <rcombs> Daemon404: regarding autobsf+dash, what would you recommend I do? Have the mov muxer turn autobsf off at init-time?
[17:50:35 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:9cb1ed5735ec: ffprobe: Fix missing dec_ctx check
[17:52:47 CEST] <nevcairiel> rcombs: dont they need to set some common attribute for dash behavior to be enabled, that you could check for?
[17:53:11 CEST] <rcombs> nevcairiel: they set movflags=+dash
[17:53:30 CEST] <rcombs> well, strictly, they set movflags=frag_custom+dash+delay_moov
[17:53:44 CEST] <rcombs> not sure if one of those is more productive to gate this on than dash itself
[17:53:59 CEST] <rcombs> and I'm assuming that nobody will ever want auto-bsf at the mov muxer level when using DASH
[17:54:17 CEST] <rcombs> (in my patches, autobsf works at the DASH muxer level)
[18:24:45 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:e8373143e118: ffprobe: Don't try and decode things that have no dec_ctx
[18:35:55 CEST] <kurosu> Zeranoe: mpeg-2, xvid or vp9 - h264/avc or hevc are particularly hindered by bitstream reading using gcc inline asm
[18:36:38 CEST] <Daemon404> mpeg-2 has a bunch of inline asm
[18:36:58 CEST] <kurosu> oh right, some mc functions I haven't converted
[18:37:10 CEST] <kurosu> (not sure they impact much the decoding, but true)
[18:37:22 CEST] <Daemon404> i seem to recall quit a difference
[18:37:27 CEST] <Daemon404> but this was ~2 years ago
[18:37:28 CEST] <Daemon404> or 3
[18:38:49 CEST] <kurosu> also, the mastering metadata effort is indeed probably linked to HDR
[18:44:53 CEST] <wm4> does anyone know how HDR is supposed to work yet?
[18:46:01 CEST] <Daemon404> kurosu, BBC/EBU/whoever is doing a separate type of HDR btw
[18:46:09 CEST] <Daemon404> 'backwards compatible'
[18:46:20 CEST] Action: Daemon404 is sure it till be fun to mix
[18:46:55 CEST] <kurosu> then you have hdr10, then dolby vision
[18:47:12 CEST] <kurosu> (or the reverse, as netflix will initially use the later)
[18:47:28 CEST] <Daemon404> excellent. so many choices. /s
[18:48:33 CEST] <kurosu> Wait for Google's own version
[18:48:53 CEST] <kurosu> it's as if ffmpeg will soon need improved colorspace filters <g>
[18:49:06 CEST] <kierank> hdr is a joke
[18:49:12 CEST] <kierank> can only see the difference in the dark by the water
[18:49:20 CEST] <kierank> another geek toy like 4k
[18:50:17 CEST] <kurosu> kierank, wait until you have to implement part of it for your clients :p
[18:50:35 CEST] <Daemon404> his clients will probably want the easy one (ebu)
[18:50:36 CEST] <kierank> they need to be able to deliver it to me in a cable first
[18:50:47 CEST] <Daemon404> kierank, good thing the ebu one can!
[18:50:51 CEST] <kierank> the easy one I do nothing
[18:50:54 CEST] <durandal_1707> BBB: when you gona apply filter?
[18:51:02 CEST] <kierank> actually I got asked to implement the dolby one
[18:51:06 CEST] <kierank> but nobody gave me a spec
[18:51:11 CEST] <Daemon404> kierank, depends if it needs special processing wrt color stuff they need
[18:51:14 CEST] <Daemon404> but yea
[18:51:19 CEST] <durandal_1707> buy spec
[18:51:26 CEST] <kierank> spec don't exist
[18:51:27 CEST] <Daemon404> you cant buy dolby specs
[18:55:40 CEST] <kurosu> http://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-white-paper.pdf <- Dolby Vision seems to be based on some sort of scalable coding (p11)
[18:56:12 CEST] <kurosu> oh, and multiview hevc/avc-based
[19:03:35 CEST] <rcombs> kurosu: Daemon404: wtf is dolby vision anyway
[19:03:52 CEST] <rcombs> I've got a sample file here and afaik it's lust an hevc 10-bit file?
[19:04:36 CEST] <JEEB> yeah, it should be standard 10bit HEVC with specific mastering data
[19:04:50 CEST] <JEEB> and then possibly some specs on the playback side
[19:04:54 CEST] Action: JEEB shrugs
[19:05:10 CEST] <rcombs> wow, they're not even developing their own mediocre tech anymore
[19:05:16 CEST] <rcombs> just slapping their name on existing stuff
[19:05:18 CEST] <JEEB> I linked stuff on the video type of "HDR" for a guy before
[19:05:20 CEST] <rcombs> I think that's a plus
[19:05:53 CEST] <JEEB> but yeah, basically content-wise it's just that mastering metadata crap
[19:05:58 CEST] <JEEB> and then it gets rendered accordingly
[19:07:01 CEST] <rcombs> dialnorm for video!
[19:07:16 CEST] <rcombs> I'm sure it'll be used just as effectively in practice
[19:11:55 CEST] <wm4> well what the consumer sees is that the video is "faded"
[19:12:07 CEST] <haasn> the answer is everybody does HDR differently. it's all marketing
[19:12:19 CEST] <haasn> no standard at all
[19:12:29 CEST] <haasn> Or well, no consistent use of the existing standards
[19:12:38 CEST] <kierank> what existing standrads
[19:13:28 CEST] <haasn> SMPTE ST-2084
[19:13:32 CEST] <Daemon404> why even do real hdr. just crank up the contrast and saturation and tell people it's hdr
[19:13:35 CEST] <Daemon404> they eat it up
[19:14:01 CEST] <fritsch> :-)
[19:14:03 CEST] <fritsch> so true
[19:14:12 CEST] <fritsch> sadly
[19:14:40 CEST] <Daemon404> add some bloom for good measure
[19:15:24 CEST] <rcombs> I mean, 10-bit coding can be useful for efficiency and handling dark gradients and such well
[19:15:40 CEST] <fritsch> yes ... but it's not only the decoder 
[19:15:44 CEST] <fritsch> but the rendering, the display
[19:16:09 CEST] <fritsch> on linux intel gpus cannot even output 10 bit colors
[19:16:18 CEST] <wm4> yet?
[19:16:22 CEST] <haasn> bit depth and HDR are not strictly related. The difference is in the semantics. You can get 10 and 12-bit coding for traditional response curves that max out at 120 cd/m². In fact, BT.2020 standardizes those exact two bit depths
[19:16:37 CEST] <fritsch> wm4: i think  plain X works, but in combination with OpenGL big problem
[19:16:38 CEST] <Daemon404> fritsch, who even owns 10bit panels
[19:16:40 CEST] <haasn> HDR is not just adding bits, it's taking the 120 cd/m² peak and raising it up to 10,000 cd/m²
[19:16:44 CEST] <rcombs> clearly we should compromise at either 9-bit or 11-bit
[19:16:44 CEST] <Daemon404> aside from a very select group
[19:16:49 CEST] <rcombs> this will solve all the problems
[19:16:56 CEST] <haasn> Daemon404: who even owns 8bit panels
[19:16:57 CEST] <kierank> haasn: that's essentially dolby
[19:16:58 CEST] <haasn> aside from a very select group
[19:17:05 CEST] <kierank> 2804
[19:17:07 CEST] <Daemon404> lol... somewhat true
[19:17:14 CEST] <Daemon404> 8bit is becoming somewhat more common though
[19:17:17 CEST] <haasn> I mean most 10 bit displays on the market are 8 bit panels with good dithering
[19:17:21 CEST] <wm4> fritsch: that's terrible
[19:17:28 CEST] <haasn> and 8 bit displays on the market are mostly 6 or 7 bit panels with dithering
[19:17:39 CEST] <wm4> fritsch: I think the same works perfectly well on dxva/d3d11
[19:17:51 CEST] <rcombs> my laptop's 8-bit :3
[19:17:56 CEST] <haasn> meanwhile it took nvidia a few years to get 10-bit support implemented after announcing the feature
[19:17:59 CEST] <rcombs> pretty sure my projector is too
[19:17:59 CEST] <haasn> but now it works
[19:18:11 CEST] <rcombs> (3LCD lol)
[19:19:48 CEST] <fritsch> wm4: most likely, yes
[19:19:54 CEST] <BBB> durandal_1707: can do now if you want
[19:19:56 CEST] <haasn> anyway the problem with Ultra HD and BT.2020 in general is that there's a lot of standards confusion going on; because the idea of the standard was to support a very gratuitous color space, suitable for virtually any future media - except apparently nobody really talked about how people would actually use it on real world displays that can't perfectly reproduce these ideals
[19:20:00 CEST] <BBB> durandal_1707: I dont tihnk there were any pending big comment
[19:20:48 CEST] <haasn> for example, how would you watch a BT.2020 wide gamut film on a TV that can only handle adobeRGB gamut. How do you watch a HDR movie with super-peaks at 5000 cd/m² on a TV that only goes up to 1000 (or 100)
[19:21:13 CEST] <haasn> The standards are built around unrealistic ideal devices
[19:22:03 CEST] <haasn> Which is fine in theory but in practice nobody can seem to agree about how to use them. Do you just encode movies with a limited range (as a subset of the available encoding space) so that real world devices can display them? What devices do you target?
[19:22:07 CEST] <nevcairiel> there are algorithms to compress the gamut or luminance
[19:22:42 CEST] <haasn> Yeah but these algorithms generally require the ability to know what the signal peak is going to be (ahead of time)
[19:22:53 CEST] <haasn> for example, what brightness do you map onto the display's maximum?
[19:23:17 CEST] <nevcairiel> if its a SDR display thats pretty easy
[19:23:28 CEST] <haasn> One solution would be sufficiently tagging this information so you can pick a good-enough conversion algorithm, but such tagging seems to be absent
[19:23:31 CEST] <nevcairiel> and HDR should have metadata to tell you the peak
[19:23:45 CEST] <nevcairiel> at least h265 hdr encoders do have it
[19:23:49 CEST] <haasn> It doesn't in practice (from what I've seen)
[19:24:01 CEST] <nevcairiel> any hevc hdr samples i have seen have it
[19:24:09 CEST] <haasn> interesting, got some examples?
[19:24:18 CEST] <haasn> or sample files that I could use for testing
[19:24:21 CEST] <nevcairiel> at least those that claim to be uhd blu-ray hdr compatible
[19:24:29 CEST] <haasn> (and does ffmpeg export this information?)
[19:24:40 CEST] <nevcairiel> on an API level its exported now
[19:24:46 CEST] <nevcairiel> not sure how well the CLI shows it
[19:24:56 CEST] <Daemon404> re metadata: "iirc, contains the primaries, transfer curve, and peak brightness of the reference display"
[19:25:00 CEST] <Daemon404> from elsewhere
[19:25:08 CEST] <Daemon404> seems relevant (peak brightness)
[19:25:32 CEST] <nevcairiel> people have implemented hdr -> sdr conversion algorithms based on that metadata, and it looks better than a sdr source of the same content =p
[19:25:36 CEST] <haasn> What is this primaries tag? Is that the signal peak, or is that just tagging whether it's BT.2020 or BT.709 or whatever?
[19:26:09 CEST] <nevcairiel> http://demo-uhd3d.com/fiche.php?cat=uhd&id=89 .. that sample should have all the data iirc
[19:26:20 CEST] <nevcairiel> other hdr samples on that site as well, but one or two were broken
[19:26:31 CEST] <haasn> nevcairiel: Mapping HDR to SDR during display and just encoding the SDR sample that way to begin with are technically indistinguishable. My guess is that it just looks different, new, exciting, and therefore better
[19:26:45 CEST] <haasn> Like the I bought new headphones and everything sounds so amazing now effect
[19:27:45 CEST] <nevcairiel> well not quite, authoring from the original master could result in a different image
[19:28:01 CEST] <haasn> There is two version of this demo (Right Clic and Save) and I don't realy know what's the difference (only 1Kb difference ...) : lol
[19:28:19 CEST] <nevcairiel> unfortunately HDR -> SDR conversions dont seem to be standardized yet
[19:28:34 CEST] <fritsch> amlogic does it blackbox wise ...
[19:28:49 CEST] <fritsch> on linux, they decode and then directly output to framebuffer
[19:28:52 CEST] <nevcairiel> wonder what (if anything) future SDR TVs might do for UHD HDR playback
[19:29:10 CEST] <haasn> nevcairiel: How long did it take the ITU-R to standardize HDR -> SDR conversion (on the dark end of the spectrum) last time? :p
[19:29:34 CEST] <haasn> (that is going from a color space with a true black point to a display with a low contrast)
[19:30:12 CEST] <fritsch> dark channel prior for the win
[19:30:31 CEST] <fritsch> though ... that won't work as it will end up as contrast maximization
[19:30:34 CEST] <fritsch> for every image
[19:40:47 CEST] <jamrial> BBB:  example of wrapped_avframe vs rawvideo: http://pastebin.com/raw/uVEqJ6UK
[19:41:15 CEST] <nevcairiel> wrapped avframe should probably hash the contents, not the frame itself
[19:55:34 CEST] <cone-755> ffmpeg 03Moritz Barsnick 07master:f4a0236cbd75: avformat: add hash and framehash muxers
[19:55:35 CEST] <cone-755> ffmpeg 03Michael Niedermayer 07master:e3111b1ff859: avformat/framehash: Add more information to the output
[20:21:31 CEST] <cone-755> ffmpeg 03James Almer 07master:d7815df40285: arm/rdft_init: fix license header
[20:21:47 CEST] <blop> hello ;)
[20:22:25 CEST] <blop> is it possible to disable audio decoding while using -acodec copy ? ffmpeg keeps trying to decode AAC and fail, but all I need is copy
[20:29:03 CEST] <JEEB> that should not decode the audio at all
[20:29:35 CEST] <JEEB> blop: and please don't spam both channels :P for such usage questions the main channel works
[20:29:43 CEST] <blop> yes sorry :)
[20:29:47 CEST] <JEEB> so please respond there with the command line and terminal output pastebin'd
[20:30:30 CEST] <wm4> JEEB: it may decodes some by libavformat design
[20:30:41 CEST] <JEEB> sure
[20:30:44 CEST] <JEEB> for probing
[20:41:33 CEST] <DHE> as I understand it ffmpeg does decode just enough to identify the stream, for metadata purposes. once it's ready the stream copy does not decode
[20:41:53 CEST] <DHE> avformat_find_stream_info does this
[20:41:59 CEST] <JEEB> the errors happen after the probing
[20:42:12 CEST] <JEEB> http://pastebin.com/dWc9THSS
[21:49:14 CEST] <durandal_1707> working on libnut codecpar changes?
[21:50:27 CEST] <wm4> who cares about libnut
[22:15:09 CEST] <Angus> is anyone here familar with the H264_vdpau codec/decoder?
[22:15:31 CEST] <fritsch> ask your questions and we will see if you get responses
[22:16:04 CEST] <Angus> If you call avcodec_decode_video2 with the codec initialized to h264_vdpau, does it work?
[22:16:29 CEST] <Angus> this guy:
[22:16:30 CEST] <Angus> http://stackoverflow.com/questions/23289157/how-to-use-hardware-acceleration-with-ffmpeg
[22:17:07 CEST] <Angus> seem to have run into a bunch of problems with the vdpau decoder, although I'm not sure if he was using avcodec_decode_video2
[22:23:30 CEST] <jkqxz> Angus:  Standalone H.264 vdpau decoder ("h264_vdpau") is deprecated but still in the codebase.  You want to use the normal decoder + vdpau hwaccel.
[22:25:28 CEST] <jkqxz> (ffmpeg_vdpau.c being an example of what you need to do to set that up.)
[22:26:45 CEST] <Angus> would avcodec_decode_video2 still be used in that case? I suspect I would have to write a function to replace it?
[22:27:06 CEST] <fritsch> why?
[22:28:13 CEST] <jkqxz> Yes.  You use it with the decoder "h264", and have a suitable hwaccel_context in the AVCodecContext.
[22:30:36 CEST] <Angus> ahh, I see. Would the decoder .capabilities need to be updated for hwaccel?
[22:32:07 CEST] <Angus> (with AV_CODEC_CAP_HWACCEL_VDPAU  )
[22:38:18 CEST] <jkqxz> No?  That looks like it exists to hack the standalone decoder into working.  (It's inside deprecation markers, anyway.)
[22:41:06 CEST] <BBB> kierank: with the clipw addressed, ok to commit colorspace filter?
[22:41:20 CEST] <BBB> kierank: I agree the constants should be grouped in lavfi, Ill do that separtately since it involves quite a few filters
[22:41:35 CEST] <BBB> kierank: theres no constants in lavfi yet...
[22:41:38 CEST] <kierank> Ok
[22:41:40 CEST] <wm4> Angus: ffmpeg_vdpau.c might serve as example
[22:41:41 CEST] <BBB> ty
[22:41:42 CEST] <kierank> Ok
[22:41:46 CEST] <wm4> Angus: it has all of the glue code needed
[22:42:41 CEST] <Angus> alright, going to read through it more carefully then
[22:43:28 CEST] <cone-755> ffmpeg 03Ronald S. Bultje 07master:2e2e08a35b47: lavfi: new colorspace conversion filter.
[22:43:29 CEST] <cone-755> ffmpeg 03Ronald S. Bultje 07master:5ce703a6bff7: vf_colorspace: x86-64 SIMD (SSE2) optimizations.
[22:44:57 CEST] <durandal_1707> now we can deprecate colormatrix shit
[22:46:19 CEST] <wm4> ok so we have 4 filters which can do conversions and also a library nobody wants to cleanup
[22:56:02 CEST] <cone-755> ffmpeg 03Paul B Mahol 07master:392b0a25c236: avcodec/exr: fix clearing end of bitmap
[22:56:03 CEST] <cone-755> ffmpeg 03Martin Vignali 07master:ac07e57c39de: avcodec/exr: fix huf_decode
[22:59:47 CEST] <durandal_1707> wm4: moar features
[22:59:53 CEST] <cone-755> ffmpeg 03Yuuki Galaxy 07master:af5419f91b06: libavfilter/vf_owdenoise.c: skip processing when strength is 0
[23:32:30 CEST] <michaelni> BBB, "vf_colorspace: x86-64 SIMD (SSE2) optimizations." break checkasm here
[23:32:41 CEST] <BBB> hm?
[23:32:44 CEST] <BBB> works for me
[23:32:59 CEST] <BBB> got more details?
[23:33:05 CEST] <michaelni> "Bus error" here valgrind says:
[23:33:12 CEST] <michaelni> Process terminating with default action of signal 11 (SIGSEGV)
[23:33:12 CEST] <michaelni> ==29432==  Access not within mapped region at address 0x7FF001000
[23:33:13 CEST] <michaelni> ==29432==    at 0x4210EE: rgb2yuv_444p10_c (colorspacedsp_template.c:187)
[23:33:13 CEST] <michaelni> ==29432==    by 0x41F65A: checkasm_checked_call (checkasm.asm:242)
[23:33:28 CEST] <michaelni> beynd that the backtrace is bunch of ???
[23:33:50 CEST] <nevcairiel> my msvc fate box also segfaults on it
[23:33:58 CEST] <BBB> 32bit or 64bit?
[23:34:02 CEST] <nevcairiel> 32
[23:34:07 CEST] <michaelni> 64 here 
[23:34:09 CEST] <BBB> that should never run any assembly
[23:34:13 CEST] <BBB> very confused
[23:34:28 CEST] <Daemon404> his bt looks like the c path.
[23:34:40 CEST] <BBB> oh I see
[23:34:53 CEST] <BBB> I think were overallocating the rgb buffer by 2x and underallocating the yuv buffer by 2x
[23:34:54 CEST] <BBB> clever
[23:35:47 CEST] <nevcairiel> and that didnt crash for you?
[23:35:54 CEST] <BBB> michaelni: in checkasm/vf_colorspace.c line 206-215, can you change the buf size of uint8_t buffers from W * H to W * H * 2, and int16_t buffers from W * H * 2 to W * H?
[23:36:00 CEST] <BBB> nope, runs fine for me
[23:36:33 CEST] <nevcairiel> guess windows actually cares to check memory access then =p
[23:36:50 CEST] <BBB> I think it simply means array layout on stack is inverted for clang
[23:37:11 CEST] <BBB> (dst is locates before src)
[23:37:26 CEST] <BBB> which means we overwrite dst into src, but since both c and asm paths do that, the outcome is actually still identical
[23:37:57 CEST] <BBB> nevcairiel: or you can test that change also if you want
[23:38:15 CEST] <BBB> my tree is quite messy so itd take me a while to submit a patch (working on some h264 stuffies)
[23:38:29 CEST] <michaelni> BBB works with the change
[23:38:30 CEST] <nevcairiel> thats what git invented stash for =)
[23:38:40 CEST] <BBB> Ive never used stash in my life
[23:38:53 CEST] <BBB> quilt had push/pop, is it similar to that?
[23:38:59 CEST] <JEEB> yeah
[23:39:04 CEST] <BBB> ah, ok
[23:39:07 CEST] <JEEB> git stash pushes, git stash pop pops
[23:39:07 CEST] <BBB> intruiging
[23:39:18 CEST] <BBB> should look into that
[23:39:25 CEST] <JEEB> that said, I always tend to forget about what I had in git stash if it's for more than 10 seconds
[23:39:32 CEST] <JEEB> so I just use branches with quick commits
[23:40:08 CEST] <michaelni> BBB should i push the *2 change or you do it (asking as "my tree is quite messy so itd take me a while to submit a patch") ?
[23:40:16 CEST] <BBB> you can do it, thanks
[23:40:30 CEST] <JEEB> but it's simple for git stash && git merge origin/master && git stash pop or so, where I just want to remove and re-add some changes that I haven't committed
[23:40:31 CEST] <BBB> I suppose wed want this in quickly
[23:40:44 CEST] <michaelni> k, ill just test on other platforms too
[23:43:05 CEST] <BBB> ty
[23:45:50 CEST] <cone-755> ffmpeg 03Marton Balint 07master:ee94b1a50ad9: ffplay: convert to codecpar
[23:48:01 CEST] <cone-755> ffmpeg 03Michael Niedermayer 07master:4d59d075a96c: tests/checkasm/vf_colorspace: Fix dst array sizes
[00:00:00 CEST] --- Wed Apr 13 2016