April 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190409
by burek 10 Apr '19

10 Apr '19

[03:18:24 CEST] <cone-053> ffmpeg 03Jun Zhao 07master:0a347ff42223: lavf/matroskaenc: Fix memory leak after write trailer [04:03:34 CEST] <jamrial> half the fate clients haven't yet synced the new sample, so it all looks very yellow [13:19:03 CEST] <nevcairiel> its been three days and some fate clients still lack a sample? [13:19:12 CEST] <nevcairiel> are they using a different sample source or some other nonsense? [15:30:25 CEST] <cone-424> ffmpeg 03Carl Eugen Hoyos 07master:d6a8392224c0: lavf/movenc: Pass correct pointer to av_log(). [15:50:08 CEST] <cone-424> ffmpeg 03Tristan Matthews 07master:1ec777dcdd03: avformat/matroskaenc: fix leak on error [17:12:54 CEST] <cone-424> ffmpeg 03Jeremy Dorfman 07release/4.1:420fe39aff3d: avformat/av1: Initialize padding in ff_isom_write_av1c [17:12:55 CEST] <cone-424> ffmpeg 03Tristan Matthews 07release/4.1:cf7a5c655c04: avformat/matroskaenc: fix leak on error [18:50:14 CEST] <philipl> BtbN: well, that was a generally unhelpful response re nvenc. [18:51:14 CEST] <BtbN> What they propose is not really sensible possible in the context of ffmpeg [18:51:25 CEST] <BtbN> It is if you embed nvenc into an application [18:57:10 CEST] <philipl> Worst case you add some flag to indicate you're using it with a fixed frame pool and don't need to unregister every time? [19:12:41 CEST] <nevcairiel> that seems like a rather hacky option [19:13:21 CEST] <philipl> It is. Maybe it can be detected? I have not thought hard about it. [19:13:23 CEST] <nevcairiel> before doing anything I would definitly try to get nvidia to comment on it [19:13:36 CEST] <philipl> the nvidia guys said don't unregister until you free the frame. [19:13:39 CEST] <philipl> which we can't really do. [19:15:21 CEST] <nevcairiel> does this problem apply to cuda input, software input, or both? [19:16:54 CEST] <philipl> The 'problem' is that unregistering after unmap (when the buffer is actually going to be reused) causes a throughput bottleneck in nvenc. That applies to every scenario, although it's only detectly in extreme parallel encoding situations. [19:17:07 CEST] <philipl> s/detectly/detectable/ [19:17:32 CEST] <philipl> The guy in the ticket has three big quadroos and wants to do 60 parallel encodes on one system for whatever reason. [19:17:55 CEST] <nevcairiel> 60 encodes doesnt seem like it would run any faster then 2x 30 encodes in series [19:18:17 CEST] <philipl> Depending on the exact pipeline setup, there may be a fixed buffer pool being reused all the time, in which case delayed unregistration is fine. [19:18:34 CEST] <philipl> Or there may be buffers getting deallocated and newly allocated each time, in which case it is not fine. [19:18:44 CEST] <philipl> I'm not sure which pipelines are which. [19:18:54 CEST] <philipl> nevcairiel: and yes, one would asssume that is so if full utilisation occurs. [19:21:44 CEST] <nevcairiel> even the big quadro cards dont have more encoding resources. some get a second nvenc engine, and thats it, afaik? [19:22:35 CEST] <philipl> They may have an additional engine, but nvidia also lifts the artifical limit on the number of parallel encodes on a single engine. [19:22:50 CEST] <nevcairiel> you can lift that with mild driver hacking on c onsumer cards too [19:23:10 CEST] <philipl> I don't know how silly this guy's scenario is (but I have suspicions), but it is true that the official nvidia recommendation is not to unregister all the time. It's relatively expensive and they don't consider that a bug. [19:23:37 CEST] <nevcairiel> our architecture doesnt really allow anything else and still feeling "clean" tho [19:24:08 CEST] <nevcairiel> I wonder what happens if you dont unregister and then dont use a fixed pool [19:24:35 CEST] <philipl> Presumably some sort of resource leak that eventually leads to errors the next time you try to register. [19:25:16 CEST] <nevcairiel> thats the only place we unregister, isn't it? so the pool is never unregistered, and presumably if you make enough pools or something, it might also result in that? [19:25:57 CEST] <nevcairiel> or maybe nvenc cleans it up when the session is closed [19:27:18 CEST] <philipl> I would hope so. Presumably someone could use a custom pool implementation that actually did full allocations and deallocations (rather than maintaining a pool) and that would create the pathological scenario? [19:27:22 CEST] <nevcairiel> tying that to the frames lifetime would be ideal, but alas we can't exactly have encoders messing with the incoming avframe [19:28:08 CEST] <philipl> I asked BtbN if we could register a deallocation hook, but that requires keeping the nvenc alive - unless we convince ourselves that closing the session cleans things up and then we just need a weak reference. [19:28:13 CEST] <philipl> Still messy, but not crazy. [19:28:52 CEST] <philipl> We sort of do this on the decoder side where frames are owned by the encoder and returned via a custom pool. The frames hold a decoder ref. [19:29:14 CEST] <philipl> but in that case the decoder is the actual allocator. [19:29:27 CEST] <philipl> s/encoder/decoder/ [19:30:46 CEST] <BtbN> That's done via a custom deallocator in the buffer pool [19:30:54 CEST] <BtbN> nvenc can't do that, since it's not allocating the frames [19:31:22 CEST] <philipl> We'd need to add a new buffer pool mechanism for generic deallocation callbacks. [19:32:15 CEST] <BtbN> Which would actually need to be attached to the internal buffer pool, not to the frame [19:32:20 CEST] <BtbN> since the frame _does_ get freed eventually [19:32:24 CEST] <BtbN> the underlying buffer does not [19:33:50 CEST] <philipl> Yes. [19:41:52 CEST] <siperman> hello [19:42:19 CEST] <siperman> someone can help applying a patch to solve an issue to ffmpeg [19:42:20 CEST] <siperman> ? [19:45:06 CEST] <Kwiboo> philipl: I added get+release callbacks for buffer pool in https://github.com/Kwiboo/FFmpeg/commit/42e3ab0b889a736fcbbdb50086b1a645844… when I was looking for a resource leak in my v4l2 request api hwaccel + kodi, not sure if something like that is what you had in mind with mechanism for generic deallocation callbacks [19:46:36 CEST] <philipl> Kwiboo: it's not quite that. We would need to attach a callback from a frame consumer (the nvenc encoder) that would fire when the buffer was eventually deallocated (and not when the frame is freed) [19:46:46 CEST] <philipl> So it's not something you set up at bool init time. [19:46:55 CEST] <philipl> s/bool/pool/ [19:49:50 CEST] <Kwiboo> philipl: I see, a little bit more complex scenario [20:00:45 CEST] <siperman> hello [20:02:46 CEST] <siperman> i have a problem with Inconsistent UDP output packet size [20:02:53 CEST] <siperman> can someone help me [20:02:54 CEST] <siperman> ? [23:17:45 CEST] <cone-114> ffmpeg 03Jarek Samic 07master:1c50d61a5a68: libavutil/hwcontext_opencl: Fix channel order in format support check [00:00:00 CEST] --- Wed Apr 10 2019

1 0

ffmpeg.log.20190409
by burek 10 Apr '19

10 Apr '19

