December 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20191205
by burek 06 Dec '19

06 Dec '19

[00:36:10 CET] <durandal_1707> braw parsing bug finally resolved, not to implement more stuff .... [00:36:52 CET] <durandal_1707> *now to [00:39:57 CET] <BradleyS> \o/ [01:49:09 CET] <pbd> Hello [01:50:09 CET] <pbd> Icecast has a max ebml size set to 131072, which makes streaming webm impossible with ffmpeg since 4.1. [01:50:35 CET] <pbd> I'm not sure whether ffmpeg should bring some modifications to reduce the size of the ebml or if that's icecast that shuold increase the value. [01:51:37 CET] <pbd> Anyway, modifying icecast allows to stream again. [03:20:54 CET] <cone-986> ffmpeg 03James Almer 07master:94fd85d81d50: fate/matroska: add a test for xiph lacing [03:20:54 CET] <cone-986> ffmpeg 03Andreas Rheinhardt 07master:f7bf59b431e0: avformat/matroskadec: Check before allocations [03:20:54 CET] <cone-986> ffmpeg 03Andreas Rheinhardt 07master:eec26b591162: avformat/matroskadec: avcodec/tta: Set extradata_size to 22 [03:20:54 CET] <cone-986> ffmpeg 03Andreas Rheinhardt 07master:668490ac981b: avformat/matroskadec: Use bytestream API instead of AVIOContext [03:20:54 CET] <cone-986> ffmpeg 03Andreas Rheinhardt 07master:9ad1a6d64cc6: avformat/matroskadec: Avoid allocating array for lace sizes [03:20:54 CET] <cone-986> ffmpeg 03Andreas Rheinhardt 07master:a69f92a94638: avformat/matroskadec: Simplify control flow of parsing laces [03:20:54 CET] <cone-986> ffmpeg 03Andreas Rheinhardt 07master:f74eaa17bb0b: avformat/matroskadec: Remove unnecessary check [03:20:55 CET] <cone-986> ffmpeg 03Andreas Rheinhardt 07master:dbe3be674459: avformat/matroskadec: Improve frame size parsing error messages [03:20:56 CET] <cone-986> ffmpeg 03Andreas Rheinhardt 07master:d5274f86a838: avformat/matroskadec: Reuse AVIOContext [06:03:52 CET] <philipl_> My server at home seems to be half alive and half dead. I can't connect to it but it still seems to be connected to things (like irc)... [16:44:59 CET] <av> I'm getting an error when building ffmpeg: https://pastebin.com/FSnNTYez [16:49:37 CET] <hero100> Guest86008: run configure first. [16:54:07 CET] <Guest86008> Nvm, configure stopped when it encountered an unknown cflag. I thought it would behave like x264 and just ignore unknown flags but I guess not [19:11:32 CET] <durandal_1707> https://0x0.st/zl64.png --> current braw decoder output [19:12:22 CET] <durandal_1707> subsampling is indeed 420 [19:14:11 CET] <Lynne> at least its not bayer [19:14:29 CET] <JEEB> braw sounsd like some heavy metal thing [21:45:57 CET] <cone-831> ffmpeg 03Andreas Rheinhardt 07master:3f37880c0571: avformat/mpeg: Make VobSub demuxer have its own context struct [21:45:57 CET] <cone-831> ffmpeg 03Andreas Rheinhardt 07master:bc3cf2bbd320: avformat/mpeg: Don't copy or leak string in AVBPrint [21:45:57 CET] <cone-831> ffmpeg 03Andreas Rheinhardt 07master:4825d8a98d4c: avformat/mpeg: Fix leaks of AVFormatContext and subtitle packets [21:45:57 CET] <cone-831> ffmpeg 03Michael Niedermayer 07master:37f31f4e509f: avcodec/fitsdec: Use lrint() [00:00:00 CET] --- Fri Dec 6 2019

1 0

ffmpeg.log.20191205
by burek 06 Dec '19

06 Dec '19

[14:54:06 CET] <ButtDog> Anyone know any solutions for getting media info similar to ffprobe, in a webbrowser? I've tried mediainfo.js but with no luck. [16:25:31 CET] <ncouloute> I'm getting "h264_mp4toannexb filter failed to receive output packet" when trying to concat some clips together using the concat demuxer. It used to work on very old version of ffmpeg. (N-51511-g599866f from 2013) [16:33:58 CET] <kepstin> (preferrably from both ffmpeg versions so we can compare) [16:34:19 CET] <ncouloute> okay [17:03:36 CET] <ncouloute> FFMPEG 2013 N-51511-g599866f output: https://paste.ee/p/MMuIF FFmpeg 4.2.1 output: https://paste.ee/p/wgXWp Wouldnt let me use pastebin too long. Have to purchase pro. Pastie seems like the site is dead. [17:08:54 CET] <BtbN> looks like what you're trying to concat is either invalid or broken. [17:08:56 CET] <kepstin> ncouloute: hmm, looks like one of your input files in the playlist has no video frames [17:09:10 CET] <BtbN> *incompatible [17:10:02 CET] <kepstin> anyways, the old version of ffmpeg skipped it, that's probably what the "[h264 @ 007b2e20] no picture " message is from [17:10:10 CET] <kepstin> but the new version gives an error [17:10:20 CET] <kepstin> the old version probably predates the auto-inserted bsfs [17:28:36 CET] <ncouloute> Thing is the actual file has both video clips in it on the older version [17:31:12 CET] <ncouloute> So it may report no video. it is actually still stitching it together with the old version. New version just has the first clip in the MP4 [17:33:33 CET] <ncouloute> You can tell that by the frame= line at the end and the time=. An I actually can see the file [17:41:39 CET] <kepstin> ncouloute: does running "ffmpeg -i <whatever> -c copy something.mp4" work when run individually on each input file? [17:46:11 CET] <ncouloute> nope [17:46:51 CET] <ncouloute> I will most likely have to reenode each? I though the demuxer was doing that. I guess it stitches it together and then decodes after if not copying [17:48:58 CET] <kepstin> ncouloute: that's strange. what's the output of the failed ffmpe on the individual input file? [17:49:16 CET] <kepstin> like, frmp mp4 source to mp4 dest, that should always work with -c copy [17:49:29 CET] <kepstin> unless the source file is busted somehow [17:50:15 CET] <kepstin> but yes, the concat demuxer does not decode (it's a demuxer not a decoder). It concatenates the still-encoded video streams then sends the combined result to a decoder [17:50:37 CET] <kepstin> (which is why it can't work if the videos have different codecs, or sometimes even different settings in the same codec) [17:50:43 CET] <ncouloute> So there is no error on the actual copy command. When I try to concat I get the same error. [17:51:45 CET] <kepstin> and both of these video files are from the same camera? [17:54:19 CET] <ncouloute> yes a DJIN drone camera [17:54:59 CET] <kepstin> I'd really expect the concat demuxer to work on that, it's very strange. does it break if you switch the order of the two files? [17:55:05 CET] <ncouloute> One of their Mavik cameras.. Dont know the exact model.. Interesting thing is smoe of the clips work others dont [17:55:17 CET] <ncouloute> let me try that [17:56:23 CET] <ncouloute> Still errors out when switching the order. [17:56:34 CET] <void09> I need to join several mp4 files into one mkv, while generating a chapter for each of them. any way to have ffmpeg handle the time intervals but provide chapter title info from outside ? [17:57:10 CET] <kepstin> ncouloute: hmm. probably not gonna get further with debugging unless you can provide some sample files (probably open a ticket on trac). Someone familiar with h264 bitstreams will have to take a look. [17:57:26 CET] <kepstin> ncouloute: also test with latest git build instead of the 4.2.1 release first, just in case [17:57:54 CET] <kepstin> possible this is a bug that's already been fixed :) [17:59:39 CET] <kepstin> void09: i don't know of any way to have ffmpeg automatically generate chapter metadata on file boundaries when concatenating. [18:00:07 CET] <void09> so i must generate it myself.. [18:00:25 CET] <ncouloute> I was about to say. if that existed I would love that. [18:00:29 CET] <void09> get times with mediainfo, in miliseconds.. add them up.. blah [18:00:49 CET] <ncouloute> I know the mkv tools set can do that [18:01:12 CET] <JEEB> the problem is that concatenation can be done on N levels in FFmpeg :P because nobody wanted to do it in ffmpeg.c [18:01:22 CET] <JEEB> so you have the concat protocol, demuxer and filter [18:01:38 CET] <JEEB> the only thing that can create chapters is the demuxer [18:02:03 CET] <JEEB> now, if ffmpeg.c did concatenation [18:02:18 CET] <JEEB> and knew where the files switched, then it could do it too [18:02:19 CET] <JEEB> :P [18:03:47 CET] <kepstin> honestly, adding it to the concat demuxer would be nice [18:04:02 CET] <kepstin> could even add some new stuff to the playlist format for chapter metadata to set names and stuff [18:04:49 CET] <JEEB> apparently someone already wanted some of that stuff, since there's segment_time_metadata [18:04:59 CET] <JEEB> which apparently adds metadata to the side data of the read AVPacket [18:05:20 CET] <JEEB> so you get the start time and duration of the segment [18:05:30 CET] <JEEB> (and that this is the packet where that begins) [18:06:03 CET] <JEEB> also I'm not 100% sure how the chapter stuff worked in FFmpeg [18:06:25 CET] <JEEB> you'd in theory have to update it as you hit EOF with each segment you're concatenating [18:07:07 CET] <ncouloute> You can get that info with ffmpeg.c ? The way I get the start and stop times is by reading the debug log....which is not the best [18:07:33 CET] <JEEB> ffmpeg.c gets that info, but it is most likely not utilized for anything [18:08:35 CET] <JEEB> http://up-cat.net/p/6e84a652 [18:08:37 CET] <JEEB> only references [18:08:52 CET] <JEEB> apparently there's a filter that utilizes the value [18:09:34 CET] <JEEB> thos values are available just fine to API clients, of which ffmpeg.c is one [18:09:39 CET] <ncouloute> yeah the segment filter or flag? I remember using that to create clips that are 1 gop each. thinking that would fix another isuse lol [18:10:49 CET] <JEEB> select filter is what does something with that stuff :P [18:10:59 CET] <JEEB> didn't check the context so no idea how exactly [18:11:28 CET] <kepstin> hmm. chapters only exist at the format context level, and it looks like code would expect them not to change after the file is open, so if the concat demuxer was gonna do chapters it would either need durations set in the playlist file, or it have to open all the files at the start, and they'd have to all have defined lengths. [18:12:41 CET] <ncouloute> One of the issues with parsing the debug log. Is the debug log info is not giving me the right PTS info when using the fps filter with the concat demuxer. It will say "Read frame with in pts 93263, out pts 9317" if you dont use the concat filter it gives the right out pts so I'm thinking it cant calculate the PTS across multiple files? Its giving me some sort of offset or frame count? [18:13:51 CET] <kepstin> ncouloute: the out pts on the fps filter is the pts after framerate conversion, i'm not sure what you're asking about [18:14:38 CET] <kepstin> I'm not sure how pts works with the concat demuxer, I'd expect it to offset the second file so the pts continues after the end of the first file. [18:15:17 CET] <ncouloute> sorry its not the fps filter [18:15:36 CET] <ncouloute> well idk what it is tbh it says [Parsed_fps_0 @ 06876540] [18:15:40 CET] <kepstin> that demux output you pasted is the fps filter [18:15:45 CET] <kepstin> debug output* [18:16:05 CET] <kepstin> but i dunno why you have that or what you're doing, since you pasted neither the command line nor the complete output of ffmpeg. [18:16:32 CET] <ncouloute> gotcha... I'll get on that [18:16:51 CET] <kepstin> the "out pts" in the fps filter debug output is the pts that the frame will have in the output file (modulo any additional conversion to container timebase done during muxing) [18:17:14 CET] <kepstin> the "in pts" is the pts the frame had when it was sent to the fps filter's input [18:17:22 CET] <kepstin> note that they are very likely to be in different timebases [18:19:16 CET] <kepstin> (fps filter always sets the output timebase to the inverse of the framerate it's converting to, so output pts values will always go up by 1 each frame) [18:22:13 CET] <ncouloute> I didnt know that. That is why I have the 1 frame offset. Interesting [18:24:33 CET] <kepstin> note that if you're using an old ffmpeg version, you should always make sure to convert to constant fps *before* the concat filter, since the concat filter was only recently fixed to work correctly if the inputs have different framerates [18:25:59 CET] <kepstin> old being, uh, anything but git master, I don't think that fix has made it to a release yet. [18:26:02 CET] <kepstin> should be in 4.3 [18:27:40 CET] <kepstin> (if the first input is detected as vfr, the concat filter was ok, it's only an issue if the first input was cfr) [18:28:07 CET] <ncouloute> that will be useful for me. [18:35:16 CET] <ncouloute> Here is the full command with output: https://paste.ee/p/DjHxM [18:54:23 CET] <Aison> Hello :-) I just detected this: https://scottlinux.com/2016/09/17/video-stabilization-using-vidstab-and-ffm… [18:54:25 CET] <Aison> vidstab [18:55:23 CET] <Aison> Is it somehow possible to keep the "main object" in the center of the video? [18:58:18 CET] <ncouloute> All I care about is the output files PTS. So I just need to know what the fps filters out pts time base would be. If I set it to 60000/1001 fps. I would think I could just divide it by 1001 and get the PTS_TIME. Although that math doesnt check out. Its closer to the concat PTS value after the -> but moved around a few frames [19:03:06 CET] <kepstin> ncouloute: the fps filter resets the output pts to start at 0 by default [19:03:56 CET] <kepstin> other than that, it's a straightforwards conversion of input pts to output timebase, with configurable rounding behaviour [19:05:23 CET] <kepstin> if multiple input frames map to the same output pts, the last frame is output. if an input frame is duplicated, the duplicates will fill the timestamps up until the next frame appears. [19:06:30 CET] <kepstin> hmm actually, i might be wrong about it resetting pts to start at 0 [19:06:44 CET] <kepstin> in this case your input pts started at 0, so the output pts did as well [19:08:43 CET] <kepstin> ncouloute: if you set fps=60000/1001, then the output timebase is 1001/60000. But note that the fps filter's output timebase/pts is not necessarily the timebase/pts used in the output file, since many formats cannot save arbitrary timebases [19:09:07 CET] <kepstin> so an extra conversion is often done during the muxing step to a timebase that the output container supports [19:10:59 CET] <ncouloute> I think learning ffmpeg api might be easier. I really just need the start and stops times... I convert to cfr. It's going to be harder to walk through this log and figure out whats duplicated and whats dropped. For the most part I've been fine just using the data after the concat -> but if fps filter has to duplicate a frame then it gets off [19:13:39 CET] <kepstin> hmm? it's pretty straightforwards. you just have to follow the pts through the concat then through the fps [19:13:46 CET] <kepstin> e.g. [concat @ 06c65ac0] file:1 stream:1 pts:3643 pts_time:6.07167 dts:3602 dts_time:6.00333 -> pts:8567 pts_time:14.2783 dts:8526 dts_time:14.21 [19:13:51 CET] <kepstin> then [Parsed_fps_0 @ 0784a1c0] Read frame with in pts 8567, out pts 856 [19:14:39 CET] <kepstin> although that still doesn't account for any conversions done during muxing step. [19:18:28 CET] <ncouloute> There shouldnt be any of that if I have -muxpreload 0 -muxdelay 0 ? I'm muxing to a MP4 AVC/AAC [19:18:58 CET] <kepstin> i'm not familiar with exactly what timebases mp4 container supports. [19:19:15 CET] <ncouloute> The "Writing frame with pts 20 to pts 21" line should account for any duplication correct? [19:19:24 CET] <ncouloute> nope it doesnt [19:19:38 CET] <ncouloute> well idk actually the dupicated frame line shows up after [19:19:46 CET] <kepstin> duplicates fill the space after each frame until the next frame [19:20:29 CET] <kepstin> so if you have a frame with "out pts 856" then another with "out pts 858", then you know that the space inbetween, 857, is a duplicate of the previous frame. [19:21:24 CET] <kepstin> and you'll also have a line "Writing frame with pts 856 to pts 857" in that case. [19:22:09 CET] <kepstin> (note that debug output is not a stable api, and can be changed at any time, so if your parse breaks on updates, well, too bad) [19:22:52 CET] <kepstin> the current debug output of the fps filter is just what I happened to find useful for debugging the fps filter itself when i rewrote it a while ago :) [19:27:49 CET] <ncouloute> Yeah so that math checks out. I guess I had the wrong timebase initially. These calculation should account for the go up 1 frame you were talking about before? (fps filter always sets the output timebase to the inverse of the framerate it's converting to, so output pts values will always go up by 1 each frame) [19:41:03 CET] <kepstin> (the reason the duplicates are done like that is because of how video playback works - a frame is displayed starting at its pts value, and is then held until the next frame is displayed or the file ends) [19:49:27 CET] <ncouloute> Regarding the "h264_mp4toannexb filter failed to receive output packet" issues. I should submit a bug ticket for that with the video in question. [21:19:24 CET] <ncouloute> I had to move location. Should I submit a bug for that "h264_mp4toannexb filter failed to receive output packet" issue. I was hoping more info would be in the log =/ [21:35:19 CET] <BtbN> It's not a bug, it just means your input is broken. [22:52:30 CET] <ncouloute> Yeah, I understand that. I was hoping there was a way to correct it without having to reencode the file. It used to work on previous version of ffmpeg. I guess not it just quits on error instead of trying to do it anyways. [00:00:00 CET] --- Fri Dec 6 2019

