Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2019

1 participants
62 discussions

ffmpeg-devel.log.20190325
by burek 26 Mar '19

26 Mar '19

[01:10:08 CET] <BtbN> philipl, can you reply to the crop_cuda thread with what we discussed about integrating it into scale_cuda? Don't want to leave the guy hanging. [01:10:18 CET] <BtbN> Don't have time to do so myself right now. [01:18:41 CET] <cone-081> ffmpeg 03Jun Li 07master:c3b517dac2bb: avformat/rtsp: Add https tunneling support [02:22:10 CET] <damdai> from which ffmpeg version, did ffmpeg started supporting Stream #0:0: Audio: dst (DST / 0x20545344), 352800 Hz, 5.1(side), flt [05:58:10 CET] <philipl> BtbN: done [11:17:15 CET] <BtbN> thanks! [11:23:03 CET] <jya> I'm having a particular weird h264 stream here where the first frame is a single IDR NAL, no SPS/PPS. Is there an actual way to decode that? [11:23:56 CET] <nevcairiel> are there any sps/pps later on? [11:24:12 CET] <nevcairiel> because if not, then you are mostly screwed [11:25:09 CET] <nevcairiel> if there are sps/pps later on, then the extract_extradata bsf might be able to find them and pull them out, so you can feed it to the decoder [11:25:12 CET] <jya> can't see any. Weird thing is that OpenH264 can somehow decode it. Need to dwelve into that one, maybe openh264 cause an error, and so the server resend it [11:26:00 CET] <BtbN> The extradata could just be sent out of band in the container? [11:26:46 CET] <jya> it's a RTP stream [11:27:30 CET] <jya> though if the SPS/PPS isn't sent with the IDR but later, then we wouldn't detect it (we only look for SPS/PPS if the packet also has an IDR) [11:35:20 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/rtpdec_h264.c;h=… looks like RTP does transport extradata out of band [11:35:53 CET] <jya> yes, it could be pass in the sdp, but I don't see anything here [11:37:32 CET] <jya> our code doesn't support it anyway (this is a webrtc stream) [15:01:21 CET] <thardin> kierank: good post re: hardware APIs [15:02:17 CET] <thardin> I wish more manufacturers realized they're hardware companies [15:02:33 CET] <kierank> I mean we literally went and built our own hardware in part for this reason [15:03:42 CET] <atomnuker1> how did blackmagic take it or they couldn't care less? [15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:1223696c725a: avcodec/truemotion2: Fix integer overflow in tm2_null_res_block() [15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:d92034a06aad: avcodec/dxtory: Check slice sizes before allocating image [15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:ff13a92a6f84: avformat/mov: Fix potential integer overflow in entry check in mov_read_trun() [15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:4ef27d40729c: avcodec/indeo2: Check input size against resolution in ir2_decode_plane() [15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:635067b75fce: avcodec/mpegpicture: Check size of edge_emu_buffer [15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:c0ca67ba4083: avcodec/prosumer: Check decoded size [15:04:06 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:b8f53a23421b: avcodec/jpeg2000dec: Skip de-quantization of empty areas [15:23:29 CET] <kierank> atomnuker1: don't care [15:26:54 CET] <cone-124> ffmpeg 03James Almer 07master:40490b3a6336: avcodec/cbs_av1: fix range of values for Mastering Display Color Volume Metadata OBUs [15:49:39 CET] <BBB> that matrox email is soooooooo self-serving [15:50:02 CET] <BBB> "we're a hardware company, please give us special treatment, it'll be good for all of us [and we'll make tons of money shhhhhhh]" [15:51:25 CET] <JEEB> xD [15:52:30 CET] <thardin> yeah that was kind of funny [15:57:22 CET] <kierank> BBB: they are just so obsessed with secrecy [15:57:27 CET] <kierank> as if we can't just buy the ASIC they have bought [15:58:38 CET] <kierank> it's not as if ffmpeg doesn't implement low level functions for anything anyway, it's not gstreamer [16:31:03 CET] <Gramner> I don't really understand why hardware vendors don't just release the relevant libraries under liberal open source licenses, all the "secret sauce" is in the hardware itself anyway [16:32:08 CET] <kierank> Gramner: i've spoken to them at length about this, they think their "value" is in the sdk [16:32:13 CET] <kierank> they are obsessed about sdk [16:32:15 CET] <kierank> s [16:32:33 CET] <kierank> But at the end of the day it boils down to the same thing every time: [16:32:37 CET] <kierank> They Don't Understand Open Source [16:33:01 CET] <Gramner> which is weird because nobody cares about the sdk, it's just a means to access the hardware [16:34:14 CET] <nevcairiel> as a hardware company i dont really understand that obsession, shouldnt they try to make good hardware and sell that [16:34:18 CET] <nevcairiel> but i guess thats too hard? :D [16:36:57 CET] <gnafu> nevcairiel: Whoa, whoa. Slow down there, buddy. "Good"? That's a lot to ask for. [16:37:29 CET] <gnafu> I'm gonna need you to agree to our SDK's ToS before we can even talk. [16:57:23 CET] <jamrial> BBB: when you have time, can you look at the av1 frame split bsf patch? i sent an updated version [16:57:35 CET] <BBB> okiedokie [16:57:38 CET] <BBB> anything specific it does? [16:58:04 CET] <BBB> "native av1 decoder" :D [16:58:13 CET] <jamrial> eventual :p [16:59:43 CET] <jamrial> it splits all the frames in a temporal units into separate packets, making sure to include frame header and all the tile group obus (or just the frame obu) [17:00:25 CET] <jamrial> it includes all leading obus with the first frame (seq header, etc), and all trailing obus with the last frame (whatever could be there, like maybe padding) [17:01:09 CET] <jamrial> if there's only one frame, it just passes it through [17:35:23 CET] <cone-124> ffmpeg 03Gyan Doshi 07master:9ae8f3cdd330: doc/filters: indicate range for zoom in lavfi/zoompan [17:42:04 CET] <lotharkript> qq: Should a video filter update the AVframe duration? if not, then there seems to be problem here https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c#L1085 when using filter complex. it updates the AVframe->duration even if we did apply a fps filter in the filter complex. [17:55:11 CET] <kierank> thardin: Gramner: note how he's gone quiet when I ask him for his chip api [17:55:21 CET] <kierank> yet he wants us to do everything to accommodate him [17:59:32 CET] <Gramner> dropping proprietary 3rd party libs from ffmpeg would be an incentive for hw vendors to open source their stuff then, since they obviously do want to be supported in ffmpeg [17:59:58 CET] <j-b> exactly [18:00:07 CET] <nevcairiel> Trying to interpret any meaning into a 3 hour silence from a business seems like diluding yourself =p [18:00:35 CET] <nevcairiel> deluding* [18:00:42 CET] <j-b> FFmpeg is becoming the core of all multimedia pipelines. We have the power to make things change. [18:00:44 CET] <kierank> nevcairiel: he spams the list with all his requestes very day [18:05:40 CET] <j-b> This libmvM264Ffmpeg is very suspicious [18:09:07 CET] <thardin> Gramner: possibly, yes [18:10:03 CET] <thardin> kierank: indeed [18:13:53 CET] <thardin> he also seems to want support for all those weird mxf things for free [18:15:49 CET] <thardin> ooh a patch for my favorite codec, cinepak [18:16:41 CET] <thardin> gym first [18:17:33 CET] <gnafu> Now there are two things I can't relate to: being excited about a Cinepak patch, and going to the gym. [18:17:36 CET] <gnafu> ;-D [18:36:51 CET] <JEEB> hmm [18:37:03 CET] <JEEB> I wonder how many parsers fail at H.264 Level 6.0 [18:40:05 CET] <Gramner> anything hardware-base probably wouldn't be able to decode 6.0 anyway [18:41:20 CET] <JEEB> my x230 seemed to do it surprisingly well, but AMDs, nvidias and another intel seemed to bork at it [18:41:39 CET] <Gramner> I'm pretty sure my nvidia card didn't complain, but produces garbage output for large mv:s [18:41:52 CET] <JEEB> yup [18:42:00 CET] <JEEB> I was surprised my x230 (ivy bridge?) worked [18:42:33 CET] <JEEB> as in, I didn't see those artifacts I saw both with a newer intel + nvidia [18:43:14 CET] <CounterPillow> open-source is the thing where we can con people into doing our work for free, right? [18:44:11 CET] <j-b> JEEB: what about modify x264 to create z264 codec with larger block sizes? [18:44:26 CET] <JEEB> lol [18:44:31 CET] <j-b> most patents for h264 will be out soon [18:44:39 CET] <JEEB> possibly a fun experiment [18:44:42 CET] <j-b> JEEB: do you think we can beat x265? [18:44:53 CET] <JEEB> not sure, since I feel like they share the optimization problem [18:45:02 CET] <JEEB> unless they have a completely different coding cost calc [18:45:18 CET] <JEEB> because bigger block sizes usually are something that easily ends up looking like "cheap way to encode" [18:45:25 CET] <JEEB> but then you suddenly get all that blur [18:45:49 CET] <Gramner> JEEB: did you try with something containing large mv:s? they rarely happen with most content but levels 6.0 and above increased the maximum allowed mv range and it seemed to cause breakage on nvidia gtx 1080 when I tested it some time ago [18:46:22 CET] <JEEB> yea, that's why I commented. I happened to render some 2160p60 and just let preset slower rip [18:46:34 CET] <j-b> JEEB: I'm quite sure we can take some simple ideas from HEVC/VP9 and "backport them to" x264 [18:46:38 CET] <j-b> and improve :) [18:47:37 CET] <CounterPillow> Notable absence of AV1 in that sentence [18:47:39 CET] <JEEB> Gramner: and yes, I noticed the artifacts as I opened the clip in something that defaulted to hwdec with nvidia :) [18:48:21 CET] <JEEB> j-b: sure, it should be possible [18:48:44 CET] <j-b> H264 is soon out of patents, and that would be nice [18:48:48 CET] <JEEB> aye [18:49:07 CET] <CounterPillow> How soon? I thought it was another 10 years off. [18:49:18 CET] <JEEB> 2013-4 for initial stuff [18:49:24 CET] <JEEB> uhh [18:49:25 CET] <JEEB> 2023 [18:49:38 CET] <JEEB> then high profile etc I think was 2006 so 2026? [18:49:56 CET] <JEEB> or was it earlier? [18:50:32 CET] <gnafu> "< CounterPillow> open-source is the thing where we can con people into doing our work for free, right?" <-- I mean, that's what I've done all these years. [18:50:39 CET] <j-b> the patents were earlier [18:51:33 CET] <gnafu> CounterPillow: Though replace "con people" into "wait for someone else to do it because I can't be bothered". [18:51:52 CET] <JEEB> also talking of blurring, having stuff with a bokeh sure lowers bit rate requirements :P [18:53:59 CET] <Gramner> some H.264 patents expire in 2027 [18:54:08 CET] <Gramner> because extentions are apparently a thing [18:54:47 CET] <Gramner> https://scratchpad.fandom.com/wiki/MPEG_patent_lists#H.264_patents (not sure how accurate it is though) [18:56:24 CET] <Gramner> 2028 even [18:56:43 CET] <CounterPillow> heh, a lot of these expire this year. [18:59:41 CET] <kurosu> I'm looking forward to those expiring on 32nd of May 2023 [19:00:19 CET] <Gramner> it means they will be valid indefinitely of course [19:01:35 CET] <kurosu> obviously, if we follow the Mickey Mouse doctrine [19:09:49 CET] <JEEB> Gramner: the first device that outright nope'd at the streams was my TV :) [19:10:00 CET] <JEEB> I think 5.2 or something might be the biggest it'll take? [19:11:38 CET] <Gramner> probably either 4.1 or 5.2 according to specs, which may or may not include things slightly above that [19:13:28 CET] <JEEB> 4.1 is the thing that you need to tell some devices on the browser level what your stream is [19:13:41 CET] <JEEB> (because so many people forget to update their hwdec level check [19:13:49 CET] <JEEB> (even if they have a 4K compatible hwdec) [19:13:55 CET] <JEEB> *cough* chromecast *cough* [19:14:44 CET] <Gramner> levels 6 is just special in the fact that it also increases mv-range and not just frame size / mb rate, so you can have a stream with a resolution and framerate that fits within lower levels but have mv ranges that do not. that can cause fun issues which very rarely happen [19:15:00 CET] <JEEB> yea [19:15:35 CET] <JEEB> I didn't even think they let you do that when I started encoding [19:16:24 CET] <JEEB> it seems that my 2160p renders are just great for making x264 use those longer MVs :) [19:23:24 CET] <Gramner> iirc the reference decoder is slightly broken for level 6 streams as well, I think it warns about too large mv ranges because the check is wrong [19:23:33 CET] <JEEB> :D [19:23:34 CET] <Gramner> which is funny [19:24:08 CET] <JEEB> yea, but it kind of makes sense: "why would you have to update the reference software after 13 years?" [19:24:20 CET] <JEEB> (except they went and changed things) [19:24:34 CET] <nevcairiel> oh so that level actually allows something fundamental beyond just more bitrate then [19:25:20 CET] <Gramner> yeah. most levels before 6 have just been basically "decode more macroblock in the same time" [19:25:57 CET] <Gramner> not sure how useful giant mvs even are, seems like a dubious addition to the spec [19:26:58 CET] <JEEB> not sure how much I gained from them with the two encodes I did without specifying a level, but they did get utilized :D [19:29:20 CET] <Gramner> yeah, but how much better than some other shorter mv? probably negligible for anything other than some contrieved edge cases [19:29:44 CET] <JEEB> quite possible [19:59:30 CET] <rcombs> macroblock rate, bit rate, frame size, and DPB size [20:00:36 CET] <rcombs> (and I've never figured out how the VCL bit rate limit is supposed to be applied) [20:10:22 CET] <kierank> applied using vb [20:10:23 CET] <kierank> vbv [20:10:34 CET] <kierank> also mincr is important [20:10:43 CET] <orlcp440> Hello, I have RTP sending using the UDP muxer and set it up to send packets at a constant rate. How can I make RTP also use the UDP module to receive packets instead of using its own internal udp_read function? [20:15:06 CET] <orlcp440> The libavformat/rtpproto.c rtp_read() function is getting called instead of the libavformat/udp.c udp_read() function. [20:15:47 CET] <orlcp440> the rtp_read() function is calling recvfrom() udp directly [20:16:23 CET] <JEEB> are you the guy who asked about passing those rate control options before [20:16:29 CET] <JEEB> I think I linked https://github.com/jeeb/ffmpeg/commit/84c3261dd3cff17eb32aea06391bb6646311c… to you? [20:16:40 CET] <JEEB> so you could maybe test it if it worked for you :P [20:16:56 CET] <orlcp440> I guess what I really want to know if it is possible to chain demuxers and if it is how I can accomplish that. I want to chain for output RTP -> UDP muxer and for input UDP muxer to RTP muxer. [20:17:28 CET] <orlcp440> @JEEB: Yup, I am that guy lol [20:18:11 CET] <orlcp440> I thought that only solved 1 direction but noth both [20:18:49 CET] <JEEB> you're talking about sending and the UDP protocol does the rate control, no? you just have to be able to set the parameters [20:19:11 CET] <JEEB> (also the separately threaded writing is I think only under pthreads due to requiring pthread cancel?) [20:19:26 CET] <orlcp440> plus I want to concat or chain (whatever term is used) the UDP dec Muxer to the RTP dec Muxer [20:19:55 CET] <JEEB> I don't really understand what that probably means to you [20:20:08 CET] <orlcp440> @JEEB I got the sending part working but not the receiving part. [20:20:18 CET] <JEEB> well what's the problem with receiving? [20:20:44 CET] <JEEB> that is also buffered and reading in a separate thread if you have threading enabled [20:20:46 CET] <orlcp440> it is not using a separate thread and putting the data in a FIFO for me to grab it [20:20:55 CET] <orlcp440> that is my problem with the receiving [20:20:59 CET] <JEEB> then you have managed to build FFmpeg without threading? [20:21:50 CET] <JEEB> or wait, it might be indeed limited to pthreads on that way as well :P [20:21:54 CET] <orlcp440> @JEEB: No, what I meant was that the RTP dec muxer is actually calling recvfrom() itself instead of letting the UDP dec muxer do it [20:21:56 CET] <JEEB> under HAVE_PTHREAD_CANCEL [20:23:32 CET] <orlcp440> The UDP dec muxer is actually running and receiving using its thread and putting the data in a FIFO but the RTP dec muxer is not calling the UDP dec mux's udp_read but instead calling its own function that does recvfrom() straight [20:23:44 CET] <orlcp440> straight -> directly [20:24:40 CET] <orlcp440> @JEEB: Keep in mind I do not even know the whole architecture and how data should flow on this library. I would love to find some documentation about that [20:26:01 CET] <orlcp440> I would like to know how I can take the output of a dec muxer and use it as an input to another dec muxer and the output of the second dec muxer to be the input of a third dec muxer etc. That is what I meant when I said dec muxer chaining [20:26:27 CET] <orlcp440> like a pipeline [20:27:11 CET] <JEEB> there's a difference between a protocol and a demuxer or muxer [20:27:24 CET] <JEEB> anyways, don't remember the details myself either and I haven't really looked into the RTP stuff [20:27:36 CET] <JEEB> I just expected it to normally chain stuff [20:37:04 CET] <orlcp440> It does chain forward from RTP to UDP but not from UDP to RTP [20:38:04 CET] <orlcp440> @JEEB: Do you know where I can learn all those concepts? [21:00:12 CET] <llogan> who maintains the ffmpeg page on facebook? [21:38:05 CET] <orlcp440> I guess I should ask, what is the process a new developer for ffmpeg project takes to learn the whole architecture so that he can contribute to the ffmpeg project? Not as a user of the libraries but as a core developer for ffmpeg? [21:47:53 CET] <BBB> you just start doing fun things and learn how things work as you go, I think [21:48:00 CET] <BBB> I doubt many people know everything [21:48:05 CET] <BBB> most people know just some subsystems [21:48:08 CET] <faLUCE> I would like to propose some patches to the project, for fixing some issues. How can I start? I downloaded the last git image of ffmpeg. Then, after changing for example file1.c, how should I propose the commit? [21:48:11 CET] <BBB> maybe jamrial and michaelni know everything [21:48:20 CET] <BBB> orlcp440: ^^ [21:48:42 CET] <durandal_1707> i know everything and nobody else [21:48:50 CET] <BBB> faLUCE: https://www.ffmpeg.org/developer.html#Submitting-patches-1 [21:49:01 CET] <BBB> that's true, durandal_1707 might know most stuff also [21:51:02 CET] <faLUCE> BBB: how can I test git-send-email? Could I try to use it by sending the patch to my email? [21:51:15 CET] <BBB> yes [21:52:15 CET] <faLUCE> BBB: and which is the "object" field, so that I can explain what the patch does? [21:54:34 CET] <faLUCE> maybe "--compose" ? [21:55:40 CET] <durandal_1707> JEEB: i got KB2f fully working except deblocking [21:57:34 CET] <orlcp440> @durandal_1707: Cool, then you can probably answered the question I was asking @BBB before. Can you help me? [21:58:06 CET] <durandal_1707> orlcp440: can you compile and run ffmpeg? [21:58:29 CET] <orlcp440> @durandal_1707: Yes, I can do it right now [22:00:06 CET] <durandal_1707> orlcp440: then do what you want to do, if you want to do codecs say which want, read similar code to learn new things [22:00:35 CET] <TD-Linux> Gramner, you really want the mvs to reach across most of the frame. once you do longer reference structures your mvs get bigger [22:00:57 CET] <TD-Linux> it's obviously sequence dependent but it's a pretty drastic hit when you do run out of mv range. [22:01:08 CET] <TD-Linux> we had to bump AV1 mvs longer than VP9 because of this [22:01:35 CET] <durandal_1707> llogan: why you dissapeared? [22:02:10 CET] <BBB> TD-Linux: nope [22:02:16 CET] <BBB> TD-Linux: mvs are the same in av1 as they are in vp9 [22:02:25 CET] <TD-Linux> oh I thought we increased them 1 bit :/ [22:02:29 CET] <BBB> TD-Linux: I requested a change to that, it got merged, and then reverted [22:02:35 CET] <TD-Linux> I missed the revert :9 [22:02:40 CET] <BBB> :( [22:02:43 CET] <BBB> sorry [22:02:46 CET] <orlcp440> @durandal_1707: I am already doing that but I am stuck on a high level architectural questions that depending on the answer of that question I will know if what I want to do is possible using the current state of ffmpeg [22:02:52 CET] <BBB> I wish it had been fixed, it's pretty important at high resolution (4k) [22:03:15 CET] <TD-Linux> at least it's not level dependent. (unless they changed that too) [22:03:41 CET] <durandal_1707> orlcp440: do you have exact question? [22:05:24 CET] <faLUCE> it seems that the "--annotate" field adds an object to the email with the patch... can you confirm that? [22:05:42 CET] <orlcp440> @durandal_1707: Yes, how do I make the RTP module use the UDP.c module for all its receiving needs? Right now I have the RTP module using the UDP.c module for transmitting RTP. I wanted to do that because the UDP.c module supports pthreads with FIFO buffers and bitrate so I have the UDP.c module sending packets out to the network every 1ms [22:09:36 CET] <orlcp440> @durandal_1707: I enabled HAVE_PTHREAD_CANCEL to accomplish that [22:10:08 CET] <durandal_1707> orlcp440: i'm not that much into network and protocol code, sorry [22:11:18 CET] <orlcp440> @durandal_1707: :-( Do you happen to know who is? [22:11:57 CET] <durandal_1707> look at MAINTAINERS file for relevant file you are interested [22:20:07 CET] <llogan> durandal_1707: i'm still around for now but getting bored of it (computer stuff in general), and too much bickering on mailing list. [22:23:51 CET] <jamrial> llogan: i assume you had to approve some of the mails on these discussions? [22:26:36 CET] <llogan> jamrial: I had to approve messages from non-subscribed users, but i recently changed the behavior so users must be subscribed to send a message. [22:32:02 CET] <orlcp440> @durandal_1707: Damn that is pretty solid advice. I did not know of the existence of that file. However, the only bad thing is that they do not include their email or any way of contacting them in that file [22:32:53 CET] <llogan> you can cross reference the git log [22:34:07 CET] <llogan> MAINTAINERS can be outdated. view git log of a file to see who works on it most. [22:42:09 CET] <jamrial> llogan: i know, i meant that no wonder having to approve message in that and similar threads tired you [22:45:18 CET] <faLUCE> are there parts of ffmpeg that are compatible with gpl v2 but not compatible with gpl v3 ? [22:46:31 CET] <nevcairiel> i dont think so [22:47:12 CET] <nevcairiel> our gplv2 license is specifically upgradable [22:47:59 CET] <faLUCE> nevcairiel: but there's a note: "Should you, for whatever reason, prefer to use version 3 of the (L)GPL, then the configure parameter --enable-version3 will activate this licensing option for you. Read the file COPYING.LGPLv3 or, if you have enabled GPL parts, COPYING.GPLv3 to learn the exact legal terms that apply in this case" ... so, does it imply restrictions? [22:49:36 CET] <nevcairiel> the licenses are different, you should understand the differences between them [22:49:48 CET] <nevcairiel> but our code is all allowed under v3 as well [22:50:54 CET] <faLUCE> I see, so, there's compatibility for v3+ but the license will be specifically v3+ if you enable it [22:50:56 CET] <faLUCE> ? [22:51:00 CET] <nevcairiel> there is a few external libraries that we can use that are only available under v3 [22:51:24 CET] <nevcairiel> so if you want to use those, ffmpeg itself needs to be licensed under v3 as well [22:52:21 CET] <faLUCE> nevcairiel: ok, so, the issue can be if you use v2 instead of v3 (with some v3+ libs), but not vice-versa [22:52:33 CET] <cone-203> ffmpeg 03Daniel Playfair Cal 07master:6e4202112898: avfilter/vf_lensfun: add scale parameter [22:52:36 CET] <nevcairiel> correct [22:52:41 CET] <faLUCE> thanks nevcairiel [22:53:35 CET] <nevcairiel> All our code is either GPLv2+ or LGPLv2+, any other options only come into play when external libraries are involved that require different licenses [22:54:25 CET] <faLUCE> right [22:55:10 CET] <BtbN> Very small parts art MIT [22:59:06 CET] <j-b> faLUCE: Apache2 + GPLv2+ gives you automatically GPLv3 [22:59:26 CET] <j-b> because GPLv2 is incompatible with Apache2, while GPLv3 is compatible [23:03:57 CET] <faLUCE> but, is v3 license different than v3+ ? From what I see, the license doc is "v3" and the "any later part" must be specified, instead, on the source code [23:48:02 CET] <lotharkript> who is the right person to talk about difference between filtercomplex and vf ? [23:51:04 CET] <jamrial> either durandal_1707 or Nicolas George, i think [23:54:27 CET] <lotharkript> Thanks.. We are seeing some difference between filtercomplex and vf when using fps filter and vsync [00:00:00 CET] --- Tue Mar 26 2019

1 0

ffmpeg.log.20190325
by burek 26 Mar '19

26 Mar '19