[00:12:43 CEST] <faLUCE> DHE: it seems that if I force a keyframe, while encoding, the global quality decrease and remains with that lower quality [00:13:20 CEST] <DHE> keyframes are large. forcing them will negatively impact quality. [00:13:38 CEST] <faLUCE> DHE: ok, but why that quality remains bad forever? [00:13:57 CEST] <DHE> you don't get stuck using keyframes the whole way from then on are you? [00:16:52 CEST] <faLUCE> DHE: you are right again [00:17:07 CEST] <faLUCE> so, How can I unset AV_PICTURE_TYPE_I ? [00:17:43 CEST] <faLUCE> (on pict_type) [00:18:07 CEST] <faLUCE> AV_PICTURE_TYPE_NONE ? [00:18:24 CEST] <DHE> yeah [00:18:25 CEST] <JEEB> yes, anything that is not I/P/B goes to default [00:18:35 CEST] <JEEB> which is X264_TYPE_AUTO [00:20:26 CEST] <DHE> it's worth noting there's a special setting for x264 that makes I frames into IDR frames, which may be what you want [00:21:15 CEST] <faLUCE> what a asshole I was ;-). x264 was soo good that I even did note that all were keyframes... [00:21:22 CEST] <faLUCE> I did not note [00:23:07 CEST] <DHE> called it [02:52:30 CEST] <Ariyasu> maybe offtopic question [02:52:48 CEST] <Ariyasu> if my display is set to 2160p and im playing a 1080p video [02:53:19 CEST] <Ariyasu> what is handling the upscaling to 2160p? the media player? the display itself? the os? [02:55:01 CEST] <tlacatlc6> that'd be the media player [03:40:05 CEST] <dongs> uh, depends completely on what is playing, and waht mode etc. [03:42:45 CEST] <Hello71> if you have dpi scaling on your media player that's a shit media player [03:43:20 CEST] <Ariyasu> i use mpc-hd with lav and playing back a m2ts from bluray [03:43:30 CEST] <Ariyasu> i was just curious what was handling the scaling [03:43:35 CEST] <klaxa> the most sane way would be some scaling filter in the player [03:43:39 CEST] <Ariyasu> mpc-hc* [03:43:43 CEST] <klaxa> and that's what probably all do [03:44:01 CEST] <klaxa> you can make the OS scale it by reducing the screen resolution [03:44:18 CEST] <klaxa> the display should only output what it is fed [03:44:52 CEST] <klaxa> having the scaling done in the player adds the advantage that you can choose how to scale [03:45:29 CEST] <klaxa> also probably less syscalls if you had to call the OS to scale [03:51:37 CEST] <dongs> yeah but like, if youre in fullscreen exclusive mode it could be your gpu or your monitor [03:52:00 CEST] <dongs> Hello71: dpi has nothing to do with this [03:52:06 CEST] <klaxa> wouldn't that scale on OS level then? [03:52:19 CEST] <dongs> thats what im saying, theres not enough information in the question to ansewr [03:52:42 CEST] <klaxa> i think there is enough information [03:52:44 CEST] <dongs> "i play back 1080p video on 2160p screen, what is doing the scaling"? answer: could be anything depending on how its done [03:52:59 CEST] <dongs> klaxa, what if its not even fullscreen [03:53:02 CEST] <dongs> then there's no scaling. [03:53:03 CEST] <klaxa> ><Ariyasu> i use mpc-h[c] with lav and playing back a m2ts from bluray [03:53:22 CEST] <klaxa> ><Ariyasu> what is handling the upscaling to 2160p? the media player? the display itself? the os? [03:53:34 CEST] <dongs> decoder will output 1080p, eihter renderer or gpu or monitor will be scaling [03:53:45 CEST] <dongs> depending on screen mode [03:53:46 CEST] <klaxa> should probably be a setting in the player [03:56:32 CEST] <Hello71> the question specifically says "set to 2160p" [03:57:57 CEST] <dongs> the real answer is nobody gives a shit cuz you wont notice the difference anyway. [03:58:00 CEST] <dongs> :) [03:59:01 CEST] <klaxa> blasphemy! [12:08:18 CEST] <sadasaulna> Hi. Is the warning "[mp3float @ 0x7f7ff7b03800] Could not update timestamps for skipped samples." something I should worry about? [12:36:57 CEST] <DHE> it probably means the file is damaged. mp3 is recoverable with some glitchy sound where the damage is... [13:45:19 CEST] <ozette> Does anyone know if MPEG-4 Part 2 can be decoded by browsers? I got a .mp4 here, which won't play in chrome nor firefox. It was "converted" from a .mpeg, I don't know how exactly, but supposedly 4videosoft's 'video converter' was used [13:45:39 CEST] <ozette> Chrome says: Resource interpreted as Document but transferred with MIME type video/mp4 [13:46:03 CEST] <ozette> Firefox says a whole lot and then: No MP4 audio () or video () tracks [13:46:49 CEST] <furq> no it can't [13:46:53 CEST] <ozette> MediaInfo shows 'Video' in Tree view and under that: Format: MPEG-4 Visual [13:46:58 CEST] <ozette> oh [13:47:31 CEST] <furq> mpeg-4 part 2 is like divx/xvid etc [13:47:46 CEST] <furq> browsers will generally only decode h.264 (mpeg-4 part 10 if you want to be technical) [13:47:52 CEST] <furq> at least in mp4 [13:47:59 CEST] <ozette> Yea I noticed [13:48:17 CEST] <ozette> I'm not familiar with divx or vidx codecs [13:49:32 CEST] <ozette> Thanks :) [17:43:26 CEST] <pkeroulas_> I'd like to convey closed captions in flv/rtmp stream. It is suggested to use AMF messages and more precisely "onCaptionInfo" event to do that. Is there any support/example/doc in ffmpeg for that use case? [17:47:15 CEST] <pkeroulas_> apparently, the flv decoder can handle such messsages but not the encoder [18:26:26 CEST] <zerodefect> When scaling YUV420p with sws_scale() (using C-API), do I have to make any explicit considerations for chroma subsampling when setting up the scaler? I'm getting a crash, but I can't quite put my finger on the problem. [18:31:57 CEST] <DHE> the input data fields need to be arrays of pointers. maybe you're providing the wrong frame fields? [18:35:19 CEST] <zerodefect> Well, what's interesting is my logic works for YUV422P but not YUV420P. In my height calculations, I'm not taking chroma subsampling into consideration, but I think that is ok. The problem is definitely my side, but just trying to corner it. [18:50:23 CEST] <DHE> I just call sws_scale(scaler, (const uint8_t* const*)source_frame->data, source_frame->linesize, 0, input_h, frame->data, frame->linesize); // source source_frame is the input, and frame is the output. I'm going 420p to 420p but it's been fine for me... [18:55:04 CEST] <Mavrik> linesize array is the prime suspect there [19:28:05 CEST] <dablitz> start : ---> ffmpeg -f alsa -i hw:1,0 -acodec libopus -ar 8000 -sdp_file sdp -f rtp rtp://192.168.100.21:52000 [19:28:05 CEST] <dablitz> <dablitz> and when i play : ---> ffplay -nodisp rtp://192.168.100.20:52000 [19:28:05 CEST] <dablitz> <dablitz> it should allow the audio to stream from one computer to the next. I do get cli showing stings are happening on the sending side...but nothing on the recieving side [19:28:05 CEST] <dablitz> * alex`` (~alex(a)aputeaux-651-1-292-49.w86-249.abo.wanadoo.fr) has joined [19:28:05 CEST] <dablitz> <dablitz> ffplay just sits : nan : 0.000 fd= 0 aq= 0KB vq= 0KB f=0/0 [19:39:29 CEST] <siperman> hello [19:40:15 CEST] <siperman> i need some help with ffmpeg running on ubuntu [19:40:28 CEST] <siperman> i am using it to make an udp stream [19:41:18 CEST] <siperman> i have a problem with the packet creation, and i read on the wiki that i need to apply a patch [19:41:25 CEST] <siperman> i downloaded the patch [19:41:36 CEST] <siperman> but i dont know how to apply it [19:43:42 CEST] <DHE> for mpegts? [19:44:42 CEST] <siperman> yes [19:45:49 CEST] <siperman> i have a problem when i use the pkt_size=1316, the files are not constant sized, is well known problem and auser create a patch, but i dont know how to apply it [19:47:32 CEST] <DHE> I see... I've not actually had that as a problem though. nothing's complained about the packet sizes [19:49:29 CEST] <siperman> did you need to apply a patch in the past? [19:50:47 CEST] <DHE> I see small packets from time to time. but there's been nothing on the network complaining about it so I've just ignored it as a non-issue [19:50:54 CEST] <DHE> curious what you have that's causing you grief [19:53:26 CEST] <siperman> the problem is because i am trying to send the feed to an equipment that i am thinking is the decoder from hell [19:53:40 CEST] <siperman> but the decoder doesent see the udp packets [19:54:14 CEST] <DHE> multicast? [19:54:33 CEST] <siperman> the brand and the model os the decoder is Ateme Kyrion DR5000 [19:54:48 CEST] <siperman> no, i am sending as an unicast [19:55:02 CEST] <siperman> i am sending the packags directly to the decoder [21:21:52 CEST] <zerodefect> @DHE / @Mavrik - Silly mistake with my YUV420p scaling problem - the height of the frame was not a multiple of 2 so the scaler was reading off the end of the buffer :( [21:23:51 CEST] <pranayvshah> Can anyone please help me with an issue regarding burning Indic subtitles into a video. Works perfectly fine with Handbrake GUI and CLI and also when the subtitles are added as a stream instead of burning them into the video. [23:36:16 CEST] <Hackerpcs> reading about AAC encoding https://trac.ffmpeg.org/wiki/Encode/AAC , it says about using a higher cutoff "keeping in mind that a higher limit may audibly reduce the overall quality." why is that? [23:42:49 CEST] <furq> because you're encoding more data at the same bitrate [23:46:26 CEST] <Hackerpcs> what could possibly be a good combination of the highest available cutoff and bitrate for fdk acc to achieve transparency? [23:46:37 CEST] <Hackerpcs> highest is 20k [23:46:41 CEST] <furq> if you just want no cutoff then use -vbr 5 [23:48:00 CEST] <Hackerpcs> that works, it goes over 20k too [23:50:07 CEST] <Hackerpcs> thanks! [00:00:00 CEST] --- Wed Apr 10 2019

1 0

ffmpeg-devel.log.20190408
by burek 09 Apr '19

09 Apr '19

[01:40:49 CEST] <lrusak_> anyone know why this happens?: [01:40:50 CEST] <lrusak_> Assertion *(const AVClass **)avctx->priv_data == codec->priv_class failed at libavcodec/utils.c:998 [01:41:58 CEST] <lrusak_> ah, similar fix here, http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b942845beedc369cf0684e… [01:42:42 CEST] <nevcairiel> yeah if you use options, the struct needs to include AVClass [03:55:38 CEST] <x420> where did trac go [03:55:50 CEST] <x420> seems down for me [03:59:47 CEST] <jamrial> works here [04:00:44 CEST] <jamrial> although kinda slow [04:04:07 CEST] <x420> can ping it but times out on 80 and 443 for me idk [04:04:10 CEST] <x420> oh well [16:26:25 CEST] <cone-476> ffmpeg 03Jeremy Dorfman via ffmpeg-devel 07master:bb5efd1727ee: avformat/av1: Initialize padding in ff_isom_write_av1c [16:29:21 CEST] <durandal_1707> jamrial: now you, previously michaelni, same error [16:31:16 CEST] <jamrial> ugh [16:32:08 CEST] <jamrial> yeah, my fault, i don't run any script to catch these. i just didn't pay enough attention [16:32:43 CEST] <jamrial> it's annoying how google emails get mangled like this [19:02:12 CEST] <j-b> Can we not do that, again? [19:04:02 CEST] <JEEB> gitlab when (ŽûÉû@) (only half-jokingly) [19:13:38 CEST] <thardin> gitmab is ok [20:34:49 CEST] <durandal_1707> gitmob [20:43:58 CEST] <durandal_1707> who gonna RE blackmagic and prores RAW? [20:46:25 CEST] <gnafu> Is that like a flash mob? [20:46:42 CEST] <gnafu> A bunch of people committing several tiny typo fixes all at once. [20:46:50 CEST] <gnafu> Or code formatting changes. [21:19:55 CEST] <philipl> BtbN: so this ticket #7674. The guy who reopened it pinged me on devtalk too. It seems on the surface that cleaning up after yourself and avoiding a resource leak leads to a big performance penalty. [21:20:13 CEST] <philipl> I think we should throw it to an nvidia person to deal with. [21:21:28 CEST] <BtbN> Yeah, removing the deregistering is incorrect and only works because the hwframes_ctx keeps reusing the same frames over and over again [21:21:40 CEST] <BtbN> Which cannot be safely assumed in nvenc [21:22:16 CEST] <BtbN> His usecase is such an edge case that I have a hard time caring. Only breaks when using at least 50 encode sessions... [21:49:53 CEST] <nevcairiel> I imagine there is a certain overhead of resource management, and the special case of re-using the same stuff all the time avoids that [21:50:03 CEST] <nevcairiel> why it suddenly kills performance is a bit odd, but who knows [21:59:05 CEST] <BtbN> re-registering the same frame over and over again certainly does not feel right [21:59:23 CEST] <BtbN> So that deregister got to be there. If it causes a serious performance impact, that's on the driver. [22:00:20 CEST] <philipl> Could we, in theory, have some sort of hook that get registered with the hwframes_ctx so that we unregister when the frame gets deallocated? [22:01:06 CEST] <philipl> Of course, better if nvidia fixes driver, but register/unregister is slow for many of their resource types. [22:01:09 CEST] <philipl> Seems a tradition. [22:02:19 CEST] <BtbN> In theory, yes. In practice, that would require some hackery to keep nvenc alive until the frame is freed [22:02:29 CEST] <BtbN> which sounds dangerous and deadlocky to me [22:03:11 CEST] <BtbN> Would need to work in a very similar fashion as it does in nvdec, except that nvenc does not produce the frames and thus can't set a custom deallocator [22:40:48 CEST] <durandal_1707> oh no! black belt training in RE sold out: https://nullcon.net/website/goa-2019/training/black-belt-in-reverse-enginee… [22:42:00 CEST] <nevcairiel> it also happened a month ago a lready [22:43:06 CEST] <BtbN> Talking about RE, i'm currently trying to reverse engineer some "encryption" algorithm arcade cabs use. I have the decompiled code Ghidra generated for the decrypt function, but holly hell they put some effort into making this obtuse. [22:44:32 CEST] <nevcairiel> in my experience decompiled code hardly looks straight forward from the get go =p [22:44:45 CEST] <BtbN> It does a surprisingly good job [22:45:02 CEST] <BtbN> Since it uses no external functions and just shuffles around on a block of memory [22:45:19 CEST] <durandal_1707> just reproduce decompiled function, you can even compile it with minor changes if it is not referencing extra stuff [22:45:52 CEST] <BtbN> It's 6 layers deep of memory shuffling functions though [22:46:23 CEST] <BtbN> I guess I could just straight up copy the decompiled C code, and it'd work. [22:46:46 CEST] <durandal_1707> well, it may not work always,... [22:47:54 CEST] <JEEB> BtbN: they just open sourced the decompiler C++ module I think [22:47:56 CEST] <JEEB> @ ghidra [22:48:18 CEST] <BtbN> nice, but I doubt that'd help me. At least immediately. [22:48:26 CEST] <BtbN> In the long run it'll probably greatly improve its quality. [22:48:43 CEST] <durandal_1707> you can also use retdec [22:48:45 CEST] <BtbN> I'm still a bit confused about their intention with releasing Ghidra, but I take it [22:49:11 CEST] <JEEB> BtbN: it's a PR thing mostly [22:49:16 CEST] <JEEB> but yes [22:49:38 CEST] <JEEB> it doesn't seem to be a generally OK thing [22:49:48 CEST] <JEEB> so yes, taking it :) [22:50:30 CEST] <BtbN> Maybe someone higher up at the NSA got seriously upset about Hexrays [22:50:46 CEST] <BtbN> Cause they are right now actively harming their business quite a bit [22:51:12 CEST] <JEEB> yup [22:51:50 CEST] <JEEB> granted, this seems to fit their defensive role. by releasing this they bring good reverse engineering tools into the hands of many whom the NSA is supposed to defend [22:52:24 CEST] <JEEB> (and yes, IDA Pro / Hex-rays loses some market share or at least doesn't get utilized in the manner it has been so far as much) [22:52:43 CEST] <BtbN> They probably primarily will get pirated a lot less [22:52:48 CEST] <JEEB> yea [22:52:53 CEST] <durandal_1707> lol, it loses nothing [00:00:00 CEST] --- Tue Apr 9 2019

