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

[burek]

[00:02:40 CET] <SortaCore> https://pastebin.com/1y6u2e6E final patch :p
[00:02:57 CET] <nevcairiel> no, its not
[00:03:10 CET] <nevcairiel> you cant declare a variable there, they need to be at the top of the block
[00:03:47 CET] <nevcairiel> (ie. with all the other variables)
[00:05:00 CET] <BtbN> I hate shell
[00:05:18 CET] <BtbN> lets see how fast the other version actually is. Without millions of debug echos...
[00:05:18 CET] <nevcairiel> thats because shell is terrible for anything beyond simple automation
[00:05:26 CET] <SortaCore> int ret, resetCount; or int ret; [line break] int resetCount; ?
[00:07:30 CET] <nevcairiel> same line is probably ok
[00:07:57 CET] <cone-952> ffmpeg 03Aman Gupta 07master:b7f963c4444d: avcodec/videotoolbox: reorder functions to avoid forward declarations
[00:08:19 CET] <BtbN> The other approach also breaks, but differently and less severe. Hm
[00:09:37 CET] <SortaCore> one needs initialising and the other doesn't, so I'll keep separate
[00:09:47 CET] <BtbN> anyway, going to bed, more digging tomorrow
[00:10:34 CET] <jamrial> later
[00:11:12 CET] <cone-952> ffmpeg 03wm4 07master:9283a4f19b76: avcodec/videotoolbox: fix opaque_ref handling
[00:14:21 CET] <SortaCore> https://pastebin.com/raw/DkgnVmqZ this ok?
[00:26:27 CET] <cone-952> ffmpeg 03Muhammad Faiz 07master:8329ae781a75: avutil/crc: use ff_thread_once at av_crc_get_table
[00:28:38 CET] <tmm1> SortaCore: none of the other variables use camel case
[00:29:19 CET] <tmm1> also i might move the av_log before the reset, since the message says attempting not attempted
[00:29:49 CET] <tmm1> SortaCore: you should mention the ticket number in the commit message body
[00:31:22 CET] <SortaCore> what ticket number
[00:32:08 CET] <tmm1> https://trac.ffmpeg.org/ticket/5708
[00:45:18 CET] <kierank> JEEB: yeah insane
[00:47:25 CET] <SortaCore> ...why do functions and vars have the same convention
[00:47:37 CET] <JEEB> welcome to C
[00:48:24 CET] <SortaCore> I've not seen C done like that
[00:49:07 CET] <JEEB> C++ is a different animal
[00:56:20 CET] <SortaCore> h264_qsv doesn't seem to like flushing though
[00:57:04 CET] <SortaCore> probably those cabac/intra errors
[01:36:44 CET] <SortaCore> and the Intel reset does nothing, no idea why VLC uses it then
[01:38:13 CET] <tmm1> that's what i thought.. it didn't work last time i tried it
[02:16:59 CET] <SortaCore> the alternative is QSVEnc's method, which is all abstracted away with classes so I can't tell what it's actually doing
[03:00:16 CET] <tmm1> SortaCore: it just recreates the session
[03:33:27 CET] <cone-952> ffmpeg 03Steven Liu 07master:880b299381de: avformat/hlsenc: write fmp4 init header after first AV frame
[04:54:55 CET] <cone-952> ffmpeg 03Michael Niedermayer 07master:58cf31cee7a4: avcodec/x86/mpegvideodsp: Fix signedness bug in need_emu
[05:22:14 CET] <philipl> BtbN: which other nvdec hwaccels were you planning to add next? I'm happy to put some time into it - I want to do vc1 and vp8 as there are known cases there that the cuvid parser fails on (wmv3 and webp respectively)
[05:24:03 CET] <philipl> BtbN: of course, no one ever added vp8 hwaccel hooks, so maybe I can't be bothered there...
[05:25:09 CET] <philipl> jkqxz: never committed that?
[05:29:42 CET] <atomnuker> no, someone had webp concerns I think
[05:29:54 CET] <philipl> funnily enough.
[05:39:11 CET] <jamrial> vc1 is a good idea. i think someone mentioned the software decoder wasn't 100% correct
[05:40:56 CET] <philipl> jamrial: I'm working on it now
[06:02:20 CET] <philipl> alloc_frame_buffer in mpegpicture.c does a check that "if (pic->f->linesize[1] != pic->f->linesize[2]) {"
[06:02:50 CET] <philipl> For nv12, that's never going to pass
[06:02:56 CET] <philipl> How does this work for other hwaccels?
[06:04:55 CET] <philipl> but anyway - if I comment that check out, shit works. And I can decode wmv3 content too
[06:05:00 CET] <philipl> mission accomplished.
[06:06:00 CET] <philipl> HAH. For vdpau, all linesizes are zero.
[06:06:04 CET] <philipl> "problem solved"
[06:18:35 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/b4f9b68e6b30c3937bfd8809b004bc9aefb22607
[06:18:45 CET] <philipl> I'll send to mailing list after I have a proper fix for mpegpicture.c
[10:01:49 CET] <durandal_1707> atomnuker: write svg parser?
[10:28:30 CET] <BtbN> philipl, I think there are missing #if CONFIG_WMV3_NVDEC_HWACCEL around its hwaccel block
[10:28:40 CET] <BtbN> otherwise that looks sensible and way more straight forward than VP9
[10:30:18 CET] <BtbN> And I would indeed like to add VP8, I think someone already had made hwaccel hooks. Ideally I would like to finally have all the cuvid ones
[10:36:04 CET] <nevcairiel> i still think its wasted effort for vp8 =p
[10:36:26 CET] <nevcairiel> hardware support is rather spotty at best
[10:37:04 CET] <nevcairiel> they had it in maxwell but for some reason only *some* pascal cards inherited it, not all of them
[10:39:46 CET] <nevcairiel> it seems to be in the first-gen pascal chips and removed from newer variants, so it stands to reason future chips may not have it at all anymore
[10:42:55 CET] <robUx4> Intel CPUs also have VP8 decoding
[10:44:17 CET] <nevcairiel> but that is irrelevant for nvdec :p
[10:44:37 CET] <robUx4> indeed
[11:46:56 CET] <BtbN> VP8 in VAAPI is pure terror
[11:47:07 CET] <BtbN> In nvdec, the data it wants to decode VP8 is minimal
[11:47:21 CET] <BtbN> in vaapi it wants an insane amount of information
[12:07:27 CET] <nevcairiel> that has always been my experience even with dxva. any fields it can parse from the slice headers, it will, and you can basically leave those empty, while intel requires every single field to be filled perfectly, even if it could read it from slice headers - which in the beginning exposed a bunch of issues in the implementations :)
[12:11:59 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/compat/cuda/dynlink_cuviddec.h#L578
[12:12:03 CET] <BtbN> this is really small luckily
[12:12:56 CET] <BtbN> guess it just does parse everything else itself
[13:02:24 CET] <BBB> jamrial: can you review Avoid corrupting diagnostic state with _Pragma changes? I think youre the best review target for that patch
[13:20:26 CET] <J_Darnley> What are the y_ and uv_offset variables supposed to be testing in tests/checkasm/v210enc.c ?
[13:20:45 CET] <J_Darnley> Gramner: since you added it can you tell me?
[13:36:44 CET] <BtbN> ${!SOMEVAR} is bashism, is it?
[14:21:52 CET] <BtbN> jamrial, I think I fixed it for real this time. The other calls need to be in the same subshell obviously...
[14:22:24 CET] <BtbN> Just fighting with printf now
[14:22:37 CET] <BtbN> Cause that's how it prints stuff right now: EXTRALIBS-avcodec=-pthread-lm-llzma-lz-lfdk-aac-lx264-lva-ldl
[14:23:40 CET] <jamrial> cool
[14:23:50 CET] <BtbN> I'm not sure why on earth it does that though
[14:24:13 CET] <BtbN> Using echo instead of printf works, but has the risk of some library being interpreted as parameter to echo
[14:54:55 CET] <jamrial> BtbN: seems working
[14:55:02 CET] <jamrial> let me try windows
[15:22:18 CET] <jamrial> BtbN: you're calling unique twice now?
[15:22:52 CET] <BtbN> yes, otherwise you might end up with for example -lX11 being in there twice
[15:22:59 CET] <BtbN> Because in my case both vdpau and vaapi have it
[15:23:33 CET] <BtbN> Before the fix this was shadowed away
[15:23:39 CET] <jamrial> ah
[15:24:14 CET] <BtbN> And unique, resolve, unique is way faster than just resolve and then unique, as it removed a considerable amount of duplicates
[15:24:28 CET] <jamrial> mmh, seems it breaks macos stuff
[15:24:43 CET] <BtbN> I'd suspect those are broken dependencies then?
[15:24:51 CET] <jamrial> as each ld flag has -framework
[15:25:00 CET] <BtbN> oh...
[15:25:05 CET] <BtbN> great
[15:25:22 CET] <BtbN> Is it valid to link to a library multiple times?
[15:25:54 CET] <jamrial> yeah
[15:26:10 CET] <BtbN> Well, scratch that second unique then
[15:26:29 CET] <jamrial> i'm runnning configure again without it, to make sure it's good that way
[15:28:35 CET] <jamrial> yeah, looks good without it
[15:28:53 CET] <BtbN> it's a bit weird to have -lX11 twice
[15:29:08 CET] <BtbN> but I guess using a proper X11 dependency instead of having a bunch of libs just add -lX11 themselves will fix that
[15:30:35 CET] <jamrial> -lvpx is four times if you enable libvpx :p
[15:35:34 CET] <jamrial> but that has been the case for a long time now
[15:48:38 CET] <nevcairiel> the framework stuff has always been a problem
[15:48:56 CET] <BtbN> Can't it just be -framework=...
[16:00:15 CET] <philipl> jkqxz: are you going to revisit the vp8 hwaccel hooks? Last discussion I see on list was in June
[16:03:25 CET] <nevcairiel> many why is libtool so braindead stupid, or more precisely why did noone ever think of the usecase of building a shared library with its dependencies included statically
[16:03:48 CET] <JEEB> yea, that's /very/ often overlooked
[16:03:59 CET] <nevcairiel> f'ing libtool crap
[16:04:13 CET] <nevcairiel> now i have to manually make a .so file because this thing is dumb
[16:06:01 CET] <nevcairiel> it even tells me that it found static versions of those libraries it needs, why the fuck do you not just include them
[16:07:20 CET] <jkqxz> philipl:  I was going to tack them on to merging <https://lists.libav.org/pipermail/libav-devel/2017-November/085326.html> (because of 4/10).
[16:07:29 CET] <jkqxz> To try again.
[16:13:04 CET] <philipl> jkqxz: jolly good.
[16:39:56 CET] <cone-918> ffmpeg 03Aman Gupta 07master:91a565e20f0c: avformat/http: fix chunked response w/ multiple_requests=1
[16:50:17 CET] <Gramner> J_Darnley: just testing unaligned pointers probably. could've just used a static offset though, not really any need to randomize it
[16:53:27 CET] <J_Darnley> Thanks
[16:54:27 CET] <J_Darnley> I need aligned addresses anyway for my decoder test
[17:24:02 CET] <SortaCore> interesting, libmfxhw32.dll accesses near-null addresses if you continue with the reset 3 times thing
[17:24:42 CET] <tmm1> huh
[17:25:06 CET] <SortaCore> call stack becomes useless though so can't narrow down a ffmpeg function
[17:25:49 CET] <BtbN> sounds more like it heavily shits on the stack
[17:33:57 CET] <SortaCore> don't have a pdb for the libmfx dll though
[17:34:20 CET] <SortaCore> although I wouldn't put that past intel
[17:35:29 CET] <BtbN> I have also seen some driver-libs do ultra weird stuff with the stack. Like, knowing they would bust it, so they backed it up and started a new one. Which results in ultra weird backtraces if something explodes.
[17:37:37 CET] <SortaCore> hmm I should be saving more often
[18:13:51 CET] <tmm1> is there any reason vf_crop couldnt automatically use the params in metadata added by vf_cropdetect, so you could chain them together?
[18:22:37 CET] <BtbN> tmm1, because nobody added support for it
[18:30:30 CET] <SortaCore> trying to use intel's media sdk tracer to find the error, now it never occurs... again
[18:31:02 CET] <SortaCore> ofc the app is stalling six ways to sunday so it could just be the extra lag cancelling out a race condition
[18:44:28 CET] <tmm1> SortaCore: definitely feels like a race.. i tried to change that usleep in the loop to try to fix it but that didn't help either
[18:44:45 CET] <tmm1> maybe something stupid like a sleep after feeding the first frame would help
[18:45:12 CET] <SortaCore> I already have the RTSP set up not to send non-keyframes as first frame
[18:46:33 CET] <SortaCore> Does ffmpeg work with the 2017.0.1 Media SDK? atm I'm using 2016.0.2
[18:47:49 CET] <tmm1> it doesn't need the sdk to work
[18:47:55 CET] <tmm1> so, yes.
[18:49:27 CET] <SortaCore> even for static linking?
[18:50:17 CET] <SortaCore> and the only other question is why I'm getting so many decode errors on a rtsp over tcp stream
[18:53:46 CET] <SortaCore> ...it seems to output a encode failure then jump forward 10 seconds
[19:26:02 CET] <cone-918> ffmpeg 03Aman Gupta 07master:034e1f82d924: avcodec: fix whitespace on AVPanScan struct definition
[20:01:50 CET] <SortaCore> is there a peek I can do for RTSP to see if there's any packets remaining to read
[21:03:25 CET] <cone-918> ffmpeg 03Kaustubh Raste 07master:e5f66a9ea40c: avcodec/mips: cleanup unused macros
[21:03:25 CET] <cone-918> ffmpeg 03Kaustubh Raste 07master:143fc5f6e20b: avcodec/mips: Improve hevc non-uni hz and vt mc msa functions
[21:03:26 CET] <cone-918> ffmpeg 03John Stebbins 07master:57a422ea4c27: fate/mov: add test for overlapping fragments
[21:03:28 CET] <cone-918> ffmpeg 03Dale Curtis 07master:01763144dcc1: Avoid corrupting diagnostic state with _Pragma changes.
[21:03:28 CET] <cone-918> ffmpeg 03Sasi Inguva 07master:54f8ac199fe3: lavf/mov.c: Don't correct edit list start to zero, when we can't find a frame before edit list start.
[21:53:22 CET] <atomnuker> oh wow opencl <-> d3d11 interop
[21:54:20 CET] <atomnuker> jkqxz: can the arm drm interop also work with non-arm devices?
[21:54:32 CET] <atomnuker> e.g. kms
[21:56:31 CET] <jkqxz> If the driver supported it, sure.  But it is an ARM vendor extension, and it's also kindof shit (only buffers, so the images have to be linear).
[21:59:29 CET] <atomnuker> an arm only extension?
[21:59:33 CET] <atomnuker> what were they smoking
[22:00:08 CET] <jkqxz> And for some reason they thought it would be a good idea for it to be link-only rather than accessible through the normal extension mechanism, so it doesn't work through the ICD.
[22:00:29 CET] <jkqxz> <https://www.khronos.org/registry/OpenCL/extensions/arm/cl_arm_import_memory.txt>
[22:01:11 CET] <jkqxz> It's not really ARM-only, it's just written by ARM people for their specific requirements, so while it could work for everyone else it's not very good.
[22:02:44 CET] <BtbN> I wish there was OpenCL to CUDA interop and vice versa
[22:02:50 CET] <BtbN> But Nvidia will boycot that
[22:03:11 CET] <BtbN> At least every OpenCL filter can be easily converted to CUDA.
[22:06:54 CET] <philipl> opencl -> opengl -> cuda :-)
[22:07:21 CET] <atomnuker> vulkan -> all
[22:07:36 CET] <philipl> vukan <-X-> cuda
[22:07:39 CET] <philipl> for some strange reason
[22:07:50 CET] <BtbN> you can't do that
[22:07:59 CET] <philipl> that's what I was trying to say
[22:07:59 CET] <BtbN> You cannot map something that's already mapped
[22:08:10 CET] <BtbN> You can copy the data that way
[22:08:12 CET] <philipl> oh, you mean my joke
[22:08:15 CET] <BtbN> But it's a double copy
[22:08:29 CET] <jkqxz> OpenCL really only does map-to, not map-from.  You would have to do everything in OpenGLland and map to the others, which wouldn't be very fun.
[22:08:59 CET] <philipl> So who's going to write the hwaccel hooks for mjpeg?
[22:09:13 CET] <BtbN> What else is even left?
[22:09:17 CET] <philipl> That's it
[22:09:17 CET] <BtbN> mjpeg and vp8?
[22:09:19 CET] <philipl> yeah
[22:09:28 CET] <BtbN> Yeah, I'll just add mjpeg then
[22:09:46 CET] <philipl> I meant that there are no hooks - not just that there's no hwaccel.
[22:09:55 CET] <philipl> So there's no vaapi_mjpeg although there could be.
[22:10:07 CET] <philipl> jkqxz was not motivated :-)
[22:10:09 CET] <BtbN> well, mpeg2 and mpeg4 are also there
[22:10:20 CET] <philipl> Yeah. We can do mpeg1/2/4
[22:10:41 CET] <BtbN> If there are hooks, yeah, why not. If not, eh
[22:11:11 CET] <BtbN> The (m)jpeg cuvid hwaccel will be trivial btw.: https://github.com/FFmpeg/FFmpeg/blob/master/compat/cuda/dynlink_cuviddec.h#L457
[22:11:15 CET] <philipl> BtbN: do you have any idea on how to do the deinterlacer with nvdec? Is it futile?
[22:11:19 CET] <philipl> heh, yeah, I looked :-)
[22:11:43 CET] <BtbN> It's impossible to do deinterlacing within the hwaccel framework
[22:11:47 CET] <jkqxz> I looked at MJPEG for VAAPI a while ago and found that writing the hooks would be rather a pain.
[22:11:55 CET] <jkqxz> Then I gave up and did something else because fuck MJPEG.
[22:12:07 CET] <BtbN> Guess VAAPI actually wants data?
[22:12:11 CET] <jkqxz> Yeah.
[22:12:16 CET] <BtbN> what a surprise
[22:12:25 CET] <BtbN> vp8 for vaapi is also a huge mess. Bigger mess than VP9 for some reason
[22:12:31 CET] <BtbN> And in nvdec vp8 is close to trivial
[22:13:24 CET] <jkqxz> How does that MJPEG work in CUVID?  You have to copy the stream and prepend huffman tables and whatnot if they aren't already there?
[22:13:54 CET] <BtbN> From the looks of it, you just give it the raw data, and it munches away
[22:13:58 CET] <BtbN> it does not need any pre-parsing
[22:14:16 CET] <BtbN> So the hwaccel hooks would be trivial
[22:22:58 CET] <atomnuker> `.
[22:28:00 CET] <durandal_1707> michaelni: do you mind providing solution for deprecated YUVJ formats?
[22:32:30 CET] <durandal_1707> atomnuker: still waiting for svg parser answer
[22:32:44 CET] <michaelni> durandal_1707, not sure why you ask me this question but theres AVFrame.color_range and various similarly named fields in the various APIs
[22:33:38 CET] <durandal_1707> michaelni: but it doesnt work if one replace yuvj formats,  fate breaks
[22:33:48 CET] <BtbN> I guess it's just a quest of fixing up every piece that still uses it to look at those fields
[22:33:53 CET] <BtbN> or set them
[22:34:32 CET] <durandal_1707> look at mjpeg encoder and decoder
[22:36:22 CET] <nevcairiel> encoders need a proper way to signal what they accept, which is something that doesnt exist yet
[22:40:17 CET] <atomnuker> encoders should support both ranges
[22:41:04 CET] <nevcairiel> thats not up to the encoder, a jpeg image is just going to be full range
[22:41:27 CET] <atomnuker> durandal_1707: nah, I don't want to deal with libxml, you can give it a go if you'd like to
[22:43:37 CET] <atomnuker> nevcairiel: that's what I mean, encoders shouldn't care about what they have, they should just signal it if they can or error if they can't
[22:44:22 CET] <nevcairiel> and they currently cant signal what they can accept
[22:44:36 CET] <nevcairiel> so someone would have to either know, or randomly try
[22:44:41 CET] <nevcairiel> which is both not very friendly
[22:44:48 CET] <BtbN> couldn't they add a static init function, that sets the pixel format based on the color range, or is that not set yet at that point?
[22:45:40 CET] <atomnuker> nevcairiel: its not, but we can't fit every single requirement in AVCodec so many encoders check inputs at init time
[22:46:02 CET] <nevcairiel> but it can do that right now, if you want to break that, you'll have to convince a lot of people
[22:48:37 CET] <atomnuker> the thing is YUVJ has been deprecated, right?
[22:48:50 CET] <atomnuker> so that also implicitly breaks that
[22:49:02 CET] <nevcairiel> yes
[22:49:05 CET] <atomnuker> as people couldn't really use it considering it could get removed in the future
[22:49:08 CET] <BtbN> a bit weird to deprecate something that has no proper replacement
[22:49:17 CET] <atomnuker> color_range
[22:49:21 CET] <nevcairiel> thats why it was never removed, it serves a purpose that was not replaced
[22:49:27 CET] <BtbN> which was just explained to be inadequate
[22:49:46 CET] <atomnuker> but no one _can_ use them considering they're deprecated
[22:50:04 CET] <atomnuker> so no solution really exists
[22:50:06 CET] <nevcairiel> thats nonsense, deprecated stuff still works just fine
[22:50:18 CET] <atomnuker> yeah, but they're discouraged from usage
[22:50:32 CET] <BtbN> I guess the obvious solution would be to just add the color ranges to AVCodec
[22:50:33 CET] <JEEB> basically "please make up an alternative"
[22:50:36 CET] <nevcairiel> so we should probably un-deprecate them until a full solution is available
[22:50:40 CET] <JEEB> BtbN: accepted_color_ranges
[22:50:48 CET] <atomnuker> nevcairiel: I wouldn't mind that either
[22:51:10 CET] <JEEB> LIMITED, FULL, BOTH, BOTH_BUT_FULL_ONLY_IN_RGB \o/ or some really non-pretty thing
[22:51:21 CET] <JEEB> or you'd have to mark it separately for each supported pix_fmt
[22:51:22 CET] <BtbN> There already is an enum for it
[22:51:57 CET] <atomnuker> okay, so just add that to avcodec then
[22:52:08 CET] <atomnuker> (and avfilterlink and whatever else got mentioned)
[00:00:00 CET] --- Wed Nov 15 2017