Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

September 2017

1 participants
60 discussions

ffmpeg-devel.log.20170914
by burek 15 Sep '17

15 Sep '17

[00:00:08 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/developer.texi;h=98540c8…> [00:01:06 CEST] <nevcairiel> it doesnt really clarifiy either way where new modules should go =p [00:02:20 CEST] <jkqxz> I think they're in the third category, because the second is implied to be an API change. Though it could be clarified! [00:12:47 CEST] <thebombzen> just tried it out, and it can't find any useable planes on nvidia [00:12:59 CEST] <thebombzen> I will probably have to specify the CRTC ID, which means I have to figure that out [00:13:31 CEST] <atomnuker> on nouveau? it should work [00:13:57 CEST] <wm4> nvidia doesn't really support drm afaik? [00:14:16 CEST] <atomnuker> no, they still don't [00:15:00 CEST] <thebombzen> I'm not on nouveau, I'm on nvidia proprietary [00:15:29 CEST] <thebombzen> unless nouveau has gotten good in the last few years I hadn't considered using it [00:16:03 CEST] <thebombzen> but if nvidia doesn't do drm, then I'm SOL. I didn't realize they didn't do DRM, that's bad. [00:16:57 CEST] <TD-Linux> they do /dev/nvidia [00:17:14 CEST] <thebombzen> ah [00:19:11 CEST] <jkqxz> I assume nouveau will work like amdgpu. It can't download directly, but mapping to VAAPI and downloading there works. [00:19:50 CEST] <thebombzen> TD-Linux: it's not /dev/nvidia0. That just returns this: [AVHWDeviceContext @ 0x55837fab2be0] Failed to get version information from /dev/nvidia0: probably not a DRM device? [00:20:15 CEST] <TD-Linux> thebombzen, yeah I mean it's a custom API [00:20:45 CEST] <thebombzen> oh I see, so someone would have to write a patch to interface with the nvidia proprietary driver [00:20:48 CEST] <thebombzen> ugh [00:21:05 CEST] <TD-Linux> yeah, the API is also "secret" [00:21:08 CEST] <durandal_1707> EGLstreams? [00:21:39 CEST] <thebombzen> I would try it on Intel but i915 crashes my skylake sometimes [00:22:28 CEST] <thebombzen> I wonder what happens if I disable my X server first [00:23:42 CEST] <thebombzen> nope, running an X server has no effect [06:44:44 CEST] <cone-417> ffmpeg 03James Almer 07master:6561cdd70c55: avcodec.h: fix doxygen comment [10:26:54 CEST] <cone-096> ffmpeg 03Mark Thompson 07master:16b44d9ab9fd: lavd/kmsgrab: Fix packet flag setting [18:07:31 CEST] <cone-612> ffmpeg 03Paul B Mahol 07master:133002e8ae51: avfilter/vf_despill: fix assigment [19:59:49 CEST] <BBB> openHEVC for audio decoding :D @ https://stackoverflow.com/questions/46214911/openhevc-for-audio-decoding [20:00:54 CEST] <JEEB> lol [20:05:48 CEST] <nevcairiel> isnt it just a modified ffmpeg [20:06:22 CEST] <JEEB> yea, it's a library on top of FFmpeg's libraries [20:06:28 CEST] <JEEB> which then is used by GPAC's player [21:14:27 CEST] <Compn> gpaq [21:14:33 CEST] <Compn> qmac ? [21:14:34 CEST] <Compn> hmm [00:00:00 CEST] --- Fri Sep 15 2017

1 0

ffmpeg.log.20170914
by burek 15 Sep '17

15 Sep '17

[05:04:21 CEST] <sir123> Hello, this question is not ffmpeg-specific. I have a big h264 video with DTS sound, and want to transcode the file into a patent-unencumbered format. I've looked into the ogg format, but I can't find a lossless video format made by Xiph.org. Any recommendations? [05:05:56 CEST] <c3-Win> VP9 or AV1 as the video codec? [05:07:43 CEST] <kepstin> sir123: are you sure you want lossless? unless the h264 file is originally lossless, that's gonna be a huge increase in filesize [05:08:26 CEST] <sir123> kepstin: It's a blu-ray rip, so I don't know if it is originally lossless [05:08:56 CEST] <kepstin> definitely not, blu-ray doesn't support lossless, and most rips that are obtained ... indirectly ... have been lossy re-encoded for file size [05:09:20 CEST] <sir123> I ripped it myself from MakeMKV [05:09:37 CEST] <sir123> I have the blu-ray here lol [05:09:41 CEST] <kepstin> so yeah, use vp9, expect a slight quality loss (should be able to keep it unnoticable from a bd source), it'll be very slow [05:11:47 CEST] <kepstin> use opus audio (or if the original is lossless - some recent bds do have lossless audio, labeled 'dts master audio' - then use flac instead if you like) [05:13:04 CEST] <sir123> So, from what I can gather, media has different encoding systems for audio and video, so Opus handles audio, for instance. And video has some other formats, too. So then you need a container format for handling both (and text) in a single file. Is that right? [05:13:38 CEST] <kepstin> yes. Use mkv aka matroska (or webm, which is just mkv with a different name and restricted codec list). [05:15:20 CEST] <kepstin> if your file has subtitles, make sure to use "-c:s copy" in ffmpeg so they pass through untouched - bd subs are an image format. [05:21:59 CEST] <sir123> Ok, so a VP9 video format with Opus audio, copy the subtitles all in a Matroska container? [05:24:46 CEST] <sir123> Why would I use MKV when I could use WebM? [05:41:50 CEST] <sir123> how can i work out the best bitrate for my file? [08:28:50 CEST] <Puggy> Well, why do I get "Context scratch buffers could not be allocated due to unknown size." when I try to use -hwaccel vdpau but doesn't occur otherwise. [08:35:59 CEST] <Puggy> nvm [08:36:07 CEST] <Puggy> Just gonna use CPU encoding/decoding, works fine .-. [08:36:11 CEST] <Puggy> I have a GTX 1050 Ti [13:13:43 CEST] <redrabbit> i use cpu decoding and nvenc encoding [13:13:57 CEST] <redrabbit> gives me more flexibity with input formats for iptv [13:14:10 CEST] <redrabbit> but if i know its a AVC source i use the hw decoders as well [13:15:10 CEST] Action: redrabbit wonders if there is 1 command with hw decoding that accepts both mpeg2 and avc [13:15:32 CEST] <redrabbit> (nvidia 1060) [16:54:21 CEST] <JohnJay> ;/j #diy [17:41:21 CEST] <JohnJay> Hmm. So there's no way I can do ffmpeg -i mylist.txt output.mp3 where mylist.txt is just "file output.mp3" several times? [17:41:32 CEST] <JohnJay> I'm trying to duplicate an audio file [17:41:56 CEST] <c_14> If you want to duplicate an audio file just cp file.mp3 duplicate.mp3 ? [17:42:05 CEST] <c_14> But no, you can't reference the output file in the input [17:42:08 CEST] <c_14> How would that even work? [17:42:36 CEST] <JohnJay> it doesn't work [17:42:46 CEST] <JohnJay> I'm on a windows box atm, don't know how to concat [17:42:56 CEST] <JohnJay> can you even just cat mp3 files together? does that even work? [17:43:08 CEST] <c_14> should work afaik [17:43:18 CEST] <c_14> but what you want is https://trac.ffmpeg.org/wiki/Concatenate#demuxer [17:43:50 CEST] <c_14> where the file is repeated "file input.mp3" and your output is output.mp3 [17:47:32 CEST] <JohnJay> right, I tried that but ou still have to rename the output [17:47:39 CEST] <alphabet> # ffmpeg -i 1.mp3 -i 2.mp3 -i 3.mp3 -filter_complex concat=n=3:v=0:a=1 output.mp3 ?? [17:47:39 CEST] <alphabet> ? [17:47:43 CEST] <JohnJay> but apparently you can just concatenate mp3 files together and it works. lol [17:48:13 CEST] <JohnJay> alphabet: very funny [17:48:36 CEST] <JohnJay> anyway apparently on windows you have to tell copy the /b option or it won't work on binary files [17:49:04 CEST] <JohnJay> not even sure what it means to treat a binary file as a text file and screw it up [17:49:09 CEST] <JohnJay> but that's what it does if you forget it [17:52:10 CEST] <JohnJay> well [17:52:22 CEST] <JohnJay> apparently appending mp3 files together doesn't always work [17:52:32 CEST] <JohnJay> I tried appending some files with a 10 second mp3 of silence [17:52:38 CEST] <JohnJay> and it doesn't seem to work [18:05:22 CEST] <Kuukunen-> JohnJay: well first of all you have to understand the times windows users use copy to concatenate anything are extremely rare :P [18:07:30 CEST] <JohnJay> I'm more frustrated by the concatenation thing not working [18:08:12 CEST] <JohnJay> Maybe I have to do it alphabet's way after all [18:09:54 CEST] <JohnJay> apparently \n doesn't work in echo either. goddammit [18:12:20 CEST] <Kuukunen-> I don't think mp3 is a format that really officially supports concatenation anyway, or......? [18:12:36 CEST] <Kuukunen-> most formats don't [18:14:29 CEST] <JohnJay> I tried this from the documentation and it didn't work: ffmpeg -i "Ohio Part 002.mp3" -i 10SecSilence.mp3 -filter_complex "[0:a:0] [1:a:0] concat=n=2:a=1 [a]" -map "[a]" blah.mp3 [18:15:36 CEST] <JohnJay> the command alphabet wrote at least lets ffmpeg run [18:15:51 CEST] <JohnJay> I think it's reencoding the whole file [18:17:04 CEST] <JohnJay> nice, it worked [18:17:30 CEST] <JohnJay> although now vlc player displays a fluctuating number for total file length [18:18:50 CEST] <JohnJay> Kuukunen-: apparently it supports concatenation as long as the second thing you're concating isn't silence. XD [18:22:08 CEST] <JohnJay> anyway that command seems to do the trick [18:22:15 CEST] <JohnJay> i can hear the 10 second silence at the end of the file now [21:12:56 CEST] <bencc> is there a recommended docker image that build ffmpeg from master with result similar to the ubuntu package? [21:13:18 CEST] <bencc> or maybe I can just take the ubuntu deb package and replace the ffmpeg source with master? [21:21:37 CEST] <DHE> a docker image to compile ffmpeg? that's asking a lot. ffmpeg has a lot of optional but recommended 3rd party libraries (libx264 just being the most popular) and such an image will require a compiler [21:26:36 CEST] <bencc> a docker image that compiles ffmpeg [21:27:22 CEST] <c_14> just copy the configure line that ffmpeg prints [21:27:32 CEST] <c_14> along with the recent --disable-autodetect builds should be pretty easy to reproduce [21:28:30 CEST] <bencc> what does --disable-autodetect do? [21:28:36 CEST] <bencc> I don't see it in the commit message [21:28:40 CEST] <bencc> https://patchwork.ffmpeg.org/patch/4492/ [21:28:41 CEST] <c_14> What does it sound like it does? [21:28:45 CEST] <c_14> Disables autodetection of libraries [21:29:00 CEST] <c_14> >disable automatically detected external libraries [no] [21:29:11 CEST] <bencc> ok [21:41:30 CEST] <JohnJay> kjh [21:41:46 CEST] <JohnJay> oh i didn't disconnect, amazing [22:41:35 CEST] <selsta> is there a difference between setting frame_size in AVCodec and AVCodecParameters? [22:41:48 CEST] <Mavrik> Second one is the new API IIRC [22:42:32 CEST] <selsta> thats why Im trying to change it but my program only works when I set it in AVCodec [22:43:57 CEST] <selsta> setting sample_rate works [22:54:25 CEST] <faLUCE> hello. How can I split myfile.mp3 into two chunks, the first one starting at 00:00:00 and ending at 00:02:10, the second one starting at the end of first chunk and ending at 00:04:30 ? [22:55:52 CEST] <JohnJay> faLUCE: the -ss and -to options should work [22:56:02 CEST] <JohnJay> I had trouble with the -to option not taking the right format or something though [22:56:38 CEST] <faLUCE> JohnJay: but how can I produce multiple files? [22:56:54 CEST] <JohnJay> The documentation when I looked at it said you can't, you have to do a loop [22:57:02 CEST] <JohnJay> i'm no expert though [22:57:37 CEST] <JohnJay> oh wait there was something like that [22:57:48 CEST] <JohnJay> sorry lol i forgot about it [22:57:54 CEST] <JohnJay> there's a segment filter that does that [22:58:15 CEST] <JohnJay> ffmpeg -i input.mp4 -c copy -map 0 -segment_time 8 -f segment output%03d.mp4 [22:58:19 CEST] <JohnJay> the 8 is 8 seconds [22:58:49 CEST] <JohnJay> However make sure you put the right filename at the end. I left it as .mp4 and it produced mp3 files but named them mp4 and confused me [22:59:19 CEST] <JohnJay> The reason I've been fiddling with this is I bought an mp3 player for when I exercise [22:59:31 CEST] <JohnJay> But it ONLY takes mp3. So I have to convert anything I want to listen to to mp3 [23:00:01 CEST] <JohnJay> since I only workout for an hour I needed a way to segment longer files into 45 minute chunks [23:00:46 CEST] <faLUCE> JohnJay: thanks, but I don't understand how to generate the two lengths I said before with your syntax [23:02:42 CEST] <JohnJay> oh i see. yeah the latter method automatically produces multiple files but takes a fixed length [23:03:00 CEST] <JohnJay> to do what you want you'll have to use the -ss and -t options probably [23:03:58 CEST] <JohnJay> or you could segment the file into units of 2:10 and then combine the last 2 together maybe... [23:04:19 CEST] <faLUCE> JohnJay: never mind if you don't know the syntax for the commanbd [23:04:36 CEST] <JohnJay> Syntax for what command [23:04:42 CEST] <JohnJay> I just gave 2 different commands [23:05:25 CEST] <faLUCE> JohnJay: I would like to produce the two files that I said before with one command [23:05:41 CEST] <faLUCE> they have different lengths [23:05:54 CEST] <JohnJay> well if there's a way to do that I'd like to learn about it too [23:05:59 CEST] <JohnJay> maybe furq or someone can give the answer [00:00:00 CEST] --- Fri Sep 15 2017

1 0

ffmpeg-devel.log.20170913
by burek 14 Sep '17

14 Sep '17

[01:07:53 CEST] <cone-209> ffmpeg 03James Almer 07master:9669c05baf37: avcodec/h264_sei: add namespace prefix to frame packingarrangement enum values [01:37:49 CEST] <atomnuker> how do subdirectories (e.g. libavcodec/x86/ or arm or aarch64) get compiled? [01:38:41 CEST] <atomnuker> I don't see a reference to the makefile or directory in which it is in any makefile or the configure script [01:53:18 CEST] <iive> atomnuker: ffmpeg-source/Makefile:112 looks like the thing you are looking for [02:54:35 CEST] <cone-424> ffmpeg 03Paras Chadha 07master:6ce4a635ed19: avformat/fitsenc: fill header line with spaces [17:51:38 CEST] <kevinn__> Does anyone here know what type of compression algorithm FFmpeg uses to stream video? [17:52:33 CEST] <durandal_1707> kevinn__: thare are many [17:54:28 CEST] <kevinn__> I have been trying to implement a more or less live video streaming algorithm and the numbers are just not adding up. I was on the networking IRC and they suggested I come here. Basically I want to know how exactly FFmpeg makes the raw video bits so small that it can transfer over the internet quick enough to be considered streaming quality. [17:54:53 CEST] <kevinn__> I have exhausted nearly every compression algorithm I can find on github and none of them compress quite well enough [17:55:11 CEST] <kevinn__> I am using UDP and I also implemented a delta algorithm where only differences in the video are sent over [17:55:42 CEST] <kevinn__> but the size of the buffers are still easily over a mega byte (almost 2) for each render cycle on a 1080p video [17:56:00 CEST] <kevinn__> and I just can't send that much data so quickly [17:56:51 CEST] <kevinn__> The only other things I am considering right now is just adding some latency (which really won't work because the video is live...) or to create like a cache database on the other end with "most common buffers" [17:57:03 CEST] <iive> we do use standard video codecs. [17:57:04 CEST] <kevinn__> or something along those lines, so how does FFmpeg do it? [17:57:22 CEST] <kevinn__> what does that mean? [17:57:28 CEST] <kevinn__> like mp4? [17:57:53 CEST] <kevinn__> Is there a way to convert my straight char buffers to an mp4 codec? [17:58:13 CEST] <iive> e.g. H.264 also known as AVC or iso14496-10 [17:58:57 CEST] <iive> ffmpeg uses x264 library for encoding it. [17:59:06 CEST] <iive> it's a separate project. [17:59:34 CEST] <kevinn__> Yes I actually saw that, but I didn't really look into it much. Is this what you are talking about? https://github.com/cisco/openh264 [18:00:09 CEST] <wm4> kevinn__: you want to look into x264 and rate control, bitrate, vbv, etc. [18:00:56 CEST] <kevinn__> wm4: so something like this? https://github.com/mirror/x264 [18:01:00 CEST] <iive> kevinn__: not exactly. while the cisco codec does implement h264, it implements only the smallest subset possible. [18:01:23 CEST] <iive> kevinn__: you are however free to use it, as they cover the patents for h264. [18:02:05 CEST] <kevinn__> @iive: okay, would you suggest I use x264 like @wm4 suggested? [18:02:19 CEST] <iive> kevinn__: depends what your needs are [18:02:47 CEST] <kevinn__> I'm sorry to be a hassle here, but is there anywhere I can look to see what the pros and cons are of each? [18:02:51 CEST] <iive> kevinn__: i guess you've tried lossless compression. video and audio compression is lossy [18:03:20 CEST] <kevinn__> oh yes it is super important that the video is lossless [18:03:28 CEST] <kevinn__> are both of these lossy compression? [18:03:39 CEST] <wm4> kevinn__: ffmpeg can be built with x264 support [18:03:50 CEST] <wm4> it'll be used by default when transcoding to h264 [18:03:59 CEST] <iive> kevinn__: why do you need video to be lossless? [18:04:02 CEST] <wm4> but on this level these are #ffmpeg questions [18:04:13 CEST] <wm4> oh, lossless changes everything [18:04:26 CEST] <wm4> the answer is there's probably no such algorithm [18:04:29 CEST] <iive> x264 does have lossless mode (qp=0) [18:05:09 CEST] <kevinn__> @iive: well take things like your own desktop. if it rendered using lossy video wouldn't it just look bad? [18:05:20 CEST] <iive> no [18:05:28 CEST] <kevinn__> how so? [18:05:34 CEST] <iive> you can get good quality at reasonable bitrate [18:06:41 CEST] <kevinn__> okay, interesting. I never considered this. So since x264 supports both lossless and lossy I think that's the direction I want to go so I can tune it. But does it work on just a vanilla frame buffer? [18:07:01 CEST] <kevinn__> Like can I just input a framebuffer of what the screen is and it'll return to me what to send to the client? [18:08:30 CEST] <iive> it have development API, and it can be tuned for low latency. [18:09:20 CEST] <kevinn__> I understand that, but does it support compressing vanilla buffers? [18:09:34 CEST] <kevinn__> and will it return a buffer for me to send to the client? [18:09:55 CEST] <iive> it gets image buffers and returns bitstream. [18:11:00 CEST] <kevinn__> okay, btw thank you so much for your help here. So the link I provided above. Is all the information/files I need in there? Can I do everything I want with it? [18:11:07 CEST] <kevinn__> https://github.com/mirror/x264 [18:11:08 CEST] <kevinn__> this one [18:11:19 CEST] <kevinn__> or is there somewhere better I can reference? [18:12:27 CEST] <jamrial> kevinn__: https://git.videolan.org/?p=x264.git [18:13:52 CEST] <jamrial> also, check #x264dev [18:14:16 CEST] <kevinn__> oh thank you so much!! Is that IRC pretty active? [19:32:23 CEST] <BBB> jamrial: fwiw, I think I agree with carl here, if nan is difficult, lets just use dbl_max or dbl_min or so (assuming that works) [19:51:56 CEST] <jamrial> BBB: just replied to that email. I'll not opose to that solution if it's prefered, but keep in mind that NAN not being usable here is apparently against the spec [19:52:26 CEST] <BBB> I appreciate that, just trying to be pragmatic :) [19:53:00 CEST] <BBB> Im wary of disabling random built-in/native components depending on the exact toolchain [19:53:28 CEST] <BBB> its a very unideal situation, obviously [19:54:31 CEST] <BBB> https://www.gnu.org/software/gnulib/manual/html_node/math_002eh.html NAN is not a compile time constant with some compilers [19:55:52 CEST] <BBB> googling this issue leads to quite funny discsussions on this subject [19:57:09 CEST] <jamrial> i don't really care what solution we use. i just want to fix netbsd and djgpp which have been broken for a month [19:57:42 CEST] <jamrial> i tried replacing NAN with nan(""), and the results were mixed. Vittorio isn't even trying to fix it himself, and people suggest other solutions but don't send patches [19:58:20 CEST] <BBB> I dont have djgpp or netbsd installed so I cant reproduce it [19:58:59 CEST] <jamrial> ubitux has a djgpp toolchain and michaelni has netbsd [19:59:29 CEST] <jamrial> michaelni is who tested my nan("") patch and found out it worked in some toolchains but broke others [20:00:42 CEST] <BBB> I think its easier if we ask koda to fix it himself [20:00:57 CEST] <BBB> a quick look suggests negative or large values are impossible for the param [20:01:11 CEST] <BBB> in which case either any negative or large positive (dbl_max) can be used to signal "default" [20:01:24 CEST] <BBB> but he knows that better than me so he can verify that [20:02:22 CEST] <BBB> and yes that may mean it stayts broken for another month :( [20:09:56 CEST] <BBB> jamrial: anyway, I dont want to ohld anything up so if nobody has better ideas just commit it I guess [20:37:24 CEST] <jamrial> BBB: reimar just pointed vf_zscale does the same, and Vittorio is not going to bother with it, so i'll just push my patch until someone comes up with any other solution they prefer [20:37:34 CEST] <BBB> sure [20:41:00 CEST] <cone-464> ffmpeg 03James Almer 07master:4d390344ec38: configure: check if NAN can be used as a constant initializer [21:42:27 CEST] <jkqxz> durandal_1707: No comment on kmsgrab doc I wrote for you? :( [21:44:03 CEST] <jamrial> kierank: can you check the mpegts opus patch on the ml? [21:44:34 CEST] <durandal_1707> jkqxz: how can i use it? [21:55:44 CEST] <jkqxz> By reading it? [21:57:35 CEST] <jkqxz> More seriously, I will push that series in a bit after "make check" finishes if there is nothing else to say about it. [22:13:06 CEST] <jamrial> jkqxz: i tested it and at least trace_headers works as intended. so do the metadata ones i presume judging by the fate tests, but those just bypass the bitstream without changing anything [22:13:25 CEST] <jamrial> can't test the vaapi changes [22:13:34 CEST] <jamrial> overall it's a really neat feature [22:15:08 CEST] <jamrial> i think eventually it should be made public, or at least shared between libs, to simplify the lavf hvcc parsing code [22:15:20 CEST] <jkqxz> You can feed metadata straight into trace_headers to examine the result. [22:15:56 CEST] <jkqxz> Being public locks down a huge amount of API. I don't really want that. [22:18:21 CEST] <jamrial> btw, that (or those) hevc mkv files with non spec complaint VUI apparently were made with divx's hevc encoder, and a mkvtoolnix version with early support for hevc [22:18:39 CEST] <JEEB> oh, those files [22:18:41 CEST] <jamrial> the extradata is not even hvcc, it's annexb. trace_headers bails out with it [22:19:42 CEST] <jamrial> so they are not hevc or even matroska compliant :p [22:22:00 CEST] <jkqxz> It should work on annexb extradata? Though yeah, it will reject the VUI error. [22:22:43 CEST] <cone-464> ffmpeg 03James Almer 07master:7bae17e37ab6: avcodec/extract_extradata: return an error when buffer allocation fails [22:24:07 CEST] <jamrial> jkqxz: ff_h2645_packet_split (called by the filter) failed when checking the extradata, i think [22:25:19 CEST] <jkqxz> Let me find the file and try. [22:26:17 CEST] <jamrial> jkqxz: https://trac.ffmpeg.org/ticket/6644 firt attachment [22:27:38 CEST] <cone-464> ffmpeg 03James Almer 07release/3.3:9f7042f9cd0f: avcodec/extract_extradata: return an error when buffer allocation fails [22:31:26 CEST] <jkqxz> Er, what? {0x0, 0x1, 0x60, 0x0, 0x0, 0x0, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x78, 0xf0, 0x0, 0xfc, 0xfd, 0xf8, 0xf8, 0x0, 0x0, 0x47, 0x3, 0x20, 0x0, 0x1, 0x0, 0x18, 0x40, 0x1, 0xc, 0x1} [22:31:30 CEST] <jkqxz> This is not a thing. [22:32:12 CEST] <jamrial> it is a non compliant file alright :p [22:38:27 CEST] <jkqxz> I think it kindof works as HVCC if you ignore the first zero and then assume that the array count is missing as well. [22:39:51 CEST] <jkqxz> So the 3 is the at position 22 is the NAL length byte, the 0x20 is SPS, 1 of the, 24 bytes long, etc. [22:41:13 CEST] <jkqxz> ... why am I looking at this. File sucks, delete it. [22:41:25 CEST] <jamrial> haha [23:33:02 CEST] <jkqxz> Heh. kmsgrab -> vaapi encode runs fine at 60fps /in valgrind/. Offload ftw! [23:33:37 CEST] <atomnuker> make check completed? [23:34:29 CEST] <jkqxz> A while ago, just making sure I haven't screwed something else up. [23:37:53 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:9cb23cd9fe58: lavu: Add DRM hwcontext [23:37:54 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:170c65335caa: hwcontext_vaapi: Add DRM to VAAPI mapping [23:37:55 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:82342cead15b: lavc: Add flag to mark packets containing trusted input [23:37:56 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:c8dea8192150: lavc: Add wrapped_avframe decoder [23:37:57 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:52194f0bcb2b: lavd: Add KMS screen grabber [23:37:58 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:ec1573f879b1: doc/indevs: Document kmsgrab input device [23:38:30 CEST] <thebombzen> oh man kmsgrab naisu [23:49:03 CEST] <jamrial> jkqxz: new modules (de/encoders, de/muxers, in/outdevs, etc) bump minor, not micro [23:52:43 CEST] <jkqxz> Huh. I thought it was external API for minor, internal but with external effects for micro. [23:53:27 CEST] <thebombzen> jkqxz: how does one compile in kmsgrab? I don't see --enable-kmsgrab in configure [23:54:52 CEST] <jkqxz> You need --enable-libdrm, then it's an indev. [23:55:41 CEST] <thebombzen> ah, okay [23:56:56 CEST] <thebombzen> hm, I wonder if I can use nvenc with kmsgrab without hwdownloading [23:57:02 CEST] <jkqxz> jamrial: Docs seem to agree with me. Maybe send a patch to update that if it's meant to be the policy? [23:57:31 CEST] <nevcairiel> thebombzen: not unless someone invents drm to cuvid mapping [23:57:35 CEST] <jkqxz> (I don't mind at all, but it should be clear.) [23:57:57 CEST] <thebombzen> ah okay, "it could work, patches welcome" [23:58:09 CEST] <nevcairiel> its unclear if it could work :) [23:58:18 CEST] <nevcairiel> unless someone tries to make it work.. [23:58:23 CEST] <nevcairiel> hardware can be annoying with this stuff [23:58:54 CEST] <jkqxz> I've no idea if it will even work at all on nvidia. Even if it does, it might well have crazy tiling or just not be downloadable directly without assistance from some other API. [23:59:32 CEST] <jamrial> jkqxz: where in the docs? in any case, it's what i've seen done all the time. just look at lavc/lavf/lavfi version.h history [23:59:42 CEST] <jamrial> not that it matters much as long as something is bumped anyway [00:00:00 CEST] --- Thu Sep 14 2017

1 0

ffmpeg.log.20170913
by burek 14 Sep '17

14 Sep '17

[01:33:25 CEST] <kkanungo17> homebrew ffmpeg fails to configure, ERROR: vda requested, but not all dependencies are satisfied: vda_framework pthreads [04:58:00 CEST] <mistym> I'm trying to remux an MPEG-PS file while matching the contents of the original as closely as possible. Having trouble getting it to match the original, and the picky player I'm muxing for is barfing. Anyone have any advice? [04:58:04 CEST] <mistym> I can provide samples and more specifics :) [05:03:20 CEST] <c_14> Going to need more specifics [05:03:26 CEST] <c_14> (like the ffprobe output of both files) [05:14:18 CEST] <mistym> Default ffprobe output okay, or do you prefer JSON/XML? [05:15:39 CEST] <mistym> The original file is a nonstandard mostly-VCD video designed for playback on a mid-90s era MPEG decoder card. [05:16:00 CEST] <mistym> My goal is to remux the existing video as-is with a new audio track, encoded to the same specifications. [05:17:05 CEST] <mistym> While I have encoded a new audio track which is identically-sized to the original, the muxing overhead that ffmpeg is producing with `-target ntsc-vcd` is substantially higher, and the new file is significantly larger than the original. It's also being rejected by the original player. [05:17:26 CEST] <mistym> https://gist.github.com/mistydemeo/b2b4dcd410e29ff035d8b7eb0e410f3c - ffprobe output for the original video, with -show_format -show_streams [05:17:47 CEST] <mistym> https://gist.github.com/mistydemeo/89f06dc501bfd82ee2bec8a138c45fa5 - ffprobe output for the original audio (as a separate M2A), with -show_format -show_streams [05:21:06 CEST] <mistym> The original video is in an MPEG-PS/CDXA container so I'm using vcdgear to wrap the MPG produced by ffmpeg, but the major differences are at the MPEG-PS container level. [05:21:13 CEST] <c_14> I'm pretty sure using -target reencodes all the data [05:21:35 CEST] <c_14> You probably just want to copy the streams [05:26:06 CEST] <mistym> Oh heh, yeah, it is! Went so fast I figured it couldn't be reencoding. Remuxing does indicate the sizes are around what I'm expecting [05:26:36 CEST] <mistym> vcdgear rejects it now, but maybe it's just being picky. I'm assuming ffmpeg doesn't support MPEG-PS/CDXA so I'll look up something else to wrap it. [05:30:21 CEST] <c_14> Does it give a reason for rejecting it? [05:32:44 CEST] <mistym> Unfortunately not. That would have been convenient of it, hah. Gets a far as printing what it's going to do, then exits 1 without a message. [05:48:14 CEST] <mistym> Hmm, interestingly vcdgear is happy with mjpegtools mplex's job. Wonder what's different, I should dig in with a hex editor. [08:16:40 CEST] <FunkyBob> morning, all... am using the pyav wrapper, and the examples seem to indicate I can't rely on the frame.pts ... I'm hoping to be able to find a reliable frame sequence index value [or way to calculate it] [08:21:42 CEST] <thebombzen> FunkyBob: ffmpeg counts frames, so a python wrapper should provide access to that information [08:23:17 CEST] <FunkyBob> thebombzen: ok... in a stream object where would I find the frame count? [08:23:23 CEST] <FunkyBob> s/object/struct/ [08:26:14 CEST] <FunkyBob> basically, in this application we need to seek to a position in the stream, and extract the frame... [08:26:45 CEST] <FunkyBob> so if ffmpeg is counting frames, is it able to accurately count when I've skipped? [08:28:34 CEST] <FunkyBob> gak... have to go catch a flight... [08:28:38 CEST] <FunkyBob> thanks for your help so far, anywayt [09:35:47 CEST] <jeffW_> I built ffplay.exe using MSYS2, but when I try to open a file with it, it starts to load up, showing my ./configure settings and the libs, but then crashes [09:36:09 CEST] <jeffW_> Using Visual Studio 2015 to debug, I got errors: An unhandled win32 exception occured in ffplay.exe [18012] [09:36:15 CEST] <jeffW_> and Unhandled exception at 0x0000000000000064 in ffplay.exe: 0xC0000005: Access violation executing location 0x0000000000000064. [09:37:02 CEST] <jeffW_> My configure settings are: ./configure --prefix=/c/ffmpeg-output --enable-gpl --enable-version3 --enable-asm --disable-encoders --arch=x86_64 --disable-ffserver --disable-ffmpeg --disable-ffprobe --disable-doc --disable-shared --enable-static --disable-bzlib --disable-libopenjpeg --disable-iconv --disable-zlib --pkg-config=pkg-config [09:39:48 CEST] <jeffW_> I saw that on Zeranoe, he uses --disable-w32threads so I tried building it with this option, but this also did not work. [09:42:30 CEST] <jkqxz> Do you have a backtrace? [09:45:01 CEST] <oerg866> Hello, is it possibhle to change the playback speed of an mkv file without re-encoding. I have some 23.976fps content that I'd like to "speed up" to 25 fps, so it'll sync with my 25i display output. [09:46:00 CEST] <jeffW_> @jkqxz, No I do not have a backtrace... I have the output of the MSYS2 window as ffplay.exe was being created... [09:48:21 CEST] <thebombzen> oerg866: you will have to re-encode the audio, but you can dump the video as a raw stream and then feed it back into FFmpeg. Assuming it's H.264, you can do something like this: [09:48:45 CEST] <thebombzen> ffmpeg -i input.mkv -map v -c copy -f h264 rawvideo.h264 [09:48:54 CEST] <oerg866> <thebombzen> oerg866: you will have to re-encode the audio <-- yeah that's what I was going for [09:49:07 CEST] <thebombzen> then do: ffmpeg -f h264 -r 25 -i rawvideo.h264 -c copy another.mkv [09:49:25 CEST] <oerg866> ahh, super [09:49:26 CEST] <oerg866> thank you [09:50:05 CEST] <thebombzen> you can re-do the audio with the atempo filter, but use the librubberband filter if your FFmpeg has that in. it works better than libavfilter's atempo filter [09:50:50 CEST] <oerg866> alright [09:50:51 CEST] <oerg866> tyvm [09:51:37 CEST] <jeffW_> Do you know how I could go about getting a backtrace from an .exe ? [09:52:24 CEST] <jkqxz> Doesn't visual studio just give it to you when something crashes? [09:53:25 CEST] <jeffW_> let me crash it again [09:56:31 CEST] <jeffW_> other than the Exception thrown at 0x0000000000000064 in ffplay.exe: 0xC0000005: Access violation executing location 0x0000000000000064. [09:56:58 CEST] <jeffW_> The thread 0x4a6c has exited with code 0 (0x0). [09:59:09 CEST] <jeffW_> The gods are against me [09:59:23 CEST] <jeffW_> They simply do not want me to be able to compile ffplay.exe [10:01:13 CEST] <jkqxz> Does ffmpeg work? (If you don't set --disable-ffmpeg.) [10:03:23 CEST] <jeffW_> Ok here is callstack: [10:03:27 CEST] <jeffW_> 0000000000000064() Unknown [10:03:31 CEST] <jeffW_> SDL2.dll!000000006c8358ce() Unknown [10:03:36 CEST] <jeffW_> SDL2.dll!000000006c7cebfa() Unknown [10:03:40 CEST] <jeffW_> ffplay.exe!0000000140b4c925() Unknown [10:03:44 CEST] <jeffW_> ffplay.exe!00000001400013f7() Unknown [10:03:47 CEST] <jeffW_> > ffplay.exe!000000014000152b() Unknown [10:03:51 CEST] <jeffW_> [External Code] [10:04:37 CEST] <jkqxz> So it dies in SDL. Does your SDL install work for anything else? [10:04:49 CEST] <jeffW_> I have no idea [10:04:59 CEST] <jeffW_> I'm pretty sure i got it via: pacman -S SDL2 [10:06:25 CEST] <jeffW_> If i try to compile with ffmpeg, should i also remove --disable-encoders ? [10:08:24 CEST] <jeffW_> I removed --disable-encoders and --disable-ffmpeg, should have the results in about 23 minutes or so :\ [10:15:45 CEST] <oerg866> thebombzen: [matroska @ 00000000027ec0c0] 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 [10:15:45 CEST] <oerg866> [matroska @ 00000000027ec0c0] Can't write packet with unknown timestamp [10:15:45 CEST] <oerg866> av_interleaved_write_frame(): Invalid argument [10:15:58 CEST] <oerg866> well there goes that idea :S [10:28:34 CEST] <thebombzen> oerg866: try using -framerate 25 instead of -r 25 [10:28:41 CEST] <thebombzen> although that *should* work [10:29:35 CEST] <oerg866> nope, doesn't work either [10:31:08 CEST] <jeffW_> :p beemo [10:33:14 CEST] <FunkyBob> back [10:34:57 CEST] <thebombzen> oerg866: alternatively, you can use L-smash [10:35:18 CEST] <oerg866> what is that? [10:35:50 CEST] <thebombzen> it's another program [10:35:57 CEST] <thebombzen> I don't know how to use it though, you'd have to ask someone else [10:36:03 CEST] <thebombzen> I just recall that you could do this with L-smash [10:39:03 CEST] <jeffW_> what is a super dumb simple test I could do to verify that ffmpeg is working? [10:39:36 CEST] <thebombzen> jeffW_: ffmpeg -f lavfi -i testsrc -c copy -f null - [10:40:10 CEST] <jeffW_> where testsrc is the name of my file? or the filepath ? [10:40:18 CEST] <thebombzen> copy that verbatim [10:40:26 CEST] <jeffW_> oh... [10:41:13 CEST] <jeffW_> will it then display psycadellic fractal patterns and spinning picture of Dick Cheyne indicating that it is working properly? [10:42:15 CEST] <jeffW_> (I can't test it right now, I'm waiting for it to compile) [11:11:52 CEST] <jeffW_> OK, i copied verbatim what you told me, "ffmpeg -f lavfi -i testsrc -c copy -f null -" [11:12:31 CEST] <jeffW_> And I get the message: The application was unable to start correctly (0x000007b). Click OK to close the application. [11:20:19 CEST] <u32> Hello. I'm trying to play a video stream with the lowest latency I can and have had some mild success with gstreamer (bottoming at ~300ms) and now i want to do the same with ffmpeg (ffplay) [11:20:29 CEST] <u32> but i can't bring it below 1000ms or so. [11:20:32 CEST] <furq> jeffW_: that's an incredibly vague error message which could mean lots of things [11:20:48 CEST] <furq> but if these are the zeranoe builds then i suspect you've downloaded the wrong version for your architecture [11:20:58 CEST] <u32> Any ideas on how to reduce latency whith all other considerations second? [11:21:17 CEST] <furq> that normally means you're trying to load a 32-bit dll into a 64-bit binary or vice versa [11:21:55 CEST] <BtbN> u32, ffplay is more a proof-of-concept than an actual player. [11:22:04 CEST] <u32> The error is also typical when some applications (Qt comes to mind) fail to load some dlls [11:22:05 CEST] <BtbN> For ultra-low-latency, you will always want to write your own player. [11:22:12 CEST] <furq> if you've definitely got the right binary then it could be any number of different things [11:22:39 CEST] <jeffW_> These are not zeranoe builds [11:22:43 CEST] <furq> it's one of those typical MS error messages where the official advice is "do 21 different things and try it after every step and if it works, great!" [11:22:55 CEST] <furq> and step 21 is "reinstall windows" [11:23:19 CEST] <jeffW_> ffplay is proof that ffmpeg doesn't work on Windows. [11:23:26 CEST] <u32> BtbN: Is there any reference app/tool to test ffmpeg? [11:23:42 CEST] <BtbN> That's what ffmpeg and ffplay are for [11:23:48 CEST] <furq> oh you're building this yourself [11:24:33 CEST] <jeffW_> yes [11:24:38 CEST] <jeffW_> using MSYS2 [11:25:30 CEST] <jeffW_> i established with jkqxz's help that SDL2 is causing the problem in ffplay [11:25:44 CEST] <furq> i was going to suggest cross-compiling, but then i remembered my build script doesn't actually build ffplay [11:26:00 CEST] <jeffW_> but now (several minutes later) ffmpeg does not work when compiled either. [11:26:25 CEST] <furq> probably check dependency walker and see if you're missing a dll [11:26:27 CEST] <jeffW_> As usual in the world of compiling, nothing ever works. [11:26:53 CEST] <u32> So no real way to test wether ffmpeg will be of any advantage without making a custom app? [11:27:17 CEST] <jeffW_> This is why I should have just stuck with Python and dared venture outside the house. [11:27:33 CEST] <jeffW_> and never* dared [11:28:06 CEST] <jeffW_> I just wanted to make a very simple video player, and ffplay is just such a player. [11:28:36 CEST] <jeffW_> I dont care about fancy filiters, or changing bit-streams or YUV to RGB or any of that nonsense [11:28:54 CEST] <jeffW_> I just want to play with mapping the keys on the keyboard to times in any given video [11:29:22 CEST] <jeffW_> I did it already with Python using a "wrapper" for VLC.dll [11:29:38 CEST] <jeffW_> Only problem is, it's slow as hell to start up [11:30:04 CEST] <jeffW_> And when it does (when u start it up after not having started it in a while) the video begins to play the first second of the video over and over [11:30:13 CEST] <jeffW_> and I have to quit out of the program and restart it [11:31:10 CEST] <jkqxz> It think the answer to your complaint that compiling it is terrible is "don't use windows". [11:31:43 CEST] <jeffW_> So then i decided, why not re-write it in C, it will be a good opportunity to learn C/C++ and change that "Python, MATLAB (Some familiarity with C/C++)" on my resume to "Python, MATLAB, C/C++" [11:31:45 CEST] <jkqxz> It is certainly possible to make it work (Zeranoe does, after all), but it is not easy and rather fragile. [11:32:03 CEST] <u32> well. Target people tend to dislike linux [11:32:27 CEST] <jeffW_> @jkqxz, yes exactly. Windows -- the bane of all programmers. [11:33:06 CEST] <jeffW_> Zeranoe makes it work with Debian :\ [11:33:18 CEST] <jkqxz> I build ffmpeg in msys2 for testing some stuff, but it's something I made work (possibly by luck) a while ago and now try not touch anything in case it breaks. [11:33:22 CEST] <jeffW_> And all I have is my Windows 8.1 laptop. [11:33:51 CEST] <furq> if you want to cross-compile it then do it in a vm [11:34:22 CEST] <jeffW_> All I have is my Windows 8.1 laptop, what am I going to be cross-compiling for? [11:34:25 CEST] <furq> for windows [11:34:46 CEST] <furq> compile it in a linux vm running on windows for windows [11:34:52 CEST] <jeffW_> My understanding was cross-compiling meant creating executables for various OSs. [11:35:01 CEST] <furq> if that sounds ridiculous to you then blame this guy [11:35:03 CEST] <furq> https://pbs.twimg.com/profile_images/889736688624312321/xVAFH9ZH_400x400.jpg [11:35:52 CEST] <jeffW_> Nah, I'll blame the ppl running MS since... oh, let's say... idk.... 2008ish? 2013? [11:36:19 CEST] <jeffW_> why the hell doesn't their coveted Visual Studio have the equivalent of MSYS2 already? [11:36:35 CEST] <jeffW_> MS is living in denial of Unix/Linux's existance? [11:37:06 CEST] <jeffW_> They refuse to accept that Linux systems are THE preferred method for cross-platform implementation [11:37:10 CEST] <furq> msys sort of sucks tbh [11:37:24 CEST] <jeffW_> well, its msys or vm [11:37:30 CEST] <furq> yeah i picked the latter [11:37:53 CEST] <c_14> Isn't there the fancy Ubuntu on Windows stuff now? Didn't that leave beta yet? [11:38:01 CEST] <furq> he's on windows 8 [11:38:03 CEST] <jeffW_> vm sounded like over-kill/hassle/big-disk-space-hog/etc. [11:38:05 CEST] <furq> WSL is only for 10 [11:38:17 CEST] <furq> and also it is still in beta iirc [11:38:59 CEST] <furq> with that said, is there some reason you can't use the ffplay from zeranoe [11:39:02 CEST] <furq> at least for testing and whatnot [11:39:40 CEST] <jeffW_> So apparently I'm the first person on planet Earth to attempt to use MSYS2 to compile FFmpeg on a Windows 8.1 machine. Horray for me. [11:39:55 CEST] <jeffW_> Well, in looking at ffplay.c [11:40:23 CEST] <jeffW_> I saw that was where the keyboard code was, so i decided, "Perfect! This is what I need to mess with an compile." [11:40:44 CEST] <jeffW_> And that was where innovation came to an end. [11:42:49 CEST] <jeffW_> Could any of you explain this to me: I downloaded Visual Studio 2015, and started a new C++ console application. Open ffplay.c, copy, paste it into MSVC as ffplayJeff.cpp, rename it to ffplayJeff.c (now a bunch of red (errors) disappars. [11:43:22 CEST] <c_14> Well, it's not C++ [11:43:25 CEST] <jeffW_> Go to Visual C++ settings [11:43:51 CEST] <jeffW_> set Include Directories to include C:\ffmpeg where i put the FFmpeg Snapshot [11:44:00 CEST] <jeffW_> now more red disappars [11:44:21 CEST] <jeffW_> Using the config.h from running /.configure with MSYS2 [11:44:31 CEST] <c_14> ffplay includes a bunch of ffmpeg headers [11:44:45 CEST] <jeffW_> now that is no longer an issue. Perfect! All the red is gone, it should compile without problems [11:45:50 CEST] <jeffW_> And instead i get Unhandled Symbol _hide_banner in Object line 1 [11:46:00 CEST] <jeffW_> Unhandled Symbol in blahblahblah in Object line 1 [11:46:20 CEST] Last message repeated 1 time(s). [11:46:20 CEST] <jeffW_> ad nauseum [11:46:42 CEST] <jeffW_> so i use Notepad++ to search C:\ffmpeg for "_hide_banner" [11:47:29 CEST] <jeffW_> And... of course it returns results: 0 occurrences of "_hide_banner" found in "C:\ffmpeg\" [11:48:12 CEST] <jeffW_> o rly? then where the f did msvc get "_hide_banner" from? [11:48:35 CEST] <jkqxz> The windows ABI puts an underscore on the front of all C symbols. [11:48:48 CEST] <jkqxz> So lost the leading underscore and search again. [11:48:59 CEST] <jkqxz> *lose [11:49:00 CEST] <c_14> I don't think ffplay.c is standalone [11:49:02 CEST] <jeffW_> I had thought of doing that. damnit. [11:49:06 CEST] <c_14> you probably need cmdutils.c and other stuff [11:49:20 CEST] <jeffW_> yup. It does. [11:49:24 CEST] <c_14> I'd guess ffmpeg_opt.c as well [11:49:26 CEST] <jkqxz> Yeah, probably also some config.h stuff. [11:49:27 CEST] <u32> C puts a leading underscore when linking symbols [11:49:32 CEST] <u32> is a C thing actually [11:49:43 CEST] <jkqxz> It's not a C thing, it's a Windows C ABI thing. [11:50:34 CEST] <jeffW_> I'm just curious wtf it is [11:50:49 CEST] <jeffW_> i think i had, in reading trying to figure out wtf Unhandled symbol" meant [11:51:03 CEST] <jeffW_> that it might be calling out stuff that it doesn't even need [11:51:17 CEST] <jeffW_> but it's "unhandled" so it bitches about it anyway [11:51:47 CEST] <c_14> cmdutils.h hide_banner [11:51:56 CEST] <c_14> It's an option [11:51:56 CEST] <jeffW_> ah [11:52:22 CEST] <jeffW_> So what needs to be done in msvc to make it stop complaining about it being "unhandled" ? [11:53:29 CEST] <c_14> make sure cmdutils.* is in your cwd [11:53:35 CEST] <c_14> in this case in your project or something [11:56:34 CEST] <jeffW__> back. connection died. [11:56:57 CEST] <jeffW__> Also, ffplay.c does not contain #include cmdutils.c, only #include cmdutils.h [11:57:08 CEST] <c_14> Well, obviously [11:57:12 CEST] <c_14> You don't include .c files [11:57:20 CEST] <c_14> You link the resulting object files into your binary [11:57:50 CEST] <jeffW__> Good to know. Thought someone had said they thought ffplay required cmdutils.c [11:57:59 CEST] <c_14> yes [11:58:01 CEST] <c_14> me [11:58:03 CEST] <c_14> Because it does [11:58:11 CEST] <c_14> Just not during compilation [11:58:13 CEST] <c_14> But during linking [11:58:31 CEST] <jeffW__> via cmdutils.h I presume. [11:58:49 CEST] <c_14> yes and no, let's just say yes [11:59:55 CEST] <jeffW__> Fair enough. [12:00:25 CEST] <jeffW__> So what object files am I linking? [12:00:49 CEST] <c_14> ffplay.o and cmdutils.o [12:00:51 CEST] <jeffW__> I'm only seeing .o files [12:01:10 CEST] <jeffW__> will msvc recognize .o files? or only .obj [12:01:18 CEST] <c_14> .o files are the result of compiling .c files [12:01:24 CEST] <c_14> You give msvc the .c files [12:01:30 CEST] <c_14> And then it will create and link them [12:01:35 CEST] <c_14> s/create/assemble/ [12:02:33 CEST] <c_14> (you'll probably also have to tell msvc somehow that ffplay.c wants to be linked against cmdutils.c) [12:03:01 CEST] <jeffW__> I gave it ffplay.c (renamed as ffplayJeff.c since msvc only will compile Solutions, not individual files). [12:03:37 CEST] <c_14> Then you have to create a Solution that contains ffplay.c and cmdutils.c and depends on their compilation and linking [12:04:09 CEST] <jeffW__> well i opened ffplay.c , copy, and pasted it into blank ffplayJeff.c [12:04:43 CEST] <jeffW__> well... ffplayJeff.cpp then renamed it to ffplayJeff.c and watched as a bunch of red stuff disappared when i did that. [12:04:47 CEST] <c_14> Well, MSVC has to have some sort of project Makefile or project structure that lets you tell it how to compile things and what depends on what [12:05:25 CEST] <jeffW__> hmm [12:06:00 CEST] <jeffW__> okay. more research on msvc "Properties Pages" dialog needs to be done. [12:06:41 CEST] <jeffW__> so my "solution" needs a "makefile" ? [12:06:47 CEST] <jeffW__> i thought makefiles were a Linux thing.. [12:07:18 CEST] <jeffW__> what with the whole "make" command and all that [12:07:36 CEST] <c_14> Makefiles are a POSIX thing [12:07:44 CEST] <jeffW__> ah [12:08:29 CEST] <jeffW__> I noticed when you start a new project... er... solution, in msvc Makefile Project is one of the options [12:09:11 CEST] <jeffW__> Could this be the one and only concession Microsoft has made that Linux exists? [12:10:30 CEST] <jeffW__> I mean other than having MS Word import .odf Open Document format [12:11:57 CEST] <jkqxz> Microsoft copied make as nmake a very long time ago. [12:12:27 CEST] <jeffW__> why am i not surprised... [12:13:17 CEST] <jeffW__> ugh. i'm starting to lose conciousness, i need to copy the stuff c_14 said and put it in a .txt file [12:15:41 CEST] <jeffW__> jkqxz, do you suppose deleting any/all folders with SDL in them from MSYS folders and running pacman -S SDL2 again would help? [12:18:21 CEST] <jkqxz> Highly unlikely. But possible, I guess, so it's probably in front of "sacrifice a second goat" on the list of things to try. [12:20:08 CEST] <jeffW__> hmmm [12:20:34 CEST] <jeffW__> alright then [12:21:02 CEST] <jeffW__> I ask b/c i had been trying various other things [12:21:15 CEST] <jeffW__> (reading old posts from back when FFmpeg used SDL1.2) [12:21:28 CEST] <jeffW__> and following instructions on things to change [12:21:31 CEST] <jeffW__> based on that [12:22:23 CEST] <jeffW__> then after reading one post about ffmpeg changing from sdl1.2 to sdl2.0 in ~version 3.0.2 [12:23:16 CEST] <jeffW__> i realized that the instructions someone posted that i was following, which had me download ffmpeg-3.0.2, which i was trying to get to compile for 3 days, was for sdl2.1 [12:24:16 CEST] <jeffW__> so i got sdl2.1 and tried messing with CFLAGS and LDFLAGS and --cflags=/c/msys64/home/Jeff/sdl/SDL-1.2.15/ [12:25:18 CEST] <jeffW__> and then realized, maybe i should just download ffmpeg again... and low and behold, it actually compiled ffplay! But of course it didn't work. [12:28:00 CEST] <jeffW__> well it was a little more involved than that... but you get the idea. [12:31:21 CEST] <jeffW__> Ah, I have another question... When msys2 is compiling ffmpeg, I get several warnings now and then [12:31:33 CEST] <jeffW__> Should that not be happening? Or is that normal? [12:31:53 CEST] <jeffW__> when compiling ffmpeg or ffplay* [17:54:18 CEST] <thebombzen> ohey, there's an update to CUDA, I wonder if they unbroke nvcc with glibc 2.26 [17:56:57 CEST] <thebombzen> it appears that this has been unbroken [18:43:00 CEST] <wouter> what format does ffmpeg's -framerate (with -f image2) accept? Can I just tell it to use 30000/1001 or some such? [18:45:39 CEST] <wouter> apparently yes [00:00:00 CEST] --- Thu Sep 14 2017

1 0

ffmpeg-devel.log.20170912
by burek 13 Sep '17

13 Sep '17

[00:31:52 CEST] <jamrial> iive: could you test the xvmc stuff? looking at it, flipping FF_API_XVMC to 0 cleanly disables everything related to the old decoders and pixfmts but doesn't affect the hwaccels at all [00:32:19 CEST] <jamrial> so maybe it doesn't need any further changes to make sure the hwaccels work post bump [00:32:23 CEST] <iive> jamrial: i can't test at the moment, due to hardware problems [00:32:48 CEST] <jamrial> i see [00:32:50 CEST] <iive> i'll try to do it soon-ish [00:32:56 CEST] <jamrial> alright [01:03:21 CEST] <cone-588> ffmpeg 03James Almer 07master:c9a1cd08eafe: avcodec/hevc_ps: improve check for missing default display window bitstream [01:53:06 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:380659604f26: avcodec/shorten: Move buffer allocation and offset init to end of read_header() [01:53:07 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:abf3f9fa2324: avcodec/hevc_ps: Fix c?_qp_offset_list size [01:53:08 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:e952d4b7ace6: avcodec/hevc_ps: Fix limit of chroma_qp_offset_list_len_minus1 [02:49:17 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07release/3.3:0c5eb03aac6f: avcodec/shorten: Move buffer allocation and offset init to end of read_header() [02:49:18 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07release/3.3:de260c7b34de: avcodec/hevc_ps: Fix c?_qp_offset_list size [02:49:19 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07release/3.3:41479c83aea0: Changelog: update [03:29:10 CEST] <cone-588> ffmpeg 03James Almer 07release/3.3:e3a1c0491fa2: avcodec/hevc_ps: improve check for missing default display window bitstream [03:42:33 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07n3.3.4:HEAD: avcodec/hevc_ps: Fix limit of chroma_qp_offset_list_len_minus1 [03:53:12 CEST] <jamrial> michaelni: ah, sorry, didn't know you were in the middle of tagging the release and backported something [04:06:02 CEST] <michaelni> jamrial, no problem, that was a rare coincidence [07:51:58 CEST] <ubitux> damn, asan is stalled again [07:52:44 CEST] <ubitux> seems it's stalled in fate-filter-dcshift [11:08:25 CEST] <cone-209> ffmpeg 03Nicolas George 07master:76613618d978: lavfi: add helper functions and macros for activate. [11:08:26 CEST] <cone-209> ffmpeg 03Nicolas George 07master:567d318b1cc1: lavfi/af_agate: use helper macros. [11:08:27 CEST] <cone-209> ffmpeg 03Nicolas George 07master:61b0b03f3fdc: lavfi/af_sidechaincompress: use helper macros. [11:08:28 CEST] <cone-209> ffmpeg 03Nicolas George 07master:1b8e061cc574: lavfi: remove framesync. [11:08:29 CEST] <cone-209> ffmpeg 03Nicolas George 07master:5f5dcf44e3c4: lavfi: rename framesync2 to framesync. [11:08:30 CEST] <cone-209> ffmpeg 03Nicolas George 07master:064c9d45ff10: doc: update filter_design.txt. [12:30:07 CEST] <cone-209> ffmpeg 03Nicolas George 07master:9bad5e531910: lavfi/framesync: reword repeatlast option help. [12:37:14 CEST] <cone-209> ffmpeg 03Nicolas George 07master:549ef6ef9a81: lavfi/framesync: remove dead code. [14:22:07 CEST] <cone-209> ffmpeg 03Ronald S. Bultje 07master:183216b21870: frame_thread_encoder: make 'exit' member atomic. [14:26:50 CEST] <brash> I am getting an error of "Invalid data found when processing input". Specifically this error is happening at avformat_write_header(). I am wanting to mux a video stream (h264) into a matroska container. It seems that this error is happening when avformat_write_header() is calling init_pts() and not init_muxer(). This is with libavformat version 56.40. I know it's old, but upgrading requires a lot of hoops working around dependencies. Any [14:35:17 CEST] <brash> If it means anything, I am following the example at http://www.ffmpeg.org/doxygen/2.8/muxing_8c_source.html [16:10:43 CEST] <brash> Anyone know where to begin debugging an "Invalid data found when processing input" error when trying to mux an h264 stream encoded with libx264 into an mkv container? [16:10:57 CEST] <brash> I am getting the error at avformat_write_header(). [16:28:50 CEST] <jkqxz> brash: Step through avformat_write_header() (and callees) with a debugger to find where the error is generated? [16:46:01 CEST] <brash> jkqxz: I've been trying that, but I think since I don't have ffmpeg compiled with debugging flags it won't show any symbols. [16:47:03 CEST] <brash> jkqxz: It's a new library for me, and I think that I just need to keep working with it until I figure out what is going. I am still figuring out the difference between AVCodec and AVCodecContext structs, ect. [16:48:12 CEST] <brash> Of course all frustration is on my part for thinking that writing a 'simple' program with ffmpeg would be anything but. [17:04:41 CEST] <jkqxz> --enable-debug [17:07:18 CEST] <brash> For anyone wondering what I did wrong, I had a pointer that I was not pointing back to the codec in my AVStream. [19:13:37 CEST] <ubitux> i have to disable the asan fate instance [19:13:48 CEST] <ubitux> as it stalls ffmpeg [19:17:20 CEST] <jamrial> ubitux: could it be an asan bug? seeing you updated gcc [19:17:37 CEST] <ubitux> i updated after it was already stalled [19:17:39 CEST] <ubitux> so dunno [19:17:46 CEST] <jamrial> does it happen with an specific test, or all? [19:18:20 CEST] <jamrial> maybe it was a recent ffmpeg commit [19:25:25 CEST] <cone-209> ffmpeg 03Michael Niedermayer 07master:4c88087f934b: avformat/mxfenc: Replace more literal magic numbers by enum values. [19:25:26 CEST] <cone-209> ffmpeg 03Michael Niedermayer 07master:4c33ec004fd8: avformat/mxfenc: Comment edit rate write code like the surrounding code [19:25:27 CEST] <cone-209> ffmpeg 03Michael Niedermayer 07master:de03eb622d30: avformat/mxfenc: Correct the Sample rate for PCM outside D10 [19:25:51 CEST] <michaelni> ubitux, what do you mean by "stalled" ? [19:26:51 CEST] <ubitux> infinite loop, no cpu usage [19:27:17 CEST] <ubitux> jamrial: previous one was fate-filter-dcshift, didn't check that last one [19:28:02 CEST] <michaelni> ubitux, random guess, is this threads related ? does it also happen with threads disabled? [19:28:31 CEST] <ubitux> i didn't enable threads on asan [19:28:56 CEST] <jamrial> ubitux: maybe eea69a9f25 [19:29:32 CEST] <jamrial> first change in two years, and it more or less matches the point when your fate clients stalled [19:29:52 CEST] <ubitux> i'll do some checks around this then [19:29:58 CEST] <ubitux> but not today, maybe tmr [19:32:42 CEST] <jamrial> yep, sep 6 was the last time asan had a successful run, using a snapshot before the above commit [19:47:50 CEST] <jamrial> durandal_1707: commit eea69a9f25 seems to make fate-filter-dcshift stall when run under gcc asan [19:54:48 CEST] <durandal_1707> jamrial: i see nothing wrong with that commit [19:56:34 CEST] <jamrial> can reproduce the stall if you compile using the asan configure toolchain? [19:58:55 CEST] <jamrial> s/can/can you/ [20:12:28 CEST] <ubitux> the fate test should include a perms filter :p [20:12:32 CEST] <jamrial> ubitux, durandal_1707: https://pastebin.com/Jk5HFexh [20:12:50 CEST] <ubitux> try to insert an aperms filter :p [20:12:56 CEST] <ubitux> afk bbl [20:13:15 CEST] <jamrial> ubitux: doesnt' change the fact asan shouldn't segv :p [20:14:33 CEST] <jamrial> reverting the above commit "fixes" it [20:20:37 CEST] <durandal_1707> i see nothing wrong with commit [20:24:21 CEST] <durandal_1707> found it [20:29:36 CEST] <cone-209> ffmpeg 03Paul B Mahol 07master:04b9010f7f54: avfilter/af_dcshift: do not leak out frame [20:31:05 CEST] <jamrial> durandal_1707: confirmed working, thanks [20:31:07 CEST] <jamrial> ubitux: ^ [20:41:53 CEST] <ubitux> durandal_1707: jamrial: cool, thanks :) [20:41:55 CEST] <ubitux> will re-enable [20:49:40 CEST] <BBB> ah crap tsan doesnt like vp9 tile threading [20:49:41 CEST] <BBB> now what [20:49:49 CEST] <BBB> also the webinterface is slow? [20:49:52 CEST] <BBB> whats going on... [20:49:56 CEST] <BBB> takes like a minute to load the page [20:52:47 CEST] <jamrial> BBB: tsan's logs can be massive, and the more tests fail the slower it will be to load [20:54:12 CEST] <BBB> hm, I see [20:54:13 CEST] <BBB> ok... [20:54:21 CEST] <BBB> so it looks like tsan doesnt like atomic integers [20:54:32 CEST] <BBB> do we have an atomic integer expert who can fix that for us? [20:55:01 CEST] <BBB> Ive never understood the exact access models for atomic integers, and it all seems theoretical since in practice (on x86) the test doesnt actually fail in terms of md5 [20:58:25 CEST] <ubitux> the vp9 tiling is pushed? [20:59:09 CEST] <ubitux> ah, seems so [20:59:41 CEST] <BBB> yes [20:59:44 CEST] <BBB> sorry, I broke tsan [20:59:57 CEST] <BBB> ubitux: can you test a patch for me on the tsan-slice station? [21:00:27 CEST] <ubitux> i can test locally, i'd like to make a full run of the fate instances that has been on hold for a while [21:00:28 CEST] <BBB> (it doesnt really seem to be very consistent here locally&) [21:00:35 CEST] <BBB> sure, no rush or anything [21:00:41 CEST] <ubitux> branch? [21:00:57 CEST] <BBB> just master+patch [21:01:01 CEST] <BBB> oh you want a github branch? [21:01:03 CEST] <BBB> sec [21:02:16 CEST] <ubitux> you can send me a patch too, that's fine [21:03:44 CEST] <ubitux> BBB: btw, i don't really care about tsan slices for now, i'm still obsessed with tsan turning green (but i know i didn't do much about the threading issues) [21:04:01 CEST] <ubitux> tsan as in "tsan frames" [21:06:22 CEST] <BBB> https://pastebin.com/3TnjqvA8 [21:06:27 CEST] <BBB> yes, tsan-frame would be nice to fix entirely [21:07:00 CEST] <BBB> I *believe* the frame_thread_encoder should be green. at some point I may dive into making mpeg4 happy also (thats the only remaining issue) but Im not exactly excited to start on that :-p [21:08:07 CEST] <ubitux> didn't michael submit a prototype for this? [21:08:16 CEST] <ubitux> like, ranges of stuff to copy or whatnot [21:08:26 CEST] <BBB> he did [21:08:44 CEST] <BBB> it seems brittle to me, isnt it easier to copy individual members? we made the same transition for h264 [21:08:54 CEST] <ubitux> probably. [21:08:56 CEST] <BBB> (we used to do ranges, and stepped away because it sucked) [21:09:10 CEST] <ubitux> it would be much better to individually copy yes [21:10:14 CEST] <BBB> ok so we can wait for him to update that patch then, and theres no other issues afaict [21:10:25 CEST] <BBB> tsan-slice is & hrm& all over the place [21:13:51 CEST] <ubitux> BBB: your patch works for me [21:14:11 CEST] <ubitux> (tested before -failing-, and after -working with several runs-) [21:14:19 CEST] <BBB> ok [21:14:20 CEST] <BBB> tnx [21:14:21 CEST] <ubitux> tested different number of threads too [21:14:24 CEST] <BBB> very interesting [21:15:49 CEST] <ubitux> BBB: so& mmh, should we have a tsan frame+slices? is it supported with vp9? [21:15:59 CEST] <ubitux> (both frame threading and tile threading simultaneously) [21:16:04 CEST] <BBB> no [21:16:07 CEST] <ubitux> ok [21:16:17 CEST] <BBB> the libavcodec api does not support it [21:16:22 CEST] <ubitux> ok [21:16:57 CEST] <ubitux> the point of tile threading is latency, or that's actually faster than frame threading with some encodes? [21:17:11 CEST] <jamrial> BBB: really? why does fate run with both enabled at the same time by default then? is one automatically disabled if you do that? [21:17:26 CEST] <BBB> jamrial: yes [21:17:31 CEST] <ubitux> frame takes over i guess [21:17:36 CEST] <BBB> both means use frame if supported, else use tile if supported [21:17:36 CEST] <jamrial> i see [21:17:44 CEST] <BBB> frame means use frame if supported, else nothing" [21:17:51 CEST] <BBB> tile means use tile if supported, else nothing" [21:18:13 CEST] <BBB> I agree this isnt very properly documented [21:18:35 CEST] <BBB> some codecs would probably support both at the same time, vp9 being one of them [21:19:09 CEST] <BBB> I dont think it would work for h264 since slices arent horizontally contiguous and vertically linearly ordered (which is a requirement for frame to be useful) [21:23:33 CEST] <BBB> for hevc, wpp+frame or wpp+tile might work [21:23:42 CEST] <BBB> I believe slice/tile are mutually exclusive [21:23:45 CEST] <BBB> I dont remember [21:23:59 CEST] <BBB> wpp+frame+tile-col may work, but frame+tile-row will not work [21:24:12 CEST] <ubitux> h264 slices are pretty crazy afaik [21:24:13 CEST] <BBB> so that could be interesting (wpp+frame+tile-col = 3 methods combined) [21:24:16 CEST] <BBB> yeah they are [21:24:34 CEST] <ubitux> no wonder there is so much tsan "warnings" [21:26:33 CEST] <cone-209> ffmpeg 03Ronald S. Bultje 07master:1db03e952b4e: vp9: fix explicit memory order for report_progress. [21:27:09 CEST] <BBB> Im not sure the tsan warnings are all bad, they could indicate some actual issues [21:27:38 CEST] <jamrial> ubitux: btw, your build system changes broke darwin on arm (ios?) [21:27:41 CEST] <jamrial> "src/libavfilter/vf_coreimage.m:27:9: fatal error: 'AppKit/AppKit.h' file not found" [21:27:55 CEST] <jamrial> i guess an extra header check in configure would solve it [21:29:19 CEST] <ubitux> ah, oops [21:29:48 CEST] <ubitux> i'll fix that thursday, i can't test til then [21:53:47 CEST] <ubitux> michaelni: some fields are still failing with your mpeg patch btw [21:54:05 CEST] <ubitux> http://sprunge.us/ZWCK [21:54:12 CEST] <ubitux> on fate-vsynth1-mpeg4 [23:53:08 CEST] <cone-209> ffmpeg 03Mark Thompson 07master:6eb102a61636: h264_sei: Add namespace prefix to all SEI values [00:00:00 CEST] --- Wed Sep 13 2017

1 0

ffmpeg.log.20170912
by burek 13 Sep '17

13 Sep '17

[03:25:50 CEST] <Abbott> so if I want to compile ffmpeg using cygwin, I only need to ./configure, and make, right? Assuming I have all of the dependencies listed here: https://ffmpeg.org/platform.html#Compilation-under-Cygwin [03:48:30 CEST] <qmr> ffmpeg -r 30 -start_number 0001 -i FHD%d.JPG -s 1920x1080 -vcodec libx264 00-output.mp4 [03:48:36 CEST] <qmr> [image2 @ 0x7fd144800a00] Could find no file with path 'FHD%d.JPG' and index in the range 1-5 [03:48:39 CEST] <qmr> halp [03:48:50 CEST] <qmr> oh wait, this guide is for windoze [03:49:15 CEST] <qmr> should I change that for linux? [03:49:16 CEST] <furq> i suspect you want FHD%04d.JPG [03:49:20 CEST] <furq> on any os [03:49:26 CEST] <furq> %d assumes no zero padding [03:50:11 CEST] <qmr> my hero! [03:50:13 CEST] Action: qmr swoons [03:50:43 CEST] <qmr> dammit, a sequence is missing and it aborte [03:50:45 CEST] <qmr> d [03:51:13 CEST] <furq> !demuxer image2 [03:51:13 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#image2-1 [03:51:17 CEST] <furq> you can try using the glob stuff [03:51:53 CEST] <qmr> going to start by just copying neighbor frame hopefully don't have to do it too many times [03:52:00 CEST] <qmr> I guess I shut off camera when 237 was being written or something [05:25:51 CEST] <qmr> thanks guys [06:46:38 CEST] <bray90820> What do these errors mean "[h264 @ 0x7f8c3ed10200] A non-intra slice in an IDR NAL unit." and "[h264 @ 0x7f8c3ed10200] decode_slice_header error" [09:04:56 CEST] <hendry> i have a Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default) [09:05:30 CEST] <hendry> but it doesn't show its bitrate... or am i blind? [09:20:18 CEST] <vlt> hendry: You can calculate that using duration and file size. [09:26:59 CEST] <kaninte> I've also seen cases when it doesn't display bitrate. why is that? [09:29:47 CEST] <kaninte> vlt: How do you calculate? [09:57:07 CEST] <furq> hendry: ffprobe -show_streams [09:57:09 CEST] <furq> or mediainfo [10:22:59 CEST] <hendry> furq: bit_rate=N/A [10:23:37 CEST] Action: hendry wonders if there is a tool to show VBR... like how well certain scenes were compressed et al [10:24:10 CEST] <JEEB> for bit rate you can just divide the file size with the duration. if the container is such that there is no duration field you might have to "decode" through the file with ffmpeg once to get the data [10:24:50 CEST] <JEEB> there are multiple tools that can show you bit rates graphed but the problem with most tools is that they will not show you what they are graphing exactly [10:25:04 CEST] <JEEB> as in, what they are giving you as a point etc [10:26:03 CEST] <JEEB> also stuff like VBV/HRD, which pretty much nothing takes into account [10:52:00 CEST] <brash> I am running ffmpeg 2.8 and trying to mux an mkv with an h264 video stream, but when I run avformat_write_header(), I get an error saying "Invalid data found when processing input". What would be the best way to debug this problem? I am stepping through with gdb, but I honestly am not sure what to even look for. [10:53:49 CEST] <hendry> JEEB: interesting, thanks [10:53:58 CEST] <brash> I am following the muxing.c example file at http://www.ffmpeg.org/doxygen/2.8/muxing_8c_source.html [11:13:08 CEST] <brash> All right. I figured that I am getting an undefined timestamp value. Where would I look to fix that? [11:44:27 CEST] <brash> wzur [12:54:44 CEST] <kaninte> I still can't figure out how some people encode 40min video to around 300MB with very good quality using x264 and aac. For me to achive that means crf=30 which destroys the quality. :-/ [13:02:41 CEST] <furq> kaninte: it massively depends on the source [13:08:08 CEST] <CoreX> kaninte what is the source you have exactly [13:15:28 CEST] <vlt> kaninte: Depends also on the CPU cycles invested during encoding. You should get smaller results at the same quality with somehting like "-preset veryslow". [13:47:26 CEST] <kaninte> CoreX: I have tried videos taken från my phone and från my Canon G7Xm2 camera. I just can't compress it that much without loosing alot of quality [13:47:48 CEST] <kaninte> vlt: I'm using veryslow [13:52:35 CEST] <vlt> kaninte: What happens when you recode one of those 300MB/40min videos and recode them. Just as a test? [13:52:39 CEST] <kaninte> furq: The source is very clear and noise-free in my opinion. [13:53:28 CEST] <kaninte> vlt: Interesting test, haven't tried. [13:54:29 CEST] <kaninte> vlt: Generally speaking, should the result be the same if you re-encode a video? [13:55:33 CEST] <vlt> kaninte: It doesn't get better (even when using a higher bitrate) but it shouldn't get much worse. [13:56:26 CEST] <kaninte> vlt: I mean the file size. if you use same method to re-encode should the size be the same? [13:58:31 CEST] <brash> I'm getting an "Invalid data found when processing input" when trying to mux in a matroska container. The error occurs specifically at avformat_write_header(). Anyone have experience with this? [13:59:22 CEST] <kaninte> vlt: I'm asking because I don't know exactly how encoding works. That is, do we loose some needed data during this process which makes it impossible to get the same result after re-encode, or not? [13:59:26 CEST] <vlt> kaninte: I'm not sure because the source material has (in most cases) slightly changed. [13:59:38 CEST] <kaninte> mm [14:00:07 CEST] <vlt> kaninte: We loose data. That's the whole point of (lossy) video compression. [14:01:05 CEST] <brash> I am thinking the error is happening when avformat_write_header() calls init_pts() and not init_muxer(). Still, not sure how to continue debugging this issue. Is this the right channel for this discussion? [14:01:25 CEST] <vlt> kaninte: There are lossless video codecs and there's a "lossless" h264 mode (or just -crf 0?) which I don't know anything about. [14:02:32 CEST] <furq> kaninte: are these high motion videos by any chance [14:09:42 CEST] <drakkan1000> Hi, this sample https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/demuxing_decoding… use deprecated api avcodec_decode_video2 and avcodec_decode_audio4 any plan to update it? thanks [14:12:58 CEST] <BtbN> When someone sends patches for that, sure. Feel free to write one. [14:17:34 CEST] <drakkan1000> Ok, I'll test the new api inside my application before send the patch, thanks! [14:19:23 CEST] <kaninte> vlt: yes I know about that. just thought if you unpack and repack it exactly the same way, will anything differ [14:19:41 CEST] <DHE> wow surprised that hasn't been updated yet [14:20:12 CEST] <kaninte> furq: No. I'm home videos of my new born baby, So it's really static :-) [14:28:47 CEST] <acresearch> hello people, is this a good channel to ask about desktop screen video recording (regarding best software and file format)? [14:31:46 CEST] <brash> acresearch: what software and format are you thinking about using? [14:37:22 CEST] <acresearch> brash: i think .mp4 is the best right? so i can edit it anywhere? [14:40:02 CEST] <brash> Hmm. Depends on what codecs you are wanting to run through it. FWIR MP4 is limited to specs using h.264 and AAC. [14:41:11 CEST] <brash> Are you trying to sacrifice information for size - lose some color and definition to fit into a smaller file? [14:41:17 CEST] <acresearch> i don't care about sound, i care more about the HD quality of the final video [14:41:37 CEST] <acresearch> brash: i want best colours, no need for sound quality [14:43:49 CEST] <brash> By HD do you mean 1920x1080p@60 or 1366x720p@30 etc.? [14:44:12 CEST] <acresearch> 1080p [14:47:11 CEST] <brash> In my opinion, h.264/mp4 would be a good combo. ffmpeg is capable of grabbing x11 frames, but the colors seem to be 'fuzzy'. Not sure about bitrates, quant values, I P B frame periods, etc. [14:47:29 CEST] <acresearch> hmmm [14:47:41 CEST] <brash> Are you running linux or a proprietary OS? [14:47:51 CEST] <acresearch> linux ubuntu 17.04 [14:48:56 CEST] <brash> IIRC the CLI ffmpeg -i x11grab -c:v libx264 -b:v BITRATE_VALUE out.mp4 [14:49:00 CEST] <kaninte> What are VP8 and VP9? Something new? [14:49:34 CEST] <acresearch> brash: wait, i do not have the video yet, i am asking how to record one. what formats are best and any reccomended linux software [14:49:38 CEST] <brash> acresearch: You might try that command out and see how it looks. The man pages are abundant. [14:50:20 CEST] <brash> That's what that command does. It grabs the x11 frames, encodes them with -c:v libx264 at bitrate -b:v BITRATE_VALUE to out.mp4. [14:50:49 CEST] <brash> kaninte: vp8 and vp9 are codecs teh goggles are pushing out for webm container. [14:51:10 CEST] <acresearch> brash: oh, i can record my screen from ffmped??? [14:51:26 CEST] <kaninte> goggles? [14:51:32 CEST] <brash> acresearch: yep. -i x11grab is how it's done, from what I remember. [14:51:39 CEST] <brash> kaninte: google [14:51:42 CEST] <acresearch> brash: wooow i did not know that [14:51:47 CEST] <kaninte> Ahh [14:51:49 CEST] <acresearch> brash: ok i'll give it a go [14:52:40 CEST] <acresearch> brash: ok so the command is (ffmpeg -i x11grab -c:v libx264 -b:v 5000 out.mp4)? [14:54:06 CEST] <acresearch> brash: i get an error: x11grab: No such file or directory do i have to install x11grab? [14:54:24 CEST] <brash> acresearch: change -b:v 5000 to -b:v 5000K if you want approximately 5Mbps. [14:55:01 CEST] <brash> If you have X server installed, then you don't need to install x11grab. If you don't have libx264, you will need to install libx264 and to compile libx264 support in with ffmpeg. [14:55:35 CEST] <brash> Wait, you are running ubuntu? I don't know if it runs an x11 server. [14:56:12 CEST] <acresearch> x11? so is this a server i have to connect to from a website? [14:56:47 CEST] <brash> acresearch: No. Here is a site that should help you out. I had the command wrong. https://ubuntuforums.org/showthread.php?t=2318460 [15:01:35 CEST] <acresearch> brash: i am sorry i do not understand how they solved it [15:04:56 CEST] <furq> acresearch: don't use mp4 for that [15:05:06 CEST] <furq> if the recording drops out halfway through you'll get an unreadable file [15:05:37 CEST] <furq> use a streamable container like mkv, mpegts, nut etc and remux if you need an mp4 [15:06:05 CEST] <acresearch> furq: hmmm, but the question is how to record the screen from ffmpeg (or another software that can record the colours well) [15:06:22 CEST] <acresearch> x11grab is not working with me [15:06:27 CEST] <furq> the fuzzy colours thing is probably due to the rgb to yuv conversion, particularly if you're using yuv420p [15:06:40 CEST] <acresearch> hmmm [15:06:41 CEST] <furq> so the question is what you intend to do with these videos [15:06:56 CEST] <furq> if you're uploading them to the web then that's going to happen regardless [15:07:08 CEST] <furq> so you might as well let ffmpeg do it and save some bandwidth [15:07:20 CEST] <furq> otherwise, use some codec that supports rgb [15:07:39 CEST] <furq> probably libx264rgb for lossy or ffv1 for lossless [15:07:53 CEST] <debianuser> acresearch: It depends on what you want to do. FFmpeg is good enough for screencasts. For games you may want to try SSR ( https://en.wikipedia.org/wiki/SimpleScreenRecorder ), which has some special tricks for opengl. And if you need complex overlays with webcam and mic on top of main recording and don't like command-line (unix.stackexchange.com/a/84013) you may try OBS (obsproject.com) instead. [15:08:04 CEST] <acresearch> furq: this is a tutorial on how to use molecular graphics, so colours are important, i tried two screen recorders, one is simple usless, crashes all the time (RecordMyDesktop), the other works really well but gives dull colours (SimpleScreenRecorder) [15:08:21 CEST] <furq> how are people going to watch the videos though [15:08:36 CEST] <furq> if it's youtube or something then they'll convert any input to yuv420p, so you'll have the same problem [15:08:37 CEST] <acresearch> furq: youtube [15:09:12 CEST] <furq> iirc chrome and firefox will play yuv444p h264 now, so if you can use a hosted video player then that might be an option [15:09:44 CEST] <acresearch> furq: wow, looks like this feild it too big to learn quickly. what is a hosted video player? [15:09:52 CEST] <brash> acresearch: this is their command they ran ffmpeg -f x11grab -s 1360x765 -r 30 -i :0.0 -qscale 0 -vcodec huffyuv ~/Desktop/$(date +%H%M%S).avi [15:10:03 CEST] <furq> just hosting the files somewhere [15:10:04 CEST] <brash> just look through man ffmpeg to figure out what those options do and adjust them to your needs [15:10:45 CEST] <furq> i'm impressed that you found an ffmpeg command on a forum that only has two obvious issues [15:10:53 CEST] <furq> it's normally way more than that [15:11:31 CEST] <brash> heh furq [15:12:31 CEST] <debianuser> acresearch: Make a simple color test to make sure youtube won't break your colors. Record like a few seconds with `ffmpeg -f x11grab -s 1280x1024 -r 25 -i :0 x11grab.mkv` then play x11grab.mkv and see if your colors are fine. If they are - upload x11grab.mkv to youtube and check if colors are still fine. If they're not - it's youtube to blame and you can't do anything about that. [15:13:04 CEST] <furq> you should probably convert to yuv420p yourself if you're uploading to youtube [15:13:25 CEST] <furq> it's less bandwidth and also you have some control over the conversion [15:13:57 CEST] <acresearch> furq: hmmm [15:14:09 CEST] <furq> there is some magic to getting swscale to do a better job with rgb to yuv but colourspace stuff is all over my head really [15:14:19 CEST] <furq> or getting zscale to do it at all if your build has that [15:14:23 CEST] <acresearch> the command works debianuser testing to see how to grap the whole screen [15:14:42 CEST] <acresearch> furq: this is way over my head [15:15:03 CEST] <debianuser> acresearch: adjust resolution. E.g. replace `-s 1280x1024` with `-s 1920x1080` if that's your screen resolution [15:15:13 CEST] <furq> a good rgb to yuv conversion should usually look basically the same [15:15:34 CEST] <furq> but yuv420p has half the chroma resolution, which is why sharp contrast edges of colours look blocky [15:15:40 CEST] <furq> which basically ruins small coloured text [15:15:47 CEST] <acresearch> debianuser: i get an Invalid argument [15:16:09 CEST] <acresearch> furq: then how can i oversome that? [15:16:14 CEST] <furq> if you need small coloured text and this is going to youtube then there's not much you can do [15:16:21 CEST] <furq> other than changing the colours or font size [15:17:09 CEST] <debianuser> acresearch: What's your screen resolution? Run `xrandr` command, it'd print something like: DVI-I-0 connected 1920x1200+0+0 (...) [15:17:34 CEST] <acresearch> debianuser: oh ok, i changed -s to 1280x800 [15:19:06 CEST] <debianuser> acresearch: Don't forget to play the recorded file locally and make sure the colors are fine there. I mean if the colors are already broken in the recorded file - no need to test it with youtube. :) [15:19:51 CEST] <acresearch> debianuser: furq true, this is what i am trying to do,,, colour are better than SimpleScreenRecord application, but still dull, and the video is kind of low quality [15:20:17 CEST] <acresearch> maybe because it is .avi? [15:20:30 CEST] <furq> oh [15:20:38 CEST] <furq> yeah the default codecs for avi are bad [15:20:43 CEST] <furq> use mkv [15:21:52 CEST] <acresearch> MUCH MUCH MUCH BETTER!!!! [15:22:40 CEST] <acresearch> 600MB for 20 seconds??????? [15:22:55 CEST] <furq> what's the full command [15:23:05 CEST] <acresearch> furq: ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -qscale 0 -vcodec huffyuv X.mkv [15:23:12 CEST] <furq> oh [15:23:30 CEST] <furq> the container shouldn't have made any difference then lol [15:23:44 CEST] <furq> but yeah huffyuv is a lossless codec, and i assume that'll be using yuv444p [15:24:01 CEST] <Mavrik> Probably RGB there tho [15:24:04 CEST] <furq> get rid of -qscale 0 -vcodec huffyuv and use -c:v libx264 -pix_fmt yuv420p [15:24:08 CEST] <furq> oh yeah huffyuv does rgb doesn't it [15:24:16 CEST] <Mavrik> Note that conversion to 4:2:0 is the one that messes up the colors [15:24:23 CEST] <Mavrik> Usually red comes out all fuzzy and dark [15:24:27 CEST] <furq> yeah [15:26:02 CEST] <acresearch> furq: Mavrik let me try it, i am just saving the commands so i do not forget them [15:26:34 CEST] <brash> anyone familiar with adding a video stream to a matroska container with libavformat? I keep getting "Invalid data found when processing input" when running avformat_write_header(). [15:27:13 CEST] <acresearch> furq: no back to dull colours (but size is not 3MB) [15:27:34 CEST] <furq> by dull do you mean like the contrast/brightness is wrong [15:27:38 CEST] <furq> or just the blocky edges [15:28:10 CEST] <furq> the former should actually be fixable [15:29:01 CEST] <acresearch> furq: hmmmm how do i explain. [15:29:20 CEST] <acresearch> the green is greshish, the blue is gresh like that... also not very HD [15:29:48 CEST] <debianuser> acresearch: Try a different codec. `ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -vcodec libx264 -crf 11 -pix_fmt yuv444p -preset veryfast x11grab.mkv` - that'd use x264 codec, which generates smaller files, but may affect colors (I'm not sure if rgb->yuv444 is lossless). So check if colors are fine there. [15:30:09 CEST] <acresearch> debianuser: ok let me record this command and try it [15:30:17 CEST] <debianuser> (acresearch: also if you're saving commands, make a note next to them, like "this command has bad colors", "this has better colors", "this has good colors but 600MB for 20 sec", etc. :) ) [15:30:30 CEST] <acresearch> debianuser: i do :-) thanks [15:31:17 CEST] <furq> debianuser: he's already using x264, and this is going to youtube so it has to be yuv420p anyway [15:32:21 CEST] <acresearch> debianuser: nah, same dull colours (the first command was PERFECT, but very very large files size) [15:32:54 CEST] <furq> iirc it's doing the full to limited range conversion wrong [15:33:01 CEST] <furq> but i can't remember how to fix that [15:33:07 CEST] <furq> other than using yuvj420p and that's probably no good [15:34:12 CEST] <furq> replace -pix_fmt yuv420p with -vf colorspace=range=mpeg,format=yuv420p [15:35:02 CEST] <furq> or er [15:35:09 CEST] <furq> -vf colorspace=range=mpeg:format=yuv420p [15:35:28 CEST] <furq> either should work but i assume the second one is better [15:36:00 CEST] <acresearch> failed to inject frame into filter network: Invalid argument [15:44:34 CEST] <Nacht> Afternoon [15:44:58 CEST] <acresearch> furq: i tried both commands [16:02:23 CEST] <acresearch> furq: debianuser when i change -vcodec huffyuv -> -vcodec libx264 i get low file size and low colour quality (all other flags do not affect the quality and colours) [16:02:37 CEST] <acresearch> so the issue is with the codec ha? [16:05:24 CEST] <Nacht> Would changing the colorspace effect the colours ? [16:05:45 CEST] <Nacht> Like BT709 ? [16:05:46 CEST] <acresearch> Nacht: i don't know, how do I change the colourspace? [16:05:56 CEST] <Nacht> -color_primaries 1 -color_trc 1 -colorspace 1 [16:06:29 CEST] <acresearch> Nacht: no it is the same [16:06:54 CEST] <Nacht> Hmm shame. [16:07:44 CEST] <acresearch> so i read that huffyuv is a lossless codec, does this mean any other codec is less quality so would make the colours dull? [16:07:52 CEST] <furq> no [16:07:52 CEST] <Mavrik> Nacht, acresearch, no changing to yuv444 format should fix the color [16:08:00 CEST] <Mavrik> However, you can't do anything about youtube [16:08:02 CEST] <furq> huffyuv isn't doing the conversion [16:08:06 CEST] <Mavrik> because most players only do YUV420p [16:08:06 CEST] <furq> it's keeping it as rgb [16:08:18 CEST] <Mavrik> and either you convert it or youtube will [16:08:27 CEST] <furq> Mavrik: he said the colours were still wrong with 444 so i assume he means the contrast is messed up [16:08:34 CEST] <Mavrik> ah [16:08:38 CEST] <Mavrik> *shrug* [16:08:46 CEST] <furq> which i guess is an incorrect full->limited conversion [16:09:15 CEST] <furq> i forget how you're supposed to use colorspace with rgb though [16:09:38 CEST] <furq> i guess you need to set the primaries and trcs but idk what those are meant to be for x11grab [16:09:53 CEST] <acresearch> oh so huffyuv is not converting colour, while libx264 is converting colours which is why i get them dull? [16:09:58 CEST] <furq> yes [16:10:01 CEST] <acresearch> aha [16:10:04 CEST] <acresearch> hmmmm [16:10:20 CEST] <acresearch> it is possible to stop it from converting colours? [16:10:35 CEST] <furq> youtube always uses yuv, so either you do the conversion or they will [16:10:38 CEST] <acresearch> or is it an intrinsic part of the code? [16:10:54 CEST] <acresearch> furq: but i see screen casts on youtube with amazing colours [16:10:55 CEST] <furq> they'll probably mess it up in exactly the same way [16:11:35 CEST] <furq> i mean you can try uploading rgb to youtube and see if they do a better job of converting it [16:11:51 CEST] <furq> if it's a screencast then try -c:v ffv1 [16:11:59 CEST] <furq> and get rid of any -pix_fmt stuff you have [16:12:17 CEST] <acresearch> with libx264? [16:12:23 CEST] <furq> no get rid of that [16:12:47 CEST] <acresearch> then use huffyuv? [16:12:48 CEST] <furq> ffv1 is lossless so that should eliminate any other cause of things going wrong [16:12:54 CEST] <furq> no, use ffv1 [16:13:02 CEST] <furq> huffyuv is ancient and compresses really badly [16:16:16 CEST] <acresearch> furq: one moment, let me try them all [16:16:20 CEST] <acresearch> back in 10 minites [16:35:59 CEST] <acresearch> furq: [16:36:03 CEST] <acresearch> ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -vcodec libx264 -c:v ffv1 X.mkv [16:36:05 CEST] <acresearch> ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -vcodec ffv1 -c:v ffv1 X.mkv [16:36:07 CEST] <acresearch> These seems to all give the same quality and large file size (10 seconds = 100+ MB) [16:36:09 CEST] <acresearch> y [16:39:04 CEST] <Nacht> c:v is short for vcodec [16:39:20 CEST] <Nacht> So you're specifying the codec twice [16:40:24 CEST] <acresearch> ohhhh ok [16:41:40 CEST] <acresearch> so the best command so far is `ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -c:v ffv1 X.mkv` but it still gives a file size of 100 MB for 5 seconds - but colours and quality is very good [16:44:35 CEST] <acresearch> is there a way to reduce it or compress it? [16:50:39 CEST] <redrabbit> use another codec [16:51:54 CEST] <acresearch> redrabbit: hmmm, is there a list for ffmpeg? [16:52:50 CEST] <redrabbit> you can use any codec [16:53:04 CEST] <redrabbit> if you have hardware encoders, you might want to use them [16:53:24 CEST] <acresearch> hardware encoders? i have a macbook pro with ubuntu on it [16:53:39 CEST] <acresearch> redrabbit: i am not sure what are all the codecs so i can test them [16:57:10 CEST] <Fyr> guys, I can't find a manual describing d3d11va. [16:57:19 CEST] <Fyr> do you know how to use it? [16:57:51 CEST] <vlt> redrabbit: I think the problem was that they can't use just *any+ codec because of lost colors. [17:01:52 CEST] <JEEB> Fyr: seems to be utilized in a similar way to other hwaccels in the API [17:02:24 CEST] <Fyr> JEEB, there is no similarity between HW in FFMPEG. [17:02:45 CEST] <JEEB> yes there is, HWContextType [17:03:10 CEST] <JEEB> which contain the specifics for each hwaccel [17:03:21 CEST] <Fyr> JEEB, ok, give me an example of its usage. [17:04:12 CEST] <JEEB> I would probably see how mpv does it if you really want to use it through the API instead of DXVA2 [17:04:24 CEST] <JEEB> since mpv and vlc both seem to utilize the hwaccel [17:04:53 CEST] <JEEB> the primary reason for using d3d11va seems to be UWP [17:05:37 CEST] <JEEB> ok, ffmpeg.c also seems to have some thing for it? [17:05:53 CEST] <JEEB> I did remember the original patch set having something for ffmpeg.c but I just never remembered if that was taken in [17:06:06 CEST] <JEEB> oh, and there's even an example [17:06:14 CEST] <JEEB> doc/examples/hw_decode.c: fprintf(stderr, "Usage: %s <vaapi|vdpau|dxva2|d3d11va> <input file> <output file>\n", argv[0]); [17:06:31 CEST] <JEEB> so that example seems to implement d3d11va [17:06:37 CEST] <JEEB> as in, use it [17:08:04 CEST] <acresearch> redrabbit: i tried all the lossless codecs, but ffv1 works well, the others give very bad quality [17:08:36 CEST] <brash> acresearch: did you see which encoders you have by running ffmpeg -encoders [17:08:45 CEST] <acresearch> brash: yes [17:08:50 CEST] <brash> ok [17:08:57 CEST] <acresearch> brash: i will paste you here my commands: [17:09:45 CEST] <acresearch> brash: http://paste.debian.net/plain/985725 [17:11:08 CEST] <relaxed> acresearch: pretty sure you want -framerate 30 and not -r 30 [17:11:26 CEST] <brash> With the -i :0.0 option, you can crop the screen also by using -i :0.0+x,y where x is your crop on the horizontal and y is the crop on the vertical [17:12:03 CEST] <redrabbit> if you want to get smaller files forget about lossless [17:12:06 CEST] <acresearch> brash: no i need to record the full screen [17:12:12 CEST] <redrabbit> doesnt mean it has to look bad [17:12:15 CEST] <brash> i see [17:12:18 CEST] <acresearch> redrabbit: hmmm [17:12:44 CEST] <acresearch> i am hoping to grab my students by showing off good quality graphics, that way they pay attention [17:13:21 CEST] <kepstin> x264 can be used in high quality non-lossless mode with either yuv 4:4:4 or rgb, which should give you smaller files that don't have the colour artifacting from subsampling. [17:13:27 CEST] <redrabbit> re encode the caps with AVC [17:13:59 CEST] <relaxed> acresearch: what are you capturing? An open window? [17:14:09 CEST] <acresearch> relaxed: no my desktop screen [17:14:39 CEST] <redrabbit> lossless only make sense in very specific cases [17:15:03 CEST] <acresearch> ok wait, i was using -r 30 but then i changed it to -framerate 30 and that reduced the size nicely (now 20 seconds - 100 MB instead of 5 seconds) [17:15:27 CEST] <acresearch> redrabbit: i just want HD quality. 1080p [17:15:31 CEST] <relaxed> acresearch: you've seen https://trac.ffmpeg.org/wiki/Capture/Desktop ? [17:15:52 CEST] <redrabbit> use x264 with constant quality at like 20 [17:15:56 CEST] <redrabbit> its plenty [17:16:33 CEST] <redrabbit> -crf 20 [17:16:44 CEST] <acresearch> redrabbit: x264 reduces the nice colours [17:16:48 CEST] <redrabbit> -vcodec libx264 [17:17:09 CEST] <kepstin> acresearch: please describe what you mean by "reduces the nice colours" [17:17:25 CEST] <redrabbit> im sure its because you didnt tweaked the settings properly [17:17:36 CEST] <acresearch> kepstin: the colours are not original as in the screen, they are matter, greyer, off [17:18:10 CEST] <kepstin> acresearch: hmm, that probably means a player or color conversion issue. You can use "-c:v libx264rgb" instead and it'll completely avoid the problem. [17:18:23 CEST] <kepstin> assuming you have a player that supports h264 in rgb mode. [17:19:09 CEST] <acresearch> kepstin: wow,, yes [17:19:25 CEST] <acresearch> kepstin: let me try it several times, the file size is very low [17:19:46 CEST] <redrabbit> that's the point isnt it :p [17:19:53 CEST] <redrabbit> desktop caps compress well [17:20:47 CEST] <redrabbit> what are your settings atm [17:21:36 CEST] <acresearch> kepstin: wow that actually solves my issue, nice colours, HD, and small file size :-) 30 second 8MB [17:21:45 CEST] <acresearch> redrabbit: this is my final command: ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -c:v libx264rgb X.mkv [17:22:14 CEST] <kepstin> acresearch: by default that will be using "-crf 23", feel free to try a different value to adjust the quality. [17:22:31 CEST] <kepstin> and again, you should be using "-framerate 30" not "-r 30" on the input [17:22:54 CEST] <acresearch> kepstin: what is the difference? i tried both and i cannot see a difference? [17:23:09 CEST] <redrabbit> add -crf 20 [17:23:33 CEST] <kepstin> -framerate asks the screengrabber to capture 30 frames per second. Instead, -r ignores the framerate from the screengrabber and rewrites the timestamps to 30fps. [17:24:08 CEST] <kepstin> (note that the default -framerate value is very close to 30fps, so for short videos you might not notice) [17:24:30 CEST] <JohnJay> Is there something wrong with the syntax ffmpeg -ss 00:00 -to 45:00 .... ? [17:24:32 CEST] <kepstin> but for long ones, or ones where you need audio sync, it's very important not to use -r input option :) [17:24:48 CEST] <acresearch> kepstin: ohhhh ok [17:25:05 CEST] <acresearch> now what about the -crf 20,,, what does this do? [17:25:05 CEST] <kepstin> JohnJay: -to is not supported as an input option, only as output (for now, iirc someone proposed adding it) [17:25:26 CEST] <kepstin> acresearch: -crf adjusts the video quality/size. Smaller numbers mean higher quality & higher size. [17:25:39 CEST] <kepstin> acresearch: default is 23, adjust to taste. [17:25:48 CEST] <JohnJay> kepstin: So what's the best way to segment a file into blocks of T time? [17:26:06 CEST] <acresearch> kepstin: ohhhh ok [17:26:12 CEST] <acresearch> kepstin: thanks [17:26:17 CEST] <kepstin> JohnJay: you can use -to as an output option, or use the -t option instead. [17:26:18 CEST] <relaxed> acresearch: https://trac.ffmpeg.org/wiki/Encode/H.264 [17:27:25 CEST] <kepstin> JohnJay: but if you're segmenting a file, look at using the ffmpeg segment muxer instead, to do it in one pass without having to worry about discontinuities at cuts. [17:27:32 CEST] <JohnJay> okay the t option did allow for the HH:mm:ss syntax [17:28:01 CEST] <JohnJay> kepstin: ok thanks, I will try that [17:28:34 CEST] <JohnJay> Once I know what term to use finding a tip on superuser or askubuntu is usually easy. :) [17:31:21 CEST] <acresearch> i can use .mkv for video editing later on? [17:35:36 CEST] <JohnJay> ooo NICE the -segment_time option takes options in hh:mm:ss [17:40:23 CEST] <acresearch> what does it mean with i get a printout: Past duration 0.998878 too large [17:41:08 CEST] <JohnJay> I've gotten that before, dunno what it means [17:43:15 CEST] <brash> acresearch: It probably means a time stamp (presentation or decompressed) was larger than expected. It might mean not enough CPU. [17:43:31 CEST] <acresearch> brash: hmmm [17:43:44 CEST] <acresearch> would this cause problems in my video output? [17:47:21 CEST] <JohnJay> heh now if I could only get youtube-dl to download a playlist properly then i'd be all set [17:49:51 CEST] <brash> acresearch: if it's not a buffer underflow, I wouldn't think so. The problems with using x11grab are generally losing sync with audio and video. But if you aren't capturing audio, it won't matter. [17:50:24 CEST] <acresearch> brash: oh ok good [17:50:57 CEST] <acresearch> i will be recording externally and hopefully sync them during editing, which is my last question. I can use .mkv files for video editing right? [18:06:49 CEST] <brash> acresearch: I am fairly certain most video editing software support mkv files. [18:07:02 CEST] <acresearch> nice excellent [18:10:19 CEST] <kepstin> acresearch: that problem happens when ffmpeg guesses that the video is some constant framerate, but some frames end up being closer together than expected. (iirc, a frame might get dropped). [18:10:44 CEST] <acresearch> kepstin: but it shouldn't ruin the video right? [18:11:21 CEST] <kepstin> no. But you might get better results in some cases by using an fps filter to fix the frame timestamps with the expected rate, or a couple of other options [18:11:22 CEST] <debianuser> acresearch: Also try to add option `-preset ultrafast` that'd increase the file size, but reduce cpu usage so you may get rid of "too large" warnings, if that was because of high CPU usage. [18:12:39 CEST] <kepstin> some filter chains can cause a lot of these messages, for example using 'concat' filter when the second video has higher framerate than the first (it'll cause noticable issues then) [18:12:56 CEST] Action: kepstin really should finish his patch for that [18:24:46 CEST] <debianuser> acresearch: also don't forget to upload some small video file with good colors to youtube to check if youtube breaks colors or not. [18:25:02 CEST] <acresearch> debianuser: i will do that. [18:38:50 CEST] <ritsuka> acresearch: I would check if your app supports mkv, I don't know if premiere does [18:39:12 CEST] <acresearch> i am still looking for a video editing program for ubuntu [18:50:16 CEST] <debianuser> acresearch: I don't know what people use there days. There were a lot of video editing apps: lives, kino, kdenlive, cinerella, jahshaka, winff, PiTiVi, OpenMovieEditor... blender. Not sure which of those is still alive/good. [18:50:42 CEST] <debianuser> (well, blender is certainly alive, but it might be overkill for your needs) [18:50:43 CEST] <acresearch> debianuser: hmmm i think i wil ask in #ubuntu [18:52:17 CEST] <debianuser> Ah, there're also apps like `transcode` and `avidemux`, for simple things like cut/resize... But you can also use ffmpeg for such things, if you don't mind to type a long command line for that. :) [19:16:18 CEST] <JohnJay> lol [19:16:26 CEST] <JohnJay> when I used the segment_time segment muxer [19:16:43 CEST] <JohnJay> I told it to name the output files .mp4 even though it was mp3. and so it did what I asked for [19:25:33 CEST] <JohnJay> okay i think i got the magic voodoo to get youtube-dl to download a playlist [19:25:47 CEST] <JohnJay> I do youtube-dl --playlist-start=1 --playlist-end=XXX <URL> [19:25:57 CEST] <JohnJay> if XXX is too big I guess it fails for some reason [20:05:33 CEST] <Fyr> JEEB, what is better: dxva2 or d3d11va? [20:06:27 CEST] <JEEB> I don't think they have too big of a difference [20:06:46 CEST] <JEEB> d3d11va can be used with UWP? [20:06:52 CEST] <JEEB> aka the windows ARM devices etc [20:07:00 CEST] <JEEB> the store stuff I think? [20:07:56 CEST] <Fyr> =| [20:11:29 CEST] <jkqxz> They're functionally identical. If your target platforms support both, use the one with more convenient output (IDirect3DSurface9 or ID3D11Texture2D) for whatever it is you want to do. [20:12:29 CEST] <JEEB> yup [20:31:06 CEST] <pgorley> JEEB: doc/examples/hw_decode.c is compiled against the ffmpeg 3.3.3 api? [20:31:22 CEST] <JEEB> if it's there in the repo for 3.3.3 then it will work there [20:31:31 CEST] <JEEB> docs/examples [21:11:58 CEST] <pgorley> hmm, it's in neither 3.3.3 nor 3.3.4, i'm guessing it'll be included only starting with 3.4? [21:14:28 CEST] <JEEB> pgorley: whatever happened after 3.3 then :P it might or might not work with 3.3 [21:15:54 CEST] <pgorley> it doesn't i tried compiling it, bunch of stuff missing in 3.3.x [21:16:14 CEST] <JEEB> alright, that settles it then [21:16:17 CEST] <pgorley> yup [21:16:33 CEST] <JEEB> anyways, I just recommend trying to keep up with master where possible (or where master last was green on FATE) [21:16:34 CEST] <pgorley> i'm gonna try to convince the team to get on master [21:16:43 CEST] <JEEB> http://fatebeta.ffmpeg.org/ [21:16:49 CEST] <pgorley> yea, but i don't get to make the final decision :( [21:16:52 CEST] <JEEB> sure [21:16:59 CEST] <JEEB> FATE is generally a good way of checking your arch/OS [21:17:03 CEST] <JEEB> if the tests pass [21:17:12 CEST] <JEEB> not perfect, but something [22:58:13 CEST] <BRaNaTi> Hi friends [22:58:27 CEST] <durandal_1707> hi [22:59:29 CEST] <BRaNaTi> I install a apt source deb-multimedia. Im not install a ffmpeg because i download a git project [22:59:42 CEST] <BRaNaTi> this is a last vesion [22:59:48 CEST] <BRaNaTi> version [23:00:17 CEST] <BRaNaTi> how to install command [23:00:45 CEST] <BRaNaTi> i run git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg [23:00:59 CEST] <BRaNaTi> i need install this [23:08:06 CEST] <gh0st__> BRaNaTi: run the following command in the ffmpeg directory: ./configure && make && make install [00:00:00 CEST] --- Wed Sep 13 2017

1 0

ffmpeg-devel.log.20170911
by burek 12 Sep '17

12 Sep '17

[00:02:01 CEST] <atomnuker> only issue is you can't directly hwdownload,format=bgr0 them but oh well [00:28:01 CEST] <atomnuker> jkqxz: I think it might be better to wait for the major bump to apply the opencl stuff since then we could add and remove them in a single patchset [00:32:03 CEST] <jkqxz> Yeah, the tiled hwdownload is annoying. You get around it by mapping to any other API, though. [00:32:30 CEST] <jkqxz> There isn't any interdependency, so the bump is irrelevant for addition. Only removal is a problem. [00:37:38 CEST] <atomnuker> I don't want to end up with 2 opencl boilerplates lying around [00:51:31 CEST] <jamrial> Technically, the old opencl stuff, being public api, can't be removed right away [00:52:17 CEST] <jamrial> you could however argue that if no downstream project uses it, we could just remove it and skip the deprecation period [00:52:34 CEST] <jamrial> not sure how popular would that be [00:54:24 CEST] <atomnuker> isn't it avpriv? [00:54:52 CEST] <jkqxz> Not, it's all "av_". "This interface is considered still experimental and its API and ABI may change without prior notice." wins, though, I think. [00:56:21 CEST] <jkqxz> (Since early 2013, of course. Google indeed suggests exactly zero downstream users.) [00:57:34 CEST] <kode54> I have a fate test now [00:57:45 CEST] <kode54> using the "gapless" module used for mp3 [00:57:58 CEST] <kode54> strangely, output 1 and output 2 produce the same md5 [00:58:14 CEST] <kode54> maybe because it already skips the leading sample data without seeking [00:59:09 CEST] <kode54> how do I submit a fate change, in addition to the tiny test file? [01:01:02 CEST] <atomnuker> jkqxz: yeah, that note's enough to convince anyone I think [01:10:54 CEST] <jamrial> kode54: add the changes to gapless.mak and the new files created by GEN=1 that should be in the tests/ref folder to your patch [01:11:09 CEST] <jamrial> or send them in a separate patch to be applied after the mp3dec change [01:11:39 CEST] <jamrial> upload the sample somewhere and link it in the test patch as well [01:12:06 CEST] <jamrial> the file will be uploaded to the samples repo [01:13:06 CEST] <jamrial> jkqxz: oh hey, if it's still tagged as experimental then it can probably be removed without having to deprecate it [04:48:03 CEST] <TimothyGu> BtbN: do you know why sudo is "required" by FFmpeg-Coverity? [04:48:09 CEST] <TimothyGu> https://github.com/FFmpeg/FFmpeg-Coverity/blob/master/.travis.yml#L1 [07:28:36 CEST] <atomnuker> hardware encoders ruined video encoding in general and are behind the disinterest of people in encoding [07:31:59 CEST] <atomnuker> they have crap quality but people use them because they are faster, and since they can't change them and have no one to complain to, there's no motivation to improve them [07:46:47 CEST] <graphitemaster> dude, same with hardware decoders [08:11:32 CEST] <atomnuker> really? they can be okay as long as they don't do color coversion, don't interlace non-interlaced video, don't deinterlace and are faster for most practical videos [08:13:02 CEST] <atomnuker> though you may have a point given how pathetically underpowered some are and can't do higher levels of a profile so encoders that target them can't use certain features [08:14:58 CEST] <atomnuker> hardware people are all living in the past, they refuse to admit time has passed at all and technology has gotten better [08:15:56 CEST] <atomnuker> you'd think that current hardware decoders for h264 could handle absolutely every level and profile since the codec is more than 10 years old [08:18:15 CEST] <atomnuker> but no, even though current technology can fit 10, 20, 30 times as many transistors in a given amount of space, with around the same reduction in power and for cheaper, they still keep the same feature set (and speed too probably) [09:42:23 CEST] <ubitux> atomnuker: it's hard to get around hardware encoding on embedded platforms (mobile&) unfortunately [09:42:50 CEST] <ubitux> or even decoding fwiw [09:42:55 CEST] <JEEB> yea [09:43:05 CEST] <graphitemaster> atomnuker, I think it's a matter of cost more than anything. There's basically three ways to make hardware decoders. True hardware decoding, which takes die space (and they have to implement several variants as it is since so many conflicting codecs) and that also costs wires, and it's hard enough for GPUs which pack so much tranistors (several orders of magnitude than say CPUs do). Then there's just software based decoders [09:43:05 CEST] <graphitemaster> that leverage the parallel/programmable aspect of the GPUs themselves (see Cuda, OpenCL, etc), and then there's hybrid approaches. [09:43:25 CEST] <JEEB> although you get an extra layer of shit in any case, due to the disparity in quality (Ž4@) [09:45:30 CEST] <graphitemaster> I wonder if anyone has actually compared hardware encoder/decoders by dumpping their results against some reference raw set and calculate RMSE of each frame, averaging that over how ever many frames there is, taking special care to plot each frame RMSE difference on a bar graph, one pixel wide for each frame. That could be a useful metric for looking at hardware differences. [09:46:16 CEST] <graphitemaster> I bet one can easily do that with ffmpeg [09:46:18 CEST] <nevcairiel> decoders are bit-exact, we can easily test that with ffmpeg FATE [09:46:35 CEST] <JEEB> yea, at least that if you can get the YCbCr out of them [09:46:37 CEST] <nevcairiel> encoders of course produce varying quality and some people have measured SSIM and the like [09:47:17 CEST] <nevcairiel> i don't consider those crappy decoders that give you RGB or something to be "valid" =p [09:47:42 CEST] <JEEB> :D [09:47:45 CEST] <graphitemaster> I think it's just my exposure to video playback programs then because I can see noticable difference in say vdpau playback of a video in mplayer vs software, is there some stupid bilinear filtering happening? I just don't quite get it. Or maybe it's all placebo :P [09:48:44 CEST] <JEEB> if you want the least insane playback chain I recommend taking a look at mpv's opengl renderer [09:48:46 CEST] <nevcairiel> i cant tell you what mpv might actually do, but at least PC based hardware decoders in the 3 mainstream GPU vendors cards are all bitexact with the possibility of extracting that image untouched [09:48:55 CEST] <graphitemaster> maybe the decoders are bit-exact, but the presentation of frames isn't because there's so many ways to get it out, e.g OpenGL textures can have filtering applied, even global settings in something like nvidia-settings can affect that. [09:49:14 CEST] <JEEB> and then you can read the caveats @ https://mpv.io/manual/master/#options-hwdec [09:49:29 CEST] <graphitemaster> like, even if the application developer askes for nearest min/mag on everything, global settings can override it :| [09:50:00 CEST] <graphitemaster> and then you have compositors that can change that if you don't playback full screen (proper, not windowed fullscreen or windowed) [09:51:13 CEST] <nevcairiel> i dont have much experience with opengl interop, i do know however that you can get perfect zero-copy rendering with d3d11. of course if you have a opengl renderer and/or linux, that doesn't really help you much :) [09:51:55 CEST] <graphitemaster> yeah, my day job is rendering and I can tell you some horror stories about how awful texture copies can get. [09:52:50 CEST] <graphitemaster> the real problem with opengl is the lack of native texture formats like ycbcr, so you have to do three luminance textures instead, and then some form of a shader pass to combine that into rgb, something the hardware can natively sample ... there's extensions of course. [09:53:12 CEST] <graphitemaster> and shaders are subject to shader aliasing depending on quality/performance settings [09:53:13 CEST] <nevcairiel> had the same problem with d3d9, luckily d3d11 added them [09:53:24 CEST] <nevcairiel> (the texture formats) [09:53:33 CEST] <GoD-Tony> threaded AAC encoding, thought you guys might find this interesting, https://github.com/enzo1982/superfast [09:55:02 CEST] <JEEB> when is AAC encoding the bottleneck of your chain? [09:55:48 CEST] <GoD-Tony> my tv setup only allows AAC, so im converting to that format all the time [09:56:22 CEST] <ubitux> atomnuker: oh, and i forgot all the licensing fees shit [09:56:49 CEST] <ubitux> when you use the mobile encoders, you don't have to pay anything, the company does it for you [09:57:06 CEST] <JEEB> GoD-Tony: yea but even the libavcodec encoder as far as I can tell is quite fast, and if you're converting files you can just run them parallel [09:57:07 CEST] <ubitux> if you want to use your h264/hevc encoder OTOH, good luck with the legal thing [09:57:43 CEST] <graphitemaster> nevcairiel, the irony here isn't so much that OpenGL can't do it or shouldn't do it. Nearly all hardware vendors support it, if not by virtue of the fact that it's needed for other things they already advertise. The problem is no one has standardized an extension for it yet. The ARB is just not interested. Meanwhile we get insane texture formats like shared 5-bit exponent and 9 bit RGB channels for cheaper HDR, which becomes [09:57:44 CEST] <graphitemaster> standard. That's not even sensical from a purity standpoint. [09:58:13 CEST] <graphitemaster> YCbCr makes more sense than RGB9E5 [09:58:51 CEST] <nevcairiel> odd [09:59:15 CEST] <graphitemaster> It's ironic because the argument here is that these optimized formats are meant to reduce bandwidth. Which is exactly what YCbCr is meant to do as well, half resolution Cb/Cr. [10:00:10 CEST] <GoD-Tony> JEEB: it can take a couple minutes to transcode a full film of audio, so it's fast, but could be 4+ times faster [10:00:53 CEST] <JEEB> where you just put multiple things next to each other on a higher level [10:00:56 CEST] <nevcairiel> or you could just transcode 4 movies at a time and have the same speed without hacks :) [10:01:12 CEST] <JEEB> I mean, threading is fun but I don't see the major positive side effect here [10:01:20 CEST] <JEEB> because audio encoding is so fast already [10:01:25 CEST] <graphitemaster> how fast can you chop a movie up into 4 pieces :P [10:01:41 CEST] <JEEB> doesn't even have to be the same thing chopped does it? [10:01:59 CEST] <JEEB> you can just work your back log multiple at once :P [10:01:59 CEST] <GoD-Tony> lol, yea all good points [10:02:52 CEST] <nevcairiel> unless you can do actual transparent multithreading, which in a codec like aac might not be really easy, its probably not worth it [10:03:31 CEST] <nevcairiel> i mean, that tool does just that, it slices the file into chunks and encodes them in parallel, using multiple encoder instances [10:03:42 CEST] <nevcairiel> it d oesnt actually multithread the encoder [10:04:09 CEST] <nevcairiel> you could apply that technique to any encoder in ffmpeg [10:04:17 CEST] <JEEB> hah, why did I guess it was like that :P [10:04:20 CEST] <nevcairiel> (or any encoder anywhere, for that matter) [10:05:08 CEST] <nevcairiel> some people use that for video encoding as well, because the frame-threading in video encoders doesnt scale properly for many cores [10:05:57 CEST] <graphitemaster> you're not going to get the optimal file size this way though [10:06:21 CEST] <nevcairiel> yeah, but the difference should be very minimal [10:06:25 CEST] <graphitemaster> extra reference frames for nothing [10:06:40 CEST] <graphitemaster> depends how much you parallelize it [10:06:45 CEST] <nevcairiel> if you're smart you find a scene cut to cut on [10:06:54 CEST] <nevcairiel> to reduce that effect [10:06:54 CEST] <graphitemaster> split the movie up into 1024 threads [10:07:02 CEST] <graphitemaster> yeah I guess [10:09:36 CEST] <graphitemaster> I've been toying with writing my own video codec for work because we have some shitty intel compute sticks to decode video on that claim to support hardware accelerated video decoding, just not at the resolutions we need, and also hard to get in an OpenGL application as a texture applied on a surface in a 3D scene. [10:10:01 CEST] <graphitemaster> We only need it for short 30 second advertisements [10:10:57 CEST] <graphitemaster> so I've been toying with converting frames into yuv planes, and taking each plane, and subdividing it as a quad tree, and giving each node of the quad tree an intensity value, then representing frame changes as quad tree changes [10:11:08 CEST] <graphitemaster> and then entropy encoding the quad trees [10:11:31 CEST] <graphitemaster> it works surprsingly well, just not happy with the file size still [10:12:21 CEST] <nevcairiel> i'm sure someone could recommend an existing codec with decent size and fast software decode on those tiny CPUs [10:12:33 CEST] <graphitemaster> doing some sort of dither at the beginning to reduce the palette helps file size but it's ugly quality wise [10:13:08 CEST] <graphitemaster> it beats motion jpeg in file size and quality though, so I got that going for it :P [10:15:10 CEST] <graphitemaster> the idea came from some existing work done by this guy http://d00m.org/~someone/qtc/ [10:15:33 CEST] <graphitemaster> he even has it working in javascript reasonably well http://d00m.org/~someone/qtc/qtwdemo/?VVVVVV1 [10:18:34 CEST] <graphitemaster> his demo videos are kind of unfair since he's only showing things that tend to have lots of areas of constant color [10:18:56 CEST] <graphitemaster> which this technique works really well with obviously [12:08:03 CEST] <atomnuker> GoD-Tony: nope, I discussed this in opus, the consensus was its insane [12:08:15 CEST] <atomnuker> it doesn't touch anything on the encoder itself [12:08:36 CEST] <atomnuker> instead it creates multiple encoder contexts and feeds them all at the same time, with an offset to each other [12:09:58 CEST] <atomnuker> the only codec you can thread sanely is opus, I think, since you can put up to 6 long/48 short frames in a packet [12:10:29 CEST] <atomnuker> (which I did do, but I dropped until I had proper analysis) [12:29:56 CEST] <GoD-Tony> yea fair enough. basically the same as splitting my audio in 4 big chunks and encoding them all at once, then concat [12:29:59 CEST] <GoD-Tony> probably wont do that [13:19:31 CEST] <cone-638> ffmpeg 03Michael Niedermayer 07master:b5995856a423: avcodec/diracdec: Fix overflow in DC computation [13:19:32 CEST] <cone-638> ffmpeg 03Michael Niedermayer 07master:c225da68cffb: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_pel_bi_w_pixels [13:19:33 CEST] <cone-638> ffmpeg 03Michael Niedermayer 07master:f0efd795f460: avcodec/clearvideo: Only output a frame if one is coded in the packet [13:19:34 CEST] <cone-638> ffmpeg 03Michael Niedermayer 07master:2d025e742843: avcodec/jpeg2000dsp: Fix multiple integer overflows in ict_int() [14:08:11 CEST] <cone-638> ffmpeg 03Ronald S. Bultje 07master:9bab39dee52a: vp9: fix compilation with threading disabled. [14:08:12 CEST] <cone-638> ffmpeg 03Ilia Valiakhmetov 07master:86eb50549a57: Changelog: add vp9 tile threading support [15:24:40 CEST] <GoD-Tony> heh, out of curiousity i wrote a script that does the above, encodes the audio with 8 ffmpeg processses and throws it all back together. ends up being a little over 2.5x faster [15:26:08 CEST] <nevcairiel> i would think you can get almost linear scaling, well, minus the cost of splitting and re-assembling, which is a bunch of disc IO i guess [15:33:16 CEST] <GoD-Tony> yea you're right, ill play around with it more a bit later to see if im missing something [15:34:21 CEST] <rcombs> up to whatever [total available CPU time] / [CPU time used by a single encode] is [15:35:51 CEST] <nevcairiel> of course if you run out of cpus it will stop [15:55:05 CEST] <BBB> anyone feel like fixing trivial tsan issues? http://fate.ffmpeg.org/report.cgi?time=20170906040551&slot=x86_64-archlinux… [15:55:16 CEST] <BBB> c->exit should be mutex-protected or atomic [15:55:49 CEST] <BBB> making it atomic is probably what the code intended it to be [15:59:07 CEST] <BBB> or Ill do it myself, lets be not-lazy [16:10:58 CEST] <jamrial> ubitux: your fate slots haven't run in five days [16:41:44 CEST] <cone-638> ffmpeg 03Steven Liu 07master:ad0d016f1cd2: MAINTAINERS: Add myself to maintainer of dashdec [18:28:19 CEST] <GoD-Tony> conclusion is the new bottleneck is IO on my hdd, which I dont mind. was cool to see the audio encode crazy fast anyway :P [19:45:56 CEST] <cone-638> ffmpeg 03Michael Niedermayer 07release/3.3:b590758298cc: avcodec/scpr: optimize shift loop. [19:45:57 CEST] <cone-638> ffmpeg 03Michael Niedermayer 07release/3.3:a295d1870a8c: avcodec/diracdec: Fix overflow in DC computation [19:45:58 CEST] <cone-638> ffmpeg 03Michael Niedermayer 07release/3.3:32fa6ce64afd: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_pel_bi_w_pixels [19:45:59 CEST] <cone-638> ffmpeg 03Michael Niedermayer 07release/3.3:4f97556f5489: avcodec/jpeg2000dsp: Fix multiple integer overflows in ict_int() [19:46:00 CEST] <cone-638> ffmpeg 03Michael Niedermayer 07release/3.3:eca53fd52bdc: Update for 3.3.4 [20:51:31 CEST] <ubitux> jamrial: mmh yeah, it's stalled in asan [20:51:41 CEST] <ubitux> i'll restart asap [21:29:16 CEST] <jamrial> ubitux: cool [21:30:04 CEST] <jamrial> oh, you took the chance to run pacman. good since it should have updated glibc as well [21:30:58 CEST] <jamrial> i think there was a ticket related to some compilation issue with glibc 2.26 [21:31:12 CEST] <jamrial> but it might have been related to cuda instead [21:38:34 CEST] <jamrial> BBB: http://fate.ffmpeg.org/log.cgi?time=20170911192454&log=compile&slot=x86_64-… the error at the end [21:39:12 CEST] <BBB> hm? [21:39:34 CEST] <BBB> lemmecheck [21:39:36 CEST] <BBB> sorry about that [21:39:58 CEST] <jamrial> i wonder why it doesn't fail on all cases [21:40:49 CEST] <jamrial> assert() seems to be ignored during compilation outside of that one fate client [21:41:20 CEST] <jamrial> it should be av_assert0 or 2 for that matter [21:42:02 CEST] <BBB> oh [21:42:03 CEST] <BBB> I chose 1 [21:42:08 CEST] <BBB> it was a random toincoss [21:42:09 CEST] <BBB> is 1 ok? [21:45:12 CEST] <jamrial> BBB: it should be ok i guess. i always see 0 used for checks that must be always done and 2 for checks in speed critical code [21:45:25 CEST] <jamrial> hence my suggestion. i didn't read the doxy in avassert.h [21:55:19 CEST] <BBB> jamrial: if its important, please review patch so I can push it [22:01:07 CEST] <BBB> jamrial: its only in a per-frame loop (2-pass decoding), so it executes once or twice per frame, and this is only ni 1-pass mode-related code [22:01:28 CEST] <BBB> so I think av_assert1 is more correct [22:01:32 CEST] <jamrial> ok, 1 should be good then [22:01:33 CEST] <BBB> its not per-block coding or anything like that [22:01:36 CEST] <BBB> ty [22:01:38 CEST] <BBB> will push [22:02:50 CEST] <BBB> pushed [22:02:58 CEST] <cone-638> ffmpeg 03Ronald S. Bultje 07master:4ce99e96d611: vp9: assert -> av_assert and fix associated compile error. [22:08:42 CEST] <atomnuker> jkqxz: are you going to push the kmsgrabber changes soon? [22:35:47 CEST] <jkqxz> atomnuker: Does that constitute approving the patch series? Noone has said anything about the wrapped_avframe stuff. [22:38:23 CEST] <jamrial> jkqxz: i think wm4 pointed it was a security concern. not sure if you addressed that [22:39:47 CEST] <jkqxz> Muhammad Faiz did. Is he here? The second version should have addressed that. [22:42:14 CEST] <jamrial> i don't think he is [22:42:24 CEST] <jamrial> maybe ping the thread? [22:42:56 CEST] <atomnuker> jkqxz: yep, it does, I've tested it and looked at the code [22:45:07 CEST] <atomnuker> jkqxz: though I'm not sure if the trusted flag would do any good [22:47:36 CEST] <jkqxz> It prevents the described attack which invokes the decoder externally; there might be some more subtle problem (which is why I'd like someone to actually look at it). [00:00:00 CEST] --- Tue Sep 12 2017

1 0

ffmpeg.log.20170911
by burek 12 Sep '17

12 Sep '17

[09:27:17 CEST] <hotbobby> I am looking for a suggestion of a RTSP streaming server that works with ffmpeg. I can only find proprietary solutions, all in one streaming software etc, nothing like nginx+rtmp module but for rtsp [09:28:28 CEST] <JEEB> yea, rtsp is definitely not as popular as those HTTP-based things nowadays [09:29:00 CEST] <hotbobby> i am researching alternative protocols due to low performance of flv video over high latency (not low bandwidth) connections [09:29:48 CEST] <hotbobby> if you ask me the popularity of rtmp is unwarranted :P [09:30:55 CEST] <JEEB> yes, and it really isn't popular any more [09:31:11 CEST] <JEEB> other than as an ingest format since most people are lazy to implement fragmented ISOBMFF or NUT or Matroska :) [09:31:34 CEST] <JEEB> even the nginx-rtmp module supports HLS and DASH which are very popular because those pesky browsers can use XHR to access the stream [09:32:04 CEST] <Nacht> RTMP is nice for low latency though [09:32:42 CEST] <hotbobby> oh even hls gave me poor performance. rather, it worked fine for the duration of chunk length but left me hanging a few seconds in between [09:33:07 CEST] <JEEB> usually players should be buffering ~3 segments [09:33:28 CEST] <JEEB> Nacht: I'd say anything that isn't chunk-based should be better than the HTTP stuff we have right now :D [09:33:42 CEST] <hotbobby> oh im just using vlc with the default options. i should look into that [09:33:45 CEST] <JEEB> the chunk-based stuff is currently 100% because of browsers not being able to keep reading [09:33:46 CEST] <kaninte> Hi! I'm trying to encode home videos so that I can archive them in my NAS. The goal is ofcourse to have small files with good quality. Using ffmpeg I get quite a size reduction but when I compare with other files for instance a whole 2h movie encoded to around 1.5GB my files are huge. Is there a standard way to do what I'm trying to do? [09:33:59 CEST] <JEEB> or well, they can read but they will also keep buffering I think? [09:34:30 CEST] <JEEB> like, even if you just do MPEG-TS over HTTP as a single stream that should have pretty low latency as long as you set up your encoder and player correctly [09:34:36 CEST] <JEEB> or Matroska [09:34:52 CEST] <hotbobby> you see, originally my files are mpeg 2 transport streams that are like 15 mbps [09:35:04 CEST] <hotbobby> i wish i could ust reencode at a lower bitrate but leave the ts alone! :P [09:35:08 CEST] <Nacht> 15Mbps total ? [09:35:26 CEST] <hotbobby> total? per second, yes [09:35:34 CEST] <Nacht> As in, all the different bitrates together ? [09:35:42 CEST] <hotbobby> the entire stream, yes [09:36:29 CEST] <Nacht> I quite like HLS, it's simple and does the job. [09:37:59 CEST] <hotbobby> kaninte: the way youve worded your question seems confusing. without going into detail you may not care about i suggest encoding your camera files as x264 at a decent enough bitrate you do not notice the degredation in quality. if you need help forming a command to do this just say so [09:38:48 CEST] <hotbobby> Nacht: i really want to like hls but it has that weird stuttering. perhaps i need to mess with different settings or just not watch inside of vlc [09:39:11 CEST] <Nacht> hotbobby: The manifest is looking normal ? [09:39:23 CEST] <JEEB> you will have issues if the latency doesn't go completely bonkers and your segment length is long enough [09:39:29 CEST] <JEEB> *is not long enough [09:39:38 CEST] <JEEB> argh, fuck my morning English [09:39:52 CEST] <hotbobby> i think segment length was 10s, but yes the latency -does- go bonkers thats the use case im trying to solve around [09:40:01 CEST] <kaninte> hotbobby: well, I was asking for a typical/standard way to encode videos for archiving. But yes, I use x264 crf:23 for video and ACC br:128. Do you have any suggestions? [09:40:05 CEST] <JEEB> basically if you have enough time to get the responses for the future segments that'll work as long as you're within two or so segments [09:40:22 CEST] <JEEB> but if your latency is really bonkers then the player will go through three segments and boom :P [09:40:40 CEST] <hotbobby> is there a standard way to encode video for arching? :P maybe losslessly [09:40:42 CEST] <JEEB> (a player with a general reading of the spec should have ~3 segments buffered) [09:40:50 CEST] <Nacht> Which are usually the first 2-3 segments your player is required to have to fill the buffer [09:40:56 CEST] <JEEB> they're trying to standardize FFV1 and Matroska for archival now in the EU [09:42:09 CEST] <hotbobby> i wish there was a hls that chunked on a single frame basis, i thought thats what rtmp does [09:42:16 CEST] <kaninte> hotbobby: yes, if you record movies of your baby and you want to store them and you don't want to upgrade your storage every week for the videos to fit :) [09:42:43 CEST] <hotbobby> like ideally i would just be taking my mpeg 2 stransport stream and lower the video bitrate so its not incredibly large :( [09:43:55 CEST] <hotbobby> kaninte: go all in on x265 maybe. it is -a- future but not -the- future :o [09:44:34 CEST] <hotbobby> hevc makes some tiny files but only the last 2(?) generations of intel cpus have hardware decoders for it [09:45:37 CEST] <kaninte> hotbobby: I've thought of that but what I've read x265 is more efficient on 4k videos. My videos are Full HD. Or do you mean that x265 has a better compression rate? [09:46:05 CEST] <JEEB> it is a better format in general but unfortunately it lacks a lot of love [09:46:11 CEST] <JEEB> I would not use it unless you specifically need HEVC [09:46:15 CEST] <hotbobby> its more efficient for any video, its cool seeing full episodes of shows being around a hundred megabytes [09:46:34 CEST] <hotbobby> but uhh yeah its the playback part thats not practical [09:46:41 CEST] <JEEB> no, the encoding one too [09:46:53 CEST] <kaninte> really? that's cool [09:46:57 CEST] <JEEB> as far as I've seen due to the lack of community around x265 [09:47:12 CEST] <JEEB> the encoder is not really anywhere close to being realistic to use [09:47:24 CEST] <JEEB> other than for very low bit rate scnearios where you will have artifacts in any case [09:47:30 CEST] <JEEB> and it's not the *format's* fault [09:47:34 CEST] <JEEB> the format is fine [09:47:46 CEST] <bencoh> well, for file encoding it's roughly fine [09:47:54 CEST] <bencoh> but don't expect to use it for live encoding [09:48:06 CEST] <JEEB> well this seemed to be some archival use case? [09:48:13 CEST] <JEEB> in which case something something lossless something something [09:48:37 CEST] <kaninte> but still my confusion is why "other" people can compress hour long movie to around 900MB with good quality and whatever I do I get 13min video around 600MB with same codec for video/audio [09:48:44 CEST] <hotbobby> lossless and save space by using black and white and mono audio :) [09:49:24 CEST] <kaninte> JEEB: Yes, just home videos I want to store.. but I will be making more all the time so I would like them to be small [09:50:24 CEST] <Nacht> kaninte: Most likely using higher CRF values [09:52:01 CEST] <kaninte> Nacht: I've been expermenting with CRF all weekend :) Problem is the only way I get comparable file sizes is using values like CRF=30. This really makes bad quality video [09:53:38 CEST] <hotbobby> do -crf and -b:v contradict eachother? [09:54:14 CEST] <kaninte> What do you mean? [09:54:20 CEST] <hotbobby> for example can i set a ceiling with the video bitrate flag and an attempted quality with crf? or does crf kind of take care of that itself [09:55:06 CEST] <kaninte> CRF uses variable bit rate so I've not try to assign a static value [09:56:26 CEST] <Nacht> Another option to try is using 2-pass encoding [09:57:00 CEST] <kaninte> Nacht: You mean using constant bitrate? [09:57:20 CEST] <kaninte> I thought that is discouraged [09:57:42 CEST] <hotbobby> i was live streaming at a constant bitrate until a few moments ago... [09:58:09 CEST] <hotbobby> crf is really cool i wish i had read the documentation more closely :P [09:58:27 CEST] <Nacht> 2-Pass encoding uses a constant bitrate, but allocates the bitrate to the places that need it most [09:59:02 CEST] <kaninte> Nacht: Hmm..I didn't know that [09:59:21 CEST] <JEEB> uhh, constant is usually used in a different context [09:59:29 CEST] <JEEB> that's usually called ABR (AVERAGE bit rate) [09:59:58 CEST] <JEEB> constant bit rate is when you are within some VBV/HRD parameters and keep the bit rate generally constant'ish within those parameters throughout the stream [10:04:07 CEST] <hotbobby> wow this is amazing, -crf 50 and -q:a 9 turn a 14mbps stream into like 50 kBps [10:04:27 CEST] <hotbobby> this works fine without stuttering on my cellular connection it's a shame it looks so bad :o [10:05:04 CEST] <kaninte> hotbobby: what does -q:a do? [10:05:13 CEST] <bencoh> I'ms sure it looks fine on a 64x64 display [10:05:43 CEST] <hotbobby> kaninte: crf for libmp3lame, 9 is worst 0 is best quality [10:07:04 CEST] <kaninte> hotbobby: It's for the audio? [10:07:14 CEST] <hotbobby> yes, variable bitrate audio [10:07:34 CEST] <hotbobby> whereas -b:a 320k would be constant (i think) [10:08:00 CEST] <JEEB> audio encoders generally don't have ABR rate control [10:08:06 CEST] <JEEB> which is why that ends up being CBR'ish [10:08:12 CEST] <JEEB> (depending on the exact encoder) [10:08:51 CEST] <kaninte> Yeah I had no idea that you could even do that for audio [10:10:07 CEST] <JEEB> generally audio takes so much less space that people generally only tend to implement quantizer-based VBR and something pretty much CBR [10:10:19 CEST] <JEEB> there's just not that much worth optimizing there in general [10:11:13 CEST] <hotbobby> yeah i am not really enjoying any real space saving encoding audio at 64k as opposed to v0. i think v0 averages ~260k [10:11:39 CEST] <bencoh> just set a constant bitrate for audio, don't bother playing with that [10:11:44 CEST] <bencoh> :) [10:13:16 CEST] <hotbobby> is it possible to pass through the audio from the source untouched? [10:13:38 CEST] <hotbobby> reencoding lossy mp3 to lossy mp3 again is..... lame :o [10:15:56 CEST] <hotbobby> -c:a copy [10:45:15 CEST] <kaninte> Anyone used the preset tuning? How much difference could you expect? [10:46:35 CEST] <JEEB> it depends on various things, you should generally use the slowest preset that is fast enough for your use case [10:46:46 CEST] <JEEB> in libx264 at least [10:47:35 CEST] <kaninte> There are additional tunings like film,animation,grain, etc.. [10:48:03 CEST] <JEEB> yes, tunes are tunes [10:48:06 CEST] <JEEB> presets are presets [10:48:23 CEST] <JEEB> tunes are not required [10:48:36 CEST] <JEEB> presets are something you should set although 'medium' (default) is not bad [10:48:46 CEST] <kaninte> I know, but how much gain will you get using them? [10:49:08 CEST] <kaninte> I thought tunes are part of preset.. oops :) [10:51:27 CEST] <JEEB> nope [10:53:48 CEST] <hotbobby> there is an excellent table that defines the commands used in presets for extra finetuning http://dev.beandog.org/x264_preset_reference.html [10:54:13 CEST] <hotbobby> i believe the ones that make the biggest different are scene changes and lookahead? [10:55:05 CEST] <kaninte> thanks [13:28:53 CEST] <alqemyst> hi, does anybody knows is it possible to stream mpegts to unix domain socket? [13:29:07 CEST] <JEEB> why not? [13:29:56 CEST] <alqemyst> I'm looking to unix.c, but can't find the way to do it [13:30:19 CEST] <alqemyst> is socket created with ffmpeg? [13:38:13 CEST] <Nacht> alqemyst: https://ffmpeg.org/ffmpeg-protocols.html#unix [13:40:02 CEST] <alqemyst> but what is the syntax then: -f mpegts unix:///var/run/test.sock [13:41:07 CEST] <Nacht> That should work I believe [13:41:43 CEST] <alqemyst> hm.. [13:41:44 CEST] <alqemyst> unix:///var/run/test.sock: No such file or directory [13:45:50 CEST] Action: mrAZ looking for help with -map or -map_channel option: needed to extracl left from 2nd audio channel to 1+2nd channel(mono) [13:46:55 CEST] <alqemyst> if I change this line in unix.c then socket is created, but nothing happends really [13:47:00 CEST] <alqemyst> { "listen", "Open socket for listening", OFFSET(listen), AV_OPT_TYPE_BOOL, { .i64 = 1 }, [13:51:07 CEST] <alqemyst> but when I connect first reader it start with encoding, when I stop reader it breaks [13:51:11 CEST] <alqemyst> strange [13:52:34 CEST] Action: mrAZ have detected the channels https://paste.ubuntu.com/25514054/ so i think i would need 0.2.0, but then how to map it to 2 mono channels? [13:53:59 CEST] Action: mrAZ or do i need pan option? [13:55:35 CEST] <Nacht> mrAZ: Both should suffice. https://trac.ffmpeg.org/wiki/AudioChannelManipulation [13:55:56 CEST] <mrAZ> Nacht: i was reading that [14:24:58 CEST] <alqemyst> it works if socket is created before ffmpeg [14:25:00 CEST] <alqemyst> socat - UNIX-LISTEN:/var/run/test.sock [14:25:31 CEST] <alqemyst> but if ffmpeg is stopped it also destroys the socket, which is not correct behaviour in my opinion [15:12:32 CEST] <paveldimow> Hi, anyone knows if it's possible to have one process to write mp4a file while other is reading/playing ? [15:12:42 CEST] <JEEB> fragmented isobmff [15:13:24 CEST] <paveldimow> that was FAST :) [15:14:24 CEST] <JEEB> basically set the fragment duration accordingly (with audio only it can be as short as a single sample if you *really* want) [15:14:36 CEST] <JEEB> and the muxer should write fragmented output [15:14:50 CEST] <JEEB> now, of course it depends on what is reading that thing, if it supports movie fragments [15:15:44 CEST] <paveldimow> Huh, Wowza (media server we are using) does not support fmp4 :( [15:16:00 CEST] <paveldimow> my idea was to use wowza to save live audio [15:16:47 CEST] <paveldimow> while I have ffmpeg to read that file and use uct/trim to get the segment user requested... [15:16:55 CEST] <DHE> maybe use a different format then? mpegts maybe? [15:17:09 CEST] <DHE> not a wowza user, just throwing out ideas [15:17:26 CEST] <paveldimow> IIRC they can only use mp4 for recording [15:17:39 CEST] <paveldimow> but I will check thank you JEEB and DHE [15:23:37 CEST] <grkblood13> I'm having an issue with mapping. Whenever I run the following script I get the error: "Invalid input file index: 1." Could someone tell me what's wrong? https://pastebin.com/a4QqknLN [15:25:44 CEST] <klaxa> i think you want 0:1 instead of1:0 [15:26:10 CEST] <klaxa> doesn't look like you have 2 input files, but only one [15:26:37 CEST] <klaxa> wait... what are you trying to do? [15:26:56 CEST] <grkblood13> this: http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live… [15:27:10 CEST] <grkblood13> take an input source and make two seperate output sources i believe [15:27:28 CEST] <grkblood13> i tried 1:0 thinking that might work but it was the same thing. [15:27:57 CEST] <klaxa> huh... 1:0 should be correct [15:28:23 CEST] <klaxa> are you using alsa or pulseaudio? if you are using pulseaudio you should use: -f pulse -i default instead of -f alsa [...] -i hw:2 [15:28:29 CEST] <klaxa> maybe you need to use hw:0 also? [15:28:38 CEST] <klaxa> instead of hw:2 i mean [15:28:42 CEST] <klaxa> not too good with alsa [15:28:52 CEST] <grkblood13> well, i took all of that out since my input is different [15:29:06 CEST] <grkblood13> in my script im just doing -i $1 [15:29:15 CEST] <grkblood13> $1 being a stream link [15:29:15 CEST] <klaxa> then you have no second input [15:29:31 CEST] <klaxa> does it have audio? then you want -map 0:1 instead of -map 1:0 [15:29:50 CEST] <grkblood13> alright, thanks [15:29:53 CEST] <klaxa> although that will only map it to the second output and not to the first [15:30:09 CEST] <klaxa> you could skip using -map altogether and it will use video and audio for both by default [15:30:46 CEST] <grkblood13> well, i have to map if its using different codecs correct? [15:31:01 CEST] <grkblood13> their tutorial uses vp9 for one and vp8 for the other [15:31:41 CEST] <klaxa> i'm not 100% sure, but i don't think so, otherwise use -map 0:0 -map 0:1 in front of -c for both outputs [15:33:57 CEST] <c_14> klaxa: I think one of the outputs is audio-only and one video-only, so what he's doing is correct (barring the 1:0 0:1 switchup) [15:34:38 CEST] <c_14> (as in, he doesn't want to map both streams in both outputs) [15:34:52 CEST] <klaxa> >-c:a libvorbis \ [15:34:52 CEST] <klaxa> > -c:v libvpx \ [15:34:57 CEST] <klaxa> that tells a different story though :P [15:35:29 CEST] <c_14> yeah, but he sets the video bitrate for one and the audio bitrate for the other [15:35:31 CEST] <c_14> never both [15:35:39 CEST] <c_14> and he sets audio_chuck_duration for only the second one [15:36:17 CEST] <c_14> Though he does set -deadline for the second output instead of the first [15:36:23 CEST] <c_14> Which is a libvpx-only option [15:36:35 CEST] <grkblood13> well, the script is working now so thats good [16:35:41 CEST] <paveldimow> Can I read/write to flv at the same time? [16:36:03 CEST] <paveldimow> I can't find any usable info about it [16:43:00 CEST] <paveldimow> heh it looks like flv is indeed read/write compatible! what a nice format :) [17:18:35 CEST] <Fyr> guys, are there ARM computers for encoding? [17:19:08 CEST] <Fyr> I mean computers, like Raspberry Pi, but designed particularly to encode video. [17:22:33 CEST] <Nacht> Well.. yeah. Hardware encoders [17:22:52 CEST] <Nacht> Like Ericson or Harmonics [17:23:14 CEST] <Nacht> Ericsson* [17:23:43 CEST] <Nacht> https://www.harmonicinc.com/ [17:25:22 CEST] <klaxa> many GPUs include encoding hardware as well [17:26:45 CEST] <Mavrik> They're just not good. [17:27:29 CEST] <klaxa> is there any "good" encoding hardware? [17:29:15 CEST] <Nacht> I quite enjoyed my old Envivio encoders. They were quite good [17:30:04 CEST] <Mavrik> Envivios are okish, but still can't really compete with Xeon servers running x264 [17:30:13 CEST] <furq> can anything [17:30:44 CEST] <Mavrik> Nope. [17:30:53 CEST] <furq> i'm glad we cleared that up [17:30:58 CEST] <Mavrik> I think Cisco and some of those now actually sell you a "hardware encoder" [17:31:05 CEST] <Mavrik> Which is a Xeon box with their software running x264 :P [17:31:08 CEST] <furq> nice [17:31:12 CEST] <furq> not even their own h264 encoder [19:48:01 CEST] <Fyr> can FFMPEG utilize Intel Phi? [19:52:39 CEST] <JEEB> Fyr: no [19:52:49 CEST] <kepstin> but Intel VCA/VCA2 should work fine [19:52:59 CEST] <kepstin> (they're just some xeon chips on pcie cards) [19:55:23 CEST] <Fyr> JEEB, why does FFMPEG keep avoiding AMD's VCE? [19:55:49 CEST] <JEEB> I don't think it does? nobody just cared about it is the real thing. although doesn't it expose something through VA-API? [19:55:55 CEST] <JEEB> VA-API is something that FFmpeg supports [19:56:18 CEST] <Fyr> on Linux, yes. [19:57:02 CEST] <JEEB> on windows you have dxva2 [19:57:21 CEST] <JEEB> encoding wise someone has to give a shit and since FFmpeg is a community project... :P [19:57:29 CEST] <Fyr> it doesn't bring actually acceleration. [19:57:55 CEST] <JEEB> uh-huh, this HEVC dxva2 decoding through lavc totally is just a mistake and never happened [19:57:57 CEST] <JEEB> nod nod [19:58:30 CEST] <JEEB> of course I have no idea if ffmpeg.c supports it, but that's now none of my problem (Ž4@) [20:07:06 CEST] <stripes416> win 2 [20:07:17 CEST] <stripes416> geez, sorry y'all [21:17:21 CEST] <analogical> hi is it possible to convert an MKV-file to an MP4-file without re-encoding the file?? [21:17:37 CEST] <JEEB> ffmpeg -i input.mkv -c copy out.mp4 [21:17:46 CEST] <analogical> ...using FFMPEG [21:17:47 CEST] <JEEB> (add -map 0 if you want all streams from input) [21:27:01 CEST] <iive> have in mind that mp4 supports less formats than mkv :D [21:29:02 CEST] <JEEB> well that's a given, yes [21:46:52 CEST] <kmax> help [21:47:28 CEST] <kmax> any HLS gurus in here? [21:47:52 CEST] <kmax> using HLS to get RTSP video from cctv cams out to html5 video [21:48:12 CEST] <kmax> creating the m3u8 on the fly... takes a long time [21:48:23 CEST] <kmax> trying to figure out if there is a way to speed it up [21:48:37 CEST] <kmax> tried lowering the length of the chunks etc etc [21:57:44 CEST] <kmax> anyone know of a forum dedicated to ffmpeg support? [22:01:35 CEST] <c7j8d9> doom9? [00:00:00 CEST] --- Tue Sep 12 2017

1 0

ffmpeg-devel.log.20170910
by burek 11 Sep '17

11 Sep '17

[00:00:26 CEST] <hanna> that explains it [00:00:32 CEST] <jamrial> nevcairiel: any reason you didn't submit 543dc6060c to the ml? [00:00:36 CEST] <hanna> doesn't it reuse the SIMD-accelerated block search from x264 etc? [00:01:29 CEST] <nevcairiel> jamrial: its kind of ugly and I didnt test much with a variety of hardware [00:01:39 CEST] <jamrial> ah [00:02:13 CEST] <nevcairiel> i tried to put it into the flags member, but that one has too much logic baked into it for sanity [00:03:09 CEST] <durandal_1707> hanna: no its all c and lgpl, x264 is gpl [00:03:22 CEST] <atomnuker> also x264 doesn't expose them [00:03:42 CEST] <jamrial> nevcairiel: was going to say, sounds like it fits better as a flag than its own field [00:03:56 CEST] <atomnuker> it uses the good old snow encoder obmc [00:04:07 CEST] <hanna> ah okay [00:04:17 CEST] <hanna> well I would be interested in perhaps writing a compute shader accelerated version of this [00:04:22 CEST] <nevcairiel> flags is really more a "refs", every bit set in it indicates its still being held on to for various reasons [00:04:23 CEST] <hanna> if you can help me with the algorithm [00:04:25 CEST] <JEEB> sounds cool [00:04:30 CEST] <nevcairiel> and flags == 0 has special meaning [00:04:49 CEST] <nevcairiel> so it got ugly to put anything unrelated in there [00:05:44 CEST] <jamrial> nevcairiel: flags2 :D [00:06:32 CEST] <nevcairiel> would rather rename flags at that point [00:06:37 CEST] <durandal_1707> hanna: read the code , its straight forward [00:07:51 CEST] <nevcairiel> in any case sending empty dummy frames to the hardware doesnt really help it, and can even have negative effects, but I haven't confirmed yet if this applies to all hardware or if some might require it [01:05:31 CEST] <thebombzen> I'm not sure if this is a bug in NVCC or in FFmpeg, but I can't compile CUDA anymore. I recently updated gcc to 7.2, or it might have been a recent patch on git master, and now libavfilter/vf_scale_cuda.ptx won't compile [01:06:20 CEST] <JEEB> it's the nvcc thing derping IIRC [01:06:42 CEST] <JEEB> related thing https://trac.ffmpeg.org/ticket/6648 [01:08:07 CEST] <thebombzen> that's the exact error I'm getting [01:10:55 CEST] <thebombzen> googling it said add -std=c++11 to your cxxflags, but I tried adding it to --extra-cxxflags and --nvccflags and it didn't work [01:11:24 CEST] <JEEB> anyways, it's the nvcc derping with the new glibc [01:11:33 CEST] <JEEB> (not related to the GCC itself as far as I can tell) [01:11:39 CEST] <JEEB> (most likely glibc got updated, too) [01:11:57 CEST] <thebombzen> probably? but that error is the same one I'm getting, so yea [01:12:11 CEST] <thebombzen> I'm also on Arch, as was the person who reported that [02:15:44 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:4306ddd87d09: avcodec/diracdec: Check weight_log2denom [02:15:45 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:c55478835275: avcodec/diracdsp: fix integer overflow [02:15:46 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:ef8db67c9295: avcodec/h264idct_template: Fix integer overflow in ff_h264_idct_add() [02:15:47 CEST] <cone-087> ffmpeg 03James Cowgill 07release/3.3:8aa32a8d5c6b: swscale: fix gbrap16 alpha channel issues [02:15:48 CEST] <cone-087> ffmpeg 03Steven Siloti 07release/3.3:fd871e24e65b: avformat/utils: fix memory leak in avformat_free_context [02:15:49 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:1dbfcd65b26d: avcodec/h264_slice: Fix overflow in slice offset [02:15:50 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:818f73542daf: avcodec/aacdec_fixed: fix invalid shift in predict() [02:15:51 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:86b5a3d35dd2: avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97* [02:15:52 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:dcf02ee6c691: avcodec/mpeg4videodec: Clear mcsel before decoding an image [02:15:53 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:f5c6ce899fa5: avcodec/ffv1dec_template: Fix undefined shift [02:15:54 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:a33e375d7d4c: avcodec/diracdec: Check perspective_exp and zrs_exp. [02:15:55 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:02d224406f40: avcodec/diracdec: Fixes integer overflow [02:15:56 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:99491bd260d3: avcodec/zmbv: Check decomp_size [02:15:57 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:53dae9585f1f: avcodec/pixlet: fixes integer overflow in read_highpass() [02:15:58 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:16772e43ef5a: avcodec/snowdec: Fix off by 1 error [02:15:59 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:f5227c50b739: avcodec/fic: Fixes signed integer overflow [02:16:00 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:253b7829e4f5: avcodec/dirac_dwt_template: Fix integer overflow in vertical_compose53iL0() [02:16:01 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:736ef73f9c04: avcodec/pixlet: Fixes: undefined shift in av_mod_uintp2() [02:16:02 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:4a122a0879d5: avcodec/me_cmp: Fix crashes on ARM due to misalignment [02:16:03 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:6ce9b2c1fec1: avcodec/aacdec_template: Fix running cleanup in decode_ics_info() [02:16:04 CEST] <cone-087> ffmpeg 03Vitaly Buka 07release/3.3:b6a79b841dcd: avcodec/utils: Fix signed integer overflow in rc_initial_buffer_occupancy initialization [02:16:05 CEST] <cone-087> ffmpeg 03Vitaly Buka 07release/3.3:c8890413520a: avformat/mov: Fix signed integer overflows with total_size [02:16:06 CEST] <cone-087> ffmpeg 03Vitaly Buka 07release/3.3:9739a269fb4d: avformat/aviobuf: Fix signed integer overflow in avio_seek() [02:16:07 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:deca5e734913: avformat/rtpdec_h264: Fix heap-buffer-overflow [02:16:08 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:eea01de3ff15: avcodec/hevc_ps: Check delta_pocs in ff_hevc_decode_short_term_rps() [02:16:09 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:5474a7e93b8e: ffprobe: Fix null pointer dereference with color primaries [02:16:10 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:85ffdcd8ffe4: ffprobe: Fix NULL pointer handling in color parameter printing [02:16:11 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:305f37e5be00: avformat/hls: Fix DoS due to infinite loop [02:16:12 CEST] <cone-087> ffmpeg 03Yi and *®() 07release/3.3:6447815dfbbe: avformat/asfdec: Fix DoS due to lack of eof check [02:16:13 CEST] <cone-087> ffmpeg 03Yi and *®() 07release/3.3:4ff1fcd3caa2: avformat/cinedec: Fix DoS due to lack of eof check [02:16:14 CEST] <cone-087> ffmpeg 03Yi and *®() 07release/3.3:6bd562e04440: avformat/rmdec: Fix DoS due to lack of eof check [02:16:15 CEST] <cone-087> ffmpeg 03Yi and *®() 07release/3.3:8cb0f2c4e55d: avformat/rl2: Fix DoS due to lack of eof check [02:16:16 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:e910f15fcbb7: avformat/mvdec: Fix DoS due to lack of eof check [02:16:17 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:b5f0302eeb74: avcodec/sbrdsp_fixed: Fix undefined overflows in autocorrelate() [02:16:18 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:25ff26aaac97: avcodec/hevc_ps: Fix undefined shift in pcm code [02:16:19 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:cd221a86a6a3: avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered() [02:16:20 CEST] <cone-087> ffmpeg 03Yi(SÑ) 07release/3.3:e6a8d110d7e8: avformat/nsvdec: Fix DoS due to lack of eof check in nsvs_file_offset loop. [02:16:21 CEST] <cone-087> ffmpeg 03Yi(SÑ) 07release/3.3:c01f799314c3: avformat/mxfdec: Fix DoS issues in mxf_read_index_entry_array() [02:16:22 CEST] <cone-087> ffmpeg 03Yi(SÑ) 07release/3.3:9d3a7c82a669: avformat/mxfdec: Fix Sign error in mxf_read_primer_pack() [02:16:23 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:73427f5c7499: avcodec/diracdec: Fix integer overflow in INTRA_DC_PRED() [02:16:24 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:fef0ccc40132: avcodec/dirac_dwt: Fix multiple overflows in 9/7 lifting [02:16:25 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:8a640fc7cb5e: avcodec/dirac_vlc: Fix invalid shift in ff_dirac_golomb_read_32bit() [02:16:26 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:d9cf9f5af822: avformat/mov: Fix DoS in read_tfra() [02:16:27 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:b61e5a878c84: avformat/asfdec: Fix DoS in asf_build_simple_index() [02:16:28 CEST] <cone-087> ffmpeg 03Mark Wachsler 07release/3.3:1df91b48a39a: libavcodec/h264_parse: don't use uninitialized value when chroma_format_idc==0 [02:16:29 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:8eb8882af5cc: avcodec/dirac_vlc: limit res_bits in APPEND_RESIDUE() [02:37:39 CEST] <atomnuker> kierank: x264's commerical license is basically LGPL, right? [02:37:47 CEST] <kierank> no idea [02:37:53 CEST] <kierank> ask j-b [02:37:54 CEST] <atomnuker> https://mailman.videolan.org/pipermail/x264-devel/2010-July/007508.html [02:38:07 CEST] <kierank> why? [02:39:29 CEST] <atomnuker> JEEB said the other day in #ffmpeg it was fully commerical (e.g. you didn't have to release modifications) [02:40:02 CEST] <kierank> there was a time where i cared about that but now i don't [03:03:06 CEST] <cone-087> ffmpeg 03James Almer 07master:27a86b8ece6f: avfilter/vf_convolve: use av_clip_uint8 [03:15:56 CEST] <iive> atomnuker: it is not LGPL, it is fully commercial and you have to give modifications back to x264, is what I understand from this email. [03:24:31 CEST] <kode54> amazing [03:25:03 CEST] <kode54> so apparently, if I want an implementation of iTunes gapless MP3 tag support in, I have to write a test for it, and craft a public domain test vector [03:25:56 CEST] <kode54> is there a test framework that can already handle opening a given stream file into a context for me, so I can just verify that the length of the file is correct? [04:50:00 CEST] <jamrial> kode54: what do you mean? [04:50:08 CEST] <kode54> well [04:50:36 CEST] <kode54> first I wrote and contributed an implementation that supports reading named comment tags from ID3v2, which has been integrated [04:50:56 CEST] <kode54> then I wrote something that reads the iTunSMPB tag, parses it, and applies it to MP3 files with iTunes gapless info [04:51:15 CEST] <kode54> but someone on the mailing list told me it would not be applied until I included some tests [04:51:29 CEST] <jamrial> what's the patch/thread name? [04:52:34 CEST] <jamrial> adding a test is not a requirement for a new feature. it's encouraged (to detect regressions in the future) but the lack of a test should not prevent a feature to be added [04:54:40 CEST] <kode54> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206198.html [04:54:49 CEST] <kode54> poster asked for a fate test, whatever that is [04:55:04 CEST] <kode54> I can make a test, but I need to know where I should design it and put it [04:55:21 CEST] <kode54> basically, I can encode some short test content with iTunes, and verify that their reported lengths are correct [04:55:56 CEST] <kode54> it's a slightly annoying tag to deal with, since it requires parsing ID3v2 first [04:56:38 CEST] <kode54> the tag contains hex encoded fields for pregap, total stream sample count, and a file byte offset of the last six packets of the file [04:56:41 CEST] <jamrial> kode54: fate is https://ffmpeg.org/fate.html [04:57:02 CEST] <jamrial> it's our intergrated test system, to detect regressions and such [04:58:19 CEST] <jamrial> what you were asked was for a sample file (which would be uploaded to the samples repository), and a test using it [04:58:29 CEST] <jamrial> in this case a simple demuxing test should suffice i guess [04:58:42 CEST] <kode54> just needs to open the file and check its length [04:58:51 CEST] <jamrial> the patch can go in without the test, but ideally one should be added. mp3 demuxing can be easily broken [04:58:58 CEST] <kode54> right [04:59:02 CEST] <kode54> I will make a test [04:59:23 CEST] <kode54> does it need to be a full avformat session startup/shutdown? [04:59:41 CEST] <jamrial> you don't need to write a test program [04:59:44 CEST] <kode54> oh [05:00:01 CEST] <jamrial> a simple fate test can just run a ffmpeg cli command [05:00:16 CEST] <jamrial> check the tests folder in the repo [05:00:46 CEST] <jamrial> tests/fate has a bunch of Makefiles with recipes to run different tests [05:00:59 CEST] <jamrial> look at gapless.mak specifically [05:02:14 CEST] <jamrial> you say this just changes the duration value? does it affect timestamps and such? [05:08:49 CEST] <kode54> it changes mp3->start_pad and mp3->end_pad, (MP3DecContext) and applies the start_pad + 529 to AVStream start_skip_samples [05:09:21 CEST] <kode54> subtracting the 529 (decoder delay) from the end pad if it's large enough [05:09:39 CEST] <kode54> oh yeah [05:09:45 CEST] <kode54> and it affects the duration returned to the caller [05:10:21 CEST] <kode54> it affects stream duration field and bitrate field [05:10:29 CEST] <kode54> not sure if the seek table is built yet by that point [05:10:49 CEST] <jamrial> the three of those MP3DecContext fields seem to only be looked at if the encoder is lame, lavf or lavc, at least on git head [05:10:51 CEST] <kode54> called from mp3_parse_vbr_tags [05:11:39 CEST] <jamrial> ah wait, start_skip_samples is an AVStream field [05:11:46 CEST] <kode54> it applies duration to AVStream->duration if the itunes function affects it (returns that value 0 if not, prompting caller to ignore it) [05:12:35 CEST] <kode54> I had to redo the comments patch too [05:12:45 CEST] <kode54> because iTunes writes v2.2 tags [05:13:44 CEST] <kode54> I can encode a test file, assuming there's some public domain audio I should use first? [05:16:53 CEST] <jamrial> kode54: use https://0x0.st/7rk.wav, and try to make the encoded file as short as possible [05:17:01 CEST] <jamrial> 30 audio frames or so, for example [05:17:59 CEST] <kode54> well, then I'll need to trim it to 30 frames worth of audio [05:18:11 CEST] <kode54> or I'll have to construct my own gapless header [05:18:16 CEST] <kode54> I wonder if itunes encodes files that short? [05:19:12 CEST] <jamrial> it can be longer if needed. the point is that it should not be too big since it will be added to the fate samples repository [05:19:19 CEST] <kode54> right [05:19:41 CEST] <jamrial> and because the more frames the file has, the bigger the reference output of the cli will be [05:21:02 CEST] <jamrial> use ffmpeg to trim the above wav to whatever amount of frames you think itunes will accept [05:23:13 CEST] <jamrial> then look at gapless.mak, near the end of the file, and duplicate one of the existing probegaplessinfo tests for your sample [05:24:05 CEST] <jamrial> name the test fate-gaplessinfo-itunes3 for example [05:28:40 CEST] <kode54> I'll need to build my own stuff to ffprobe it first [05:29:04 CEST] <kode54> is there any way to make configure spew out tons of useless info before it completes? [05:29:45 CEST] <kode54> oh well, building, then I'll assemble a test [05:39:02 CEST] <Compn> yes there is a way to get configure to do that [05:39:15 CEST] <Compn> i forgot how :) [05:56:00 CEST] <kode54> so how do I generate one of those gaplessinfo files? [05:59:46 CEST] <jamrial> kode54: add your test in gapless.mak poiting to your sample in the fate repo folder, then run "make testname GEN=1" [06:00:02 CEST] <jamrial> as i said, the name can be fate-gaplessinfo-itunes3 for example [06:01:05 CEST] <jamrial> if you didn't sync the whole fate samples repo somwhere (like 1gb of samples) then just create an empty folder with the expected hierarchy and put the sample there [06:01:39 CEST] <jamrial> use SAMPLES=/path/to/samples as part of the make options if you didn't run configure with --samples [06:02:33 CEST] <jamrial> if you want to sync the whole samples repo, run make fate-rsync and wait [06:03:02 CEST] <kode54> ran fate-rsync to get the command line [06:03:06 CEST] <kode54> running it on a NAS4Free instance [06:03:44 CEST] <jamrial> you don't really need the whole thing if you're not planning on running the whole suit [06:03:53 CEST] <kode54> probably not [06:04:03 CEST] <jamrial> for this test, just your sample in the expected folder is enough [06:04:25 CEST] <kode54> is there a gapless folder? [06:04:57 CEST] <jamrial> yes, look at fate-gaplessinfo-itunes2 [06:05:05 CEST] <jamrial> $(TARGET_SAMPLES)/gapless [06:06:01 CEST] <kode54> what about that other gapless mp3 sample? [06:06:39 CEST] <jamrial> that's used by fate-gapless-mp3 [06:07:09 CEST] <jamrial> not sure what kind of gapless information it uses, but certainly not itunes [06:27:21 CEST] <cone-047> ffmpeg 03Diego Biurrun 07master:cbe181c8e161: build: Skip generating .version files when cleaning [06:32:11 CEST] Action: jamrial sleeps [09:48:20 CEST] <durandal_1707> atomnuker: i will add weston capture format demuxer and decoder, ok? [12:38:48 CEST] <JEEB> atomnuker: what I said you released libx264 changes to x264 LLC, that's why you get those pastebins on #x264dev [12:39:09 CEST] <JEEB> but as far as I know you don't have to give those changes to people who request, although I might be incorrect of course :P [12:51:24 CEST] <atomnuker> durandal_1707: nope, don't do specific protocols unless you want to end up with 10 or more [12:51:30 CEST] <atomnuker> the sway guys made one [12:51:36 CEST] <atomnuker> the orbment guy made one [12:51:43 CEST] <atomnuker> the kde guys have one [12:51:48 CEST] <atomnuker> the gnome guys have one too [12:51:53 CEST] <atomnuker> and of course weston [12:52:12 CEST] <atomnuker> and whatever other nih their own protocol [12:52:38 CEST] Action: JEEB at one point was doing a wl_shell compatibility modes for ivi_shell [12:54:04 CEST] <atomnuker> the DRI capture one jkqxz wrote would be way more useful [12:57:17 CEST] <JEEB> I'm not even trying to compete there, just mentioned a Yet Another NIH'd protocol (ivi_shell) [12:57:34 CEST] <JEEB> and how to make it actually useful you had to add a wl_shell compatibility layer ;) [12:57:53 CEST] <iive> what is this about? [12:58:21 CEST] <JEEB> wayland protocols [12:59:11 CEST] <iive> for capturing screen? [12:59:56 CEST] <JEEB> according to the nearby back-log it seems like he is dis-recommending durandal_1707 from doing something specific to some wayland protocol, since there's so many of them [13:28:34 CEST] <durandal_1707> wcap from recording screen, simple rle codec [13:38:30 CEST] <jkqxz> It's just a simple codec which gets used in the capture files, not a protocol. Makes sense for ffmpeg to be able to take it as input from files. [13:38:51 CEST] <JEEB> yea [13:38:53 CEST] <jkqxz> (Dunno why they had to make a new codec for it - maybe they have some GPU magic to compute it quickly? Or just pointless NIH.) [18:03:43 CEST] <jkqxz> Would there be much protest if I proposed deleting the old opencl stuff entirely? [18:03:49 CEST] <jkqxz> It was added in early 2013, abandoned a few months later, and hasn't changed since. [18:04:40 CEST] <jkqxz> There is a load of pointless external API only used by the two filters in lavfi, using a lot of global state in lavu. [18:19:40 CEST] <atomnuker> not at all, go right ahead [18:20:15 CEST] <atomnuker> I can convert them to vulkan compute once I get chromaticaberration running [18:21:07 CEST] <jkqxz> I'm also going to submit OpenCL hwcontext, which might sour you to the idea :P [18:21:27 CEST] <atomnuker> yes, it would, my vulkan hwcontext is done [18:21:46 CEST] <jkqxz> (Including interop with Beignet, IntelMediaBlob, DXVA2, D3D11 and ARM Mali.) [18:22:09 CEST] <atomnuker> yeah well I have an interopt with cuda, though its untested [18:23:06 CEST] <atomnuker> do you seriously think people are going to write opencl crap even if there's all these interops? [18:23:24 CEST] <jkqxz> No idea. People seem to like GPU-only stuff. [18:23:50 CEST] <atomnuker> opencl is old news, outdated, hardly supported, and one one seems to know how to write stuff for it [18:24:06 CEST] <atomnuker> (those that do give up and leave it bitrotting) [18:24:08 CEST] <jkqxz> OpenCL is supported on pretty much every device you get nowadays, unlike Vulkan. [18:24:20 CEST] <atomnuker> for now... [18:24:43 CEST] <atomnuker> though support can hardly be called support [18:24:58 CEST] <atomnuker> beignet is crappily packaged and quite heavy [18:25:10 CEST] <jkqxz> I was a bit shocked that it all worked with the Rockchip MPP stuff, I admit. [18:25:28 CEST] <atomnuker> you need extra library crap everywhere [18:25:44 CEST] <atomnuker> rather than a single library with vulkan [18:25:46 CEST] <jkqxz> ? Beignet is fine, it's just one library. [18:26:16 CEST] <atomnuker> fine? its crap, doesn't even have the right name [18:27:05 CEST] <atomnuker> should have been called libopencl and been the only one [18:27:32 CEST] <jkqxz> Um, no. The ICD loader exists so that you can use multiple implementations properly. [18:27:59 CEST] <atomnuker> and ICD loader? vulkan handles that stuff for you [18:28:04 CEST] <atomnuker> how outdated [18:28:10 CEST] <jkqxz> Nothing should be called libopencl except the ICD loader. [18:28:19 CEST] <jkqxz> How does vulkan do it? [18:29:22 CEST] <atomnuker> dunno, I don't think anyone has tried to support multiple implementations (because obviously there should only be one and its called mesa) but its there on paper [18:30:26 CEST] <jkqxz> True, but unfortunately proprietary drivers exist. [18:30:54 CEST] <jkqxz> Is there mesa/nouveau vulkan for nvidia then? I thought that didn't exist. [18:30:54 CEST] <atomnuker> I think they've started to go extinct as far as linux goes [18:31:30 CEST] <atomnuker> nope, nouveau doesn't support vulkan yet, but amdgpu does and its faster than the binary [18:31:36 CEST] <jkqxz> For Intel they died a long time ago, AMD still clings to it but Mesa is basically better at everything. [18:32:06 CEST] <atomnuker> see, a few years ago it was 1/3, now its 2/3, that's progress [18:32:46 CEST] <atomnuker> (also on my laptop nouveau is faster because DRI_PRIME is efficient and primusrun is a horrid hack) [18:33:52 CEST] <atomnuker> are you going to port the filters too when you send your opencl patches? [18:34:15 CEST] <jkqxz> What about Imagination, ARM, Vivante, Qualcomm? Not much progress really. [18:34:42 CEST] <jkqxz> No. Does anyone use those? (unsharp and deshake) [18:35:02 CEST] <jkqxz> They're pretty embedded in the current external API and untangling looks hard. [18:35:21 CEST] <atomnuker> but you're still going to provide some filters, right? [18:36:31 CEST] <jkqxz> In the first implementation, only a program filter. I had an overlay filter in libav, but it's kindof stalled on colour conversion issues (should just rewrite it requiring the user to deal with it). [18:36:33 CEST] <jamrial> jkqxz: the current opencl stuff is pretty much unmaintained and used by two low usage filters, so yeah, IMO it can go if it will be replaced by a better implementation [18:37:02 CEST] <atomnuker> jkqxz: a program filter? [18:37:12 CEST] <jkqxz> "run this pixel shader" filter. [18:37:55 CEST] <jamrial> it was written by some amd guy some time ago, who stopped submitting patches after a while [18:37:58 CEST] <BtbN> jkqxz, I tried adding opencl to some other filters. The maintainer actually reacted. [18:38:01 CEST] <jamrial> he was not happy his request to make opencl automatically detected was denied, i recall [18:38:16 CEST] <BtbN> And had such high compatiblity requirements for the OpenCL code that I'd have had to gimp it so much that it'd be slower than CPU [18:40:37 CEST] <jkqxz> Which filters did you try to add it to? [18:40:40 CEST] <atomnuker> jkqxz: that doesn't count, lets make it a gentleman's agreement to not submit hwcontexts until there's something using them without runtime requirements [18:41:37 CEST] <atomnuker> (I'm very concerned if opencl doesn't get any filters right away no one will try to write some unless there's an actual example) [18:41:39 CEST] <jkqxz> I've been sitting on the code for more than a year. [18:42:18 CEST] <atomnuker> my vulkan code is more than a year old too [18:42:36 CEST] <jkqxz> What's wrong with the "run this pixel shader" filter? At least OpenCL is required to have a compiler at run-time :P [18:43:14 CEST] <atomnuker> you won't release any pixel shaders to go along with it, and if you do, there's no excuse to not making it an actual usable filter [18:43:47 CEST] <jkqxz> It is an actual usable filter. [18:44:08 CEST] <atomnuker> not by itself it isn't [18:46:05 CEST] <jkqxz> What filters are you actually intending to write? [18:48:46 CEST] <atomnuker> chromatic aberration (also not intending, I have the shaders, tested them with my mpv vulkan vo) [18:49:34 CEST] <atomnuker> I just need the 400 or so lines of boilerplate to spawn a pipeline and run them [18:50:58 CEST] <atomnuker> though the possibilities are endless considering I found shadertoy [18:54:58 CEST] <atomnuker> so I need to figure out how to not duplicate those 400 or so lines on every filter [18:56:43 CEST] <c3r1c3-Win> write a function to setup said 400 lines and pass in the needed values (like filter name and handle and etc)? (well actually a series of functions, not a single one). [18:57:52 CEST] <atomnuker> its more complicated than that, the vertex buffer and the fragment shader data are difficult to setup and are well integrated with pipeline creation [18:59:35 CEST] <atomnuker> I'll probably just make some structs to serve as descriptors to make the actual descriptors [18:59:51 CEST] <atomnuker> https://www.shadertoy.com/view/Md2GDw <- I should do this one too [19:00:40 CEST] <jamrial> jkqxz: the RockChip stuff, can't it be hwaccels instead decoders? [19:00:54 CEST] <jamrial> i thought we were trying to move out of adding more hw decoders [19:01:20 CEST] <jkqxz> There is no usable hwaccel interface. It's a full stream decoder only. [19:01:27 CEST] <Compn> stop worrying about 400 lines :P [19:03:11 CEST] <jkqxz> jamrial: I have this series <https://lists.libav.org/pipermail/libav-devel/2017-September/084804.html> to make the hwaccel/full decoder situation more sane. It's significantly worse to apply to ffmpeg because there is much more crazy shit, though. [19:03:34 CEST] <jamrial> cleaning crazy shit is what i'd love to do [19:03:46 CEST] <BtbN> jkqxz, color/chromakey [19:03:46 CEST] <jamrial> the incoming major bump gets rid of some things, like the old vdpau stuff [19:04:01 CEST] <jamrial> and xvmc [19:04:25 CEST] <iive> do you remove xvmc completely? [19:04:44 CEST] <jamrial> iive: apparently no, it's one of the things i asked about in the patch i sent in question [19:04:46 CEST] <iive> because the ifdef-ery with FF_API_XVMC removes only the old implementation [19:04:47 CEST] <jkqxz> Bringing it across at the major bump would make sense. It technically has some externally visible effects in deleting all the fake hwaccels (which shouldn't be externally visible at all), but on a major bump that would be ok. [19:05:01 CEST] <iive> jamrial: where is the patch? [19:05:18 CEST] <iive> what thread [19:05:19 CEST] <jamrial> the ml [19:05:23 CEST] <jamrial> it's called "Bump major versions of all libraries" [19:05:58 CEST] <jamrial> the deprecation removes the decoders and most pixfmts except one, and leaves the hwaccels in place [19:06:10 CEST] <jamrial> this is unlike libav, where there were no hwaccels and everything was removed [19:06:52 CEST] <iive> well, I did unpdate xvmc to use hwaccels, and mplayer has been using the new api for years [19:07:19 CEST] <jamrial> it's the one thing i couldn't test, which is why i asked for help/confirmation nothing broke [19:07:36 CEST] <JEEB> did anyone actually verify xvmc to have been working the last few years? [19:07:41 CEST] <iive> ok, will test [19:07:43 CEST] <jamrial> but the patch has been mostly ignored so far [19:07:57 CEST] <JEEB> since IIRC it only worked with a certain subset of cards circa... 2006 or so? [19:08:14 CEST] <iive> JEEB: nvidia and radeon and probably intel [19:09:30 CEST] <JEEB> umm [19:09:50 CEST] <JEEB> oh, ok. some via s3 thing had xvmc? [19:10:39 CEST] <JEEB> except openChrome no longer has a web site? [19:11:10 CEST] <JEEB> ok, this has a nice list https://wiki.archlinux.org/index.php/XvMC [19:11:16 CEST] <iive> no s3 had something else, that did more stuff, like vlc decoding, drequant [19:11:28 CEST] <cone-076> ffmpeg 03Michael Niedermayer 07master:981f04b2ae2d: avcodec/scpr: optimize shift loop. [19:11:28 CEST] <cone-076> ffmpeg 03Jesse Liu 07master:8e17cd20b9cd: add missing ignore files [19:14:28 CEST] <JEEB> iive: the openchrome driver implemented xvmc interfaces anyways, which is why I noted it :P [20:27:51 CEST] <jkqxz> Why does calling ff_framesync2_dualinput_get() try to make copies of the input frames? As compared to ff_framesync2_dualinput_get_writable(), shouldn't the whole point be that it doesn't? [20:28:54 CEST] <jkqxz> Or is there an ff_framesync2_dualinput_get_and_really_dont_copy_i_mean_it_this_time() somewhere? [20:32:13 CEST] <nevcairiel> who knows why lavfi does anything [20:32:43 CEST] <jkqxz> People are meant to have been poking this thing recently. [20:34:25 CEST] <nevcairiel> maybe someone didnt understand how frame refcounting works [20:35:16 CEST] <jkqxz> It seems that it always makes a copy of the primary input. The _writable version is talking about the secondary input only. [20:35:19 CEST] <jkqxz> Wtf. [20:40:10 CEST] <durandal_1707> you never asked me so i will not answer [20:46:15 CEST] <jkqxz> Should I ask you? [21:02:13 CEST] <jamrial> durandal_1707: answer him, please. he asked in general [21:03:02 CEST] <jamrial> jkqxz: beware, though, that Nicolas is the one writing this lavfi stuff, and he doesn't take criticism well [21:09:03 CEST] <durandal_1707> jkqxz: you came to that via looking code or by practice? [21:09:06 CEST] <jkqxz> I'm aware, which is why I don't really want to touch it at all if possible. [21:09:31 CEST] <jkqxz> durandal_1707: Both. I wrote some code and it tried to clone hardware frames (which doesn't work), and then I looked at it. [21:10:28 CEST] <durandal_1707> its not designed for hw frames, and copy may not always be needed [21:10:46 CEST] <jkqxz> How can I contrive circumstances to ensure that copy is never needed? [21:11:58 CEST] <durandal_1707> you cant, copy is needed by design, how framesync works it needs copy of frame [21:12:35 CEST] <jkqxz> I don't write on the primary input frame at all. [21:12:42 CEST] <durandal_1707> but feel free to ask Nicolas, via ml so he is forced to reply [21:13:48 CEST] <jkqxz> Would adding a ff_framesync2_dualinput_get_readonly(), which calls ff_framesync2_get_frame() with get == 0 for both inputs be considered sensible? [21:14:21 CEST] <jkqxz> (Or is there some internal reason I haven't understood why that doesn't work.) [21:17:02 CEST] <durandal_1707> jkqxz: you dont need to add dualinput helper for that, call raw framesync2 [21:18:36 CEST] <jkqxz> Example? [21:19:14 CEST] <jkqxz> vf_premultiply? [21:20:28 CEST] <durandal_1707> hstack,vstack,remap etc [21:23:03 CEST] <kierank> durandal_1707: can you come to vdd and give lecture on libavfilter [21:24:42 CEST] <durandal_1707> kierank: no, i will be with people who actually use it only [21:24:50 CEST] <kierank> so yourself [21:25:47 CEST] <jkqxz> And apparently some gluttons for punishment. [21:26:07 CEST] <jkqxz> durandal_1707: Thank you, that makes more sense. [21:26:10 CEST] Action: kierank uses it but statically links a known-good ffmpeg version [21:26:26 CEST] <durandal_1707> nay, see qctools folks [21:31:23 CEST] <jkqxz> durandal_1707: Right, that works much better. Thank you! [21:31:46 CEST] <jkqxz> (Apparently it pays to have some idea how stuff works.) [21:31:50 CEST] <durandal_1707> with hw frames? [21:31:57 CEST] <jkqxz> Yes. [21:33:02 CEST] <durandal_1707> why would you need hw frames for framesync at all? hw filters are for single big stuff [21:33:27 CEST] <jkqxz> OpenCL overlay filter (e.g. subtitles on video). [21:33:56 CEST] <durandal_1707> noòooo opencl is absurd [21:34:50 CEST] <jkqxz> How so? Pixel shaders do exactly what you want here, and the win is doing transcode on the GPU only. [21:35:07 CEST] <durandal_1707> what speed gain do you get? [21:35:34 CEST] <durandal_1707> i still may write simd for gbrp/yuv444 case [21:37:21 CEST] <atomnuker> durandal_1707: its for when the data's already on the GPU, so you don't have to download -> overlay -> upload but just do an upload and overlay on the GPU [21:37:40 CEST] <atomnuker> uploading and downloading can be extremely slow, especially on 4k video and up [21:38:07 CEST] <jkqxz> Yeah. It's definitely for GPU-only cases. [21:38:17 CEST] <BtbN> I wish it was possible to map CUDA to OpenCL [21:38:40 CEST] <durandal_1707> so you are all on 4k, i switched from sd to hd [21:38:54 CEST] <atomnuker> BtbN: haha, you can do that with vulkan (and it'll be faster than opencl, I guarantee it) [21:39:06 CEST] <atomnuker> (if only because nvidia gimp opencl performance) [21:39:11 CEST] <jkqxz> For my silly PNG overlay test, it's like 3x speedup for 1/6x CPU, but that's including hardware decode on the GPU. [21:39:22 CEST] <BtbN> Not really, no. There is no working interop for that yet either [21:39:43 CEST] <atomnuker> BtbN: but what about the VK_NV_external_memory thing? [21:39:50 CEST] <BtbN> It's a draft [21:40:23 CEST] <atomnuker> what are they doing there, they write extension after extension [21:40:36 CEST] <jkqxz> Hmph. I'm going to have send this shit to the ML now, because atomnuker challenged me into actually writing a filter. [21:40:57 CEST] <jkqxz> It still needs stupid conversions in real transcode because there is no nv12a format. [21:41:35 CEST] <atomnuker> jkqxz: where do you need to convert and what? the overlay (e.g. subtitles) or the video? [21:42:03 CEST] <jkqxz> Both. I want to overlay rgba on nv12, so I do yuva420p on yuv420p. [21:42:35 CEST] <jkqxz> rgba on rgb0 could work too, I guess, but that's probably memory bandwidth because of the lack of subsampling. [21:43:18 CEST] <BtbN> I also kinda want to write CUDA variants of the color/chromakey and despill filters. They are way too slow on CPU [21:43:34 CEST] <BtbN> And GPUs are just made for that kinda task [21:43:35 CEST] <jkqxz> (I generally test on Intel / VAAPI / Beignet), VAAPI is able to convert these things pretty much instantly so it doens't really matter. [21:44:38 CEST] <atomnuker> jkqxz: couldn't you write your kernel to support yuva420p on nv12 overlaying? [21:44:53 CEST] <jkqxz> If I made it less general. [21:45:27 CEST] <jkqxz> <http://sprunge.us/BJJg> [21:46:30 CEST] <jkqxz> (This is of course a case where pixel shaders are /exactly/ what you want, so OpenCL is pretty good.) [21:47:36 CEST] <BtbN> The primary problem with using Vulkan as general-purpose compute/pixel shader platform is the lack of standard shaders [21:47:37 CEST] <atomnuker> how fast are conversions like that (nv12 to yuv420p) in opencl? [21:48:04 CEST] <atomnuker> BtbN: there's a standard, its what glslang accepts as input [21:48:20 CEST] <atomnuker> (also SPIRV but writing SPIRV asm doesn't seem fun unlike x86) [21:48:57 CEST] <BtbN> glslang is just a SPIR-V generator by chance, is it? [21:48:59 CEST] <jkqxz> No idea, I'm doing conversions in other layers. (VAAPI, primarily.) [21:49:02 CEST] <BtbN> And I heard it's pretty terrible [21:49:18 CEST] <jkqxz> Since mapping VAAPI -> OpenCL is completely free. [21:51:59 CEST] <atomnuker> BtbN: nope, its not a spirv generator, its a validator which can convert [21:52:22 CEST] <BtbN> Yeah, you'd either need to commit the SPIR-V to ffmpeg, or bundle a version of glslang into ffmpeg, as they change it all the time [21:52:29 CEST] <atomnuker> its also tolerable crap if you don't use the API [21:52:33 CEST] <atomnuker> nope [21:52:35 CEST] <jkqxz> Hmm. I wonder whether we could have common spirv for multiple APIs in ffmpeg. [21:52:42 CEST] <atomnuker> BtbN: I'll just depend on it [21:52:54 CEST] <BtbN> Will be fun when the interface suddenly changes [21:53:04 CEST] <BtbN> they don't seem to care about api/abi compatiblity [21:53:35 CEST] <atomnuker> BtbN: the cli? its a reference and plenty of other programs depend on it, so I doubt they'll change it [21:53:57 CEST] <BtbN> they all bundle/sub-module it for the reason that it's a moving target [21:54:22 CEST] <thardin> that capture decoder has an impressive amount of sigsegv and infinite loop potential [21:56:06 CEST] <jkqxz> Oh, durandal_1707 wrote the wcap thing. Is it actually usable? Are the files it makes sanely sized for reasonable use-cases? [21:58:11 CEST] <durandal_1707> its rle so its not that much useable for storage, scpr is much better in that case if you wish to write encoder for it [21:59:01 CEST] <thardin> looks like a pretty awful format. just simple deflate would likely be better [21:59:18 CEST] <durandal_1707> but if you have high motion its files will be huge [22:00:58 CEST] <durandal_1707> deflate is slow iirc [22:01:24 CEST] <jkqxz> The specification made it look like it will immediately saturate your disk bandwidth on non-flat content. [22:01:34 CEST] <thardin> there are fast setting. even in RLE mode it would likely be faster [22:01:51 CEST] <thardin> or at least not bloat the data as much [22:22:55 CEST] <atomnuker> what is wcap? [22:26:32 CEST] <durandal_1707> atomnuker: weston capture, screen recorder [22:30:52 CEST] <Compn> durandal_1707 : whats the best screen capture codec ? [22:30:56 CEST] <Compn> :) [22:31:12 CEST] <Compn> where is ff screen capture codec? "ffsc" ? durandal_1707!!! you could make this [22:31:19 CEST] <durandal_1707> Compn: HEVC [22:31:25 CEST] <Compn> just like ffv1... [22:33:20 CEST] <durandal_1707> Compn: ffv2 or ffvx with ffv1 compresion ratio and utvideo decode speed [22:56:05 CEST] <jkqxz> Does anyone want to coment on kmsgrab? Has anyone tested it at all? [23:00:27 CEST] <atomnuker> I'll test it [23:00:53 CEST] <atomnuker> (code wise I've looked at it and looks good) [23:01:25 CEST] <jkqxz> I've tried in on Intel (works cleanly with VAAPI) and AMD (works, but hard to use the result). [23:02:00 CEST] <jkqxz> Be nice to know if it works at all Nvidia, I could believe it just barfs totally. [23:04:53 CEST] <atomnuker> knowing how fragile their vulkan driver is (it causes kernel oopses if you do something obviously wrong) I don't have high hopes [23:05:46 CEST] <nevcairiel> if its so obviously wrong, don't do it? :) [23:06:52 CEST] <jkqxz> "Doctor, doctor, it hurts if I do this." [23:07:58 CEST] <atomnuker> nevcairiel: the thing is nothing is obvious in vulkan and the validator passed with flying colors [23:09:25 CEST] <atomnuker> jkqxz: where are the patches to remove the old opencl crap? [23:09:41 CEST] <BtbN> I'm pretty sure the maintainers will complain about removing it. [23:09:51 CEST] <BtbN> They do still respond to mails [23:10:41 CEST] <jkqxz> Not written yet, because we can't apply them until the version bump. [23:10:53 CEST] <jkqxz> (lavfi depends on the lavu symbols.) [23:12:56 CEST] <atomnuker> jkqxz: "No handle set on framebuffer: maybe you need some additional capabilities?" [23:13:33 CEST] <BtbN> VK_NV_external_memory seems to be win32 only... [23:13:54 CEST] <atomnuker> jkqxz: if I run it as root - "Failed to create surface from DRM object: 18 (invalid parameter)." [23:14:33 CEST] <jkqxz> Platform? [23:15:36 CEST] <atomnuker> linux [23:15:49 CEST] <jkqxz> And yeah, you need to run it as root if something else (X or Wayland, say) is DRM master. [23:16:25 CEST] <jkqxz> (Well, CAP_SYS_ADMIN.) [23:16:26 CEST] <BtbN> https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/maste… looks very Windows specific. [23:16:43 CEST] <BtbN> Would probably need a CUDEVPTR addition from nvidia to be useful [23:17:47 CEST] <jkqxz> OPAQUE_FD sounds like exactly what all real people would want. [23:17:48 CEST] <atomnuker> jkqxz: why is there a hwmap filter? [23:18:01 CEST] <BtbN> jkqxz, if you have system memory, or an fd, maybe [23:18:03 CEST] <jkqxz> Can you turn CUDA images into DRM objects? [23:18:06 CEST] <BtbN> no [23:18:17 CEST] <atomnuker> oh to map kms to vaapi frames [23:19:08 CEST] <jkqxz> hwmap is the best filter evar! [23:20:49 CEST] <atomnuker> doing -vf hwdownload,format=bgr0 yields junk, though the image is there [23:21:07 CEST] <BtbN> jkqxz, the OPAQUE_FD expects a file descriptor returned by getMemoryFdKHR [23:21:15 CEST] <atomnuker> (maybe its some special gpu tiled format) [23:21:17 CEST] <BtbN> and getMemoryFdKHR uses the same enum I linked for the memory it is able to turn into an fd [23:21:28 CEST] <BtbN> so no dice there either [23:21:39 CEST] <BtbN> Will have to wait for nvidia to add CUDA interop there [23:21:43 CEST] <BtbN> which should be trivial for them [23:21:50 CEST] <iive> most cpu do use 8x8 tiles (blocks) [23:21:54 CEST] <iive> gpu [23:22:37 CEST] <jkqxz> Yeah, you getting tiled formats is annoying. We don't have any untiler. [23:23:12 CEST] <jkqxz> For Intel at least you can map through an untiler in the MMU, but that requires quite a bit more specific magic. [23:23:32 CEST] <jkqxz> (Hence mapping to VAAPI being the easiest use-case.) [23:23:39 CEST] <BtbN> at least nvidia doesn't in their API [23:23:45 CEST] <BtbN> if they do it internally, it's nicely hidden [23:24:06 CEST] <atomnuker> jkqxz: yeah, seems like mapping drm->vaapi fails here [23:24:23 CEST] <atomnuker> (removing the kms part and feeding in some video with hwupload works) [23:25:26 CEST] <jkqxz> Intel? [23:25:30 CEST] <jkqxz> AMD? [23:26:30 CEST] <atomnuker> intel [23:26:36 CEST] <atomnuker> I'll try on another machine and on x11 [23:29:28 CEST] <jkqxz> X11 vs. anything else shouldn't make any difference. [23:30:05 CEST] <jamrial> jkqxz: no way to implement the opencl version of overlay into the existing filter, much like deshake does with the old lavu opencl api? [23:30:51 CEST] <jkqxz> It's not useful to do. You need AV_PIX_FMT_OPENCL input and output. [23:31:59 CEST] <jkqxz> (Auto-upload/download is an abomination. It's not a cheap operation at all, it should never be transparent.) [23:32:28 CEST] <jkqxz> (Since the whole point of this stuff is to make things faster, not to do things you couldn't do some other way.) [23:34:59 CEST] <jkqxz> atomnuker: On things to test with, do you have any of the ARM platforms with Vulkan implementations? Do they work sensibly at all? [23:38:24 CEST] <BtbN> I know the Nvidia ones do, but that's about to be expected [23:39:00 CEST] <atomnuker> jkqxz: no, but I don't think I've heard bad things from people who have worked with them [23:43:41 CEST] <atomnuker> jkqxz: works perfectly on another machine, cpu activity is around 27% for hevc encoding [23:43:45 CEST] <atomnuker> even on wayland [23:48:53 CEST] <philipl> BtbN: vk_khr_external_memory(_fd) are supported on linux. [23:48:59 CEST] <philipl> The early vk_nv version might be win32 only [23:49:07 CEST] <philipl> but there's not documentation on how to do cuda interop [23:49:38 CEST] <philipl> maybe you just pass a cudaPtr to it and it works, but I've never been in a position to try [23:52:15 CEST] <jkqxz> atomnuker: Nice! And you get everything except the mouse? (It is possible that things use KMS overlay planes, and unfortunately this method would require capturing them separately and then blending them afterwards to match what the GPU would do on its own output, which doesn't sound very fun.) [23:53:12 CEST] <jkqxz> Well, the mouse is also an overlay plane and could be captured, but there doesn't seem much point. [23:53:31 CEST] <nevcairiel> some people might want it if they make demo videos of things [23:53:48 CEST] <nevcairiel> show where to click and whatnot [23:54:33 CEST] <atomnuker> yeah, I get everything except the mouse, though it seems the hardware encoder can't handle 60fps at 2560x1440 so I have to downscale it [23:55:02 CEST] <atomnuker> (or maybe its the scaler, I'm also playing a 60fps video so the gpu has some load) [23:55:05 CEST] <jkqxz> hevc_vaapi? They set the default speed down in recent versions, set -compression_level 7. [23:55:13 CEST] <atomnuker> (or maybe its the scaler, I'm also playing a 60fps video so the gpu has some load) [23:55:51 CEST] <atomnuker> yep, compression level=7 makes it almost realtime [23:57:02 CEST] <jkqxz> IMO that was a stupid change (people use hardware encoders for speed / low CPU use, not for quality), but oh well. [23:57:48 CEST] <atomnuker> damn, even switching VTs works without corruption or dropped frames [00:00:00 CEST] --- Mon Sep 11 2017

1 0

ffmpeg.log.20170910
by burek 11 Sep '17

11 Sep '17

[02:06:40 CEST] <Sebas_> hi :) [02:07:54 CEST] <Sebas_> I am splitting a mp4 using the segmenter.. but each segment now has non-zero starttime, and it will not load in the MediaSource using javascript. [02:08:41 CEST] <Sebas_> How can I strip them of the segment times and make each it's own little 'movie' ? :) [02:09:08 CEST] <Sebas_> This is my converter command (Node.js) args.push(['-i', vid.file, '-movflags', '+faststart', '-vcodec', 'libx264', '-acodec', 'aac', '-preset', 'veryfast', '-vf', 'scale='+x+'x'+y, '-map', '0', '-profile:v', 'baseline', '-level', '3.0', '-segment_list_type', 'csv', '-segment_time', '15', '-f', 'segment', 'tmp/'+y+'_%03d.mp4']); [02:10:11 CEST] <dystopia_> what is your scale command doing? [02:12:13 CEST] <dystopia_> im unsure about your segment times, maybe split source video, then encode split source files ? [02:12:25 CEST] <Sebas_> 1280x720 and some more resolutions [02:12:59 CEST] <dystopia_> oh so the +x and +y are some form of variable? [02:13:01 CEST] <Sebas_> gives me this on the duration line: Duration: 00:00:13.97, start: 17.914000, bitrate: 2143 kb/s [02:13:07 CEST] <dystopia_> i guess i should learn javascript heh [02:13:09 CEST] <Sebas_> yes :) [02:14:03 CEST] <Sebas_> I guess the start 17.914 is the issue.. because I am adding it to a html5 video element.. the browser gets confused I think and won't play.. clean mp4 files I can append to another in the browser, giving seamless transition [02:14:10 CEST] <dystopia_> does each segment after the first have a valid header? [02:14:24 CEST] <Sebas_> I am splitting the files so I can control loading of the segments using javascript [02:15:12 CEST] <Sebas_> Yes, they will play in VLC and HTML5 video element, but now when appending them via MediaSource (same browser api that youtube uses) [02:15:50 CEST] <Sebas_> now=not* [02:16:00 CEST] <dystopia_> i am unsure :( [02:16:17 CEST] <dystopia_> hopefully someone else knows if you hang around [02:16:54 CEST] <Sebas_> Is there a way to copy the h264 data without the timestamps? I could write a simple loop that converts all files afterwards [02:17:31 CEST] <dystopia_> you could try to copy each segment to a new file [02:18:09 CEST] <dystopia_> ffmpeg -i seg_in.mp4 -vcodec copy -acodec copy seg_out.mp4 [02:19:05 CEST] <Sebas_> test file with a start stamp... try ffmpeg -i <file> https://ufile.io/1pvpo [02:21:18 CEST] <Sebas_> I think I got it.. ffmpeg -i in.mp4 -c copy out.mp4 ... let me check [02:21:59 CEST] <Sebas_> I think it works :) [02:28:31 CEST] <Sebas_> All start times are reset.. but still not working [02:29:38 CEST] <Sebas_> I am encoding the same.. https://pastebin.com/m9vWH2jJ :) really thx anyway I will keep trying [02:30:43 CEST] <klaxa> >At least one output file must be specified [02:30:54 CEST] <klaxa> your command seems wrong [02:31:07 CEST] <klaxa> unless you didn't want to encode? [02:31:51 CEST] <Sebas_> did not want to encode indeed.. giving no output file shows stats :) including 'start' time when segments are created [02:32:17 CEST] <klaxa> hmm... are you trying to do some live-streaming stuff? [02:33:01 CEST] <Sebas_> Already got that working once xD but no, I am writing a browser video player, with segmented files I can better control buffering [02:33:30 CEST] <klaxa> i see, well i'm not good with web-stuff [05:43:50 CEST] <jeffw_> I am having trouble performing "./configure" on msys2. I receive: "gcc is unable to create an executable file. C compiler test failed." [05:45:52 CEST] <jeffw_> I have performed: "pacman -S mingw-w64-x86_64-nasm mingw-w64-x86_64-gcc mingw-w64-x86_64-SDL2 mingw-w64-x86_64-yasm" Although I had to use "--force". [05:46:51 CEST] <jeffw_> I am on 64bit Windows 8.1, using Msys2 and mingw64 [05:47:35 CEST] <jeffw_> The program advises: "If gcc is a cross-compiler, use the --enable-cross-compile option. Only do this if you know what cross compiling means." [05:49:49 CEST] <jeffw_> Upon running: "./configure --enable-cross-compile --arch=x64 --target-os=mingw-w64" The same error occurs. Also attempting with "--arch=x86 --target-os=mingw32" fails, (as stated here: https://trac.ffmpeg.org/wiki/CompilationGuide/CrossCompilingForWindows ) [06:22:35 CEST] <titbang> try x86_64 [06:26:35 CEST] <jeffw_> Trying it now. [06:27:20 CEST] <jeffw_> What should "--target-os" be set to? [06:33:04 CEST] <jeffw_> Same error occurs using --target-os=mingw32, --target-os=mingw64, --target-os=mingw-w64 [06:33:22 CEST] <jeffw_> And using --arch=x86_64. [07:18:14 CEST] <JeffW_> Has anyone successfully compiled ffmpeg using a Windows machine? [13:38:15 CEST] <Sebas_> hi :) I am segmenting a video into ~15 second pieces, this gives me files with lengths and starttimes (PTS data) but when I convert each part with ffmpeg -i 240_001.mp4 -movflags frag_keyframe+empty_moov+default_base_moof -acodec copy -vcodec copy -copyts n240_001.mp4 [13:38:37 CEST] <Sebas_> the PTS data is erased, how can I keep the exact same duration AND starttime? [14:57:47 CEST] <Sebas_> anyone know howto preserve starttime in a fragmented mp4? ffmpeg -i 240_001.mp4 -movflags frag_keyframe -acodec copy -vcodec copy n240_001.mp4 [14:59:52 CEST] <Sebas_> or is there a way to -movflag frag_keyframe when segmenting the original file? [15:33:24 CEST] <c_14> -copyts [15:36:15 CEST] <c_14> or when segmenting -segment_format_options movflags=+frag_keyframe [15:42:18 CEST] <Martchus_> I'm trying to get rid of the first 9.125 seconds in the audio stream of the 2nd input file. However, the options -ss and -itsoffset don't have any effect. [15:42:30 CEST] <Martchus_> So this is likely not correct: ffmpeg -i $avi -ss -9.125 -i $mkv -map 0:0 -map 1:1 -map 0:1 -c:v libx265 -preset medium -crf 24 -c:s:a:0 libfdk_aac -filter:a:0 atempo="1.04270937604270937604270937604" -c:s:a:1 libfdk_aac -metadata:s:a:0 language=eng -metadata:s:a:1 language=ger $output [15:43:16 CEST] <Martchus_> Using -itsoffset doesn't have any effect either. [15:44:07 CEST] <Sebas_> thx c14, i'll try it [15:47:30 CEST] <furq> Martchus_: probably use -af atrim,adelay [15:47:36 CEST] <c_14> Martchus_: your -ss value is negative [15:47:45 CEST] <furq> oh yeah that probably doesn't help [15:48:07 CEST] <furq> also you probably want atempo=25/(24000/1001) [15:54:06 CEST] <Martchus_> furq: c_14: Thanks for your. I've already noticed that -ss requires a positive value and it works. [15:55:51 CEST] <Martchus_> furq: I have already added atempo for that stream, but good to know it also supports the form 25/... . [16:08:06 CEST] <Sebas_> thx c_14, that gave me propper split mp4's with start_time (PTS) intact! Not yet conintued playing(only first file plays) in the broswer MediaSource element yet, but working on it. [18:39:06 CEST] <Sebas_> Just split up my mp4 file using -f dash, getting audio and video stream, got the video working in the browser using javascript + MediaSource, but the audio doesn't seem to work. any tips? [18:39:48 CEST] <Sebas_> I tried 2 different MediaSource's and 2 different buffers within the same MediaSource. No results for audio(video works). [18:40:06 CEST] <BtbN> aac should just work [18:40:14 CEST] <BtbN> And why don't you just use dash.js? [18:48:37 CEST] <Sebas_> because I am using websockets as a source :) [18:51:55 CEST] <Sebas_> works with dash.js, made a quit test page [18:52:12 CEST] <Sebas_> I'll keep debugging my own player :) [18:56:21 CEST] <BtbN> using Websockets as source sounds needlessly complicated [18:58:16 CEST] <Sebas_> also alot of fun :) [00:00:00 CEST] --- Mon Sep 11 2017

1 0