1 0

ffmpeg.log.20190408
by burek 09 Apr '19

09 Apr '19

[00:01:16 CEST] <JEEB> coolhp48: it uses swresample, but it might be utilizing the non-AVFrame API [00:01:45 CEST] <JEEB> just make sure you check the headers for AVFrame utilizing functions [00:01:55 CEST] <coolhp48> Ok. I'll dig into the AVFrame API. Thanks again. [02:17:13 CEST] <KombuchaKip> How robust are FLAC files to data corruption? I'm doing some testing. I flipped a bit half way in the file and ffmpeg doesn't detect any bad frames. If I corrupt more data, eventually it emits a warning about bad frames. Doesn't FLAC headers contain a checksum? [02:19:48 CEST] <KombuchaKip> If I pass it through flac(1) via -wst it confirms data corruption. [02:23:35 CEST] <TheAMM> https://xiph.org/flac/features.html They do [02:23:40 CEST] <TheAMM> and https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281… [02:24:11 CEST] <TheAMM> but also https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281… [02:24:45 CEST] <TheAMM> ' [02:32:15 CEST] <KombuchaKip> TheAMM: Ok, so basically I need to specify AV_EF_CRCCHECK or AV_EF_COMPLIANT to something. [02:32:28 CEST] Action: KombuchaKip tries to find where. [03:21:55 CEST] <KombuchaKip> TheAMM: I've tried setting m_DecoderContext->err_recognition = AV_EF_EXPLODE & AV_EF_CRCCHECK after opening the codec, but before decoding any data. It still doesn't seem to detect the corrupt bit in the FLAC file. [04:58:35 CEST] <lindylex> How do I fix these errors when compiling ffmpeg with gltransition https://pastebin.com/9WLAm901 [07:19:29 CEST] <rjp421> ffmpeg is shown on screen during the movie Glass when Samuel L Jackson is hacking a computer [07:41:21 CEST] <circuitbone> cracking the movie to complete the mission. [07:42:53 CEST] <circuitbone> rjp421: Had a giggle at mr robot screens ? [07:42:54 CEST] <circuitbone> https://www.youtube.com/watch?v=SZQz9tkEHIg [11:32:39 CEST] <dablitz> good morning channel. [11:33:48 CEST] <dablitz> start : ---> ffmpeg -f alsa -i hw:1,0 -acodec libopus -ar 8000 -sdp_file sdp -f rtp rtp://192.168.100.21:52000 [11:34:38 CEST] <dablitz> and when i play : ---> ffplay -nodisp rtp://192.168.100.20:52000 [11:35:41 CEST] <dablitz> it should allow the audio to stream from one computer to the next. I do get cli showing stings are happening on the sending side...but nothing on the recieving side [11:44:15 CEST] <dablitz> ffplay just sits : nan : 0.000 fd= 0 aq= 0KB vq= 0KB f=0/0 [17:42:10 CEST] <pkeroulas_> Hello, I'd like to transcode rtp raw streams to mpegts (h264 + acc + cc53). Audio and video are fine. Closed caption (EIA 608) can be decoded to output file, as scc or text but it doesn't appear in the output stream. https://pastebin.com/UvCU08uS [17:43:11 CEST] <pkeroulas_> any idea someone, please? [17:43:17 CEST] <DHE> that uses a distinct subtitle stream for the closed captions? [17:46:47 CEST] <pkeroulas_> DHE, ideally yes, but it could also be inserted in SEI metadata of h264, but I know how to verify that. Vlc doesn't detect any cc/subtitles [17:47:46 CEST] <DHE> if the subtitles are present as SEI data in the input, most h264 encoders have an option -a53cc to just copy them as SEI data to the destination [17:49:03 CEST] <pkeroulas_> The input is not h264. It 3 "raw" rtp streams. [17:50:59 CEST] <DHE> oops, missed the pastebin link [17:53:19 CEST] <pkeroulas_> by the way, how to check if SEI data contains subtitles? [17:54:21 CEST] <DHE> Stream #0:0: Video: bitpacked (UYVY / 0x59565955), yuv422p10le(top first), 1920x1080, 90k tbr, 90k tbn, 90k tbc # this line would indicate h264, and there would be a "Closed Captions" clause listed [18:03:16 CEST] <pkeroulas_> DEH, not sure I understand. What the input video decoder, bitpacked, which is not aware of subtitles, has to do with h264 SEI? [18:06:32 CEST] <pkeroulas_> But my real question is: why does ffmpeg shows a distinct output stream ("Stream #0:1: Subtitle: text") but mediainfo and ffplay don't recognize that track? [18:10:58 CEST] <JEEB> pkeroulas_: if your input has the captions as a separate stream ffmpeg.c will show them as such. if they are in a video track the command line applications have limited support because they're not dynamic [18:12:14 CEST] <JEEB> (any ffmpeg api using application can utilize those packets though as they're properly presented as side data within the framework [18:16:21 CEST] <aboxer__> does FFMpeg process AFD data in mpeg user data ? [18:16:30 CEST] <aboxer__> parse it [18:23:00 CEST] <pkeroulas_> JEEB, understood. Could you please take a look at this ? https://pastebin.com/UvCU08uS Everything looks good in ffmpeg, but ffplay and mediainfo fail at detecting the subtitle track. [18:33:18 CEST] <DHE> the ffmpeg cli does very little with side data, which is what SEI-based closed captions are carried by [20:26:40 CEST] <egrouse> Hey all. I am using a complex filter map to concatenate x amount of videos together and stream to rtmp. the first video plays fine - 30fps, 1x speed; however later files seem to get exponentially faster almost. The 2nd one is currently on 35fps at 1.17fps and keeps getting faster [20:27:51 CEST] <egrouse> which eventually results after a few hours in huge video skips and dropping of 100s of frames at a time i guess as its trying to catch up with itself [20:28:01 CEST] <egrouse> in fact, it seems to be related to VBV underflow messaging - when i get that message the speed/fps seems to go up [20:28:49 CEST] <egrouse> bit of a vague question i'm sure but any suggestions or ideas how i could possibly counteract this!? [20:33:28 CEST] <egrouse> https://pastebin.com/T3rFW9LQ is the current command [20:48:40 CEST] <DHE> you have two [scaled] labels.. so there's that [20:49:29 CEST] <egrouse> so there is [20:49:46 CEST] <DHE> I don't think that's the cause of the problem, but it's the first error I found [22:40:21 CEST] <pkeroulas_> I have a situation where closed caption can be written to a srt file or in a mp4 container. But to insert this cc in a distinct mpeg ts stream (not embedded in video)? [22:41:54 CEST] <another> not sure ts supports subtitles [22:42:05 CEST] <JEEB> it does [22:42:06 CEST] <pkeroulas_> I tryed different codecs: srt, text, dvb, ass, no success. Mediainfo seems to detect an empty track [22:42:36 CEST] <JEEB> pkeroulas_: not sure if you can put closed captions into a separate stream in mpeg-ts [22:42:43 CEST] <JEEB> usually dvb teletext is what's being utilized [22:42:51 CEST] <JEEB> or dvb subtitles (which are images) [22:43:19 CEST] <pkeroulas_> and text-to-bitmaps is complicated, right? [22:43:44 CEST] <JEEB> I wouldn't say complicated, but not sure how easily you can do it with the command line app [22:43:45 CEST] <another> nvm, it does [22:44:15 CEST] <JEEB> I don't think we have a libzvbi encoder module (if it supports *encoding* dvb teletext) [22:44:21 CEST] <JEEB> but in theory that way you could stick text into mpeg-ts :P [22:44:29 CEST] <JEEB> in a way that receivers like [22:45:00 CEST] <JEEB> but since your input is US style closed captions more often you stick those closed caption packets to video tracks [22:45:10 CEST] <JEEB> not sure how easily or if at all the command line app supports that [22:45:40 CEST] <JEEB> which is going to become a theme I think. since the API gives you possibilities to do a lot of stuff, but you can guess how many things are properly implemented in ffmpeg.c and friends because it has its limitations :P [22:49:30 CEST] <pkeroulas_> "./configure --help [...] --enable-libzvbi enable teletext support via libzvbi [no]" [22:49:58 CEST] <JEEB> yea but I think that was decoder only [22:50:14 CEST] <JEEB> yes [22:50:15 CEST] <JEEB> libavcodec/libzvbi-teletextdec.c [22:50:20 CEST] <JEEB> > teletextDEC [22:50:52 CEST] <JEEB> you would have to add a module yourself and propose it to be added to FFmpeg if you want to create teletext subtitles :) [22:52:43 CEST] <pkeroulas_> interesting [22:54:06 CEST] <pkeroulas_> what about inserting the CC in video frames? It doesn't work either in my case. -a53cc doesn't seem to help. [22:55:18 CEST] <JEEB> pkeroulas_: you can do that with the API just fine. the command line tools work with this when the input is in the incoming video packets (because the tools don't have to do anything in that case) [22:55:30 CEST] <JEEB> also they get passed by default in most encoders by now [22:56:03 CEST] <JEEB> so in case of the input having the captions in a separate track, you would have to make the command line application take the packets from that stream and stick them together with decoded video frames being pushed into the encoder [22:56:13 CEST] <JEEB> which it currently does not do [23:02:53 CEST] <pkeroulas_> yes, JEEB I have been trying to stick the cc track to the video track, using the command line. Developing a new app on top of API sounds more complicated to me than adding libzvbi :) [23:03:09 CEST] <pkeroulas_> thanks for your help [23:43:51 CEST] <faLUCE> Hello. Which could be the best way to force an h264 keyframe with lavc? InputLibAVFrame->pict_type = AV_PICTURE_TYPE_I before send_frame() ? [23:44:53 CEST] <DHE> basically yes [23:59:05 CEST] <faLUCE> thanks DHE [00:00:00 CEST] --- Tue Apr 9 2019

1 0

ffmpeg-devel.log.20190407
by burek 08 Apr '19

08 Apr '19

