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

[burek]

[00:42:07 CET] <michaelni> durandal_170, when do you and others want me to make 3.3 ?
[00:47:41 CET] <philipl> BtbN: so the silly yuv444p10 thing? I didn't exactly get clear feedback from the ml - mostly just confusion.
[00:47:52 CET] <philipl> Should we just remove the mapping? It does more harm than good right now.
[00:48:05 CET] <atomnuker> michaelni: I'd like my opus encoder to make it in, but I need someone to review it
[00:53:52 CET] <jamrial> atomnuker: ping the patchset
[00:59:42 CET] <atomnuker> I need to make a v2 for 2 patches though, I fixed the mdct strides
[01:00:10 CET] <atomnuker> but I still need a day or two to figure out why the damn transients don't work for 10 and 20ms frames
[03:16:43 CET] <peloverde> do we have a way to rewind getbits or do I need to make a copy of the context?
[03:20:06 CET] <atomnuker> peloverde: make a context or if what you're wanting to read is conviniently aligned just get the pointer to the current byte and subtract from it
[03:32:56 CET] <jamrial> peloverde: can't you use show_bits()? or do you have to rewind a considerable amount?
[03:33:22 CET] <peloverde> jamrial: It's potentially quite a bit
[03:34:27 CET] <jamrial> peloverde: maybe skip_bits() works with negative amount. but probably not, otherwise there would be a seek() function i think
[03:56:54 CET] <cone-098> ffmpeg 03Rostislav Pehlivanov 07master:d164ef658970: mjpegenc_common: add missing ff_ prefix to init_uni_ac_vlc
[04:00:07 CET] <cone-098> ffmpeg 03Rostislav Pehlivanov 07master:20614e868b90: tests/mjpegenc_huffman: replace assert() with av_assert0()
[04:02:28 CET] <cone-098> ffmpeg 03Rostislav Pehlivanov 07master:a70f0927ea45: mjpegenc: use s->avctx as a context for av_log rather than NULL
[04:09:22 CET] <cone-098> ffmpeg 03Rostislav Pehlivanov 07master:53234b9ba5e6: tests/mjpegenc_huffman: align static tables
[05:07:47 CET] <kierank> Chloe: dvbinspector
[05:17:49 CET] <kierank> peloverde: afaik latm doesn't care about byte alignment
[07:17:03 CET] <wm4> jkqxz: thanks - odd that fate didn'tcatch this
[09:14:40 CET] <wm4> the commit jamrial pointed out doesn't apply to use, because "avconv: replace -vsync cfr code with the fps filter." was skipped in 2012
[09:23:35 CET] <JEEB> wm4: wow, someone removed vsync code
[09:25:28 CET] <wm4> but only in Libav
[09:25:42 CET] <JEEB> ye
[09:36:02 CET] <wm4> so all what's left is cuvid
[09:36:57 CET] <nevcairiel> cuvid uses some hacky approaches to timestamps =p
[09:42:40 CET] <wm4> my problem is that cuvid somehow stopped working on my system
[09:42:47 CET] <wm4> probably could be recovered by a reboot
[10:43:53 CET] <BtbN> philipl, I'm pretty sure if we remove it, some people would show up and complain about their yuv444p10 input being converted to 420 P010. At least that was the original argument for introducing it.
[10:44:21 CET] <BtbN> wm4, a reboot or nvidia kernel module re-load.
[10:45:04 CET] <wm4> the latter is essentially equivalent to a reboot (need to restart the X session)
[10:45:33 CET] <BtbN> I also don't think we can just remove a supported input pixel format, that would be kind of an API break.
[11:41:26 CET] <wm4> wbs: any idea what causes "The TLS connection was non-properly terminated." with gnutls when the connection is closed?
[11:43:25 CET] <wbs> wm4: no, not really. is it perhaps related to 74ea1167d91ccb2e1f2943efa030f2c278b598be?
[11:43:47 CET] <wm4> oh.
[11:44:47 CET] <wm4> looks like tls_close shouldn't be able to trigger any log messages
[11:45:43 CET] <BtbN> is there some magic in av_log to print pixfmts, and other enums?
[11:46:09 CET] <wm4> no, but there's a pixdesc.h function for pixfmt->string
[11:46:26 CET] <BtbN> hm, way too much code for that
[11:47:21 CET] <wm4> ah the log message is caused by tls_read
[11:47:27 CET] <wm4> odd that this would cause errors?
[11:50:05 CET] <wbs> well tls_read shouldn't be called any more at that point, so then it's probably not related to your commit
[12:09:59 CET] <BtbN> hm, I'm running out of ideas why nvenc complains about being Oom
[12:10:06 CET] <BtbN> Everything looks perfectly in order to me
[12:10:14 CET] <BtbN> All the sizes match, the formats everywhere match
[12:14:12 CET] <wm4> and it works before the merged commit?
[12:14:22 CET] <BtbN> yes, current master works fine
[12:14:41 CET] <nevcairiel> where do you keep that branch?
[12:15:00 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/compare/master...wm4:filter-merge?expand=1
[12:15:26 CET] <wm4> (I force-pushed that today)
[12:18:54 CET] <nevcairiel> it seems some of the filter changes got easier with some of the recent lavfi dataflow changes
[12:19:03 CET] <nevcairiel> previously practically every audio encode would've failed
[12:19:52 CET] <wm4> I didn't change any special lavfi API use
[12:20:04 CET] <nevcairiel> nah nicolas did those a few weeks ago
[12:20:12 CET] <nevcairiel> i was wondering if those changes may actually help this merge
[12:20:24 CET] <wm4> the ffmpeg reap_filters is oddly similar to libav poll_filters, but different
[12:20:34 CET] <nevcairiel> yeah the lavfi layout is similar but different
[12:21:56 CET] <BtbN> https://bpaste.net/show/61be36402471 that's what I'm getting right now with a lot of additional debug outputs.
[12:22:02 CET] <BtbN> Everything looks perfectly in order
[12:22:24 CET] <nevcairiel> maybe the frame surface it gets is wrong or invalid
[12:22:36 CET] <BtbN> how would that happen?
[12:22:42 CET] <nevcairiel> a bug
[12:22:43 CET] <nevcairiel> :D
[12:22:48 CET] <BtbN> I'd expect it to fail at registering it then
[12:24:06 CET] <BtbN> it's also complaining about being out of memory, so maybe something else is actually munching away all the memory?
[12:24:31 CET] <BtbN> But nothing initializes the cuda hwcontext, except for cuvid, which does so with correct dimensions
[12:26:16 CET] <nevcairiel> thats why i would think maybe something is wrong with the hwframes context
[12:26:40 CET] <BtbN> [AVHWFramesContext @ 0x41ef6a0] cuda_frames_init: fmt: nv12, w: 1920, h: 1080
[12:26:46 CET] <BtbN> everything seems to be in order
[12:30:04 CET] <BtbN> https://bpaste.net/show/e5df4181fefd that's with master.
[12:30:11 CET] <BtbN> Only notable difference I see is the order of things
[12:30:24 CET] <BtbN> which is to be expected. The order on the filter-merge branch seems way more sane
[12:32:19 CET] <nevcairiel> thats the entire point of those changes
[12:32:29 CET] <nevcairiel> making init order logical, from input to output in that order
[12:32:38 CET] <JEEB> sounds good
[12:32:54 CET] <BtbN> except for the part where it makes nvenc fail because oom
[12:33:40 CET] <nevcairiel> i would add some more log into the hwframes context code, just to see if its maybe doing weird things
[12:35:03 CET] <nevcairiel> like the number of frames it allocates and whatnot
[12:41:15 CET] <BtbN> also looks ok, allocates just a single frame
[12:41:32 CET] <nevcairiel> its using that pool for decoding, shouldnt it allocate more
[12:41:56 CET] <BtbN> it decodes the first frame, and nvenc chokes on that one, so it never gets to allocating more
[12:46:40 CET] <jkqxz> Is hw_frames_ctx actually set to the right thing from the decoder when the nvenc encoder is opened?  It doesn't look like there is a check in the encoder for that, so it would use the wrong code path for an AV_PIX_FMT_CUDA frame and probably do something odd.
[12:48:10 CET] <BtbN> you mean if cuvid and nvenc get the same hw_frames_ctx, and if nvenc gets one at all?
[12:48:51 CET] <BtbN> it definitely gets one, it aborts if the pix_fmt is AV_PIX_FMT_CUDA but hw_frames_ctx is unset
[12:49:26 CET] <BtbN> And the input pixel format also matches, and the frame dimensions, so I very much assume it's the right one.
[12:49:54 CET] <nevcairiel> might help to print the pointers or something of those things
[12:50:19 CET] <nevcairiel> the log only mentions one, but not sure if you can have an empty one that was never inited
[12:51:11 CET] <BtbN> that can definitely happen, but the one nvenc gets is not empty
[12:51:55 CET] <nevcairiel> well can you verify that the frame you get actually belongs to that hwframe ctx?
[12:53:22 CET] <nevcairiel> some input has to be different to before, and that part would be a prime suspect since its so opaque
[12:56:46 CET] <BtbN> https://bpaste.net/show/11a448f2cf25
[12:56:55 CET] <BtbN> I'm pretty sure there is only exactly one hwframes_ctx
[13:06:08 CET] <nevcairiel> some other troubling t hought is that it doesnt like the order of things, maybe nvenc wants to be assigned to the context before the frame is allocated, which it previously would be but not anymore
[13:07:26 CET] <nevcairiel> dont think there is a clear cut way to test that, however
[13:20:52 CET] <nevcairiel> one way would be to check if direct surface transcoding works in libav, they should follow the same dataflow as the branch
[13:22:26 CET] <wm4> did anyone try qsv + my branch?
[14:11:59 CET] <kierank> wm4: did michaelni ever reply to you
[14:12:04 CET] <wm4> kierank: no
[14:12:08 CET] <kierank> funny that
[14:12:22 CET] <wm4> indeed
[14:12:24 CET] <wm4> funny
[14:12:30 CET] <kierank> and funny how when I send a fuzzing tool it gets rejected but when google sends an inferior one it gets merged immediately
[14:12:50 CET] <wm4> pretty weird
[14:14:54 CET] <nevcairiel> there was a post about ffmpeg-security access on the ML, go read that
[14:15:52 CET] <kierank> it's a crazy argument
[14:16:04 CET] <wm4> well I sent him a mail by replying on the ML
[14:16:07 CET] <kierank> if you have commit access you have more of a risk than access to security ML
[14:16:25 CET] <kierank> yet every random person is given commit but suddenly security is now top secret
[14:16:27 CET] <kierank> #ffmpeglogic
[14:16:48 CET] <wm4> you could add that shady patches make it in easily
[14:16:53 CET] <wm4> even if you don't have push access
[14:21:06 CET] <jkqxz> wm4:  Yes, I tried qsv + your branch.  Everything looked happy to me (i.e. works as well as it does in avconv).
[14:23:02 CET] <wm4> with qsv surfaces from decoder to encoder?
[14:23:20 CET] <jkqxz> Yes.
[14:24:38 CET] <jkqxz> I want to merge scale_qsv to check filtering as well, which I haven't yet done.
[14:25:18 CET] <wm4> so that nvenc issue remains myerious
[14:25:22 CET] <wm4> mysterious even
[14:31:29 CET] <durandal_170> michaelni: what kind of game you play now? you resigned as leader months ago
[14:33:19 CET] <atomnuker> he said he's busy as hell today, yet you can't wait a few hours without pining him to ask him where your access is
[14:33:50 CET] <kierank> that's the exact point
[14:34:08 CET] <kierank> we should be able to do stuff in the project without having to go through michaelni 
[14:34:33 CET] <nevcairiel> you can do plenty things without access to some silly ML that has barely any traffic as is
[14:36:17 CET] <BtbN> wm4, it's also only nvenc btw.
[14:36:26 CET] <BtbN> cuvid -> scale_npp -> hwdownload -> x264 works
[14:37:01 CET] <wm4> BtbN: good enough I think
[14:37:17 CET] <BtbN> I just don't understand what the hell is going on
[14:37:25 CET] <nevcairiel> does hwupload with nvenc work?
[14:37:32 CET] <jkqxz> Does native -> hwupload -> nvenc work?
[14:37:34 CET] <BtbN> haven't tested yet
[14:37:41 CET] <BtbN> Will do once I get home
[14:37:55 CET] <nevcairiel> i could totally see that nvenc doesnt like being initialized after the frame was already created
[14:38:04 CET] <nevcairiel> not that that would be anything we can fix =p
[14:39:20 CET] <wm4> I don't care if nvenc breaks as long as cuvid works
[14:39:26 CET] <wm4> merges have broken shit before
[14:39:38 CET] <jkqxz> I don't think it can be that.  The hwupload cases must be ok with frames existing beforehand, since hwupload_cuda exists.
[14:40:12 CET] <BtbN> nvenc in itself works, it's just the hwaccel path
[14:52:33 CET] <s-ol> does anyone know what the current status of the mpeg-dash muxer is?
[14:52:55 CET] <s-ol> i found these patches on the mailing list and they are not merged: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199183.html
[14:53:07 CET] <s-ol> (also they don't work perfectly, it outputs a bandwidth of 0 for all streams for me)
[15:08:42 CET] <Compn> kierank / wm4 : ever stop to think maybe just maybe some emails get lost? ping your fuzz tool or just commit it...
[15:09:05 CET] <Compn> kierank / wm4 : also you could cross-vote for each other to be included on list
[15:09:10 CET] <Compn> that would help the vote
[15:12:54 CET] <cone-518> ffmpeg 03Rostislav Pehlivanov 07n3.1.7:HEAD: tests/mjpegenc_huffman: align static tables
[15:12:54 CET] <wm4> I think the main issue is that michaelni remains silent
[15:13:20 CET] <nevcairiel> he did mention that he is extremely busy right now making releases and backporting security fixes
[15:15:23 CET] <wm4> not to me anyway
[15:23:03 CET] <RiCON> he did send a mail concerning ffmpeg-security to the ML yesterday
[15:58:15 CET] <Chloe> I dont see the issue with anyone having commit access having ffmpeg-security access too. It's not access to ffmpeg-security gives them any more scope to do damage
[15:58:37 CET] <Chloe> which gives*
[16:00:06 CET] <Chloe> Compn: I dont see a vote, and I hope it doesn't have to come to one either
[16:03:13 CET] <jamrial> Chloe: 0 day exploit details and reproduction steps before a fix can be pushed and a release made is a lot of scope to do damage
[16:04:06 CET] <jamrial> you don't see CVE details for any project until weeks after a fix is pushed for a reason
[16:07:00 CET] <Chloe> hmm I guess
[16:08:01 CET] <Chloe> dvb tt is so broken
[16:09:45 CET] <Chloe> https://usercontent.irccloud-cdn.com/file/BJ2ZinKj/works-for-me.png
[16:12:06 CET] <wm4> I bet it's some kind of DRM scheme
[16:19:25 CET] <Chloe> That's after conversion to dvdsub, VLC plays the source fine. I cant tell if this has ever worked though, I cant find a sample where it does work
[16:20:49 CET] <wm4> normal dvb subs (whatever they are) should work with lavc
[16:20:53 CET] <wm4> no idea about vlc
[16:21:10 CET] <nevcairiel> normal dvb subs are also relatively sane
[16:21:17 CET] <nevcairiel> dvb teletext is the crazy thing
[16:22:04 CET] <Chloe> yes dvb subs work fine
[16:22:15 CET] <Chloe> dvb teletext is absolutely stupid
[16:24:17 CET] <wm4> of course both of these things have to exist
[16:29:09 CET] <s-ol> do patches _need_ to be signed? checklist mentions it but the ones I saw on the mailing list weren't
[16:29:21 CET] <wm4> no
[16:29:57 CET] <nevcairiel> you mean the signed-off thing?
[16:30:25 CET] <s-ol> yep
[16:30:26 CET] <nevcairiel> i find signing off my own patches stupid, why wouldnt i sign off on a patch i wrote and sent? its just redundant
[16:32:17 CET] <wm4> apparently signing off is also a way to say "I agree with the project policies"?
[16:32:23 CET] <wm4> though that doesn't make much sense to me
[16:32:59 CET] <nevcairiel> i would think it was originally meant to be used by a maintainer to sign off on the patch as a clear sign he reviewed it
[16:36:06 CET] <s-ol> it's a bit confusing that thte developer docs mention `git commit -s` rigth next to an (outdated) link to what the linux kernel docs call signing off
[16:36:45 CET] <Chloe> wm4: agreeing the license too
[16:36:57 CET] <s-ol> oh wait
[16:37:15 CET] <s-ol> nvm, commit -s is very different from tag -s
[16:44:55 CET] <Chloe> why is data an uint8_t*[4] in AVSubtitleRect?
[16:45:25 CET] <nevcairiel> why not
[16:45:42 CET] <nevcairiel> thats our standard format for bitmap data
[16:46:56 CET] <Chloe> err. I'm being stupid
[17:45:53 CET] <cone-518> ffmpeg 03Rostislav Pehlivanov 07n2.8.11:HEAD: tests/mjpegenc_huffman: align static tables
[17:54:53 CET] <Chloe> how is the duration of teletext defined? Spec suggests the PES packet, which I can see it is being used for the start time, but not sure how the end time is defined.
[17:58:34 CET] <wm4> often enough with these things the end time is defined by the start of the next one
[17:58:46 CET] <wm4> or something like that
[18:09:07 CET] <jkqxz> Yeah.  I would assume it is just mapped from the analogue form, so each numbered page is a single image which gets updated at some regular interval (as the broadcast runs through all pages in sequence).
[18:14:05 CET] <Chloe> wm4: how would you get the time of the next one (if it even exists)? doesn't that depend on the caller?
[18:15:37 CET] <wm4> Chloe: yeah, unless you buffer it in the decoder
[18:16:03 CET] <wm4> but bluray and dvd subs also end subtitles on the next, and let the caller handle that
[18:16:48 CET] <nevcairiel> Blu-ray has a special end segment that defines it's duration
[18:18:17 CET] <wm4> still the same problem I suppose
[18:18:30 CET] <wm4> what really confuses me about blu-ray subs is that they have some sort of pts reordering
[18:19:49 CET] <nevcairiel> Well it's not like mpegts could signal a duration, the container just doesn't have that option
[18:21:07 CET] <nevcairiel> Never noticed pts reordering
[18:21:19 CET] <Chloe> the libzvbi decoder has a 'duration' argument which is set to 30sec(!) by default, which ends up having a bunch of dialogue on the screen at one point for example
[18:26:47 CET] <JEEB> is dvb tt limited to one line at a time?
[18:26:59 CET] <JEEB> if yes, use start time of the next one
[18:27:17 CET] Action: JEEB did that with mpc-hc's dvd sub decoder
[18:27:29 CET] <Chloe> yes it is, but getting the start time of the next one is the issue
[18:27:30 CET] <jkqxz> 30 seconds sounds like a plausible number for the normal pages (IIRC it did take something like that long to update).
[18:27:34 CET] <jkqxz> Not so much for it in subtitles, though; there is nothing to help you there, you just have to replace it with the next one when that turns up.
[18:28:30 CET] <JEEB> yea, so start of next is the duration if no better duration is gotten
[18:28:59 CET] <JEEB> or well, that is the maximum always
[18:29:43 CET] <Compn> Chloe : btw if you do figure out dvb teletext stuff, theres always people wanting features, and probably a lot of $$$ work to be done on it
[18:30:13 CET] <Chloe> Compn: I'm getting paid for this, probably a bit low now that I'm more into it
[18:30:18 CET] <JEEB> also IIRC vlc does a pretty OK job with dvb-tt
[18:30:37 CET] <JEEB> so code / maintainer can be a good source of info
[18:33:06 CET] <Chloe> Compn: the worst feature is multiple pages in one stream
[18:36:19 CET] <Compn> its no conspiracy, we have current active russian developers :D
[18:36:28 CET] <Compn> Chloe : yes, i've heard of those :D
[18:38:35 CET] Action: Compn doesnt know why he tries to help anymore
[18:51:10 CET] <Compn> we're back to the voting thing again
[18:51:39 CET] <Chloe> 2 weeks is awfully long
[18:51:44 CET] <Chloe> JEEB: seems VLC checks it within it's decoding handler rather than the decoder (the decoder is passed in an end time)
[18:52:14 CET] <Compn> Chloe : yeah, well, otherwise people bitch that its "only 1 week" or "only 3 days" etc
[18:52:24 CET] <Compn> "2 weeks" is unwritten rule on commits and stuff 
[18:52:45 CET] <Chloe> Compn: it's actually written down
[18:53:20 CET] <Chloe> Compn: https://ffmpeg.org/developer.html#Patches_002fCommitting see the last guidline
[18:53:45 CET] <Compn> yea
[18:53:49 CET] <Compn> i mean its unwritten for voting
[18:53:57 CET] <Compn> i think is what i mean
[18:53:57 CET] <Chloe> ah
[18:54:27 CET] <jkqxz> Why are we voting on that?  It isn't the important question.
[18:54:32 CET] <jkqxz> I don't think anyone disagreed that adding specifically kierank and wm4 to the security list is fine.
[18:54:51 CET] <Chloe> Why are we voting
[18:54:56 CET] <jkqxz> The important question was what the method for deciding who should be added to the list is.
[18:54:57 CET] <kierank> i don't particularly care about being on the list
[18:54:57 CET] <Chloe> does no one else have access at all?
[18:55:04 CET] <kierank> i just don't want michaelni to be the single point of failure
[18:55:11 CET] <kierank> people get ill you know
[18:55:31 CET] <kierank> also running things like a dictator is not the way to run a project
[18:55:32 CET] <jkqxz> Now if the answer is "always vote on it", then sure, vote.  But please clarify what the process is first.
[18:55:40 CET] <Compn> jkqxz  / Chloe : we voting because its a democracy and we have to vote
[18:56:11 CET] <Chloe> democracies dont have a referendum for every petty dispute
[18:56:19 CET] <jkqxz> (If we have to vote on what the process is, also fine.)
[18:56:41 CET] <Compn> welcome to petty dispute country ffmpeg :P
[18:57:04 CET] <Compn> theres always one guy who wants to vote on the process lol
[18:57:40 CET] <atomnuker> Compn: why did you start a bloody vote now?
[18:58:07 CET] <atomnuker> nobody said anything about voting, are you even reading?
[18:58:37 CET] <Compn> atomnuker : are you? 
[18:58:37 CET] <Compn> I think FFmpeg has a very good security history, theres a "name" to
[18:58:37 CET] <Compn> loose here. My oppinion is that there should be a rule whatever that
[18:58:37 CET] <Compn> rule is, and the community should decide this rule.
[18:58:42 CET] <Compn> thats michael ^^
[18:58:54 CET] <Compn> " the community should decide this rule."
[18:58:58 CET] <wm4> how did this blow so out of proportion anyway
[18:59:09 CET] <Chloe> misinterpretation
[18:59:10 CET] <Compn> the usual
[18:59:11 CET] <atomnuker> because some people are too damn impatient
[19:00:06 CET] <atomnuker> Compn: but the vote isn't about a damn rule
[19:00:08 CET] <wm4> all I want is being able to review those patches before they get pushed under curious circumstances
[19:00:12 CET] <Compn> if you guys dont want to make it bigger just vote yes...
[19:00:18 CET] <Compn> or vote no
[19:00:19 CET] <atomnuker> getting people on the ml isn't a rule
[19:00:28 CET] <Compn> its a community decision
[19:01:00 CET] <Compn> If the community wants me to add every FFmpeg maintainer who wants
[19:01:00 CET] <Compn> to be on the alias, i can do that. But in the absence of a clear
[19:01:01 CET] <Compn> community decission (poll/vote) on the inclusion criteria iam reluctant
[19:01:01 CET] <Compn> to add anyone without a strong reason.
[19:01:01 CET] <atomnuker> either way no one said no and there wasn't a reason to do a damn vote, you just had to wait 1 damn bloody day
[19:01:02 CET] <Compn> ^^^^
[19:01:21 CET] <Compn> what was going to happen in 1 day ?
[19:01:28 CET] <kierank> 6:00 PM <"wm4> all I want is being able to review those patches before they get pushed under curious circumstances
[19:01:29 CET] <kierank> this
[19:01:41 CET] <atomnuker> releases done (ish) and gsoc deadline passed
[19:01:46 CET] <Compn> oh
[19:01:57 CET] <Compn> this vote wont stop those, atomnuker
[19:02:19 CET] <Compn> you are spending more time on this discussion here than sending a "vote yes" or " i vote no" email.... :D
[19:02:35 CET] <atomnuker> no but it will bloody well prolong this for 2 bloody weeks
[19:03:13 CET] <atomnuker> can you at least not put end of the bloody universe deadlines? like a week, a few days or something?
[19:03:14 CET] <Compn> if you just say "i vote yes" in the thread , and we get at least 10-20 people to do the same, we can probably cut the 2 weeks down...
[19:03:23 CET] <Compn> i would love to , but unwritten rule...
[19:03:25 CET] <kierank> i don't recognise anything from compn
[19:03:31 CET] <Chloe> what unwritten rule
[19:03:44 CET] <wm4> atomnuker: sure, if he tells me "wait a week"
[19:03:56 CET] <Chloe> I think we should have a vote to decide on how long votes should be
[19:04:35 CET] <Compn> kierank : as in, my opinion means nothing, or as in "i dont see mail from compn" ?
[19:05:13 CET] <kierank> http://uk.businessinsider.com/oss-manual-sabotage-productivity-2015-11
[19:05:28 CET] <atomnuker> Chloe: I think you ought to stop that thought
[19:05:48 CET] <Compn> michaelni said hes not adding anyone without community vote
[19:05:54 CET] <Compn> i dont know how to make this more clear
[19:06:02 CET] <Compn> just vote yes and get it over with
[19:06:19 CET] <Chloe> atomnuker: It was a joke about ridiculous votes
[19:06:37 CET] <Chloe> though I wouldn't be surprised if it ended up becoming an actual vote in the future
[19:06:55 CET] <Compn> Chloe : its a bit of a raw nerve around here (voting)
[19:07:51 CET] <Compn> because we agree on nothing, ever
[19:08:02 CET] <Chloe> Compn: he didn't say that, he said: "This is of course something the community has to decide". Deciding this doesn't require a vote.
[19:08:16 CET] <Compn> are you playing semantics with me ? :D
[19:08:23 CET] <atomnuker> Compn: we did a time or two, but people would rather remember all the times we didn't
[19:09:42 CET] <Chloe> Compn: I'm only saying that not every decision requires a vote
[19:11:02 CET] <Compn> Chloe : sure. what do you propose to have the community decide ?
[19:11:50 CET] <Chloe> What everyone here (except you) has said already--that there was no problem with adding wm4 and kierank
[19:11:58 CET] <kierank> ignore compn
[19:12:00 CET] <kierank> he is just noise
[19:12:11 CET] <kierank> and conspiracy theories
[19:12:30 CET] <jamrial> Compn: things have been pretty calm for some months now. you just had to scratch that itch, didn't you?
[19:14:19 CET] <Compn> jamrial : guess you are right
[19:14:24 CET] <Compn> kierank : i am the problem
[19:14:25 CET] <Compn> cya
[19:15:35 CET] <relaxed> mplayer expatriates
[19:15:39 CET] <Chloe> kierank: how would you get the PTS of the next teletext page? The only way I can think to do it is to buffer the teletext and send it when the next one comes through (this would require a 'final' bogus teletext to trigger the last actual tt to be sent though).
[19:15:47 CET] <kierank> you don't
[19:15:59 CET] <kierank> ask funman 
[19:16:32 CET] <Chloe> funman: could you help? ^^
[19:18:01 CET] <BtbN> nevcairiel, jkqxz: hwupload_cuda -> nvenc works fine.
[19:18:34 CET] <wm4> Compn means well, but the result isn't always so good unfortunately
[19:18:45 CET] <wm4> Chloe: why do you want the next pts?
[19:19:10 CET] <Chloe> set the duration to next pts - current pts if it's smaller than the max
[19:19:18 CET] <Chloe> maybe there's a way in ASS to do this?
[19:20:09 CET] <BtbN> nevcairiel, jkqxz: Which is actually just what I tested before... a hwdownload path does not seem possible, as ffmpeg_cuvid.c aborts
[19:21:29 CET] <wm4> Chloe: no there isn't
[19:21:38 CET] <kierank> so is there a public list of members of ffmpeg-security
[19:21:41 CET] <wm4> Chloe: we had to solve the same problem for CC, but I don't remember the solutiob
[19:21:58 CET] <wm4> Chloe: maybe tmm1 can help you (though I couldn't reach him lately)
[19:22:31 CET] <wm4> hm, actually I think CC used to buffer until the next, and tmm1 introduced a "realtime" mode which avoids this
[19:22:37 CET] <wm4> either way it's pretty messy
[19:23:33 CET] <wm4> I don't know if ffmpeg.c can even use this "realtime" mode
[19:24:48 CET] <wm4> (mpv supports this realtime mode, but it can do so because it can adjust the duration of the current ASS event - ffmpeg.c can't do that when muxing ASS subtitles)
[19:49:17 CET] <ryantheseer> Hi, I'm trying to build an RTSP/RTP client with ffmpeg. Can anyone tell me how to switch the "preference" of ffmpeg to use TCP instead of UDP? I'm interested in preferring UDP even if TCP is available from the server. Right now I've just hard-coded the RTSP_LOWER_TRANSPORT_UDP on line 1891 of libavformat/rtsp.c, where the ff_rtsp_make_setup_request
[19:49:17 CET] <ryantheseer> () function is called. Any better ideas?
[19:54:39 CET] <rcombs> ryantheseer: pass the rtsp_transport option?
[19:55:05 CET] <rcombs> ryantheseer: or for this particular goal, set prefer_tcp to false
[20:03:05 CET] <ryantheseer> Of course! Perfect.
[20:23:40 CET] <wm4> BtbN: can I get a patch that makes ffmpeg_cuda work? even if it doesn't work with nvenc for now
[20:24:04 CET] <wm4> actually ffmpeg_cuvid
[20:30:35 CET] <BtbN> wm4, work in what way? nvenc is the only thing I found that doesn't work.
[20:30:52 CET] <wm4> copy mode I guess
[20:31:13 CET] <BtbN> From what I can see it works fine, but something changed, which makes nvenc behave weird.
[20:31:27 CET] <BtbN> Can't figure out what that something is though
[20:31:51 CET] <wm4> I mean ffmpeg_cuvid.c contains nonsensical code on my branch
[20:33:54 CET] <BtbN> what do you mean?
[20:35:58 CET] <wm4> BtbN: I just commented out the fields that went away
[20:36:07 CET] <wm4> like resample_format or whatever it was
[20:36:28 CET] <BtbN> you removed it, as it isn't needed anymore. Seems correct to me.
[20:36:36 CET] <BtbN> the resample_pix_fmt
[20:36:44 CET] <wm4> ah maybe
[20:37:00 CET] <wm4> so should I send the patches as they are?
[20:37:58 CET] <BtbN> Yeah, I can't see something that's wrong with them. Except for the part where they somehow break the hwaccel-path for cuvid->nvenc
[20:38:32 CET] <BtbN> But I wouldn't worry to much about that, I or someone will find it eventually
[20:41:33 CET] <BtbN> The ffmpeg_cuvid.c can probably still be simplified a lot though.
[20:43:37 CET] <wm4> ffmpeg_qsv could
[20:43:52 CET] <wm4> some equivalent code could be dropped
[20:45:28 CET] <funman> Chloe: you just want the duration of teletext?
[20:46:36 CET] <BtbN> wm4, if I get rid of cuvid_transcode_init, can I just get rid of the entire loop around it in ffmpeg.c?
[20:46:59 CET] <JEEB> funman: yeah, he currently has a small issue with the default timing from libzvbi (?) https://usercontent.irccloud-cdn.com/file/f5y5JSJa/Screen%20Shot%202017-02-09%20at%2016.30.52.png
[20:47:11 CET] <BtbN> it basically does nothing anymore
[20:47:57 CET] <wm4> BtbN: I guess so
[20:48:04 CET] <wm4> I don't see any need for it in the future
[20:48:52 CET] <BtbN> ok, I'll simplify the ffmpeg_cuvid.c quite a bit then
[20:49:25 CET] <funman> JEEB: agree, that language looks very wrong
[20:49:35 CET] <JEEB> well, that too :D
[20:50:15 CET] <JEEB> but yeah, seems like either zvbi or the avcodec wrapper set the default duration of a line to 30s or so, and don't cut it f.ex. when the next thing comes
[20:52:59 CET] <funman> hm yes it's 30s
[20:53:33 CET] <funman> txt_duration in libzvbi-teletextdec.c
[20:54:44 CET] <funman> in upipe the next teletext replaces the previous one
[20:54:52 CET] <funman> usually you have one before you reach the 30s
[20:55:13 CET] <JEEB> yea
[20:55:29 CET] <funman> and empty strings to end display
[20:55:33 CET] <JEEB> that's how I dealt with DVDsub decoding in mpc-hc a few years back
[20:55:33 CET] <funman> Chloe: 
[20:55:47 CET] <JEEB> ah, empty strings as endpoints
[20:55:53 CET] <JEEB> makes sense funny enough
[20:57:09 CET] <funman> iirc
[20:58:58 CET] <funman> i use the zvbi renderer, don't remember if they show up as a subtitle without a pixmap or something else
[21:06:45 CET] <Chloe> does the zvbi bitmap renderer work in ffmpeg then?
[21:07:10 CET] <wm4> that's probably image based
[21:07:26 CET] <wm4> since ffmpeg can transcode only to other image based things (or video), there's no problem
[21:07:32 CET] <Chloe> it didnt work for me, so I was going to use ASS and then do ASS -> DVB
[21:07:38 CET] <funman> it's rendered by libzvbi
[21:07:48 CET] <wm4> the problem is only with text, which can be "transcoded" to soemthing that needs durations, like ASS
[21:08:03 CET] <funman> txt_format option in the decoder
[21:08:28 CET] <funman> there's a tiny old school font
[21:08:42 CET] <Chloe> yes, that doesnt work
[21:10:52 CET] <funman> why not?
[21:11:22 CET] <BtbN> jkqxz, what's up with the child_device qsv has? It seems weird.
[21:12:07 CET] <BtbN> QSV seems to have two devices because of that. One is the -hwaccel_device, and the other is the qsv_device.
[21:14:02 CET] <jkqxz> -qsv_device is working around the fact that -hwaccel_device doesn't actually pass the thing you want.
[21:14:04 CET] <BtbN> what I also find to be weird is that the hwaccel_device, represented by the static global hw_device_context in ffmpeg.c, is still set via the per-stream hwaccel_device option, which gives the wrong impression of it being per-stream, which it isn't.
[21:14:35 CET] <BtbN> jkqxz, I'm also looking at hwcontext_qsv.c, there is the device, and the child_device?
[21:14:41 CET] <Chloe> funman: I'm not sure, it jsut renders incorrectly. Anyway, I think it'd be better to have it as ASS. The issue with the text is: how would I know if there will be an empty page afterwards (to signal duration), and how will I know when the next page is.
[21:14:46 CET] <BtbN> and it create a sub-hwdevice_ctx, which seems super weird.
[21:15:25 CET] <BtbN> Like, I'm unsure which method to choose for cuvid. Just keep using the -hwaccel_device, and basically ignore all but the first occurance, or adding a -cuvid_device?
[21:15:34 CET] <wm4> Chloe: again, look at CC, it answers these questions more or less (although I suppose it might be hard to get through that code)
[21:15:51 CET] <jkqxz> Yeah, there are two devices.  QSV doesn't really access the hardware directly, it talks through a child device which is VAAPI on Linux and DirectX-something on Windows (DXVA2 only there, but other versions can also work).
[21:16:00 CET] <jkqxz> VAAPI also has the single device.
[21:16:10 CET] <jkqxz> (And there there really is only one.)
[21:16:22 CET] <BtbN> And still uses a dedicated option instead of the ist->hwaccel_device
[21:16:32 CET] <BtbN> why?
[21:16:41 CET] <jkqxz> Because we don't have multiple device support.
[21:16:50 CET] <jkqxz> Multiple device support: https://github.com/fhvwy/libav/tree/device (WIP).
[21:17:02 CET] <funman> Chloe: you know when you receive the next one ;)
[21:17:03 CET] <BtbN> well, the entirety of ffmpeg.c doesn't have multiple device support, seeing there is only one global hw_device_ctx
[21:17:25 CET] <jkqxz> Indeed, I am trying to eliminate that.
[21:17:54 CET] <BtbN> Ok, I'll stick to just using the ist->hwaccel_device then
[21:18:00 CET] <BtbN> as cuvid in theory can easily use multiple devices
[21:18:09 CET] <BtbN> And it doesn't break existing commandlines.
[21:18:22 CET] <jkqxz> Sure.
[21:18:40 CET] <jkqxz> Since you aren't using generic hwupload, it doesn't matter.  (That gets fed the highlander device.)
[21:19:03 CET] <BtbN> by now, cuvid could easily use generic hwupload.
[21:19:14 CET] <BtbN> hwupload_cuvid is just a relic, and the generic one should work
[21:19:20 CET] <BtbN> *hwupload_cuda
[21:19:51 CET] <jkqxz> Well, yes, but that would need to set the device somewhere in ffmpeg (and not depend on having a decoder to do it).
[21:20:51 CET] <jkqxz> Which is what the -vaapi_device and -qsv_device options do, and using the global device on -hwaccel_device was deemed acceptable because genuinely-multiple-device cases of those are quite crazy.
[21:22:24 CET] <jkqxz> Talking of devices, I think everyone is happy now with AVCodecContext.hw_device_ctx?
[21:23:31 CET] <wm4> the complaints will start once everything is done and implemented
[21:37:56 CET] <Chloe> what is 'pac' in ccaption_dec.c?
[21:40:49 CET] <wm4> I don't know...
[21:43:27 CET] <Chloe> i wanted to say packet but I see usages of pkt so I dont think it is that
[21:45:57 CET] <BtbN> wm4, https://github.com/BtbN/FFmpeg/tree/filter-merge
[21:46:41 CET] <wm4> BtbN: ok, I will include that patch when sending the series to the ML tomorrow
[21:47:11 CET] <BtbN> I might still change it a bit, so look at it again before
[21:47:39 CET] <BtbN> it still doesn't work with it though, same oom
[21:48:39 CET] <wm4> thanks anyway... I'll ping you before sending it
[21:49:02 CET] <BtbN> I'm still at a loss why it fails. If it's really the initialization order...
[21:57:42 CET] <BtbN> well, the hwdownload route works now...
[21:57:46 CET] <BtbN> sooo, no idea what's going on
[21:58:06 CET] <jkqxz> BtbN:  cuvid_get_buffer() isn't needed - lavc automatically calls av_hwframe_get_buffer() in the way you want.
[21:58:22 CET] <BtbN> copied that from qsv
[21:58:30 CET] <BtbN> suspected it might be the reason for nvenc exploding
[21:58:31 CET] <jkqxz> (It also technically violates the API we are trying to introduce, since hw_frames_ctx is no longer readable.)
[21:58:38 CET] <jkqxz> Yeah, I'm going to remove it from there too.
[22:00:00 CET] <BtbN> jkqxz, you happen to know where the sw_pix_fmt in avctx comes from?
[22:00:13 CET] <BtbN> the one ffmpeg_qsv and _cuvid use
[22:00:28 CET] <jkqxz> The decoder has to set it for the get_format() callback to use.
[22:00:49 CET] <BtbN> but... the get_format callback wasn't called yet at that time?
[22:02:35 CET] <jkqxz> Yes, it's used to signal the format which is in the stream so that the user can make an appropriate choice of the surface format in the get_format() callback.
[22:03:17 CET] <BtbN> but at least for cuvid.c it needs the hwframes_ctx to bet set at init
[22:03:31 CET] <BtbN> and init, or even later at first frame, is when ff_get_format is called
[22:04:24 CET] <wm4> that means cuvid must use the new device API I guess?
[22:04:25 CET] <jkqxz> Er, that's not how the API is meant to work.  (And is why we are adding hw_device_ctx.)
[22:06:05 CET] <BtbN> looking at ffmpeg_vaapi.c: ctx->frames->sw_format = (avctx->sw_pix_fmt == AV_PIX_FMT_YUV420P10 ?
[22:06:06 CET] <BtbN>                               AV_PIX_FMT_P010 : AV_PIX_FMT_NV12);
[22:06:18 CET] <BtbN> I guess I will copy that logic for cuvid.
[22:06:54 CET] <BtbN> i need a 10 bit sample...
[22:35:49 CET] <BtbN> wm4, jkqxz: Ok, figured out how that works, it just calls the cuvid_init function again each time the ff_get_format callback is called.
[22:36:09 CET] <BtbN> So it needs a minor change in cuvid.c to actually work that way.
[22:36:13 CET] <BtbN> Pushed that one as well.
[22:38:46 CET] <BtbN> doesn't exactly make the whole thing less hacky.
[22:39:01 CET] <BtbN> But it's only an interim-solution anyway.
[00:00:00 CET] --- Fri Feb 10 2017