1 0

ffmpeg-devel.log.20191204
by burek 05 Dec '19

05 Dec '19

[09:58:03 CET] <cmeister2> hi. i'm interested in using ffmpeg to stream video from my Logitech C920 webcam. AFAICT it uses h.264 frames attached to an mjpeg stream, rather than exposing an h.264 stream. If I wanted to write an extension to ffmpeg so that it could split the mjpeg stream into mjpeg + h.264, what would the design for that look like? from my limited research so far i think it'd be a demuxer, but i'd appreciate an expert opinion [09:59:10 CET] <cmeister2> (basically, doing https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/h… but in ffmpeg) [09:59:46 CET] <JEEB> it would be a custom demuxer, yes. which would get somehow picked [10:00:32 CET] <thardin> is mjpeg synonymous with something else here, or is there literally an mjpeg decoder? I thought it was just another word for intra-only with jpeg as the codec [10:00:44 CET] <thardin> err mjpeg container of course [10:01:33 CET] <cmeister2> i think it's mjpeg, but apparently there are extensions to mjpeg which allow you to attach arbitrary jfif frames [10:01:45 CET] <cmeister2> something about APP0 [10:01:53 CET] <thardin> right jfif is a container unto itself as well [10:03:06 CET] <cmeister2> it's the reason you see the errors here i think: https://stackoverflow.com/questions/55439184/getting-unable-to-decode-app-f… [10:04:54 CET] <cmeister2> but thanks. knowing that it'll be a custom demuxer gets me a little closer. [10:06:00 CET] <thardin> if you open a ticket for it and attach a dump of the webcam's output then perhaps more people can chip in [10:06:15 CET] <thardin> plus it'd be tracked [10:07:49 CET] <cmeister2> ok. i'll work out how to do that. [10:11:52 CET] <JEEB> trac.ffmpeg.org basically [10:49:17 CET] <Lynne> what time is the meeting on friday? [10:51:21 CET] <kurosu> huh [10:53:01 CET] <Lynne> wasn't there a meeting on the 6th? or was it the 8th [10:53:42 CET] <JEEB> I don't think I've seen any announcement yet [10:53:55 CET] <JEEB> I was going to bring it up if no announcement would happen [10:58:00 CET] <kurosu> last I've heard was last Monday, but I don't think it happened [10:59:25 CET] <kurosu> maybe because there was not enough priori notice [11:00:15 CET] <JEEB> yes, the original message said, 1-2-3 [11:02:31 CET] <j-b> Goor morning people [11:02:58 CET] <j-b> It'll be next Monday, because some people were not available. Sorry, my fault [11:04:05 CET] <durandal_1707> Goor ray [11:06:50 CET] <kurosu> Oh, so one could have asked to delay such a meeting. Nice to know [11:07:44 CET] <durandal_1707> secdet meeting everdwhede [11:08:06 CET] <j-b> nothing secret. [11:11:17 CET] <durandal_1707> certainly secret for me, I always hear about it on irc and as last one [11:16:53 CET] <j-b> You are invited, and you can join a call, like everyone. [11:18:21 CET] <durandal_1707> i never received any notification, ecept once [11:21:42 CET] <j-b> there was only one meeting, so that's good. [11:22:00 CET] <j-b> I'll notify you personally if you want [11:24:43 CET] <kurosu> First mail mentioning it was on 2019/10/14, meeting confirmed on the 6th of November, further detailed indeed in this channel on the 9th (depending on timezone), held on the 10th [11:25:14 CET] <durandal_1707> i want to receive it via wire [11:35:36 CET] <jdarnley_obs> What sort of wire? A telegram? Countries are starting to deprecate them now. [11:35:49 CET] <stevenliu> timezone? Now here is 18:35:00 :D [11:38:42 CET] <cmeister2> (trying to generate some appropriate video input right now) [11:39:05 CET] <kurosu> jdarnley_obs: I here cloud is the new fad, so smoke signalling is probably what he needs [11:43:34 CET] <stevenliu> Stream #0:0(und): Video: mjpeg (mp4v / 0x7634706D), yuvj422p(pc, bt470bg/unknown/unknown), 1920x1080, 64007 kb/s, 30.61 fps, 29.92 tbr, 1000k tbn, 1000k tbc (default) [11:43:45 CET] <stevenliu> the video codec is mjpeg, not H.264 [11:45:45 CET] <JEEB> apparently there's some awful stuff that packs h.264 frames into mjpeg like stream, although I find that rather head-scratching :p [11:46:25 CET] <cmeister2> i believe it's Logitech and maybe some capture cards that do similar things [11:47:21 CET] <cmeister2> don't ask me why. they used to expose native H.264 video, but then in a revision of the camera apparently they started doing this weirdness [11:49:37 CET] <stevenliu> Wow, 3D printer :D [11:49:45 CET] <cmeister2> :) [11:56:56 CET] <durandal_1707> tried radare2 with this braw program and it failed again, r2 is far from complete [12:07:13 CET] <JEEB> durandal_1707: radare2 has unfortunately not had enough people bringing it to stability or features. classic open source problem when you're niche [12:07:42 CET] <JEEB> and many people stop when they just notice it's broken for something they need (or crashes) [12:07:58 CET] <JEEB> granted, until NSA's thing came along it was the only thing in open source for that :P [12:12:28 CET] <durandal_1707> it there free download of 64bit windows? XP or Vista? [12:12:58 CET] <JEEB> only 10 is officially freely avilable if you use a lunix UA [12:13:09 CET] <JEEB> (otherwise it tries to feed you a downloader exe) [12:13:24 CET] <JEEB> XP, vista, 7, 8.x all needed unofficial links to possibly official CDNs [12:13:30 CET] <JEEB> digitalriver or whatever it was [12:14:04 CET] <JEEB> (in other words, if you google for digitalriver windows VERSION (usually 7) you'd get results) [12:14:11 CET] <JEEB> also there are windows VMs available from MS I think [12:14:14 CET] <JEEB> those might still include 7 [12:16:06 CET] <durandal_1707> preferably torrent? [12:16:16 CET] <durandal_1707> this it GB download [12:16:36 CET] <JEEB> no official torrents and HTTPS has worked well so far from official CDNs [12:16:41 CET] <durandal_1707> braw player is 64bit app, while i have only 32 bit VM vista [12:17:03 CET] <durandal_1707> windows 7, or whatever it was called [12:17:31 CET] <JEEB> check https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ [12:17:37 CET] <JEEB> they're officially for web testing [12:17:40 CET] <JEEB> but I think they might not be that limited [12:18:49 CET] <JEEB> oh, they're al 32bit :< [12:18:52 CET] <JEEB> fug that [12:19:03 CET] <JEEB> only the win10 one is 64bit [12:19:57 CET] <JEEB> durandal_1707: if you search for "microsoft digitalriver windows 7" you'll probably find the 64bit iso :P [12:20:21 CET] <JEEB> if you don't want the win10 one [12:22:18 CET] <durandal_1707> but download is big and they never provide direct links [12:22:33 CET] <durandal_1707> and i'm not on fiber [12:22:44 CET] <JEEB> I don't see how that makes any difference between p2p and non-p2p [12:22:54 CET] <JEEB> and you do get a link there, no? [12:23:09 CET] <durandal_1707> if connection breaks, i need to start over from 0 [12:23:10 CET] <JEEB> anyways, if you want to make it harder for yourself - check MSDN checksums and search for them [12:23:24 CET] <JEEB> for the images you need that is [12:23:32 CET] <JEEB> the MSDN checksums at least used to be freely available [12:34:39 CET] <Illya> j-b: will you send a mail about next monday? I think that would be best to make sure everyone is informed [12:35:19 CET] <durandal_1707> who is "everyone" ? [12:35:48 CET] <JEEB> "the mailing list" [12:35:53 CET] <JEEB> I would guesstimate [12:36:01 CET] <Illya> everyone who needs to be informed, sending a mail to the list should catch that group [12:38:39 CET] <Illya> And if you to be more specific: the general assembly, and anyone else who is interested to listen/contribute [12:51:09 CET] <durandal_1707> JEEB: radare2 have bunch of nice features but its is very buggy at same time [12:51:51 CET] <JEEB> durandal_1707: yes. [20:18:10 CET] <kierank> durandal_1707: i can download and send you by post [20:44:38 CET] <cone-121> ffmpeg 03Andreas Rheinhardt 07master:296f769fdca5: avformat/rmdec: Use av_packet_move_ref() for packet ownership transfer [20:44:38 CET] <cone-121> ffmpeg 03Limin Wang 07master:0485033ae1dd: avfilter/vf_elbg: Fix for the seed type [20:44:39 CET] <cone-121> ffmpeg 03hwren 07master:3003917a8fe0: lavc/libxavs2.c: use more descriptive variable names in xavs2_copy_frame* functions [20:44:40 CET] <cone-121> ffmpeg 03hwren 07master:6721cd942ad6: lavc/libxavs2.c: avoid recomputations of pointers in xavs2_copy_frame* functions [20:44:41 CET] <cone-121> ffmpeg 03hwren 07master:191203aa1fe1: lavc/libxavs2.c: fix code style - spaces [20:44:42 CET] <cone-121> ffmpeg 03hwren 07master:0bafcc987458: lavc/libxavs2.c: optimize error descriptions [20:51:44 CET] <durandal_1707> kierank: what? [20:51:59 CET] <kierank> if you need big file download [22:10:55 CET] <BBB> [hls @ 0x7fe885800600] pkt->duration = 0, maybe the hls segment duration will not precise, is there a ffmpeg flag to generate duration if it's not set by default in encoder/muxer? [22:12:46 CET] <JEEB> not that I know, movenc tries to check if the muxer has the next packet already fed to it, I think? [22:13:00 CET] <JEEB> but that's something that every muxer would have to attempt to do, which is a bit sub-optimal I guess [22:13:59 CET] <JEEB> ff_interleaved_peek [22:14:14 CET] <JEEB> seems to be what movenc is utilizing when flushing fragments [22:14:57 CET] <JEEB> I think better option would be to have the encoder modules and such actually set the duration field in AVPackets [22:16:04 CET] <Lynne> BBB: hlsenc generates the duration just after printing the warning [22:19:15 CET] <BBB> oh ok [22:24:11 CET] <JEEB> it doesn't appear to utilize peeking, so what this looks like it's just setting it to the pkt->pts - previous_end [22:24:28 CET] <JEEB> vs->duration = (double)(pkt->pts - vs->end_pts) * st->time_base.num / st->time_base.den; [22:26:21 CET] <Lynne> muxing/demuxing vfr hls would require some high level divine luck [22:27:21 CET] <JEEB> sure, and generally the heaviest case is the end of clip [22:27:41 CET] <JEEB> since while you can assume that frame was supposed to shown at the frame rate, but that can depend [22:30:08 CET] <Lynne> that said, there's a high chance some chinese ip camera manufacturer does it anyway [00:00:00 CET] --- Thu Dec 5 2019

1 0

ffmpeg.log.20191204
by burek 05 Dec '19

05 Dec '19

