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

[burek]

[01:13:56 CET] <SortaCore> is there a reason the metadata is stripped if it's set before av_write_header?
[01:14:27 CET] <SortaCore> bug or by design 🤔
[01:34:18 CET] <cone-981> ffmpeg 03Gyan Doshi 07master:6c1c6c6c71fc: avfilter/drawtext - implement fix_bounds
[01:37:47 CET] <cone-981> ffmpeg 03Mark Thompson 07master:a0c624e29973: avcodec: v4l2_m2m: fix races around freeing data on close
[01:37:48 CET] <cone-981> ffmpeg 03Jorge Ramirez-Ortiz 07master:5d5de3eba4c7: avcodec: v4l2_m2m: remove unnecessary timeout.
[01:37:49 CET] <cone-981> ffmpeg 03Jorge Ramirez-Ortiz 07master:0b9b7f0b46a8: avcodec: v4l2_m2m: context: fix raising warning on POLLERR
[02:03:35 CET] <jkqxz> atomnuker:  map_to/from is for mapping individual frames.  frames_derive_to/from is for creating new frames contexts on a different device.
[02:04:08 CET] <jkqxz> The latter may be needed if there is extra hardware-specific information about the frames context required.
[02:04:29 CET] <atomnuker> ah, I see
[02:05:15 CET] <atomnuker> I wanted to get vaapi->opencl running so I could see if I could replicate what it does in vulkan but it failed with "Assertion dst->format == AV_PIX_FMT_OPENCL failed at libavutil/hwcontext_opencl.c:2827"
[02:06:08 CET] <jkqxz> Frame mapping requires that you have made the derived frames context, but the derivation step only actually does anything in the hwcontext implementation if it needs to.
[02:06:08 CET] <atomnuker> -vf 'hwmap=derive_device=opencl,hwmap=derive_device=vaapi:reverse=1,format=vaapi' is my filter line, before the input file I select vaapi device normally as well as vaapi format
[02:06:40 CET] <jkqxz> Don't put the reverse there.
[02:06:58 CET] <jkqxz> Reverse-hwmap is only for making the destination frames in the sink, which you aren't there.
[02:07:29 CET] <atomnuker> same error
[02:08:16 CET] <jkqxz> Hmm.  Does mapping back and forth work?  Try actually doing something in OpenCL?
[02:11:41 CET] <jkqxz> Hmm.  The second derive has created a new device and therefore barfed.  Why did it do that?
[02:12:51 CET] <atomnuker> dunno, this was part of an example you posted on the patchset
[02:12:54 CET] <jkqxz> Oh, it didn't.  I'm misreading the messages.
[02:13:14 CET] <atomnuker> tried to put unsharp opencl but got failed to map frame, function not implemented
[02:13:24 CET] <atomnuker> (after hwmap opencl)
[02:13:27 CET] <jkqxz> It all works if you actually do something in OpenCL.  Mapping to another API and back is pointless.
[02:14:00 CET] <jkqxz> "./ffmpeg_g -v 55 -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD129 -hwaccel_output_format vaapi -i in.mp4 -an -vf 'hwmap=derive_device=opencl,unsharp_opencl,hwmap=derive_device=vaapi:reverse=1' -c:v h264_vaapi -frames:v 10 out.mp4"
[02:17:07 CET] <atomnuker> that works as long as I feed that into a vaapi encoder, any way to skip this?
[02:18:27 CET] <atomnuker> got it working, I just put a vaapi_deinterlace filter right after
[02:18:28 CET] <jkqxz> 'hwmap=derive_device=opencl,format=opencl,hwmap=derive_device=vaapi'
[02:19:13 CET] <jkqxz> works.  The filter failed to deduce that the frames between the mappings should have format opencl, so it was mapping vaapi -> vaapi -> vaapi with the OpenCL mapping, hence the error.
[02:20:15 CET] <jkqxz> Or libavfilter failed to deduce, because query_formats happened too early to tell.
[02:21:11 CET] <jkqxz> Should probably add something to vf_hwmap to spot that case.  (It's basically the same problem as hwdownload often needing a format instance after it to tell it the target format.)
[02:22:10 CET] <jkqxz> Your needs-encoder case will be the same thing as well.
[02:23:01 CET] <jkqxz> Anyway, I should sleep at some point.  I'll have another look at Vulkan tomorrow after I deal with the VAAPI filter stuff.
[02:23:12 CET] <atomnuker> k, thanks
[03:48:52 CET] <cone-981> ffmpeg 03Carl Eugen Hoyos 07master:251f0bcb7be9: lavf/rawdec: Also probe the last byte of mjpeg streams.
[04:50:53 CET] <cone-981> ffmpeg 03James Almer 07master:9462b2b82053: avcodec/hevc_ps: add a function to uninitialize parameter set buffers
[04:50:54 CET] <cone-981> ffmpeg 03James Almer 07master:1f0cf1b2f4ef: avcodec/hevcdec: use ff_hevc_uninit_parameter_sets()
[04:50:55 CET] <cone-981> ffmpeg 03James Almer 07master:2159d4bbc3e6: avcodec/hevc_parser: use ff_hevc_uninit_parameter_sets()
[05:19:06 CET] <mistym> Is there a way to access info on whether an AVPacket is a duplicate frame from within a muxer? I noticed the CLI tool visualizing that data, but not sure how to access it.
[05:22:47 CET] <mistym> (Context: the format I'm muxing has the ability to skip frames; the header can increment the timebase to indicate skipped frames.
[05:27:33 CET] <mistym> And AFAIK the only compatible video codec, Cinepak, will be able to drop duplicated frames in this case because the only thing being written will be two "reuse strip" commands.
[06:59:31 CET] <cone-981> ffmpeg 03sfan5 07master:777d6c677b1d: dashdec: Make use of frame rate specified in Representation
[06:59:32 CET] <cone-981> ffmpeg 03Brendan McGrath 07master:2472dbc7a770: avformat/hlsenc: Check that data is set
[06:59:33 CET] <cone-981> ffmpeg 03Brendan McGrath 07master:1f48c5c0671b: dashdec: Only free url string if being reused
[06:59:34 CET] <cone-981> ffmpeg 03Colin NG 07master:8db4ef3e6d93: avformat/dashdec.c: Download dash content with byte range info
[06:59:35 CET] <cone-981> ffmpeg 03Colin NG 07master:7a63da891023: libavformat/dashdec: Fix for ticket 6658 (Dash demuxer segfault)
[06:59:36 CET] <cone-981> ffmpeg 03Colin NG 07master:78e884f3fb1d: libavformat/dashdec: Fix for ticket 6856 (filename limited to 1024)
[14:05:14 CET] <kierank> carl reviews, always so useful
[17:34:00 CET] <Chloe> is there an easy way to run fate for several commits? perhaps with git bisect?
[17:46:31 CET] <BtbN> make a bisect script that does it
[17:47:03 CET] <nevcairiel> you can make a script and use git bisect run, but its usually more effort then doing that manually for the few steps it takes
[17:51:15 CET] <BtbN> A generic "do a fate run" script is nice to have though, and it rarely changes
[19:05:08 CET] <kierank> michaelni: how do I reproduce this https://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/224375.html
[19:05:15 CET] <kierank> and do you know how it could happen
[19:11:18 CET] <JEEB> the "only happens with ffplay" thing is quite funky
[22:37:26 CET] <cone-320> ffmpeg 03Carl Eugen Hoyos 07master:55bdee7b0726: lavc/svq3: Do not write into memory defined as const.
[22:52:53 CET] <cone-320> ffmpeg 03Jorge Ramirez-Ortiz 07master:15a05d2b73c6: MAINTAINERS: add myself for avcodec/v4l2_
[22:52:54 CET] <cone-320> ffmpeg 03Michael Niedermayer 07master:56a53340ed4c: avcodec/truemotion2: Fix integer overflow in TM2_RECALC_BLOCK()
[22:53:43 CET] <BtbN> no idea if the new v4l2 maintainer is in here, but he should definitely have a look at what coverity reports about some recent commits
[22:54:51 CET] <Compn> probably bring it up on the mailing list ? 
[00:00:00 CET] --- Mon Jan 22 2018