June 2019 - Ffmpeg-devel-irc - lists.ffmpeg.org

ffmpeg-devel.log.20190611
by burek 12 Jun '19

12 Jun '19

[16:33:18 CEST] <Jestin> Hey! Is it possible to create a scheduled livestream with FFmpeg thast plays a video at certain times/ [16:45:57 CEST] <thardin> that sounds more like an OBS question [16:46:10 CEST] <thardin> or some other similar software [16:49:19 CEST] <philipl> BtbN: so those nvenc hdr metadata patches went nowhere? [17:26:19 CEST] <BtbN> nope [17:26:45 CEST] <BtbN> I'm very much against merging that code into nvenc. And nobody seems to have felt the need to implement them as a (bitstream)filter [17:27:00 CEST] <BtbN> philipl, ^ [19:21:55 CEST] <philipl> BtbN: so how would a bitstream filter work. I assume that from an nvenc perspective, you want to pull the metadata as side-data? and the filter's job is to add the sidedata? [19:22:20 CEST] <BtbN> Pretty much, yes [19:22:58 CEST] <philipl> and if it's a transcode, there should be a way to pass it all the way through, and for a raw encoding, the filter would take the command line parameters? [19:23:37 CEST] <philipl> I want to say we already have hdr sidedata defined. nvenc could consume that today if so. [19:25:57 CEST] <philipl> AV_FRAME_DATA_DYNAMIC_HDR_PLUS? [19:26:42 CEST] <JEEB> that's the dynamic one (HDR10+) [19:27:53 CEST] <philipl> For static, what do we do? [19:28:24 CEST] <JEEB> there's two things I think. there's the brightness stuff and the mastering screen stuff [19:28:35 CEST] <philipl> Ok, I thought it might be. [19:28:35 CEST] <JEEB> time to boot up my development VM :) [19:28:53 CEST] <JEEB> we have support for the static metadata on the decoder side so checking the HEVC decoder/parser probably would be simplest? [19:29:24 CEST] <philipl> yeah [19:33:04 CEST] <philipl> vaapi_encode_h265 already pulls it in, so we can follow that as an example. [19:33:19 CEST] <jamrial> philipl: look how the h264_metadata bsf inserts display_orientation sei messages [19:33:37 CEST] <philipl> but yeah, the point is we should add support to nvenc to use the side data and then worry about how a bsf can inject hdr metadata [19:33:38 CEST] <jamrial> you could do the same for the hdr sei messages in h265_metadata bsf [19:33:49 CEST] <jamrial> ok [19:38:29 CEST] <philipl> BtbN: so the guy's change handles side data. That half of the change we could take? [19:39:01 CEST] <BtbN> I don't think it does. It put all the extraction logic and parameters into nvenc. [19:39:21 CEST] <BtbN> Patch 1/3 just changed the structure a bit, to generally support multiple SEI parameters. [19:40:51 CEST] <philipl> So if I read it right, he adds a bunch of fields to nvenccontext and uses those for the encoder param stuff. [19:41:00 CEST] <philipl> he also reads the side data. Sets it into the fields, and then writes the sei. [19:41:14 CEST] <philipl> Presumably you'd remove the fields and just copy the side data directly into the sei [19:43:10 CEST] <philipl> Maybe you still want the command line params that indicate which SEIs to include? Or we just say that if the side data exists, we use it. [19:44:57 CEST] <BtbN> There probably should be an option to ignore side data, as there is for ac53cc [20:29:01 CEST] <mkver> Does anybody have a recent version of ISO/IEC 14496-15 (that's the specification how H.264/HEVC should be put into mp4)? [20:29:42 CEST] <JEEB> I only have the one that I utilized to write the HEVC-in-Matroska draft [20:30:07 CEST] <JEEB> I really have no idea why 14496-15 is not free while both 14496-12 and HEVC are :P [20:30:14 CEST] <JEEB> (same for 14496-10) [20:31:25 CEST] <mkver> You mean this thing that someone (maybe you?) once posted on the Matroska developer mailing list? I already got that. [20:32:01 CEST] <JEEB> https://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.h… [20:32:04 CEST] <JEEB> yea, this is me :P [20:32:55 CEST] <mkver> Then thanks for providing this to us, including me. [20:33:07 CEST] <mkver> Where did you get it in the first place? [20:33:37 CEST] <JEEB> they had their WIP documents available [20:33:38 CEST] <JEEB> > Incheon output document W13478 [20:33:54 CEST] <JEEB> Incheon meeting, and the Wxxxx is the working group document ID [20:34:52 CEST] <mkver> I was actually interested into whether the VisualSampleEntry's width and height really refer to frames and not to fields even for HEVC or whether they changed that eventually. [20:35:30 CEST] <JEEB> I'm still on the mp4-sys mailing list so let's see if they have anything linked there [20:35:40 CEST] <mkver> In my experience their WIP documents are always .doc/.docx files, not pdf. But never mind. [20:36:30 CEST] <JEEB> yes. I just used a PDF printer from office [20:37:49 CEST] <JEEB> seems like 14496-15 5th ed was in FDIS since Jan-19 [20:37:52 CEST] <JEEB> document ID 18241 [20:39:31 CEST] <JEEB> https://sd.iso.org/projects/project/74429/overview [20:39:39 CEST] <JEEB> so they've moved to a "secure" document storage :P [20:39:45 CEST] <JEEB> so you no longer can spy as much [20:40:36 CEST] <mkver> Does this mean that one could have easily downloaded this freely before Jan-19? [20:40:41 CEST] <JEEB> no [20:40:46 CEST] <JEEB> they moved a year or two ago [20:43:33 CEST] <mkver> Ok. Btw: mkvmerge already uses the frame-dimensions for HEVC (https://gitlab.com/mbunkus/mkvtoolnix/issues/2446) [20:45:06 CEST] <JEEB> found what probably became 5th ed? [20:45:07 CEST] <JEEB> w16169 4th ed + 16787C1+16938C2+16490A1+17993A2.docx [20:45:29 CEST] <JEEB> from end of jan [20:48:13 CEST] <kurosu> I'm still using mkvtoolnix 8.3, even for hevc... Not happy with the UI afterwards *lame* [20:49:10 CEST] <mkver> Link doesn't work/is too smart for me. [20:51:47 CEST] <mkver> That's what I initially thought, too, but nowadays, when using old versions looking for whether a bug is a regression or not, it's the complete opposite. Probably just getting used to it. [20:52:00 CEST] <jamrial> kurosu: mkvmerge got a crapload of fixes since that version, including for hevc afaik [20:52:22 CEST] <kurosu> yeah, that's why I'm saying I'm lame [20:52:42 CEST] <kurosu> though it never really impacted me, apparently [20:52:48 CEST] <mkver> Yep. And H.264, too. E.g. changing extradata could result in problems in older versions. [20:53:35 CEST] <JEEB> mkver: try http://fushizen.eu/random/w16169_4th_ed_+_16787C1+16938C2+16490A1+17993A2.p… [20:53:41 CEST] <JEEB> that's the last thing I found on the mailing list :P [20:55:37 CEST] <mkver> Thanks. [21:02:22 CEST] <mkver> The rules for VisualSampleEntry's width and height are more complicated in this version, but the dimensions still apply to frames, not fields. Good to know. [00:00:00 CEST] --- Wed Jun 12 2019

1 0

ffmpeg.log.20190611
by burek 12 Jun '19

12 Jun '19

