[Ffmpeg-devel-irc] ffmpeg.log.20171102
burek
burek021 at gmail.com
Fri Nov 3 03:05:01 EET 2017
[00:08:44 CET] <dreamy> Hi there, how are you? Is it possible to set the start PTS to be like the unix time? I saw the docs about a filter called setpts but I couldn't see how can I set the initial pts to, let's say, `date +%s`
[00:37:08 CET] <DHE> dreamon: the PTS is intended to be a time reference for the video. it's an integer and must be unique for each frame (for video)
[00:37:24 CET] <DHE> so unless you're making a 1fps slide show with no audio, that's not what you want to do with it
[01:42:10 CET] <dreamy> DHE: yes I know
[01:42:31 CET] <dreamy> thanks =D my idea is to provide an initial pts equals to time(0)
[01:42:47 CET] <dreamy> and then it increases it frame like 30 per second
[01:44:26 CET] <dreamy> each frames adds 1 to the START_PTS
[01:44:33 CET] <DHE> that... doesn't seem very useful...
[01:55:51 CET] <dreamy> DHE: I use the unix epoch as pts to provide a smooth backup streaming option
[01:56:11 CET] <dreamy> [rtmp]-->[packager]---[cdn]
[01:56:36 CET] <dreamy> when a stream_0 goes offline I can serve from stream_1 with almost no hickup
[01:57:10 CET] <dreamy> (even though I rely on the weak link which is the time api and ntp)
[01:57:19 CET] <dreamy> but it's doing good until now
[03:42:30 CET] <geri> hi
[03:42:41 CET] <geri> is there a video codec which takes BGRA ?
[03:49:37 CET] <atomnuker> ffv1
[04:51:13 CET] <geri> atomnuker: re
[04:53:02 CET] <geri> atomnuker: isnt it slower than h269?
[05:10:39 CET] <atomnuker> no, because h269 doesn't exist yet
[05:10:54 CET] <geri> i want to use CV_8UC4
[05:10:59 CET] <geri> but seems not to work
[05:11:13 CET] <geri> when writing to VideoWriter
[05:12:02 CET] <geri> i read: VideoWriter can only write 8 or 24 bit images (not 32bit RGBA)
[05:39:28 CET] <blap>
[05:39:28 CET] <blap> Œ
[05:39:29 CET] <blap> Œ ™€ Œ€€ Ÿ „ ›„ ™€
[05:39:30 CET] <blap> €€Ÿ Œ Œ ŒŒ Œ
[05:39:31 CET] <blap> Œ Œ Œ Œ
[05:39:32 CET] <blap> €€€€€€€€€€€œ Œ Œ Œ Œ›€€œ
[05:39:33 CET] <blap> € ›€€ €€œ›œ€€€€ Œ Œ Œ ™Ÿ
[05:39:34 CET] <blap> Œ € ™€€€€€€Œ €€€Ÿ › ™€€„ €€€ €€€ ™€€€€Ÿ
[05:39:35 CET] <blap> œ › ›€€€ Œ€ €€€œ Œ
[05:39:36 CET] <blap> ›œ›Ÿ ›€€€€€€€œŸŒ ›€€œ™ž€œŸ Œ
[05:39:37 CET] <blap> ™ ™œ €€€€œŸ €€››Ÿ › Œ Œ Œ€€ €€€ €€€Ÿ ›„ ™€
[05:39:38 CET] <blap> €€€ Ÿ €›š €œ€Ÿ€œ Ÿ Œ Œ ›€Ÿ Œ Œ› Œ› „ œ
[05:39:39 CET] <blap> Œ › €€€€€„€„€€€ € › › Œ Œ Œ Œ ™Œ Œ Œ „€€€Ÿ
[05:39:40 CET] <blap> ™ Œ „Ÿ €€ €Ÿ ™œ Ÿ Œ Œ Œ › Œ Œ ™€ ™€
[05:39:41 CET] <blap> œ ™œ ›™€€›€€€€€€€€€ Œ Œ Œ Œ Œ Ÿ Œ €€€„œ Œ
[05:39:42 CET] <blap> € ™€€€€€€€ › €Ÿ Œ ™€€ Œ Ÿ Ÿ œ Œ
[05:39:43 CET] <blap> œ ™œ Œ › ›Ÿ Œ Œ Œ › ™œ €
[05:39:44 CET] <blap> ™Ÿ ™€€ €€
[05:39:45 CET] <blap> ™€Ÿ €› Ÿ
[05:39:46 CET] <blap> š€€Ÿ ™œ›„ ŒŒ ŒŒ Ÿ ™ ™œ Ÿ „„ ™ ›„ ™€
[05:39:47 CET] <blap> œ Ÿ ™€Ÿ Œ Œ ŒŒ Œ ŒŒ Œ
[05:39:49 CET] <blap> Œ Ÿ ŒŸ Œ Œ ŒŒ Œ Œ Œ
[05:39:50 CET] <blap> Œ Œ ŒŒ Œ Œ Œ›€€œ
[05:39:52 CET] <blap> ™ € Œ Œ Œ ŒŒ Œ Œ ™Ÿ
[05:39:53 CET] <blap> ™€€€€„ €€€Ÿ™€€€ €€€Ÿ„€€Ÿ €€€ €€€ €€€ ™€€€€Ÿ
[08:05:53 CET] <arvut> ffoo morning
[08:06:01 CET] <arvut> I have a question about bottlenecks
[08:07:18 CET] <arvut> If I run ffmpeg on a quadcore 4th gen i7, maxing load at 11.0 (I have 8 logical cores), would the bottle neck then be usb3.0 which the read and write medium is connected with, or the cpu running at overload?
[08:07:44 CET] <arvut> speed is 4.72x
[08:10:37 CET] <arvut> And how does the 'speed' of ffmpeg correspond to load and bitrate?
[08:10:50 CET] <arvut> I see it go up and down .1
[08:12:32 CET] <fella> arvut: try to write to your internal hdd/ssd or even to ramdisk - that might clear it
[08:50:31 CET] <arvut> fella: it finished fast, end result is a much smaller file :)
[08:51:01 CET] <arvut> time=02:14:37.40
[09:23:33 CET] <BugzBunny> Hello, I'm using NVENC, which works perfectly here but I can't seem to reduce the FPS it's outputing at. I have tried '-r 30' and '-vf fps=30' from a 60FPS input and neighter seem to work here on my test?
[09:24:57 CET] <BugzBunny> Perhaps I need something like '-vf fps=30,scale=1920x1080'? I can't seem to find documentation that explains if ffmpeg take arguments like this?
[09:26:38 CET] <BugzBunny> Ahh, that seem to do the trick.
[11:42:37 CET] <twid> How to run 'http_multiclient' example given in 'doc/examples' folder?
[11:57:08 CET] <traw> what is the proper way to test 'http_multiclient' example in 'doc/example' folder? thanks
[12:02:55 CET] <DHE> it's meant to be an example to you of how to use the API to accomplish common objectives. in this case, a minimal fork-on-accept HTTP server that serves one file and 404's the rest
[12:38:30 CET] <traw> thanks, but how can client can get file given as first argument to server?
[12:39:47 CET] <traw> what should be the argumets passed to client?
[14:18:00 CET] <fps> hi. i'm looking for a tutorial on how to write an mp4 file from within a c++ application.. i was googling around for a bit but wasn't successful yet :)
[14:18:22 CET] <JEEB> see the examples under doc
[14:18:32 CET] <JEEB> it has muxing examples and decoding and encoding and filtering examples
[14:18:36 CET] <ravikiran> How to select VP8 explicitly in libavformat when trying to write a webm file programatically ? By default when I allocate AVFormatContext, VP9 is selected.
[14:18:45 CET] <fps> JEEB: ok, ty
[14:19:03 CET] <JEEB> ravikiran: video formats aren't picked in that spot until you create a stream...
[14:19:15 CET] <JEEB> and the stream is whatever you have packets with
[14:19:57 CET] <twid> all concept are there but given in different examples
[14:23:05 CET] <ravikiran> I actually receive VP8 encoded RTP packets on my server. I want to write this to a webm file. For that when I initialize the library and allocate AVFormatContext, by default VP9 is selected. Am I missing anything or is there a way to explicitly select VP8 ?
[14:23:42 CET] <JEEB> ravikiran: by just opening the avformatcontext you're not yet getting anything. there should be no streams
[14:26:43 CET] <JEEB> ravikiran: so avformat_new_stream and then set the codec parameters
[14:27:09 CET] <JEEB> you can give an AVCodec to avformat_new_stream
[14:27:16 CET] <JEEB> and then you can set additional values in the parameters
[14:27:19 CET] <JEEB> (if needed)
[14:33:05 CET] <ravikiran> okay thanks. But upon calling avformat_alloc_output_context2() AVFormatContext is allocated. Now in that, AVFormatContext->oformat->video_codec contains VP9 AVCodecID. But I want it to be VP8.
[14:35:17 CET] <JEEB> that is the default one if you create an encoder
[14:35:21 CET] <JEEB> it has nothing to do with your streams
[14:35:24 CET] <JEEB> you have to ADD A STREAM
[14:35:27 CET] <JEEB> I just told you the APIs
[14:38:13 CET] <ravikiran> okay thanks.
[14:38:36 CET] <twid> howt to test 'http_multiclient' example? I am able to run server with command(./http_multiclient file:///mnt/proj/out.avi http://localhost:9999), but don't know how to run client. thanks
[14:39:33 CET] <twid> what should be the arguments to run ./http_multiclient'
[14:40:57 CET] <twid> cause what I understand is first args should be file and second should be server url, I dont know where am I going wrong
[14:42:43 CET] <c_14> That's just an example and the internal logic isn't very good, the requested filename has to match exactly with the path given as the first argument
[14:45:03 CET] <twid> thanks, What command you type to test http_multiclient?
[14:45:22 CET] <BugzBunny> Hello, I am having issue with ffmpeg nvenc, snipped "-bv 3500k -minrate 2000k -maxrate 3600k", full here https://hastebin.com/eyezacelod.go. When I introduce movement in a video, the bitrate skyrockets to 15000k, completely ignoring -maxrate? Am I doing this properly?
[14:46:07 CET] <c_14> twid: ./a.out out.mkv http://localhost:8080
[14:46:17 CET] <c_14> then mpv http://localhost:8080
[14:47:37 CET] <twid> should it be somthing like this server command==> ./http_multiclient in.avi http://localhost:9999 and CLient command ==> ./http_multiclient out.avi http://localhost:9999
[14:48:05 CET] <c_14> http_multiclient does not operate as a client
[14:48:07 CET] <c_14> It's only a server
[14:48:14 CET] <sfan5> BugzBunny: have you tried with -cbr ?
[14:48:16 CET] <c_14> the client is either a video player or ffmpeg
[14:48:16 CET] <DHE> it's a server that serves multiple clients
[14:49:04 CET] <BugzBunny> sfan5: I was looking online, but I am not nvenc supports cbr? I'll check again
[14:49:39 CET] <sfan5> if it doesn't support cbr then why are trying to force it to?
[14:50:02 CET] <sfan5> -cbr is listed in ffmpeg -h encoder=nvenc so i doubt that anyway
[14:50:09 CET] <twid> ok
[14:50:25 CET] Action: BugzBunny is checking here
[14:53:46 CET] <BugzBunny> Alright, -rc cbr seem to be working...
[14:54:00 CET] <BugzBunny> sfan5: thanks
[14:54:36 CET] <twid> Thankd c_14.
[15:00:34 CET] <twid> I am trying to write my own media server based on ffmpeg. Is it possible to redirect one client to another client?
[15:02:02 CET] <c_14> "redirect"?
[15:04:35 CET] <DHE> unless you need super-low latency, you might be better served with things like MPEG-DASH and the web server of your choice.
[15:07:03 CET] <twid> yes, I mean if some other client C1 serving streamC and if Client C2 request media server about StreamC, then is it possible to redirect C2 to C1 for StreamC?
[15:10:44 CET] <c_14> If you build it on top of HTTP you can send a 301 redirect
[15:11:44 CET] <twid> ok
[15:12:21 CET] <twid> let me work on that, If I can get it working
[15:12:27 CET] <twid> thanks c_14
[15:28:08 CET] <drathir> hi all...
[15:29:52 CET] <drathir> guys im wonder if there is a way to convert mp4s to format acceptable by mkv container?
[15:30:20 CET] <JEEB> most things you can stick into ISOBMFF (mp4) you can also stick into matroska
[15:30:27 CET] <JEEB> ffmpeg -i input.mp4 -c copy out.mkv
[15:30:47 CET] <c_14> maybe with -map 0 depending on if the input has more than one video/audio/subtitle/*
[15:30:52 CET] <drathir> kind of Tag mp4s incompatible with output codec id '94208'
[15:32:07 CET] <drathir> c_14: that mean copy not handling multiple tracks?
[15:32:55 CET] <c_14> by default ffmpeg will only map one track of type subtitle/video/audio each
[15:33:06 CET] <c_14> if you want more than that you have to explicitly tell it
[15:33:13 CET] <c_14> (or less)
[15:34:19 CET] <drathir> c_14: k that could explain the issue... i thought it takes 1:1 all available streams of type where copy used, thanks a lot...
[15:35:06 CET] <JEEB> yea the stream selection by default takes "best stream of type X"
[15:35:14 CET] <JEEB> whatever the definition of "best" in that case is :)
[15:35:29 CET] <JEEB> `-map 0` just tells it "take everything from input file nr1"
[15:53:28 CET] <drathir> JEEB: looks like drop subtitles helped...
[15:54:09 CET] <BobbyJohnson> Hi guys, I have a video that I play on VLC and the facebook player, but sometimes it's laggy, and totally randomly. Not sure what to fix in the video.. I don't know if it's the right place to ask, but if someone has and idea to where to look at, or where to ask help..
[15:54:55 CET] <JEEB> drathir: if it's 3GPP timed text you might need to convert that to srt or ass
[15:55:05 CET] <JEEB> -c:s srt
[15:56:39 CET] <drathir> JEEB: indeed i thought to extract from mp4 and convert to srt and add to mkv... really ? ffmpeg support convert on the fly of subtitles? o.O
[15:56:55 CET] <JEEB> yes?
[15:59:00 CET] <drathir> JEEB: thats nice save a lot of time... thanks for tip...
[16:04:39 CET] <BobbyJohnson> Does anyone know a forum where I can ask help because my video seems to be badly encoded ?
[16:05:58 CET] <Mavrik> well you can always pastebin mediainfo here ;)
[16:06:50 CET] <BobbyJohnson> mediainfo ?
[16:07:10 CET] <Mavrik> yes, run mediainfo on your problematic video.
[16:07:59 CET] <BobbyJohnson> Okay doing that, thanks !
[16:16:49 CET] <BobbyJohnson> Mavrik: https://pastebin.com/57q9mrGg
[16:17:49 CET] <Mavrik> Doesn't seem to be anything obviously wrong with it.
[16:18:56 CET] <BobbyJohnson> Hm okay.. do you know why a player would lag randomly with it ?
[16:19:16 CET] <CoReX> what player ?
[16:21:49 CET] <BobbyJohnson> VLC, Facebook
[16:23:44 CET] <Mavrik> on which platform?
[16:27:39 CET] <BobbyJohnson> Mac OSX
[16:28:09 CET] <BobbyJohnson> I can give you a link to the video if you want ? Via Dropbox ?
[16:28:24 CET] <BobbyJohnson> its 40 secs, 15mb
[16:35:41 CET] <BobbyJohnson> Weird thing is that the video plays nice on my phone, but it's super laggy on desktop..
[16:37:01 CET] <dziadu_> hi, I am trying to cut a video using
[16:37:04 CET] <dziadu_> ffmpeg -ss 14:32.0 -i input.ogv -async 1 -to 0:21:16.120 output.ogv
[16:37:33 CET] <dziadu_> but iy instead of making around 7 min long video makes it 21 min long, starting at 14:32 of the inpit one
[16:37:37 CET] <dziadu_> what is wrong?
[16:38:26 CET] <dziadu> hmm, now I did
[16:38:39 CET] <dziadu> ffmpeg -i input.ogv -ss 14:32.0 -async 1 -to 0:21:16.120 output.ogv
[16:38:41 CET] <dziadu> and it worked...
[16:39:35 CET] <c_14> if you use -ss as an input option and -to as an output option you need -copyts
[16:39:42 CET] <c_14> because -ss as an input option rewrites the timestamps
[16:39:47 CET] <c_14> so -to works like -t would
[16:39:50 CET] <twid> does ffmpeg support webrtc?
[16:40:00 CET] <dziadu> c_14: thanks for explanation
[16:46:42 CET] <BobbyJohnson> Mavrik: any idea why the player would lag ? If not, do you know a forum or something where I could post my video so people help me to find what's wrong with it ?
[16:47:46 CET] <Mavrik> No idea, I'd recommend you test on another machine first.
[17:01:44 CET] <BobbyJohnson> Mavrik : lagging on my windows 10 also, I have a good processor and a good graphic card.
[17:40:42 CET] <astedq> is it possible to integrate webrtc with ffmpeg?
[17:41:26 CET] <relaxed> you can use a loopback device to send video through webrtc
[17:43:16 CET] <kepstin> ffmpeg doesn't support talking directly to webrtc endpoints, but it's certainly used (as a library) by some of the software that does.
[17:45:50 CET] <astedq> ok, is the any example or open source code base to study?
[18:21:16 CET] <kitsu> Hey! I wanted to replace every N frame of the video with my images. E.g if I have 4 images and want to replace every 200-th then 200,400,600,800 -th frames are replaced.
[18:21:27 CET] <kitsu> I found this post: https://stackoverflow.com/a/42687231 that is almost solve my problem
[18:22:13 CET] <kitsu> Could you help me with the param that specifies different images
[18:56:38 CET] <JnvSor> Hi, I can't find any documentation on changing mkv chapters in ffmpeg - is it possible?
[19:25:56 CET] <durandal_1707> JnvSor: no
[19:27:55 CET] <JnvSor> Ok, thanks anyway
[19:43:01 CET] <kiroma> --enable-lto and --enable-shared are pretty slow.
[19:43:19 CET] <kiroma> Each lib is linked one after another instead of in parallel.
[19:45:51 CET] <BtbN> yes, sounds about right?
[19:46:34 CET] <DHE> can you LTO against shared libraries? normally it's not possible to use them for a static link in the first place
[19:47:29 CET] <BtbN> The slow optimization happens at link time, so obviously linking the libs is slow
[19:49:12 CET] <kiroma> But I have -j4 specified, why am I limited to linking one library at a time?
[19:49:28 CET] <DHE> there's only 1 link step
[19:49:29 CET] <kiroma> I never had issues with LTO on shared libs.
[19:49:44 CET] <BtbN> What makes you think it does? It's just slow, and some libs are way smaller than others, so finish sooner.
[19:51:19 CET] <kepstin> lto doesn't do any optimization between shared libs and the code that uses it - it has to allow you to replace the lib at runtime, afterall
[19:52:06 CET] <sfan5> you should be able to use -flto=4 for 4 threads
[19:52:10 CET] <sfan5> according to https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto
[19:52:34 CET] <kiroma> Oh, didn't notice that
[20:05:11 CET] <Cvfk> Newbies question. I Want to integrate ffmpeg,e with external http server which will be responsible to streaming and recording, which embeddable webserver should preferred, and how to transmitted head
[20:12:30 CET] <DHE> Cvfk_: any is fine. apache and nginx are popular ones. the latter is my favourite. it's just a matter of storage for the data which can be a ramdisk
[20:17:40 CET] <Cvfk_> Ok. I want my app to be able to change capturing and encoding parameters at run time, but nginx directly runs ffmpeg command so I thing I need to write complete Nitin module for that, am I going in right direction?
[20:19:16 CET] <Cvfk_> *nitin=nginx
[20:35:51 CET] <earnestly> Ever since http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=a606f27f4c610708fa96e35eed7b7537d3d8f712 when using mpv I now get to enjoy my logs getting spammed with this message every second.
[20:36:27 CET] <JEEB> so you seek every second?
[20:36:31 CET] <earnestly> No
[20:36:47 CET] <earnestly> I still don't see why a library thinks it's appropriate to print /anything/
[20:37:00 CET] <JEEB> it's not printing
[20:37:02 CET] <JEEB> mpv is
[20:37:13 CET] <earnestly> This isn't it? av_log(NULL, AV_LOG_WARNING, "Invalid return value 0 for stream protocol\n");
[20:37:15 CET] <earnestly> Hm
[20:37:19 CET] <JEEB> the library provides logging functionality and mpv tells it to call its logger
[20:37:25 CET] <earnestly> Sigh
[20:37:28 CET] <JEEB> which then ends up in your terminal
[20:37:30 CET] <earnestly> How can mpv control this?
[20:37:50 CET] <JEEB> well to be honest I wonder how you end up with EOF every second
[20:37:53 CET] <JEEB> image files?
[20:38:24 CET] <JEEB> earnestly: anyways mpv API update happened @ https://github.com/mpv-player/mpv/pull/5033
[20:38:32 CET] <JEEB> so after that it shouldn't end up there
[20:38:34 CET] <earnestly> JEEB: Here's a test case: mpv https://twitch.tv/spammiej
[20:39:23 CET] <JEEB> basically zero vs AVERROR_EOF with EOF
[20:39:29 CET] <earnestly> I know
[20:39:43 CET] <JEEB> seems like mpv newer than e9dc4ac should not log anything since zero shouldn't be output any more for WOF
[20:39:46 CET] <JEEB> *EOF
[20:40:26 CET] <earnestly> Newer, at least latest, mpv no longer builds against ffmpeg (or ffmpeg-git)
[20:40:30 CET] <earnestly> Due to their fork :/
[20:40:42 CET] <JEEB> well yea, everyone has fun.
[20:40:45 CET] <earnestly> [Not that I blame them, ffmpeg should never break API]
[20:40:56 CET] <earnestly> (libraries should never break API, more generally)
[20:41:00 CET] <JEEB> no, this was not really the change that broke the camel's back
[20:41:09 CET] <earnestly> Things like llvm, mupdf and ffmpeg are some of the worst to deal with
[20:41:18 CET] <JEEB> it was the hwdec stuff if you have looked at the goddamn mailing list discussions
[20:41:32 CET] <earnestly> A lot of projects I used to be involved with have some pretty serious hatred for ffmpeg :P
[20:41:40 CET] <JEEB> sure, we suck
[20:41:50 CET] <JEEB> we fucking suck and I should commit suicide for trying to work on it
[20:41:50 CET] <earnestly> Because ffmpeg thinks deprecation notices are "good enough", when in fact the API should never have changed
[20:41:55 CET] <earnestly> E.g. introduce new symbols instead
[20:41:58 CET] <earnestly> Like Linux does
[20:42:03 CET] <earnestly> epoll_create1, for example
[20:42:04 CET] <JEEB> yes, that is done as well
[20:42:10 CET] <JEEB> anyways the EOF thing was a disaster
[20:42:16 CET] <JEEB> I fucking agree with you on that
[20:42:17 CET] <earnestly> Of course it was
[20:42:20 CET] <earnestly> No notice, nothing
[20:42:29 CET] <JEEB> but it is not the reason why wm4 did his fork
[20:42:36 CET] <JEEB> he did mention the EOF fiasco on the fucking commit message
[20:42:42 CET] <JEEB> but the CUVID bullshit was the bigger reason
[20:42:53 CET] <earnestly> Oh I'm aware of wm4's long standing issues, and how this has been a storm waiting to happen
[20:42:55 CET] <JEEB> unfortunately I just don't fucking know about that shit
[20:43:05 CET] <JEEB> so I couldn't comment on that motherfucking patch set
[20:43:07 CET] <JEEB> so ytea
[20:43:21 CET] <earnestly> I don't even mind building ffmpeg from git, to use mpv git. But now that even fails, so I have to fall back on standard releases :(
[20:43:52 CET] <earnestly> JEEB: Say, has ffmpeg looked into things like abi-compliance-checker? It's something glibc uses to help spot any potential issues
[20:44:03 CET] <JEEB> I think someone was running that but then died off
[20:44:04 CET] <earnestly> https://sourceware.org/glibc/wiki/Testing/ABI_checker
[20:44:26 CET] <JEEB> and yes, there should be fucking CI running on at least some arch before a patch set gets merged
[20:44:31 CET] <JEEB> but hey, I don't fucking control that shit
[20:44:35 CET] <JEEB> and the EOF shit didn't break FATE
[20:44:37 CET] <earnestly> There is this site, I think by the author, which keeps some tracking: https://abi-laboratory.pro/tracker/timeline/ffmpeg/
[20:44:37 CET] <JEEB> so fuck that
[20:45:29 CET] <earnestly> Currently ffmpeg-mpv causes libavformat bump from 57 to 58, so I can't use that as my system ffmpeg either without relinking a lot of big stuff (webengine for example, blender, etc.)
[20:46:06 CET] <JEEB> also the EOF bullshit didn't break fucking ABI + due to seemingly how the API was documented was not easy to notice as a breakage (not that I am providing reasonings for nicolas to have merged that first-timer's thing like that)
[20:46:57 CET] <JEEB> anyways, I don't know what you want from me - as you can see I was the one that then pushed nicolas's "fix" in to get some sort of goddamn closure on the EOF fiasco
[20:47:03 CET] <BtbN> It actually didn't break documented API/ABI. But the assumed undocumented behaviour was very widely used.
[20:47:42 CET] <earnestly> I'll temporarily raise mpv's warning level so hopefully it doesn't print this message so frequently. Thanks for pointing out the path. I just get the hives when I see printing in libraries due to vaapi doing this for years
[20:47:54 CET] <JEEB> also as far as I can tell FFmpeg APIs recently have been more stable than ever :P
[20:48:02 CET] <BtbN> And I think it's a good thing ffmpeg actually removes deprecated stuff, instead of dragging it along forever. Then you end up with an unmaintainable mess. Just look at the WinApi
[20:48:22 CET] <BtbN> 2 years deprecation phase seems generous enough
[20:48:22 CET] <earnestly> BtbN: You should watch the talk by the wonderful Michael Kerrisk on designing API. It's about the Linux kernel, from fosdem 2016: https://www.youtube.com/watch?v=DOZZOLHQpd0
[20:48:30 CET] <JEEB> the most recent stuff was the push/pull decoding and encoding APIs
[20:48:36 CET] <JEEB> and you still have your darn encode4
[20:48:39 CET] <earnestly> He has examples which are not too dissimilar to what happened
[20:48:40 CET] <JEEB> and decode2
[20:48:56 CET] <earnestly> JEEB: People I know tend to like ffmpeg, but they think the API is horrible :(
[20:48:59 CET] <BtbN> The EOF thing was pretty much an accident
[20:49:08 CET] <JEEB> which are deprecated I think, but will be there for at least two+ years
[20:49:17 CET] <JEEB> which I think is goddamn fair
[20:49:26 CET] <earnestly> BtbN: Yeah, and now like any good engineer you have to try and understand why that mistake was allowed to happen and think about how to prevent it happening again
[20:49:39 CET] <JEEB> more API tests that are automated
[20:49:47 CET] <JEEB> CI for at least some goddamn architectures
[20:49:55 CET] <JEEB> FATE is great but if you fixed ffmpeg.c then hahaha
[20:49:55 CET] <earnestly> Sounds good, I think the more automated you can have testing of APIs, the better
[20:49:56 CET] <durandal_1707> earnestly: the bump is part of ffmpeg too
[20:50:02 CET] <earnestly> durandal_1707: Yeah I just noticed :(
[20:50:06 CET] <BtbN> Well, with a mailinglist-based patch-submission system CI is hard to impossible
[20:50:20 CET] <JEEB> BtbN: you'd have to do it on pushes I guess
[20:50:22 CET] <JEEB> which is lol
[20:50:25 CET] <earnestly> BtbN: I'm surprised people who write patches don't make sure it works locally
[20:50:37 CET] <JEEB> well the problem with EOF is that it *works* locally
[20:50:41 CET] <JEEB> since you made fftools works
[20:50:45 CET] <JEEB> and many API users will work
[20:50:52 CET] <earnestly> But yeah, if engineering as taught us anything, it's relying on humans to do the right thing is not going to end well
[20:50:52 CET] <BtbN> Nobody is going to test a patch so in-depth that that subtle change would have been noticed
[20:50:53 CET] <JEEB> as long as you don't override the AVIO
[20:51:03 CET] <earnestly> But even now
[20:51:15 CET] <earnestly> Deprecation on symbols which have a new AV_ prefix
[20:51:26 CET] <BtbN> It was well known and kind of expected that those EOF changes break some things
[20:51:30 CET] <BtbN> the plan was to find them and fix them
[20:51:50 CET] <earnestly> This is breaking a lot of stuff now that the deprecation period of over, and they can't just use the new names. They have to support both in order to work on multiple versions of ffmpeg
[20:52:29 CET] <BtbN> So what do you suggest instead? Never fix mistakes of the past, and drag them along forever?
[20:52:33 CET] <earnestly> Leave both names
[20:52:35 CET] <earnestly> Forever
[20:52:37 CET] <earnestly> Yes
[20:52:44 CET] <earnestly> Forever. This is your mistake, not others
[20:52:45 CET] <BtbN> That would end up with a horrible mess which I'd refuse to maintain.
[20:52:58 CET] <earnestly> Then don't make mistakes you can't be responsible for?
[20:52:59 CET] <BtbN> ffmpeg is not WinAPI 2.0
[20:53:05 CET] <earnestly> Linux is the same
[20:53:10 CET] <JEEB> realistically though, if you have 2+ years of deprecation
[20:53:30 CET] <JEEB> you have at least one new LTS version of ubuntu out for example, and/or debian most likely
[20:53:35 CET] <earnestly> JEEB: Personally, I say fuck the old versions. I'm pretty militant about using latest everything
[20:54:06 CET] <earnestly> I wish mpv didn't feel any obligation to support multiple versions of ffmpeg, or retroarch, or anyone else
[20:55:00 CET] <JEEB> you can still support multiple versions of FFmpeg even if you don't have a very wide array of things. There's a limit, though, of course. ffms2 recently cleaned up a lot of really old version related stuff
[20:55:08 CET] <earnestly> JEEB: It's not about the deprecation though, it could be 10 years. Eventually someone is going to have to ifdef between two (or more) versions of ffmpeg
[20:55:26 CET] <JEEB> ...
[20:55:39 CET] <JEEB> you just went beyond any goddamn LTS distro like centos
[20:55:53 CET] <earnestly> Yeah, and you know my personal opinion on it
[20:56:07 CET] <earnestly> But some projects really have a thing for being portable everywhere
[20:57:00 CET] <earnestly> Oh well, in the end of the day, mpv is now a mess to work with reasonably because their attitude is that every project using ffmpeg should just statically link it
[20:57:57 CET] <JEEB> given that you are getting a new release every couple of months you will be compatible for quite a long time after the feature becomes available that you have to migrate to it. in that sense whatever the goddamn current deprecation period is sounds pretty darn good for me
[20:58:11 CET] <JEEB> old distros will not get new versions of your fancy app packaged, anyways
[20:58:45 CET] <JEEB> and yes, feel free to herp a derp at people who most likely had nothing to dow ith the thing that you goddamn hate about this fucking awful project
[20:58:50 CET] <JEEB> vittu pekrele
[20:59:17 CET] <earnestly> :D
[20:59:56 CET] <JEEB> go yell at nicolas or someone else if you really fucking care; or if you are a fucking programmer chime into the thread with the fucking deadlock between wm4 and michaelni. I just fucking technically didn't fucking have enough fucking time to fucking weigh on that thing
[21:00:24 CET] <earnestly> I don't hate ffmpeg tbh. I dislike all libraries that break API recklessly. ffmpeg is far from the worst in this regard. Gnome's libvte broke API because the developer felt like changing the order of formal parameters. mupdf breaks everthing all the time. llvm cannot be used with most projects reasonably unless they pin against a specific version
[21:00:58 CET] <earnestly> everything*
[21:00:58 CET] <BtbN> The ffmpeg API is stable, unless accidents happen
[21:01:15 CET] <BtbN> ABI breaks on major bumps, but that's intended.
[21:01:23 CET] <earnestly> BtbN: https://abi-laboratory.pro/tracker/timeline/ffmpeg/ this seems to indicate that between releases ffmpeg is pretty stable
[21:01:45 CET] <earnestly> Except every time you're not 100%, that's another #ifdef in someone elses codebase
[21:01:54 CET] <earnestly> There has to be a balance somewhere
[21:02:30 CET] <earnestly> Why don't we see major bumps when backwards compatibility drops?
[21:02:44 CET] <BtbN> That's what they indicate?
[21:02:55 CET] <BtbN> incompatible changes are only allowed during a major bomp
[21:03:05 CET] <earnestly> 3.3 to 3.4 was with a year. No major bumps, and two ABI breakages
[21:03:09 CET] <earnestly> within*
[21:03:34 CET] <BtbN> new symbols are not an ABI break
[21:03:58 CET] <earnestly> BtbN: Ah, I meant to only include removed symbols sorry
[21:04:13 CET] <earnestly> Is master going to be 4.0 then?
[21:04:20 CET] <JEEB> it will be whatever
[21:04:25 CET] <BtbN> 4.0 or 3.5, not decided yet
[21:04:26 CET] <JEEB> currently it's "3.5n" I think?
[21:04:33 CET] <earnestly> Humans shouldn't be allowed to version anything ._.
[21:04:51 CET] <earnestly> Hm
[21:04:57 CET] <BtbN> Bumping the major version on a major bump seems like a good idea to me
[21:05:16 CET] <JEEB> earnestly: anyways, since you herp a derp at people think how you'd enjoy replying to this shit https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218434.html https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218438.html https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218441.html
[21:05:29 CET] <JEEB> you can fscking feel the condescending tone
[21:05:46 CET] <BtbN> That ABI breakage site is mostly wrong as well
[21:05:47 CET] <earnestly> JEEB: Wow that reply
[21:05:55 CET] <earnestly> BtbN: What's wrong?
[21:06:22 CET] <BtbN> looking as the stuff it reports for 3.4, it complains for example about AVCOL_SPC_NB having changes. Which is for internal use only and not part of the public API/ABI.
[21:06:24 CET] <earnestly> BtbN: I mean, granted tracking ABI/API breakage is a difficult task. This tool could be getting it wrong too
[21:06:32 CET] <earnestly> BtbN: It's automated
[21:06:45 CET] <earnestly> BtbN: So, it could only have poked what the API expresses to it
[21:06:56 CET] <earnestly> It wouldn't touch non-API functions/symbols
[21:07:11 CET] <BtbN> And it complains about a new fields being added to AVCodecContext, which would now not be properly initialized by old builds
[21:07:27 CET] <BtbN> Which is wrong, the size of that struct is not part of the ABI, there are allocator functions for it for that exact reason
[21:07:32 CET] <earnestly> ncurses is an example of this, they don't type anything, so it's api-tester can generate bogus test cases for every API function ncurses has which results in segfaulting
[21:07:39 CET] <earnestly> Because ncurses has no precondition checking at all
[21:07:55 CET] <earnestly> E.g. https://ptpb.pw/PGWh
[21:08:20 CET] <earnestly> BtbN: Why is the structure public then?
[21:08:34 CET] <BtbN> Because C has no means of making stuff private
[21:08:42 CET] <earnestly> 'static'
[21:08:51 CET] <BtbN> For struct fields?
[21:08:56 CET] <earnestly> For structs
[21:09:08 CET] <BtbN> That's not how that works
[21:09:09 CET] <JEEB> you can have two separate definitions of a struct
[21:09:17 CET] <JEEB> one in the public header and one in the private one
[21:09:22 CET] <JEEB> but that can also be "fun"
[21:10:01 CET] <BtbN> And the fields are part of the API and meant to be accessed by users
[21:10:10 CET] <BtbN> It's just that the size of the struct is not
[21:10:24 CET] <earnestly> The size is part of the ABI though, which is why changing it breaks ABI
[21:10:29 CET] <BtbN> So applications which are aware of the field can use it. New fields are only added at the end of the struct
[21:10:36 CET] <BtbN> The size is explicitly not part of the ABI
[21:10:44 CET] <earnestly> explicitly or not
[21:10:45 CET] <BtbN> You only ever allocate those structs by calling ffmpeg functions
[21:10:59 CET] <BtbN> If you allocate the struct yourself, you are using the API wrong
[21:11:16 CET] <BtbN> And ffmpeg itself always knows the correct size.
[21:11:19 CET] <JEEB> basically technically it is an ABI break, but the API usage requires you to utilize the helper functions
[21:11:20 CET] <earnestly> BtbN: You said above that fields are part of the API, meant to be accessed by users
[21:11:29 CET] <BtbN> Yes, of the API
[21:11:31 CET] <BtbN> but not of the ABI
[21:11:37 CET] <earnestly> But it still breaks the ABI regardless
[21:11:38 CET] <BtbN> Adding fields to the end of a struct does not break anything
[21:11:56 CET] <BtbN> Adding them in the middle does, but that's not been done
[21:11:59 CET] <earnestly> I.e. a program built against on version of ffmpeg's library will fail on another
[21:12:04 CET] <BtbN> no it won't
[21:12:10 CET] <BtbN> Unless it misuses the API
[21:12:15 CET] <earnestly> Hm
[21:12:17 CET] <JEEB> earnestly: if someone ignores the API usage guidelines, yes. But it's seriously hard to get it to work properly
[21:12:47 CET] <JEEB> earnestly: basically since that stuff only gets allocated by FFmpeg's libraries themselves in the proper case (allocate_contextX)
[21:13:01 CET] <JEEB> which also initializes non-public things
[21:13:23 CET] <BtbN> We should add something to those structs which size is not known, so trying to allocate it yourself plain fails.
[21:13:36 CET] <earnestly> heh
[21:14:02 CET] <earnestly> DJB style of defensive programming
[21:14:03 CET] <BtbN> Just some internal-header-only struct embedded at the very end
[21:14:19 CET] <JEEB> so yes, technically it's an ABI break in the sense that if the API user was allocating those things it would break against newer library versions
[21:14:22 CET] <earnestly> To be fair, it must be annoying that you can't express this nicely in C
[21:14:44 CET] <JEEB> but as far as the API goes, it's really hard not to make it segfault if you allocate that stuff yourself
[21:14:46 CET] <BtbN> C is all about following the defined guidelines on how to use some API
[21:14:47 CET] <JEEB> :P
[21:14:53 CET] <BtbN> If you don't follow them, you end up with breakage
[21:15:16 CET] <earnestly> Sure, and I don't mean to invoke Rust or C++ or something else, because I don't think they can express this nicely either
[21:15:34 CET] <BtbN> Someone tried to re-implement parts of ffmpeg, I think the VP9 decoder, in Rust
[21:15:41 CET] <BtbN> And, oh surprise, it was magnitudes slower
[21:15:53 CET] <sfan5> but hackernews said rust was good?!
[21:15:53 CET] <JEEB> kostya made a nice post about implementing speed-critical stuff in rust
[21:15:57 CET] <earnestly> Ultimately I wish people didn't feel obliged to support ancient versions of everything because of distros like debian or centos
[21:16:12 CET] <earnestly> sfan5: Have you considered rewriting it in rust?
[21:16:20 CET] <JEEB> earnestly: https://codecs.multimedia.cx/2017/08/rust-optimising-decoder-experience/
[21:16:24 CET] <earnestly> The only language I think did this nicely is Ada, and it's limited
[21:18:00 CET] <earnestly> BtbN: And it uses unsafe blocks :P
[21:18:02 CET] <JEEB> also currently the only way to do shared libraries with rust seems to be C ABI, which has its limitations
[21:18:16 CET] <JEEB> granted, same issue with many other modern things
[21:18:28 CET] <earnestly> Oh, Rust is fucking way immature
[21:18:33 CET] <earnestly> It literally cannot even be packaged
[21:18:46 CET] <BtbN> not being packageable is not immature, it's modern!
[21:18:47 CET] <earnestly> Debian's solution to this is to actually package the source code
[21:19:43 CET] <earnestly> BtbN: Every little stupid thing in Rust gets discussed for what must be larger than all of Russian litrature
[21:20:00 CET] <earnestly> Even obviously stupid things like making stdout O_NONBLOCKING
[21:21:12 CET] <earnestly> BtbN: Modern languages all seem to need their own snowflake language package managers, something that really riles me up. A mark of a good language is how easy it can be integrated into a real system without invoking custom, half-arsed (they all are) package managers
[21:21:29 CET] <earnestly> Ironically the easiest language to package is C
[21:22:09 CET] <cryptodechange> Are there any factors during encode that can cause stuttering?
[21:22:26 CET] <cryptodechange> I'm not sure if I'm paranoid, seeing things, it being the player or not
[21:22:33 CET] <earnestly> BtbN: Either way, that Kerrisk talk is nice. This Nicolas could learn a thing or two from it for sure
[21:22:42 CET] <cryptodechange> I see a stutter, rewind it and its gone, so probably the player/my system
[21:24:58 CET] <earnestly> JEEB: ("example doc/examples/avio_reading.c" hehe)
[21:26:18 CET] <JEEB> but yes, I would love a goddamn CI because for example I'm not sure if I have the space or time to do a full FATE run
[21:26:56 CET] <JEEB> I'd like to at least know that on x86_64 linux I don't break crap with a patch before posting it
[21:27:08 CET] <earnestly> JEEB: [Another pet idea I have is about developer bubbles. A bug report of one may seem minor but can often have 100+ users affected behind it. Those who simply don't know, or don't get involved. It could be a maintainer speaking on behalf of potentially thousands. It happens in freetype2 a lot as well, changes happen in seeming isolation and they seem almost shocked when even one person starts
[21:27:10 CET] <earnestly> complaining about breaking their setup :P]
[21:28:14 CET] <earnestly> JEEB: Fwiw, I set msg-level=all=error for mpv which prevents printing all warnings. It works around it for now, thanks
[21:28:47 CET] <JEEB> anyways, FFmpeg is one of the sane libraries with regards to logging. you get callbacks that you can configure to put the logs into your framework
[21:28:59 CET] <JEEB> so the framework calls your callbacks with the message or whatever
[21:30:26 CET] <earnestly> Yeah I see that now, sorry for blaming ffmpeg.
[21:30:33 CET] <sfan5> earnestly: many people consider the "<language>-specific package manager handles everything from downloading to building to linking approach" good, and i can't fault them for it "npm install left-pad" is indeed easier than hoping debian does not have a hopelessly outdated version of whatever library you want to use
[21:30:41 CET] <BtbN> JEEB, patchwork can do CI. Intel does that for their gfx stack
[21:30:45 CET] <earnestly> sfan5: I can fault them for it
[21:30:49 CET] <BtbN> But people don't really use patchwork
[21:30:52 CET] <sfan5> but i'm very much used to the C way of "developer handles linking", it just feels right
[21:31:00 CET] <JEEB> BtbN: I only use it to grab the patches
[21:31:03 CET] <earnestly> sfan5: But at the same time I do also think distributions like Debian are actively dangerous
[21:31:05 CET] <JEEB> because it's simpler than with my e-mail client :P
[21:31:07 CET] <sfan5> it also discourages the library hell javascript devs made for themselves (by making dependencies non-trivial)
[21:31:35 CET] <earnestly> (Also deb/rpm formats severely discourge any investment by ordinary users to learn and use)
[21:31:54 CET] <JEEB> I think rpm was relatively simple for a person who develops software
[21:31:59 CET] <JEEB> specfile and run crap over it
[21:32:05 CET] <JEEB> deb on the other hand
[21:32:09 CET] <furq> making a deb is easy
[21:32:16 CET] <furq> making a deb that would actually get included in debian is the thing that sucks ass
[21:32:16 CET] <JEEB> until I got to https://kuroko.fushizen.eu/docs/building_with_pbuilder.txt
[21:32:21 CET] <JEEB> took quite a while
[21:32:41 CET] <JEEB> and that's just "build things properly from the tarballs and whatever that are already provided"
[21:32:47 CET] <furq> but then i have no idea how you'd go about getting an rpm into centos or whatever
[21:33:04 CET] <earnestly> furq: How do you make a deb?
[21:33:15 CET] <JEEB> checkinstall
[21:33:17 CET] Action: JEEB ducks
[21:33:18 CET] <earnestly> Heh
[21:33:26 CET] <earnestly> furq: Oh, from scratch
[21:33:32 CET] <JEEB> anyways, now that I learned how to use pbuilder
[21:33:38 CET] <JEEB> it became less of a nuisance
[21:33:40 CET] <JEEB> but holy crap
[21:33:41 CET] <earnestly> furq: You have ar(1) and tar(1) (or bsdtar(1) if you want). How do you make a deb?
[21:34:02 CET] <BtbN> https://patchwork.freedesktop.org/series/31758/ for example. It has CI tests at the bottom
[21:34:03 CET] <JEEB> getting to the point where I could utilize pbuilder was meh to the second degree
[21:34:09 CET] <furq> well for starters you install debhelper
[21:34:12 CET] <earnestly> furq: haha
[21:34:14 CET] <earnestly> no
[21:34:21 CET] <earnestly> Too complex, start again
[21:34:25 CET] <furq> why are you trying to build a deb on a system that doesn't have debhelper
[21:34:46 CET] <earnestly> Why should I need a random tool when a package should literally just be a tarball?
[21:34:59 CET] <furq> because it isn't a tarball
[21:35:03 CET] <earnestly> Thankfully Solus's Ikey is sane, and avoided deb/rpm "insanity" as he called it
[21:35:13 CET] <earnestly> furq: It's an ar with two tarballs inside yeah
[21:35:21 CET] <earnestly> Because someone thought that was a good idea
[21:35:39 CET] <sfan5> earnestly: i know (roughly) how to make a deb from memory actually, because i have implemented that mess as a script previously
[21:35:51 CET] <earnestly> sfan5: Oh nice, have you documented the process anywhere?
[21:36:10 CET] <JEEB> https://github.com/jeeb/zimg/tree/debian
[21:36:11 CET] <sfan5> what do you need docs for? it's simple
[21:36:17 CET] <JEEB> this is how far I got the last time
[21:36:22 CET] <JEEB> I should rebase this and poke the debian multimedia folk
[21:36:23 CET] <JEEB> >V
[21:36:25 CET] <JEEB> :V
[21:36:46 CET] <earnestly> sfan5: Because I did the same for pacman packages, just to remember. It is very simple indeed, but I couldn't find anything from google back when I tried to understand what a deb was
[21:36:57 CET] <earnestly> I'd run into things like quilt and other incomprensible things
[21:37:31 CET] <JEEB> yea the debian stuff is just AAAAAAAAA
[21:37:35 CET] <JEEB> documentation wise
[21:37:36 CET] <earnestly> sfan5: E.g. https://gist.github.com/bebad057f40a662b5cc3
[21:37:44 CET] <JEEB> when you get to it, it's not that awful but holy crap
[21:37:59 CET] <JEEB> you get the unix freedom of getting to the end point in as insane way as you want to
[21:38:02 CET] <sfan5> tar -cf data.tar -C $pkgdir --exclude=./DEBIAN .;lzma data.tar;tar -czf control.tar.gz -C $pkgdir/DEBIAN .;echo "2.0" >debian-binary;ar c foobar.deb debian-binary data.tar.lzma control.tar.gz
[21:38:04 CET] <sfan5> that should be it
[21:38:13 CET] <sfan5> probably made some mistake along the way
[21:38:50 CET] <earnestly> sfan5: tar -cC "$pkgdir" --exclude=./DEBIAN . | lzma > data.tar; ...
[21:38:55 CET] <earnestly> sfan5: Hm, that's not too bad
[21:39:10 CET] <earnestly> You could keep DEBIAN outside of it so you don't need to depend on gnu tar
[21:39:36 CET] <sfan5> https://gist.github.com/sfan5/11222898#file-mkpkg-sh yes the script sucks, i know
[21:39:58 CET] <earnestly> sfan5: Can the inner tarballs be named .lzma or something arbitrary?
[21:40:39 CET] <sfan5> dpkg supports a few: gzip, bzip2, lzma, maybe more read the manpages
[21:40:45 CET] <earnestly> sfan5: You can use fakeroot to get that owner to be 0 btw
[21:40:53 CET] <earnestly> sfan5: Does the extention matter?
[21:41:03 CET] <sfan5> no idea, guessing yes
[21:41:10 CET] <earnestly> *nod*, okay, thank you
[21:41:20 CET] <earnestly> Not too bad
[21:41:25 CET] <earnestly> Why isn't this the main documentation? D:
[21:42:03 CET] <sfan5> ¯\_(Ä)_/¯
[21:43:23 CET] <sfan5> hm the manpage does not mention lzma but i've seen those work previously, http://man7.org/linux/man-pages/man1/dpkg-deb.1.html (-Z option)
[21:43:56 CET] <__jack__> xz == lzma
[21:44:22 CET] <sfan5> wasn't there some subtle file format difference?
[21:44:23 CET] <__jack__> to be precise: xz == lzma2
[21:44:42 CET] <__jack__> see https://en.wikipedia.org/wiki/Xz
[22:39:01 CET] <DHE> xz == a file format featuring LZMA2, but with additional features
[22:39:50 CET] <earnestly> The NAME makes this clear: "xz, unxz, xzcat, lzma, unlzma, lzcat - Compress or decompress .xz and .lzma files"
[22:40:14 CET] <earnestly> DESCRIPTION: The native file format is the .xz format, but the legacy .lzma format used by LZMA Utils and raw compressed streams with no container format headers are also supported."
[22:40:20 CET] <earnestly> Ah, the beauty of manpages :D
[00:00:00 CET] --- Fri Nov 3 2017
More information about the Ffmpeg-devel-irc
mailing list