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

[burek]

[01:01:27 CEST] <jkqxz> wm4:  Can you see any problems with libva changing the SONAME and then disallowing loading old drivers?  I think that fixes everything going forward (destroy buffers if libva2, don't if libva1 except quirk for intel), but I might be missing something.
[01:01:50 CEST] <jkqxz> (Ignoring the broken intermediate releases.)
[01:02:20 CEST] <wm4> jkqxz: that sounds fine
[01:02:34 CEST] <wm4> is the bug in the individual drivers?
[01:03:13 CEST] <jkqxz> Which bug?
[01:04:02 CEST] <wm4> the buffer destruction semantics
[01:04:10 CEST] <jkqxz> One consequence of that change would be that it would kill the vdpau wrapper unless someone takes it over and updates it to libva2.
[01:04:32 CEST] <wm4> that would probably make the world a better place
[01:04:41 CEST] <wm4> anyway I yelled a lot at intel's direction and now I feel better
[03:04:57 CEST] <stevenliu> <ubitux> you mean rotate, yes;    <ubitux> you have the rotate filter..   no, do you have it?
[06:20:13 CEST] <cone-477> ffmpeg 03James Almer 07master:bd1179e36bad: avutil/pixfmt: remove superfluous define
[07:50:13 CEST] <ubitux> stevenliu: -vf rotate is present in the codebase
[07:51:01 CEST] <stevenliu> Thanks, let me try to use it :)
[07:54:34 CEST] <stevenliu> Ahaha, That's cool
[07:54:44 CEST] <stevenliu> very nice function :)
[10:17:44 CEST] <AaronL> maybe I'm missing something here, but as far as I can tell, av_write_trailer() does nothing in practice for mpegts
[10:18:33 CEST] <AaronL> in mpegtsenc.c, mpegts_write_end() is set to write_trailer(), and all this does is a flush
[10:18:46 CEST] <AaronL> I looked at other enc avformats, and most do quite a bit
[10:18:54 CEST] <AaronL> of work to write a trailer
[10:18:59 CEST] <nevcairiel> mpegts doesnt have headers or footers, so neither write_header or write_trailer do anything really
[10:19:07 CEST] <nevcairiel> its the fate of a streaming format
[10:20:02 CEST] <nevcairiel> (or broadcast format)
[10:20:17 CEST] <AaronL> well, there must be some sort of header to identify the programs and streams in it, right?
[10:20:28 CEST] <nevcairiel> its not actually a header though
[10:20:37 CEST] <nevcairiel> it gets repeated all over
[10:20:59 CEST] <AaronL> well, I think  the rate at which it is repeated is controllable
[10:22:38 CEST] <alevinsn> ok, so, there is no real way to know that an mpeg TS is finished being sent from the TS itself?
[10:23:28 CEST] <alevinsn> other than it stops getting packets, I guess, although that could be caused by a number of different things
[10:24:03 CEST] <wm4> well broadcast streams rarely actually stop
[10:25:01 CEST] <alevinsn> ok
[10:25:50 CEST] <alevinsn> totally unrelated, when I use h264_qsv for decoding 1080i59.94 video, I noticed that it is reporting the duration incorrectly for each video frame
[10:26:01 CEST] <alevinsn> I looked into the cause
[10:26:09 CEST] <alevinsn> and its complicated
[10:26:17 CEST] <nevcairiel> duration information is often quite inaccurate
[10:26:38 CEST] <alevinsn> well, in this case, its wrong for a pretty understandable reason
[10:26:53 CEST] <alevinsn> but, I'm not sure of the right way to fix it
[10:27:05 CEST] <BtbN> I don't think the decoder is involved with the duration at all
[10:27:09 CEST] <alevinsn> with 1080i59.94, the frame rate is 30000/1001
[10:27:10 CEST] <BtbN> it just re-orders timestamps
[10:27:12 CEST] <alevinsn> it is
[10:27:16 CEST] <alevinsn> but I'll get to that
[10:27:37 CEST] <alevinsn> but, in an mpegts, the timebase is 90000/1
[10:27:50 CEST] <alevinsn> so, the first video frame pts is 3003
[10:27:58 CEST] <alevinsn> and it ought to have a duration of 3003 as well
[10:28:15 CEST] <alevinsn> but, instead, it gets a duration of 1501
[10:28:45 CEST] <nevcairiel> sounds like something wm4 might get upset about =p
[10:28:46 CEST] <alevinsn> The duration is calculated by ff_compure_frame_duration() for each packet
[10:29:07 CEST] <alevinsn> and, it does this by using st->internal->avctx->ticks_per_frame
[10:29:22 CEST] <alevinsn> which happens to be 2 in this case--there is a comment associated with ticks_per_frame
[10:29:31 CEST] <alevinsn> indicating that it is 2 for H.264 and MPEG-2
[10:29:37 CEST] <alevinsn> although, I wonder if that comment is correct
[10:29:48 CEST] <alevinsn> however h264_qsv doesn't set ticks_per_frame
[10:30:17 CEST] <alevinsn> st->internal->avctx is actually an AVCodecContext * for the default H.264 decoder
[10:30:29 CEST] <alevinsn> I tried passing in a whitelist
[10:30:42 CEST] <alevinsn> but that doesn't work at all, because when probing, there is a sort of kludge in the code
[10:30:54 CEST] <alevinsn> that forces it to load the default H.264 decoder no matter what if the codec ID is H.264
[10:31:29 CEST] <nevcairiel> the packet timestamps should be entirely independent of whatever decoder is used later
[10:31:38 CEST] <alevinsn> the packet timestamps are correct
[10:31:47 CEST] <alevinsn> it is the calculated durations that are wrong, divided by 2
[10:32:05 CEST] <nevcairiel> ff_compute_frame_duration is used during demuxing, either its always wrong or always right, it must not depend on the decoder used
[10:32:57 CEST] <BtbN> some decoders might strip the duration though. I'm not sure how I did in in cuvid
[10:32:59 CEST] <alevinsn> I think it always ends up being wrong in the case that the H.264 decoder that is actually used is not the default H.264 decoder (i.e. the software one)
[10:33:15 CEST] <alevinsn> if it uses the software decoder, I think it will be correct
[10:33:16 CEST] <nevcairiel> or the decoder is handling it wrong =p
[10:33:30 CEST] <alevinsn> there are two issues I think
[10:33:44 CEST] <alevinsn> first, I'm not sure if setting ticks_per_frame to 2 is legit in any situation
[10:34:03 CEST] <alevinsn> the comment in avcodec.h indicates that this is the right thing to do for H.264 and MPEG-2
[10:34:21 CEST] <alevinsn> that these codecs use a "time base that is closer to the field rate than the frame rate"
[10:35:14 CEST] <alevinsn> second, the fact that there is this internal codec context for each stream is also cause for concern
[10:35:29 CEST] <alevinsn> particularly since it may not necessarily be equivalent to the one that the user picks
[10:35:43 CEST] <nevcairiel> its an internal implementation detail, its totally irrelevant to the user
[10:36:00 CEST] <alevinsn> well, in this case, it is relevant, because it results in the duration being calculated incorrectly
[10:36:15 CEST] <nevcairiel> or it doesn't and qsv just screws up
[10:36:19 CEST] <nevcairiel> which in my mind is far more likely
[10:36:32 CEST] <alevinsn> no, the duration isn't populated at all by QSV
[10:36:35 CEST] <alevinsn> I confirmed it
[10:36:43 CEST] <nevcairiel> maybe thats the problem =p
[10:36:44 CEST] <alevinsn> it is entirely calculated
[10:36:45 CEST] <nevcairiel> interlaced is messy
[10:37:03 CEST] <alevinsn> I think it will be wrong regardless of interlaced or progressive actually
[10:37:07 CEST] <nevcairiel> mixing field and frame durations can get annoying
[10:37:13 CEST] <alevinsn> will always be divided by 2
[10:37:31 CEST] <alevinsn> because it uses ticks_per_frame from the internal context for that calculation
[10:37:41 CEST] <alevinsn> and h264_qsv doesn't set ticks_per_frame
[10:37:49 CEST] <nevcairiel> so maybe qsv should just behave and set ticks_per_frame like every good h264 decoder? :)
[10:37:50 CEST] <alevinsn> and neither do the rest of the H.264 decoders for that matter
[10:38:30 CEST] <alevinsn> I mean, the hardware H.264 decoders
[10:39:04 CEST] <alevinsn> it looks like libx264 doesn't even set it
[10:39:30 CEST] <nevcairiel> its an encoder
[10:39:33 CEST] <nevcairiel> its different
[10:39:48 CEST] <alevinsn> ok, right, I figured it might be used for decoding as well
[10:40:09 CEST] <wm4> soon enough it should become unneeded to use the qsv decoder
[10:40:15 CEST] <wm4> and you can just use dxva or vaapi
[10:40:28 CEST] <alevinsn> true, but it looks like this will be an issue for h.264 dxva or vaapi decoders as well
[10:40:34 CEST] <nevcairiel> no it wont
[10:40:36 CEST] <alevinsn> neither of which sets the duration
[10:41:01 CEST] <alevinsn> which makes me think that the duration for those decoders is calculated the same way
[10:41:27 CEST] <nevcairiel> just set ticks_per_frame in the hardware decoders if they dont handle durations themself somewhere
[10:41:59 CEST] <alevinsn> that might not be enough in and of itself
[10:43:18 CEST] <alevinsn> the code in h264dec.c also adjusts time_base.den
[10:43:35 CEST] <wm4> time_base is outdated
[10:44:08 CEST] <alevinsn> time_base in general or just the one for AVCodecContext ?
[10:44:36 CEST] <wm4> time_base for decoding
[10:44:44 CEST] <wm4> in AVCodecContext
[10:44:59 CEST] <alevinsn> the one in AVStream is still relevant I would think
[10:45:01 CEST] <wm4> it's supposed to be used for encoding only
[10:45:05 CEST] <wm4> yes
[10:45:46 CEST] <alevinsn> but, is using 2 for ticks_for_frame correct for H.264 in the first place?
[10:46:00 CEST] <alevinsn> someone obviously thought so
[10:46:24 CEST] <alevinsn> and H.264 always uses 2 for ticks_per_frame
[10:46:29 CEST] <alevinsn> for both progressive and interlaced
[10:47:18 CEST] <wm4> I think this is just for making "space" in the timebase so you can sneak in fields
[10:47:30 CEST] <wm4> progressive and interlaced can switch midstream anyway
[10:47:50 CEST] <alevinsn> then, would it be relevant for HEVC as well?  It isn't being done there
[10:48:20 CEST] <alevinsn> At least with QSV encoding, it only deals with interleaved frames
[10:48:28 CEST] <alevinsn> and doesn't encode fields separately
[10:49:15 CEST] <nevcairiel> hevc has practically no interlacing support, and our decoder doesnt support it at all
[10:49:38 CEST] <nevcairiel> it only has some metadata to interleave individual fields coded as frames, but they are not very special
[11:37:48 CEST] <BtbN> Can I just use the _WIN32 macro in ffmpeg C code, or is there some configure macro I should check instead?
[11:38:24 CEST] <nevcairiel> BtbN: it depends what exactly for
[11:38:46 CEST] <BtbN> The driver version nvenc needs differs between Windows and Linux, and I want to display the correct one in an error message.
[11:39:05 CEST] <nevcairiel> its probably fine using _WIN32 then
[11:39:36 CEST] <nevcairiel> did you consider making use of the probe function conditional if its present or something? it seems to dump up the requirement quite a bunch without real tangible improvement
[11:39:58 CEST] <BtbN> There is no capabilty to check if the driver version is sufficient for the used SDK header
[11:40:24 CEST] <BtbN> I'm not actually sure at which point it explodes if you use a too old driver, but I'm about to find out
[11:42:13 CEST] <BtbN> Or what do you mean by probe function conditional?
[11:42:23 CEST] <nevcairiel> the getcaps function
[11:42:30 CEST] <nevcairiel> it seems to be what mostly requires the very new driver
[11:43:21 CEST] <BtbN> oh, you mean NvEncodeAPIGetMaxSupportedVersion
[11:43:34 CEST] <BtbN> that was already there in SDK 7, I'm pretty sure
[11:44:13 CEST] <nevcairiel> i actually meant cuvidGetDecoderCaps in the decoder
[11:44:36 CEST] <BtbN> oh, that
[11:44:40 CEST] <BtbN> It's already using that
[11:44:49 CEST] <nevcairiel> i'm saying maybe it shouldnt
[11:45:02 CEST] <nevcairiel> or only if its actually present
[11:45:12 CEST] <nevcairiel> because that one call bumps up the driver versions way high
[11:45:26 CEST] <BtbN> Just using the newer header bumps the driver version
[11:45:34 CEST] <nevcairiel> not really
[11:46:22 CEST] <nevcairiel> older drivers seemed to just fail if you request P016 output, as far as i can tell, for example
[11:48:59 CEST] <BtbN> I'm pretty sure just loading all the functions will fail on an older driver
[11:49:09 CEST] <BtbN> it won't ever get to actually calling anything
[11:49:37 CEST] <nevcairiel> thats not the drivers fault, thats your codes doing - the only "new" function is the one i mentiooned above
[12:46:57 CEST] <BtbN> nevcairiel, https://github.com/BtbN/FFmpeg/commit/ff3084606c09911cdd3b6d6b588c47b9e71acea3 https://github.com/BtbN/FFmpeg/commit/f890a6d71286cd4602a778fc551df0b4d87bc39e seems to actually work on an old driver
[12:47:00 CEST] <BtbN> but might explode randomly
[13:02:37 CEST] <nevcairiel> if you wanted to be really safe you could just disable 10-bit entirely, since its technically part of the same SDK release
[13:22:31 CEST] <kiroma> Hey, where can I put a small feature request?
[13:25:34 CEST] <atomnuker> here
[13:26:49 CEST] <durandal_1707> kiroma: about what?
[13:28:01 CEST] <kiroma> Simply don't display error message about overwriting file if the output filename is "/dev/null" or "-pass 1" is specified.
[13:28:42 CEST] <kiroma> *and
[13:46:12 CEST] <wm4> does anyone know why h264_mp4toannexb_bsf specifically waits for IDRs before adding sps/pps?
[13:46:28 CEST] <wm4> couldn't it just dump all sps/pps at the beginning of the stream
[13:46:39 CEST] <nevcairiel> that would technically be invalid
[13:46:45 CEST] <nevcairiel> it should be before the IDR
[13:47:29 CEST] <wm4> no idea if I'm reading this right, but it seems to append _after_ the IDR (which confuses me additionally)
[13:47:48 CEST] <Compn> kiroma : sure, i can make a trac ticket for that if you dont want to
[13:48:50 CEST] <wm4> nevcairiel: or does your statement refer to my suggestion to dump sps/pps at the start of the stream
[13:48:54 CEST] <BBB> ubitux: ping
[13:49:14 CEST] <nevcairiel> wm4: that, but it should be before the IDR, otherwise it seems rather pointless
[13:49:53 CEST] <wm4> if you dump them at the start (before any other NALs), shouldn't the decoder parse and store them
[13:50:25 CEST] <nevcairiel> in practice perhaps, but the stream would still be possibly invalid
[13:50:46 CEST] <nevcairiel> that thing is not only used for our decoders but also for remuxing, in which case you want to make fully valid streams
[13:51:13 CEST] <wm4> so what's invalid about it? that they are not repeated?
[13:51:26 CEST] <nevcairiel> there is specs that say where it should go
[13:51:32 CEST] <nevcairiel> cant just randomly throw it everywhere
[13:51:33 CEST] <ubitux> BBB: pong
[13:51:47 CEST] <wm4> yeah, I'm trying to look
[13:52:17 CEST] <nevcairiel> the code talks about predening
[13:52:55 CEST] <nevcairiel> and it also seems to do that
[13:53:06 CEST] <wm4> oh I see now
[13:53:15 CEST] <nevcairiel> prepending*
[13:53:15 CEST] <wm4> blergh
[13:53:19 CEST] <nevcairiel> shouldnt just skip syllables
[13:53:57 CEST] <wm4> (reading libav's code helps lol)
[14:02:28 CEST] <kiroma> Compn: Sure, thanks.
[14:09:31 CEST] <Compn> kiroma : what ver ffmpeg are you using ?
[14:15:58 CEST] <kiroma> I'm building new versions every week or so using git pull
[14:16:39 CEST] <Compn> k
[14:17:03 CEST] <Compn> kiroma : http://trac.ffmpeg.org/ticket/6435#ticket
[14:21:11 CEST] <kiroma> I think it should still check if the filename already exists if "-pass 1" is specified, because then you could accidentally overwrite an existing video with an empty file.
[14:23:37 CEST] Action: Compn updates
[14:23:38 CEST] Action: Compn afk
[14:23:56 CEST] <Compn> and there goes my english capabilities
[14:24:04 CEST] <Compn> is devnull is specified :\
[14:52:33 CEST] <RiCON> has it ever been suggested to use @file/response file at least for the library linking commands?
[14:53:41 CEST] <DHE> are command-line lengths an issue?
[14:53:58 CEST] <RiCON> using a certain number of external libs and long enough paths is going over the 32767 limit on Windows
[14:55:53 CEST] <RiCON> example: http://sprunge.us/hiLh
[14:57:23 CEST] <RiCON> i workaround it by deduplicating -L and -l options, but the lib*/*.o options on their own take 22888 characters
[14:57:28 CEST] <nevcairiel> perhaps thats because it repeats the same library path 100 times? :D
[14:59:07 CEST] <RiCON> i'd suggest a fix for it, but makefile syntax looks like chinese
[15:00:14 CEST] <wm4> chinese is probably fairly simple compared to make
[15:01:24 CEST] <atomnuker> ^^the truth, m4 is alien level
[15:01:37 CEST] <nevcairiel> nothing in ffmpeg is m4
[15:01:43 CEST] <DHE> lib*/*? not using the libav*.a instead?
[15:01:58 CEST] <RiCON> that's for the shared libs
[15:02:17 CEST] <RiCON> the sprunge link, that is
[15:02:53 CEST] <RiCON> the static lib command is apparently shorter
[15:03:11 CEST] <nevcairiel> well it lacks all sorts of linking commands, only has object files
[15:16:28 CEST] <LA> hey. guys, please help me. why logging doesn't work on 64 bit ffmpeg? I set callback by av_log_set_callback, and it's ok on 32 bit, but with 64 bit I don't receive anything.
[15:44:44 CEST] <BtbN> Is the github mirror updated with a hook by now, or is it some cron job?
[16:09:42 CEST] <cone-477> ffmpeg 03Srinath K R 07master:d8da329cc364: avcodec/nvenc: Add default value for AVCodecContext::refs
[16:09:43 CEST] <cone-477> ffmpeg 03Timo Rothenpieler 07master:2d978d1c721a: configure: libnpp does not need to link libcuda
[16:09:44 CEST] <cone-477> ffmpeg 03Timo Rothenpieler 07master:cb3358b68fa7: avcodec/nvenc: print minimum driver version on error
[16:09:45 CEST] <cone-477> ffmpeg 03Timo Rothenpieler 07master:f890a6d71286: compat/cuda: make cuvidGetDecoderCaps optional
[16:09:46 CEST] <cone-477> ffmpeg 03Timo Rothenpieler 07master:ff3084606c09: avcodec/cuvid: make capability check optional
[16:13:43 CEST] <ubitux> is it legit to use checkasm to only bench the functions and not actually test them?
[16:15:07 CEST] <nevcairiel> if you can already call th em with some valid data, comparing that to the output of the C version seems trivial? :)
[16:18:41 CEST] <ubitux> depends if it's fuzzy floats :p
[16:19:44 CEST] <ubitux> oh we have a float_near_ulp_array thing
[16:22:40 CEST] <jamrial> ubitux: there's float_near_abs_eps as well. look at synth_filter.c for float tests
[16:23:12 CEST] <jamrial> also dcadsp.c, although that one is disabled in our tree
[16:26:07 CEST] <ubitux> oh "ulp" is some soft float thing?
[16:26:10 CEST] <ubitux> what does it stand for?
[16:36:45 CEST] <ubitux> ulp = "unit in the last place"?
[16:36:46 CEST] <jkqxz> <https://en.wikipedia.org/wiki/Unit_in_the_last_place>.  For this, it should be how many floating point numbers are between your two values.
[16:37:25 CEST] <jkqxz> The implementation there looks pretty dubious, though - it's going to say that 1.0 and 0.999999999... are very far apart.
[16:37:40 CEST] <ubitux> i wonder which i should use, arbitrary epsilon or ulp
[16:38:06 CEST] <ubitux> i guess i'll go for an epsilon with 0.0001
[16:38:17 CEST] <ubitux> float_near_abs_eps_array() seems not used
[16:38:31 CEST] <ubitux> float_near_ulp_array() has a few usages
[16:41:06 CEST] <jamrial> float_near_abs_eps_array() is not used because synth_filter wanted to print errors inside the loop, so it reimplemented it using  float_near_abs_eps() directly
[16:41:56 CEST] <jamrial> no, my bad, that was dcadsp.c
[16:44:23 CEST] <nevcairiel> jkqxz: how so, it uses the bitpattern in an int to compare, and 1.0 and 0.999999999 look very similar in that
[16:45:43 CEST] <nevcairiel> ie. 1.0 is 0x3f800000 and 0.9999999 is 0x3f7ffffe
[16:47:20 CEST] <nevcairiel> which is just a difference of 2 ulps
[16:47:21 CEST] <jkqxz> Hmm, right.  I was thinking that the mantissa was going to mess with it, but it doesn't for sensible numbers.  Only sign and infinities get you.
[16:47:50 CEST] <jkqxz> *exponent
[16:47:59 CEST] <nevcairiel> 0.0000001 and -0.0000001 would probably screw this over
[16:48:20 CEST] <nevcairiel> but inaccuary should generally not flip the sign
[16:48:34 CEST] <jkqxz> Subnormals already screw with that, there are a lot more numbers close to zero.
[16:50:12 CEST] <nevcairiel> anything close to zero will likely fail because the exponent also changes then
[16:50:18 CEST] <nevcairiel> or could change
[16:50:31 CEST] <nevcairiel> even without going into subnormal range
[16:51:39 CEST] <nevcairiel> could even encounter that at 0.1 vs 0.099
[18:09:27 CEST] <jamrial> oh, fuck this, it was fixed_dsp the test that was fucking with float_dsp
[18:09:45 CEST] <jamrial> because i was giving the same names to both in check_func()
[18:16:58 CEST] <cone-477> ffmpeg 03James Almer 07master:93dc1c122185: checkasm: add _fixed suffix to fixed_dsp tests
[18:38:04 CEST] <wm4> ffmpeg.c truly is a rotten piece of shit
[18:38:21 CEST] <wm4> it doesn't do packet refcounting correctly, instead it does absurd brainfucked shit
[18:38:27 CEST] <wm4> which cost me a few hours of shit
[18:48:13 CEST] <wm4> this shit is so bad
[19:01:52 CEST] <kierank> wm4: amen
[19:02:29 CEST] <wm4> and libav's API also goes on my nerves
[19:02:49 CEST] <wm4> why in heaven's fuck do you need to provide a "cleared" packet for the first ref in av_buffer_ref
[19:03:01 CEST] <wm4> why doesn't it either unref or completley erase that packet
[19:03:11 CEST] <wm4> s/erase/overwrite/
[19:46:51 CEST] <jamrial> Gramner: checkasm can't currently handle dsp functions that return a float value (instead of void or an int)
[19:46:59 CEST] <jamrial> it fails on x86_32 apparently because emms is always issued in call_ref/new()
[19:52:58 CEST] <Gramner> jamrial: did you use declare_func_emms?
[19:53:15 CEST] <jamrial> Gramner: yes, that still calls emms
[19:54:26 CEST] <Gramner> oh, it does
[19:54:47 CEST] <jamrial> Gramner: https://github.com/jamrial/FFmpeg/tree/floatdsp
[19:55:02 CEST] <jamrial> works on x86_64, fails on x86_32
[19:59:29 CEST] <Gramner> probably drop the emms instruction in checked_call I guess. although that may possibly break something else
[19:59:53 CEST] <Gramner> this is one of the reasons why I don't like mmx
[20:00:50 CEST] <jamrial> how about adding a new checked_call() func without the emms?
[20:02:25 CEST] <Gramner> jannau wrote the emms stuff in checkasm, maybe check with him if he thought about it. also I think the _emms suffix usage is kind of backwards
[20:02:40 CEST] <jamrial> removing the emms in checked_call() makes fifteen tests fail, so not an option :p
[20:04:59 CEST] <Gramner> adding another checked_call implementation for functions returning a float is a possibility. dunno if there's a cleaner way
[20:06:21 CEST] <Gramner> the 32-bit x86 calling convention for returning floating point values is stupid as fuck for requiring x87 in the first place but we just have to live with that
[20:36:07 CEST] <jamrial> Gramner: something like https://pastebin.com/Y1UUC0n7 ?
[21:11:28 CEST] <cone-477> ffmpeg 03Vittorio Giovara 07master:88521a753761: ffprobe: Print AVMasteringDisplayMetadata side data contents
[21:11:29 CEST] <cone-477> ffmpeg 03Vittorio Giovara 07master:2934a10f2ed3: ffprobe: Print AVContentLightMetadata side data contents
[21:26:44 CEST] <cone-477> ffmpeg 03Paul B Mahol 07master:dc72d1dde914: avfilter: add audio surround upmixer
[22:55:31 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07master:cd6f319a7470: avcodec/cfhd: Fix runtime error: signed integer overflow: 65280 * 65288 cannot be represented in type 'int'
[22:55:32 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07master:8b3e580b7f43: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int'
[22:55:33 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07master:adb4854aac17: avcodec/asvdec: Use rounded up dimenensions in input size check
[23:37:11 CEST] <Gramner> jamrial: yeah, I guess that would work
[23:37:48 CEST] <Gramner> only need it on 32-bit though since 64-bit returns it in xmm0
[23:38:34 CEST] <cone-477> ffmpeg 03Kevin Mark 07master:3385989b98be: libavfilter/scale2ref: Add constants for the primary input
[23:39:22 CEST] <kevmark> \o/
[23:43:31 CEST] <kevmark> Thanks for the merge Michael (if you're in here)
[23:43:52 CEST] <michaelni> np
[23:44:51 CEST] <kevmark> I believe this can be closed now https://trac.ffmpeg.org/ticket/5392
[23:57:19 CEST] <atomnuker> returning floats in xmm regs is probably one of the best ideas someone had
[23:57:48 CEST] <atomnuker> most of the time all you want to do is SPLAT them so they're ready for that
[23:58:21 CEST] <nevcairiel> amd64 uses xmm for all float operations, its not like the return register is a special case there
[23:58:27 CEST] <BBB> its one of those duh moments where once youve cosnidered it, you cant imagine ever having done anything else
[23:59:25 CEST] <BBB> kevmark: cehoyos will probably close it
[23:59:54 CEST] <nevcairiel> x87 is idling quietly on amd64 most of the time, you can probably still use it if you really wanted to?
[00:00:00 CEST] --- Fri Jun  2 2017