[00:30:29 CET] <jkhsjdhjs> sorry faLUCE, noticed just now that you highlighted me [00:31:02 CET] <jkhsjdhjs> https://hastebin.com/ogaxiwequh.bash [00:31:06 CET] <jkhsjdhjs> this is the command [00:32:50 CET] <jkhsjdhjs> -r 15 sadly doesn't seem to have any effect, just checked a recording [00:43:52 CET] <faLUCE> jkhsjdhjs: rtsp AFAIK is not well supported on ffmpeg, use vlc instead [00:44:57 CET] <jkhsjdhjs> hm, i think it's good enough supported for me. according to my understanding the problem is, that the camera reports a wrong framerate [00:45:15 CET] <jkhsjdhjs> and i currently attempt to fix that when capturing the stream [00:45:23 CET] <JEEB> there's a patch on the mailing list that lets you use -r before input like you did [00:45:33 CET] <JEEB> although I'm not 100% sure if it works with anything else than raw streams [00:45:56 CET] <jkhsjdhjs> hm, interesting, thanks for the info! [00:46:00 CET] <JEEB> there's also an option to set the input timestamps to match receipt (more or less) timestamps [00:46:04 CET] <faLUCE> jkhsjdhjs: it's not sure that this is a wrong framerate. It could be a reference framerate [00:47:02 CET] <faLUCE> how are you sure that the camera reports a wrong framerate? [00:49:23 CET] <jkhsjdhjs> i'm not sure. you could be right, maybe it's just a reference framerate. but i thought ffmpeg is a program developed over years by skilled developers. and the camera is rather cheap [00:50:12 CET] <faLUCE> jkhsjdhjs: of course ffmpeg is developed by skilled developers but some parts could not have an up to date support... [00:50:19 CET] <faLUCE> jkhsjdhjs: ffmpeg is huge [00:50:45 CET] <faLUCE> jkhsjdhjs: I remember that in the past years I always had troubles with rtsp on ffmpeg, and no troubles at all with vlc [00:50:53 CET] <damdai> i just saw a website that has to wait 60 seconds to go to the next page, but that 60 seconds stops when you minimize the browser and go to different windows. only way for 60 seconds to go to zero is you litterally have to stare at the scren, HOW is this possible? [00:50:56 CET] <DHE> I've used rtsp webcams in the past with ffmpeg. ran fine for days at a time considering. [00:51:31 CET] <jkhsjdhjs> that's true faLUCE [00:51:44 CET] <faLUCE> anyway, you should try if with other players you experience the same frame rate problem [00:51:46 CET] <jkhsjdhjs> does vlc offer a headless version? [00:52:05 CET] <faLUCE> jkhsjdhjs: at least, what does it happen if you record the rtsp stream? [00:52:12 CET] <faLUCE> does it provide a wrong frame rate? [00:52:59 CET] <jkhsjdhjs> you mean when i record it with vlc? [00:53:11 CET] <faLUCE> no, I mean when you record it with ffmpeg [00:54:25 CET] <jkhsjdhjs> the frames the camera sends get recorded. but since it's only 15fps instead of 25fps, the recorded duration is shorter then the time actually recorded [00:54:40 CET] <jkhsjdhjs> if i record 1 hour the file will have a duration of about 38 minutes [00:56:10 CET] <faLUCE> jkhsjdhjs: https://tools.ietf.org/html/rfc4566 <--- do you have the framerate in the sdp description? If so, the rfc doc says that that value is a recomandation [00:56:16 CET] <faLUCE> not the exact value [00:57:35 CET] <jkhsjdhjs> where can i view the sdp description? it it the metadata shown by ffmpeg at record start? [01:03:17 CET] <faLUCE> jkhsjdhjs: I would try with a player with a verbose output [01:16:32 CET] <jkhsjdhjs> ok thanks, i'll try to take a look on the sdp [01:19:15 CET] <faLUCE> yw [01:48:43 CET] <Retro64XYZ> Can anyone help me convert 'ffmpeg -i input.mp4 -c:v libx264 -crf 24 -b:v 1M -c:a aac output.mp4' into a python-ffmpeg equivalent? [01:49:07 CET] <Retro64XYZ> I am trying to write a script to convert my anime into smaller files. [02:11:16 CET] <Retro64XYZ> https://pastebin.com/7m2QTauy This is what I have right now but it errors out due to missing input stream. Obviously I am doing something wrong. Can any one help make this work? [02:20:03 CET] <Retro64XYZ> Never mind. I got it working. Should I post the fix or do I just leave it at 'Fixed'? [02:20:21 CET] <faLUCE> Retro64XYZ: was it a path issue? :-) [02:21:02 CET] <damdai> from which ffmpeg version, did ffmpeg started supporting Stream #0:0: Audio: dst (DST / 0x20545344), 352800 Hz, 5.1(side), flt [02:21:06 CET] <Retro64XYZ> No, formatting. I changed to a different method of formatting and I needed to specify lib(x)<--264 and not just lib264. [02:21:18 CET] <faLUCE> ok [02:28:21 CET] <damdai> i was told opusenc does not support 44.1khz : is this true? [02:28:29 CET] <damdai> i was told opus does not support 44.1khz : is this true? [02:33:12 CET] <faLUCE> damdai: the available sample rates are 48000, 24000, 16000, 12000, 8000, 0, [02:33:34 CET] <damdai> faluce thanks [02:33:50 CET] <damdai> i wonder why it doesn't support 44.1 [02:34:36 CET] <faLUCE> damdai: https://github.com/xiph/opus/issues/43 [02:35:23 CET] <damdai> is that opus bugreport website? [02:35:41 CET] <faLUCE> not exactly, it explains why adding 44.1 would be unuseful [02:36:13 CET] <faLUCE> (basically because it's not loseless) [02:36:49 CET] <damdai> okay let me read [02:37:18 CET] <faLUCE> I'm using opus and I find it excellent. It has a very low latency [02:37:43 CET] <damdai> i am so confused: people in #opus is saying it does support 44.1 [02:38:05 CET] <faLUCE> damdai: the ffmpeg wrapper doesn't [02:38:09 CET] <damdai> [18:34] <+gmaxwell> I wouldn't be shocked if _ffmpeg_ (not opusenc) didn't support 44100, but openenc happily does. [02:38:09 CET] <damdai> [18:34] <damdai> it's it same thing [02:38:09 CET] <damdai> [18:34] <damdai> don't they both use same lib [02:38:09 CET] <damdai> [18:35] <+gmaxwell> It's not the same thing [02:53:41 CET] <damdai> faclue i have no idea what gmaxwell is talking about [02:53:47 CET] <damdai> faluce [02:53:55 CET] <faLUCE> damdai: ? [02:54:04 CET] <damdai> so it does support 44.1 or not [02:54:17 CET] <faLUCE> damdai: he says that it supports it [02:54:40 CET] <damdai> but he keeps talking about how opus like 48 integers [02:54:44 CET] <faLUCE> damdai: he says that it supports it as INPUT but not as OUTPUT [02:55:22 CET] <faLUCE> instead, from what I see, ffmpeg considers that samplerate a "global" one [02:55:27 CET] <faLUCE> do you understand? [02:55:32 CET] <damdai> so you can do clean 44-1.wav to 44.1.opus [02:55:46 CET] <faLUCE> yes, but only as input [02:55:53 CET] <faLUCE> the output will be 48 [02:56:02 CET] <damdai> output meaning, only during playback? [02:56:08 CET] <faLUCE> yes [02:56:11 CET] <damdai> i see [02:56:24 CET] <damdai> but ffmpeg does not even support 44.1 as input (at least right now) [02:56:29 CET] <damdai> ?? [02:56:40 CET] <faLUCE> damdai: in fact this could be a limitation [02:57:02 CET] <faLUCE> I don't know why ffmpeg people made this limitation [02:57:37 CET] <faLUCE> maybe they thought that input was resampled. Dunno. [02:57:51 CET] <faLUCE> maybe gmaxwell is wrong and the input is really resampled [02:58:27 CET] <damdai> does this paste prove anything? https://0bin.net/paste/QqX3c1N9SnGYArz6#W0wazxWh3q3i6RZrp+z1dCIKQAQLHKah2aP… [02:58:55 CET] <damdai> in your opinion [02:59:15 CET] <faLUCE> from what I see, it doesn't prove [02:59:23 CET] <damdai> i see [02:59:28 CET] <faLUCE> because you can't know if the input has been resampled before processing [03:00:19 CET] <faLUCE> I mean, it could be 1) input 44.1 ---> resample to 48 ---> encode ---> output 48 OR 2) input 44.1 ---> encode ---> output 48 [03:02:22 CET] <damdai> which one is gmaxwell claiming? 1 or 2 [03:02:33 CET] <faLUCE> damdai: 2) [03:03:00 CET] <damdai> i see [04:14:00 CET] <kepstin> internally, opus encodes at 48khz and a couple divisions thereof depending on the particular encoding mode and tools it's using [04:14:12 CET] <kepstin> most input will end up being resampled to 48kHz before encoding [04:16:17 CET] <damdai> kepstin not according to opus dev [04:16:37 CET] <damdai> if you use opusenc binary [04:16:56 CET] <kepstin> i mean, you can technically run the opus encoder in celt-only mode at arbitrary sample rates, but that's not following the spec so it's not officially "opus" [04:17:18 CET] <damdai> opusenc is "official opus binary" [04:19:09 CET] <kepstin> damdai: not sure what you're on about. opusenc (the tool) accepts input at arbitrary sample rates, but resamples to 48khz before encoding. [04:19:23 CET] <kepstin> notably, opusenc *does* store the original sample rate as metadata in the ogg opus file [04:19:48 CET] <damdai> kepstin join #opus because that's not what the opus devs are saying [04:19:48 CET] <kepstin> and i think opusdec can use that to resample the when decoding from 48kHz back to what the input was [04:21:46 CET] <damdai> kepstin let me paste you the logs [04:22:31 CET] <damdai> https://pastebin.com/7DpAxMUe [04:25:30 CET] <kepstin> hmm, they say that opus can produce an exact number of output samples for arbitrary input sample rates, which is kind of interesting. [04:25:46 CET] <kepstin> kind of a weird edge case, but sure. [04:27:00 CET] <damdai> kepstin so what did you learn from that log [04:27:31 CET] <kepstin> that the libopus encoder/decoder can preserve an exact number of samples when the input/output rate is something other than 48kHz [04:27:55 CET] <damdai> then why can't ffmpeg ? [04:28:02 CET] <kepstin> which is more a property of their resampler than anything else, really. [04:28:04 CET] <damdai> then why can't ffmpeg using libopus ? [04:30:05 CET] <kepstin> it's not required by the opus spec, so I guess nobody bothered with the internal opus decoder, and it never got added to the libopus wrapper. [04:31:04 CET] <damdai> kepstin are you ffmpeg dev? [04:31:29 CET] <kepstin> you'll need to better define "ffmpeg dev" [04:31:41 CET] <kepstin> i am a developer who has written code that's been merged into ffmpeg [04:31:43 CET] <kepstin> fwiw. [04:31:58 CET] <damdai> do you have access to ffmpeg dev site? [04:32:19 CET] <kepstin> what do you mean "dev site"? [04:32:39 CET] <damdai> ffmpeg site then [04:34:16 CET] <kepstin> what about it? most of the stuff on there is just autogenerated from the ffmpeg source code. [04:36:02 CET] <damdai> lol never mind [04:37:38 CET] <damdai> why can't single player able to find proper length of .mlp file? including ffprobe/ffplay [04:37:50 CET] <kepstin> it's not like there's any secret cabal of ffmpeg developers, I mean the link to the development irc channel is right in the topic of this one. [04:38:07 CET] <damdai> kepstin but i am sure some dev have more access than the other [04:38:29 CET] <damdai> it's not like anybody can upload a ffmpeg binary to ffmpeg.org [04:38:40 CET] <kepstin> yeah, some have the ability to commit directly to the git tree (and they're also responsible for merging stuff from other contributors) [04:39:02 CET] Action: kepstin has no idea about mlp [04:39:26 CET] <damdai> kepstin i see, but if ffmpeg doesn't fix it , then nobody else will [04:39:39 CET] <damdai> almost everything relies on ffmpeg [04:39:43 CET] <kepstin> assuming that's a raw bitstream of a compressed format, it makes sense that the length would be tricky to determine [04:39:57 CET] <kepstin> it's not like pcm where you can just measure the file size [04:40:11 CET] <kepstin> and without headers, there's no metadata for length [04:41:09 CET] <kepstin> i suspect this is very much a case of "if you can figure out how to do it in a reasonable way, please send a patch" [04:42:01 CET] <damdai> i've seen ffprobe giving warning to a different audio format; it will calculate duration by filesize but this might not be accurate [04:42:09 CET] <damdai> sayying something like that [04:42:30 CET] <damdai> but it was accurate [04:42:37 CET] <kepstin> there's some code for that in a few specific demuxers in cases where it can make an educated guess [04:42:57 CET] <damdai> if ffprobe can do that with that format, why can't it work with MLP [04:43:25 CET] <kepstin> because it requires format specific knowledge to make an educated guess, and it's only been implemented in a few specific demuxers [04:43:26 CET] <damdai> uration: N/A, start: 0.000000, bitrate: N/A [04:43:26 CET] <damdai> Stream #0:0: Audio: mlp, 96000 Hz, 5.1, s32 (24 bit) [04:43:48 CET] <kepstin> iirc it works reasonably well in mp3 because a lot of mp3 content is constant bitrate, or has a xing header with average bitrate [04:44:19 CET] <damdai> xing ? that's one of the rare mp3 encoders [04:44:23 CET] <damdai> that nobody uses [04:44:44 CET] <kepstin> sure, but xing encoder wrote an extra header with some metadata, and the lame encoder and a bunch of others copied it [04:44:56 CET] <kepstin> so that header is a de-facto standard now [04:45:05 CET] <damdai> kepstin i see, metadata on mp3 was invented by xing first? [04:45:23 CET] <damdai> didn't know that [04:45:35 CET] <kepstin> no, it wasn't. this one particular header containing information that helps determine the length of vbr mp3 files was invented by xing. [04:46:03 CET] <damdai> i see [04:46:12 CET] <damdai> what about for VBR AAC or VBR OPUS [04:46:26 CET] <kepstin> aac is typically used in an mp3 container, which has length as metadata [04:46:41 CET] <kepstin> opus has to be stored in a container, and in ogg opus it has timestamped packets so you can figure out the length [04:46:45 CET] <damdai> aac uses same container as mp3 ? [04:46:48 CET] <kepstin> er, mp4 container* [04:46:48 CET] <damdai> didn't know that either [04:46:52 CET] <kepstin> typo :) [04:46:55 CET] <damdai> oh [04:48:05 CET] <damdai> Duration: 00:04:19.17, bitrate: 6819 kb/s [04:48:05 CET] <damdai> Stream #0:0: Audio: dst (DST / 0x20545344), 352800 Hz, 5.1(side), flt [04:48:36 CET] <damdai> only MLP has this issue of not finding the duration [04:49:11 CET] <kepstin> lots of formats can't determine a duration, or can do so only unreliably. it's not just mlp [04:49:18 CET] <kepstin> but if you know how to do it, please share [04:49:38 CET] <damdai> kepstin what other format can you think off right now [04:50:38 CET] <kepstin> i have no idea what 80%+ of the formats ffmpeg supports even are, since there's a lot of esoteric stuff. [04:51:15 CET] <kepstin> obviously you have to exclude network/live streaming formats since the concept of length doesn't make sense for those at all [04:51:40 CET] <damdai> i am interested in what version of ffmpeg did ffmpeg started supporting "DST" how do i find out [04:52:08 CET] <kepstin> damdai: look through the news posts to see when it's mentioned, check the git logs for the dst files. [04:52:24 CET] <damdai> does ffmpeg even use github? [04:52:30 CET] <kepstin> git, not github [04:52:34 CET] <damdai> oh [04:52:50 CET] <kepstin> (there is actually a github mirror of ffmpeg's git repository, tho) [04:52:55 CET] <damdai> why can't ffmpeg use github [04:53:04 CET] <damdai> github is really nice [04:54:12 CET] <kepstin> dunno entirely. probably part of it is to add an extra barrier for people contributing code rather than having open pull requests (most code is still reviewed on a mailing list before being committed) [04:55:04 CET] <damdai> how can ffmpeg even playback DSD when i don't even have a soundcard that only supports PCM [04:55:30 CET] <kepstin> i cannot parse the grammar of that sentence [04:55:46 CET] <damdai> how can ffmpeg even playback DSD when i have a soundcard that only supports PCM [04:55:48 CET] <damdai> sorry [04:56:12 CET] <damdai> most people don't have dsd soundcard [04:56:16 CET] <kepstin> ffmpeg has a dsd "decoder" that converts it to pcm [04:56:36 CET] <damdai> don't you still need a dsd DAC ? [04:56:49 CET] <kepstin> no, because after you convert it to pcm, it's pcm [04:56:56 CET] <kepstin> so you can use a normal pcm dac [04:57:36 CET] <damdai> i am guessing you lose a lot of quality during that converting by ffmpeg [04:57:48 CET] <damdai> conversion* [04:58:12 CET] <kepstin> should introduce very little distortion, well below the audible range [04:58:54 CET] <kepstin> some claims i've seen are that the dsd to pcm conversion should in theory be lossless [04:59:14 CET] <damdai> really? where did you hear that [04:59:56 CET] <kepstin> https://wiki.jriver.com/index.php/DSD - but that assumes you're converting to ridiculously high pcm sample rates [05:00:20 CET] <kepstin> in real use cases you'd have to downsample to something reasonable like 48kHz which would mean doing a lowpass to remove ultrasonics [05:01:14 CET] <kepstin> (hopefully dsd dacs have such a lowpass filter builtin to avoid damaging speakers and whatnot) [05:07:08 CET] <kepstin> i'm kind of curious where all this dsd content comes from anyways, since the vast majority of audio is recorded & mixed in pcm [05:07:32 CET] <kepstin> i'd expect a lot of dsd stuff to actually be converted from pcm (I assume there are exceptions) [05:10:22 CET] <damdai> kepstin SACD [05:10:53 CET] <damdai> all sacd uses dsd [05:12:21 CET] <kepstin> sure, but i'm willing to bet that a lot of sacds are mastered by converting pcm audio to dsd :) [05:12:47 CET] <kepstin> (again, not all, i have definitely heard of sacds being mastered through a full dsd pipeline) [05:13:22 CET] <damdai> no, dsd audio can be edited using 8bit dsd audio [05:13:49 CET] <damdai> and they finalize to 1bit dsd audio [05:25:44 CET] <kepstin> i wouldn't be surprised if most of the newer classical recordings on sacd were dsd from start to finish. and remasters of old (pre-80s) albums may have been newly digitized from analogue tapes in dsd. but other than that... [05:25:59 CET] <kepstin> you know, i haven't actually really seen anything other than that on sacd [05:28:44 CET] <kepstin> oh, hah, there's a sacd release of dire straits "brothers in arms", which was originally recorded/mixed/edited on sony digital audio equipment in pcm. [05:31:13 CET] <damdai> lol , they cheated [05:31:24 CET] <damdai> and cheating customers too [05:31:59 CET] <damdai> how did you know it was originally in PCM? [05:33:18 CET] <kepstin> because that's a historical record since it's once of the first CD releases marked as 'DDD', meaning recorded/mixed/mastered digitally, and it was one of the first albums recorded using a particular sony 24track digital recorder. it's a pretty well documented release because of the firsts. [05:34:03 CET] <damdai> i see [05:35:05 CET] <damdai> vlc nightly is so buggy, it's unusable [14:19:35 CET] <jkhsjdhjs> hey. i'm capturing an rtsp stream with the following command: https://hastebin.com/ogaxiwequh.bash [14:19:36 CET] <jkhsjdhjs> the problem is that ffmpeg assumes the stream has 25fps, when it actually has 15fps. this can be seen here: https://hastebin.com/uricefabic [14:19:36 CET] <jkhsjdhjs> so i checked the session description by printing the sdp data: https://hastebin.com/leqimogiho [14:19:36 CET] <jkhsjdhjs> as you can see in line 11 the camera tells ffmpeg that it streams with a framerate of 15, but ffmpeg ignores this information [14:19:36 CET] <jkhsjdhjs> is there a way to make ffmpeg capture with 15fps instead of 25fps? i was told yesterday that there is a patch on the mailing list allowing me to use -r 15 in front of -i, but i couldn't find it. it would be cool if anyone could paste a link [14:56:11 CET] <faLUCE> hello [14:59:28 CET] <jkhsjdhjs> hey faLUCE [14:59:40 CET] <jkhsjdhjs> i found the sdp data [14:59:56 CET] <jkhsjdhjs> https://hastebin.com/leqimogiho [15:01:01 CET] <faLUCE> jkhsjdhjs: yes, as said yesterday ffmpeg uses that framerate in a strict sense [15:01:13 CET] <faLUCE> then you should use another receiver [15:02:31 CET] <JEEB> double-check if the rtsp demuxer sets pts by anything else. I am not sure if rtsp has timestamps in the packets, but if there are such they should be utilized? [15:02:53 CET] <faLUCE> JEEB: it's not rtsp which has ts, but rtp [15:02:54 CET] <JEEB> (it will probably print the sdp fps as metadata, but timestamps of packets should be with the pts) [15:03:02 CET] <JEEB> and rtp has no pts in packets? [15:03:09 CET] <faLUCE> JEEB: yes, it has [15:03:48 CET] <faLUCE> but, in each case, it's a matter of interpretation of the sdp metadata. Ffmpeg takes it more strictly than other players [15:04:47 CET] <JEEB> http://up-cat.net/p/6d5a1e7c [15:04:50 CET] <JEEB> this looks like relevant? [15:05:15 CET] <JEEB> anyways, dunno - I've not used rtsp too much but it's worked for me in general [15:05:24 CET] <JEEB> (in the few cases I've poked at it) [15:06:05 CET] <faLUCE> JEEB: yes, but IMHO jkhsjdhjs would not be fixed. It's a matter of how you interpret that field [15:06:21 CET] <JEEB> is the part I linked irrelevant? [15:06:37 CET] <JEEB> found it by quickly checking `git grep -C2 "pts =" -- libavformat/rtp*` [15:06:43 CET] <JEEB> and checking parts where not NOPTS was set [15:06:59 CET] <JEEB> rtsp code seems to not touch packets, rtp code seems [15:07:04 CET] <JEEB> (timestamp wise) [15:07:16 CET] <faLUCE> JEEB: from what I see, the "delta" part is obtained by rtsp [15:07:22 CET] <faLUCE> (maybe) [15:07:28 CET] <JEEB> anyways $dayjob for me o/ [15:07:48 CET] <faLUCE> JEEB: rtsp is an additional layer for rtp [15:08:46 CET] <JEEB> yea but it didn't seem to touch AVPackets' pts at all :) [15:09:04 CET] <JEEB> git grep "pts =" -- libavformat/rtsp* [15:09:07 CET] <JEEB> see the result of that [15:09:22 CET] <JEEB> anyways, off [15:09:41 CET] <jkhsjdhjs> cu [15:09:52 CET] <faLUCE> JEEB: we'll discuss about that later :-) [15:10:49 CET] <faLUCE> jkhsjdhjs: as said before, CHECK if with other players you can record properly the stream [15:11:06 CET] <jkhsjdhjs> ok, will do [15:11:18 CET] <faLUCE> jkhsjdhjs: you can also try live555, there are some examples for receiving and dump a rtsp stream [15:11:35 CET] <faLUCE> that library is completely focues on rtsp [15:11:39 CET] <faLUCE> focused [15:12:00 CET] <jkhsjdhjs> ah, it is used by vlc [15:12:16 CET] <jkhsjdhjs> i'll check recording with vlc then [15:12:19 CET] <faLUCE> jkhsjdhjs: yes, and note that vlc DOESN'T use the laavf rtsp [15:53:51 CET] <moef> Is it possible to force the processing of an input stream to follow the duration of the input video file? [15:54:21 CET] <moef> For example: Process of video1.mp4 with the duration 30s will result in an output stream that lasts 30s? [16:02:39 CET] <moef> YES I CAN [16:02:44 CET] <moef> It's called native [16:02:58 CET] <moef> It processes input at the native framerate [16:02:59 CET] <moef> awesome [21:43:52 CET] <orlcp440> Is there a way for one to concatenate/pipeline/chain/nest (whatever the term is) two protocols and/or two demuxers? For example, if I want to use the UDP demux/protocol and I want the output of it to be in input of the RTP demux/protocol module how do I go about doing that? [21:47:00 CET] <orlcp440> I want to use the UDP module because it uses pthreads and a fifo buffer so I can set a bit rate etc but I want the UDP module's output which in this case the payload is nothing but RTP to go into the RTP demux for further processing [22:45:31 CET] <faLUCE> are there parts of ffmpeg that are compatible with gpl v2 but not compatible with gpl v3 ? [22:48:35 CET] <furq> no [22:48:53 CET] <DHE> this is explicitly discussed in the LICENSING.md file in the source [22:49:57 CET] <furq> afaik (l)gpl2 is always gpl3 compatible as long as it mentions "or later" in the license [22:50:12 CET] <furq> which it does [22:55:02 CET] <faLUCE> I see. nevcavriel answered too that, instead, there could be parts compatible with gpl v3 but not compatible with gpl v2 [22:55:13 CET] <furq> right, and there are [22:55:30 CET] <furq> or there are libs you can link to that are [22:55:49 CET] <faLUCE> so the best choice would be always to use the newer version of gpl/lgpl [22:56:21 CET] <furq> if you're writing an application that might need a gpl3 component then yeah [22:57:14 CET] <faLUCE> except for the case you specifically want something that is in v2+ license but is not in the v3+ version... but it could be very hard to figure what :-) [22:57:38 CET] <furq> well there is no such case within ffmpeg [23:11:26 CET] <faLUCE> but, is v3 license different than v3+ ? From what I see, the license doc is "v3" and the "any later part" must be specified, instead, on the source code [23:12:27 CET] <furq> well there is no gplv4 so that's fine [23:13:24 CET] <faLUCE> furq: :-) [23:14:22 CET] <faLUCE> furq: but this doesn't answer to my question... [23:14:48 CET] <faLUCE> anyway, I could not find any text of the "gpl v3+" license. Only "gpl v3" [23:14:57 CET] <furq> v3+ and v3 are identical as long as v3 is the latest version [23:15:08 CET] <furq> they both subsume any other compatible license [23:15:40 CET] <furq> you only need to worry that gpl2/lgpl2 stuff specifies that it's 2+ or 2 or later [23:15:55 CET] <furq> otherwise it's incompatible by some weird technicality afaik [23:16:33 CET] <faLUCE> furq: yes, anyway, in the gnu channel they gave me an exact answer: "[23:15] <AliciaC> GPLv3+ is not a license of its own, but shorthand for GPLv3 and invoking the option to let people upgrade to a newer version of the GPL" [23:16:42 CET] <furq> with that said, if you're not actually depending on gplv3 code then you can just use v2 anyway [23:16:52 CET] <furq> even if a user links it with an --enable-version3 ffmpeg [23:17:09 CET] <faLUCE> I see [23:17:28 CET] <furq> and there's only a couple of obscure libs that need v3 [23:19:42 CET] <Hello71> gplv3 is compatible with gplv2 by a special exception [23:19:57 CET] <Hello71> iirc [23:20:43 CET] <faLUCE> Hello71: from what alicia said, the compatibility is done by the option mentioned in the license [23:22:25 CET] <Hello71> hm. must be confusing it with cc by-sa 4.0 then [23:22:55 CET] <DHE> it's hardly even an exception, the license's shipped boilerplate version contains the "or later" clause, or strongly encourages you to use such wording. [23:23:12 CET] <DHE> linux is considered slightly unusual in NOT taking the "or later" clause. [23:23:16 CET] <faLUCE> DHE: yes, it's an option, not an execption [00:00:00 CET] --- Tue Mar 26 2019

1 0

ffmpeg-devel.log.20190324
by burek 25 Mar '19

25 Mar '19

[10:37:27 CET] <cone-319> ffmpeg 03Michael Niedermayer 07master:013f71497ba5: avcodec/tiff: do not allow bpp 40 with undefined pixel formats [15:15:29 CET] <BtbN> Vulkan extension for video de/encode. Now that sounds interesting. [15:16:18 CET] <BtbN> Might be just the thing specially Linux needs to clean up the mess a bit. [15:26:13 CET] Action: bencoh mutters something about openmax [15:29:10 CET] <BtbN> Except no normal GPU driver implements that, while they all implement Vulkan [15:50:52 CET] <philipl> BtbN: I'm sure they'd find a way to implement different video extensions which are all part of the spec, just like the memory sharing ones... [15:52:20 CET] <philipl> jkqxz, BtbN: Is that crop_cuda the right way to do the cropping? I saw jkqxz posted his change to the crop filter to propagate the crop values - should we be doing cuda cropping in the scale filter too? [15:52:39 CET] <philipl> and save a copy [15:58:11 CET] <BtbN> Thing is, with the "save a copy" argument you would end up with one huge catch-all filter [16:09:05 CET] <BtbN> And if you put it into the scale filter, won't it have to internally copy either way? [16:16:59 CET] <tmm1> can anyone see a problem with this approach: https://gist.github.com/tmm1/002096d61886fb7f58830455870104ad [16:26:18 CET] <jkqxz> For VAAPI, it's straightforward to put it in every filter so you don't have to use scale (right now only scale has it, but it can easily be pushed in the generic VAAPI filter code). It can't be set on an encoder, though. [16:27:09 CET] <jkqxz> Other APIs are all a bit uglier though. OpenCL would be trivial if it had subimages, but it doesn't so you would need a bit of code to support it in every kernel. [16:28:52 CET] <JEEB> &33 [16:29:13 CET] <jkqxz> I was thinking of adding a hwframe transfer flag to indicate whether cropping is desired. It would be easy on some APIs and impossible on others, though, so the exact semantics of how it should behave are unclear. [16:29:46 CET] <jkqxz> (And add an option to hwdownload (maybe set by default?) to control it.) [16:55:39 CET] <BtbN> jkqxz, the problem with CUDA are the strict alignment requirements [16:55:53 CET] <BtbN> cropping top/right/bottom works without copy, but left... [17:04:16 CET] <jkqxz> Isn't the cuda code itself (in the scale filter) just treating them as arrays of bytes, though? [17:05:43 CET] <BtbN> They are arrays of bytes [17:05:57 CET] <BtbN> but each line has to be at least 256 byte aligned [17:06:39 CET] <BtbN> so you could crop the left side. In increments of 256 [17:07:09 CET] <BtbN> Or 512 even, depending on format [17:07:24 CET] <jkqxz> But doesn't that mean that your scale filter just ignores however many bytes on the left edge to apply the cropping? Or is there some additional constraint on how that code works which I'm not aware of? [17:07:46 CET] <BtbN> The scale filter doesn't do cropping. It's a dedicated crop filter that's on the ML. [17:08:25 CET] <jkqxz> Generic crop followed by something like scale, I mean. [17:08:54 CET] <jkqxz> And supporting cropping from the decoder, too. [17:09:07 CET] <BtbN> cuvid supports cropping. nvdec can't. [17:09:35 CET] <jkqxz> NVDEC correctly sets the crop fields, so it anything read them it would work. (Like scale_vaapi does.) [17:09:52 CET] <BtbN> And when you crop in a generic fashion, it'll fail to encode due to poor alignment [17:10:10 CET] <BtbN> unless you happen to hit proper alignment with your crop [17:11:55 CET] <jkqxz> The encoder just ignores the cropping information, yeah. [17:12:42 CET] <BtbN> I don't follow. The Cuda Pointers are pretty much normal pointers. And they need to be properly aligned. So if you do naive cropping without copying to another aligned buffer, it will fail at some point. [17:12:46 CET] <jkqxz> Not sure any hardware encoder supports that, so you always have to put something in front of the encoder to deal with the cropping. [17:13:43 CET] <jkqxz> Sorry, maybe that wasn't clear. By generic cropping I mean setting the AVFrame cropping fields (like the decoder does). Other filters can make use of them (like scale_vaapi does). [17:14:08 CET] <jkqxz> It doesn't change any pointers, so the filters need to have enough awareness to apply offsets themselves. [17:14:55 CET] <BtbN> Hm, so that'd mean rejecting the scala_cuda filter, and implement its functionality into the scale_cuda filter instead? [17:15:02 CET] <BtbN> *rejecting the crop_cuda filter [17:16:26 CET] <jkqxz> Yes, that's my thought. [17:18:53 CET] <BtbN> The problem is, we'd then end up with pretty much only one everything_cuda filter, to avoid copies [17:19:05 CET] <jkqxz> Maybe we need another comparison point. How will cropping work with vulkan, say? [17:19:38 CET] <BtbN> Cause the argument of avoiding a copy works with pretty much every CUDA filter. [17:20:20 CET] <jkqxz> What other components are you thinking everything has there? The crop filter only works in this case because we already support it from the decoder and have the AVFrame fields to do so. [17:20:47 CET] <BtbN> Pretty much every filter implemented in CUDA [17:21:15 CET] <BtbN> if you implement tham as individual avfilter filters, most of them will need a copy or call make_writable [17:21:30 CET] <BtbN> If you stuff all of them into one filter into a common kernel, you can do all of them with only one single copy [17:24:30 CET] <jkqxz> Give a specific example? I'm not sure I see any other separate filters we could deal with like this. (Colour conversion can since the AVFrame has those fields, but scale already handles that in the software case too.) [17:25:07 CET] <BtbN> transpose, scale, crop, color correction, ... literally anything you can write into a CUDA Kernel [17:28:48 CET] <jkqxz> I don't see. How do you implement transpose in this form? The generic transpose filter on software frames does a copy, and there isn't any pointer trickery or "also transpose this" field you can mark to indicate that a transpose is needed. [17:29:35 CET] <BtbN> You just write one big kernel which does all the things, and run it once. [17:30:04 CET] <BtbN> Instead of chaining 5 different Kernels, with a copy in between each [17:30:55 CET] <jkqxz> But you would then need to make your filter -vf allthethings_cuda. Not -vf crop,transpose,scale_cuda in series, which is what the proposal is. [17:31:10 CET] <BtbN> Which is exactly what I'm saying the issue is [17:32:32 CET] <BtbN> Putting all the functionality into one big kernel will vastly outperform the other approach, but it's clearly very ugly [17:35:25 CET] <jkqxz> I don't think it follows that you want to do that. My slippery slope has a fence on it at the fields already existing which should be supported anyway. [17:35:37 CET] <jkqxz> (Such as the cropping fields in AVFrame.) [17:45:20 CET] <philipl> BtbN: it seems like it would be reasonable to apply crop in the scale filter. It would not double the amount of code in there. [18:04:03 CET] <BtbN> jkqxz, it's entirely unrelated to any fields anywhere. This applies to pretty much each and every cuda based filter. [18:04:17 CET] <BtbN> philipl, yeah, crop can go in there. And transpose and rotate probably as well. [19:10:10 CET] <philipl> BtbN: I can't tell if you're being sarcastic when you say that :-P [19:10:57 CET] <BtbN> No, I'm fine with a "all the video transformations" filter [19:11:47 CET] <BtbN> combining scale and crop should be simple enough [19:12:32 CET] <philipl> Ok. So that's a plan at least. I wonder if the crop filter guy is willing to do the work. [19:12:54 CET] <philipl> Do you know who these people are? Looks like a chinese company. [19:13:20 CET] <BtbN> No idea, I thought it was an nvidia guy first, some of them use their gmail address to avoid the company footer, but it doesn't seem to be. [19:13:40 CET] <BtbN> Pretty sure it's just one person, sometimes using an pseudonym, sometimes the right now? [19:13:59 CET] <philipl> I thought I saw one author and two other guys showing up for the first time doing partial reviews. [19:14:14 CET] <jkqxz> You are thinking transpose/rotate by making the generic one set displaymatrix which can be read by scale? [19:14:27 CET] <philipl> Not terribly important, but always interesting when the author isn't nvidia. [19:14:55 CET] <BtbN> Hm? I'm thinking by writing all of them into one kernel. [19:15:06 CET] <BtbN> And activating the neccesary parts via parameters. [19:16:59 CET] <jkqxz> Oh. That's not what I was imagining, nor how the generic crop is working. [19:18:00 CET] <BtbN> But that's what the whole discussion was about, putting all the functionalities into one filter, to avoid copying the frame around more than absolutely neccesary. [19:20:55 CET] <jkqxz> Er, no? From my point of view the intent was to put the functionalities of filters which we already have to handle in non-filter form (like cropping information) into the scale filter, and making the generic filters set those parameters for hardware frames so you can use them identically. [19:25:41 CET] <atomnuker> the thing I'm worried about is that if they have a vulkan decoding api they'll probably jam the post-processing side of things (deinterlacing, eq) in the swapchain like they did with hdr [19:28:36 CET] <BtbN> So you want to auto-insert the "do everything scaling/cropping" filter before the encoder? But then again, that does not change a thing about the issue at hand. [19:28:46 CET] <BtbN> A monolithic filter would even make that easier. [19:30:28 CET] <jkqxz> I wasn't particularly intending to auto-insert it, though I guess it could be. [19:31:14 CET] <BtbN> With no metadata attached it's just a plain passthrough [19:41:14 CET] <j-b> BtbN: philipl: I have a called scheduled next week with nVidia [19:41:55 CET] <BtbN> sounds good [19:42:26 CET] <j-b> for nvcc, yes [19:42:32 CET] <j-b> for npp, not really [19:42:45 CET] <j-b> but anyway, I'll try my best [19:43:05 CET] <BtbN> The thing is, the compiler isn't even the hard part. clang can do that. It's all the libs it links against. [19:43:19 CET] <nevcairiel> i thought it doesnt actually do that [19:43:32 CET] <nevcairiel> just generate cuda-asm [19:43:34 CET] <j-b> my understanding was similar to nevcairiel [19:43:45 CET] <BtbN> clang can replace nvcc, but still needs the SDK for headers and libs [19:44:11 CET] <BtbN> Which makes the whole matter a whole lot more complicated. [19:45:52 CET] <BtbN> https://developer.nvidia.com/cuda-llvm-compiler even suggests nvidia themselves uses that for nvcc now [19:51:26 CET] <BtbN> Basically, we need _any_ way to build. .cu to .ptx that does not require accepting EULAs and registering with Nvidia. [19:57:02 CET] <philipl> j-b: were you able to ask Bradley about the compiler thing? [19:57:13 CET] <philipl> whether there's actually a licence issue here? [19:59:24 CET] <BtbN> I mean, we can always implement the idea of adding the .ptx files to the tree... [19:59:55 CET] <BtbN> But I feel like that Idee will receive general disagreement when sending it for review [20:01:51 CET] <philipl> I don't see what licensing problem that fixes. If you consider the ptx files to still be free then what is checking them in solving? Sounds like the argument is that a EULA encumbered compiler is inconvenient. Yes it is, but that is not licensing. [20:03:52 CET] <philipl> BtbN: and you are right about the compiler. the actual compiler binary is probably free or almost free if it's not identical to clang, but you need to give it sdk components to actually do the compilation to resolve symbols and so on. [21:53:17 CET] <jkqxz> j-b: I don't know about the others, but I'm not sure the "glorified ioctl" comment is really true for Intel. On Linux at least, the userland parts (libmfx / any of the VAAPI drivers) are pretty huge. [21:53:40 CET] <jkqxz> The ioctl() interface being used is pretty much entirely "enqueue this operation to some command ring", where that operation is something pretty complex constructed in userland. [21:53:41 CET] <j-b> VAAPI drivers are drivers [21:54:03 CET] <j-b> and are part of "major components of the OS [21:54:41 CET] <jkqxz> So the kernel-land comment was meaning something more than the kernelspace/userspace distinction? I guess that's fair. [21:54:57 CET] <j-b> the issue is that the GPL is unclear [21:55:04 CET] <j-b> and was written in 1991 [21:55:29 CET] <j-b> > However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. [21:55:35 CET] <j-b> This is what it says [21:55:45 CET] <j-b> It does not speak about libraries, at all. [21:55:56 CET] <j-b> It speaks about 'major components' [21:56:15 CET] <j-b> and it speaks about 'so on' [21:57:01 CET] <j-b> It mentions compiler, which is what philipl was talking about, but it was meant as C compiler, at that time. [21:59:42 CET] <jkqxz> A Linux distribution is inconveniently huge nowadays - you could produce a distribution which "normally distributes" basically any binary thing you want (NDIux, say). Reading that as kernelspace/userspace would at least apply a clean delineation. [22:00:21 CET] <j-b> that is why it says "major components" [22:00:26 CET] <j-b> not "any components" [22:02:19 CET] <jkqxz> Well, libNDI is a critical and required component of NDIux. [22:05:07 CET] <j-b> Which is not an OS, and not a way to access hardware [22:27:38 CET] <cone-081> ffmpeg 03James Almer 07master:699d0c2a30d5: avcodec/av1_parser: don't abort parsing the first frame if extradata parsing fails [23:23:11 CET] <BBB> this is honestly too much legalese for me. As I've said in my email, my concern is philosophical as much as it is legal [23:23:16 CET] <BBB> the legal case is murky at best [23:23:25 CET] <BBB> the philosophical case is just outright dubious [23:23:26 CET] <BBB> imo [00:00:00 CET] --- Mon Mar 25 2019

1 0

ffmpeg.log.20190324
by burek 25 Mar '19

25 Mar '19