[00:10:16 CEST] <electrotoscope> brimestone: There's an old build hosted at http://www.ffmpegmac.net/ [00:11:39 CEST] <brimestone> electrotoscope, that side no longer active [00:13:28 CEST] <kepstin> brimestone: seems like the answer is "nowhere", then. It shouldn't be hard to build it yourself on a mac, and there probably is a mac os update available for your system...? [00:13:40 CEST] <electrotoscope> https://web.archive.org/web/20180109214631/http://www.ffmpegmac.net:80/ sorry [00:13:42 CEST] <kepstin> might be an archive.org copy of that site tho [00:14:34 CEST] <kepstin> using an old ffmpeg has similar issues to using an old os, of course, which is that there's likely to be known unpatched security issues. [00:15:32 CEST] <cehoyos> Not just likely... [00:15:44 CEST] <brimestone> Got it.. hope this work [00:16:57 CEST] <brimestone> It works! thanks! [09:21:16 CEST] <grosso> hi [09:25:18 CEST] <grosso> in muxing.c example, line 444 [09:25:41 CEST] <grosso> when it does "avio_open" [09:27:32 CEST] <grosso> suppose I have an avformat_context that is allocated for librtmp [09:28:10 CEST] <grosso> I want to stream out, so using muxer.c example [09:29:08 CEST] <grosso> then, in line 44 it does "avio_open" and that, in turn, calls rtmp_open() in librtmp library [09:29:19 CEST] <grosso> line 444 sorry [09:29:29 CEST] <grosso> so, the question is: [09:30:26 CEST] <grosso> how it is supposed to pass the "rtmp_buffer" parameter to librtmp? because avio_open does not receive a dictionary [09:31:42 CEST] <JEEB> you can't pass option to the librtmp library itself. the option passing is to the AVFormat input or output module [09:31:47 CEST] <grosso> I can send the dictionnary later when writing header (line 451) but it is too late [09:32:13 CEST] <JEEB> so you check what the AVOption it is you want to set [09:33:39 CEST] <grosso> ok, so, when and how to pass that option to av_format before calling avio_open? [09:36:31 CEST] <grosso> in muxing.c example, options are passed in avformat_write_header (line 451) but, for librtmp that is too late, because the actual opening is at avio_open [09:36:59 CEST] <JEEB> yea [09:37:18 CEST] <JEEB> I think the AVFormatContext can have options set to it [09:37:27 CEST] <JEEB> and you create the AVFormatContext first [09:37:36 CEST] <JEEB> (the output lavf context) [09:40:13 CEST] <grosso> maybe... but, pay attention to this: when calling avio_open, no avformat_context is passed, rather is an internal "pb" field, which is an avio_context I think [09:41:33 CEST] <JEEB> the first parameter is an AVIO context [09:41:44 CEST] <grosso> maybe I can set the options to that avio_context... [09:43:51 CEST] <JEEB> see the comments in libavformat/avformat.h [09:44:00 CEST] <JEEB> @defgroup lavf_encoding Muxing [09:44:13 CEST] <JEEB> it also notes things about avio_open2 [09:45:23 CEST] <grosso> ok! let me see [09:45:46 CEST] <JEEB> https://svn.ffmpeg.org/doxygen/trunk/group__lavf__encoding.html [09:45:58 CEST] <JEEB> this is the generated documentation for it [09:46:58 CEST] <grosso> yes I see [09:47:51 CEST] <grosso> avio_open2 has a dictionary entry, and even an interrupt callback... look interesting [09:54:17 CEST] <grosso> I think avio_open2 is the solution... I wonder what can I do with that interrupt_callback [15:09:09 CEST] <th3_v0ice> Is it possible to reconfigure the x264 encoder on the fly? Do i need to close and reopen it again in order to set new parameters? [15:30:38 CEST] <BtbN> depends on the parameters [15:48:38 CEST] <DHE> th3_v0ice: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L180 [15:50:27 CEST] <JEEB> then it's down to libx264 at which point it actually reconfigures the encoder [15:50:38 CEST] <JEEB> I recommend reading it up on x264's side [15:51:33 CEST] <DHE> but the ffmpeg compatibility layer is as indicated. it won't reconfigure for other changes. so you can't, say, switch resolutions or colourspaces without reopening the encoder [15:51:44 CEST] <JEEB> yeh [15:52:19 CEST] <BtbN> The muxer would hate that anyway [15:52:48 CEST] Action: JEEB has seen that over in broadcasts anyways [15:53:00 CEST] <JEEB> sometimes with the same PID, otherwise with a PID switch [15:53:05 CEST] <DHE> yeah I've seen broadcast streams do all sorts of nasty things. [15:53:12 CEST] <JEEB> not really nasty tbqh [15:53:13 CEST] <DHE> AAC -> AC3 remains my least favourite [15:53:20 CEST] <JEEB> within the same PID? [15:53:39 CEST] <JEEB> I would be surprised if that was something almost anything supported [15:53:47 CEST] <JEEB> suddenly switching codecs in the same PID [15:53:49 CEST] <JEEB> with PID switches, sure [15:53:54 CEST] <JEEB> that can make *anything* happen [15:53:59 CEST] <DHE> I'd need to doublecheck. what I recall is that even though the PMT updated with a new version, even when I cut it past that point the decoder still went to crap. it wasn't a good, "clean" cut by any stretch. [15:54:01 CEST] <BtbN> mpegts is special in that you can do stuff like that, since the container doesn't really care [15:54:30 CEST] <BtbN> how well it works depends on the one trying to decode the mess you made [15:54:48 CEST] <JEEB> the problem is when you utilize the hack in the mpeg-ts demuxer that merges the PID switches when it thinks there was one [15:54:58 CEST] <DHE> `cut` using linux command dd, viewing with wireshark for verification, and then ffmpeg based (custom written) app to transcode [15:55:01 CEST] <JEEB> although I think that doesn't try to merge different codec IDs [15:55:21 CEST] <JEEB> same PID is just murder though :D [15:56:06 CEST] <DHE> yeah, my app will reset the avformatcontext without doing any UDP stop/start if the decoders go to crap for this exact situation. :/ [16:21:04 CEST] <exonintrendo> I have a small webserver running that the goal is to take a requested video, generate an m3u8 playlist file from it that the video player will use and as it requests the segment files, it will create them as requested. The general concept seems to work as the playlist is generated and the video plays, but the video starts skipping ahead and becomes off. Could someone maybe take a look and see if I'm missing [16:21:06 CEST] <exonintrendo> something obvious? [16:21:08 CEST] <exonintrendo> https://paste.w00t.cloud/view/697f3f0b [16:24:19 CEST] <DHE> you're generating the .ts files on demand using ffmpeg and the offsets? [16:24:38 CEST] <DHE> that's not safe/reliable. ffmpeg will always seek to a keyframe which may not be where you want it [16:25:13 CEST] <exonintrendo> ah, so should probably build the ts files based on those keyframes' [16:26:02 CEST] <DHE> ffmpeg has an hls muxer. I suggest using that. Either actually break it into lots of .ts files, or if you prefer you can have a single playable .ts file with -hls_flags single_file and metadata for seek offsets will be included in the .m3u8 allowing HTTP fetches with Range headers [16:26:25 CEST] <exonintrendo> oh really? [16:26:51 CEST] <exonintrendo> i just want to be able to generate / send them as requested to prevent having to pre-transcode all files ahead of time [16:27:00 CEST] <exonintrendo> i understand the 'load' time might be a bit longer, but that's fine [16:27:30 CEST] <DHE> well that's technically doable, but you'd basically have to read the .ts file and index it for keyframes, PAT/PMT, and make a .m3u8 intelligently using the Range-offsets method [16:28:35 CEST] <exonintrendo> right, i was hoping i could use ffprobe to get the keyframe offsets, generate an m3u8 playlist with TS file urls that have those offsets in their request, so the http request can take that information, generate a TS file based on that offset and duration (duration until the next keyframe) and send that data down [16:28:56 CEST] <kepstin> hmm, you're actually transcoding tho, so the keyframe locations in the original video don't matter [16:31:47 CEST] <exonintrendo> i just assumed that i could send down a TS file and transocde using those time offsets and duration, but doesn't seem to be giving me the desired effect [16:31:56 CEST] <kepstin> exonintrendo: to start, you should skip the live business and try just manually generating segment files on the HD, tweaking stuff until you get that right [16:32:00 CEST] <exonintrendo> err, m3u8 file, not ts file [16:32:27 CEST] <exonintrendo> if i manually run the ffmpeg command to generate 10 second clips individually, it seems to work [16:32:54 CEST] <kepstin> manually generate a few segments, then concatenate them (e.g. with cat) and make sure they play smoothly [16:33:05 CEST] <kepstin> if that doesn't work, the final result definitely won't work :) [16:33:12 CEST] <exonintrendo> right [16:33:25 CEST] <exonintrendo> so individually they're fine [16:33:27 CEST] <exonintrendo> let me concat them [16:34:41 CEST] <exonintrendo> ok, concatting them worked [16:34:58 CEST] <Jestin> Hey! Is it possible to create a scheduled livestream with FFmpeg thast plays a video at certain times/ [16:36:09 CEST] <exonintrendo> could some of the information in my m3u8 file be incorrect as far as telling the player what to do? [16:36:49 CEST] <kepstin> Jestin: sure, by writing an external application that either uses ffmpeg libraries or that runs an ffmpeg command at a certain time. [16:37:19 CEST] <kepstin> exonintrendo: dunno, hls streaming has always been kind of a weird black magic sort of thing. [16:37:56 CEST] <exonintrendo> i'm also not married to that, i think i could use mpegDash if necessary (if that matters [16:38:34 CEST] <kepstin> I stand by my original statement that the easiest way to do this is to buy a bigger hdd and pre-transcode everything :) [16:50:03 CEST] <cehoyos> DHE: Could you provide a broadcast sample with AAC -> AC3? I don't think we have that. [18:05:15 CEST] <Compusomnia> furq: For the sake of submitting a bug report, since you were able to reproduce my problem yesterday, are you a developer? [18:07:45 CEST] <DHE> cehoyos: it's not quite broadcast. it's IP over fiber. this particular source is a channel that shows sports games from various regions. when they switch from their filler feed to the actual event sometimes the audio codec changes. [18:08:15 CEST] <cehoyos> Can you dump the stream? [18:25:08 CEST] <DHE> cehoyos: I have a capture in .ts format, yes. raw off the network [18:25:20 CEST] <cehoyos> Please provide it [18:46:40 CEST] <DHE> cehoyos: the sample I have is 1.4 GB (about 8 megabit video, could be trimmed further but I wanted a good sample) and I'd rather not have it publicly readable. got a place to put it? [19:18:08 CEST] <DHE> what exactly does ffmpeg do on stream/PMT changes? the mpegts.c code doesn't make it very obvious [19:19:19 CEST] <exonintrendo> anyone here familiar with HLS and/or videojs? From what I can tell, what I'm doing should be working, but having some issues with playback [19:20:06 CEST] <DHE> I've produced a single-variant HLS video from a webcam with hls.js for the player [19:22:04 CEST] <JEEB> DHE: you grab the AVProgram that you are interested in (or all of them), and after tmm1's changes it will have a flag for updates + a version entry in the AVProgram [19:22:07 CEST] <exonintrendo> so i'm building an HLS playlist file and sending it to the player and as the player requests the chunks, I'm creating them on demand. Each chunk is 10 seconds long. Here's an example playlist file that I generated: https://paste.w00t.cloud/view/602f8884 [19:22:34 CEST] <JEEB> DHE: so in theory you have the means to update your API client's configuration when PMT changes if there are program changes (removing/adding AVStreams etc) [19:22:46 CEST] <exonintrendo> The issue is that the player seems to jump to start playing the next chunk after only about 5 seconds. But if I only include a single chunk in the playlist, it plays it properly and to completion [19:23:03 CEST] <exonintrendo> So i'm not sure if it's an issue with the format of my playlist file, or what. [19:24:44 CEST] <DHE> JEEB: while I'm running slightly old Git, I see the avfctx->programs[0]->pmt_version number change, but not necessarily an update in the stream information. eg: codec changed according to the PMT, but nothing happens in the streams[x]->codecpar data [19:25:01 CEST] <JEEB> DHE: yea I'm not sure if tmm1 had samples of that [19:25:20 CEST] <JEEB> DHE: so the sample has no PID switch? [19:25:22 CEST] <DHE> well I do, but it's from premium TV channels so I can't just share it [19:25:38 CEST] <JEEB> no streams appear/disapper but the same PID just gets switched? [19:25:58 CEST] <JEEB> in that case it can be funky because you'd have to somehow tell the demuxer to re-configure all that stuff [19:26:01 CEST] <DHE> let me double-check.... [19:31:42 CEST] <DHE> https://pastebin.com/raw/LJqtbDqn Yep, PID remains unchanged... [19:31:52 CEST] <JEEB> fun times [19:31:56 CEST] <DHE> yeah... [19:32:12 CEST] <DHE> and last I tried it, I get the PMT version change but not the updated codec info in CodecPar [19:32:43 CEST] <JEEB> yes, that's not unexpected. I don't think we re-init that stuff [19:32:47 CEST] <JEEB> (currently) [19:33:37 CEST] <DHE> yeah, but I need to know what's new and if at all possible I want to avoid resetting the avformatcontext because it'll affect decoding of the unchanged streams (in this case I lose video and need to wait for a new keyframe) [19:33:53 CEST] <DHE> I'm concerningly close to doing my own demuxing... :/ [19:34:12 CEST] <JEEB> I'm not sure how hard it would be to send the AVStream back to being sniffed [19:34:38 CEST] <JEEB> you'd somehow have to figure out from the descriptors that the codec has changed [19:35:33 CEST] <DHE> there's a whole "codec id" byte in the header. it changes. [19:35:34 CEST] <DHE> + Stream type: ATSC A/52 Audio (0x81) [19:35:46 CEST] <DHE> the information is there. I just need to get it [19:36:31 CEST] <JEEB> yes, pretty sure it checks that and the descriptors in the descriptor loop [19:36:46 CEST] <JEEB> and it works for new PIDs [19:37:04 CEST] <JEEB> so it could be something as simple as checking new descriptors for a stream and switching the codec id if needed [19:43:48 CEST] <greypack> im running ffmpeg 3.3 - is latest more performant for codecs like h265? [19:44:28 CEST] <JEEB> slightly, but in general HEVC is a bad example since nobody seems to be interested in optimizing the software decoder more :P [19:44:34 CEST] <JEEB> (and nobody's paying either it seems) [20:21:39 CEST] <DHE> yeah I'm just going to modify mpegts.c for now to force codec tracking.... [20:24:02 CEST] <kurosu> > nobody's paying either it seems [20:24:09 CEST] <kurosu> yeah... [20:24:17 CEST] <DHE> ..? [20:24:41 CEST] <kurosu> it is not in a particularly good state [20:47:32 CEST] <greypack> I have a dual processor e5-10 core, gets 5fps encoding bluray rips at 1080p... something about hevc just sucks the wind out of my datacenter [20:51:18 CEST] <BtbN> x265 at higher settings just is that slow [20:51:35 CEST] <BtbN> It also doesn't scale with more cores endlessly [20:52:04 CEST] <kurosu> s/x265/new codecs/ ? maybe svt-av1 scales better, dunno [20:52:35 CEST] <BtbN> Video Encoding in general doesn't scale like that [20:53:10 CEST] <DHE> number of cores only helps so much [20:54:25 CEST] <kepstin> we've all been spoiled by x264 [20:55:19 CEST] <DHE> in fairness it's a very mature codec [20:57:23 CEST] <BtbN> Even x264 doesn't profit from more than a handful of cores [20:59:12 CEST] <kepstin> i wonder if the intel svt codecs are doing something like encoding multiple gops in parallel, that would explain the memory usage. [20:59:40 CEST] <kepstin> although even x264 needs lots of ram :) [20:59:48 CEST] <DHE> assuming linux, numactl to pin the encoder on a single physical CPU and same memory controller might help a bit. do make sure you have quad channel memory going [20:59:49 CEST] <JEEB> I think they did do something like that [21:02:06 CEST] <kepstin> for my usage, i need lots of throughput of video encoding but latency isn't as important, so I just do a bunch of completely separate encodes, each with a smallish number of threads, in parallel. [21:08:51 CEST] <DHE> Little of column A, little of column B, so I have 10 VMs with 24 cores/threads each at my disposal for good quality but also not absurdly slow turnarounds. [21:33:34 CEST] <jafa> hevc technical - when there are multiple slice NALs in a row, how does code tell if they relate to the same frame (for example 4 NALs each carrying 1/4 of the image) vs different frames (each slice NAL is a new frame)? [21:35:09 CEST] <JEEB> I think multi-slice coding and the thing they added for HEVC for vertical+horizontal slicing are both noted in the spec [21:35:26 CEST] Action: JEEB doesn't know from the top of his head [21:47:44 CEST] <jafa> ah, there is a "first slice in pic" flag [00:00:00 CEST] --- Wed Jun 12 2019