[00:15:35 CET] <rafael2k> cehoyos: errr, because AOT 42 is USAC? [00:15:57 CET] <rafael2k> cehoyos: and in the description of the stream says "xHE-AAC" [00:16:25 CET] <rafael2k> cehoyos: and I see DTV here in Brazil for ages, and the mux is LATM? [00:16:30 CET] <rafael2k> :P [00:21:02 CET] <rafael2k> ffmpeg does have a latm parser. [00:27:50 CET] <cehoyos> Yes, in the FFmpeg-sense, it has a "latm parser", but it does not contain the necessary parser ("bitstream filter") to convert latm into aac [00:28:12 CET] <cehoyos> (Current bitstream filters do not allow to change codec iirc) [00:29:34 CET] <rafael2k> right, I'll investigate a bit more, but here is the xHE-AAC sample, anyway: [00:29:44 CET] <rafael2k> wget http://stream.radioh.no:443/rh.x16 [00:36:07 CET] <cehoyos> Yes, you posted it already (thank you!) [00:38:31 CET] <rafael2k> I was just confirming it is indeed a USAC sample, after you questioned if it really was it... tks. [00:41:45 CET] <cehoyos> How were you able to confirm? [00:41:55 CET] <cehoyos> (Is there software that allows decoding?) [00:48:32 CET] <JEEB> cehoyos: fdk-aac's 2018 v2.x release apparently does xhe-aac? [00:50:31 CET] <cehoyos> Indeed, I have libfdk 1,6 installed [00:53:25 CET] <JEEB> libMpegTPDec/src/tpdec_asc.cpp apparently mentions it a lot? [00:54:24 CET] <JEEB> git grep -i "usac" gave possibly a bit better results :) [00:54:43 CET] Action: JEEB goes hit the sack [01:03:26 CET] <rafael2k> JEEB: ; )) [01:03:47 CET] <rafael2k> cehoyos: ffmpeg latm aac decoder can read the AOT... [01:04:17 CET] <cehoyos> It fails here for the sample [01:04:35 CET] <rafael2k> it fails as it does not implement USAC [01:04:52 CET] <cehoyos> Yes. [01:04:58 CET] <cehoyos> What were you trying to say before? [01:06:54 CET] <rafael2k> If I could decode it I was not asking here [01:07:33 CET] <rafael2k> I have fdk-aac v2 here [01:07:49 CET] <rafael2k> yes, it should support xHE-AAC... the library [01:09:19 CET] <rafael2k> <cehoyos> (Is there software that allows decoding?) [01:10:04 CET] <rafael2k> cehoyos: Yes, I use Fraunhofer Multimedia Player, but it is not free software. [01:10:35 CET] <cehoyos> The library may support it but as I explained before, FFmpeg does not contain the necessary bitstream filter ("parser") afaict. [01:10:50 CET] <rafael2k> I understand now, tks cehoyos, and sorry to bother [01:10:53 CET] <cehoyos> Unless the library accepts latm which I cannot test because I don't have v2 here. [01:11:17 CET] <cehoyos> Where can I find the Fraunhofer Multimedia Player? [01:12:24 CET] <rafael2k> it is not free... [01:12:43 CET] <cehoyos> That means I cannot find it? [01:15:02 CET] <rafael2k> I'm not stopping you from nothing [12:43:36 CET] <Ducky^> ffmpeg -y -i WAVs/DDC-Logo_f_DCDM_1-0.wav -i WAVs/DDC-Logo_f_DCDM_2-0.wav -i WAVs/DDC-Logo_f_DCDM_3-0.wav -i WAVs/DDC-Logo_f_DCDM_4-0.wav -i WAVs/DDC-Logo_f_DCDM_5-0.wav -i WAVs/DDC-Logo_f_DCDM_6-0.wav -filter_complex [12:43:37 CET] <Ducky^> "[0:a]apad=whole_dur=3600[merge];[1:a]apad=whole_dur=3600[merge];[2:a]apad=whole_dur=3600[merge];[3:a]apad=whole_dur=3600[merge];[4:a]apad=whole_dur=3600[merge];[5:a]apad=whole_dur=3600[merge];[merge]amerge=inputs=6[out]" -map "[out]" -c:a pcm_s16le -ar 48000 -rf64 auto -t 3600 5.1_Test.wav [12:43:47 CET] <Ducky^> with this command I get the error Cannot find a matching stream for unlabeled input pad 1 on filter Parsed_amerge_6 [12:44:13 CET] <Ducky^> does anyone know where the command is tripping up? [12:45:03 CET] <durandal_1707> Ducky^: because you use output pad merge several times [12:45:35 CET] <durandal_1707> [a][b][c]..amerge[out] [12:45:41 CET] <durandal_1707> is proper way [12:45:51 CET] <Ducky^> ahh, I see [12:45:55 CET] <Ducky^> thanks durandal_1707 I'll try it [12:48:15 CET] <Ducky^> it worked! [12:57:43 CET] <Ducky^> simplified it a little by only having apad instead of the whole_dur part [16:18:26 CET] <PeRy_SoY> Hello! I have tvheadend server and ffmpeg to stream my local videos and works really nice but i cant forward or rewind videos, my ffmpeg: < pipe://ffmpeg -loglevel fatal -i /home/pery/Escritorio/WindowsShare/it2.mkv -g 250 -vcodec copy -acodec copy -metadata service_provider="provider" -metadata service_name=" Name" -f mpegts -tune zerolatency pipe:1 > any suggest? thanks in advance and sorry for my english ! [16:18:59 CET] <pink_mist> you're using pipes [16:19:15 CET] <pink_mist> pipes don't support rewinding [16:19:42 CET] <PeRy_SoY> oh! :( [16:19:46 CET] <PeRy_SoY> thanks :) [16:22:01 CET] <ButtDog> Is it possible to obtain video duration, bitrate, etc in the browser front end, from a file input without actually uploading the video? [16:45:53 CET] <another> you could write something in js that does that [17:09:57 CET] <ButtDog> another: I found something actually. Looking at implementing it: https://mediaarea.net/en/MediaInfo/Download/JavaScript [17:10:03 CET] <ButtDog> Not sure if there's a more simple way [18:05:47 CET] <capin> does ffmpeg support providing an input file for peformming a series of `-t` `-ss` operations on a media file? [18:08:27 CET] <kepstin> capin: the "concat" demuxer: https://ffmpeg.org/ffmpeg-formats.html#concat takes a playlist file as input, which can specify "inpoint" and "outpoint", but note that as this is the demuxer level, it can only start at keyframes (no accurate seek) [18:11:32 CET] <capin> kepstin: was looking for something like this, https://gist.github.com/georgechalhoub/e9c1c50507f651c8af90c5f40e8376c7#fil… [18:13:02 CET] <kepstin> not sure what your final goal is, but it seems you already have a working solution? [18:14:32 CET] <kepstin> if you plan to concatenate all those pieces after splitting them, then you could certainly do it all in one ffmpeg command (build the command line with a script) [18:14:33 CET] <capin> trying to edit an input file using the `-ss` and `t` flags to remove the segments of input file i'd like to keep and then later produce a single file from the segments [18:15:37 CET] <capin> and was wondering if ffmpeg provides a option for supplying an input file to the `-ss` and `t` flags, so i don't end up with some super gnarly command line command [18:16:09 CET] <kepstin> it doesn't really make sense, since you have to specify the input file multiple times anyways, and those options are separate per input [18:16:39 CET] <capin> it'd be a lot easier to edit an input file rather than having to navigate the cmd line to edit the `-ss` and `-t` flags for where i want trim the input file [18:16:45 CET] <kepstin> the concat demuxer that I already told you about would work, but it would have the same issue as your current script, which is that your seek points are rounded to the nearest keyframe [18:18:07 CET] <kepstin> I'd actually suggest using a -filter_complex_script option, use a "movie" source filter for each input segment, and then the concat filter to combine them. [18:18:25 CET] <kepstin> but that would still be sufficiently complicated that it would be best to generate with a script [18:20:01 CET] <capin> are there any GUIs / frontends for ffmpeg that could provide such editing that i seek, (no pun there) [18:22:16 CET] <kepstin> you probably should just go straight to using a proper NLE. Maybe kdenlive or something? [18:30:58 CET] <capin> kdenlive = total PITA on macOS just to get setup [18:31:18 CET] <capin> i'll just end up cobbling together a py or shell script [18:31:39 CET] <kepstin> well, on mac os there's lots of well known native video editing applications... [18:31:46 CET] <capin> and i use shotcut for NLE [18:32:03 CET] <kepstin> like you could probably just straight up use imovie [18:35:01 CET] <kepstin> the ffmpeg cli is a multipurpose tool that can do many things, but it's not necessarily the easiest or best tool for any specific job. It can certainly do this, but writing a script to generate the filter chain and cli options would be a good idea. [18:38:21 CET] <capin> yeah the issue with using apps such as `imovie` or most other NLA editors is they reencode the input stream after editing, and i'm specifically trying to avoid reencoding the input stream thus why i'm relying on using ffmpeg [18:38:47 CET] <kepstin> the issue with not re-encoding is that your seek points will not be exactly where you want them [18:38:53 CET] <kepstin> since it can only start at keyframes [18:39:12 CET] <kepstin> (how far off they will be depends on the settings the source file was encoded with) [18:43:34 CET] <kepstin> if you're sure you don't want to re-encode, my initial suggestion of using the concat demuxer's playlist format is probably the simplest way forwards [20:54:48 CET] <void09> any flags i can pass to ffmpeg so that it writes proper mkv metadata readable by mediainfo ? for example i am getting no audio info from mediainfo after writing an mkv with ffmpeg [21:02:09 CET] <pbd> Is anyone able to stream live webm with ffmpeg 4.1 and 4.2? It looks like the EBML header is kinda broken. [21:03:24 CET] <JEEB> void09: you can forcibly write that metadata field but the general problem is that mediainfo does not want to calculate that value by itself :P [21:03:51 CET] <void09> reading a value is simpler than calculating it :P [21:04:07 CET] <JEEB> sure, but mediainfo is already parsing the matroska file [21:05:00 CET] <JEEB> pbd: there have been improvements to the matroska muxer recently, so I'd check with master. if master is still broken, report the issue on trac.ffmpeg.org , and if not then there's just some fixes not applied onto the "stable" branches [21:05:44 CET] <JEEB> void09: the problem with metadata fields that are metadata is that they get copied by many tools without a further thought even if stuff gets re-encoded :P [21:06:05 CET] <JEEB> but hey, you can get your "this is totally 32kbps" or "this is totally 1280kbps" [21:06:32 CET] <void09> ok, any flag for ffmpeg to automagically write everything ? [21:08:52 CET] <JEEB> there is no automatic thing since they are not standardized? [21:09:17 CET] <pbd> JEEB: yes, master is still broken. [21:09:27 CET] <JEEB> pbd: cool. feel free to report it then [21:09:37 CET] <JEEB> and if possible, with how to replicate it [21:09:48 CET] <JEEB> example command line with ffmpeg.c etc, if possible [21:10:13 CET] <pbd> JEEB: yes, I had already planned to open a ticket but it was very complicated to get into the trac. [21:10:36 CET] <pbd> First, it says that I am a spammer based on shitty blacklists, then I was only able to get the verification mail yesterday. [21:10:40 CET] <pbd> That was quite annoying. [21:10:42 CET] <JEEB> ouch [21:10:57 CET] <pbd> And the worst was to complete a google captcha. [21:11:16 CET] <JEEB> but I must guess the person who set that up had the best intentions in mind [21:11:24 CET] <JEEB> just that it unfortunately hit you [21:11:46 CET] <pbd> yes usually they have good intentions but people should be aware of the consequences of creating a relliance on third parties. [21:12:18 CET] <JEEB> funny enough I do remember configuring some systems myself back a few years ago [21:12:36 CET] <JEEB> and then there was some standard captcha thing [21:12:51 CET] <JEEB> and yea, that let a lot of stuff through :/ [21:13:02 CET] <JEEB> I think the best stopper were custom questions [21:13:26 CET] <JEEB> which someone having the in-theme knowledge would be able to complete [21:13:40 CET] <pbd> When it's on the trac, it's not too bad because you are told what the problem is, but when it's used on mail servers that's awful. [21:13:52 CET] <pbd> It allows some shady organizations to blackmail ISP. [21:14:12 CET] <pbd> So whenever I see this I get frustrated. [21:14:49 CET] <JEEB> but yea, I think I was able to come up with like two or three questions when I was maintaining the thing I used to maintain [21:15:08 CET] <JEEB> and some spam did still come through, but at least the numbers went a bit down [21:15:33 CET] <JEEB> so I can see why going for the google recaptcha seemed like a GoodIdea [21:15:53 CET] <JEEB> anyways, not even sure who maintains the trac at this point :/ [21:35:44 CET] <pbd> JEEB: it would be best to have some bayes, because if the spam still comes through it probably mean that it's not fully automated. [21:54:12 CET] <JEEB> &30 [22:57:18 CET] <ncouloute> I'm trying to concatenate some video files from a Drone together and I'm getting this error message: h264_mp4toannexb filter failed to receive output packet on the stitch of Clip12+Clip13. Is there a way around this? Apparently it used to work a long time ago. As I was able to concat with a old version of ffmpeg from 2013. [00:00:00 CET] --- Thu Dec 5 2019

1 0

ffmpeg-devel.log.20191203
by burek 04 Dec '19

04 Dec '19

