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

[burek]

[00:00:18 CET] <jamrial> valgrind says process_input() in ffmpeg.c:4419 freed it
[00:03:44 CET] <jamrial> how the hell did it work on windows, i don't know
[00:17:27 CET] <michaelni> jkqxz, your patch seems working
[00:24:01 CET] <cone-260> ffmpeg 03Aman Gupta 07master:05d77587cb7d: lavc/videotoolbox: fix out-of-bounds memory access during hvcc creation
[00:35:28 CET] <cone-260> ffmpeg 03James Almer 07master:7a02b364b68c: avcodec/vp9_superframe_bsf: cache packets by creating new references rather than moving them
[00:35:42 CET] <jamrial> BBB: ^
[01:05:07 CET] <cone-260> ffmpeg 03Carl Eugen Hoyos 07master:ff994c2aaa0a: lswr/rematrix: Support s32p.
[01:47:41 CET] <BBB> jamrial: sorry, back
[01:47:47 CET] <BBB> jamrial: had to go trick-or-treating with the kids
[01:48:23 CET] <jamrial> BBB: figured that was the case, don't worry :p
[01:48:36 CET] <BBB> ty
[01:48:51 CET] <BBB> so, does ffmpeg always unref it?
[01:48:55 CET] <BBB> or is that only in an error condition?
[01:49:01 CET] <BBB> (ffmpeg=ffmpeg.c)
[01:49:46 CET] <jamrial> in this case, the filter returned EAGAIN after buffering the packet
[01:50:39 CET] <jamrial> but yeah, ffmpeg.c probably unrefs it since it's considered already consumed
[01:50:57 CET] <jkqxz> jamrial:  <http://sprunge.us/QdaT>
[01:51:18 CET] <jamrial> so "moving" the ref was not a good idea
[01:51:28 CET] <BBB> jamrial: so do other filters use move_ref?
[01:51:35 CET] <BBB> vp9_superframe_bsf_split seems to use move_ref
[01:51:51 CET] <jamrial> BBB: all filters do for pass through
[01:52:06 CET] <jamrial> but it's moved to out, and not some internal buffer
[01:52:15 CET] <BBB> so if ffmpeg unrefs, how does that work?
[01:52:25 CET] <BBB> shouldnt that crash because in was unrefed twice?
[01:52:45 CET] <BBB> anyway if move->ref fixes it w/o memleaks, its obviously ok with me
[01:52:49 CET] <BBB>  just dont get it
[01:56:17 CET] <BBB> src/libavfilter/x86/af_afir.asm:22: fatal: unable to open include file `libavutil/x86/x86util.asm'
[01:56:20 CET] <BBB> is that something new?
[01:56:36 CET] <BBB> all freebsd things fail compiling with that
[02:04:56 CET] <jamrial> BBB: yeah, seems to be a problem with nasm
[02:09:16 CET] <BBB> oh right I saw that when I tried nasm
[02:09:24 CET] <BBB> I think it was an older version though
[02:09:29 CET] <BBB> I went back to yasm and it works fine now
[02:11:33 CET] <cone-260> ffmpeg 03Kaustubh Raste 07master:6854dd70391f: avcodec/mips: Improve hevc bi weighted copy, hz and vt mc msa functions
[02:11:34 CET] <cone-260> ffmpeg 03Kaustubh Raste 07master:e39c0f29a17f: avcodec/mips: Improve hevc bi hz and hv mc msa functions
[02:11:35 CET] <cone-260> ffmpeg 03Kaustubh Raste 07master:a21162697882: avcodec/mips: Improve hevc uni vt and hv mc msa functions
[02:11:36 CET] <cone-260> ffmpeg 03Jun Zhao 07master:fdfc51766d28: examples/transcoding: suppress build warning.
[02:11:37 CET] <cone-260> ffmpeg 03Jun Zhao 07master:cb6e20f8de12: examples/filtering_video: suppress the build warning.
[02:11:38 CET] <cone-260> ffmpeg 03Jun Zhao 07master:5c51d0edd4f3: examples/filtering_audio: suppress the build warning.
[02:14:56 CET] <jamrial> jkqxz: lgtm, thanks
[03:08:27 CET] <cone-260> ffmpeg 03Carl Eugen Hoyos 07master:17806f6083c8: lavu/murmur3: Enforce usual function attribute order.
[09:51:31 CET] <cone-573> ffmpeg 03Moritz Barsnick 07master:a0560d047754: avfilter/vf_ocr: check ff_set_common_formats() return value
[10:53:26 CET] <durandal_1707> why configure takes ages now?
[10:53:50 CET] <sfan5> it always took ages for me
[10:54:51 CET] <JEEB> durandal_1707: proper dependency checking
[10:55:04 CET] <JEEB> that's why some people are hoping it will no longer be in shell at some point :P
[10:55:30 CET] <durandal_1707> what?
[12:43:27 CET] <FernetMenta> hi, after upgrade of ffmpeg to 3.4 we (kodi) observe video corruption after seek, affected is vdpau and vaapi
[12:43:37 CET] <FernetMenta> any idea where to look at?
[12:44:47 CET] <FernetMenta> seems avcodec_flush_buffers does not flush the decoder completely
[13:11:09 CET] <iive> FernetMenta: could you try the current git? There was another issue related to draining packet/frames.
[13:12:45 CET] <FernetMenta> would you have the sha of the commit? cherry-picking would be faster, or does it not apply to 3.4 branch?
[13:40:18 CET] <FernetMenta> iive: I tried current master, same problem
[13:46:30 CET] <cone-975> ffmpeg 03Carl Eugen Hoyos 07master:f6b9e365cd48: lavc/ppc/svq1enc_altivec: Fix function prototype after dad31083.
[14:04:43 CET] <BtbN> Is kodi still using the old decode/encode API?
[14:12:39 CET] <iive> mplayer definitely still uses the oldest api that didn't get removed and I don't see video corruption after seeking.
[14:13:01 CET] <iive> so it is something tricky...
[14:17:33 CET] <cone-975> ffmpeg 03Carl Eugen Hoyos 07master:40d635e8c330: lavc/ppc/h264dsp: Fix function prototype after bc26fe89.
[14:21:37 CET] <FernetMenta> BtbN kodi uses new APIs
[14:22:16 CET] <BtbN> I remember mpv also running into issues with seeking recently
[14:24:13 CET] <FernetMenta> kodi sets get_buffer2, I log the buffers ffmpeg request, on avcodec_flush_buffers one buffer is not unrefed
[14:24:25 CET] <FernetMenta> this one comes back some time later
[15:38:15 CET] <FernetMenta> strange, kodi has an AVFrame parameter to hold the the frame received from decoder. if this parameter is not unreferenced, we get video corruption
[15:44:21 CET] <nevcairiel> hardware or software decoding?
[15:44:59 CET] <nevcairiel> i dont see how software might care, but hardware can be peculiar
[15:45:05 CET] <FernetMenta> vapau and vaapi, sw and vtb are ok
[15:51:52 CET] <jamrial_> rcombs: ping
[15:52:13 CET] <rcombs> jamrial_: pong
[15:53:12 CET] <jamrial> rcombs: does the autobsf patch i sent yesterday look ok for you?
[15:54:05 CET] <rcombs> this one? https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218908.html
[15:54:24 CET] <jamrial> yeah
[15:54:43 CET] <rcombs> yeah looks reasonable
[15:55:09 CET] <jamrial> ok, thanks
[15:55:25 CET] <rcombs> so I guess the packet just gets dropped
[15:56:56 CET] <rcombs> sorta wish lavf muxers had a way of reporting non-fatal errors
[15:57:12 CET] <cone-975> ffmpeg 03James Almer 07master:502050cb4ca7: avformat/movenc: let avpriv_ac3_parse_header() allocate the AC3HeaderInfo struct
[15:57:13 CET] <cone-975> ffmpeg 03James Almer 07master:e70cdf91a7bc: avformat/mux: be less strict with bitstream filter failures
[16:46:48 CET] <jya> setting CONFIG_SMALL to 1, how much performance hit can be expected? I see that it removes introducing lots of strings in the code, but also use  less efficient methods (not using pre-calculated tables) and so forth. 
[16:47:12 CET] <jya> too bad the choice can't be made of removing useless / unused strings, while keeping faster code
[16:48:32 CET] <jamrial> jya: some modules are slower, like most hashing algorithms that don't unroll loops to reduce binary size
[16:52:28 CET] <jya> jamrial: thanks, have there been benchmarks in regards to performance though?
[16:52:37 CET] <jya> trying to find the best compromise
[16:53:11 CET] <jya> seems that I would achieve a combination of the two by only changing the NULL_IF_CONFIG_SMALL macro
[17:02:25 CET] <jamrial> i don't know, to be honest. it's a rarely used option and most new code doesn't even seem to take it into consideration
[17:56:37 CET] <cone-975> ffmpeg 03Luca Barbato 07master:16cb06bb3039: hlsenc: Support recovery from an already present playlist
[17:56:38 CET] <cone-975> ffmpeg 03Martin Storsjö 07master:4d444d04c1e1: configure: Default to _WIN32_WINNT=0x0502 (XP) as minimum, for legacy mingw
[17:56:39 CET] <cone-975> ffmpeg 03James Almer 07master:7c9b469a6b24: Merge commit '16cb06bb30390c3d74312fc6aead818e19bfd8e4'
[17:56:40 CET] <cone-975> ffmpeg 03James Almer 07master:9c2f47715106: Merge commit '4d444d04c1e19cd02ac836d411433906a9f32613'
[17:56:41 CET] <cone-975> ffmpeg 03James Almer 07master:4b97435566dc: doc/libav-merge: mention skipped hlsenc commit
[18:06:19 CET] <cone-975> ffmpeg 03Martin Storsjö 07master:2ca759657bcd: os_support: Remove the dynamic loading of getaddrinfo from the fallback getaddrinfo
[18:06:20 CET] <cone-975> ffmpeg 03James Almer 07master:b5e2974b64e5: Merge commit '2ca759657bcda328acc312e5882a940333a3e268'
[18:09:16 CET] <cone-975> ffmpeg 03Michael Niedermayer 07master:b98f082d8ddc: smacker: Check that the data size is a multiple of a sample vector
[18:09:17 CET] <cone-975> ffmpeg 03James Almer 07master:a33a15751e27: Merge commit 'b98f082d8ddc0a0d8317114d8414ab51de60ef02'
[18:26:39 CET] <cone-975> ffmpeg 03Diego Biurrun 07master:5edded9df31b: smacker: Improve error handling
[18:26:40 CET] <cone-975> ffmpeg 03James Almer 07master:bc98788dd262: Merge commit '5edded9df31bc4712a023f89941b4c278f1bd6f5'
[18:57:44 CET] <atomnuker> is there some pixel format which describes planar 8 bit pixels with 8 bits of padding in between?
[18:58:48 CET] <durandal_1707> in between what?
[18:59:20 CET] <atomnuker> each pixel
[19:00:03 CET] <atomnuker> so the memory layout of YUV444P10 but with 8 bit values
[19:01:59 CET] <durandal_1707> no
[19:02:12 CET] <durandal_1707> why you need that?
[19:05:59 CET] <kierank> huh
[19:06:12 CET] <kierank> strange memory layout, no?
[19:06:20 CET] <atomnuker> ffv2/daala, all coefficients and filters need 32 bits
[19:06:47 CET] <atomnuker> so I'd need to do a memcpy for 8 bit output
[19:07:13 CET] <kierank> you handle this in the asm, no?
[19:07:25 CET] <kierank> to output 8-bit
[19:14:31 CET] <nevcairiel> this would be a rather peculiar and special pixel format, better to just transform it, otherwise everyone will have to anyway
[19:14:50 CET] <atomnuker> I could just make it 10-bit and 12-bit out only
[19:15:20 CET] <atomnuker> (its already 444 and RGB only because I want to experiment with CFL resynthesis for 420)
[19:16:05 CET] <nevcairiel> imo a lossless codec that cant represent the original exactly isnt worth the title lossless =p
[19:16:49 CET] <atomnuker> FFV1 doesn't work for YUV410 either :)
[19:17:02 CET] <nevcairiel> 410 is rather obscure tho
[19:17:07 CET] <nevcairiel> 420 is like 99% of all media
[19:18:58 CET] <durandal_1707> bad design
[19:19:18 CET] <atomnuker> you could disable CFL resynthesis for subsampled and put a perfect reconstruction upsample -> downsample filter
[19:19:23 CET] <atomnuker> (for lossless mode only)
[19:19:53 CET] <durandal_1707> whats your goal?
[19:19:53 CET] <atomnuker> lossy would still upscale it and use resynthesis and output 444
[19:21:34 CET] <atomnuker> durandal_1707: proving subsampling doesn't make sense with cfl
[19:21:51 CET] <atomnuker> kinda like what 8 vs 10 bit h264 video
[19:22:20 CET] <durandal_1707> subsampling is so old tech
[19:22:41 CET] <nevcairiel> there is other concerns then just compressed bitstream size tho, like memory bandwidth of uncompressed images
[19:25:01 CET] <atomnuker> its the 21st century, all computers ought to handle a 50% increase in uncompressed bandwith
[19:25:29 CET] <atomnuker> (for a given increase in compression)
[19:28:10 CET] <durandal_1707> what about bandwidth?
[19:28:30 CET] <atomnuker> what bandwith?
[19:28:52 CET] <durandal_1707> how much does it compress?
[19:29:32 CET] <atomnuker> the word is compression then
[19:30:16 CET] <atomnuker> and yeah, the plan is to see how high it can get first
[19:31:46 CET] <atomnuker> you know, for all the crap that decoder got its actually been quite useful for me
[19:32:00 CET] <durandal_1707> atomnuker: compression of I and P frames
[19:32:33 CET] <durandal_1707> rstio to uncompressed for various type of source
[19:32:43 CET] <durandal_1707> *ratio
[19:32:59 CET] <atomnuker> dunno lol, it'll take me years to answer that question, I just started writing it
[19:35:18 CET] <kierank> #6797 is why we shoudln't have a psd decoderf
[19:35:24 CET] <kierank> we'll end up having to support all the shit
[19:39:20 CET] <durandal_1707> whats color mode 4?
[19:39:33 CET] <JEEB> kierank: I was going to mention :D
[19:39:54 CET] <JEEB> there was some implementation where the documentation header basically sweared all over the PSD format
[19:43:00 CET] <marsrover> hi. is nvidia cuvid supposed to be a replacement for vdpau?
[19:44:12 CET] <JEEB> I don't think we have a person inside nvidia here, but at least it seems like only CUVID has 10bit support - although they've said they might be adding it to VDPAU as well
[19:45:54 CET] <marsrover> im trying to figure out what the difference between the two is aside of 10bit. it seems like cuvid is like vdpau2 or something from what i read but its not clear to me
[19:49:31 CET] <atomnuker> kierank: the psd decoder is honestly great, I regret even saying it was initially going to be a mess
[19:49:40 CET] <kierank> really?!
[19:50:08 CET] <JEEB> I guess it's OK to get the raw version?
[19:50:18 CET] <JEEB> if the file has one (I think thumbnails?)
[19:50:20 CET] <atomnuker> yeah, its not messy, its not big and it decoded a lot of what I threw at it
[19:51:41 CET] <lrusak> jkqxz: hello, I have some question regarding drm prime and integration with v4l2 m2m
[19:52:42 CET] <lrusak> I've spoken to LongChair the author of the rockchip work and he has told me a bit about how the drmprime format works
[19:53:18 CET] <lrusak> I'm just a little bit confused about how to use this for v4l2
[19:54:48 CET] <marsrover> if all i need to do is playback audio/video files, live dvb streams, and i use vdpau for video + alsa for audio, its safe to disable all filters right? any scaling/deinterlace/etc is done in vdpau for video, and i dont touch audio at all... ??
[19:57:21 CET] <lrusak> I think we can export the buffer from v4l2 and allocate a drm prime format and then set the drmframedescriptor information with the exported fd
[20:10:24 CET] <atomnuker> kierank: do you know if movie blu-rays which use MPEG2 use interlacing?
[20:11:02 CET] <kierank> Theoretically yes
[20:11:10 CET] <kierank> Not sure any exist
[20:11:34 CET] <JEEB> I have samples of one
[20:11:38 CET] <atomnuker> I found one, I'll tell you in 20 hours when it completes
[20:12:03 CET] <JEEB> or actually I think two
[20:12:22 CET] <JEEB> AIR and underwater ray romano
[20:12:49 CET] <atomnuker> would be interesting to know if non-interlaced mpeg2 was a thing
[20:14:46 CET] <JEEB> yes
[20:14:56 CET] <JEEB> the spec lets you do progressive_sequence=1
[20:15:03 CET] <JEEB> with 24/1.001 and 24
[20:15:13 CET] <JEEB> (and a few others in 720p mode)
[20:15:38 CET] <atomnuker> only 720p?
[20:15:48 CET] <JEEB> the first two are in 1080p
[20:17:37 CET] <nevcairiel> I have full progressive mpeg2 Blu-rays in 1080p
[20:19:39 CET] <jamrial> from like 2008, right? :p
[20:20:31 CET] <jamrial> mpeg2 in blu ray was mostly used back when the war with hd-dvd was still ongoing
[20:21:23 CET] <marsrover> atomnuker - pal sd dvb-s is mostly progressive mpeg2 iirc
[20:22:43 CET] <JEEB> ...
[20:22:47 CET] <nevcairiel> dunno when the discs came out, but I have 9 movies in my library ranging from '96 to '06 (movie release years)
[20:22:48 CET] <JEEB> progressive in my broadcast?
[20:23:10 CET] <nevcairiel> we have some 720p50 progressive mpeg2 broadcasts here
[20:23:19 CET] <JEEB> wow
[20:23:22 CET] <JEEB> sanity!
[20:23:23 CET] <nevcairiel> over DVB-T/C
[20:23:50 CET] <nevcairiel> the other stations use 1080i for HD
[20:28:00 CET] <durandal_1707> Compn: find me ty tivo samples!
[20:35:52 CET] <jkqxz> lrusak:  Dunno.  The submitter mainly wanted to do software-only with pretty much the existing code, so I'm not sure what the intent is now.  Maybe it can be hacked in with some VIDIOC_EXPBUF calls?  (The necessity to mmap() everything isn't ideal, but it would probably work.)
[20:36:28 CET] <lrusak> yea I'm looking at using EXPBUF to get the fd and pass it into a drm prime structure
[20:36:44 CET] <jkqxz> I'm not sure how V4L2 works with modifiers at all, either.
[20:36:58 CET] <jkqxz> And you probably end up with duplicate fds, though that isn't really a problem.
[20:39:28 CET] <lrusak> Ok
[20:39:41 CET] <lrusak> bear in mind that this is all pretty new to me
[20:41:12 CET] <jkqxz> You are looking at this for Kodi?  Or in some other context?
[20:42:51 CET] <lrusak> yes kodi
[20:42:55 CET] <lrusak> eventually
[20:43:11 CET] <lrusak> someone else is doing the drm prime renderering kodi already
[20:43:17 CET] <lrusak> for the rockchip context
[20:43:42 CET] <lrusak> but it should work the same for v4l2 if we can get ffmpeg to output drmprime frames
[20:46:25 CET] <jkqxz> An annoying feature of the DRM format stuff is that everything can be represented in mutliple different ways (the composed and separated layer forms, and maybe mixed ones as well).
[20:47:39 CET] <jkqxz> KMS output wants the composed form, while graphics APIs all want the separate planes.
[20:48:33 CET] <LongChair> depends on the graphics API; for Intel yes, but that's also because their graphics driver doesn't support well NV12. it's ongoing from what i read but not merged yet :)
[20:48:36 CET] <jkqxz> Rockchip tries to duck that problem by having a GL extension which allows it to pass the composed form an be resampled to RGB automatically.
[20:49:11 CET] <jkqxz> But that opens its own can of worms wrt actually getting correct colours out.
[20:50:06 CET] <LongChair> jkqxz: talking about how to pass on color modes to drm ? 
[20:51:26 CET] <LongChair> i think this is more a problem with DRI not defining any standard properties for that, hopefully that changes and everyone gets a standard property name for setting colorspaces
[20:51:35 CET] <jkqxz> Yeah, colours are a problem with KMS too.
[20:51:41 CET] <LongChair> until then it's up to vendors creativity :)
[20:52:08 CET] <lrusak> sounds fun
[20:52:23 CET] <jkqxz> lrusak:  Is the intent that this would be rendered via GL or sent directly to scanout with KMS?
[20:52:27 CET] <LongChair> i have seen colorspace management in DRM atomic, the main issue is that everyone uses a variable property count as well as a different name :)
[20:52:45 CET] <LongChair> jkqxz: i think he's looking for KMS :)
[20:52:58 CET] <lrusak> yes directly with kms
[20:53:23 CET] <lrusak> we want to use a full zero copy path
[20:54:05 CET] <jkqxz> Do you always have NV12/P010/whatever video format, or is there going to be an extra m2m colour conversion there?
[20:54:15 CET] <jkqxz> *video format scanout,
[20:54:28 CET] <LongChair> jkqxz: iirc the goal is to have several devices that all implement DRM Atomic to be able to have the same render path. and ideally coming from DRM_PRIME format
[20:54:57 CET] <LongChair> some other devices have v4L2 support for decoding, so he needs to get both connected :)
[20:55:19 CET] <LongChair> and i think his devices would output NV12 as well 
[20:55:32 CET] <LongChair> not sure about their 10 bits format though 
[20:55:47 CET] <cone-975> ffmpeg 03Diego Biurrun 07master:61cec5adaacb: tls: Hide backend implementation details from users
[20:55:48 CET] <cone-975> ffmpeg 03James Almer 07master:4600b0619afc: Merge commit '61cec5adaacb358783c18aa07362f15824c1b274'
[20:56:03 CET] <lrusak> v4l2 is always nv12 at the moment
[20:56:24 CET] <LongChair> so 10 bits video never come out or are converted to 8 bits ? 
[20:56:34 CET] <jkqxz> I mean for scanout.  Do you assume that your devices can send that directly to the output?
[20:58:18 CET] <lrusak> I'm not actually sure
[20:59:24 CET] <jkqxz> Rockchip can do that, but I don't know if others can.  For comparison, Intel can't at the moment (but there are patches for it on gen9+ (Skylake+)).
[21:00:10 CET] <jkqxz> And whether that is possible is going to affect a lot of how you can build this - if it isn't, then you need some m2m conversion in the middle.
[21:00:32 CET] <LongChair> i think AllWinner can as well 
[21:01:23 CET] <LongChair> lrusak: it's all about the fact that you can do drmModeAddFB(with nv12 here)
[21:01:37 CET] <LongChair> but i'm pretty sure most embedded devices that support drm can do that 
[21:01:56 CET] <lrusak> ok cool :)
[21:02:41 CET] <lrusak> I see that here, https://github.com/Kwiboo/plex-home-theater/blob/rockchip-leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererRKMPP.cpp#L224
[21:03:26 CET] <jkqxz> Let me check exynos.
[21:07:00 CET] <lrusak> I also interested in imx6 and msm
[21:09:40 CET] <jkqxz> "formats: XR12 AR12 XR15 AR15 RG16 XR24 AR24" -> no.
[21:17:28 CET] <lrusak> hmm
[21:17:47 CET] <lrusak> is this a hardware or software limitation?
[21:18:32 CET] <jkqxz> No idea.  That's what KMS in 4.9 reports as supported.
[21:21:24 CET] <llogan> the "battleforthenet" popup on ffmpeg.org is annoying.
[21:21:47 CET] <JEEB> llogan: that kind of gets annoying when browsing ffmpeg-all
[21:21:52 CET] <JEEB> or well, opening a new one
[21:23:26 CET] <llogan> popup anger. 1st World Problems Man.
[21:28:28 CET] <lrusak> jkqxz: what tool outputted that?
[21:29:11 CET] <jkqxz> modetest (test program for libdrm).
[21:33:48 CET] <cone-975> ffmpeg 03Mark Thompson 07master:cf170869821a: ffmpeg: Fix flush packet stream copy input timestamp handling
[21:34:18 CET] <lrusak> on intel with 4.13.6
[21:34:20 CET] <lrusak>   formats: C8   RG16 XR24 XB24 AR24 AB24 XR30 XB30 YUYV YVYU UYVY VYUY
[21:37:30 CET] <jkqxz>  "formats: C8   RG16 XR24 XB24 AR24 AB24 XR30 XB30 YUYV YVYU UYVY VYUY NV12"
[21:37:40 CET] <jkqxz> On Intel 4.13 with <https://patchwork.freedesktop.org/series/25377/>.
[21:38:15 CET] <jkqxz> Presumably Intel is mostly a separate target for you, though?
[21:38:24 CET] <jkqxz> (VAAPI + GL.)
[21:38:50 CET] <jkqxz> Though it can work directly with KMS.
[21:43:05 CET] <cone-975> ffmpeg 03James Almer 07master:a876958d0fdd: avutil/md5: fix misaligned reads
[21:43:06 CET] <cone-975> ffmpeg 03Diego Biurrun 07master:f960fd2fb121: build: Skip generating .version files when reconfiguring
[21:43:07 CET] <cone-975> ffmpeg 03James Almer 07master:60ed9b704290: Merge commit 'a876958d0fdd8bf10d315175daff12cd7d768053'
[21:43:08 CET] <cone-975> ffmpeg 03James Almer 07master:8e8d4cf83274: Merge commit 'f960fd2fb1218d49866d0bf47cbf839233fb9904'
[22:03:11 CET] <cone-975> ffmpeg 03Diego Biurrun 07master:908f737d6c29: cmdutils: Mark conditionally used variable as av_unused
[22:03:12 CET] <cone-975> ffmpeg 03James Almer 07master:26868f80e025: Merge commit '908f737d6c2900b5d34319ca6ea1d1cb71221463'
[22:04:32 CET] <jamrial> michaelni: can you check what version of nasm you have in your freebsd fate machine?
[22:05:51 CET] <michaelni> NASM version 2.11.06 compiled on Oct 23 2014
[22:07:48 CET] <jamrial> huh, and it fails like that?
[22:08:13 CET] <alevinsn> nevcairiel:  got a second?  It would be nice to resolve patch 1 of 2 (regarding "wincrypt"), because patch 2 is needed to fix libmfx build issues.
[22:12:00 CET] <cone-975> ffmpeg 03Michael Niedermayer 07master:e8fafef1db43: avcodec/xan: Improve overlapping check
[22:12:01 CET] <cone-975> ffmpeg 03Michael Niedermayer 07master:2b739e1cb8f6: avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add()
[22:37:16 CET] <cone-975> ffmpeg 03James Almer 07master:3df4939988ac: avcodec/dca: return standard error codes in avpriv_dca_parse_core_frame_header()
[22:41:56 CET] <cone-975> ffmpeg 03Carl Eugen Hoyos 07master:42a9722a5c48: lavc/ppc/hpeldsp_altivec: Remove declaration of two unused variables.
[22:43:27 CET] <llogan> michaelni: how do i make mailing-list-faq.html from doc/mailing-list-faq.texi for the online docs?
[22:46:20 CET] <cone-975> ffmpeg 03Diego Biurrun 07master:5e27ef800bfa: build: Add missing zlib dependencies for several protocols
[22:46:21 CET] <cone-975> ffmpeg 03Diego Biurrun 07master:adfd7892e3b8: configure: Move x86 assembler sanity check into assembler probe function
[22:46:22 CET] <cone-975> ffmpeg 03Diego Biurrun 07master:ed434be106a4: configure: Bail out if both GnuTLS and OpenSSL are enabled
[22:46:23 CET] <cone-975> ffmpeg 03James Almer 07master:070336b89b0b: Merge commit 'ed434be106a4615e0419b3ac7664220741afda2d'
[22:50:50 CET] <cone-975> ffmpeg 03wm4 07master:fff90422d181: lavu: add new D3D11 pixfmt and hwcontext
[22:50:51 CET] <cone-975> ffmpeg 03wm4 07master:bd747b922641: lavc: set avctx->hwaccel before init
[22:50:52 CET] <cone-975> ffmpeg 03wm4 07master:4dec101acc39: dxva: preparations for new hwaccel API
[22:50:53 CET] <cone-975> ffmpeg 03wm4 07master:831cfe10b404: dxva: move d3d11 locking/unlocking to functions
[22:50:54 CET] <cone-975> ffmpeg 03wm4 07master:f9e7a2f95a71: dxva: add support for new dxva2 and d3d11 hwaccel APIs
[22:50:55 CET] <cone-975> ffmpeg 03James Almer 07master:508fc8085022: Merge commit 'f9e7a2f95a7194a8736cc1416a03a1a0155a3e9f'
[22:52:37 CET] <cone-975> ffmpeg 03Srinath K R 07master:98ea98069b40: nvenc: Add default value for AVCodecContext::refs
[22:52:38 CET] <cone-975> ffmpeg 03James Almer 07master:358c886655bc: Merge commit '98ea98069b40c34aa7b762096f8f380012a7dd84'
[22:54:08 CET] <michaelni> llogan, IIUC look at ffcrontexi.sh
[22:55:23 CET] <llogan> michaelni: i'll look at that. thanks.
[23:00:14 CET] <durandal_1707> jamrial: how will you merge hwaccel patch from libav?
[23:02:06 CET] <jamrial> durandal_1707: the stuff michaelni blocked? I'm hoping that gets solved before i reach that point in the queue, but nobody seems to be calling a vote or even asking other devs to chime in and tip the scales in one direction
[23:02:49 CET] <jamrial> wm4 is the one that was interested on it the most, but now he's apparently not pushing for it any longer
[23:03:07 CET] <llogan> did he push it in his new fork?
[23:03:17 CET] <jamrial> i don't understand half of it to start the vote myself and present both sides of the argument, and nobody else seems to care
[23:03:52 CET] <jamrial> llogan: yeah, looks like
[23:11:06 CET] <durandal_1707> should we organize ffmeeting?
[23:11:17 CET] <jamrial> no, why?
[23:11:25 CET] <jamrial> if all this needs is a vote then just start one
[23:12:16 CET] <jamrial> it's literally a "do we push this as submitted, or change the parts michael oposses?" kind of question
[23:12:49 CET] <durandal_1707> to discuss situations
[23:13:25 CET] <jamrial> i don't see anything worth discussing in a meeting atm
[23:14:24 CET] <durandal_1707> really? we should stop doing merges, they break lot of stuff
[23:15:15 CET] <ubitux> i disagree
[23:15:22 CET] <ubitux> jamrial: thanks a lot for working on the merges btw
[23:15:31 CET] <ubitux> we're almost back on par with libav thanks to you
[23:16:39 CET] <durandal_1707> whats point of merges, when:
[23:16:50 CET] <durandal_1707> 1. most of them are noop
[23:17:13 CET] <durandal_1707> 2. they are not merged anyway
[23:17:22 CET] <jamrial> it's been mentioned plenty of times, it makes it easy to track what was imported and what was not
[23:17:34 CET] <jamrial> otherwise we would have done standard cherry picks since day one
[23:17:58 CET] <jamrial> goddamn deja vu, we have this discussion at least once a year
[23:23:05 CET] <Compn> durandal_1707 : did you ask carl for ty tivo samples yet?
[23:24:31 CET] <durandal_1707> ceffmpeg is conspirator, i cant share emails with him
[23:26:11 CET] <Compn> durandal_1707 : ask llogan to make a twitter post asking for ty tivo samples
[23:26:14 CET] <Compn> i dont have any
[23:26:27 CET] <Compn> llogan : can you make a twitter post asking for ty tivo samples ? 
[23:26:32 CET] <Compn> please ?
[23:26:59 CET] <llogan> if durandal_1707 wants me to i can. i can can retweet anythign he posts.
[23:27:07 CET] <llogan> *or I can
[23:27:27 CET] <Compn> durandal_1707 : you still are not interested in figuring out all of the vivo codecs? :)
[23:27:38 CET] <Compn> you can learn h263 :)\
[23:28:40 CET] <durandal_1707> Compn: where are all vivo samples?
[23:29:14 CET] <Compn> durandal_1707 : http://samples.ffmpeg.org/vivo/
[23:29:44 CET] <durandal_1707> i cant promiss anything, maybe kostya will do it someday, he likes obscure oned
[23:30:19 CET] <Compn> some here too http://samples.ffmpeg.org/archive/extension/viv/
[23:32:48 CET] <Compn> maybe kierank wants help on merging the newly opensourced red codec too ?
[23:33:07 CET] <Compn> e.g. the bayer parts 
[23:33:41 CET] <Compn> durandal_1707 : have you worked on any bayer stuff yet ? :)
[23:34:38 CET] <llogan> the bare bear likes bayer
[23:34:46 CET] <durandal_1707> no, i work on secret stuff
[23:35:35 CET] <Compn> llogan : so can you post a request for ty tivo samples for me ? something like "we need some more of the original .ty or .tyt tivo samples for research, please upload"
[23:35:42 CET] <Compn> hmm twitter
[23:36:10 CET] <Compn> "we need more .ty / .tyt tivo samples , please upload"
[23:36:31 CET] <llogan> ok. upload where?
[23:36:50 CET] <Compn> hmm
[23:36:53 CET] <Compn> is incoming working ?
[23:37:07 CET] <durandal_1707> .ty .ty+
[23:37:30 CET] <Compn> llogan : http://streams.videolan.org/upload/
[23:37:34 CET] <Compn> maybe ? or maybe its still down ?
[23:37:50 CET] <durandal_1707> no .tivo or .tmf, they are smthing else
[23:37:54 CET] <llogan> durandal_1707: give me exact sentence and i'll tweet it
[23:38:22 CET] <Compn> hmm no, maybe is down
[23:38:27 CET] <Compn> j-b : where do we upload samples ?
[23:38:35 CET] <llogan> Compn: don't matter. people will use whatever.
[23:38:38 CET] <Compn> j-b : also , how do we access them again ? 
[23:38:41 CET] <Compn> llogan : right
[23:45:00 CET] <cone-975> ffmpeg 03Gyan Doshi 07master:3524c9295083: lavf/img2enc: remove redundant option 'updatefirst'
[23:47:14 CET] <Compn> llogan : "looking for .ty .tyt and .ty+ tivo samples for reverse engineering, please upload"
[23:47:18 CET] <Compn> something like that ?
[23:47:32 CET] <durandal_1707> remove tyt
[23:48:00 CET] <durandal_1707> for testing
[23:48:17 CET] <durandal_1707> its already REd
[23:48:20 CET] <Compn> oh ok
[23:48:36 CET] <durandal_1707> besides i already posted tweet
[23:48:53 CET] <Compn> whats your tweeeter ?
[23:50:03 CET] <durandal_1707> search for ffmpeg and you will see it
[23:50:31 CET] <llogan> durandal_1707: done. and this time I'm not 12 hours late as usual
[23:50:59 CET] <Compn> thanks llogan , you are hard worker :)
[23:52:21 CET] <Compn> also durandal_1707 is good too ehe
[23:53:35 CET] <Compn> lol someone linked to the samples repo
[23:55:57 CET] <atomnuker> durandal_1707: gave up on atrac9?
[23:56:57 CET] <durandal_1707> atomnuker: some guy REed it already, waiting him to publish code
[23:57:38 CET] <atomnuker> cool
[23:57:46 CET] <Compn> durandal_1707 : what secret are you working on  ? 
[23:58:31 CET] <durandal_1707> top secret, if you look at my github repo you will see it
[00:00:00 CET] --- Thu Nov  2 2017