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

burek burek021 at gmail.com
Wed Dec 7 03:05:03 EET 2016


[00:04:45 CET] <cone-511> ffmpeg 03Mathieu Velten 07n3.0.5:HEAD: avcodec/vaapi-vp9: add support for profile 2 (bpp > 8)
[00:05:58 CET] <cone-511> ffmpeg 03James Almer 07master:9c1ccee7f840: avformat/dump: remove line break on mastering display metadata info dump
[00:27:35 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:c165bad0c073: avformat/utils: Fix type mismatch
[00:27:36 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:2d51cb1d0ad9: avcodec/me_cmp: Fix median_sad size
[00:27:37 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:8e4f737d2f25: avformat/idroqdec: Check chunk_size for being too large
[00:27:38 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:2fb7eb05dcac: avcodec/flac_parser: Update nb_headers_buffered
[00:27:39 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:a0ed412f38f5: avformat/utils: Check start/end before computing duration in update_stream_timings()
[00:27:40 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:a0715c1e897f: avformat/oggparsespeex: Check frames_per_packet and packet_size
[00:27:41 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:c39e8d05f587: avcodec/flacdsp_template: Fix undefined shift in flac_decorrelate_indep_c
[00:27:42 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:a772aaf5dc76: avcodec/flacdec: Fix signed integer overflow in decode_subframe_fixed()
[00:27:43 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:bbe9a4b54263: avformat/ffmdec: Check media type for chunks
[00:27:44 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:334901aea0e3: avcodec/get_bits: Fix get_sbits_long(0)
[00:27:45 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:af1e19b9e4d6: avcodec/flacdec: Fix undefined shift in decode_subframe()
[00:27:46 CET] <cone-511> ffmpeg 03Timothy Gu 07release/3.2:f66bfe71bbca: zmqsend: Initialize ret to 0
[00:27:47 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:32b95471a86a: avformat/rtmppkt: Check for packet size mismatches
[00:27:48 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:46cd1699f956: Avoid using the term "file" and prefer "url" in some docs and comments
[00:27:49 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:c12ee64e80af: ffserver: Check chunk size
[00:27:50 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.2:148c4fb8d203: Update for 3.2.2
[00:56:12 CET] <cone-511> ffmpeg 03James Almer 07n3.2.2:HEAD: avformat/dump: remove line break on mastering display metadata info dump
[01:18:09 CET] <michaelni> BBB, the http backport to 2.8 has a bug i think there are 2 "s->chunksize < 0" in there but chunksize is unsigned
[01:20:55 CET] <cone-511> ffmpeg 03Timothy Gu 07release/2.8:c472c1b3e7c0: zmqsend: Initialize ret to 0
[01:20:56 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/2.8:5bfb0b02b6fb: avformat/rtmppkt: Check for packet size mismatches
[01:20:57 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/2.8:15abba737bff: Avoid using the term "file" and prefer "url" in some docs and comments
[01:20:58 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/2.8:e0cb113f9b4b: ffserver: Check chunk size
[01:20:59 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/2.8:4a947f43850a: Changelog: fix typos
[01:29:50 CET] <BBB> michaelni: feel free to remove them, I didnt really check very closely, theyre just removed in later versions so if you ignore their existence (which a compiler will, with a warning), its probably ok
[01:41:46 CET] <michaelni> BBB, in 3.0 you replaced them with == UINT64_MAX
[01:42:13 CET] <BBB> I dont remember
[01:42:35 CET] <BBB> I guess Im no good at backporting
[03:48:35 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/2.8:1ec9fd15b9c1: avformat/http: Match chunksize checks to master..3.0
[03:51:45 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/2.8:16c0d8aa46b6: update for ffmpeg 2.8.10
[04:07:00 CET] <cone-511> ffmpeg 03James Almer 07n2.8.10:HEAD: avformat/dump: remove line break on mastering display metadata info dump
[13:39:45 CET] <wm4> so on OSX, VTDecompressionSessionCreate sometimes mysteriously fails with some files
[13:40:04 CET] <wm4> it returns kVTVideoDecoderNotAvailableNowErr, but I'm pretty sure that's a lie, because with other files it works
[13:41:49 CET] <BtbN> Well, it's only not available now. Didn't say anything about in 10 seconds!
[13:42:01 CET] <ritsuka> maybe it doesn't support some h.264 profiles/levels? (if you are decoding h.264)
[13:42:53 CET] <wm4> both used the h264 high profile
[13:43:11 CET] <ritsuka> 8bit or 10bit? which level?
[13:43:18 CET] <rcombs> high profile is 8-bit
[16:43:57 CET] <cone-485> ffmpeg 03Michael Niedermayer 07master:108db37586e4: tests/api/api-seek-test: Fix use of uinitialized value
[16:43:58 CET] <cone-485> ffmpeg 03Michael Niedermayer 07master:5952b8da0b7f: tests/api/api-seek-test: Silence compiler warnings about uninitialized variables
[16:43:59 CET] <cone-485> ffmpeg 03Michael Niedermayer 07master:7679c38b3b57: tests/api/api-seek-test: check all compute_crc_of_packets() calls
[17:00:03 CET] <wm4> merges are dead now, huh
[17:31:10 CET] <nevcairiel> work and life keeps me busy right now
[17:50:43 CET] <cone-485> ffmpeg 03Thomas Turner 07master:da3c69a5a97d: Added test for libavcodec/avpacket.c
[19:24:18 CET] <durandal_1707> kierank: do you translate machine instructions by hand?
[19:29:29 CET] <fritsch> wm4: cabac different between does that work and don't work?
[19:30:04 CET] <wm4> hm can check
[19:30:43 CET] <fritsch> which "real" device is running under that API?
[19:30:49 CET] <fritsch> some AMD gpu? intel?
[19:32:19 CET] <wm4> Intel
[19:33:11 CET] <nevcairiel> how much does it even know about the stream when you call that function?
[19:33:18 CET] <nevcairiel> most other HW APIs no jack shit at such a point
[19:33:26 CET] <nevcairiel> but of course Apple APIs are always different :D
[19:34:07 CET] <wm4> not too much... just sps and pps and the data it's passed to
[19:34:15 CET] <wm4> ...I think
[19:34:40 CET] <nevcairiel> I mean, with dxva or vaapi or such you tell it the dimensions, and at tbest the profile/level
[19:35:12 CET] <fritsch> yeah, can you dump mediainfo
[19:35:14 CET] <fritsch> on both
[19:35:19 CET] <fritsch> perhaps it jumps directly out
[19:35:27 CET] <fritsch> which flag it does not like
[19:36:05 CET] <fritsch> did you recalculate the level that file states?
[19:36:18 CET] <fritsch> there are a lot of 4.1 at high out there with too many reframes
[19:36:49 CET] <nevcairiel> that would be silly to fail, especially if the hardware actually supports 5.1
[19:36:53 CET] <nevcairiel> which all modern ones do
[19:37:04 CET] <fritsch> always remembers me on amd
[19:37:12 CET] <fritsch> even radeon oss always assumes 5.1 level
[19:37:14 CET] <fritsch> cause of that
[19:39:37 CET] <nevcairiel> amd is one of the last to actually support full 5.1 though
[19:39:45 CET] <nevcairiel> took them ages to get 4k working
[19:39:49 CET] <fritsch> hehe
[19:40:05 CET] <fritsch> there was a problem
[19:40:10 CET] <fritsch> with the "first 256 MB"
[19:40:16 CET] <fritsch> that they needed to use for their UVD
[19:40:26 CET] <fritsch> and was hard to fit 4k stuff into that range
[19:40:37 CET] <nevcairiel> is that the one where they advertised 4k support and half the image turned out green?
[19:40:44 CET] <fritsch> hehe, no idea
[19:40:55 CET] <fritsch> i talked to ckoenig the amd oss dev back at that time
[19:41:00 CET] <fritsch> and he explained that
[19:41:03 CET] <fritsch> 2048x1152
[19:41:16 CET] <fritsch> was max h264 and with "special hack" level 5.1
[19:41:34 CET] <fritsch> http://www.phoronix.com/image-viewer.php?id=amd_xvba_xbmc&image=amd_xbmcxvba_9_lrg
[19:41:45 CET] <nevcairiel> with the 7000 series of cards the advertised 4k support and enabled it in the drivers, but it was shortly after revealed that it only managed to decode about half the frame
[19:41:49 CET] <fritsch> here, that was before I found "the hack" to convince the chip to do 5.1 at high
[19:41:52 CET] <nevcairiel> amd turned it off in the drivers again a bit later
[19:44:03 CET] <fritsch> the funny thing was that the switch to enable 51 was readable via strings
[19:44:07 CET] <fritsch> inthe XVBA shared object
[19:46:16 CET] <fritsch> HWUVD_H264Level51Support=V1
[19:46:21 CET] <fritsch> that was hidden in the linux blob driver
[19:46:37 CET] <fritsch> cause only available for some manufacturer that paid amd back at that time
[20:19:45 CET] Action: wm4 starts at brew failing to compile mediainfo
[20:30:04 CET] <wm4> fritsch: http://sprunge.us/jMDI 
[21:09:02 CET] <cone-485> ffmpeg 03Georgi D. Sotirov 07master:581f93f37ef2: lavf/chromaprint: Update for version 1.4
[21:15:13 CET] <wm4> nice, cehoyos applying a patch even though another dev still had doubts about it
[21:15:39 CET] <wm4> I guess I don't need to respect cehoyos' doubts either!
[21:17:04 CET] <wm4> also demanding from the patch author to use git format-patch, even though he himself refused to do this for years and only recently started to use it
[21:17:45 CET] <nevcairiel> he demanded that even w hen he didnt
[21:31:03 CET] <Timothy_Gu> Bug #6000!
[21:59:00 CET] <durandal_1707> wm4: the patch was reversed..
[22:01:59 CET] <wm4> oh, wtf
[22:02:18 CET] <RiCON> wtf
[22:06:27 CET] <jamrial> what carl committed was probably the actual intention of the patch
[22:07:18 CET] <J_Darnley> Carl's crystal ball must have been working.
[22:07:38 CET] <jamrial> git log chromaprint.c shows the initial commit and the codecpar port only
[22:07:52 CET] <durandal_1707> sometimes...
[22:07:55 CET] <jamrial> that "CPR_VERSION_INT >= AV_VERSION_INT(1, 4, 0)" check was never in the file
[22:08:26 CET] <J_Darnley> The submitter must have had his args to diff backwards
[22:08:35 CET] <jamrial> yeah
[22:08:50 CET] <durandal_1707> I don't have that library enabled so can't confirm it works
[22:09:08 CET] <wm4> jamrial: I was actually trying to check when that was added
[22:09:12 CET] <wm4> but found it nowhere lol
[22:10:06 CET] <wm4> definitely would have called for more reviews, instead of just pushing some guessed approximation
[22:22:26 CET] <cone-485> ffmpeg 03Timothy Gu 07master:16a75304fe42: omx: Fix OOM check
[22:22:27 CET] <cone-485> ffmpeg 03Timothy Gu 07master:b6f80b16d1a8: qsvdec: Fix memory leak
[23:00:52 CET] <Timothy_Gu> The cehoyos patch looks completely wrong
[23:01:26 CET] <Timothy_Gu> The ChromaprintContext structure seems to have been public for a while now
[23:01:40 CET] <Timothy_Gu> *have NOT been public
[23:02:31 CET] <Timothy_Gu> never mind something is odd
[23:07:42 CET] <rcombs> it's super weird
[23:08:05 CET] <rcombs> ChromaprintContext used to be void*
[23:08:25 CET] <rcombs> but the functions all returned ChromaprintContext*
[23:08:27 CET] <rcombs> i.e. void**
[23:08:47 CET] <rcombs> but void* and void** are compatible types and generally can be implicitly converted to one another without warnings
[23:08:54 CET] <rcombs> (returned, and took as arguments)
[23:09:28 CET] <rcombs> I think I originally read the header and saw it was void* and assumed I should use ChromaprintContext (as opposed to ChromaprintContext*)
[23:09:52 CET] <rcombs> in newer versions it's typedef'd to an incomplete struct type, so you need ChromaprintContext*
[23:09:59 CET] <rcombs> afaik that should also work in older versions
[00:00:00 CET] --- Wed Dec  7 2016


More information about the Ffmpeg-devel-irc mailing list