[00:00:59 CET] <faLUCE> Dodutils: AFAIK vlc has better support for rtsp. why don't you use that? [00:02:49 CET] <Dodutils> @faLUCE : not sticked to ffmpeg, only know it better than vlc, I can go to vlc if it better support RTSP and can do what I need [00:03:40 CET] <faLUCE> Dodutils: try vlc for that, command line [00:05:10 CET] <faLUCE> Dodutils: about the second question: [00:05:37 CET] <faLUCE> (server "frozen") [00:06:19 CET] <faLUCE> it depends on which kind of cameras you use [00:07:13 CET] <Dodutils> an example is that I restart camera every night and ffmpeg do not detect that and just stop recording but do not reconnect to camera [00:07:48 CET] <faLUCE> Dodutils: no, you can't proceed in this way [00:08:32 CET] <faLUCE> ok, the "easy way is this": [00:08:39 CET] <Dodutils> but what I do not understand is why ffmpeg do not warn/detect/quit or do anything once connection to camera is lost [00:09:01 CET] <faLUCE> Dodutils: wait, I'll write you the easy and difficult ways to solve that, step by step [00:09:49 CET] <faLUCE> the easiest way is to relaunch the recorder at each disconnection of the camera [00:09:58 CET] <faLUCE> (do you use an usb camera?) [00:10:34 CET] <faLUCE> or do you use an IP camera? [00:13:18 CET] <Dodutils> I use an IP cam but the example of camera restart was just one case (this one I control and I can restart ffmpeg same time) [00:13:27 CET] <Dodutils> 8 cams differents models [00:13:36 CET] <faLUCE> Dodutils: are they all IP ? [00:13:45 CET] <Dodutils> yep [00:14:25 CET] <faLUCE> ok, now: would it be enough if you restart recording after a reconnection? [00:18:29 CET] <Dodutils> that's what I planned checking video file date if 'touch' older than xx second and ffmpeg process still present then houston we have a problem so restart ffmpeg [00:19:34 CET] <faLUCE> Dodutils: you did not answer: [00:19:39 CET] <faLUCE> would it be enough if you restart recording after a reconnection? [00:20:28 CET] <faLUCE> or you want something more accurate? [00:21:39 CET] <Dodutils> I want to keep all the files (by default I do 5 mins segmentation) and yes I can restart recording with a loss of a few secs [00:23:33 CET] <faLUCE> Dodutils: ok, so, first of all, exec cvlc rtsp://camera-ip with option that lets vlc exit after a connection failure [00:23:57 CET] <faLUCE> I don't remember the name of the option, but there's one, wait [00:25:25 CET] <faLUCE> it should be: --play-and-exit [00:25:30 CET] <faLUCE> you can test it [00:25:55 CET] <faLUCE> so: cvlc --play-and-exit rtsp://camera-ip [00:26:18 CET] <faLUCE> after you tested that, put that into a loop script, and we can proceed with the second part [00:26:30 CET] <Dodutils> done [00:26:42 CET] <faLUCE> does it exit after a disconnection ? [00:29:43 CET] <Dodutils> nope [00:31:38 CET] <Dodutils> may be there is some timeout parameter ? [00:31:53 CET] <faLUCE> Dodutils: some years ago play-and-exit worked, wait [00:35:50 CET] <faLUCE> Dodutils: --rtsp-timeout [00:36:14 CET] <faLUCE> try: clvc --rtsp-timeout=5 ... [00:37:10 CET] <faLUCE> (it could not work, anyway, it seems more a timeout for the rtsp part, not for the transport part) [00:37:28 CET] <faLUCE> anyway, try it [00:37:32 CET] <Dodutils> unknown option or missing mandatory argument `--rtsp-timeout=5' [00:38:49 CET] <Dodutils> same with space instead of "=" [00:39:20 CET] <Dodutils> and a grep on vlc --help show only 3 timeout parameters with no connection with "streaming" [00:40:50 CET] <faLUCE> Dodutils: I know, vlc options are a mess. Try that: --ipv4-timeout=1000*seconds-you-want [00:41:18 CET] <faLUCE> for example: --ipv4-timeout=5000 (5 seconds timeout) [00:44:43 CET] <Dodutils> not stopping either, I guess it is timeout for first connection [00:48:16 CET] <faLUCE> Dodutils: well, try: vlc --longhelp --advanced | grep timeout [00:48:26 CET] <faLUCE> there are some other timeouts that you can try [00:48:38 CET] <faLUCE> for example: --rtp-timeout [00:48:56 CET] <faLUCE> also --mms-timeout [00:49:40 CET] <faLUCE> --notify-timeout seems the "global" one [00:51:00 CET] <faLUCE> Dodutils: another option is to use a playlist with a "quit" element at the end, but it's more complex. try firstly if some timeout option does work [00:53:17 CET] <Dodutils> longhelp showed the ipv4 parameter but not the one you tell that are unrecoginzed [00:53:35 CET] <faLUCE> Dodutils: did you use "--advanced" ? [00:53:45 CET] <Dodutils> yep [00:53:51 CET] <faLUCE> which version of vlc ? [00:53:55 CET] <Dodutils> 3.0.4 [00:54:24 CET] <faLUCE> did you exec "vlc --longhelp --advanced | grep timeout" ? [00:54:52 CET] <faLUCE> (I use 3.0.4 as well, and I see that options) [00:54:55 CET] <Dodutils> sure 1 more parameter showed 4 instead of 3 [00:55:16 CET] <faLUCE> how did you install vlc ? [00:55:22 CET] <Dodutils> apt-get [00:55:26 CET] <Dodutils> vlc-bin [00:56:03 CET] <faLUCE> that's very strange, it's the same version that I use [00:56:17 CET] <faLUCE> vlc --version [00:56:18 CET] <faLUCE> VLC media player 3.0.4 Vetinari (revision 3.0.4-0-gf615db6332) [00:56:26 CET] <Dodutils> VLC media player 3.0.4 Vetinari (revision 3.0.4-0-gf615db6332) [00:56:35 CET] <faLUCE> exactly the same [00:57:19 CET] <faLUCE> Dodutils: ok, open the GUI, advanced options [00:57:50 CET] <Dodutils> have no GUI [00:58:11 CET] <faLUCE> ?? then something is broken in your installation of vlc [00:58:30 CET] <Dodutils> I mena I do not use any Linux GUI [00:58:33 CET] <Dodutils> mean [00:58:43 CET] <faLUCE> what distro? [00:58:52 CET] <Dodutils> WSL [00:59:03 CET] <faLUCE> I see, then you have some minimal vlc installation [00:59:38 CET] <faLUCE> then you have to figure how to install a full vlc [01:00:10 CET] <Dodutils> yep you gave me a lead with those timeout parameters [01:00:44 CET] <Dodutils> so then I do I wwrite direct-to-disk and also provide server to this stream ? [01:00:45 CET] <faLUCE> anyway, it's only a matter of a parameter [01:00:54 CET] <faLUCE> I did that some years ago and it worked [01:01:06 CET] <Dodutils> will recompile it full [01:01:22 CET] <faLUCE> after you figure the right param, you have to pipe a sout stream [01:01:45 CET] <faLUCE> (it will be the proxy" you said) [01:02:45 CET] <Dodutils> pipe the stream to a file ok but how to make it act as RTSP TCP source ? and ... how do both at same time ? [01:03:11 CET] <Dodutils> that was my firt issue [01:03:40 CET] <faLUCE> https://wiki.videolan.org/Documentation:Streaming_HowTo/Command_Line_Exampl… <---- look at "Multiple streaming" [01:04:06 CET] <faLUCE> it will create a new rtsp source [01:05:31 CET] <faLUCE> what was the other question Dodutils? [01:06:01 CET] <Dodutils> I see the examples but they make VLC retsream to other IP [01:06:34 CET] <faLUCE> Dodutils: just replace with localhost [01:06:42 CET] <faLUCE> nd it will act as a server [01:06:45 CET] <Dodutils> is it so simple ? :-) [01:06:50 CET] <faLUCE> yes, very simple [01:07:32 CET] <faLUCE> I don't even know why they put a specific address. It's meaningless for non-UDP [01:08:12 CET] <faLUCE> anyway, I used that tons of times in the past, and it works as server very easily [01:10:06 CET] <faLUCE> but which was the other question? [01:16:08 CET] <Dodutils> other question was about the timeout problem with ffmpeg but I also have another problem with segment naming %03d when I restart ffmpeg it recstart from -000 file [01:16:27 CET] <faLUCE> Dodutils: note that you have to use rtsp as sout, not rtp [01:16:43 CET] <Dodutils> I would like it to continue to name-count the file segments of the direct-to-disk streaming [01:17:05 CET] <faLUCE> [01:16] <Dodutils> other question was about the timeout problem with ffmpeg <--- for what do you use ffmpeg ? [01:17:33 CET] <Dodutils> yep rtsp but WSL version of vlc do not recognize --sout ... hell I will start a true Linux VM [01:18:11 CET] <faLUCE> [01:16] <Dodutils> other question was about the timeout problem with ffmpeg <--- for what do you use ffmpeg ? [01:18:16 CET] <Dodutils> for now ffmpeg is used for direct-to-disk record [01:18:38 CET] <faLUCE> you won't use ffmpeg anymore for that, because you will create two subpipes with vlc [01:19:12 CET] <faLUCE> the first subpipe will redirect your stream, the second one will write to file [01:19:22 CET] <Dodutils> yep that is great and will meet my requirements, will have to set good parameters for that to restarm with no re-encodding [01:19:26 CET] <faLUCE> so, they will depend both on the connection [01:19:28 CET] <Dodutils> re-encoding [01:19:45 CET] <faLUCE> it's not necessary to reencode [01:20:01 CET] <Dodutils> yep exactly if input stop bith output stop too no problem [01:20:19 CET] <Dodutils> I do not want to reencode as I want it to be low CPU [01:20:27 CET] <faLUCE> you don't have to [01:20:32 CET] <Dodutils> that is in fact the main goal of all of this [01:20:53 CET] <faLUCE> (I did these things since 10 years :-) ) [01:21:11 CET] <faLUCE> I don't understand your last problem [01:21:26 CET] <faLUCE> "but I also have another problem with segment naming %03d when I restart ffmpeg it recstart from -000 file" [01:22:30 CET] <Dodutils> yes you can name the files incremental way when you specify ffmpeg to do a segmented every 5 mins direct-to-disk file, by the way I also want to do it with vlc [01:23:07 CET] <faLUCE> Dodutils: do you want to create a new recording file every 5 mins ? [01:23:10 CET] <Dodutils> I do not want a huge H.264 file but only small ones, each one containing 5 mins video [01:23:17 CET] <Dodutils> yep [01:23:32 CET] <faLUCE> ok, then, you have two ways for doing that [01:23:37 CET] <Dodutils> with ffmpeg it is easy [01:25:28 CET] <Dodutils> ffmpeg -rtsp_transport tcp -i 'rtsp://login:password@192.168.1.138:554/ch01.264?ptype=tcp&dev=1' -c copy -map 0 -map -0:1:0 -map -0:1:1 -f segment -segment_time 300 -segment_list slist.txt -segment_format mp4 capture-%03d.mp4 [01:25:38 CET] <faLUCE> Dodutils: there are multiple ways for doing that [01:26:16 CET] <faLUCE> first of all, ask to vlc people if is there an embedded option for segmenting the output [01:26:23 CET] <faLUCE> (but I suspect there is not) [01:27:18 CET] <faLUCE> is there is not, then you could use a rc interface [01:27:54 CET] <Dodutils> I could kill/restart vlc every 5 mins [01:27:56 CET] <faLUCE> which means: you will have an instance of vlc , always active, which is controllable by rc commands [01:28:00 CET] <faLUCE> no, no [01:28:02 CET] <faLUCE> never kill [01:28:04 CET] <Dodutils> rc command [01:28:07 CET] <faLUCE> yes [01:28:23 CET] <faLUCE> it's an embedded interface that allows you to send commands to vlc [01:28:32 CET] <faLUCE> like record/stop record [01:28:53 CET] <faLUCE> so you will create a script that every 5 mins sends this command [01:29:05 CET] <faLUCE> look at "rc-interface" [01:29:17 CET] <Dodutils> --rc-host [01:29:26 CET] <faLUCE> yes, it's a server [01:29:33 CET] <Dodutils> ok got it, I will RTFM [01:29:40 CET] <faLUCE> you will set it to localhost with a port [01:29:51 CET] <faLUCE> and then you will send commands (with nc) to it [01:29:52 CET] <Dodutils> good lead tnx [01:30:19 CET] <faLUCE> but ask firstly to vlc people if they added an option for segmenting, meanwhile [01:30:23 CET] <faLUCE> maybe they did [01:30:27 CET] <Dodutils> oups ... 1.30am got to go bed [01:30:42 CET] <Dodutils> thanx for your help [01:30:47 CET] <Dodutils> and your time [01:31:02 CET] <faLUCE> yw [01:31:17 CET] <Dodutils> cya [01:31:19 CET] <Dodutils> quit [02:07:58 CET] <FlipFlops2001> Why is the value for "acompressor=threshold=[range 0.00097563-1]" expressed in FRACTIONS as opposed to DECIBELS (dB) like every other hardware and software compressor/limiters in the galaxy? -Asked by Me: Studio & Live Audio Engineer since 1975. [02:07:58 CET] <ph88> does anyone know a website where i can download a bunch of test videos ? [02:10:11 CET] <FlipFlops2001> ph88: Try https://www.matrox.com/video/en/products/monarch_hdx/testyourencoder/ [02:11:44 CET] <FlipFlops2001> ph88: Also see: https://www.demo-world.eu/2d-demo-trailers-hd/ [02:14:27 CET] <ph88> I was thinking more some videos specially crafted/selected to test encoders [02:14:42 CET] <ph88> otherwise i might just take some of my own videos if it's just any other video [02:21:15 CET] <FlipFlops2001> ph88: Does not the Matrox site fulfill your needs? After all the final folder is labeled "/testyourencoder/". Are you testing for both quality and filesize? [02:22:42 CET] <ph88> well it's just the same video in different sizes and kb/s right? [02:28:00 CET] <FlipFlops2001> ph88: Yes, but wouldn't you want to download the largest, most uncompressed file, re-encoded it and make a comparison. Sorry haven't found any "raw" video to download; like one that's Full HD (or better), 4:4:4, 10-bit and at least bt2020. Anybody know if it exists? [02:28:31 CET] <ph88> no worries, ill figure something out [02:31:04 CET] <tlacatlc6> ph88, something like this: https://media.xiph.org? [02:31:28 CET] <ph88> ah that looks great [02:31:30 CET] <ph88> thanks a lot [02:31:44 CET] <tlacatlc6> np [02:33:03 CET] <ph88> tlacatlc6, do you know which file i should download ? y4m ? [02:33:50 CET] <tlacatlc6> yeah [02:33:55 CET] <ph88> can i merge the audio and video into a container first ? [02:35:14 CET] <tlacatlc6> hmm, honestly i haven't done that as i only encode video. but maybe you can mux it to an mkv? [02:37:15 CET] <FlipFlops2001> ph88: MKVToolNix/MKVmerge: https://mkvtoolnix.download/windows/continuous/64-bit/ [02:38:01 CET] <FlipFlops2001> Gotta go: Watching some of my reencoded HEVC vids. Bye! [04:30:57 CET] <damdai> how do i report bugs for ffmpeg [05:37:00 CET] Last message repeated 1 time(s). [05:57:49 CET] <pink_mist> go to the ffmpeg.org website [05:57:55 CET] <pink_mist> click on the link "bug reports" [05:58:01 CET] <pink_mist> read the page [12:44:14 CET] <__gh0st> Is it good to preserve the GOP-structure of a video when transcoding it? For example I have a h.264 encoded video file and I want to downscale it and transcode it to h.264 again, if we retain the same GOP-structure of the input video file in the output(transcoded) video file, will we benefit from less quality loss? [12:44:31 CET] <JEEB> no [12:44:47 CET] <JEEB> generally you and your transcode have your requirements and features available [12:47:43 CET] <__gh0st> Can you, please, elaborate why exactly we won't benefit from any quality loss? [12:49:59 CET] <JEEB> ok, let's put it this way. if the original author had a requirement of having 2 frame GOPs. [12:50:13 CET] <JEEB> or he used an encoder without tweaking values that output something like that [12:50:49 CET] <JEEB> also GOPs generally don't mean that's a good (compression wise) place to put a RAP start [12:51:04 CET] <JEEB> I mean, they could - but you cannot expect that you can re-use the same spots [12:52:29 CET] <JEEB> and there isn't really anything to gain in general from trying to follow the same RAP/GOP structure [12:53:00 CET] <__gh0st> What is RAP? [12:53:39 CET] <JEEB> random access point [12:57:54 CET] <__gh0st> JEEB: Oh, okay. But what if for some reason we need to do multiple transcoding iterations to the same format(h.264 for example) -- in this case preserving the GOP-structure doesn't give us anything too? [12:59:00 CET] <JEEB> not really. generally I recommend utilizing lossless intermediates if you are going to iterate [13:03:10 CET] <BtbN> Every transcode has quality loss, unless encoding lossless. No matter if you match the original parameters or not. [13:03:22 CET] <DHE> there's only one time I use synchronized keyframes - adaptive bitrate protocols like DASH or HLS. even then it's less about copying the source GOP structure as it is having outputs with consistent GOP structures [13:05:29 CET] <JEEB> and even there those might be overused since I've only seen stuff like MS's PlayReady SDK for *iOS* (which nobody in their right mind should have to support) utterly fail at that stuff. also 2015 Tizen TVs had something funny but by now I've completely erased them from my memory [13:06:00 CET] <__gh0st> Huh, I thought if we had a h.264 encoded video with for example a GOP-structure like this: IBBBIBBBI..., and when we transcode it to something like this: IBBBBBBB... We would loss a lot more quality when transcoding than if we would have the GOP-structure the same as input. [13:06:49 CET] <damdai> Stream #0:0: Audio: dsd_lsbf_planar, 352800 Hz, stereo, fltp, 5644 kb/s : if ffplay can play this file, how come VLC cannot? [13:07:05 CET] <__gh0st> Because if we encode the I-frame as a B frame we would lose a lot more quality than if we would encode it as I-frame(obviously)? [13:07:10 CET] <DHE> unlike old codecs like mpeg4 (aka divx), h264 doesn't suffer degradation without keyframes. their only true use is so that a player can begin with no reference frames [13:07:29 CET] <JEEB> a lot of encoders raise the quantizer for non-I pictures, but at that point it's a case if you actually set your rate control right or not. and by using longer GOPs you will probably be able to compress it better :P [13:07:55 CET] <JEEB> in other words, if you're utilizing constant I frames to keep your bit rate high enough, you've simply not set your rate control right [13:08:38 CET] <JEEB> not to mention that if you set the same bit rate with bit rate based rate control, the encoder might have to raise the quantizer in those I frames anyways [13:08:58 CET] <JEEB> generally having shorter GOPs is just for applications being able to seek and scrub quicker :P [13:09:09 CET] <JEEB> there's no compression wise benefit [13:09:24 CET] <JEEB> and benefit for compression means that with the average bit rate you get better quality [13:11:06 CET] <__gh0st> And there is no quality benefit too as I understand.. [13:11:31 CET] <JEEB> *with the same average bit rate [13:11:32 CET] <DHE> quality and compression are the mutual tradeoff, with "cpu usage" available as a tweak as well [13:12:54 CET] <__gh0st> Are there cases where preserving the GOP-structure is justfied? [13:13:23 CET] <JEEB> this is really unrelated to the input, but if your output GOP requirements are exactly the same as the ones for your input [13:13:31 CET] <JEEB> but really, in that case you are not following the input GOP structure [13:13:35 CET] <DHE> if you're making multiple bitrates like I described, you'll need to make sure at least SOME keyframes are properly aligned. but a perfect match still isn't needed (depending) [13:13:36 CET] <JEEB> you are following your requirements [13:14:16 CET] <JEEB> (they just happen to match) [13:15:04 CET] <__gh0st> Okay, thank you very much with your answers! [13:17:01 CET] <damdai> Stream #0:0: Audio: dsd_lsbf_planar, 352800 Hz, stereo, fltp, 5644 kb/s : if ffplay can play this file, how come VLC cannot? [13:31:20 CET] <durandal_1707> damdai: not registered decoder for vlc [13:31:38 CET] <damdai> durandal_1707 i just tried with nightly and it works [13:31:51 CET] <damdai> nightly vlc 4.0 [13:32:04 CET] <damdai> somebody told me to do that [13:36:55 CET] <damdai> there are dsd_lsbf and dsd_msbf it stands for "least significant bit first" and "most significant bit first" : what is better [13:37:45 CET] <DHE> whatever is supported by the player [13:38:59 CET] <damdai> ffplays them both [14:41:09 CET] <pkunk> JEEB: Was it you I discussed with about parallel opening of input streams with ffmpeg cli ? [14:41:22 CET] <JEEB> probably :) [14:41:37 CET] <pkunk> I have it working @ https://github.com/chetan-prime/FFmpeg/tree/release/4.1 [14:42:31 CET] <pkunk> If it works fine for a few people then I could create a branch and then send a pull request after making the code safe for non-thread builds [14:44:43 CET] <JEEB> funky [14:46:37 CET] <faLUCE> hello all [14:47:49 CET] <jkhsjdhjs> hey [14:56:43 CET] <pkunk> JEEB: I have tested it on a 16 stream mosaic. Takes 6-7 seconds vs 3 minutes before [14:57:05 CET] <JEEB> which is about how long lavf attempts to probe [14:57:08 CET] <JEEB> by default [14:57:22 CET] <JEEB> I think 5 seconds is the general default, and MPEG-TS had a custom default of 7? [14:58:04 CET] <JEEB> I'll probably not be able to poke at it any time soon so I recommend you try and make a proper single change set for it, and prod #ffmpeg-devel with it [14:58:55 CET] <popara> Is there any way to delay the ffmpeg output? I want to have for example 2 minutes delay, so if i start the stream now, i get 2 minutes earlier of stream data, and continue normal. Save them in a buffer or something and then start streaming. [15:07:02 CET] <faLUCE> popara: it's not clear what you want [15:07:30 CET] <faLUCE> why do you want to save data into a buffer and which kind of buffer? [15:08:11 CET] <faLUCE> memory or file? [15:17:09 CET] <popara> faLUCE i have a stream ok, and i want to watch this stream but 2 minutes earlier from now [15:17:30 CET] <popara> and continue as live [15:17:42 CET] <faLUCE> popara: is the stream a file or a live stream? [15:17:47 CET] <popara> live stream [15:18:07 CET] <faLUCE> popara: then you remux it? [15:18:50 CET] <popara> yes [15:19:02 CET] <faLUCE> and do you want to save it into a file befor re-streaming? [15:19:52 CET] <faLUCE> I mean, what do you have to do with the buffer, other than re-streaming? [15:21:03 CET] <popara> ah basically if i do HLS streaming setting seg list size and seg time to be 2 minutes, it will work what i want. Anytime that i want to start the stream, i will get 2 minutes earlier [15:21:33 CET] <popara> it will consume a lot of disk space if i want -5 hours for example [15:21:33 CET] <popara> but maybe there is no other way [15:25:54 CET] <faLUCE> popara: you could pipe the output of ffmpeg to a named pipe [15:26:19 CET] <faLUCE> then you read from this pipe after 2 mins [15:36:03 CET] <kepstin> that's unlikely to actually work - the pipe buffer will fill up and ffmpeg will stall. [15:36:11 CET] <kepstin> which will probably break the input [15:36:47 CET] <faLUCE> kepstin: what if you set a pipe size ? [15:37:20 CET] <kepstin> then you're buffering based on size not time, and even then i think the max pipe size probably won't be big enough for 2 minutes of video [15:37:35 CET] <faLUCE> kepstin it's compressed video I suppose [15:37:50 CET] <faLUCE> but you use a size which is enough big [15:42:11 CET] <kepstin> on linux, the default max pipe size is only 1MB. You /can/ increase that with some config under /proc, but even so& For this use case, you'd probably be better off using HLS with the delete old segments config enable on a ramdisk (tmpfs). [15:42:59 CET] <faLUCE> kepstin: you can flush the pipe when it's full [15:43:17 CET] <faLUCE> then, read again [15:43:47 CET] <faLUCE> I don't see big problems [15:44:05 CET] <kepstin> that doesn't fit the requirement of having a continuous 2 minute buffer [15:44:58 CET] <kepstin> and needs custom tools besides - with hls you can do it with stock ffmpeg cli [15:50:16 CET] <faLUCE> kepstin: from what I see you can set the size for a specific pipe [15:51:07 CET] <faLUCE> kepstin: you have to increase also the max pipe size accordingly, under /proc, as you said [15:51:31 CET] <kepstin> size != time [15:51:50 CET] <kepstin> and it still has the issue where it there's no reader, the pipe blocks [15:51:58 CET] <kepstin> and if you flush the pipe, you lose the buffer [15:52:00 CET] <kepstin> so... [15:52:05 CET] <kepstin> doesn't work. [15:54:40 CET] <faLUCE> kepstin: I remember there are some circular buffers [15:55:03 CET] <kepstin> ffmpeg's hls output can be configured to operate as a circular buffer. [15:55:14 CET] <kepstin> (effectively) [15:55:36 CET] <faLUCE> kepstin: I mean circular buffers for linux [15:58:11 CET] <faLUCE> I would not reject this solution, otherewise he would be constrained to HLS [16:10:17 CET] <kepstin> well, if you want to find or write a non-blocking/asynchronous single writer multiple reader circular buffer, and either modify applications to support it or provide some sort of adapter, i'm not gonna stop you. [16:13:06 CET] <kepstin> in the mean time: hls (in a live streaming mode where old files get deleted) is an implementation of such a buffer that works fine and is already supported by players. [16:39:12 CET] <deltasquared> kmsgrab is proving to be difficult to get to play ball once again... [16:40:11 CET] <deltasquared> tried hwdownload on it's own with kmsgrab, complains not linearly mappable. VAAPI context derivation doesn't work any more either, different system (all AMD stuff) and I just get "unknown libva error". [16:41:23 CET] <jkqxz> Does hwmap work without derivation? There is still an annoying libva thing where it refuses to work as render on a master device when it doesn't have DRM master. [16:41:44 CET] <deltasquared> jkqxz: so just plain hwmap? let me try that [16:42:33 CET] <deltasquared> "A device reference is required to map to a hardware format." (one moment pasting log) [16:43:05 CET] <jkqxz> You need to provide a destination context. Something like -f kmsgrab -device /dev/dri/card0 -i - ... -init_hw_device vaapi=v:/dev/dri/renderD128 -filter_hw_device v -vf hwmap,... [16:43:33 CET] <deltasquared> whoah whoah how is this the first time I have heard about -init_hw_device and -filter_hw_device [16:43:44 CET] <deltasquared> (like seriously no pointers this is needed in the ffmpeg man pages?) [16:45:59 CET] <deltasquared> jkqxz: https://a.uguu.se/E8JCo52kI1XX_ffmpeg.log is what I tried previously (note the invocation after "record started") [16:46:06 CET] <deltasquared> warning, may contain escape codes. [16:46:17 CET] <JEEB> the hardware stuff is always a kind of a special snowflake :P [16:46:37 CET] <deltasquared> JEEB: what can I say, I didn't want x11's minor copying overhead at 1440p. :P [16:46:41 CET] <deltasquared> "minor" [16:46:57 CET] <deltasquared> also being able to record the console is a nice extra [16:47:07 CET] <JEEB> that's just kms, no? [16:47:19 CET] <JEEB> this has nothing to do with kms tbqh, the part where you're using vaapi [16:47:26 CET] <JEEB> and that's what I was commenting on [16:47:45 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#kmsgrab [16:47:45 CET] <deltasquared> JEEB: right... I was going off a bug on the tracker that suggested someone do this when they ran into mapping errors [16:48:08 CET] <JEEB> kmsgrab even has some example with dervice_device stuff [16:48:21 CET] <JEEB> deltasquared: so you got completely randomly into the world of hw encoding? wow [16:48:27 CET] <JEEB> good luck :P [16:49:04 CET] <deltasquared> JEEB: not even hardware, most hw encoders I've tried so far have been leaving something lacking. I'm just trying to grab frames with the least possible overhead possible given the data rates involved [16:49:43 CET] <jkqxz> "ffmpeg -y -f kmsgrab -i /dev/dri/card0 -init_hw_device vaapi:/dev/dri/renderD128 -filter_hw_device vaapi0 -vf hwmap,scale_vaapi=format=nv12 -c:v h264_vaapi out.mp4" works for me to do the mapping without DRM master. [16:50:15 CET] <deltasquared> jkqxz: actually it is being run as sudo there (sorry, my script didn't output that part) [16:50:29 CET] <deltasquared> I wanted to get it to work first, then see if I could drop privs :P [16:50:33 CET] <jkqxz> I'm not sure kmsgrab+hwdownload is going to gain much over x11grab. You still have the same copy, just at a different point. [16:51:03 CET] <jkqxz> Yeah, that was as root. The requirement for CAP_SYS_ADMIN (basically root) for kmsgrab is a hard one, it can't work at all without it. [16:51:37 CET] <deltasquared> hmm. I mean sure if I was using hardware encoding, I'd want to use kmsgrab if only because I could arrange it such that the frames didn't leave the GPU unencoded. [16:52:00 CET] <deltasquared> but for plain frames perhaps not worth the effort, as has been evidenced thus far >_> [16:54:43 CET] <deltasquared> honestly never realised you had to explicitly set up and declare hardware devices with a name then pass them to the filter graph like that [16:57:19 CET] <grosso> hi [16:57:49 CET] <jkqxz> You generally don't want it if you have a hardware decoder and stay in one API (though it does still work, those names can be passed to -hwaccel_device if you want multiple input streams on the same device), but it's required for filtering-only (i.e. OpenCL) and when you do mapping between APIs. [16:58:35 CET] <deltasquared> jkqxz: another question then, is it possible to ditch the format filter? my understanding is that ran in software no? [16:58:53 CET] <deltasquared> (I've had problems with it assuming wonky pixel formats in the past though...) [16:59:00 CET] <jkqxz> The one after hwdownload? [16:59:02 CET] <deltasquared> like gray8 or something. what even [16:59:03 CET] <deltasquared> yes [16:59:43 CET] <jkqxz> That's needed to hint the libavfilter negotiation into doing the right thing. It can't currently see into the properties of the hardware frames enough to do it automatically. [16:59:57 CET] <deltasquared> ah, I had thought it was something like that [17:00:08 CET] <jkqxz> (It doesn't actually do anything at all at runtime, just a setup hint to get the format right.) [17:00:16 CET] <deltasquared> ok fair enough [17:05:29 CET] <grosso> I have a problem when muxing a flv stream. When I call av_interleaved_write frame() and there is no internet connection, it hangs for about 15 minutes and interrupt_callback is never called. This happens only when dealing with rtmps stream (through librtmp I guess); with rtsp there is no problem at all [17:06:07 CET] <grosso> using ffmpeg v3.3.9 [17:10:11 CET] <grosso> librtmp seems to have a timeout for reading but not for writing [17:10:45 CET] <grosso> all timeout, rw_timeout, etc. settings have no effect [17:13:52 CET] <deltasquared> jkqxz: here's what I have thus far... https://a.uguu.se/VPY2r7woBOr1_ffmpeg.log [17:14:05 CET] <deltasquared> I do have two GPUs though. maybe I need to select the other one. [17:14:14 CET] <deltasquared> I don't know which way around the render nodes are :/ [17:14:32 CET] <deltasquared> ... nope, exact same error [17:16:27 CET] <deltasquared> I may just have to try my luck with x11grab at this rate and see what the cycle hit looks like. [17:16:45 CET] <deltasquared> I wouldn't mind but I have been able to get this to work before, with much swearing [17:17:10 CET] <deltasquared> on an i3-3100M laptop. iGPU of all things. capture worked flawlessly. [17:17:26 CET] <deltasquared> (i3-3100M CPU*) [17:17:47 CET] <deltasquared> apparently there is more swearing involved before I get it to work on this system too :) [17:22:22 CET] <deltasquared> ok, next daft question then... the ffmpeg-devices man page says you can use -video_size but it defaults to vga. so what video_size expression makes it record the entire screen area by default? (if any) [17:22:34 CET] <deltasquared> *"cif" doesn't appear to be it.) [17:23:34 CET] <deltasquared> you'd have thought the default would have been "everything" (but then again... I guess due to how x11 works, if you have multiple monitors that would not be the right thing) [17:25:37 CET] <deltasquared> ironically gdigrab (the windows one) can do this... [17:25:50 CET] <deltasquared> idk. maybe it'd require some communication with xrandr or such. [17:26:24 CET] <deltasquared> but I have no idea how to make it do that programmatically. (xrandr's output is not all that great for shell script use) [17:43:21 CET] <jkhsjdhjs> hey, i'm capturing an rtsp stream with ffmpeg. the stream has - according to the metadata - 25 fps. but ffmpeg is recording 15fps. is there any way to write 15fps to the metadata of the recorded file without reencoding it? [17:58:28 CET] <deltasquared> that's interesting. when using x11grab, my GPU fans are spinning up [17:58:37 CET] <deltasquared> is that the pixel format conversion being done I wonder [17:59:45 CET] <Foaly> i wouldn't expect the pixel format conversion to happen on the gpu. rather in the driver [18:00:00 CET] <deltasquared> Foaly: I'm definitely hearing the GPU fans spin up. [18:00:11 CET] <deltasquared> they're quite distinctive. and loud. >_> [18:00:40 CET] <deltasquared> I mean I am using the amdgpu ddx, maybe it's being smart and utilising the GPU to do whatever tiled/pixel format conversions [18:01:02 CET] <deltasquared> which is what I wanted to do with kmsgrab anyway. oh well :D [18:04:33 CET] <deltasquared> next question, do we have a list of pixel formats anywhere again... I was previously using bgr0 for ffvhuff, but it seems that no longer works and uses gbrp. [18:05:07 CET] <deltasquared> (as in, I get an incompatible pixel format warning.) [18:05:11 CET] <BtbN> x11grab is pretty inefficient [18:05:32 CET] <deltasquared> BtbN: yeah well, kmsgrab is not cooperating [18:05:44 CET] <deltasquared> we've been through a lto of that earlier [18:05:47 CET] <deltasquared> *lot [18:15:34 CET] <deltasquared> BtbN: for your curiosity if it should be the case, the current invocation: fmpeg -f kmsgrab -framerate 30 -i - -init_hw_device vaapi=v:/dev/dri/renderD128 -filter_hw_device v -vf hwmap,hwdownload,format=bgr0 -vcodec ffvhuff -pix_fmt bgr0 /fs/local/framegrab/huff.mkv [18:15:55 CET] <deltasquared> > [AVHWDeviceContext @ 0x55d7c9ad7f80] Failed to initialise VAAPI connection: -1 (unknown libva error). [18:16:11 CET] <deltasquared> if there's one thing that annoys me, it's "unknown errors" that aren't logged. [18:16:50 CET] <deltasquared> (at least in managed langs with exceptions you generally had no excuse for not providing semi-meaningful error messages.) [18:17:24 CET] <BtbN> Have you tried putting the hw_device options before -i? [18:17:40 CET] <deltasquared> no actually, I had not spotted that [18:18:11 CET] <deltasquared> ... alas same error [18:19:27 CET] <BtbN> You are using an Intel card though? [18:20:09 CET] <deltasquared> BtbN: negative. it's just that a certain bug report I came across when getting an error about not being able to map the DRM object suggested trying to use vaapi on AMD cards. let me see if I can find it again. [18:20:41 CET] <BtbN> Yeah, the whole VAAPI stuff is primarily tested on Intel, and only parts of it work on AMD. [18:20:45 CET] <deltasquared> https://trac.ffmpeg.org/ticket/7375 then someone on here suggested ditching the derive_device part. [18:20:55 CET] <deltasquared> if you know a way to make it work by vdpau, by all means... [18:21:05 CET] <deltasquared> (preferably without needing an x11 connection) [18:21:17 CET] <BtbN> vdpau has no meanf of doing anything like that [18:21:19 CET] <BtbN> *s [18:21:24 CET] <BtbN> It's a pure video decode API [18:21:30 CET] <BtbN> And it's half-dead [18:21:34 CET] <deltasquared> well shoot. how else am I supposed to get around the mapping issue then [18:21:49 CET] <deltasquared> if I just use a straight hwdownload, I get... one moment [18:21:56 CET] <BtbN> The AMD driver plain might not support doing that [18:23:03 CET] <deltasquared> :/ [18:23:08 CET] <jkqxz> You might be able ot diagnose "unknown libva error" by running it in strace and seeing what it tries to load. [18:23:19 CET] <jkqxz> Or building a debug libva and stepping through it in gdb. [18:23:40 CET] <deltasquared> oof, I'm getting fairly invested in this aren't I :) [18:23:43 CET] <deltasquared> [AVHWFramesContext @ 0x558a8fef3e40] Failed to map DRM object 4 to memory: 22. [18:23:43 CET] <deltasquared> [hwdownload @ 0x558a8ff03080] Failed to download frame: -22. [18:23:43 CET] <deltasquared> Error while filtering: Invalid argument [18:23:53 CET] <BtbN> Are you sure /dev/dri/renderD128 is correct? [18:24:00 CET] <deltasquared> BtbN: I have no idea to be quite honest [18:24:03 CET] <deltasquared> neither seem to work [18:24:08 CET] <deltasquared> (I have two render nodes) [18:24:25 CET] <deltasquared> this motherboard doesn't seem capable of disabling the integrated graphics >_> [18:25:33 CET] <deltasquared> however, I do think that card0 is correct, as the screen resolution is being detected. [18:27:45 CET] <deltasquared> BtbN: here's the log when I try to use hwdownload,format=bgr0: https://a.uguu.se/LDCDGZcXVKLA_stdin [18:27:58 CET] <deltasquared> ... err, that does not appear to have worked well [18:28:02 CET] <deltasquared> stupid mime types [18:29:25 CET] <jkqxz> That's inability to map the display memory on a discrete card to the CPU, I think. [18:29:37 CET] <deltasquared> jkqxz: I kinda guessed [18:29:57 CET] <deltasquared> the question seems to be, what can have it transferred to main memory without involving the CPU to copy data [18:30:16 CET] <deltasquared> I would have thought "download" implied it could do so, but apparently not. [18:30:26 CET] <deltasquared> then again how would it... you'd need DMA set up. [18:31:34 CET] <jkqxz> hwdownload for some APIs (like VDPAU or VAAPI) invokes a special copy to get the stuff into CPU memory. The KMS/DRM stuff is too generic to know anything about the hardware, so all it can do is try to memory map and copy. [18:32:47 CET] <deltasquared> so, linux doesn't have a means to do this in all cases? [18:33:09 CET] <deltasquared> if vaapi isn't universal (or maybe it's an ffmpeg issue? idek anymore) [18:34:29 CET] <deltasquared> I have tried other solutions before now like simplescreenrecorder. that does not appear to support all codecs that ffmpeg can. e.g. ffvhuff in my case. [18:34:51 CET] <deltasquared> it'd be neat if that did work; to my understanding the way that's implemented is fairly efficient, involving hooks into opengl rendering. [18:51:36 CET] <deltasquared> BtbN: actually, doing some experiments, x11grab isn't too bad [18:51:45 CET] <deltasquared> not much time spend in xorg for instance. 5% cpu at most. [18:52:47 CET] <deltasquared> if I save rawvideo for instance the workload becomes mostly kernel I/O overhead. [18:53:16 CET] <deltasquared> (side note, does ffmpeg have a more efficient way of writing loadsadata? mmap or O_DIRECT perhaps?) [21:45:59 CET] <jkhsjdhjs> hey, just reposting my question: i'm capturing an rtsp stream with ffmpeg. the stream has - according to the metadata - 25 fps. but ffmpeg is recording 15fps. is there any way to write 15fps to the metadata of the recorded file without reencoding it? [21:46:36 CET] <tmm1> what metadata? [21:48:43 CET] <jkhsjdhjs> sorry, i don't know that much of rtsp and videos in general. i can show you what ffmpeg says when it begins capturing [21:51:41 CET] <jkhsjdhjs> https://hastebin.com/uricefabic [21:53:06 CET] <jkhsjdhjs> in line 8 it says 25fps. but ffmpeg captures 15fps and writes 25fps in the metadata of the mp4 file [21:56:45 CET] <grosso> all timeout, rw_timeout, etc. settings make no effect [21:56:58 CET] <grosso> I have a problem when muxing a flv stream. When I call av_interleaved_write frame() and there is no internet connection, it hangs for about 15 minutes and interrupt_callback is never called. This happens only when dealing with rtmps stream (through librtmp I guess); with rtsp there is no problem at all [21:57:19 CET] <grosso> using ffmpeg v3.3.9 [21:57:28 CET] <grosso> librtmp seems to have a timeout for reading but not for writing [22:20:32 CET] <jkhsjdhjs> i think i just had to add -r 15 before -i [22:20:53 CET] <jkhsjdhjs> i'll see 40 minutes if it worked or not [22:33:39 CET] <ohnx> hi, i'm having some issues using the stop_silence option with the silenceremove filter on ffmpeg 4.0.2-2 [22:34:07 CET] <ohnx> I see the option on the documentation website here: https://ffmpeg.org/ffmpeg-filters.html#silencedetect but when I try to use it on my computer, I am told that "Option 'stop_silence' not found" [22:42:12 CET] <ohnx> ah never mind, I see now that the latest version of ffmpeg is 4.1.2 [22:49:45 CET] <faLUCE> jkhsjdhjs: something is wrong with your command. you should not add framerate [22:49:55 CET] <faLUCE> jkhsjdhjs: paste the ffmpeg command [23:36:09 CET] <remlap> Hi I am trying to build from the github and I get this error: make: *** [ffbuild/common.mak:60: libavfilter/af_sofalizer.o] Error 1 [23:37:25 CET] <faLUCE> remlap: paste a more detailed output int pastebin [23:37:31 CET] <remlap> ok [23:37:47 CET] <remlap> https://pastebin.com/sfuCnmAw [23:39:22 CET] <faLUCE> remlap: OS? [23:39:26 CET] <faLUCE> remlap: configure? [23:44:06 CET] <remlap> ubuntu 18.10 https://pastebin.com/9FF8YccK [23:46:30 CET] <faLUCE> remlap: sudo apt-get install libysofa-dev [23:46:35 CET] <faLUCE> remlap: sudo apt-get install libmysofa-dev [23:47:11 CET] <remlap> already got mate [23:47:18 CET] <furq> it would fail in configure if that was missing [23:47:34 CET] <faLUCE> furq: yes, but given it's git... [23:49:36 CET] <remlap> the error seems to date back to 8b53d13 which is ages ago but last time I was able to build successfully [23:50:18 CET] <remlap> I remember noticing all the changes to sofalizer and reverted back, but its been months and still seeing it when I went to build today [23:51:03 CET] <furq> oh [23:51:08 CET] <furq> apparently you need a newer libmysofa [23:51:10 CET] <faLUCE> remlap: I would check if mysofa_neighborhood_init_withstepdefine is inside the last release of sofa [23:51:13 CET] <faLUCE> exactly [23:51:41 CET] <furq> https://github.com/hoene/libmysofa/commit/ae6dbe79661ca698c7bf5a32506aa9061… [23:52:17 CET] <remlap> so the repositories version is causing the error? [23:52:29 CET] <faLUCE> there's not a check for the version of sofa [23:52:31 CET] <furq> if it's older than august 2018 then it doesn't have that function [23:52:45 CET] <furq> but yeah it might be worth filing a bug because configure should check that [23:52:45 CET] <faLUCE> but you can install the new version [23:53:15 CET] <remlap> okay ill build and see [23:58:30 CET] <remlap> think its gone through it and still building :) [23:58:38 CET] <remlap> thanes faLUCE furq [23:58:43 CET] <remlap> thanks [00:00:00 CET] --- Mon Mar 25 2019

1 0

ffmpeg-devel.log.20190323
by burek 24 Mar '19

24 Mar '19