[00:02:08 CET] <BenLubar> is there some kind of skeleton demuxer/decoder or am I better off grabbing one of the simple ones and dissecting it? [00:05:55 CET] <JEEB> since I don't see ffmpeg.org results on DDG, I think while there have been some changes regarding registration of formats, this probably is a pretty good overview https://wiki.libav.org/Internals/DemuxerHowTo [00:06:44 CET] <BenLubar> thanks [00:09:10 CET] <JEEB> the registration is now handled by the addition of the thing to libavformat/allformats.c it seems [00:09:18 CET] <JEEB> makefile changes are still needed, of course [00:11:04 CET] <JEEB> while the read_header is awfully long, libavformat/yuv4mpegdec.c might be OK to look at? [00:11:18 CET] <JEEB> since it is a relatively simple raw video container and thus doesn't really have much in there [00:11:55 CET] <JEEB> basically you implement the callbacks you require [01:41:58 CET] <cone-533> ffmpeg 03Ross Nicholson 07release/4.2:289838b7bd20: libavformat/rtsp: return error if rtsp_hd_out is null instead of crash [05:53:56 CET] <BenLubar> I don't know the correct terminology for this, but CMV has an 8 bit index into a texture map and 4+3 bits of color information per pixel. Is there anything in ffmpeg that decodes more than one "pixel per pixel"? [07:21:08 CET] <BenLubar> alright, I figured out what seems to be a pretty good way to do it. not sure how to do audio properly, but there are only two cmv files in existence with audio as far as I know [07:58:43 CET] <thardin> "Byte X+(Columns*Y). An index into IBM PC Code Page 437" wut [07:59:22 CET] <thardin> this sounds like the format used in that ibm 5050 demo [07:59:55 CET] <thardin> https://wiki.multimedia.cx/index.php?title=CMV this is also funny [08:00:02 CET] <thardin> MJPEG, but worse [08:06:34 CET] <thardin> 8088 corruption [08:27:26 CET] <thardin> oh they left [09:29:17 CET] <cehoyos> I am currently working on a new presentation for the archivists conference in Budapest this week. If anybody has ideas about what to include in the presentation, please say so here and forward the question to Paul! I have to go now but will leave the irc window open, thank you! [09:55:55 CET] <cone-539> ffmpeg 03Andreas Rheinhardt 07master:710ab136931f: avfilter/vf_unsharp: Don't dereference NULL [09:55:55 CET] <cone-539> ffmpeg 03Linjie Fu 07master:8fc8bdddbf73: libavformat/utils: Fix code indentation [09:55:55 CET] <cone-539> ffmpeg 03Guo, Yejun 07master:b864af033d41: MAINTAINERS: add myself to libavfilter/dnn [11:10:13 CET] <cone-539> ffmpeg 03Marton Balint 07master:f5b83d5419a3: avformat/mpegtsenc: allow any sensible PID for elementary and PMT PIDs [11:10:14 CET] <cone-539> ffmpeg 03Marton Balint 07master:565dc3e451c7: avformat/mpegtsenc: set priority flag for AC3 codecs if writing BluRay [11:10:15 CET] <cone-539> ffmpeg 03Marton Balint 07master:db63db3977bb: avformat/mpegtsenc: move around setting m2ts_mode [11:10:16 CET] <cone-539> ffmpeg 03Marton Balint 07master:998906a0a408: avformat/mpegtsenc: factorize writing packet [11:10:17 CET] <cone-539> ffmpeg 03Marton Balint 07master:1e0ea369456b: avformat/mpegtsenc: add padding to m2ts streams [12:43:10 CET] <cehoyos> durandal_1707: I am currently working on a new presentation for the archivists conference in Budapest this week. If anybody has ideas about what to include in the presentation, please say so here [12:45:19 CET] <durandal_1707> cehoyos: cfhd [12:59:30 CET] <cehoyos> I will mention it but better would be developments that happened in the last two years [13:04:40 CET] <JEEB> the last time I had looked into what archivists wnated it was mostly lossless + checksums [13:04:51 CET] <JEEB> most likely not the only thing, but a theme at least [13:05:10 CET] <JEEB> (which is why they're standardizing matroska+ffv1 for that apparently) [13:20:09 CET] <cehoyos> The goal is not to tell the archivists what they want to hear but what we developed over the last two years. [13:21:00 CET] <JEEB> sure [13:21:20 CET] <JEEB> I was mostly thinking in the sense of what their interest areas would be :P [13:21:52 CET] <cehoyos> So basically what was developed since 3.4 was released [13:22:43 CET] <cehoyos> 50% of those attending use FFmpeg because of FFv1, 50% don't know what FFmpeg is, so my goal is to explain to all 100% why they need FFmpeg independently of FFv1 [17:49:25 CET] <cone-669> ffmpeg 03Michael Niedermayer 07master:3ae87bb3c1cb: tools/target_dec_fuzzer: Support fuzzing error detection [17:49:25 CET] <cone-669> ffmpeg 03Michael Niedermayer 07master:5ac8675cb1a4: tools/target_dec_fuzzer: Support setting AV_CODEC_FLAG2_FAST [19:42:40 CET] <cehoyos> kierank: I believe you should tell us what (and who) you would like to hear... [19:46:03 CET] <kierank> cehoyos: well as I mentioned at vdd they are scared of us [19:50:51 CET] <cehoyos> Fosdem... [19:51:28 CET] <cehoyos> (As said, I claim to know the archivists as good as you, I am just curious if anybody wants me to talk about something he - the FFmpeg developer - thinks is important) [19:53:03 CET] <cehoyos> (As said, I claim to know the archivists as good as you, I am just curious if anybody wants me to talk to the archivists about something he - the FFmpeg developer - thinks is important) [19:55:27 CET] <kierank> Ok [19:58:56 CET] <cehoyos> kierank: I believe you should tell us what (and who) you would like to hear at fosdem [19:59:25 CET] <kierank> Anyone and their project [21:14:25 CET] <cone-253> ffmpeg 03Kusanagi Kouichi 07master:12bbfc4ccaa1: avdevice/xcbgrab: Handle reply and error properly [22:32:35 CET] <BenLubar> I'm not sure how to implement the audio for https://patchwork.ffmpeg.org/patch/16572/ - can a container format tell ffmpeg to pull in a different file at a specific timestamp? [22:40:47 CET] <cehoyos> BenLubar: It may be better to start with video only. [22:40:52 CET] <cehoyos> The demuxer file is missing a license header [00:00:00 CET] --- Wed Dec 4 2019

1 0

ffmpeg.log.20191203
by burek 04 Dec '19

04 Dec '19

[00:33:55 CET] <analogical> can some ffmpeg ninja please extract the video stream from this site? http://ustvgo.tv/cnn-live-streaming-free/ [00:41:07 CET] <BtbN> extracting video from websites is not something ffmpeg does. [00:50:11 CET] <analogical> BtbN, wut? [00:50:21 CET] <analogical> I've done that many times [00:50:38 CET] <BtbN> very unlikely. You probably used youtube-dl or something the like. [00:50:43 CET] <BtbN> ffmpeg does not parse html [03:59:51 CET] <pbd> Hi [04:00:02 CET] <pbd> I believe the mail server for the trac is not working. [04:00:11 CET] <pbd> First I'm being told that I'm a spammer.. [04:00:27 CET] <pbd> Then I have the worst of the captchas. [04:00:30 CET] <pbd> And then no email. [04:43:55 CET] <void09> any way to make ffmpeg extract all srt subs from an mkv ? i got one with 25 subtitles [04:54:32 CET] <void09> https://gist.github.com/abjdiat/6383447 [04:54:36 CET] <void09> something like this, but it does not work [06:22:20 CET] <void09> found one [06:22:40 CET] <void09> h264_metadata=delete_filler=1 - is there a h265 equivalent to this, or h265 does not have filler ? [07:03:49 CET] <void09> got this ts file, trying to mkv it: ffmpeg -i "input.ts" -vcodec copy -acodec copy outputvideo.mkv [07:04:02 CET] <void09> Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly [07:04:02 CET] <void09> [matroska @ 0x55f747a51440] Can't write packet with unknown timestamp [07:04:02 CET] <void09> av_interleaved_write_frame(): Invalid argument [07:04:17 CET] <void09> mkvtoolnix has no issues with it though. any params i can try to fix this situation? [07:10:54 CET] <void09> just found hte -fflags +genpts advice and that does not fix it, same error [08:18:45 CET] <Fyr> guys, is there a script for Windows to create a slideshow with transitions? [08:19:02 CET] <Fyr> if it's a simple bash script, it's alright, I have busybox. [08:41:22 CET] <void09> Fyr: i usually search github with those keywords when i need stuff like that [08:41:31 CET] <void09> ffmpeg slideshow [11:40:42 CET] <lofo> I'm not sure how output formats and networking protocols play out together [11:41:32 CET] <lofo> i'm trying to stream with tcp://, i managed to make it work with -f mpegts but not mp4 [11:42:26 CET] <lofo> flv works too [11:42:47 CET] <pink_mist> yeah, mp4 isn't made for streaming [11:42:53 CET] <pink_mist> trying it is going to be painful [11:43:23 CET] <JEEB> fragmented mp4 will work [11:43:38 CET] <JEEB> TheAMM even made it work with a <video> tag apparently [11:43:41 CET] <JEEB> which was a pleasant surprise [11:44:20 CET] <TheAMM> "Made" as in set the flags and yolod stdout directly at a browser [11:45:40 CET] <lofo> if there some source of information that says what format work with what protocol ? Because iwould like to try out many different combinations [18:14:09 CET] <void09> is there any flags I can use to make sure the resulting mkv file has readable bitrate tag? [18:14:18 CET] <void09> or whatever mediainfo uses to get the bitrate info [18:32:20 CET] <Ducky^> I'm using a command, something like this: [18:32:24 CET] <Ducky^> ffmpeg -y -i WAVs/1.wav -i WAVs/2.wav -i WAVs/3.wav -i WAVs/4.wav -i WAVs/5.wav -i WAVs/6.wav -filter_complex amerge=inputs=6,apad=whole_dur=3600 -c:a pcm_s16le -ar 48000 -rf64 auto -t 3600 6chantest.wav [18:32:43 CET] <Ducky^> one of the input wav files is longer than the other, but I'd like the output audio to be of fixed length [18:32:57 CET] <Ducky^> the problem is that the longer file is cut short to the shortest file [18:33:08 CET] <Ducky^> but all files are padded with silence as expected, up to one hour of audio [18:33:28 CET] <Ducky^> I'd like the longer file to continue while the shorter files are padded, then the longer file padded once it reaches the end [18:33:34 CET] <Ducky^> is that possible with ffmpeg? [18:38:43 CET] <kepstin> Ducky^: sure, you would want to use an apad filter on the shorter inputs to add silence to the end. [18:40:09 CET] <kepstin> actually, what i'd do is attach an apad filter to each input before feeding to the amerge filter, then you don't need an apad afterwards, and the -t option would set the final duration. [18:59:35 CET] <matto312> I have question. (I'm new to video but an experienced dev) Using ffmpeg, when my input has FPS = 29.97 and I specify 30 FPS output (using -r 30) ... My question is ... is that bad? What are the implications of doing this? Thanks! [19:01:36 CET] <DHE> depends how you do it. either you'll skew the speed of the video, or ffmpeg will duplicate frames [19:02:09 CET] <c_14> using -r as an output option should duplicate frames [19:04:45 CET] <matto312> Is duplicating frames ok? To me it feels sloppy, but I don't know video stuff well enough [19:05:27 CET] <c_14> it's essentially the same thing your video player does when video fps != display fps [19:05:51 CET] <matto312> Gotcha, thx c_14 [19:06:55 CET] <c_14> it can cause some jankiness because you'll be artificially elongating the lengths of certain "frames" [19:07:34 CET] <c_14> and if you change a video from 29.97 to 30fps and then play that on a display with 59.94 Hz you can end up dropping frames [19:08:11 CET] <c_14> read: It's usually best not to mess with fps except in specific circumstances, but it's not going to break anything in most cases [19:08:40 CET] <matto312> c_14 ... thank you, this is really helpful [19:09:15 CET] <matto312> going to see if I can just pass thru ffmpeg whatever frame rate the input is [19:09:50 CET] <c_14> if you don't explicitly set the framerate, ffmpeg won't change it [19:15:42 CET] <bvarg0> What does "[mp3float @ 0x55e4f8bc1540] overread, skip -7 enddists: -4 -4" mean? Is it a problem? Is it fixable? [19:35:45 CET] <cehoyos> bvarg0: It indicates that your mp3 stream is broken [19:36:45 CET] <cehoyos> matto312: Note that most likely the frame rate of your input stream is not 29.97 but 30000/1001 [19:36:48 CET] <bvarg0> so if the .opus sounds ok, then don't worry about it? I get a running stream of these errors. [19:37:09 CET] <cehoyos> For best results, FFmpeg with the setpts filter allows you to change the video speed (to 30 fps) [19:37:29 CET] <bvarg0> 30000/1001 = 29.97002997 [19:37:32 CET] <bvarg0> ? [19:37:52 CET] <cehoyos> Which is != 29.97 [19:38:24 CET] <bvarg0> ok, so there's no video here. [19:38:26 CET] <cehoyos> If your input is a file, provide it, if it is a stream, record it [19:38:29 CET] <bvarg0> does that make a difference? [19:38:39 CET] <cehoyos> I wrote "matto312:" to indicate that this information is not meant for you [19:38:54 CET] <bvarg0> shit, sorry [19:39:39 CET] <cehoyos> Note that recording can be difficult with FFmpeg, mplayer -dumpstream is an alternative [19:41:40 CET] <bvarg0> ok, well, i don't know what results from a broken mp3 stream but the output file is intelligable so i suppose it doesn't matter. [19:41:47 CET] <bvarg0> is there anyway to put a : in [19:41:51 CET] <cehoyos> If your input is a file, provide it, if it is a stream, record it [19:41:53 CET] <bvarg0> the output file name? [19:42:01 CET] <cehoyos> Use file: [19:51:04 CET] <matto312> ceyhoyos: thx for info ... I'm working with live RTMP input and output is HLS (which is being uploaded to CDN) [19:52:21 CET] <cehoyos> Then there is no good solution if your input is 30000/1001 and you have to provide 30fps [19:52:44 CET] <cehoyos> For endless input [19:54:10 CET] <matto312> cehoyos: so for endless input, going from 30000/1001 to 30 fps ... going to end up with some choppyness? [19:57:46 CET] <kepstin> yeah, there's basically gonna be a momentary stutter from a duplicated frame every ~1000 frames (so about 33 seconds at 30fps), which is just enough to annoy people who notice it. [19:58:28 CET] <cehoyos> Unless you use the framerate filter that interpolates and takes a lot of cpu power, likely not being real-time for many resolutions [19:59:15 CET] <kepstin> (if you play a 30000/1001 video on a 60fps screen it's not *as* noticable, because the player can insert a half-frame delay every ~500 frames instead) [19:59:32 CET] <matto312> Thx, this info is super helpful [20:02:30 CET] <kepstin> but yeah - in general with video for computer playback, you should send the video with the framerate as-is, and let the remote player time the frames as best as possible given its local monitor refresh rate. [20:02:51 CET] <kepstin> for *non* computer video, it's a different story :) [20:03:35 CET] <matto312> I have another general question that prob will make me sound dumb. [20:03:35 CET] <matto312> Like I mentioned before, I have live RTMP input and I'm using FFMPEG to output HLS. [20:03:35 CET] <matto312> Most of the time this works fine. However, occasionally (like 1 out 10 times) FFMPEG appears to have issues with the input. [20:03:35 CET] <matto312> I'll see flood of messages like "st:1 invalid dropping" and the output doesn't work. It feels like randomly FFMPEG will encounter issues with the RTMP input. [20:03:36 CET] <matto312> How would you approach an issue like this? Do you think this is an issue with the input or is it something I am doing wrong with FFMPEG. [20:04:00 CET] <matto312> Oops, sorry about the flood of messages [20:08:27 CET] <cehoyos> First step is to test current FFmpeg git head and provide (pastebin) the (simplified) command line including the complete, uncut console output [20:08:52 CET] <cehoyos> Simplified means here that if you don't have a problem with the hls output, file output will make the console paste much more readable [20:09:55 CET] <matto312> cehoyos thx, I'm on it [20:09:57 CET] <cehoyos> In the specific case of rtmp input you can test if the native or the librtmp input work better [20:17:32 CET] <Polochon_street> does anyone have any idea why the given command makes any `ffplay stream` have this garbage output when trying to play it back? https://paste.isomorphis.me/MWK [20:17:58 CET] <Polochon_street> after waiting 10/15 seconds it eventually picks up the stream and plays it, but it's rather annoying not to know if I did something bad anywhere to have this output [20:21:00 CET] <cehoyos> Note that here, only complete, uncut console output is supported, no excerpts. That being said, it is normal for transport streams to take a few seconds until reception is ok (this is true for all players, some make a lot of effort to hide the beginning from you) [20:21:18 CET] <Polochon_street> oh, mb [20:22:01 CET] <Polochon_street> https://paste.isomorphis.me/nJZ something like this? [20:22:29 CET] <cehoyos> Unrelated: Putting the encoder first and the filter afterwards imo makes the command line more difficult to read, that may only be me though... [20:22:52 CET] <cehoyos> LOL, no ;-) [20:23:56 CET] <Polochon_street> more sth like this? https://paste.isomorphis.me/PPy [20:24:22 CET] <Polochon_street> I'm asking because I'm trying to get this stream picked up by the hw decoder of my raspberry pi, that decodes h264 via hardware, and it just hangs forever [20:27:13 CET] <Polochon_street> erf, my laptop kind of died right now [20:27:33 CET] <Polochon_street> anyways, I was just wondering, maybe I'm not generating a valid h264 stream, or something like this? [20:28:47 CET] <furq> Polochon_street: the rpi hwdec only supports yuv420p [20:28:51 CET] <furq> same for most h264 hwdec [20:29:44 CET] <Polochon_street> oh, so *I am* doing something wrong [20:29:59 CET] <cehoyos> Add -pix_fmt yuv420p [20:30:16 CET] <furq> in place of -pix_fmt rgb565le obviously [20:30:42 CET] <furq> also for future reference you need to use libx264rgb if you actually want rgb output [20:32:29 CET] <Polochon_street> damn, it worked like a charm [20:32:36 CET] <Polochon_street> there's still some weird big pixels some places though [20:33:33 CET] <furq> yeah that filter isn't going to look good in yuv420p [20:34:33 CET] <Polochon_street> why not? [20:35:15 CET] <furq> because it's all 1px thick coloured lines and dots on a black background [20:36:20 CET] <Polochon_street> do you have any lead on how I could improve that? [20:36:26 CET] <Polochon_street> would you* [20:38:33 CET] <furq> avectorscope=rc=255:gc=255:bc=255:rf=25:gf=25:bf=25 [20:38:44 CET] <furq> or whatever monochrome values you want [20:40:13 CET] <Polochon_street> it's not perfect, but it helped a lot, thanks :) [20:40:36 CET] <furq> you probably also want -crf 18 or something [20:40:45 CET] <furq> lower values = higher quality [20:41:55 CET] <Polochon_street> even better [20:42:05 CET] <Polochon_street> well, thanks a lot, without you I'd be stuck [21:21:43 CET] <matto312> https://pastebin.com/ZC27A6vY ... This is error that appears to happen randomly, like 1 out of 10 times I run it [21:42:16 CET] <Ducky^> kepstin: thanks, that makes sense! [21:50:52 CET] <calloc> What would cause hash differences between container conversions? E.g. md5(flv) == md5(mkv) != md5(mp4) [21:51:21 CET] <kepstin> containers are different, therefore a hash including the container will be different [21:51:32 CET] <kepstin> or are you hashing only the streams inside the container? [21:51:39 CET] <calloc> The streams [21:51:50 CET] <calloc> md5(flv) == md5(mkv) [21:51:58 CET] <kepstin> mp4 stores h264 in a different format from other containers, regarding to some headers on the nal units [21:52:11 CET] <kepstin> the transformation is completely mechanical, and can be undone by a bsf [21:52:17 CET] <DHE> h264 has a NAL separation mode called Annex B which is different between containers [21:53:38 CET] <calloc> So can ffmpeg hash them in a container agnostic manner? (or even just mkv, flv and mp4)? [21:54:38 CET] <kepstin> you could run the video from the mp4 through the -bsf:v h264_mp4toannexb to get a consistent format before hashing, i guess. [21:54:46 CET] <furq> yeah for this case use the bsf [21:54:56 CET] <furq> otherwise drop -c copy [21:55:05 CET] <furq> that'll hash the decoded contents which is slower but more reliable [21:55:33 CET] <kepstin> is that bsf a no-op if the format is already annex-b? [21:58:09 CET] <furq> looks like it [21:58:38 CET] <furq> [AVBSFContext @ 000001d4795c7f00] The input looks like it is Annex B already [21:58:42 CET] <furq> yes, then [22:01:00 CET] <calloc> Ok so copy applys some bitstream filters. Are these needed for simple no-encode remuxing? I would like to verify simple conversions. [22:01:23 CET] <furq> depends what remuxing [22:01:28 CET] <kepstin> remuxing might require converting the h264 bitstream format, depending on the source and destination containers [22:01:35 CET] <furq> you can't mux annex b h264 into mp4 so that bsf gets autoinserted [22:02:33 CET] <calloc> Ok, so my best bet would be handling the filter in the hash rather than the remux. [22:03:11 CET] <furq> yeah [22:03:49 CET] <calloc> Would a decode behave pretty consistently for this? I'd rather the hash handle as many filetypes as possible. [22:04:29 CET] <furq> decoding will work for anything unless the pixel formats don't match [22:04:50 CET] <furq> it'll be yuv420p 99% of the time though [22:06:00 CET] <furq> that's only really a concern for lossless rgb stuff [22:07:11 CET] <calloc> I'm a little paranoid about this service I'm writing reencoding or deleting the original media after a bad remux. [22:09:03 CET] <kepstin> fwiw, ffmpeg will never re-encode if you ask it to copy, it'll fail instead if it can't copy. [22:11:35 CET] <kepstin> h264 requires a bit-accurate decoder, so if you decode an h264 stream, the decoded frames will always match (although you have to make sure you're using the image memory layout - pixfmt - if you're hashing the frame contents) [22:11:46 CET] <kepstin> the same image memory layout [22:12:36 CET] <rafael2k> anyone know if currently I can decode xHE-AAC/USAC with ffmpeg linked with fdk-aac v2? [22:15:02 CET] <cehoyos> rafael2k: Can you provide a sample? [22:15:45 CET] <rafael2k> cehoyos: yes, if needed. [22:16:24 CET] <kepstin> looks like the fdk library supports usac, so the answer should be 'yes' [22:17:12 CET] <calloc> kepstin: pixfmt should be handled in any copy conversions to mkv though, so that should be pretty consistent. Are there any common encodings that do not require bit-accurate decoding? [22:17:35 CET] <cehoyos> kepstin: Do you have a sample? [22:18:53 CET] <rafael2k> kepstin: the current anwser is no, as far as I could test [22:18:57 CET] <kepstin> calloc: pixfmt has no relevance in copy conversions, the same video data can be decoded into a few different layouts (e.g. yuv420p, nv12) which represent the exact same data, but would hash differently. [22:19:02 CET] <rafael2k> cehoyos: I'll prepare a sample [22:19:09 CET] <kepstin> rafael2k: did you actually tell it to use the libfdk_aac decoder? [22:19:19 CET] <kepstin> by default it'll use the builtin decoder. [22:19:31 CET] <rafael2k> kepstin: good point [22:19:36 CET] <rafael2k> kepstin: nope [22:20:21 CET] <cehoyos> calloc: Many audio formats and mpeg-1 do not provide a bit-exact reference [22:20:22 CET] <rafael2k> kepstin: I'll try forcing the libfdk_aac decoder [22:20:23 CET] <kepstin> that said, some samples would still be nice, since at some point someone might want to add usac support to ffmpeg's builtin aac decoder. [22:20:37 CET] <cehoyos> Really? [22:34:04 CET] <rafael2k> kepstin: I'll get a DRM tx from the air and extract the xHE-AAC bitstream, in order to be sure we have a sample which we can distribute without licensing issues. [22:35:06 CET] <kepstin> (as an aside, Digital Radio Mondiale has a very unfortunate initialism) [22:36:22 CET] <furq> yeah everyone will think they're the direct rendering manager [22:37:07 CET] <rafael2k> lol [22:37:20 CET] <cehoyos> Sadly, we don't have any samples that do not have licensing issues;-( [22:37:36 CET] <rafael2k> in past was Digital Rights Managment, now Direct Rendering Manager... wtf [22:38:20 CET] <cehoyos> And since you mention "extracting": It's often better to provide an unchanged sample stream. [22:38:46 CET] <rafael2k> I can provide even the I/Q stream [22:38:47 CET] <rafael2k> ; ) [22:40:17 CET] <cehoyos> But otoh, I don't know DRM... [22:40:41 CET] <rafael2k> This *might* have a xHE-AAC inside, but I'll try a signal from a DRM30 tx from India: https://github.com/Opendigitalradio/qt-drmplus/files/3916828/Recording_IQ_S… [22:40:59 CET] <rafael2k> (which I'm sure has xHE-AAC inside) [22:51:24 CET] <rafael2k> Found! https://ufpr.dl.sourceforge.net/project/drm/samples/DRM%20sample%20recordin… [22:51:54 CET] <rafael2k> I hope to post a xHE-AAC if I manage to correctly extract the bitstream and decode with standalone fdk-aac v2. [23:02:32 CET] <calloc> furq, kepstin: Thanks for the tips! Specifying the bit-stream format seems to be what I was after. [23:11:01 CET] <matto312> I'm using FFMPEG to turn live RTMP into HLS ... most of the time it works fine but every now and then I get flooded with these errors: "DTS 4294967551, next:2147483902996 st:1 invalid dropping" ... here is the cmd and logs: https://pastebin.com/ZC27A6vY ... thx [23:27:48 CET] <cehoyos> Your FFmpeg is 19 months old... [23:28:20 CET] <cehoyos> Feel free to also test with --enable-librtmp [23:46:34 CET] <rafael2k> kepstin: I found a stream with USAC: http://stream.radioh.no:443/rh.x16 [23:47:42 CET] <rafael2k> with stock ffmpeg aac I get: [aac_latm @ 0x55f7b1095f00] Audio object type 42 is not implemented. [23:49:34 CET] <matto312> cehoyos: thx, I'm walking home, will try when i arrive :) [23:51:28 CET] <cehoyos> How is the relation of this stream with the wav file you linked before? [23:55:08 CET] <rafael2k> cehoyos: that wav is an I/Q recording of a DRM transmission [23:55:18 CET] <rafael2k> forget about it [23:57:06 CET] <cehoyos> There is no latm parser in FFmpeg and no latm decoder in libfdk, the sample stream therefore cannot be decoded atm [23:57:32 CET] <cehoyos> How do you know that it contains "USAC"? [00:00:00 CET] --- Wed Dec 4 2019

1 0

ffmpeg-devel.log.20191202
by burek 03 Dec '19

03 Dec '19

[02:31:45 CET] <linjie> https://github.com/FFmpeg/FFmpeg/blob/637742b45dc8df329b8593f6ad8f4e154d609… [02:32:46 CET] <linjie> An indentation issue? or it's arranged intentionally? [02:38:39 CET] <kierank> looks like a bug [02:41:07 CET] <jamrial> https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=077939626eeaa0c136406… [02:41:24 CET] <jamrial> guess the indentation was never fixed after that [02:51:20 CET] <linjie> thx [13:43:58 CET] <rcombs> ^ so who wants to implement the CSS parser in lavc then [13:48:54 CET] <thardin> css is turing-complete if I'm not mistaken [13:49:06 CET] <thardin> so that's going to be a "no" [14:05:14 CET] <JEEB> I think VLC already had some parser, but I would bet it's C++ [14:27:45 CET] <hero100> JEEB: https://code.videolan.org/videolan/vlc/blob/master/modules/codec/webvtt/css… [14:27:58 CET] <JEEB> oh, C [14:50:22 CET] <rcombs> huh, doesn't look too awful as a base to start from [14:50:47 CET] <rcombs> thardin: also CSS isn't properly turing-complete on its own [14:51:12 CET] <thardin> it's still pretty bad [14:51:15 CET] <rcombs> it's just stupidly complex for a subtitle format, and can be made turing-complete by hooking it up to other stuff [14:51:29 CET] <rcombs> but you don't really need most of the more complex bits [14:51:53 CET] <rcombs> like, a pretty minimal subset of actual CSS rules would cover 99%+ of WebVTT [14:52:09 CET] <rcombs> most of the required complexity is in lexing the damn thing [14:52:58 CET] <rcombs> which is still really fucking annoying but it's not, like, web-browser-level [14:59:29 CET] <thardin> brace for yet more ad-hoc parsing [15:15:28 CET] <mkver> Someone with experience with Real Media files here? [15:27:10 CET] <Stevenliu> Just play rmvb file look "FBI Warning" :D [15:29:31 CET] <JEEB> kostya and his multimedia.cx mind dumps are probably the main source for that by now? [15:29:53 CET] <JEEB> also if it's matroska I think the old haali.su codec mappings pdf is still alive [15:31:11 CET] <mkver> I am actually interested in the question of how many packets can a Matroska block contain? [15:32:06 CET] <mkver> Right now the number is (sub_packet_cnt +nb_laces) / sub_packet_h * sub_packet_h * frame_size / block_align. [15:33:51 CET] <mkver> frame_size can be as big as UINT16_MAX, block_align could be 1 and one could have as many as UINT16_MAX * UINT16_MAX AVPackets resulting from one block. [15:35:10 CET] <mkver> I am looking for some sane limits to apply to this to not run into an OOM scenario. [15:40:18 CET] <cone-873> ffmpeg 03James Almer 07n3.4.7:HEAD: fate/cbs: add a decode model AV1 test [17:36:22 CET] <cone-873> ffmpeg 03Zhao Zhili 07master:f9d436691257: avfilter/buffersrc: remove write-only variable [19:10:14 CET] <cone-873> ffmpeg 03James Almer 07master:5985ca0436f2: avcodec/av1_parser: skip frames with spatial_id > 0 [19:10:15 CET] <cone-873> ffmpeg 03James Almer 07master:968c4cbf2281: fate/cbs: add svc AV1 tests [19:43:06 CET] <williamto> Hi everyone, I am looking forward to contributing to FFmpeg. Recently I tried to profile ffmpeg and found a significant overhead on aarch64 system. It is in the `get_cabac` function. I don't have much experience in ffmpeg development. I was wondering if someone could explain why there is such an overhead percentage on aarch64 system? [19:43:17 CET] <williamto> Here is a screenshot of what i found [19:43:18 CET] <williamto> https://imgur.com/a/JA5fWyU [19:44:17 CET] <JEEB> CABAC is the way of compressing the coded data [19:44:41 CET] <nevcairiel> bitstream parsing is the biggest bottleneck in most optimized decoders [19:44:48 CET] <nevcairiel> because its very hard to optimize [19:45:12 CET] <BBB> williamto: x86 has hand-written asm for cabac (not simd; this is regular scalar assembly). that could be done for aarch64 as well [19:45:26 CET] <BBB> although I'm surprised it doesn't have that already TBH [19:45:33 CET] <williamto> oh yes [19:45:43 CET] <williamto> I tried the same command on a x86_64 system [19:45:43 CET] <BBB> oh it does actually [19:45:49 CET] <BBB> why is that not active on yuor system? [19:45:56 CET] <BBB> check arm/cabac.h [19:45:58 CET] <williamto> and the overhead was significantly lower (around 20%) [19:46:03 CET] <BBB> maybe that's only on 32bit armv7? [19:46:16 CET] <BBB> (depends on HAVE_ARMV6T2_INLINE) [19:46:19 CET] <williamto> oh let me check my system [19:50:06 CET] <williamto> oh i checked `arm/cabac.h` [19:50:35 CET] <williamto> tbh I don't have much experience in Assembly either haha, just learning here. But the code looks different. [19:50:54 CET] <BBB> check if it's used in your build [19:52:13 CET] <BBB> there's apparently an aarch64/cabac.h also [19:52:20 CET] <BBB> I guess that's what's supposed to be used [19:52:38 CET] <williamto> yes [19:52:47 CET] <williamto> i don't think `arm/cabac.h` was used in my build [19:52:53 CET] <williamto> it was `aarch64/cabac.h` [19:57:46 CET] <williamto> is there a reason for the overhead difference between `x86_64` and `aarchie64`/`arm`? [19:58:06 CET] <BBB> uhm... yes, they are architecture-specific assembly [19:58:17 CET] <BBB> so obviously you can't use x86-64 asm on aarch64 or vice versa [19:58:28 CET] <williamto> ohhh I see [20:00:29 CET] <williamto> also I am wondering another thing. When I tried to annotate `get_cabac` with `perf` on my system, it is pointing to the `ldrb` command which resulted in the high overhead. Do you know why that command alone would take such a high amount of time? [20:01:43 CET] <nevcairiel> ldrb is the load instruction, its pretty reasonable that this might be the most time spent [20:02:21 CET] <williamto> ohh I see, that makes sense [20:04:08 CET] <williamto> Thank you for explaining guys! [20:04:27 CET] <williamto> it seems like I can't easily optimize this functionality [20:04:47 CET] <nevcairiel> we're still waiting for the day someone can make a magical fast cabac [20:05:05 CET] <williamto> haha [20:05:38 CET] <williamto> is CABAC used by default in ffmpeg no matter what the architecture/platform is? Is there an option for me to use CAVLC instead? [20:06:13 CET] <nevcairiel> that depends on the video [20:06:20 CET] <nevcairiel> when encoding you get a choice [20:08:43 CET] <williamto> oh I see [23:57:29 CET] <BenLubar> Are there any demuxers that use external files? I'm curious whether https://github.com/BenLubar/libcmv/blob/master/README.md would be possible to implement in ffmpeg and whether there's anything I can look at for reference. [23:59:12 CET] <JEEB> if you look at libavformat/mpeg.c that already refers to the vobsub .sub file if you give it an .idx file [23:59:57 CET] <JEEB> also not sure 100% sure but I think mov also has some sort of references implemented [00:00:00 CET] --- Tue Dec 3 2019

1 0

ffmpeg.log.20191202
by burek 03 Dec '19

03 Dec '19

[03:02:19 CET] <flai> This is more of an "how should I approach this" kind of question, so bear with me: I have 10+ HLS (m3u8+mpegts+h264) live streams, and want to cut segments of those together into one big clip, with a nice crossfade between these segments [03:04:08 CET] <flai> In general, I've come down to two approaches: I could use a modded version of ffmpeg that supports opengl shaders (for example, I don't think ffmpeg supports it easily natively), or I could simply export rgb frames of the segments and then add those together programmatically, piping it into a secondary instance of ffmpeg [03:04:34 CET] <flai> in both cases audio isn't trivial [03:04:47 CET] <flai> (I want a simple mp4+h264+audio as output) [03:05:04 CET] <flai> What kind of solution would you guys go for? [03:08:24 CET] <flai> Anyway, here's a version of what it should look like, essentially: https://www.youtube.com/watch?v=TFwAOrj2uSo [03:12:02 CET] <Pie-jacker875> does anyone know anything about mlt rendering parameters through kdenlive [03:12:15 CET] <Pie-jacker875> I'm trying to figure out how to get a profile for 2 pass vp9 [03:12:47 CET] <Pie-jacker875> it's only actually trying to do the second pass and fails because it doesn't actually have the log file from the first pass [03:13:07 CET] <Pie-jacker875> and if I set it to do 1 pass then it doesn't seem to create the log file [03:35:56 CET] <trfl> flai, this and similar things would be much easier with vapoursynth [03:36:10 CET] <trfl> so i would use that for the sequencing and then ffmpeg for encoding [03:36:39 CET] <trfl> ...actually VS didn't do audio the last time i checked, but i recall someone was working on that [03:37:46 CET] <flai> hm, yeah [03:39:27 CET] <trfl> if you can survive with something windows-native, then avisynth is compiled into the ffmpeg static builds by zeranoe [03:39:35 CET] <trfl> that's what inspired vapoursynth and does audio too [03:40:02 CET] <flai> Hm, i mean we run a few cloud-windows instances anyway, but they're being used for sth else [03:40:08 CET] <flai> but windows vms work anyway if we need them to [03:40:37 CET] <flai> but avisynth looks great [03:41:27 CET] <flai> yeah, that looks amazing [03:45:11 CET] <flai> hm, i'd might have to remux the relevant sections to avi, but that should be trivial [03:46:44 CET] <flai> Thank you so much trfl! [09:43:14 CET] <th3_v0ice> How can I call reconfigure_encoder from x264 encoder for example? Are there any methods available from the API that allow this? [09:44:12 CET] <JEEB> the libx264 wrapper has support for that, various parameters are checked when you feed the encoder an AVFrame [09:45:24 CET] <JEEB> X264_frame() which is the cfunction called at each AVFrame calls reconfig_encoder, which checks various params and then calls x264_encoder_reconfig one or more times [09:46:01 CET] <JEEB> libx264 does limit in which cases it will actually reconfigure though :P [09:46:21 CET] <JEEB> so I'd check first if you're not or are hitting x264_encoder_reconfig already in the wrapper [09:46:39 CET] <JEEB> for the exact changes monitored see the wrapper code [09:46:48 CET] <th3_v0ice> So reading from the code, if I just change in the AVCodecContext CRF value, it will reconfigure the encoder on the next send frame? [09:46:49 CET] <JEEB> reconfig_encoder in libavcodec/libx264.c [09:47:04 CET] <JEEB> should yes [09:47:17 CET] <JEEB> whether libx264 itself takes that change in is then what matters [09:47:53 CET] <JEEB> but that is no longer a FFmpeg thing, but rather a libx264 thing :P [09:48:05 CET] <th3_v0ice> That's true :) [09:48:09 CET] <th3_v0ice> Thanks for the info [09:48:32 CET] <JEEB> np. I tried at one point to add colorspace reconfig there but failed :/ [09:48:55 CET] <JEEB> as in, if I don't have knowledge of output colorspace/primaries when the encoder is init, but there is knowledge of that in the first AVFrame [09:49:07 CET] <JEEB> (which is what often happens in ffmpeg.c) [09:49:28 CET] <th3_v0ice> Why did you fail in accomplishing that? [09:49:49 CET] <th3_v0ice> Encoder didnt like it? [09:49:49 CET] <JEEB> x264 didn't take the change in, apparently. or I didn't see anything changing :P [09:49:55 CET] <JEEB> I did try to patch x264 too, btw [09:49:59 CET] <JEEB> so it wasn't just FFmpeg side [09:50:02 CET] <JEEB> but I didn't get far enough [09:50:23 CET] <JEEB> I think it might make sense to instead init x264 at the first frame [09:50:32 CET] <JEEB> do a test-init in wrapper's init() [09:50:46 CET] <JEEB> and then initialize actually in encode_frame() [09:51:12 CET] <th3_v0ice> That sounds like a solid idea [09:55:30 CET] <th3_v0ice> Also seems from x264 code that they only support changing bufsize, maxrate, crf and bitrate. [09:55:54 CET] <JEEB> yup [09:55:58 CET] <JEEB> mostly rate control [10:16:38 CET] <lain98> does the order in which i specify the filtergraph affect the output ? using -vf [10:17:18 CET] <cehoyos> Definitely [10:26:23 CET] <lain98> hmm okay [11:41:31 CET] <lain98> i'm using this command to generate a video using geq filter. ffmpeg -f lavfi -i "nullsrc='s=512x512:d=256:r=1',scale=out_range=full,geq='r=N:g=N:b=N',format=yuv420p,drawtext=fontfile=Arial.ttf: text=%{n}: x=(w-tw)/2: y=h-(2*lh): fontsize=20: fontcolor=white: box=1: boxcolor=0x00000099" test.mp4 [11:41:45 CET] <lain98> but the 5th frame seems to be incorrect [11:42:06 CET] <lain98> because i get r=g=b=3 instead of 4 [11:50:47 CET] <lain98> ok, there are many frames where the geq equation isnt correct [11:53:35 CET] <durandal_1707> lain98: geq is correct, probably dropped frames [11:55:07 CET] <lain98> how do i not drop ? [11:55:31 CET] <durandal_1707> post full uncut output to pastebin [12:01:59 CET] <lain98> check pm durandal_1707 [12:04:03 CET] <lain98> durandal_1707: https://gist.github.com/a-sansanwal/145f244b10acca2ae696dbf282f84d30 [12:06:00 CET] <durandal_1707> you are converting rgb to yuv [12:06:33 CET] <durandal_1707> can not expect same R/G/B values [12:08:00 CET] <lain98> yeah, that might be it [12:11:38 CET] <durandal_1707> it sure is [12:16:33 CET] <lain98> thanks durandal_1707 , was able to fix it [16:34:52 CET] <lofo> Hi [16:35:16 CET] <lofo> From FFmpeg's StreamingGuide i can read " It either streams to a some "other server", which re-streams for it to multiple clients, or it can stream via UDP/TCP directly to some single destination receiver" [16:35:39 CET] <lofo> i do not understand the difference between the two approaches [16:36:55 CET] <DHE> ffmpeg is not a server that handles many users connected to it at once [16:37:20 CET] <lofo> If we do not care for the "multiple clients" the other server streams to in either case there is an emitter and a receiver. [16:39:40 CET] <lofo> what im trying to figure out is : How, on a technical standpoint, does "streams to a some other server" and "stream via UDP/TCP directly to some single destination receiver" are different [16:42:24 CET] <lofo> Another way to put it : When you stream to a single destination do you do it the same way you would stream to a Streaming server that would subsequently dispatch to N other devices ? [16:43:08 CET] <lofo> because the phrase i've copy pasted suggests that it isnt the case [16:45:00 CET] <kepstin> there's some modes where you can use ffmpeg as a "server" (accepts an incoming tcp connection) but it only supports one client connecting. [16:47:51 CET] <lofo> sure, but i'm only using ffmpeg to produce the stream [16:49:38 CET] <lofo> I'm trying to figure out if transmitting to a server or directly to a single receiver are two diffirent connection methods [16:49:51 CET] <kepstin> not necessarily [16:50:21 CET] <kepstin> ffmpeg does support a lot of different connection methods, you pick one according to what the remote side supports, not what role the remote side fulfills. [16:51:19 CET] <lofo> Because in this phrase from FFmpeg's StreamingGuide we can read "UDP/TCP" like an alternative connection method : "It either streams to a some "other server", which re-streams for it to multiple clients, or it can stream via UDP/TCP directly to some single destination receiver" [16:51:50 CET] <kepstin> "some other server which re-streams to multiple clients" is an example of "a single destination receiver" [16:52:48 CET] <lofo> this is what i was suspecting. needed confirmation. :) [16:53:19 CET] <kepstin> although a "single destination receiver" is usually interpreted as "something that plays the video directly", which is why the server that re-streams is also listed [16:53:32 CET] <kepstin> but ffmpeg doesn't care what the remote side does with the video [16:53:47 CET] <lofo> the "real" info in this phrase is that FFmpeg does handle multiple clients. It was an odd way to put it [16:53:54 CET] <kepstin> no, it does not [16:54:04 CET] <lofo> does NOT sorry [16:58:30 CET] <lofo> I'm sorry to insist but this documentation suggests that point-to-point is a different way to stream: https://trac.ffmpeg.org/wiki/StreamingGuide#Pointtopointstreaming [17:07:00 CET] <kepstin> that's just giving an example of how to do a point to point stream, showing how to set up bothe ffmpeg and the player. [17:07:35 CET] <kepstin> a point to point stream is just one where the thing on the other end is playing the video directly, rather than throwing the data into a black hole or sending it to multiple other machines [17:08:20 CET] <kepstin> ffmpeg doesn't care what the other end is, but for people who want to do a point to point stream, it's helpful to know how to set up the *other end* of the connection. [17:09:04 CET] <kepstin> if you're sending to a re-streaming server, presumably it's already set up and you just need to know how to get ffmpeg to talk to it. [17:09:18 CET] <kepstin> which is why they're documented differently. [18:38:11 CET] <Fyr> is there a tool to create slideshow with FFMPEG? [18:38:35 CET] <Fyr> I mean, a script for Windows with random tranitions. [20:01:22 CET] <Polochon_street> Hi! Let's say I have a vizualisation I'm making from a song in FFmpeg. Is there an "easy" way to stream it on some port for my LAN ? [20:02:39 CET] <Polochon_street> the ideal would be to only be computing the vizualisation if someone requests it, and then stopping it as soon as the connection has closed [20:51:03 CET] <BenLubar> I'm thinking about trying to implement a demuxer and a decoder in ffmpeg for dwarf fortress cmv files [20:59:28 CET] <Polochon_street> guys, I've managed to do this https://paste.isomorphis.me/6Wv to stream the spectrometer of my audio out in my LAN, but I still have like 1s of latency when looking at the output on my own computer (see the line where I play it below) [20:59:36 CET] <Polochon_street> do you have any idea to reduce latency even more? [21:12:38 CET] <faLUCE> Hello. When I open an ac3 file with Audacity, it uses the ffmpeg ac3 decoder and shows the channels Rear-left/right at a lower volume than front-left/right. Is this the recording volume or does the decoder lower the volume when downmixing? (It should not downmix, given that I see 6 different channels with audacity, but I want to be sure) [21:15:14 CET] <durandal_1707> dunno what audacity does [21:16:53 CET] <kepstin> it seems like it uses ffmpeg to decode most formats it doesn't handle natively, and passes no extra options to the decoder [21:17:38 CET] <durandal_1707> you can use ffmpeg to export ac3 with all channels to wav [21:37:27 CET] <faLUCE> durandal_1707: right. how can I export only channels 3,4 and 5 ? [21:40:09 CET] <kepstin> faLUCE: https://www.ffmpeg.org/ffmpeg-all.html#channelmap [21:40:27 CET] <kepstin> is one way [21:40:50 CET] <kepstin> i thought there was an ffmpeg option as well, but i can't be bothered to search the docs for it [21:41:18 CET] <furq> -map_channels [21:41:41 CET] <furq> -map_channel rather [21:42:06 CET] <faLUCE> thnks [21:55:19 CET] <analogical> can some ffmpeg ninja please extract the video stream from this site? http://ustvgo.tv/cnn-live-streaming-free/ [21:56:52 CET] <kepstin> analogical: maybe the youtube-dl folks would be more appropriate? [21:58:16 CET] <kepstin> but in general for a one-off, it just ends up being "use the browser inspector network panel to find the hls playlist url, then use that as an input to ffmpeg" [22:06:37 CET] <safinaskar> how to list all codecs supported by particular container? [22:06:52 CET] <kepstin> safinaskar: ffmpeg doesn't have that functionality. [22:07:16 CET] <safinaskar> kepstin: thanks [22:07:25 CET] <safinaskar> kepstin: this is very sad [22:08:49 CET] <safinaskar> kepstin: how to get list of all codecs supported by nut? i know that there exists a file https://git.ffmpeg.org/gitweb/nut.git/blob/670ff4339ed54f779ece2086fe8dbe9c… , but i want to get list of strings i can pass to "-c:v" switch, so that I can do "for I in ...list...; do ffmpeg -c:v $I" [22:09:04 CET] <kepstin> it's kind of annoying at times, yeah. There is technically an api to do it in libavformat, but last I checked not very many formats actually provided a list, so it's not useful. [22:10:12 CET] <analogical> safinaskar, https://en.wikipedia.org/wiki/Comparison_of_video_container_formats#Video_c… [22:10:27 CET] <kepstin> safinaskar: note that "a string you can pass to -c:v" and "codec name" are not the same thing [22:11:15 CET] <kepstin> -c:v takes the name of an encoder (although all the builtin encoders have the same name as the codec, and there is a fallback so it'll pick a random encoder for the codec if there's no builtin one) [22:16:36 CET] <safinaskar> kepstin: analogical: thanks [22:19:09 CET] <kepstin> my impression was that nearly everything which ffmpeg can encode (and probably some things it can only copy) can be put into nut, but the result might not be particularly useful (or even decodeable, necessarily) [22:19:32 CET] <kepstin> like, i don't think the nut muxer has any code to reject any codecs as unsupported. [22:46:25 CET] <Polochon_street> hm. So, I've managed to stream a 800x480 x264 stream over my network and it's read smoothly by another laptop, but my raspberry pi struggles to display it via fbdev. Do you have any idea of how I could ease things for it? [22:46:43 CET] <Polochon_street> the poor little guy struggles [22:47:48 CET] <irwiss> LO2 chiller? :P [22:50:24 CET] <wodim> I want to overlay a series of png files, in loop, one image per frame, on a video. would this be a good approach? https://stackoverflow.com/q/42943805 [22:50:46 CET] <wodim> or anything else you can suggest [22:59:30 CET] <kepstin> seems fine. If you don't want to specify a bunch of -i options, it's possible to use the "movie" filter in your filter chain as the image source. [23:53:43 CET] <CounterPillow> I think the latest commit broke bofa [00:00:00 CET] --- Tue Dec 3 2019

