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

[burek]

[01:02:24 CEST] <jkqxz> wm4:  I think draw_horiz_band really is fatal to this.  It appears to be an eldritch horror from the past (and won't work with modern codecs or threading), but I imagine some people will be attached to it.
[01:22:31 CEST] <jkqxz> Hmm, the wrapped_avframe decoder is also evil in this respect.  (And what idiot added that one?)
[01:29:28 CEST] <wm4> retarded shit
[01:29:44 CEST] <wm4> I value a cuvid hwaccel and working videotoolbox more
[01:31:22 CEST] <jkqxz> Sounds like you need opaque_opaque_ref.
[01:32:57 CEST] <wm4> or fuck this shit and just use Libav
[02:43:28 CEST] <cone-673> ffmpeg 03Kaustubh Raste 07master:51ebce7d7d61: avcodec/mips: Cleanup unused functions
[05:24:53 CEST] <cone-726> ffmpeg 03Luca Barbato 07master:1e2783726570: rtsp: Move message parsing to a separate function
[05:54:41 CEST] <rcombs> looking into some mechanisms to handle poor OTA input better
[05:54:53 CEST] <rcombs> specifically, the case of timestamps coming in corrupted
[05:55:32 CEST] <rcombs> probably gonna go with an option to discard input timestamps if AV_PKT_FLAG_CORRUPT is set, and also set AV_PKT_FLAG_CORRUPT when the MPEGTS TEI flag is set
[10:16:41 CEST] <ilyanov> ffmpeg  3.3.3  no longer has the file "avformat-55.dll"  contained in it. Why?
[10:42:03 CEST] <nevcairiel> thats because its 56 now
[10:44:16 CEST] <nevcairiel> or actually 57 already
[10:49:43 CEST] <ilyanov> nevcairiel   here is output from a ffprobe  on an m4a file
[10:49:49 CEST] <ilyanov> http://dark-code.bulix.org/tfov1m-205560
[10:50:05 CEST] <ilyanov> "encoder         : X Lossless Decoder 20151214, QuickTime 7.7.3"
[10:50:22 CEST] <ilyanov> I think that ffmpeg cannot decode this format.  true?
[10:50:41 CEST] <nevcairiel> its just alac, should work fine
[10:50:48 CEST] <nevcairiel> also, user support is in #ffmpeg, not here
[17:13:47 CEST] <cone-310> ffmpeg 03Tobias Rapp 07master:62bdec806ecd: avfilter/vf_fps: add eof_action filter option
[20:36:33 CEST] <cone-113> ffmpeg 03Marton Balint 07master:7d141e2cacb4: avdevice/decklink_dec: fix extracting luma
[22:12:35 CEST] <ubitux> nevcairiel: the ER doesn't work with libav, the recovery code was dropped/never introduced
[22:12:44 CEST] <ubitux> at least the reconstruction part
[22:12:56 CEST] <ubitux> (i remember because it was pretty annoying with the merges)
[22:12:59 CEST] <nevcairiel> heh
[22:13:13 CEST] <nevcairiel> well that sample shows that it actually does something useful
[22:32:37 CEST] <jamrial> ubitux: did you have time to test the merge?
[22:32:40 CEST] <jamrial> i'll not push it until 3.4 is branched off master, btw
[22:32:46 CEST] <jamrial> so no hurry
[22:32:52 CEST] <jamrial> even if we test it enough right now, there's always the chance some specific library/module configuration could end up missing one ldflag
[22:32:57 CEST] <ubitux> nope sorry not yet
[22:33:04 CEST] <ubitux> that's the extralib thing?
[22:33:05 CEST] <jamrial> and i don't want to cherry pick such fixes for 3.4
[22:33:07 CEST] <jamrial> yeah
[22:33:10 CEST] <ubitux> i had a quick look but that's all
[22:35:16 CEST] <jamrial> ok, thanks
[22:35:50 CEST] <jamrial> we're pretty close to the bump :D
[22:36:12 CEST] <jamrial> spring? cleaning season upcoming
[22:52:14 CEST] <wm4> I want the hardware decoding stuff in 3.4
[23:39:07 CEST] <ldts> jkqxz: hi
[23:45:50 CEST] <jkqxz> ldts:  Hi.
[23:46:13 CEST] <ldts> ah I was just sending the result of your test on my boards with some info
[23:46:31 CEST] <ldts> I dont see the problem with the patch applied
[23:47:29 CEST] <jkqxz> I'm just doing a clean build now.
[23:47:36 CEST] <ldts> ah ok. thanks
[23:48:14 CEST] <jkqxz> (Takes a while to build.)
[23:48:33 CEST] <ldts> yeah..do you use ccache?
[23:48:34 CEST] <jkqxz> Do you have an exynos to test on?
[23:49:02 CEST] <ldts> I have one but cant find the freaking supply...I have a tonne for 5 v 2A but no 5V 4A so it wont boot...
[23:49:41 CEST] <ldts> unfortunately this morning we didnt test on exynos (the guy had to leave) so we only tested on imx6 and db410
[23:50:05 CEST] <ldts> but I think this particular use case should be independent from the hardware
[23:50:23 CEST] <ldts> this is the string I want to see: [h264_v4l2m2m @ 0xaaaadd3bbb50] ff_v4l2m2m_codec_end leaving pending buffers 
[23:51:08 CEST] <ldts> it means we deteced the user wanted to close the codec with a pending reference
[23:51:16 CEST] <ldts> so we wont close the file descriptor
[23:51:26 CEST] <ldts> then when the buffer is released we do a proper close
[23:52:02 CEST] <ldts> [I will buy a supply next week when I relocate to my new office - moving 1000Km north)
[23:52:12 CEST] <jkqxz> It happens in both cases - see the log I sent for one with it failing.
[23:52:39 CEST] <ldts> yes in one case it was an error in the other case it was a debug message
[23:52:50 CEST] <ldts> can you differentiate them in the trace? different colors?
[23:53:50 CEST] <jkqxz> Gah, it doesn't build with --disable-optimizations.  Oh well, so much for debuggability...
[23:54:06 CEST] <wm4> lol
[23:54:22 CEST] <ldts> ? I always build : ./configure --disable-optimizations --disable-stripping
[23:54:25 CEST] <jkqxz> (asm impossible constraint things.)
[23:54:38 CEST] <jkqxz> "src/libavutil/arm/intmath.h:77:5: error: impossible constraint in asm"
[23:54:39 CEST] <ldts> I am building on arm64
[23:54:52 CEST] <ldts> all the boards I use are arm64...
[23:55:06 CEST] <jkqxz> This is 32.  (Hence also the PRId64 patch I sent yesterday...)
[23:55:13 CEST] <ldts> yeah, thanks for that!
[23:56:11 CEST] <jkqxz> I definitely had the message in both cases.  I don't remember if it was a different colour.
[23:58:31 CEST] <ldts> yes but in the case where is an error message I made the mistake of removing the return 0 (when I went from patch v12 to patch v13)
[23:59:26 CEST] <ldts> I will be very surprised if this doesnt work on your board...the use case is very straightforward
[23:59:44 CEST] <ldts> but I'll wait. this has to be fixed obviously
[00:00:00 CEST] --- Sat Oct  7 2017