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

[burek]

[00:02:13 CEST] <jkqxz> On patch 1/2, I was really just wanting to know that it's actually been tested in that mode now.
[00:02:48 CEST] <jkqxz> ... and on what.
[00:02:50 CEST] <jkqxz> (Hint hint wiki page outlining supported devices.)
[00:04:20 CEST] <ldts> did I answer your question or you expected some other info? yes imx6 is single plane (it was the Kodi team who raised the issue)
[00:05:36 CEST] <jkqxz> Yeah, if it's been tested now that's fine.
[00:07:50 CEST] <ldts> ok
[00:13:52 CEST] <ldts> still building?
[00:14:15 CEST] <jkqxz> Almost done.
[00:14:58 CEST] <jkqxz> wm4:  Which hardware decoding patches do you actually want here?
[00:18:52 CEST] <jamrial> jkqxz: inline asm is annoying like that when you're register starved
[00:19:39 CEST] <jkqxz> ldts:  <http://sprunge.us/dJBC>, <http://sprunge.us/PeIG>
[00:21:43 CEST] <ldts> jkqxz: um...ok. and that is a debug message, correct?
[00:22:40 CEST] <jkqxz> Yes.
[00:23:19 CEST] <jkqxz> ff_v4l2_m2m_codec_end() has been called with an AVCodecContext containing a NULL priv_data.
[00:23:57 CEST] <ldts> I wonder why I dont see it on my board...ok
[00:24:50 CEST] <wm4> jkqxz: minimum the frame pool info one I sent to Libav, ideally the cuvid one, and possibly yours
[00:29:06 CEST] <jkqxz> ldts:  Do you want me to do anything else with this?  (It's 100% repeatable, I don't think I said that earlier.)
[00:29:56 CEST] <ldts> jkqxz: I cant reproduce on my board...but I guess it makes sense. when the codec is closed the private data must be deallocated inmmediatly right?
[00:30:35 CEST] <ldts> so on the second call, the private data is null...
[00:30:56 CEST] <ldts> I wonder why that doesnt happen on arm64 (maybe the memory is managed differently)
[00:31:14 CEST] <jkqxz> Yes <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/utils.c;h=9551f312e7224fc5aff6182592b2fd400f04cb2a;hb=HEAD#l1214>.
[00:33:07 CEST] <ldts> ok so you are right, the patch doesnt fix it...
[00:34:16 CEST] <ldts> I'll think of something else then ...but av_free should be setting the pointers to null on all architectures
[00:35:43 CEST] <jkqxz> Ok.  I'll push the other one on its own, then.
[00:36:24 CEST] <ldts> yes..I suppose there is no way to delay the deletion of the private data?
[00:37:32 CEST] <jkqxz> No.  I think you need to keep references to it from the buffers which are outstanding (see hwcontext, where the frames context do all of this).
[00:39:04 CEST] <Compn> wm4 : you mean you want the release delayed until cuvid is in ?
[00:39:15 CEST] <wm4> Compn: yes
[00:39:16 CEST] <Compn> wm4 : "I vote the release until this has happened."
[00:39:22 CEST] <Compn> you ate a word somewhere
[00:39:27 CEST] <ldts> but the buffers to keep a refence (See v4l2_free_buffer that can get called after the codec was closed)
[00:39:29 CEST] <wm4> ah
[00:39:50 CEST] <ldts> s/to/do
[00:39:50 CEST] <Compn> just a friendly reminder :)
[00:39:55 CEST] <Compn> i dont want people to be confused :)
[00:40:32 CEST] <jkqxz> Can I accidentally the release as well?
[00:40:52 CEST] <ldts> ?
[00:41:00 CEST] <Compn> ehe
[00:41:20 CEST] <Compn> its a recurring interenet joke when someone the word.
[00:43:05 CEST] <ldts> jkqxz: so after the codec has been closed, v4l2_free_buffer can be called; it keeps a reference to the buffer which provides a pointer to the AVCtx via the private data (V4L2m2mContext)
[00:48:33 CEST] <cone-507> ffmpeg 03Jorge Ramirez-Ortiz 07master:2a31ad7d6063: avcodec/v4l2: fix single plane decoding
[00:50:48 CEST] <ldts> jkqxz: I can have something ready in 20 minutes. will you be around? 
[00:53:53 CEST] <jkqxz> For a bit.  I do sleep sometimes.
[00:55:36 CEST] <ldts> thanks a lot, just 10 minutes 
[01:00:47 CEST] <ldts> testing on my end now
[01:01:57 CEST] <ldts> looks good on my side
[01:02:31 CEST] <ldts> https://hastebin.com/iroruqomuq.php
[01:03:41 CEST] <ldts> obviously no need to clean the build...so should be fast. again many thanks for doing this. I'll get my power supply soon!
[01:04:40 CEST] <jkqxz> Is that link right?  It's a blank page, with just some javascript in the source.
[01:05:17 CEST] <ldts>  yes it works for me: https://hastebin.com/iroruqomuq.php
[01:05:43 CEST] <ldts> http://paste.ubuntu.com/25688854/
[01:05:48 CEST] <ldts> what about that one?
[01:06:08 CEST] <ldts> this goes on top of the previous patch by the way
[01:06:24 CEST] <jkqxz> That's better.
[01:06:29 CEST] <ldts> so no need to remove the other one...
[01:12:05 CEST] <jkqxz> Looks better.
[01:12:36 CEST] <ldts> ok. should I send a new patch then?
[01:12:49 CEST] <ldts> works also ok on my hardware
[01:13:52 CEST] <jkqxz> Right, it doesn't crash, but there is still something nasty going on.
[01:14:09 CEST] <jkqxz> <http://sprunge.us/cKSB> (and some others).
[01:14:57 CEST] <ldts> how do I Get that info?
[01:15:27 CEST] <ldts> I'll get the supply and work on my odroid then...
[01:16:26 CEST] <jkqxz> That's valgrind.  Is it valgrind-clean on aarch64?
[01:17:08 CEST] <ldts> sorry I havent been checking it after the initial implementation
[01:18:22 CEST] <ldts> will test now
[01:19:47 CEST] <ldts> same command than before?
[01:20:40 CEST] <jkqxz> Yes.
[01:20:56 CEST] <ldts> --leak-check=yes?
[01:22:35 CEST] <jkqxz> Should be irrelevant, but I ran with full.
[01:23:13 CEST] <jkqxz> Looks some packets are being leaked as well.
[01:23:58 CEST] <ldts> http://paste.ubuntu.com/25688964/
[01:24:46 CEST] <ldts> ok I'll have to look into this more carefully
[01:25:20 CEST] <jkqxz> But you didn't have any invalid reads?
[01:25:29 CEST] <ldts> yes I did
[01:25:39 CEST] <ldts> same than yours
[01:25:56 CEST] <jkqxz> Right, ok.
[01:27:28 CEST] <ldts> I think the segfault fix should go in while I fix this. what do you think?
[01:31:45 CEST] <jkqxz> That this problem hasn't been understood properly.
[01:34:12 CEST] <ldts> isn't the problem statement to avoid closing the file descriptor until the last buffer reference is released? but ok, maybe we should discuss on the ML
[01:51:27 CEST] <ldts> jkqxz: interesting the same code on 3.3.3 gives http://paste.ubuntu.com/25689107/
[01:51:48 CEST] <ldts> jkqxz: same code, same test
[01:52:25 CEST] <ldts> jkqxz: instead of http://paste.ubuntu.com/25688964/
[03:00:04 CEST] <cone-507> ffmpeg 03James Almer 07master:cc5b7601f7c2: avformat/mp3enc: flush buffered packets if referencing fails
[03:43:12 CEST] <cone-507> ffmpeg 03Carl Eugen Hoyos 07master:a20f64bee235: lavf/img2dec: Auto-detect svg images.
[08:06:32 CEST] <rcombs> has anyone considered
[08:06:37 CEST] <rcombs> using nasm's preprocessor
[08:06:38 CEST] <rcombs> for ARM
[11:21:39 CEST] <cone-957> ffmpeg 03Sasi Inguva 07master:123f6dc6b563: lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.
[14:05:50 CEST] <ubitux> ffplay is broken with ffmpeg -lavfi testsrc2=d=5:r=100 -r 100 -y /tmp/fps100.gif
[14:06:48 CEST] <ubitux> (the color are fucked but i'm talking about the timings)
[14:07:00 CEST] <ubitux> it's fine in firefox
[14:07:23 CEST] <ubitux> ah my bad, it's not
[14:07:47 CEST] <ubitux> i though a delay of 1 meant a sleep of 1/100 sec
[14:07:57 CEST] <ubitux> there is something weird going on here
[20:49:41 CEST] <cone-605> ffmpeg 03Carl Eugen Hoyos 07master:50462e3e5e32: lavf/sdp: Fix MIME-type for big-endian G.726.
[20:49:41 CEST] <cone-605> ffmpeg 03Carl Eugen Hoyos 07master:2386cfc1ae29: lavf/rtpenc: Add support for little-endian G.726.
[20:50:17 CEST] <cone-605> ffmpeg 03Carl Eugen Hoyos 07master:5d3e935728c1: lavfi: Rename local variables "main" as "master".
[23:28:13 CEST] <BBB> j-b: ping
[23:28:42 CEST] <j-b> BBB: pong?
[23:35:04 CEST] <atomnuker> speaking of which, j-b, are the vdd talks going to be uploaded to youtube?
[23:35:27 CEST] <j-b> atomnuker: uhh, why not
[23:35:57 CEST] <durandal_1707> effort!
[00:00:00 CEST] --- Sun Oct  8 2017