Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2019

1 participants
62 discussions

ffmpeg-devel.log.20190315
by burek 16 Mar '19

16 Mar '19

[01:11:51 CET] <cone-544> ffmpeg 03Carl Eugen Hoyos 07master:dbecf03f692a: lavc/qtrle: Do not use aligned writes for 24bit frames. [01:17:25 CET] <uau> cehoyos's patch doesn't look complete [01:18:07 CET] <uau> in the 64-bit case, while the loop itself advances by 8, it doesn't look like the pointer would be kept 8-aligned overall [01:18:15 CET] <nevcairiel> that code is old [01:18:24 CET] <nevcairiel> only the 24bpp case was changed recently [01:19:59 CET] <nevcairiel> unless i missed a commit [01:20:01 CET] <uau> nevcairiel: nope, AV_WN64A was introduced by 3278ea67c8f2a7c1aea8fd3114b35983791e6732 (part of recent changes) [01:41:49 CET] <cone-544> ffmpeg 03Carl Eugen Hoyos 07master:def18ac43bb9: tests/fate/ffmpeg: Check for apng codec for fate-copy-apng. [04:16:42 CET] <vel0city> Is anyone working on the DNG GSoC project idea? [04:18:07 CET] <vel0city> Noone has expressed interest for it? [07:17:48 CET] <vel0city> DNG is an extension of the TIFF 6.0 format [07:17:55 CET] <vel0city> should its implementation reside in tiff.c? [08:27:20 CET] <JEEB> vel0city: if it makes sense. if it is sharing most of the structure etc then it mighr make sense as a separate input format like mp4/mov/etc are in mov(enc) [08:27:47 CET] <JEEB> if it's only some basic structures then sharing some parsing functions only makes sense [08:32:35 CET] <vel0city> JEEB: Right, just looked at mov(enc) and that's pretty much what I was thinking would be best. Because they do share most of the structure. [08:32:57 CET] <JEEB> alright [08:35:52 CET] <vel0city> JEEB: Could it be a combination of the two approaches? Use tiff.c but implement DNG specific stuff in dng.c [08:37:03 CET] <vel0city> Assuming that it's worth it (ie. there would be a lot of DNG code) [08:37:08 CET] <JEEB> yea [12:04:45 CET] <vel0city> I'm looking at an image file format that has 5 8-bit components per pixel [12:05:06 CET] <vel0city> it's CMYK + A which I'm assuming is not even used [12:05:30 CET] <vel0city> how would I map that to an pixfmt? [12:05:40 CET] <vel0city> the only 40bpp formats I can find are planar, which this isn't [12:06:20 CET] <vel0city> CC durandal_1707 [12:08:03 CET] <vel0city> would I have to process it myself? [12:09:50 CET] <thardin> something tells me you need color information to go along with it [12:10:01 CET] <nevcairiel> we don't have any CMYK formats at all, so the easier option would be to convert it to RGBA, or the more complex alternative would be adding CMYK formats as needed [12:10:40 CET] <thardin> conversion to RGB is lossy tho [12:10:51 CET] <nevcairiel> i believe some tiff decoding already does cmyk to rgb [12:12:01 CET] <vel0city> nevcairial: Not TIFF, but PSD does [12:12:26 CET] <vel0city> *nevcairiel [12:12:45 CET] <nevcairiel> tiff as well as far as i can tell [12:12:51 CET] <vel0city> where? [12:12:57 CET] <nevcairiel> look for the TIFF_PHOTOMETRIC_SEPARATED case [12:13:28 CET] <vel0city> ah right [12:13:58 CET] <vel0city> that wasn't really my problem though [12:14:12 CET] <vel0city> first I gotta map it to a pixfmt [12:14:23 CET] <vel0city> or figure out how to do it without pixfmt [12:16:22 CET] <vel0city> oh, I just read the code around the SEPARATED case [12:18:08 CET] <vel0city> yeah that doesn't look too hard, thanks [14:44:56 CET] <lemourin> why can't anyone comment on my one line patch: https://patchwork.ffmpeg.org/patch/12153/ ? i've been waiting for 3 weeks and pinged it twice already.. [14:48:35 CET] <durandal_1707> lemourin: just ping it more, every day [14:49:32 CET] <lemourin> ehh, i didn't want to be called out on being too annoying [14:51:17 CET] <durandal_1707> lemourin: you are ok until Nicolas complain [15:05:32 CET] <thardin> that m264 guy is still trying to do dlopen() [15:05:46 CET] <BBB> that m264 guy still trying to link to closed source software [15:05:52 CET] <thardin> yes [15:06:06 CET] <BBB> why did we reject realvideo wrappers but are we intending to accept matrox264 wrappers [15:06:18 CET] <BBB> should I submit a request for a foundation vote? [15:06:23 CET] <thardin> did the realvideo wrappers also use dlopen() [15:06:40 CET] <thardin> ? [15:06:52 CET] <BBB> ctx->lib_handle = dlopen(LIBRV11DEC_FILE, RTLD_LAZY); [15:06:55 CET] <BBB> https://ffmpeg-devel.ffmpeg.narkive.com/Ok5y3HXO/patch-0-3-codec-wrapper-fo… [15:06:58 CET] <BBB> looks like it, yes [15:07:23 CET] <BBB> I think it's so that people can download binaries with rv support [15:07:27 CET] <BBB> but without rv binaries [15:07:35 CET] <BBB> and then they can add rv support by simply installing the dll [15:07:40 CET] <durandal_1707> ladspa and frei0r use dlopen [15:07:40 CET] <BBB> without needing a new build of ffmpeg [15:07:56 CET] <nevcairiel> those are plugin frameworks, isnt that used to load plugins? [15:08:00 CET] <durandal_1707> yes [15:08:05 CET] <nevcairiel> well different thing =p [15:08:18 CET] <thardin> those also aren't for circumventing the (l)gpl [15:08:32 CET] <thardin> though they may have that effect indirectly [15:08:33 CET] <BBB> I don't think it's circumventing, it's just ignoring entirely [15:08:48 CET] <BBB> "we don't care about your license, we just want to make money" [15:09:17 CET] <thardin> "donate $100¬ to fffoundation and me might consider it" [15:09:25 CET] <thardin> err 100k¬ [15:09:39 CET] <BBB> lol [15:10:01 CET] <nevcairiel> i'm sure some companies might even consider that [15:10:14 CET] <BBB> anyway, I'm thinking we should set a project policy on linking to closed-source software [15:10:15 CET] <durandal_1707> yes, then we can make FFDD [15:10:26 CET] <BBB> and this "it's hardware GPU drivers!" thing should also be tightened if you ask me [15:10:32 CET] <thardin> BBB: aren't there lots of hardware encoders already? [15:10:32 CET] <BBB> not everything is a "system library" [15:10:42 CET] <thardin> or do those go via some kernel thing maybe? [15:10:53 CET] <BBB> I honestly think we're starting to have too many [15:10:58 CET] <BBB> qsvmpeg [15:11:03 CET] <BBB> instead of ffmpeg [15:11:11 CET] <BBB> can you still use ffmpeg without intel qsv hardware? [15:11:19 CET] <BBB> or is that similar to using ffmpeg without simd optimizations? [15:11:21 CET] <BBB> ;) [15:11:33 CET] <thardin> I mean, they could just push yuv4mpeg or whatever it's called instead of hooking crap into libav* [15:11:56 CET] <BBB> the part where certain filters require qsv or cnn annoys me a bit [15:12:11 CET] <BBB> maybe I'm just old-fashioned [15:12:16 CET] <BBB> or just old [15:12:19 CET] <thardin> piping raw video streams around is a perfectly workable solution and incurs no maintainer effort for ffmpeg's part [15:12:45 CET] <BBB> right, so why don't they do that? why all this effort to integrate into ffmpeg? I don't get it, other than us now carrying the maintenance burden [15:12:58 CET] <nevcairiel> qsv decoding and the qsv filters should really just be canned, since platform-driven decoding like dxva or vaapi is generally better and more maintained, and the qsv encoder can afaik accept surface data from vaapi or dxva [15:13:06 CET] <nevcairiel> but some people hang on to those for reasons [15:13:48 CET] <thardin> BBB: probably the latter part. also network effect [15:14:12 CET] <nevcairiel> it makes it sound nice to be able to say that ffmpeg supports it [15:14:17 CET] <thardin> it effectively turns ffmpeg into an advertising vehicle for a set of vendors [15:17:08 CET] <durandal_1707> for free? [15:18:44 CET] <iive> what is matrox264 doing? decoding or encoding? [15:19:23 CET] <iive> last time i heard of matrox, they were rebranding radeon cards... so are they really using their own hardware? [15:24:16 CET] <nevcairiel> its apparently some enterprise-y stuff [15:25:40 CET] <nevcairiel> 422 encoding only, presumably 10-bit [15:26:05 CET] <nevcairiel> https://www.matrox.com/video/en/products/developer/hardware/m264/ [15:32:47 CET] <BBB> I believe it's primarily encoding, but it appears there was a decoder wrapper in the patch also [15:35:29 CET] <JEEB> anyways, we'd need clear-cut rules for what's kosher and what's not and unfortunately that's going to be hard :/ [15:35:55 CET] <BBB> not doing anything is worse [15:35:59 CET] <JEEB> yes [15:36:07 CET] <BBB> I understand if people are fine with closed-source, and then I'll take the result and shut up [15:36:08 CET] <JEEB> since we already got nonfree-and-not-open-source things in there [15:36:17 CET] <JEEB> which is IMHO bad [15:36:20 CET] <BBB> the reason I keep bringing this up is because it is my impression many of us *don't* like this [15:36:22 CET] <BBB> yes [15:36:32 CET] <JEEB> I think nonfree originally was for just incompatible *OSS* licenses [15:36:45 CET] <JEEB> not "get yer free proprietary module in here!" [15:37:43 CET] <JEEB> but I'd have to check the history of the repo for that a bit more [15:37:43 CET] <JEEB> :P [15:42:42 CET] <BBB> I think you're right [15:42:52 CET] <BBB> "nonfree" was for things like the weird licensed aac encoders [15:42:54 CET] <BBB> but they were opensource [15:42:57 CET] <JEEB> yup [15:43:04 CET] <BBB> and then it became for non-compatible but free licenses [15:43:20 CET] <BBB> there were some opensource licenses incompatible with gpl [15:43:32 CET] <BBB> so --enable-gpl + these encoders became nonfree = nondistributable [15:43:40 CET] <BBB> but it was never intended for closed source software [15:43:50 CET] <BBB> nowadays we don't even bother with nonfree anymore [15:43:54 CET] <BBB> we just dlopen it and it's ok??? [15:43:59 CET] <BBB> crazy [15:44:45 CET] <nevcairiel> we dont even have that many things in the nonfree list, there is 2 openssl things, 1 of those aac decoders, and only 2 actual proprietary things, one of those is a hardware interface, and one is pure s oftware afaik [15:45:08 CET] <nevcairiel> and that software thing was being discussed recently anyway (ndi shit) [15:45:58 CET] <JEEB> but yea, there's the question of what we're considering OK. for actual OS provided interfaces the answer is simple (f.ex. dxva2/d3d11va), but then you get the stuff where the interfaces are provided by the driver, not the OS [15:46:15 CET] <JEEB> to which point is that OK and to which point is it not? [15:46:19 CET] <JEEB> (Ž4@) [15:46:21 CET] <nevcairiel> if you to to linux, what is "the OS" anyway? [15:46:25 CET] <nevcairiel> go to* [15:46:45 CET] <JEEB> yea, that was what I limited my sentence first, but then remembered that nvidia provides interfaces on windows as well P [15:46:48 CET] <JEEB> :P [15:49:07 CET] <JEEB> and if we're OK with driver provided interfaces then how do we decide what to go with and what to not go with? is it enough if we stick against interfaces that will dload stuff in the background or? [15:49:11 CET] <JEEB> :psyduck: [15:51:55 CET] <nevcairiel> the problem is that there is technically no difference between an nvidia encoder and a matrox encoder, both use some .so to talk to a driver to facilitate some hardware encoder doing things, except one is actually useful to thousands if not millions of people, and one is a "pro" device for corporate use [15:52:13 CET] <JEEB> yes [15:52:44 CET] <JEEB> the nvidia layer just IIRC puts the dload stuff behind an nvidia interface, and here they put it in the patch [15:52:50 CET] <JEEB> > nvenc_dload_funcs [15:53:47 CET] <nevcairiel> thats even a header-only implementation that it pulls in, not a library it links to [15:56:46 CET] <iive> the matrox thing is not even video card. it's just pcie card. [15:56:56 CET] <nevcairiel> well, hardware is hardware [15:57:20 CET] <iive> is that a problem for vaapi or vdpau? [15:57:32 CET] <iive> how hard is to write a wrapper for them? [15:57:44 CET] <iive> same for the nvidia encoder? [15:58:01 CET] <nevcairiel> vdpau doesnt have any encoding, and vaapi encoding is .... very low level [15:58:28 CET] <atomnuker> yeah, they wouldn't expose such low level stuff [15:58:56 CET] <nevcairiel> i'm really not sure what someone thought when they designed the vaapi encoding api [15:59:10 CET] <nevcairiel> it seems like a direct driver interface with the high-level api library missing [15:59:10 CET] <durandal_1707> does anybody know how to RE codec using only entropy data from video frames? [15:59:31 CET] <iive> then it is up to us to create a new api for hardware encoding [15:59:36 CET] <atomnuker> its pro hardware, so the people who use it would still need to force the decoder and presumably won't use anything else, so I don't see the problem with not including m264 and letting users implement it themselves [15:59:47 CET] <iive> and to movie the vendor stuff into it. [16:00:56 CET] <iive> the library implementing it should probably be some mit/bsd/llvm style license [16:01:03 CET] <iive> and it will by a system library. [16:01:26 CET] <atomnuker> libyami :) [16:01:34 CET] <JEEB> :D [16:01:37 CET] <JEEB> libdarkness [16:02:49 CET] <iive> btw, does v4l2 also get into the codec business? [16:02:55 CET] <nevcairiel> the problem is that such a project would be a swamp of annoyance, because all the hardware interfaces are so different [16:03:41 CET] <nevcairiel> v4l2 has some decoding interfaces [16:03:54 CET] <nevcairiel> but i dont think its very widely supported [16:03:58 CET] <nevcairiel> on some ARM systems iirc [16:04:17 CET] <nevcairiel> we even support that [16:04:23 CET] <iive> nevcairiel, the question is if the swamp would be in a separate library or inside ffmpeg. [16:04:32 CET] <atomnuker> yeah, but very few boards support that horrible interface anyway [16:04:43 CET] <iive> it's already getting quite muddy around here. [16:05:12 CET] <nevcairiel> now ARM, thats a real swamp of hardware nonsense [16:05:25 CET] <nevcairiel> no unified interfaces whatsoever [16:05:43 CET] <nevcairiel> only OpenMAX, which is horrible [16:05:57 CET] <atomnuker> no one uses that now these days though, right? [16:06:21 CET] <iive> it was replaced by something even more obscure, afaik [16:06:23 CET] <nevcairiel> i have no clue what one uses to achieve hardware access on arm in a broader scale [16:06:30 CET] <nevcairiel> on android you probably hook into mediacodec [16:07:28 CET] <atomnuker> I think wm4 was telling me about some /sys or debugfs horrors, not sure if that was on the odroid or rpi [16:07:45 CET] <nevcairiel> rpi is the worst non-standard thing when it comes to graphics anyway [16:07:56 CET] <iive> agree [16:08:02 CET] <nevcairiel> the broadcom proprietary drivers are so bad [16:08:15 CET] <nevcairiel> and the opensource version is slow :) [16:09:29 CET] <sourabhboss> What is codec_tags in mov muxer [17:22:32 CET] <J_Darnley> sourabhboss: a mapping of ffmpeg api to codec specific values, maybe [17:48:47 CET] <sourabhboss> J_Darnley: Thanks :) [17:52:02 CET] <durandal_1707> JEEB: open bug report about v3.80 APE not decoding properly [17:52:07 CET] <JEEB> ok [17:52:14 CET] <JEEB> I was planning on but not during $dayjob [18:12:18 CET] <faLUCE> Hello. Please have a look at ffmpeg.c, the line with: av_log(NULL, AV_LOG_INFO, "encoder -> type:audio " . The previous line "av_packet_rescale_ts(&pkt, enc->time_base, ost->mux_timebase); " should be put AFTER the log line [18:15:12 CET] <JEEB> I guess what he is trying to say is that the logging would be more consistent if the time base for the send and receive log would be the same [18:15:31 CET] <JEEB> you can grasp the time base from the _time logging but those are not exact values [19:54:31 CET] <atomnuker> if anyone's bored and still hasn't played it - play dead cells [19:58:40 CET] <durandal_1707> atomnuker: stop playing games, make something useful [19:59:10 CET] <gnafu> Like FFV2. [19:59:32 CET] <durandal_1707> nope [20:00:22 CET] <gnafu> Well, I'd like to see more FFV2 development. [20:02:04 CET] <atomnuker> nah, don't wanna work on that, I wanna work on vulkan [20:08:37 CET] <gnafu> atomnuker: Aah. [20:12:49 CET] <jamrial> nevcairiel: do you have any idea why fate-copy-png is failing on msvc even after carl's fix? [21:42:10 CET] <JEEB> oh, so we're OK with bools now? [21:42:34 CET] <JEEB> as much as C bools are such :D [21:43:52 CET] <JEEB> mediacodec and msbc at least seem to use bool [21:44:36 CET] <atomnuker> we should not be okay with it unless some external api requires it [21:59:07 CET] <J_Darnley> yeah, cant do a 3 state boolean with bool [22:17:04 CET] <philipl_> true, false, file_not_found [22:18:39 CET] <atomnuker> true, false, *((uint8_t *)&var) = 0xff; [22:28:32 CET] <iive> true, false, NULL :P [23:07:22 CET] <vel0city> apparently I _have_ to assign a pixfmt even if I want to process it myself? why? [23:07:39 CET] <vel0city> what is it even used for? [23:08:38 CET] <vel0city> ahh I see it's used to check the image size [23:08:45 CET] <vel0city> still, that's hacky :/ [23:08:58 CET] <vel0city> image support seems hacky in general [23:09:11 CET] <durandal_1707> vel0city: how it is hacky? [23:09:51 CET] <vel0city> durandal_1707: because now I have to find any 40bpp format and assign it to that [23:09:57 CET] <vel0city> so that the size check will work [23:10:02 CET] <vel0city> even if that format has nothing to do with mine [23:10:07 CET] <vel0city> or, make a new pixfmt... [23:11:03 CET] <durandal_1707> if you need 10bit per 4 components, make new format [23:11:26 CET] <vel0city> it's 8-bit 5 components actually [23:11:48 CET] <vel0city> and the thing is, TIFF can support arbitrary components per each photometric [23:12:07 CET] <vel0city> though now I'm just limiting it to just 4+1, probably not much point to be generic in this case [23:12:27 CET] <vel0city> aribitrary extra components* [23:12:51 CET] <vel0city> er, sorry, I haven't provided much context. here's the issue I'm solving: https://trac.ffmpeg.org/ticket/7675 [23:14:42 CET] <durandal_1707> vel0city: wasnt patch about that made by Carl already? [23:15:18 CET] <vel0city> which patch? master from yesterday still doesn't read that image properly [23:15:28 CET] <durandal_1707> on mailing list [23:15:34 CET] <durandal_1707> not yet committed [23:17:16 CET] <vel0city> oh. crap. [23:19:06 CET] <vel0city> shouldn't there be a indication on Trac when someone solves an issue? ... [23:19:36 CET] <JEEB> links to patches, possibly? although generally active tickets might only get updated after the improvement gets in [23:20:13 CET] <vel0city> so the only option is to always search the mailing lists for relevant patches? [23:20:23 CET] <JEEB> pretty much [23:23:53 CET] <vel0city> alright [23:24:29 CET] <vel0city> at least I didn't waste my time, getting familiar with that code is useful for DNG [23:25:08 CET] <vel0city> someone should review that patch though... it's from two months ago [23:25:16 CET] <vel0city> er, one [23:26:30 CET] <JEEB> I remember there was some discussion regarding it, but I don't remember the details [23:27:27 CET] <vel0city> I'm looking at his code too atm. hm, he doesn't read the ExtraSamples tag which seems wrong [23:29:25 CET] <vel0city> it's less generic the way he does it, but I guess it doesn't matter if you're not gonna implement ExtraSamples support for other color spaces/formats anyway [23:30:32 CET] <vel0city> JEEB: I assume the discussion was on here? Can't find any emails. [23:30:53 CET] <JEEB> it was on the ML [00:00:00 CET] --- Sat Mar 16 2019

1 0

ffmpeg.log.20190315
by burek 16 Mar '19

16 Mar '19