1 0

ffmpeg-devel.log.20191201
by burek 02 Dec '19

02 Dec '19

[00:21:18 CET] <thardin> 420 is the weed number [12:15:29 CET] <ubitux> sorry i haven't been here for a while, is "for (int i ..." allowed now? [12:15:41 CET] <ubitux> is it limited to the for loop or can we do modern c declaration too? [12:16:25 CET] <durandal_1707> it is allowed, please follow our discussion and developer manual [12:16:52 CET] <ubitux> yeah sorry the first one was a rethorical question, i'm seeing the thousands of matches, that's nice [12:17:14 CET] <durandal_1707> second one, is not because it is ugly [12:17:31 CET] <thardin> considering c99-to-c89 exists it shouldn't be a problem [12:17:54 CET] <ubitux> durandal_1707: opinion, but ok :) [12:27:09 CET] <durandal_1707> ubitux: use { } [14:01:23 CET] <durandal_1707> ubitux: i'm not goint to send new nlmeans iteration, very bad experience [14:30:26 CET] <ubitux> durandal_1707: what do you mean? [14:33:01 CET] <durandal_1707> lost interest, i'm not going to wait days for negative review [16:42:59 CET] <kierank> durandal_1707: could be bug [16:54:20 CET] <durandal_1707> kierank: what? [16:55:08 CET] <kierank> I don't see how they make braw 420 [16:56:03 CET] <durandal_1707> 64 + 64 + 32 + 32: coded coefficients in this order [16:56:58 CET] <durandal_1707> perhaps last is just split... [16:57:22 CET] <durandal_1707> so its 64+64+(32+32) [16:57:29 CET] <durandal_1707> but that is very weird [16:57:44 CET] <kierank> yes odd [17:10:49 CET] <cone-519> ffmpeg 03Steven Liu 07master:b26225a3c710: avformat/dashenc: remove unused check of avformat_free_context [17:10:50 CET] <cone-519> ffmpeg 03Steven Liu 07master:e880f4fb387b: avformat/hdsenc: removed unused check of avformat_free_context [17:10:51 CET] <cone-519> ffmpeg 03Steven Liu 07master:0f79a71353fa: avformat/rtpenc_mpegts: removed unused check of avformat_free_context [17:10:52 CET] <cone-519> ffmpeg 03Steven Liu 07master:9cc88ed4b71c: avformat/smoothstreamingenc: removed unused check of avformat_free_context [17:13:02 CET] <Boist> 174 [17:20:17 CET] <cone-519> ffmpeg 03Andreas Rheinhardt 07master:35005a4af1eb: avformat/flac_picture: Simplify checks [17:20:18 CET] <cone-519> ffmpeg 03Andreas Rheinhardt 07master:84a4261cd842: avformat/flac_picture: Switch to bytestream2 API [17:20:19 CET] <cone-519> ffmpeg 03Andreas Rheinhardt 07master:5946243fa893: avformat/flac_picture: Return directly if nothing has been allocated [17:20:20 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:13816a1d085f: avformat/mxfdec: Clear metadata_sets_count in mxf_read_close() [17:20:21 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:47d963335eb2: avcodec/vmdaudio: Check chunk counts to avoid integer overflow [17:20:22 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:0e010e489b70: avcodec/vc1_block: Fix integer overflow in AC rescaling in vc1_decode_i_block_adv() [17:20:23 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:589cb44498b5: avcodec/wmaprodec: Fix buflen computation in save_bits() [17:20:24 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:7686ba1f149a: avcodec/alac: Fix integer overflow in lpc_prediction() with sign [17:20:25 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:d468da8d7960: avcodec/g729dec: Check for KELVIN && 6k4 [17:20:26 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:f64be9da4c8b: avcodec/g729dec: require buf_size to be non 0 [17:20:27 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:576746b4e300: avcodec/g729dec: Factor block_size out [17:20:28 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:336f9461df7d: avcodec/g729dec: Avoid using buf_size [17:20:29 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:0ddef0045737: avcodec/g729dec: Avoid one multiply by using init_get_bits8() [17:20:30 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:fd3c34ff304a: avcodec/alsdec: Avoid 1 layer of pointer dereferences in INTERLEAVE_OUTPUT() [17:20:31 CET] <cone-519> ffmpeg 03Michael Niedermayer 07master:a11aa5f3ed7e: avcodec/alsdec: Discard frames for which no channel could be decoded [18:57:18 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:e2def5f382b0: avcodec/cngdec: Remove AV_CODEC_CAP_DELAY [18:57:19 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:650ce5047cf3: avutil/lfg: Correct index increment type to avoid undefined behavior [18:57:20 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:f3e553e36a98: avcodec/rawdec: Check bits_per_coded_sample more pedantically for 16bit cases [18:57:21 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:66e701af697d: avcodec/wmavoice: Fix integer overflow in synth_frame() [18:57:22 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:9162df98e1cf: avcodec/nuv: Move comptype check up [18:57:23 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:3f186986520f: avcodec/mxpegdec: Check for multiple SOF [18:57:24 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:a67d997ad735: avcodec/g729dec: Use 64bit and clip in scalar product [18:57:25 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:6ce537910543: avcodec/ralf: Fix integer overflows with the filter coefficient in decode_channel() [18:57:26 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:ed4f48535335: avcodec/ffwavesynth: Fix integer overflow with pink_ts_cur/next [18:57:27 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:db659cdf4789: avcodec/nuv: Use ff_set_dimensions() [18:57:28 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:0eff731d8d35: avformat/mxfdec: Clear metadata_sets_count in mxf_read_close() [18:57:29 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:2f942ddf7415: avcodec/vmdaudio: Check chunk counts to avoid integer overflow [18:57:30 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:5b43aa7a80f5: avcodec/vc1_block: Fix integer overflow in AC rescaling in vc1_decode_i_block_adv() [18:57:31 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:f4daf42c1a5c: avcodec/wmaprodec: Fix buflen computation in save_bits() [18:57:32 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:4d932eb66b03: avcodec/alac: Fix integer overflow in lpc_prediction() with sign [18:57:33 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:0b49c74fe177: avcodec/g729dec: require buf_size to be non 0 [18:57:34 CET] <cone-519> ffmpeg 03Michael Niedermayer 07release/3.4:289a79d545e8: Changelog: update [19:47:27 CET] <mateo`> <èè [19:47:31 CET] <mateo`> oups [20:59:59 CET] <cone-519> ffmpeg 03James Almer 07master:eced91afa5fc: avcodec/cbs_av1: implement missing set_frame_refs() function [21:00:00 CET] <cone-519> ffmpeg 03James Almer 07master:553c1431ac7d: Revert "avcodec/cbs_av1_syntax_template: Check ref_frame_idx before use" [21:00:01 CET] <cone-519> ffmpeg 03James Almer 07master:af7ab32b897b: fate/cbs: add a switch frame AV1 test [21:00:02 CET] <cone-519> ffmpeg 03James Almer 07master:637742b45dc8: fate/cbs: add a decode model AV1 test [23:10:19 CET] <mkver> Anybody with knowledge about tta here? [23:24:18 CET] <durandal_1707> mkver: whats wrong? [23:25:44 CET] <mkver> The Matroska demuxer allocates 30 bytes of extradata for it, but uses only 18 of them. The tta demuxer uses 22 bytes for the extradata (the difference is in a CRC-32, but even then eight bytes are unaccounted for). This is weird [23:27:08 CET] <durandal_1707> mkver: note that out tta demuxer can't handle correctly decoding of last frame after seeking [23:27:13 CET] <durandal_1707> *out [23:27:14 CET] <durandal_1707> *our [23:27:51 CET] <mkver> And you think that this has something to do with this? [23:28:14 CET] <durandal_1707> that is only major issue with it i think, and same applies to matroska [23:28:33 CET] <durandal_1707> or only to tta in matroska, long time ago it was [23:28:44 CET] <jamrial> tta in mkv is a mess because the spec strictly requires the header to be dumped, which forces us to somehow calculate the last frame size [23:28:48 CET] <jamrial> but yeah, that 30 is probably wrong [23:29:17 CET] <durandal_1707> last frame size calculation is not working, last time i tested it [23:29:38 CET] <jamrial> yup [23:31:21 CET] <jamrial> the decoder says "30bytes includes TTA1 header" [23:31:40 CET] <jamrial> and rejects any extradata smaller than 22 bytes [23:32:21 CET] <mkver> And this here: http://tausoft.org/wiki/True_Audio_Codec_Format has only 22 bytes. [23:35:23 CET] <mkver> The 30 bytes is with a seektable with one frame; see c4e0e314248865830ec073e5a3ef08e0a40aabf2 [23:44:27 CET] <jamrial> mkver: if you want, change the 30 in the mkv demuxer to 22. the tta demuxer doesn't store the seek table in extradata either [23:44:52 CET] <mkver> Already did so. [00:00:00 CET] --- Mon Dec 2 2019