1 0

ffmpeg-devel.log.20190610
by burek 11 Jun '19

11 Jun '19

[01:53:29 CEST] <cone-047> ffmpeg 03Peter Ross 07master:b12432721611: fate: add dst decoder test [15:12:10 CEST] <cone-931> ffmpeg 03Zhong Li 07master:ef56c28b2596: lavf/qsvvpp: add extra_hw_frames support [15:12:11 CEST] <cone-931> ffmpeg 03Zhong Li 07master:e62f625163f8: lavf/qsvvpp: add P010 output format support [17:22:17 CEST] <jamrial> jkqxz, BtbN, philipl: i just finished implemented the encode api equivalent of 061a0c14bb [17:22:48 CEST] <jamrial> and i need your help adapting the existing encoders using the decoupled api callbacks. nvenc, vaapi, amf, etc [17:24:51 CEST] <BtbN> Should be straight forward for nvenc at least. No idea about the others. [17:25:30 CEST] <BtbN> Though it's probably going to end up with the awkward constructs it claims to avoid, since nvenc actually works pretty well with the current design. [18:23:29 CEST] <jamrial> jkqxz, BtbN, philipl: https://github.com/jamrial/FFmpeg/commits/encode_api if you want to take a look [18:24:45 CEST] <jamrial> BtbN: i implemented it for the librav1e patch on the ml, and it wasn't awkward, so dunno [18:25:25 CEST] <philipl> looking [18:34:23 CEST] <jamrial> the main benefit with this change is that we can remove the fallback encode2 callback implementations in all these encoders, since now those using only the receive_packet callback will also work for people still using avcodec_encode_video2() [18:38:31 CEST] <Lynne> I don't get it [18:39:50 CEST] <Lynne> its just encode2() but you need to call a function to get a frame/packet [18:41:39 CEST] <Lynne> the new api was meant to simplify async-like encoders and decoders, this just makes it more like the old api [18:43:12 CEST] <nevcairiel> its capabilities are still quite the same, an encoder can consume any number of frames through the request api, and produce as many as it likes [18:44:45 CEST] <nevcairiel> the really big difference is in the external API [18:44:56 CEST] <nevcairiel> could've done the same with encode2 by just re-definining it slightly [18:47:30 CEST] <nevcairiel> but I don't see how people calling avcodec_encode_video2 could use encoders that use the new API, at least if an encoder actually produces more packets then input frames, say for example interlaced encoding with one packet er field [18:48:18 CEST] <philipl> Presumably it should fail? On the decode side, a decoder that only supports the new API will fail to work with the old decode API [18:48:56 CEST] <Lynne> if this was done for backwards compatibility, why? the old api will be removed eventually, this is just a stopgap for a year or two [18:49:31 CEST] <nevcairiel> for decoders people considered this easier to work with in the decoder themselves [18:49:39 CEST] <nevcairiel> so presumably the same would be true for encoders [18:49:57 CEST] <nevcairiel> it gets to decide to request a new frame itself, instead of relying on the external callback to be called [18:50:03 CEST] <nevcairiel> its just a bit more explicit [18:52:03 CEST] <nevcairiel> one entry point to drive the logic, instead of two that somehow interact [18:53:09 CEST] <jamrial> Lynne: the decode and encode2 callbacks are left alone to prevent having to rewrite a hundred or so decoders/encoders [18:53:50 CEST] <jamrial> the old encode public functions can be removed after the above commits, as the internal callbacks are not related to them anymore [18:54:20 CEST] <jamrial> the old decode functions could be removed right now for the same reason, but i don't see that happening anytime soon [18:54:41 CEST] <jamrial> i don't know how many library users already ported their code to send/receive [18:59:58 CEST] <Lynne> well they can't be removed until the bump, but I don't see how the commit helps [19:20:24 CEST] <jamrial> Lynne: if you look at the current code you'll notice that the avcodec_send_frame() and avcodec_receive_packet() functions are calling avcodec_encode_video2() and avcodec_encode_audio2() for encoders using the encode2 callback [19:20:44 CEST] <jamrial> the above patches makes them instead call the callback directly [19:24:53 CEST] <jamrial> actually, even after those patches the old functions couldn't be removed, because the frame threading code for some reason uses them... [19:47:49 CEST] <Lynne> ah, I see [19:56:36 CEST] <maxine> hi, i was just wondering, if i wanted to contribute a patch that fixes mkv encoding of webvtt subs (https://trac.ffmpeg.org/ticket/5641) would it be better to preserve its ability to recognise the webm style stuff or simply drop it in favour of what the matroska spec says? [21:36:11 CEST] <cone-207> ffmpeg 03Stephan Hilb 07master:1954161628ab: avformat/nut: add cpia codec [22:57:48 CEST] <jdarnley> maxine: usually ffmpeg strives to maintain reading of "invalid" files [22:59:34 CEST] <maxine> so the old behaviour should be preserved, ok. thanks! [23:12:06 CEST] <cone-207> ffmpeg 03Paul B Mahol 07master:80e68ce11686: avfilter/vf_normalize: fix filtering of RGB0 formats [23:23:10 CEST] <j45> maxine, jdarnley: the ticket references encoding and decoding, but maxine's question appears to be about *encoding*. seems if the question as stated is what was intended, then the question is do you want ffmpeg to preserve *writing* invalid files? [23:23:57 CEST] <jdarnley> Probably not by default. [23:24:01 CEST] <maxine> j45: actually, i did mean decoding of webm style encoded matroska files. [23:24:08 CEST] <maxine> sorry for not being clear [23:24:11 CEST] <jdarnley> There us the "strict" option for that [00:00:00 CEST] --- Tue Jun 11 2019

1 0

ffmpeg.log.20190610
by burek 11 Jun '19

11 Jun '19

