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

[burek]

[00:05:55 CET] <funman> kierank: sure but why?
[00:07:14 CET] Action: funman reads thread
[00:08:37 CET] <kierank> They are misunderstanding the things purpose
[00:09:36 CET] <funman> please remind me tomorrow, i don't have my second factor at hand
[00:09:43 CET] <funman> so no github
[00:10:02 CET] <kierank> Ok
[00:12:09 CET] <cone-439> ffmpeg 03Carl Eugen Hoyos 07master:6a22d2459d2c: lavd/opengl_enc: Fix a typo.
[00:15:56 CET] <sfan5> sent a fixed rtmpdh patch
[00:16:31 CET] <sfan5> apologies if i didn't reply correctly, i wasn't subscribed prior to sending the initial mail so i didnt manage to figure out how to reply properly
[00:52:18 CET] <llogan> sfan5: you can always reply via the archives. just click on the email address link and it will include the In-Reply-To info
[00:52:36 CET] <llogan> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/
[02:39:20 CET] <cone-439> ffmpeg 03Jacek Manko 07master:c10455644897: avcodec/mips/Makefile: corrected conditional build of version 1 of vc1dsp optimizations for loongson mmi
[02:39:21 CET] <cone-439> ffmpeg 03Michael Niedermayer 07master:9568b2e425f1: avcodec/h264_ps: Check chroma_qp_index_offset
[03:11:50 CET] <DHE> I'm going to be making a local mod to ffmpeg and wondering if it makes sense to upstream. Basically I have an application that receiver over-the-air streams which sometimes changes stream layout (number of streams, metadata) and I need to be made aware of when this happens
[03:12:20 CET] <DHE> to that end, I intend to add something to the AVProgram structure that changes to clearly indicate the stream information has changed for that program. thoughts?
[06:09:44 CET] <cone-761> ffmpeg 03Rick Kern 07master:dcd3418a35aa: lavc/videotoolboxenc: check for dictionary key symbols
[06:18:36 CET] <wm4> DHE: probably? we already have something for changing metadata
[06:34:22 CET] <wm4> also hi Compn 
[06:50:51 CET] <Compn> wm4 : did you send mail to konst ?
[06:50:58 CET] <Compn> or find a russian ?
[06:52:01 CET] <Compn> i didnt get a reply from lnoor, so ping him on github maybe
[06:52:11 CET] <wm4> sent mail to both, no reply
[06:52:47 CET] <Compn> the two mplayerxp devs too ?
[06:53:49 CET] <Compn> obviously that would be the first place you started...
[06:57:50 CET] <wm4> the mplayerxp one and the beye one
[07:02:44 CET] <Compn> anyone else you are looking for ?
[07:03:06 CET] <Compn> i finished looking for nick's nickname in google, no luck finding any posts from him after 2010
[07:03:28 CET] <wm4> no, dead-end for me
[07:06:52 CET] <Compn> wm4 : can you replace anything of what he wrote with anything from mplayerg2? it was lgpl iirc... although unfinished
[07:08:21 CET] <wm4> is that available anywhere? but the problem is mostly not real code, but that it was replaced by other code during refactoring, which probably makes the copyright stick
[07:08:28 CET] <wm4> anyway that's offtopic on this channel
[07:09:36 CET] <Compn> yea
[07:09:52 CET] <Compn> i still suggest you ask someone who speaks russian to help, they might have better idea where/how to search
[07:10:18 CET] <Compn> cant remember if atomnuker was russian or not
[07:10:22 CET] <Compn> thresh in vlc maybe 
[07:10:24 CET] Action: Compn afk
[07:11:20 CET] <atomnuker> bulgarian, even though I somewhat know russian I wouldn't know where to look
[07:15:02 CET] <Compn> wm4 : 2 more devs to ask, benjamin zores and mans from vidix project https://sourceforge.net/p/vidix/wiki/Home/
[07:17:03 CET] <Compn> and of course zdenek if you havent asked him yet
[07:17:33 CET] <wm4> I asked zdenek and konstantin
[07:26:02 CET] Action: Compn sleps
[11:03:04 CET] <jkqxz> Can you delay frame output for arbitrarily long in H.265?  (E.g. a sequence P 9001*B P, with all of the B frames referring to the two P frames, and the second P frame gets output at the end.)
[11:05:08 CET] <wm4> I was under the impression that it's limited to 16 frames like in h264, but OTOH I have no clue
[11:07:20 CET] <nevcairiel> i'm sure there is a max dpb size as well
[11:07:49 CET] <nevcairiel> oh waits thats not that
[11:07:56 CET] <nevcairiel> who knows then
[11:08:16 CET] <jkqxz> That never gets exceeded here.  I've deliberately chosen my example so that only the delay gets arbitrarily large.
[11:09:16 CET] <jkqxz> And yeah, I was under the impression it was 16, too.  But the standard is very opaque in this area...
[11:19:07 CET] <rcombs> isn't the hard-maximum DPB size defined by the field used to reference a coded picture being 4 bits wide
[11:19:16 CET] <rcombs> I might be making that up but I'd kinda assumed that was how it worked
[11:23:15 CET] <jkqxz> It's up to 16 bits (fixed by an SPS parameter) for POC, which gives a somewhat larger limit.
[11:24:40 CET] <jkqxz> Also you can duck the use of POC for reference pictures by using long-term pictures instead.
[11:26:02 CET] <jkqxz> And long-term pictures can indeed be kept for arbitrarily long.  My question, then, is whether you can set them to be output after an arbitrarily long delay.
[12:04:24 CET] <rcombs> if you do I'll tell you you should probably put an IRAP somewhere
[12:17:16 CET] <jkqxz> I think someone making a stream with 9001 B frames between every two P frames has worse problems than that.
[12:19:10 CET] <wm4> yet someone will do it
[12:20:14 CET] <Chloe> Are there more people on ffmpeg-security yet?
[12:20:46 CET] <rcombs> if I'm on there then it's very quiet
[12:22:14 CET] <Chloe> rcombs: you actually got added then?
[12:22:22 CET] <rcombs> no idea
[12:22:52 CET] <Chloe> michaelni: is anyone else on ffmpeg-security yet?
[12:27:18 CET] <michaelni> Chloe, the list of members of the ffmpeg-security alias is in the MAINTAINERs file
[12:27:27 CET] <DHE> <wm4> DHE: probably? we already have something for changing metadata  # Oh? I didn't see anything in my searches, short of doing exhausting checking of parameters for changes
[12:27:49 CET] <wm4> DHE: only for AVStream.metadata or such
[12:31:48 CET] <Chloe> michaelni: wm4 or kierank weren't added?
[12:33:51 CET] <DHE> wm4: so you suggest clearing the dictionary and waiting to see if it comes back with data?
[12:33:52 CET] <michaelni> Chloe, iam talking with wm4 about that ATM. 
[12:34:05 CET] <Chloe> ok :)
[12:35:13 CET] <wbs> sfan5: I had a look at your rtmpdh patch; it seems pretty close to what I did in libav in october already. have a look at 016387fe0fe3eff1a03ec0673bf4d2967f6cad94. I noticed a few minor details, like where I changed an av_malloc into av_mallocz (I tested my change with valgrind)
[13:12:28 CET] <sfan5> wbs: indeed very similar; i have no idea about libav* internals so changing some malloc call didn't occur to me and i just wanted something that works anyway
[13:13:33 CET] <sfan5> however whether the struct is zero'd before use (= overwriting the individual components) shouldn't make a difference anyway
[13:15:05 CET] <nevcairiel> i kinda prefer the static  functions over those defines with a ret parameter
[13:16:51 CET] <nevcairiel> all in all i would just cherry-pick wbs' patch,  also avoids having to deal with differences in a future merge
[14:54:51 CET] <DHE> wm4: looks like it's not going to work the way I thought, but at the same time ffmepg doesn't provide what I want...
[15:05:26 CET] <wm4> DHE: what was that again?
[15:05:38 CET] <wm4> I think I only meant it as suggestion how the API could be extended
[15:06:10 CET] <nevcairiel> DHE: you should talk to JEEB, he also wanted some ways to communicate changes in stream layout
[15:06:38 CET] <JEEB> I haven't gotten to design it yet
[15:07:11 CET] <DHE> wm4: yeah, I'm dealing with mpegts (over the air) channels that change streams. ffmpeg doesn't really announce these updates beyond adding new streams as needed. but what I've discovered is that the old streams may not be deleted.
[15:07:41 CET] <JEEB> but yeah, programs and their updates should be replicated to API clients
[15:07:53 CET] <JEEB> DHE: ah, ë
(comrade)
[15:08:07 CET] <nevcairiel> ffmpeg isnt really designed for all the weird concepts the japanese put into their broadcast
[15:08:10 CET] <DHE> yeah it's me again.
[15:08:15 CET] <nevcairiel> a more specialized component may be more fitting =p
[15:08:15 CET] <DHE> :)
[15:08:15 CET] <JEEB> nevcairiel: not limited to that
[15:08:22 CET] <JEEB> BBC also does PID switches
[15:08:36 CET] <JEEB> and Finnish DVB gets and loses tracks all the time
[15:08:48 CET] <DHE> there's a multicultural channels here that will switch between english and portugese (that I've seen) and then my program goes up in flames
[15:08:57 CET] <JEEB> Tokyo MX's video PID switches were the most funky though
[15:09:16 CET] <DHE> seriously considering forcing a complete AVFormatContext reset when that happens.
[15:09:38 CET] <nevcairiel> cant force that internally, that would break all sorts of things
[15:16:46 CET] <wm4> AVStreams can't be deleted
[15:16:56 CET] <wm4> except of course when the user closes the context
[15:23:44 CET] <DHE> well, in the case of mpegts I think I have a hack. While I can't deleted AVStreams, it can delete the AVProgram listing and recreate it. so rather than looking at the AVSstreams directly I can use the AVProgram list as a stream reference to skip unwanted streams
[15:24:13 CET] <DHE> so my program will have to check for the program stream index count and actual array contents for changes. which isn't too bad...
[15:24:43 CET] <JEEB> hmm
[15:24:51 CET] <JEEB> will have to check AVProgram
[15:26:41 CET] <cone-087> ffmpeg 03Paul B Mahol 07master:f06294726144: avcodec/qdrw: do better w/h parsing for direct bit packing
[16:43:39 CET] <kierank> wm4: did you get added to security
[17:05:47 CET] <wm4> kierank: no idea
[17:23:26 CET] <cone-087> ffmpeg 03Paul B Mahol 07master:fd7af82c53ea: avcodec/scpr: do not allow out of array access for 16bit case
[17:25:49 CET] <michaelni> wm4, we just talked about it and i was waiting for your reply on what to put in the patch to the MAINTAINERs file for you in the ffmpeg-security entry
[17:26:16 CET] <michaelni> so you are not on ffmpeg-security currently but once such patch is applied i add you
[17:26:48 CET] <wm4> michaelni: ok, if has to be that way
[17:26:51 CET] <michaelni> note i do not oppose adding "wm4" in there
[17:27:12 CET] <michaelni> people wanted the list to be public
[17:27:19 CET] <michaelni> the list of people that is
[17:27:39 CET] <michaelni> wm4, ok so what should i put in the patch ?
[17:28:13 CET] <wm4> michaelni: wm4 is fine
[17:28:19 CET] <michaelni> ok
[17:42:01 CET] <atana> michaelni, ping
[17:42:30 CET] <michaelni> atana, hi
[17:42:57 CET] <atana> michaelni, did you check the repo? any comment?
[17:44:11 CET] <michaelni> atana, iam just looking now
[17:44:17 CET] <atana> ok
[17:54:50 CET] <michaelni> atana, you can replace all count = count + 1; by count++ similarly any other x = x+1
[17:55:13 CET] <atana> ok
[17:59:25 CET] <michaelni> atana, also instead of prev_songid and prev_matchtime its easier to use p->mi[i-1] i think
[18:51:12 CET] <cone-087> ffmpeg 03Paul B Mahol 07master:95a5af446bd2: avcodec/scpr: check that current row is in valid range
[19:34:52 CET] <tmm1> jkqxz: does vaapi deinterlace+encode work with the latest patch, or is that still a known issue
[19:47:26 CET] <cone-087> ffmpeg 03Paul B Mahol 07master:45ed942e7e16: avcodec/scpr: improve check for out of range motion vectors
[20:07:01 CET] <jkqxz> tmm1:  With Mesa?  No, it still doesn't.  That's just a Mesa problem, though.
[20:14:11 CET] <tmm1> ah ok, misunderstood the old thread then
[20:14:13 CET] <tmm1> thanks
[20:19:44 CET] <jkqxz> It works cleanly on both Intel platforms (i965 and iHD).
[20:38:29 CET] <llogan> jkqxz: do you think "[PATCH] omx: Add support for specifying H.264 profile [v4]" is acceptable? a user asked how to set profile for this encoder and i remembered this patch.
[20:44:03 CET] <jkqxz> llogan:  Oops, I forgot about that one.
[20:45:26 CET] <jkqxz> No, because it still sets the profile explicitly to high if the user doesn't pass anything, which will fail on implementations which don't support that.
[20:45:54 CET] <nevcairiel> gotta have some default profile, but main is probably better then high
[20:47:10 CET] <jkqxz> No.  Just don't set it (as happens now) and the openmax implementation chooses whatever it supports.
[20:47:29 CET] <nevcairiel> i see
[20:51:16 CET] <cone-087> ffmpeg 03Lou Logan 07master:f5fa12d6eefe: doc/filters: mention 'ffmpeg -filters' in timeline section
[20:59:27 CET] <durandal_1707> kierank: do you have apple intermediate codec binary?
[21:01:28 CET] <kierank> No but can be found I guess
[21:57:28 CET] <jkqxz> wm4:  Do you want to say anything else about the VAAPI interlacer?  If you're happy with it then I'd just push it.
[21:58:45 CET] <jkqxz> Um, *deinterlacer.
[21:59:05 CET] <jkqxz> I like to think that I'm not quite insane enough to make new interlaced videos.
[22:00:15 CET] <wm4> the only thing that sticks out is the duplication of the vaapi pipeline setup code that the vaapi scaler also has
[22:00:19 CET] <wm4> but I guess it's fine
[22:00:50 CET] <wm4> does it have an "interlaced frames only" mode like vf_yadif.c?
[22:06:56 CET] <jkqxz> The filter just feeds in the frames and magic happens.
[22:09:02 CET] <jkqxz> It doesn't obviously do horrific things to progressive frames, though.
[22:15:13 CET] <wm4> well it's still your choice what to do with it (or whatever to feed progressive frames to it in the first place)
[22:16:21 CET] <jkqxz> They would still need to be copied to make them end up in the right hardware frames context.
[22:18:23 CET] <wm4> that's lame
[22:19:30 CET] <jkqxz> Such is the price of abstraction.
[22:19:52 CET] <jkqxz> (It probably all works anyway if you don't, but that would be Very Naughty.)
[22:21:11 CET] <wm4> time for a hw->hw frame copy function?
[22:24:58 CET] <jkqxz> Maybe av_hwframe_map() could do it?  Mapping to another frames context on the same device could decide whether it's ok to just rename the frame, allocating a new one and copying if necessary.
[22:25:54 CET] <wm4> no idea, it basically hangs on the hw_frames_ctx pointer, doesn't it
[22:26:09 CET] <wm4> a bit weird that it has to be the same for a filter pad
[22:26:16 CET] <wm4> even if the format is the same
[22:26:23 CET] <BtbN> vaapi frames have a hard dependency on the hw_frames_context?
[22:26:36 CET] <BtbN> For cuda the context does not matter at all anymore after the frame is created
[22:26:46 CET] <BtbN> Only the CUDA context needs to match
[22:26:57 CET] <jkqxz> The sameness requirement only actually matters if you pass it to something else which cares.
[22:27:13 CET] <nevcairiel> most hw frames at least belong to a device, in some cases even a frame pool
[22:27:17 CET] <wm4> which filters do (currently)
[22:27:21 CET] <jkqxz> hwmap to QSV requires it, say.
[22:27:55 CET] <BtbN> yeah, but the pool deallocation is handled by the frame itself
[22:27:58 CET] <jkqxz> Nothing as currently in ffmpeg, I think.
[22:28:00 CET] <wm4> jkqxz: so I'm not sure how mapping would solve it... wouldn't that make one frame pool reference another one?
[22:28:02 CET] <BtbN> one doesn't need the context for it
[22:28:36 CET] <jkqxz> I'm only speculating on overloading mapping to do it, because it's kindof a map operation.
[22:29:04 CET] <jkqxz> And it's a single-frame-map, so the pool references wouldn't be changing.
[22:29:06 CET] <nevcairiel> also cuda frames are only so independent because of the way you make them, you practically allocate a plain memory buffer and copy into it, its not really related to any video-specific function anymore at that point =p
[22:29:24 CET] <jkqxz> As BtbN says, the pool doesn't matter for the deallocation.
[22:29:42 CET] <BtbN> Yeah, a cuvid-frame would be much more sophisciated
[22:29:52 CET] <BtbN> which actually has a map and unmaps on free
[22:30:27 CET] <BtbN> But even that only depends on the CUDA context to be the same
[22:30:51 CET] <nevcairiel> an actual cuvid frame needs to lug around the decoder reference to access it
[22:31:04 CET] <BtbN> Not to access it, but to free it
[22:31:33 CET] <BtbN> it's just mapped to a normal cuDevicePtr
[22:32:04 CET] <nevcairiel> you really shouldnt keep it mapped all the time though
[22:32:18 CET] <nevcairiel> a cuvid frame is safer as decoder+index
[22:32:21 CET] <nevcairiel> and m apped when needed
[22:32:32 CET] <BtbN> Yeah, carrying around a mapped cuvid frame would be kind of crazy
[22:32:46 CET] <BtbN> which is why it's just copied to normal device memory
[22:33:25 CET] <BtbN> In general cuvid frames would be insane, as I don't see a way to properly ensure the decoder doesn't reuse an index before the frame using it is freed
[22:35:00 CET] <jkqxz> If only there were some way to deal with the frame management yourself...
[22:35:26 CET] <BtbN> Even then it would still be insane
[22:35:35 CET] <BtbN> Makes for funny deadlocks
[22:35:54 CET] <BtbN> something waiting on more input frames, while the decoder is waiting on free output frames
[22:38:10 CET] <BtbN> I like the way the CUDA frames work right now. It's quite fault tolerant and easy
[22:38:16 CET] <BtbN> And not noticably slower
[22:49:45 CET] <jamrial> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
[23:03:37 CET] <cone-087> ffmpeg 03Paul B Mahol 07master:20789372da91: avcodec/shorten: support decoding AIFF-C variant
[23:14:04 CET] <durandal_1707> jamrial: on what they loose cpu cycles
[23:19:38 CET] <cone-087> ffmpeg 03Mark Thompson 07master:359586f14f46: lavfi: Add VAAPI deinterlacer
[00:00:00 CET] --- Fri Feb 24 2017