1 0

ffmpeg.log.20191201
by burek 02 Dec '19

02 Dec '19

[00:04:21 CET] <lavalike> now I'm running it with VO [gpu] and there are audio problems, ha! of the form: [ffmpeg/audio] aac: Number of bands (54) exceeds limit (44). [00:05:32 CET] <lavalike> example: https://pastebin.com/raw/GTgGRmn7 [00:06:41 CET] <furq> yeah that looks like junk data [00:07:03 CET] <lavalike> how can I work around that? [00:07:12 CET] <furq> watch a better stream [00:07:29 CET] <lavalike> there seem to be no better streams [00:08:11 CET] <furq> is it actually breaking playback completely or just showing corrupt video/audio sometimes [00:08:12 CET] <lavalike> you pick one, I'm 90% sure it'll behave the same way [00:08:17 CET] <furq> if it's the latter then you can't really do any better than that [00:08:40 CET] <lavalike> it stops the video, then when the desync detected message pops up, it starts again, usually takes 15 seconds or more [00:08:55 CET] <lavalike> (it stops the playback of both video and audio to be precise) [00:09:00 CET] <JEEB> the message from the hls reader hints at something going really wrong :P [00:09:16 CET] <furq> yeah that is also extremely not good [00:09:18 CET] <JEEB> and no, it's not necessary for HLS/DASH streams to have broken segments [00:09:24 CET] <furq> although that shouldn't cause broken segments [00:09:39 CET] <lavalike> I think it might be something local to the machine [00:09:39 CET] <JEEB> I produce streams in various places and I'm pretty sure I don't produce garbage [00:10:07 CET] <furq> JEEB: i mean assuming he can only watch this broken-ass stream [00:10:21 CET] <JEEB> yes, sure [00:10:33 CET] <JEEB> just that he noted it in a way that seemed like "test any stream, they'll probaly have this" [00:10:41 CET] <furq> oh right [00:10:46 CET] <lavalike> that is what I meant yes [00:10:56 CET] <furq> if this is happening with every hls stream you watch then something is messed up on your end [00:11:05 CET] <JEEB> or all the streams he watcher are crappy [00:11:10 CET] <furq> or that yeah [00:11:10 CET] <lavalike> you pick one! [00:11:19 CET] <JEEB> also I wonder if the thing producing the stream just overwrites segments without new names [00:11:25 CET] <JEEB> or something like that [00:11:33 CET] <JEEB> that would explain the data just being crapped on top of [00:12:49 CET] <furq> watch some youtube live stream if you just want to test that you can receive hls [00:12:54 CET] <furq> that ought to be packaged properly [00:13:57 CET] <JEEB> https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_4x3/bip… [00:14:12 CET] <JEEB> this will give a lot of warnings from the MPEG-TS reader because apple did a poo-poo there with the timestamps [00:14:21 CET] <JEEB> but it has no invalid video/audio data :P [00:14:35 CET] <JEEB> you can just keep playing bipbop [00:15:05 CET] <lavalike> wow :) [00:17:01 CET] <lavalike> hmm I took a random youtube live stream and the AO: [wasapi] suggests it won't give me ffmpeg errors any time soon.. [00:17:36 CET] <lavalike> no I'm wrong it was the same AO in the erroring example [00:18:08 CET] <lavalike> no errors, nor warning, now I'm puzzled [00:18:49 CET] <JEEB> it just seems like the people behind the stream you were watching couldn't properly keep the stream on. so most likely when their crap restarts or something, they overwrite segments that you are playing [00:18:53 CET] <JEEB> or something like that [00:18:57 CET] <JEEB> in any case, broken segments [00:20:02 CET] <lavalike> is this consistent with the mac side showing no errors and warnings whatsoever on the same streams? [00:20:30 CET] <JEEB> for video it just seems like hwdec vs swdec and different errors if any being reported :P [00:21:20 CET] <lavalike> I smelled something funny when I noticed this windows installation *can't* play any of those streams inside chrome itself [00:23:54 CET] <lavalike> https://imgur.com/a/IvlxmFy [00:26:02 CET] <furq> doesn't chrome use lavc on all platforms [00:26:25 CET] <JEEB> if provided. there are chromium builds without it [00:26:37 CET] <furq> yeah i know chromium doesn't necessarily [00:26:37 CET] <JEEB> also on some setups it does use hwdec [00:26:41 CET] <furq> and firefox doesn't [00:26:52 CET] <lavalike> ah I might have ended up with a stripped chromium [00:26:54 CET] <pink_mist> chrome is always a binary from google [00:27:00 CET] <furq> if it's chromium then yeah that would explain it [00:27:04 CET] <pink_mist> chromium is the one you can build yourself [00:27:05 CET] <lavalike> I see [00:27:21 CET] <JEEB> pink_mist: but people also can end up calling chromium binaries "chrome" :P [00:27:29 CET] <JEEB> which is why I didn't remove the option from the table [00:27:33 CET] <pink_mist> ah [00:27:45 CET] <lavalike> and I just confused things by doing exactly that [00:28:36 CET] <furq> chromium on windows often has no h264 decoder for licensing reasons [00:28:41 CET] <furq> chromium builds, that is [00:28:53 CET] <furq> and youtube live stuff is always h264, no vp9 [00:28:53 CET] <lavalike> so that explains the chromium playback issue, perfect [00:29:21 CET] <lavalike> I had imagined a deeper connection between the mpv playback problems but there is none oh well [00:48:57 CET] <b1rk0ff> what is muxing overhead ? [00:50:52 CET] <Atlenohen> data that's part of the mux but not part of the video/audio streams [00:51:24 CET] <Atlenohen> is what I think [00:53:48 CET] <b1rk0ff> what does it mean if an ffmpeg with filter invocation exits abruptly with this error? [00:54:42 CET] <DHE> b1rk0ff: muxing overhead is the how much the file size is above the raw stream sums [00:55:11 CET] <DHE> if audio + video is 100 MB, but the file is 101 MB large, then you have about 1% muxing overhead [01:00:02 CET] <Kaedenn> How do I export a specific frame of a video file as a png or jpeg? [01:00:14 CET] <Kaedenn> (working on a thumbnailer program) [01:00:55 CET] <JEEB> if you need frame exactness I recommend you look into ffms2 [01:01:07 CET] <JEEB> because ffmpeg.c will not do that [01:01:25 CET] <Kaedenn> eh, I just wanna export frames from like 10% the way through, 20% the way through, etc [01:01:28 CET] <JEEB> (ffmpeg.c can be pretty much frame exact in various containers/formats, but to be sure you need an index) [01:01:52 CET] <Kaedenn> exactness isn't really a concern since the frame indexes will be calculated anyway [01:02:11 CET] <JEEB> Kaedenn: if your inputs always output properly the duration and support seeking exacly enough [01:02:28 CET] <JEEB> then you can utilize seeking and thumbnail etc filters [01:02:49 CET] <JEEB> I did actually make a thing as a mental exercize once [01:02:53 CET] <Kaedenn> I need to know how to use the thumbnail filter (which, as of a few seconds ago, I didn't know existed) [01:03:15 CET] <JEEB> it just attempts throughout some metric to pick the "most active" frame from given input [01:03:25 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#thumbnail [01:03:32 CET] <Kaedenn> ffmpeg -i input.flv -ss 00:00:14.435 -vframes 1 out.png woot [01:03:34 CET] <JEEB> usually doing ctrl+F on this page is pretty good [01:03:53 CET] <Kaedenn> ooooh [01:03:55 CET] <Kaedenn> this is even better [01:03:58 CET] <Kaedenn> thank you kindly [01:04:20 CET] <JEEB> but yea, I wrote a thumbnailing app without ffms2 once [01:04:29 CET] <JEEB> fed it mp4 which has a seeking index [01:04:31 CET] <JEEB> and it worked pretty well [01:04:36 CET] <JEEB> fed it an mpeg-ts from broadcast [01:04:39 CET] <JEEB> and it was hilarious [01:05:12 CET] <Kaedenn> nice [01:05:15 CET] <JEEB> so by using ffmpeg.c you gain not having to index the whole thing container-wise :P [01:05:33 CET] <JEEB> but you do lose being able to know the duration surely [01:05:36 CET] <Kaedenn> I'm writing this as a python script using subprocess so I don't really have to worry about bindings [01:05:51 CET] <JEEB> ffms can be utilized from vapoursynth [01:05:59 CET] <JEEB> which is a python based frame server [01:07:33 CET] <JEEB> http://up-cat.net/p/a226bc42 [01:07:36 CET] <JEEB> looks like this [01:07:51 CET] <JEEB> this is not ffms2, but another filter like it [01:09:14 CET] <Kaedenn> What is `ffms2`? [01:09:53 CET] <JEEB> https://github.com/FFMS/ffms2/ [01:10:09 CET] <JEEB> based on FFmpeg's libraries, a library providing frame-exact capabilities [01:15:51 CET] <Kaedenn> the latest tag they have seems to be quite old [01:16:12 CET] <void09> any good gui programs that can cut .ts that use ffmpeg? [01:16:35 CET] <void09> i'm sick of inputting timestamps in the terminal [01:29:55 CET] <JEEB> Kaedenn: there was some bug they want to fix and then cut a new release. unfortunately people are busy/bugs are not simple [01:30:15 CET] <JEEB> generally people use master in such cases since master in many projects like FFmpeg is supposed to be as stable as releases [01:34:47 CET] <Kaedenn> understandably [01:34:54 CET] <Kaedenn> alright, that makes sense [03:56:24 CET] <void09> .join #ffms2 [03:56:52 CET] <void09> Whoop, no such thing :) [04:00:17 CET] <void09> JEEB: you around ? [04:00:38 CET] <void09> I was wondering if you can tell me if it would make any difference to put -ss before/after input file, when cutting a .ts file [04:08:48 CET] <furq> yes it makes a huge difference [04:09:07 CET] <furq> mpegts has no seek index so -ss before -i just guesses [04:12:51 CET] <void09> isn't -ss after -i that just guseses? [04:13:45 CET] <furq> no -ss after -i decodes the stream [04:13:58 CET] <furq> so it just discards everything up to the timestamp you asked for [04:14:29 CET] <furq> it should always be perfectly accurate for any format [04:15:11 CET] <void09> oh, well that's what I've been using so far, ffmpeg -i -ss -to [04:15:44 CET] <void09> Must have done over 100 cuts by now, And i'm thinking if there isnt' some easier way, like an mpv script for example [04:15:59 CET] <furq> there is an mpv script for cutting but it just execs ffmpeg [04:16:01 CET] <void09> I press A at start point then Z at the end frame, and I get an accurate cut by calling ffmpeg [04:16:05 CET] <void09> there is ? [04:16:10 CET] <void09> wow [04:17:22 CET] <void09> https://github.com/kelciour/mpv-scripts/blob/master/sub-cut.lua [04:17:23 CET] <void09> this one? [04:17:50 CET] <furq> there's a few different ones [04:17:52 CET] <furq> that looks fine though [04:18:35 CET] <TheAMM> Mind that if you're playing a file with ordered chapters, ffmpeg doesn't load those (mpv does) and the timestamps might be off [04:19:15 CET] <void09> TheAMM: I am using ordered chapters to cut the extra frames from the raw ffmpeg cut (as it only cuts on keyframe) [04:19:29 CET] <furq> yeah it'd be nice if there was a lua api to get demuxed streams out of mpv [04:20:23 CET] <TheAMM> It's easy-ish enough to recreate the timeline if you can dump the chapter xml [04:20:27 CET] <void09> ideally the script would do a cut at the start-end point, up to the nearest keyframe that includes that frame. and then it would add a chapter that would start/end on the frames that I selected to cut [04:20:47 CET] <TheAMM> Well, in theory, I've only done it in vapoursynth, I expect ffmpeg concat would get quite messy [04:21:00 CET] <TheAMM> Yeh, good luck with that [04:21:27 CET] <void09> i currently do that with mkvtoolnix-gui (adding chapters) [04:21:43 CET] <void09> I think mkvpropedit would work from the terminal [04:22:33 CET] <furq> you could try avidemux maybe [04:22:44 CET] <void09> -c, --chapters <filename> Add or replace chapters in the file with the ones from 'filename' or remove them if 'filename' is empty [04:23:20 CET] <void09> but how would I get the corresponding timestamp in the newly cut video (after ffmpeg cuts it), to know the offsets for the chapter ? [04:24:39 CET] <furq> just subtract -ss from them all [04:27:02 CET] <void09> but is mpv accurate with the timestamps anyway, in a non indexed format like ts ? [04:27:40 CET] <void09> the way i do it now, is, seek to the frames i want to cut from/to, and do ffmpeg -i ss first_frame-500miliseconds -to last_frame+500miliseconds [04:28:00 CET] <void09> if i don't add those, it's possible the frame i want will be left out of the cut [04:28:27 CET] <void09> now until recently i thougt that's because ffmpeg cuts to the nearest keyframe, not necessarily the nearest that includes the desired timestamp. [04:28:55 CET] <void09> but JEEB told me it should include that frame, and the timing offset I need is due to mpv's inaccuracy [04:29:44 CET] <TheAMM> Remux your .ts into matroska and stop worrying about timestamp issues [04:30:07 CET] <TheAMM> Then write a simple script or even input command to dump current timestamp to a file upon keypress [04:30:18 CET] <TheAMM> Seek, tap, repeat, done [04:30:27 CET] <void09> TheAMM: I am using .mkv as the final format [04:30:40 CET] <TheAMM> Use it as an intermediary format as well [04:30:44 CET] <void09> but do not have an intermediate step. [04:30:51 CET] <void09> right.. i had some errors when i did that [04:30:56 CET] <void09> something about timestamps [04:31:01 CET] <void09> non-monotonous.. something [04:31:05 CET] <TheAMM> Yes [04:31:10 CET] <furq> mpv can seek accurately in mpegts iirc [04:31:14 CET] <TheAMM> Because the .ts is f'd up [04:31:17 CET] <furq> it just takes a while [04:31:30 CET] <void09> TheAMM: I got it every time, on every cap I did : [04:31:35 CET] <furq> it obviously has to start decoding the stream straight away to show it to you so it can check if it's in the right place [04:32:06 CET] <void09> furq: it takes a while ? [04:32:21 CET] <furq> it takes longer than it would if the file had a seek index [04:32:32 CET] <furq> it's faster than ffmpeg though [04:32:32 CET] <void09> It seems equally fast on my pc [04:32:52 CET] <void09> which is.. ridiculously fast, i can drag the cursos over the seekbar and get 0 latency [04:33:09 CET] <void09> 0 perceivable latency. which is the reason i started using mpv in the first place. no other player that I tried could do that [04:33:11 CET] <furq> it's a lot less fast if you have a very high bitrate file [04:33:21 CET] <void09> I have ~10mbps 1080i [04:33:42 CET] <furq> i've tried it with 50mbps stuff and there's a noticeable lag [04:34:03 CET] <furq> it's not a criticism, there's no way to not have that [04:34:29 CET] <void09> h265 gets decoded in the gpu ? with shaders, not the video decoding asic [04:34:36 CET] <void09> by default, with mpv ? [04:35:05 CET] <furq> that's not up to mpv [04:35:17 CET] <void09> of course it is [04:35:31 CET] <furq> you just turn hwaccel on or off and then it'll be decoded if your system hwaccel supports it [04:35:43 CET] <furq> or not [04:35:50 CET] <void09> assuming you have competent hardware that is [04:36:15 CET] <void09> anyway, back to the topic. remux .ts to .mkv, and then cut, you say? and just ignore the timestamp errors I get ? [04:36:44 CET] <void09> it says something about rewriting timestamps [04:36:57 CET] <void09> I want to get a perfect result, so I am worried about that [04:40:44 CET] <void09> just installed avidemux, it seems to pre-index the .ts file when opening it [04:49:25 CET] <void09> This video uses non-IDR recovery points instead of IDR as keyframes. Picture reordering information in the video stream is not reset at non-IDR frames. The chosen start and end points of the cut may result in playback interruption due to reversed display order of frames if saved in copy mode. [04:49:26 CET] <void09> Proceed anyway? [04:50:20 CET] <void09> more confusion [05:10:25 CET] <void09> thanks for the avidemux tip, it's a very handy program I didn't know about [05:21:51 CET] <void09> furq know some program that can help me find timestamps with video/audio errors? [07:28:38 CET] <classsic> Hi, somebody know what mean "[SAR 2:1 DAR 32:9]" on this info: Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 2:1 DAR 32:9], 521 kb/s, SAR 1:1 DAR 16:9, 5.02 fps, 25 tbr, 16k tbn, 10 tbc (default) [07:29:37 CET] <classsic> the video play squeezed [10:41:14 CET] <locsmif> Hi all. How can I limit output file size to, say.. 50MB and have FFMpeg calculate the required video codec quality reduction parameters? [10:44:20 CET] <Mavrik> classsic, that SAR seems very strange, is that some kind of ultrawide camera? [10:44:39 CET] <Mavrik> locsmif, I don't think ffmpeg can do it for you, but you can easily calculate it based on length with a script/ [11:49:10 CET] <locsmif> Mavrik: thanks [13:50:23 CET] <safinaskar> I am attempting to write c++ program, which will record video from each opened window in x11 (simultaneously). Reasons why I want to write such program are not relevant here, but if you are curious, you can read my comments in this bug report: https://bugs.kde.org/show_bug.cgi?id=412731 . (I discuss Wayland in that bug report, but now I decided to [13:50:24 CET] <safinaskar> stick with X11 for now.) I need to capture each window as a separate thing, so "ffmpeg -f x11grab" is not for me. I already solved problem of actually getting pictures from X server. My question is: how to store them? I will write my own player for such videos in any case, so there is no need to write in some standard format (but outputting [13:50:24 CET] <safinaskar> standard format still would be good idea). Video should be compressed lossless, all frames should be keyframes and I will attach metadata to frames. My previous attempt was this: I generated raw frames in my c++ app and passed them to ffmpeg binary via pipe. ffmpeg converted this video to usual mkv/h264. Unfortunately, there was one problem with [13:50:25 CET] <safinaskar> this solution: my program generated frames only when window changes. So frames were generated rarely. And ffmpeg buffered them. So, if computer suddenly resets, then that buffered frames are lost. So, what to do? Is there way to tell ffmpeg to actually write frame to disk immediately after getting new frame via pipe? Or maybe there is some simple [13:50:26 CET] <safinaskar> way which will enable me to generate compressed video from c++ myself? But please don't say me "just use libav" or something like that. I don't want to spend too much time to this task. I want some hack, which will enable me to write such code easily, I don't want to learn big APIs. Also, as a last resort I will just generate my own custom format, [13:50:26 CET] <safinaskar> which is concatenated ppm images compressed with xz. And I will call xz binary using popen for each image. This is simple. If you can offer something better, but without much complexity (I don't want to learn big APIs!), please offer [14:29:26 CET] <roxlu> hey, I'm trying to download ffmpeg but it seems that the server is down? https://imgur.com/a/kwFBkXZ [14:29:37 CET] <roxlu> this one https://ffmpeg.zeranoe.com/builds/ [14:29:57 CET] <BtbN> That's Zeranoes server, not anything owned or controlled by FFmpeg. [14:31:27 CET] <roxlu> Yeah I figured; only wanted to let ppl know [14:32:03 CET] <BtbN> I don't think there's anyone here that can actively do something about that. [14:32:04 CET] <roxlu> I guess I've to build it myself ^.^ ... it's been a while but can we build ffmpeg w/o cygwin or similar on Windows [14:32:24 CET] <BtbN> It's eaiser to just cross-compile it. [14:32:34 CET] <BtbN> Since you need a shell anyway [14:35:29 CET] <roxlu> yeah, if there is no other solution [14:37:49 CET] <roxlu> hmm https://ffbinaries.com/ [14:39:20 CET] <BtbN> Or just enable WSL and use that. [14:42:52 CET] <roxlu> Have you compiled ffmpeg with WSL before? [14:43:14 CET] <BtbN> You can just get it from the Ubuntu repos, if their version is good enough for your plans [14:43:41 CET] <roxlu> What do you mean from the Ubuntu repos? they provide windows libs? [14:43:51 CET] <BtbN> no [14:43:59 CET] <BtbN> That's the whole point of WSL [14:44:24 CET] <roxlu> hmm what do you mean by "You can just get it from the Ubuntu repos" ? [14:44:36 CET] <BtbN> apt install ffmpeg [14:44:41 CET] <roxlu> ah in WSL [14:45:10 CET] <roxlu> but would I then be able to use those libs in a msvc project? [14:45:15 CET] <JEEB> no [14:45:16 CET] <BtbN> no [14:45:44 CET] <BtbN> You will have to compile ffmpeg with MSVC to be able to use it with that. [14:45:44 CET] <roxlu> hehe ok [14:45:50 CET] <JEEB> no, you don't have to [14:45:55 CET] <JEEB> you can use mingw-w64 just fine [14:45:56 CET] <JEEB> with MSVC [14:45:57 CET] <JEEB> :P [14:46:03 CET] <JEEB> but sure, you can do both with MSVC as well [14:46:07 CET] <BtbN> But then you will be forced to ship two libcs, which potentially clash [14:46:13 CET] <BtbN> would recommend against that [14:46:19 CET] <JEEB> two libcs? [14:46:25 CET] <JEEB> and ship them? [14:46:27 CET] <BtbN> MinGWs one, and MSVC, yes [14:46:36 CET] <JEEB> there is no real libc in mingw-w64 [14:46:50 CET] <JEEB> it has some compatibility functions that the Windows CRT doesn't support [14:46:52 CET] <BtbN> You have to drag around libgcc_s.dll and one or two other files [14:46:57 CET] <JEEB> that is not the CRT [14:47:03 CET] <JEEB> also those can be statically linked just fine :P [14:47:09 CET] <JEEB> just remove the .dll.a from mingw-w64 [14:47:24 CET] <roxlu> ok thanks [14:47:29 CET] <BtbN> Does that even properly work when building just libraries, and not the binaries? [14:47:41 CET] <JEEB> yes [14:47:43 CET] <BtbN> If you intend to use the ffmpeg libs in MSVC, build them with the same msvc version. [14:47:51 CET] <roxlu> so best is to setup mingw (or how that's calle ..msyss, cygwin ... it's been a while ^.^) [14:48:04 CET] <BtbN> If you have msvc already, might as well just use it [14:48:09 CET] <BtbN> Only need a bash [14:48:13 CET] <BtbN> or any shell really [14:48:49 CET] <JEEB> the positive notion with MSVC is that you get the right debug symbols since only llvm mingw-w64 seems to support them? not 100% sure though [14:48:53 CET] <JEEB> technically the libs work JustFine though [14:49:00 CET] <JEEB> and the libgcc_s etc are not the CRT [14:49:11 CET] <JEEB> mingw-w64 can depend on multiple CRTs, by default it still uses msvcrt.dll [14:49:16 CET] <JEEB> you can define that, though [14:49:22 CET] <JEEB> (which windows CRT it picks) [14:49:29 CET] <BtbN> I had plenty of situations where msvc exploded on linking mingw builds libs, because some symbols were defined twice [14:49:47 CET] <roxlu> if only we had something like CMake ^.^ [14:49:47 CET] <JEEB> the only issue I think with MSVC is if you want *static* libs and then link those [14:49:57 CET] <JEEB> roxlu: you still need that shell or cmake or whatever [14:50:06 CET] <JEEB> to generate the build part [14:50:16 CET] <roxlu> cmake can run basically everywhere [14:50:17 CET] <JEEB> it's exactly the same as running configure in a shell [14:50:24 CET] <roxlu> not really [14:50:27 CET] <JEEB> why not? [14:50:28 CET] <BtbN> yeah really [14:50:34 CET] <JEEB> the only thing you don't have is the fancy project file [14:50:53 CET] <roxlu> because now, on windows, I have to figure out how to get a shell that I can use to compile ffmpeg [14:51:05 CET] <roxlu> cmake runs in powershell, cmd which are default on windows [14:51:22 CET] <JEEB> shell .exe is the same as cmake's .exe [14:51:25 CET] <JEEB> it just *feels* different [14:51:27 CET] <BtbN> Feel free to convert the entire build system to cmake then, without causing any regressions on any of the supported platforms. [14:51:35 CET] <roxlu> JEEB: yeah that's true [14:51:43 CET] <JEEB> anyways, for native windows probably msys2? [14:51:48 CET] <roxlu> hehe BtbN I did once, long time ago [14:51:56 CET] <roxlu> ok yeah thanks [14:52:05 CET] <JEEB> also it seems like people are more veering towards meson now [14:52:05 CET] <BtbN> And you tested all the dozens of different systems with hundred of different dep combinations? [14:52:33 CET] <BtbN> I have yet to encounter a meson using project that's not broken in some way [14:52:37 CET] <roxlu> BtbN: no it was just as an experiment; but I know it's not a simple thing [14:52:59 CET] <JEEB> BtbN: anyways, I used to link against MSVC a lot more before, but I think it was mostly about static libs under some very specific circuimstances which I no longer remember :) [14:53:13 CET] <JEEB> I was just mostly arguing because I can clearly see with libmpv and friends that people are linking against it [14:53:47 CET] <JEEB> but yes, if a person really wants to go the full MSVC way (before the only way to get readable debug stuff in MSVS) [14:53:56 CET] <JEEB> then sure, msys2 or something [14:54:47 CET] <JEEB> http://fate.ffmpeg.org/report.cgi?slot=x86_32-msvc14-dll-md-windows-native&… [14:55:01 CET] <JEEB> there's the FATE MSVS 2017 box's command line [14:55:25 CET] <JEEB> the toolchain=msvc is the primary point I think [14:59:06 CET] <roxlu> thanks JEEB I'm going to read up a bit on how to setup an correct environment [15:01:50 CET] <roxlu> btw, what is that fate.ffmpeg.org site? [15:01:58 CET] <JEEB> it's the testing suite [15:02:05 CET] <JEEB> the results get posted there [15:02:47 CET] <roxlu> is that basically compiling ffmpeg on windows? (automated) [15:03:02 CET] <JEEB> on multiple systems and running the FATE test suite [15:03:26 CET] <JEEB> if you look at fate.ffmpeg.org it's got everything from *BSD to linux to windows, x86 to arm to mips :P [15:03:39 CET] <roxlu> ok :) so why not provide those builds as downloadable zips? (like Zeranoe) [15:04:01 CET] <JEEB> because that's not the idea of it, and you don't necessarily want to trust the people running those test nodes [15:04:10 CET] <JEEB> or maybe those test node running people do not want to upload them [15:04:18 CET] <roxlu> oh i see [15:04:30 CET] <JEEB> it is to test 1) building 2) running FATE [15:04:35 CET] <JEEB> that's its purpose [15:05:04 CET] <roxlu> ok [15:30:54 CET] <roxlu> ok so I wanted to give it a try and use msys2 (https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW) there is says to execute mingw64_shell.bat from the msys2 home; but that file is not there [15:32:33 CET] <roxlu> there is a mingw64.exe though but the the docs say not to run the the "MSYS2 Shell". But it's not clear if that's the mingw64.exe though [15:38:37 CET] <JEEB> yea msys2 changed in that sense [15:39:41 CET] <roxlu> Is it 'mingw64.exe' that I need? [15:39:57 CET] <JEEB> no idea :P just whatever gets you a shell started [15:40:09 CET] <JEEB> anyways, you're not building with mingw-w64 so as long as you get the msvc compiler and linker (link.exe) right in the PATH that should be OK [15:40:42 CET] <roxlu> ok :-) .. [15:40:55 CET] <roxlu> hehe remember me saying "not really" before lol ... [15:41:20 CET] Action: roxlu just kidding [16:40:22 CET] <roxlu> ok it's compiling [20:15:09 CET] <roxlu> ok, I've got the .exe, .dll and .lib files but when I try to link with the .lib I get unresolved symbols. though I get them at compile time when using the .lib files. is there something obvious I missed from the documentation? I'm looking at AVCODEC-58.dll and see it has an dependency with MSVCP_WIN.dll. [20:16:27 CET] <JEEB> I think what it does with regards to the CRT depends on the parameters you give the MSVC linker [20:16:43 CET] <JEEB> and most likely your own project has to match in that sense [20:17:18 CET] <JEEB> you should be able to see how things get linked within the FFmpeg build system with make V=1 [20:17:22 CET] <JEEB> that outputs the exact commands utilized [20:18:13 CET] <roxlu> JEEB: it's either with /MT or /MD right? [20:22:29 CET] <JEEB> roxlu: I'd just recommend you check how it's actually linked [20:22:34 CET] <JEEB> make V=1 should do it [20:22:37 CET] <JEEB> when you build [20:22:55 CET] <JEEB> but yes, I think some of those options are also another thing [20:23:10 CET] <cehoyos> rm ffmpeg_exe and make V=1 ffmpeg_g.exe [20:23:19 CET] <cehoyos> rm ffmpeg_g.exe [20:23:41 CET] <JEEB> or remove one of the libraries, yea. to check how those DLLs/LIBs get generated [20:23:58 CET] <JEEB> (or both) [20:24:42 CET] <roxlu> ok going to do that [20:47:27 CET] <roxlu> ok, lets build 64bit libs ^.^ [20:47:59 CET] <roxlu> is there any reason why one would default to 32bit? [20:52:31 CET] <pink_mist> one might be a timetraveller with a computer from 1998 [20:53:08 CET] <roxlu> haha [20:53:33 CET] <JEEB> I'm actually not sure how much the configure sets regarding win32/64 [20:54:43 CET] <JEEB> there seem to be some things like if 32bit -> make it large address aware, or if x86_64 then objformat is win64 and otherwise win32 [20:54:50 CET] <roxlu> I opened a `Native VS 2019 64bit` console and from there the msys shell (as described in the docs) [20:55:15 CET] <JEEB> yea, I think that's how you do it nowadays since you no longer have a convenient env var to add to your PATH [20:55:41 CET] <roxlu> but I think I still need to tell `./configure` that I want a 64bit build [20:55:47 CET] <roxlu> I'm rebuilding now [21:10:35 CET] <Polochon_street> hi! I'm wondering, would it be possible to make a spectrogram of what I'm currently playing on my default pulseaudio output? I got its name by doing `pactl list short sinks` and tried something like ffmpeg -f pulse -fragment_size 128 -sample_rate 48000 -channels 2 -wallclock 0 -i <output_name> -c:v rawvideo -filter_complex "avectorscope"` [21:10:48 CET] <Polochon_street> but then I simply get `alsa_output.usb-DAC_FOR_USB_FOCAL_XS-00.iec958-stereo: Input/output error` (the output name) [21:11:00 CET] <Polochon_street> am I doing something obviously wrong? [21:21:54 CET] <cehoyos> roxlu: FFmpeg's configure script detects if your toolchain defaults to 32 or 64 bit, no need to specify it [21:29:33 CET] <roxlu> cehoyos: thanks, I just noticed that I was using a 32bit env. :# I'm rebuilding again [21:56:47 CET] <roxlu> I got the 64bit dll/libs now ... but ... https://imgur.com/a/uc4mCcV [23:48:29 CET] <trfl> can i somehow use mpeg2_vaapi to encode mpeg1-compliant-ish video? fwict they are fairly similar with the major difference being constraints in mpeg1 which don't exist in mpeg2, so would be cool if you could just transform the bitstream in some way to have mpeg1 decoders take it [23:48:46 CET] <trfl> not expecting this to be fully according to mpeg1 spec of course [23:49:32 CET] <cehoyos> Do you know of an mpeg-1 decoder? [23:49:58 CET] <trfl> the one I intend to use is jsmpeg, but I'm curious about the general case too [23:51:44 CET] <cehoyos> Did you test it with non-interlaced mpeg-2 video? [23:53:04 CET] <iive> trfl, btw, mpeg2 patents have expired recently. in case you want mpeg1 for legal reasons. [23:53:34 CET] <trfl> thanks iive that's good to know :> maybe jsmpeg will take that into consideration and support both out of the box [23:53:59 CET] <trfl> cehoyos, I did and it failed, didn't get any hints in the console so would have to start adding breakpoints to figure out exactly why [23:54:59 CET] <cehoyos> I may misremember but I believe you have to take extra steps to avoid decoding progressive mpeg2video with an mpeg1video decoder [00:00:00 CET] --- Mon Dec 2 2019

1 0