[02:01:17 CEST] <cone-429> ffmpeg 03Carl Eugen Hoyos 07master:d234ed76330a: lavf/Makefile: Fix kux demuxer standalone compilation. [04:27:35 CEST] <cone-429> ffmpeg 03Jun Zhao 07master:7c1875143db4: doc/examples/metadata: fix the example can't dump FLV metadata [08:20:57 CEST] <cone-973> ffmpeg 03Lauri Kasanen 07master:50e672bc5437: swscale/ppc: VSX-optimize non-full-chroma yuv2rgb_1 [08:20:58 CEST] <cone-973> ffmpeg 03Lauri Kasanen 07master:3256e949be7b: swscale/ppc: VSX-optimize yuv2rgb_full_2 [08:20:59 CEST] <cone-973> ffmpeg 03Lauri Kasanen 07master:8607e29fa3d4: swscale/ppc: VSX-optimize yuv2rgb_full_X [11:22:31 CEST] <superware> AVPacket holds pts/dts, where can I find the corresponding time_base relating to the entire packet? [11:23:53 CEST] <nevcairiel> depends where you got the packet from [11:24:48 CEST] <nevcairiel> when demuxing, its time_base in the corresponding AVStream [11:25:08 CEST] <nevcairiel> when encoding its the time_base of the encoding context [11:25:20 CEST] <nevcairiel> thats probably all major sources of AVPackets [11:26:28 CEST] <superware> I'm demuxing using av_read_frame, there are multiple streams inside an AVPacket [11:26:43 CEST] <nevcairiel> no, every packet always corresponds to one stream [11:26:53 CEST] <superware> hmm [11:27:15 CEST] <nevcairiel> identified by stream_index [13:04:53 CEST] <superware> nevcairiel: is there a way to have ffmpeg return the next frame (av_read_frame) from a file at playback speed? [13:05:16 CEST] <nevcairiel> no [13:11:47 CEST] <superware> I'll really appreciate any help: I have an app which has a MediaInput class that has a thread spitting out packets, and a MediaPlayer class which has a thread filling a queue of frames (avcodec_receive_frame) and another thread which dequeue and handles synchronization and rendering, this works well for network streams, but not for files since MediaInput has no synchronization. is this a valid use case? [13:12:34 CEST] <nevcairiel> typically you would synchronize on rendering, ensuring that audio a nd video are rendered at the appropriate times, and with limited queue space it would limit everything else automatically [13:13:15 CEST] <superware> so you basically say the MediaPlayer queue is redundant [13:13:56 CEST] <superware> ? [14:02:34 CEST] <superware> nevcairiel: thanks [16:06:59 CEST] <cone-083> ffmpeg 03Nikolas Bowe via ffmpeg-devel 07master:4c8e3725d9ff: avfilter/af_asetnsamples: fix sample queuing. [16:30:20 CEST] <j-b> Oh, come on [16:30:25 CEST] <j-b> "Nikolas Bowe via ffmpeg-devel [16:30:30 CEST] <j-b> How is that a name? [16:30:42 CEST] <nevcairiel> thats just email being terrible [16:30:57 CEST] <nevcairiel> and the commiter being lazy or forgetting to fix it [16:30:58 CEST] <j-b> yet, it stays forever in the git history [17:07:43 CEST] <durandal_1707> force push it [17:07:50 CEST] <JEEB> we already have a few of those :P [17:07:59 CEST] <JEEB> just means that whomever is pushing should double-check author/e-mail [17:30:51 CEST] <michaelni> or automate it with a script that works better than mine, which failed to catch this one as it was just looking for a name which this one had [17:35:01 CEST] <JEEB> michaelni: yea. I guess checking for "via ffmpeg-devel" or something would have caught this [17:35:27 CEST] <JEEB> also checking for the e-mail [17:35:38 CEST] <JEEB> XXX via ffmpeg-devel <ffmpeg-devel(a)ffmpeg.org> [17:35:40 CEST] <JEEB> seems to be the pattern [17:35:50 CEST] <jamrial> looking for @ffmpeg.org email as author seems easier [17:36:20 CEST] <JEEB> yea [17:53:50 CEST] <BtbN> How does it determine the commiter Name/Email? Just the user.name and user.email of the one who ran git commit? [17:53:54 CEST] <BtbN> Or push, rather? [17:55:16 CEST] <JEEB> git commit, yea [17:55:56 CEST] <JEEB> git push just pushes those info nodes onto a remote server [18:12:25 CEST] <durandal_1707> vel0city: do not forget to finalize proposal, without it you can not work at all... [18:32:27 CEST] <durandal_1707> michaelni: now when i have both codes, symbols and bit-lengths how can i dechipher this algo? [18:34:43 CEST] <michaelni> look for patterns [19:15:17 CEST] <durandal_1707> michaelni: what patterns? anything specific? [19:22:32 CEST] <durandal_1707> what a waste, libreoffice dec2bin is limited to -512-512 [21:11:30 CEST] <durandal_1707> michaelni: ugh asetnsamples change is wrong [21:12:00 CEST] <durandal_1707> warning is issued here [21:16:52 CEST] <BradleyS> $(.+) via (.+)^ [21:17:23 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:3a2adeedaff3: avformat/riffdec: pass correct pointer to av_log [21:17:23 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:ecdaa4b4fa52: avfilter/af_asetnsamples: use correct function [21:17:40 CEST] <BradleyS> ^$ obviously [22:05:52 CEST] <durandal_1707> apparently mpc-be guys ripped my dhav code [22:08:52 CEST] <jamrial> for what purpose? [22:10:13 CEST] <durandal_1707> for demuxing in dvrsplitter [00:00:00 CEST] --- Mon Apr 8 2019

1 0

ffmpeg.log.20190407
by burek 08 Apr '19

08 Apr '19