[02:36:16 CEST] <nicolas17> can ffmpeg read a playlist that is just a list of filenames? or should I turn it into a proper concat script? [02:43:36 CEST] <relaxed> nicolas17: https://webcache.googleusercontent.com/search?q=cache:KnDHyY6VAY4J:https://… [07:42:37 CEST] <PhantomOfNyx> Is there a way to prevent the bitrate spiking at all I've set both an vbv-bufsize vbv-maxrate and a rateol=1.0 and it still spikes happily to 12k bitrate under high activity [07:42:49 CEST] <PhantomOfNyx> with me trying to limit it to 7k [08:00:51 CEST] <PhantomOfNyx> Is there a way to prevent the bitrate spiking at all I've set both an vbv-bufsize vbv-maxrate and a rateol=1.0 and it still spikes happily to 12k bitrate under high activity I'm trying to limit the max cap to 7k under spikes but not having much luck [18:07:01 CEST] <cousin_luigi> Greetings. [18:07:45 CEST] <cousin_luigi> I have a 6 channel AC3 track and I would like to downmix it to 2 channels, but keep the AC3 format. How would you recommend I do that? [18:08:58 CEST] <kepstin> cousin_luigi: use "-ac 2 -c:a ac3 -b:a 192K" in your output options (adjust bitrate to taste) [18:09:27 CEST] <cousin_luigi> kepstin: I would like to keep it as the original, do I have to specify it? [18:09:50 CEST] <kepstin> "keep as original" makes no sense when you're re-encoding and changing the number of channels [18:10:33 CEST] <kepstin> like, most 5.1 ac3 content on dvds is something like 384kbit/s iirc? with fewer channels you don't need nearly that much. [18:11:21 CEST] <kepstin> if you don't specify it, it'll use some default value, it won't attempt to keep anything from the source file. [18:13:21 CEST] <cousin_luigi> kepstin: Right, thanks. [18:21:28 CEST] <cousin_luigi> kepstin: It worked! [18:21:29 CEST] <cousin_luigi> bbl [19:22:43 CEST] <electrotoscope> I'm trying to add more information to the documentation for the "metadata" function in drawtext at https://ffmpeg.org/ffmpeg-filters.html#toc-Text-expansion [19:22:48 CEST] <electrotoscope> I was confused, thinking all of the information that ffmpeg -show_frames can access would be available as "metadata", and from googling the problem for a few days and reading a bunch of blog posts and stack overflow threads I know I'm not the only one. [19:22:52 CEST] <electrotoscope> Eventually I found out that "metadata" in this context means the lines shown in ffprobe [FRAME] data with "TAG:" in front of it. [19:22:56 CEST] <electrotoscope> I wanted to write: The metadata accessible to this function must show up using @code{ffprobe -show_packets} formatted as TAG:[metadata_key]=[metadata_value]. [19:23:00 CEST] <electrotoscope> But someone commenting on https://trac.ffmpeg.org/ticket/7947 obviously didn't understand what I meant so it needs improvement [19:23:12 CEST] <electrotoscope> What if I wrote something like: If what you're trying to read from a file doesn't show up with @code{ffprobe -show_frames} formatted as TAG:[metadata_key]=[metadata_value] then it won't be visible to this option. [19:23:39 CEST] <electrotoscope> (i switched show_packets to show_frames since I think that's actually closer to the truth) [19:30:29 CEST] <durandal_1707> electrotoscope: stuff you want to be TAG is simply not metadata [19:32:26 CEST] <kepstin> electrotoscope: when you write it like that it sounds like you have causality backwards. It's just that in the default ffprobe output format, that's how it formats metadata. [19:32:49 CEST] <electrotoscope> hmm [19:33:28 CEST] <electrotoscope> Most frame data is not visible to this option. "metadata" in the context of this option refers to data that is visible to ffprobe etc etc [19:33:31 CEST] <electrotoscope> is that better? [19:33:48 CEST] <kepstin> no, because lots of the stuff visible in ffprobe is not metadata [19:34:26 CEST] <electrotoscope> apologies [19:34:27 CEST] <electrotoscope> Most frame data is not visible to this option. "metadata" in the context of this option refers to data that is visible to @code{ffprobe -show_frames} formatted as TAG:[metadata_key]=[metadata_value] [19:34:29 CEST] <kepstin> the use of the word 'metadata' is pretty consistent in ffmpeg, refering to extra data, often user-provided, that's stored in the container alongside the actual stream [19:35:05 CEST] <electrotoscope> yes but unfortunately it's not well documented, which is what I'm trying to improve. metadata outside of ffmpeg refers to data about data [19:35:10 CEST] <durandal_1707> he is talking about frame metadata, and not sream metadata [19:35:25 CEST] <durandal_1707> *stream [19:35:37 CEST] <electrotoscope> @durandal_1707: to the best of my knowledge, stream metadata is not visible to drawtext [19:35:48 CEST] <electrotoscope> or accessible to drawtext or exposed to drawtext or whatever the appropriate term is [19:36:05 CEST] <durandal_1707> correct [19:36:39 CEST] <Compusomnia> Why does the normalize video filter crop my video from 16:9 to 4:3, and how can I make it not do that? [19:37:47 CEST] <furq> Compusomnia: paste the full command and output [19:38:29 CEST] <electrotoscope> kepstin: Should I maybe write it as "The use of the term metadata in ffmpeg refers to extra data, often user-provided or generated live during decode by other filters, that's stored in the container alongside the actual stream"? [19:38:30 CEST] <Compusomnia> To where? The pastebin link doesn't work for me. [19:38:43 CEST] <kepstin> Compusomnia: use a different pastebin then [19:39:42 CEST] <kepstin> we don't care where you paste it, as long as it's not in the chat. [19:43:58 CEST] <Compusomnia> https://pastebin.com/3T2WbfAG [19:44:55 CEST] <kepstin> hmm. is frame metadata used for /anything/ other than passing info between filters in libavfilter? [19:46:09 CEST] <furq> some filters will log it [19:46:17 CEST] <furq> idet for one [19:46:25 CEST] <electrotoscope> you can write it out of a filter into a txt file [19:46:40 CEST] <electrotoscope> or you can insert it into a concat list with file_packet_metadata key=value [19:47:43 CEST] <furq> Compusomnia: the output is the same resolution and apparently the same sar/dar as the input [19:47:50 CEST] <electrotoscope> and theoretically some camera somewhere might record it into the frame information and it would look like https://stackoverflow.com/a/34345153/1747979 [19:47:50 CEST] <furq> how does it appear to be cropped [19:48:27 CEST] <electrotoscope> kepstin: perhaps I should just write "if you think you can read something from the file with this you're probably wrong" [19:49:19 CEST] <Compusomnia> Yes, the actual video size stays untouched, but only the left 4:3 part of the video has any data. The right part is black. [19:50:30 CEST] <electrotoscope> Compusomnia: perhaps reading the input file and output file in MediaInfo would shed some light on it? [19:51:24 CEST] <furq> i don't think that would give you any information that the above paste wouldn't [19:51:34 CEST] <furq> that sounds broken to me but then i've never used normalize [19:53:24 CEST] <kepstin> hmm. i wonder if the filter has a bug in its handling of rgb24 vs. rgb0 and similar formats [19:53:32 CEST] <kepstin> that would account for working on only 3/4 of the frame [19:54:18 CEST] <kepstin> Compusomnia: can you re-run that with -v verbose -vframes 1 so I can see the fitler chain setup (including inserted scale filters)? [19:57:58 CEST] <kepstin> it looks like the normalize filter is stepping horizontally by num_components bytes per pixel, but stuff like rgb0 has 3 components in 4 bytes, so it's using the wrong step value. [19:58:28 CEST] <furq> that'd do it [19:58:37 CEST] <Compusomnia> verbose output: https://pastebin.com/WWH6xHUf [19:58:52 CEST] <kepstin> yep, bgr0 [19:58:54 CEST] <furq> Compusomnia: if you just want to work around it then -vf format=rgb24,normalize,format=yuv420p should work [20:00:22 CEST] <kepstin> filter shouldn't be hard to fix, it just has to save the step value out of the AVComponentDescriptor and use that when incrementing over pixels. [20:02:50 CEST] <Compusomnia> Your filter chain did in fact fix it, furq [20:05:28 CEST] <Compusomnia> I guess this means I should submit a bug report? [20:09:10 CEST] <kepstin> weird tho, i can't seem to reproduce this issue on ffmpeg 4.1 [20:10:21 CEST] Action: kepstin waits for his git ffmpeg to rebuild [20:11:19 CEST] <furq> https://github.com/FFmpeg/FFmpeg/commit/ac551c54b13834f1ddf2b0f2196d6c8d817… [20:11:22 CEST] <furq> that's the only commit since 2017 [20:11:30 CEST] <furq> that doesn't really seem like the culprit [20:11:51 CEST] <kepstin> i wonder if something changed in ffmpeg's representation of pixel formats recently [20:13:49 CEST] <eschie> I'm trying to create HLS files but having issues where the audio drops out after seeking. Apple's 'mediastreamvalidator' errors saying "Different target durations detected" for the audio and video streams. How to fix? [20:16:36 CEST] <kepstin> like, i'd expect `ffmpeg -v verbose -f lavfi -i testsrc -vf format=bgr0,normalize -vframes 10 out.mkv` to show this issue, but it doesn't? v. strange. [20:17:52 CEST] <Compusomnia> The pixel format straight out of my webcam is bgr24, if that makes any difference. [20:19:03 CEST] <furq> ffv1 is always bgr0 internally iirc [20:19:46 CEST] <furq> for rgb, i mean [20:21:24 CEST] <furq> kepstin: i can reproduce it here on 4.1.3 by going via ffv1 [20:21:49 CEST] <kepstin> must be some quirk relating to buffer re-use then, i guess [20:22:57 CEST] <furq> https://i.imgur.com/riBOM8j.png [20:23:08 CEST] <furq> $ ffmpeg -f lavfi -i testsrc=d=1 -c:v ffv1 -f nut - | ffmpeg -y -i - -vf normalize -frames:v 1 out.png [20:25:05 CEST] <kepstin> my guess is that you only see the black in the case where the frames given to the normalize filter are not writable, and so have to be copied. [20:25:22 CEST] <kepstin> if the frames are writable you'll see the whole image, but only the left 3/4 will actually have been processed [20:44:09 CEST] <exonintrendo> Ok, not sure if this is a realistic goal, but I want to build a basic video player that will let me view videos in my family's home video gallery. The videos are various formats from .mp4 and .mov depending on the device recording them. I want to be able to have ffmpeg transcode / create HLS files on demand when someone clicks on the video to view rather than creating the HLS files ahead of time to save space [20:44:11 CEST] <exonintrendo> But I also want the user to be able to load up the video and have it start playing if they say scrub half way through (start transcoding / creating the HLS files from a given point in the video). Is this reasonably possible? [20:45:47 CEST] <furq> exonintrendo: why use hls at all instead of just serving the mp4s [20:53:18 CEST] <kepstin> well, you still need to do something about any video files that browsers can't play directly. [20:53:34 CEST] <exonintrendo> furq i was just thinking of a good way to transcode for bandwidth purposes as i want playback to be fluid regardless if you're on LAN or not [20:53:37 CEST] <kepstin> exonintrendo: honestly, i'd just go with "disk space is cheap, just pre-transcode everything" [22:01:37 CEST] <lavaflow> I have two video files and I want to copy the audio tracks from the second into the first, keeping all audio and video tracks the first has [22:02:01 CEST] <lavaflow> I'm trying: ffmpeg -i one.mp4 -i two.mp4 -map 0 -map 1:1 -c copy out.mp4 [22:02:49 CEST] <lavaflow> but that says: Argument two.mp4 provided as input filename, but one.mp4 was already specified [22:03:07 CEST] <lavaflow> pretty sure I'm using -map wrong, can anybody help me out here? [22:04:39 CEST] <lavaflow> ah crap I'm an idiot, nevermind [22:04:49 CEST] <kepstin> lavaflow:i'm not sure what's up, that command shouldn't make that message. please pastebin the command and complete terminal output as you ran it. [22:05:14 CEST] <lavaflow> kepstin: I was accidentally invoking ffprobe not ffmpeg, because I'm dumb [22:05:22 CEST] <lavaflow> it's working now [22:07:21 CEST] <kepstin> note that if you don't want to bother looking up exact stream indexes, "-map 1:a:0" would select the first audio track from the second input. [22:10:16 CEST] <lavaflow> ah nice, thank you [23:55:30 CEST] <brimestone> Anyone know where I can download an FFmpeg build for macOS 10.8.5 [23:56:18 CEST] <MoziM> kepstin: thanks! didn't know that, sorry for late response [23:57:21 CEST] <MoziM> kepstin: i've already made the video and now i'm wondering if there's a way for ffmpeg to add an audio delay of 1400 ms to compensate... or am i better off just running the ffmpeg command to merge audio and video again using the native fps of 23.97? [23:57:42 CEST] <kepstin> MoziM: i don't remember the context for this [23:58:02 CEST] <MoziM> sorry one moment [00:00:00 CEST] --- Tue Jun 11 2019

1 0

ffmpeg-devel.log.20190609
by burek 10 Jun '19

10 Jun '19

[02:35:23 CEST] <pross> uartie: github/gitlab/gitee/etc bug trackers have limitations too. but i am glad no-one said jira -- that seems to be as infectious today as microsoft office once [02:35:26 CEST] <pross> .was [14:08:21 CEST] <cone-072> ffmpeg 03Paul B Mahol 07master:a9bf65657752: avfilter/vf_lut2: add slice threading [14:37:57 CEST] <mkver> jkqxz: In 4d56f7ab8f627aa140c1ede1bb61305f01cefcdd you made BSF see EOF so that they can flush any delayed packets. Does this really work? Because it seems that EOF does not even reach process_input_packet. Maybe it did work for avconv and not ffmpeg? [14:40:01 CEST] <rcombs> huh, Network.framework TLS is built on top of BoringSSL [19:02:02 CEST] <kierank> mkver: you could theoretically have every byte of H.264 in a separate PES [19:02:50 CEST] <mkver> Yes, that seems to be spec-compliant. I would have expected the specs to bann such nonsense. [19:04:37 CEST] <kierank> mkver: the intention I believe is to allow muxers to make sure bytes are not wasted [19:04:55 CEST] <kierank> so you can start the next AU immediately after the last one ends [19:05:11 CEST] <kierank> at low bitrates 1-180bytes wasted per AU is a lot [19:06:01 CEST] <mkver> Ok, that makes sense. [19:08:17 CEST] <mkver> If a new H.264 access unit doesn't immediately start at the beginning of the payload of a TS packet, then payload unit start indicator mustn't be set for said packet, I presume? [19:08:54 CEST] <mkver> And then the container doesn't contain information to know where frames begin and end at all, so one needs to rely on the parser. [19:10:51 CEST] <kierank> yes [19:11:17 CEST] <kierank> high performance muxers do all sorts of things to reduce bitrate [19:11:25 CEST] <kierank> a whole gop in the same pes is common [19:12:30 CEST] <mkver> What about timestamps in such cases? How are they signalled? [19:21:21 CEST] <kierank> just one at the beginning [19:21:29 CEST] <kierank> it's cfr [19:23:05 CEST] <mkver> And in case of frame reordering the parser/decoder needs to figure out the pts? [00:00:00 CEST] --- Mon Jun 10 2019

1 0

ffmpeg.log.20190609
by burek 10 Jun '19

10 Jun '19

