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

[burek]

[00:24:08 CET] <cone-664> ffmpeg 03Andreas Rheinhardt 07master:e895b800fe27: cbs_h2645: Avoid memcpy when splitting fragment
[05:46:36 CET] <sinclair> hi, im looking for information on piping video frames (encoded as png's) into FFMPEG, and having the resulting video piped to out.
[05:47:28 CET] <sinclair> I have a fixed (known) number of frames, and what im sorta not sure about is having ffmpeg signal its finished encoding after processing the last frame.
[05:47:51 CET] <sinclair> also, not sure about delimiting frames as they are piped into ffmpeg.
[05:48:13 CET] <sinclair> is anyone able to provide assistance here?
[05:58:41 CET] <jamrial> sinclair: see https://trac.ffmpeg.org/wiki/Slideshow
[05:58:52 CET] <jamrial> also, this is a question for #ffmpeg, not this channel
[05:59:12 CET] <sinclair> jamrial: i can't seem to talk in ffmpeg
[05:59:52 CET] <sinclair> jamrial: but thanks for the link, is slideshow really the thing i need to use, each PNG is 1 frame in a 24fps video
[06:10:19 CET] <sinclair> so yeah, it looks like slideshow is probably what i want, but is it possible to stream images in over STDIN?
[06:22:17 CET] <Compn> ffmpeg might try to read it as individual files not a stream/video
[08:43:02 CET] <j-b> morning
[09:01:56 CET] <BradleyS> o/
[09:46:08 CET] <cone-045> ffmpeg 03Andrey Semashev 07master:fa08345e882c: lavf/dashenc: Fix segment duration overflow on fine time bases.
[10:01:41 CET] <LigH> Hi.
[10:02:40 CET] <LigH> Compiling ffmpeg in MSYS2/MinGW fails for configuring tesseract with undefined references to ZSTD_ symbols.
[10:04:31 CET] <LigH> in libtiff.a
[10:08:22 CET] <durandal_1707> we do no use libtiff
[10:09:33 CET] <LigH> tesseract may?
[10:09:51 CET] <LigH> But on its own, tesseract compiles.
[10:11:12 CET] <LigH> I'll remove existing tesseract libraries and package conf files, force a recompile...
[10:20:47 CET] <Gag_H> DC?
[10:23:24 CET] <LigH> Nope.
[10:23:36 CET] <LigH> Forced recompiling of tesseract: passes.
[10:23:51 CET] <LigH> Configuring ffmpeg incl. libtesseract: Fails.
[10:25:07 CET] <LigH> Brief head and tail of config.log: https://pastebin.com/HMEgbU3y (exceeds 512 KB, max. size of pastebin)
[10:25:31 CET] <LigH> I could offer a ZIP archive of several log files...
[10:26:55 CET] <durandal_1707> could you compile tesseract without tiff support?
[10:30:55 CET] <LigH> I don't know how that may impact the compilation of everything else in media-autobuild_suite. So I will propose that in this project, to give their maintainers a chance to inspect it.
[10:31:49 CET] <LigH> OK, I see it has been reported already.
[10:31:52 CET] <LigH> https://github.com/jb-alvarado/media-autobuild_suite/issues/981
[10:31:58 CET] <LigH> So I guess it will be fixed.
[10:32:09 CET] <LigH> Thanks, bye for now.
[10:51:01 CET] <LigH> durandal_1707, success: --extra-libs=-lzstd
[11:56:26 CET] <thardin> is there some reliable way to count the number of samples in a stream in a muxer? st->duration doesn't seem to come out right
[11:56:43 CET] <thardin> or, number of frames I guess
[11:56:57 CET] <nevcairiel> before muxing, or afterwards?
[11:57:20 CET] <nevcairiel> duration is of course timestamp-bound, so gaps would offset it
[11:59:00 CET] <thardin> hum
[12:03:49 CET] <thardin> ah I need to convert between sample_rate and st->time_base
[12:06:07 CET] <thardin> avpriv_set_pts_info() to the rescue
[12:12:05 CET] <thardin> is there a flag for saying "extradata will take a little while, don't write headers immediately" from encoder to muxer?
[12:12:39 CET] <nevcairiel> no, thats not really a generic feature we can do
[12:12:45 CET] <thardin> I see side data at least
[12:13:05 CET] <nevcairiel> its very specific to some codecs and muxers
[12:16:22 CET] <thardin> I guess I'll signal AV_PKT_DATA_NEW_EXTRADATA and just always rewrite extradata on the end in the muxer
[12:25:04 CET] <thardin> it seems the extract_extradata bsf is related
[12:29:16 CET] <nevcairiel> thats for demuxing
[12:29:27 CET] <nevcairiel> to get extradata from a stream without global headers
[12:30:08 CET] <thardin> actually, libavcodec/pngenc.c uses this
[12:30:49 CET] <nevcairiel> oh i meant the bsf
[12:32:02 CET] <thardin> right
[12:32:44 CET] <thardin> ok, so that side data gets picked up in apngenc.c and is not automagically put into codecpar as part of the parameter probing shenanigans
[12:33:07 CET] <thardin> not so strange for apng since it is only available on the end. oh well
[12:42:58 CET] <thardin> it werks
[15:52:06 CET] <Holter> Hi
[15:53:45 CET] <Holter> I think I found a small bug in mpegtsenc.c. 
[16:02:01 CET] <Holter> Changing the type will fix it.
[16:02:34 CET] <Holter> Can anybody fix it?
[16:06:19 CET] <jamrial> Holter: send a patch to the mailing list with the fix, or open a ticket on https://trac.ffmpeg.org/ with details about the bug
[16:07:32 CET] <Holter> ok, thanks. 
[16:46:32 CET] <thardin> is it possible to tell whether a stream's duration is an estimate or not?
[16:50:51 CET] <thardin> it's kind of crappy that it doesn't get filled in correctly when transcodinge
[17:02:22 CET] <atomnuker> BBB: videolan's shitlab instance logged me out after 3 hours
[17:03:07 CET] <atomnuker> and I stopped charging my phone after I found out it would stop beeping at every piece of mail I got if it had no battery
[17:07:27 CET] <atomnuker> also could you voice some sanity regarding what unlord's suggesting
[17:07:48 CET] <atomnuker> he's adding back the hell that msac.c used to be with the anti-optimization which was LOTS_OF_BITS
[17:08:05 CET] <atomnuker> and snake oil placebo tier likely/unlikely optimizations
[17:15:47 CET] <BBB> ...
[17:16:48 CET] <BBB> look, for each of these optimizations, I think we can look at them individually if you want to go that way
[17:17:00 CET] <BBB> the way I look at it is that if it gets faster, I'm ok
[17:17:14 CET] <BBB> don't say shitlab, just tune your preferences to not send you email
[17:17:56 CET] <atomnuker> yeah but I can't disable dual factor
[17:17:58 CET] <BBB> and if you think some optimization is not right ("snake oil"), let's measure the improvement of it in isolation
[17:20:54 CET] <jamrial> BBB: clean, maintainable no spaghetti ifdeffed code should be a priority as well
[17:21:01 CET] <jamrial> speed is great, but when you focus too much on it and let it go wild you end up with swscale and swresample :p
[17:21:23 CET] <BBB> fair enough
[18:28:48 CET] <BtbN> philipl, I just had a really messy idea that I'm not sure I'd want merged. A hidden flag somewhere on CUDA frames that contain nvdec mapped surfaces that have been deinterlaced. And then a filter that separates them into two (still mapped) frames.
[19:17:32 CET] <philipl> BtbN: so two deinterlaced frames carried by one avframe?
[19:17:51 CET] <philipl> and then the filter splits them.
[19:18:35 CET] <philipl> That doesn't seem terrible to me, especially if the frame still works for ignorant filters or outputs. You'd get half rate without the extra filter.
[19:19:08 CET] <BtbN> Yeah, something like that. Just can't come up with a clean idea to have both frames in one in a somewhat clean way.
[19:19:43 CET] <BtbN> It crosses library boundaries, so can't use our private storage space.
[19:20:11 CET] <philipl> Well, storing both frames can be fudged. for semi-planar you can use plane 2 and 3 directly.
[19:20:22 CET] <philipl> and any real world content will be semi-planar
[19:20:41 CET] <philipl> Then it's a question of where the flag goes.
[19:21:45 CET] <philipl> I wonder if the cuvid deinterlacer even works for 444 interlaced content.
[19:21:51 CET] <philipl> i never bothered trying.
[19:22:10 CET] <philipl> if it doesn't, then it's moot
[19:22:57 CET] <philipl> we'd need something uglier for that.
[19:24:25 CET] <philipl> You'd have to put the fuller buffer in plane 3 and then rely on the fact that the first frame's layout is the same and recover how to split the second frame's planes.
[19:24:40 CET] <philipl> s/fuller/full second/
[19:29:16 CET] <BtbN> I'm not even sure if both planes can be mapped at the same time.
[19:30:37 CET] <BtbN> Well, they probably can
[19:30:42 CET] <BtbN> would be pretty useless otherwise
[19:37:16 CET] <philipl> speak of the devil...
[19:38:19 CET] <nevcairiel> decoder and encoder sharing a surface pool is always a bit iffy
[19:38:25 CET] <nevcairiel> at least if your pool has to be fixed size
[19:47:04 CET] <philipl> BtbN implemented a special pool that directly uses nvdec mapped planes but that has to be fixed. We put offer a filter that just copies frames using a dynamic pool to remove the restriction.
[19:47:53 CET] <philipl> This would give you equivalent functionality to what we saw before he added the mapped frame pool
[19:49:11 CET] <BtbN> The b frame depth should be known beforehand, so the pool size should (and I think already is?) adjusted accordingly.
[19:50:18 CET] <BtbN> I don't see how being interlaced makes a difference there really
[19:50:36 CET] <BtbN> unless it's paff vs. mbaff stuff.
[19:53:15 CET] <philipl> could be that
[20:20:27 CET] <orbea> Hi, not sure if anyone recalls, but little over a week ago I asked about a crash with alephone and ffmpeg. The alephone developer had time to follow through on the advice given here and now its fixed, thanks. :) https://github.com/Aleph-One-Marathon/alephone/issues/121
[20:25:24 CET] <philipl> BtbN: malakudi is the guy from devtalk with all the problems.
[20:27:55 CET] <BtbN> Well, he's probably not wrong. Just using very unusual and untested combinations of stuff.
[20:28:15 CET] <JEEB> 732
[21:32:57 CET] <BtbN> Bugreports ending in "Fix this bug!" are surely motivation to invest time into the issue.
[21:33:07 CET] <nevcairiel> yeah as a baseline i ignore those
[21:34:10 CET] <BtbN> Well, they all seem like legitimate issue, but the perceived level of entitlement is through the roof.
[21:34:49 CET] <durandal_1707> gonna push truehd_core_bsf soon!
[21:39:20 CET] <jamrial> BtbN: eh, "Please, fix this bug!" is not a demand
[21:39:30 CET] <nevcairiel> ! makes it a demand
[21:39:34 CET] <nevcairiel> in my book
[21:44:55 CET] <durandal_1707> kickban bug creator for life, he spammer
[22:05:18 CET] <cone-065> ffmpeg 03Paul B Mahol 07master:0279cb4f6985: avcodec: add truehd_core bitstream filter
[22:26:42 CET] <BtbN> I'm confused about this hwdownload scale issue. Somehow I doubt his conclusion that hwdownload is at fault is correct.
[00:00:00 CET] --- Sat Nov 24 2018