[00:00:27 CET] <JEEB> av_get_bytes_per_sample(sample_fmt) [00:00:28 CET] <JEEB> HA [00:00:30 CET] <JEEB> there it was [00:00:32 CET] <faLUCE> JEEB: av_get_bytes_per_sample(avctx->sample_fmt)) [00:00:35 CET] <JEEB> yes [00:00:41 CET] <JEEB> had to just remember how it was called :) [00:10:52 CET] <faLUCE> there should be an option for setting the buffer size of the opus encoder [01:18:44 CET] <Geek> does anyone know a ffmpeg based tool that uses mouse to select video area to cut a video? [01:19:17 CET] <Geek> or is there a script to measure video screen then return ffmpeg code for that, I am considering to create such thing [01:45:00 CET] <ossifrage> I copied the movflags from libavformat/dashenc.c and it gets a parse error "frag_every_frame+dash+delay_moov+skip_sidx+skip_trailer" == Undefined constant or missing '(' in 'skip_sidx' [01:45:03 CET] <ossifrage> Any ideas? [03:46:51 CET] <fling> Geek: there is an mpv plugin [05:10:50 CET] <ossifrage> Doh, it turns out at some point I had moved my ffmpeg git tree I was using for reference to a version after the one I have on my desktop and on the embedded target, doh [08:24:29 CET] <JEEB> dongs: so is it really mostly tlv id 0x03 and header packed ipv6 packets? i fed a few megabytes into a thing and I just get cid 1,2,3 from those. so no signaling packets etc? or are they just rarely muxed? [08:31:15 CET] <JEEB> also I get it why you said "not really variable length" because a whole lot of packets are 14xx bytes [08:31:35 CET] <JEEB> there's some 32-7xx ones but mostly 14xx [08:33:02 CET] <dongs> hi [08:33:18 CET] <dongs> JEEB: there's SI tables and shit (described in B60 [08:33:29 CET] <dongs> and NTP stuff over ipv6 [08:33:31 CET] <dongs> otherwise, yes just that [08:34:04 CET] <dongs> also i think i was doing something wrong with cid1/2/3 stuff before, i reran my shit and cid != 2 (from teh samples you haev anyway) is very little amount of data. i think my != or == thing was wrong when i was rejecting stuff [08:34:13 CET] <JEEB> ok [08:35:58 CET] <dongs> there's the PLT table that describes where stuff is, as well as MPT table. other stuff isnt strictly necessary, MH-SDT, MH-EIT etc. [08:36:17 CET] <dongs> also MH-CAT for crpyto stuff [08:38:11 CET] <dongs> about the only cunty stuff is gathering mfu/mpu sections until complete packet is done [08:38:16 CET] <dongs> this is where the DumpTS thing fails [08:39:15 CET] <JEEB> yea so a growing buffer a la pes packet finishing with mpeg-ts [08:39:40 CET] <dongs> yeah, start it on division=0, apppend othewies, and if 3= append and commit. [08:39:41 CET] <JEEB> then you pass that to the following layer as it's complete [08:39:45 CET] <dongs> ya [12:23:55 CET] <sazawal> Hello. I have split a video into clips at every keyframe using, "ffmpeg -i input.mkv -acodec copy -f segment -vcodec copy clip%d.mkv >& output.txt". I found the keyframe timestamps using, "ffprobe -v error -skip_frame nokey -sexagesimal -show_entries frame=pkt_pts_time -select_streams v -of csv=p=0 input.mkv >output1.txt". The first clip (clip0.mkv) I get is about 11 seconds long, and the timestamps in output1.txt says "(1) 0:00: [12:23:55 CET] <sazawal> 00.120000 (2) 0:00:01.200000 (3) 0:00:11.200000 (4) 0:00:20.920000". I do not understand why the first split is taking place at the third keyframe. [12:35:27 CET] <Ariyasu> the first key frame is probably the first frame [12:35:32 CET] <Ariyasu> so no point splitting there [12:35:42 CET] <Ariyasu> also the second frame could also be a keyframe [12:36:00 CET] <Ariyasu> the inital gop can be weird depending on how the file was created or cut [12:36:15 CET] <Ariyasu> you can have a few idr/i frames next to each other [12:44:04 CET] <sazawal> Ariyasu, I see. So apart from the first few clips/keyframes, it should be good otherwise. I mean, I am not doing anything wrong here. [12:47:12 CET] <sazawal> Ariyasu, Is there a way to get timestamps when the split is happening? Can I use some options in the split command (first command) to get the timestamps at the time of spllitting? [13:21:04 CET] <faLUCE> is it possible to encode/decode a RAW opus audio file? [13:34:47 CET] <JEEB> there's no raw opus as far as I know, although you will want to verify from #xiph or #opus or whatever the channel for that is? [13:34:58 CET] <JEEB> the .opus files are actually OGG [13:35:48 CET] <JEEB> (and those libavformat can read) [13:36:11 CET] <JEEB> if you have actual separate opus packets then I guess it could be decoded if you make AVPackets out of them [13:36:52 CET] <faLUCE> JEEB: ok. In addition, I just verified that frames sent to the opus encoder (not by me, but by ffmpeg command) have non costant pts incremental (--> they don't have pts = nb_samples.frame_counter) [13:37:40 CET] <faLUCE> I don't understand how ffmpeg sets these pts.... [13:38:05 CET] <faLUCE> they are around the same incremental value, but not with an exact incremental value [13:38:53 CET] <faLUCE> I printed the pts inside static int libopus_encode(...) [13:39:04 CET] <faLUCE> (libopusenc.c) [13:39:11 CET] <JEEB> don't need to do that to see the timestamps [13:39:12 CET] <JEEB> -debug_ts [13:39:15 CET] <JEEB> if you are using ffmpeg.c [13:39:27 CET] <JEEB> that will show you what the AVFrame/AVpacket timestamps will look like [13:40:10 CET] <faLUCE> but does it show that for ENCODED or MUXED frames/packets? [13:40:21 CET] <JEEB> yes [13:40:36 CET] <faLUCE> encoded or muxed? [13:40:38 CET] <faLUCE> or both? [13:40:40 CET] <JEEB> both [13:41:11 CET] <JEEB> demux, ffmpeg adjusted demux (fed to decoder), decoded timestamps [13:41:26 CET] <JEEB> you can see all the spots with `git grep -A2 "debug_ts"` [13:42:22 CET] <JEEB> basically on ffmpeg.c level (which is the API client) [13:42:42 CET] <JEEB> demuxer has two entries, "raw" demuxer and demuxer+ffmpeg adjustment [13:43:59 CET] <JEEB> for encoding it has both encoder <- (in) and encoder -> (out) etc [13:45:53 CET] <faLUCE> yes, I see all. I confirm they don't have a fixed incremental value [13:46:26 CET] <JEEB> you could add to the decoder output logging the nb_samples [13:46:52 CET] <JEEB> in the received AVFrame [13:54:52 CET] <faLUCE> JEEB: in the received avpacket o frame ? [13:54:56 CET] <faLUCE> or [13:57:02 CET] <faLUCE> (right,the frame for the decoder) [13:59:48 CET] <JEEB> yup [14:19:37 CET] <faLUCE> this is the command I used: ffmpeg -f alsa -ac 2 -i default -c:a libopus -f mpegts -debug_ts prova.ts I don't understand why it outputs also pts of a "demuxer" and "demuxer+ffmpeg" element. which is this demuxer? [14:20:58 CET] <faLUCE> are they the pts for the decoder? [14:21:36 CET] <JEEB> it's the input you feed into ffmpeg.c [14:21:43 CET] <JEEB> in this case the libavdevice ALSA device :P [14:22:02 CET] <JEEB> demuxer+ffmpeg is after ffmpeg.c plays with the values that are received from the "demuxer" [14:22:21 CET] <JEEB> you av_read_frame() from the devices so it makes sense to use the same logic as for normal reading of input [14:22:52 CET] <faLUCE> I see. In my program I don't use av_read_frame(), I call alsa API directly [16:24:03 CET] <faLUCE> Given this command: ffmpeg -f alsa -ac 2 -i default -c:a libopus -f mpegts -debug_ts prova.ts ---> I see two lists of pts: [16:24:11 CET] <faLUCE> encoder <- type:audio frame_pts:97935 frame_pts_time:2.04031 time_base:1/48000 [16:24:19 CET] <faLUCE> encoder -> type:audio pkt_pts:183039 pkt_pts_time:3.81331 pkt_dts:183039 pkt_dts_time:3.81331 [16:25:20 CET] <faLUCE> so, the second one is the output of the encoder: but how are these pts obtained ? I checked that they are not the pts of the avpackets obtained with "receive_av_packet()" [16:29:01 CET] <faLUCE> it seems that there's an additional rescaling for the out packets of a libopus encoder [16:44:22 CET] <faLUCE> this is very obscure... is there some hidden resampling or remuxing involved? [16:45:17 CET] <durandal_1707> opus encoder resamples everything into 48k [16:45:51 CET] <JEEB> but the fed time base seemed to be 48k too [16:46:07 CET] <JEEB> the offset is what he was interested in I guess? [16:46:18 CET] <JEEB> if those were for the same frame/packet [16:47:18 CET] <JEEB> faLUCE: check if that receival part is before or after the thing gets rescaled to the muxer time base? [16:48:17 CET] <JEEB> anyways i've had lavf+lavc work fine input to output with the api without any other pts/dts/duration adjustment than time base scaling where needed [16:49:07 CET] <JEEB> so I know that in theory the extra random stuff that ffmpeg.c isn't really needed (like starting timestamps at zero) [16:50:34 CET] <faLUCE> JEEB: it's before. In fact: [16:50:38 CET] <faLUCE> encoder -> type:audio pkt_pts:8400 pkt_pts_time:0.175 pkt_dts:8400 pkt_dts_time:0.175 [16:50:39 CET] <faLUCE> muxer <- type:audio pkt_pts:8400 pkt_pts_time:0.0933333 pkt_dts:8400 pkt_dts_time:0.0933333 size:151 [16:52:01 CET] <faLUCE> there should be an adjustmen somewhere.... let's lool libopusenc.c again [16:54:05 CET] <faLUCE> maybe the rescaling is in ff_af_queue_add() [17:19:56 CET] <faLUCE> nothing found... [17:39:06 CET] <faLUCE> [16:46] <JEEB> the offset is what he was interested in I guess? <--- which offset? [17:40:28 CET] <JEEB> the one between the two _time variables, pkt_pts_time:0.175 vs pkt_pts_time:0.0933333 . [17:40:37 CET] <JEEB> or those weren't the same thing? [17:41:28 CET] <JEEB> although no [17:41:39 CET] <JEEB> those are just two different things, just having matching pkt_pts :P [17:41:46 CET] <JEEB> 8400 / 48000 [17:41:47 CET] <JEEB> 0.175 [17:41:52 CET] <JEEB> 8400 / 90000 [17:41:52 CET] <JEEB> 0.09333333333333334 [17:41:59 CET] <JEEB> so it's not the same thing you're looking at :P [17:42:17 CET] <faLUCE> I mean: there seem to be some offset put by ffmpeg to the encoded pkts' pts.... [17:42:40 CET] <JEEB> to compare the same thing, the latter would be [17:42:40 CET] <JEEB> 8400 * (90000 / 48000) [17:42:41 CET] <JEEB> 15750.0 [17:42:45 CET] <JEEB> that pkt_pts [17:43:28 CET] <faLUCE> so, the value debugged by ffmpeg as the "encoder output", is not the avpacket->pts .... but what is it? [17:43:47 CET] <JEEB> it is, but it is the output of an earlier packet that you looked at :P [17:43:56 CET] <JEEB> because the timestamps have been adjusted for time base [17:44:25 CET] <JEEB> the one that is fed to MPEG-TS muxer has its timestamps adjusted to 1/90000 [17:44:28 CET] <faLUCE> I checked that... there was no buffering [17:44:41 CET] <JEEB> ok, let's not go further. let's confirm one thing [17:44:47 CET] <JEEB> you posted two AVPacket log lines, right? [17:44:52 CET] <faLUCE> yes [17:44:55 CET] <JEEB> with both having pkt_pts 8400, right? [17:45:22 CET] <faLUCE> yes [17:45:34 CET] <JEEB> now, do you understand that those two are not the same "thing". it's just two packets that happen to have the same pkt_pts *after* the pkt_pts was adjusted for time base? [17:45:53 CET] <JEEB> when you receive the AVPacket from encoder that packet is in encoder time base [17:45:59 CET] <JEEB> which in case of libopus is 1/48000 [17:46:00 CET] <faLUCE> damn, I thought they were the same packet [17:46:02 CET] <JEEB> yea [17:46:18 CET] <faLUCE> so, the "encoder->" packet is a buffered packet, right? [17:46:19 CET] <JEEB> the log line for muxing is after the pkt_pts is adjusted [17:46:32 CET] <JEEB> what do you mean with "buffered packet"? [17:46:49 CET] <faLUCE> I mean: [17:46:54 CET] <JEEB> anyways, to match the packet that was received from the decoder for pkt_pts [17:46:56 CET] <JEEB> 8400 [17:46:57 CET] <JEEB> 18:42 < JEEB> 8400 * (90000 / 48000) [17:46:57 CET] <JEEB> 18:42 < JEEB> 15750.0 [17:47:06 CET] <JEEB> that pkt_pts should be the same timestamp for 1/90000 [17:47:16 CET] <faLUCE> look at this log: [17:47:19 CET] <faLUCE> encoder <- type:audio frame_pts:3832 frame_pts_time:0.0798333 time_base:1/48000 [17:47:20 CET] <faLUCE> encoder -> type:audio pkt_pts:6593 pkt_pts_time:0.137354 pkt_dts:6593 pkt_dts_time:0.137354 [17:47:22 CET] <faLUCE> muxer <- type:audio pkt_pts:6593 pkt_pts_time:0.0732556 pkt_dts:6593 pkt_dts_time:0.0732556 size:168 [17:47:52 CET] <faLUCE> now, you confirm that the muxer packet is not the "encoder->" packet [17:47:53 CET] <faLUCE> right? [17:48:10 CET] <JEEB> encoder -> is the "received from encoder" point [17:48:34 CET] <JEEB> muxer <- is the "feeding AVPacket with these timestamps to muxer" [17:48:45 CET] <faLUCE> and in this case they are not the same packet [17:48:48 CET] <faLUCE> right? [17:49:06 CET] <JEEB> yes, the one fed into muxer is an earlier one [17:49:30 CET] <JEEB> the pkt_pts just happens to match :P [17:49:42 CET] <JEEB> (after time_base adjustment) [17:49:50 CET] <faLUCE> ok, now: looking at the "encoder <-", that frame does not correspond to the packet in the "encoder->" line soon after [17:49:52 CET] <faLUCE> right? [17:52:06 CET] <faLUCE> (in fact I see different pts) [17:52:38 CET] <JEEB> for the record, there can also be an offset due to the encoder's encoder delay for audio [17:52:47 CET] <JEEB> the amount of encoder delay depends on the audio frame sizes usually [17:53:13 CET] <JEEB> but I don't know, I don't know your full logs or anything to make a proper assessment which frame and packet match each other. sorry :P [17:54:20 CET] <faLUCE> but I made a debug inside libopus_encode(). I debugged the pts for of the input FRAME, and it is the same of (encoder<-) part, and the pts of the output packet, and it is the same of (encoder<-) part [17:54:41 CET] <faLUCE> so, there should be a buffering outside the opus stuff [17:54:50 CET] <JEEB> yes, because encoder <- is what is fed into the encoder [17:54:52 CET] <JEEB> from ffmpeg.c [17:55:19 CET] <faLUCE> ok, but the pts of the output packet should be the same of that of "encoder->" [17:55:22 CET] <faLUCE> but it is not [17:55:35 CET] <faLUCE> so, the debug is misleading... [17:55:41 CET] <JEEB> depends on how ffmpeg.c calls teh receive [17:55:47 CET] <JEEB> and/or other possible factors [17:56:15 CET] <faLUCE> [17:55] <JEEB> depends on how ffmpeg.c calls teh receive . Well, this is true. But this is not something associated to the opus code [17:56:23 CET] <JEEB> of course not [17:56:35 CET] <faLUCE> but at the same time, it's mixed to the opus part [17:57:09 CET] <faLUCE> but in each case, there's something between send and receive that ADJUSTS [17:57:12 CET] <faLUCE> these timestamp [17:57:21 CET] <faLUCE> in ffmpeg.c [17:57:34 CET] <faLUCE> am I wrong? [17:57:42 CET] <thebombzen> tfw my patch is ignored again [17:57:44 CET] <thebombzen> 2nd time in a row [17:57:45 CET] <thebombzen> lol [17:57:53 CET] <JEEB> I've just been dead and all :V [17:58:00 CET] <JEEB> I tried to get derek to look at the fps patch [17:58:05 CET] <JEEB> since he asked about that very thing [17:58:08 CET] <thebombzen> oh so u know which one I'm talking about [17:58:13 CET] <JEEB> "can I set fps with ffmpeg.c?" [17:58:25 CET] <thebombzen> ye [17:58:30 CET] <thebombzen> I sent it in january [17:58:47 CET] <JEEB> yea, it's unfortunate that some patches don't get attention [17:58:52 CET] <JEEB> there was also a patch to improve examples [17:59:06 CET] <JEEB> I wanted to take a look at it but I've had other things I've had to prioritize higher than that [17:59:09 CET] <JEEB> :V [17:59:10 CET] <thebombzen> it was this one [17:59:10 CET] <thebombzen> https://0x0.st/zXg0.patch [17:59:50 CET] <faLUCE> I sent patches one year ago. they had also good feedbacks, but they were forgotten [18:00:08 CET] <JEEB> faLUCE: I'm not sure if ffmpeg.c adjusts timestamps after receiving the AVPacket and feeding it into a muxer. other than adjusting the timestamps and duration according to time base [18:00:26 CET] <JEEB> check how much encoder delay libopus adds? [18:00:50 CET] <JEEB> this probably doesn't help at all, but I've actually built an API client myself that decoded and re-encoded audio [18:00:53 CET] <JEEB> it worked :P [18:00:59 CET] <JEEB> without any real special stuff [18:01:36 CET] <thebombzen> doesn't ffmpeg.c sanitize timestamps on input [18:01:41 CET] <thebombzen> unless you use `-copyts` input option? [18:01:41 CET] <JEEB> on input, yes [18:01:50 CET] <JEEB> this is after receiving AVPacket from encoder [18:01:58 CET] <thebombzen> also what happens if you try `-vsync passthrough` [18:02:07 CET] <JEEB> he is ok with the input adjustments [18:02:11 CET] <faLUCE> <JEEB> check how much encoder delay libopus adds? <--- already done. there's a delay field. It sets a "312" delay to the avctx [18:02:12 CET] <JEEB> (after av_read_frame) [18:02:16 CET] <thebombzen> oh nvm, that's video [18:02:39 CET] <JEEB> faLUCE: it should also be adjusted in the AVPackets [18:02:44 CET] <JEEB> at least that's how it usually is [18:03:10 CET] <faLUCE> JEEB: yes, in fact I saw it's adjusted in the output avpacket [18:03:13 CET] <JEEB> just like you open an mp4 file with encoder delay and the AVPacket you demux has a negative PTS [18:03:22 CET] <JEEB> (the first one) [18:03:34 CET] <faLUCE> but it is not the same delay in the encoder-> part [18:04:17 CET] <JEEB> anyways, the logging is very close by [18:04:22 CET] <JEEB> if you look at do_audio_out [18:04:25 CET] <JEEB> in ffmpeg.c [18:04:58 CET] <JEEB> 1. debug_ts encoder <- 2. avcodec_send_frame 3. go into avcodec_receive_packet loop [18:05:24 CET] <JEEB> it rescales to muxer AVStream time base and another debug_ts [18:05:30 CET] <faLUCE> av_packet_rescale_ts(&pkt, enc->time_base, ost->mux_timebase); [18:05:34 CET] <faLUCE> damn!!!| [18:05:59 CET] <faLUCE> then this is misleading [18:06:13 CET] <JEEB> well yes, I've mentioned it will rescale the timestamps from encoder time base to muxer time base? [18:06:27 CET] <JEEB> but yes, the differing time bases can be fun. that should still not cause a drift [18:06:43 CET] <faLUCE> JEEB: ok, but this is misleading, because the debug says encoder-> and muxer<- [18:06:47 CET] <JEEB> that should only make f.ex. 8400 into 15750 [18:06:56 CET] <faLUCE> this should be fixed, IMHO [18:06:59 CET] <JEEB> faLUCE: muxer <- comes later :P [18:07:30 CET] <JEEB> but yes, it should be more clear what time base is being used [18:07:39 CET] <faLUCE> I'll send a ticket [18:07:45 CET] <JEEB> for what? [18:07:48 CET] <faLUCE> for that [18:07:52 CET] <JEEB> ? [18:08:10 CET] <JEEB> for it not being clear which time base it is? [18:08:15 CET] <faLUCE> it's absolutely not clear that the out ts of the encoder-> part is rescaled [18:08:24 CET] <faLUCE> yes [18:08:26 CET] <JEEB> ok [18:08:34 CET] <JEEB> I just wanted you to confirm that :P [18:08:55 CET] <faLUCE> JEEB: note that the timebase in other log lines is specified [18:09:05 CET] <JEEB> yea [18:09:12 CET] <JEEB> in the AVFrame ones at least [18:09:23 CET] <JEEB> or the one right before feeding it [18:09:35 CET] <JEEB> the _time ones give a hint, but are not exact [18:09:39 CET] <JEEB> so yes, I agree :P [18:09:42 CET] <JEEB> that logging could be improved [18:09:44 CET] <faLUCE> but I think that the two lines should be swapped [18:10:00 CET] <faLUCE> av_packet_rescale_ts(&pkt, enc->time_base, ost->mux_timebase); AFTER the av_log [18:10:55 CET] <JEEB> yea, I guess it makes sense to log in the same time base that the other log line logged in [18:10:56 CET] <faLUCE> let's inform the devel channel [18:11:43 CET] <JEEB> these sorts of things are just low priority. not controversial and I bet nobody would actually mind :P [18:12:11 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=fftools/ffmpeg.c;h=544f1… [18:12:16 CET] <JEEB> I improve logging sometimes [18:13:07 CET] <JEEB> although the delta and the ts_offset are not exactly understandable :P [18:13:14 CET] <JEEB> but at least it tells you now which stream had a discontinuity [18:13:21 CET] <JEEB> and if it was video or audio or whatever [19:13:04 CET] <lemourin> is it possible to read parts of very big images with ffmpeg without running out of memory? e.g these http://images.aperio.com/BigTIFF/ [19:20:50 CET] <JEEB> lemourin: there's a random memory allocation limit somewhere so if those images are really large you might hit that [19:21:06 CET] <JEEB> supposedly it's to protect against mistaken large allocations... or something [19:23:18 CET] <lemourin> yea, but in the link i sent there is an image with resolution 1095630 x 939495 (10^12 pixels) so there is no way any normal pc would load it all at once; so what i'm asking about is whether it is possible to read only a subrectangle of such big image [19:24:34 CET] <JEEB> you'd need to make a decoder that takes in requests of specific parts [19:24:39 CET] <JEEB> or something like that [19:25:03 CET] <lemourin> ok, so currently it is not possible; thats all i need to know for now :) [19:26:40 CET] <JEEB> or at least I don't remember any decoders being able to return limited images without the decoder supporting it. and other than cropping in AVC / HEVC etc I don't remember there being such partial things [19:28:03 CET] <JEEB> lemourin: basically just not that I know of :) [19:28:13 CET] <JEEB> I could be incorrect o' course [20:46:29 CET] <faLUCE> is it possible to feed an opus audio muxer, with ffmpeg, with encoded frames as separate files? [20:48:15 CET] <faLUCE> (or with a raw opus encoded stream file) [20:54:39 CET] <faLUCE> ffmpeg -f alsa -ac 2 -i default -c:a libopus -f opus prova.opus <---- I don't understand if the output is raw opus and how to play it (if I play it with ffplay, I hear very fast audio) [20:57:23 CET] <JEEB> -f opus is opus-in-ogg [20:57:28 CET] <JEEB> there is no such thing as "raw opus" [20:57:40 CET] <JEEB> opus always needs some encapsulation [21:46:53 CET] <retal> Hi guys, how to fix common.mak:57: recipe for target 'libavcodec/libx264.o' failed ? [21:46:55 CET] <retal> https://pastebin.com/VXeFWtKq [21:54:55 CET] <faLUCE> retal: which version of ffmpeg are you compiling? [21:55:50 CET] <retal> i pulled from git [21:55:58 CET] <faLUCE> retal: then update x264 too [21:56:32 CET] <faLUCE> (upgrade) [21:56:45 CET] <retal> 264 also pulled from N-76538-gb83c849e87 [21:56:58 CET] <retal> sorry https://code.videolan.org/videolan/x264.git [21:58:29 CET] <retal> faLUCE, ffmpeg from git://source.ffmpeg.org/ffmpeg.git [21:58:29 CET] <retal> x264 from https://code.videolan.org/videolan/x264.git [21:58:56 CET] <faLUCE> retal: check if you have x264_bit_depth in x264_config.h [21:59:33 CET] <faLUCE> defined [22:01:39 CET] <retal> faLUCE, #define X264_BIT_DEPTH 0 [22:05:08 CET] <faLUCE> retal: wait a sec [22:06:09 CET] <faLUCE> retal: do you need latest x264 ? [22:06:41 CET] <retal> faLUCE, https://code.videolan.org/videolan/x264.git not latest ? [22:06:48 CET] <faLUCE> retal: I mean: [22:06:58 CET] <faLUCE> do you WANT to use the latest x264 [22:07:01 CET] <faLUCE> ? [22:07:08 CET] <faLUCE> for specific reasons? [22:07:22 CET] <retal> i dont care about version , i just need x264 :) [22:08:21 CET] <kepstin> i don't see anything obvious in current x264 git that would break it with ffmpeg [22:08:35 CET] <faLUCE> ok, then download an older x264 version, and make sure that in common.c "const int x264_bit_depth = BIT_DEPTH;" [22:08:45 CET] <faLUCE> make sure there's that line [22:09:39 CET] <faLUCE> kepstin: yes, it's strange [22:10:04 CET] <retal> faLUCE, thank you i will try [22:11:08 CET] <kepstin> retal: it looks like the issue is that ffmpeg's configure script and ffmpeg's build were run with different x264 versions [22:11:20 CET] <kepstin> maybe you have a system copy of x264 installed that's confusing things? [22:11:39 CET] <kepstin> hmm, wait, no that makes no sense [22:12:04 CET] <faLUCE> kepstin: just checked that I have x264_bit_depth in ffmpeg 4.2.1 too, but not in libx264. and it compiled fine [22:12:08 CET] <kepstin> but regardless, ffmpeg shouldn't be trying to access teh `x264_bit_depth` field at all for X264 >= 153 [22:12:17 CET] <kepstin> so it's misdetected the x264 version [22:13:11 CET] <faLUCE> yes, that's right [22:14:31 CET] <faLUCE> kepstin: btw, the ffmpeg program doesn't calculate timestamps for the avframe input of opus encoder based on samples... it's time based [22:14:57 CET] <kepstin> faLUCE: yes, that's because everything ffmpeg cli does is generic and based on time/pts. [22:15:13 CET] <kepstin> faLUCE: however, most audio inputs to ffmpeg will report time based on samples, so... [22:15:23 CET] <kepstin> although it depends [22:15:52 CET] <faLUCE> kepstin: in each case, sample-based or time-based pts gave me the same choppy audio :-( [22:16:20 CET] <kepstin> faLUCE: hmm, sometime else going wrong then. really hard to say without being able to hear it or see the code. [22:16:29 CET] <faLUCE> kepstin: I know, I know [22:16:49 CET] <faLUCE> kepstin: the biggest problem is that I could write a "raw opus file" but [22:17:05 CET] <faLUCE> I don't know how I could use it for debugging [22:17:18 CET] <kepstin> there's no such thing as raw opus, because opus packets are not self framing (they need external signalling of packet length) [22:17:33 CET] <kepstin> inside ffmpeg, that's done by the data size on the AVPacket [22:17:39 CET] <kepstin> and in containers, by the container [22:18:24 CET] <faLUCE> the biggest problem is that it's very hard to figure which field in the avctxt, in the avframe or in the muxer has not been set..... they are so many [22:20:49 CET] <kepstin> i think all you need to actually set on the avctx is just channels, sample_rate, and sample_fmt - everything else has reasonable defaults [22:21:23 CET] <faLUCE> kepstin: and they are set correctly (and they work with mp2 and adts aac) [22:23:12 CET] <faLUCE> kepstin: on the avframe I set nb_samples, format, channels, layout, sample_rate and pts (before encoding) [22:24:00 CET] <faLUCE> and filled the avframe with linesize[0] bytes [22:24:02 CET] <kepstin> right, frame->nb_samples should match avctx->frame_size - and you have to make sure you actually have that many samples in the buffer, of course. [22:24:20 CET] <faLUCE> yes, I have all the samples in the buffer [22:24:40 CET] <faLUCE> the strange thing is that the audio distortion is very little [22:25:07 CET] <faLUCE> I wonder if it has something to do with a pre-roll [22:25:23 CET] <kepstin> preroll has nothing to do with it [22:25:47 CET] <kepstin> preroll is how many samples the decoder is supposed to discard after starting playback [22:25:53 CET] <kepstin> it doesn't affect ongoing decoding [22:26:38 CET] <kepstin> (the encoder sticks some extra samples at the start before encoding to, "prime" the encoder i guess you'd say) [22:27:29 CET] <faLUCE> kepstin: but if I encode (resulting good audio ) with ffmpeg, I see that the first encoded frame has a ts = -312. Where 312 is a sort of padding [22:28:05 CET] <kepstin> yeah, that's the preroll. how it's signalled depends on the container [22:28:29 CET] <kepstin> when you decode that, you throw out the first 312 samples and then use the rest continuously [22:29:04 CET] <faLUCE> then the distortion could depend on that [22:29:08 CET] <kepstin> how? [22:29:40 CET] <faLUCE> I mean, if I have to use the rest continously, there a bad offset of 312 for each frame? [22:29:51 CET] <faLUCE> (there is) [22:29:53 CET] <kepstin> the worst that could happen is you forget to remove the preroll during playback, and then you have an extra couple ms of junk (mostly silence) at the start. [22:30:08 CET] <faLUCE> kepstin: exactly [22:30:11 CET] <kepstin> all the timestamps are correct in that case - 0 is the start of the useful audio [22:31:06 CET] <faLUCE> coming back in 15 mins [22:31:20 CET] <kepstin> so the first frame contains e.g. samples -312 to before 0, which you throw out, and then it has the other 648 that you keep [22:31:30 CET] <kepstin> then the next frame has 960 samples starting at 648 [22:31:42 CET] <kepstin> then the next has 960 sample starting at 1608 [22:31:44 CET] <kepstin> and so on [22:32:30 CET] <kepstin> but that's on the decoder side [22:32:55 CET] <kepstin> on the encoder side, you don't need to do anything - you just pass in audio, and the encoder will insert the preroll samples before starting to encode your audio [22:34:38 CET] <kepstin> note that preroll samples are common in all dct based audio codecs, with varying ways to signal them [22:34:56 CET] <kepstin> vorbis signals them in-stream, so the decoder transparently removes them for you [22:35:33 CET] <kepstin> mp3 doesn't bother, so the only way you'll know about the added samples is if the encoder put some custom metadata in (e.g. a xing header) that indicates it [22:37:09 CET] <kepstin> aac is a mess, there's apparently a way to signal it properly in mp4 now, but originally you just assumed that your aac was made by itunes, and hardcoded the delay to the value itunes used. [22:37:28 CET] <kepstin> anyways, none of this *in any way* would cause ongoing noticable problesm with audio quality [22:38:31 CET] <kepstin> since it's done by the encoder, so you don't need to do anything when encoding, and it's only handled once at the start of the audio when decoding, and if you forget to do that you probably still wouldn't be able to tell unless you cared about exact alignment of samples or "gapless" music playback between multiple files [22:41:34 CET] <kepstin> (er, i guess "MDCT" based codecs specifically, since those are the onces that do overlap) [22:48:39 CET] <MiniDude_> Hello ffmpeg group don't want to step on anyone else's questions, and hopefully this is the right channel to ask. When doing some transcoding with the fflag discardcorrupt, what is it looking at in the frames to determine if the frame is corrupted? i see when transcoding the error Dropped corrupted packet (stream = 1). I've been digging through the files, and see in utils.c where it is using the constant AVFMT_FLAG_DISCARD_CORRUP [22:49:36 CET] <kepstin> MiniDude_: corruption is detected in the decoder - if the decoder sees something it doesn't expect, it might set the a flag on the decoded flag to indicate it has corrupt data [22:49:54 CET] <kepstin> how accurate this is depends on the decoder [22:50:06 CET] <kepstin> a flag on the decoded frame* [22:50:19 CET] <JEEB> MiniDude_: it's handled within libavformat [22:50:20 CET] <kepstin> I suppose some containers with checksums might also do something at the container level [22:50:26 CET] <kepstin> not sure, haven't looked into that [22:50:30 CET] <JEEB> if some demuxer sets the flag [22:50:36 CET] <JEEB> AV_PKT_FLAG_CORRUPT [22:50:44 CET] <JEEB> if that gets set, you get that message [22:50:50 CET] <JEEB> since the internal lavf code drops that packet [22:50:57 CET] <kepstin> hmm, is it only at the packet level? [22:51:01 CET] <JEEB> this option is [22:51:08 CET] <JEEB> (discardcorrupt) [22:51:21 CET] <kepstin> oh right, I should have seen the "Dropped corrupted *packet*" :) [22:51:33 CET] <faLUCE> About two years ago I submitted some api examples, like this one: https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg50906.html now I will use the same example in order to understand what was wrong with opus... if anyone finds useful this patch, please signal it so it can be added to the examples of ffmpeg [22:52:06 CET] <JEEB> MiniDude_: so if *you* want to handle the corrupt packets, then you *don't* set that flag [22:52:18 CET] <JEEB> because with this flag it will just drop the packets for you [22:52:27 CET] <MiniDude_> yeah i figured if by not setting the flag it would stop the errors [22:52:50 CET] <MiniDude_> was just trying to understand what would cause the packet to be considered corrupt when it is passed through the decoder. [22:53:07 CET] <MiniDude_> So i guess it would have to do with the other flags that are being used [22:53:13 CET] <JEEB> s/decoder/demuxer/ [22:53:15 CET] <JEEB> since this is libavformat [22:54:17 CET] <JEEB> if you do a `git grep "AV_PKT_FLAG_CORRUPT"` you will see which modules utilize this value at all [22:54:34 CET] <faLUCE> kepstin: as you can see, about two years ago I used the sample-based method: pts = converted_audio_frame->nb_samples*(encoded_pkt_counter-1); :-) [22:55:10 CET] <MiniDude_> i saw the code in libavformat where it was using the if statement to compare the value [22:55:11 CET] <kepstin> faLUCE: biggest change you should have to make to that example for opus is that the libopus encoder doesn't accept planar formats, only packet s16 and flt. [22:55:20 CET] <kepstin> packed* [22:55:26 CET] <faLUCE> kepstin: I defined all... [22:55:42 CET] <faLUCE> so, with few changes it would be good for opus too [22:55:46 CET] <MiniDude_> thanks for the quick response. i'll go do some more research. [22:55:52 CET] <JEEB> MiniDude_: basically without the flag the API gives you packets including those marked by the demuxers as corrupt [22:55:54 CET] <faLUCE> and it's really better than the strange examples in the doc dir [22:56:04 CET] <JEEB> MiniDude_: with the flag, it automagically drops them [22:56:11 CET] <JEEB> which is where the message comes from [22:56:18 CET] <JEEB> so that you know that the API did indeed drop a packet [22:56:24 CET] <JEEB> (because it was flagged corrupt) [22:56:27 CET] <MiniDude_> yeah i figured that was the case. [22:57:08 CET] <MiniDude_> would it be possible that by dropping packets it would cause an issue like lipsync on video? [22:57:11 CET] <MiniDude_> i would assume yes [22:57:29 CET] <kepstin> it shouldn't, since the following packets will still have correct timestamps (pts) [22:57:30 CET] <JEEB> depends on the exact container and if it has proper timestamps and you as the API client are able to re-sync [22:58:06 CET] <MiniDude_> hmm you just might have just given me an ahah moment. [22:58:31 CET] <kepstin> depending on the codec, you might want to pass corrupt packets to the decoder anyways, they might be able to partly decode it or do some error concealment. Or you might just get cool glitch effects. [22:59:19 CET] <MiniDude_> lol cool glitch effect [23:01:12 CET] <MiniDude_> what would you say the effects would be of dropping those corrupt packets. mind you this is doing mpeg2 and mpeg4. [23:01:27 CET] <JEEB> depends [23:03:42 CET] <kepstin> in general, the earlier in the gop your corrupt frame is the worse it'll be, since it means predictions of later frames in the gop will be based on incorrect/missing data [23:03:44 CET] <MiniDude_> so one thing i'm experiencing is the lipsync issue on some of my streams, but like it was pointe dout that could be the re-sync of the time stamps, but i'm also seeing where sometimes it will just stop doing transcoding [23:04:17 CET] <kepstin> what container? something like mpeg-ts where you can resync? [23:04:35 CET] <MiniDude_> correct mpeg-ts [23:05:03 CET] <JEEB> some corruption can cause long-lasting effects in a decoder for instance [23:05:18 CET] <JEEB> i've had one channel get such an error about nightly while it was around :P [23:05:53 CET] <MiniDude_> that is what i'm seeing. over a span of time the channel will be fine and then just start spewing corrupt errors. Restarting the channel seems to clear them up for a while. [23:06:19 CET] <JEEB> if it's the corrupt error you quoted before, that's *before* decoding [23:06:26 CET] <JEEB> it's the protocol/demuxing layer [23:06:42 CET] <JEEB> I'm talking about passing such data to the decoder anyways [23:07:08 CET] <JEEB> protocol (file, udp, whatever) -> demuxer (f.ex. mpeg-ts) -> decoder (f.ex. H.264) [23:07:16 CET] <MiniDude_> ot [23:07:26 CET] <MiniDude_> it's* pulling in a udp [23:07:44 CET] <MiniDude_> not that it really matters, but the full error is: 03-14 10:15:18 INFO [50450:libavutil/log.c:338] [mpegts @ 0x2483740] Dropped corrupted packet (stream = 0) [23:07:58 CET] <MiniDude_> and that can be repeated multiple times in a single second. [23:08:09 CET] <kepstin> might want to double-check buffers/processing speed if this is something that happens regularly after it's been running for some amount of time [23:08:21 CET] <JEEB> yes, that's the libavformat packet reading layer telling you it's getting garbage in [23:08:26 CET] <JEEB> it's way before decoding [23:08:48 CET] <JEEB> libavformat handles protocols (I/O) and containers (demuxing and muxing) [23:08:55 CET] <MiniDude_> ok [23:09:26 CET] <JEEB> if you have multiple sources, make sure you're only taking in one [23:09:35 CET] <MiniDude_> would you think a low udp buffer in the sysctl cause it to become garbage? [23:09:54 CET] <JEEB> yes, if the kernel has to drop packets from queue the result will be garbage [23:09:58 CET] <kepstin> if you receive multiple frames while the application is busy doing something else, yes [23:10:02 CET] <MiniDude_> perfect. [23:10:09 CET] <MiniDude_> that is another route i was going down [23:10:11 CET] <kepstin> well, s/multiple frames/too much data/ [23:10:49 CET] <MiniDude_> i was thinking that if the udp buffer was filling up too much it was dropping and then the next packet in line would not be in the correct order [23:15:15 CET] <MiniDude_> thanks everyone for the input. gonna take this back and do some tweaks to see if it improves performance. If not i'll probably come back and hit you with some more questions. [00:00:00 CET] --- Sat Mar 16 2019

1 0

ffmpeg-devel.log.20190314
by burek 15 Mar '19

15 Mar '19

