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

[burek]

[00:12:54 CET] <TD-Linux> sega cd titles mostly did cinepak in software iirc
[00:14:39 CET] <atomnuker> hardcore, but IIRC the sega cd was more powerful than a regular mega drive
[00:14:41 CET] <TD-Linux> PS1 only had built in motion jpeg. many wii titles were still motion jpeg in 2006...
[00:15:11 CET] <atomnuker> odd, considering the ds had a special codec
[00:15:33 CET] <c3r1c3-Win> Yeah, I remember that about the Wii. Wasn't Bink also kinda big at that time as well?
[00:15:35 CET] <TD-Linux> no, ds had no special decoder either, all that was software
[00:15:42 CET] <JEEB> bink has always been big in gaming
[00:15:52 CET] Action: JEEB has quite a few games with bink/bink2 stuff
[00:16:04 CET] <TD-Linux> yeah there might have been some bink titles for both, I don't remember. both were pretty potato, wii had a ppc750 with no altivec
[00:16:04 CET] <atomnuker> yeah, I meant a ds-tuned codec that was done in software
[00:16:19 CET] <JEEB> criware had middleware for all of those nintendos
[00:16:23 CET] <TD-Linux> yeah, actimagine
[01:06:12 CET] <cone-758> ffmpeg 03James Almer 07master:936a4c04b9fd: avformat: remove unnecessary AVStreamParseType enum offset
[01:24:49 CET] <atomnuker> -flags +bitexact isn't working for opus anymore
[01:43:01 CET] <SortaCore> I thought ffmpeg doesn't use any version of intel sdk?
[01:43:37 CET] <SortaCore> I'm getting linker errors unless I #pragma comment the libmfx.lib
[01:43:51 CET] <jamrial> atomnuker: opus decoder? it never worked with it. it alwyas outputs fltp
[01:44:07 CET] <atomnuker> no, the encoder
[01:44:21 CET] <atomnuker> it used to work, I could always get md5 exact
[01:44:32 CET] <atomnuker> it doesn't seem to be the packets that are different
[01:44:43 CET] <atomnuker> lavf seems to not be doing something bitexact
[01:46:43 CET] <jamrial> you can't get bitexact output from opusenc, it's a float encoder...
[01:47:03 CET] <jamrial> also, for lavf you need to use -fflags
[01:47:28 CET] <jamrial> -flags is decoder/encoder, -fflags is muxer/demuxer
[01:52:48 CET] <atomnuker> well, not bitexact universally on every machine but certainly locally
[01:52:55 CET] <atomnuker> thanks, -fflags works fine
[02:08:09 CET] <atomnuker> actually it would be bitexact universally if everyone used standard ieee non-extended precision floats
[02:09:12 CET] <atomnuker> but arm can have either those or its non-standard floats (which sacrifice NaN to get more precision)
[02:10:01 CET] <atomnuker> and gcc can run the fpu instead of sse with full 80 bit precision
[02:27:01 CET] <jkqxz> philipl:  <http://sprunge.us/gjUD>.  Not too bad!
[02:27:19 CET] <jkqxz> The formats on the Intel driver are horrible, though.  You really do have to use IMC3 rather than NV12, etc.
[02:27:32 CET] <jkqxz> So I need to work out what to do with that before sending it further.
[02:28:14 CET] <jkqxz> But that patch is enough to encode an 4:2:2 MJPEG stream from a UVC webcam with ~zero CPU.
[02:32:21 CET] <atomnuker> jkqxz: just curious, is it faster than software for really big images (e.g. 10k x 10k and up)?
[02:45:56 CET] <jkqxz> Max 8192x8192.
[02:46:07 CET] <jkqxz> Let me try making some to test, I guess?
[02:46:19 CET] <jkqxz> I doubt it, though.
[02:51:53 CET] <jkqxz> Looks like yes?  My 8192x8192 YUV 4:2:2 images decode at about 7fps on the CPU, about 11fps on the GPU (including a big scale-down to force it to actually decode the images).
[02:55:18 CET] <jkqxz> No, that will be rubbish.  It's a debug build.
[02:57:52 CET] <jkqxz> Up to 10fps.  GPU still wins, just.
[03:01:11 CET] <atomnuker> nice
[03:06:48 CET] <jkqxz> Remember that the MJPEG decode has no threading, too.
[03:07:02 CET] <jkqxz> If you want fast MJPEG decodes there are very low-hanging fruit.
[04:39:36 CET] <cone-714> ffmpeg 03DHE 07master:ae61bcbdf83a: ffmpeg_filter: use nb_threads=1 on unused filtergraph
[04:39:36 CET] <cone-714> ffmpeg 03Vitaly _Vi Shukela 07master:80ef3c836018: ffmpeg: Allow "-to" on input files in addition to "-t"
[04:39:36 CET] <cone-714> ffmpeg 03James Cowgill 07master:0ecb1c53c8dc: avformat/dashenc: fix min_seg_duration option size
[04:43:29 CET] <philipl> jkqxz: I wonder if there's any 422 support in nvdec. It certainly doesn't work for other decoders, but maybe it would for mjpeg
[04:44:45 CET] <philipl> jkqxz: the cuviddec decoder accepts 422 input but it's still producing nv12 output frames
[06:04:07 CET] <philipl> jkqxz: nvdec needs the entire AVPacket. If I change your hooks to pass that it works. I think the thing to do here is pass the whole packet to start_frame and then I'll have the nvdec hwaccel grab the buffer from start_frame and not use decode_slice.
[06:04:21 CET] <philipl> That's how the mpeg4 hwaccel is used by vdpau (and presumably will be by nvdec when I finally get it working)
[10:21:09 CET] <durandal_1707> were those vorbis encoder improvements from gsoc being merged?
[11:31:12 CET] <jkqxz> philipl:  Can you make it produce non-downsampled output?  I'm not sure the sw_pix_fmt setup is going to like always getting NV12.
[11:38:53 CET] <nevcairiel> nvdec doesnt support anything but nv12/p010 output
[11:39:10 CET] <nevcairiel> the output format enum just doesnt have any others
[12:01:13 CET] <BtbN> well, the output enum only has NV12 and P016
[12:01:24 CET] <BtbN> But in 10 bit mode P016 pretty much is P010
[12:01:44 CET] <BtbN> And I have no idea how it's called in 12 bit mode.
[12:02:04 CET] <BtbN> But no, one cannot get anything but yuv420 out of it
[12:02:07 CET] <nevcairiel> thats why P010/P016 were defined the way they are, they can alias each other without too much issues
[12:03:21 CET] <BtbN> I remember there being an issue with ffmpeg and nvidia not agreeing on where to put the data, so if the msb or the lsb are 0
[12:03:29 CET] <BtbN> but not sure in which context that was
[12:03:34 CET] <BtbN> I think it was 12 bit input into nvenc?
[12:51:49 CET] <cone-714> ffmpeg 03Paul B Mahol 07master:e679ac8d7c74: avfilter: add acontrast filter
[13:38:34 CET] <LongChair> would soemthing be broken in current master ? i'm getting this :
[13:38:40 CET] <LongChair> https://www.irccloud.com/pastebin/COjwkpYp/
[13:39:13 CET] <LongChair> seems like audio_frame_queue.c isn't built
[13:43:48 CET] <jdarnley> LongChair: Do you have a weird configure line?  Do you disable many things?
[13:44:14 CET] <LongChair> i have some configure options ... but was working fine until now 
[13:44:28 CET] <LongChair> any option that woudl be required for this ? 
[13:45:00 CET] <jdarnley> A quick `git grep audio_frame_queue` shows that several things in configure will select it.
[13:45:58 CET] <jdarnley> Oh, when you say just now do you mean the commit ~1hr ago?
[13:46:17 CET] <LongChair> well i just pulled it
[13:46:31 CET] <jdarnley> Let me pull todays commits and recheck
[13:49:45 CET] <jdarnley> No.  I can still do a static build just fine
[13:50:11 CET] <LongChair> lemem grab the configure line 
[13:50:29 CET] <jdarnley> but it seems unlikely that that shared libs would make a difference here
[13:51:48 CET] <LongChair> itmight be one of teh flags, but should then fail at configure with proper message :)
[14:00:37 CET] <LongChair> jdarnley: i'll post that in a few when another package has finished building :)
[14:03:42 CET] <jdarnley> okay
[14:27:15 CET] <LongChair> jdarnley: --disable-static --enable-shared --enable-version3 --disable-doc --enable-debug --disable-stripping --disable-armv5te --disable-armv6t2  --disable-ffprobe  --disable-ffplay  --disable-ffserver   --disable-devices --enable-gnutls --enable-vaapi --disable-encoders --enable-encoder=ac3  --disable-muxers --enable-muxer=spdif --disable-indevs --disable-outdevs  --disable-altivec --disable-symver
[14:35:37 CET] <jdarnley> I'll try
[14:36:44 CET] <jdarnley> FYI: on x86 several of those options are pointless
[14:41:44 CET] <jdarnley> Ah ha!  I can reproduce
[14:50:08 CET] <jdarnley> Yep.  New codec in aptx.c is the problem.
[14:57:48 CET] <jdarnley> LongChair: as an immediate solution use --disable-decoder=aptx --disable-encoder=aptx
[15:17:17 CET] <jkqxz> jdarnley:  Are you fixing that?  (I will if you don't.)
[15:17:32 CET] <jdarnley> Yeah, I've just sent an email.
[15:18:18 CET] <jdarnley> Yes I am.  I've just sent an email.
[15:19:57 CET] <jkqxz> I don't see it yet, but if it's <http://sprunge.us/cjaS> then just push it.
[15:20:24 CET] <jdarnley> It is
[15:20:38 CET] <JEEB> LGTM
[15:20:52 CET] <JEEB> since it definitely depends on it ;)
[15:21:13 CET] <cone-714> ffmpeg 03James Darnley 07master:0b7cd29d47a3: configure: add audio_frame_queue dependency for aptx codec
[15:22:01 CET] <JEEB> also replied on the ML
[15:22:04 CET] <JEEB> so we just get a LGTM there as well
[15:22:13 CET] <jdarnley> thanks
[15:22:30 CET] <jkqxz> And I get the initial message and the cvslog one together.  Oh well.
[16:04:53 CET] <philipl> jkqxz: In my test, nothing barfed when the hwaccel insisted on returning nv12.
[17:39:02 CET] <cone-714> ffmpeg 03Michael Roitzsch 07master:4f4e19914ddc: lavfi/af_pan: fix sign handling in channel coefficient parser
[17:42:10 CET] <philipl> jkqxz: Have nvdec vp8 hwaccel working with your hooks patch
[17:42:21 CET] <philipl> BtbN: Only mpeg4 remains obnoxiously out of reach.
[17:44:30 CET] <atomnuker> the least popular mpeg codec anywhere
[17:44:49 CET] <nevcairiel> yeah should just leave mpeg4 be, its all sorts of crazy
[17:45:18 CET] <JEEB> hmm, does this look like incorrect API usage? mostly the straight unref after failure https://github.com/mpv-player/mpv/blob/master/video/decode/d3d.c#L97..L113
[17:45:32 CET] <JEEB> since a guy is getting a segfault inside that av_buffer_unref
[17:45:53 CET] <JEEB> https://pastebin.com/MtWTEgmc
[17:46:12 CET] <philipl> nevcairiel: It's become a personal fight at this point.
[17:46:31 CET] <JEEB> (also I'm surprised how decent the backtrace is)
[17:49:35 CET] <JEEB> wonder if that ID3D11Device_AddRef() adds some funky reference somewhere which then kills the thing if lavc starts destroying the hwcontext
[17:54:30 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commits/nvdec
[17:55:14 CET] <BtbN> wait, there are mjpeg hwaccel hooks?
[17:56:05 CET] <philipl> jkqxz wrote some yesterday
[18:09:02 CET] <jamrial> JEEB: mmh, if initialization within av_hwdevice_ctx_init() fails, it calls HWContextType.device_uninit() before returning
[18:09:07 CET] <jamrial> av_buffer_unref(&device_ref) afterwards will call the internal free function, that also calls HWContextType.device_uninit()
[18:09:21 CET] <jamrial> that apparently is Not Good(tm)?
[18:09:26 CET] <JEEB> ah
[18:09:39 CET] <nevcairiel> its the only way to free such a struct, anyway
[18:09:45 CET] <jamrial> i see CloseHandle() in d3d11va_device_uninit(), as pointed in that backtrace
[18:10:03 CET] <JEEB> yup
[18:10:42 CET] <JEEB> so it most likely has nothing to do with the AddRef and no release there
[18:11:05 CET] <nevcairiel> it seems a bit odd that those uninit functions never null out the things
[18:13:55 CET] <JEEB> yea
[18:17:21 CET] <philipl> I have recognisable pixels on the screen!
[18:20:49 CET] <jamrial> JEEB: https://pastebin.com/6GAq95gk may be and awful hack, and may not even work as intended, or make things worse :p
[18:21:04 CET] <JEEB> :D
[18:22:13 CET] <JEEB> let me make that into a build and pass on to the unfortunate person having these init failures
[18:22:39 CET] <nevcairiel> really all of those things it frees should probably be NULLed out if this can be called twice
[18:22:53 CET] <jamrial> yeah
[18:22:59 CET] <nevcairiel> although i have no idea how it can even fail
[18:23:32 CET] <nevcairiel> unless the device in question maybe has no video support
[18:23:45 CET] <nevcairiel> not sure how exactly it would fail then
[18:24:26 CET] <JEEB> it seems to only fail with the non-copyback configuration in mpv
[18:24:43 CET] <JEEB> and it seems to be specific to that user
[18:25:38 CET] <JEEB> would have to add some more logging to get the reasoning from the init()
[18:25:51 CET] <nevcairiel> well its not going to work either way if it fails there, so he might as well stop trying to use it
[18:25:54 CET] <jamrial> CloseHandle() documentation says "If the application is running under a debugger, the function will throw an exception if it receives either a handle value that is not valid or a pseudo-handle value. This can happen if you close a handle twice"
[18:26:45 CET] <jamrial> so it should not normally crash for trying to close the handle a second time
[18:27:01 CET] <JEEB> ok, then the crash itself without a debugger probably happened later
[18:34:04 CET] <JEEB> now to wait for results
[19:17:45 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commits/nvdec now including mpeg4
[19:18:03 CET] <BtbN> you figured out where to get all the weird stuff it wants?
[19:18:05 CET] <philipl> Once jkqxz has the vp8 and mjpeg hooks in, we will have full coverage
[19:18:09 CET] <philipl> Yeah, after much suffering
[19:18:54 CET] <philipl> and some of it is blind assumption. eg: packed b-frames means divx_flags = 5. No ide if there are other meaningful flag values.
[19:19:28 CET] <BtbN> that can be fixed as it comes up
[19:19:31 CET] <philipl> Yeah
[19:19:39 CET] <BtbN> my vaapi hevc implementation had two major functions broken for almost a year
[19:19:41 CET] <BtbN> until someone noticed
[19:20:13 CET] <philipl> heh. I'm pretty sure most of the divx and general mpeg4 edge cases has slid into extinction over the decades.
[19:20:32 CET] <philipl> the mpeg1 and common logic patches are on the ml if you could review them please.
[19:20:45 CET] <atomnuker> oh wow, I never noticed we had mpeg4 hwaccels at all
[19:21:00 CET] <atomnuker> especially vaapi, my skylake doesn't even support mpeg4 through vaapi
[19:21:17 CET] <atomnuker> (did they drop support for it with later CPUs?)
[19:27:20 CET] <philipl> BtbN: -1 is casted to 255 when going from int to unsigned char. I actually looked up the C spec for it
[19:28:00 CET] <jkqxz> No, Intel never had it.  It kindof works a bit on AMD/Mesa, but they basically said "this is broken shit, we don't support it" and disabled it unless you set a special environment variable.
[19:28:28 CET] <BtbN> scary stuff
[19:30:11 CET] <nevcairiel> so why was it ever implemented in ffmpeg? =p
[19:30:47 CET] <nevcairiel> someone must've once had a use for it
[19:30:58 CET] <nevcairiel> mpeg4 is a too screwed up format for hardware accel, really
[19:31:53 CET] <jkqxz> I think some of the non-Intel Intels supported it better, a long time ago.
[19:33:17 CET] <jkqxz> So Intel did have an interest in it at one point.
[19:52:05 CET] <cone-714> ffmpeg 03Gyan Doshi 07master:e75fe0ef2130: avformat/subfile: allow to extract till EOF
[21:19:50 CET] <cone-714> ffmpeg 03Paul B Mahol 07master:460df96904b7: avfilter: fix indentation
[21:21:00 CET] <cone-714> ffmpeg 03Paul B Mahol 07master:69cbebbd3d44: avfilter/af_surround: add some more layouts
[22:16:00 CET] <cone-714> ffmpeg 03James Almer 07master:c6f7eb86639f: configure: fix module dependencies on zlib
[23:53:29 CET] <cone-714> ffmpeg 03Martin Storsjö 07master:3152058bf1dc: libavcodec: Don't use dllexport, only dllimport when building DLLs
[23:53:30 CET] <cone-714> ffmpeg 03James Almer 07master:c9cd990dcc8e: Merge commit '3152058bf1dca318898550efacf0286f4836cae6'
[00:00:00 CET] --- Mon Nov 20 2017