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

[burek]

[00:44:10 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vN1xJ
[00:44:10 CET] <KGB> 13FFV1/06master 149df20bf 15Dave Rice: bump to version 01...
[01:12:13 CET] <wm4> rcombs: I sent a patch that partially reverts a commit by you, can you review?
[01:12:21 CET] <rcombs> sure
[01:13:18 CET] <rcombs> wm4: yeah that's fine
[01:13:40 CET] <rcombs> the point was to try to be more friendly to existing API users, so if it's not having that effect reverting's fine
[01:15:21 CET] <atomnuker> jkqxz: I see you can map vaapi frames to drm frames, what use is that? can you output vaapi frames directly to VTs this way?
[01:16:48 CET] <wm4> not just via DRM but also EGL and others
[01:17:10 CET] <wm4> since the DRM hwcontext is just unix FDs + metadata
[01:22:36 CET] <jkqxz> atomnuker:  <http://ixia.jkqxz.net/~mrt/kms_va_nv12.c>
[01:25:26 CET] <atomnuker> this does vaapi->drm by itself, I was wondering why there was a vaapi->drm in lavu
[01:25:32 CET] <atomnuker> can you use it?
[01:26:36 CET] <jkqxz> Oh, right.  It's the same thing.
[01:27:28 CET] <jkqxz> I was planning to use it as an intermediate for other stuff (like OpenCL), but it still isn't in a released libva.
[01:29:23 CET] <jkqxz> So it's currently there but unused.  You can see it working in ffmpeg with hwmap, but not very usefully.
[01:30:23 CET] <atomnuker> could be useful for VAAPI->DRM->Vulkan
[01:30:35 CET] <atomnuker> because there's no way to directly import from vaapi as far as I can see
[01:30:55 CET] <jkqxz> Yeah, I'd like to do DRM intermediates using it, but OpenCL was there before it could be used.
[01:31:41 CET] <wm4> jkqxz: what's the to be released libva thing?
[01:32:18 CET] <jkqxz> vaExportSurfaceHandle() is in libva 2.1, but it's not yet released.
[01:32:42 CET] <jkqxz> Hmm, I should chase the AMD people in Mesa over that again.
[01:33:32 CET] <wm4> oh right
[01:33:45 CET] <wm4> I'm waiting for that too
[01:33:48 CET] <wm4> vdpau must die
[01:39:43 CET] <jkqxz> Huh, they've posted H.265 encode with VAAPI - <https://lists.freedesktop.org/archives/mesa-dev/2018-January/183471.html>.
[01:40:17 CET] <jkqxz> Raven Ridge only though (the newest APU chips, which aren't in many places yet).
[03:30:08 CET] <wm4> old but nice: https://de.slideshare.net/SamsungOSG/ffmpeg-a-retrospective
[03:30:27 CET] <wm4> gems like this https://image.slidesharecdn.com/2015102801sosconslidesffmpeg-151104161552-lva1-app6891/95/ffmpeg-a-retrospective-13-638.jpg?cb=1446677165
[03:36:30 CET] <kierank> wm4: not untrue
[03:41:42 CET] <youngluoyang> how to use docker build ffmpeg develop environment?
[04:18:41 CET] <cone-625> ffmpeg 03wm4 07master:637dfa39421c: hls: do not allow fallback to generic seeking
[04:18:41 CET] <cone-625> ffmpeg 03wm4 07master:6194d7e56454: avformat, hls: add a flag to signal unavailability of seeking
[04:18:41 CET] <cone-625> ffmpeg 03wm4 07master:23ffeb91fe46: hls: don't print a certain warning if playlist loading is aborted
[04:31:21 CET] <cone-625> ffmpeg 03Michael Niedermayer 07master:c6939f65a116: avfilter/vf_transpose: Fix used plane count.
[04:31:22 CET] <cone-625> ffmpeg 03Michael Niedermayer 07master:1bfc1aa00495: avcodec/mjpegdec: Fix integer overflow in DC dequantization
[04:31:23 CET] <cone-625> ffmpeg 03Michael Niedermayer 07master:a026a3efaeb9: avcodec/hevc_cabac: Check prefix so as to avoid invalid shifts in coeff_abs_level_remaining_decode()
[12:54:18 CET] <KGB> [13FFV1] 15michaelni tagged 06draft-ietf-cellar-01 at 06master: 02https://git.io/vNMEW
[13:49:53 CET] <dijkstrazeppelin> Hi guys, I was investigating the MPEG-4 ALS decoder  aka "alsdec.c" for  the qualification task. Could someone please tell me how a modified alsdec.c can be tested ? Is there some command that 'runs' ffplay and uses my modified alsdec.c file?Thanks a ton in advance !:)
[13:58:15 CET] <DHE> umm.. recompile and produce new binaries to test it?
[13:59:03 CET] <dijkstrazeppelin> Thanks! I'm sorry I'm such a noob :( 
[15:50:46 CET] <atomnuker> jkqxz: for some reason doing hwmap,hwdownload makes lavfi correctly call map_to but then gives the original unmapped frames to hwdownload
[15:50:48 CET] <atomnuker> ./ffmpeg_g -init_hw_device "vulkan=sl:0,extensions=VK_EXT_debug_report" -device /dev/dri/card0 -crtc_id 0 -f kmsgrab -i /dev/zero -filter_hw_device sl -vf hwmap,hwdownload,format=bgra -f null -
[15:51:30 CET] <atomnuker> so hwdownload gets frames with drm_prime as pixfmt
[17:08:14 CET] <BtbN> philipl, can you take a look at the mapping-refcounting-nvenc patch? I'm pretty confident it's ok, but a second pair of eyes would be good.
[17:19:58 CET] <BtbN> I'd also like to backport this to at least 3.4 and 3.3. It fixes crashes in a few strange edge cases I wasn't able to reproduce myself.
[17:29:42 CET] <jkqxz> atomnuker:  Did it choose the right pixfmt on the output of hwmap?
[17:30:19 CET] <jkqxz> (The lavfi format setup runs before you can map anything, so it can easily mess up.)
[17:51:15 CET] <atomnuker> you mean the right drm -> vulkan format mapping?
[17:51:29 CET] <atomnuker> or the hwdownload format?
[18:05:58 CET] <jkqxz> I mean what lavfi chooses as the format on the link between hwmap and hwdownload.
[18:08:24 CET] <kierank> michaelni:
[18:08:24 CET] <kierank> > +        s->mb_x = mb_num % s->mb_width;
[18:08:24 CET] <kierank> > +        s->mb_y = mb_num / s->mb_width;
[18:08:24 CET] <kierank> missing validity checks
[18:08:33 CET] <kierank> it's the same in the normal mpeg4 video code
[18:08:37 CET] <kierank> what do you want me to validate them as?
[18:08:44 CET] <kierank> nonzero?
[18:09:28 CET] <kierank> same with
[18:09:28 CET] <kierank> > +    Mpeg4DecContext *ctx = (Mpeg4DecContext *)s;
[18:09:34 CET] <kierank> that's exactly the same as the existing code
[18:10:37 CET] <kierank> also get_vlc2 isn't documented as returning any errors?
[18:10:54 CET] <atomnuker> jkqxz: would that be the output sw_format?
[18:11:02 CET] <atomnuker> (after mapping?)
[18:20:01 CET] <jkqxz> No.  AVFilterLink.format on the link between hwmap and hwdownload, is that AV_PIX_FMT_VULKAN_WHATEVER?  If not, it can't possibly work.  And I don't think your command has given lavfi the opportunity to choose that.
[18:22:52 CET] <atomnuker> yeah, link->format is dri_prime in filter_frame
[18:23:15 CET] <atomnuker> the same command works with vaapi though, if you replace vulkan->vaapi and add a proper /dev/dri node
[18:24:49 CET] <jkqxz> Luck?  Dunno.  Put format=vulkan_whatever between the two filters and try again, I think.
[18:25:44 CET] <jkqxz> (Are there going to be multiple vulkan formats, or is the VkImage the only sensible thing to expose?)
[18:26:44 CET] <atomnuker> vkimage is the only sensible thing
[18:29:39 CET] <atomnuker> hm, seems to work now, though the avframe I'm getting is junk
[18:29:49 CET] <atomnuker> the avbufferref seems to be all 0's
[18:29:57 CET] <atomnuker> (that's where I store my context)
[18:32:12 CET] <atomnuker> wait, no, whatever's in the bufferref is definitely not an avvkframe
[19:28:19 CET] <michaelni> kierank, i meant that mb_num must be less than the number of mbs. theres a check for this in the existing code "mb_num>=s->mb_num", zero if its disallowed can be checked too. ill double check and if needed fix the existing code
[19:28:34 CET] <kierank> ok that's what i did
[19:37:13 CET] <atomnuker> grr vulkan, why do you support all these obscure packings and yet no bgr0
[19:37:50 CET] <atomnuker> I get that you can use BGRA and swizzle the alpha to null but its less nice
[20:05:11 CET] <durandal_1707> lol,  so vulkan thing doesnt work at all?  awesome work!
[20:10:00 CET] <atomnuker> durandal_1707: no, it does, its quite fast too
[20:10:24 CET] <atomnuker> I have a working DRM->Vulkan interop
[20:10:56 CET] <kierank> durandal_1707: can you review my patch
[20:11:37 CET] <atomnuker> and since everywhere in lavfi in vulkan we work in linear images the drm tiles images can be converted to linear (de-tiled) via a filter which just blits 'em
[20:12:24 CET] <atomnuker> once I write that filter you'll finally be able to losslessly download kms frames rather than going through vaapi
[20:12:34 CET] <durandal_1707> kierank: no, im michaelni lieutenant
[20:12:41 CET] <kierank> durandal_1707: ok, np
[20:12:47 CET] <kierank> I defer to the dear leader
[20:13:19 CET] <durandal_1707> @/
[20:16:08 CET] <durandal_1707> atomnuker: what? does it support float formats?
[20:18:54 CET] <durandal_1707> kierank: where is simple idct patch? when you last time sent it?
[20:19:03 CET] <kierank> durandal_1707: december 27
[20:19:06 CET] <kierank> i think
[20:19:50 CET] <atomnuker> durandal_1707: sure, though it works on non-planar floats though so I'll need to write a few lines to (de) interleave them during mapping/uploading
[20:20:31 CET] <atomnuker> lavu only has planar GBR float formats
[20:21:55 CET] <atomnuker> I could add non-planar float support if there's anything to generate them (zlib?)
[20:24:05 CET] <durandal_1707> atomnuker: zlib works only with planar , libp2p on other hand works with packed
[20:24:34 CET] <JEEB> p2p is the packed<->planar conversion thing :P
[20:24:49 CET] <JEEB> did it support NV12?
[20:24:57 CET] <JEEB> (or other half-packed things)
[20:25:44 CET] <durandal_1707> kierank: michaelni said that you hadnt renamed functions to have clear whats what in bitdepth
[20:25:56 CET] <kierank> I did
[20:26:08 CET] <durandal_1707> for 12 bit too?
[20:26:18 CET] <atomnuker> hmm, actually what I could do is to flag the image as YUV444 multiplanar and then allocate 3 planes for 1 image and bind them all to it
[20:26:24 CET] <kierank> durandal_1707: yes
[20:26:42 CET] <atomnuker> the sw_format's going to be GRAPF so filters will know its not YUV but float RGB in each plane
[20:27:27 CET] <atomnuker> durandal_1707: why do you need float pixfmt support?
[20:32:43 CET] <durandal_1707> atomnuker: out of gamut values for hdr?
[20:34:26 CET] <durandal_1707> kierank: one of test stuff is not updated, ff_simple_idct_16_12
[20:35:20 CET] <kierank> fixed that already
[20:38:43 CET] <durandal_1707> JEEB: https://github.com/sekrit-twc/libp2p/blob/master/p2p_api.cpp
[20:41:08 CET] <JEEB> yea, I noticed the V210 case too already
[20:44:34 CET] <atomnuker> jkqxz: is there a filter which refs the frames context rather than creating a new one?
[20:48:43 CET] <durandal_1707> kierank: where are studio samples?
[20:49:02 CET] <kierank> On trac
[20:49:36 CET] <kierank> Only 3, one uses dpcm so only plays for a bit
[20:49:43 CET] <kierank> But I will fix later
[20:50:59 CET] <jkqxz> atomnuker:  deinterlace_qsv.
[20:53:20 CET] <durandal_1707> kierank: i get segv plaaying  sr lite incomplete download
[20:53:58 CET] <kierank> Send backtrace
[20:54:27 CET] <kierank> Probably because mpeg4video uses unchecked bitstream reader
[20:56:28 CET] <durandal_1707> yes
[20:56:59 CET] <durandal_1707> ff mpeg4 decode studio slice header
[20:57:18 CET] <durandal_1707> mpeg4video.c:560
[20:57:35 CET] <durandal_1707> *dec
[21:08:49 CET] <philipl> BtbN: looking
[21:10:22 CET] <durandal_1707> kierank: it also randomly crashes when playing with mpv or ffplay, inside add_dct at libavcodec/mpegvideo.c:1877
[21:10:35 CET] <JEEB> can you try valgrind'ing it?
[21:12:50 CET] <durandal_17> (gdb) bt
[21:12:50 CET] <durandal_17> #0  0x0000000000000000 in ?? ()
[21:12:50 CET] <durandal_17> #1  0x00007ff4dcbbf6ae in add_dct (s=0x5596e2055240, i=0, line_size=<optimized out>, block=<optimized out>, dest=<optimized out>) at libavcodec/mpegvideo.c:1877
[21:12:53 CET] <durandal_17> #2  mpv_reconstruct_mb_internal (lowres_flag=0, is_mpeg12=0, s=<optimized out>, block=<optimized out>) at libavcodec/mpegvideo.c:2092
[21:12:56 CET] <durandal_17> #3  ff_mpv_reconstruct_mb (s=<optimized out>, block=<optimized out>) at libavcodec/mpegvideo.c:2214
[21:12:59 CET] <durandal_17> #4  0x00007ff4dc868988 in guess_mv (s=<optimized out>) at libavcodec/error_resilience.c:453
[21:13:02 CET] <durandal_17> #5  ff_er_frame_end (s=<optimized out>) at libavcodec/error_resilience.c:1231
[21:13:05 CET] <durandal_17> #6  0x00007ff4dc8d0283 in ff_h263_decode_frame (avctx=<optimized out>, data=<optimized out>, got_frame=<optimized out>, avpkt=<optimized out>) at libavcodec/h263dec.c:670
[21:13:08 CET] <durandal_17> #7  0x00007ff4dcc4e612 in frame_worker_thread (arg=<optimized out>) at libavcodec/pthread_frame.c:201
[21:13:11 CET] <durandal_17> #8  0x00007ff4d84e46da in start_thread (arg=0x7ff4b68df700) at pthread_create.c:456
[21:13:27 CET] <durandal_17> #9  0x00007ff4d821ed7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
[21:14:21 CET] <durandal_1707> JEEB: with valgrind it doesnt crash
[21:14:44 CET] <JEEB> :<
[21:15:10 CET] <durandal_1707> randomly crashes at begining ^ 
[21:15:59 CET] <durandal_1707> guess frame threading triggers it
[21:17:44 CET] <philipl> BtbN: reviewed. Looks fine
[22:43:48 CET] <kierank> durandal_1707: damn, gonna be hard to fix that threading problem
[23:36:31 CET] <RiCON> heh
[00:00:00 CET] --- Sun Jan 28 2018