[01:06:35 CET] <cone-144> ffmpeg 03Alex Mogurenko 07release/4.1:7e204f72607c: avcodec/prores_ks: Fix luma quantization if q >= MAX_STORED_Q [01:06:35 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:1a82246caed8: avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c() [01:06:35 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:d25f388584a3: avformat/mov: Do not use reference stream in mov_read_sidx() if there is no reference stream [01:06:35 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:8066cb3556e7: avcodec/mpeg4videodec: Clear interlaced_dct for studio profile [01:06:35 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:4d1fcd734e87: avformat/matroskadec: Do not leak queued packets on sync errors [01:06:36 CET] <cone-144> ffmpeg 03Kevin Backhouse via RT 07release/4.1:cc5361ed18ab: avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for tag scaning [01:06:36 CET] <cone-144> ffmpeg 03Kevin Backhouse via RT 07release/4.1:f7f3937494f6: avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for handling braces [01:06:37 CET] <cone-144> ffmpeg 03Wenxiang Qian 07release/4.1:11375cd10147: avformat/ftp: Fix Out-of-Bounds Access and Information Leak in ftp.c:393 [01:06:37 CET] <cone-144> ffmpeg 03Wenxiang Qian 07release/4.1:ec22b46a4d34: avformat/http: Fix Out-of-Bounds access in process_line() [01:06:38 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:339f40f61818: avformat/webmdashenc: Check id in adaption_sets [01:06:39 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:9495228df028: avcodec/h264_direct: Fix overflow in POC comparission [01:06:40 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:4e624c89fddd: avcodec/jvdec: Check available input space before decode8x8() [01:06:41 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:ff491b154442: avcodec/zmbv: obtain frame later [01:06:42 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:92335fc02b2c: avcodec/mlpdec: Insuffient typo [01:06:43 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:b8dd1d2d4bde: avcodec/error_resilience: Use a symmetric check for skipping MV estimation [01:06:44 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:662b6351c80a: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int() [01:06:45 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:09683e1f4e21: avcodec/bethsoftvideo: Check block_type [01:06:46 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:29619a8ac275: avcodec/gdv: Check for truncated tags in decompress_5() [01:06:47 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:6c0124d3921d: avcodec/aic: Check remaining bits in aic_decode_coeffs() [01:06:48 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:c90836cc3df3: avcodec/qpeg: Limit copy in qpeg_decode_intra() to the available bytes [01:06:49 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:67d030787e0b: avcodec/scpr: Fix use of uninitialized variable [01:06:50 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:ad12d9df1ed9: avcodec/dxv: Correct integer overflow in get_opcodes() [01:06:51 CET] <cone-144> ffmpeg 03Michael Niedermayer 07release/4.1:1e50a327c649: avcodec/mpeg4videodec: Check idx in mpeg4_decode_studio_block() [01:43:03 CET] <vel0city> do you guys have any GSoC candidates? [10:10:34 CET] <JEEB> i think I am at peak masochist when I start writing a TLV parser >_> [10:33:10 CET] <durandal_1707> i'm trying harder and harder and harder but can not RE this shit [10:36:40 CET] <j-b> JEEB: in rust? [10:40:13 CET] <JEEB> j-b: I... didn't think of that since I wanted the nice binary reading helpers of lavu :D [10:40:19 CET] <JEEB> but that might be interestdusting [10:40:30 CET] <j-b> JEEB: use Rust and Nom [10:41:11 CET] <JEEB> yes, Nom I did know of [10:43:12 CET] <BradleyS> michaelni: these can probably be backported, handbrake needs at least the first one [10:43:13 CET] <BradleyS> https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/402bf262375dfecd0e90d7a… [10:43:13 CET] <BradleyS> https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/d9b2668766e3e924d4ebb3c… [10:43:13 CET] <BradleyS> https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/db332832a17c6da68067869… [10:44:34 CET] <nevcairiel> why are you not using pkg-config? :) [10:47:53 CET] <j-b> especiallys since libvpx provides a vpx.pc now [10:48:51 CET] <BradleyS> and pain [10:49:05 CET] Action: BradleyS runs [10:49:21 CET] <j-b> fighting against .pc in 2019 is beyond idiotic [10:49:27 CET] <j-b> pkg-config has won, deal with it. [10:49:31 CET] <JEEB> pkgconf doesn't require gobject [10:49:38 CET] <JEEB> it also can be built with MSVC IIRC [10:49:41 CET] <j-b> pkgconflite either [10:49:43 CET] <j-b> etc.. [10:49:43 CET] <BradleyS> i meant libvpx :P [10:49:43 CET] <JEEB> https://github.com/pkgconf/pkgconf/ [10:49:54 CET] <BradleyS> pkg-config is fine [10:50:03 CET] <JEEB> different distros have moved to pkgconf as the pkg-config provider [10:51:04 CET] Action: BradleyS wishes he had a cluster to throw at vp9/av1 [10:51:13 CET] <BradleyS> JEEB: which? [10:51:32 CET] <j-b> VP9 is dead :0 [10:51:37 CET] <j-b> also, fork libvpx [10:52:38 CET] Action: BradleyS sticks a fork in j-b's hat and runs faster [10:52:43 CET] <j-b> :D [10:55:48 CET] <JEEB> BradleyS: fedora quite a while ago, and I think I saw some other distro recently switch over during a package upgrade [10:55:53 CET] <JEEB> not sure if it was ubuntu or what [10:56:07 CET] <BradleyS> ah [11:04:01 CET] <JEEB> ah yes, cygwin was actually the one I saw switch most recently [12:25:04 CET] <cone-198> ffmpeg 03Matthew Fearnley 07master:032137060183: libavcodec/zmbvenc: Add support for RGB formats [12:26:35 CET] <thardin> cutting edge high-color zmbv [12:56:13 CET] <JEEB> durandal_1707: were you interested in poking at a seemingly incorrectly decoding APE file? [12:57:10 CET] <durandal_1707> JEEB: what version of APE? [12:57:39 CET] <durandal_1707> and how it decodes incorrecly? [12:57:58 CET] <JEEB> I haven't listened to it [12:58:05 CET] <JEEB> I just got a sample from an audio player dev [12:59:09 CET] <JEEB> having him test with latest master if possible first [12:59:16 CET] <JEEB> https://www.foobar2000.org/temp/Viande.ape is the sample [13:01:14 CET] <JEEB> was just tested with d227ed5d59 which is not too old of a master revision and it seems to still be borked there :) [13:02:55 CET] <faLUCE> I think that the line with "if ((ret = mjpeg_decode_app(s)) < 0) av_log(avctx, AV_LOG_ERROR, "unable to decode APP fields: %s\n", av_err2str(ret));" in mjpegdec.h is overkill in many cases. Currently lot of usb cameras have multiple APP fields with uncorrect length, so they raise continously this warning, which is ennoying... Since Ffmpeg 3.3.3 there was not this warning... would it be better to remove it? [13:03:09 CET] <faLUCE> (mjpegdec.c not, h) [13:03:40 CET] <faLUCE> at lease IMHO should be removed for APP = AVI1 [13:03:46 CET] <faLUCE> (at least) [13:06:00 CET] <faLUCE> in addition, MJPEG specs are very obscure. I only found an old doc, with google. So, there's no need to be so much strict with checkings... [16:26:12 CET] <cone-129> ffmpeg 03Michael Niedermayer 07master:38381400fca4: avformat/gdv: Check fps [16:26:12 CET] <cone-129> ffmpeg 03Michael Niedermayer 07master:9a9f0e239c1c: avcodec/cdgraphics: Use ff_set_dimensions() [16:26:12 CET] <cone-129> ffmpeg 03Michael Niedermayer 07master:a8c5ae451184: avcodec/dvbsubdec: Check object position [16:28:22 CET] <JEEB> seems like that stuff pops up every now and then due to android forcing PIC [16:37:06 CET] <J_Darnley> Does that mean android still only does 32bit? [16:38:59 CET] <nevcairiel> there is also x64 android [16:42:48 CET] <J_Darnley> Dude should upgrade his cpu to one from this decade then [16:59:41 CET] <Gramner> for some reason people really like using 32-bit x86 instead of 64-bit with android [17:00:50 CET] <gnafu> My recently purchased, current generation Fire TV Stick 4K appears to run 32-bit Android. As far as I can tell, it has a 64-bit processor; I just can't install 64-bit apps. [17:31:02 CET] <JEEB> yea they usually have 64bit kernel even [17:31:21 CET] <JEEB> except those that intel.missed the driver builds with [17:31:37 CET] <JEEB> those were thus limited to 32bit for the age of those devices [17:51:45 CET] <cone-129> ffmpeg 03Guo, Yejun 07release/4.1:9bf40978c657: configure: add missing pthreads extralibs dependency for libvpx-vp9 [17:51:46 CET] <cone-129> ffmpeg 03Guo, Yejun 07release/4.1:83bfd4f3b5b6: configure: use vpx_codec_vp8_dx/cx for libvpx-vp8 checking [17:51:47 CET] <cone-129> ffmpeg 03Michael Niedermayer 07release/4.1:5d208aac5253: avformat/gdv: Check fps [17:51:48 CET] <cone-129> ffmpeg 03Michael Niedermayer 07release/4.1:04ce4cc0728e: avcodec/cdgraphics: Use ff_set_dimensions() [17:51:49 CET] <cone-129> ffmpeg 03Michael Niedermayer 07release/4.1:8cee4190f368: avcodec/dvbsubdec: Check object position [17:51:50 CET] <cone-129> ffmpeg 03Michael Niedermayer 07release/4.1:77d244e7a937: Update for 4.1.2 [18:47:35 CET] <BtbN> tfw some "I get paid by Google and have an important 12h meeting with them tomorrow and need you to acknowledge the 1200 zero day exploits I found!!!" guy turns up right before your shift ends. [18:53:03 CET] <JEEB> ouch [19:44:29 CET] <cone-129> ffmpeg 03Diego Biurrun 07master:a70eac7a9b19: tests: Convert image2pipe tests to non-legacy test scripts [19:44:30 CET] <cone-129> ffmpeg 03Diego Biurrun 07master:eb8a81159944: tests: Convert audio-only lavf tests to non-legacy test scripts [19:44:31 CET] <cone-129> ffmpeg 03Diego Biurrun 07master:a957e9379d11: tests: Convert lavf image tests to non-legacy test scripts [19:44:32 CET] <cone-129> ffmpeg 03Diego Biurrun 07master:896fe15dbb7b: tests: Convert lavf pixfmt conversion tests to non-legacy test scripts [19:44:33 CET] <cone-129> ffmpeg 03Diego Biurrun 07master:618d02c1fa9e: tests: Convert lavf container tests to non-legacy test scripts [19:44:34 CET] <cone-129> ffmpeg 03Diego Biurrun 07master:f8df5e2f31a5: tests: Add a convenience function for video-only lavf tests [19:44:35 CET] <cone-129> ffmpeg 03James Almer 07master:d0c43e32427e: Merge commit 'a70eac7a9b193e8434b5bed90bd72aa4cb688363' [19:44:36 CET] <cone-129> ffmpeg 03James Almer 07master:29929fc8e244: Merge commit 'eb8a8115994434b548523cf0bca6a4a74784e79c' [19:44:37 CET] <cone-129> ffmpeg 03James Almer 07master:c2631dfd0a0a: Merge commit 'a957e9379d11f2982d615f92c30580a57ea8bb40' [19:44:38 CET] <cone-129> ffmpeg 03James Almer 07master:ace96d2e693d: Merge commit '896fe15dbb7b78de495c4a7dd75e7faec66778da' [19:44:39 CET] <cone-129> ffmpeg 03James Almer 07master:fda424b300c1: Merge commit '618d02c1fa9e74d490cace64a7d15762656b521c' [19:44:40 CET] <cone-129> ffmpeg 03James Almer 07master:a200bf8094bf: tests: Convert lavf container tests with samples to non-legacy test scripts [19:44:41 CET] <cone-129> ffmpeg 03James Almer 07master:ac4b5d862220: Merge commit 'f8df5e2f31a5ba7b30a0e1caaaf5a03c753b3f9b' [19:46:28 CET] <jamrial> those took a while. the build system has deviated quite a bit by now [19:53:56 CET] <cone-129> ffmpeg 03Luca Barbato 07master:899ee03088d5: Unbreak travis on macos [19:53:57 CET] <cone-129> ffmpeg 03James Almer 07master:ecb5546e97c4: Merge commit '899ee03088d55152a48830df0899887f055da1de' [20:12:10 CET] <cone-129> ffmpeg 03Magnus Röös 07master:0801853e6406: libavcodec: vp8 neon optimizations for aarch64 [20:12:11 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:26d7af4c381e: aarch64: vp8: Fix assembling with clang [20:12:12 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:2eeac79936e8: aarch64: vp8: Fix assembling with armasm64 [20:12:13 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:85bfaa4949f4: aarch64: vp8: Use the proper aarch64 form for conditional branches [20:12:14 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:ad32f7b1264d: aarch64: vp8: Remove superfluous includes [20:12:15 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:b4b27dce95a6: aarch64: vp8: Move the vp8dsp makefile entries to the right places [20:12:16 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:f1011ea28a40: aarch64: vp8: Reorder the function pointer inits to match the arm original [20:12:17 CET] <cone-129> ffmpeg 03James Almer 07master:a2ae381b5a6f: Merge commit '0801853e640624537db386727b36fa97aa6258e7' [20:12:18 CET] <cone-129> ffmpeg 03James Almer 07master:94346ab593f3: Merge commit '2eeac79936e83c4495cbe5905064ab797e9b45ff' [20:12:19 CET] <cone-129> ffmpeg 03James Almer 07master:398000abcf98: Merge commit '85bfaa4949f4afcde19061def3e8a18988964858' [20:12:20 CET] <cone-129> ffmpeg 03James Almer 07master:b8eb0827f053: Merge commit 'b4b27dce95a6d40bfcd78043d3abec7d80dae143' [20:12:21 CET] <cone-129> ffmpeg 03James Almer 07master:4f9a8d3fe2f9: Merge commit 'f1011ea28a4048ddec97794ca3e9901474fe055f' [20:16:14 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:c513fcd7d235: aarch64: vp8: Fix a typo in a comment [20:16:14 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:52c9b0a6c0d0: aarch64: vp8: Port vp8_luma_dc_wht and vp8_idct_dc_add4uv from arm version [20:16:15 CET] <cone-129> ffmpeg 03James Almer 07master:39278ff0de5b: Merge commit 'c513fcd7d235aa4cef45a6c3125bd4dcc03bf276' [20:16:17 CET] <cone-129> ffmpeg 03James Almer 07master:79025da3f2e7: Merge commit '52c9b0a6c0d02cff6caebcf6989e565e05b55200' [20:17:15 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:cc7ba00c35fa: aarch64: vp8: Port missing epel8 functions from arm version [20:17:16 CET] <cone-129> ffmpeg 03James Almer 07master:c6892f59eb0e: Merge commit 'cc7ba00c35faf0478f1f56215e926f70ccb31282' [20:18:26 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:58d154922707: aarch64: vp8: Port epel4 functions from arm version [20:18:27 CET] <cone-129> ffmpeg 03James Almer 07master:2ac399d7faa5: Merge commit '58d154922707bfeb873cb3a7476e0f94b17463dd' [20:19:03 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:e39a9212ab37: aarch64: vp8: Port bilin functions from arm version [20:19:04 CET] <cone-129> ffmpeg 03James Almer 07master:34a0a9746b2f: Merge commit 'e39a9212ab37a55b346801c77487d8a47b6f9fe2' [20:21:33 CET] <dominiques> Hello please, can you HELP me... i really need solve using ffmpeg cutting exactly 00:04:00 second audio fragments ... i need cut ideally aac or wav, for example, i have 60 second audio file, and i need to cut them to exactly 15*4sec audio fragments i am using for example ffmpeg -i $DIR_TMP/"${file%.mp4}.wav" -segment_time 4 -f segment $DIR_TMP/"${file%.mp4}%03d.wav" [20:22:00 CET] <dominiques> please PM to me [20:22:33 CET] <J_Darnley> With uncompressed you should be able to cut to *exactly* 15 seconds [20:22:58 CET] <J_Darnley> with aac youre gonna have to hope and pray to the frequency transform gods [20:23:34 CET] <J_Darnley> oh sorry, 4 seconds [20:24:11 CET] <J_Darnley> Also this isnt the tech support channel [20:24:12 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:cef914e08310: arm: vp8: Optimize put_epel16_h6v6 with vp8_epel8_v6_y2 [20:24:13 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:37394ef01b04: aarch64: vp8: Optimize put_epel16_h6v6 with vp8_epel8_v6_y2 [20:24:14 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:49f9c4272c40: aarch64: vp8: Skip saturating in shrn in ff_vp8_idct_add_neon [20:24:15 CET] <cone-129> ffmpeg 03Martin Storsjö 07master:7e42d5f0ab2a: aarch64: vp8: Optimize vp8_idct_add_neon for aarch64 [20:24:16 CET] <cone-129> ffmpeg 03James Almer 07master:d6b62ce1aced: Merge commit 'cef914e08310166112ac09567e66452a7679bfc8' [20:24:17 CET] <cone-129> ffmpeg 03James Almer 07master:fbd607dd560a: Merge commit '37394ef01b040605f8e1c98e73aa12b1c0bcba07' [20:24:18 CET] <cone-129> ffmpeg 03James Almer 07master:409e684e79b6: Merge commit '49f9c4272c4029b57ff300d908ba03c6332fc9c4' [20:24:19 CET] <cone-129> ffmpeg 03James Almer 07master:5c363d3e595a: Merge commit '7e42d5f0ab2aeac811fd01e122627c9198b13f01' [20:32:39 CET] <cone-129> ffmpeg 03Janne Grunau 07master:186bd30aa3b6: h264/arm64: implement missing 4:2:2 chroma loop filter neon functions [20:32:40 CET] <cone-129> ffmpeg 03Janne Grunau 07master:f8abf7d4dfa0: checkasm/h264: test 4:2:2 chroma loop filter functions [20:32:41 CET] <cone-129> ffmpeg 03James Almer 07master:92219ef4ac01: Merge commit '186bd30aa3b6c2b29b4dbf18278700b572068b1e' [20:32:42 CET] <cone-129> ffmpeg 03James Almer 07master:0dda0f3bdb7e: Merge commit 'f8abf7d4dfa0504f7f65e4f1fd9d22e01cb371cc' [21:17:12 CET] <dominiques> I CAN PAY FOR YOUR HELP ! REALLY NEED SOLVE THIS .. PLEASE CHECK https://codeshare.io/aVnze3 [21:17:51 CET] <cone-129> ffmpeg 03James Almer 07master:85649b6523a6: fate/lavf-image: fix passed arguments for some high bit depth tests [21:36:57 CET] <J_Darnley> another damn pastebin that requires javascript [23:11:51 CET] <uau> qtrle now has code like this: [23:11:54 CET] <uau> AV_WN16A(rgb + pixel_ptr, rg); [23:11:54 CET] <uau> rgb[pixel_ptr + 2] = b; [23:11:54 CET] <uau> pixel_ptr += 3; [23:12:23 CET] <uau> that combination of AV_WN16A and ptr+=3 looks very suspicious [23:12:44 CET] Action: JEEB double-blinks [23:16:27 CET] <jamrial> uau: i mentioned a qtrle fate failure introduced by that to the author of that code [23:19:51 CET] <atomnuker> uau: its rgb so 24 bits, we don't have writes by 24 bits so it looks okay [23:24:23 CET] <uau> atomnuker: what do you mean? [23:25:47 CET] <uau> to clarify, that code looks like it'd violate alignment, and i don't see how your comment would say it doesn't [23:29:00 CET] <atomnuker> alignment? [23:29:49 CET] <uau> yes, as in the 'A' at the end of 'AV_WN16A' [23:31:51 CET] <atomnuker> right, forgot about that [00:00:00 CET] --- Fri Mar 15 2019

1 0

ffmpeg.log.20190314
by burek 15 Mar '19

15 Mar '19

[03:40:44 CET] <ossifrage> Should I be able to call avformat_write_header() .. av_write_trailer() multiple times without tearing down the AVFormatContext? [03:41:32 CET] <ossifrage> I thought I had things working with non-seekable files, but when I started trying to write out multiple segments I got: muxer does not support non seekable output [03:52:42 CET] <ossifrage> yeah, av_write_trailer() clobbers all my streams :( [04:35:15 CET] <c0nundrum> hello [04:35:48 CET] <c0nundrum> Anyone know what causes ffmpeg to trigger a chmod on the output file / [04:45:03 CET] <darthshort> trying to build HandBrake-1.2.2 on Centos 7 and getting the error "opus not found using pkg-config" when running make [04:45:36 CET] <darthshort> the opus package is installed as well as opus-devel [05:55:19 CET] <ossifrage> Huh, setting "movflags" to "frag_every_frame+dash+delay_moov+skip_sidx+skip_trailer" causes a parse error [05:55:32 CET] <ossifrage> Undefined constant or missing '(' in 'skip_sidx' [05:55:40 CET] <ossifrage> Unable to parse option value "skip_sidx+skip_trailer" [05:56:08 CET] <ossifrage> I pulled those settings from libavformat/dashenc.c [07:16:08 CET] <ross`> Hey, Can someone tell me why -vn might not strip audio of an mp4 file but also not fail with an error? [07:16:38 CET] <ross`> ffmpeg -vn -i video.mp4 -o foo.mp4 [07:17:25 CET] <pink_mist> why would -vn strip audio? -vn should strip video... [07:17:31 CET] <ross`> er strip video* [07:17:37 CET] <ross`> Ya, I meant video [07:18:28 CET] <pink_mist> perhaps you need to put it after the -i video.mp4 [07:20:09 CET] <ross`> pink_mist: <3 [07:20:10 CET] <ross`> Thanks! [09:36:45 CET] <StudentSA> Hi! I have a use case where I need to run two separate ffmpeg process (one for streaming and one for recording) from a UDP mp3 stream source. when running the second ffmpeg process I get error "bind failed: Address already in use". Is it not possible for multiple consumers to use the same UDP port? [09:37:44 CET] <StudentSA> I found that this can be done in a single ffmpeg process, but I want to decouple the two actions. any help is appreciated [10:55:26 CET] <LigH> Hi. [10:55:31 CET] <JEEB> ohai [10:56:47 CET] <LigH> I stumbled upon a recent patch for x264 removing a compatibility change for 4:4:4 CABAC. This may affect ffmpeg before June/July 2017. Can you tell me a version milestone of this time? I believe it was before v4? [10:57:25 CET] <JEEB> yea, that's quite old. check the search on git.videolan.org's ffmpeg repo [10:57:51 CET] <JEEB> probably 840b41b2a643fc8f0617c0370125a19c02c6b586 [10:58:39 CET] <JEEB> which was committed into the repo 2017-06-19 [10:59:02 CET] <JEEB> 3.4 does have that change as far as I can tell [10:59:19 CET] <JEEB> (and it might have been back-ported to other things) [11:00:32 CET] <LigH> Yes, in the "tags" list, the release of v3.4 was 16 months ago, that should just be past. [11:00:49 CET] <LigH> Thank you, bye... [11:01:09 CET] <JEEB> gitk f.ex. can nicely show what tags etc a thing precedes and follows [11:08:00 CET] <santigaite> FFmpeg suports UHD HDR ? keeps 10bit color space ? [11:10:00 CET] <JEEB> HEVC/AVC/VP9 decoders support 10bit just fine and if the colorspace/transfer function can be read and is in the AVFrames, the question is mostly what you want to do with it [11:36:30 CET] <justinasvd> JEEB: Remember the question what to do if avio blocks on another thread? Said to implement asynchronous AVIO. [11:37:07 CET] <justinasvd> I tried to do that (and several other things). In the end, pthread_cancel was the most robust and elegant solution. [11:38:35 CET] <justinasvd> If the thread blocks on IO, the easiest way to kill it is via thread cancellation. [11:56:43 CET] <sazawal> BtbN, Hi. Now I have used "ffmpeg -i input.mkv -acodec copy -f segment -vcodec copy -map 0 clip%d.mkv" to split the video at every keyframe, without reset_timestamps option. But when I obtain frames from the clip using "ffmpeg -vsync 0 -i clip1.mkv -vf "showinfo" frame%04d.png -hide_banner >& output.txt", I am not getting the original timestamps of the frame in output.txt. The pts_time timestamps are relative to each clip. How do [11:56:43 CET] <sazawal> I get the original timestamps of the frame? [12:00:36 CET] <JEEB> justinasvd: I would guess so [12:00:43 CET] <JEEB> (haven't given it too much thought) [12:01:11 CET] <JEEB> I know that the UDP protocol internally implements stuff in a separate thread and feeds it forwards as requested by the non-async API [12:12:47 CET] <ringo_> hello [14:45:39 CET] <santigaite> JEEB, recode/compress [15:10:22 CET] <iTommix> Hello. I have read many about usage of ffmpeg and tried many things without success. maybe someone can point me to a solution: What i want is to transcode and stream a RTP (its a TV program stream, like rtp://@239.35.10.1:10000) that i can pause and rewind that stream. is it possible? [15:52:26 CET] <ncouloute> Is there a way with ffprobe and ffmpeg to get the timestamp of a particular frame. I know with ffprobe you can get every frames timestamp, but that takes longer than I would like. I want to just seek to a frame then get its time stamp. If not maybe suggest another 3rd party cmdline util? [15:53:27 CET] <kepstin> ncouloute: you can't seek to a frame by number, file formats don't index that information [15:53:38 CET] <kepstin> (and you can't seek to a time and find the frame number either) [15:54:32 CET] <JEEB> for mp4 l-smash's boxdumper can give you the timestamps of samples, and for matroska I think mkvinfo can do it. those might or might not be faster than ffprobe -of json -show_packets FILE [15:54:32 CET] <kepstin> ncouloute: the only way to match up frame time & frame number is to read every frame from the start of the file. iirc, there is a library that does this and builds an index which you can use [15:54:46 CET] <JEEB> and yes, if you are OK with indexing once, then ffms2 [15:54:56 CET] <perseiver> ncouloute: while using ffmpeg to convert the video to another format. (like from wav to mp4 ).. You will see Frame number on left.. and timestamp in 2nd Column from right.. This might help you to look into frame number and its timestamp [15:54:57 CET] <JEEB> that is less format specific [15:55:05 CET] <ncouloute> I should specify that I'm dealing with h264 mp4s [15:55:28 CET] <JEEB> MP4s as long as they have a full index should be quick to check. possibly even ffprobe -show_packets should be quick? [15:56:06 CET] <kepstin> well, -show_packets runs through the full demuxer, it'll be disk speed limited [15:56:57 CET] <perseiver> for example: when I run command. ffmpeg -i videofilename outputfilename.. then I got [15:57:00 CET] <perseiver> frame= 838 fps=170 q=-1.0 Lsize= 986kB time=00:00:33.38 bitrate= 241.9kbits [15:57:08 CET] <perseiver> Here you got frame number and timestamp [15:57:18 CET] <perseiver> so you can guess timestamp and frame... [15:57:40 CET] <kepstin> yes, you can record this information while you encode the file - but that doesn't help if you have existing already encoded files. [15:58:47 CET] <perseiver> Yes, I know, but you can output the file to temp directory... As main intention is to know the frame with timestamp [15:59:16 CET] <ncouloute> in my case I am trying to find a particular frame in the original file after I encode it. So that approach may work. Although is that the frame and timestamp for the encoded file? [15:59:16 CET] <kepstin> if you just want the frame with timestamp, it would be a lot faster to use ffprobe -show_packets instead of doing a full re-encode :) [16:00:07 CET] <ncouloute> Basically I have a list of frames numbers. IN and OUT points.. and I need to get the new frame number location [16:01:13 CET] <kepstin> ncouloute: I think ffmpeg prints that message using frame numbers and timestamps of frames being sent to the encoder - but i'm not totally sure. It's possible the muxer might make additional changes to the timestamps (although unlikely in most cases). And that output is rate-limited and thus missing frames. [16:02:31 CET] <ncouloute> This will be almost always going from lower fps to higher fps. So I shouldnt lose many frames for example 30->60. [16:04:41 CET] <kepstin> if you want to log this information while encoding... maybe use a filter to do it? the "showinfo" filter should output all the info you want [16:04:59 CET] <kepstin> i thought there was a filter that generated an mkvmerge-style timestamps file, but I can't find it now. [16:05:53 CET] <kepstin> although note that the filter chain is possibly running at a different timebase from the encoder/muxer [16:12:42 CET] <ncouloute> I guess I have to see what info that is giving me. I'm assuming its the info about the original file. I've seen resources online about being able to write the original timestamp and/or frame number on the resulting file. Not quite what I want I need it just in text form. My intial thoughts was to index both the try and find that same timestamp in the resulting file. But that is bond to be inaccurate. I guess I need to [16:12:42 CET] <ncouloute> look into showinfo and go from there. [16:15:23 CET] <ncouloute> so it looks like showinfo will give me lots of info about the input file. That would save me from having to index the original file but I would still have to index the resulting file. =/ [16:15:47 CET] <kepstin> showinfo logs stuff at the point where you insert the filter in the filter chain [16:15:57 CET] <kepstin> so if you put it after the fps filter... [16:16:39 CET] <kepstin> (although that won't really tell you much, the fps filter always generates "perfect" timestamps, counting up by exactly 1 each frame in the specified timebase) [16:22:08 CET] <kepstin> fwiw, if your video has a framerate that's exactly representable in mp4 (most integer rates are? ntsc rates aren't iirc), then the pts values from the fps filter will be saved into the file without modification, so you can calculate the time of each frame exactly. [16:22:22 CET] <JEEB> that's matroska [16:22:50 CET] <JEEB> mp4 you can have 1001/24000 time base and then each sample has +1 PTS [16:22:53 CET] <kepstin> ffmpeg's matroska muxer converts everything to 1/1000 timebase, so basically nothing is stored exactly [16:23:10 CET] <kepstin> weird, when i tried to make a 1001/24000 file, ffmpeg actually made it 1/24000 [16:23:19 CET] <kepstin> (in mp4) [16:24:40 CET] <JEEB> movenc.c has some weird stuff, although generally it should only ² your time base or so until it's "large enough" [16:25:14 CET] <JEEB> I don't remember it ever making the output time base worse [16:25:16 CET] <kepstin> and I though nut stored timebases exactly, but my 1001/24000 video got stored as 1/48000!? [16:25:43 CET] <JEEB> I should probably try and make an API usage test for the MP4 case and see wtf one gets out of it [16:25:57 CET] <JEEB> since movenc.c already has an API usage based test [16:26:40 CET] <kepstin> yeah, I just did a simple test using fps filter to get some exact timestamps and timebase, and it gets messed up when muxed. hmm. this system has ffmpeg 4.0.3 tho, i should check other versions [16:28:34 CET] <kepstin> but yeah, if mp4 is capable of storing ntsc timebase exactly, we really should be doing that :) [16:29:23 CET] <ncouloute> So I'm thinking my best bet is to index each file get the timestamps then find the same timestamp in the resulting file. Those are very slow operations though. I was hoping ffmpeg or maybe the fps filter could output the frame mapping somehow. I think you are saying use show info twice once before fps filter and then after the fps filter? [16:32:25 CET] <JEEB> kepstin: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;h=77943… [16:32:39 CET] <JEEB> that's the only thing I know of where we're poking at the time base [16:32:44 CET] <faLUCE> how can I list the supported samplerates for opus? [16:32:52 CET] <kepstin> faLUCE: 48000 [16:32:53 CET] <kepstin> done [16:33:15 CET] <another> ffmpeg -h encoder=libopus [16:33:23 CET] <another> ffmpeg -h encoder=opus [16:33:49 CET] <kepstin> (libopus technically has an internal resampler, and accepts other sample rates too, converting them itself) [16:33:54 CET] <faLUCE> tnx [16:35:33 CET] <another> (yes, but ffmpeg only knows about 48k and therefore resamples) [16:36:00 CET] <another> oh. i was wrong [16:37:11 CET] <another> seems like ffmpeg only resamples if the sample rate does not match opus' native rates [16:40:27 CET] <kepstin> the ffmpeg libopus wrapper allows a few different sample rates, yeah. it does signal it to the libopus encoder, and in theory libopus might use that to make some decisions on which encoding modes to use? [16:43:10 CET] <kepstin> presumably sending it 48Khz and setting the -cutoff option lower does the same thing. [16:51:53 CET] <ncouloute> I see that there is a select filter. Doesn't that seek to a certain frame or does it actually decode until it gets to that point? [16:52:05 CET] <kepstin> ncouloute: filters can't seek [16:52:47 CET] <kepstin> (filters like trim and select work by discarding unwanted frames in the filterchain, so after they're decoded) [16:54:34 CET] <ncouloute> gotcha so I think I'm pretty much going to have to index each file then. Unless -r or fps filter can output some debug information about where each frame ends up. [16:56:44 CET] <TheAMM> If you want all the timestamps, ffmpeg -i file.mkv -vsync 0 -f mkvtimestamp_v2 timestamps.txt [16:57:05 CET] <TheAMM> (or ffprobe -show_frames and parsing the output) [16:57:28 CET] <TheAMM> but both of these do mean decoding the stream (as far as I know) [16:57:33 CET] <ncouloute> I just want the timestamps of particular frames but it doesnt seem like I can do that without running through the entire file. [16:57:48 CET] <ncouloute> maybe i can make the ffprobe line faster somehow [16:58:04 CET] <kepstin> oh, the mkvmerge timestamp think is a muxer? right. [16:58:21 CET] <kepstin> you could probably do two outputs when encoding the file - one to the mp4, one to the timestamp muxer [16:58:39 CET] <kepstin> be tricky to set up since you'd need to use the tee muxer, but theoretically doable [16:59:14 CET] <kepstin> ncouloute: the ffprobe command with -show_streams -show_packets should run as fast as it can read the file from disk, since it's not doing any decoding. [16:59:19 CET] <TheAMM> ffprobe -i file.mkv -select_streams 0:v -show_frames -show_entries frame=pkt_pts_time -of csv=p=0 [16:59:55 CET] <ncouloute> that brings up a good point. I should be using pkts_pts_time instead of the best_effort_timestamp_time? [16:59:56 CET] <TheAMM> That's the fastest way to get (just) timestamps for all frames [17:00:02 CET] <ncouloute> gotcha [17:00:13 CET] <TheAMM> At least from my testing from a few months ago [17:00:43 CET] <TheAMM> I don't use it though, since for my thing I needed the image data as well [17:01:02 CET] <TheAMM> So I wrote a NUT demuxer, getting the timestamp and actual frame data [17:01:23 CET] <TheAMM> But it's a bit faster than mkvtimestamps_v2 [17:01:40 CET] <TheAMM> Like, couple of seconds faster on a 20-minute file [17:01:53 CET] <TheAMM> on this speciic file, on this specific hardware, etc [17:03:11 CET] <kepstin> but if you're encoding the file in the first place, writing the mkvtimestamps in the same command while encoding should be faster. [17:04:19 CET] <kepstin> something like ... -f tee "[f=mkvtimestamp_v2]timestamps.txt|output.mp4" [17:30:48 CET] <esx2ve> Hey guys. I'm in dire need of advice / guidance. Long story short, due to a stupid bug in our production pipeline, we 'concat'd' an HEVC file with an x264 file. Obviously when playing the joined .mov file, everything that comes from the x264 is read as corrupted (Invalid NAL unit size). Is there a way to extract the original video fragments? [17:31:48 CET] <durandal_1707> you concated 2 movs into 1 mov? [17:32:15 CET] <durandal_1707> also is there audio or only video? [17:32:48 CET] <esx2ve> only video [17:32:56 CET] <esx2ve> it's working perfectly when the codecs match [17:33:34 CET] <kepstin> esx2ve: depending exactly what happened, you might need a custom tool that parses the packets and tries to figure out whether it's h264 or hevc :/ [17:34:02 CET] <kepstin> also you might be missing some initialization data required for the hevc data to be playable depending how it was muxed [17:34:28 CET] <faLUCE> do you know in which cases libopus can output this warning? "[libopus @ 0x558cd0bf15c0] Queue input is backward in time" [17:36:13 CET] <esx2ve> Thanks @kepstin! [17:36:31 CET] <esx2ve> Maybe go about it like this - force ffmpeg to use a certain codec to decode? Is it possible? [17:36:38 CET] <kepstin> faLUCE: iirc, that means timestamps on the input frames don't match the length of audio in the frames - like, you have a frame with 20ms of audio, but the timestamp of the next frame is only 15ms later. [17:37:23 CET] <JEEB> or just going bsckwards in genersl [17:38:46 CET] <faLUCE> uhmmmm [17:40:00 CET] <kepstin> esx2ve: it sounds like you want to copy the data, not decode it? but yeah, you can try "-c:v hevc" as an input option (before the input file). no idea if it'll work, it might not be able to find the initialization data needed, and it'll definitely report errors on the h264 packets. you might be able to seek to near where the hevc starts and get better results. [17:40:51 CET] <ossifrage> So my make fragmented mp4 files and then cat them back together in the server thing works on chrome/linux but not on chrome/ios :-( [17:41:21 CET] <kepstin> tbh, i'm surprised it works in native chrome [17:41:44 CET] <ossifrage> Yeah I just use the url: http://192.168.100.100/video.mp4 and it plays [17:41:50 CET] <kepstin> but yeah, chrome on ios isn't chrome, it's just a webview (webkit) wrapper, so it can't really do anything safari can't do. [17:41:58 CET] <esx2ve> kepstin, thank you very much! we tried to force the codec using -f and it got the frames we needed [17:42:06 CET] <ossifrage> Yup, it also doesn't work in safari [17:42:52 CET] <ossifrage> You get the play button with a line through it, and it seems the console is missing on ios now, you need to do the USB debug thing, which requires a mac [17:44:20 CET] <ossifrage> Any ideas how to generate fmp4 that ios can decode, it is not the raw h.264, ios will decode that just fine [17:44:22 CET] <kepstin> yeah, we picked up a new mac mini at my office for testing mac os x and ios stuff. If you need to support macs, you need to give apple money :/ [17:44:27 CET] <ossifrage> (if I use ffmpeg to make a mp4 file) [17:44:54 CET] <kepstin> ossifrage: as far as i know, ios doesn't support fragmented mp4. remux it into normal mp4. [17:45:18 CET] <kepstin> although what i know might be obsolete :) [17:46:02 CET] <ossifrage> hls supports fragmented mp4, I thought that would mean ios could play a file with fragments :-( [17:46:37 CET] <ossifrage> kepstin, I can't remux it into normal mp4 because I'm trying to do live playback [17:46:41 CET] <kepstin> nah, hls stuff is distinct from the standalone file playback for who knows what reason [17:48:13 CET] <kepstin> if you want live streaming to ios devices, you need to use hls. [17:48:32 CET] <ossifrage> Hmm, now I need to come up with another way to do live streaming (without js if possible) to chrome/safari/firefox [17:48:45 CET] <kepstin> (i'm unsure about whether dash works in ios yet) [17:48:56 CET] <kepstin> dash works in other browsers, and iirc can use the same encoded media files [17:51:07 CET] <faLUCE> kepstin: in case of opus I encode a pkt with a size = avframe->linesize[0]. Then it could be that the size is wrong, if I get all that warnings? The audio results a bit choppy [17:52:04 CET] <ossifrage> I was trying to do something that would work for both live and archived playback. I write the fragments to tmpfs and then selectively archive the interesting bits for later playback [17:52:16 CET] <faLUCE> (I use the same value for aac and mp2, and don't have problems...) [17:53:09 CET] <ossifrage> I'm working on an opensource security camera firmware replacement project [17:54:22 CET] <kepstin> ossifrage: if you have the fragments as separate files on tmpfs, then it shouldn't be hard to have a dash manifest and hls playlist referencing those fragments, then just statically serve up a dash js player for non-ios browsers. [17:54:46 CET] <kepstin> faLUCE: are your pts values set right? [17:55:02 CET] <faLUCE> kepstin: yes, just checked [17:55:35 CET] <kepstin> (iirc, you usually want to use inverted sample rate for audio timebase, then the pts is just the sample number of the first sample in the frame) [17:55:50 CET] <ossifrage> The whole point of using dash was I thought it was implemented natively in chrome, grrr... [17:56:42 CET] <kepstin> hls is natively supported in safari (it basically just loads an os level player for it), and every other browser needs JS for fragmented live streaming. [17:59:49 CET] <ossifrage> Kinda sad that I can't get the same result I get with raw h.264 over ssh, 500ms latency and it just works [18:01:52 CET] <kepstin> if you want really low latency streaming to browsers, the only way is webrtc - and *that* is a pain to get working :) [18:02:57 CET] <kepstin> it's not just rtp, there's required dtls encryption and ice that make it tricky to get right and interoperable. [18:03:04 CET] <ossifrage> (I wanted low latency and no javascript, just native html5 video, didn't seem like too much to ask for) [18:03:17 CET] <kepstin> nah, way too much to ask for [18:03:46 CET] <kepstin> live native html5 video is only possible on a limited number of browsers that natively play hls [18:03:52 CET] <kepstin> every other browser needs javascript. [18:03:56 CET] <kepstin> and low latency is right out. [18:04:43 CET] <kepstin> (well, some browsers don't break if you feed them live-generated streams in certain specific formats, but that's more of a quirk than anything imo) [18:06:48 CET] <ossifrage> It was a simpler time when you could do moderately low latency multicast video on the local network with very little pain, now things have gotten more complex and much higher latency [18:07:59 CET] <kepstin> i mean, you can still do that if you can convince people to install a player app on their local systems [18:08:10 CET] <kepstin> it's only this reliance on doing everything in a web browser that makes it hard [18:08:11 CET] <Mavrik> or use webrtc :) [18:08:30 CET] <kepstin> webrtc can't multicast due to the encryption requirements [18:09:02 CET] <Mavrik> I've seen most solutions walk away from multicast anyway [18:09:05 CET] <ossifrage> Yeah, I really don't want to do anything with multicast video. But back when I was it generally worked fairly well [18:09:28 CET] <kepstin> the main issue is that multicast over the internet basically isn't usable, yeah. [18:09:41 CET] <Mavrik> mhm [18:09:54 CET] <kepstin> but even unicast udp over modern internet is a pain due to stateful firewalls and nat :/ [18:09:57 CET] <Mavrik> Even live tv providers I've worked with moved away from multicast on their networks due to people using mobile devices :) [18:10:07 CET] <ossifrage> The multicast video stuff I was doing in the past was purely to save compute costs in the device sending the video [18:10:43 CET] <ossifrage> It just didn't have the compute/network budget to send multiple copies of the data, so you multicasted out one stream and multiple clients could watch it (on the local network) [18:11:09 CET] <Mavrik> also multicast tends to greatly trash wifi networks :) [18:11:16 CET] <ossifrage> So you could stick a camera on the end of a longish haul wifi link and still have multiple people watch it [18:11:29 CET] <kepstin> falls back to broadcast at base rate iirc? yeah :) [18:11:55 CET] <ossifrage> Yeah you do need all the igmp stuff working in the network [18:12:10 CET] <faLUCE> kepstin: you were right, it was a mismatch between the time calculated on the framesize and the pts. [18:12:47 CET] <ossifrage> If the multicast traffic leaks into the wrong places then it does fall apart quite nicely [18:14:04 CET] <kepstin> faLUCE: yep. that message is printed based on a simple sanity check on the input timestamps and framelengths. [18:14:35 CET] <ossifrage> For this project I have enough encoder channnels that I can produce a set of streams hi/medium/low/potato/mjpeg without much effort [18:15:37 CET] <ossifrage> So I thought that DASH would be a good fit for what I can already encode [18:15:41 CET] <kepstin> faLUCE: the message is printed by a generic queue that's used to re-frame the samples to the right packet size for the codec. [18:17:08 CET] <kepstin> ossifrage: it is, particularly if you want to support stuff like dynamic quality switching based on bandwidth. but it does require js in the player, which isn't normally a problem. [18:17:37 CET] <retal> Hi guys, where i can found working guide about how to buld ffmpeg with nvenc support for ubuntu 18 [18:17:39 CET] <kepstin> since the way dash is implemented in the browser is that the javascript builds a continuous stream which is fed to the browser player through the "media source extensions" [18:17:55 CET] <ossifrage> kepstin, yeah I don't mind that. But I assumed there was a solution to do the simple single live stream playback without any js [18:18:39 CET] <kepstin> ossifrage: it shouldn't be a big deal? you just need to grab a dash player js file and server it statically along with your player html page. [18:20:23 CET] <ossifrage> I just was hoping to do the simple thing first so I could go back to working on what I actually care about and then come back to the video streaming stuff later [18:24:59 CET] <kepstin> retal: your easiest bet is to probably just grab a static ffmpeg build of 4.1 - there's some linked off the ffmpeg site, including ubuntu packages - most should have nvenc support. building it yourself isn't that hard, just need to make sure you have the ffmpeg "nv-codec-headers" installed before building. [18:25:56 CET] <retal> kepstin, thank you ! [18:28:20 CET] <kepstin> retal: regarding nv-codec-headers - that's from this git repo: https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary - if those are installed correctly, ffmpeg's configure script will automatically enable nvenc support (you can check by adding --enable-nvenc to the ffmpeg configure command line, then it'll error out if it can't find them) [18:29:56 CET] <retal> kepstin, why i need headers, if i download static build ? [18:30:09 CET] <kepstin> retal: that's only if you build it yourself [18:32:46 CET] <retal> kepstin, oh yea. I first will try with static build (wor saving time) for testing my nvidia, then will try build from sources , thank you [18:37:11 CET] <retal> kepstin, i just downloaded ffmpeg version 4.1.1-static, and try: ./ffmpeg -codecs | grep nvenc, looks loke there no nvrenc support in static buld [18:58:31 CET] <sazawal> Hi. I have used "ffmpeg -i input.mkv -acodec copy -f segment -vcodec copy -map 0 clip%d.mkv" to split the video at every keyframe. I obtained frames from the each of clips using "ffmpeg -vsync 0 -i clip1.mkv -vf "showinfo" frame%04d.png -hide_banner >& output.txt". How do I get the timestamps of the frames as it was in the original video? [19:06:10 CET] <ossifrage> Ouch, my ffmpeg code has a memory leak that was bad enough to panic the machine, ouch [19:19:16 CET] <kepstin> sazawal: you can't, there's not enough information to do that. You'd have to record the frame timestamps of the original video before splitting. [19:24:42 CET] <sazawal> kepstin, Yes I was expecting this. Can I record the information of the timestamps when I am splitting the original to clips? So for example, the second keyframe is at 00:00:10 and the particular frame is at 00:00:02 in the second clip, then the original timestamp of the video must be 00:00:12. [19:25:22 CET] <sazawal> original timestamp of the frame must be 00:00:12* [19:25:54 CET] <kepstin> sazawal: i'd just do the same thing you're doing with showinfo when you're doing the command that splits into segments, then you should be able to reference by counting frames. [19:27:39 CET] <sazawal> kepstin, Actually I did redirect the output of the first command (when I split the original into clips) to a text file. I am not sure which variable in the output has this timestamp information. [19:28:15 CET] <kepstin> sazawal: you didn't add any options to the first command that would cause it to record that information. [19:28:42 CET] <sazawal> kepstin, I see. Please tell me which are these options. [19:29:01 CET] <kepstin> <kepstin> sazawal: i'd just do the same thing you're doing with showinfo when you're doing the command that splits into segments, then you should be able to reference by counting frames. [19:29:25 CET] <sazawal> kepstin, Ohh. Let me quickly check it. [19:41:41 CET] <faLUCE> now, I don't understand exactly the size that I have to use for each packet to encode with opus. Normally, I set this size = avframe->linesize[0], but for libopus there's the "frame_duration" option, which is set to 20 as default. Then, I should use a size that corresponds to this duration... but how to calculate it? [19:48:02 CET] <sazawal> kepstin, It is not working with -vf "showinfo" option. It says, "Filtergraph 'showinfo' was defined for video output stream 0:0 but codec copy was selected. [19:48:02 CET] <sazawal> Filtering and streamcopy cannot be used together." [19:48:16 CET] <kepstin> ah, right. [19:53:10 CET] <sazawal> kepstin, Is there another way to get these timestamps? Maybe I can get all the keyframe timestamps before splitting it into clips. The keyframe timestamps must be the timestamps where the splitting is taking place. [20:19:39 CET] <dominiques> hello [20:19:50 CET] <dominiques> Hello please, can you HELP me... i really need solve using ffmpeg cutting exactly 00:04:00 second audio fragments ... i need cut ideally aac or wav, for example, i have 60 second audio file, and i need to cut them to exactly 15*4sec audio fragments i am using for example ffmpeg -i $DIR_TMP/"${file%.mp4}.wav" -segment_time 4 -f segment $DIR_TMP/"${file%.mp4}%03d.wav" [20:22:08 CET] <dominiques> please PM to me [20:28:36 CET] <retal> I am trying use nvenc coder ffmpeg -i video.mp4 -vcodec h264_nvenc -b:v 5M -acodec copy out.mp4 [20:28:36 CET] <retal> But it can utilize videocard only for ~20%, how i can increase utilization? [20:29:10 CET] <kepstin> retal: how are you measuring utilization? [20:29:36 CET] <kepstin> there's some cases where you might be bottlenecked by the decoder or memory transfers - using hardware decoder might help [20:30:05 CET] <retal> nvidia-smi [20:30:57 CET] <retal> how to use hardvare decoder in my case ? [20:31:03 CET] <kepstin> note that the hardware encoder is a specific functional unit - it can be used 100% independently of gpu compute resources. [20:31:44 CET] <kepstin> retal: see the nvdec section of https://trac.ffmpeg.org/wiki/HWAccelIntro [20:32:07 CET] <arthuralbano2> hello world [20:33:30 CET] <arthuralbano2> Hi people! I wanted to generate a single image from a mp4 video, so I can filter everything that is moving and leave one single image of the background. Perhaps using median smooth over all video, but I have no idea on how to accomplish this... [20:33:43 CET] <retal> kepstin, i think in my case it shuld work , i am using GPU wit Pascal [20:33:46 CET] <arthuralbano2> Sorry about newbie question... :) [20:36:30 CET] <kepstin> arthuralbano2: that's not really something that ffmpeg can do by itself. You might want to look at OpenCV, which has a bunch of related image processing algorithms [20:36:57 CET] <kepstin> (although removing a static background is more common problem than keeping the background and removing foreground, but the problems are kinda related) [20:41:24 CET] <retal> also with hwaccel option: ffmpeg -hwaccel nvdec -i 1.mp4 -vcodec h264_nvenc -b:v 5M -acodec copy out.mp4 utilization ~37$ [20:41:48 CET] <dominiques> any idea how to split audio to everytime get exactly 00:04:00 ~+-01 audio fragments ? [20:41:50 CET] <kepstin> arthuralbano2: https://docs.opencv.org/master/d1/dc5/tutorial_background_subtraction.html is the related tutorial - note that the "BackgroundSubtractor" builds a background model, after processing you can ask it to generate a background image. [20:41:51 CET] <retal> Intel i7 8th gen, DRR4 [20:46:02 CET] <kepstin> retal: now you've gone and disabled the hardare encoder... look at the "Full hardware transcode" example. [20:56:15 CET] <retal> kepstin, also tryed with "Full hardware transciding" ffmpeg -hwaccel cuvid -c:v h264_cuvid -i SuperMama.mp4 -c:v h264_nvenc 1.mp4 same result ~8% Utilisation. I understand it gave me x48 speed but i think there is so much power still inused [20:57:21 CET] <furq> retal: like he said, nvenc is a separate asic, its utilisation won't show up as gpu utilisation [20:57:38 CET] <kepstin> retal: you have to look specifically at usage of the hardware encoder, not gpu as a whole [20:58:01 CET] <kepstin> retal: and for the higher end gpus, they're really designed for multiple concurrent streams to get full usage of the hardware encoder [20:58:26 CET] <kepstin> (although geforce branded cards have arbitrary limits on concurrent streams - you need quadro hardware for lots of streams) [21:00:15 CET] <another> dominiques: what's with your current command (.. -f segment -segment_time 4 ...) [21:01:29 CET] <retal> ooh guys thank you i understood, i was looks whole GPU utilization [21:02:08 CET] <furq> is nvenc utilisation even observable [21:03:27 CET] <furq> i assume it's not but the last nvidia card i had was a gtx 260 [21:03:50 CET] <retal> im my case gtx 1060 [21:04:54 CET] <retal> 100 min vide i transcoded with i7 8gen in 16 min, with GPU 2 min [21:13:29 CET] <dominiques> another https://codeshare.io/aVnze3 [21:13:57 CET] <dominiques> can someone help me get EXACTLY 4 second audio splitting ? please check code https://codeshare.io/aVnze3 [21:17:02 CET] <dominiques> I CAN PAY FOR YOUR HELP ! REALLY NEED SOLVE THIS .. PLEASE CHECK https://codeshare.io/aVnze3 [21:24:00 CET] <ksk> stop screaming. [21:24:24 CET] <ksk> IIRC there is an example of how to take samples (just some seconds) of a file in the ffmpeg-wiki/x264 article [21:25:46 CET] <dominiques> ok [21:26:31 CET] <ksk> -t and -to - see the manpage [21:26:43 CET] <kepstin> note that a lot of the ffmpeg audio stuff works on frame boundaries, not sample accurate. Especially things that deal with encoded audio (like the segment muxer), which can't split anywhere except a sample boundary. [21:26:50 CET] <kepstin> except a frame boundary* [21:27:36 CET] <ksk> also, you can just go from input to wav directly, you dont need to make that output aac first, and then wav.. [21:28:55 CET] <kepstin> dominiques: for this type of stuff, sometimes dedicated audio processing tools (like sox) might be easier to use than ffmpeg. [21:31:14 CET] <dominiques> problem its, i have video mp4, i will extract audio and now i need split audio to exactly 4 second, i am still looking for best solution [21:33:40 CET] <dominiques> for example i have extracted from mp4 ... wav ... and this have exactly 3.98 az 4.01 second . this is OK ... can you tell me how can i get them back to AAC without loose lenght ... [21:34:00 CET] <dominiques> wav to aac to have 3.98 az 4.01 still [21:35:10 CET] <sazawal> dominiques, You could use Audacity to process/split the extracted audio. [21:36:09 CET] <kepstin> aac is tricky, because it has a frame length of ~20ms it can cause rounding errors if an application somwhere isn't indicating the correct samples to use in playuback [21:37:17 CET] <faLUCE> when I encode with libopus, the output says: "Stream #0:0: Audio: opus (libopus), 48000 Hz, stereo, s16, delay 312, 96 kb/s" <--- what is "delay"? [21:37:50 CET] <faLUCE> I mean: how can I set it through av_opt_set ? [21:41:26 CET] <kepstin> faLUCE: delay is the number of samples of preroll the codec uses as part of its algorithm. setting the frame duration to a lower value, and setting application to lowdelay should reduce that. [21:41:54 CET] <kepstin> note that 312 samples is 6.5ms @ 48kHz [21:43:10 CET] <faLUCE> kepstin: I did not set anything with the "ffmpeg" command, but I wonder how to obtain the same delay value with libavcodec... or do I have to leave all as default? [21:43:45 CET] <kepstin> faLUCE: i have no idea what you mean [21:43:56 CET] <kepstin> if you don't set options, the defaults are used... [21:45:33 CET] <faLUCE> kepstin: sorry, I explain better. I executed this command: "ffmpeg -f alsa -ac 2 -i default -c:a libopus -f mpegts -v verbose prova.ts" and obtained 312 as "delay". Now, I want to replicate the same settings manually with some code using libavcodec. Which "non default" option should I use for that? [21:45:55 CET] <kepstin> faLUCE: nothing, the defaults should do that [21:46:13 CET] <kepstin> make sure you selected the libopus codec specifically, rather than ffmpeg's builtin opus encoder [21:46:21 CET] <faLUCE> I see. I don't understand why I still have a bit choppy audio. [21:46:26 CET] <faLUCE> I used libopus codec [21:46:41 CET] <kepstin> choppy audio has nothing to do with that [21:47:15 CET] <faLUCE> it should depend on the size of each encoded packet [21:47:28 CET] <faLUCE> which is not the right size, pheraps [21:47:44 CET] <kepstin> choppy audio could happen if each input frame to the codec has fewer samples than required for the time between frames [21:48:05 CET] <retal> last question for today :) How to compile with nvresize ? [21:48:05 CET] <kepstin> because then the extra time will have to be filled with silence, i guess [21:49:16 CET] <kepstin> retal: that one's harder, I don't actually know. I think it actually requires some nvidia sdk to be installed on your machine to build it. [21:49:23 CET] <faLUCE> yes, in fact I don't understand how to calculate the exact input frame size... I copied avframe->linesize[0] bytes into the avpacket.... [21:49:58 CET] <kepstin> a frame should contain a number of samples equal to (next pts - current pts in seconds) * sample rate [21:50:24 CET] <retal> kepstin, thanks [21:50:37 CET] <kepstin> so if you have a frame at 0 seconds, the next frame at 1 second, and 48000khz sample rate, then the first frame should have exactly 48000 samples. [21:51:30 CET] <kepstin> the amount of bytes depends on the sample format and channels - as an example, for s16 stereo, that'll be 2 * 2 *48000 bytes. [21:51:55 CET] <faLUCE> kepstin: ok, but ffmpeg should already give me this value with the linesize[0] field [21:52:12 CET] <faLUCE> I used that field for MP2 and AAC and all worked fine [21:52:20 CET] <kepstin> faLUCE: how did ffmpeg give you something? where did this audio frame come from? [21:52:36 CET] <kepstin> is this a frame you got from a libavcodec decoder? [21:52:55 CET] <kepstin> if so, the only thing you should need to do is rescale the pts if needed. [21:53:06 CET] <faLUCE> kepstin: it is the frame obtained with av_frame_alloc(); [21:53:13 CET] <faLUCE> when allocating all the codec stuss [21:53:17 CET] <faLUCE> stuff [21:53:51 CET] <kepstin> faLUCE: sure, but where did the buffer come from? av_frame_alloc doesn't give you a buffer [21:54:13 CET] <faLUCE> kepstin: av_frame_get_buffer(mRawInputLibAVFrame, 0) [21:54:32 CET] <another> faLUCE: maybe relevant: 312 is the value opustools call pre-skip [21:55:15 CET] <kepstin> faLUCE: before you called av_frame_get_buffer, you need to set nb_samples and channel_layout on the avframe [21:55:24 CET] <kepstin> faLUCE: the nb_samples is ... the number of samples [21:55:29 CET] <faLUCE> kepstin: mRawInputLibAVFrame->nb_samples = mAudioEncoderCodecContext->frame_size; [21:56:04 CET] <kepstin> and the number of the samples is equivalent to the duration of the frame [21:56:33 CET] <faLUCE> I followed all the procedure for AAC and MP2 and I can encode well with these two codecs [21:56:35 CET] <kepstin> the number of samples in the frame and the pts values you set on each frame should be calculated from the same values [21:57:26 CET] <faLUCE> kepstin: I did not set the pts values... I left the encode() function set them [21:57:41 CET] <faLUCE> I mean: they are set by the encode() function [21:57:41 CET] <kepstin> faLUCE: that's not how it works... [21:57:52 CET] <kepstin> you set the pts values on the avframe before you send it to the encode function [21:58:12 CET] <faLUCE> kepstin: normally I set them in the way you say [21:58:39 CET] <faLUCE> but given that without setting them I see that they are set by the function, I avoided to set them [21:58:54 CET] <kepstin> faLUCE: you need to set the pts on an avframe before sending it to the encoder [21:59:12 CET] <kepstin> it might work by coincidence in some encoders, but you can't rely on that [21:59:19 CET] <faLUCE> kepstin: I see. this explains the previous problem. But why the hell are they set by the encoding function?? [21:59:25 CET] <faLUCE> this confused me [21:59:50 CET] <kepstin> the encoder shouldn't be touching the pts on the input frame. It will set the pts on the output packet. [22:00:10 CET] <kepstin> if you don't provide a pts on the input frame, the output packet's pts will be nonsense [22:00:23 CET] <faLUCE> kepstin: but I see that they are monotonic [22:00:28 CET] <kepstin> although some audio codecs might set it based on input sample count, so it could just work by chance [22:00:32 CET] <kepstin> but you can't rely on that [22:00:37 CET] <faLUCE> I see, I see [22:00:37 CET] <kepstin> set your pts values. [22:00:42 CET] <faLUCE> ok, thanks [22:00:59 CET] <faLUCE> I saw monotonic values and I thought they were right... [22:01:20 CET] <kepstin> libopus in particular uses a queue to adjust the input frame sizes if needed, and that queue relies on pts values to work correctly. [22:02:13 CET] <faLUCE> I see [22:03:01 CET] <faLUCE> well, If I set manually them with av_rescale_q(av_gettime_relative(), AV_TIME_BASE_Q,mAudioEncoderCodecContext->time_base) I still have some issues [22:03:17 CET] <faLUCE> maybe the rescaling is not correct [22:04:17 CET] <kepstin> faLUCE: set it based on the count of samples in the packet, not current time [22:04:41 CET] <faLUCE> kepstin: even with VBR ? [22:04:41 CET] <kepstin> av_rescale_q(number_of_samples_processed_so_far, sample_rate, output_time_base) [22:04:50 CET] <kepstin> vbr has nothing to do with sample rate [22:05:11 CET] <faLUCE> kepstin: I see, but why the previous way is not good? It should have a high resolution [22:05:22 CET] <kepstin> faLUCE: because it *doesn't match what's in the packet* [22:05:36 CET] <kepstin> it's a different clock, at a different speed, sampled at a different time [22:05:42 CET] <kepstin> has no relation to your audio whatsoever [22:05:57 CET] <faLUCE> kepstin: I see [22:06:11 CET] <faLUCE> ok let's try all [22:06:15 CET] <kepstin> an audio frame containing N samples at 48000khz is *exactly* N/48000 seconds long. [22:08:15 CET] <kepstin> so i'd recommend keeping a running count of number of samples encoded, start at 0, update it after encoding each frame with the number of samples in the frame. [22:08:33 CET] <kepstin> use that to calculate the pts by using the sample rate as a time base [22:09:05 CET] <kepstin> (equivalently, if every frame is the same size, you could work out a formula to calculate from number of frames encoded) [22:09:33 CET] <faLUCE> kepstin: yes, I used AudioEncoderCodecContext->time_base = (AVRational){ 1, audioSampleRate::value }; [22:10:35 CET] <faLUCE> but I did not calculate the pts before sending to the encoder in the way you said. I used the get_time() way for MP2, and given that it's not buffered, it worked [22:12:09 CET] <kepstin> audio is tricky, because the sound card has its own independent clock that it uses to count out the samples/sample rate [22:12:46 CET] <kepstin> if you request a specific sample rate, then you can determine the time from the sound card clock by the number of samples you get from it [22:13:47 CET] <kepstin> (this makes timing separately captured audio and video tricky, because they were probably timed using different clocks - and therefore might have drift) [22:14:50 CET] <faLUCE> yes, I remember that [22:17:36 CET] <kepstin> note that in the case where you're capturing audio in realtime and want to sync it with your system clock, you should use the aresample filter (see the resampler options) to fix it before encoding it [22:18:35 CET] <kepstin> so if you set the frame pts value from the system clock, you can then run the frames through aresample filter with appropriate options, and it'll add/remove frames and adjust speed to make the audio samples match the pts values. [22:18:40 CET] <kepstin> then the encoder will be happy with it [22:18:52 CET] <kepstin> add/remove samples* [22:19:27 CET] <faLUCE> kepstin: I don't need to sync with my system clock, I just need to sync it with the samples count when making pts [22:19:47 CET] <kepstin> yeah, if you're just capturing audio, that's the way to do it. [22:23:24 CET] <faLUCE> kepstin: but, given that the encoder timebase is (AVRational){ 1, audioSampleRate::value }, what do you mean with output timebase? the timebase of the muxer/container ? [22:24:45 CET] <kepstin> faLUCE: i'm missing some context, but the container might require scaling to a different timebase (e.g. ffmpeg's matroska/webm muxer uses a fixed timebase of 1/1000) [22:25:13 CET] <faLUCE> kepstin: for mpegts I use (AVRational){ 1, audioSampleRate::value } as timebase [22:25:46 CET] <kepstin> mpegts has a fixed timebase of 1/90000 [22:25:55 CET] <kepstin> so that'll need rescaling before muxing [22:26:15 CET] <faLUCE> kepstin: yes, you are right, it was the timebase of the muxer's encoder [22:26:31 CET] <faLUCE> I mean, the timebase of the muxer's codeccontext [22:58:36 CET] <faLUCE> kepstino, so, with: sample_rate = 48000, float, stereo, with opus frame_duration = 60ms, I have nb_samples = 2880 . should I feed the opus encoder with pts = 2880*i , where i is the frame number? [22:58:39 CET] <faLUCE> kepstin: [22:59:10 CET] <kepstin> faLUCE: assuming timebase is 1/sample_rate, that would be correct. [22:59:39 CET] <faLUCE> kepstin: yes, I have that timebase .... but audio is still a bit choppy :-( [23:01:12 CET] <JEEB> usually you check how big audio frames an encoder wants with http://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#aec57f0d859a6df8b… [23:01:21 CET] <JEEB> the problem seems to be that I can't see libopus wrapper setting that [23:02:48 CET] <faLUCE> JEEB: in libopusenc.c there's avctx->frame_size = frame_size * avctx->sample_rate / 48000; [23:03:03 CET] <JEEB> oh, how did I not see that one [23:03:14 CET] <JEEB> yup, it does set it [23:04:21 CET] <JEEB> so yea, you should be able to figure out how big audio frames the encoder wants with that. [23:04:47 CET] <JEEB> personally I used libavfilter to do my resampling previously, and there was a nice function which you could tell how many samples you wanted exactly [23:04:58 CET] <JEEB> mostly because your input format could have 1024, or 960 or 1500 [23:05:02 CET] <faLUCE> JEEB: I already took that value with avframe->linesize[0] [23:05:22 CET] <JEEB> not nb_samples? [23:05:32 CET] <JEEB> linesize != actual amount of samples [23:05:39 CET] <kepstin> faLUCE: avframe->linesize is meaningless, that's just the size of the buffer you allocated. you already know that, since you allocated the buffer [23:06:03 CET] <faLUCE> uhmmm wait [23:06:20 CET] <JEEB> linesize is the amount of bytes to go to get to the following set of samples [23:06:31 CET] <JEEB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html#aa52bfc6605f6a3059a0c32… [23:06:41 CET] <JEEB> nb_samples is how many audio samples it has [23:06:46 CET] <kepstin> in particular, when you set nb_samples and the sample format on the avframe, then the buffer allocation calculates how big the buffer should be from those. [23:07:37 CET] <JEEB> right, av_buffersink_get_samples [23:07:40 CET] <JEEB> is what I used with libavfilter [23:07:49 CET] <JEEB> "gimme XYZ samples from the audio chain" [23:08:01 CET] <JEEB> and then I just fed decoded audio to that and got out what I needed [23:09:57 CET] <faLUCE> well, what Imeant is that I set the avpacket size to linesize[0] [23:10:18 CET] <kepstin> avpacket size has nothing to do with frame size, why would you do that? [23:10:20 CET] <faLUCE> which tells me how many bytes (considering the layout, the format etc.) [23:10:51 CET] <faLUCE> what I do is to allocate an avpacket, and then fill it with data for linesize[0] bytes [23:10:53 CET] <kepstin> note that with planar audio formats, linesize[0] will be the length of only one of the planes (channels) [23:11:03 CET] <faLUCE> I use packed format [23:11:07 CET] <kepstin> do you mean avframe? packets are for encoded audio [23:11:51 CET] <faLUCE> I allocate an avpacket, then copy raw data into it. I copy exactly linesize[0] bytes [23:12:04 CET] <faLUCE> all works perfectly with MP2 and AAC [23:12:09 CET] <kepstin> the input to an encoder is avframes, not avpackets... [23:14:04 CET] <faLUCE> well, you are right, I was confused by "receive_packet" [23:14:39 CET] <faLUCE> (encoding is in two steps... the second one outputs packets) [23:14:42 CET] <JEEB> yes [23:14:48 CET] <JEEB> feed it frames, receive bacon^Wpackets [23:14:49 CET] <faLUCE> so, I have to set the FRAME's ts [23:15:02 CET] <kepstin> YES THAT"S EXACTLY WHAT I"VE BEEN SAYING ALL DAY [23:15:11 CET] Action: kepstin goes home [23:15:12 CET] Action: JEEB pats kepstin [23:15:42 CET] <faLUCE> thanks kepstin and JEEB... but you know? some times ago there was the first step function with packet too [23:15:54 CET] <JEEB> yes, the other way [23:15:55 CET] <JEEB> decoding [23:16:04 CET] <faLUCE> it's pretty confusing [23:16:05 CET] <JEEB> feed packet, receive bacon^Wframe [23:16:09 CET] <faLUCE> ok [23:16:28 CET] <JEEB> faLUCE: just think of AVFrames always when you deal with raw data, and AVPackets with encoded data [23:18:13 CET] <kepstin> i guess it was only about an hour and a half ago that i wrote "<kepstin> you set the pts values on the avframe before you send it to the encode function" :/ [23:18:26 CET] <faLUCE> JEEB: yes... now I remember all... I did not use libavcodec since one year [23:18:52 CET] <faLUCE> kepstin: sorry.... but when reading "setting pts" I suddenly thought about an avpacket [23:19:56 CET] <faLUCE> I know that I was wrong, but there's another function that misleaded me: [23:19:59 CET] <faLUCE> av_write_frame() [23:20:06 CET] <faLUCE> which wants an avpacket [23:20:20 CET] <JEEB> yes, those old functions are a real misnomer [23:20:22 CET] <faLUCE> (muxing) [23:20:29 CET] <JEEB> av_read_frame and av_write_frame [23:21:48 CET] <faLUCE> why a "deprecated" ticket is not open? [23:22:20 CET] <JEEB> because deprecation generally means something new was written instead [23:22:29 CET] <JEEB> although in theory there could be a rename deprecation :P [23:22:45 CET] <faLUCE> but send_frame and receive_packet were the result of a deprecation [23:22:52 CET] <faLUCE> and they clarify lot of things [23:23:03 CET] <JEEB> they were the result of someone making a better API [23:23:10 CET] <JEEB> and thus the old one was deprecated [23:23:26 CET] <JEEB> deprecation usually is "here's a better thing, please use it before we remove the old one" [23:23:34 CET] <faLUCE> so, also for write/read_frame the same thing should be applied [23:23:56 CET] <faLUCE> depraction is good also for API improvement... when changing names [23:24:03 CET] <faLUCE> (deprecation) [23:24:07 CET] <JEEB> yes, I don't disagree [23:24:13 CET] <JEEB> it could/should get renamed [23:24:46 CET] <faLUCE> :-) [23:37:30 CET] <faLUCE> so, let's resume. I feed the AVFrame* frame with linesize[0] bytes. And I set frame.pts = frame.nb_samples*i , where i is the frame number. .... still choppy audio... :-( . I tried also frame.pts = frame.nb_samples*i*2 (stereo) but the problem remains [23:40:47 CET] <faLUCE> the strange thing is that the distortion is minimal [23:42:18 CET] <faLUCE> I don't even get any warning from libavcodec. If I set, for example frame.pts = i, where i is incremental, I have warnings [23:42:51 CET] <faLUCE> I think it's a matter of insufficient buffering [23:44:54 CET] <JEEB> why are you putting linesize[0] amount of samples, and not nb_samples amount of samples? [23:45:27 CET] <JEEB> also I'm not sure if your sample is of size of a single byte, but that's a detail :P [23:46:02 CET] <JEEB> like, there's a warning about linesize being larger than nb_samples*sizeof(sample) [23:46:09 CET] <JEEB> for optimization etc reasons [23:46:19 CET] <JEEB> it can be the same, but never ever expect it to be [23:46:30 CET] <JEEB> it really sounds like you have fed into the AVFrame more data than nb_samples [23:46:35 CET] <faLUCE> I don't put linesize[0] samples... I put linesize[0] bytes [23:46:41 CET] <JEEB> yes, still [23:46:50 CET] <JEEB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html#aa52bfc6605f6a3059a0c32… [23:46:58 CET] <JEEB> > The linesize may be larger than the size of usable data there may be extra padding present for performance reasons. [23:47:19 CET] <JEEB> never, ever use linesize for anything else than getting from one set of data to the next or previous [23:47:31 CET] <faLUCE> I see, there's an extra padding [23:47:38 CET] <JEEB> always use nb_samples*sizeof(sample) [23:47:51 CET] <JEEB> you know the size of a sample from the AVFrame's sample format [23:47:58 CET] <faLUCE> JEEB: nb_samples*sizeof(sample)*channels [23:47:59 CET] <faLUCE> ? [23:48:37 CET] <JEEB> channels can be separate or together, so depending on planar/not planar [23:48:44 CET] <faLUCE> I use packed [23:50:38 CET] <JEEB> I don't remember the exact details of audio frames, but if it's a single "line" for all channels then yes [23:50:48 CET] <JEEB> (I let avfilter do this boring stuff for me) [23:50:58 CET] <JEEB> which then used swresample underneath [23:51:17 CET] <JEEB> (which at the very least can do the AVFrame size changes for me vOv) [23:54:20 CET] <JEEB> but yea, the primary thing I try to note is that linesize != nb_samples*size of sample [23:54:26 CET] <faLUCE> JEEB: nb_samples*sizeof(float)*2 gives me exactly the value of linesize[0] .... and the same problem :-( [23:54:52 CET] <JEEB> pretty sure there's a function for the size [23:56:01 CET] <JEEB> surprising that it doesn't have any padding :/ [23:57:15 CET] <faLUCE> JEEB: there's not such a function in the avframe API [23:57:35 CET] <JEEB> no I mean something that gives you a size from AVSampleFormat [23:57:42 CET] <JEEB> of course I could be incorrect :P [23:57:46 CET] <JEEB> it just feels like something that should be there [23:58:02 CET] <faLUCE> yes, there is but I'm sure I used float... [23:59:14 CET] <JEEB> which should be native 32bit float [23:59:39 CET] <JEEB> anyways, I'm just interested myself if I were to code this myself :P [00:00:00 CET] --- Fri Mar 15 2019

1 0

ffmpeg-devel.log.20190313
by burek 14 Mar '19

14 Mar '19

[02:53:25 CET] <kierank> j-b: as in the gaming Oliver Collyer? [09:36:54 CET] <j-b> kierank: maybe, dunno [12:35:43 CET] <_bluez> exit [12:36:39 CET] <_bluez> Hello! I want to work on hief support for gsoc... can anyone suggest me a qualification task that is not already taken? [12:37:25 CET] <_bluez> heif* [12:41:38 CET] <durandal_1707> _bluez: contact mentor by mail [12:44:35 CET] <cone-101> ffmpeg 03Mark Reid 07master:283ce69a107b: avformat/mxfenc: allow user comments for opatom muxer [12:44:36 CET] <cone-101> ffmpeg 03Mark Reid 07master:7ff89574c78d: fate/mxf: add mxf user comments tests [12:46:15 CET] <_bluez> durandal_1707: Thanx.. will do that :) [12:50:34 CET] <jkqxz> What should be done with the patch adding parallelism to the ffmpeg utility? [12:50:44 CET] <jkqxz> The most recent version has added big locks around some specific cases I noted in the previous review, but there are still a load of data races in there. [12:51:47 CET] <jkqxz> I don't really have much confidence that the submitter understands what they're doing, since it seems like their response to the concerns has been reactive to specific cases only. [12:52:10 CET] <JEEB> :/ [12:52:14 CET] <JEEB> that's unfortunate [12:52:15 CET] <durandal_1707> tell him to rewrite ffmpeg from scratch [12:52:18 CET] <jkqxz> And I don't want to spend days doing their audit work on what is a very hard problem. [12:52:30 CET] <JEEB> but yea, that's what was my initial response to it [12:53:41 CET] <jkqxz> I feel like if I point out another race, we'll just get another version with another lock and be no further forward in believing that the result is actually correct. [12:57:08 CET] <jkqxz> durandal_1707: Tbh that's the right answer to properly adding parallelism. Adding it as a bolt-on in code which wasn't written with it in mind at all is very difficult. [12:57:23 CET] <JEEB> yea [16:45:11 CET] <faLUCE> Hello. While decoding mjpeg frames I have this continuous msg: "[mjpeg @ 0x7efda4003b80] unable to decode APP fields: Invalid data found when processing input" . This is the command that I executed: "ffplay -f v4l2 -input_format mjpeg -video_size 640x480 -framerate 25 -i /dev/video0". I'm seeing that a patch has been submitted for that: https://git.ring.cx/savoirfairelinux/ring-daemon/commit/ [16:45:13 CET] <faLUCE> 4036b7708fa7de996b0585a7bc432397c77d41b2 but I don't understand if the log message is still a valid message. In addition, I don't see the patch in the git current image of ffmpeg... [16:46:24 CET] <faLUCE> in 2.8.7 version I did not have that msg... [16:50:23 CET] <faLUCE> so, I don't understand if I have to ignore this msg... [16:53:53 CET] <jkqxz> What is actually in the APP block in your JPEG? [16:54:03 CET] <faLUCE> jkqxz: AVI1 [16:54:11 CET] <faLUCE> In a chat of some time ago, another user had the same issue: http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-September/004509.ht… . He solved the issue by downgrading ffmpeg to 3.3.3. [16:56:05 CET] <jkqxz> Is that over the end of the file? That won't hit the < 6 case (since it's 2 byte length + 4 bytes data), and those are the only two ways to get INVALIDDATA there. [16:57:07 CET] <jkqxz> Or maybe the length in the file is wrong. [16:57:32 CET] <faLUCE> jkqxz: no, they are bytes 6-7-8-9 of the frame [16:57:56 CET] <faLUCE> jkqxz: which length ? [16:59:20 CET] <jkqxz> An APP block is two bytes of length followed by the data. The length field should match the total length (that is, the length of the data plus two). [17:01:34 CET] <faLUCE> jkqxz: the total lenght of what? of the frame or of the APP block? [17:01:52 CET] <jkqxz> Of the APP block. [17:02:02 CET] <faLUCE> let me check [17:05:11 CET] <jkqxz> <https://www.w3.org/Graphics/JPEG/itu-t81.pdf>, page 48. [17:10:14 CET] <faLUCE> jkqxz: bytes 4-5 have values of 0 and 33. Then the lenght you say is 33. But I don't understand if this length should be =4 or the APP field is longer than "AVI1". I can't find mjpeg specs on google [17:15:11 CET] <faLUCE> I tried to set it manually to 4 and to 6. But still get the warning [17:17:11 CET] <jkqxz> Show the first line of a hexdump of the file? ("hd file | head -1") [17:18:32 CET] <faLUCE> jkqxz: how many bytes? I'm running a program made with libavcodec [17:19:18 CET] <jkqxz> At least 11. [17:22:47 CET] <faLUCE> jkqxz: ff d8 ff e0 0 21 41 56 49 31 0 1 1 1 0 78 0 78 0 0 0 0 0 0 0 0 0 0 0 0 [17:25:04 CET] <faLUCE> jkqxz: (40 bytes) ff d8 ff e0 0 21 db 041 56 49 31 0 1 1 1 0 78 0 78 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ff [17:25:32 CET] <jkqxz> Huh. I don't see how that can generate the error at all. [17:25:40 CET] <jkqxz> Do you perhaps have another APP section later in the file? [17:28:50 CET] <faLUCE> let me check [17:29:40 CET] <faLUCE> (not easy, I have to debug libavcodec) [17:34:56 CET] <faLUCE> jkqxz: here's one of the frames captured with ffmpeg -f v4l2 -input_format mjpeg -video_size 640x480 -framerate 25 -i /dev/video0 thumb%04d.jpg ----> https://unsee.cc/98e1a0b8/ [17:35:13 CET] <faLUCE> (with the output showing all the warning msg) [17:35:41 CET] <faLUCE> I have the same issue with all the usb cameras I used [17:41:27 CET] <faLUCE> sorry, I had connection problems [17:46:26 CET] <faLUCE> I suspect it's a bug [17:47:23 CET] <jkqxz> I don't see anything useful at that link (just an upload page). [17:48:42 CET] <faLUCE> jkqxz: sorry: https://unsee.cc/100e3eb2/ [17:49:34 CET] <faLUCE> sorry again jkqxz, let me find another site for uploading [17:50:11 CET] <JEEB> curl -F'file=@/path/to/file' https://0x0.st [17:50:35 CET] <JEEB> for a random sample that should be good enough? [17:52:33 CET] <faLUCE> I can't open http or https port [17:52:45 CET] <faLUCE> https://a.uguu.se/ReegXWAjsTDb_thumb0005.jpg [17:55:22 CET] <faLUCE> well: (thanks to JEEB) [17:55:23 CET] <faLUCE> https://0x0.st/zXN8.jpg [17:55:31 CET] <faLUCE> jkqxz: ^ [17:56:40 CET] <jkqxz> That has no APP blocks or warnings? [17:57:50 CET] <faLUCE> it has the same warning that I said before... [17:58:09 CET] <faLUCE> [mjpeg @ 0x564a00b44740] unable to decode APP fields: Invalid data found when processing input [18:54:41 CET] <thealakazam> Hello, people, I wanted to ask if there are any tutorials or guides for creating muxers wanna try implementing one, for contributing later. [18:55:40 CET] <JEEB> looking at one of the recently added smaller ones might be a good one [18:56:07 CET] <faLUCE> jkqxz: you were right, there's another "ff e0" marker in the header. I don't know why the USB camera put it there, but I don't know either if it's an error of the camera or, instead, the libavcodec jpeg decoder should stop searching other markers when the first one has been found [18:56:12 CET] <JEEB> and generally there's this check-list https://www.ffmpeg.org/developer.html#New-codecs-or-formats-checklist [18:56:47 CET] <faLUCE> jkqxz: IMHO the libavcodec decoder should stop searching other markers when the first one has been found [18:58:00 CET] <llogan> seeing some users complaining that ffmpeg fails to compile using blackmagic SDK 11, but 10.11.4 works fine. i didn't look into it and can't test. [18:58:41 CET] <thealakazam> oh ok thanks, will start reading up on it [18:59:06 CET] <JEEB> :< [18:59:31 CET] <JEEB> I would have linked a simple demuxer and told him that muxers are similar (just different callbacks are registered) [19:00:16 CET] <llogan> scared off by developer.html wall-o-text [19:03:12 CET] <faLUCE> jkqxz: note that the image that I uploaded was a JPEG image (without the MJPEG header) [19:05:42 CET] <JEEB> llogan: I tried to find the "baby's first component" tutorial that I remember seeing on libav's site, but I couldn't find it right away :< [19:05:50 CET] <faLUCE> there should be something broken in ffmpeg > 3.3.3 for MJPEG decoding [19:27:38 CET] <durandal_1707> no way!! [21:35:19 CET] <cone-537> ffmpeg 03Jun Li 07master:c2a221c5ae50: avformat/rtpdec.h remove unused variable [21:42:52 CET] <Lynne> does someone here know aarch64 assembly? [21:43:12 CET] <Lynne> I've written a function but its only 1.25 times faster than C (when #if 1): https://paste.ubuntu.com/p/pbPRXtZZTm/ [00:00:00 CET] --- Thu Mar 14 2019

1 0

ffmpeg.log.20190313
by burek 14 Mar '19

14 Mar '19

[00:00:20 CET] <cryptopsy> i know that but im not sure why you're telling me this? [00:00:37 CET] <kepstin> that's probably the reason why you're getting the strange buffering issue [00:00:52 CET] <cryptopsy> with grep the output is comming as separated by \n and i would actually like to change it to \r [00:01:57 CET] <kepstin> at this point, I'd switch to a programming language other than bash, this type of text handling is really hard to get right in bash. [00:02:36 CET] <cryptopsy> how would that help? that hard part is separating each iteration of ffmpeg's internal loop [00:03:03 CET] <kepstin> if the only thing you need to to display the progress output to the user, why not just run ffmpeg with no output redirection so the user can see the progress output? [00:03:06 CET] <cryptopsy> if i was going to use a prog lang and write my own loop that calculates time intervals it would be just as hard in any lang as in bash [00:03:36 CET] <cryptopsy> only the frame numbers are important, separated by \r [00:04:14 CET] <tdr> you can just pipe output to sed to change it [00:04:26 CET] <cryptopsy> tdr: i mentioned why that didnt work [00:04:35 CET] <cryptopsy> seems to be a side effect of multiple piping (to grep to sed) [00:04:39 CET] <kepstin> or tr can switch the newline/carriage return thing [00:04:52 CET] <kepstin> every command you add to the pipe adds another buffer of course, so :/ [00:05:28 CET] <cryptopsy> there might be a way to run multiple greps in a single grep statement [00:05:47 CET] <cryptopsy> multiple -e [00:05:51 CET] <cryptopsy> attempting now ... [00:05:56 CET] <kepstin> (doing this in a programming language where you can read from the ffmpeg output directly, then work with string processing locally seems like a much better option...) [00:06:29 CET] <cryptopsy> a man's gotta stick to his guns .. [00:06:32 CET] <TheAMM> ffmpeg = subprocess.Popen(cmd, universal_newlines=True, stderr=subprocess.PIPE) [00:06:47 CET] <TheAMM> for line in ffmpeg.stderr: [00:06:47 CET] <TheAMM> print(line.strip()) [00:06:52 CET] <kepstin> but yeah, i still don't have any idea why exactly you need this info, so I can't provide any feedback other than to say "ffmpeg doesn't provide the data you're asking for in a processing-friendly way", and "doing this in bash is hard" [00:07:04 CET] <cryptopsy> i'm only fluent in C i'm not prepared to do this is in C [00:07:12 CET] <cryptopsy> oh, and bash :D [00:07:30 CET] <kepstin> any yeah, for this type of text processing, i'd use python too :) [00:07:42 CET] <kepstin> but first, i'd just not do it at all if i didn't have to [00:07:45 CET] <TheAMM> (I haven't tested if subprocess gives you a legit textio to allow iterating lines like that but I expect it to) [00:07:49 CET] <kepstin> and i still don't know why you want to do it [00:09:55 CET] <kepstin> (15 years ago, I would have used perl instead, but i've just about forgotten how to program in perl nowadays) [00:10:22 CET] <TheAMM> (and it was for the better) [00:55:15 CET] <ossifrage> My arm build is not working: "[NULL @ 0x23240] Requested output format 'mp4' is not a suitable output format" [00:56:06 CET] <ossifrage> it seems like all the muxers where built [00:58:02 CET] <pink_mist> are you perhaps trying to put things into mp4 that don't belong in mp4? [00:58:21 CET] <ossifrage> pink_mist, so it works with my x86_64/fedora build [00:58:47 CET] <ossifrage> just not my arm32/buildroot build [00:59:59 CET] <ossifrage> It is failing really early in avformat_alloc_output_context2() [01:01:10 CET] <ossifrage> I'm assuming this is a build problem, but the trial and error loop is kinda slow [01:06:04 CET] <ossifrage> It doesn't help that the host has ffmpeg-4.0.3 and the br is only 3.4.5 [01:29:53 CET] <ossifrage> So the libavformat seems to have ff_mp4_muxer, any ideas what else would be needed for avformat_alloc_output_context2(&mux->fmtCtx, NULL, "mp4", NULL) to be happy? [01:34:24 CET] <ossifrage> Adding av_log_set_level(AV_LOG_TRACE) didn't provide anything extra [01:47:09 CET] <relaxed> ossifrage: maybe my arm builds will work? https://www.johnvansickle.com/ffmpeg/ [01:56:05 CET] <ossifrage> relaxed, I'm in the process of building the same version as I have on my fedora devel box [01:56:19 CET] <JEEB> ossifrage: clearly something's missing as it says the output format is not there :/ [01:56:55 CET] <ossifrage> JEEB, yeah, I can see the symbols and the mime types in the library [01:57:57 CET] <JEEB> that message comes from libavformat/mux.c right within avformat_alloc_output_context2. if you don't have a format set, then it checks the string with av_guess_format(string, NULL, NULL) [01:58:01 CET] <ossifrage> Should I build 4.0.3 or go for 4.1.1? (fedora29 has 4.0.3, the arm box was 3.4.5) [01:58:01 CET] <JEEB> and that seems to return nullptr [01:58:45 CET] <ossifrage> The "NULL @" did seem odd, I'm not sure what it is supposed to be? [01:58:49 CET] <JEEB> I would just pick a version from master that is green on FATE for the systems and architectures you require, but if you go for release the newer is better [01:59:08 CET] <JEEB> the NULL in the message is just that it does't yet have a format picked [01:59:15 CET] <JEEB> it's the av_log first parameter [01:59:27 CET] <JEEB> it pushes the just created AVFormatContext there [01:59:30 CET] <pink_mist> what's FATE? [01:59:34 CET] <JEEB> fate.ffmpeg.org [01:59:36 CET] <JEEB> automated testing [01:59:38 CET] <ossifrage> Oh, I never called av_log() [01:59:46 CET] <JEEB> no, the framework does [01:59:49 CET] <ossifrage> err, never mind [02:00:12 CET] <JEEB> anyways, you can try emulating the stuff with av_guess_format :P [02:00:16 CET] <pink_mist> well, can't seem to connect to fate.ffmpeg.org [02:00:30 CET] <pink_mist> no wait, it was just very very slow [02:00:40 CET] <JEEB> yea, it seemed lately to be rather slow for one reason or another [02:00:49 CET] <JEEB> also older versions of FFmpeg require you to register_all [02:00:52 CET] <JEEB> while newer donät [02:00:54 CET] <JEEB> *don't [02:01:03 CET] <JEEB> so check that you're doing that if you need to support older versions [02:01:23 CET] <JEEB> you will get a deprecation warning when building against newer code, but the functions are there [02:01:40 CET] <JEEB> av_register_all() is the exact function it seems [02:02:35 CET] <JEEB> that registers all formats, protocols etc (in newer versions it's static because the dynamic registration didn't work anyways due to requiring internal structures) [02:02:46 CET] <JEEB> so if we make a new dynamic registration thing, it will be better designed :P [02:05:28 CET] <ossifrage> JEEB, using av_guess_format() also failed, but I didn't get the 'Requested output format..." message [02:05:57 CET] <JEEB> it doesn't of course, I just noted that you can use that as a simple test cae :P [02:05:58 CET] <JEEB> *case [02:06:06 CET] <JEEB> since that's what's internally failing in the function you were calling [02:06:19 CET] <JEEB> which sounds like you didn't call av_register_all in the older FFmpeg version [02:06:24 CET] <JEEB> please make sure you're doing that :) [02:06:39 CET] <ossifrage> the joys of older versions, bah [02:07:19 CET] <ossifrage> JEEB, winner winner! [02:08:21 CET] <JEEB> and you can call that in the newer versions still, it will just warn during compilation [02:13:48 CET] <ossifrage> Application provided duration: 6413133197 / timestamp: 6413333310 is out of range for mov/mp4 format [02:13:56 CET] <ossifrage> I didn't provide a duration, hmmm... [02:14:46 CET] <JEEB> check time base, dts and pts given in AVPackets [02:25:41 CET] <ossifrage> Well it is doing something, but it only calls my avio handler twice (36 bytes and 689 bytes) and then nothing for the frames. [02:26:17 CET] <ossifrage> I really need to sync up the versions so I can compare intel to arms [02:28:18 CET] <ossifrage> I accidentally fed it some h.265 and it didn't complain so something isn't right [02:29:42 CET] <JEEB> I don't think the muxer expects such cases and as long as the data looks correct enough it will stick it in [02:30:36 CET] <ossifrage> This version doesn't have AV_PKT_FRAME_KEY or AV_PKT_FLAG_DISPOSABLE which I was setting in the x86_64 version [10:10:33 CET] <sazawal> Hello. I want to convert a video clip into png images and get the associated timestamp. I tried this command, "ffmpeg -i input.mkv -vf "showinfo" -vsync 0 frame%04d.png -hide_banner >& output.txt". But sometimes the number of frames generated are one more than the number of timestamps I get. How do I solve this? [10:44:58 CET] <rnmhdn> I need to convert 150h of video that is exportend from adobe premier [10:45:34 CET] <rnmhdn> I need to write them into DVD and USB stick and distribute them. [10:46:21 CET] <rnmhdn> I did a lot of research about how to do it but I cant get confident that I'm doing good enough [10:46:41 CET] <rnmhdn> I also need a dash version of them. [10:47:26 CET] <rnmhdn> for example I see that there is a technique of downsampling the colors and assigning good bitrate to luminance [10:48:06 CET] <rnmhdn> basically I want to learn the common practices in encoding videos for distribution to users. [10:48:17 CET] <rnmhdn> my current videos are h264 [10:49:11 CET] <rnmhdn> for example this is one of the commands I used: ffmpeg -i N1.1.mp4 -codec:v libx264 -x264opts "keyint=24:min-keyint=24:no-scenecut" -profile:v baseline -level 4.0 -vf "scale=-2:1080" N1.1_1080.mp4 [10:50:19 CET] <sazawal> rnmhdn, I normally use Handbrake to downsize videos. It is basically ffmpeg but with a gui which makes it easier to use. [10:52:00 CET] <rnmhdn> for example this is ffmpeg -i for one of my videos: [10:55:30 CET] <rnmhdn> https://paste.ubuntu.com/p/v7GZFNYXxw/ [10:59:17 CET] <rnmhdn> https://paste.ubuntu.com/p/45t5KSgQ6h/ [11:13:21 CET] <another> any specific reason why you use baseline profile? [11:40:57 CET] <another> hmm.. what is the difference betwenn all those isobmff muxers (mp4, ipod, mov, psp, ...)? [11:54:28 CET] <JEEB> another: various sub-types of mov or isobmff added at some point of time [11:55:08 CET] <JEEB> some of them are probably no longer as needed (f.ex. the PSP one probably is unneeded now since I've always used normal MP4 files after some 3.xx firmware) [12:06:52 CET] <another> iC [12:25:46 CET] <sazawal> Hello. I want to convert a video clip into png images and get the associated timestamp. I tried this command, "ffmpeg -i input.mkv -vf "showinfo" -vsync 0 frame%04d.png -hide_banner >& output.txt". But sometimes the number of frames generated are one more than the number of timestamps I get. How do I solve this? [13:05:15 CET] <BtbN> sazawal, pretty sure that just gives the frames numbers, strictly counting up? [13:05:54 CET] <BtbN> The img2 muxer has an option called frame_pts, have you tried that? [13:11:26 CET] <sazawal> BtbN, Now I looked carefully at the output.txt. I have actually missed to look at the frame0001.png which is at pts_time=0. Okay, so I have the same number of frames and timestamps. [13:12:55 CET] <BtbN> https://www.ffmpeg.org/ffmpeg-formats.html#Options-6 [13:13:03 CET] <BtbN> frame_pts reads like it's exactly what you want [13:13:44 CET] <sazawal> BtbN, I have another question. I have split a video file into different clips at all the keyframes. Now for the first clip, the first frame is captured at pts_time=0.021. But for the rest of the clips the first frame is captured at pts_time=0. Why is this happening? [13:14:08 CET] <BtbN> How did you split it? Segment muxer? [13:15:22 CET] <sazawal> BtbN, I have used "ffmpeg -i input.mkv -acodec copy -f segment -vcodec copy -reset_timestamps 1 -map 0 clip%d.mkv" [13:16:01 CET] <BtbN> reset_timestamps: "Reset timestamps at the beginning of each segment, so that each segment will start with near-zero timestamps." [13:16:04 CET] <BtbN> That'd be why [13:17:17 CET] <sazawal> BtbN, I see. But why the first clip is starting at 0.021? I mean what is happening to the frames before this time? [13:17:28 CET] <BtbN> There might not be any [13:17:40 CET] <BtbN> The first timestamp does not have to be 0 [13:18:00 CET] <sazawal> oh I see. [13:19:05 CET] <BtbN> though with how the logic is implemented, it does seem a bit strange how it can start at anything but 0 [13:20:00 CET] <BtbN> What it does is pts += initial_offset - cur_entry.start_pts [13:20:33 CET] <sazawal> Another question. If I want the timestamp of a frame in clip-3 for example. Then I would do pts_time (of this frame)+pts_time (of the last frame of clip1)+pts_time (of the last frame of clip-2). Is this correct? [13:21:05 CET] <BtbN> I don't think so, no [13:21:16 CET] <BtbN> That would give you a crazy high number potentially [13:21:29 CET] <sazawal> BtbN, I see. So, what would be a way to find the actual timestamp? [13:21:49 CET] <BtbN> What do you need them for? They are not exactly carrying much information other than how to play the frames relative to each other. [13:22:47 CET] <sazawal> BtbN, I am writing a script to generate subtitles. [13:23:28 CET] <sazawal> After I process a frame in clip-n for example, and extract the subtitles. I would want the timing of this frame in the original video, [13:23:30 CET] <BtbN> With how the segment muxer does the reset timestamp thing, I don't think the original timestamp is fully recoverable [13:24:03 CET] <sazawal> BtbN, What if I don't use reset-timestamp flag? [13:24:16 CET] <BtbN> Then you will have the original timestamps in each segment [13:24:51 CET] <BtbN> If your software can work with that, that's probably the easiest way [13:25:04 CET] <sazawal> BtbN, Then it is easier right? I don't need the seperate clip timestamp anyway. [13:25:18 CET] <sazawal> Yes I think so. [13:36:50 CET] <sazawal> BtbN, Sorry I did not understand what you said about frame_pts. I don't see frame_pts in the output.txt file. [13:37:01 CET] <BtbN> It's an image2 muxer option [13:37:17 CET] <BtbN> see the link I pasted [13:41:07 CET] <sazawal> Okay, so this is just for naming the image files. [14:01:29 CET] <jksamir> Hi! In the extract_mvs example, I was wondering if I could get the reference frames numbers from which the motion vectors were calculated (instead of the +/- 1 direction) [15:41:20 CET] <_Vi> How do I read output of `silencedetect` filter specified in FFmpeg command line without "size= 111830kB time=00:09:56.42 bitrate=1536.0kbits/s speed= 314x" statistics interfering? [15:41:47 CET] <_Vi> Probably found myself: "-nostats" [16:23:39 CET] <CyberShadow> _Vi: Looks like the filter sets metadata, which can be written to a file by itself using https://ffmpeg.org/ffmpeg-filters.html#metadata_002c-ametadata (mode=print and file=yourfile.txt) [16:24:01 CET] <CyberShadow> Oh, there's even an example with silencedetect there. [16:30:16 CET] <faLUCE> hello. After executing: ffplay -f v4l2 -input_format mjpeg -video_size 640x480 -framerate 25 -i /dev/video0 I can see the video, but I have lot of this msgs: "[mjpeg @ 0x7efda4003b80] unable to decode APP fields: Invalid data found when processing input". Is this a ffmpeg bug? [16:47:19 CET] <USian_nogoodnick> i have a script with a few lines like this: https://pastebin.com/pthJTu2Q and they recently quit recording usable video. i suspect a recent ffmpeg update. does anyone know what changed or what i can do to fix this issue? [17:03:07 CET] <brimestone> I'm trying to do this. ffmpeg -i 40fps_speedUp.mp4 -f lavfi -i "sine=frequency=40" -filter_complex "[0:a][1:a]amerge=inputs=2[a]" -map 0:v -map "[a]" -codec copy 40fps_speedUp_40hz.mp4 but Im getting "Filtering and streamcopy cannot be used together" - how would I make this work? [17:12:45 CET] <BungeeTheCookie> hello [17:12:49 CET] <BungeeTheCookie> I'm having a problem with ffprobe [17:13:54 CET] <BungeeTheCookie> I run this command [17:13:57 CET] <BungeeTheCookie> /Users/me/Desktop/audioextract/dist/ffmpeg/ffprobe -show_streams file:/Users/me/Desktop/test.webm [17:14:38 CET] <BungeeTheCookie> and I get this error [17:14:39 CET] <BungeeTheCookie> https://hastebin.com/hiwejeleyu.js [17:14:40 CET] <BungeeTheCookie> help [17:16:31 CET] <kepstin> BungeeTheCookie: where did you get this ffmpeg binary from? looks like it's missing some dependencies [17:19:59 CET] <BungeeTheCookie> okay you're right I redownlaoded it and now it works :) [17:22:55 CET] <BungeeTheCookie> also kepstin where can I find ffmpeg binaries without mp4 / GPL enabled [17:24:36 CET] <kepstin> I don't know of any lgpl builds for mac os x offhand. you might have to build it yourself. [17:25:11 CET] <kepstin> (also, i assume you're refering to libx264 for h264 encoder? mp4 container and h264 decoding are available in an LGPL build) [18:15:59 CET] <_Vi> CyberShadow, Thanks for the suggestion. [18:18:36 CET] <rnmhdn> another: no, I don't really know what I'm doing:)) [18:21:25 CET] <kepstin> brimestone: do you want to copy the video? if so, change "-codec copy" to "-codec:v copy", that way it's *only* copying the video and can encode the audio. [18:22:12 CET] <brimestone> thanks let me check it. [18:57:51 CET] <BLZbubba> hi guys what is the easiest way to make a video from a single image file, e.g.: https://www.youtube.com/watch?v=3ZsNRKHWqWk [18:59:19 CET] <brimestone> kepstin: It finished without any errors, but I can't hear the 40Hz tone either left or right audio [19:00:58 CET] <another> rnmhdn: i suggest the wiki articles https://trac.ffmpeg.org/wiki/Encode/H.264 https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio [19:02:20 CET] <kepstin> brimestone: was your input stereo? if so, amerge would have put the sine into the 3rd audio channel, which might not work for you. [19:02:29 CET] <rnmhdn> I want to write videos into dvd [19:02:48 CET] <rnmhdn> I want to have the least size with relatively good quality:D [19:02:50 CET] <kepstin> brimestone: you might want to use the 'amix' filter instead, if your goal is to have both the original audio and the sine wave mixed together [19:02:57 CET] <rnmhdn> I don't need some 4k or something [19:03:10 CET] <kepstin> rnmhdn: do you want something playable in a hardware dvd player? [19:03:18 CET] <rnmhdn> something that looks not bad is fine, the quality I get in 1080 movies is fine. [19:03:24 CET] <rnmhdn> kepstin: no. [19:03:41 CET] <rnmhdn> I also want to stream dash [19:03:49 CET] <rnmhdn> actually my main problem is the dash streaming [19:04:12 CET] <kepstin> rnmhdn: right then, to fit a video onto a dvd, just encode it with libx264 in 2-pass mode with a bitrate calculated to give the desired target size. [19:05:40 CET] <rnmhdn> for example I have a 3h movie which is 1GB [19:06:01 CET] <rnmhdn> can I achieve the same ratio of quality and size on a dash video? [19:07:47 CET] <rnmhdn> this is ffmpeg -i for that file: https://termbin.com/5hgx [19:08:54 CET] <_Vi> BLZbubba, Example making single-frame 10-second video: ffmpeg -safe 0 -f concat -r 0.1 -i <(echo file pic.png; echo file pic.png) -pix_fmt yuv420p -c libx264 -y output.mkv [19:09:11 CET] <BLZbubba> _Vi: perfect thanks! [19:09:48 CET] <_Vi> BLZbubba, Note that the lack of intermediate frames sometimes breaks other tools and players. FPS=0.1 is extreme, typical FPS is 15 to 60. [19:10:10 CET] <kepstin> rnmhdn: depends what exactly your goal is with the dash streaming. in some cases for streaming - in order to be able to seek, to minimize bursts of high required bitrate, and to allow quality switching, you will want a shorter keyframe interval or even fixed keyframes [19:10:26 CET] <kepstin> rnmhdn: and setting shorter keyframe interval does reduce the quality per bitrate ratio. [19:11:21 CET] <kepstin> rnmhdn: if bandwidth/buffering isn't a concern and you don't need quality switching, you could probably get away with just copying the encoded video data from your original file, and so it's the exact same quality/size [19:12:08 CET] <rnmhdn> bandwidth is not a concern [19:12:16 CET] <rnmhdn> the only problem is the size it takes on my server [19:12:49 CET] <rnmhdn> for example this is ffmpeg -i for one of my videos: [19:12:56 CET] <rnmhdn> https://paste.ubuntu.com/p/v7GZFNYXxw/ [19:13:02 CET] <rnmhdn> https://paste.ubuntu.com/p/45t5KSgQ6h/ [19:13:57 CET] <kepstin> alright, so you've got some 10-15mbit/s 1080p videos... [19:15:05 CET] <kepstin> no way to tell the encoder settings those were made with, it's possible that you could potentially re-encode them with slow x264 settings to make them slightly smaller without visibly reduced quality... but you'd have to try and see. [19:19:11 CET] <rnmhdn> no [19:19:13 CET] <rnmhdn> lol [19:19:16 CET] <rnmhdn> not at all [19:19:19 CET] <another> that termbin link has mono audio. urg.. [19:19:25 CET] <rnmhdn> my videos are super large [19:19:30 CET] <another> how can you live with that ;) [19:19:58 CET] <rnmhdn> eg [19:20:04 CET] <rnmhdn> this one I send you is 3.4GB [19:20:17 CET] <rnmhdn> and it's only 40MB [19:21:29 CET] <kepstin> rnmhdn: so, what's your goal here? [19:22:15 CET] <kepstin> do you have a particular target size for the videos? or just want them to be "as small as possible" at a target quality? [19:22:21 CET] <rnmhdn> I want to achieve a ratio like movies that I watch [19:22:29 CET] <rnmhdn> good quality 3GB 3h [19:22:38 CET] <rnmhdn> as small [19:22:54 CET] <rnmhdn> and when I do research I see a lot of ideas and things but I don't know if I'm using them or not [19:23:12 CET] <kepstin> well, there's two options: you can either pick a final size, and tell the encoder to make the quality as good as possible for that size, or you can pick a final quality, but then the size will be whatever the encoder gives you. [19:23:14 CET] <rnmhdn> eg down sampling colors and assigning high bitrate for luminance [19:23:23 CET] <kepstin> rnmhdn: probably read through https://trac.ffmpeg.org/wiki/Encode/H.264 to start with [19:24:12 CET] <rnmhdn> I will [19:24:17 CET] <kepstin> rnmhdn: none of your videos are hdr, so that doesn't matter. your videos are already yuv420p, so don't bother changing any subsampling or anything [19:24:34 CET] <rnmhdn> but If you know some good options that I could use in adobe primier pro, ffmpeg, handbrake [19:24:40 CET] <rnmhdn> I would really appreciate it [19:24:51 CET] <rnmhdn> https://termbin.com/jcrs [19:25:07 CET] <rnmhdn> this is the info for my 3.4GB 36minute video [19:25:08 CET] <kepstin> rnmhdn: so in the end, the recommendation is basically "encode your videos with libx264 using the slowest setting for -preset that you can stand, and with a -crf setting that gives a quality you're ok with" [19:25:10 CET] <kepstin> that's it. [19:25:33 CET] <rnmhdn> can you elaborate on slow preset? [19:25:39 CET] <rnmhdn> what does it mean? [19:25:41 CET] <kepstin> rnmhdn: read the wiki doc i linked [19:26:10 CET] <rnmhdn> and then I simply convert that to dash with mp4box os somesuch? [19:26:14 CET] <rnmhdn> the dash part doesn't matter? [19:26:44 CET] <rnmhdn> because when I converted some if these videos to dash and played them on my local browser they were not so good [19:26:50 CET] <kepstin> depends on the requirements of your dash player and network, which you haven't specified [19:27:02 CET] <rnmhdn> I'm using dashjs [19:27:13 CET] <rnmhdn> I'm open to anything opensource for the dash part [19:27:18 CET] <kepstin> note that if you're not doing quality switching or anything, there's no point in dash - just encode to an mp4 file with "-movflags faststart" [19:27:25 CET] <rnmhdn> and my bandwidth is very very good [19:27:43 CET] <rnmhdn> but the space I have for storing the videos is very expensive [19:27:57 CET] <rnmhdn> so I want them to be as small as possible [19:28:30 CET] <rnmhdn> I don't need quality switching [19:28:54 CET] <kepstin> well, bandwidth and space are the same thing. so if space is expensive, you need to use less bandwith. [19:28:56 CET] <kepstin> The other part of the equation is time - how much time can you spend encoding videos and how fast is your cpu. [19:28:57 CET] <rnmhdn> but I still need dash because of other things like inserting something or removing something from the video [19:29:31 CET] <rnmhdn> kepstin: I mean my harddisk on my server is limited [19:29:37 CET] <rnmhdn> but the bandwidth of the server is very much [19:30:02 CET] <rnmhdn> as for the cpu part. I don't actually know. right now I have about 150GB of video. [19:30:02 CET] <kepstin> file size = bitrate * length [19:30:11 CET] <rnmhdn> I need to get it done in 3-4 days [19:30:14 CET] <kepstin> so for higher bitrate (= higher bandwidth), you get higher size [19:30:16 CET] <rnmhdn> I could rent rigs if needed [19:30:48 CET] <kepstin> anyways, start playing around with x264 options to find something that fits your need. there's no "one size fits all" thing, because every use case is different [19:31:25 CET] <kepstin> x264 is super easy to use, the only options you need to set is -preset (to adjust how much time to spend encoding video) and either -crf (to adjust target quality) or bitrate options (if you want to target a specific file size) [19:58:07 CET] <ober> are there any ffmpeg related tools that can do video stabilization? [19:59:36 CET] <another> https://ffmpeg.org/ffmpeg-all.html#vidstabdetect-1 [19:59:53 CET] <ober> ty [21:23:50 CET] Action: kylemson slaps arps around a bit with a large trout [21:25:25 CET] <kylemson> Hi All, I'm trying to watermark a video and this works fine "ffmpeg -y -i /tmp/videofile.mp4 -i /tmp/pngfile.png -filter_complex "overlay=x=(main_w-overlay_w)/2:y=(main_h-overlay_h)/2" -strict -2 /tmp/videofile2.mp4", but i need to tone down the opacity of the watermark, how can i adjust this command to do this? [21:34:03 CET] <rnmhdn> kepstin: thank you for you advices:) I will look into them tomorrow:) sorry I was so busy I had to go. [21:36:57 CET] <kepstin> kylemson: use imagemagick or gimp to reduce the opacity of the png first? :) [21:38:25 CET] <arps> kepstin: the image already has a transparent background and consists of some white text...is it possible to reduce the white text opacity still? [21:38:37 CET] <arps> kepstin: i was under the impression that there's just one transparency layer in a png [21:39:02 CET] <kepstin> png images have an alpha channel, each pixel can have arbitrary amount of transparency set [21:39:44 CET] <kepstin> there probably is a way to adjust this in ffmpeg, but i don't know which filter you'd need for it [21:40:12 CET] <arps> well the png is always the same one anyway so it would be fine to do it your way... just need to figure out *how* :D [21:40:32 CET] <arps> kepstin: I'm working with kylemson on this one so that's why i'm answering for him, he's a bit shy [21:41:19 CET] <kepstin> it looks like you could use the colorlevels filter in ffmpeg to do this, by setting the "aomax" parameter to limit the opacity of the output. [21:42:16 CET] <kepstin> so something like -filter_complex '[1:v]colorlevels=aomax=0.5[img];[0:v][img]overlay=<your options here>' [21:42:22 CET] <kepstin> adjust the 0.5 to taste [21:42:35 CET] <arps> kepstin: we're trying imagemagick this second but will try that if it's a no go, much appreciated [21:44:27 CET] <kepstin> you might also consider using the 'blend' filter rather than 'overlay' depending on the effect you're going for, blend supports some stuff like image editor layer modes. [21:50:03 CET] <arps> kepstin: I think we have a winner with the first suggestion, thank you for your help with this [00:00:00 CET] --- Thu Mar 14 2019

1 0

ffmpeg-devel.log.20190312
by burek 13 Mar '19

13 Mar '19

[00:50:15 CET] <cone-641> ffmpeg 03Andreas Rheinhardt 07master:3f086a2f665f: avcodec/mpeg4videodec: Fix nonsense warning [00:50:15 CET] <cone-641> ffmpeg 03Michael Niedermayer 07master:d227ed5d5983: avcodec/mpeg4videodec: Check idx in mpeg4_decode_studio_block() [08:52:06 CET] <buhman> I was looking at https://github.com/ammen99/wf-recorder , and it seems like wlr-screencopy-v1 should just be implemented in ffmpeg, and exposed via `-f wlr-screencopy-v1` [08:53:00 CET] <buhman> would a well-written patch to add that be accepted, or is that considered "too new"? [08:57:51 CET] <JEEB> buhman: if it's a stable API and you add proper configure checks etc I don't see any reason WhyNot? [08:58:04 CET] <JEEB> without looking what that screen capture API is, of course [08:58:35 CET] <buhman> sure; seems like a fun project [09:03:26 CET] <JEEB> also talking of libavdevice, do any modules there use the "packed AVFrame" stuff? [09:04:18 CET] <JEEB> since stuffing raw video into AVPacket never felt too great since you couldn't put all of the colorspace info there [09:05:10 CET] <JEEB> ah, in avformat at least y4m encoder uses AV_CODEC_ID_WRAPPED_AVFRAME [09:06:02 CET] <JEEB> and the vapoursynth "demuxer" uses it as input [09:06:10 CET] <JEEB> surprising how few libavdevices use it, though [09:06:13 CET] <JEEB> (for input) [09:06:31 CET] <JEEB> oh, kmsgrab does :D [18:15:33 CET] <nevcairiel> jamrial: didn't we remove the block on tree vectorize some time ago? I added it to my own extra cflags at that point after all. [18:16:01 CET] <jdarnley> I recall it was allowed for a time [18:16:08 CET] <jdarnley> Then bogs like that came in [18:16:20 CET] <jdarnley> and the block was restored [18:16:21 CET] <durandal_1707> it is still not disabled for clang [18:16:38 CET] <nevcairiel> I think it's still allowed because bikeshedding [18:17:15 CET] <nevcairiel> Oh yeah and definitely only was GCC [18:18:56 CET] <jamrial> nevcairiel: we removed it but then readded it because gcc still generated crap code with it [18:19:07 CET] <nevcairiel> Apparently it is disabled now yeah [18:19:23 CET] <nevcairiel> But not for clang which the report is using [18:19:26 CET] <jamrial> and yeah, now that you mention it, -fno-tree-vectorize is checked for gcc only [18:19:43 CET] <jamrial> does that flag work with clang? [20:12:09 CET] <Gramner> is DECLARE_ALIGNED supposed to be part of the public API? including avformat.h redefines that macro if the code contains a macro with that name [20:12:48 CET] <Gramner> feels like it should either have an appropriate prefix or not be exposed in public headers [20:14:11 CET] <jamrial> it's not meant to be public [20:15:54 CET] <jamrial> no wait, mem.h, so looks like it is [20:17:50 CET] <jamrial> and yeah, it could use a prefix [20:21:41 CET] <Gramner> same goes for DECLARE_ASM_ALIGNED and DECLARE_ASM_CONST. I'm not sure the value of having those public [22:50:23 CET] <atomnuker> holy shit an aacenc patch from someone with an apple email [22:51:05 CET] <nevcairiel> I don't see anything [22:51:20 CET] <atomnuker> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/240867.html [22:51:49 CET] <nevcairiel> Oh that old one [22:51:56 CET] <atomnuker> also >made with git 2.20.1.windows.1 [22:52:33 CET] <nevcairiel> Mac.com is available for anyone, in case you're thinking he is an employee [22:52:52 CET] <nevcairiel> It's iCloud email [22:53:26 CET] <atomnuker> oic [22:53:55 CET] <atomnuker> I always thought mac.com was a fan website (or was at some point) but it redirects to apple [22:59:38 CET] <j-b> Oliver is really cool. [23:24:41 CET] <cone-280> ffmpeg 03James Almer 07master:dcf64b599d31: avcodec/libdav1d: route dav1d internal logs through av_log() [23:24:41 CET] <cone-280> ffmpeg 03James Almer 07master:2a31bf2a3507: avcodec/libdav1d: move the pix_fmt enum array up in the file [23:24:41 CET] <cone-280> ffmpeg 03James Almer 07master:28746a0e2088: avcodec/libdav1d: use a custom picture allocator [23:24:41 CET] <cone-280> ffmpeg 03James Almer 07master:36bb2cc200d0: avcodec/libdav1d: consistently use AVERROR return values [23:24:51 CET] <jamrial> nevcairiel: ^ [23:25:54 CET] <jamrial> the buffer pool based allocator should give it a slight boost, similar to how it would be once and if it gets ported as native decoder using get_buffer2 [23:32:35 CET] <atomnuker> I wonder why intel are not trying to add their av1 encoder to lavc as a wrapper, since they're trying to get their hevc one in [23:33:35 CET] <jamrial> not mature enough? [23:34:38 CET] <TD-Linux> also very nearly the same api, so once they get the hevc one through review they can copy paste [23:45:53 CET] <cone-280> ffmpeg 03Vittorio Giovara 07master:38a413213216: libdav1d: Add support for reading hdr10 metadata [23:45:54 CET] <cone-280> ffmpeg 03James Almer 07master:f6803cfbd2d7: avcodec/libdav1d: unref the frame on failure [23:46:05 CET] <jamrial> nevcairiel: color metadata ^ [23:49:08 CET] <BBB> woohoo dav1d patches [23:49:30 CET] <nevcairiel> neat jamrial [23:49:31 CET] <BBB> the sad thing is that "ffdav1d" is not faster than tools/dav1d b/c of the bufferpool [23:49:43 CET] <BBB> s/not/now/ [23:49:46 CET] <nevcairiel> heh [23:49:49 CET] <BBB> (wow that was freudian) [23:49:55 CET] <BBB> sorry [23:50:06 CET] <BBB> let me restate that just so it's clear: [23:50:12 CET] <nevcairiel> we like being faster [23:50:20 CET] <BBB> the sad thing is that "ffdav1d" is now faster tha tools/dav1d b/c of the bufferpool [23:50:30 CET] <BBB> maybe tools/dav1d needs a bufferpool also ;) [23:50:32 CET] <nevcairiel> is the dav1d executable assumed to even get any real world use? [23:50:54 CET] <BBB> no, but if it helps cheat performance tests I'm happy [23:51:05 CET] <BBB> I guess we can also just use ffmpeg -c:v libdav1d [23:51:29 CET] <jamrial> google uses it for something, seeing they requested annex-b support for it [23:53:36 CET] <nevcairiel> i'll update my ffmpeg copy tomorrow and pull in dav1d instead of aom [23:54:08 CET] <jamrial> and a buffer pool in dav1d would not be cli exclusive. it would benefit any library user that doesn't implement their own allocator [23:55:50 CET] <atomnuker> nevcairiel: I don't think you can disable the libaom decoder and its always that one which gets chosen by default [23:56:40 CET] <nevcairiel> i can build without aom =P [23:57:34 CET] <jamrial> you sure can disable it. and it get chosen by default because of ordering in codec_list.c [23:57:51 CET] <jamrial> we could swap the order at this point, i guess [23:57:54 CET] <nevcairiel> i dont build any encoders, so i'll just throw out aom [00:00:00 CET] --- Wed Mar 13 2019

1 0

ffmpeg.log.20190312
by burek 13 Mar '19

13 Mar '19

[00:04:06 CET] <AuroraAvenue> systemd0wn, Its too complicated (I'm really an XP user :( ) ... [00:04:41 CET] <AuroraAvenue> If the two webm files are in the same directory cant you just give me he file command line reference, for ease ? [00:05:40 CET] <systemd0wn> AuroraAvenue: Try this StackOverflow link then https://stackoverflow.com/a/11175851/2171182 they have commands listed. [03:18:11 CET] <ossifrage> What is the proper way to do what avformat_find_stream_info() does, but with the frame data from memory? I have the correct NALUs in a buffer, but I'd rather have libavformat parse it then do it my self. [03:32:16 CET] <ossifrage> I looks like I found what to do in libavformat/dashdec.c [04:14:00 CET] <damdai> is there a website where i can upload a video where video quality is not downgraded [04:27:44 CET] <another> probably any website which does just "files" and not "video" [04:37:09 CET] <dustsquid> vimeo if you follow their guideline [04:37:43 CET] <dustsquid> https://vimeo.com/help/compression [04:40:32 CET] <furq> i'm pretty sure vimeo reencodes everything [04:42:08 CET] <dustsquid> they host very high quality videas and have built their entire reputation on that [04:42:26 CET] <dustsquid> assuming you encode to their standards I don't see any reason why they would re-encode [04:42:48 CET] <dustsquid> they certainly re-encode to support other resolutions [04:43:09 CET] <dustsquid> but your source should be fine [04:44:48 CET] <furq> https://vimeo.com/blog/post/untangling-the-knotty-myths-of-video-compression [04:44:49 CET] <furq> #5 [04:46:41 CET] <dustsquid> I am wrong and you are absolutely correct [04:46:48 CET] <dustsquid> apparently I have been believing the myth [05:50:36 CET] <damdai> why does ffplay take so much CPU usage playingback 2k video 50%, when i play with vlc it takes only 5% [06:10:00 CET] Last message repeated 1 time(s). [06:11:05 CET] <mozzarella> I don't know [06:27:28 CET] <mikemocha> anyone know where to obtain a Linux 64 bit static ffmpeg built with nvenc support? [06:27:51 CET] <damdai> what is nvenc ? [06:29:33 CET] <mikemocha> https://trac.ffmpeg.org/wiki/HWAccelIntro [07:44:02 CET] <ossifrage> It seems like avformat_open_input()/avformat_find_stream_info() don't honour AVFormatContext.probesize, it kept reading until it had consumed everything in my avio buffer. [07:46:35 CET] <ossifrage> Hmm, it seems to be some sort of interaction between the probsize, and the buffer_size passed to avio_alloc_context [07:47:50 CET] <ossifrage> When probesize == buffer_size, it keeps reading until the buffer is exhausted [09:39:57 CET] <damdai> i have a 10 minute video and from 6 minute point to 8 minute point, i want to mute the audio: is this possible to do with ffmpeg? [09:42:36 CET] <JEEB> pretty sure you can do that with libavfilter, check the filters part of ffmpeg-all.html [10:48:01 CET] <AhirPK> hi, can anyone please tell me what did i do wrong here? [10:48:08 CET] <AhirPK> filter graph: https://pastebin.com/dVhx1uTJ [10:48:34 CET] <AhirPK> [afifo @ 0x9cd880] Format change is not supported [10:48:34 CET] <AhirPK> Error while feeding the filtergraph [10:48:40 CET] <AhirPK> i am getting this error [11:01:43 CET] <CyberShadow> AhirPK: Mostly guessing but is your audio input in FLTP? [11:02:17 CET] <CyberShadow> Posting the command / code that resulted in said graph might be helpful [11:03:58 CET] <AhirPK> CyberShadow: input file https://pastebin.com/V8dG7GXH [11:04:23 CET] <AhirPK> code: https://www.dropbox.com/s/eojzuw78s7zemzt/main.c?dl=0 [11:04:50 CET] <AhirPK> output https://i.stack.imgur.com/JR30E.png [11:05:42 CET] <AhirPK> and here is detailed explanation of my problem in stack overflow https://stackoverflow.com/questions/55115335/getting-error-in-ffmpeg-comple… [11:06:48 CET] <CyberShadow> I am not an ffmpeg developer but what I would do is change where the error is produced in avfilter.c to print the given and expected formats [11:09:22 CET] <JEEB> you can dump the config with an avfilter command after you've configured the chain [11:10:07 CET] <JEEB> generally I recommend deciding before hand what you want as the output formats, and waiting for the initial AVFrame from the audio decoder to set the input parameters [11:10:54 CET] <JEEB> I know stuff like stereo <-> 5.1 should work as far as switching goes [11:11:03 CET] <JEEB> (although this depends on the input filter maybe :P) [11:11:33 CET] <JEEB> (the actual resampling filter does support reconfig as far as I can tell) [11:17:37 CET] <AhirPK> JEEB: yes correct I can dump filter chain [11:18:12 CET] <AhirPK> and i thought showvolume filter works only on fltp format [11:18:16 CET] <AhirPK> is it true? [11:19:19 CET] <CyberShadow> Looks like it: https://github.com/FFMpeg/FFmpeg/blob/master/libavfilter/avf_showvolume.c#L… [11:20:58 CET] <AhirPK> and i have set all output parameters as per requirements and inputs are dynamic [11:21:58 CET] <AhirPK> CyberShadow: correct, thats why I have added fixed sample format in aformat filter [13:52:35 CET] <Momentum> Hi, anyone knows if there's a way to record i3 workspaces? [13:52:45 CET] <Momentum> or like a specific workspace [13:53:36 CET] <justinasvd> Morning! [13:53:51 CET] <JEEB> mornin' [13:56:50 CET] <justinasvd> I am having a problem with av_read_frame. Basically, it hangs indefinitely when it stops receiving frames from "pipe:". I tried to implement timeouting via fmtctx interrupt_callback, but it doesn't help. [13:57:40 CET] <justinasvd> Any other approaches? How to implement forced timeout for av_read_frame? [13:58:41 CET] <BtbN> av_read_frame just uses whatever avio you gave the underlying format. So you'll probably have to write your own. [13:58:46 CET] <JEEB> I know file followed the rw_timeout thing but not sure if pipe does that [13:58:48 CET] <BtbN> The default one is blocking. [13:58:58 CET] <JEEB> and yes if you need custom AVIO I recommend implementing the callacks [13:59:00 CET] <JEEB> *callbacks [13:59:08 CET] <JEEB> I think we might even have an example of that under doc/examples [14:00:05 CET] <justinasvd> Would be greatly appreciated. [14:06:21 CET] <ossifrage> Finally getting closer to having mp4 streaming from this camera... [14:06:59 CET] <BtbN> mp4 isn't exactly streamable [14:07:10 CET] <ossifrage> BtbN, fmp4 [14:07:30 CET] <BtbN> I'd rather have a stream with... really anything else [14:07:59 CET] <ossifrage> I'm using dash for the rate adaption stuff [14:08:25 CET] <BtbN> Can't dash do .ts? [14:08:46 CET] <ossifrage> The overhead of a transport stream kills any benefits [14:09:28 CET] <ossifrage> I may end up doing rtsp if I can't get the dash stuff to work well enough [14:10:08 CET] <ossifrage> Especially if I can't get the start latency down below 1s [14:10:56 CET] <ossifrage> I was seeing about 400-500ms sensor to display latency with IBBP h.26[45] [14:11:16 CET] <BtbN> I think that's pretty much impossible with those fragments formats due to the way they work [14:11:31 CET] <BtbN> Twitch is doing some really hacky proprietary HLS extensions to achive ~1 second latency [14:12:08 CET] <ossifrage> I wonder what the breakdown of the latency is for them? [14:12:23 CET] <ossifrage> I was getting 500ms streaming over ssh [14:12:27 CET] <BtbN> They basically tell the player to play segments that don't exist yet [14:12:33 CET] <BtbN> And it just so happens to work out [14:14:28 CET] <ossifrage> I was hoping to be able to hide the startup latency with a lower resolution stream (with smaller GOPs and no B) but that will require the player to cooperate [14:14:30 CET] <Momentum> anyone knows how to record a specific i3 workspace? [14:14:44 CET] <Momentum> or if that is an option [14:16:08 CET] <BtbN> I don't think startup latency depends on the resolution or bitrate. [14:16:18 CET] <ossifrage> BtbN, does that twitch 1s include transcoding or are they able retransmit what the user sends? [14:16:26 CET] <BtbN> It's the source stream [14:16:32 CET] <BtbN> The transcodes have a couple seconds more delay [14:16:49 CET] <ossifrage> BtbN, the lower resolution saves bits to I can afford to have extra streams [14:17:33 CET] <ossifrage> The h.265 4k stream has long gops, the 1080p h.264 stream has shorter gops, but the 720p (or less) has short gops and no B [14:17:47 CET] <ossifrage> So you have more entry points into the 720 stream vs the higher res streams [14:18:04 CET] <BtbN> If you have a fragmented stream, each segments is an entry point anyway? [14:18:40 CET] <BtbN> So whatever is downloaded, can be played immediately either way. It will just be more es less behind. [14:19:27 CET] <BtbN> You will most likely never get a close to realtime stream with DASH/HLS. It's just not what they are designed for. [14:20:07 CET] <ossifrage> I think it is one of those things I need to see how it works first [14:20:36 CET] <ossifrage> If you want low latency you can watch bloody m-jpeg :-) [14:21:01 CET] <ossifrage> I was sorta amazed how well chrome was playing back 45mbps motion jpeg [14:21:28 CET] <ossifrage> I pointed the camera at a mentronome and I didn't see any stutter [14:22:05 CET] <ossifrage> I remember doing that same test some years back and it was jitter central [14:22:20 CET] <BtbN> Why would it be? mjpeg isn't very hard on the CPU or anything [14:22:58 CET] <ossifrage> I think the problem at one point was that the jpeg decoder sucked [14:23:30 CET] <ossifrage> chrome still has an annoying bug that they won't output a frame until they receive the next one which really pisses me off [14:24:04 CET] <ossifrage> (firefox doesn't have that problem, but it doesn't seem to do nearly as good of a job doing the stream/decode/playback [14:25:07 CET] <ossifrage> I still need to figure out how to dial down the TCP window for a go http connection so it drops earlier [14:26:49 CET] <ossifrage> I'd assume the firefox playback problems are that they suck at nvidia GPU on linux, whereas chrome is gpu heavy [14:27:07 CET] <BtbN> Both Firefox and Chrome do not support hardware acceleration on Linux. [14:27:26 CET] <BtbN> They gave up due to too many driver issues [14:27:54 CET] <ossifrage> The last I checked chrome makes heavy use of the GPU, I'm not sure if it bothers with the hardware decoders though [14:29:16 CET] <ossifrage> Chrome has: #enable-webrtc-h264-with-openh264-ffmpeg [14:29:27 CET] <BtbN> That's an encoder. [14:30:14 CET] <ossifrage> "When enabled, an H.264 software video encoder/decoder pair is included. If a hardware encoder/decoder is also available it may be used instead of this encoder/decoder. Mac, Windows, Linux, Chrome OS" [14:31:04 CET] <BtbN> They both definitely do not support any hwaccels on Linux [14:31:17 CET] <BtbN> Too many APIs, too many driver issues. [14:31:26 CET] <ossifrage> Hardware Protected Video Decode: Hardware accelerated [14:31:34 CET] <BtbN> I highly doubt that [14:31:46 CET] <ossifrage> That is what chrome://gpu/ says [14:31:53 CET] <BtbN> Specially as there are patched versions of Chromium to force-enable VAAPI and the like. [14:32:12 CET] <BtbN> Hardware Protected Video Decode is probably DRM stuff, not hwaccel. [14:33:14 CET] <BtbN> "Video Decode: Hardware accelerated" is the flag you want [14:33:20 CET] <BtbN> and it's definitely not a thing on Linux [14:33:44 CET] <BtbN> And according to this, the option even straight up lies on Linux: https://www.omgubuntu.co.uk/2018/10/hardware-acceleration-chrome-linux [14:33:51 CET] <BtbN> no idea how reliable of a source that is [14:36:01 CET] <ossifrage> Ouch... Well the software decoders work surprisingly well on this very old machine [15:54:30 CET] <flowgunso> is ffmpeg supposed to return exit codes other than 0 ? [15:55:03 CET] <flowgunso> im trying to convert a file, expecting it to fail. it fails but the exit code stays at 0. [15:55:17 CET] <JEEB> yes it will [15:55:25 CET] <JEEB> as in, return nonzero [15:55:44 CET] <flowgunso> well it does return 0. always. [15:55:55 CET] <flowgunso> even on failures [15:56:07 CET] <JEEB> ok, then whatever happened was not considered failure by ffmpeg.c [15:56:52 CET] <flowgunso> JEEB, give me a mn, i'll pastebin [16:02:53 CET] <flowgunso> JEEB, pastebin.com/YvPPFDn8 [16:03:05 CET] <JEEB> merci [16:03:24 CET] <JEEB> also i wihs [16:03:42 CET] <JEEB> wish my terminal client would pick that up as a link :p [16:03:54 CET] <JEEB> will check when i get home [16:04:16 CET] <flowgunso> merci, c'est pas pressé :) [17:12:38 CET] <ossifrage> To just multiplex h26[45] elementary streams to fmp4, is it necessary to pass avformat_new_stream() a AVCodec? [17:13:16 CET] <ossifrage> To do that I needed to call avcodec_find_encoder() which requires linking against libavcodec, which I'd like to avoid [17:13:42 CET] <JEEB> I'm still waiting for my dev VM to boot up, but I'm pretty sure not. you just need to set the AVCodecID and other parameters for the stream's codecpar [17:14:28 CET] <ossifrage> that seemed to work, but for small values of work [17:15:32 CET] <JEEB> it's simpler with an already available thing since there's helpers that set everything from a decoder or encoder context, but it should work 100% the same as long as you set all the required data [17:15:44 CET] <DHE> avformat doesn't get directly involved with the codec operation anymore. just fill in the AVStream->codecpar fields ahead of avformat_write_header() [17:16:18 CET] <JEEB> required data being the fields and buffers in the stream's codecpar :P [17:17:25 CET] <ossifrage> Once I deal with the buildroot issues I'm only going to build libavformat (well at least only install it) [17:17:48 CET] <JEEB> do note that depending on requirements you might need BSFs and I think those are in avcodec [17:17:55 CET] <JEEB> f.ex. if your encoder's output is Annex B [17:18:01 CET] <JEEB> and you need AVCc [17:18:11 CET] <JEEB> although I don't remember if that way was automated within movenc [17:18:46 CET] <DHE> annex b is more for mpegts I thought... [17:18:49 CET] <JEEB> yes [17:18:57 CET] <JEEB> I just didn't remember which way the bsf was [17:19:03 CET] <JEEB> and which way there was auto-conversion within movenc [17:19:10 CET] <JEEB> or if there was any [17:19:37 CET] <JEEB> ok so teh BSF was the other way yes [17:19:41 CET] <JEEB> from AVCc to annexb [17:19:49 CET] <ossifrage> It is now linking with just avutil/avformat [17:20:12 CET] <JEEB> yea, there is ff_hevc_annexb2mp4_buf [17:20:14 CET] <JEEB> in movenc [17:21:50 CET] <ossifrage> I'm encoding h265, but I was having performance problems playing 4k back so I switch to h264 1080p until I can get more stuff working [17:22:27 CET] <ossifrage> The encoder on the hi3519a really isn't that bad, so much better then the last time I worked with a hisilicon part [17:33:45 CET] <JEEB> ossifrage: also it just bumped into my mind that the movenc test set is actually an API client doing something similar to what you're doing :P [17:34:05 CET] <JEEB> it uses pre-made pseudo-valid AVC buffers to mux stuff into fragmented isobmff [17:34:41 CET] <JEEB> libavformat/tests/movenc.c [17:46:10 CET] <ossifrage> JEEB, thanks, I'll take a look at it as soon as I can figure out why my buildroot ffmpeg is not happy [18:17:23 CET] <USian_nogoodnick> i'm using ffplay to display an rtsp stream, but it shows ffplay output in original terminal and shows stream in a new terminal window. how to make it display the stream in the original terminal window (replacing command output) instead? [18:18:27 CET] <Boobuigi> USian_nogoodnick: libcaca is one way [18:19:28 CET] <Boobuigi> ... that depends on what you mean by stream, though. You're talking about a video, right? [18:19:46 CET] <USian_nogoodnick> yes, rtsp video stream from ip cam [18:20:41 CET] <Boobuigi> Then libcaca--though not many people are bad-ass enough to actually desire video output in their terminals. [18:21:45 CET] <USian_nogoodnick> lol. well right now i'm using ffplay in 4 terminal windows as my nvr gui, basically. :) [18:22:28 CET] <USian_nogoodnick> i'll check libcaca out, thanks [18:31:27 CET] <USian_nogoodnick> i'm wondering if i'm misunderstanding what is happening when i run the ffplay command. what kind of window is ffplay using to show the video? is that a gtk window when one is using gnome? i thought it was another gnome terminal window. [18:31:50 CET] <Boobuigi> Oh boy. [18:32:47 CET] <USian_nogoodnick> ffplay docs just say sdl and ffmpeg. [18:32:48 CET] <furq> USian_nogoodnick: it's whatever sdl uses [18:33:01 CET] <furq> i think it's just a straight x11 window [18:33:08 CET] <USian_nogoodnick> i see thanks [18:36:09 CET] <faLUCE> Hello. What is the "app" field of a jpeg image? I have issues when decoding it [18:39:00 CET] <faLUCE> it seems something associated to "motion jpeg", but not to a "jpeg" image [18:40:59 CET] <USian_nogoodnick> my ultimate goal is to make my own gui for my ip cams, but right now i'm just trying to determine the easiest way to get 4 rtsp streams (ip cam video) in a grid in one desktop gui window. is ffmpeg best for the capturing part in this scenario or gstreamer? [18:57:46 CET] <mozzarella> I don't like gstreamer [18:57:50 CET] <faLUCE> USian_nogoodnick: do you have to write your code or do you want to use ffmpeg as a standalone app? [18:59:36 CET] <flowgunso> JEEB, have you taken a look to pastebin.com/YvPPFDn8 ? [19:00:58 CET] <JEEB> flowgunso: ok, so I think that hits the logic of "I tried to read this file as much as I could" -> zero exit code [19:01:03 CET] <JEEB> there's a parameter to try and make that more strict [19:04:15 CET] <mozzarella> guys [19:04:29 CET] <mozzarella> how can I speed up a video 240 times using ffmpeg [19:04:44 CET] <flowgunso> -loglevel trace or something? [19:05:46 CET] <USian_nogoodnick> mozzarella: out of curiosity: what don't you like about it? [19:07:05 CET] <USian_nogoodnick> faLUCE: at first, it would be nice to just be able to display 4 cam streams in one window using ffmpeg, if that's possible [19:07:23 CET] <Hello71> USian_nogoodnick: there is, but it would be easier to use a tiling window manager [19:08:29 CET] <mozzarella> USian_nogoodnick: there are some of my porn videos I've never been able to watch using gstreamer, I tried to solve the issue on my own and it's a pain in the ass to troubleshoot, never had a problem with ffmpeg [19:08:52 CET] <mozzarella> tells me I don't have the right codecs even though I do [19:08:54 CET] <mozzarella> ¯\_(Ä)_/¯ [19:09:24 CET] <mozzarella> seems to be a demuxing problem but no one understands what's going on [19:09:34 CET] <USian_nogoodnick> mozzarella: i see, thanks [19:10:39 CET] <USian_nogoodnick> Hello71: right now i'm using 4 ffplay windows and that's not really a big problem it's just that you have to have 4 terminal tabs open too. i suspect it would be the same with a tiling window manager? [19:10:50 CET] <Hello71> >terminal tabs [19:10:52 CET] <Hello71> wat [19:11:18 CET] <mozzarella> you can detach them from the terminal [19:11:32 CET] <mozzarella> and you'll get your prompt back so you can launch new ones in the same tab [19:12:07 CET] <USian_nogoodnick> mozzarella: this is the info i was after in the beginning. how do you do that? [19:12:29 CET] <mozzarella> with zsh I do [19:12:32 CET] <mozzarella> ffmpeg &! [19:13:04 CET] <mozzarella> there's also something called nohup [19:13:29 CET] <USian_nogoodnick> great, thanks [19:20:09 CET] <flowgunso> JEEB, -xerror works, thank you for your help ! [19:22:26 CET] <furq> USian_nogoodnick: you could potentially use xstack to tile the inputs together, but it's maybe not advisable if these are network streams [19:22:57 CET] <furq> if one stream drops out the whole thing will die, and any kind of packet loss or timestamp discontinuity will cause issues [19:23:46 CET] <furq> also you'd need to do this with ffmpeg and pipe it into whatever player because ffplay doesn't support multiple inputs [19:24:17 CET] <USian_nogoodnick> furq: interesting [19:53:48 CET] <ossifrage> Ugg, everything is cross connected, even thought it only linked against -llibavutil -llibavformat, it actually had a huge number of libs [19:54:34 CET] <ossifrage> ldd on my desktop counts 102 .so for a simple test program (not sure on the arm box, no ldd) [20:05:49 CET] <ossifrage> I finally tried running it and: "[NULL @ 0x23240] Requested output format 'mp4' is not a suitable output format" [20:25:42 CET] <TheAMM> Is the size in the status line "size= 6926kB time=00:04:50.51 bitrate= 195.3kbits/s speed=17.8x" kilobytes (1000) or kibibytes (1024)? [20:25:54 CET] <mozzarella> how can I speed up a video 240 times using ffmpeg [20:31:12 CET] <DHE> TheAMM: ffmpeg is careful about its use of bits vs bytes. Capital B means bytes. also k = 1000 exactly [20:31:26 CET] <DHE> mozzarella: like, super-high fps? [20:31:32 CET] <TheAMM> Thanks, just making sure [20:34:00 CET] <kepstin> mozzarella: in general, you use the setpts filter to adjust the frame timestamps to change the video speed, then use the fps filter to set your output framerate (dropping frames if needed) [20:34:44 CET] <kepstin> (some minor quirks in there depending on what timebase you're using and which particular frames you want to keep) [20:38:18 CET] <mozzarella> DHE: I don't mind having it play at the original framerate [20:39:43 CET] <mozzarella> they are sleep recordings I'm trying to speed up& so a video of 8 hours should play in 2 minutes [21:11:01 CET] <Boobuigi> My n4.1.1 installation gets GIF animation timings wrong. Please look: https://www.dropbox.com/s/21ormag6m6obzzi/FFmpeg%20GIF%20Timing%20Issues.mkv [21:11:30 CET] <Boobuigi> Here is the GIF used in the demonstration video: https://www.dropbox.com/s/glj72e9xq5zgo23/realTime.gif [21:12:25 CET] <Boobuigi> Can anyone confirm/deny that the same thing happens with their FFmpeg installation? [21:14:12 CET] <Boobuigi> The frames are only 0.01 seconds long. This seems to be related. [21:18:04 CET] <durandal_1707> Boobuigi: what is problem? [21:19:32 CET] <Boobuigi> durandal_1707: The timings are off. [21:19:46 CET] <Boobuigi> Each frame is should be 0.01 seconds long, but ffmpeg stretches them out much longer. [21:22:08 CET] <durandal_1707> Boobuigi: look at gif demuxer options [21:22:26 CET] <Boobuigi> durandal_1707: You mean fps, right? [21:22:28 CET] <durandal_1707> too low duration is extended by default [21:22:40 CET] <durandal_1707> Boobuigi: nope, min frame duration [21:22:59 CET] <Boobuigi> Ah! [21:23:05 CET] <durandal_1707> ffmpeg -h demuxer=gif [21:23:29 CET] <Boobuigi> The default is 2, hehe. Thanks for steering me in the right direction. [21:31:41 CET] <Boobuigi> durandal_1707: That did the trick! Thank you. [23:29:06 CET] <cryptopsy> test [23:30:15 CET] <cryptopsy> how do i get ffmpeg to only output the files being created when breaking up a video into a series of frames (one image every 30s for example) ? [23:31:52 CET] <kepstin> cryptopsy: it might have a debug log if you turn the log level up high enough, but I wouldn't rely on parsing that [23:32:10 CET] <cryptopsy> the info is in the regular output but i want to get rid of the other stuff [23:32:54 CET] <cryptopsy> basically the names of the files being created when doing %o1d.png [23:33:17 CET] <kepstin> you could also consider using an OS file notification api (e.g. inotify on linux) to notice when new files are written, rather than getting it from ffmpeg [23:33:55 CET] <cryptopsy> how do i do that? [23:34:11 CET] <cryptopsy> it would have to run in parallel as the ffmpeg command [23:34:36 CET] <kepstin> well, i don't know what you need this list for [23:34:48 CET] <cryptopsy> i want to know how far along the ffmpeg command is running [23:34:55 CET] <cryptopsy> so it has to be real-time [23:35:21 CET] <kepstin> then you'd need something running in parallel anyways? [23:35:33 CET] <cryptopsy> i think your approach is wrong [23:36:05 CET] <kepstin> if you were making a tool to consume the images that ffmpeg was outputting, my idea might make sense. [23:36:32 CET] <kepstin> but if you just want progress... iirc there was a way to enable machine-readable stats output? wouldn't have the filenames, but it should have a frame counter [23:37:30 CET] <kepstin> the separate file output isn't a common use case, so there's no real special handling for that. [23:37:59 CET] <cryptopsy> i think i can pipe with &| to while IFS= read -r l; do [23:44:33 CET] <cryptopsy> how can i ouput just %{frame_num} ? [23:46:30 CET] <kepstin> cryptopsy: no way as far as I know. no matter what, you're probably gonna have to parse some of the ffmpeg output. [23:46:50 CET] <cryptopsy> thats fine but i would like to get a line for each frame [23:47:43 CET] <cryptopsy> maybe with progress pipe:1 [23:47:48 CET] <cryptopsy> -progress pipe:1 [23:48:09 CET] <kepstin> the progress output is rate limited, updated about once a second [23:48:15 CET] <kepstin> which is fine for general progress output [23:48:41 CET] <kepstin> why do you need to know about each frame? [23:48:46 CET] <cryptopsy> just the numbre [23:48:56 CET] <cryptopsy> as an indicator of how far along the command is going [23:49:17 CET] <kepstin> then the -progress output should be fine, I think the current frame number is something it includes [23:51:05 CET] <cryptopsy> what if i want better resolution than 1 second? [23:54:53 CET] <kepstin> use libavcodec and friends directly as a library. [23:55:48 CET] <kepstin> you could also try enabling the human-readable stats output, which updates more often, but note that its format is not stable between ffmpeg releases, so it's hard to reliably parse. [23:57:33 CET] <cryptopsy> when i pipe to grep it outputs line by line but when i pipe to set it waits for the command to finish before ouputting all lines [23:59:59 CET] <kepstin> the stats output has lines separated with \r (carriage return) not \n (line feed), your application has to handle that correctly [00:00:00 CET] --- Wed Mar 13 2019

1 0

ffmpeg-devel.log.20190311
by burek 12 Mar '19

12 Mar '19

[01:17:47 CET] <cone-755> ffmpeg 03Diego Biurrun 07master:7e5bde93a1e7: build: Rename OBJDIRS variable to OUTDIRS [01:17:48 CET] <cone-755> ffmpeg 03Diego Biurrun 07master:e22ffb3805f6: tests: Unify output directory creation [01:17:49 CET] <cone-755> ffmpeg 03James Almer 07master:06476249cd23: Merge commit '7e5bde93a1e7641e1622814dafac0be3f413d79b' [01:17:49 CET] <cone-755> ffmpeg 03James Almer 07master:1c9ac700dd14: Merge commit 'e22ffb3805f6994bd1fd7ab73e6297f36a53f915' [02:21:45 CET] <cone-755> ffmpeg 03Diego Biurrun 07master:862914981693: tests: Drop duplicate variable declaration [02:21:46 CET] <cone-755> ffmpeg 03James Almer 07master:44085b9951b0: Merge commit '8629149816930a43bf5a66b11c6224446cabd044' [02:24:17 CET] <cone-755> ffmpeg 03Diego Biurrun 07master:dad5fd59f3d6: tests: Enable CRC test for yuv4mpeg [02:24:18 CET] <cone-755> ffmpeg 03James Almer 07master:bad70b7af6b9: Merge commit 'dad5fd59f3d6a8311365314cfcde0ebcd15c2b01' [02:33:44 CET] <cone-755> ffmpeg 03Diego Biurrun 07master:5846b496f0a1: tests: Use a predefined function for lavf-rm test [02:33:45 CET] <cone-755> ffmpeg 03James Almer 07master:5ab44ff20cdc: Merge commit '5846b496f0a1dd5be4ef714622940674305ec00f' [08:42:59 CET] <j-b> 'tsup [11:59:54 CET] <JEEB> can someone give me a quick run-down on LATM AAC vs ADTS AAC? [12:00:09 CET] <JEEB> since it seems like more and more places are moving to LATM (for some reason) [12:30:34 CET] <nevcairiel> both are simple containers around raw AAC streams [12:30:41 CET] <nevcairiel> LATM is more complex and supports more features [12:32:04 CET] <nevcairiel> LATM can theoretically contain multiple programs and multiple layers, whatever that exactly means, but ffmpeg only supports one of each [12:32:55 CET] <nevcairiel> I could see your 22.2 stream use LATM layers, perhaps. [12:37:30 CET] <kurosu> by now, I suppose 22 is not the actual number of channels, but also includes objects (ie 23008-3) ? [12:38:22 CET] <nevcairiel> well that wouldnt exactly be AAC anymore then [12:41:41 CET] <kurosu> well, the stream using AAC as an audio codec doesn't preclude it from being 23008-3? It's just that I haven't seen any atmos (which is already 3D audio) use more than 9.1.2 (or some such) [12:42:09 CET] <kierank> JEEB: latm is lower overhead [12:42:13 CET] <kurosu> "channel layout" (at least speaker setup) [12:42:23 CET] <kierank> JEEB: goes to painful lengths to save bits [12:42:28 CET] <kurosu> adding 10 more channels seems unlikely to be meant to be actual channels, that's what I meant [12:44:11 CET] <kurosu> but well, you tell me, I'm likely wrong, just want to get educated [12:44:12 CET] <nevcairiel> the latm header seems pretty long, it seems bigger then the ADTS header, but granted it also supports way more features [12:44:56 CET] <nevcairiel> the aac profiles that fit into adts are even severely limited because it only has a limited bit field for it [13:26:18 CET] <JEEB> kurosu: I'll be sure after I get the 22.2ch wagner 8K sample [13:26:26 CET] <JEEB> but it seemed to just be normal AAC [13:26:32 CET] <JEEB> with a 22.2ch map [13:26:43 CET] <JEEB> (possibly multiple AAC streams) [13:27:37 CET] <nevcairiel> that seems like a rather unlikely config for broadcast really [13:27:57 CET] <nevcairiel> mix it all down to stereo in the end? =p [13:28:08 CET] <JEEB> yea, it seems like just advertising [13:28:18 CET] <JEEB> I've demo'd the tech at NHK in 2017 [13:28:25 CET] <JEEB> it was cool [13:28:33 CET] <JEEB> but not something a normal person would have in his setup [14:21:39 CET] <J_Darnley> JEEB: you dont think you could sell people 22 channels? 22 is bigger than 6. [14:46:49 CET] <BBB> does anyone here have strong opinions on the closed-source thing? or do most people just not care so much? [14:47:50 CET] <atomnuker> I don't like it, I could somewhat understand if it was a codec no one is interested in but this is h264 [14:48:16 CET] <nevcairiel> I like being able to use my hardware with ffmpeg, which in many cases means supporting access to a closed-source driver. That easily opens the door to someone asking whats the difference between a driver and just some library [14:50:44 CET] <BradleyS> perception could be bad if you come off like american retail giants who move into town with low prices, take over by running smaller stores out of business, and then jack up the prices [14:51:26 CET] <BradleyS> if there's a current expectation that certain features are provided, and later there's a wholesale removal, it comes off malicious even if it's not [14:51:40 CET] <BradleyS> and comes off political even if it's not [14:51:54 CET] <BradleyS> not an argument for or against, just something to think about [14:53:00 CET] <BtbN> BBB, given how people are aggressively fighting some other closed source thing right now... [14:53:07 CET] <BradleyS> there's a balance with what's technically good, philosophically good, legally good, and good for the users/customers... shift too far to any extreme and it won't be received well by some group [14:53:48 CET] <BtbN> Only difference here is that it's for a hardware component. But the code needs quite some work from the looks of it. [14:55:44 CET] <BBB> nevcairiel: that's a good point, I've been worrying about the driver vs. lib thing also, not just in terms of my personal opinion, but in terms of if you put a dividing line there, then people will try to play (cheat) to get into the harware list [14:56:20 CET] <BBB> nevcairiel: it's also kind of a random line, it seems born out of convenience or necessity, I'm not sure I buy the system library thing when we're talking about custom hardware that nobody except BigCorps can afford [14:56:28 CET] <BBB> (as opposed to consumer-level nvidia cards) [14:56:37 CET] <BBB> so it's a very obscure line :-/ [14:57:05 CET] <nevcairiel> do we even have any bigcorp hardware support? [14:57:44 CET] <BBB> that matrox thing did not appear to be targeted at consumers [15:00:42 CET] <BradleyS> is any corp following a model where they keep things closed for a period of 2-5 years for market advantage and then open the source [15:01:07 CET] <BtbN> probably not, they're too afroid of patent lawsuites if people get to dig around in their code [15:01:19 CET] <BradleyS> yeah, tech patents in the us are a pain [15:01:45 CET] <BradleyS> i'm mostly opposed but at the least they should be cut to a period like the aforementioned instead of 20 years [15:32:39 CET] <iive> isn't there an open source implementation that we can replace the closed source one? [15:34:25 CET] <JEEB> IIRC NDI worked pretty hard to squish open source implementations, although I don't know the details of that [15:35:30 CET] <JEEB> and yes, in general the "letting non-OS closed source things in" thing should be cleared up. because right now it's grey and things like NDI can get pushed into FFmpeg due to not enough people caring [15:35:39 CET] <JEEB> one way or another I mean [15:40:02 CET] <j-b> BBB: it needs to be settled. [15:40:21 CET] <j-b> Last year at NAB and demuxed, everyone is standardizing around FFmpeg/libav [15:40:40 CET] <j-b> So everyone want to push their own crap on FFmpeg/libav and hope the project will maintain it for free for their customers [15:41:18 CET] <j-b> We (videolabs) receive one FFmpeg patch contract per week (we refuse most) and it is always the integration of a crappy non-open source library [15:42:38 CET] <j-b> Dolby, Zixi, NDI, DTS, Real and other folks [15:42:46 CET] <BBB> I'm trying to bring it up, but not really getting any traction so far :-p [15:42:56 CET] <j-b> "but our encoder is sooo amazing" [15:44:03 CET] <j-b> VVC and AAC-ULL-ELD [15:44:05 CET] <kurosu> dolby must be particularly delectable [15:44:15 CET] <kurosu> well, dts too [15:44:24 CET] <j-b> And I don't even speak about the new Dash extensions [15:45:00 CET] <j-b> and the new ATSC will be new crap over crap [15:45:15 CET] <JEEB> MMTP/TLV nîn [15:45:23 CET] <JEEB> such a clusterduck [15:48:55 CET] <nevcairiel> ATSC 3.0 is the worst crap in broadcast i've ever read [15:49:05 CET] <nevcairiel> i dont envy anyone trying to implement that independently [15:50:41 CET] <mayanksha> gsoc [15:52:46 CET] <j-b> nevcairiel: yeah, horrible [15:55:13 CET] <JEEB> nevcairiel: ATSC 3 is only one thing which contains the MMTP/TLV thingamajig [15:55:30 CET] <JEEB> also unlike ATSC 3 broadcasts, I'm seeing an unfortunate amount of JP content with that being aired xD [15:55:47 CET] <nevcairiel> well in my dayjob i dont really interact with asia [15:55:52 CET] <nevcairiel> but US we cover [15:55:53 CET] <JEEB> sure [15:55:56 CET] <nevcairiel> so that may eventually bite us [16:25:01 CET] <amaim_> Where can I find documentations about video/audio formats? for example the DHAV, I've been searching for a documentation(not about the code but about the file structure) about it and I can't find anything. [17:05:47 CET] <durandal_1707> amaim_: what you want to know about DHAV? [17:06:21 CET] <amaim_> The file structure, header contents,etc.. [17:06:45 CET] <amaim_> I'm trying to understand the DHAV code [17:06:49 CET] <durandal_1707> amaim_: that is proprietary info [17:07:06 CET] <durandal_1707> amaim_: is something wrong about it? [17:07:28 CET] <amaim_> No nothing wrong, I'm just trying to understand how demuxers work [17:07:58 CET] <amaim_> So I chose DHAV (I was told it's an easy example) to educate myself [17:08:18 CET] <durandal_1707> well its all in code [17:08:39 CET] <durandal_1707> and there are much easier examples [17:09:01 CET] <durandal_1707> and documented ones also, open source formats [17:09:06 CET] <amaim_> Can you tell me one? [17:09:11 CET] <amaim_> I was thinking maybe bmp [17:09:21 CET] <amaim_> But that's an image format, I want a video one [17:09:27 CET] <durandal_1707> matroska, nut, .... [17:09:40 CET] <durandal_1707> bmp is image codec [17:09:52 CET] <durandal_1707> not really codec actually [17:10:01 CET] <amaim_> Okay I'll check matroska, great. [17:10:22 CET] <amaim_> Thank you. [17:10:23 CET] <durandal_1707> amaim_: are your working on format or codecs? [17:11:15 CET] <amaim_> durandal_1707: I'm working on formats, my goal is to apply for the DICOM support project in GSoC [17:11:42 CET] <amaim_> or HEIF [17:11:44 CET] <jamrial> matroska demuxer is not the best introduction avformat demuxers... [17:13:01 CET] <amaim_> What would you suggest @jamrial ? [17:13:13 CET] <jamrial> an extremely simple one to get an idea of how to use the different callbacks is ivf [17:14:50 CET] <jamrial> another less trivial is caf [17:15:04 CET] <amaim_> Alright great, noted. thank you [00:00:00 CET] --- Tue Mar 12 2019

1 0

ffmpeg.log.20190311
by burek 12 Mar '19

12 Mar '19

[00:07:09 CET] <ongo> I'm not sure what I'm doing wrong here, but I'm getting option pixel_format not found: "( r=$(slop) ; ffmpeg -pix_fmt yuv420p -f x11grab -video_size $(cut -d + -f 1 <<<$r) -i :0.0+$(sed 's/.*+$.*$+$.*$/\1,\2/' <<<$r) tmp_vid.mp4 )" [00:08:06 CET] <CyberShadow> ongo: Move the "-pix_fmt yuv420p" to before the output file name [00:09:05 CET] <ongo> CyberShadow: though it is before [00:09:17 CET] <ongo> tmp_vid.mp4 is the output, which is at the end [00:11:20 CET] <CyberShadow> Strange, it works for me. [00:11:20 CET] <ongo> ah u mean right before it :D [00:11:29 CET] <ongo> ( r=$(slop) ; ffmpeg -f x11grab -video_size $(cut -d + -f 1 <<<$r) -i :0.0+$(sed 's/.*+$.*$+$.*$/\1,\2/' <<<$r) -pix_fmt yuv420p tmp_vid.mp4 ) this worked [00:15:00 CET] <ongo> hmm, this is getting weird: https://0x0.st/zHyq.txt [00:15:04 CET] <ongo> any ideas CyberShadow? [00:16:31 CET] <CyberShadow> Oh yeah, that [00:16:53 CET] <CyberShadow> chroma subsampling needs even coordinates. Needs a bit of arithmetics with the slop coords [00:17:34 CET] <ongo> 0.0 [00:18:09 CET] <ongo> I'm not too sure what to do here [00:18:12 CET] <ongo> [x11grab @ 0x55a0e4bf8f00] Stream #0: not enough frames to estimate rate; consider increasing probesize [00:18:14 CET] <ongo> Input #0, x11grab, from ':0.0+247,217': [00:18:16 CET] <ongo> Duration: N/A, start: 1552259680.371950, bitrate: N/A [00:18:18 CET] <ongo> Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 1029x812, 29.97 fps, 1000k tbr, 1000k tbn, 1000k tbc [00:18:20 CET] <ongo> File '/tmp/tmp_vid.mp4' already exists. Overwrite ? [y/N] y [00:18:22 CET] <ongo> Stream mapping: [00:18:24 CET] <ongo> Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264)) [00:18:26 CET] <ongo> Press [q] to stop, [?] for help [00:18:28 CET] <ongo> [swscaler @ 0x55a0e4c112c0] Warning: data is not aligned! This can lead to a speed loss [00:18:30 CET] <ongo> [libx264 @ 0x55a0e4c06840] width not divisible by 2 (1029x812) [00:20:34 CET] <CyberShadow> ( . <(slop -f 'x=%x;y=%y;w=%w;h=%h') ; w=$((w/2*2)) ; h=$((h/2*2)) ; ffmpeg -y -f x11grab -video_size ${w}x${h} -i :0.0+$x,$y -pix_fmt yuv420p out.mp4 ) [00:21:17 CET] <ongo> sweet, thanks! [00:26:33 CET] <ongo> is it possible to record to a new file? [00:26:37 CET] <ongo> for instance with mktemp? [00:29:05 CET] <CyberShadow> Sure, why not. What I like to do is use $(date +%s).mp4 or such for the file name [00:56:44 CET] <damdai> what is the command to exact subtitle file .mkv file that has subtitle file [01:21:23 CET] <CyberShadow> damdai: I don't know how to do it with ffmpeg but usually I'd use mkvextract for that [01:21:47 CET] <damdai> how do i do it with mkvextract [01:22:55 CET] <CyberShadow> `mkvextract tracks file.mkv`, find the track number, then `mkvextract tracks file.mkv 2:subtitles.ext`, replacing 2 with the track number for mkvextract [01:24:08 CET] <damdai> i see [01:24:40 CET] <damdai> ffmpeg cannot accomplish this? [01:25:21 CET] <damdai> C:\Program Files\MKVToolNix>mkvextract tracks R:\1.mkv [01:25:21 CET] <damdai> Error: Nothing to do. [01:25:33 CET] <CyberShadow> damdai: Checking Google finds this: https://superuser.com/questions/583393/how-to-extract-subtitle-from-video-u… [01:25:49 CET] <damdai> CyberShadow i already tried that [01:27:05 CET] <CyberShadow> Sorry the first command is not mkvextract, it's `mkvinfo file.mkv` [01:27:34 CET] <fling> JEEB: How should it be set from the commandline flags point of view? [01:28:05 CET] <JEEB> fling: you added an AVOption? [01:28:07 CET] <fling> JEEB: should I just hook the options to input flags like input bitrate? [01:28:31 CET] <damdai> C:\Program Files\MKVToolNix>mkvextract tracks R:\1.mkv 3:sub.srt [01:28:31 CET] <damdai> Error: No track with the ID 3 was found in the source file. [01:28:32 CET] <fling> Or should I use a separate flag for all the avoptions? [01:28:41 CET] <JEEB> I'm trying to figure out what you mean [01:28:48 CET] <fling> ok [01:29:06 CET] <CyberShadow> damdai: You need to use the "track ID for mkvmerge & mkvextract:" [01:29:15 CET] <fling> Should I make this work? -> ffmpeg -f v4l2 -b:v 300 -i /dev/video0 & [01:29:23 CET] <JEEB> the command line apps just take AVOptions like any other options and let you set them with the - in the front ("my_option PARAM" -> -my_option param) [01:29:40 CET] <JEEB> fling: uhh I thought trying to set the bit rate for inputs was some sort of global check :P [01:29:59 CET] <JEEB> which is why I recommended the AVOption style of having an AVOption called bit_rate or something [01:30:15 CET] <fling> JEEB: do you have a commandline example? [01:30:20 CET] <JEEB> ? [01:30:32 CET] <damdai> CyberShadow okay it worked using mkvextract tracks R:\1.mkv 2:R:\sub.srt eventhough mkvinfo says it's in track 3 [01:30:36 CET] <JEEB> if you added an AVOption to an input module, you set it before the input [01:30:51 CET] <JEEB> AVOptions literally become set'able from cli by default [01:30:58 CET] <JEEB> they should pop up under -h demuxer=v4l2 [01:31:03 CET] <CyberShadow> mkvtoolnix has two kinds of track IDs confusingly [01:31:03 CET] <fling> ohh [01:31:26 CET] <fling> so just ffmpeg -f v4l2 -bit_rate 300 -i /dev/video0 & ? [01:31:31 CET] <JEEB> yup [01:31:46 CET] <fling> thanks! this is what I wanted to know. [01:32:02 CET] <JEEB> it will attempt to set the bit_rate AVOption to the avformat context or the avcodec context [01:32:05 CET] <JEEB> basically [01:32:24 CET] <fling> Will try to patch things today. [01:32:25 CET] <JEEB> those that the lavf context ignores, it tries setting to the avcodec side [01:32:42 CET] <JEEB> (at least if I remember the logic correctly) [01:33:16 CET] <fling> It does not look proper for me maybe because I like the flags to be unified but it is just a different approach. [01:33:48 CET] <JEEB> fling: also I'm not sure if the bit rate AVCodec parameter ends up in the input module [01:34:04 CET] <JEEB> since you're dealing with a protocol/demuxer (whatever avdevice is) [01:34:38 CET] <JEEB> while setting a bit rate affects the bit rate in the relevant codec context(s) [01:34:57 CET] <fling> ok makes sense [02:03:38 CET] <damdai> i have this super weird situation/video: i have this video file that has a subtitle. but mediainfo/ffprobe doesn't show that it has a subtitle track: and only VLC can play this video with subtitles [02:04:17 CET] <damdai> how is this possible [02:12:56 CET] <Hello71> do you have an external sub file [02:13:43 CET] <damdai> no [02:16:59 CET] <damdai> only VLC shows the subtitle track : it shows as "EIA-608 subtitles (c608) [02:34:01 CET] <Hello71> do you have some ass-balls old ffmpeg [02:34:17 CET] <Hello71> try git master, there are binaries available [02:40:40 CET] <damdai> Hello71 huh? i am using latest version [02:40:55 CET] <Hello71> what is "latest" [02:41:00 CET] <damdai> 4.1.1 [02:41:02 CET] <Hello71> everybody always says they have the latest version [02:41:06 CET] <damdai> lol [02:41:15 CET] <damdai> and they don't? lol [02:41:22 CET] <Hello71> half the time it turns out they're on fucking debian oldstable or some shit [02:41:26 CET] <dongs> damdai: EIA608 is line21 VBI subtitles, what freaking video is this [02:41:40 CET] <damdai> dongs what do you mean? [02:41:46 CET] <dongs> i mean, its a thing from analog captures [02:41:47 CET] <Hello71> not all the time but often enough that it's annoying [02:41:57 CET] <dongs> like, it shouldn't be in a digital video? [02:42:24 CET] <dongs> oh looks like some apple shit used them [02:42:30 CET] <dongs> are you stealing stuff from itunes? [02:43:03 CET] <damdai> https://pastebin.com/qK35k8zu [02:44:15 CET] <dongs> what exactly does VLC call it [02:44:24 CET] <dongs> 608 is old analog stuff. 708 is newer digital tv stuff [02:44:27 CET] <damdai> "EIA-608 subtitles (c608) [02:44:33 CET] <dongs> i still don't understand how either would survive conversion to mkv tho. [02:45:46 CET] <damdai> https://i.imgur.com/29RZ845.jpg [02:45:58 CET] <dongs> EIA-608 and similar closed captioning standards, the captions are embedded directly in the video bitstream as user data. H.264 bitstreams are stored as a sequence of NAL (network abstraction layer) units. Each unit has a type; user data is stored in a NAL unit of the supplemental enhancement information (SEI) type. [02:46:13 CET] <dongs> apparently thats where they're hiding [02:46:26 CET] <damdai> huh [02:46:28 CET] <dongs> https://forum.videohelp.com/threads/390217-Deleting-CEA-608-%28EIA-608%29-c… [02:46:32 CET] <dongs> this seems to be related. [02:46:36 CET] <dongs> and even ffmpeg relevant [02:47:19 CET] <DHE> when transcoding, several h264 encoders have a parameter, -a53cc, which can copy the captions while transcoding. [02:47:39 CET] <damdai> dongs doesn't VLC use ffmpeg ? [02:47:50 CET] <dongs> no [02:48:00 CET] <damdai> vlc doesn't use ffmpeg? then what does it use [02:48:53 CET] <dongs> i honestly dont care [02:49:39 CET] <dongs> i stopped usign vlc after version 2.something when they had some bug that made large .ts files almost unusable to seek in [02:49:46 CET] <Hello71> vlc uses some forked ffmpeg components [02:50:14 CET] <damdai> and ffmpeg no longer reports closed caption for the video stream [02:50:28 CET] <Hello71> at least I think it did at some point in time [02:50:48 CET] <damdai> dongs according to that link you just gave me: it says "and ffmpeg no longer reports closed caption for the video stream: [02:50:57 CET] <damdai> is this true? [02:51:01 CET] <dongs> shrugging [02:51:26 CET] <dongs> you can use that filter_units thing to get to the bits that have teh subtitles in them [02:52:03 CET] <damdai> and how do i do that [02:52:07 CET] <DHE> ffprobe reports "Closed Captions" on the video stream for me... this is a reasonably new git version [02:52:29 CET] <damdai> DHE on what video? [02:53:54 CET] <DHE> damdai: over the air video captured to multicast [03:11:00 CET] <damdai> how come AVI is rarely used now? it used to be most popular container [03:11:15 CET] <dongs> hipsters took over [03:11:23 CET] <damdai> huh [03:50:53 CET] <damdai> does youtube ever create upsampled video? for example if i upload a 960x540 video, would it create a 1280x720 video in the dash? [03:51:46 CET] <furq> no [03:52:58 CET] <damdai> furq are you sure? [03:53:30 CET] <dongs> upload, wait a few hours then youtube-dl -F [03:53:35 CET] <dongs> and see what formats it exposes. [03:53:41 CET] <dongs> why ask when you can just test yourself [03:53:53 CET] <damdai> to save bandwidth [03:55:10 CET] <damdai> dongs i was told that bandwidth is expensive; that's why youtube is willing sacrifice storage space to save bandwidth space [03:55:28 CET] <dongs> im certain you can use ffmpeg to generate a 960x540 still frame video running for like 30 seconds with dickbutt on it and a sine tone for audio, which would be a few 100kbytes at most, and upload that. [03:55:52 CET] <damdai> dickbutt ? [03:56:23 CET] <dongs> you come off to me as a typical LARP'er . you spend all this time coming up with hypothetical what-if questions and then wasting time pondering about them, isntead of actually getting work done [03:56:53 CET] <dongs> like, do you have a specific use case for 960x540 video on youtube? if you do, it takes just a few minutes to verify your theory [03:57:01 CET] <dongs> all the other shit you asked about yesterday as well [03:57:14 CET] <dongs> most of it you could test or verify by looking at source or wahtever [03:57:41 CET] <damdai> dongs true, i could find the answer my testing [03:57:47 CET] <dongs> get to it then [03:57:51 CET] <damdai> by [03:58:03 CET] <damdai> but bandwidth is expensive [03:58:38 CET] <damdai> dongs furq did say "no" [03:59:07 CET] <dongs> if I say "yes", will you actually get off your ass and do the test to find out? [04:00:26 CET] <damdai> dongs okay how can i create minimum size vidoe files using ffmpeg [04:00:41 CET] <damdai> so i can test [04:00:43 CET] <dongs> hint: the less motion there is, the smaller size will be [04:00:46 CET] <dongs> just make a static image. [04:00:55 CET] <dongs> i.e. take a png, draw some shit on it in mspaint [04:01:03 CET] <dongs> then feed it into ffmpeg as a single-frame image source. [04:01:21 CET] <damdai> i see [04:01:23 CET] <dongs> specify length + framerate, and either have no audio or use some filter to genrate a sinewave tone and use that [04:01:41 CET] <damdai> does youtube allow video with no audio? [04:02:04 CET] <dongs> https://superuser.com/questions/724391/how-to-generate-a-sine-wave-with-ffm… [04:02:07 CET] <dongs> yes it certainly does [04:02:16 CET] <dongs> i've uploaded several without audio [04:02:24 CET] <damdai> i see [04:02:36 CET] <damdai> i know that youtube doesn't allow "audio only" file though [04:03:21 CET] <damdai> okay i got the .bmp file. how do i create video with this using ffmpeg [04:03:46 CET] <dongs> https://stackoverflow.com/questions/25891342/creating-a-video-from-a-single… [04:04:25 CET] <dongs> you just need -loop and -t stuff, and iirc -r to set framerate or else it ends up being 25fps [04:04:35 CET] <dongs> can ignore the scale/etc stuff [04:05:26 CET] <dongs> ou want to make a video from a single pic and don't care about any details at all? ffmpeg -loop 1 -i image.png -t 5 out.mp4 [04:09:59 CET] <damdai> well i have to specify the resolution [04:17:25 CET] <dongs> no you dont [04:17:29 CET] <dongs> the image size is your resolution [04:20:07 CET] <damdai> well i want to create 1120x630 [04:20:13 CET] <damdai> and it's not working [04:22:27 CET] <dongs> http://worksonmymachine.pro [04:25:06 CET] <damdai> okay i got it working [04:25:15 CET] <damdai> lol the video file is smaller than the .png file [04:25:26 CET] <damdai> how is that possible [04:25:39 CET] <damdai> i made 30 second video [04:26:49 CET] <another> lossy compression [04:27:09 CET] <damdai> but it's 30 seconds [04:27:17 CET] <dongs> its 30 seconds of static [04:27:35 CET] <damdai> so what if i make 1 hour video of static ? [04:27:44 CET] <dongs> remember what i said an hour about [04:27:53 CET] <dongs> about 'asking' instead of "doing"? [04:34:37 CET] <damdai> it created audio file dash when the file had no audio in it? [04:34:50 CET] <damdai> why would google this stupid? [04:40:14 CET] <cards> player compatability? [04:41:37 CET] <damdai> it's perfectly normal to have a video with no audio in it [05:01:41 CET] <cards> must not fit in their model [05:03:53 CET] <damdai> cards it's easy to make youtube detect if a video file has no audio in it [05:44:33 CET] <fructose> When cutting video, is there a way to get ffmpeg to seek to the first pts time before -ss while keeping audio synced? [05:46:47 CET] <Beam_Inn> hi, i'm recording in audacity and want to prevent clipping during the recording process [05:50:35 CET] <cards> lower your microphone gain [05:50:54 CET] <Beam_Inn> thanks. [05:51:19 CET] <cards> or line-in gain [07:10:04 CET] <boblamont> when I use this script https://paste.ee/p/AI1gn I get "Argument '/path/to/01-file.mp3' provided as input filename, but '/path/to/00-file.mp3 was already specified." [07:18:44 CET] <CyberShadow> boblamont: Your problem is with the shell syntax, not your usage of ffmpeg. `for file in "$DIR"/*.mp3; do` / ` ffprobe "$file" | grep -vi "stereo" >mono.txt` (mind the quotes' placement). [07:20:54 CET] <CyberShadow> boblamont: Also, shellcheck would have told you this. https://www.shellcheck.net/ [07:27:36 CET] <boblamont> ok, I've updated it and no longer get errors https://paste.ee/p/BEmFy but I also am not getting the expected results [07:27:50 CET] <boblamont> mono.txt is blank, but I know there is a mono file in the directory [08:03:28 CET] <CyberShadow> boblamont: ffprobe sends ALL its output to stderr [08:05:13 CET] <boblamont> CyberShadow: do I need ">out 2>&1"? [08:05:40 CET] <CyberShadow> That would be one way to do it probably, or you could 2>&1 | grep ... [08:07:36 CET] <boblamont> ok, I sort of got it with that [08:07:57 CET] <boblamont> but I've been foiled by it not counting each entry as a single line [08:09:26 CET] <CyberShadow> The "correct" approach depends on what you want to do with e.g. files that don't have audio, or that have more than one audio track (out of which none, or some, or all can be mono). Also I guess 5.1 etc. are a thing too. [08:12:06 CET] <boblamont> I think everything I'd be using this on has a single audio track, so it looks like I want the file names of anything that doesn't have stereo in Stream #0:0 [08:13:51 CET] <CyberShadow> for f in "$dir"/*.mkv ; do if ! ffprobe "$f" 2>&1 | grep -qF stereo ; then echo "$f is mono" ; fi ; done [08:22:56 CET] <boblamont> CyberShadow: thanks! that did it [08:54:26 CET] <mikemocha> hello, I'm looking for a static 64 bit linux build of ffmpeg with nvenc. [08:54:40 CET] <mikemocha> I've seen this website: https://johnvansickle.com/ffmpeg/git-readme.txt [08:54:54 CET] <mikemocha> but it doesn't seem to have static builds compiled with nvenc. [08:55:15 CET] <mikemocha> Thanks for any pointers. [13:46:20 CET] <ossifrage> I only have PTS, but no DTS, what do I need to set to get avformat to compute the DTS? [13:46:34 CET] <ossifrage> If I just set dts to AV_NOPTS_VALUE it complains [13:47:39 CET] <JEEB> set the DTS, even if it's just a +1 on the time base [13:48:06 CET] <ossifrage> pts = dts works fine for I and IP but not for IBBP [13:49:01 CET] <JEEB> yes, generally with b-frame streams you need to add some difference between PTS and DTS so that you don't end up with PTS < DTS [14:28:47 CET] <ossifrage> I looks like I do need to keep a small fifo PTS to generate DTS that will make avformat happy [14:29:23 CET] <Mavrik> Lack of DTS will make every single player unhappy too :P [14:29:25 CET] <ossifrage> But I got something playing from chrome, not live but at least it is working [14:29:56 CET] <ossifrage> Mavrik, it looks like libavformat use to be able to compute the DTS itself (at least in the past) [14:30:28 CET] <ossifrage> Mavrik, I just dropped the b pictures to see if was working, poof magic bitrate savings [14:30:41 CET] <Mavrik> .. [14:31:01 CET] <Mavrik> Yeah, sounds something that would cause a lot of player authors to come kick you :P [14:31:40 CET] <ossifrage> Well, my off-on-detector is fixating on this off by one in chrome: https://i.imgur.com/fPegwA8.png [14:32:05 CET] <ossifrage> They put a transparent box around the ui overlay and they don't quite get it all the way to the bottom [14:33:38 CET] <iive> what is that encoder that doesn't output the dts of the packet it has just released? [14:34:05 CET] <ossifrage> iive, yeah the hardware just has a pts in the frame header [14:35:19 CET] <iive> ossifrage, the thing is, when you feed it image frames with pts, the decoder is supposed to output it in dts order [14:35:26 CET] <ossifrage> They also can't slew the PTS only jump it which is really annoying for keeping it synced to NTP [14:39:36 CET] <ossifrage> iive, yeah I know what DTS is for, I just wonder why ffmpeg is deprecating the 'figure it out inside the muxer' part [14:41:18 CET] <ossifrage> The code is actually there in libavcodec/nvenc.[ch] [14:56:07 CET] <ossifrage> Is there a way to do what avformat_find_stream_info() does with the data in an AVPacket? [14:56:36 CET] <ossifrage> I can make sure the the AVPacket contains all the header NALUs [14:57:59 CET] <Mavrik> Because DTS shouldn't be just made up [14:58:01 CET] <Mavrik> Neither PTS [14:58:13 CET] <Mavrik> Since that causes sync issues and bunch of other headaches. [15:02:14 CET] <ossifrage> It isn't made up, all the data is there, it looks like you need to at some delay to do it right [15:06:42 CET] <ossifrage> I'm going to try and compute the DTS closer to the hardware, but I really don't want to add extra delay buffers to do it that would suck. [17:49:41 CET] <belen_> When I try to run `ffmpeg -f concat -i outro.mp4 -i outro.mp4 -c copy test.mp4` I am told `outro.mp4: Invalid data found when processing input` [17:50:06 CET] <belen_> is there a way to tell exactly what invalid data it's finding? `-loglevel verbose` didn't give me any additional output [17:54:34 CET] <belen_> http://paste.debian.net/plain/1072700 is the output of `ffprobe -loglevel verbose outro.mp4` [17:56:45 CET] <furq> belen_: -f concat expects a text file containing the files you want to concat [17:57:14 CET] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#concat-1 [17:57:38 CET] <belen_> oh. I thought that was a potentially convenient option, not a requirement. [17:59:40 CET] <belen_> is there a way to force it to use "unsafe" file names like ones containing colons? [18:00:49 CET] <belen_> -safe 0 [18:01:03 CET] <belen_> it's the absolute vs relative location actually [18:02:29 CET] <belen_> thanks furq [18:05:41 CET] <ksk> hola. [18:06:39 CET] <ksk> I have some video files on server A), that I would like to view a transcoded version of at client B): I can use ffmpeg to convert the files to something else, and then use http to download the transcoded file. [18:07:05 CET] <ksk> Is there some way I could already download the file to B) as it is transcoding on A)? [18:07:30 CET] <ksk> Ive been looking at the wiki/StreamingGuide, but I am not sure if that is what I want.. [18:09:12 CET] <ksk> Iam looking for something like "put this ffmpeg string into nginx config and make nginx run ffmpeg and output it" if a client sent a request - Is that possible? [18:13:38 CET] <ksk> reading the webz a little bit more it seems I will always need an rmpt service to archive that? [19:56:37 CET] <JKSamir> Hi. I need some help. In the extract_mvs example, I was wondering if I could get the reference frame numbers from which the motion vectors were calculated instead of a +/- 1 direction field as mentioned in the motion_vector.h file. I think it's a TODO. Can anyone give me some pointers on where should I look to get the reference frames numbers not only the directions? [23:25:45 CET] <AuroraAvenue> testing. [23:26:42 CET] <AuroraAvenue> How do I splice 2 videos (back to back) that are webm, videos? What is the simple command in Ubuntu? [23:59:45 CET] <systemd0wn> AuroraAvenue: Have you looked at https://trac.ffmpeg.org/wiki/Concatenate ? [00:00:00 CET] --- Tue Mar 12 2019

1 0