[00:00:00 CET] --- Sat Mar 23 2019 [00:45:13 CET] <Matti-> i found a amazing program that scans mp3 files and tell which mp3 encoder was used. if this could happen with mp3, is it possible to have a program that does for AAC, and tells which AAC encoder used [00:45:29 CET] <Matti-> oops wrong channel [01:00:08 CET] <cone-219> ffmpeg 03James Almer 07n4.1.2:HEAD: Merge commit '0676de935b1e81bc5b5698fef3e7d48ff2ea77ff' [05:56:11 CET] <cone-682> ffmpeg 03Jun Zhao 07master:305025c8aede: lavfi/sidedata: add missed frame side data type [05:56:11 CET] <cone-682> ffmpeg 03Jun Zhao 07master:fba42b33b7f2: lavf/flvdec: fix typo in log message [08:04:26 CET] <cone-682> ffmpeg 03Steven Liu 07master:2cb29a5d8de0: avformat/avformat.h: update the comment from deprecated to new API [08:04:27 CET] <cone-682> ffmpeg 03hwrenx 07master:bf05f621d583: lavc/libdavs2: add davs2_flush [08:04:28 CET] <cone-682> ffmpeg 03hwrenx 07master:5252d594a155: lavc/libdavs2: fix frame dumping error description [12:55:24 CET] <BtbN> I feel like I have forgotten one or two nvidia related patches, but I can't find them on the ML anymore. [13:04:27 CET] <JEEB> was npp or cuda the thing we were trying to get rid of? [13:05:53 CET] <JEEB> since I see a cuda crop filter being posted on the ML [13:07:33 CET] <jkqxz> CUDA crop? Isn't that redundant, since you already have the cropping information on hardware frames? [13:08:07 CET] <jkqxz> Hmm. Apparently I never merged the generic crop filter. [13:15:34 CET] <jkqxz> That CUDA version seems wildly complicated. Why does it even copy? Aren't the CUDA data references just pointers anyway? [13:16:03 CET] <jkqxz> (Or meant to look like them, at least.) [13:16:19 CET] <nevcairiel> they are, and it really confused me when i saw it the first time, when I thought "why is someone doing pointer arithmetic on these opaque hardware pointers" [13:16:55 CET] <BtbN> Those opaque hardware pointers can be casted to actual pointers and they just work most of the time as well. [13:17:57 CET] <BtbN> Can you even do full crop, like top and left side, with just pointer arith? [13:17:58 CET] <nevcairiel> that then leaves the question, why bother with cropping if you can just increment pointers [13:18:08 CET] <nevcairiel> sure [13:18:08 CET] <BtbN> well, top obviously, but left side [13:18:24 CET] <nevcairiel> well in software you can [13:18:45 CET] <BtbN> I'm pretty sure that would mess up the strict alignment requirements CUDA has on the pointers. [13:18:51 CET] <nevcairiel> in software the o nly problem that comes up is that the reslulting pointers are no longer aligned [13:18:54 CET] <BtbN> So you could only crop in multiple of 256 or even 512 [13:19:09 CET] <nevcairiel> if hardware has similar annoyances, then you cant [13:19:22 CET] <BtbN> Alignment requirements on CUDA frames are super strict [13:19:48 CET] <BtbN> 256 byte aligned minimum, depending on GPU gen [13:19:56 CET] <jkqxz> Do NVENC or any other things support the AVFrame cropping fields? [13:20:27 CET] <BtbN> no [13:20:31 CET] <jkqxz> Let me just send the generic one again. It's from a year ago, but sitll works nicely for VAAPI at least. [13:20:49 CET] <jkqxz> Could scale_cuda support it easily? [13:20:50 CET] <BtbN> I don't remember nvenc having cropping parameters either. nvdec has [13:21:23 CET] <BtbN> Adding support for it to scale_cuda would require pretty much the same kind of code that filter adds. [13:21:27 CET] <nevcairiel> in a perfect world you would want to get rid of cropping parameters w hen transcoding [13:21:41 CET] <nevcairiel> because many players dont support top/left either [13:22:02 CET] <BtbN> I'm not aware of nvenc supporting cropping parameters either, as in, speciying an input rect [13:22:49 CET] <BtbN> It defines a NVENC_RECT type, but then proceeds to never use it [13:28:22 CET] <nevcairiel> in related topics, do they 16-series cards have the full turing video engine? I would assume so, right? [13:28:47 CET] <BtbN> I'd assume the same, but in lack of any Turing card, can't test it. [13:29:55 CET] <nevcairiel> well i have a 20 series, but that doesnt really allow me to extrapolate to the 16 series that I might want to plug into a media system [13:31:19 CET] <BtbN> If they were to release a 16 series card with 8GB RAM like a 1670, I'd probably get it. [13:33:17 CET] <nevcairiel> i dont think the 16-series is going to go upwards in performance, because it would seriously infringe on the 2060 then [13:46:35 CET] <BtbN> Will need to get a 2070 or 2080 then at some point [13:46:44 CET] <BtbN> My 1060 is already limiting me in some games [18:52:11 CET] <durandal_1707> BBB: now what about qpel? lets use (A+B+1)>>1 for 1/2pel and (6A+2B+1)>>3 for 1/4pel and (2A+6B+4)>>3 for 3/4pel, how to make 16 combinations from those? [18:52:55 CET] <durandal_1707> 0,0 is copy [19:02:49 CET] <kierank> See how h264 does it [19:08:16 CET] <durandal_1707> h264 is mess [19:28:16 CET] <iive> i thought that all MC already do that. I even remember that RV40 turned out to use the wrong interpolation function for one of the cases e.g. [3,3]/4 [19:33:03 CET] <BBB> wait, wait [19:33:15 CET] <BBB> the reason that h264 is the way it is, is because halfpel is special-cased [19:33:23 CET] <BBB> the idea in h264 is that qpel positions are derived from hpel [19:33:26 CET] <BBB> this is hell for decoders [19:33:47 CET] <BBB> but for encoders, it is supposedly better [19:34:02 CET] <BBB> that's why h264 is the way it is (in terms of dsp function pointer table design) [19:34:09 CET] <BBB> for a more generic system, you don't need that [19:34:24 CET] <BBB> just use a subpel position function argument x/y [19:34:31 CET] <BBB> and use that as multiplier for A [19:34:57 CET] <BBB> if mx is in range of [0..3], then the B coefficient is simply mx [19:35:39 CET] <BBB> so out=A+(((B-A)*mx+4)>>3) [19:35:40 CET] <BBB> IIRC [19:35:48 CET] <BBB> it's just standard bilinear [19:35:59 CET] <BBB> and then store that in temp, do the same for my vertical [19:36:00 CET] <BBB> etc. [19:36:05 CET] <BBB> durandal_1707: ^^ [19:55:47 CET] <durandal_1707> BBB: what about my? i have 16 combinations, 4Xx4Y [19:57:25 CET] <BBB> but you don't need 16 functions [19:57:30 CET] <BBB> just pass mx/my as function arguments [19:57:36 CET] <BBB> and do the function I just gave you per direction [19:57:39 CET] <BBB> it's simple bilinear [19:57:43 CET] <BBB> there's nothing complex about it [19:58:26 CET] <BBB> durandal_1707: if I'm not making sense, let me know, I can explain in some more detail if that helps [19:59:29 CET] <iive> some of the 16 combinations are repeats. [19:59:32 CET] <durandal_1707> so first 2 bits are x part of coded motion vector and rest is 2 bits for y part, that gives 0-15 values [20:00:25 CET] <durandal_1707> first 4 cases are pure horizontal? [20:04:15 CET] <durandal_1707> BBB: i do not understand how to do vertical - for which cases it is done? [20:05:10 CET] <BBB> so you have a motion vector right? [20:05:15 CET] <BBB> and the lowest 2 bits are fractional [20:05:22 CET] <BBB> that is, they are the subpixel position [20:05:29 CET] <BBB> of each (x, y) component [20:05:31 CET] <BBB> yes? [20:05:35 CET] <BBB> does that make sense so far? [20:06:06 CET] <BBB> let's call this set of 2x 2 bits "mx" and "my" [20:06:17 CET] <BBB> mx is the x mv subpixel component [20:06:24 CET] <BBB> my is the y mv subpixel component [20:06:26 CET] <BBB> ok? [20:06:31 CET] <durandal_1707> ok [20:06:46 CET] <BBB> ok, let's start with horizontal [20:06:52 CET] <BBB> you said, for mx=0, the function is A [20:07:02 CET] <BBB> for mx=1, it's (A*6+B*2+4)>>3 [20:07:10 CET] <BBB> for mx=2, it's (A+B+1)>>1 [20:07:27 CET] <BBB> for mx=3, it's (A*2+B*6+4)>>3 [20:07:28 CET] <BBB> ok? [20:07:34 CET] <durandal_1707> yes [20:08:02 CET] <BBB> I'm gonna rewrite that as (mx*B+(4-mx)*a+2)>>2 [20:08:18 CET] <BBB> which can also be written as A+(((B-A)*mx+2)>>2) [20:08:28 CET] <BBB> this is the standard bilinear equation [20:08:41 CET] <BBB> where A is src[x], and B is src[x+1] [20:08:44 CET] <BBB> that's the horizontal part [20:08:48 CET] <BBB> store it, do the same vertically [20:08:49 CET] <BBB> and done [20:09:26 CET] <BBB> it's just that vertically, you do A=src[x] and B=src[x+stride] [20:09:41 CET] <BBB> so do the hor loop wx(h+1) [20:09:45 CET] <BBB> and the verloop wxh times [20:11:11 CET] <durandal_1707> other cases from 8 to 15 are just repeat of those? [20:11:26 CET] <durandal_1707> 4-7 are vertical? [20:30:21 CET] <BBB> whatdo you mean 8 to 15 [20:30:26 CET] <BBB> you have4 mx positions and 4 my [20:30:34 CET] <BBB> so in h264 these are unrolles to unique functions [20:30:39 CET] <BBB> but for bilin you don't need that [20:30:48 CET] <BBB> so it's not 4x4 functions; it's just 1 function handling 2x4 mx/my pairs [20:34:19 CET] <durandal_1707> i need to map somehow those bits to something, so which of them are which .... [20:36:07 CET] <BBB> I can see that we have some sort of a mismatch of information here [20:36:29 CET] <BBB> I don't see what you don't understand and you can't see why I can't understand you :-p [20:36:35 CET] <BBB> but I don't know what you mean, sorry [20:36:48 CET] <BBB> can you show some code and tell me what is unclear? [20:42:18 CET] <durandal_1707> BBB: https://pastebin.com/Axn1TKLz [20:42:49 CET] <BBB> hehe [20:42:51 CET] <BBB> mx=mode&3 [20:42:54 CET] <BBB> my=mode>>2 [20:42:57 CET] <BBB> and then do what I did above [20:43:05 CET] <BBB> don't write it out using switches, that's terrible :) [20:43:08 CET] <BBB> it'll be way too long [20:49:17 CET] <durandal_1707> for which mx/my i pick vertical and v+h? [20:55:56 CET] <BBB> if mx != 0, there is horizontal subsampling [20:56:04 CET] <BBB> if my != 0, there is vertical subpixeling [20:56:07 CET] <BBB> not subsampling, sorry [23:42:43 CET] <cone-134> ffmpeg 03Carl Eugen Hoyos 07master:5fceac1cdb82: lavd/v4l2: Fix the type of the probe function. [00:00:00 CET] --- Sun Mar 24 2019

1 0

ffmpeg.log.20190323
by burek 24 Mar '19

24 Mar '19

