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

[burek]

[00:04:00 CEST] <nevcairiel> is it just me, or does the v4l2 api sound terrible
[00:09:34 CEST] <jkqxz> I don't think it's terrible in this aspect, I think the submitter is just not very clueful in some places.
[00:09:52 CEST] <jkqxz> (Certainly it is terrible in other places.)
[00:14:51 CEST] <nevcairiel> i guess that might also be a reason, i havent really read up on it, just taken his explanations
[00:17:30 CEST] <jamrial> jkqxz: "Feel free to submit a patch to avcodec.h which changes the definition of the API."
[00:17:32 CEST] <jamrial> y tho
[00:18:40 CEST] <nevcairiel> the api design is fine
[00:20:13 CEST] <nevcairiel> and we cant just change how the api works anyway
[00:20:27 CEST] <jkqxz> Implicitly, "... and everyone will reject it."
[00:21:11 CEST] <nevcairiel> not sure he'll understand it that way
[00:21:28 CEST] <jkqxz> But I don't think they have actually read it at all, and having to write something there would require reading and understanding it.
[00:22:21 CEST] <jkqxz> At which point hopefully it would clear up the issue.
[04:13:13 CEST] <stevenliu> wm4: hello?
[08:49:07 CEST] <cone-076> ffmpeg 03Paul B Mahol 07master:6faa1275a2e1: avfilter: add despill filter
[10:40:41 CEST] <wm4> oh, we also have 2 ASF demuxers
[10:40:47 CEST] <wm4> fucking insane
[10:44:10 CEST] <durandal_1707> both have good and bad points
[11:09:25 CEST] <LongWork> jkqxz: i talked to wm4 about removing the hwaccels stuff i nthe rockchip decoder and it seems that would break mpv as well ... 
[11:09:46 CEST] <LongWork> i'm not sure what the reason is , maybe he can comment 
[11:10:13 CEST] <wm4> get_format excludes opaque pixfmts if there's no aVHWAccel entry
[11:11:15 CEST] <wm4> so it would break opaque decoding completely
[11:11:39 CEST] <LongWork> he also asked to remove that : https://github.com/LongChair/FFmpeg/blob/5bb3e264e67c8ea53ecd60050dd6ece8918ec8ee/libavcodec/rkmppdec.c#L150-L153
[11:11:50 CEST] <LongWork> as this seemed to lead to some crash on debian 
[11:12:13 CEST] <LongWork> and replace it with  avctx->pix_fmt = AV_PIX_FMT_DRM_PRIME
[11:12:43 CEST] <nevcairiel> you always need an ordinary software format if you're going to call ff_get_format
[11:13:16 CEST] <nevcairiel> if you can only output an opaque hardware format and nothing else (which seems like it would make the thing basically useless, imho), you shouldnt call get_format
[11:17:57 CEST] <wm4> hm yeah, if there's no sw format, calling get_format would be pointless
[11:18:27 CEST] <nevcairiel> i think the code might even expect there to be one
[11:19:01 CEST] <nevcairiel> (and as a bonus, if you dont need ff_get_format, you also dont need the dummy hwaccel)
[11:20:45 CEST] <wm4> you could argue the avhwaccel should be there to inform the API user that support is present
[11:21:08 CEST] <wm4> (although I'm not using that in mpv, because AVHWAccel is completely useless due to being incomplete)
[11:24:47 CEST] <stevenliu> wm4: is that dashdec ok?
[11:25:10 CEST] <jkqxz> The code has an assert that there is an sw format.  It's at level 2 so you don't see it normally, but it is a hard requirement of how it works.
[11:25:16 CEST] <stevenliu> will push if ok :D
[11:25:57 CEST] <wm4> stevenliu: my ok was for the change av_free -> xmlFree
[11:26:16 CEST] <stevenliu> mhmm, others?
[11:26:20 CEST] <wm4> stevenliu: I don't think others would be comfortable with dashdec in its current state yet
[11:26:30 CEST] <wm4> but not sure
[11:26:49 CEST] <jkqxz> Anyway, there is exactly one format and the hwaccel does nothing, so IMO the lavc implementation should reflect that.
[11:26:51 CEST] <wm4> I also pointed out loads of code duplication with hls.c, which probably wasn't fixed
[11:27:29 CEST] <jkqxz> Callers can adapt if they have weird hard requirements on get_format() being called.
[11:27:57 CEST] <wm4> jkqxz: the only reason we keep adding AVHWaccels for full-stream decoders is because ff_get_format wants it
[11:27:57 CEST] <stevenliu> I think the code duplication with hls.c maybe make a fragutils.c willl ok?
[11:28:13 CEST] <wm4> stevenliu: that might be much better
[11:29:15 CEST] <stevenliu> I'll do it this weekend :D
[11:30:40 CEST] <wm4> great
[11:32:22 CEST] <wm4> jkqxz: so I agree that AVHWAccels could probably be skipped if they have no function, but still it'd be nice if there were some meta information about hw decoders
[11:34:25 CEST] <LongWork> wm4, jkqxz: thanks, that answers the questions i had for now :)
[11:36:11 CEST] <stevenliu> rcombs: hello? is the dashdec have the printf fmt problem now?
[11:37:24 CEST] <stevenliu> i have apply Timo Rothenpieler's suggestion.
[11:47:04 CEST] <cone-076> ffmpeg 03Paul B Mahol 07master:2c10f054c2bc: avfilter/avf_avectorscope: add possibility to auto zoom
[11:56:53 CEST] <cone-076> ffmpeg 03Paul B Mahol 07master:a5e6cd79ec34: avfilter/avf_avectorscope: fix mistake in previous commit
[12:13:14 CEST] <jkqxz> wm4:  By meta information, do you mean like the hw_configs thing in the RFC patch a few weeks ago?  Or do you want more than that?
[12:14:12 CEST] <wm4> I don't remember that patch, what was the title?
[12:14:50 CEST] <jkqxz> <https://lists.libav.org/pipermail/libav-devel/2017-August/084592.html>
[12:18:59 CEST] <wm4> jkqxz: ah yes
[12:19:23 CEST] <wm4> as long as AVCodecHWConfig.device_type can be NONE
[12:20:15 CEST] <jkqxz> NONE with a non-NONE format?
[12:21:10 CEST] <wm4> yes
[12:21:32 CEST] <wm4> there's some legacy crap around that, like mmal and crystalhd
[12:21:52 CEST] <jkqxz> I'm not sure that's meaningful.  It might as well be in the pix_fmts list.
[12:22:19 CEST] <jkqxz> (Is it in the pix_fmts list?)
[12:22:36 CEST] <jkqxz> For MMAL, yes.
[12:23:17 CEST] <wm4> what I'd actually like to know about a codec is: is it hardware accelerated? what API does it belong to (like vaapi, vdpau, mmal)? does it need a hw device and which? does it supported hwaccel style decoding (initiating decoding with get_format)?
[12:23:53 CEST] <wm4> I guess the pixfmt is interesting too
[12:24:04 CEST] <wm4> at least for true hwaccels
[12:24:37 CEST] <jkqxz> get_format() seems orthogonal.  It will be called if there are multiple choices or you might need hw_frames_ctx, otherwise it need not.
[12:24:54 CEST] <jkqxz> The hw device part is what I'm trying to solve here.
[12:25:18 CEST] <jkqxz> It also solves the formats for things with devices, but there is a hole for the things without.
[12:26:15 CEST] <jkqxz> If we said that the AV_PIX_FMT_FLAG_HWACCEL formats must appear in the pix_fmts list, would that be sufficient?
[12:28:33 CEST] <wm4> I mean, for true hwaccels, I could switch between real decoder and hwaccel on demand
[12:28:49 CEST] <wm4> can't do that with a full stream decoder, I'd have to setup everything when the codec is opened
[12:37:37 CEST] <jkqxz> If you have a non-hw_device_ctx full-stream decoder then you don't know anything about the context it has used internally until the first frame comes out of it.
[12:43:10 CEST] <cone-076> ffmpeg 03Clément BSsch 07master:516ac7bcc761: build: consistent spacing between lists (cosmetics)
[15:25:53 CEST] <rcombs> stevenliu: looks to be safe now, yes
[15:40:21 CEST] <ubitux> any reason to hold on VDA or it's still too early?
[15:40:38 CEST] <ubitux> it's really causing me trouble with my configure changes because i can't test it
[15:40:48 CEST] <ubitux> since the osx i have doesn't even have it
[15:41:08 CEST] <ubitux> and it looks like we have 2 legacy layers of vda
[15:45:33 CEST] <wm4> yes we do
[15:45:41 CEST] <wm4> and it mixes with videotoolbox in bad ways
[15:55:51 CEST] <BBB> ubitux: I think we can probably remove it
[15:56:14 CEST] <BBB> ubitux: new updates for osx are free anyway, so theres not many systems out there that dont support vtb
[15:57:31 CEST] <ubitux> RFC on the ml
[16:00:07 CEST] <nevcairiel> whats the OS requirements for vtb?
[16:00:49 CEST] <BBB> 10.8+?
[16:00:51 CEST] <BBB> says apple docs
[16:00:56 CEST] <BBB> https://developer.apple.com/documentation/videotoolbox
[16:01:13 CEST] <BBB> macOS 10.8+; iOS 6.0+; etc.
[16:08:56 CEST] <jamrial> ubitux, BBB: whenever you have time, could you check the audiotoolboxdec patches i sent some months ago?
[16:09:17 CEST] <jamrial> rcombs is too lazy
[16:09:27 CEST] <BBB> I can try...
[16:09:36 CEST] <rcombs> I thought I checked those
[16:10:20 CEST] <ubitux> jamrial: Subject?
[16:10:21 CEST] <jamrial> rcombs: you didn't reply to the ml patchset, and i don't recall you commenting here
[16:10:33 CEST] <jamrial> sorry if you did the latter and i missed it
[16:10:56 CEST] <jamrial> ubitux: "[PATCH 1/2] avcodec/audiotoolboxdec: always use a copy of the AVCodecContext extradata"
[16:11:20 CEST] <jamrial> it's three patches. the first two are memleak fixes, the third is a port to the autobsf at the decoder level
[16:11:40 CEST] <jamrial> it's all guesswork since i have no way to test it :p
[16:12:10 CEST] <rcombs> oh yeah, I looked over them but didn't get a chance to test at the time, and then forgot about it
[17:23:12 CEST] <durandal_1707> ubitux: that film grain that you linked is extremly slow
[17:24:39 CEST] <ubitux> you mean the example program? that's usually just a PoC with stupid code
[17:24:49 CEST] <ubitux> i mean, just a demo
[17:25:01 CEST] <ubitux> you think the logic has flaw speed wise?
[17:27:32 CEST] <durandal_1707> its very complicated, qcif takes 6 seconds to filter
[17:32:29 CEST] <cone-076> ffmpeg 03Karthick J 07master:837c55e07271: avformat/hlsenc: Added configuration to override HTTP User-Agent
[17:33:18 CEST] <ubitux> okay, too bad then
[17:35:20 CEST] <atomnuker> film grain filter?
[17:41:17 CEST] <ubitux> is it me or check_header_objcc is broken?
[17:41:25 CEST] <ubitux> ’ enable_safe $headers
[17:41:32 CEST] <ubitux> it's not setting $headers
[17:41:42 CEST] <ubitux> currently, if i shuffle some stuff a little
[17:41:52 CEST] <ubitux> it ends up adding psapi.h and window.h
[17:41:55 CEST] <ubitux> &
[17:41:59 CEST] <ubitux> how can this even work currently
[17:42:33 CEST] <ubitux> atomnuker: http://www.ipol.im/pub/art/2017/192/
[17:59:39 CEST] <ubitux> lol wtfffff
[18:00:34 CEST] <ubitux> header=AVFoundation/AVFoundation.h headers=math.h
[18:00:36 CEST] <ubitux> header=QuartzCore/CoreImage.h headers=CoreGraphics/CoreGraphics.h
[18:00:41 CEST] Last message repeated 1 time(s).
[18:00:41 CEST] <ubitux> so header is the tested header
[18:00:47 CEST] <ubitux> and headers is the enabled header
[18:01:02 CEST] <ubitux> i guess i understand now why these check are in some random places
[18:01:07 CEST] <ubitux> and the deps completely broken
[18:01:25 CEST] <ubitux> their positions were probably shuffled randomly til it worked
[18:01:29 CEST] <ubitux> kill me now
[18:01:31 CEST] <ubitux> T_T
[18:02:06 CEST] <mateo`> killing your Apple laptop should be enough
[18:13:45 CEST] <wm4> ubitux: well it's so complex that nobody really understands it
[18:13:56 CEST] <wm4> that's what happens if you try to do such things in shell
[18:45:32 CEST] <nevcairiel> the shell thing isnt a reason to write confusing code, the objcc stuff was probably just a hackjob and back in that time noone cared
[19:22:45 CEST] <cone-076> ffmpeg 03James Almer 07master:9a174d203ae4: avfilter/lavfutils: remove usage of AVStream->codec
[19:25:12 CEST] <jamrial> fate doesn't cover the above function, btw
[19:25:26 CEST] <jamrial> showcqt, removelogo, cover_rect, etc, are all untested
[19:25:38 CEST] <durandal_1707> jamrial: try them,  test them
[19:25:47 CEST] <jamrial> durandal_1707: i did before pushing
[19:26:17 CEST] <jamrial> what i mean is that a fate test should be added by someone familiar with these filters
[19:46:29 CEST] <durandal_1707> this nobody wants ^ 
[21:15:23 CEST] <doublya> Is there a way I can retrieve the srcFilter and dstFilter that were passed to sws_getContext()
[22:16:46 CEST] <cone-076> ffmpeg 03Kaustubh Raste 07master:fa805df060ae: libavcodec/mips: Improve avc idct8 msa function
[00:00:00 CEST] --- Wed Sep  6 2017