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

[burek]

[00:45:01 CEST] <cone-733> ffmpeg 03Carl Eugen Hoyos 07master:6dbb64fdccaf: lavc/v4l2_m2m_enc: Add missing braces around initializers.
[00:45:52 CEST] <cone-733> ffmpeg 03Carl Eugen Hoyos 07master:cffbeda4621b: tests/ref/fate/pixelutils: Add a newline.
[02:54:12 CEST] <cone-733> ffmpeg 03Avi Halachmi (:avih) 07master:09e49a8fb082: configure: <fflib>_deps: validate, reduce sensitivity
[04:57:23 CEST] <Gregor> atomnuker: I've been poking at rnnoise, namely training some neural network models for it with input more suited to different uses than the canonical one's voip, and parameterizing it. Ultimately I wanted to package the result up and see if I could stuff it into ffmpeg (and maybe a LADSPA plugin for Audacity), but I see that you've at least partially beat me to the punch on that. Do you have some WIP code with rnnoise in ffmpeg?
[04:58:17 CEST] <atomnuker> nope, not at all, I used to have a few hundred lines but I gave up as it wasn't fun
[04:58:28 CEST] <Gregor> Hyuk
[04:58:40 CEST] <Gregor> Noted, thanks.
[04:58:57 CEST] <atomnuker> decoupling the opus bits (the dcts, functions to do measurements, etc.) was an issue
[04:59:23 CEST] <Gregor> Yeah, that's exactly what I imagined would be problematic, as they're all modified from their original source.
[05:00:38 CEST] <atomnuker> welp, if you do want to do the dirty bits shouldn't be too hard
[05:01:27 CEST] <atomnuker> just keep in mind the mdct15 that the code needs (same as opus) is currently private, and I'm working on moving all the audio transform stuff to lavf
[05:01:52 CEST] <Gregor> *nods*
[05:02:41 CEST] <atomnuker> so for now you can just append av_ for the mdct15 functions to get something working
[05:03:21 CEST] <atomnuker> (and I'll add it to my list I'm blocking yet-another piece of code relying on a lavu fft)
[05:04:11 CEST] <Gregor> OK.
[05:11:52 CEST] <cone-733> ffmpeg 03Jun Zhao 07master:3ad0e6724de8: lavc/pthread: use THREAD_SAFE_CALLBACKS() to simplifx more code
[05:14:45 CEST] <atomnuker> Gregor: btw keep in mind you should make it so models are externally loadable
[05:29:49 CEST] <Gregor> atomnuker: That was step one, I've already implemented that :)
[05:30:45 CEST] <Gregor> Meanwhile I'm building up an assortment of models for likely scenarios. The builtin model hates joy, by the way. It wasn't trained with laughter, and often interprets it as noise. A+.
[05:38:29 CEST] Action: Compn going to get a bunch of new format samples from dash cams , security dvr etc
[07:00:36 CEST] <rcombs> is there a reason why AVPacket.pos is before the preceding FEC bytes in MPEGTS, even though mpegts.c skips FEC per-packet _after_ the packet?
[07:00:42 CEST] <rcombs> seems to cause seeking errors
[07:01:35 CEST] <rcombs> you can end up seeking to several bytes before the packet's actual start, and then skipping the packet because resync can fail if the FEC/DVHS data has 0x47s
[07:04:41 CEST] <rcombs> particularly if reading from the incorrect offset results in afc=0
[07:08:41 CEST] <rcombs> (in this case it's actually BDAV timestamps, not DVHS data, but it's 4 bytes either way so it's treated the same)
[07:13:50 CEST] <rcombs> looks to have been added in 4c6b49bf74f
[07:14:02 CEST] <rcombs> not sure they thought through the implications much
[09:16:28 CEST] <nevcairiel> technically the BDAV timestamp is in front of the packet, so thats an accurate pos, even if slightly awkward
[09:29:49 CEST] <rcombs> nevcairiel: hmm, but if resync is gonna find the position after that, and read_packet() consumes the next packet's timestamp _after_ the current packet& ¯\_(Ä)_/¯ semantics
[09:30:19 CEST] <rcombs> like, for all other intents and purposes, lavf treats the extra bytes as being at the end
[09:32:25 CEST] <rcombs> but if we want the pos field to be technically-correct, we should fix resync to handle that
[09:32:35 CEST] <rcombs> and possibly handle_packet
[09:32:50 CEST] <nevcairiel> i'm somewhat sure some of my code wants it to be correct to match it with blu-ray playlist metadata
[09:32:54 CEST] <nevcairiel> so changing that would be bad
[09:33:02 CEST] <nevcairiel> when does that really happen? byte seeks?
[09:33:34 CEST] <rcombs> yeah, or seeks to index entries
[09:33:51 CEST] <rcombs> came up when looking at ffms2, but AVIndex seeks should also be affected
[09:34:33 CEST] <nevcairiel> heh i must've worked around that at some point and do byteseeks to pos+4
[09:35:24 CEST] <rcombs> lol
[09:35:24 CEST] <JEEB> :D
[09:35:30 CEST] <JEEB> gotta love these little things
[09:36:23 CEST] <nevcairiel> of course this is blu-ray reading only where i know its BDAV streams
[09:36:47 CEST] <nevcairiel> if you have general-purpose ts reading, that may be iffy
[09:37:02 CEST] <rcombs> is the same even true for FEC and DVHS?
[09:37:13 CEST] <rcombs> (i.e. that the additional data is at the start of the packet)
[09:37:14 CEST] <nevcairiel> that i dont know
[09:37:35 CEST] <rcombs> I'm really amused that there's no actual BDAV code in lavf
[09:37:45 CEST] <rcombs> it just happens to work with the DVHS code
[09:37:52 CEST] <rcombs> since the data's the same size
[09:38:35 CEST] <nevcairiel> i've always wondered if the timestamp is actually useful
[09:38:41 CEST] <nevcairiel> because i get by fine without using it
[09:38:47 CEST] <rcombs> how would a timestamp per MPEGTS packet be useful
[09:39:01 CEST] <nevcairiel> someone must've once though it might be
[09:39:08 CEST] <nevcairiel> or why would they have done this
[09:39:10 CEST] <rcombs> people think a lot of things
[09:39:22 CEST] <rcombs> nobody ever accused BD of efficiency
[09:40:54 CEST] <rcombs> 2% additional overhead for no reason at all sounds about right
[13:12:34 CEST] Action: durandal_1707 summons reviews
[13:47:46 CEST] <durandal_1707> looks like there is no need to merge libav hevc simd patches because ffmpeg hevc decoder is already faster than libav's
[13:53:04 CEST] <JEEB> it all depends on if those patches make ffhevc even faster or not
[13:53:39 CEST] <JEEB> so if it's just a case of E_NO_INTEREST they shouldn't be scratched from the todo
[13:55:28 CEST] <nevcairiel> some of the simd improvements look like an i mprovement, but their C interface is different to some degree, so its more like E_NOTTRIVIAL
[13:55:41 CEST] <durandal_1707> *look*
[13:56:59 CEST] <nevcairiel> you cant test them entirely without doing all  t he work
[13:57:04 CEST] <nevcairiel> feel free to proof it either way =p
[13:58:54 CEST] <durandal_1707> there is already hevc mc simd, so its like comparing apples and oranges
[13:59:30 CEST] <cone-314> ffmpeg 03Tobias Rapp 07master:56f68a099cc6: fate: add 10-bit test for hue video filter
[14:01:13 CEST] <JEEB> nevcairiel: yes, basically if it's not trivial and you don't care enough to check -> E_NO_INTEREST
[14:02:04 CEST] <kurosu___> Theirs might be better just because of code size. But they don't have avx2. On the other hand, h/w decoders are almost ubiquitous nowadays
[14:03:43 CEST] <JEEB> yes, that's one of the reasons for lack of interest
[14:04:26 CEST] <JEEB> + the lack of content where the SW decoding is required (since most official content is DRM'd to hell and thus hwdec only)
[14:04:33 CEST] <JEEB> and 'tube etc don't use HEVC of course
[14:05:22 CEST] <JEEB> also man, I hate cases where I don't have git send-email at hand
[14:05:45 CEST] <JEEB> did patchwork etc work with attachment patches?
[14:05:58 CEST] <kurosu___> And browsers, the first s/w decoder consumer (see ffvp9), want at best to use the platform decoder (ie none)
[14:06:27 CEST] <durandal_1707> JEEB: 99% no
[14:07:11 CEST] <JEEB> because I can bet if I send through gmail's web interface and ptu the patch in-line it will get messed up :D
[14:07:25 CEST] <nevcairiel> definitely
[14:08:13 CEST] <durandal_1707> what are you sending?
[14:08:51 CEST] <JEEB> sub2video improvements...
[14:09:16 CEST] <JEEB> (I actually wonder how much simpler this would be if the whole subtitle overlaying would be done in ffmpeg.c)
[14:09:37 CEST] <JEEB> the heartbeat stuff etc is kind of over-complicated
[14:09:54 CEST] <JEEB> or well, it gets even more complicated when your filter chain resets in the middle
[14:10:07 CEST] <JEEB> resets/re-inits/whatever
[14:10:28 CEST] <durandal_1707> i'm still waiting for new lavfi API description
[14:16:53 CEST] <JEEB> let's see how badly I failed with these two
[14:17:41 CEST] <JEEB> seems like hte "change topic" butan might have removed the in-reply-to
[14:59:13 CEST] <durandal_1707> is there dshow encoder like virtualdub2?
[15:25:55 CEST] <JEEB> durandal_1707: I think you have to use graphedit or graphstudio for that
[15:26:03 CEST] <JEEB> to make the DShow graph
[15:44:27 CEST] <nevcairiel> dshow never really got used for encoding
[15:50:29 CEST] <JEEB> yea, everything that did that more or less did it in some custom way and the only muxer I remember in DShow was gabest's
[15:50:32 CEST] <JEEB> no, no, haali's
[15:50:40 CEST] <JEEB> haali's some filter had a Matroska muxer
[15:59:12 CEST] <durandal_1707> i need simple application which will use dshow encoder
[16:01:20 CEST] <JEEB> graphstudio is your best bet
[16:01:28 CEST] <JEEB> unless you code a dshow app yourself for a specific thing
[16:02:42 CEST] <durandal_1707> how i can convert avi file from one codec to another with graphstudio?
[16:05:53 CEST] <JEEB> load avisource, it will then make you a filter chain for playback
[16:06:03 CEST] <JEEB> you remove the renderer and add an encoder filter and muxer
[16:06:04 CEST] <JEEB> done
[16:12:26 CEST] <JEEB> or actually you don't need to load the source manually, I think they have a "generate filter chain from file"
[16:12:40 CEST] <JEEB> which will source->renderer
[16:12:53 CEST] <JEEB> then you just start replacing filters at the end of the chain
[16:18:19 CEST] <durandal_1707> JEEB: how to load avisource? do i need to install something? using GraphStudioNext
[16:18:26 CEST] <JEEB> no
[16:18:34 CEST] <JEEB> just pick the "render file" thing
[16:18:37 CEST] <JEEB> it should auto-load it
[16:21:35 CEST] <durandal_1707> i dont have avi muxer/compressor
[16:22:20 CEST] <JEEB> well if you don't have any encoders...?
[16:22:38 CEST] <durandal_1707> i have, recodec.ax
[16:22:51 CEST] <durandal_1707> just missing muxer
[16:22:55 CEST] <JEEB> that sounds like vfw?
[16:22:58 CEST] <JEEB> are you sure it's not vfw
[16:23:11 CEST] <durandal_1707> it is dshow, have guid in regedit
[16:23:16 CEST] <JEEB> ok
[16:23:25 CEST] <JEEB> then google for haali's muxer
[16:23:33 CEST] <JEEB> it should take in pretty much everything in vfw mode
[16:32:21 CEST] <durandal_1707> JEEB: it works!!! Thanks!
[16:32:40 CEST] <durandal_1707> except it saved in mkv and not in avi
[16:35:03 CEST] <JEEB> durandal_1707: yea, but that IMHO shouldnt be a problem
[16:35:15 CEST] <JEEB> I mean, you should get the VFW 4CC in the codec id
[16:35:24 CEST] <JEEB> and then the packets just contain the AVI data
[16:37:02 CEST] <durandal_1707> except data is raw
[16:37:15 CEST] <durandal_1707> for some reason..
[16:37:35 CEST] <JEEB> something not connected right?
[16:37:59 CEST] <JEEB> did you add the encoder filter in the chain?
[16:45:28 CEST] <durandal_1707> http://0x0.st/stW1.png
[16:46:39 CEST] <JEEB> I'll take a look after I get home
[16:46:43 CEST] <JEEB> still filling hours @ wor
[16:46:46 CEST] <JEEB> *work
[17:21:27 CEST] <durandal_1707> apparently this racodec.ax aka RemotelyAnywhere, from LogMeIn is also using zlib - are you suprised?
[17:22:23 CEST] <jya> what's the proper use of a parser (and its corresponding AVCodecParserContext) when it comes to draining? are you to feed the parser will null data like you would with the decoder ? or can the parser be ignored?
[17:23:08 CEST] <jya> BBB: seems that the vp9 parser no longer returns immediately if fed a size of 0 , was changed (not so recently)
[17:23:45 CEST] <BBB> I think you ignore the parser
[17:23:59 CEST] <BBB> the parser is supposed to be drained (as far as possible) for each input packet
[17:24:03 CEST] <BBB> and then draining is a decoder-only thing
[17:24:07 CEST] <jya> for all codecs?
[17:24:14 CEST] <BBB> since decoders are pipelined, and parsers are not
[17:24:24 CEST] <BBB> (frame-mt, delayed/b frames, etc.)
[17:24:25 CEST] <jya> okay.. will change that, will make me feel more comfortable with that dangling pointer returned
[17:24:27 CEST] <BBB> yes
[17:26:18 CEST] <nevcairiel> i actually call the parser function with a NULL pointer, not sure if that ever returns anything though, i should maybe test some day
[17:30:42 CEST] <jya> nevcairiel: it's not called with a null pointer, but a null size, in which case the pointer passed is no longer used:
[17:30:42 CEST] <jya> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/parser.c#L143
[17:31:05 CEST] <jya> meaning you potentially return a pointer to dummy_buf
[17:32:06 CEST] <jya> after that *poutbuf  == dummy_buf
[17:32:46 CEST] <nevcairiel> if the size is also 0, that doesnt matter
[17:32:58 CEST] <nevcairiel> but it may otherwise also still theoretically flush real data out
[17:35:03 CEST] <nevcairiel> because ff_combine_frame handles a 0-sized buffer to flush all remaining data out
[17:35:48 CEST] <jya> nevcairiel: how confident are you that the pointer returned is a dangling one so long that the size is 0? no read is ever done? after all the code has comment about buffer needing padding even if size == 0
[17:36:05 CEST] <nevcairiel> thats for the parsers themself
[17:36:08 CEST] <nevcairiel> not the api user
[17:36:38 CEST] <nevcairiel> because the parsers may try to find a mpeg startcode or something like that
[17:36:57 CEST] <jya> ok... in any case, if the parser could theorically contain data to be drained, then using a point to a local stack variable can't work... so it's just for being on a safer side
[17:37:11 CEST] <jya> s/point/pointer
[17:47:26 CEST] <cone-144> ffmpeg 03Paul B Mahol 07master:aeb73c73e112: avcodec/dnxhdenc: stop leaking memory when initalization fails
[19:00:47 CEST] <durandal_1707> vfw is documented on wiki.multimedia.cx, but directshow isn't
[20:24:13 CEST] <durandal_1707> 21
[21:13:00 CEST] <durandal_1707> JEEB: if you are on windows, you can try to create file with real avi muxer, otherwise do not bother
[21:13:44 CEST] <JEEB> yea I wasn't sure how things would work on wine :P
[22:40:12 CEST] <durandal_1707> JEEB: it doesn't, i tried to encode something with different codecs, and it just crash
[22:40:33 CEST] <JEEB> rip
[22:40:38 CEST] <JEEB> but not surprising
[22:41:03 CEST] <JEEB> durandal_1707: you can try https://developer.microsoft.com/en-us/windows/downloads/virtual-machines
[22:41:27 CEST] <JEEB> I think there were more minimal ones too
[22:41:48 CEST] <JEEB> these https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
[22:42:07 CEST] <JEEB> has win7 etc
[22:42:26 CEST] <durandal_1707> 20GB, are you serious?
[22:42:40 CEST] <JEEB> that's the development one
[22:42:49 CEST] <JEEB> as I noted the web checking VMs are smaller
[22:43:04 CEST] <JEEB> I mean they will be full on VMs, but I don't think you're going to get much further with wine :P
[22:44:28 CEST] <durandal_1707> i have 4GB of RAM, so i can not use it anyway, win 10 needs 4GB min
[22:44:58 CEST] <durandal_1707> is directshow in XP?
[22:46:16 CEST] <JEEB> yes
[22:46:29 CEST] <JEEB> I mean, DShow is old
[22:46:32 CEST] <JEEB> from like 95 or so
[22:47:07 CEST] <JEEB> > ActiveMovie was announced in March 1996, and released in May 1996, bundled with the beta version of Internet Explorer 3.0.
[22:47:33 CEST] <JEEB> and became a full-on OS component in win98 it seems
[22:49:26 CEST] <nevcairiel> Vista already introduced MediaFoundation, which was supposed to replace it, but t hat never really happened
[22:49:50 CEST] <nevcairiel> DShow became a standard OS component in Windows 98
[22:51:33 CEST] <JEEB> yup
[22:51:40 CEST] <JEEB> and yea, MF was supposed to take the mantle
[22:51:44 CEST] <JEEB> but then sw usage didn't happen
[22:51:56 CEST] <JEEB> except with apps that bundled most of their stuff that they needed
[22:53:30 CEST] <nevcairiel> MFs api is pretty ok even, but it had the chicken-egg problem, no apps used it, and thus no filters were made
[22:53:47 CEST] <JEEB> yup
[22:54:11 CEST] <nevcairiel> .. and then no apps used it because no filters exited =p
[22:56:11 CEST] <gnafu> JEEB: Ooh!  I'm going to have fun with those.
[22:56:23 CEST] <gnafu> (Well, "fun".  Just interesting to try it out.)
[00:00:00 CEST] --- Sat Sep  1 2018