[00:45:32 CET] <Matti-> i found a amazing program that scans mp3 files and tell which mp3 encoder was used. if this could happen with mp3, is it possible to have a program that does for AAC, and tells which AAC encoder used [00:46:00 CET] Last message repeated 1 time(s). [00:50:43 CET] <JEEB> some encoders leave visible metadata in the bit stream. if that is utilized it's possible to look into that. the problem of course is that there's no way to be sure if that thing is valid or not [00:51:24 CET] <JEEB> if it's actual hints by how an encoder encodes thing, and not random metadata [00:51:41 CET] <Matti-> jeeb would you like to know program name? [00:51:55 CET] <JEEB> then that might work better as long as those structures are well-noted to be specific to that encoder [00:52:30 CET] <JEEB> so far of the latter category I only know a single video encoder that has a known thing that you can spot it from even if metadata is cleared out :P [00:52:52 CET] <JEEB> but I do not know if there's an automated application to find those hints out [00:52:56 CET] <Matti-> jeeb it's not perfect but it can differenciate lame/bladeenc/fdk/gogo/xing [00:53:16 CET] <Matti-> i never heard of "gogo" [00:55:40 CET] <Matti-> jeeb have you heard of all of them here: lame/bladeenc/fdk/gogo/xing [01:00:27 CET] <faLUCE> JEEB: just checked that MPEGTS NEEDS a starting video keyframe for audio-video stream [01:04:13 CET] <BtbN> I don't see how that information is overly useful though? [01:04:35 CET] <Matti-> btbn what information [01:04:49 CET] <faLUCE> BtbN: it was a past discussion with JEEB [01:05:02 CET] <faLUCE> (just for updating him) [01:36:26 CET] <Matti-> what do you people think about PCM vs DSD ? and does ffmpeg support DSD? [01:56:46 CET] <buhman> Matti-: you mean PDM? [01:56:53 CET] <Matti-> no [01:57:02 CET] <Matti-> PCM and DSD [01:57:11 CET] <buhman> those aren't comparable things [01:57:15 CET] <Matti-> yes it is [01:57:46 CET] <Matti-> buhman i am guessing you don't know what they are [04:27:05 CET] <locsmif> Hi all. Trying to play an .m3u8 from local disk, i.e. ffmpeg -i C:\Temp\playlist.m3u8 -c copy -o output.mp4, but ffmpeg is giving me: [https @ 000000000053ed80] Protocol not on whitelist 'file,crypto'! c:\temp\playlist.m3u8: invalid argument - what am I doing wrong? [04:28:55 CET] <furq> locsmif: -protocol_whitelist file,tcp,https [04:34:09 CET] <locsmif> Now it's giving me a TLS error, but it works fine in VLC [04:34:29 CET] <furq> if it's another whitelist error then add tls to that string [04:35:23 CET] <furq> or just -protocol_whitelist ALL [04:35:34 CET] <locsmif> TLS is not an URI scheme though [04:36:07 CET] <furq> ? [04:36:40 CET] <locsmif> Ffmpeg is trying to tell me it doesn't like the TLS handshake with the server for some reason, right? (Besides, I just tried adding it to -protocol_whitelist anyways and as expected it failed) [04:36:59 CET] <furq> what's the actual error [04:39:21 CET] <locsmif> Creating security context failed (0x80090302) [04:39:46 CET] <locsmif> It works fine in VLC/Browsers, etc. [04:41:28 CET] <ossifrage> I thought I had finally fixed my bframe muxing problems (computing DTS) only to find that chrome is presenting the frames out of order, joy [04:41:34 CET] <locsmif> I think I should upgrade. [04:43:45 CET] <furq> locsmif: if upgrading doesn't work then -tls_verify 0 should work around it [04:43:49 CET] <furq> obviously that's not ideal [04:48:31 CET] <locsmif> ffmpeg now works after upgrade. Switch back to -i "https://..." for the moment as I wanted to get rid of that factor in the equation [04:53:00 CET] <locsmif> ffplay however doesn't wan to play the audio, because: SDL_OpenAudio (2 channels, 44100 Hz): WASAPI can't initialize audio client: CoInitialize has not been called., then: [04:53:25 CET] <locsmif> SDL_OpenAudio (1 channels, 44100 Hz): WASAPI can't initialize audio client: CoInitialize has not been called. === followed by: No more combinations to try, audio open failed [04:55:29 CET] <locsmif> But, okay, I used the nightly GIT build [04:55:58 CET] <locsmif> Seems to be covered here: https://trac.ffmpeg.org/ticket/6891 [05:54:47 CET] <friendofafriend> Hi there, I'm getting "Invalid UE golomb code" when I'm playing an MPEG-TS stream created by ffmpeg. Is there something I should add to my ffmpeg encoder's command line to fix it? [10:36:19 CET] <Janosch__> I have a question regarding the conversion between a 'gray8' input and e.g. a 'yuv420p' output. I've learned that the 'Y' component in the YUV420p format is supposedly an 8-bit grayscale value. However, when i convert an 8-bit grayscale image to yuv using either ffmpeg.exe or 'sws_scale' from libav, the color is changed, so the spectrum doesn't include very dark and very bright values. When i convert back from yuv420 to gray8 [10:36:19 CET] <Janosch__> (e.g. as PNG output) the colors are almost correct again, with every 4th color gray-value missing from the histogram. why is that? [11:53:02 CET] <__raven__> how to force a video pid in an flv container in cases the input rtmp is that bad that no video is recognized while probing? [11:54:40 CET] <BtbN> Pretty sure you don't. [11:54:45 CET] <BtbN> Increase the probe duration. [11:55:47 CET] <pkunk> Well, that was much easier than I though it would be [12:01:28 CET] <pkunk> As I discussed in the channel yesterday, I've modified the ffmpeg cli to support opening inputs in parallel [12:02:56 CET] <pkunk> It works very well with only one issue.. The inputs are now out of order at the filter level, so in my mosaic use case the overlays are now in random with 0:v having the frame from the 5th input instead [12:04:46 CET] <pkunk> Is there any function or OptionsContext struct field I can use to "request" a particular order for the streams probed in parallel [12:17:07 CET] <BtbN> You wrote that code, how would anyone here know? [15:18:52 CET] <kepstin> pkunk: you're gonna have to have a serialization step that collects all the asynchronously probed inputs in the order specified on the command line [15:20:59 CET] <kepstin> Janosch__ is gone, but their problem was that they were converting from full range gray8 to limited range yuv420p :/ [16:45:11 CET] <SnakesAndStuff> I'm pretty sure I need to convert a -vf into a -filter_complex to do what I want... I'm trying to put a black box over an area of a video as well as speed up the video.... [16:45:39 CET] <SnakesAndStuff> I want to use -vf "color=black:581x53 [over]; [in][over] overlay=75:69 [out]" and "setpts=0.05*PTS" at the same time.... How do I combine these filters? [16:48:56 CET] <furq> overlay=75:69,setpts=0.05*PTS [16:53:21 CET] <SnakesAndStuff> I think I was putting it in the wrong spot.... [16:59:15 CET] <locsmif> friendofafriend: still no response huh [16:59:23 CET] <locsmif> friendofafriend: I'd repost the question [17:12:20 CET] <jkhsjdhjs> hey, i'm recording an rtsp stream with ffmpeg. i'm segmenting it in files à one hour. the first file starts at 0:00:00. however, the following files don't start at 0:00:00, but at 1:00:00, 2:00:00 etc. the problem is that all segments end after one hour, thus many segments have a starting timecode that is higher than the end timecode, e.g. a file starts at 4:00:00 and ends at 1:00:00. is there a way to make [17:12:21 CET] <jkhsjdhjs> every segment start at 0:00:00? here's the full command i'm using to capture the stream: https://hastebin.com/ogaxiwequh.bash [17:20:23 CET] <locsmif> jkhsjdhjs: tried -reset_timestamps ? [17:20:36 CET] <jkhsjdhjs> nope, will do, thanks! [17:22:12 CET] <locsmif> It belongs after -f segment amongst your other -segment_time / -segment_atclocktime options. I'm not sure if it works but I should hope so. [17:23:43 CET] <jkhsjdhjs> nice, placed it after -segment_atclocktime [17:27:59 CET] <jkhsjdhjs> yep, that seems to work :D [17:30:29 CET] <jkhsjdhjs> do you perhaps know where i can find information on segmentation? i looked in man ffmpeg, but it contains the word segment just once. is there a seperate manpage for segmentation? [17:32:04 CET] <JEEB> the manpages are all separated into parts [17:32:06 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html [17:32:11 CET] <JEEB> this is a link to the full one [17:32:19 CET] <JEEB> the exact options depend on the module you're using [17:33:33 CET] <jkhsjdhjs> alright, thanks! [17:33:38 CET] <furq> jkhsjdhjs: https://www.ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_… [17:34:33 CET] <jkhsjdhjs> thank you too furq! [17:36:23 CET] <furq> reset_timestamps is listed in there as doing the exact thing you want so it should work [17:36:34 CET] <furq> i guess we'll find out in 44 minutes [17:38:24 CET] <locsmif> jkhsjdhjs: great =) [17:51:04 CET] <faLUCE> hello all [17:53:07 CET] <JEEB> faLUCE: so which part of H.222 says you have to start the mux from a RAP? [17:53:19 CET] <JEEB> (H.222 = MPEG-2 Systems, contains MPEG-PS and MPEG-TS) [17:53:33 CET] <JEEB> or is it the FFmpeg muxer specifically and not a format specification limitation? :P [17:53:40 CET] <faLUCE> JEEB: with RAP do you mean a video keyframe? [17:53:54 CET] <JEEB> random access point, keyframe is just one, rap promises that you can decode what comes after [17:53:59 CET] <JEEB> which is an important distinction [17:54:13 CET] <faLUCE> [17:53] <JEEB> or is it the FFmpeg muxer specifically and not a format specification limitation? :P <--- pheraps this one [17:54:39 CET] <JEEB> yea, because as far as I looked at MPEG-TS I don't think the spec says you can't start the mux with a non-RAP :P [17:55:24 CET] <faLUCE> JEEB: I told that because I had issues (-->warnings) in decoding a mpegts audio video starting with video non keyframes [17:55:26 CET] <JEEB> in H.264 a RAP is either an IDR NAL unit, or the open GOP random access SEI + normal intra NAL :P [17:55:28 CET] <DHE> considering mpegts is a streaming protocol, it sounds reasonable that it would allow it to happen that way, though from a muxer standpoint it sounds pretty stupid to do that... [17:55:42 CET] <JEEB> faLUCE: that's normal [17:55:49 CET] <JEEB> the decoder will warn you that it couldn't decode frames [17:56:01 CET] <JEEB> you just keep feeding the decoder until you get a RAP [17:56:07 CET] <JEEB> so yea, it's not a muxer limitation either then [17:56:33 CET] <JEEB> you will get the same warnings when you start decoding a live TV station :P [17:56:38 CET] <JEEB> until you get a RAP [17:56:40 CET] <faLUCE> but I think that warning is not proper for an audio/video demuxer. I mean, the red color let you think about an error [17:57:34 CET] <JEEB> yea, I think that's because it's hard to distinguish decoding errors before you have gotten your first RAP and after you have received your first RAP :P [17:57:44 CET] <kepstin> assuming the demuxer sets the keyframe flag appropriately, you should be able to just drop packets until you get a RAP and only then start decoding? [17:57:48 CET] <JEEB> so you can get errors in your logs until you get your first RAP, but that's 100% OK [17:57:51 CET] <JEEB> kepstin: yes [17:58:07 CET] <faLUCE> kepstin: but it's not mine demuxer, it's ffplay [17:58:25 CET] <faLUCE> JEEB: ^ [17:58:39 CET] <JEEB> sure, ffplay.c doesn't skip packets [17:58:53 CET] <faLUCE> then, that warning for mpegts in not proper [17:58:57 CET] <faLUCE> is [17:59:13 CET] <JEEB> yes, but now go around changing the messages to depend on whether you have already received your first RAP or not [17:59:19 CET] <JEEB> have fun trying to figure that out [17:59:30 CET] <JEEB> (from within the decoder) [17:59:50 CET] <JEEB> also you will only get warnings/errors until you get your RAP, then it stops :P [18:00:03 CET] <kepstin> you could patch ffplay to handle it better, but honestly who cares, it's just a demo player? [18:00:03 CET] <JEEB> also if you really want to minimize that stuff, just skip the darn packets in your own API client [18:00:27 CET] <JEEB> everything could be more perfect but is this really your main issue right now? [18:01:00 CET] <faLUCE> JEEB: I'm not deprecating ffplay, I just noted it could be misleading [18:01:19 CET] <JEEB> I don't even know what you mean with that, and quite honestly I don't care. [18:01:43 CET] <faLUCE> JEEB: I care, instead. Because when I see red color msgs I think about an error. [18:02:09 CET] <faLUCE> JEEB: I don't even know what you care, and quite honestly I don't care of what you care [18:02:16 CET] <JEEB> please read my message some lines upwards where I note how non-simple it is to add a global state into the decoder [18:02:29 CET] <JEEB> also many people utilize the functionality of starting to decode from non-RAP [18:02:46 CET] <faLUCE> JEEB: I never said it's or it would be easy. [18:02:58 CET] <JEEB> yes, now compare how much good you get out of it [18:03:01 CET] <JEEB> compared to the effort [18:03:23 CET] <JEEB> which is why I said "everything could be more perfect, but is this really your main issue right now?" [18:03:24 CET] <faLUCE> JEEB: again, I'm not saying that ffplay should be patched for that [18:03:34 CET] <kepstin> the individual pieces of ffmpeg are working correctly here - demuxer is returning packets from the start of the file, decoder is warning that it can't properly decode the first few packets sent into it. [18:03:40 CET] <faLUCE> so, this discussion is pointless [18:03:45 CET] <JEEB> thank you [18:04:38 CET] <faLUCE> I just said it's confusing. then, what should or should not patched is not my decision, of course. [18:05:12 CET] <faLUCE> and JEEB, read again: "[18:02] <faLUCE> JEEB: I don't even know what you care, and quite honestly I don't care of what you care" [18:19:45 CET] <dannysantos> Hi people. I'm trying to do `ffmpeg -f alsa -ac 2 -i hw:0,0 output.wav` on my Manjaro but I get "[alsa @ 0x55e9429f9e80] cannot open audio device hw:0,0 (No such file or directory)"... please help [18:21:20 CET] <faLUCE> dannysantos: what is hw:0,0 ? an usb mic ? [18:25:07 CET] <dannysantos> faLUCE, I don't know. my cat /proc/asound/cards gives me -> https://hastebin.com/egovelumuq [18:25:33 CET] <faLUCE> dannysantos: where are you recording audio? on a microphone, usb camera or what?? [18:26:10 CET] <faLUCE> internal mic? [18:26:25 CET] <dannysantos> right now I want to record the sound that I get from the speakers [18:26:33 CET] <dannysantos> faLUCE, [18:27:02 CET] <faLUCE> dannysantos: ok, but record with WHAT? the internal microphone? [18:27:09 CET] <faLUCE> an usb camera? an usb mic? [18:27:50 CET] <dannysantos> it is not the usb camera or usb headset microphone. I believe its the internal microphone then [18:28:05 CET] <faLUCE> dannysantos: try ffmpeg -f alsa -ac 2 -i default output.wav [18:28:16 CET] <dannysantos> ok [18:28:55 CET] <dannysantos> [alsa @ 0x564340037e80] cannot open audio device default (No such file or directory) default: Input/output error [18:29:22 CET] <dannysantos> faLUCE [18:30:50 CET] <c_14> dannysantos: check the output of arecord -L [18:31:33 CET] <dannysantos> faLUCE c_14, https://hastebin.com/ohesegefam [18:33:40 CET] <c_14> try using one of those devices (probably any of the sysdefault:CARD= devices), or because it appears you have pulse installed use the pulse input instead [18:33:51 CET] <dannysantos> I want to get the interface of the sound that I get on my speakers to use it on my icecast stream to my girlfriend [18:34:04 CET] <faLUCE> c_14: I think it's a jacl problem [18:34:07 CET] <faLUCE> jack [18:34:59 CET] <dannysantos> I dont have jack hardware, I only use usb [18:35:07 CET] <faLUCE> but you have jack installed [18:35:17 CET] <dannysantos> I have a usb camera and a usb headset that has a microphone [18:35:36 CET] <faLUCE> jack is an audio server [18:36:06 CET] <faLUCE> dannysantos: well, it's not a ffmpeg issue. You will have the same issue with skype, for example [18:36:11 CET] <dannysantos> alright, I'm really new at this and mostly ignorant at this. what is your suggestion? [18:36:45 CET] <faLUCE> dannysantos: wait, I start jack [18:36:45 CET] <dannysantos> faLUCE, skype works well on my PC. already had tried it in the past [18:36:50 CET] <c_14> So you don't want to record your mike, but rather the sound output of a program? [18:36:58 CET] <dannysantos> yes [18:37:22 CET] <dannysantos> the sound of the system in general [18:38:05 CET] <dannysantos> for example, I have firefox and listening to a youtube music video, I want to stream that to my girl, but dont know which interface to use [18:38:11 CET] <c_14> https://trac.ffmpeg.org/wiki/Capture/ALSA#Recordaudiofromanapplication [18:39:54 CET] <dannysantos> c_14, will try that [18:40:00 CET] <c_14> Or with pulse you could use the pulseaudio ui to create a monitor device for the audio output and record that with ffmpeg [18:44:17 CET] <faLUCE> well, dannysantos, [18:44:38 CET] <faLUCE> ffmpeg -f pulse -ac 2 -i default output.wav [18:45:52 CET] <faLUCE> see if it works [18:46:04 CET] <dannysantos> faLUCE, default: No such process [18:46:36 CET] <faLUCE> dannysantos: how did you write the command? [18:46:50 CET] <dannysantos> ffmpeg -f pulse -ac 2 -i default output.wav [18:48:06 CET] <dannysantos> c_14, I dont have a pulseaudio ui on my Manjaro Deepin. [18:48:27 CET] <faLUCE> dannysantos: install pavucontrol [18:48:40 CET] <dannysantos> ok [18:49:30 CET] <dannysantos> Im running the pavucontrol ui... [18:50:13 CET] <faLUCE> dannysantos: at the voice "input devices" which devices are listed ? [18:51:39 CET] <dannysantos> ok there are some, please wait [18:53:17 CET] <dannysantos> CM108 Audio Controller Mono Analogic | Webcam C270 Mono Analogic | Front Microphone (unplugged) | Analog Input [18:54:23 CET] <dannysantos> Im seeing "All except monitors" [18:54:43 CET] <dannysantos> should I change this? [18:56:41 CET] <faLUCE> dannysantos: basically, you have to follow that: [18:56:43 CET] <faLUCE> https://askubuntu.com/questions/682144/capturing-only-desktop-audio-with-ff… [18:56:56 CET] <faLUCE> (using pavucontrol and ffmpeg) [18:58:03 CET] <dannysantos> here is my pacucontrol screenshot -> https://ibb.co/dtdG0s7 [18:58:44 CET] <faLUCE> dannysantos: but you firstly said that you wanted to record from your mic, then you said you wanted to record from some other output [18:58:56 CET] <faLUCE> so, what do you want to record? [19:02:33 CET] <dannysantos> never said I want to record from my mic, i only said that I didnt want from my usb headset or usb camera so i believe it was the one suggestion left that you gave me: internal mic [19:02:54 CET] <faLUCE> in any case: 1) if you want to record from your mic: ffmpeg -f alsa -i pulse out.wav . 2) if you want to record the output of a program follow the link I pasted [19:03:21 CET] <dannysantos> I want to record the sound that I get on my speakers, not from my mics [19:03:40 CET] <dannysantos> I believe my system doesnt have pulseaudio [19:03:47 CET] <dannysantos> is that possible? [19:04:32 CET] <faLUCE> dannysantos: yes, it has. Then just follow the link I pasted and replace "ffmpeg -f pulse -i default output.wav" with "ffmpeg -f alsa -i pulse output.wav" [19:04:49 CET] <faLUCE> (depending on the ffmpeg version) [19:07:24 CET] <dannysantos> `ffmpeg -f pulse -i default output.wav` -> "default: no such process" | `ffmpeg -f alsa -i default output.wav` -> https://hastebin.com/uduyujidak.bash [19:07:35 CET] <dannysantos> faLUCE [19:10:34 CET] <faLUCE> dannysantos: is this the output of "ffmpeg -f alsa -i default output.wav" [19:10:45 CET] <dannysantos> yes faLUCE [19:11:13 CET] <faLUCE> dannysantos: [19:11:15 CET] <faLUCE> [19:04] <faLUCE> dannysantos: yes, it has. Then just follow the link I pasted and replace "ffmpeg -f pulse -i default output.wav" with "ffmpeg -f alsa -i pulse output.wav" [19:11:16 CET] <faLUCE> [19:04] <faLUCE> (depending on the ffmpeg version) [19:11:29 CET] <dannysantos> sorry [19:11:32 CET] <faLUCE> the right command should be: [19:11:39 CET] <faLUCE> "ffmpeg -f alsa -i pulse output.wav" [19:12:34 CET] <dannysantos> faLUCE, https://hastebin.com/apeninucub.bash [19:14:29 CET] <faLUCE> dannysantos: did you follow the sequence in the link? 1) open pavucontrol 2) start ffmpeg [19:15:31 CET] <dannysantos> I open pavucontrol, then when running ffmpeg I get a ffmpeg error crash, that I have shown you, so I cant proceed [19:16:40 CET] <dannysantos> on pavucontrol tab Record I get "no application is currently recording audio" message [19:16:59 CET] <faLUCE> it seems a permission problem, wait [19:17:03 CET] <dannysantos> and it is showing "Applications" [19:17:48 CET] <faLUCE> dannysantos: what if you run "sudo ffmpeg -f alsa -i pulse output.wav" ? [19:18:18 CET] <dannysantos> it seems to be working [19:18:23 CET] <dannysantos> with sudo [19:18:42 CET] <faLUCE> ok, please confirm that all works and I tell you how to fix permanently [19:22:46 CET] <dannysantos> ok faLUCE, following the askubuntu.com link I got it working ;) [19:22:59 CET] <faLUCE> ok, now: [19:23:53 CET] <faLUCE> "cat /etc/group | grep audio" [19:24:09 CET] <faLUCE> paste the output [19:24:21 CET] <dannysantos> audio:x:92:fernando [19:24:27 CET] <dannysantos> my current user is daniel [19:24:37 CET] <dannysantos> there is only fernando there [19:24:50 CET] <faLUCE> sudo gpasswd -a daniel audio [19:25:06 CET] <dannysantos> alright [19:25:18 CET] <dannysantos> is it everything? [19:25:24 CET] <faLUCE> logout and login again and see if it works without sudo [19:25:31 CET] <dannysantos> ok [19:28:52 CET] Last message repeated 1 time(s). [19:28:52 CET] <dannysantos> I have issues faLUCE [19:28:56 CET] <dannysantos> this is my error [19:29:32 CET] <dannysantos> https://hastebin.com/yopaqoqiki.bash [19:29:45 CET] <faLUCE> dannysantos: sudo gpasswd -a pulse audio [19:30:08 CET] <faLUCE> then paste the output of "cat /etc/group | grep audio" [19:30:21 CET] <dannysantos> "the user pulse does not exist" [19:30:32 CET] <faLUCE> paste the output of "cat /etc/group | grep audio" [19:31:08 CET] <dannysantos> audio:x:92:fernando,daniel [19:31:23 CET] <dannysantos> `whoami` -> daniel [19:31:40 CET] <dannysantos> should I reboot just to be sure? [19:32:25 CET] <faLUCE> dannysantos: "cat /etc/group | grep pulse" [19:32:42 CET] <dannysantos> there is no output [19:33:19 CET] <faLUCE> then something is broken with your installation. What if you login as "fernando" ? [19:33:40 CET] <dannysantos> that is my dad account [19:33:49 CET] <FlipFlops2001> Why is the "acompressor" threshold parameter expressed in DECIMALS rather than DECIBELS(dB) like every other hardware or software compressor/limiter in the world? [19:34:01 CET] <dannysantos> whould I su as fernando on the command line and test it? [19:34:12 CET] <faLUCE> dannysantos: yes [19:34:36 CET] <faLUCE> but, in any case, it should grep the pulse user [19:34:44 CET] <faLUCE> wait [19:35:31 CET] <dannysantos> ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused [19:35:31 CET] <dannysantos> [alsa @ 0x55b2f950ee40] cannot open audio device pulse (Connection refused) [19:35:31 CET] <dannysantos> pulse: Input/output error [19:35:43 CET] <faLUCE> dannysantos: ok: "adduser daniel pulse" [19:36:06 CET] <faLUCE> then "adduser daniel pulse-access" [19:36:17 CET] <dannysantos> what will that command do? [19:36:23 CET] <dannysantos> create a pulse user? [19:36:45 CET] <faLUCE> no, they will add daniel to the group "pulse" [19:36:51 CET] <dannysantos> ok [19:36:52 CET] <faLUCE> and to the group "pulse-access" [19:36:57 CET] <dannysantos> ok [19:37:24 CET] <dannysantos> but I dont have a pulse group right now [19:37:27 CET] <faLUCE> then logout/login [19:39:06 CET] <dannysantos> cat /etc/group | grep -i pulse -> no output [19:39:15 CET] <faLUCE> that's pretty weird... we could create this group but it should have been already created with your OS [19:39:35 CET] <faLUCE> what is your distro? [19:39:45 CET] <dannysantos> I believe I will use sudo on ffmpeg [19:39:53 CET] <faLUCE> no, don't mess things with sudo [19:40:02 CET] <faLUCE> what is your distro? [19:40:14 CET] <dannysantos> Manjaro Deepin x86_64 [19:41:33 CET] <dannysantos> so, you believe the right action is to create the pulse group and add daniel user to that group [19:41:48 CET] <dannysantos> ? [19:42:04 CET] <faLUCE> no, I don't believe that. it should already be created with the installation of your OS/software [19:42:20 CET] <dannysantos> faLUCE, ok [19:45:19 CET] <faLUCE> dannysantos: let's try by addind the groups. If it won't work, we will remove them: [19:45:23 CET] <faLUCE> groupadd -g 58 pulse [19:45:37 CET] <faLUCE> groupadd -g 59 pulse-access [19:46:06 CET] <faLUCE> usermod -a -G audio pulse [19:46:31 CET] <dannysantos> the user pulse doesnt exist [19:46:51 CET] <dannysantos> maybe daniel? [19:47:15 CET] <faLUCE> useradd -c "Pulseaudio User" -d /var/run/pulse -g pulse -s /bin/false -u 58 pulse [19:47:52 CET] <dannysantos> ok, now it works the last command [19:48:11 CET] <dannysantos> the usermod command [19:48:20 CET] <faLUCE> (then repeat ok, logout/login, then grep "cat /etc/group | grep pulse" [19:50:14 CET] <dannysantos> audio:x:92:fernando,daniel,pulse [19:50:14 CET] <dannysantos> pulse:x:58: [19:50:14 CET] <dannysantos> pulse-access:x:59: [19:50:25 CET] <faLUCE> ok, try the ffmpeg command [19:51:42 CET] <dannysantos> error [19:51:45 CET] <dannysantos> https://hastebin.com/qamumahoru.bash [19:52:46 CET] <faLUCE> dannysantos: does it still work with sudo ? [19:52:51 CET] <dannysantos> faLUCE, maybe daniel should be on pulse group instead of audio? [19:53:05 CET] <faLUCE> dannysantos: no... [19:53:21 CET] <dannysantos> yes, it doesnt give error with sudo [19:53:25 CET] <dannysantos> faLUCE, [19:54:08 CET] <faLUCE> dannysantos: how did you install the audio? [19:54:19 CET] <faLUCE> stuff? [19:54:34 CET] <dannysantos> I havent messed with any audio, just installed the distro [19:54:49 CET] <dannysantos> and am using what it came with [19:55:22 CET] <dannysantos> maybe on pavucontrol some interface maybe blocked [19:55:25 CET] <dannysantos> no? [19:55:46 CET] <faLUCE> dannysantos: it seems a bug of the distro [19:55:50 CET] <faLUCE> wait [19:56:45 CET] <dannysantos> I mean locked [19:57:23 CET] <faLUCE> dannysantos: did you install your distro for some real time audio stuff? [19:58:33 CET] <dannysantos> no [19:58:39 CET] <dannysantos> faLUCE, [20:00:58 CET] <faLUCE> dannysantos: then use sudo meanwhile, and send a bug/missing feature report to your distro [20:01:42 CET] <friendofafriend> Hello everyone, I'm getting "Invalid UE golomb code" when playing an MPEG-TS stream created by ffmpeg. Is there something I should add to my ffmpeg encoder's command line to fix it? [20:02:36 CET] <dannysantos> hmmm.... bugs.manjaro.org stop existing and I dont know what to write in this bug report... [20:02:51 CET] <dannysantos> if I use the manjaro forum [20:03:44 CET] <faLUCE> dannysantos: then use a better distro :-) [20:04:15 CET] <dannysantos> loool [20:04:20 CET] <dannysantos> ok [20:04:44 CET] <dannysantos> I'm happy with it right now faLUCE . Thanks man for all your help [20:05:22 CET] <faLUCE> dannysantos: yw [20:05:24 CET] <faLUCE> ;-) [20:05:29 CET] <dannysantos> :D [20:31:14 CET] <dannysantos> faLUCE, everything is working but my interface sound volume is too low. do you know a way to increase it? [20:31:51 CET] <dannysantos> i'm not using ffmpeg now, i'm using ices to create an icecast stream... [20:33:30 CET] <dannysantos> maybe some hack to increase the pulse interface volume... [20:35:20 CET] <faLUCE> dannysantos: you have the volume control il pavucontrol [20:35:40 CET] <dannysantos> yes, it still is too low. i have it on max [20:36:31 CET] <faLUCE> dannysantos: see also the volumes by executing "alsamixer" [20:38:25 CET] <dannysantos> faLUCE, the capture is on max [20:38:35 CET] <tdr> use alsamixer then press f6 to get the right card/device [20:38:39 CET] <dannysantos> of pulseaudio.... need more [20:39:00 CET] <tdr> pulse will still be very quiet is the lower-level alsa is turned down [20:40:26 CET] <dannysantos> ok, which card should increase? loopback? [20:40:54 CET] <tdr> it depends what your options are. check each of them [20:41:10 CET] <tdr> probably isn't loopback, it would be your actual hard/device that you're getting input from [20:41:22 CET] <tdr> s/hard/card [20:42:18 CET] <dannysantos> there are so many that im afraid of messing with this [20:42:36 CET] <tdr> you mean in the card list when you run alsamixer and press f6 ? [20:42:39 CET] <dannysantos> there are some usb ones, i know that those arent [20:42:55 CET] <tdr> what kind of device is it you're using for input? [20:43:58 CET] <dannysantos> im not using microphones, im using software apps for the input Im outputing sound that came from my pc programs [20:45:21 CET] <tdr> ok so it would either be output channels (do the programs sound super quiet when you're not capturing?) or the levels for the input channels if you are using loopback or similar. [20:45:39 CET] <tdr> there's 1000 ways to do sound on linux, so its hard to say "it's right there" for sure [20:46:00 CET] <tdr> (just alsa, pulse on alsa, oss, jack ... so many ways to mix layers) [20:46:45 CET] <alexpigment> hey guys, it's been a long time since i've been around, but i have a question that hopefully someone knows the answer to [20:47:11 CET] <alexpigment> i've got a video from a DVD source that I believe came from a VHS source but the field order got messed up in the process [20:47:18 CET] <alexpigment> so the interlacing lines are jumping up and down [20:47:29 CET] <alexpigment> anyone have any idea how to fix this type of issue? [20:47:42 CET] <dannysantos> tdr, the program sound on my pc are not super quiet, only on my icecast stream [20:48:21 CET] <dannysantos> on my iceast stream im using "pulse" as a input device [20:48:24 CET] <tdr> dannysantos, ok so if it set up some loopback type virtual devices, check the levels on that/them [20:50:24 CET] <dannysantos> tdr, on pavucontrol im using the "monitor of cm108 audio controller digital stereo" [20:50:47 CET] <dannysantos> but on alsamixer I cant find that card/device [20:57:37 CET] <dannysantos> tdr, on alsamixer I should be looking for the capture section? [20:58:13 CET] <tdr> it could be "capture" volumes down, sure [20:58:31 CET] <tdr> it could be just pcm channels on some device it setup, i dont know the internals of how your software cofigures thing [21:04:56 CET] <dannysantos> on pavucontrol i have "ALSA plug-in [ices]" . Can it be this plugin fault? [21:05:10 CET] <dannysantos> tdr [21:06:06 CET] <tdr> that makes me think it's setting up some "virtual" channels and should have their own volume controls in pulse and alsa when you look inside alsamixer [21:07:56 CET] <dannysantos> i dont seem to be finding that virtual channels. im searching on the "select sound card" [21:08:06 CET] <dannysantos> in alsamixer [21:11:06 CET] <dannysantos> the only one that I'm finding that is not the usual is Loopback and maybe that is because I have modprobe snd-aloop pcm_substreams=1 following other tutorial [21:12:22 CET] <Matti-> " legacy WAVE file has format type 1 but bits-per-sample=24" i get this warning: what is "format type 1" mean [21:19:29 CET] <dannysantos> ok I got it tdr [21:20:10 CET] <dannysantos> thank you for the patience, I had to increase the master and decrease my headset audio output [21:29:07 CET] <tdr> nice, glad its working, good job [21:39:44 CET] <Matti-> what would sound better to human ears? 24bit 48khz wav file or 16 bit 96khz wav file? [21:46:18 CET] <another> define better [21:47:13 CET] <Matti-> another closer to true analog sound [21:48:45 CET] <another> chances are you can't hear a difference [21:54:30 CET] <alexpigment> a lot of things are in 24bit 48khz in the professional world [21:54:51 CET] <alexpigment> but that's really just because there's more headroom for mixing [21:55:03 CET] <Matti-> alexxpigment i am sure professionals use 24bit 96khz [21:55:08 CET] <alexpigment> of course [21:55:14 CET] <alexpigment> but they also use 24/48 [21:55:21 CET] <alexpigment> no one uses 16/96 in the professional world [21:55:40 CET] <Matti-> why would they record in 24/48 if they can record in 24/96 [21:55:49 CET] <alexpigment> at any rate, 24/48 probably also sounds better too, although it would be difficult to hear the difference [21:56:03 CET] <alexpigment> Matti - don't ask me. i see it in professional contexts [21:56:21 CET] <alexpigment> but i would *guess* that it's because certain hardware doesn't do 24/96 [21:58:00 CET] <alexpigment> could also be that broadcast/video mastering will ultimately be 48khz anyway so there's no need to waste the extra bits [21:58:27 CET] <alexpigment> for purely audio - there's a lot of people that argue it's better to record at 44.1 or 88.2 rather than 48 or 96 [21:58:41 CET] <Matti-> alexpigment really? i never heard of that [21:58:46 CET] <Matti-> why do they say that [21:58:52 CET] <alexpigment> yeah, it goes back to CD production [21:59:07 CET] <alexpigment> 88.2 > 44.1 is much cleaner than 96 > 44.1 [21:59:20 CET] <Matti-> alex i see; that makes sense [21:59:33 CET] <another> if you can hear the resampler, get a better resampler [21:59:50 CET] <alexpigment> right, but resampling at non-integer values is always imperfect, technically speaking [22:00:00 CET] <alexpigment> better to know your final medium and choose accordingly [22:01:07 CET] <Matti-> 88.2 > 44.1 would be cleaner, that makes total sense [22:01:17 CET] <alexpigment> i'll be the first to admit though that this is all academic cork-sniffing stuff. a lot of stuff is bounced from 24/96 to 16/44.1 and it sounds great [22:02:05 CET] <alexpigment> the bit depth is really just for editing though. 24-bit is better than 16-bit, but if you're never going to change the volume of the track after recording, it doesn't matter [22:02:11 CET] <Matti-> not sure why dvd-video started using 48khz [22:02:24 CET] <alexpigment> i feel like i knew at some point, but i can't recall anymore [22:02:39 CET] <another> you sniff corks? ^^ [22:04:31 CET] <another> afaik 48kHz is the recommended sampling rate when you do video [22:04:33 CET] <alexpigment> haha. no, i'm not a cork sniffer. there are some quality things i care about (proper interlacing/deinterlacing, maintaining original frame rates, keeping high bitrates, etc) but i consider myself to have pretty discerning ears and I have no problem with a 320kbps MP3, for example [22:04:46 CET] <another> i think aes recommended that [22:04:57 CET] <alexpigment> right, 48khz for video unless you're doing some sort of blu-ray audio thing [22:05:26 CET] <alexpigment> specialized blu-ray audio to be clear. 48khz is still the normal standard there [22:08:47 CET] <another> alexpigment: no wine for you then ;) [22:08:52 CET] <alexpigment> haha [22:09:11 CET] <alexpigment> i'm a beer guy anyway. my wife is the wine drinker ;) [22:12:11 CET] <dingwat> fwiw 24/48k (rather than 24/96k) is better when bandwidth is an issue. I work with systems that transport huge channel counts over standard layer 3 networking layers, and doubling the bandwidth would cripple the channel count needlessly [22:13:48 CET] <dingwat> also 48k is a lot nicer relative to 44.1k from a filter design perspective, it's a lot harder to design a well-behaved filter that that's flat out to 20k and then drops 60 or 80dB at 22.05kHz versus 24kHz [22:13:51 CET] <dingwat> just my two cents [22:15:18 CET] <alexpigment> dingwat: for the original context, Matti was asking about using 24/48 vs 16/96 [22:15:35 CET] <dingwat> I'd prefer 24/48k over 16/96k, 48k is plenty enough sample rate unless you're timestretching heavily, whereas the extra dynamic range of 24 vs 16 is significant and comes in handy in a lot of contexts [22:15:41 CET] <alexpigment> i don't anyone who uses 16/96 in a pro context [22:16:07 CET] <dingwat> I don't either. 16 bit converters aren't too common these days [22:16:24 CET] <dingwat> the audiophile folks are pushing 32bit converters, in fact... [22:16:35 CET] <dingwat> and the converter manufacturers, I guess.. [22:16:54 CET] <Matti-> then why does dsd uses 1bit 2.8mhz ? which suppose to sound better than pcm 24bit192khz [22:16:55 CET] <alexpigment> yeah, even basic software like audacity defaults to 32-bit (as well as audition, which i use). a lot of data, but no reason not to use it [22:17:07 CET] <alexpigment> dsd is a weird beast [22:17:14 CET] <alexpigment> SACD i assume you're talking about [22:17:17 CET] <dingwat> AKMs latest chipsets do have very impressive performance, but you have to have very good pres and the rest of your signal chain has to be bombproof for it to matter [22:17:22 CET] <Matti-> alexpigment yes [22:17:33 CET] <alexpigment> it doesn't relate to PCM at all, and i have no idea why it sounds as good as it does [22:17:36 CET] <dingwat> Matti-: you can't really compare DSD to PCM directly, they're different beasts [22:17:51 CET] <Matti-> dsd use massive mhz sampling rate [22:17:59 CET] <Matti-> but only 1 bit [22:18:13 CET] <dingwat> DSD is essentially the direct output of a delta sigma converter, and is great when you are driving a delta sigma converter [22:19:05 CET] <alexpigment> on the other hand, modern PCM formats at high bit depths and sample rates should sound better [22:19:17 CET] <alexpigment> i think SACD is only advantageous compared to CD redbook audio [22:19:46 CET] <alexpigment> but it is a standardized format with an established catalog, so that's an inherent benefit [22:19:50 CET] <dingwat> Matti-: for further reading, start with the wiki page on delta sigma: https://en.wikipedia.org/wiki/Delta-sigma_modulation [22:23:07 CET] <dingwat> it's also worth pointing out that modern DS converters are operating at very high orders with extreme noise shaping, and most of the reading material focuses on first or second order DS architectures, which is fine, but in general, "real" audio converter design is a sort of black magic and there's not a lot of folks out there who can design the stuff that AKM/Cirrus/others are making [22:23:29 CET] <dingwat> It's not difficult to build your own first, second, maybe third order DS [22:24:01 CET] <dingwat> But at the higher orders it's very difficult to get them to be stable and well-behaved (or so I'm told, I'm not good enough at math to mess with that stuff) [22:25:57 CET] Action: alexpigment understands nothing about what dingwat just said, but appreciates the high level of knowledge [22:26:01 CET] <alexpigment> ;) [22:26:14 CET] <Matti-> alexpigment me neither [22:26:37 CET] <dingwat> Sorry, I'm an audio nerd and this shit is cool :) [22:27:01 CET] <Matti-> dingwat do you think dsd is superior to pcm [22:29:50 CET] <dingwat> No, I don't think either one is superior. In general, PCM is a more versatile format, but DSD (more generally, pulse-density) is an attempt to eliminate certain parts of the signal chain, with inconclusive results [22:30:28 CET] <alexpigment> i agree about the inconclusive results :) [22:31:13 CET] <dingwat> Matti-: IIRC, 24/48k PCM theoretically has more DR than DSD, and it's also much more widely supported, so IMO PCM should be used unless there's a very specific reason not to [22:31:33 CET] <alexpigment> having said that, if you were debating on releasing a "definitive" version of something, i'd do blu-ray audio rather than SACD [22:31:48 CET] <Matti-> dingwat DSD much much higher sample rate [22:31:54 CET] <Matti-> dsd has* [22:32:12 CET] <alexpigment> a lot of that sampling rate is wasted on making up for the 1-bit depth though [22:32:22 CET] <dingwat> yes but it's not the same "kind" of sample rate [22:32:34 CET] <dingwat> You cannot compare them directly [22:32:39 CET] <Matti-> what does bluray-audio use? PCM? [22:32:47 CET] <alexpigment> several formats, PCM is one of them [22:32:53 CET] <alexpigment> you can do 24/192 even [22:32:53 CET] <Matti-> what is other format [22:32:59 CET] <alexpigment> although 24/92 is more common [22:33:17 CET] <alexpigment> DTSMA, DolbyHD [22:33:24 CET] <alexpigment> or whatever dolby calls their "lossless" format [22:33:29 CET] <alexpigment> truehd [22:33:54 CET] <alexpigment> of course there's regular dolby digital, but that's not really worth mentioning for high quality audio [22:33:56 CET] <Matti-> then what is the difference between bvluray audio vs dvd-audio? [22:34:01 CET] <Matti-> sounds very similar [22:34:12 CET] <alexpigment> sampling rates mostly i think [22:34:20 CET] <alexpigment> but you run out of space quickly at 24/96 [22:36:26 CET] <alexpigment> i was trying to do the bitrate calculation - i think 5.1 24/96 PCM is like 13mbps or so (i may have done that wrong) but it also reminded me that DVDs have a bitrate maximum [22:36:53 CET] <alexpigment> 10mbps total stream bitrate, but realistically much lower for universal compatibility [22:36:58 CET] <alexpigment> 10.8 [22:42:02 CET] <another> wiki says max 9,8 MBit/s [22:42:07 CET] <Matti-> "FLAC supports linear PCM samples with a resolution between 4 and 32 bits per sample. FLAC does not support floating point samples" what is "floating point samples" mean [22:42:31 CET] <another> 5.1 24/96 should come to ~13,8 MBit/s [22:42:47 CET] <alexpigment> floating point usually means decimal vs integer [22:43:29 CET] <Matti-> but what does that mean in real life [22:44:15 CET] <alexpigment> for normal humans? nothing that i'm aware of [22:44:25 CET] <alexpigment> dingwat probably has an answer though [22:45:35 CET] <alexpigment> another: that's for video. there's a total data rate though that is 10.8 i think [22:45:39 CET] <alexpigment> or maybe 10.08? [22:45:47 CET] <alexpigment> i don't remember. it's been a while since i worked with dvd in a professional context [22:56:37 CET] <another> i think i got that number from the dvd-audio article [22:57:34 CET] <Matti-> how comes ffmpeg -i 24bit.flac 24bit.wav converts 24bit.flac to 24bit.wav fine but flac binary does not [22:57:57 CET] <Matti-> how is ffmpeg does better than flac binary [22:59:04 CET] <alexpigment> another: ah. i suppose it's probably maximum bitrate for a single stream then (video or audio) [23:05:22 CET] <Matti-> how comes ffmpeg.exe -i 24bit.flac 24bit.wav converts 24bit.flac to 24bit.wav fine but flac.exe -d 24bit.flac 24bit.wav does NOT [23:11:08 CET] <Matti-> sorry i made a mistake [23:11:26 CET] <Matti-> ffmpeg.exe -i 24bit.flac 24bit.wav is not working it's creating 16bit.wav [23:12:44 CET] <Matti-> ffmpeg.exe -i 24bit.flac 24bit.wav is not working it's creating 16bit.wav: why is that? [23:15:28 CET] <another> because you didn't specify the format. therefore ffmpeg guesses it from the extension of the output file [23:15:40 CET] <Matti-> another how do i do that [23:16:37 CET] <alexpigment> -sample_fmt s24 i would assume [23:17:15 CET] <alexpigment> although i would *think* it should pass it along [23:17:18 CET] <another> -c:a pcm_s24le [23:17:37 CET] <alexpigment> makes sense. if you're outputting pcm_s16le, it's going to force 16-bit [23:17:59 CET] <Matti-> what is the difference between -c:a pcm_s24le and -sample_fmt s24 then [23:18:06 CET] <alexpigment> does ffmpeg assume s16le for .wav? [23:18:45 CET] <another> yes [23:18:47 CET] <alexpigment> Matti: well, that's the generic way to force a bit depth, but with PCM in ffmpeg, you generally have to use the correct c:v to get the right bit depth anyway [23:18:59 CET] <another> alexpigment: ffmpeg -h muxer=wav [23:19:05 CET] <alexpigment> ah [23:19:23 CET] <Matti-> what does ffmpeg -h muxer=wav do? [23:19:28 CET] <alexpigment> i kinda just assumed it would auto choose a little endian format based on the input depth [23:20:04 CET] <alexpigment> -h is help and you're getting the specific help related to the wav muxer [23:20:23 CET] <Matti-> oh okay [23:20:37 CET] <alexpigment> it says "default audio codec: pcm_s16le" [23:21:00 CET] <Matti-> -c:a pcm_s24le works, but why isn't ffmpeg smart enough to know that flac is 24bit and use -c:a pcm_s24le automatically [23:21:32 CET] <another> i guess because wav is not a codec but a container [23:21:42 CET] <alexpigment> well, you're converting, so it's gotta choose a codec, and it seems like it chooses that exact codec by default when the output extension is wav [23:22:19 CET] <Matti-> another ffmpeg is smart enough to detect that flac is using 88.2 khz and convert automatically to 88.2 khz wav [23:22:38 CET] <alexpigment> the sampling rate is separate from the codec fwiw [23:23:23 CET] <alexpigment> although i do hear what you're saying. it seems like it could detect all of the above and select the appropriate codec [23:23:35 CET] <alexpigment> equivalent codec, i mean [23:35:14 CET] <Dodutils> hi guys, I am trying to use ffmpeg as some kind of double RTSP flow redirector (-c copy mode no re-encoding), I need ffmpeg to read an RTSP H.264 source and do direct-to-disk recording (easy part) but I also want it to be used as some kinf of proxy for this same stream to be used by some other RTSP client (not FFMPEG to restream but act as server) but FFServer is dead project so anyone have some idea about how to do it ? [23:38:34 CET] <Dodutils> the final goal of this is to have some "lossless" video quality (original quality from RTSP source) but also let something like OpenCV read same stream to detect movements and write timestamps to a text file so I can then cut the saved file stream to keep only parts with movements, but I do not want camera to provide two streams at same time (bandwidth and camera ressources limitation). [23:45:37 CET] <Dodutils> OpenCV is an example but could be a videosurveillance software too this is why I need this direct-to-disk + "proxy/server" approach [23:47:22 CET] <faLUCE> Dodutils: then you want a rtsp server on demand, right? [23:48:00 CET] <tdr> Dodutils, "motion" software already does what you're suggestion [23:48:05 CET] <Dodutils> and second question is there a way to monitor that ffmpeg is not frozen ? I mean the camera tream may go wrong and ffmpeg will stop to read the stream but will not quit, my idea is to check for the direct-to-disk file last touch and if no touch for a few seconds then kill/restart ffmpeg. [23:49:01 CET] <tdr> Dodutils, https://motion-project.github.io [23:49:24 CET] <Dodutils> motion can do direct-to-disk ? [23:49:32 CET] <faLUCE> Dodutils: too many things, let's proceed by order [23:49:54 CET] <faLUCE> first of all, do you want a rtsp server on deman, right? [23:50:19 CET] <Dodutils> @faLUCE : not exactly I want ffmpeg to read one stream, save it realtime direct-to-disk but also act as RTSP server source for this same stream [23:50:41 CET] <faLUCE> Dodutils: yes, so it will do a rtsp server on demand [23:50:44 CET] <faLUCE> with multiple clients [23:50:51 CET] <Dodutils> one client only [23:54:24 CET] <faLUCE> Dodutils: wait [23:57:34 CET] <Dodutils> @tdr : you are correct I read "Passthrough recording from many IP cameras" never checked that feature but I do not want to use Motion as motion detection software unless Motion can also "cut" the passthrough file to keep only movement parts (with 2 second pre-buffer) [23:58:40 CET] <faLUCE> it seems that the rtsp support is in a bad state, can you guys confirm that? [00:00:00 CET] --- Sun Mar 24 2019

1 0

ffmpeg-devel.log.20190322
by burek 23 Mar '19

23 Mar '19

[00:02:10 CET] <atomnuker> you ought to know [00:04:28 CET] <jdarnley_obs> heh maybe [00:15:11 CET] <BtbN> thardin, mjpeg also fulfills that codec requirement. [00:15:43 CET] <BtbN> Though it's not nearly as fast to de and encode [02:40:44 CET] <cone-659> ffmpeg 03Ruiling Song 07master:61cb505d18b8: lavu/opencl: replace va_ext.h with standard name [02:40:44 CET] <cone-659> ffmpeg 03Ruiling Song 07master:d0f3798b4e7f: lavfi/colorspace: move some functions to common file [02:40:44 CET] <cone-659> ffmpeg 03Ruiling Song 07master:2593122a167d: lavfi/opencl: add ff_opencl_print_const_matrix_3x3() [02:40:44 CET] <cone-659> ffmpeg 03Ruiling Song 07master:8b951cd4752c: lavfi/tonemap_opencl: reuse color matrix calculation from colorspace.c [02:40:44 CET] <cone-659> ffmpeg 03Ruiling Song 07master:b073fb9eeae8: lavfi/colorspace_common: add ifdef check to be more compatible. [03:39:35 CET] <rcombs> JEEB: if it's guaranteed to be UCS-2 (and not UTF-16) then it's literally just "encode UTF-8 from 16-bit code points", which lavu has code for (PUT_UTF8) [03:40:18 CET] <rcombs> JEEB: if it might be UTF-16 (which isn't a bad idea to assume regardless), it's ever-so-slightly complex in that you have to decode surrogate pairs, but lavu also has code for that (GET_UTF16) [08:04:55 CET] <JEEB> rcombs: cool. that might make it workable purely within lavu [09:01:17 CET] <thardin> BtbN: it does? I thought jpeg's transforms weren't bitexact [09:07:58 CET] <atomnuker> they aren't unless you use some different approximation close enough to decoder mjpeg coeffs with some errors but be reversible [09:08:28 CET] <atomnuker> though everyone agrees that the libjpeg integer ones are the de-facto standard [09:09:04 CET] <atomnuker> there's a real standard, some ieee document, but it only tells you how to test transforms and gives you an approximate error to keep below [09:14:43 CET] <thardin> yeah I've seen those [09:15:11 CET] <thardin> h264's transform is fully specified, an intra-only thing based on it without intra prediction would work [11:01:24 CET] <vel0city> durandal_1707: why does the decode function (decode_frame) get called twice when converting a tif to some other format? [11:02:06 CET] <atomnuker> once to probe it to check the resolution and pixel format and once to actually decode it [11:02:13 CET] <atomnuker> if it had a parser it wouldn't need to [11:09:18 CET] <vel0city> atomnuker: I see [11:20:04 CET] <kierank> atomnuker: thardin: https://guru.multimedia.cx/the-mpeg124-and-h26123-idct/ [11:31:51 CET] <thardin> yeah I remember that post [12:31:06 CET] <cone-925> ffmpeg 03Carl Eugen Hoyos 07master:e704070f61e8: lavd/v4l2-common: Add an entry for Z16. [13:34:30 CET] <gnafu> So, who's gonna update https://trac.ffmpeg.org/ticket/7589? [13:34:36 CET] <gnafu> ;-) [14:37:36 CET] <durandal_1707> how is interpolation in MC working? [14:54:46 CET] <atomnuker> mayjick [15:00:31 CET] <kurosu> or something involving a cardinal sin [15:01:48 CET] <durandal_1707> motion compenstation [15:06:22 CET] <BBB> most interpolation filters are either variations of bilinear, or something sinc-like [15:07:03 CET] <BBB> sinc: sin(x)/x where x is distance from center [15:07:09 CET] <BBB> and then some approximation thereof [15:07:20 CET] <durandal_1707> i have certain codec, which apparently does not need edge emulation for MC [15:07:27 CET] <BBB> and then in vp9/av1 they merge the standard sinc with a sharpening or blurring filter [15:07:42 CET] <BBB> some codecs use mirror edging [15:07:53 CET] <durandal_1707> does avcodec allows padding frame data pointers? [15:08:32 CET] <BBB> yes [15:09:19 CET] <durandal_1707> i allocate bigger frame, so i do not need to emulate edges [15:15:28 CET] <kierank> durandal_1707: means you can't render codec into fixed buffer size for hw or something though [15:15:30 CET] <kierank> edge emu is useful [15:40:26 CET] <BBB> edge emu is mostly for decoders though [15:40:40 CET] <BBB> for encoders, I think actually drawing the edge is faster [15:43:18 CET] <BradleyS> anyone interested in / working on EIA-608 CC? [15:44:24 CET] <durandal_1707> (A - 4*B + 19*C - 4*D + E + 1) >> 5 [15:44:42 CET] <durandal_1707> this is MC for Y [15:44:57 CET] <kierank> BradleyS: what doesn't work [15:45:08 CET] <BradleyS> https://github.com/HandBrake/HandBrake/issues/1300 [15:45:27 CET] <BradleyS> multiple reports from multiple users stating latest ffmpeg release doesn't recognize it [15:45:33 CET] <BradleyS> thus handbrake does not recognize it [15:46:29 CET] <durandal_1707> BBB: give above formula, how I can derive horizontal/vertical/both MC? [15:46:32 CET] <kierank> ah it's the track based variant [15:46:57 CET] <BBB> durandal_1707: encoder or decoder? [15:47:03 CET] <durandal_1707> decoder [15:47:19 CET] <xxxmaker> https://pastebin.com/rB5cUs3K [15:47:48 CET] <xxxmaker> both mediainfo/ffprobe doesn't recognize the subtitle track [15:48:16 CET] <nevcairiel> then it d oesnt exist [15:48:38 CET] <xxxmaker> nevcairiel it does, VLC can play it: but only vlc player can play this video with subtitle [15:48:58 CET] <xxxmaker> EIA-608 c608 [15:49:12 CET] <nevcairiel> matroska doesnt have codec tags for that, i dont think [15:49:26 CET] <xxxmaker> nevcairiel same issue with .mp4 [15:49:48 CET] <nevcairiel> its never the same issue with distinct container formats [15:50:06 CET] <nevcairiel> in any case bug reports go to #ffmpeg [15:50:16 CET] <nevcairiel> or better, trac :) [15:50:44 CET] <BradleyS> i sent him here, blame me ;) [15:51:23 CET] <nevcairiel> also the ffmpeg info dump from that handbrake ticket shows it finding the track just fine [15:51:27 CET] <nevcairiel> Stream #0:2(eng): Subtitle: c608 [15:51:56 CET] <BradleyS> xxxmaker: upload a safe for work sample somewhere and open an issue on ffmpeg's trac i guess [15:51:57 CET] <xxxmaker> nevcairiel but mine doesn't [15:52:04 CET] <BradleyS> the handbrake issue was created by others [15:52:26 CET] <nevcairiel> if the CC data is actually inside the video stream, then ffmpeg will never show it as a seperate track [15:52:30 CET] <xxxmaker> https://i.imgur.com/xjFiVDS.jpg [15:52:31 CET] <nevcairiel> its up to the API user to extract i t [15:53:25 CET] <xxxmaker> nevcairiel is that "inside" or "outside" [15:54:01 CET] <xxxmaker> https://i.imgur.com/xjFiVDS.jpg this from vlc player [15:54:10 CET] <vel0city> durandal_1707: pushed a patch for multipage, whenever you get the chance [15:54:39 CET] <nevcairiel> i have no points of reference to interpret its output, so its impossible to say. [15:54:44 CET] <nevcairiel> provide a sample file. [15:55:03 CET] <xxxmaker> what is the command to cut this file to 1 minute [15:55:37 CET] <nevcairiel> cutting will re-write the headers, so quite possibly influence the behavior [15:55:41 CET] <BradleyS> nevcairiel: sorry if i pinged you on github, forgot to remove the @ [15:56:18 CET] <xxxmaker> nevcairiel but it might not; let me try at least [15:56:40 CET] <nevcairiel> I dont actually know how Handbrake uses ffmpeg, if you use the ffmpeg CLI tool itself, it also has a feature to extract the CC data into a stream, but its a bit complicated to use [15:56:52 CET] <nevcairiel> but if you u se avcodec/avformat, you need to make code for that [15:57:14 CET] <BradleyS> it's api-based [15:57:54 CET] <nevcairiel> the main problem there being that the CC data is only available after decoding, not through demuxing [15:58:09 CET] <nevcairiel> someone wanted to make a bitstream filter to extract it without decoding iirc, but that never got anywhere [15:59:21 CET] <xxxmaker> nevcairiel but how do i tell if it's "inside" or "outside" [16:00:08 CET] <BradleyS> i think the fact that in your case it's not identified as a separate track indicates it's inside the video track [16:00:35 CET] <BradleyS> i pinged one of our developers regarding this, so maybe he'll have an idea [16:00:48 CET] <xxxmaker> how does VLC able to show it as separate track? doesn't vlc use ffmpeg? [16:00:49 CET] <BradleyS> but it sounds like we have to decode some or all of the video track to identify its presence [16:01:17 CET] <vel0city> durandal_1707: I made some multipage tiffs for testing, do ask if you want them [16:02:03 CET] <nevcairiel> CC data is super annoying, because it breaks the typical data flow we use for everything else [16:02:36 CET] <nevcairiel> lazy muricans couldnt develop a proper subtitle format [16:03:34 CET] <BradleyS> we get fat, too [16:04:04 CET] <durandal_1707> vel0city: why you added uint16 type to opt? that is completely useless [16:04:21 CET] <nevcairiel> I wouldnt be surprised if CC was still in ATSC 3.0. Everything else they change (and m ake terrible in the process), but I already see it, CC remains =p [16:04:36 CET] <kierank> it's in the law, there's nothing they can do [16:04:45 CET] <kierank> literally a copy of the spec [16:04:49 CET] <durandal_1707> vel0city: please use just int [16:04:50 CET] <vel0city> durandal_1707: I noticed the min/max limits later. Figured I'd leave it in since I had already done it... [16:04:58 CET] <nevcairiel> the law is so technical that it says you have to provide subtitles in this particularly crappy format? [16:04:59 CET] <vel0city> And no need to be hostile [16:05:02 CET] <xxxmaker> nevcairiel : this is very minor issue that i know how to get around it: but ffmpeg doesn't support S_TEXT/WEBVTT [16:05:17 CET] <durandal_1707> vel0city: please no code bloating [16:07:25 CET] <atomnuker> just saw the twitch ad insertion talk at demuxed [16:07:55 CET] <atomnuker> so if they delay each segment to fill the hole the ad might have left what happens with each next ad? [16:08:02 CET] <funman> nevcairiel: don't think so but it has to work on existing TVs [16:08:21 CET] <nevcairiel> funman: as if atsc 3.0 will w ork on those without extra hardware [16:08:35 CET] <nevcairiel> those boxes could overlay subs or whatever [16:08:37 CET] <kierank> nevcairiel: the signals will need to be transcoded back to atsc20 for years [16:08:41 CET] <kierank> for hotels and hospitals etc [16:08:50 CET] <kierank> so need to have cc [16:09:00 CET] <atomnuker> (also they're very clever, ads have pts/dts of 0 but since twitch's timestamps are bad no client can use the pts to detect an ad) [16:09:02 CET] <BtbN> "if (intnum == 1 && d == (float)UINT16_MAX) {" what [16:09:21 CET] <BtbN> why would ffmpeg need a AV_OPT_TYPE_UINT16 in the first place [16:09:40 CET] <funman> https://www.ecfr.gov/cgi-bin/text-idx?SID=72eb5a624e8dc043293819a5663dff41&… [16:10:15 CET] <nevcairiel> so basically, CC will never go away [16:10:20 CET] <nevcairiel> never ever [16:10:51 CET] <JEEB> I was surprised that even advertisements had captions in the US [16:11:22 CET] <nevcairiel> those are the most important to have captioned [16:11:26 CET] <xxxmaker> nevcairiel okay i created a 1 minute sample and it worked [16:11:26 CET] <nevcairiel> need to sell the things [16:11:48 CET] <xxxmaker> do you accept dcc? [16:11:53 CET] <nevcairiel> no. [16:11:59 CET] <xxxmaker> then where can i upload [16:12:13 CET] <nevcairiel> host it somewhere publicly so more then one person can look at it [16:12:24 CET] <xxxmaker> where can i do that? [16:17:51 CET] <xxxmaker> http://www.filedropper.com/video-with-subtitle-and-cc-problem [16:20:49 CET] <xxxmaker> nevcairiel are you able to download? [16:26:46 CET] <nevcairiel> the video stream definitely contains CC data [16:29:59 CET] <xxxmaker> nevcairiel and how do/did you determine that? [16:35:24 CET] <nevcairiel> i looked at ffprobe, which has fancy info like side_data_type=ATSC A53 Part 4 Closed Captions [16:36:14 CET] <xxxmaker> i see [16:36:31 CET] <xxxmaker> how does vlc make this work if vlc uses ffmpeg [16:37:05 CET] <nevcairiel> ffmpeg has all the tools for that, this is entirely up to handbrake to support it [16:37:52 CET] <xxxmaker> BradleyS said ffmpeg doesn't support this [16:38:03 CET] <nevcairiel> he was wrong :) [16:38:22 CET] <nevcairiel> its just complicated because CC is an annoying format [16:38:33 CET] <xxxmaker> how how do i play this file with ffplay and make the subtitle appear [16:38:42 CET] <nevcairiel> no clue [16:38:46 CET] <nevcairiel> ffplay is a bit dumb itself [16:38:59 CET] <xxxmaker> lol, then you can't say ffmpeg support this [16:39:08 CET] <nevcairiel> of course i can [16:39:14 CET] <nevcairiel> handbrake doesnt want to play the video, does it [16:39:58 CET] <xxxmaker> video is fine: just subtitle part is not working [16:43:26 CET] <JEEB> I'm pretty sure I've recently explained to just you why ffmpeg.c et al don't handle this right, but the FFmpeg libraries do [16:43:34 CET] <JEEB> as a proof you can see how mpv does it with FFmpeg :P [16:44:00 CET] <nevcairiel> it also doesnt help that lavfi doesnt really do subtitles [16:44:07 CET] <nevcairiel> so i cant exactly make a graph for ffplay to overlay them [16:46:30 CET] <nevcairiel> didnt ubitux want to get back on lavfi subtitles sometime ago [16:47:28 CET] <xxxmaker> jeeb no idea what you just said: are you talking about the cc/subtitle issue? [16:47:39 CET] <JEEB> yes [16:47:46 CET] <xxxmaker> i see [16:47:46 CET] <BradleyS> i've been wrong before [16:47:51 CET] <nevcairiel> in any case, the ffmpeg libraries have all the tools required to handle CC data [16:47:57 CET] <nevcairiel> its sitll annoying and maybe we could do more [16:48:02 CET] <nevcairiel> but anyone that wants to support it can [16:48:10 CET] <xxxmaker> nevcairiel but if ffplay cannot play then you can't prove that it does [16:48:21 CET] <nevcairiel> i dont have to prove anything, to you or anyone [16:48:40 CET] <BradleyS> xxxmaker: i think you've got your answer, ball's back in handbrake's court [16:48:55 CET] <BradleyS> i've pinged one of our other developers regarding it and we'll look into it further [16:49:01 CET] <BradleyS> thanks for the clarifications nevcairiel! [16:58:25 CET] <JEEB> you just don't get an extra AVStream because it's not a stream, and the first x minutes of video might not have any captions anyways [16:58:59 CET] <JEEB> you need to keep an eye on side data. mpv checks after decoding if the avframe has the side data [16:59:06 CET] <JEEB> if I recall correctly [17:49:26 CET] <durandal_1707> BBB: no ideas? [18:14:53 CET] <BBB> durandal_1707: ? [18:15:14 CET] <BBB> durandal_1707: I don't udnerstand, you have the formula, what is the question? [18:15:24 CET] <BBB> you want me to write out what? [18:15:39 CET] <BBB> it's a simple 5-tap filter [18:16:26 CET] <BBB> for (y=0;y<h;y++){for(x=0;x<w;x++){dst[x] = FILTER(src, y*stride+x);}} [18:17:24 CET] <BBB> with #define FILTER(src, pos) ((src[pos-2]-4*src[pos-1]+19*src[pos]-4*src[pos+1]+src[pos+2]+1) >> 5) [18:17:28 CET] <BBB> that's the horizontal filter [18:17:35 CET] <durandal_1707> now i need to do same for V and V & H [18:17:47 CET] <BBB> then same for vertical, but instead of -2, -1, +1, +2 you use -2*stride [18:17:53 CET] <BBB> so it's two loops [18:18:05 CET] <BBB> one into a temp buffer of size w*(h+4) [18:18:09 CET] <BBB> from y-2 to h+2 [18:18:17 CET] <BBB> and then use that temp buffer as input for the vertical (second) pass [18:18:29 CET] <BBB> fairly simple [18:18:45 CET] <BBB> 19-4-4=11+1+1-13 btw [18:18:48 CET] <BBB> 13 is not 32 [18:18:55 CET] <BBB> so your formula might have a bug [18:19:09 CET] <BBB> either >>5 is wrong, or 1/-4/19 is wrong [18:19:20 CET] <BBB> I Think it may be a 6tap filter [18:19:24 CET] <BBB> 19-4=15+1=16 [18:19:26 CET] <BBB> 2*16=32 [18:19:41 CET] <BBB> so the halfpel position is probably this, and then +1,-4,+19,+19,-4,+1 [18:19:45 CET] <BBB> that makes 32 [18:20:00 CET] <durandal_1707> yes, correct formula is something else.... [18:20:32 CET] <BBB> ok, so does it make sense now? [18:20:45 CET] <durandal_1707> yes [19:15:05 CET] <durandal_1707> vel0city: upload one multipage tiff if you can somewhere [19:52:34 CET] <atomnuker> also I think the correct way to handle multipage is to expose them all as streams via lavf [19:53:43 CET] <durandal_1707> atomnuker: tiff is not simple container [19:57:52 CET] <atomnuker> its fine, if the header isn't duplicated lavf can just splice the 2 together [20:07:13 CET] <cone-071> ffmpeg 03Martin Storsjö 07master:0676de935b1e: arm: Implement a NEON version of 422 h264_h_loop_filter_chroma [20:07:13 CET] <cone-071> ffmpeg 03James Almer 07master:47e12966b754: Merge commit '0676de935b1e81bc5b5698fef3e7d48ff2ea77ff' [20:25:03 CET] <atomnuker> who decodes h264 without a hardware decoder on arm? [20:25:36 CET] <atomnuker> in fact who decodes anything that isn't a picture on any arm ISA without a hardware decoder [20:25:51 CET] <JEEB> I do it for various stuff :) [20:26:30 CET] <kierank> atomnuker: I do for 4:2:2 [20:27:06 CET] <atomnuker> surely not cabac 1080i30 at 20mpbs, it doesn't have enough power [20:27:13 CET] <kierank> mine does [20:27:56 CET] <kierank> rk3399 [20:28:56 CET] <jamrial> atomnuker: h264 caught your attention, but all the vp9, hevc and av1 arm simd didn't? [20:30:53 CET] <atomnuker> well, yeah, I don't know an arm chip that doesn't have a (terrible mostly) h264 decoder [20:34:08 CET] <atomnuker> they're mostly all mobile too, so low power is a must for them [20:34:52 CET] <JEEB> my 2014 oneplus one could almost do 720p24 10bit H.264 perfectly [20:35:12 CET] <JEEB> (it had some drops together with rendering & subs and all) [20:46:05 CET] <Gramner> ass subs can sometimes take more cpu power to render than than decoding a 10-bit 1080p video though [20:46:18 CET] <JEEB> yup [20:46:26 CET] <Gramner> doesn't seem very optimized [20:46:32 CET] <BtbN> ass is just complex [20:46:47 CET] <BtbN> and drawing text is as well [20:47:35 CET] <philipl> Need to GPU accelerate it like DirectWrite :-) [20:48:16 CET] <atomnuker> which reminds me mozilla have a vulkan powered font rasterier now [20:49:21 CET] <philipl> written in rust? :-P [20:53:51 CET] <atomnuker> well, yeah [20:54:21 CET] <durandal_1707> BBB: do I need mirroring when doing temp in V&H MC? [20:54:59 CET] <BBB> it depends on the exact nature of the MC algorithm in the codec [20:55:07 CET] <BBB> are you sure they do mirroring? [20:55:20 CET] <BBB> or do they just clamp the index? [20:55:24 CET] <BBB> (that's emu_edge) [20:56:47 CET] <durandal_1707> I just get black last row of MB with VH MC [21:45:31 CET] <TD-Linux> I looked a while back and libass wouldn't be too hard to plug into pathfinder [21:45:45 CET] <JEEB> funky [21:46:00 CET] <TD-Linux> it has a bunch of "create circle" "create arc" commands that you would just map to building a pathfinder display list [22:37:37 CET] <durandal_1707> BBB: how this HV MC is done? I get last black row, filter is: #define LHFILTER(src) ((((src)[0]+(src)[1])*19 >> 1)-((src)[-1]+(src)[2 ])*2+(((src)[-2 ]+(src)[3 ])>>1)+8>>4) [22:40:30 CET] <BBB> if it's at the bottom of the frame, that's what emu_edge is for [22:40:36 CET] <BBB> you need to implement some form of emu_edge [22:40:40 CET] <BBB> or is this on each block? [22:40:43 CET] <BBB> then your temp bfuferis not filled [22:41:50 CET] <durandal_1707> what size of temp buffer needs to be? 16x21 ? [22:41:59 CET] <durandal_1707> do i need only one temp buffer? [22:44:45 CET] <atomnuker> what codec is this for? [22:45:12 CET] <durandal_1707> atomnuker: bink [22:54:04 CET] <BBB> 16x21 yes [22:54:11 CET] <BBB> a temp buffer on stack should be enough [22:57:15 CET] <durandal_1707> BBB: how second pass should look like? [23:02:17 CET] <BBB> show me code [23:02:28 CET] <BBB> what do you have, I'll show you what's wrong [23:02:39 CET] <BBB> and show me what artifact you get [23:02:46 CET] <BBB> is it per-block or per-image bottom row? [23:03:57 CET] <durandal_1707> https://pastebin.com/S17U3706 [23:04:02 CET] <durandal_1707> it is in middle [23:04:14 CET] <durandal_1707> it does not need emu edge [23:04:59 CET] <durandal_1707> and artifacts are small, black row in last row of 16x16 macro block [23:05:12 CET] <durandal_1707> this is for Y, for now... [23:08:21 CET] <BBB> you need >> 5, not 4? [23:08:33 CET] <BBB> 19+19-4-4+1+1 = 32 [23:08:44 CET] <BBB> oh >> 1 insid [23:08:45 CET] <BBB> weird [23:08:48 CET] <durandal_1707> no, filter is working fine [23:09:21 CET] <BBB> your h loop has wrong dimensions [23:09:25 CET] <durandal_1707> BBB: https://0x0.st/z8Fb.png [23:09:30 CET] <BBB> when you do the horizontal filter, you need to do it vertically 21 times [23:09:39 CET] <BBB> and horizontally 16 times, which consumes (horizontally) up to 21 pixels [23:09:53 CET] <BBB> then you have 21 input pixels horizontally per line giving horizontally 16 output pixels [23:09:55 CET] <BBB> 21 lines [23:09:58 CET] <durandal_1707> ignore bottom black blocks -- those are wrong DC because of some other bug [23:10:02 CET] <BBB> do that vertically to reduce vertical 21 -> 16 [23:10:05 CET] <BBB> output is 16x16 [23:10:14 CET] <BBB> for (int j = 0; j < 16; j++) { [23:10:14 CET] <BBB> for (int i = 0; i < 21; i++) [23:10:15 CET] <BBB> make that [23:10:20 CET] <BBB> for (int j = 0; j < 21; j++) { [23:10:20 CET] <BBB> for (int i = 0; i < 16; i++)

