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

[burek]

[00:03:11 CEST] <cone-156> ffmpeg 03Andriy Gelman 07master:90e965be6d90: tools/zmqsend: Avoid mem copy past the end of input buffer
[00:03:11 CEST] <cone-156> ffmpeg 03Olivier Maignial 07master:c29d81e73641: avformat/rtpdec_mpeg4: Fix integer parameters size check in SDP fmtp line
[12:03:56 CEST] <roxlu> hey, someone around who knows a bit about vaapi and the intel-media-driver? The va.h describes that one can get the preferred pixel format for a surface by providing a `VASurfaceAttrib` with it's value set to 0. Though this doesn't return the preferred pixel format; it only tells me I should pass a larger attrib buffer. Then, the second call does give me a pixel format. 
[16:01:12 CEST] <durandal_1707> Lynne: do you know why mlpenc does strange pointer mappings and castings?
[16:03:39 CEST] <Lynne> like DecodingParams *seq_dp = (DecodingParams *) ctx->decoding_params+ ...
[16:03:51 CEST] <durandal_1707> yea
[16:05:01 CEST] <durandal_1707> cehoyos: i will revert your commit then from stereo3d filter
[16:05:04 CEST] <Lynne> probably leftovers, that code is old
[16:05:50 CEST] <durandal_1707> fix it properly
[16:56:52 CEST] <cehoyos> durandal_1707: Don't forget to also remove support for DUBOIS and SIDE_BY_SIDE
[16:57:22 CEST] <durandal_1707> why?
[16:59:18 CEST] <cehoyos> Or ask the authors
[17:00:07 CEST] <cehoyos> Some of them were not written by Reimar, Gordon Schmidt or Endre
[17:00:24 CEST] <cehoyos> (not all dubois, not all side_by_side)
[17:00:50 CEST] <durandal_1707> lies
[17:09:31 CEST] <cehoyos> Lies?
[17:09:40 CEST] <cehoyos> Not sure I understand.
[17:37:01 CEST] <ramiro> durandal_1707: 10+ years old code, and not finished during the original gsoc. i remember thinking those casts would end up being a good thing, but now I can't even understand what they do anymore.
[17:37:37 CEST] <durandal_1707> lol
[17:53:39 CEST] <J_Darnley> Maybe they are casts c++ would require?
[17:57:04 CEST] <durandal_1707> see math after cast...
[18:40:21 CEST] <vel0city> michaelni: Regarding the huffman codes change, did you have a specific workaround for just the sym==0 case in mind?
[18:41:51 CEST] <michaelni> well, i was thinking of just setting that one to 0 and just checking that one, if that works
[18:42:12 CEST] <vel0city> ah gotcha
[19:02:32 CEST] <vel0city> michaelni: I'm building under WSL so I can't use ffplay. I tried decoding the image you mentioned (to a .png) and it worked fine. Is there another way for me to try and repro?
[19:03:56 CEST] <Lynne> vel0city: btw there is a gamma metadata (that png exports) to let anyone rendering know the gamma
[19:04:13 CEST] <Lynne> do you think it could be used instead of doing that in the decoder?
[19:04:41 CEST] <Lynne> mpv will read the gamma and use it, afaik
[19:04:53 CEST] <vel0city> Lynne: but that's png-specific
[19:06:25 CEST] <vel0city> you mean that there's some generic "color space" property that I can set from the decoder?
[19:06:27 CEST] <durandal_1707> check that white level is not same as black level
[19:06:50 CEST] <vel0city> durandal_1707: hm true
[19:07:13 CEST] <durandal_1707> this gamma is custom always thing 
[19:07:42 CEST] <durandal_1707> there is no way to export it
[19:08:43 CEST] <Lynne> vel0city: no, its not specific, its just a metadata string
[19:09:53 CEST] <durandal_1707> there is other stuff done after gamma, making stuff imposible to be done
[19:18:04 CEST] <Rathann> hi
[19:18:23 CEST] <Rathann> I've just noticed that libavresample was deprecated back in 4.0 release
[19:18:31 CEST] <Rathann> when is it going to be removed?
[19:18:49 CEST] <Rathann> in 5.0?
[19:18:59 CEST] <nevcairiel> typically at leas 2 years after the deprecation
[19:19:38 CEST] <Rathann> ok, thanks
[19:20:04 CEST] <nevcairiel> so possibly next year. We recommend migrating to swresample instead, the API is even quite similar
[19:22:04 CEST] <Rathann> yes, I saw the work some downstream consumer did to switch
[19:23:07 CEST] <Rathann> I co-maintain ffmpeg package in RPM Fusion and I've just gone over the remaining consumers and filed bugs against them
[19:23:19 CEST] <Rathann> and came here to ask about the timeline they have ;)
[19:28:10 CEST] <J_Darnley> Even if we remove it in master, won't it stick around in 4.0 and any other release it is in?
[19:29:24 CEST] <Rathann> it's still there in 4.2, sure
[19:32:27 CEST] <Rathann> but we (RPM Fusion/Fedora) usually try to keep just one latest version of any library in a given distribution release, so when FFmpeg stops providing libavresample in (I guess) 5.0, the dependent packages which still require it will break
[19:32:45 CEST] <Rathann> so it's better start poking the maintainers in advance
[19:34:27 CEST] <Rathann> about half of the packages depending on libavresample that we have in RPM Fusion for Fedora 29 are already ported to libswresample already
[21:41:31 CEST] <durandal_1707> why am i not allowed to part of security team?
[21:42:11 CEST] <kierank> durandal_1707: because you do not comply with secret procedure
[21:44:36 CEST] <durandal_1707> what is needed to be part of security team? competency in what?
[21:44:54 CEST] <kierank> Who knows
[21:45:04 CEST] <kierank> Competence in muddying water I think
[21:45:08 CEST] <kierank> And blocking change
[21:46:35 CEST] <durandal_1707> blocking change is more to do with certain dev certainly not in security team
[21:49:52 CEST] <durandal_1707> irc logs are still broken, i wonder why
[22:04:24 CEST] <Lynne> thinking about it, even if dolby weren't dobly, I still don't think opus stood any chance of being considered for object based audio
[22:05:14 CEST] <Lynne> because otherwise it would have had a decent system for signalling layout rather than the vorbis-like family mapping it got
[22:05:53 CEST] <durandal_1707> patents matters also standards
[22:06:38 CEST] <Lynne> patents matter most for that, usability is second, but at least someone working on ac4 thought of how channels should be signalled
[22:07:05 CEST] <Lynne> and the spec says how, opus doesn't even say a word on mapping in the rfc
[22:07:35 CEST] <durandal_1707> why you inspect ac4?
[23:28:37 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:57987deefcdc: lavc/libx264: bit_rates > INT_MAX are not supported.
[23:34:20 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:4b1687f23c13: lavc/libx264: Cast bit_rate to int64_t to avoid an integer overflow.
[23:34:21 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:67114195694d: lavf/dump: Fix vbv_delay type specifier.
[23:50:46 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:098ed8a73e68: lavf/dump: Fix cpb bitrate type after next major bump.
[23:55:26 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:690cab32326e: lavc/libx264: Cast cpb bit_rates to int64_t to avoid an integer overflow.
[23:59:42 CEST] <jgb> who do i have to beg if i want to get this fixed: https://trac.ffmpeg.org/ticket/7912
[00:00:01 CEST] --- Sun Aug 11 2019