[00:26:53 CEST] <grosso> anyone knows a lot about rtmp and mediaservers? [02:09:11 CEST] <Atlenohen> Hi [02:09:25 CEST] <Atlenohen> is it possible to concat mulitple files by using wildcard? [02:09:30 CEST] <Atlenohen> like *.ts [02:09:37 CEST] <Atlenohen> extension specific in this case [02:21:01 CEST] <another> if it is indeed mpeg-ts, i guess you could just cat them on your shell [02:28:52 CEST] <Atlenohen> 250 of them, can't name them all manually [02:29:16 CEST] <Atlenohen> not sure if "for each .ts do ffmpeg .." will work, it's not an operation on each of the files separately [02:32:26 CEST] <klaxa> as another said, if it really is mpeg-ts all the same format you can just do cat *.ts > all.ts [02:32:40 CEST] <klaxa> that will mess up some timestamps maybe but you can remux that with ffmpeg then [02:37:49 CEST] <DHE> or maybe generate a concat demuxer input file with a shell command or something? [02:38:40 CEST] <Atlenohen> I'll figure out tomorrow, not sure, yeah timestamps, m3u8 has some stuff yes [02:39:10 CEST] <Atlenohen> at least that's what I think those numbers between chunks are ... rats [02:39:47 CEST] <Atlenohen> but I'm on windows [02:39:53 CEST] <Atlenohen> not sure if I can do cat [02:55:48 CEST] <another> hls? [03:10:34 CEST] <DHE> if it's hls, ffmpeg can read the .m3u8 file. or the concat method is basically guaranteed to work. [15:53:10 CEST] <void09> help. i want to do a 10bit encode [15:53:15 CEST] <void09> of an 8bit video source [15:53:45 CEST] <void09> nobody wants to tell me how :P do i need to set this in the encoder ? or just the pixel format for the ffmpeg stream ? [16:40:48 CEST] <c_14> void09: just set the output pixel format to a 10bit format (if the encoder supports 10bit encoding) [17:04:03 CEST] <void09> c_14 so I don't need to actually tell teh encoder to encode to 10bit ? [17:04:12 CEST] <void09> or does it that automatically if the source is 10bit? [17:19:30 CEST] <void09> ok i got it.. it neede both the input stream to be converted, and the encoder to be set at bit depth 10 [17:42:57 CEST] <kepstin> void09: you need convert the pixel format of the video to 10bit (this is done for you if you set the -pix_fmt output option) and you need to select an encoder that supports 10bit. There's no encoder settings needed. [17:46:56 CEST] <void09> kepstin: i tried it with svt-av1, piping from ffmpeg (not encoding with ffmpeg itself) [17:47:18 CEST] <void09> and if i didn't specify -bit-depth 10 as an encoder param, i'd get a greenish messy video [17:47:40 CEST] <void09> so maybe ffmpeg encoders detect 10 bit source and encode accordingly [17:47:43 CEST] <kepstin> oh, well, yeah - what i said only applies when you're using an encoder within ffmpeg. if you're doing something unusual, you need to say that up front [17:48:00 CEST] <void09> ok now it all makes sense. thanks [22:43:55 CEST] <A4L> Hey! I can use -filter_complex acrossfade=d=10:c1=tri:c2=tri to crossfade audio from one input to other and join them in output. But how do I apply one filter if I am inputing 1000s of files and I want to use that same filter over all of them? I input 1000 files using concat and then I want to crossfade all of them with the same filter effect. How do I achieve this? Ty [22:54:02 CEST] <relaxed> A4L: you could create a script to construct the ffmpeg command [22:55:51 CEST] <A4L> Is this the only option? The filter list would be veryyy long... [22:57:03 CEST] <relaxed> what difference does that make? have the script write to a file and then execute it [22:57:38 CEST] <A4L> ok, i had a thought that it would be more CPU hungry, but nevermind... [23:06:17 CEST] <relaxed> maybe for loop through the files and pipe/appeand to one output file? [23:09:25 CEST] <A4L> this would reencode one file 1000 times since it is mp3 [23:09:59 CEST] <relaxed> ah, you're right [23:13:31 CEST] <relaxed> wait, if you're filtering you're transoding [23:29:43 CEST] <A4L> by the way, how do I apply a filter for example 3 input files? [23:29:52 CEST] <A4L> acrossfade in my case? [23:47:02 CEST] <durandal_1707> A4L: use -filter_complex_script, as you will need 1000-1 acrossfades [23:55:29 CEST] <A4L> thanks! [00:00:00 CEST] --- Mon Jun 10 2019

1 0

ffmpeg-devel.log.20190608
by burek 09 Jun '19

09 Jun '19