1 0

ffmpeg.log.20190322
by burek 23 Mar '19

23 Mar '19

[00:06:15 CET] <xxxmaker> what is the command to see what libcodec version my ffmpeg build is using [01:31:48 CET] <pink_mist> xxxmaker: uhm, literally just running 'ffmpeg' on the commandline shows it [01:51:34 CET] <net|> is there a flag to make the -fs 1M portion reoccurring to overwrite itself without relaunching ffmpeg ? [01:52:37 CET] <net|> or would i have to use webm_chunk somehow [01:53:14 CET] <net|> maybe a frame limiter would work better [01:54:22 CET] <net|> maybe moving it to a secondary tmp file every minute or 3 [01:54:36 CET] <kepstin> net|: i'd suggest using the segment muxer [01:55:38 CET] <kepstin> hmm, it doesn't support breaking by file size. i'm actually kind of surprised by that. [01:55:42 CET] <kepstin> but it can do by time [01:56:39 CET] <furq> i take it this is a live input [01:56:45 CET] <net|> yes [01:56:50 CET] <furq> nvm then [01:56:55 CET] <net|> its for streaming webm with html video tag [01:57:00 CET] <furq> mkvmerge can split by size but that's no use to you [01:57:32 CET] <net|> i have autorefresh html code to make it better [01:58:06 CET] <net|> kepstin how do you do it by time ? [01:58:35 CET] <kepstin> for streaming webm, you should probably look into using dash [01:59:31 CET] <net|> does DASH work with html video tag ? i tried with the hdr file but maybe my video options were out [01:59:41 CET] <net|> even vlc wont read it [02:01:24 CET] <net|> ffmpeg -i input.mp4 -c copy -map 0 -segment_time 00:20:00 -f segment -reset_timestamps 1 output%03d.mp4 [02:02:32 CET] <net|> i wonder if i took the %03d option out if it would overwrite itself [04:00:22 CET] <aicpro> even with a maximum bitrate of 7000 and a CRF of 10 set I'm consistently getting artifacts like this https://my.mixtape.moe/frfvsz.png [04:00:38 CET] <aicpro> the q value of ffmpeg's output is regularly 25-30 as well [04:10:06 CET] <furq> that's just yuv420p [04:10:11 CET] <furq> there's nothing you can do about that [04:10:47 CET] <furq> other than using a different colour scheme [04:13:52 CET] <aicpro> any suggestions? [04:14:28 CET] <furq> not other than the one i just gave [04:14:42 CET] <aicpro> any suggestions on another color scheme [04:14:44 CET] <furq> you could use a different pixel format but youtube or whatever will just convert it to 4:2:0 anyway [04:14:47 CET] <furq> oh right [04:15:08 CET] <furq> either use a bigger font or use colours that have more luma contrast [04:15:25 CET] <furq> white on black or vice versa will look fine [04:17:20 CET] <aicpro> alright [12:52:32 CET] <danieel> hello, we are feeding ffmpeg a raw h264 stream in order to make a MOV file. What are the possibilities to fix dropped frames? Can we edit the NAL before it enters ffmpeg, to say "i am twice that long?", or is there a special "no difference" NAL blob we can just insert to correct for delay ? [12:52:51 CET] <danieel> the application uses multiple cameras, and dropping frames make the streams asynchronous :( [12:53:25 CET] <JEEB> just set timestamps right and then things should be OK? [12:53:53 CET] <BtbN> raw h264 doesn't exactly have proper timestamps, even though in theory it does [12:53:54 CET] <JEEB> it only becomes a problem if you're still passing monotonically rising timestamps even though there's been a skip in packets [12:54:01 CET] <JEEB> BtbN: AVPackets do have timestamps [12:54:09 CET] <JEEB> oh, he means ffmpeg.c? [12:54:11 CET] <JEEB> perkele [12:54:12 CET] <JEEB> :V [12:54:14 CET] <BtbN> If the input is raw h264 though... [12:54:36 CET] <JEEB> yes, but the camera or whatever should have timestamps (in the worst case the receipt timestamps if there absolutely is no better way) [12:54:37 CET] <danieel> the h264 is produced by a hw encoder (nvidia) outside of ffmpeg, i can see parsing it whether it is a I or P frame [12:55:01 CET] <BtbN> Why are you encoding with nvenv, and then feeding it to ffmpeg? [12:55:02 CET] <danieel> hoping there is also a timestamp or duration field in it, which i could edit [12:55:12 CET] <BtbN> *nvenc [12:55:22 CET] <JEEB> danieel: raw annex b very unlikely has that :P [12:55:43 CET] <danieel> the frames come from argus, and then we inspect images (e.g. to sync the streams between each other) [12:55:51 CET] <BtbN> h264 bitstream in theory has timestamps. They are usually not set to anything meaningful though, and the container is used for that. [12:56:49 CET] <danieel> so better to look into crafting a no difference P frame? [12:57:00 CET] <BtbN> Better use a container [12:57:12 CET] <BtbN> Proper timestamps are the only way to make this work reliably [12:57:54 CET] <danieel> container is now handled by ffmpeg, so it does also do some implicit timestamping based on -r FPS option, right? [13:01:17 CET] <JEEB> ahahahaha [13:01:19 CET] <JEEB> no [13:01:25 CET] <JEEB> that is an output option :P [13:01:46 CET] <JEEB> and even when that one patch lands for -r to work with input, it will not fix what you need [13:02:01 CET] <JEEB> the only way to fix your issue is to add proper timestamps to your input [13:02:37 CET] <danieel> editing the h264 streams, or adding extra data bearing timestamps? [13:03:36 CET] <danieel> what i am doing now is just popen( 'ffmpeg -y -r $fps -i - -vcodec copy $file' ), and feed the stream from encoder there [13:03:42 CET] <BtbN> There have to be timestamps where that comes from [13:03:49 CET] <BtbN> don't use raw h264, ever [13:04:09 CET] <BtbN> It's interpreterd frame by frame based on a constant framerate you yet [13:04:12 CET] <BtbN> *set [13:04:16 CET] <JEEB> no, it even isn't yet [13:04:20 CET] <JEEB> the patch for that is still on the ML [13:04:21 CET] <JEEB> :P [13:04:27 CET] <JEEB> so it effectively does nada [13:04:56 CET] <danieel> this gives me a file which can be used though :) and was the easiest way to achieve a container [13:05:24 CET] <JEEB> except you already found an issue with the fact that you're dropping stuff in the middle :P [13:05:29 CET] <JEEB> and suddenly your crap falls apart [13:05:58 CET] <JEEB> I don't care how you transfer the timestamps, either in some other way and you use the FFmpeg API with AVpackets having proper timestamps [13:06:17 CET] <JEEB> or if you properly create your stream from the encoder with a container with timestamps [13:07:00 CET] <JEEB> I hope why I'm saying this makes sense to you? [13:08:44 CET] <danieel> yes, the solution is to use the full api, not pass raw data by stdin [13:12:48 CET] <lixus> i recorded a screencast with ffmpeg without audio. now i would like to record an audio track to that video. is it possible to play back the video and record audio annotations at the same time using ffmeg tools ? [13:12:55 CET] <danieel> there might be a slight problem with that - the output would be a VFR / variable frame-rate video / which would cause trouble by software that does not undestand it [13:13:14 CET] <JEEB> danieel: you can always make it stable X Hz [13:13:16 CET] <JEEB> that's the simpler part [13:13:17 CET] <JEEB> :P [13:13:21 CET] <JEEB> there's an fps filter, among other things [13:14:56 CET] <danieel> what will that do, to the h264 stream that has here and there a jump in timestamp? hope not frame interpolation, is it just modifying the time to frame mapping table? [13:15:42 CET] <BtbN> Without proper input timestamps, it will probably just re-arange the frames [13:16:05 CET] <JEEB> danieel: the fps filter is really simple; it will either drop or duplicate [13:16:20 CET] <JEEB> oh wait, you didn't want to re-encode, right? :P [13:16:31 CET] <danieel> that is easy to say in uncompressed, but we have already a bitstream :) [13:16:39 CET] <danieel> yes exactly [13:17:03 CET] <JEEB> "have fun with that". but at least your input is known to have timestamps so you can have your own logic to handle it how you want [13:18:33 CET] <danieel> well the only viable solution is then to craft the zero difference frame nal blob [13:18:50 CET] <danieel> and keep it fixed rate [13:19:55 CET] <danieel> shame there is no easy definition of such stuffing frame [13:26:33 CET] <xxxmaker> what is the command to see what x264 and x265 version my ffmpeg build is using [13:29:05 CET] <BtbN> You need to read the documentation from the person who built it for that. [13:32:43 CET] <xxxmaker> btbn what is the command you would use for your build [13:32:51 CET] <xxxmaker> that you are using now [13:32:53 CET] <BtbN> There is no command. [13:33:17 CET] <BtbN> That's why you need to read the documentation. To find the version. [13:33:35 CET] <xxxmaker> are you sure there is no command to find out? [13:33:48 CET] <BtbN> x264 might print some stuff to stdout when you use it, but other then that, libx264.c has no notion of querying the version [13:35:21 CET] <xxxmaker> well i am using 4.1.1 [13:40:57 CET] <BtbN> That doesn't mean much [15:22:36 CET] <another> x264/5 do indeed print version information when you encode with it [15:30:08 CET] <xxxmaker> another but is there way to find the version by typing command? [15:30:59 CET] <aboxer__> I'm looking for sample mpeg2 videos with CEA 708 closed captions. Anyone know where I can find such ? [15:31:31 CET] <xxxmaker> aboxer why does it have to be 708 CC ? [15:51:06 CET] <another> xxxmaker: ffmpeg -y -f lavfi -i testsrc=duration=1 -c:v libx264 -f matroska /dev/null -c:v libx265 -f matroska /dev/null 2>&1 | egrep 'core|version' [15:51:30 CET] <xxxmaker> that won't work in cmd.exe [15:53:39 CET] <ksk> install linux subsystem for windows :P [15:56:25 CET] <another> ffmpeg -y -f lavfi -i testsrc=duration=1 -c:v libx264 -f matroska NUL -c:v libx265 -f null - 2>&1 | egrep 'core|version' [15:58:11 CET] <xxxmaker> 'egrep' is not recognized as an internal or external command, [15:58:11 CET] <xxxmaker> operable program or batch file. [15:58:19 CET] <another> ah wait. windows doesn't have grep [15:59:31 CET] <another> ffmpeg -y -f lavfi -i testsrc=duration=1 -c:v libx264 -f matroska NUL -c:v libx265 -f null - 2>&1 | findstr /r 'core|version' [16:00:08 CET] <xxxmaker> 'version'' is not recognized as an internal or external command, [16:00:08 CET] <xxxmaker> operable program or batch file. [16:03:15 CET] <xxxmaker> i have 2 hour video: what is the "command" to best way to create a 1 minute sample [16:04:51 CET] <Hello71> ' isn't a quote in cmd.exe [16:04:59 CET] <Hello71> or I think windows in general [16:05:54 CET] <another> well, okay. windows doing windows things [16:06:06 CET] <another> out it in double quotes then [16:06:23 CET] <another> /s/out/put/ [16:06:54 CET] <xxxmaker> another nothing happened [16:06:58 CET] <xxxmaker> no error nothing [16:07:06 CET] <xxxmaker> when using double quotes [16:10:39 CET] <Hello71> I think you missed /i [16:11:36 CET] <another> no it's all lowercae [16:12:55 CET] <Hello71> probably x265 not included [16:15:12 CET] <another> maybe. but honestly i don't want to debug this anymore [16:15:35 CET] <xxxmaker> okay forge x264/x265 , how do i tell what version "aac" "libfdk_aac" my ffmpeg build comes with [16:15:38 CET] <xxxmaker> forget* [16:16:02 CET] <another> aac is a native encoder [16:16:12 CET] <xxxmaker> yes i know but i am sure it still has a version # [16:16:47 CET] <DHE> I don't think the fdk version is exported, unless it's dynamically linked in which case check out the .so/.dll [16:19:12 CET] <xxxmaker> i don't understand why this is so difficult [16:21:47 CET] <furq> patches welcome [16:22:17 CET] <JEEB> fdk-aac's license is not compatible with certain other license that f.ex. x264 and x265 are under :P [16:22:21 CET] <JEEB> and that is by design P [16:22:27 CET] <JEEB> from Google's side [16:22:33 CET] <JEEB> (and fraunhofer's) [16:23:00 CET] <JEEB> so if you make a build with fdk-aac and something that doesn't work with GPL, you cannot distribute it [16:23:06 CET] <JEEB> that's why it requires enable-nonfree :P [16:23:20 CET] <another> aac version = ffmpeg version [16:23:20 CET] <xxxmaker> jeeb what does all this have to do with just wanting to find the version # [16:23:30 CET] <JEEB> ah [16:23:47 CET] <JEEB> yea I'm not sure if fdk-aac gives out its version :P [16:24:02 CET] <Hello71> last time I think the answer was grep [16:24:05 CET] <xxxmaker> another not necessarily 4.1.2 ffmpeg might have bug fixes but no fixes for aac codec [16:24:23 CET] <xxxmaker> another not necessarily 4.1.2 ffmpeg might have other codec bug fixes but no fixes for aac codec [16:24:29 CET] <Hello71> well then the question is why did you download a frankenstein ffmpeg [16:24:38 CET] <JEEB> separate encoders or decoders are not versioned [16:24:44 CET] <JEEB> the libavcodec library is versioned [16:24:53 CET] <xxxmaker> Hello71 what is "frankenstein ffmpeg"? [16:26:45 CET] <xxxmaker> why is this so difficult, i can find the libopus version [16:26:57 CET] <furq> use libopus then [16:26:58 CET] <xxxmaker> but why can't i find "aac" or "lib-fdk" version [16:27:30 CET] <xxxmaker> furq that's not the point [16:27:39 CET] <DHE> "aac" version is ffmpeg's version. fdk version isn't available because it's an external application ffmpeg imports and it doesn't tell you what version it is [16:28:16 CET] <Hello71> smells like xy problem [16:28:17 CET] <xxxmaker> DHE: not necessarily 4.1.2 ffmpeg might have other codec bug fixes but no fixes for aac codec [16:28:30 CET] <JEEB> sure, but we don't version components within a library [16:28:35 CET] <JEEB> only the libraries [16:29:11 CET] <xxxmaker> if nothing was done to the "aac" why would version # change [16:29:12 CET] <JEEB> although I'm not sure how often those get bumped in branches :P [16:29:32 CET] <JEEB> since the bug fixes themselves generally don't touch the library versions [16:29:51 CET] <DHE> library versions are more of an API compatibility thing, right? [16:30:08 CET] <JEEB> well, micro version I think can be bumped in theory? [16:30:18 CET] <DHE> and then the project as a whole gets a release with a version number like 4.1.2 [16:31:47 CET] <xxxmaker> why doesn't ffmpeg write aac-version # on meta data [16:31:58 CET] <JEEB> because there is no AAC encoder's version [16:32:13 CET] <JEEB> we don't version on that level [16:32:40 CET] <xxxmaker> jeeb whta about lib_fdk , i don't see version # on meta data either [16:32:47 CET] <JEEB> then it doesn't export it [16:32:50 CET] <DHE> well that's their problem [16:33:23 CET] <xxxmaker> can't you modify it so that it does? [16:33:56 CET] <JEEB> then everyone would have to patch their fdk-aac the same way [16:34:10 CET] <JEEB> if that doesn't sound like a bad idea to you then I don't know what is [16:34:32 CET] <xxxmaker> no idea what that means [16:34:39 CET] <JEEB> also where the flying asdf would you even put the encoder version to? [16:34:40 CET] <DHE> no, it can't be done [16:34:57 CET] <DHE> should we disassmble the produced AAC stream, insert the metadata, and reassmeble it? [16:35:05 CET] <DHE> (again, we don't have a version number to insert anyway) [16:35:20 CET] <xxxmaker> i see version # for lib_opus and lib_flac [16:35:43 CET] <xxxmaker> and lib_lame [16:37:18 CET] <DHE> So I checked the source code. There's a version function in fdk, but the version number has only had ~10 different values since 2012 [16:38:26 CET] <DHE> (there's a build date/time but that promises very little) [16:40:45 CET] <xxxmaker> DHE: can you elaborate on "~10 different values since 2012" [16:40:54 CET] <xxxmaker> what are some version # examples [16:42:26 CET] <DHE> 2.2.6 in 2012 to 2.2.8 -> 2.3.0 in 2013 and now we're at 2.3.6 [16:43:27 CET] <another> libfdk recently bumped to 2.0 [16:44:49 CET] <another> also, i don't think ffmpeg supports libflac [16:45:05 CET] <xxxmaker> another sure it does [16:45:09 CET] <xxxmaker> DHE i see, thanks [16:45:09 CET] <furq> it doesn't [16:46:00 CET] <xxxmaker> ffmpeg -i audio.wav -acodec flac audio.flac [16:46:02 CET] <xxxmaker> that works [16:46:11 CET] <furq> that's not libflac [16:46:19 CET] <xxxmaker> same thing [16:46:29 CET] <furq> no it's not [16:46:38 CET] <xxxmaker> how is it not same thing? [16:47:38 CET] <another> it's a native encoder [16:49:59 CET] <xxxmaker> another huh? what are you talking about [16:50:12 CET] <another> also: where do you see the version of libopus? [16:50:12 CET] <xxxmaker> flac was developed by somebody else not ffmpeg [16:50:21 CET] <another> yes [16:50:35 CET] <another> and ffmpeg has it's own implementation [16:50:43 CET] <another> based on flake i think [16:51:12 CET] <xxxmaker> another why would ffmpeg change flac's implementation [16:54:41 CET] <xxxmaker> another: ffmpeg -f lavfi -i sine -acodec libopus R:\test.opus that shows libopus version [16:55:44 CET] <another> not for me [16:56:27 CET] <another> anyway, gotta go [17:03:30 CET] <xxxmaker> jeeb so what do you think?> [17:03:59 CET] <JEEB> i don't give a flyong fuck to be blunt [17:04:31 CET] <xxxmaker> jeeb no i mean nevcairiel's actions [17:04:32 CET] <JEEB> you can make an issue on trac about versioning components if you really want [17:05:06 CET] <xxxmaker> [08:48] <xxxmaker> nevcairiel but if ffplay cannot play then you can't prove that it does [17:05:06 CET] <xxxmaker> [08:48] <@nevcairiel> i dont have to prove anything, to you or anyone [17:06:10 CET] <JEEB> he is correct, he has no obligation whatsoever. although looking at other FFmpeg API clients like mpv it is flying obvious that the libraries give you what you need in order to implement closed caption support [17:06:22 CET] <xxxmaker> then ffplay should play it [17:06:46 CET] <JEEB> ffplay and ffmpeg are example api clients and they are static. thus they don't [17:07:03 CET] <xxxmaker> no idea what just said [17:07:03 CET] <JEEB> if someone cares enough they can implement the support [17:07:58 CET] <JEEB> xxxmaker: ffmpeg contains the libraries and the tools that utilize the libraries. the tools just suck but the basic building blocks for other applications like handbrake are there [17:08:11 CET] <JEEB> does this make sense? [17:08:32 CET] <xxxmaker> yes [17:08:37 CET] <JEEB> if someone cares enough about the internal tools, support will be added [17:09:07 CET] <JEEB> well not internal, just the ones delivered with FFmpeg (ffmpeg.c and ffplay.c) [17:09:47 CET] <JEEB> heck, the libraries support dynamically adding streams and ffmpeg.c will just say it found a new stream and that it ignored it [17:10:16 CET] <JEEB> because ffmpeg.c is an old example application :p [17:10:26 CET] <JEEB> it is not all of FFmpeg [17:11:12 CET] <JEEB> it is easier to add building blocks for applications than try to update ffmpeg.c to be more dynamic :p [17:11:27 CET] <JEEB> (to use those new building blocks) [17:14:16 CET] <xxxmaker> why does ffmpeg -f lavfi -i sine -acodec libfdk_aac -t 30 -vbr 3 test.aac create corrupted file? but ffmpeg -f lavfi -i sine -acodec libfdk_aac -t 30 -vbr 3 test.mp4 does not? [17:15:08 CET] <xxxmaker> is this a bug? [17:15:40 CET] <JEEB> post on the issue tracker [17:15:46 CET] <JEEB> i have no idea [17:15:57 CET] <xxxmaker> ffmpeg has weird bug tracker [17:16:26 CET] <xxxmaker> can i just post it via IRC [17:16:49 CET] <JEEB> no [17:49:13 CET] <pkunk> I am generating an ffmpeg command to create a mosaic of 16 input streams using the overlay filter. It works fine but ffmpeg takes 5-6 seconds to open each input stream which means the command takes 2-3 minutes just to start transcoding [17:49:55 CET] <pkunk> Is there a way to make ffmpeg process all the -i http://path.to/mpegts URL's simultaneously instead of one at a time ? [17:50:13 CET] <JEEB> probably not due to the design of the ffmpeg.c cli app [17:50:27 CET] <JEEB> you can see if you want to improve that part of it [17:50:45 CET] <JEEB> if you lack the skills and/or time, feel free to make a ticket on trac.ffmpeg.org [17:51:56 CET] <pkunk> JEEB: ah, I've already worked with the libav* C code before so it's doable. I have no idea if ffmpeg.c itself will need drastic changes to do this [17:52:41 CET] <pkunk> i.e is it thread-aware enough , or is it just a matter to increasing the thread count in the input processing stage [17:53:12 CET] <JEEB> yea, or is it just an iterative thing which in theory could be handled through its own thread pool [17:53:24 CET] <JEEB> because probing all of the inputs doesn't have to be A->B [17:53:35 CET] <JEEB> at least I can't think of many cases where that would have to be the case [18:11:47 CET] <kepstin> pkunk: yeah, currently the input handling code in ffmpeg.c is all single-threaded afaik. would probably need some structural changes to fix this. [18:18:06 CET] <JEEB> yea it depends on how much you want to thread [18:18:16 CET] <JEEB> if it's just the initial probing that might be possible to just handel separately? [19:02:59 CET] <kepstin> eh, if you're doing the initial probing separately, you might as well do the complete input handling in threads, should help a lot of the people doing live network streaming use cases in general. [19:05:15 CET] <JEEB> sure [20:09:10 CET] <pkunk> kepstin: Thanks, will have a look at the code tomorrow [20:31:33 CET] <faLUCE> hello all [20:33:48 CET] <faLUCE> is there a way to get from an aviocontext of a muxer if the muxed packet was a keyframe ? [20:34:16 CET] <JEEB> wrong abstraction level, no [20:35:28 CET] <faLUCE> in addition: an audio+video stream to mux must start with a video keyframe? [20:35:40 CET] <JEEB> no? [20:35:52 CET] <JEEB> I think you've asked this already before and the answer is the same [20:36:09 CET] <faLUCE> JEEB: I asked about an AUDIO only stream [20:36:40 CET] <JEEB> then the keyframe part didn't make sense since audio doesn't have keyframes as such since all formats so far (except AC-4) have all packets be keyframes [20:37:44 CET] <faLUCE> JEEB: I know that, but I don't understand why for an audio+video stream I don't need a video keyframe as well [20:38:24 CET] <JEEB> often it is preferred that you start with a RAP [20:38:28 CET] <JEEB> (random access point) [20:38:32 CET] <JEEB> but that doesn't come out of a technical limitation [20:38:57 CET] <JEEB> for example, people didn't do mp4 fragments that start with non-RAP because f.ex. chrome would have an open bug about that [20:39:07 CET] <JEEB> even though MPEG-DASH specification would let them do so [20:39:29 CET] <JEEB> then you have MPEG-TS streams where all the digital TV receivers are used to waiting for RAPs [20:39:40 CET] <JEEB> so it doesn't make any sense for the muxer to make you wait for a RAP [20:39:58 CET] <faLUCE> then, JEEB, when an audio+video doesn't start with a video keyframe, a player should play audio only before getting the first video key? [20:40:12 CET] <JEEB> what a player does is up to the player's specification [20:40:16 CET] <JEEB> it may play audio only [20:40:24 CET] <JEEB> it may not play anything until it gets the RAP [20:40:33 CET] <faLUCE> I see, thanks [20:40:54 CET] <JEEB> or as was the case with various browsers, it might just explode [20:41:10 CET] <faLUCE> :-) [20:41:52 CET] <JEEB> of course, if a format specification says that a mux has to start from a RAP [20:42:06 CET] <JEEB> then for that specific format the muxer might fail you if you try to feed it a non-RAP [20:42:11 CET] <JEEB> but that is 100% format specific [22:04:08 CET] <brimestone> Using filter (-filter_complex with multiple output) is exporting a PNG still an option? [22:04:34 CET] <furq> yes [22:05:01 CET] <brimestone> Which filter should I use? [22:05:06 CET] <furq> uh [22:05:18 CET] <furq> whatever filter you want to apply [22:19:21 CET] <DHE> filtering is done on raw decoded images. then it goes to the PNG output like normal. filter_complex is only special because it lets you select arbitrary inputs and outupts, including multiple of each type from different sources, etc [23:31:33 CET] <__raven__> hi [23:33:59 CET] <__raven__> how to set a fixed header information about fps in an flv container? [23:34:09 CET] <__raven__> we need to remux a rtmp [00:00:00 CET] --- Sat Mar 23 2019

1 0

ffmpeg-devel.log.20190321
by burek 22 Mar '19

22 Mar '19

