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

[burek]

[00:11:23 CET] <philipl> BtbN: Yes, there is ambiguity - what does "select pascal chips" mean for each item, but the nvidia driver docs continue to indicate all 10x0 cards have the same Feature Set H
[00:11:29 CET] <philipl> so I really hope they are all vp9 10bit enabled.
[00:11:39 CET] <BtbN> I doubt it
[00:12:08 CET] <philipl> BtbN: doubt what?
[00:13:05 CET] <philipl> I'd also like to believe they'd make a big statement in their support table about 10bit vp9 and then eventually it turns out to be 1050 only.
[00:13:15 CET] <philipl> believe they wouldn't do that, rather.
[00:20:44 CET] <cone-793> ffmpeg 03Michael Niedermayer 07master:6a37abc59af4: avcodec/h264_sei: Check actual presence of SEI picture timing instead of implying it
[00:22:11 CET] <kierank> michaelni: what does this patch do
[00:25:47 CET] <michaelni> kierank, fixes a sample that lacks some SEIs that SPS says should be there
[00:25:58 CET] <kierank> fixes how
[00:26:38 CET] <BtbN> philipl, well, the 1050 is the most recent card. I can totally see that happening.
[00:26:47 CET] <michaelni> kierank, corrects the interlaced flag, so no major change i think
[00:27:10 CET] <kierank> michaelni: can you explain this next time
[00:27:36 CET] <philipl> BtbN: so can I. I'm just hoping that the way they're talking about it means that it isn't 1050-only
[00:27:54 CET] <michaelni> kierank, yes i realize now i should have written this in the commit message
[00:42:31 CET] <tmm1> jkqxz: ran a profiler and all the time was spent in memcpy()
[00:43:08 CET] <tmm1> jkqxz: looks like vaDeriveImage is available but quite slow.. the comment in hwcontext_vaapi.c says memcpy is known to be slow, but looks like on this old kernel/drm writes are slow as well
[00:43:24 CET] <tmm1> as soon as i set derive_works=0 it got fast
[00:51:57 CET] <tmm1> also interesting: its only slow on units with 8GB ram. on 2GB its fine
[01:32:14 CET] <J_Darnley> What the deuce?  Why does ffmpeg think I have cuda availble?  How does it find headers that I didn't think existed here?
[01:33:05 CET] <kierank> J_Darnley: yes i have a trac ticket ope nfor that
[01:33:09 CET] <kierank> why the fuck does it include cuda
[03:58:53 CET] <jamrial> kierank: because it's using dynlink at runtime, and headers from the compat folder
[04:53:21 CET] <philipl> BtbN: for the record, no vp9 10bit support with 378.13.
[06:37:04 CET] <wm4> phh: so 1050 GTX doesn't support it?
[06:37:15 CET] <wm4> s/phh/philipl/
[06:40:00 CET] <philipl> No idea about 1050.
[06:40:08 CET] <philipl> No one with a 1050 around here I can ask to try cuvid out.
[06:40:19 CET] <philipl> nevcairiel has a second hand report of it working with dxva on windows.
[06:41:12 CET] <philipl> The nvidia page is not precise on what supports what, but what indirect documentation exists puts the 1050 in the same hardware generation as the rest of 10x0
[06:41:23 CET] <philipl> and it doesn't work with my 1080.
[06:41:36 CET] <philipl> but until they officially say 10bit is enabled, we can't say for sure where it works.
[06:46:21 CET] <wm4> philipl: I have a 1050
[06:46:32 CET] <wm4> but cuvid is still broken for me (no reboot done yet)
[06:47:40 CET] <philipl> Do you have a real technical reason you can't reboot, or is it just the principle that you should never have to reboot to fix a problem?
[06:50:17 CET] <wm4> I'd lose my UI session which would be annoying
[06:50:51 CET] <philipl> It doesn't get any easier over time :-)
[07:05:22 CET] <wm4> tmm1: if your patch gets in, it should probably also be done when getting a H264_NAL_SPS
[07:05:42 CET] <wm4> and I'm not really sure why you call decode_slice there
[07:05:56 CET] <wm4> I guess the VT decoder is stateful, and you can just feed it those NALs
[07:06:12 CET] <wm4> (which means the extradata setup is overcomplicated and could be simplified)
[10:31:01 CET] <BtbN> wm4, you can drop patch v2 8/8, it's already in master.
[10:33:21 CET] <durandal_1707> wm4: you gonna convert mpl2 to FFTextReader?
[10:34:58 CET] <wm4> BtbN: oh I see, git rebase duplicated it
[10:35:10 CET] <wm4> durandal_1707: probably not, it helps only if you want to support UTF-16 subtitle files
[10:35:18 CET] <BtbN> Yeah, I moved the block around a bit, so the patch still applies
[12:46:20 CET] <cone-986> ffmpeg 03Paul B Mahol 07master:ee4aa388b223: adpcm: fix clipping for yamaha
[12:54:04 CET] <durandal_1707> atomnuker: do you know anything about LBRR in opus?
[13:13:14 CET] <BtbN> test current git head -> tests 3.1.3
[14:21:06 CET] <Chloe> Can I make a pass a demuxer pass an avstream to another demuxer
[14:22:32 CET] <nevcairiel> no
[14:23:32 CET] <Chloe> Ok. How about a DVB teletext demuxer within the mpegts one?
[14:23:51 CET] <kierank> no, it's the "chained demuxer" problem
[14:24:24 CET] <Chloe> I mean inlining it in the code
[14:24:29 CET] <Chloe> It's pretty horrible tbh
[14:24:50 CET] <nevcairiel> who really cares about teletext anyway
[14:25:13 CET] <Chloe> some people apparently
[14:36:22 CET] <JEEB> I care about it as well :D
[14:36:31 CET] <JEEB> be it ARIB captions or DVB-TT
[14:36:53 CET] <JEEB> although thankfully I've only had a single track in a single PID so far
[14:37:06 CET] <JEEB> no multiple tracks in a single PID shenanigans
[14:37:33 CET] <nevcairiel> teletext is usually like that
[14:37:38 CET] <nevcairiel> since its one object with many pages
[14:37:53 CET] <JEEB> yea
[14:40:23 CET] <JEEB> but not many alternatives for live TV subtitles that are text unfortunately :/
[14:40:47 CET] <nevcairiel> teletext isnt exactly text
[14:40:59 CET] <nevcairiel> its low-fi pixel art =p
[14:41:24 CET] <nevcairiel> anyhow whats wrong with dvb subtitles
[14:42:27 CET] <JEEB> well, you can get text out of libzvbi :D
[14:42:32 CET] <JEEB> and that's what matters 8)
[14:42:57 CET] <JEEB> it's really hard to put that into web streaming without hardcoding (unless something actually supports base64 PNGs in something like TTML)
[14:46:04 CET] <Chloe> nevcairiel: nothing, the issue is the 100s of encodes which have TT and need subs
[14:46:27 CET] <nevcairiel> dont we have zvbi to read them
[14:46:31 CET] <Chloe> we do
[14:46:46 CET] <nevcairiel> if its so painful to handle them, maybe best to keep to the external lib
[14:47:08 CET] <Chloe> you can't transcode all tracks though
[14:47:16 CET] <Chloe> this is the issue, not the library
[14:47:28 CET] <Chloe> s/tracks/languages/
[14:47:43 CET] <nevcairiel> you can probably duplicate the input stream a nd decode it several times in different languages
[14:47:43 CET] <Chloe> if you have bs TT which has multiple languages in one stream
[14:48:02 CET] <Chloe> nevcairiel: I dont think you can do that without reading the input stream multiple times
[14:48:16 CET] <JEEB> the problem seems to stem that in ffmpeg.c at least you can't duplicate an input track so that you could set demuxer options for it N times
[14:48:21 CET] <Chloe> As in, you cant go input -> splitter -> zvbi
[14:48:28 CET] <Chloe> it's splitter -> input -> zvbi
[14:48:30 CET] <JEEB> so you end up reading the file N times, which depending on the protocol can be funzies
[14:49:01 CET] <nevcairiel> so make that work instead
[14:49:16 CET] <nevcairiel> probably better then some ugly hackery in the poor mpegts demuxer
[14:55:09 CET] <Chloe> I'm probably just going to write a standalone tool, fuck ffmpeg.c tbh
[14:56:41 CET] <JEEB> nevcairiel: hmm, so in the API you can duplicate an input stream so that you can give all of its duplicates different AVOptions?
[14:56:54 CET] <JEEB> stream as in AVStream, not a full input
[14:57:19 CET] <nevcairiel> what does the API have to do with that
[14:57:44 CET] <nevcairiel> your transcoding tool can do w hatever it wants with the data from the input avformat, and just send it to two output streams if it wants t o
[14:58:02 CET] <JEEB> right
[14:58:09 CET] <JEEB> AVPackets come and get sent to two things
[14:58:29 CET] <JEEB> that would work since libzvbi is a lavc thing
[14:59:03 CET] <JEEB> so you open two decoders, and configure them accordingly and feed to both the packets you're getting
[14:59:15 CET] <JEEB> then you get two streams of data
[14:59:37 CET] <JEEB> I haven't slept enough recently, so sorry :P I was still thinking on the lavf level
[15:00:00 CET] <nevcairiel> exactly
[15:00:10 CET] <nevcairiel> somehow i thought ffmpeg.c could even do that
[15:00:14 CET] <nevcairiel> but maybe only post-decoding
[15:00:18 CET] <nevcairiel> not pre-decoding
[15:00:26 CET] <JEEB> yea
[15:00:45 CET] <wm4> Chloe: the really lame option is to filter the subs by language in the decoder, and have a decoder private option to select the language
[15:00:57 CET] <nevcairiel> thats basically what we have today, isnt it
[15:00:59 CET] <Chloe> wm4: this already exists
[15:01:02 CET] <JEEB> yea
[15:01:10 CET] <Chloe> but hooking it up is more tricky
[15:39:21 CET] <wm4> I don't understand why we got to fix every< obscure 
[15:39:23 CET] <wm4> oops
[15:39:39 CET] <wm4> ...every obscure regression, but something like mp4 edit lists makes it in just fine
[15:40:06 CET] <durandal_170> because it came from ffmpeg.org mailing address
[15:40:47 CET] <durandal_170> who gives such mail addresses?
[15:46:32 CET] <wm4> michaelni: if you don't like the merges, do it yourself
[15:46:54 CET] <wm4> I'm not going to delay this because you come up with a regression every other day
[15:47:10 CET] <wm4> I'm only merging, not fixing every regression this will ever cause
[15:52:38 CET] <durandal_170> kierank: what you did to atomnuker ?
[15:54:06 CET] <kierank> durandal_170: ???
[15:55:02 CET] <durandal_170> he is not answering my questions?
[15:55:24 CET] <kierank> He is in San Francisco
[16:12:59 CET] <jarkko> i just received this message into my email 
[16:13:01 CET] <jarkko> https://bugs.launchpad.net/linuxmint/+bug/1664999
[17:34:41 CET] <michaelni> atana, do you have time to continue working on af_peakpoints2 ?
[17:34:59 CET] <atana> michaelni, was just writing to you
[17:35:00 CET] <atana> yes
[17:35:33 CET] <atana> mode store is implemented. Could you explain lookup so that I can start working
[17:35:57 CET] <durandal_170> whats difference between peakpoints and peakpoints2?
[17:36:20 CET] <atana> peakpoints is naive implementation
[17:36:55 CET] <atana> peakpoints2 is supposed to perform well for billions of songs/audios
[17:37:54 CET] <michaelni> atana, lookup is very similar to storing points
[17:38:56 CET] <michaelni> or each f0 the correspondig file is opened, and each entry from the file is read and compared to the peakpoints we are trying to lookup
[17:41:15 CET] <michaelni> atana, read() each entry in a array, use bytestream2_init() to init GetByteContext and then use bytestream2_get_le16() to read the values similar to how they were written
[17:41:43 CET] <atana> in order? say A-> f1,f2,f3,f4..f8,t1..t8:songid  B-> F1,..F8,T1..T8:Songid then f1 should be matched with F1, f2 with F2 and so on..? 
[17:42:37 CET] <michaelni> atana, yes, the matching is exactly in order f1 == F1, f2 == F2, ...
[17:42:59 CET] <michaelni> thats the advantage of leaving the -1 in, matching is simpler
[17:43:24 CET] <michaelni> atana, when matching you must skip the -1, -1 == -1 is not a good match 
[17:43:59 CET] <atana> ok
[17:45:14 CET] <michaelni> durandal_170, atana billions of songs is the theoretical goal, i dont think we will achieve this in this round of outreachy and we surely cant test that anyway
[17:53:46 CET] <atomnuker> durandal_170: no idea what lbrr is
[19:01:54 CET] <TD-Linux> durandal_170, atomnuker, lbrr is the SILK layer fec data in Opus
[19:02:32 CET] <TD-Linux> you normally only see it in live or recorded WebRTC streams
[19:02:53 CET] <TD-Linux> I believe ffmpeg's opus decoder totally falls over when it sees it
[19:03:08 CET] <durandal_170> one can decode audio ignoring lbrr frames?
[19:04:14 CET] <TD-Linux> durandal_170, yes (though if you have packet loss it's of course better to use it)
[19:04:46 CET] <TD-Linux> https://trac.ffmpeg.org/ticket/4641
[19:04:52 CET] <atana> michaelni, I have updated the repo. the code is not complete. in line 606 what should be the size to read? it should contain all the file content right?
[19:13:38 CET] <michaelni> atana, lets just read one entry at a time same as when writing, would be simpler
[19:14:33 CET] <michaelni> atana, that is a loop that reads one entry compares it and then does the next
[19:15:02 CET] <michaelni> we can change it later to read the whole file if that turns out to be a bottleneck speed wise
[19:18:22 CET] <atana> michaelni, read till? what's stoping condition?
[19:21:12 CET] <michaelni> atana, read() returns the number of bytes read, if thats 0 EOF (end of file) is reached, if its -1 then there was an error
[19:21:50 CET] <atana> ok
[19:40:02 CET] <durandal_1707> is mpl2 patch ready to commit?
[19:44:56 CET] <durandal_1707> anybody interested in native ilbc decoder?
[19:47:05 CET] Action: michaelni reads "native libc"
[19:51:10 CET] <atomnuker> its a voice codec so it'll be annoying to write
[19:51:44 CET] <durandal_1707> there is reference implemementation
[19:53:36 CET] <kierank> Does ilbc exist as a file
[19:54:00 CET] <kierank> Instead of In VoIP
[20:03:44 CET] <llogan> rcombs: you asked about the twitter: that would be me mostly, but reynaldo has done a few
[20:03:59 CET] <rcombs> cool
[20:04:12 CET] <rcombs> (no particular reason, just curious who I was talking to)
[20:04:42 CET] <llogan> now you know who to blame, but reynaldo and i can just blame each other. plausable deniability.
[20:05:19 CET] <durandal_1707> kierank: you can create .lbc files
[20:06:08 CET] <llogan> also, if anything wants me tweet something just ping me.
[20:06:17 CET] <llogan> *anyone
[20:14:18 CET] <durandal_1707> llogan: tweet: sending bitcoins for samples that are not decoded by ffmpeg
[20:19:15 CET] <cone-907> ffmpeg 03Mulvya 07master:449ce456a6c9: doc: correct table end for metadata filter
[20:20:36 CET] <llogan> durandal_1707: we don't have any bitcoins to send for samples
[20:21:21 CET] <durandal_1707> llogan: ask kierank :)
[20:23:01 CET] <llogan> durandal_1707: here's one for free http://stackoverflow.com/q/42192078/1109017
[20:28:22 CET] <RiCON> durandal_1707: http://www.infognition.com/ScreenPressor/
[20:28:43 CET] <RiCON> 4 samples there
[20:31:54 CET] <durandal_1707> RiCON: they are even giving source code
[20:34:06 CET] <atana> michaelni, what should be permission while opening file for reading? S_IREAD is not recognized
[20:38:11 CET] <atana> replacing it with 0444
[20:45:43 CET] <michaelni> atana, 3rd argument shouldnt matter for read only, you can pass just 2 arguments
[20:51:33 CET] <michaelni> atana, entry and buff need to be 32+2 you write 8 frequencies, 8 times and 1 song id all as le16 that makes 17*2 bytes
[20:54:35 CET] <kierank> atomnuker: did you find a plug
[20:54:39 CET] <kierank> and are you on coverity?
[20:55:36 CET] <atomnuker> yes
[20:55:45 CET] <kierank> to both?
[20:56:37 CET] <atomnuker> kierank: yep, I'm to your left
[20:56:57 CET] <kierank> ok you saw the opus stuff
[20:57:41 CET] <atomnuker> yep, that should fix alot of the hard to track uninizialized variable stuff I'm getting in valgrind
[21:00:59 CET] <cbsrobot> anyone heard of http://www.fastcompression.com/products/ffmpeg/gpu-ffmpeg.htm ?
[21:02:42 CET] <atana> michaelni, updated repo.
[21:03:26 CET] <atana> but there isn't any match. may be something wrong with the my code. going through it
[21:04:53 CET] <michaelni> atana, unrelated but "else if (frequencies[index] > p->windowSize-64) {" this should use >=
[21:06:14 CET] <durandal_1707> cbsrobot: sue them
[21:08:28 CET] <cbsrobot> durandal_1707: not sure what they really offer ... I did download the j2k codec but did not find any hints to ffmpeg
[21:10:13 CET] <michaelni> atana, i would suggest read(fp, buff, sizeof(buff)); that is reading all 34 bytes the 17 values of one entry and then loop over the 8 frequencies not read one at a time
[21:14:36 CET] <atana> I see
[21:51:55 CET] <atana> michaelni, updated repo
[21:52:17 CET] <atana> doesn't find match
[21:57:07 CET] <pross> 1~
[22:05:46 CET] <michaelni> atana, remove the match_time stuff, only compare frequencies, and skip -1
[22:07:51 CET] <michaelni> atana, also to read 16bit signed values use (int16_t)bytestream2_get_le16(&gb);
[22:08:20 CET] <michaelni> atana, if you dont use a (int16_t) cast the -1 turn into 65535 which doesnt match
[22:09:43 CET] <atana> ok
[22:10:36 CET] <durandal_1707> there is sign_extend()
[22:23:37 CET] <cone-907> ffmpeg 03Rostislav Pehlivanov 07master:1b90e2414df0: opus_pvq: fix uninitialized variable usage
[22:29:45 CET] <atana> michaelni, code pushed. now it finds matches
[22:35:15 CET] <michaelni> atana, great!, next try with 2 songs and see if it can distinguish them
[22:35:27 CET] <atana> ok
[22:39:26 CET] <atana> michaelni,  what return value does avpriv_open() should return if the file it tries to read is not present?
[22:42:16 CET] <michaelni> should be -1 with the error code indicating missing file in errno
[22:44:22 CET] <atana> but when I tried lookup with new song which is not indexed it doesn't go inside fp==-1 condition rather it tries to read file and hits retval < 0 condition
[22:46:33 CET] <atana> michaelni, I tried with two songs and it's able to match the right song
[22:47:49 CET] <michaelni> atana, great, did you add a AVOption to specify song_id when storing ?
[22:49:30 CET] <atana> not yet. For testing I manually changed it
[22:49:46 CET] <atana> I will add song_id option in AVOption
[22:50:01 CET] <michaelni> atana, ahh ok, yes, adding that will make testing easier
[22:51:34 CET] <atana> is there any way to make it as optional as when mode=0 (store case) song_id is required while when mode=1(lookup case) we don't know song_id
[22:56:03 CET] <michaelni> atana, of course, all avoptions are kind of optiona unless you explicitly write code to check that they are set
[22:56:25 CET] <atana> I see
[22:57:39 CET] <atana> michaelni, what does this  {.i64=1} mean in avoption ? is this default value ?
[22:57:43 CET] <atana> or example
[22:58:00 CET] <michaelni> atana, yes its default
[22:58:23 CET] <atana> Then I am setting default song_id as -1 
[22:59:00 CET] <atana> and make sure is mode=0 then song_id should be provided
[22:59:51 CET] <michaelni> atana, yes exactly
[23:05:28 CET] <michaelni> atana, i would also suggest to skip storing any entries that have less than 3 frequncy peaks (that is all -1 except 2 or 1) theres not enough information in these they would only waste space
[23:06:13 CET] <michaelni> its like 40% fewer entries
[23:07:42 CET] <atana> ok
[23:25:53 CET] <RiCON> atomnuker: btw, crash still happens with that commit
[23:26:31 CET] <atomnuker> yes, I know, there are others
[23:52:32 CET] <cone-907> ffmpeg 03Rostislav Pehlivanov 07master:3fc86f0d69d3: opusenc: fix coarse energy quantization with 2 bits left
[00:00:00 CET] --- Thu Feb 16 2017