[00:01:31 CEST] <BtbN> no [00:02:17 CEST] <uartie> :( [00:51:58 CEST] <jdarnley> I know there are tests for the hash functions in avutil but where is the reference/comparison files? [00:54:46 CEST] <nevcairiel> depending on how its tested, may not even have one [00:56:07 CEST] <nevcairiel> many internal base components like that have test code written in C [00:56:30 CEST] <jdarnley> ah, it might be tests/ref/fate/hash [00:57:54 CEST] <jamrial> that's the ref file for the AVHashContext framework, but each specific hash module has its own test and ref file in that same folder [01:00:10 CEST] <jdarnley> I see the md5 file now, I think [02:45:03 CEST] <cone-225> ffmpeg 03Peter Ross 07master:b6ca032adebe: avcodec/vp3data: combine eob_run_base and eob_run_get_bits tables [02:48:59 CEST] <J_Darnley> Does fate strip trailing spaces in stdout somewhere? [02:55:26 CEST] <J_Darnley> sort of [02:55:47 CEST] <J_Darnley> it uses diff -b which is "ignore changes in the amount of white space" [02:56:45 CEST] <pross> uartie: what are other good tools? [07:37:13 CEST] <uartie> pross: github and gitlab come to mind [07:38:09 CEST] <uartie> ...and are all-in-one solutions [08:00:01 CEST] <uartie> pross: afaict, ffmpeg project uses several unrelated tools/methods to handle website, wikis, git, bug tracking, ci, patch submission/review, etc. I assume someone in the community has to maintain the servers/hardware to host these services, too. And trying to integrate any of these together must be a nightmare to deal with! Something like GitLab/Hub would handle all of this stuff. [08:57:04 CEST] <grosso> hi [15:34:24 CEST] <BtbN> Just suggesting gitlab will be shot down, because a lot of contributors really like their mailing list. [15:34:40 CEST] <BtbN> Anything that needs a Browser pretty much stands no chance. [15:54:54 CEST] <rcombs> so, as of macOS 10.15, Secure Transport is deprecated [15:55:08 CEST] <nevcairiel> let me guess, the replacement isnt available yet :D [15:55:17 CEST] <rcombs> it's still present, and I'd expect it to remain present for the foreseeable future for compatibility, but it doesn't (and won't) support TLS 1.3 [15:55:26 CEST] <rcombs> the replacement is Network.framework [15:55:37 CEST] <rcombs> which is a replacement for the entire BSD Sockets API [15:55:40 CEST] <nevcairiel> as a developer, i really fiercely hate Apples philosophy for development [15:55:50 CEST] <nevcairiel> they change everythign every couple versions [15:56:00 CEST] <rcombs> it bundles TLS and TCP into a single API, and it's very async [15:56:10 CEST] <BtbN> So they are kicking out sockets and OpenGL? Fun. [15:56:14 CEST] <BtbN> Time to drop support. [15:56:15 CEST] <rcombs> it's been available since 10.14 [15:56:28 CEST] <rcombs> BSD sockets are still supported [15:56:34 CEST] <rcombs> (and not deprecated) [15:56:43 CEST] <rcombs> but there's no way to use, say, MPTCP with them [15:56:55 CEST] <nevcairiel> I would say that if they ever truely kill OpenGL, they would be in a world of pain, but then the Apple fanboi crowd will still praise them :p [15:56:58 CEST] <rcombs> (the Linux folks are working on solutions for that but they're mostly server-oriented) [15:57:22 CEST] <rcombs> nevcairiel: it'd be pretty dumb given that they have to ship a GL-on-Metal implementation regardless (for WebGL) [15:57:29 CEST] <BtbN> They already did truely kill OpenGL. They are not maintaining the drivers anymore, and a wide range of applications stops working with each update. [15:57:53 CEST] <BtbN> Dolphin-Emulator for example already dropped support due to that. [15:58:12 CEST] <rcombs> so, philosophical arguments aside: I'd expect I'll implement Network.framework TLS in lavf [15:58:20 CEST] <rcombs> how do we want to handle that? [15:58:32 CEST] <nevcairiel> good luck with that, I figure i'll just swap to GnuTLS on there [15:58:56 CEST] <rcombs> I'll set it up for weak-linking so it doesn't create a runtime dependency on 10.14 [15:59:29 CEST] <rcombs> I'm not sure if it'll fit in with the other tls.c infrastructure, since it won't be layered on top of lavf TCP [16:00:07 CEST] <rcombs> the biggest thing I'm wondering about is how to handle protocol selection [16:00:11 CEST] <nevcairiel> that'll practically make it impossible to use it in lavf, tbh [16:00:28 CEST] <nevcairiel> unless you want to change every single thing that uses it [16:00:34 CEST] <rcombs> how so? [16:01:08 CEST] <rcombs> don't most users basically open tls://[host]:[port], and it's an implementation detail that it's layered on top of lavf's tcp protocol? [16:04:57 CEST] <rcombs> BtbN: dunno where you heard that Dolphin was dropping support for macOS but it doesn't seem to be the case [16:05:08 CEST] <rcombs> apparently they're in the process of moving to MoltenVK there [16:05:42 CEST] <rcombs> my biggest question is around how tls_nwf (final name TBD?) and tls_securetransport will coexist [16:06:09 CEST] <nevcairiel> you can't build ffmpeg with two tls protocols currently [16:06:10 CEST] <rcombs> or should tls_securetransport just internally use Network.framework when available and otherwise fallback on ST? [16:06:23 CEST] <rcombs> yeah, so I need some sort of a solution to that [16:06:44 CEST] <BtbN> They implemented MoltenVK as alternative, but as it stands right now, it has even more issues than OpenGL [16:06:52 CEST] <BtbN> so effectively, Dolphin is unuseable on current OSX [16:07:31 CEST] <rcombs> maybe that means tls_securetransport gets renamed to tls_apple and implements both ST and Network.framework? [16:08:03 CEST] <rcombs> or maybe it means we add some sort of abstraction that allows multiple TLS implementations (which would be useful for testing anyway) [16:09:54 CEST] <nevcairiel> I would rather see that limited to the mac stuff [16:11:34 CEST] <ritsuka> BtbN: dolphin with moltenvk worked quite well with a few game I tried (Twilight Princess for example) [16:11:44 CEST] <rcombs> sounds like my best route is probably to rename tls_securetransport to tls_apple and have 2 implementations in 2 file with runtime version checks and #ifdefs around the new version [16:12:06 CEST] <BtbN> TP is pretty basic in terms of graphics pipeline usage [16:13:19 CEST] <rcombs> ¯\_(Ä)_/¯ I've run games on Dolphin under macOS years ago and didn't have significant problems [16:13:29 CEST] <rcombs> it's not gotten _worse_ since then [16:16:17 CEST] <BtbN> It is though, since dolphin is making use of a lot more OpenGL features now, which OSX never even implemented, or does implement, but incorrectly [17:48:37 CEST] <rcombs> also I'm gonna go ahead and get rid of the private-API crap in tls_securetransport that people have complained about wrt app store rejections [17:49:04 CEST] <rcombs> the private API it uses is to create a SecIdentity from a SecKey and an array of SecCertificates loaded from PEM data [17:49:40 CEST] <rcombs> there's no public way to do that, _but_ there's a public way to create a SecIdentity from a PKCS#12 blob [17:49:51 CEST] <rcombs> and also a public way to convert an array of keys and certificates to a PKCS#12 blob [17:51:55 CEST] <rcombs> this is dumb as shit but sure whatever [17:56:04 CEST] <JEEB> yea [17:56:17 CEST] <JEEB> makes sense to not do private apus [17:56:20 CEST] <JEEB> *apus [17:56:23 CEST] <JEEB> ffuu [18:47:07 CEST] <mkver> Does anybody know whether it would be legal to put an H.264 picture into multiple PES packets when muxing it into a transport stream? (I.e. can a H.264 access unit cross the boundaries of PES packets?) [18:48:23 CEST] <j45> yes [18:50:35 CEST] <mkver> That's bad. If it were otherwise, this could be exploited to remove some (then unnecessary) memcpys when parsing H.264 in transport streams/program streams.. [18:51:50 CEST] <j45> to expand a bit, video in pes is always escaped so that start codes are not spoofed. so when read and un-escaped, the access unit boundaries can be found by looking for the start codes [18:53:03 CEST] <nevcairiel> Whats the "boundary" of a PES packet anyway? Some streams forget PUSI and you have to entirely rely on the parser to put it back together properly [18:55:19 CEST] <nevcairiel> if that was reliable, we wouldnt need annexb in the first place :D [19:05:42 CEST] <mkver> I hoped that the packetization contained a rule like "A PES packet either consists of a complete H.264 access unit or of two complete H.264 access units provided that these two access units contain coded fields that together constitute a complememtary field pair." [19:07:33 CEST] <j45> nope. dvd is a good counter example, although it's mpeg2, same rules apply. pes packets in dvd are limited to 2KB [19:08:34 CEST] <mkver> By "boundary" of a PES packet I meant the positions in the extracted elementary stream that correspond to the first byte extracted from a PES packet. [19:09:03 CEST] <mkver> Ok, then it seems that there is no simple way to avoid some memcpys. [19:10:50 CEST] <mkver> (Even if a PES packet contains a complete H.264 access unit, it is copied into the parser's buffer, because that it is a complete access unit will only be apparent when the next access unit is received. And upon returning it will be copied once more because parsers don't make use of refcounted buffers.) [00:00:00 CEST] --- Sun Jun 9 2019

1 0

ffmpeg.log.20190608
by burek 09 Jun '19

09 Jun '19

[00:11:00 CEST] <void09> kepstin: I'm thinking another strategy might work.. if blurays have keyframes at 1-2 seconds as you say, then when a scene change is detected, if that frame is not a keyframe (very likely, 1/24 or 1/48 chance for it to be a keyframe), then loslessly compress that part until the next keyframe arrives, and then cut at the keyframe, until the next scene change, and aagain, append the last part until a scene [00:11:03 CEST] <void09> change losslessly comprssed, if not a keyframe. [00:11:56 CEST] <void09> but this not perfect for scenarios where the scene changes just for a split second and the encoder does not do a new keyframe. this might happen i guess, i don't know much about those algorithms [02:13:05 CEST] <noahmg123> I'm trying to pull a security camera stream off of a URL. I can get the video just fine (in H264 format), however, I'm having trouble pulling down the audio stream with it. [02:17:04 CEST] <dongs> oh hey [02:17:15 CEST] <dongs> aac channelConfiguration() of 13 is actaully valid [02:17:23 CEST] <dongs> so maybe my 22ch audio isnt borked as much as I thought [02:17:48 CEST] <dongs> 13: 22.2ch (3/3/3-5/2/3-3/0/0+2) [02:22:39 CEST] <dongs> is trac.ffmpeg dead [02:50:48 CEST] <electrotoscope> it's been struggling the last few days, but if you keep refreshing it should work [02:58:22 CEST] <another> void09: https://github.com/Breakthrough/PySceneDetect might be something to look into [02:58:57 CEST] <another> also, iirc the segment muxer always splits on keyframes [02:59:06 CEST] <another> see documentation [13:50:28 CEST] <zzlatev> hey guys, can you help me with something [13:50:35 CEST] <zzlatev> 2019-06-08 14:41:15.655 spawn: Executing "/usr/bin/ffmpeg [13:50:44 CEST] <zzlatev> 2019-06-08 14:41:15.686 spawn: Error splitting the argument list: Option not found [13:50:50 CEST] <zzlatev> https://pastebin.com/MXy4RCQG [13:50:59 CEST] <zzlatev> this is weird, because it works in another tvheadend [20:10:59 CEST] <kepstin> zzlatev: nothing obvious there. The '-tune' option is of course useless because you're not using any encoder it could apply to, but I don't think that's a fatal error? [20:27:08 CEST] <another> set loglevle to debug and see what comes up [21:21:54 CEST] <lagzilla> I'm trying to convert a file with ```ffmpeg -i audio.mp3 -c:a libvorbis -q:a 4 --map_metadata 0 file.ogg``` but I keep getting error Unrecognized option '-map_metadata'. But I still see the option available in the latest docs https://ffmpeg.org/ffmpeg.html [21:23:03 CEST] <another> which version are you running? [21:23:38 CEST] <another> oh, wait. you're using double dashes [21:24:21 CEST] <lagzilla> oh [21:24:25 CEST] <lagzilla> oops lol [21:24:27 CEST] <lagzilla> thanks [21:25:38 CEST] <another> super secret pro tip: reading error messages dilligently :) [21:26:17 CEST] <another> would've saved me countless hours of debugging... [00:00:00 CEST] --- Sun Jun 9 2019

1 0

ffmpeg-devel.log.20190607
by burek 08 Jun '19

08 Jun '19

[05:31:13 CEST] <cone-050> ffmpeg 03Jun Zhao 07master:1e7a8b92eedb: lavf/hls: Update av_log() log message [06:26:54 CEST] <vtorri99978666> thardin with ffmpeg 4.1.3, make V=0 or make V=1 are the same wrt output , it's verbose [08:25:35 CEST] <thardin> vtorri99978666: oh? strange [09:45:41 CEST] <cone-464> ffmpeg 03Paul B Mahol 07master:79aa91d562a5: avformat/id3v2enc: write CTOC too [16:56:20 CEST] <jamrial> jkqxz: your vaapi filter patches from a few days ago broke some fate clients [16:56:51 CEST] <jamrial> ex http://fate.ffmpeg.org/log.cgi?slot=x86_64-archlinux-gcc-threads-auto&time=… [16:57:22 CEST] <jamrial> errors about undeclared stuff. you probably forgot some vaapi version preprocessor checks [21:51:39 CEST] <cone-225> ffmpeg 03Andreas Rheinhardt 07master:c6bb825e7211: avformat/matroskadec: Remove unused variables [21:51:39 CEST] <cone-225> ffmpeg 03Andreas Rheinhardt 07master:f767c68b3483: avformat/matroskadec: Correct outdated error message [21:51:39 CEST] <cone-225> ffmpeg 03Andreas Rheinhardt 07master:410a0824f07a: avformat/matroskadec: Compactify structure [22:05:11 CEST] <jkqxz> jamrial: Urgh. I'll have a look. [22:18:37 CEST] <cone-225> ffmpeg 03Mark Thompson 07master:a53f9fde45e6: lavfi/vaapi: Fix build with libva 2.1 and 2.2 [22:18:46 CEST] <jkqxz> jamrial: Should be fixed. [22:23:15 CEST] <jamrial> jkqxz: cool, thanks [22:26:42 CEST] <cone-225> ffmpeg 03Andreas Rheinhardt 07master:ad2745e86763: cbs_av1, cbs_jpeg, cbs_mpeg2, cbs_vp9: Fix undef [23:07:19 CEST] <mkver> michaelni: Thanks for taking a look at my Matroska patchset. [23:12:17 CEST] <michaelni> well, i only looked at the first 3 patches ... [23:15:58 CEST] <mkver> Better than zero. [23:47:43 CEST] <uartie> jkqxz: ok, patch v4 should be the last version, ugh :p [23:58:01 CEST] <uartie> why is trac.ffmpeg.org so sluggish [23:58:20 CEST] <durandal_1707> uartie: because you are using it :) [23:58:31 CEST] <BtbN> trac is not a good software, and does not exactly scale well [23:58:43 CEST] <uartie> durandal_1707: oh that explains it :P [23:58:55 CEST] <BtbN> And I think it's running an ancient version [23:59:44 CEST] <uartie> any plans to move things to more modern tools? [00:00:00 CEST] --- Sat Jun 8 2019

1 0

ffmpeg.log.20190607
by burek 08 Jun '19

08 Jun '19

[01:06:38 CEST] <MoziM> is there a way to concatonate the images in 2 different directories together like "ffmpeg -f image2 -framerate 24 -i new_frames/%d.png new_frames2/%d.png -i audio.mp3 -r 24 -vcodec libx264 -crf 16 video.mp4" ? [01:45:16 CEST] <steve___> MoziM: try adding a '-i' for the second dir and the option after the inputs '-filter_complex "concat=n=2"' [02:09:01 CEST] <MoziM> steve___: i renamed the images instead and tried ffmpeg -f concat -safe 0 -framerate 24 -i output/* -i ~/audio.mp3 -r 24 -vcodec libx264 -crf 16 output.mp4 [02:09:16 CEST] <MoziM> does ffmpeg need a list of images from a text file instead? [02:10:04 CEST] <MoziM> i also tried ffmpeg -f image2 -framerate 24 -i output/* -i ../audio.mp3 -r 24 -vcodec libx264 -crf 16 ~/inque/video.mp4 [02:10:27 CEST] <steve___> MoziM: if you want to use '*' then you'll need '-pattern_type glob' [02:10:28 CEST] <MoziM> but it just gives me the prompt "File 'output/000002.png' already exists. Overwrite ? [y/N] ^C" [02:10:41 CEST] <MoziM> steve___: where would i need to put that? [02:10:56 CEST] <steve___> before -i output/* [02:11:30 CEST] <another> also: put 'output/*' in single quotes [02:11:49 CEST] <MoziM> may i ask why single quotes? [02:11:50 CEST] <steve___> or else you need to use something like FILENAME%02d.png [02:12:17 CEST] <another> because otherwise your shell might expand it [02:12:41 CEST] <MoziM> there's no prefix name and each image name is 6 digits long [02:12:46 CEST] <MoziM> so %06d? [02:12:52 CEST] <steve___> yep [02:12:58 CEST] <another> %06d.png [02:13:08 CEST] <MoziM> thanks [02:13:17 CEST] <MoziM> and use the globa option? [02:13:50 CEST] <MoziM> thanks it's working [02:13:56 CEST] <another> :) [09:10:16 CEST] <MoziM> how do i encode a video at the native fps of a video with ffmpeg? [13:10:14 CEST] <kepstin> MoziM: if you use no special options, ffmpeg will preserve frame tming from the source when availabe [14:09:50 CEST] <dongs> hmm [14:09:58 CEST] <dongs> should mpv.exe be using nvdec for 4k/8k decoding? [14:11:03 CEST] <dongs> ah ok. i had to force -hwdec nvdec [14:11:48 CEST] <dongs> damn, its just a little too slow for 8k decode [14:11:58 CEST] <dongs> goes to 95-100% nvdec usage [14:12:04 CEST] <dongs> while mpc-hc is at around 70% [14:44:00 CEST] <kepstin> they don't even list 8k support in nvdec except for some pascal and newer cards, and then only with hevc. [14:44:13 CEST] <kepstin> er, and vp9 apparently [14:45:44 CEST] <kepstin> i would expect the cards to manage realtime decoding of 1 8k stream if they support it at all tho [14:47:17 CEST] <dongs> kepstin: correct. [14:47:20 CEST] <dongs> i have hevc 8k @ 60p [14:47:25 CEST] <dongs> it plays fine on t uring gtx 1660 [14:47:34 CEST] <dongs> with mpc-hc, using nvdec [14:47:58 CEST] <BtbN> It makes no sense that Decode-Unit-Load would be different between players, they are sending the exact same stuff to the card. [14:48:10 CEST] <dongs> like i saud ~70% nvdec uasge. but for some reason mpv (based on ffmpeg?) uses too much [14:48:17 CEST] <dongs> i suspect its maybe due to HDR color scaling stuff [14:48:26 CEST] <BtbN> That's not decode unit load. [14:48:33 CEST] <kepstin> mpv runs that on the shader cores, completely independent [14:48:37 CEST] <dongs> hmmm [14:48:41 CEST] <dongs> so why its failing then [14:49:01 CEST] <dongs> mpv.exe --hwdec nvdec lol.mkv < stuttery, but looks good [14:49:11 CEST] <dongs> mpc-hc lol.mkv = looks not HDR, but smooth [14:51:49 CEST] <kepstin> (assuming the scaling is linear with number of macroblocks or whatever the hevc equivalent is decoded, i'd expect a turing nvenc instance to be able to manage ~2 streams of hevc 8kp60) [14:52:09 CEST] <dongs> no, even 1 stream takes up 70% decode [14:52:20 CEST] <kepstin> s/nvenc/nvdec/ [14:52:25 CEST] <dongs> its unplayable on pascal [14:52:31 CEST] <dongs> 100%, and around 30-40fps [14:52:39 CEST] <kepstin> i guess it's not linear then [14:52:58 CEST] <dongs> Video: HVC1 7680x4320 59.94fps [V: hevc main 10, yuv420p10le, 7680x4320 [default]]Video: HVC1 7680x4320 59.94fps [V: hevc main 10, yuv420p10le, 7680x4320 [default]] [14:53:27 CEST] <dongs> actaully 60% nvdec, not 70 [14:53:33 CEST] <kepstin> pascal can't manage very many streams of 4k even, so that's totally expected :) [14:54:13 CEST] <dongs> hmm [14:54:17 CEST] <kepstin> but yeah, i'd really expect that to work. no idea why you're seeing issues with mpv. [14:54:17 CEST] <dongs> i'd like to know why mpv fails this tho. [14:57:44 CEST] <kepstin> you've checked the other gpu load indicators right? it's not getting maxed out somewhere /other/ than the video decode unit? [14:57:49 CEST] <dongs> correct [14:58:34 CEST] Action: kepstin had that issue recently when he found out that his ryzen 2200g could decode 4k fine, but couldn't do the post-processing in hq preset at that res [14:59:17 CEST] <kepstin> yeah, a 1660 has enough shader power that i wouldn't expect that to be an issue. [14:59:36 CEST] <BtbN> sounds to me like you're decoding stuff twice [14:59:43 CEST] <BtbN> Cause nothing else but decoding puts load on the decoder. [15:00:38 CEST] <dongs> https://i.imgur.com/4VEGYtf.png [15:00:48 CEST] <dongs> mpv, exit it, re-run same content in mpc-hc [15:02:10 CEST] <kepstin> can you replicate this issue with ffmpeg or ffplay (with ffmpeg, try with -re, or just see what framerate you get at max)? [15:02:51 CEST] <kepstin> that'll narrow down if it's an issue with ffmpeg or mpv [15:02:58 CEST] <dongs> uh how do i make ffmpeg decode to screen or wahtever [15:03:23 CEST] <BtbN> No need to show it [15:03:28 CEST] <BtbN> the decode load is there no matter what [15:03:34 CEST] <kepstin> don't need to, just discard the decoded frames with e.g. '-f null -' [15:03:35 CEST] <dongs> sure ok so how do i make it just decode [15:03:37 CEST] <dongs> ok [15:03:58 CEST] <dongs> its not using nvdec by default [15:04:13 CEST] <angular_mike> i'm trying to use ffplay to play a file encoded with xvid [15:04:14 CEST] <BtbN> -hwaccel cuda [15:04:39 CEST] <angular_mike> `-vcodec libxvid` flag seems to fail tho with No codec could be found with name 'libxvid' [15:04:45 CEST] <angular_mike> am I specifying it wrong? [15:04:54 CEST] <dongs> BtbN: no [15:05:14 CEST] <kepstin> dongs: https://trac.ffmpeg.org/wiki/HWAccelIntro might be a useful reference [15:05:29 CEST] <dongs> [hevc @ 000001b90558e600] decoder->cvdl->cuvidCreateDecoder(&decoder->decoder, params) failed -> CUDA_ERROR_OUT_OF_MEMORY: out of memory [15:05:33 CEST] <dongs> lol wut [15:05:39 CEST] <kepstin> angular_mike: you shouldn't need to specify a codec for decoding - ffmpeg autodetects it, normally. [15:06:53 CEST] <dongs> frame= 290 fps= 23 q=-0.0 size=N/A time=00:00:05.75 bitrate=N/A speed=0.448x [15:07:01 CEST] <angular_mike> hm, well it's an undocumented binary data file that just happens to have som evideo streams embedded in it [15:07:01 CEST] <dongs> well, it uses around 42% of nvdec [15:07:15 CEST] <angular_mike> im am feeding it to ffplay and it seems to be able to play some of the videos but with artifacts and stuff [15:08:39 CEST] <kepstin> angular_mike: that said, the decoders in ffmpeg are all named after the codec they decoder - libxvid isn't the name of a codec but rather is the name of a specific encoder [15:09:04 CEST] <kepstin> angular_mike: libxvid produces videos that can be decoded by ffmpegs "msmpeg4" decoder, iirc. [15:09:43 CEST] <angular_mike> kepstin: I'm just trying to find a way to specify otions that are optimal for DivX chunk playback [15:12:15 CEST] <dongs> so eh? [15:15:37 CEST] <dongs> why does ffmpeg nvdec not have enough memory to decode heh [16:47:40 CEST] <short-bike> I'm looking for a way to tag / search mp4 and avi files from the command line. Would ffmpeg allow me to do this ? [17:00:29 CEST] <DHE> not without rebuilding the files from nigh-scratch. ffmpeg isn't a metadata tweaking and browsing sort of tool [17:04:11 CEST] <short-bike> Yeah - there's not a lot to choose from out there for what I'm looking for. But thanks anyway DHE. [17:42:54 CEST] <brimestone> Hey guys, what version of ffmpeg and ffprobe can I use for a macOS 10.8.5 ? [17:43:52 CEST] <Mavrik> What do you mean? [17:45:30 CEST] <brimestone> The latest static build is only works for macOS 10.9 and above.. So I need an older version. [17:46:06 CEST] <BtbN> That's up to whoever made that build. [17:46:56 CEST] <brimestone> Im talking about the static builds from http://ffmpeg.org/download.html#build-mac [17:47:13 CEST] <BtbN> That only links to external sites. There are no ffmpeg provided builds. [17:48:00 CEST] <Mavrik> Yeah, just use homebrew [17:48:07 CEST] <Mavrik> And grab it there [17:48:25 CEST] <BtbN> Upgrading that ancient OS would be a very good idea though. It's horribly insecure and should not be online. [17:48:54 CEST] <brimestone> The hombrew fails to get from repo due to ssl tls. GitHub doesn't support older than 1.1 [17:49:13 CEST] <BtbN> Yeah, your OS is just too old to still be supported by anything. [17:49:22 CEST] <brimestone> Tell me about it! :) [17:49:29 CEST] <BtbN> It's a 7 year out of date system [18:53:06 CEST] <kepstin> looks like most 2012 or later macs are still supported by macos mojave (10.14)... [18:53:39 CEST] <kepstin> and even if not you should be able to get at least 10.13 on there. [19:38:56 CEST] <electrotoscope> what's the standard way to make ffmpeg feature requests? [19:44:54 CEST] <kepstin> ... post a patch that implements your desired feature on the mailing list? [19:45:15 CEST] <kepstin> other than that, i guess you can open a trac ticket, but absolutely no guarantee anyone will work on it :/ [19:45:58 CEST] <kepstin> what kind of feature? [19:47:33 CEST] <kepstin> it never hurts to ask "how do I do X?" here, it might be that what you wanted is actually already there and you didn't know it :) [19:51:13 CEST] <electrotoscope> I tried to ask on trac at https://trac.ffmpeg.org/ticket/7946 but it was closed as invalid [19:59:21 CEST] <kepstin> trac is so slow that hasn't loaded for me yet. mind restating it here? [20:00:55 CEST] <kepstin> ah, nvm, there it goes [20:03:23 CEST] <kepstin> yeah, that's probably not gonna get any further unless you either write a patch for it or find someone else to do so. your ticket was also a bit misleading because you were talking about metadata, but the things you wanted to use in drawtext were not metadata. [20:04:11 CEST] <kepstin> "metadata" has a specific meaning in the ffmpeg code, referring to user-provided data attached to the file (sometimes called 'tags' e.g. in music files) [20:04:31 CEST] <electrotoscope> also called TAG: in ffprobe apparently [20:05:00 CEST] <electrotoscope> what would other points of information about the data be called? [20:05:20 CEST] <kepstin> hmm. there's actually another challenge with your request [20:05:26 CEST] <electrotoscope> like the timestamp or frame number? not packet metadata but packet info? [20:05:34 CEST] <kepstin> the data you're asking about is packet properties, but filters don't see packets [20:05:45 CEST] <kepstin> filters run on decoded frames [20:06:06 CEST] <kepstin> some of the packet information is passed through, but not all [20:06:51 CEST] <kepstin> anyways, your feature request should basically be "please expose packet/frame properties X, Y, Z as variables in the drawtext filter" [20:07:20 CEST] <kepstin> there's no generic way to do it for all properties, they'd have to be individually coded, so you need to request the specific ones you want. [20:08:40 CEST] <kepstin> and keep in mind that the answer for some might be "that property isn't available on decoded frames, so it's not possible". (I suspect packet size and position might be in this category) [20:12:36 CEST] <kepstin> "ffprobe -show_frames" will give you a better idea of what filters see. [20:20:04 CEST] <electrotoscope> how can I tell what a filter can see and can't see from the list? [20:21:07 CEST] <electrotoscope> like it can obviously see pkt_pts_time [20:21:18 CEST] <electrotoscope> but I guess not pkt_duration_time [20:30:03 CEST] <kepstin> a filter should be able to see everything you see in the [FRAME] block with -show_frames [20:30:31 CEST] <kepstin> not everything is necessarily exposed in the showtext filter, but it could be added. [20:38:35 CEST] <electrotoscope> ah okay! well yeah that's all I was looking for [20:39:03 CEST] <electrotoscope> I guess my feature request would be if there was some way to go (for instance) %{packetinfo:pkt_pos} [20:39:19 CEST] <electrotoscope> and then it would get the info called pkt_pos in ffprobe [20:55:57 CEST] <kepstin> looks like pkt_pos does get passed from the decoder through to the avframe, you you might be lucky on that. [20:59:32 CEST] <feliwir> Hey, where can i download a stable source tarbal of libaom? [20:59:41 CEST] <feliwir> The googlesource page of libaom is a bit weird... [21:00:03 CEST] <electrotoscope> oh nice! Okay so can I rename the ticket on trac? Or ask someone to do that? Or should I make a new ticket? [21:00:09 CEST] <kepstin> electrotoscope: adding some new variables that could be accessed as %{pkt_pos} and %{pkt_duration} would actually be pretty trivial, fwiw [21:00:52 CEST] <kepstin> looks like pkt_size is available too actually [21:01:04 CEST] <kepstin> (note that whether or not they have useful values depends on the decoder) [21:02:14 CEST] <electrotoscope> fantastic!! [21:02:56 CEST] <electrotoscope> would it be possible to have something that's universal? like %{metadata} allows you to define your own key [21:03:19 CEST] <kepstin> no, because these have to be manually coded to access particular fields in the frame structure [21:06:38 CEST] <electrotoscope> ah okay darn [21:06:52 CEST] <electrotoscope> okay so should I make a new trac ticket, or should I put comments in requesting that it be changed? [21:07:58 CEST] <kepstin> you know what, have a patch. https://www.kepstin.ca/dump/0001-vf_drawtext-Add-pkt_pos-pkt_duration-pkt_s… [21:08:08 CEST] <kepstin> (i have't even compile tested that, but it's pretty trivial) [21:08:21 CEST] <kepstin> to get that merged it would also need documentation updates [21:08:47 CEST] <electrotoscope> oh man thanks! I don't have a build chain thing up right now [21:09:25 CEST] <electrotoscope> would you be able to write one for pkt_duration_time as well? [21:09:30 CEST] <electrotoscope> or wait is that included [21:09:43 CEST] <electrotoscope> this is amazing!! [21:11:18 CEST] <kepstin> ah, I should probably just make pkt_duration return time instead of pts values to match the 't' variable [21:11:39 CEST] <kepstin> i'm kind of surprised there's not variables that return the frame pts, but whatever [21:12:04 CEST] <electrotoscope> there [21:12:07 CEST] <electrotoscope> 's one as [21:12:08 CEST] <electrotoscope> pts The timestamp of the current frame. It can take up to three arguments. The first argument is the format of the timestamp; it defaults to flt for seconds as a decimal number with microsecond accuracy; hms stands for a formatted [-]HH:MM:SS.mmm timestamp with millisecond accuracy. gmtime stands for the timestamp of the frame formatted as UTC time; localtime stands for the timestamp of the frame formatted as local time zone [21:12:27 CEST] <electrotoscope> it seems to match what ffprobe [FRAME] calls "pkt_pts_time" [21:13:20 CEST] <kepstin> oh, i see, pts is a special one, it has a formatting function instead of just being a variable. [21:13:40 CEST] <electrotoscope> I thought it might be a special case [21:14:58 CEST] <electrotoscope> could i help by writing the documentation update? [21:15:44 CEST] <kepstin> the way I did that as variables, you'd have to use %{e:pkt_pos} to access them. [21:16:18 CEST] <electrotoscope> oh okay cool! So would they also be accessible to the x and y function math then? [21:16:25 CEST] <kepstin> yes [21:28:43 CEST] <electrotoscope> I roughed it out http://www.gluce.ca/drawtext_documentation.txt but I'm happy to format appropriately, I don't know how [21:33:37 CEST] <kepstin> huh, yeah, pict_type is available as a variable in expressions but it wasn't documented. That one's not very useful, since you get the numeric enumeration value; that's why there's a special function documented in the text expansion section that turns it into a character. [21:35:48 CEST] <electrotoscope> oh right [21:36:41 CEST] <electrotoscope> I guess someone might want to do positioning based on that... doesn't seem likely [21:38:38 CEST] <electrotoscope> is the source that https://ffmpeg.org/ffmpeg-filters.html is generated from posted somewhere? [21:38:47 CEST] <kepstin> it's generated from a file inside the ffmpeg code repository [21:39:30 CEST] <kepstin> (so documentation updates are committed in the same patch as the code change is made, normally) [21:48:42 CEST] <electrotoscope> Makes sense! Trying to update my format to match [21:50:12 CEST] <kepstin> if you see any other properties in https://www.ffmpeg.org/doxygen/trunk/structAVFrame.html that you think would be useful, might as well add them at the same time. [21:50:44 CEST] <kepstin> but stuff that's numbers is easier, anything that's an enum would need a helper function to render it as a nice string [21:51:38 CEST] <kepstin> (it doesn't make sense to add audio stuff tho, because the filter only receives video frames) [21:52:02 CEST] <electrotoscope> hmm looking [21:53:22 CEST] <electrotoscope> Can't see anything! maybe pix_fmt for if things switch bit depth midway through a file but that's pretty esoteric and only affects people using Avid MediaComposer basically [21:53:55 CEST] <electrotoscope> as far as I've ever heard. And they just don't like it because it generates errors and messes with drawtext and then I have to complain to the editor to stop doing that, it's not something anyone's going to want to burn in [21:54:28 CEST] <electrotoscope> I tried to format the documentation change like your patch was written but this is my first time writing something like that so I might have gotten things wrong [21:54:28 CEST] <electrotoscope> http://www.gluce.ca/drawtext_documentation_2.txt [21:55:11 CEST] <kepstin> you'd want to actually have a git checkout of the code, and use git's diff functionality to generate that. [21:55:14 CEST] <electrotoscope> (also fixing a typo right before it, and adding clarification to the "@item metadata" section because from google searching I know I'm not the only one who got confused by that term [21:55:28 CEST] <kepstin> but having the desired text is a useful step anyways [21:55:54 CEST] <electrotoscope> I figured that would be the 100% correct way to do it, but I don't have git set up [21:56:53 CEST] <electrotoscope> Is there anything else I could do to help? [21:59:15 CEST] <kepstin> hmm, at this point the last remaining step is getting everything into a properly formatted git diff and posting it to the mailing list. but collecting the proposed changes in a ticket might be useful so they don't get lost/forgotten. [22:01:34 CEST] <electrotoscope> okay cool I'm happy to do that. Should I make a new ticket or add comments to the previous one do you think? [22:02:41 CEST] <kepstin> I'd suggest reopening it and changing the title to "expose more frame properties as variables in drawtext filter" or something like that. [22:03:03 CEST] <kepstin> if you're able to, i haven't used the ffmpeg trac much so i'm not sure what's permitted [22:04:18 CEST] <electrotoscope> I can reopen but I can't change the description. Maybe I'll just make a new one [22:12:38 CEST] <electrotoscope> I added it to trac at https://trac.ffmpeg.org/ticket/7947 [22:12:41 CEST] <electrotoscope> thank you so much!!! [22:13:29 CEST] <electrotoscope> This will be a huge help to me, save me having to write everything out from ffprobe to an external text file with tons of line returns and then setting x=(n*[offset]) to scroll up every frame [22:33:32 CEST] <void09> found this script that detects scene changes and makes screenshots at those points + text time log. I want something that also cuts the file at those points, with file names reflecting frame range. help ? [22:33:34 CEST] <void09> ffmpeg inputvideo.mp4 -filter_complex "select='gt(scene,0.3)',metadata=print:file=time.txt" -vsync vfr img%03d.png [22:46:08 CEST] <electrotoscope> @void09 maybe you could take those timecodes and create a concat list? [22:48:06 CEST] <kepstin> void09: if you can get a list of timecodes or frame numbers, then you can pass them to the segment muxer to tell it when to generate breaks. There's not currently any way I know of to do it in a single pass. [22:49:22 CEST] <kepstin> You'd probably want to make sure there are keyframes where you want breaks too if you do that, which I'm not sure how to do with ffmpeg cli. there might be encoder specific options? [22:49:41 CEST] <kepstin> other than that, you could just script a loop of ffmpeg using -ss and -t to extract video sections. [23:02:24 CEST] <void09> kepstin: thanks but that's what I wanted to find out : P [23:02:31 CEST] <void09> I'm not good with scripting or ffmpeg [23:04:11 CEST] <void09> already got the timecodes, but i'd rather have frame number [23:04:30 CEST] <void09> frame:0 pts:38789 pts_time:38.789 [23:04:33 CEST] <void09> lavfi.scene_score=0.419210 [23:04:53 CEST] <kepstin> timecodes are what you want, you can seek to timecodes but you can't seek to frame number [23:05:02 CEST] <void09> oh [23:05:21 CEST] <void09> so I guess they are precise enough to not go to the wrong frame [23:05:42 CEST] <void09> oh yeah, second with 3 decimals [23:05:58 CEST] <void09> ok, got time codes [23:06:10 CEST] <void09> I want to put together a distributed encoding thingie [23:06:27 CEST] <void09> because av1 encoding is suuper slow [23:06:53 CEST] <kepstin> hmm, that's tricky. to segment video at exact frame boundaries... you have to re-encode it [23:07:18 CEST] <kepstin> but if you're doing a distributed encoding thing, you want to avoid multiple re-encoding steps [23:07:19 CEST] <void09> re-encode it ? [23:07:24 CEST] <void09> of course [23:07:37 CEST] <void09> hm yes you are right, unless the cutting point is a keyframe, right? [23:07:41 CEST] <void09> then no re-encoding is needed [23:08:18 CEST] <kepstin> for this application, i'd recommend ignoring the whole scene detection thing, and just do segments of a fixed length (duration), which can be done easily enough with the segment muxer, cutting on keyframe boundaries without re-encoding [23:08:20 CEST] <void09> and I am guessing the x264 encoder is sane enough to detect a radical scene change and start a new keyframe with it [23:08:46 CEST] <void09> yes but this presents an adiional problem.. [23:09:01 CEST] <void09> maybe the x264 keyframe will not be the av1 keyframe, if it were not cut [23:09:18 CEST] <kepstin> void09: if your segments are long enough, it doesn't make a big difference [23:09:38 CEST] <void09> ok so the best strategy is to do both then [23:09:42 CEST] <kepstin> and really, there's not much point in transcoding h264 to av1 unless the original h264 was extremely high quality [23:09:50 CEST] <void09> scene detection -> if keyfrmae then cut, else proceed [23:09:52 CEST] <kepstin> you'll get lossy encoding losses :/ [23:10:06 CEST] <void09> it's for bluray sources only of course [23:10:14 CEST] <void09> 25-35mbit [23:10:24 CEST] <kepstin> bluray has a fixed keyframe interval that's fairly short [23:10:30 CEST] <void09> oh it does? [23:10:41 CEST] <void09> i had no idea about that [23:10:51 CEST] <void09> ok then.. this is complicated :) [23:11:00 CEST] <kepstin> to make seeking work reasonably on slow optical media, ... :/ [23:11:16 CEST] <void09> yes that makes sense, they also got lots of space to spare [23:11:48 CEST] <void09> what is this keyframe interval ?depends on the bluray disc? [23:11:57 CEST] <kepstin> anyways, just segment into chunks on keyframe boundaries, use fairly long segments (think 5-10 minutes maybe?), and the loss from not getting perfect keyframe placement will be small enough to not matter [23:12:12 CEST] <void09> kepstin: I want "perfect" :/ [23:12:20 CEST] <void09> 10kb loss will upset me :P [23:12:32 CEST] <kepstin> if you want perfect then don't segment the video before encoding. [23:12:51 CEST] <void09> hmm [23:12:57 CEST] <void09> yeah, or re-encode losslessly [23:13:01 CEST] <void09> which would be a pretty big file [23:13:03 CEST] <kepstin> to get "perfect" you have to run the encoder to find out where it wants to place keyframes in order to know where to segment [23:13:19 CEST] <kepstin> and yeah, lossless transcode would work too [23:13:51 CEST] <void09> or just try scene changes with low change value, and choose ones that intersect with teh bluray encode keyframes [23:13:53 CEST] <void09> if [23:13:57 CEST] <kepstin> blu-ray is max of 2 second gop size (some video formats lower that to 1s) [23:14:28 CEST] <kepstin> ffmpeg's scene change detection doesn't necessarily match the encoder's keyframe placement decisions [23:15:08 CEST] <kepstin> an example would be a flashing scene where it goes blank then back to the previous image - that's detected as a "scene change" but a good encoder might notice that the previous frame comes back, so it'll want to keep it in the same gop to use the reference frame. [23:17:28 CEST] <kepstin> if you want maximum efficiency and also segmented encoding, you just need to use big segments to amortize the cost of the extra keyframes :/ I suppose attempting to align it with scene changes may help slightly, but i'd expect it to be pretty minimal. [23:40:21 CEST] <void09> ok I guess I could do a test run. get a file with keyframe times ? or frame numbers? [23:41:15 CEST] <void09> and then a file with scene changes as detected by ffmpeg. and see how many match [23:52:29 CEST] <void09> any help with getting indices/timeframes of keyframaes in a video? [00:00:00 CEST] --- Sat Jun 8 2019

1 0