[00:10:05 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:978880c803d1: lavf/latmenc: Error out for unsupported codecs. [00:54:33 CET] <cone-487> ffmpeg 03Marton Balint 07master:e85f37d51e97: avfilter/af_astats: add support for selecting measured statistics [00:54:34 CET] <cone-487> ffmpeg 03Marton Balint 07master:233fdd84c2c7: avfilter/af_astats: fix identation [00:54:35 CET] <cone-487> ffmpeg 03Marton Balint 07master:235228ea5090: avfilter/af_astats: factorize sample loops [00:54:36 CET] <cone-487> ffmpeg 03Marton Balint 07master:5cc4b79b295d: avfilter/af_astats: rework sample loops [00:54:37 CET] <cone-487> ffmpeg 03Marton Balint 07master:6af67dcc3519: avfilter/af_astats: add support for optimized min/max/peak calculation [01:39:52 CET] <cone-487> ffmpeg 03Martin Vignali 07master:6dc1da416e14: Maintainers : remove myself [02:46:43 CET] <cone-487> ffmpeg 03James Almer 07release/2.8:88588a24e915: avcodec/hevcdec: decode at most one slice reporting being the first in the picture [02:46:45 CET] <cone-487> ffmpeg 03James Almer 07release/3.0:b307cbe27613: avcodec/hevcdec: decode at most one slice reporting being the first in the picture [02:46:47 CET] <cone-487> ffmpeg 03James Almer 07release/3.1:f8e254716b62: avcodec/hevcdec: decode at most one slice reporting being the first in the picture [02:46:50 CET] <cone-487> ffmpeg 03James Almer 07release/3.2:a06cd0283eea: avcodec/hevcdec: decode at most one slice reporting being the first in the picture [02:46:52 CET] <cone-487> ffmpeg 03James Almer 07release/3.3:884ecede1701: avcodec/hevcdec: decode at most one slice reporting being the first in the picture [02:46:54 CET] <cone-487> ffmpeg 03James Almer 07release/3.4:da6a61606a19: avcodec/hevcdec: decode at most one slice reporting being the first in the picture [02:46:57 CET] <cone-487> ffmpeg 03James Almer 07release/4.0:d53202f92dc5: avcodec/hevcdec: decode at most one slice reporting being the first in the picture [02:46:59 CET] <cone-487> ffmpeg 03James Almer 07release/4.1:dbef08b60f44: avcodec/hevcdec: decode at most one slice reporting being the first in the picture [10:41:09 CET] <cone-026> ffmpeg 03Michael Niedermayer 07release/4.1:7ce56329e71f: avcodec/clearvideo: Check remaining data in P frames [10:41:10 CET] <cone-026> ffmpeg 03Michael Niedermayer 07release/4.1:b429df281d50: avcodec/dfa: Check the chunk header is not truncated [10:41:11 CET] <cone-026> ffmpeg 03Michael Niedermayer 07release/4.1:a7cb7a2e4314: Changelog: update [10:54:07 CET] <j-b> kierank: wow, this guy does not like yo. [10:56:22 CET] <durandal_1707> j-b: who is that guy? have nick on github? [10:56:32 CET] <j-b> no clue [10:56:44 CET] <j-b> he is active on various mailing lists saying "use libmpv" [10:57:35 CET] <JEEB> I don't think anyone in that thread is an active mpv dev that I know of [10:57:51 CET] <JEEB> unless there are user names I just don't remember [10:57:57 CET] <JEEB> (which there probably are) [10:58:11 CET] <durandal_1707> j-b: you should use libmpv [10:58:27 CET] <JEEB> you never cease to try and troll people, do you? [10:59:05 CET] <durandal_1707> are you attacking me? [10:59:10 CET] <JEEB> no? [11:00:22 CET] <j-b> durandal_1707: of course! [11:00:28 CET] <j-b> durandal_1707: where is my AC-4 decoder? :D [11:00:31 CET] <kierank> j-b: lol [11:00:39 CET] <j-b> durandal_1707: also, I've seen more and more requests for IMM5 [11:00:42 CET] <kierank> durandal_1707: why you not respond to me tweets [11:00:45 CET] <JEEB> :) [11:01:00 CET] <j-b> kierank: because durandal_1707 hates you now. He's in love with me, now! [11:03:50 CET] <kierank> j-b: :( [11:03:54 CET] <kierank> All Brexit fault [11:04:08 CET] <kierank> durandal_1707: do you come to my birthday [11:04:31 CET] <j-b> that would be really cool! [11:04:41 CET] <thardin> are any of you folks in london? [11:05:20 CET] <funman> https://www.youtube.com/watch?v=acq2MvoSkJI [11:05:26 CET] <thardin> say in two weeks [11:05:49 CET] <kierank> No, in Vegas those weeks [11:06:17 CET] <durandal_1707> j-b: then raise bounty for IMM5 [11:06:58 CET] <thardin> darn [11:07:32 CET] <j-b> durandal_1707: OK [11:43:18 CET] <cone-026> ffmpeg 03Carl Eugen Hoyos 07master:4d8875ec23cf: lavf: Constify the probe function argument. [11:58:22 CET] <j-b> > It makes me unhappy that one FFmpeg developer apparently decided to leave [11:58:25 CET] <j-b> the project already because of this. [11:58:27 CET] <j-b> who? [11:58:35 CET] <nevcairiel> ffmpeg Martin Vignali master:6dc1da416e14: Maintainers : remove myself [11:58:50 CET] <j-b> ok [11:58:55 CET] <nevcairiel> (also, very unprofessional using the git log as his soap box) [11:59:51 CET] <j-b> (very wtf, you mean) [12:00:25 CET] <j-b> he does not even commit on the NDI code... [12:40:21 CET] <BBB> is qsv open source? [12:48:24 CET] <jkqxz> QSV is the marketing name for the hardware blocks. The use of the name in FFmpeg is rather misleading, but has stayed for historical reasons. [12:49:09 CET] <jkqxz> On Linux, the host software (both VAAPI and libmfx) is all open source. Firmware blobs for the GPU are required for some encoding features, though. [12:50:04 CET] <jkqxz> On Windows, decode works via the standard DXVA2/D3D11 OS interfaces but obviously the drivers themselves are proprietary. [12:51:06 CET] <BBB> ok [12:51:07 CET] <jkqxz> Other stuff on Windows is via libmfx, and all of that is closed. [12:51:37 CET] <BBB> that is not great :-/ [12:52:02 CET] <JEEB> yea, I think the windows version is part of the Intel Media SDK? [12:52:06 CET] <JEEB> which is not OSS? [12:52:12 CET] <JEEB> unlike the lunix variant [12:52:28 CET] <JEEB> although IIRC the intel media SDK on linux is a mess [12:52:33 CET] <JEEB> like having to patch the kernel etc [12:52:39 CET] <JEEB> vaapi on the other hand seems much saner [12:52:43 CET] <JEEB> (and has dec and enc) [12:53:25 CET] <jkqxz> Yes. The Windows part is as bad an NVENC with dynload stuff for GPL evasion. [12:53:49 CET] <jkqxz> libmfx on Linux is much saner than it used to be. It works on normal kernels with no funny business nowadays. [12:54:02 CET] <jkqxz> However, there is very little reason to use it rather than VAAPI. [12:54:20 CET] <JEEB> yup [12:54:27 CET] <BBB> you know GPL evasion is a bad word right? [12:54:37 CET] <JEEB> ý(Žü@)Î [12:54:37 CET] <BBB> in america, we have to bleeb that out on public broadcasts [12:55:54 CET] <jkqxz> I'm sure the actual argument is that it falls under the system library exception. [12:58:09 CET] <JEEB> > driver specific API installed by the hardware driver > provided by OS [12:58:11 CET] <JEEB> ayyy lmao [13:05:31 CET] <BBB> I've said before that I totally don't buy the current era's use of the system exception in the GPL [13:07:09 CET] <JEEB> generally with proprietary operating systems it's pretty concise what is a component of the OS and what's not. like Videotoolbox being an OS component, or DXVA2 or D3D11VA [13:07:53 CET] <JEEB> linux is the place where people generally tend to try and widen it mostly because linux by itself is just the kernel. then if you add the software from the distro then that area gets very very wide [13:09:37 CET] <jkqxz> The firmware blobs for quick sync are a rather ugly problem. They've built them into the userland driver to load when needed, which is very sensible technically. But, it means that package contains a load of blobs and therefore lacks the full human-readable source code. [13:10:41 CET] <jkqxz> The other drivers (e.g. Mesa / AMD) put their blobs in the linux-firmware repo to load at boot time, so the userland driver doesn't contain them. [13:10:59 CET] <nevcairiel> that seems like a rather technical distinction [13:11:09 CET] <nevcairiel> there is a blobl somewhere that you cannot read [13:12:01 CET] <jkqxz> Debian does some splitting of this. There is a blobless i965 VAAPI driver with partial functionality in Debian free. [14:47:51 CET] <j-b> On windows, the QSV encoding part are installed with the drivers. [14:48:56 CET] <j-b> It totally fits the "normally distributed with the major components" case [14:49:52 CET] <j-b> We say that this part of the GPL is unclear and unfortunate, but we cannot redefine the GPL [14:50:18 CET] <JEEB> yea, if we consider drivers as part of the OS [14:51:01 CET] <j-b> This is the common interpretation since forever, of the GPL. [14:51:15 CET] <j-b> " with the major components (compiler, kernel, and so on) " [14:51:27 CET] <j-b> drivers are considered part of the "and so on" [14:51:40 CET] <JEEB> esp. on linux I guess where the line is less clear-cut [14:51:59 CET] <j-b> that is possible. [14:53:16 CET] <j-b> But NDI is a clear-cut, IMHO [14:53:24 CET] <JEEB> yes [14:53:42 CET] <JEEB> (I think we had this discussion yesterday 8)) [14:54:01 CET] <JEEB> and now mostly were talking about the windows intel media SDK, which is how QSV is utilized on windows [14:54:10 CET] <JEEB> the linux one is an open source thing anyways [14:56:08 CET] <j-b> we use libmfx on Windows, I thought [14:58:26 CET] <j-b> philipl: what is libnpp? [15:00:19 CET] <j-b> BBB: openssl and tls are also part of the OS on some macOS/BSD, so they have the system library exception [15:05:27 CET] <KombuchaKip> Why does the ffmpeg write it's own ./configure manually instead of using the autotools? Isn't it more work to reinvent its functionality? [15:06:46 CET] <BtbN> Because autotools is a horrible mess. [15:06:59 CET] <BBB> KombuchaKip: it's a sensitive subject to some devs [15:07:16 CET] <BtbN> Almost everything is less of a pain than autotools [15:07:21 CET] <KombuchaKip> BBB: Looks like it. [15:07:30 CET] <j-b> meson is the future [15:07:48 CET] <BtbN> I'd rather have cmake or configure re-written in python or something instead. [15:08:07 CET] <JEEB> KombuchaKip: it probably was "simple enough" at first [15:08:15 CET] <JEEB> then with time it got a lot of stuff in there [15:11:19 CET] <atomnuker> somehow though the script ended up being faster than meson though [15:13:51 CET] <JEEB> if it's less than minute(s) then really nobody cares /that/ much :D [15:14:07 CET] <JEEB> it's just when it took minutes (and up to 10min on windows) when people cared about the speed [15:16:35 CET] <nevcairiel> j-b: libnpp is a library of pre-defined cuda functions to execute on the gpu, ie. it has a scaler and other stuff like that, but that one is certainly closed source [15:17:19 CET] <nevcairiel> and honestly, that part is the easiest to get rid of [15:17:50 CET] <nevcairiel> since w e have scale_cuda now, whats the point of scale_npp anymore [15:17:59 CET] <jamrial> can you even make autotools handle fine grained dependecies for the hundreds of ffmpeg modules like our custom configure does? [15:18:07 CET] <jamrial> i know you can with meson [15:18:31 CET] <jamrial> but i've never seen autotools used for anything but relatively basic system deps checks [15:19:09 CET] <KombuchaKip> jamrial: The autotools have had an M4 macro for pkg-config for many years to check dependencies. [15:19:29 CET] <jamrial> i mean internal modules [15:19:50 CET] <uau> about that "system library exception" thing, IIRC relying on that is still a problem for distributions even if you interpret it widely to include just about anything in the distribution [15:19:59 CET] <jamrial> decoder depending on parser, which in turn depends on a bsf, and so on [15:20:14 CET] <uau> since it's not permitted to rely on that for the system itself [15:20:35 CET] <uau> i.e. microsoft can't ship ffmpeg as part of windows and say it's relying on system library exception for its own system [15:20:42 CET] <KombuchaKip> jamrial: If you want recursive automake, it supports that. Otherwise you just add the dependencies as rules. They can be automatically generated for you if you like. [15:21:20 CET] <uau> so that does not allow linux distributions themselves to ship ffmpeg [15:23:50 CET] <j-b> BtbN: meson is in python :) [15:24:26 CET] <BtbN> I was more thinking like literally translating the shell script we have now to python [15:24:38 CET] <BtbN> My experiences with meson so far have been very underwhelming [15:25:32 CET] <nevcairiel> i'm not overly impressed with meson either [15:25:35 CET] <nevcairiel> a lot of rough edges still [15:25:44 CET] <j-b> sure, but it will improve [15:25:53 CET] <j-b> and people are moving to it :) [15:46:48 CET] <jdarnley_obs> Did vlc finish moving to meson yet? [15:47:38 CET] <jdarnley_obs> Also "recursive automake"? [15:47:47 CET] <jdarnley_obs> that is insanity^2 [15:48:48 CET] <jdarnley_obs> or is it just regular automake insanity? [15:49:08 CET] <j-b> jdarnley_obs: we're finishing it. [15:49:30 CET] <j-b> jdarnley_obs: CMake is an insane mess. Meson is rough, but works. [15:49:35 CET] <BtbN> I tried cross compiling stuff that used meson, and pretty much ended up compiling the thing manually [15:49:46 CET] <BtbN> Cross-Compiling with cmake just works. [15:49:47 CET] <jdarnley_obs> Good. As a followup does vlc have any of its own x86 asm files? [15:50:07 CET] <j-b> jdarnley_obs: and GTK*, Gnome, Systemd, Gstreamer, all low-level utils and libraries will move to meson, in the next year or so [15:50:21 CET] <j-b> I expect this to happen more and more [15:50:37 CET] <BtbN> Will be fun for anything that also needs to work on Windows [15:50:45 CET] <BtbN> And support msvc especially [15:50:47 CET] <j-b> BtbN: we use meson for dav1d without any problem and we compile on Android, iOS, Windows, Windows/ARM [15:50:56 CET] <j-b> we use meson with MSVC already [15:50:58 CET] <jdarnley_obs> BtbN cross compiling seems to be one area that is always ignored by configure/make replacements. [15:51:12 CET] <j-b> we cross-compile with meson, without any issue. [15:51:25 CET] <nevcairiel> cross-compiling with meson sort of works, but it defies any existing conventions and wants you to learn it all over again [15:51:25 CET] <j-b> since meson has a MSVC backend, it produces directly a MSVC project file [15:51:26 CET] <BtbN> It's not ignored, just not exactly well tested. I ran into numerous issues that were known but with no known workaround. [15:52:14 CET] <jdarnley_obs> Maybe I should use meson to re-invigorate my interest in my visualization project. [15:52:29 CET] <j-b> my experience is that there are still bugs in meson, true. But it is the less shitty alternative there is. [15:53:07 CET] <nevcairiel> in my limited experience, its not finished enough to consider it, if you care about anything but plain linux builds [15:53:38 CET] <j-b> nevcairiel: dav1d compiles all platforms with it. And it works fine [15:53:52 CET] <j-b> CMake is beyond broken and horrible syntaxically. Bazel is a hammer that requires a very specific nail to work. Scons, qbs are slow and not useful. Qmake is limited. [15:53:52 CET] <nevcairiel> once you figure out all the quirks of meson, sure [15:54:02 CET] <BtbN> david doesn't exactly have dependencies though? [15:54:27 CET] <j-b> dependencies are easy with pkgconfig [15:54:27 CET] <nevcairiel> even a simple project like dav1d had me run against a few annoying meson quirks already [15:54:31 CET] <BtbN> qmake is the Qt thing, right? If so, that's considered deprecated anyway. [15:54:45 CET] <j-b> It's quite recent, so sure, there are issues, but compared to the others, it is a better alternative [15:54:50 CET] <j-b> and custom scripts are always wrong [15:55:01 CET] <BtbN> Yes, exactly that was the issue when I built stuff for Windows. meson wanted pkg-config everything. All the stuff did not have pkg-config on Windows. [15:55:33 CET] <BtbN> Or it found the system pkg-config file instead, and blew up [15:55:42 CET] <j-b> Fighting pkg-config in 2019 is unwise, sorry. [15:56:00 CET] <BtbN> Well, I ended up hand writing a dozen pkg config files just to make it build [15:56:15 CET] <BtbN> Because the libraries (a bunch of Vulkan stuff) does not ship with any [15:57:10 CET] <BtbN> With CMake you can just override the paths and it will work. meson, nope, no dice. [15:58:23 CET] <j-b> CMake is a huge mess [15:58:42 CET] <j-b> With hundreds of Find**Package.cmake files that are never in sync [15:59:01 CET] <j-b> and you get the same crap as m4/ scripts that are copied from one project to another [15:59:02 CET] <BtbN> From my experience with dealing with build systems, cmake is the least troublesome [15:59:32 CET] <BtbN> Most of those Find*.cmake scripts just invoke pkg-config anyway, and only do stuff if that fails. [15:59:34 CET] <kurosu> j-b: I find meson MSVC solution file for dav1d horrendeous [15:59:45 CET] <kurosu> not something I'd work with - only good for compiling [15:59:54 CET] <j-b> kurosu: compared with the one from CMake? come on. [15:59:56 CET] <JEEB> :D [16:00:15 CET] <JEEB> yea, I was about to ask if it looked better or worse than such generated by cmake [16:00:25 CET] <j-b> almost the same [16:00:32 CET] <kurosu> j-b: there's stuff for CMake and dav1d? want! :p [16:00:41 CET] <j-b> absolutely not [16:00:44 CET] <kurosu> j-b: no really, I do prefer CMake output [16:00:52 CET] <JEEB> you should detail that [16:00:58 CET] <JEEB> and possibly make an issue/improvement into meson [16:01:01 CET] <j-b> Cmake is a huge mess. We tried to move to CMake for VLC [16:01:14 CET] <j-b> we had to stop, since litterally nothing was working [16:01:35 CET] <j-b> I talk to KDE people a lot, and they are unhappy with CMake with Xcompilation [16:01:51 CET] <kurosu> I'd post a screenshot of the solution file but can't at the moment [16:02:11 CET] <kurosu> I just have the object files listed, not sure about the c files [16:02:12 CET] <j-b> CMake being turing complete, people just write things in Find*.cmake that are redefining everything [16:02:20 CET] <j-b> FindQt.cmake being the worst [16:02:30 CET] <kurosu> and absolutely sure headers are not shown (or burried somewhere I haven't found yet) [16:02:59 CET] <j-b> Anyway, I don't care if you love CMake more than meson [16:03:11 CET] <j-b> my opinion is that meson will gain a lot more traction soon [16:03:12 CET] <JEEB> he doesn't, he just liked the MSVS project file structur emore :P [16:03:27 CET] <JEEB> thus I recommended him to provide an issue about that - or improve it with a patch [16:03:36 CET] <j-b> and that people staying near CMake are going to have a big battle to fight against it [16:04:07 CET] <BtbN> FindQt.cmake is deprecated for a reason [16:04:13 CET] <BtbN> you use the Qt config files that come with Qt [16:04:15 CET] <kurosu> JEEB: effort for something I have no need for yet [16:04:34 CET] <JEEB> kurosu: well at the very least mark what the isuse with those project files is for you :P [16:04:48 CET] <JEEB> fixing it yourself is one thing, but at least the possibility for improvement is noted [16:07:38 CET] <kurosu> to be fair, j-b is more likely speaking about maintaining and building with A vs B, whereas I don't care about what's under the hood as a end user [16:08:30 CET] <j-b> With VLC, we have more dependencies than most projects (around 120) and we ship VLC on more platforms than any other big project (more than Chrome, Firefox, libreoffice, or Adobe Reader) [16:08:38 CET] <j-b> the conclusion is this one: [16:09:07 CET] <j-b> "if a project does not use autotools or meson, (or at the limit Cmake), it will fail in a way or another" [16:09:34 CET] <j-b> (including FFmpeg, of course, but live555, libvpx, zlib are horrible) [16:09:35 CET] <kurosu> *ffail [16:09:37 CET] <philipl> j-b: did anyone answer your libnpp question. It's an nvidia library distributed with the cuda sdk that provides high level calls to do various accelerated operations that are implemented with cuda underneath. [16:10:02 CET] <j-b> philipl: ok. [16:10:12 CET] <j-b> philipl: not open source? [16:10:15 CET] <philipl> j-b: so unlike the filters directly written against cuda, you need the SDK for headers and libraries. [16:10:18 CET] <philipl> right [16:10:37 CET] <j-b> I would say that this is not fine, according to my opinion, then. [16:10:40 CET] <philipl> There are two filters written against libpp today. [16:10:59 CET] <j-b> philipl: and I started discussing with Brad, as I said the day before yesterday [16:11:10 CET] <philipl> One of them is basically obsolete, (the scale filer, where we have a direct cuda one too) [16:11:26 CET] <philipl> The other is a transpose filter that BtbN knows more about than me. [16:11:41 CET] <philipl> I don't have a problem removing them if it helps us get to a consistent licence position. [16:11:57 CET] <j-b> understood. [16:12:07 CET] <BtbN> The libnpp scale filter is far from obsolete sadly [16:12:12 CET] <philipl> :-( [16:12:19 CET] <BtbN> it's the only filter that can do on-gpu format conversion [16:12:24 CET] <nevcairiel> so improve the cuda filter =p [16:12:40 CET] <BtbN> We basically need format_cuda [16:12:49 CET] <BtbN> Which would be a huge mess to write [16:12:51 CET] <philipl> yeah - that would be the replacement. [16:13:09 CET] <BtbN> And scale_cuda is lacking some higher quality algorithms that npp has [16:13:27 CET] <BtbN> Plus, npp is heavily used by a lot of people, removing it would cause serious upset [16:13:54 CET] <BtbN> I got very unfriendly E-Mails already when the in-tree headers were removed. [16:14:25 CET] <nevcairiel> tell them to go send money or shove it [16:14:50 CET] <BtbN> The primary complaint was that nvenc was now no longer automagically enabled in various binary distro builds. [16:15:49 CET] <j-b> the entitlement of some people is amazing [16:17:48 CET] <j-b> JEEB: I should add my "drivers have a GPL exception" in my signature, wdyt? [16:18:00 CET] <JEEB> :D [16:18:13 CET] <j-b> philipl: I have a call with nVidia people next week. Do you have requests? [16:18:16 CET] <j-b> BtbN: same ^^ [16:18:53 CET] <JEEB> RGB input officially supported since they already support 4:4:4 encoding [16:19:08 CET] <BtbN> Pretty sure nvenc supports RGB input? [16:19:26 CET] <JEEB> I think it was still limited to YCbCr [16:19:30 CET] <JEEB> at least the FFmpeg wrapper [16:19:37 CET] <philipl> j-b: Beyond their help with the licencing, I would like a way to use the official deinterlacer as a filter. [16:19:52 CET] <philipl> JEEB: there are rgb0 and 0rgb input formats for nvenc. [16:19:57 CET] <BtbN> The ffmpeg wrapper supports AV_PIX_FMT_0RGB32 and AV_PIX_FMT_0BGR32 inptu [16:20:01 CET] <JEEB> huh [16:20:10 CET] <JEEB> and it doesn't have to be planar? [16:20:23 CET] <JEEB> I would have expected RGBP [16:20:28 CET] <JEEB> GBRP I mean [16:20:44 CET] <JEEB> just stuff it into the three planes and you get lossless RGB encoding :P [16:21:03 CET] <BtbN> Pretty sure it runs a shader internally to convert it to YUV [16:21:13 CET] <j-b> philipl: your goal is to get cuda_nvcc outside of non-free right? libnpp is less important, correct? [16:21:14 CET] <JEEB> currently I have been doing it by feeding it GBRP planes as 4:4:4 YCbCr and then filtering the bit stream [16:21:30 CET] <JEEB> so that the colorspace info in the output H.264 is RGB [16:21:31 CET] <JEEB> vOv [16:21:33 CET] <BtbN> j-b, I mean, I wouldn't mind a source code drop of libnpp, though I think that's highly unlikely. [16:21:41 CET] <j-b> very. [16:21:44 CET] <JEEB> BtbN: yea that's not RGB support - just RGB *input* support :P [16:21:44 CET] <philipl> j-b: for me, that is correct. BtbN has just said by libnpp is important for other users. [16:21:58 CET] <nevcairiel> if cuda stuff could be (L)GPL, then at least we could work towards making npp entirely obsolete and free in the process [16:22:15 CET] <BtbN> indeed [16:22:25 CET] <BtbN> Someone just needs to write the Kernels [16:22:26 CET] <JEEB> they already have 4:4:4 YCbCr support so no real technical reason not to be able to do RGB at that point unless I'm missing something :P [16:23:52 CET] <BtbN> It would cause confusion with the wrapper [16:24:08 CET] <BtbN> How do you tell if it's stuffing RGB into the encoder itself, or converting to YUV? [16:25:10 CET] <JEEB> planar vs packed? [16:25:17 CET] <JEEB> but yes [16:25:27 CET] <JEEB> if we already "support RGB" in the FFmpeg wrapper with the packed ones :P [16:26:00 CET] <JEEB> I know why those magical conversions are there, but at times like these it becomes really derpy [16:26:26 CET] <JEEB> I just don't want to keep on hacking the thing like that - getting RGB encoded for local capture is <3 [19:11:55 CET] <tmm1> i'm trying to track down some bugs in timestamp handling.. anyone have hunches as to what is happening here: https://gist.github.com/tmm1/1a0b04930c88b0a6f652e60ec73843c0 [19:12:44 CET] <JEEB> that's funky [19:12:51 CET] <JEEB> see -debugts ? [19:13:08 CET] <JEEB> that prints out the timestamps in different spots [19:13:19 CET] <JEEB> also, -vsync passthrough might remove some ffmpeg.c logic [19:13:23 CET] <JEEB> together with copyts [19:15:50 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:9664c3a4d40e: avcodec/mpegaudio_parser: Consume more than 0 bytes in case of the unsupported mp3adu case [19:15:50 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:86ba4473fa30: avcodec/mpeg4videodec: Clear partitioned frame in decode_studio_vop_header() [19:15:50 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:92382748e4ad: avcodec/cavsdec: Propagate error codes inside decode_mb_i() [19:15:50 CET] <cone-509> ffmpeg 03Andreas Rheinhardt 07release/4.0:5bdc1e51fd3a: h264_redundant_pps: Fix logging context [19:15:50 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:4b0d040e1837: avcodec/shorten: Fix integer overflow with offset [19:15:51 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:dab6409d84a7: fftools/ffmpeg: Repair reinit_filter feature [19:15:51 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:0e11b2983448: avcodec/pngdec: Check compression method [19:15:52 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:040aa140748a: avcodec/truemotion2: fix integer overflows in tm2_low_chroma() [19:15:52 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:773f58229ff0: avcodec/truemotion2rt: Fix rounding in input size check [19:15:53 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:ee20d64bec7e: avcodec/msmpeg4dec: Skip frame if its smaller than 1/8 of the minimal size [19:15:54 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:f3095068d85d: avcodec/wmv2dec: Skip I frame if its smaller than 1/8 of the minimal size [19:15:55 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:c3e263b862ec: avcodec/msvideo1: Check for too small dimensions [19:15:56 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:7070de99c082: avcodec/ppc/hevcdsp: Fix build failures with powerpc-linux-gnu-gcc-4.8 with --disable-optimizations [19:15:58 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:ff8ba749b439: avcodec/dxv: Check that there is enough data to decompress [19:15:58 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:50ee16431c56: avcodec/clearvideo: Check remaining input bits in P macro block loop [19:15:59 CET] <cone-509> ffmpeg 03chcunningham 07release/4.0:5d9daae62b9c: lavf/mov: ensure only one tkhd per trak [19:16:00 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:b80d50441233: avformat/nutenc: Document trailer index assert better [19:16:01 CET] <cone-509> ffmpeg 03chcunningham 07release/4.0:e02f55a3c5c3: lavf/id3v2: fail read_apic on EOF reading mimetype [19:16:02 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:bd9525b4bf14: avcodec/mjpegdec: Fix indention of ljpeg_decode_yuv_scan() [19:16:03 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:965eddc7ed0c: tests/fate/filter-video: increase fuzz for fate-filter-refcmp-psnr-rgb [19:16:04 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:d0e900187c2d: avformat/mpegts: Fix side data type for stream id [19:16:05 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:b29b6afdfbbf: avcodec/avcodec: Document the data type for AV_PKT_DATA_MPEGTS_STREAM_ID [19:16:06 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:5161e1e61041: avcodec/rpza: Move frame allocation to a later point [19:16:07 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:90d73a207c6a: avcodec/rpza: Check that there is enough data for all the blocks [19:16:08 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:3006a5675c7b: postproc/postprocess_template: Avoid using %4 for the threshold compare [19:16:09 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:33555963259c: postproc/postprocess_template: remove FF_REG_sp from clobber list [19:16:11 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:67bc75d5b1bc: avcodec/fic: Fail on invalid slice size/off [19:16:11 CET] <cone-509> ffmpeg 03gxw 07release/4.0:4dbfbcef1670: avcodec/mips: Fix failed case: hevc-conformance-AMP_A_Samsung_* when enable msa [19:16:12 CET] <cone-509> ffmpeg 03David Bryant 07release/4.0:cdf1dc136caa: avformat/wvdec: detect and error out on WavPack DSD files [19:16:13 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:541b62796256: avcodec/mjpegbdec: Fix some misplaced {} and spaces [19:16:15 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:472498ed473f: avcodec/v4l2_m2m: fix cant typo [19:16:15 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:ab0a8e477242: avformat/libopenmpt: Fix successfull typo [19:16:17 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:96ef96f6ba8f: avcodec/4xm: Fix returned error codes [19:16:17 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:6c2b4c716b1b: avcodec/exr: Check for duplicate channel index [19:16:18 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:11e8ea4d0a85: avcodec/exr: set layer_match in all branches [19:16:19 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:5a9170345a29: avcodec/h264_slice: Fix integer overflow in implicit_weight_table() [19:16:20 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:bf83eadbccbe: avcodec/tests/rangecoder: initialize array to avoid valgrind warning [19:16:22 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:1e09bf4d1028: avcodec/diracdec: Check component quant [19:16:22 CET] <cone-509> ffmpeg 03James Almer 07release/4.0:48ca78728afc: configure: bump year [19:16:23 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:63de02051d72: avutil/mem: Optimize fill32() by unrolling and using 64bit [19:16:25 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:f5c6d42124a4: avutil/imgutils: Optimize memset_bytes() by using av_memcpy_backptr() [19:16:26 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:fcfa104b0e05: avcodec/tiff: Check for 12bit gray fax [19:16:26 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:c600c06af96e: avcodec/fic: Check that there is input left in fic_decode_block() [19:16:27 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:636e66f35001: avformat/rtsp: Clear reply in every iteration in ff_rtsp_connect() [19:16:28 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:a066fc25ca7a: avformat/rtsp: Check number of streams in sdp_parse_line() [19:16:29 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:b9269c960cae: avcodec/pgssubdec: Check for duplicate display segments [19:16:31 CET] <cone-509> ffmpeg 03chcunningham 07release/4.0:12a09ce97514: avformat/mov.c: require tfhd to begin parsing trun [19:16:32 CET] <cone-509> ffmpeg 03chcunningham 07release/4.0:32017af5ef62: avformat/mov: validate chunk_count vs stsc_data [19:16:33 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:d5a946615ffc: avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c() [19:16:34 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:5f799f0cee95: avformat/mov: Do not use reference stream in mov_read_sidx() if there is no reference stream [19:16:34 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:8183623ca38c: avcodec/mpeg4videodec: Clear interlaced_dct for studio profile [19:16:35 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:c50ba3cb6cec: avformat/matroskadec: Do not leak queued packets on sync errors [19:16:36 CET] <cone-509> ffmpeg 03Kevin Backhouse via RT 07release/4.0:381fa4a29d38: avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for tag scaning [19:16:38 CET] <cone-509> ffmpeg 03Kevin Backhouse via RT 07release/4.0:7dc5c930354c: avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for handling braces [19:16:38 CET] <cone-509> ffmpeg 03Wenxiang Qian 07release/4.0:02518ba07fe6: avformat/ftp: Fix Out-of-Bounds Access and Information Leak in ftp.c:393 [19:16:40 CET] <cone-509> ffmpeg 03Wenxiang Qian 07release/4.0:4a9f11129697: avformat/http: Fix Out-of-Bounds access in process_line() [19:16:41 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:f1263f5c7d65: avformat/webmdashenc: Check id in adaption_sets [19:16:42 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:5f52e2c420e0: avcodec/h264_direct: Fix overflow in POC comparission [19:16:43 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:ffaa3c3071ea: avcodec/jvdec: Check available input space before decode8x8() [19:16:43 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:f32ce15f7c0b: avcodec/zmbv: obtain frame later [19:16:44 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:80c881544410: avcodec/mlpdec: Insuffient typo [19:16:45 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:63957591e951: avcodec/error_resilience: Use a symmetric check for skipping MV estimation [19:16:46 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:4ee463b69f30: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int() [19:16:48 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:24e4039c6fa1: avcodec/bethsoftvideo: Check block_type [19:16:48 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:87eecb7d8545: avcodec/gdv: Check for truncated tags in decompress_5() [19:16:49 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:ccf6ca1701d8: avcodec/aic: Check remaining bits in aic_decode_coeffs() [19:16:51 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:36a1939b59f0: avcodec/qpeg: Limit copy in qpeg_decode_intra() to the available bytes [19:16:52 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:8f6d7a454a32: avcodec/scpr: Fix use of uninitialized variable [19:16:53 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:63383dea3b16: avcodec/dxv: Correct integer overflow in get_opcodes() [19:16:54 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:aadce82c5851: avcodec/mpeg4videodec: Check idx in mpeg4_decode_studio_block() [19:16:55 CET] <cone-509> ffmpeg 03Guo, Yejun 07release/4.0:01209d220b36: configure: add missing pthreads extralibs dependency for libvpx-vp9 [19:16:56 CET] <cone-509> ffmpeg 03Guo, Yejun 07release/4.0:33651c09407e: configure: use vpx_codec_vp8_dx/cx for libvpx-vp8 checking [19:16:57 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:1d77b60e3531: avformat/gdv: Check fps [19:16:58 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:09b6cce9ba49: avcodec/cdgraphics: Use ff_set_dimensions() [19:16:58 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:86af0e2a8732: avcodec/dvbsubdec: Check object position [19:16:59 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:599cfce022b3: avcodec/clearvideo: Check remaining data in P frames [19:17:00 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:2a2bc7918727: avcodec/dfa: Check the chunk header is not truncated [19:17:02 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:162b44e110cb: Update for 4.0.4 [19:29:36 CET] <tmm1> hmm looks like maybe the value is changing during timebase conversion from 1/90k to 1001/30k [20:31:38 CET] <cone-509> ffmpeg 03Lou Logan 07master:171f8ee40bd7: doc/mailing-list-faq: ffmpeg-devel is now subscription only [20:38:29 CET] <cone-509> ffmpeg 03Lou Logan 07master:736617408622: MAINTAINERS: remove myself as mailing list maintainer [20:45:46 CET] <tmm1> JEEB: vsync passthrough didn't change anything. i updated the gist with the debug_ts output, looks like coming out of the encoder is where the ts changes [20:48:32 CET] <JEEB> alright [20:59:35 CET] <tmm1> JEEB: figured it out, it is the timebase conversion. updated gist to show the math [21:11:17 CET] <JEEB> hmm [21:11:23 CET] <JEEB> if I have some code that outputs UCS-2 [21:11:34 CET] <JEEB> how simple is it to go from UCS-2 to UTF-8? [21:15:40 CET] <atomnuker> apparently its compatible with utf-16 so same as utf-16 to utf-8 [21:19:32 CET] <JEEB> yea, now i'm just wondering if I should add iconv as a dep or make something up myself [21:21:07 CET] <atomnuker> everyone has iconv, I think [21:21:35 CET] <atomnuker> though everyone has zlib, and I've seen plenty of people complain lavu has no zlib [21:21:47 CET] <JEEB> it just gets a bit corny because I effectively made a thing out of an iconv module that didn't go upstream :P [21:21:56 CET] <JEEB> it even has a test which is nice [22:09:07 CET] <uau> atomnuker: everyone has zlib installed, not everyone has zlib development headers installed [23:14:00 CET] <thardin> got a little tour at one of the local broadcast shops, and a bit of an explanation what the hell ndi is [23:15:46 CET] <thardin> partly a way to pipe video over ethernet as already surmised. but also the codec is idempotent, meaning if you decode it, pipe it over sdi and re-encode it on the other side then you get the same bits [23:16:03 CET] <thardin> and some metadata and control crap [23:55:28 CET] <jdarnley_obs> Is that rfc4175 other than the "metadata and control crap"? [23:58:08 CET] <jdarnley_obs> or maybe hbrmt? [00:00:00 CET] --- Fri Mar 22 2019

1 0

ffmpeg.log.20190321
by burek 22 Mar '19

22 Mar '19

[00:05:45 CET] <retal> furq, thank you ! [00:06:46 CET] <retal> furq, Unknown option "--enable-cuda-nvcc" [00:08:10 CET] <furq> that's a configure option [00:09:54 CET] <retal> furq, yes. i receive error when try configure : ./configure --enable-nvenc --enable-libx264 --enable-gpl --enable-cuda --enable-cuvid --enable-cuda-nvcc [00:10:26 CET] <furq> weird [00:10:28 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L323 [00:10:49 CET] <furq> you do need --enable-nonfree for that but that should give a different error [00:14:48 CET] <retal> furq, with --enable-nonfree same error [00:18:33 CET] <furq> weird [00:18:41 CET] <furq> i don't have an nvidia card so i can't really test [00:19:18 CET] <retal> :( [00:23:53 CET] <faLUCE> is there a way to remove extradata from an avpacket? something that converts framed stream to bytestream .... [00:24:45 CET] <faLUCE> retal: paste the error [00:26:47 CET] <retal> faLUCE, ffmpeg-4.1.1# ./configure --enable-nonfree --enable-nvenc --enable-libx264 --enable-gpl --enable-cuda --enable-cuvid --enable-cuda-nvcc [00:26:48 CET] <retal> Unknown option "--enable-cuda-nvcc". [00:27:47 CET] <faLUCE> retal: try --enable-cuda-sdk [00:27:56 CET] <furq> oh [00:28:01 CET] <furq> yeah it's still --enable-cuda-sdk in 4.1.1 [00:28:07 CET] <furq> i guess it only just got changed [00:29:41 CET] <retal> ERROR: cuda_sdk not found [00:30:21 CET] <faLUCE> retal: do you use linux? which distro [00:30:22 CET] <faLUCE> ? [00:30:37 CET] <retal> Ubintu 18.04 [00:31:09 CET] <faLUCE> wait [00:33:04 CET] <faLUCE> retal: https://developer.nvidia.com/cuda-downloads [00:33:11 CET] <faLUCE> then install it [00:34:57 CET] <retal> so i need download and install CUDA SDK also ? [00:35:35 CET] <faLUCE> what should I do in order to convert framed stream to/from bitstream? is it really necessary to use a filter? something like AVBitStreamFilter ? [00:35:38 CET] <faLUCE> retal: yes [00:35:57 CET] <retal> tnx [00:48:06 CET] <ginel> I'd like to have audio in the output from this: [00:48:07 CET] <ginel> http://paste.debian.net/1074018/ [00:48:27 CET] <ginel> and input 2 (http://site.me:8081/) is an HTTP audio stream [00:48:36 CET] <ginel> I'm not sure how to do it [01:01:03 CET] <ginel> when I try "ffmpeg -i http://site.me:8081/ test.mp3" ffmpeg does identify that input #0 is an mp3 audo stream after a short delay but doesn't actually write anything to file. [01:08:42 CET] <ginel> I figured out the problem. my HTTP stream wasn't working properly [01:18:42 CET] <ginel> is there a way to make ffmpeg continue processing even if an input (an HTTP stream) stops working? [01:19:19 CET] <ginel> I like that it reconnects when it's available again but I don't like that the output just pauses until it does [01:36:07 CET] <retal> faLUCE, I installed CUDA SDK, add /usr/local/cuda-10.1/lib64 to /etc/ld.so.conf [01:36:07 CET] <retal> run ./configure --enable-nonfree --enable-gpl --enable-nvenc --enable-libx264 --enable-cuda-sdk [01:36:07 CET] <retal> Copied headers feom Samples/common/inc/*.h /usr/local/include [01:36:07 CET] <retal> As result: [01:36:07 CET] <retal> ERROR: cuda_sdk not found [01:40:09 CET] <faLUCE> retal: which cuda headers do you have in /usr/local/include ? [01:40:26 CET] <faLUCE> retal: also run "ldconfig" [01:41:14 CET] <faLUCE> but... did you copy manually the headers of cuda ??? [01:41:51 CET] <retal> ldconfig applied [01:41:56 CET] <retal> i have: common.mk ffnvcodec helper_functions.h helper_string.h libavformat multithreading.h nvShaderUtils.h rendercheck_d3d11.h x264_config.h [01:41:57 CET] <retal> drvapi_error_string.h GL helper_gl.h helper_timer.h libavutil nvMath.h nvVector.h rendercheck_d3d9.h x264.h [01:41:57 CET] <retal> dynlink_d3d10.h helper_cuda_drvapi.h helper_image.h libavcodec libpostproc nvMatrix.h paramgl.h rendercheck_gles.h [01:41:57 CET] <retal> dynlink_d3d11.h helper_cuda.h helper_math.h libavdevice libswresample nvQuaternion.h param.h rendercheck_gl.h [01:41:59 CET] <retal> exception.h helper_cusolver.h helper_multiprocess.h libavfilter libswscale nvrtc_helper.h rendercheck_d3d10.h timer.h [01:42:08 CET] <retal> yes i manualy copied [01:42:31 CET] <faLUCE> retal: no, never manually copy!! [01:42:49 CET] <faLUCE> why did you do that? [01:42:59 CET] <retal> :) [01:43:25 CET] <faLUCE> why did you do that? [01:44:18 CET] <retal> i remember before cople years ago manualy copy files from Samples/common/inc/*.h to /usr/local/include :) [01:45:37 CET] <faLUCE> you don't have to do that. first of all, copying headers doesn't mean that a library is installed [01:45:55 CET] <faLUCE> (you have to put in right places also the binary files) [01:46:30 CET] <faLUCE> now, chech the install command of the install script, and execute that. But remove the manually copied headers firstly [01:46:38 CET] <faLUCE> (check) [01:47:24 CET] <jab416171> frame= 733 fps= 16 q=30.0 size= 27392kB time=00:00:18.72 bitrate=11985.5kbits/s dup=0 drop=1354 speed=0.401x [01:47:29 CET] <jab416171> does this mean frames are being dropped? and why? [01:47:49 CET] <retal> sh cuda_10.1.105_418.39_linux.run [01:47:50 CET] <retal> then copied files [01:48:25 CET] <faLUCE> retal: you are not following what I said [01:48:33 CET] <faLUCE> 1) remove the manually copied files [01:48:39 CET] <retal> ok [01:48:53 CET] <faLUCE> 2) use the INSTALL feature of the script [01:49:05 CET] <faLUCE> I mean: don't copy manually the files [01:56:29 CET] <retal> faLUCE, i removed files, uninstalled CUDA with cuda-uninstaller, and reinstalled with command: sh cuda_10.1.105_418.39_linux.run [01:57:14 CET] <faLUCE> are sure they are installed? did you sudo the command? [01:57:53 CET] <retal> = Summary = [01:57:54 CET] <retal> =========== [01:57:54 CET] <retal> Driver: Installed [01:57:54 CET] <retal> Toolkit: Installed in /usr/local/cuda-10.1/ [01:57:54 CET] <retal> Samples: Installed in /home/user/, but missing recommended libraries [01:57:54 CET] <retal> Please make sure that [01:57:56 CET] <retal> - PATH includes /usr/local/cuda-10.1/bin [01:57:58 CET] <retal> - LD_LIBRARY_PATH includes /usr/local/cuda-10.1/lib64, or, add /usr/local/cuda-10.1/lib64 to /etc/ld.so.conf and run ldconfig as root [01:58:33 CET] <faLUCE> ok, as said before, run ldconfig [01:58:35 CET] <faLUCE> (as root) [01:58:51 CET] <retal> alredy raned [01:59:07 CET] <faLUCE> ok, now try to configure again [01:59:53 CET] <retal> ./configure --enable-nonfree --enable-gpl --enable-nvenc --enable-libx264 --enable-cuda-sdk [01:59:53 CET] <retal> ERROR: cuda_sdk not found [02:01:10 CET] <faLUCE> retal: [01:57] <retal> Samples: Installed in /home/user/, but missing recommended libraries [02:01:20 CET] <faLUCE> it seems that libraries are not installed [02:01:54 CET] <faLUCE> now, look at /usr/local/cuda-10.1/bin,... what is there? [02:02:21 CET] <faLUCE> in addition: did you SUDO the install script ? [02:03:53 CET] <retal> Install script i run from root [02:03:55 CET] <retal> bin2c crt cuda-gdb cuda-install-samples-10.1.sh cuda-uninstaller fatbinary nsight nvcc nvdisasm nvprof nvvp [02:03:56 CET] <retal> computeprof cudafe++ cuda-gdbserver cuda-memcheck cuobjdump gpu-library-advisor nsight_ee_plugins_manage.sh nvcc.profile nvlink nvprune ptxas [02:04:22 CET] <faLUCE> ok, retal what's the output of: echo $PATH [02:05:15 CET] <retal> bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games: No such file or directory [02:05:50 CET] <faLUCE> ok, and what is the output of: "echo $LD_LIBRARY_PATH" ? [02:08:56 CET] <faLUCE> (in short: you have to change that vars) [02:09:16 CET] <retal> faLUCE, its empty :( [02:09:33 CET] <faLUCE> ok, first of all: [02:09:34 CET] <retal> but i added /usr/local/cuda-10.1/lib64 to /etc/ld.so.conf [02:10:19 CET] <faLUCE> execute: PATH=$PATH:/usr/local/cuda-10.1/bin [02:10:47 CET] <retal> done [02:10:53 CET] <faLUCE> then echo $PATH again and see if it outputs the cuda dir too [02:11:14 CET] <retal> i see output [02:11:26 CET] <faLUCE> do you see the cuda dir too, in the output? [02:11:47 CET] <retal> yes - usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/cuda-10.1/bin [02:11:56 CET] <faLUCE> ok, try to configure again ffmpeg [02:12:10 CET] <faLUCE> if it fails we have to adjust LD_LIBRARY_PATH too [02:13:33 CET] <faLUCE> also: be sure to not configure as root. and be sure that "echo $PATH" shows the cuda dir when executed as normal user (non root) [02:15:21 CET] <retal> Aded LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda-10.1/bin [02:15:31 CET] <retal> again same error [02:15:32 CET] <retal> :) [02:16:15 CET] <faLUCE> no, this is not the library path [02:16:39 CET] <faLUCE> this is the path for the executables [02:17:07 CET] <XXXmaker> hy do i get 100 error when i convert .wma to .opus https://pastebin.com/pE62qS52 [02:17:13 CET] <faLUCE> you have to figure where the library is installed. Check what is inside /usr/local/cuda-10.1/ [02:17:26 CET] <faLUCE> if there are .so files [02:18:17 CET] <retal> sorry shuld be /usr/local/cuda-10.1/lib64 [02:18:39 CET] <faLUCE> yes, check if inside that dir there are the libraries [02:19:30 CET] <XXXmaker> hy do i get 100 error when i convert .wma to .opus https://pastebin.com/pE62qS52 [02:19:33 CET] <retal> yes its libs libaccinj64.so libcuinj64.so.10.1 libnppc.so.10 libnppidei_static.a libnppisu.so.10 libnvjpeg_static.a [02:19:34 CET] <retal> libaccinj64.so.10.1 libcuinj64.so.10.1.105 libnppc.so.10.1.105 libnppif.so libnppisu.so.10.1.105 libnvrtc-builtins.so [02:19:34 CET] <retal> libaccinj64.so.10.1.105 libculibos.a libnppc_static.a libnppif.so.10 libnppisu_static.a libnvrtc-builtins.so.10.1 [02:19:47 CET] <faLUCE> ok, now add THAT dir to LD_LIBRARY_PATH [02:20:15 CET] <retal> added but same error [02:20:24 CET] <faLUCE> run also ldconfig [02:20:27 CET] <faLUCE> as root [02:20:30 CET] <faLUCE> sudo ldconfig [02:20:45 CET] <faLUCE> and configure again [02:22:55 CET] <retal> doest work [02:23:13 CET] <faLUCE> doesn't ? [02:23:20 CET] <retal> no [02:23:29 CET] <retal> echo $LD_LIBRARY_PATH [02:23:30 CET] <retal> :/usr/local/cuda-10.1/bin:/usr/local/cuda-10.1/lib64 [02:23:44 CET] <retal> may be i shuld delete :/usr/local/cuda-10.1/bin [02:23:47 CET] <retal> ? [02:23:51 CET] <faLUCE> no, not necessary [02:24:14 CET] <pink_mist> I don't think it'll work right with a leading : [02:24:21 CET] <retal> from LIBRARY PATH i mean [02:24:21 CET] <faLUCE> but try to add /usr/local/cuda-10.1 to LD_LIBRARY_PATH [02:24:30 CET] <faLUCE> without "lib64" [02:24:55 CET] <faLUCE> pink_mist: right [02:26:13 CET] <faLUCE> retal: then just exec: "LD_LIBRARY_PATH=/usr/local/cuda-10.1/bin:/usr/local/cuda-10.1/lib64:/usr/local/cuda-10.1" [02:27:11 CET] <retal> same problem [02:27:15 CET] <faLUCE> (anyway, something is strange/or broken in the installation from script... the user should not have to set these things) [02:27:40 CET] <faLUCE> ok, wait, I try to install it [02:27:59 CET] <retal> faLUCE, yes yestordrday i will try reinstall, sorry now i shuld go [02:28:21 CET] <retal> faLUCE, at morning i wil retry from scrach [02:28:26 CET] <retal> thank you ! [02:28:33 CET] <faLUCE> night [02:28:57 CET] <retal> faLUCE, have good night [02:30:36 CET] <XXXmaker> why do i get 100 error when i convert .wma to .opus https://pastebin.com/pE62qS52 [02:34:02 CET] <TheAMM> XXXmaker: Because the timestamps are non-monotonous [02:34:17 CET] <TheAMM> If the opus sounds fine, you can probably just ignore the warnings [02:34:24 CET] <TheAMM> wma is wma [02:34:44 CET] <XXXmaker> theamm what does it mean if "timestamps are non-monotonous" [02:35:02 CET] <TheAMM> "Queue input is backward in time" [02:35:22 CET] <XXXmaker> TheAMM then explain why converting .wma to .aac only gives 2 errors [02:35:35 CET] <XXXmaker> and .wma to .flac gives me 0 errors [02:35:36 CET] <DHE> it means the dts between subsequent calls to av_write_frame() (with the same steam index) must be strictly larger than the previous [02:35:45 CET] <another> also: https://en.wikipedia.org/wiki/Monotonic_function [02:36:08 CET] <XXXmaker> only errors converting to .aac ttps://pastebin.com/pE62qS52 [02:36:19 CET] <XXXmaker> i mean https://pastebin.com/HVGutYGx [02:36:25 CET] <XXXmaker> https://pastebin.com/HVGutYGx [02:36:36 CET] <XXXmaker> only 2 errors converting to .aac https://pastebin.com/HVGutYGx [02:36:41 CET] <TheAMM> Does the resulting file sound okay [02:37:47 CET] <XXXmaker> TheAMM 2 hour audio so i haven't really tested it [02:38:02 CET] <XXXmaker> theamm explain why i get 0 error converting that same .wma to .flac then [02:38:18 CET] <TheAMM> Why so demanding [02:38:33 CET] <XXXmaker> TheAMM sorry [02:38:41 CET] <XXXmaker> i wasn't trying to [02:38:53 CET] <TheAMM> Maybe flac can handle out of order samples or something, how would I know [02:39:10 CET] <TheAMM> I just looked at your paste and read the warnings [02:39:18 CET] <TheAMM> It's said all in there [02:39:58 CET] <TheAMM> I do know you're working with wma and I do know not to expect anything good from wma [02:40:26 CET] <TheAMM> Check your resulting files, if they sound fine then they sound fine and you can ignore the warnings and give it a rest [02:45:29 CET] <XXXmaker> when i look up mediainfo on .flac file, it tells you the bit depth whether it's 16bit or 24bit or 8bit, how do i tell the bit depth of .opus or .aac file [02:47:03 CET] <another> afaik bit depth doesn't really apply to lossy audio [03:04:03 CET] <kepstin> yeah, "bit depth" just refers to the storage size and quantization of pcm audio, but lossy codecs take the audio apart with transformations, filters, mdct and whatnot and then quantize and reduce the result of that... so there's no real way to assign any number of bits in the result to a certain sample. [03:04:35 CET] <kepstin> fwiw, i think many of the decoders for lossy codecs in ffmpeg actually end up returning floating point (32bit) samples after decoding. [05:06:48 CET] <XXXmaker> strong-intra-smoothing=x rect=x for these 2 options should i use 1 or 0 ? [05:36:41 CET] <kepstin> XXXmaker: where do you see those option names? they're not something i recognize [05:36:58 CET] <XXXmaker> i see them in x265 options [05:38:19 CET] <kepstin> don't bother manually setting x265 options, just use the presets [05:40:37 CET] <kepstin> the x265 docs say the strong-intra-smoothing option is on by default, and the rect option is enabled starting with the "slow" preset. [06:12:29 CET] <XXXmaker> kepstin are you ffmpeg dev ? [07:04:34 CET] <XXXmaker> why doesn't ffmpeg aac_fdk support VBR ? [10:01:36 CET] <spotter> I'm having a weird issue with ffmpeg when I'm trying to use it to cut an mp4. namely, I'm using -ss and -t to specify the cut and using -c:v copy and -c:a copy as not a transcode. I'd expect the cut to start on an iframe (-ss man page seems to indicate that its adjusted to go to the last iframe before the -ss timestamp) but it doesn't seem to be happening. I get audio without video till it hits the next iframe. [10:11:54 CET] <pink_mist> spotter: that might depend on if you place the -ss and -t before or after the -i [10:12:11 CET] <pink_mist> I think [10:13:55 CET] <JEEB> the cuts should always be at samples noted as RAPs [10:14:02 CET] <JEEB> (random access points) [10:14:35 CET] <XXXmaker> is there any good GUI frontend for ffmpeg ? [10:15:14 CET] <JEEB> XXXmaker: FFmpeg (adn even the example CLI API client ffmpeg.c) does so many things you can't possibly have a good front-end that tries to do all things :P [10:15:32 CET] <XXXmaker> okay [10:15:36 CET] <XXXmaker> why doesn't ffmpeg aac_fdk support VBR ? [10:15:49 CET] <JEEB> probably because the fdk-aac library doesn't? [10:15:58 CET] <JEEB> it's just a wrapper around fdk-aac after all [10:16:14 CET] <XXXmaker> you mean fdk_aac doesn't support VBR? [10:16:21 CET] <JEEB> spotter: the one thing that can lead to funky stuff is the google-added "advanced edit list" stuff [10:16:35 CET] <JEEB> try setting -advanced_editlist 0 before input [10:18:45 CET] <JEEB> spotter: but as far as I know with mp4 output it can also attempt to use a simple edit list on the output side to make things work. so it cuts at the start of the GOP which contains the timestamp you note. and then adjusts the time line so that video only starts playing at the point where you requested [10:18:55 CET] <JEEB> too bad many players ignore that thing [10:23:35 CET] <JEEB> if you actually are getting cuts on a non-RAP then something's wrong of course :P [10:23:46 CET] <JEEB> either the input is borked, or FFmpeg is borked [10:24:11 CET] <JEEB> but yea, try disabling the GOOG-authored advanced edit list stuff first [13:37:38 CET] <ncouloute> So this file is still giving me issues. I noticed that using h264 decoder it is only decoding 16067 frames; compared to using h264_qsv (17248) or h264_cuvid (17250).. Any idea how to go about fixing that? [13:39:35 CET] <Mavrik> You're not flushing it perhaps? [13:39:46 CET] <Mavrik> That is, passing null packets until it stops emitting frames? [13:39:55 CET] <Mavrik> Although 1000+ frames difference is a lot :) [13:43:17 CET] <ncouloute> Not sure what that means exactly but I'm using "ffmpeg -i path-to-mp4 vsync 0 -f null -" Tried to take out everything possible to narrow it down. [14:07:11 CET] <ncouloute> I'm assuming you are talking about the ffmpeg api perhaps? Time is correct but several frames are missing when I output to a file. Error wise I have 5 "reference picture missing during reorder/Missing reference picture default is x" errors that pop up and 1 Application provided invalid non monotonically increasing dts to muxer in stream 0: 960>=960 [14:29:47 CET] <ncouloute> meh got disconnected [14:33:13 CET] <dongs> nobody answered your question anyway . [14:33:20 CET] <ncouloute> lol :( [14:36:56 CET] <JEEB> ncouloute: either different handling of broken packets (more likely) or the google advanced edit list feature for some reason only breaks the internal decoder. latter you can check by defining -advanced_editlist 0 before the input [14:37:17 CET] <JEEB> in theory it should break both the hardware decoders and the sw one the same way [14:51:56 CET] <ncouloute> Same thing with -advanced_editlist 0. I also tried using -enable_er 1. So what options do I have. I tried playing around with *synth apps but getting similar results after deinterlacing. =/ [14:52:48 CET] <JEEB> then I would guess the only way to figure out would be to make a bug ticket about it with a sample where this happens and that can be shared with the community [14:54:55 CET] <debianuser> XXXmaker: "why doesn't ffmpeg aac_fdk support VBR ?" -- It does. I use it all the time: `-acodec libfdk_aac -vbr 3 -cutoff 20000` [15:03:15 CET] <ncouloute> gotcha so I need to make a bug ticket. I can use the gpu decoders for now as a workaround. [15:06:22 CET] <JEEB> well we still don't know which way it goes. do the hw decoders output useful pictures in those failure cases? [15:06:32 CET] <JEEB> but as I said, further stuff isn't possible without a sample [15:09:09 CET] <aboxer> Can anyone comment on state of FFMpeg's closed captioning support ? [15:09:24 CET] <aboxer> cea 608, cea 708 , SEI ? [15:10:16 CET] <aboxer> I have a MOV that I think has 708 CCs, and with ffprobe, I get "Unsupported codec with id 0 for input stream 2" [15:10:42 CET] <aboxer> Stream #0:2(eng): Data: none (tmcd / 0x64636D74) (default) [15:12:21 CET] <JEEB> aboxer: FFmpeg supports the in-video stream stuff from MPEG-2 Video, AVC and HEVC [15:12:33 CET] <JEEB> the problem is that streams within a stream are kind of special [15:12:41 CET] <JEEB> and thus ffmpeg.c doesn't work with them [15:12:57 CET] <JEEB> tmcd I'm not sure if they're captions [15:13:06 CET] <JEEB> would have to check my MOV/ISOBMFF references [15:13:53 CET] <aboxer> thanks JEEB [15:14:33 CET] <DHE> I know mpv can play those video-embedded captions based on my own over-the-air broadcasts received by local hardware [15:14:50 CET] <aboxer> thanks, I got this playing with VLC also [15:15:03 CET] <JEEB> yes. they're side data and mpv (and other FFmpeg API clients) dynamically create a new track as they receive the side data [15:15:12 CET] <JEEB> ffmpeg.c is just so static [15:15:13 CET] <aboxer> can ffprobe identify the type of CCs in separate stream ? [15:15:25 CET] <aboxer> right [15:15:36 CET] <DHE> you'll see "Closed captions" indicated by ffprobe on the video stream line [15:16:00 CET] <JEEB> aboxer: if the mapping for that kind of stream is available, it should be noted as subtitles and the codec should be the caption one [15:16:34 CET] <aboxer> ahhh, so the fact that the codec is unknown means that there is no mapping ? [15:17:26 CET] <JEEB> yes [15:17:32 CET] <JEEB> tmcd IIRC were just timecodes though [15:17:38 CET] <aboxer> yes time codes [15:17:43 CET] <JEEB> if I recall my MOV stuff [15:17:49 CET] <aboxer> so that isn't the CC stream then [15:17:51 CET] <aboxer> ? [15:17:59 CET] <JEEB> loldunno [15:18:10 CET] <aboxer> ok, thanks guys [15:18:11 CET] <JEEB> I'm at $dayjob so I am not going start going through specs right now [15:18:15 CET] <ritsuka> yes tmcd is timecode [15:18:26 CET] <aboxer> haha got it [15:18:36 CET] <ritsuka> closed caption is c608 or c708 [15:18:42 CET] <JEEB> yes, that's how I remember it [15:18:49 CET] <JEEB> thank you for reminding me :) [15:20:05 CET] <aboxer> so what is stored in tmcd then? [15:20:12 CET] <aboxer> time codes for what ? [15:20:22 CET] <JEEB> I think it was just the initial time code and then the frame rate type [15:20:28 CET] <aboxer> aha ok [15:21:05 CET] <aboxer> so, the fact that VLC plays CCs for this file, but ffmpeg does not, can we deduce the type of CCs ? [15:21:16 CET] <JEEB> not without further info [15:21:19 CET] <aboxer> they are not separate stream [15:21:28 CET] <JEEB> ah [15:21:35 CET] <JEEB> use ffprobe and -show_packets with the video stream :P [15:21:44 CET] <JEEB> output json or so to make it more readable [15:22:47 CET] <JEEB> ffprobe -i welp.mov -of json -show_packets -show_streams -select_streams ':2' > welp.mov.json [15:22:53 CET] <JEEB> argh no [15:23:01 CET] <JEEB> ffprobe -i welp.mov -of json -show_packets -show_streams -select_streams v > welp.mov.json [15:23:05 CET] <JEEB> that [15:23:07 CET] <JEEB> :V [15:23:12 CET] <JEEB> since you don't want 0:2 which is the tmcd track [15:23:15 CET] <JEEB> but you want the video track [15:23:23 CET] <JEEB> now you can start crawling through that and checking the side data [15:23:31 CET] <JEEB> (did this require decoding?) [15:25:12 CET] <faLUCE> Hello. I would like to extract the extradata value from a sequence of h264 bitstream encoded avpackets. How could I do that? I see that there are filters, which one should I call? [15:25:35 CET] <aboxer> thanks! will give that a go [15:26:49 CET] <JEEB> AV_FRAME_DATA_A53_CC [15:26:53 CET] <JEEB> ok, it requires decoding [15:27:01 CET] <JEEB> switch from show_packets to show_frames [15:27:14 CET] <JEEB> and you can limit the frame count to decode if it's a long file [15:27:59 CET] <JEEB> oh there's also AV_PKT_DATA_A53_CC ? [15:28:04 CET] <JEEB> (Ž4@) [15:28:13 CET] <JEEB> if it shows up in AVpackets (show_packets) great [15:29:11 CET] <aboxer> AV_PKT_DATA_A53_CC would show up in json ? [15:29:15 CET] <ncouloute> JEEB: the output from sw decoder is not smooth it locks up between scene changes during playback. the output from hw decoders is smooth. I can see if I can get another file as a sample as this file cant be distributed. [15:29:21 CET] <JEEB> yes, under side data [15:29:47 CET] <JEEB> aboxer: it should list the types of side data attached to packets (or frames, with show_frames) [15:30:47 CET] <aboxer> oh, great! I see this now [15:31:00 CET] <aboxer> "side_data_type": "ATSC A53 Part 4 Closed Captions" [15:31:03 CET] <JEEB> yup [15:31:16 CET] <aboxer> fantastic, thanks [15:33:14 CET] <aboxer> so, ffmpeg doesn't support display for these ATSC A53 captions ? [15:45:41 CET] <DHE> a quick source search doesn't turn up an obvious CC decoder. the raw data is there, but no obvious means of using it beyond copying them unmodified during transcodes [15:46:40 CET] <JEEB> there's a decoder [15:47:07 CET] <JEEB> aboxer: ffmpeg.c is so static that it cannot just make up a new stream (and utilize it) during runtime [15:47:46 CET] <aboxer> thanks DHE [15:47:48 CET] <JEEB> there's one way to utilize them, but it's basically using an input thing that auto-generates a subtitle stream for captions [15:47:51 CET] <JEEB> even if there are no captions [15:47:58 CET] <JEEB> that way the subtitle stream is always there [15:48:05 CET] <aboxer> JEEB: so the decoder could store to separate file, but not display ? [15:48:15 CET] <aboxer> store the CCs [15:48:23 CET] <JEEB> no, having a decoder means you get the text [15:48:29 CET] <JEEB> and that's why mpv can show them [15:48:31 CET] <JEEB> DHE: libavcodec/ccaption_dec.c [15:49:00 CET] <JEEB> you have to at the very least make your own AVPackets from the side data, and initialize a decoder [15:49:03 CET] <JEEB> that's what mpv does [15:49:18 CET] <aboxer> right. I get it. So, as currently designed, ffmpeg cannot display CCs stored as side data ? [15:49:27 CET] <aboxer> but it can store as text [15:50:19 CET] <JEEB> uhh [15:50:24 CET] <JEEB> ffmpeg.c has limitations [15:50:26 CET] <JEEB> FFmpeg doesn't [15:51:13 CET] <aboxer> aha, I see [15:51:38 CET] <JEEB> there's some examples how to utilize the captions through ffmpeg.c [15:52:13 CET] <aboxer> great, it's very useful just being able to identify the type of CC [15:53:11 CET] <aboxer> one other question: could cea608 be also stored in side data? Or can I be sure this is 708 ? [15:53:28 CET] <aboxer> I understand that cea608 is usually in line 21 [15:54:46 CET] <JEEB> the stuff in video streams usually is 708, but what 99% of all people utilize is the mandatory 608 data in 708 [15:55:45 CET] <aboxer> oh, interesting, so 708 is superset of 608 [15:56:01 CET] <JEEB> well, the digital captions are required to have 608 [15:56:03 CET] <JEEB> IIRC [15:56:07 CET] <JEEB> I might be incorrect of course [15:56:44 CET] <aboxer> ok, so line 21 for analog, and side data 708 for digital video [15:56:56 CET] <JEEB> you can also have line 21 in digital video still [15:57:00 CET] <JEEB> but that's harder to probe for :P [15:57:06 CET] <aboxer> oh, [15:57:08 CET] <aboxer> yeah [15:57:16 CET] <aboxer> great, thanks [15:57:21 CET] <JEEB> usually it shows up like the video being of higher resolution than usual etc [15:57:41 CET] <aboxer> right, so height is larger [16:00:55 CET] <DHE> JEEB: OOOooo... decoder... [16:01:08 CET] <JEEB> there's no encoder tho, unfortunately [16:01:22 CET] <JEEB> I've been looking into if there was some well established library that we could base on [16:01:33 CET] <DHE> that's okay. I actually have a different reason to be interested [16:01:35 CET] <JEEB> since internet streaming, esp. live streams, are still a shitshow [16:01:51 CET] <JEEB> and somehow US style closed captions are the least insane way of getting things done [16:01:52 CET] <DHE> filters that affect the framerate (eg: some deinterlacers) effectively corrupt the closed caption stream right now [16:02:00 CET] <JEEB> yea [16:02:16 CET] <DHE> that's something I want to fix. [16:02:39 CET] <DHE> I have a custom git branch here with 2 or 3 tiny fixes I also need to publish to the mailing list or something. [16:03:18 CET] <kepstin> if you see a 486 line height ntsc video capture, then line 21 will be the second line in the frame. 480 line ntsc video usually cuts the top 5 or 6 lines off. [16:04:14 CET] <aboxer> so, line 21 == line 2, nice :) [16:05:20 CET] <kepstin> (iirc, a bunch of pro capture stuff, especially things dealing with sdi, will have 486 line capture modes - mostly to preserve captions and other stuff encoded in those lines) [16:05:58 CET] <aboxer> very interesting, thanks [16:16:12 CET] <kepstin> consumer capture cards - at least the pci ones i've used - typically don't include the caption line in the image frame but instead have an api to retrieve it separately. [17:22:06 CET] <spotter> JEEB, getting back to earlier Q, advanced_editlist doesn't exist in my ffmpeg (3.4.4 provided by ubuntu) [17:24:26 CET] <spotter> what I'm trying to do is remove the "quiet time" from videos (albiet with a second or so of the quiet time left in so it doesn't have as much of a jarring impact of incongruous sound to sound [17:25:31 CET] <spotter> so trying to use silencedetect to figure out the sections and then cut and stich together, but when I play my cuts, it video doesn't start at t=0 [17:28:01 CET] <cc0> hey, what does "program" mean in ffprobe? as in "-show_programs" [17:35:04 CET] <pink_mist> I believe it's something related to transport streams [17:35:07 CET] <pink_mist> .ts files that is [17:43:55 CET] <JEEB> cc0: if the input has AVPrograms, it shows those. MPEG-TS programs are the initial thing where those were utilized [17:50:23 CET] <DHE> mpegts is a bit of a special snowflake in that regard. a single mpegts stream can carry multiple TV channels. Around here some over-the-air broadcasts may contain both an HD and SD version of the same channel on the same frequency. [17:50:32 CET] <DHE> those would be 2 different programs [17:56:58 CET] <aboxer> JEEP: what about 608 inside of 708 ? is there support for this ? and a way of detecting this ? [17:57:14 CET] <aboxer> JEEB [17:58:09 CET] <aboxer> I mean 608 stored in side data [17:58:17 CET] <aboxer> no 708 [17:58:22 CET] <spotter> the answer to my problem seems to be that its picking the iframe "after" -ss and setting pkt_pts_time to the delta between tht frame at -ss (so pkt_pts_time for first frame isn't 0) [18:00:41 CET] <spotter> closet I can get for first frame is pkt_pts_time=0.035000 [18:03:42 CET] <spotter> i.e. if I set -ss to be 10, and the next iframe is at 11, it will use tht iframe as the first frame with a pkt_pts_time as 1 [18:04:22 CET] <spotter> if there's an iframe at 9, I really want it to pick that frame as as the first frame and set its pkt_pts_time to 0 (not -1) [18:44:35 CET] <intrac> is there a way to change the default 10 sec seek time for left/right keys with ffplay? [18:44:40 CET] <intrac> (GOP structure permitting) [18:44:54 CET] <intrac> I'd like to seek in 5 sec steps [18:47:53 CET] <kepstin> intrac: ffplay is a demo player, consider using something like mpv which can be programmed to do that sort of thing. [18:49:57 CET] <|szn-r|> why doesn't ffmpeg aac_fdk support VBR ? [18:50:29 CET] <furq> how many nicks do you need [18:50:42 CET] <|szn-r|> huh [18:51:33 CET] <pink_mist> |szn-r|: <debianuser> XXXmaker: "why doesn't ffmpeg aac_fdk support VBR ?" -- It does. I use it all the time: `-acodec libfdk_aac -vbr 3 -cutoff 20000` [18:51:56 CET] <intrac> kepstin: ah, great. I wasn't aware of that. I tried mplayer but the seek performance was poor [18:52:00 CET] <intrac> mpv is similar to ffplay. nice. [18:52:09 CET] <|szn-r|> what does "-cutoff" do [18:53:31 CET] <kepstin> |szn-r|: it adjusts a lowpass filter in the encoder. By default fdk_aac uses a kind of low frequency limit at lower bitrates, and depending on audio content, it might sound better with a higher cutoff. [18:54:01 CET] <|szn-r|> kepstin i see, are you a ffmpeg dev? [18:54:40 CET] <kepstin> |szn-r|: i have made a couple patches that have been merged, but i don't have commit access or anything. [18:54:43 CET] <|szn-r|> pink_mist then why do i get this error: [libfdk_aac @ 040d6920] Note, the VBR setting is unsupported and only works with some parameter combinations [18:54:53 CET] <|szn-r|> kepstin i see [18:55:20 CET] <pink_mist> I haven't the faintest idea. I'm not the one that claimed it supported it. that was debianuser. I only copied his line to you since it seemed like you had missed it when he said it. [18:55:29 CET] <intrac> kepstin: thanks [18:55:30 CET] <|szn-r|> pink_mist i see [18:55:40 CET] <kepstin> |szn-r|: bad wording in the message. "unsupported" here means that we can't help you if it breaks - there's no user support [18:58:35 CET] <|szn-r|> kesptin okay, then why does only libfdk show that warning message and not the other codecs [19:02:49 CET] <kepstin> |szn-r|: because that's a message specific to the libfdk-aac codec [19:05:09 CET] <|szn-r|> kepstin it doesn't work: Bit rate mode : Constant [19:05:22 CET] <kepstin> |szn-r|: where do you see that? [19:05:32 CET] <|szn-r|> https://superuser.com/questions/1326239/encoding-aac-from-wav?rq=1 somebody else is having same problem as me [19:05:37 CET] <|szn-r|> that's not my post [19:05:57 CET] <|szn-r|> kepstin mediainfo [19:05:57 CET] <kepstin> that person's setting a different profile [19:06:07 CET] <kepstin> it should work fine in aac_lc (the default) [19:06:45 CET] <|szn-r|> ffmpeg -i jake.mp3 -acodec libfdk_aac -vbr 3 jake.m4a [19:07:21 CET] <furq> mediainfo is wrong as usual [19:08:36 CET] <|szn-r|> furq what makes you think mediainfo is wrong? [19:09:06 CET] <|szn-r|> furq do you get the same error when you use libdk_aac ? [19:13:54 CET] <|szn-r|> what does this do? -f lavfi [19:14:53 CET] <faLUCE> is mpv made with lavc ? [19:15:06 CET] <kepstin> |szn-r|: sets the format to lavfi [19:15:27 CET] <|szn-r|> kepstin and if i don't use that option , then what happens? [19:15:48 CET] <kepstin> faLUCE: mpv uses libavcodec,libavformat, etc. for most of its file reading and decoding (some of the filtering uses libavfilter too) [19:16:34 CET] <kepstin> |szn-r|: if you don't specify any -f option, ffmpeg attempts to autodetect format from filename/protocol/probing [19:16:57 CET] <|szn-r|> what other format is there other than lavfi that ffmpeg supports? [19:17:11 CET] <JEEB> -demuxers lists them [19:17:14 CET] <JEEB> for input [19:17:21 CET] <JEEB> -muxers for output [19:17:30 CET] <furq> oh fun [19:17:42 CET] <furq> so mediainfo is still wrong but apparently the ffmpeg m4a muxer is setting a flag wrong [19:17:44 CET] <JEEB> and yes, those include libavdevice things [19:17:49 CET] <furq> at least differently to l-smash [19:18:15 CET] <furq> https://clbin.com/ikLiu [19:18:24 CET] <|szn-r|> jeeb that list like 25+ ; i am so confused [19:18:28 CET] <furq> ffmpeg on the left obviously [19:18:47 CET] <|szn-r|> why would somebody use this option -f lavfi ? [19:19:06 CET] <JEEB> because they want their input to come from the lavfi libavdevice [19:19:14 CET] <JEEB> which utilizes libavfilter blah blah [19:19:59 CET] <|szn-r|> is lavfi the most popular format ? [19:20:18 CET] <JEEB> it is a thing for very specific use cases [19:20:19 CET] <kepstin> lavfi isn't a real format at all, it's a virtual input device for special use cases [19:20:40 CET] <JEEB> in most cases you just point libavformat at a file name and it will probe/figure out what your input is :P [19:20:40 CET] <|szn-r|> then what is most popular format? [19:20:44 CET] <kepstin> in theory, most of the stuff you can do with -f lavfi you can also do with -filter_complex, but sometimes creating a virtual input device makes more sense for a particular use case. [19:20:46 CET] <JEEB> why would you care? [19:20:54 CET] <kepstin> how would we know? [19:20:54 CET] <JEEB> your input is what your input is [19:21:17 CET] <JEEB> unless you're trying to make a specification for what you will take in as input [19:21:19 CET] <JEEB> or something [19:21:26 CET] <JEEB> as in, what other people pass on to you [19:21:27 CET] <JEEB> :P [19:22:25 CET] <|szn-r|> furq , so are you convinced that it's mediainfo's fault? [19:24:34 CET] <kepstin> |szn-r|: well, your audio is definitely vbr, it's just that ffmpeg doesn't seem to be indicating that in the file in the way mediainfo understands. [19:25:52 CET] <|szn-r|> kepstin do you also get this error? Note, the VBR setting is unsupported [19:26:04 CET] <kepstin> that's not an error [19:26:14 CET] <|szn-r|> kepstin do you also get this warning? Note, the VBR setting is unsupported [19:27:31 CET] <kepstin> it's a message printed whenever you use the -vbr option with the libfdk_aac codec, indicating that the vbr option doesn't work with all parameter combinations, and is thus its use is not supported (meaning: "user support is not provided") by ffmpeg devs. [19:28:40 CET] <kepstin> but if you're not doing anything really unusual - sticking to stereo audio at common sample rates - it should be fine. [19:30:05 CET] <aboxer> how common is it to have cea608 closed captions in the mpeg side data, instead of 708 ? [19:30:11 CET] <|szn-r|> ffmpeg -f lavfi -i sine -c:a aac -q:a 1 -t 40 aac.aac why does this work? but ffmpeg -i sine -c:a aac -q:a 1 -t 40 aac.aac this doesn't [19:31:15 CET] <|szn-r|> why is that [19:32:15 CET] <kepstin> |szn-r|: because in once case you're creating a filter chain with a "sine" filter as a virtual input, and in the other you're trying to read from a presumably non-existant file named "sine" [19:33:03 CET] <|szn-r|> then how do i create sine without using lavfi format [19:33:39 CET] <kepstin> aboxer: not sure, but there's probably a fair amount of digitized legacy content where that's done, since mpeg standards crop out the line where cea608 captions would have been stored in the video [19:34:05 CET] <aboxer> kepstin: thanks, that makes sense [19:34:41 CET] <aboxer> can ffmpeg differentiate between 608 and 708 in side data ? [19:35:44 CET] <|szn-r|> ffmpeg -f lavfi -i sine -c:a aac -q:a 1 -t 40 aac.m4a -y is showing BitRate_Mode/String : Constant too [19:37:01 CET] <faLUCE> kepstin and others: but which are the most common players that intesively use lavc/lavf other that vlc and mpv ? [19:37:11 CET] <kepstin> |szn-r|: yeah, since the flag mediainfo is reading is set by the muxer, i'd expect the codec implementation to make no difference [19:37:49 CET] <|szn-r|> kepstin so whose fault is this then? [19:37:57 CET] <|szn-r|> mediainfo or ffmpeg [19:38:29 CET] <kepstin> |szn-r|: unclear at this point, someone would have to go and check some specs. [19:38:43 CET] <kepstin> |szn-r|: either way, issue is mostly cosmetic, only problem is that media info doesn't say vbr. [19:38:52 CET] <|szn-r|> kepstin how do i create sine without using lavfi format [19:39:28 CET] <kepstin> |szn-r|: find a book from pre-electronic-computer era with a sine table and manually type values in. [19:39:49 CET] <|szn-r|> you are not taking my question seriously [19:40:22 CET] <kepstin> |szn-r|: i'm not sure why you're asking. Using -f lavfi is a perfectly acceptable way of generating a sine wave audio in ffmpeg [19:40:35 CET] <kepstin> there's no reason for you to not use -f lavfi [19:41:00 CET] <|szn-r|> okay let me rephrase, is there other format i can use other than lavfi to create a sine using ffmpeg [19:41:36 CET] <kepstin> |szn-r|: lavfi is a virtual format that lets you use a filter chain as an input. Instead of doing that, you could use a filter chain in one of the other ways ffmpeg provides of doing filter chains. [19:41:49 CET] <kepstin> like, -filter_complex for example [19:42:03 CET] <|szn-r|> yes or no [19:42:18 CET] <TheAMM> such demands [19:42:22 CET] <kepstin> there's no format other than "lavfi" which allows you to generate a sine wave using avfitlers [19:44:57 CET] <kepstin> beeep: its's kind of annoying that you keep changing your name, btw. [19:48:46 CET] <kepstin> faLUCE: there's probably a fair number of people on windows with 'LAV Filters' or similar installed to do decoding for dshow-based apps. [21:11:11 CET] <ossifrage> That's weird I turned B pictures back and now mpv is complaining, "[lavf] Edit lists are not correctly supported (FFmpeg issue)." [21:12:32 CET] <JEEB> it should only do that if you have packets with the discard flag [21:12:54 CET] <JEEB> did you specifically enable the google-made "advanced" edit list mode? [21:12:59 CET] <JEEB> mpv should disable that by default [21:13:07 CET] <ossifrage> Ah, I was setting the discard flag for B frames [21:13:12 CET] <JEEB> right [21:13:34 CET] <ossifrage> Err not discard, AV_PKT_FLAG_DISPOSABLE [21:13:46 CET] <JEEB> yea, that's different I think? [21:13:57 CET] <JEEB> relevant lines [21:13:57 CET] <JEEB> demux/demux_lavf.c- if (pkt->flags & AV_PKT_FLAG_DISCARD) [21:13:57 CET] <JEEB> demux/demux_lavf.c: MP_ERR(demux, "Edit lists are not correctly supported (FFmpeg issue).\n"); [21:14:13 CET] <ossifrage> I wasn't setting that.... [21:14:52 CET] <JEEB> interesting [21:16:30 CET] <JEEB> the only thing that seems to set that flag is the mov/mp4 reader, and I think that's only in the case if the advanced edit list stuff is enabled [21:17:09 CET] <JEEB> or hmm [21:18:35 CET] <JEEB> ok, it might be setting the flags in the reader unconditionally [21:21:02 CET] <JEEB> anyways, long story short - the mov/mp4 reader is the only one exporting that flag and often exported by the edit list related stuff [21:21:13 CET] <JEEB> so it warns about it possibly leading to issues [21:22:07 CET] <ossifrage> The B picture playback is still not working right, it doesn't seem smooth with ffplay [21:22:32 CET] <JEEB> how do your sttc (I think that was it) look? [21:22:33 CET] <ossifrage> I'm still faking the DTS, but I do have good PTS [21:22:42 CET] <JEEB> also are you using negative CTS offsets? [21:23:00 CET] <JEEB> I think the reader still doesn't support negative CTS offsets [21:23:45 CET] <JEEB> FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS [21:24:06 CET] <JEEB> and I thikn currently it only gets enabled without you specifying it if you are outputting ismv [21:24:10 CET] <ossifrage> I'm setting the DTS of the P-frames to the previous DTS + 1/2 frametime [21:24:10 CET] <JEEB> since ismv has no edit lists [21:24:28 CET] <JEEB> use l-smash's boxdumper [21:25:05 CET] <JEEB> boxdumper --box file | less [21:25:26 CET] <JEEB> (or you can redirect stdout to a text file) [21:26:57 CET] <JEEB> ya, you take the timescale out of the relevant mdia, and then later within that structure you have the ctts [21:27:44 CET] <JEEB> or well, first you check stts which tells you the dts coded in the mp4 [21:27:52 CET] <JEEB> in many cases for CFR you just have a single value there [21:28:29 CET] <JEEB> I have a 2157 frame mp4 and I have a single entry in stts which says that each sample has a sample delta of 1001 [21:28:57 CET] <JEEB> so if the track starts at 0, then 0,1001,2002 etc [21:29:33 CET] <JEEB> also now I remembered that you can also get these calculated values with boxdumper]s --timestamp [21:30:26 CET] <JEEB> http://up-cat.net/p/4d39b1b9 [21:30:33 CET] <ossifrage> What is the relationship between PTS and CTS? [21:30:38 CET] <JEEB> here's the video track I had as an example [21:31:15 CET] <JEEB> in many cases CTS is pretty much what PTS is; some technical differences but Composition Timestamp in 99% of all cases means the Presentation Timestamp [21:31:57 CET] <JEEB> possibly because you have then edit lists etc which can twist actual presentation time line [21:32:10 CET] <ossifrage> boxdumper is printing out zero based timestamps (I'm assuming that is for presentation) [21:32:33 CET] <JEEB> you can see how my example looks [21:32:55 CET] <JEEB> it has b-frames and the DTS starts at zero [21:33:11 CET] <ossifrage> http://up-cat.net/p/ce92175b [21:36:03 CET] <JEEB> so that's about 60.002fps? [21:36:14 CET] <JEEB> looking at the DTS delta [21:36:48 CET] <ossifrage> It is 30fps, I' [21:37:06 CET] <ossifrage> I'm faking the DTS for the P pictures (most likely incorrectly) [21:37:32 CET] <JEEB> also you don't have b-frame delay there which does raise alarm bells if you have enabled b-frames [21:38:38 CET] <JEEB> see how my sample has nonzero CTS for the first sample because you have to have the space to reorder [21:39:17 CET] <JEEB> there's then a "simple" edit list that then moves the CTS 2002 to be the zero point of the time line [21:40:07 CET] <ossifrage> For IDR/B I set dts = pts, for P I set dst = last dts + 1/2 frametime [21:40:21 CET] <ossifrage> (which I pulled out of my ass) [21:43:32 CET] <JEEB> try dumping some raw annex b H.264 out of your encoder and see how l-smash's muxer muxes it in with a frame rate [21:44:19 CET] <ossifrage> IP only looks as you would expect: http://up-cat.net/p/eb3afea6 [21:44:28 CET] <JEEB> muxer -i file.264?fps=30/1 -o out.mp4 [21:44:36 CET] <JEEB> for 30hz [21:45:44 CET] <JEEB> and check the timestamps there [21:48:44 CET] <ossifrage> http://up-cat.net/p/3b30338e [21:49:37 CET] <xxxmaker> is fdk_aac really better than ffmpeg-aac or apple-aac ? [21:50:36 CET] <ossifrage> I guess I can't get away with my lazy DTS generation. I was hoping to do it just using the (good) PTS without any buffering [21:51:06 CET] <JEEB> indeed [21:51:09 CET] <ossifrage> And it needs to work in the variable frame rate case and when the encoder parameters are changing at runtime [21:53:15 CET] <ossifrage> I did manage to get chrome to playback my infinite mp4 file for 24 hours without blowing up (but that was just IP) [23:38:50 CET] <ossifrage> The PTS/DTS stuff is even more annoying when the encoder can switch between encoding modes on the fly [23:41:33 CET] <TheAMM> Is there any known reason why "ffprobe -show_chapters" has only a couple chapters, while "mkvextract file.mkv chapters out.xml" has them all? [23:41:57 CET] <TheAMM> Although this is one of those weird playall files using ordered chapters with segment uids [23:42:14 CET] <TheAMM> But mkvextract is not reading anything else than the mkv [23:44:19 CET] <durandal_1707> ordered chapters are not supported, -- they are in separate files [23:44:24 CET] <TheAMM> I know [23:44:34 CET] <TheAMM> But the chapter metadata is in the file [23:44:48 CET] <xxxmaker> durandal_1707 are you ffmpeg dev? [23:45:08 CET] <TheAMM> The output for this particular file https://mygi.ga/O4V/aedNA.json https://mygi.ga/H2V/aedNB.xml [23:45:17 CET] <TheAMM> JSON being ffprobe -of json [23:46:47 CET] <TheAMM> Both commands ran with the file separated from the others, so it's not looking for them [23:49:39 CET] <durandal_1707> xxxmaker: do you have bug to report? [23:49:49 CET] <xxxmaker> yes [23:50:17 CET] <xxxmaker> ffmpeg -f lavfi -i sine -c:a aac -q:a 1 -t 40 aac.m4a : it's showing as constant bitrate [23:51:01 CET] <jab416171> is it possible to turn 3 side-by-side videos into a 360 degree video? even a partial one? [23:52:35 CET] <xxxmaker> ffmpeg -f lavfi -i sine -c:a aac -q:a 1 -t 40 aac.m4a : it's showing as constant bitrate : is this a bug? [00:00:00 CET] --- Fri Mar 22 2019

1 0