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

[burek]

[00:12:19 CET] <atana> michaelni, it's updated
[00:19:48 CET] <Chloe> Are there any decoders which output more than one stream?
[00:24:16 CET] <JEEB> I think either the avc parser or decoder exports the closed captions, if available, as a separate track
[00:24:35 CET] <michaelni> atana, ok, frequencies[index] could be -1 i think, a check for that and skiping these is needed
[00:25:07 CET] <michaelni> they would fall in "if (frequencies[index] < 64) " oterwise
[00:30:56 CET] <atana> michaelni, check added and updated
[00:35:16 CET] <michaelni> atana, you use "mag = getAbs(tab[freq]) + 1;" this mismatches the 2nd loop which uses getAbs(tab[j]), i tink there should be no + 1
[00:36:28 CET] <atana> it was used in the case of log. now it's not needed will remove it
[00:37:04 CET] <michaelni> ok
[00:38:42 CET] <atana> updated
[00:42:31 CET] <michaelni> atana, ok, next we should discard "unstable" points, iam not 100% sure what is the best way but a very easy way is to count the number of points with  maxscores[index] < getAbs(tab[j])*2 and if there are more than 3 then discard the point (aka mark as -1)
[00:43:20 CET] <michaelni> that can be done in the existing 2nd loop
[00:51:59 CET] <atana> michaelni, what are unstable points?
[00:53:05 CET] <michaelni> atana, something that when noise is added will have a different peak
[00:53:58 CET] <michaelni> that is "not usefull" points 
[01:03:19 CET] <atana> michaelni, so this a additional check? should it be done after finding all invalid points? count more than 3 (is this count in neighbour region)?
[01:04:47 CET] <michaelni> atana, its just a  "if (maxscores[index] < getAbs(tab[j])*2)  count++;" after  or before "if (maxscores[index] < getAbs(tab[j])) {"
[01:05:02 CET] <michaelni> and then if count > 3 mark it as -1
[01:05:44 CET] <michaelni> we may need to adjust the "3" and "*2" once we test this with actual music 
[01:06:37 CET] <michaelni> other values may work better its just simple way that probably will work ok so we can quickly move on
[01:11:19 CET] <atana> now I see, so you mean making previous discard condition more robust to noise by adding an extra condition
[01:11:25 CET] <atomnuker> is there anywhere I can see the work in progress patch/git repo yet?
[01:12:34 CET] <michaelni> atana, yes
[01:14:02 CET] <philipl> BtbN: It's hard to prove at this stage, but it's likely that the cuvid parsers are not as comprehensive as the ffmpeg parsers.
[01:14:14 CET] <michaelni> atomnuker, https://github.com/atana1/ffmpeg the peakpoints2 filter
[01:14:28 CET] <philipl> I know that it cannot handle wmv9 content, even though the vc1 decoder would handle it fine (proven by vdpau)
[01:15:09 CET] <philipl> There are also examples of hevc content that don't decode properly, which could be due to incorrect parsing rather than a decoder error.
[01:16:27 CET] <philipl> If it wasn't such a pain to write hwaccel integrations, I'd have experimented with it. I guess if elenril wants to try it, more power to him.
[01:17:17 CET] <philipl> It'll certainly turn into many more lines of code, for whatever benefit it provides.
[01:23:39 CET] <atana> michaelni, it's updated
[01:28:37 CET] <michaelni> atana, what i meant was discard the points where either of the consitions is true not the ones where both are true
[01:29:00 CET] <atana> oh ok. will fix it
[01:33:56 CET] <atana> done
[01:37:15 CET] <michaelni> atana, ok, count should start at 0 (or at least thats what i had in mind)
[01:38:35 CET] <atana> updated
[01:40:01 CET] <michaelni> atana, the next step is the pair points, the way you implemented them is more for 2D. With 1D i would suggest to simply use 4 consecutive points. that is instead of  cpoints[i] and cpoints[j] use cpoints[i], cpoints[i+1],cpoints[i+2], cpoints[i+3]
[01:40:47 CET] <michaelni> that results on more information for each and fewer which compensates the difference of 1d and 2d
[01:43:54 CET] <atana> you mean now hash should be f1:f2:f3:f4:timediff  so how should now be timediff when we are taking 4 points for consideration?
[01:46:00 CET] <michaelni> atana, there wold be 3 timediffs (t2-t1, t3-t2, t4-t3) but i suspect they will be all close to 0
[01:46:30 CET] <atana> yes as they are from same fft window
[01:46:39 CET] <michaelni> yes
[01:53:59 CET] <Chloe> JEEB: i dont think it does? or at least I cant find any reference to it outputting multiple streams
[01:54:44 CET] <JEEB> I just noticed it gets probed within the video track
[01:54:52 CET] <JEEB> so seems like I was incorrect
[01:55:03 CET] <JEEB> I do remember *something* exporting another stream from another
[01:55:28 CET] <KGB> [13FFV1] 15dericed opened pull request #50: WIP add method to use latex(pdf) or ascii(rfc) for math (06master...06master) 02https://git.io/vDwz3
[01:57:21 CET] <atana> michaelni, I am going to bed now will continue later. Let me know if you have any dataset in mind for testing the filter.
[01:58:17 CET] <michaelni> atana, ok, no specific dataset in mind, will you have time tomorrow to continue ?
[02:01:03 CET] <atana> I will be available late tomorrow. Around 7 pm IST which I guess is 12:30 AM GMT 
[02:01:16 CET] <Chloe> is master broken?
[02:01:30 CET] <Chloe> oh. need to configure again
[02:02:00 CET] <michaelni> atana, ok ill try to be online, good night, sleep well!
[02:02:11 CET] <atana> ok good night
[02:02:30 CET] <Chloe> michaelni: do you know if there are any decoders which output multiple streams?
[02:16:03 CET] <michaelni> Chloe, as in 2 streams in one AVStream ? there are a few that support it in the syntax but thats not so much my area . dual_mono_mode in aac is one we do support
[02:17:58 CET] <Chloe> michaelni: kinda, I guess. The issue is DVB teletext can have multiple languages, and if there were a avstream for each of those then it'd make it easy to work with (I.e. Transcode each language separately) 
[02:21:29 CET] <Chloe> I guess one way would be to add it as a format as well and if there's only one language do a direct pass through to the codec
[02:21:50 CET] <Chloe> Though that seems kinda dirty, can't think of a better way to do it though 
[02:37:49 CET] <atomnuker> Chloe: some codecs can output multiple frames per packet
[02:37:52 CET] <atomnuker> AV_CODEC_CAP_SUBFRAMES
[02:39:45 CET] <Chloe> Ah thanks I'll take a look at that option tomorrow (need to sleep now l
[06:22:13 CET] <HorikawaOtane> Hello!
[06:22:51 CET] <HorikawaOtane> I am having a rather bizarre bug with the latest git ffmpeg - was wondering if this was a decent place to see if I'm either being an idiot or if it's a proper bug that I should file?
[06:24:02 CET] <HorikawaOtane> Specifically, I am compiling ffmpeg with --enable-cuvid and, when I use my binary with --hwaccel cuvid, I get the error "CUVID hwaccel requested, but impossible to achieve
[06:29:40 CET] <HorikawaOtane> (I am using a GTX 1060 and have compiled against the nvidia libraries)
[10:46:46 CET] <cone-401> ffmpeg 03Paul B Mahol 07master:8259f8a7207a: avcodec: add FM Screen Capture Codec decoder
[10:46:46 CET] <cone-401> ffmpeg 03Paul B Mahol 07master:8192e05cd24d: doc/general: mention Newtek SpeedHQ decoder
[13:29:47 CET] <cone-401> ffmpeg 03Paul B Mahol 07master:5979fb0b1ec3: avcodec/iff: support for byterun1 ACBM compression
[13:59:00 CET] <cone-401> ffmpeg 03Carl Eugen Hoyos 07master:79d232fc9f1f: lavf/mpegts: Make a pointer cast explicit.
[14:04:00 CET] <BtbN> HorikawaOtane, wrong channel. -> #ffmpeg
[14:04:31 CET] <BtbN> Also, that error means you configured a (filter) graph that is not compatible with hwaccelerated transcoding.
[14:53:33 CET] <wm4> atomnuker, Chloe: does AV_CODEC_CAP_SUBFRAMES even work with subtitles?
[14:55:13 CET] <JEEB> and then you'd have a language tag with each subframe?
[14:55:37 CET] <wm4> I guess that's the plan or something
[14:55:49 CET] <JEEB> (the broadcast stuff with multiple languages in a single dvb teletext | dvbsub track is "fun")
[14:56:02 CET] <wm4> if there were only 1 container with dvb subs support, I'd just say pretend by creating multiple AVStreams that duplicate the packets
[15:32:52 CET] <Chloe> I havent been able to check it yet, doing school work.
[16:49:57 CET] <iive> BtbN: any progress with the nvenc init problem?
[16:50:11 CET] <BtbN> No
[18:28:06 CET] <philipl> BtbN: You should cc the nvidia nvenc guy onto this one. Can't hurt.
[18:29:35 CET] <BtbN> Yeah, that's the next thing. I'm running out of ideas.
[18:31:14 CET] <philipl> You could do some nasty hacks to force nvenc initialisation early (hard code params, force _init() to be a singleton, etc)
[18:31:22 CET] <philipl> just to test if the ordering is important
[18:32:28 CET] <jkqxz> wm4:  The error on Voting_Machine.wmv happens because the muxing timebase is not the same as the output stream timebase, so the monotonisation fails because it happens in a finer timebase which then rescales back to the same value.
[18:32:46 CET] <jkqxz> I think that means you need to do the monotonisation on the output stream timebase for it to work?
[18:33:50 CET] <jkqxz> They seem to be meant to be the same, but lavf in ffmpeg overwrites it later once the stream has started.  (lavf in libav does not.)
[18:41:11 CET] <wm4> jkqxz: "once the stream has started"?
[18:41:21 CET] <wm4> I haven't looked at these failures at all yet
[18:43:00 CET] <jkqxz> elenril seems to agree that it is wrong and the rescale should be moved before the monotonisation.
[18:43:17 CET] <jkqxz> Not sure, I didn't pursue exactly when it happens.
[18:47:21 CET] <wm4> but yeah, I've been a bit confused about when the muxer can update the stream timebases
[18:56:25 CET] <BtbN> philipl, how would I do that? I'd basically have to revert the patches, and I already know it works then.
[18:58:04 CET] <philipl> BtbN: So something like, add a method (or call encoder init directly) up front and hack nvenc.c to return the same instance of nvenc context for all calls to init the encoder.
[18:58:21 CET] <philipl> So that when it's 'officially' initialised later, it's the same context you created up front
[19:11:47 CET] <jkqxz> The bogus_video.mp4 one seems to be some sort of filtering problem.  Nothing comes out of the audio filtergraph until you've pushed a lot of frames into it, hence the absence of an audio stream in the output file when you truncate the video.
[20:18:08 CET] <J_Darnley> What tools are available on linux to list all functions called/entered in a program (in this case ffmpeg)?
[20:18:26 CET] <J_Darnley> Is the term "call graph" what I should search for?
[20:26:48 CET] <jarkko> is there any good guide i could read how ffmpeg works?
[20:27:49 CET] <jarkko> i believe ffmpeg takes snapshots of video every 25seconds and uses that as base image or something like that. is there a way to configure how often this snapshot is taken
[20:28:04 CET] <jarkko> 25frames, not seconds
[20:28:11 CET] <jkqxz> J_Darnley:  gprof is the most standard one, I think.
[20:28:43 CET] <ubitux> jarkko: seems you're just refering to the default gop of the x264 encoder
[20:29:00 CET] <jarkko> i dont know the terms i am not familiar with how it works
[20:29:14 CET] <jarkko> gop stands for?
[20:29:25 CET] <J_Darnley> jkqxz: thanks, I'll start there
[20:29:37 CET] <J_Darnley> jarkko: Group Of Pictures
[20:29:53 CET] <jarkko> J_Darnley: makes sense
[20:30:21 CET] <jarkko> can you adjust the GOP when encoding?
[20:30:28 CET] <J_Darnley> 1) You want user help.  2) See the -g option.
[20:39:22 CET] <cone-040> ffmpeg 03Jan Ekström 07master:763e8237546a: movenc: add support for track names in ISML manifests
[20:40:14 CET] <jarkko> is there ways to improve the output of x265 or is all possible done now?
[20:49:40 CET] <jarkko> is there a logic how x265 picks keyframes?
[20:50:05 CET] <jarkko> shouldnt the all keyframes contain as much as content as possible
[20:50:29 CET] <JEEB> how exactly libx265 does its IRAP selection is up to itself, rather than FFmpeg
[20:51:00 CET] <JEEB> the libavcodec libx265 wrapper does let you set some parameters, but such decision things are up to libx265
[20:51:18 CET] <JEEB> thus your discussion would be more matching to #x265
[20:58:14 CET] <cone-040> ffmpeg 03Michael Niedermayer 07master:68b8be0811f8: doc/muxers: Fix typo, causing warnings during build
[21:15:30 CET] <jarkko> is it possible to use frames from begining of videoclip to the end? in term of compression or does it only use frames between keyframes
[21:16:37 CET] <rcombs> tmm1: https://lists.freedesktop.org/archives/gstreamer-commits/2014-July/080645.html
[21:17:40 CET] Action: wm4 mumbles something about apple quality
[21:18:25 CET] <rcombs> I have no argument; videotoolbox is bad
[21:18:30 CET] <JEEB> ^this
[21:18:33 CET] <rcombs> and fwiw audiotoolbox is also bad
[21:33:59 CET] <ubitux> speaking of this, they fixed the VT deadlock 
[21:34:12 CET] <ubitux> months after the report but they did it
[21:34:46 CET] <ubitux> (the thing that prevent from sending more than 3 frames in async and going into background)
[21:35:24 CET] <jarkko> this is stupid question but x265 has 8/10bit feature...do i benefit it from it somehow?
[21:47:18 CET] <tmm1> rcombs: i saw that, but none of the other decoders i've seen handle that case
[21:47:22 CET] <tmm1> which makes me think it's no longer an issue
[21:48:00 CET] <tmm1> rcombs: i did get things working on iOS with the equivalent of https://gist.github.com/tmm1/8177164dd929b96fc72702aed65cd71d
[21:48:00 CET] <rcombs> tmm1: saa
[21:48:10 CET] <rcombs> so I heard
[21:48:30 CET] <tmm1> rcombs: there's a deadlock/crash on seek/flush
[21:48:41 CET] <tmm1> but it seems pretty stable otherwise
[21:48:43 CET] <rcombs> oh, joy
[21:48:50 CET] <rcombs> inconsistent in whether it locks or crashes?
[21:49:00 CET] <tmm1> locks up on mac, crashes on ios
[21:49:08 CET] <rcombs> hah
[21:49:13 CET] <tmm1> looking at the VLC decoder, they seem to invalidate and recreate the session on flushes
[21:49:59 CET] <tmm1> i was also trying to figure out how to populate A53_CC sidedata in this decoder.. seems like none of the hw decoders do that at the moment
[21:50:19 CET] <tmm1> and would probably require finding the SEI NALU manually in the bitstream 
[21:51:16 CET] <rcombs> well we'll need some bitstream parsing anyway
[21:51:35 CET] <rcombs> seems like it'll probably be worth pulling some stuff out of the software decoder and into generic "h264 parse" code, if it's not already
[21:51:54 CET] <rcombs> worst part is I'll have to do this for MPEG1 and MPEG2 as well
[21:53:39 CET] <tmm1> ugh yea
[21:54:17 CET] <rcombs> before it can outright replace the hwaccels, anyway
[21:54:50 CET] <rcombs> there aren't any other decode APIs that just don't handle reordering at all, right?
[21:54:59 CET] <rcombs> (or, aren't guaranteed to, anyway)
[21:55:48 CET] <tmm1> not that i know of
[21:56:15 CET] <rcombs> if there were, I'd say there should be some sort of generic infrastructure for it
[21:56:49 CET] <rcombs> something between hwaccels (for low-level slice decoders that need a large portion of the software decoder) and outright decoders
[21:57:11 CET] <rcombs> probably would be internal, with the decoders exposed as regular decoders
[21:57:20 CET] <tmm1> yea that would make sense
[21:57:34 CET] <rcombs> just some more sharing between the software decoder and the VT one (and others that might need it)
[21:57:44 CET] <rcombs> but it sounds like there aren't any so I probably won't bother
[21:58:45 CET] <tmm1> if this flush/seek issue can be sorted out, i still think its worth committing this
[21:59:01 CET] <tmm1> probably as an experimental decoder, and with PATCHWELCOME if you try to use it with streams missing pts
[21:59:20 CET] <rcombs> maybe, as long as it doesn't break the existing hwaccel
[21:59:59 CET] <tmm1> given that 99% of other implementations also do PTS based reordering it seems like that's good enough for most
[22:00:14 CET] <tmm1> though now that the hwaccel works on ios, maybe it's simpler just to use that
[22:00:52 CET] <tmm1> i added the async flag to your decoder patch, need to compare how much faster that makes it compared to the sync hwaccel
[22:01:20 CET] <rcombs> probably will be faster if I refactor to use the send/receive API
[22:01:30 CET] <rcombs> or, potentially faster with a good consumer, anyway
[22:03:04 CET] <tmm1> is that a new hwaccel api?
[22:09:10 CET] <wm4> no, it just decouples input and output
[22:09:14 CET] <wm4> so data flow can be more flexible
[22:18:04 CET] <tmm1> ah like the lavf api
[22:18:23 CET] <tmm1> so in that case the hwaccel could use async?
[22:18:44 CET] <tmm1> but presumably would have the same reordering problem
[22:20:27 CET] <rcombs> yup
[22:23:12 CET] <tmm1> ok.. just trying to figure out which one i should spend time on improving
[22:25:12 CET] <tmm1> if theres no advantages to the decoder approach then ill just work on thr existing hwaccel
[22:29:46 CET] <wm4> hwaccel won't be able to do async, I think
[22:30:00 CET] <wm4> but that dude from a few years ago claimed async is critical for performance
[22:30:15 CET] <wm4> (but of course it could be that async could still be integrated into the hwaccel)
[22:32:23 CET] <tmm1> oh i thought the input/output api would allow for it
[22:39:45 CET] <cone-040> ffmpeg 03Josh de Kock 07master:2dafbae9940a: lavc/libzvbi: remove deprecated API usage
[22:51:29 CET] <durandal_1707> i wrote incomplete native ilbc decoder
[23:12:56 CET] <J_Darnley> I thought you said "libc decoder" for a moment.
[23:45:10 CET] <philipl> BtbN: did you try downgrading drivers? It might be driver specific, given Miroslave is not running latest drivers and didn't see the failure.
[23:45:30 CET] <BtbN> hm
[23:45:35 CET] <BtbN> Wonder which driver he is using?
[23:45:42 CET] <philipl> He said "latest stable"
[23:45:50 CET] <BtbN> that'd be 378
[23:45:59 CET] <philipl> On linux that's 375.26
[23:46:09 CET] <philipl> 378.09 is considered a beta release.
[23:46:20 CET] <BtbN> I'm primarily on Windows
[23:46:28 CET] <BtbN> Linux is on 375.26
[23:46:36 CET] <philipl> Oh well. Then that's not it.
[23:47:07 CET] <BtbN> hm, what's the earlierst supported driver right now?
[23:48:49 CET] <philipl> depnds on your hardware :-)
[23:48:55 CET] <nevcairiel> he tr ied hevc encode, did you give that a try?
[23:49:01 CET] <nevcairiel> i only tested with h264 here
[23:53:17 CET] <BtbN> I get the exact same error, no matter if I try h264 or hevc
[00:00:00 CET] --- Mon Feb 13 2017