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

[burek]

[00:56:48 CEST] <cone-812> ffmpeg 03Andreas Cadhalpun 07master:97792e85c338: fate: add apng encoding/muxing test
[00:56:48 CEST] <cone-812> ffmpeg 03Andreas Cadhalpun 07master:890eb3d7c477: configure: make sure LTO does not optimize out the test functions
[01:07:04 CEST] <Compn> jamrial : working together is the important part. a project will die if no one can work together...
[04:57:58 CEST] <cone-472> ffmpeg 03Philip Langdale 07master:7c27da686c06: crystalhd: Reorder mspeg4 decoder after software decoders
[05:05:12 CEST] <philipl> michaelni: I've pushed the decoder ordering fix. Would be most appreciative if you could repeat your testing with the crystalhd patches.
[10:12:27 CEST] <michaelni> philipl, seems to pass fate fine now
[10:19:46 CEST] <rcombs> michaelni: re: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201868.html did you apply the previous patches in the series?
[10:20:14 CEST] <sopparus> is that henrik guy from ML here?
[10:20:35 CEST] <rcombs> sopparus: nevcairiel?
[10:21:24 CEST] <sopparus> hendrik leppkes
[10:22:01 CEST] <rcombs> yeah that's your guy
[10:22:36 CEST] <sopparus> ok thanks, ping @nevcairiel :)
[10:22:44 CEST] <michaelni> rcombs, i thougt i did but ill retry
[10:23:01 CEST] <rcombs> michaelni: that looks like the issue I'd expect you to get if the first patch in the series was missing
[10:23:09 CEST] <rcombs> and I don't get that locally
[10:23:24 CEST] <rcombs> but it could be something else broken, ¯\_(Ä)_/¯
[10:26:24 CEST] <nevcairiel> sopparus: whats up?
[10:27:31 CEST] <sopparus> nevcairiel, Hi. I noticed you reviewd that openssl tls 1.2 patch, I cant respond to the ml, but here is a copy paste from that guide that made it
[10:27:34 CEST] <sopparus>  I think this patch from ffmpeg is not good. It works for you but all other users using TLS v1.0 will stay on dry with it because TLS v1.0 is not supported anymore. The problematic line is SSL_CTX_set_options which disables v1.0. Without this line both versions are supported but higher version has precedence (I think). You can write something on ffmpeg ml.
[10:28:20 CEST] <nevcairiel> without that line it also allows sslv2/3, which we do not want
[10:29:34 CEST] <jkqxz> After that line, the SSL context should have SSLv2 and SSLv3 disabled; TLSv1, TLSv1.1 and TLSv1.2 enabled.
[10:30:04 CEST] <nevcairiel> all the docs I could find suggest that using the SSLv23_method and blacklisting v2 and v3 afterwards should allow TLS 1.0, 1.1 and 1.2
[10:31:25 CEST] <jkqxz> The method name is really quite unhelpful, but hysterical raisins and all that.
[10:31:40 CEST] <rcombs> on newer OpenSSL versions you can use TLS_client_method
[10:32:08 CEST] <sopparus> my build with jkqxz slightly modified tls 1.2 patch just finished and it does work with tls 1.0
[10:33:03 CEST] <nevcairiel> so nothing to worry about then
[10:33:25 CEST] <jkqxz> rcombs:  On 1.1, huh.  I didn't know about that.  Maybe in a few years...
[10:33:35 CEST] <rcombs> curl does an #if around it
[10:33:48 CEST] <nevcairiel> the current thing works, even if its unintuitive
[10:34:14 CEST] <sopparus> yeah with that patch 1.0, 1.1 and 1.2 works
[10:34:22 CEST] <sopparus> tested all three. without it only 1.0 works
[10:34:31 CEST] <sopparus> thanks guys
[10:35:01 CEST] <rcombs> yeah
[10:36:47 CEST] <rcombs> "Version 1.0.2 will be supported until 2019-12-31 (LTS)."
[10:36:47 CEST] <rcombs> fun
[10:37:34 CEST] <jkqxz> I'll add a comment to the patch explaining what it's doing.
[10:50:54 CEST] <michaelni> rcombs, http://pastebin.com/Fi38mBNF
[10:51:44 CEST] <rcombs> &wacky
[10:51:58 CEST] <rcombs> just the one packet, and consistent about it
[10:52:44 CEST] <michaelni> probably some off by 1 error
[10:53:00 CEST] <michaelni> rounding or so maybe ?
[10:53:14 CEST] <rcombs> maybe? But everything involved should be bitexact, right?
[10:53:47 CEST] <rcombs> is there a mode to do framecrc with -c copy
[10:53:54 CEST] <michaelni> is this using float aac ?
[10:54:15 CEST] <nevcairiel> its codec-copy
[10:54:25 CEST] <rcombs> oh, I guess I can just stick `-c copy` on the end
[10:54:39 CEST] <nevcairiel> or should be anyway
[10:54:41 CEST] <rcombs> since fate-run.sh doesn't do anything too magical with it
[10:54:48 CEST] <rcombs> there's precedent for it
[10:56:43 CEST] <rcombs> michaelni: try this on top of the existing patch? https://gist.github.com/683b152feeef90678547586ec1c29f74
[10:57:12 CEST] <rcombs> removing the codecs from the test makes enough sense here
[10:57:42 CEST] <nevcairiel> it actually wrote pcm into the mkv?
[10:58:18 CEST] <nevcairiel> guess that involved quite a few conversion steps then
[10:58:41 CEST] <rcombs> nah, it was just decoding on the way into framecrc
[11:00:26 CEST] <nevcairiel> right, still float decoding and float -> pcm conversion
[11:00:41 CEST] <nevcairiel> float -> int
[11:00:42 CEST] <nevcairiel> i mean
[11:01:32 CEST] <rcombs> in theory that can be bitexact reproducible!
[11:01:49 CEST] <rcombs> (in practice, yeah, I highly doubt the bulk of lavc's float code is)
[11:12:17 CEST] <fritsch> mmh, some of our users have dts wavs in flacs
[11:12:29 CEST] <fritsch> we decode them, which ends up in floatp
[11:12:34 CEST] <fritsch> and then output it as 32 bit int 
[11:12:39 CEST] <fritsch> and -> avr still gets dts :-)
[11:12:46 CEST] <fritsch> so, not that bad as one could assume
[11:13:04 CEST] <fritsch> the lavc's float code
[11:14:55 CEST] <nevcairiel> why do you decode flac to float
[11:15:08 CEST] <nevcairiel> its a lossless integer format
[11:16:56 CEST] <rcombs> fuck those people, though
[11:17:12 CEST] <fritsch> hehe, yeah
[11:17:13 CEST] <nevcairiel> also that
[11:17:36 CEST] <nevcairiel> i refuse to support double-packed formats like that
[11:17:53 CEST] <nevcairiel> dts-in-wav is bad enough but you can just feed it through a decoder and it works
[11:18:18 CEST] <nevcairiel> but two decoders for dts-in-flac .. well you can bit-exact stream it if you want, but thats all I give you =p
[11:18:55 CEST] <michaelni> rcombs, when run from subdir it seems to fil with: reference file 'tests/ref/fate/segment-adts-to-mkv-header-all' not found
[11:19:15 CEST] <michaelni> the patch fixed the previous issue though
[11:19:21 CEST] <rcombs> I don't know how to fix that
[11:19:51 CEST] <nevcairiel> maybe a different path somewhere?
[11:20:04 CEST] <rcombs> oh wait, yes I do
[11:21:07 CEST] <rcombs> https://gist.github.com/e6a084df159ecba15bfec73727240ab3
[11:21:52 CEST] <nevcairiel> that looks ok
[13:08:07 CEST] <ubitux> [] subtitles decoding | [] subtitles filtering | [ ] subtitles encoding
[13:08:09 CEST] <ubitux> @_@
[13:08:41 CEST] <ubitux> how do a/v encoders figure out their output packet size?
[13:09:29 CEST] <nevcairiel> carefully
[13:09:39 CEST] <nevcairiel> its a lot of guesswork
[13:09:40 CEST] <ubitux> for subtitles we have the user hard code a large value, in ffmpeg.c it's 1024*1024...
[13:10:02 CEST] <ubitux> nevcairiel: heuristics around bitrate etc?
[13:10:31 CEST] <ubitux> is that done by the framework before the encode? of the encoder themselves? what happens in case of a two small allocated pkt data buffer?
[13:10:42 CEST] <nevcairiel> the encoder has to take care of that
[13:11:04 CEST] <nevcairiel> and the heuristic is probably part of every encoder itself, but i think they can realloc them?
[13:11:30 CEST] <ubitux> OK so it's not up to the framework to figure out a potentially good enough packet size?
[13:11:55 CEST] <nevcairiel> dont think so
[13:12:36 CEST] <ubitux> ok, that's cool then
[13:12:36 CEST] <ubitux> thanks
[13:13:47 CEST] <nevcairiel> you can just call ff_alloc_packet2 with the size you want
[13:15:14 CEST] <nevcairiel> there is also the option for an internal buffer in avctx->internal->byte_buffer for temporary writing, some encoders use that apparently
[13:17:26 CEST] <ubitux> "some encoders" = mpegvideo? :p
[13:27:48 CEST] <ubitux> yeah right we should get rid of that field and put it in mpegvideo
[13:43:33 CEST] <ubitux> ...but in the meantime i'll use it temporarly for subtitles :°
[15:26:16 CEST] <Sam_> hi there
[15:27:11 CEST] <Sam_> i have downloaded the SimpleDLNA and added a video to test, but how to play it in VLC ?
[15:27:56 CEST] <Sam_> using the http://IP Given: port give/mm-3/ ?
[16:12:41 CEST] <DHE> Sam_: wrong channel
[16:44:39 CEST] <fritsch> Short question, is there a documentation which public ffmpeg methods (like sws_scale, resample, and so on) need to use buffers allocated with av_malloc?
[16:45:38 CEST] <fritsch> i sometimes run into alignment issues, especially with arm intrinsics used when e.g. format converting yuvj420p to e.g. rgba - and properly (manually) aligning buffers fixes these issues
[16:47:31 CEST] <nevcairiel> if in doubt, all of them
[16:47:31 CEST] <nevcairiel> :D
[16:47:40 CEST] <fritsch> hehe and now without kidding?
[16:47:44 CEST] <nevcairiel> i'm not
[16:48:30 CEST] <fritsch> okay, there is no guarantee if I do uint8_t* buffer = new uint8_t[whatever];
[16:48:39 CEST] <nevcairiel> anything that deals with uncompresse data should ideally be aligned, because uncompressed is very good for SIMD
[16:48:41 CEST] <fritsch> that this will heavily crash If I add that into ffmpeg?
[16:48:46 CEST] <nevcairiel> compressed data is probably fine otherwise
[16:48:53 CEST] <nevcairiel> so align AVFrame, dont care much about AVPacket
[16:49:22 CEST] <nevcairiel> i dunno how much protection we have against this
[16:49:29 CEST] <nevcairiel> swscale used to have some checks for aligned data
[16:49:33 CEST] <nevcairiel> not sure if its complete
[16:52:40 CEST] <fritsch> oki, I will carefully check :-(
[16:52:41 CEST] <fritsch> thx
[16:53:21 CEST] <nevcairiel> even if it has checks it'll massively cost you performance
[16:53:33 CEST] <nevcairiel> because it'll likely go to a C path
[17:31:41 CEST] <cone-966> ffmpeg 03Muhammad Faiz 07master:068653700227: avfilter/avf_showcqt: add bar_t option
[17:44:20 CEST] <wm4> indeed, it's unfortunately just better to stick to ffmpeg's crap when feeding it data
[17:44:57 CEST] <wm4> even AVPacket is very weird because it requires padding
[18:14:41 CEST] <jkqxz> So, what do we want to do with qsv?
[18:21:58 CEST] <wm4> drop it entirely
[18:29:51 CEST] <jamrial_> jkqxz: commit your libav sync work and resume merges, obviously
[18:33:46 CEST] <jkqxz> How do we become quorate to do that?
[18:34:09 CEST] <jkqxz> There have been zero responses to anything I sent to the ML.
[18:35:39 CEST] <jamrial_> jkqxz: not a lot of people can test it. i think RiCON is the only one that was able to so far
[18:35:40 CEST] <nevcairiel> are there any known failures remaining?
[18:35:53 CEST] <nevcairiel> other then the vc1 log spam, that is
[18:36:10 CEST] <jkqxz> jamrial_:  I assume you didn't get any response on Ivan Uskov?
[18:36:15 CEST] <jamrial_> jkqxz: if this fourth version works and nobody finds new failures, then just push it
[18:36:36 CEST] <jamrial_> jkqxz: no. i asked publicly, same as michaelni, and neither him or any other nablet dev replied
[18:36:51 CEST] <nevcairiel> i think he was even specifically CCed to some of the threads
[18:36:59 CEST] <jamrial_> cc'd him with the second ping, yeah
[18:38:47 CEST] <jkqxz> I don't have any known failures, but I can only test on Linux.  (Excepting a break of some hardware transcode cases in ffmpeg.c, which will get fixed a few patches on from the current merge point.)
[18:39:36 CEST] <nevcairiel> the transcode case barely worked as it is due to the bbroken buffering in the current ffmpeg implementation
[18:39:47 CEST] <nevcairiel> someone decided to buffer output surfaces instead of input data
[18:39:56 CEST] <nevcairiel> nevermind that the surfaces are a far more limited resource
[18:40:46 CEST] <jkqxz> Zeranoe: RiCON:  Can either of you test qsv with the current proposed patches on Windows?
[18:41:14 CEST] <nevcairiel> if all else fails i can probably dust off my laptop, it has an ivy bridge, assuming those are still supported =p
[18:45:33 CEST] <jkqxz> Yeah, the transcode stuff is why we want the proper hwcontext implementation.  Hacks in the current code just make some simple cases work badly.
[19:37:22 CEST] <Zeranoe> jkqxz: I can
[19:37:46 CEST] <Zeranoe> jkqxz: I haven't looked, but did you include those changes I suggested? I wont be able to test without them.
[19:42:25 CEST] <jkqxz> <https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195544.html>?  I have not, it should be a separate patch.
[19:42:52 CEST] <Zeranoe> That's the one
[19:43:21 CEST] <jkqxz> I agree it should be in, though.  Let me rebase it on top of what I've got.
[19:47:14 CEST] <cone-966> ffmpeg 03James Almer 07master:c4af48eb2716: configure: add missing fork() dependency to http_multiclient example
[19:55:28 CEST] <DHE> what version of git is everybody using? I ask because my client seems to have... certain behaviours I feel are wrong.
[20:02:27 CEST] <BtbN> whatever the package manager has.
[20:03:32 CEST] <DHE> hmm... probably user error then
[20:07:34 CEST] <BtbN> what are those certain behaviours?
[20:07:56 CEST] <BtbN> Unless you are on some ancient 1.7 or 1.8, you should be fine.
[20:32:06 CEST] <Zeranoe> jkqxz: Compiled fine with both patches. I'll do some testing now
[20:37:17 CEST] <DHE> BtbN: I am actually
[20:37:46 CEST] <DHE> what happened was it put a Date: header into the format-patch email which I didn't realize and I sent the patch to the mailing list dated 2 days ago.
[20:37:46 CEST] <BtbN> those certain wrong behaviours might be still "by design" then
[20:37:59 CEST] <DHE> 1.8.4.1
[20:38:18 CEST] <DHE> not huge, but still embarrassing
[20:42:06 CEST] <Zeranoe> jkqxz: No issues with '-c:v h264_qsv -look_ahead 0 -an' yet. Is there anything specific you'd like me to test?
[20:43:19 CEST] <jkqxz> Nothing specific, just everything :P
[20:43:30 CEST] <jkqxz> Or at least, everything which you had working before.
[20:44:36 CEST] <cone-966> ffmpeg 03Andreas Cadhalpun 07master:1e660fe88d2d: doc: fix spelling errors
[20:45:35 CEST] <Zeranoe> jkqxz: I only have a 4790K to test with so I cannot do anything with lookahead
[20:53:32 CEST] <Zeranoe> jkqxz: -q and -b:v both seem fine. No hangs yet
[20:54:04 CEST] <Zeranoe> veryslow and veryfast presets seem fine.
[20:54:38 CEST] <jkqxz> Do you normally have hangs when doing this?
[20:55:19 CEST] <Zeranoe> Not on my 4790K normally
[20:56:10 CEST] <Zeranoe> But who knows... I have yet to reproduce the hangs every time
[20:58:30 CEST] <Zeranoe> Everything seems fine so far. If you'd like me to test anything else let me know. I can also provide the binary to anyone who wants to test on another CPU.
[21:00:08 CEST] <BtbN> I'll make sure my next CPU won't have any QSV. Messed up stuff.
[21:01:52 CEST] <RiCON> so, a zen?
[21:02:20 CEST] <BtbN> Broadwell-E
[21:02:49 CEST] <BtbN> Being an Early-Adopter for Zen doesn't seem overly tempting.
[21:03:19 CEST] <Zeranoe> It seems like QSV is very disliked here. Why A) Was it included in the first place and B) is not removed from FFmpeg?
[21:04:55 CEST] <jamrial_> disliked by a dev or two doesn't mean it has no merit
[21:06:29 CEST] <jamrial_> not everyone has a discrete gpu after all
[21:06:32 CEST] <RiCON> jkqxz: hadn't tested encoding yet, ivy doesn't like default rc either
[21:06:52 CEST] <BtbN> It's just a bad API, with horrible issues.
[21:07:19 CEST] <durandal_1707> what happened with irc log bot, it appears dead?
[21:08:04 CEST] <jkqxz> It's the only way to get the best throughput out of the Intel codec hardware.  I would certainly avoid it for cases which aren't maximise-throughput.
[21:08:15 CEST] <jamrial_> durandal_1707: huh, you're right, logs haven't been posted for two days now
[21:09:09 CEST] <jkqxz> RiCON:  -b + -maxrate works?  (The different modes there are not helpful.)
[21:09:37 CEST] <RiCON> -look_ahead 0 works
[21:10:36 CEST] <jkqxz> A difference against libav that I preserved was lookahead being on by default.  Not sure where that came from, but someone might expect it.
[21:11:06 CEST] <RiCON> hevc doesn't segfault anymore, which is nice
[21:13:17 CEST] <jkqxz> Heh, that's the default plugin having been changed.  A plugin which doesn't exist can't crash on you :)
[21:16:19 CEST] <RiCON> not sure if i'm supposed to have a mpeg2 encoder available
[21:18:12 CEST] <wm4> Zeranoe: because removing stuff from ffmpeg is almost impossible because those who don't have to deal with it resist against removal (that's how it usually goes)
[21:19:05 CEST] <wm4> jkqxz: why is that, what restricts throughput with vaapi?
[21:19:53 CEST] <fritsch> wm4: you already have dma buf support for hevc-10 bit vaapi implemented?
[21:20:14 CEST] <fritsch> i started a bit today, but no hardware for the rendering part yet
[21:20:32 CEST] <jkqxz> RiCON:  Probably?  I think the hardware has been there forever but drivers might not give access to you it.
[21:21:24 CEST] <wm4> fritsch: no, but should be simple?
[21:21:41 CEST] <fritsch> not really
[21:21:45 CEST] <fritsch> P010
[21:21:51 CEST] <wm4> P010 is simple
[21:22:07 CEST] <fritsch> you looked which R8G8 R8 transfer methods you have?
[21:22:26 CEST] <wm4> shouldn't be any different from software P010 once you have the textzres
[21:22:27 CEST] <wm4> *textures
[21:22:32 CEST] <fritsch> i used 2 8s for Y and 2 8s for UV
[21:22:43 CEST] <fritsch> which should work
[21:22:51 CEST] <fritsch> from there creating the textures should be simple
[21:22:55 CEST] <wm4> and DRM format support is of course a precondition
[21:22:59 CEST] <fritsch> jep
[21:23:04 CEST] <fritsch> we don't have that
[21:23:09 CEST] <RiCON> jkqxz: anyway, hevc doesn't segfault, vc1 dec is still spammy with this sample but works, h264 enc/dec works, mpeg2 dec works, this on an ivy
[21:23:09 CEST] <wm4> then fuck it
[21:23:16 CEST] <fritsch> so trying to combine the given 8 bit versions
[21:23:17 CEST] <jkqxz> wm4:  Intel put more effort into optimising their proprietary stuff.  The open-source drivers get bottlenecked on the render unit operations at the moment, so the codec blocks are idle for a significant amount of the time.
[21:23:56 CEST] <wm4> fritsch: uh... oh yeah, let's implement ridiculous hacks to give the stupid consumer users theirt fucking bullshit
[21:24:05 CEST] <fritsch> hehe
[21:24:31 CEST] <fritsch> that's why I asked on how you gonna handle it
[21:24:36 CEST] <wm4> jkqxz: makes sense (PS fuck intel)
[21:24:40 CEST] <fritsch> the vaPutSurface way is "same" as before - as they convert internally
[21:24:45 CEST] <wm4> fritsch: if it's going to be that way, not at all
[21:25:02 CEST] <fritsch> yeah, will look in that part when capable hw appears
[21:25:57 CEST] <wm4> what's missing is a DRM_FORMAT_R16 (and GR16)
[21:28:29 CEST] <RiCON> jkqxz: according to wikipedia, mpeg2/vc1(?) only from haswell
[21:28:33 CEST] <wm4> latest kernel still doesn't define such a format, but I was DRM_FORMAT_MOD_SAMSUNG_64_32_TILE, which is completely unrelated, but makes me physically sick
[21:28:48 CEST] <wm4> excuse me while I vomit my dinner into the toilet in the name of technology
[21:33:35 CEST] <jkqxz> RiCON:  The i965 driver thinks it has an MPEG-2 encoder: <https://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_device_info.c#n146>.
[21:34:31 CEST] <jkqxz> It doesn't matter, though.  Wanting to use that encoder is surely a very clear indicator of total insanity.
[21:35:40 CEST] <fritsch> perhaps you can "check the workarounds" libyami does to get it behaving properly?
[21:48:30 CEST] <Zeranoe> jkqxz: Testing on a Skylake now
[21:52:37 CEST] <Zeranoe> jkqxz: Everything seems fine, along with look_ahead. Are any of your changes supposed to address hanging?
[21:55:27 CEST] <jkqxz> Not directly, but the inner decode loop has changed significantly.
[21:56:07 CEST] <Zeranoe> i havent got the hang yet
[00:00:00 CEST] --- Sun Oct 30 2016