[11:13:51 CEST] <superware> AVPacket holds pts/dts, where can I find the corresponding time_base relating to the entire packet? [13:56:22 CEST] <DHE> in the avformatcontext->streams[pkt- [13:57:09 CEST] <DHE> in avformatcontext->streams[pkt->stream_index]->time_base iirc [18:36:30 CEST] <jokoon> hello [18:38:20 CEST] <jokoon> so scale="320:-1" requires -vf before it [18:39:37 CEST] <another> was that a question? [18:46:40 CEST] <jokoon> yes [18:46:47 CEST] <jokoon> I guess it's a yes but nevermind [18:46:48 CEST] <jokoon> Invalid pixel aspect ratio 5121/5120, limit is 255/255 reducing [18:47:31 CEST] <jokoon> I realized what I wanted was scale="-1:320" [18:47:58 CEST] <jokoon> converting from 264 to mp4 [18:48:09 CEST] <jokoon> I know it's wrong but Im doing it anyway [18:48:56 CEST] <JEEB> also generally I would recommend -2 instead of -1 [18:49:19 CEST] <JEEB> since if you're converting to 4:2:0 etc you need the resulting value to be divisible by two [18:49:47 CEST] <JEEB> since in 4:2:0 the chroma layers are stored in a single value for a 2x2 block [18:49:51 CEST] <jokoon> mh ok thanks for the heads up [18:50:34 CEST] <JEEB> and yes, that "scale=blah" thing is a filter chain [18:50:52 CEST] <JEEB> so you either put it into a vf (video filter chain), or if you want more fancy things there's also the complex filter chain stuff [18:51:00 CEST] <jokoon> any doc for that precise -2 ? [18:51:05 CEST] <jokoon> ok [18:51:29 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#scale-1 [18:51:47 CEST] <jokoon> thanks [18:51:47 CEST] <JEEB> > If one and only one of the values is -n with n >= 1, the scale filter will use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary. [18:52:42 CEST] <jokoon> mmmh [18:52:52 CEST] <jokoon> what if the input is not divisible by 2? [18:53:12 CEST] <jokoon> should I use a n that is a multiple of the input? [18:53:18 CEST] <JEEB> the input doesn't really matter [18:53:26 CEST] <JEEB> this is just a calculation based on the input values [18:53:43 CEST] <jokoon> I don't understand, why -2 instead of -1 then? [18:53:55 CEST] <JEEB> that controls the output divisibility [18:54:24 CEST] <jokoon> but anything is divisible by 1 [18:54:43 CEST] <JEEB> ok, so most video out there and most likely what you are pushing out is 4:2:0 [18:54:58 CEST] <JEEB> 4:2:0 is a way in YCbCr where the "black and white" (luma) has full resolution [18:55:09 CEST] <JEEB> but then the color information is stored for a single value for a 2x2 block [18:55:29 CEST] <JEEB> you cannot store images with the height/width not being divisible by two in 4:2:0 [18:55:43 CEST] <jokoon> ok [18:55:46 CEST] <JEEB> if you set -1 you are not making sure your calculation output is divisible by two [18:55:56 CEST] <JEEB> -2 is meant to help with that part [18:56:16 CEST] <JEEB> because after the scaling your exact output value might be not divisible by two [18:56:17 CEST] <JEEB> :P [18:57:38 CEST] <jokoon> I thought that rule only applied for 264, not for mpeg [18:57:52 CEST] <JEEB> it applies to anything coding in 4:2:0 [18:57:54 CEST] <JEEB> it's not the format [18:58:01 CEST] <JEEB> like the video compression format [18:58:13 CEST] <JEEB> H.264 for example supports everything from 4:0:0 to 4:4:4 [18:58:27 CEST] <JEEB> the first being "no color information at all" to "color information is full resolution" [18:58:47 CEST] <JEEB> the reason why everyone uses 4:2:0 for video is because that's what everything most often supports :P [18:59:13 CEST] <TheAMM> (where's my 4:1:1) [18:59:40 CEST] <TheAMM> Or wait, does H.264 handle that too? [19:02:02 CEST] <jokoon> scale="320:-2" will be a height of 320 right? [19:02:13 CEST] <jokoon> no a width [19:02:17 CEST] <DHE> width:height [19:02:30 CEST] <jokoon> yes [19:02:49 CEST] <DHE> 4:1:1 isn't listed as supported by libx264... 4:2:0 is the most common, being what hardware decoders are usually limited to and what broadcasts like TV and Youtube run [19:03:10 CEST] <jokoon> what's better about 4:1:1 or 4:4:4 ? [19:03:52 CEST] <DHE> 4:4:4 has full colour data for all pixels. any other (lower) number has adjacent pixels share at least some chroma data with each other [19:04:22 CEST] <jokoon> so higher color restitution [19:05:56 CEST] <jokoon> mmmmh so will I save space with 4:1:1? [19:06:12 CEST] <TheAMM> Please don't use 4:1:1 [19:06:16 CEST] <TheAMM> Forget my joke [19:06:17 CEST] <DHE> since x264 doesn't support it, yes since it will produce a 0 byte file [19:06:24 CEST] <DHE> :) [19:06:29 CEST] <jokoon> is there a way to save space when converting from 264 to mpeg4? [19:06:44 CEST] <DHE> wait, what? why are you going from mpeg4 part-10 to part-2 ? [19:06:57 CEST] <jokoon> Im converting to mpeg4 so I guess it doesn't matter? [19:07:13 CEST] <jokoon> a device cant read 264 [19:07:19 CEST] <jokoon> it's a old nokia phone [19:07:20 CEST] <DHE> what ffmpeg calls "mpeg4" is the video codec once known as divx back in like 2001 [19:07:31 CEST] <DHE> oh, my condolences. [19:11:59 CEST] <JEEB> DHE: mpeg-4 part 2, which was the "original" MPEG-4 video codec in that set of specs. nobody probably thought back then that we'd have multiple :) [19:12:14 CEST] <JEEB> you had pt1 for containers/system stuff [19:12:17 CEST] <JEEB> pt2 for video [19:12:22 CEST] <JEEB> pt3 for audio I think? [19:12:53 CEST] <DHE> JEEB: my company has an IPTV product. whenever I hear "MPEG4" I had to mentally substitute "H264" [19:13:18 CEST] <JEEB> yea, by now that makes sense :) [19:13:26 CEST] <JEEB> since mpeg-4 part 2 more or less simmerred off [19:13:50 CEST] <JEEB> or well, it's unfortunate but makes sense xD [19:13:54 CEST] <DHE> and I'm largely okay with it, but then these little incidents happen with [really] old hardware or users getting confused [19:49:13 CEST] <shibboleth> i've got a security camera which will only provide video over rtsp (h264) and only provide audio over http (pcm_ulaw). how can i run a background, respawning process to provide a muxed rtsp stream for a third party DVR? [20:12:47 CEST] <dablitz> getaddrinfo(fc6f, 19): Name or service not known [20:12:47 CEST] <dablitz> rtp://fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d:52000: Input/output error <--- can I get some help. using ---> ffmpeg -f alsa -i hw:1,0 -acodec pcm_mulaw -f rtp rtp://fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d:52000 [20:23:33 CEST] <another> dablitz: try putting the ipv6 addr in brackets [ ] [20:24:02 CEST] <dablitz> another thankyou I will try that [20:24:31 CEST] <dablitz> that worked thanks [20:46:57 CEST] <dablitz> ffmpeg -re -f alsa -i hw:1,0 -acodec pcm_mulaw -f rtp rtp://[fca4:b047:503e:3bfb:413c:5726:3a69:e82a]:52000 <--- this starts what it is suppose to start doing, but the other end ---> ffplay rtp://[fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d]:52000 produces this error ---> [rtp @ 0x7fe020000b80] Unable to receive RTP payload type 97 without an SDP file describing it [20:47:21 CEST] <dablitz> Input #0, rtp, from 'rtp://[fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d]:52000': [20:47:46 CEST] <dablitz> Duration: N/A, bitrate: N/A [20:48:10 CEST] <dablitz> Failed to open file 'rtp://[fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d]:52000' or configure filtergraph [21:05:37 CEST] <pranayvshah> Can someone please please help me with this issue - https://github.com/harfbuzz/harfbuzz/issues/1654 [21:07:23 CEST] <another> dablitz: look into rtsp [21:09:12 CEST] <dablitz> another, this is something I am very new at. all I want to do is stream simple audio via ffmpeg point to point. would happen to have a good document on rtsp? [21:10:10 CEST] <another> 'fraid not [21:10:44 CEST] <another> i'm not an expert on this either [21:10:44 CEST] <dablitz> ok i will continue to google [21:12:32 CEST] <pranayvshah> I tried with Handbrake GUI and the output (the hindi subtitles) were rendered correctly. Tried the same with HandbrakeCli, that worked too. Adding the subs as a stream works fine too when I view the video through VLC media player [21:30:54 CEST] <pranayvshah> Can someone please please help me with this issue - https://github.com/harfbuzz/harfbuzz/issues/1654 . I tried with Handbrake GUI and the output (the hindi subtitles) were rendered correctly. Tried the same with HandbrakeCli, that worked too. Adding the subs as a stream works fine too when I view the video through VLC media player [21:51:00 CEST] Last message repeated 1 time(s). [21:55:30 CEST] <pink_mist> please don't repeat yourself this much [21:55:40 CEST] <pink_mist> at least wait a couple of hours between asking [21:56:43 CEST] <pranayvshah> Sorry about it, I am new to IRC chat and I was not sure my message was even being broadcast [21:58:27 CEST] <Ariyasu> set utf-8 [21:59:10 CEST] <pranayvshah> My file is UTF-8 encoded and ffmpeg subtitles documentation says that is the default anyway. [22:00:10 CEST] <Ariyasu> -sub_charenc UTF-8 [22:00:16 CEST] <Ariyasu> ok [22:00:38 CEST] <Ariyasu> i remember mkvmerge never set it and always used system default which screwed up a ton of sub files rendering for years [22:01:13 CEST] <pink_mist> it wouldn't screw up like his screenshots show though. [22:02:32 CEST] <pranayvshah> Just tried with the charenc set to UTF-8, did not make a difference [22:03:02 CEST] <Ariyasu> so Glyph 0x74 not found in your font [22:03:13 CEST] <Ariyasu> i take it thats the character that gets messed up? [22:04:26 CEST] <pranayvshah> No, that's not the character which is getting messed up [22:08:47 CEST] <pink_mist> Ariyasu: it's just a little line on top of the characters that gets put in the wrong place (or at least that's what it looks like to me who can't tell front from back of any of those characters) [22:21:25 CEST] <pranayvshah> Hey sorry, is the difference clearer with this picture - https://res.cloudinary.com/qblm/image/upload/v1554668448/Annotation_2019-04… [23:19:27 CEST] <f3ndot> Curious: is there a timeline for the 4.2 release? where can such information be obtained? [23:23:36 CEST] <JEEB> I don't think there is [23:23:57 CEST] <JEEB> releases are cut every N months, at semi-random spots [23:43:34 CEST] <coolhp48> Hi JEEB. Thank you for your help yesterday. You did point me in the right direction. Those AAC frames I was trying to decode were indeed RAW AAC without the ADTS headers. I ended up just reconstructing an ADTS header and adding that to every frame I received before passing it to the AV_CODEC_ID_AAC decoder. [23:43:50 CEST] <coolhp48> It works like a charm. [23:46:07 CEST] <JEEB> nice [23:51:03 CEST] <coolhp48> Now I'm stuck with another issue and I have no idea of where to get started with this : In the framework I'm working off of, I'm given a uint8_t* pointer called "sampleBuffer". This is actually an array of pointers, one per channel. Each channel has a pointer to an uint8_t that is supposed to be where I should write the RAW PCM. But the AV_CODEC_ID_AAC decoder gives me float32s instead of uint8s and I have no [23:51:04 CEST] <coolhp48> idea of how to overcome that. [23:51:28 CEST] <coolhp48> This is very poorly explained... probably because I myself arent sure of what I'm dealing with here. [23:52:58 CEST] <coolhp48> Is it possible to convert 32bit float PCM to 8bit unsigned int PCM on the fly ? [23:53:20 CEST] <JEEB> yes [23:53:37 CEST] <JEEB> either via swresample with the AVFrame API, or through libavfilter audio filtering which utilizes swresample in the background [23:53:53 CEST] <JEEB> which in both cases means that you feed the resampler the AVFrame you get from decoder [23:54:03 CEST] <JEEB> and you get another AVFrame back [23:54:30 CEST] <coolhp48> Aha ! That sounds promising. I'm going to look into it right away. Thanks JEEB ! [23:54:48 CEST] <JEEB> :) [23:55:34 CEST] <coolhp48> Is examples/resampling_audio.c what I should be looking at as a roadmap ? [00:00:00 CEST] --- Mon Apr 8 2019

1 0

ffmpeg-devel.log.20190406
by burek 07 Apr '19

07 Apr '19

[15:23:31 CEST] <cone-059> ffmpeg 03Octavio Alvarez 07master:f4f40cbb578a: lavd/x11grab: fix vertical repositioning [15:55:47 CEST] <cone-059> ffmpeg 03Swaraj Hota 07master:208ae228fa12: lavf/flvdec: added support for KUX container [20:31:42 CEST] <durandal_1707> michaelni: i got working code, take a look: https://github.com/richardpl/FFmpeg/tree/agm [20:32:13 CEST] <durandal_1707> doesn't look like typical huffman coding to me, isn't it? [20:32:33 CEST] <JEEB> &34 [20:32:53 CEST] <durandal_1707> JEEB: did you played with bink2? [20:33:08 CEST] <JEEB> didn't have time yet, sorry :) [21:07:43 CEST] <durandal_1707> michaelni: more specifically, it appears it encodes cases for longer (2 bytes) symbols iiuc [21:19:30 CEST] <durandal_1707> or that is just 2 sequential symbols ... [21:20:30 CEST] <pridkett> why is FFMPEG listed in GSOC? are you people looking for more ffmpeg devs ? [21:21:23 CEST] <durandal_1707> why it shouldn't be listed? [21:22:21 CEST] <pridkett> i thought there are enough ffmpeg devs [21:22:33 CEST] <durandal_1707> lol [21:41:20 CEST] <durandal_1707> michaelni: extracting codes from table, and using only codes for 1 byte symbols, sucessfully decodes first frame! [21:41:56 CEST] <durandal_1707> now i just need to figure out how codes are generated, the code is unreadable currently [00:00:00 CEST] --- Sun Apr 7 2019

1 0

ffmpeg.log.20190406
by burek 07 Apr '19

07 Apr '19

[02:57:40 CEST] <CCFL_Man> ffmpeg0 in freebsd has ffserver0 [05:05:04 CEST] <tombert> Howdy, I'm trying to do an HLS stream using this following command: ffmpeg -y -i /dev/video0 -vcodec h264_omx -f hls -hls_time 30 -hls_segment_filename "fileSequence%Y%03d.ts" prog_index.m3u8 [05:05:27 CEST] <tombert> I want to put the year in the filename, but the file will have the literal %Y in the name [05:05:36 CEST] <tombert> how do I go about making the filename have a timestamp [05:07:09 CEST] <fella> $(date +%Y) [05:12:05 CEST] <tombert> What if I want the filenames to update automatically? [05:14:09 CEST] <tombert> if I do the $(date) thing, won't that only load the date initially [05:14:09 CEST] <tombert> ? [05:14:47 CEST] <furq> tombert: -strftime -hls_segment_filename fileSequence%Y%%03d.ts [05:15:45 CEST] <furq> oh i guess you need -hls_flags second_level_segment_index as well [05:16:29 CEST] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#Options-5 [05:20:12 CEST] <texasmynsted> it seems I need remux a video h264 but the timestamps/timecodes are invalid or incomplete [05:25:30 CEST] <tombert> furq: that worked, thank you! [05:25:44 CEST] <tombert> my home security system is complete! [06:15:38 CEST] <lindylex> What is the last thing I should see when I build ffmpeg from source? I see this at the end "STRIP ffprobe" [06:23:24 CEST] <furq> if you don't see an error then congratulations, you won [06:24:32 CEST] <lindylex> I saw lots of these "fftools/ffprobe.c:2920:13: warning: codec is deprecated [-Wdeprecated-declarations]" [06:24:42 CEST] <ricekrispie> warnings aren't errors [06:24:45 CEST] <ricekrispie> you're fine [06:24:46 CEST] <furq> ^ [06:25:25 CEST] <lindylex> This is a line in the ./config [06:25:27 CEST] <lindylex> PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \ [06:25:37 CEST] <ricekrispie> ok [06:25:44 CEST] <lindylex> I guess this installs to my home directory? [06:25:56 CEST] <furq> no [06:26:07 CEST] <lindylex> Where? [06:26:11 CEST] <furq> --prefix [06:26:19 CEST] <furq> but if you didn't run make install then it hasn't installed anywhere yet [06:26:38 CEST] <lindylex> Ok now I get it. I did not do that. [06:26:50 CEST] <ricekrispie> most open source projects just have the resulting binary in the same directory that you started the build in [06:26:52 CEST] <ricekrispie> try ./ffmpeg [06:27:03 CEST] <furq> it's in ffbuild/ now afaik [06:27:12 CEST] <ricekrispie> o [06:27:19 CEST] <ricekrispie> I haven't built ffmpeg in a long time [06:27:23 CEST] <ricekrispie> carry on [06:27:57 CEST] <lindylex> Ok this is awesome the binary is there and this is what I wanted. I do not want to make install it. [06:28:19 CEST] <furq> did you build with --enable-static [06:28:30 CEST] <lindylex> The binary is in the ./ffmpeg [06:29:17 CEST] <lindylex> This is what my full configure was https://pastebin.com/bFPCW7DL [06:29:42 CEST] <pridkett> what is the command to use AV1 video codec with ffmpeg? [06:29:45 CEST] <lindylex> furg : i did not. [06:30:00 CEST] <lindylex> Let me try adding this. [06:31:17 CEST] <lindylex> Sorry here it is https://pastebin.com/bFPCW7DL [06:31:38 CEST] <furq> if you don't want to install it then you'll want --enable-static [06:32:14 CEST] <lindylex> Like this https://pastebin.com/CGaruRKh [06:35:45 CEST] <lindylex> I am really trying to build ffmpeg-gl-transition and have encountered so many errors. [06:54:41 CEST] <pridkett> where can i get binary for ffmpeg 4.1.3 ? [06:56:31 CEST] <lindylex> pridett you can build it http://ffmpeg.org/download.html#build-linux [06:56:38 CEST] <lindylex> What OS is this for? [06:56:51 CEST] <pridkett> win64 [06:57:08 CEST] <lindylex> Ok I do not know how to do that for Windows. [06:58:32 CEST] <lindylex> pridkett : try thi https://ffmpeg.zeranoe.com/builds/ [06:58:46 CEST] <pridkett> i don't see 4.1.3 [12:34:59 CEST] <^Neo> I'm trying to use two BMD Quad 2's in a single machine with FFmpeg and the cards get enumerated with the same name... is this correct? [12:35:53 CEST] <^Neo> i.e. `DeckLink Quad (1)` through `DeckLink Quad (8)` and then `DeckLink Quad (1)` through `DeckLink Quad (8)` [12:36:21 CEST] <JEEB> I think we're just reading them how the system is providing them [12:36:30 CEST] <JEEB> is this dshow or which module? [12:36:50 CEST] <^Neo> uhhh on linux, so the decklink module [12:37:15 CEST] <^Neo> I was going to start digging into decklink_dec.cpp [12:37:34 CEST] <^Neo> I saw that going from 3.x to 4.x the enumeration code had changed [12:37:35 CEST] <JEEB> then quite likely how the decklink lib is exporting them [12:37:46 CEST] <^Neo> yeah, I figured... [13:38:46 CEST] <^Neo> @JEEB, so new to 4.x is the `-sources` option which gives some sort of colon delimited triplet that can be used to uniquely select ports on separate cards [13:38:57 CEST] <^Neo> so that works for me :+1: [13:39:28 CEST] <^Neo> I think 3.x FFmpeg only gave the name which would duplicate and had no notion, but I haven't tested that out [13:39:42 CEST] <JEEB> coolio [16:15:04 CEST] <gamelaster> Hi everyone, I have command which joining 1000 png frames with transparent bg into webm. Problem is that, after the rendering is complete, my webm contains default removed background (which isn't in frames), how is this possible and how to fix it? Thanks [16:27:59 CEST] <pink_mist> I don't believe webm supports alpha channel (a.k.a. transparency) [16:28:06 CEST] <pink_mist> I could be wrong, but that's my belief [16:28:25 CEST] <JEEB> vpX series of formats kind of support it, but it's a special snowflake [16:29:07 CEST] <JEEB> so the decoding might not work correctly with FFmpeg's internal decoder [16:29:18 CEST] <JEEB> you might want to check how something utilizing libvpx's decoding fares [16:29:28 CEST] <JEEB> also check that you are passing to the encoder something with the alpha channel intact [16:29:34 CEST] <JEEB> yuvaBLAH [16:29:39 CEST] <JEEB> instead of yuvBLAH [16:29:46 CEST] <JEEB> the a noting that it has alpha [16:52:32 CEST] <gamelaster> ffmpeg -framerate 12 -f image2 -i frame%04d.png -c:v libvpx-vp9 -vf format=rgba -pix_fmt yuva420p output.webm [16:53:13 CEST] <gamelaster> I'm using this, it works for few frames, but after that, it using "hidden" pixels, and I see my frames, but with old background, what is really crazy [17:04:29 CEST] <gamelaster> the images have "dirty transparency" problem, but I have no idea how to fix it [18:17:32 CEST] <nitrxgen> gamelaster, seems like something i wouldnt let ffmpeg try to fix, no way to batch edit the images first? [18:21:31 CEST] <nitrxgen> i think webm does support transparency, seems to be demonstrated here > http://www.sciencelifeny.com/transparency/transparency.html# [18:23:19 CEST] <nitrxgen> but actually it looks like that's done with video masking [18:58:30 CEST] <JEEB> nitrxgen: VPx formats since ancient times (at least VP6 series) have had transparency but it has kind of been a separate "video" within the video stream, so it was kind of outside the "normal" video decoding [18:58:45 CEST] <JEEB> which is why FFmpeg doesn't support it with at least some of the VPx formats [18:59:04 CEST] <JEEB> if you encode and decode with libvpx then you most likely can get it with VP8/9 [18:59:32 CEST] <JEEB> and I think the libvpx encoder/decoder wrappers might even support it if you pass YUVA into the encoder [19:00:41 CEST] <nitrxgen> that doc i linked to seemed to instruct you to double the height of the created video and use the bottom half for the mask, the rest seems to be done with js [19:01:47 CEST] <nitrxgen> as far as in depth video container/stream format stuff goes it's beyond me, not gonna lie lol [19:03:16 CEST] <JEEB> yea, that's just a hack :P [19:03:28 CEST] <nitrxgen> oh of course [19:03:32 CEST] <JEEB> the VPx formats actually have alpha layer [19:03:39 CEST] <JEEB> but it's not part of the primary image coding [19:03:43 CEST] <JEEB> which is why it's easy to "skip" it [19:03:51 CEST] <JEEB> (like I think FFmpeg does with VP8/9 decoding) [19:03:57 CEST] <JEEB> with the internal decoder, that is [19:04:03 CEST] <JEEB> I think the ye olde VP6 decoder has support for it [19:22:05 CEST] <pridkett> what do you people think about AV1 ? it's claiming it can produce same quality as half size of x264 [19:30:00 CEST] Last message repeated 1 time(s). [19:30:29 CEST] <durandal_1707> it is best [19:30:55 CEST] <pridkett> durandal_1707 then why aren't people using? [19:31:07 CEST] <pridkett> it [19:35:53 CEST] <durandal_1707> pridkett: are you troll? [19:36:01 CEST] <pridkett> durandal_1707 huh? [19:36:18 CEST] <pridkett> did i something that wasn't true? [19:36:23 CEST] <pridkett> did i say something that wasn't true? [19:36:31 CEST] <durandal_1707> you are trolling [19:36:41 CEST] <pridkett> because i asked about av1 ? [19:37:42 CEST] <durandal_1707> no [19:39:10 CEST] <pridkett> i don't understand then [19:50:54 CEST] <another> durandal_1707: imho pridkett is either trolling or ... i don't know [19:51:07 CEST] <pridkett> another because i asked about av1 ? [19:53:01 CEST] <another> no, because of the nature and structure of your questions [19:53:45 CEST] <pridkett> another, lol okay, what words should i have used to asked the exact same question then? [19:55:46 CEST] <another> *sigh* read my sentence again [19:57:09 CEST] <durandal_1707> av1 is going to be used soonTM [22:43:14 CEST] <wallace_mu> hi all, how do I scale image with filter_complex, i have this command but it's complaining scale2ref not found [22:43:17 CEST] <wallace_mu> ffmpeg -i inputfile [22:43:18 CEST] <wallace_mu> -i ../1/logo.png [22:43:18 CEST] <wallace_mu> -i ../1/xin.png [22:43:19 CEST] <wallace_mu> -i ../1/comment.png [22:43:21 CEST] <wallace_mu> -filter_complex [22:43:23 CEST] <wallace_mu> "[0][1]overlay=main_w/2-overlay_w/2-10:main_h-overlay_h-10:scale2ref=(W/H)*ih/8:ih/8[v1]; [22:43:25 CEST] <wallace_mu> [v1][2]overlay=main_w-overlay_w/2-10:main_h-overlay_h-10[v2]; [22:43:27 CEST] <wallace_mu> [v2][3]overlay=main_w/2-overlay_w-10:main_h-overlay_h-10 [22:49:25 CEST] <DHE> scale2ref is its own filter [22:49:33 CEST] <DHE> ffmpeg -h filter=scale2ref [22:50:21 CEST] <DHE> wallace_mu: see also https://ffmpeg.org/ffmpeg-filters.html [22:53:24 CEST] <wallace_mu> anyway i can combine these together? [22:53:26 CEST] <wallace_mu> DHE: [22:55:43 CEST] <wallace_mu> DHE: so looks like, for image it only has coreimage filter [22:56:11 CEST] <wallace_mu> still don't figure out how it apply to my command [00:00:00 CEST] --- Sun Apr 7 2019

1 0

ffmpeg-devel.log.20190405
by burek 06 Apr '19

06 Apr '19

[00:06:24 CEST] <BtbN> it's not a script that's meant to be executed though [00:08:43 CEST] <BtbN> oh wait, that one is [00:09:14 CEST] <BtbN> weird, how is that working at all? [00:11:36 CEST] <nevcairiel> iirc it'll just execute in the default shell if no bang is present [00:57:21 CEST] <BtbN> but yeah, should probably have one [11:57:10 CEST] <j-b> 'morning [11:58:05 CEST] <durandal_1707> good day [12:02:04 CEST] <j-b> durandal_1707: what's up, man? [12:03:23 CEST] <kurosu> he's in a huff, man [12:03:41 CEST] <kurosu> can't get his head around some vlc [12:06:17 CEST] <durandal_1707> yea, i'm going learn cryptography skills, man [13:14:46 CEST] <cone-185> ffmpeg 03Andreas Rheinhardt via ffmpeg-devel 07master:18a851aca766: avformat/matroskadec: Improve length check [13:14:46 CEST] <cone-185> ffmpeg 03Michael Niedermayer 07master:2169a3f262be: avcodec/agm: Fix integer overflow with w/h [15:19:53 CEST] <durandal_1707> michaelni: can one generate codes by simply doing something similar like deflate does for canonical codes, it simply shifts left by one position for higher bit lengths? [15:22:19 CEST] <durandal_1707> in one case, there is code of 7 bits, and 9 codes of length 6 (min len is 6, max len is 11) [15:23:41 CEST] <durandal_1707> some 7 length codes are 2a for 0 and a for 5 [15:24:15 CEST] <cone-185> ffmpeg 03Derek Buitenhuis 07master:772c73e61f5d: FATE: Add test for HEVC files that claim to have two first slices [15:24:43 CEST] <durandal_1707> because code of 5 is a and there is 9 codes of lenght 6, i think it uses somethinkg like breath first traversal [15:25:13 CEST] <durandal_1707> does my reasoning make sense? [15:34:53 CEST] <J_Darnley> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfa… [15:35:02 CEST] <J_Darnley> What utter lies from systemd. [15:35:10 CEST] <J_Darnley> "predictable" my arse [16:17:47 CEST] <kierank> J_Darnley: oh yes, fuck that so hard [16:18:10 CEST] <JEEB> something that sounds OK in paper, but lol. [16:18:15 CEST] <JEEB> (bases on the MAC address) [16:19:33 CEST] <J_Darnley> I doubt they ever tried the claim "Stable interface names even when hardware is added or removed" [16:20:15 CEST] <JEEB> well unless they derped it up it should be based on the hw mac address, which in all theory should be unique [16:20:33 CEST] <JEEB> but I've never looked into the details and things have so far JustWorked [16:20:34 CEST] <nevcairiel> i thought it was on the bus location [16:20:39 CEST] <JEEB> oh [16:20:44 CEST] <JEEB> could be [16:20:54 CEST] <JEEB> as I said, I just have a vague idea of that thing [16:21:22 CEST] <nevcairiel> its rather irritating if you say "predictable", but then design it on factors that you don't really know [16:21:30 CEST] <nevcairiel> sure its predicatble, by the software, and thats it [16:21:33 CEST] <JEEB> yes [16:26:49 CEST] <jkqxz> The bus location sounds like a good idea, but unfortunately with PCIe the bus can get renumbered on pretty much any change. [16:27:08 CEST] <jkqxz> Start with enp3s0, change something unrelated (not necessarily physical, could be BIOS setting), now it's enp4s0 and systemd refuses to let your system start because it can't bring up the network on enp3s0 and you need to init=/bin/sh to recover. [16:52:16 CEST] <durandal_1707> why I do not get any comments? [17:08:59 CEST] <durandal_1707> you are not smart enough to reply? [17:09:01 CEST] <jamrial> durandal_1707: my guess is that no one that knows the answer read it [17:44:03 CEST] <JEEB> why do people come up with new extensions for mp4 [17:44:05 CEST] <JEEB> cmfv, cmfa, cmft [17:44:05 CEST] <JEEB> for "CMAF" mp4 [17:44:53 CEST] <gnafu> Big fans of country music? [17:45:10 CEST] <JEEB> :D [18:36:52 CEST] <michaelni> durandal_1707, building or updating a huffman code/tree can be done in _many_ ways, i cannot guess which one your codec (which i do not even know which codec that is) is using [18:45:16 CEST] <durandal_1707> michaelni: tell some ways of building/updating tree you have in mind? [18:45:39 CEST] <durandal_1707> not counting already known stuff available in lavc [18:52:06 CEST] <michaelni> one can have a static tree change the order of the codes or remove and then insert a entry in the tree, something similar to how splay trees work maybe, one could keep track of statistics and when they chnage beyond a threshold recalculate the tree by any method. Knowing nothing about the codec its unlikely i will guess better than you. [18:54:58 CEST] <durandal_1707> michaelni: code lengths are new in every new frame, i assume that from this one can generate single binary tree that just have codes different in each branch, or there can be more than one huffman tree for same set of bit lengths? [18:56:07 CEST] <michaelni> for one set of length you can make MANY valid codes [18:56:17 CEST] <durandal_1707> yes i know that [18:57:09 CEST] <durandal_1707> in each branch you can flip bit you will give to left or right child [18:58:08 CEST] <durandal_1707> codec is agm, (missing features/code) [19:00:20 CEST] <michaelni> there are more valid codes than just from fliping bits on nodes, you can change the structure too and end with the same lengths in many cases [19:01:16 CEST] <michaelni> consider 16 codes of length 4 bits there are more permutations of 16 elements to 16 4bit codes than what one would get from just fliping bits at nodes [19:03:55 CEST] <durandal_1707> what you mean by structure? the different look of tree? [19:06:51 CEST] <michaelni> For example A and B could be leafs on a node and C and D could be leafs on another node. 3 bits to flip here but a totally different valid tree with identical lengths could have A and C leafs on a node and B and D leaves on a node which then connect together again with 3 bits on nodes to flip [19:09:44 CEST] <durandal_1707> could i derive same algo if i gather all codes? [19:11:17 CEST] <michaelni> maybe, probably, ... i assume its not intentionally obfuscated with hard crypto ... [22:24:51 CEST] <durandal_1707> michaelni: can you grasp what this function does: https://pastebin.com/MsVtRzMq -- i'm lost around 63rd line [22:26:34 CEST] <durandal_1707> basically code uses previously unset arrays [22:27:05 CEST] <durandal_1707> perhaps from look you or someone else can dechipher it [22:39:08 CEST] <michaelni> durandal_1707, access through aiStack7316 might actually go to aiStack6288 and aiStack7316 could be part of aiStack39056, that would make it a nicer size of 8192, but iam just guessing, that might eliminate one unset array [00:00:00 CEST] --- Sat Apr 6 2019

1 0

ffmpeg.log.20190405
by burek 06 Apr '19

06 Apr '19

[01:26:27 CEST] <PhantomSc> Does anyone have an example of how to use '-hls_segment_size'? [02:18:56 CEST] <unlord> how do I find out what version of libaom is in ffmpeg N-93083-g8522d219c [02:22:50 CEST] <unlord> I'm sure the answer is in a file somewhere in here: https://gitlab.com/UbikBSD/Codecs/FFMpeg/tree/8522d219c [02:36:00 CEST] <unlord> how about just printing the one linked in [02:36:13 CEST] <unlord> ffmpeg -encoders shows libaom-av1 [02:44:30 CEST] <kepstin> unlord: might not be an easy way to know without asking the person who built the ffmpeg binary you're using, unless it prints it in a log when encoding something (some encoders do, i haven't checked libaom) or maybe just looking for the version string in the compiled binary :/ [02:45:09 CEST] <kepstin> libaom is an external library, so there's no correlation between the ffmpeg version and the libaom version [02:51:58 CEST] <unlord> kepstin: I downloaded the static Windows build ffmpeg-20190205-8522d21-win64-static.zip and got it by running some video through it: [libaom-av1 @ 0000000000388640] 1.0.0-1297-g52ea88fd1 [02:53:05 CEST] <unlord> Gotta go back and verify these results https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=130284 after this announcement https://twitter.com/janozer/status/1113930266983190529 [02:53:32 CEST] <kepstin> unlord: that looks like a zeranoe build - here's the readme: https://ffmpeg.zeranoe.com/builds/readme/win64/static/ffmpeg-20190205-8522d… [02:54:13 CEST] <unlord> kepstin: libaom is not listed there [02:54:27 CEST] <kepstin> it is, it's just called 'aom' [02:54:37 CEST] <kepstin> shows the same git hash as you saw in the log [02:54:46 CEST] <unlord> wooops, you are right [02:55:09 CEST] <unlord> No idea if Jan Ozer was using this build, but without asking him who knows [02:55:46 CEST] <unlord> Note that the MSU results just came out and came to a very different conclusion on page 17: http://www.compression.ru/video/codec_comparison/hevc_2018/pdf/MSU_HEVC_AV1… [02:56:22 CEST] <unlord> but he wasn't really trying to do the same comparison, so it just sloppy reporting [03:02:09 CEST] <kepstin> every time i see these comparisons, i'm impressed by how close the quality of x264 is to the newer codecs while it's still /way/ faster to encode. [03:03:36 CEST] <furq> unlord: the aom version in the msu report is from january 30th [03:04:44 CEST] <furq> https://aomedia.googlesource.com/aom/+/625cded0550bb79efd10d98a9809a7ccd72a… [03:04:50 CEST] <kepstin> huh, the msu report didn't run av1 in a bitrate target mode, they used cq? [03:05:09 CEST] <kepstin> is 2-pass mode just not finished, or did they not feel like waiting? :) [03:05:12 CEST] <unlord> 625cded0 = Date: Tue Jan 29 19:50:20 2019 -0800 [03:05:22 CEST] <unlord> but yeah, that is just the authored date [03:05:27 CEST] <furq> yeah close enough [03:05:37 CEST] <furq> also idk how much i trust those msu reports if they're only using ssim [03:05:49 CEST] <furq> maybe they do some better analysis in the paid version [03:07:06 CEST] <unlord> furq: when you scroll that blurred PDF, my reader gets jank. Just sayin.... [03:07:17 CEST] <furq> i was going to ask what sz264/sz265 is but the link in the codecs list is just a mailto: [03:07:28 CEST] <furq> not really sure why they would include this but ok [03:09:04 CEST] <kepstin> presumably someone paid them to? [03:09:20 CEST] <kepstin> kinda amazing how closely sz264 tracks to x264 on some of the graphs... [03:09:29 CEST] <furq> yeah until you get to encoding time [03:12:15 CEST] <kepstin> so it's x264 being run in placebo mode, maybe with some asm optimizations removed? :) [03:25:56 CEST] <DHE> AV1 at 1 megabit can encode 1080p @ 25fps at very watchable image quality... [03:27:05 CEST] <DHE> (I did a test video a while ago... many months) [05:26:48 CEST] <Kuukunen> 4 [07:49:28 CEST] <lindylex> I am try to compile ffmpeg with gltransition and I keep getting the following error. https://pastebin.com/JW1Nsehf [13:34:27 CEST] <CCFL_Man> hello, what can one use in place of ffserver? the modern freebsd ports don't have it [13:35:07 CEST] <CCFL_Man> can mkvserver_mk2 provide the same stream that could be compatible with other players? [14:12:31 CEST] <DHE> people say good things about nginx-rtmp [14:13:05 CEST] <DHE> if HTTP-based streaming is acceptable, HLS or Dash with just any old static content HTTP server (apache, nginx plain, etc) can work at the cost of high delay live streaming [15:05:32 CEST] <faLUCE> hello all [15:10:45 CEST] <Freneticks> Hey Is it possible to have 2 input stream and change if input 1 is down to >> -c copy test.ts [15:19:30 CEST] <DHE> ffmpeg doesn't do that dynamically. some manual control can be done with the streamselect filter, but ffmpeg in general doesn't handle outages like that either [15:27:13 CEST] <saml_> you can set up proxy and do failover in the proxy [15:29:07 CEST] <Freneticks> what kind of proxy are you thinking about saml_ [15:29:14 CEST] <Freneticks> or maybe with dns [15:29:55 CEST] <saml_> ah is it generating livestream? [15:30:02 CEST] <Freneticks> yes [15:30:24 CEST] <saml_> and you have two source streams? what protocol those source streams use? HTTP? [15:30:34 CEST] <saml_> i'm not familiar with livestream [15:30:45 CEST] <Freneticks> http yes [15:31:17 CEST] <saml_> i think nginx and haproxy can do failover. If one http upstream is down, use another [15:32:11 CEST] <Freneticks> nice idea will check that [15:32:30 CEST] <saml_> but i don't know how well failover at loadbalancer would work with livestream. it could introduce glitches during failover [16:08:56 CEST] <pink_mist> Freneticks: I was recently informed of http://upipe.org/blog/ which I was told was what one should use rather than (or possibly in front of) ffmpeg for that kind of thing ... I've never used it myself though, so I can't really say whether or not it'll actually work [16:09:29 CEST] <JEEB> it's a framework more geared for live streaming, esp. in broadcast environments. it uses FFmpeg for decoding etc, of course [16:09:45 CEST] <JEEB> it does not have standard modules for web streaming etc, of course [16:09:55 CEST] <JEEB> but it's something I've been meaning to look into for a while [16:10:28 CEST] <pink_mist> yeah, JEEB was the one who informed me :P (though I think he was informing someone else at the time; I was just listening on the side :P) [16:12:14 CEST] <friendofafriend> I was feeding images and audio through a FIFO at ffmpeg to make slideshows. It works sort of OK, but all the sync problems you'd imagine. [16:14:47 CEST] <Freneticks> JEEB: It's a low level lib, why not go on gstreamer and built something good ? [16:15:16 CEST] <JEEB> that's another framework, and also already has logic like switching between alternative inputs? [16:15:22 CEST] <JEEB> also it seems to have alright inputs for stuff like MPEG-TS [16:15:28 CEST] <JEEB> and I like the concept of three timestamps [16:15:32 CEST] <JEEB> you have the original coded timestamp [16:15:40 CEST] <JEEB> you have the adjusted coded timestamp [16:15:44 CEST] <JEEB> and you have the receipt time [16:15:57 CEST] <JEEB> different applications can utilize these things for different things [16:18:39 CEST] <Freneticks> unfortunately i don't know anything about gstreamer, never took the time learn, but seems powerfull, and have the pipe concept too [16:18:55 CEST] <JEEB> all the frameworks have some sort of "pipeline" going [16:19:07 CEST] <JEEB> FFmpeg, upipe, gstreamer [16:20:51 CEST] <Freneticks> Also gstreamer have python bindings which can save me to learn C ^^ [16:45:13 CEST] <while> is rfc3533 the rfc implemented by ffmpeg when encoding OGG files? [16:55:42 CEST] <JEEB> no idea [16:56:15 CEST] <JEEB> it has an ogg muxer which seems apparently capable of writing ogg files readable by other applications [17:00:06 CEST] <kepstin> i'm pretty sure ffmpeg's ogg muxer was written before rfc3533 was published [17:00:46 CEST] <kepstin> but on the other hand, rfc3533 is supposed to be a document of the ogg container as it existed [17:05:23 CEST] <kepstin> ogg itself is of course pretty simple, the tricky stuff is mostly in the individual codec mappings. [17:07:19 CEST] <JEEB> yea [17:33:27 CEST] <Hello71> even though mans hates it [17:41:32 CEST] <dongs> dongs [17:44:19 CEST] <JEEB> perkele [18:43:24 CEST] <CCFL_Man> DHE: i just need low latency http streaming, same thing as what ffserver provided [18:58:35 CEST] <TAFB> How do I get microsecond in my filename with strftime? supposed to be %f I think but I always get "Could not get segment filename with strftime" if I use %f [19:16:56 CEST] <TAFB> "there is no way to get the current time with a higher precision than seconds in POSIX on which FFmpeg depends." [19:16:58 CEST] <TAFB> oh damn :( [19:24:40 CEST] <TAFB> if I can't use microsecongs, how about what frame I'm at in the -i file? [19:29:31 CEST] <TAFB> or how can I use a random number in the filename? [19:29:39 CEST] <TAFB> (windows) [20:21:42 CEST] <while> TAFB: you could probably find a proprietary solution (for creating random numbers) if nothing else works [20:38:00 CEST] <coolhp48> Hello all. I was wondering if this is the appropriate channel to ask a question about libavcodec/libavformat ? [20:38:19 CEST] <JEEB> it is [20:38:39 CEST] <JEEB> this channel for API usage of FFmpeg's libraries, and then the -devel channel is for actual development within the FFmpeg libraries [20:42:03 CEST] <coolhp48> Wonderful. I am in the middle of a puzzle I cant seem to figure out how to solve : I'm trying to decode raw AAC audio frames directly. The data I receive doesnt give me access to the packet itself. I just receive a variable with some context (like the number of channels and number of samples) [20:42:16 CEST] <coolhp48> And a buffer containing a raw AAC frame. [20:43:45 CEST] <coolhp48> In theory the right function to decode it would be either aac_decode_frame_int or aac_decode_frame but I cant access those if I just include libavcodec.h [20:44:07 CEST] <Mavrik> You shouldn't call those directly [20:44:17 CEST] <coolhp48> I've tried "reconstructing" an AVPacket from the buffer but to no avail... [20:44:34 CEST] <coolhp48> I'm at a bit of a loss as to what to try next. [20:44:43 CEST] <Mavrik> see https://ffmpeg.org/doxygen/trunk/decode__audio_8c_source.html [20:45:25 CEST] <coolhp48> Hi Mavrik. Thanks for the link. I've actually used that example as a roadmap for everything I've tried. [20:46:02 CEST] <coolhp48> But the issue with that example is that it expects the contents of the buffer to be a full ADTS/AAC Packet, not just a frame. [20:46:03 CEST] <JEEB> if you don't know if your data is properly separated per packet [20:46:09 CEST] <JEEB> oh [20:46:12 CEST] <JEEB> it's not ADTS? [20:46:24 CEST] <JEEB> or the thing that's in MP4? [20:46:43 CEST] <coolhp48> It should be. But what I'm receiving is really a raw audio frame. Not a full packet. [20:47:22 CEST] <coolhp48> I know its a proper frame because the headers are correct (ie : the first 3 bits indicate either TYPE_CPE, or TYPE_LFE or other) [20:47:35 CEST] <coolhp48> So its really a frame I'm trying to decode, not a packet. [20:50:18 CEST] <coolhp48> Here's an example of the buffer I'm being served : https://pastebin.com/iyqPU5E4 [20:57:11 CEST] <coolhp48> In theory, would this work ? Create an AVFrame, put that raw frame data I'm receiving in ->data[0], then create an AVPacket and somehow store that frame in that new packet, then follow the same logic as decode_audio.c does to finally get the decoded audio buffer ? [21:05:27 CEST] <JEEB> AVFrames are for raw audio/video/etc [21:05:32 CEST] <JEEB> AVPackets are something to feed into a decoder [21:05:43 CEST] <JEEB> or received from an encoder [21:05:49 CEST] <coolhp48> Ok. [21:06:13 CEST] <coolhp48> So assuming I have a byte array that contains an encoded AAC frame... how would I go about decoding it ? [21:06:18 CEST] <JEEB> so you would have to make an AVPacket out of your data in a format that lavc's decoder can take it in [21:06:55 CEST] <JEEB> coolhp48: you make a new AVPacket with the buffer allocated with FFmpeg helpers (to make sure you have needed alignment and additional buffer) [21:07:07 CEST] <JEEB> then make sure your frame is packaged in a way that the AAC decoder can eat [21:08:45 CEST] <coolhp48> Aye... with you so far :-) That's what I've been trying to do... Let me cleanup my code a bit and try again. [21:10:15 CEST] <JEEB> ok, so it expects when you init the decoder that you have the sample rate there [21:10:38 CEST] <coolhp48> Yup, I have that. [21:11:17 CEST] <JEEB> also channel count as far as I can see [21:11:41 CEST] <coolhp48> Just to give you a bit more context, I'm trying to decode an Apple Airplay 2 stream... while the contents of the frames are the same (proper AAC frames) the packets are in a completely different format. [21:11:43 CEST] <JEEB> I'm just looking at what the aac_decode_init() function seems to require to be set [21:11:45 CEST] <coolhp48> Thus my issue. [21:12:17 CEST] <coolhp48> (We're talking AAC stream here, not one using Apple's Lossless codec) [21:14:43 CEST] <JEEB> coolhp48: also if you have means to make it into ADTS or so, sticking the raw aac reader in front of the decoding might let you get the parsing for free, too [21:14:51 CEST] <JEEB> and thus make the whole shebang simpler [21:15:36 CEST] <coolhp48> Ah... that might be a good option... is there an example of how to call up the raw aac reader ? [21:16:20 CEST] <JEEB> there should be an example of how to utilize your own AVIO callback implementation with libavformat [21:16:38 CEST] <JEEB> then you just set the format to be "aac" in the AVFormatContext creation [21:17:01 CEST] <JEEB> yea, doc/examples/avio_reading.c [21:17:15 CEST] <JEEB> seems to be a "libavformat AVIOContext API example." [21:17:27 CEST] <JEEB> in other words, instead of reading from a file or protocol [21:17:39 CEST] <JEEB> you would be providing the functions which libavformat calls when it wants to read or write or seek [21:17:47 CEST] <JEEB> of course in your case you just implement read [21:18:12 CEST] <coolhp48> Looks very promising :-) ... I'm going to read up on it and see what I can figure out. [21:18:48 CEST] <JEEB> you just have to make sure you can make ADTS AAC from whatever you're given [21:25:47 CEST] <coolhp48> Ah... down the rabbit hole I went and low and behold, it looks like what I have are actually LATM ? Trying to understand what that is. [21:28:12 CEST] <JEEB> coolhp48: ok, then you should be able to feed that into the loas reader [21:28:26 CEST] <JEEB> as opposed to the "aac" one which ADTS [21:29:08 CEST] <coolhp48> Trying to adapt the decode example with that in mind.... brb [21:31:08 CEST] <coolhp48> There seems to be a code for that directly (CODEC_ID_AAC_LATM) [21:32:41 CEST] <JEEB> yes, of course you can try your chances and try making an AVPacket out of your data and feeding that into the AAC decoder with that codec id [21:33:03 CEST] <JEEB> if that doesn't seem to work, then you'll have to try the "demuxer" level thing with your own AVIO callbacks [21:33:18 CEST] <JEEB> which will then call the parser on the stream and all that fancy stuff [21:33:45 CEST] <coolhp48> Thanks a lot JEEB.... I'm going to keep going down this avenue and see where it leads. [21:38:07 CEST] <texasmynsted> I have videos recorded using OBS to h264 using "Apple VT H264 Hardware Encoder" with aac audio in mkv container. [21:38:55 CEST] <texasmynsted> They can not be seeked. They play but only from start to finish, no seeking of any kind. I tried copy to mp4, but the same issue exists. [21:39:04 CEST] <texasmynsted> How can I fix this? [21:39:54 CEST] <BtbN> Just remuxing to any other container will fix that. The encoder is entirely irrelevant for that. Unless it did some insanity like not adding I frames at all. [21:40:21 CEST] <texasmynsted> I added bframes [21:40:26 CEST] <texasmynsted> during encoding [21:40:53 CEST] <texasmynsted> so copy from mkv to mp4, should have fixed it? [21:41:51 CEST] <JEEB> yes, if it has random access points correctly marked [21:42:05 CEST] <BtbN> bframes don't matter either [21:42:09 CEST] <JEEB> you might try to extract into a raw .264 file first [21:42:19 CEST] <BtbN> that'll mess up sync with the audio [21:42:28 CEST] <JEEB> if it's VFR, yes [21:42:35 CEST] <BtbN> Even if not [21:42:49 CEST] <JEEB> and I was going to note L-SMASH's mxuer because the frame rate setting patch is not in yet [21:42:51 CEST] <BtbN> Audio and Video might be offset a bit [21:42:56 CEST] <JEEB> well yes [21:43:55 CEST] <BtbN> I'd first make sure if that thing has more than one I frame [21:44:18 CEST] <texasmynsted> how? [21:46:16 CEST] <JEEB> ffprobe's show_packets might not show anything else than what the container is informing it of. thus, probably ffprobe's show_frames + grep for the keyframe flag [21:46:23 CEST] <JEEB> I think it was also in AVFrames? [21:46:28 CEST] <JEEB> don't remember [21:49:43 CEST] <coolhp48> I'm now hitting a strange problem : When I call "codec = avcodec_find_decoder(AV_CODEC_ID_AAC); [21:49:43 CEST] <coolhp48> " , it always return 0x00... any ideas ? [21:49:56 CEST] <JEEB> how old FFmpeg? [21:50:04 CEST] <JEEB> also you need specifically the LATM one [21:50:16 CEST] <JEEB> AV_CODEC_ID_AAC_LATM [21:51:08 CEST] <coolhp48> Yup, that's what I tried too. My FFMpeg is 3.2.12 [21:51:23 CEST] <JEEB> ok, then you need to call av_register_all [21:51:29 CEST] <JEEB> as one of your first things :P [21:51:43 CEST] <JEEB> that was made unnecessary half a year or so ago [21:51:45 CEST] <JEEB> I think? [21:51:54 CEST] <texasmynsted> I guess -count_frames [21:52:14 CEST] <coolhp48> Doh ! ... thank you ! [21:52:25 CEST] <JEEB> texasmynsted: -of json -show_frames |grep keyframe ... I think? [21:52:26 CEST] <texasmynsted> but it will probe for the entire time of the video (I am guessing). Video is 1 hour [21:52:37 CEST] <JEEB> it will decode the whole shebang as fast as it can :P [21:52:48 CEST] <texasmynsted> ok [21:53:08 CEST] <texasmynsted> I will just let it work in the backgroun [21:53:13 CEST] <JEEB> alternatively, extract the H.264 stream and use show_packets [21:53:15 CEST] <JEEB> which is much faster [21:53:24 CEST] <JEEB> because that way it will have to parse the stream [21:53:26 CEST] <JEEB> :) [21:53:50 CEST] <JEEB> as opposed to "this is in a sane container, and I can trust it to have set the flags right") [21:54:00 CEST] <texasmynsted> ok what if it does not have frames or whatever [21:54:06 CEST] <texasmynsted> Can I somehow add them? [21:54:48 CEST] <JEEB> not without re-encoding [21:55:17 CEST] <texasmynsted> Okay, how would I re-encode? [21:55:52 CEST] <texasmynsted> like rather than copy, I am guessing I would somehow let it transcode back to the same codec? [21:56:09 CEST] <JEEB> just check the stream first :P [21:56:17 CEST] <JEEB> since it makes no sense to re-encode if you can just properly remux [22:01:21 CEST] <texasmynsted> okay [22:06:39 CEST] <texasmynsted> many key_frame [22:07:10 CEST] <JEEB> alright [22:07:15 CEST] <JEEB> so it's just a bugged mux \o/ [22:08:23 CEST] <texasmynsted> https://gist.github.com/mmynsted/f976a399080d635fb011ca354d74454d [22:09:05 CEST] <texasmynsted> they are all 1 or 0 [22:09:09 CEST] <texasmynsted> whatever that means [22:10:12 CEST] <JEEB> so yea, you should try to extract the video track, extract the timestamps (they're called "timecodes" with mkvextract or so) for the video track, and then use the separate video track and the timecodes together with the audio from the other matroska file with mkvmerge(gui) or so [22:10:16 CEST] <texasmynsted> so is this correct to re-mux? ffmpeg -i 2019-04-05_13-04-27.mkv -codec copy 2019-04-05_13-04-27.mp4 [22:10:24 CEST] <JEEB> yes, but if your input file's flags are bonkers [22:10:34 CEST] <JEEB> then it will copy the flags incorrectly [22:10:54 CEST] <JEEB> that's why I noted how to do it the "long way" [22:12:58 CEST] <texasmynsted> So then: 1. extract video h264, 2. extract audio aac, 3. extract timecodes, 4. use something called mkvmerge to combine/remux them? [22:14:09 CEST] <JEEB> no need to extract audio [22:15:31 CEST] <JEEB> 1. so extract the video (can be done in ffmpeg) 2. extract the video timecodes (really: timestamps! matroska has brought up a generation of people who go to work in media and get confused about these two). 4) in mkvmerge(gui) stick in a) the audio track from the original mkv (disable video), b) the video from the raw .264 file (with timecodes) [22:15:53 CEST] <JEEB> so you can read the audio as-is, but the video you want to once pull out [22:16:59 CEST] <coolhp48> Question : When I call av_parser_parse2 with my codec set to AV_CODEC_ID_AAC_LATM , which function in actually being called to parse the LATM packet ? Is it latm_parse() from [22:17:00 CEST] <coolhp48> libavcodec [22:17:00 CEST] <coolhp48> latm_parser.c ? [22:18:00 CEST] <texasmynsted> okay thank you. I will try this. I also need to figure out why OBS would do this, to prevent this for future videos. [22:18:22 CEST] <texasmynsted> I do now want to have to do this over and over, each day. Hehe [22:21:50 CEST] <JEEB> coolhp48: if you have an AVPacket you have already "parsed" it [22:22:17 CEST] <JEEB> not sure how you got parsing in there, but not like I've used that API [22:22:40 CEST] <JEEB> if you were getting "standard" LATM AAC packets I would have thought you would have just attempted to feed them to the decoder [22:22:45 CEST] <JEEB> and see how it explodes or not [22:28:33 CEST] <Retal> Guys, what command shows all available ffmpeg filters? Like ffmpeg -h...... [22:29:15 CEST] <durandal_1707> ffmpeg -filters [22:29:47 CEST] <Retal> durandal_1707: thx! [22:34:23 CEST] <JEEB> (45 [00:00:00 CEST] --- Sat Apr 6 2019

1 0