August 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190814
by burek 15 Aug '19

15 Aug '19

[01:14:15 CEST] <Compn> durandal_1707, are you bcak from vacation? you apply phtosensitive filter yet? [08:58:50 CEST] <cone-150> ffmpeg 03Andreas Rheinhardt 07master:8fcc5d963ebc: avfilter/vf_convolution: Fix build failures [15:04:00 CEST] <Lynne> wow, that srt patch is something, and its from collabora [16:54:30 CEST] <durandal_1707> Compn: i will apply filter after vacation finish not before [19:04:08 CEST] <durandal_1707> are ther specs for aac celp? [19:05:09 CEST] <BtbN> Is trac down? [19:08:06 CEST] <durandal_1707> works for me [19:08:40 CEST] <durandal_1707> perhaps yours traffic is rerouted through china [19:12:51 CEST] <Lynne> durandal_1707: https://www.itscj.ipsj.or.jp/sc29/open/29view/29n2603t3clp.pdf [19:14:14 CEST] <Lynne> like opus, its essentially a second codec that can be switched per-frame [19:16:47 CEST] <durandal_1707> nice [19:18:52 CEST] <durandal_1707> is trasformation friendly or it needs special hacks? [19:19:18 CEST] <durandal_1707> and why this havent be done already? [19:21:46 CEST] <Lynne> nope, not transform friendly, uses nptwo window sizes, and no work has been done because it needs a whole new decoder to be hacked into aac [19:23:13 CEST] <durandal_1707> does tx supports its transform sizes? [19:24:05 CEST] <Lynne> it doesn't use an fft, its lpc+synthesis based [19:24:38 CEST] <durandal_1707> so why is thaz hard? [19:26:27 CEST] <Lynne> the hard part is implementing it as per the spec, lol, coefficients aren't plainly coded in the bitstream [19:27:26 CEST] <durandal_1707> no code dump in spec? [19:31:25 CEST] <Lynne> nope, its a spec with sentences, pseudocode and some tables at the end [19:32:31 CEST] <durandal_1707> anybody tried successfuly to follow spec and write decoder? [19:36:27 CEST] <durandal_1707> fdk does not have it? [19:36:35 CEST] <Lynne> nope [19:37:33 CEST] <Lynne> not even the official winamp plugin supported it as of 2002 [19:47:06 CEST] <durandal_1707> i want to write it if leader michaelni sponsor me [19:47:40 CEST] <durandal_1707> j-b: care for aac celp? [19:50:33 CEST] <kierank> durandal_1707: no you should work on important fuzzinf [19:51:25 CEST] <durandal_1707> cant, michaelni doesnt want help [19:58:01 CEST] <kierank> ask one of michaelni fanbois for help [20:09:33 CEST] <jamrial> i don't know what possessed you two, but you've been insufferable for a long while now [20:09:45 CEST] <jamrial> how do you expect things to get better if all you do is adding fuel to the fire? [20:09:59 CEST] <jamrial> is all this trolling and passive aggressiveness needed? [20:10:07 CEST] <kierank> sorry [20:10:14 CEST] <kierank> taking a joke too far [20:10:39 CEST] <kierank> It is our way of trying to feel better about a bad situation [20:14:45 CEST] <durandal_1707> its very bad situation, do not know why other contributors are so passive and inactive about it [20:16:05 CEST] <BtbN> I'd move the fuzzing noise to a deidcated and less restricted ML, but I fail to see it's a bad situation. The only bad situation I see is the constant harassment. [20:17:39 CEST] <durandal_1707> i harass by calling michaelni leader? [20:18:53 CEST] <Lynne> comments on fuzzing are frequently ignored [20:19:31 CEST] <Lynne> nothing has been done but adjust a few constants to shut people up, and carry on with this task paramount to security [20:21:17 CEST] <Lynne> who would care if a few files get broken, no one uses those obscure codecs anyway, security is more important [20:21:29 CEST] <Lynne> and yet the bintext decoder is still there [20:21:59 CEST] <durandal_1707> and concat protocol [20:24:06 CEST] <durandal_1707> in case of dupe decoded frames they ruin decoder compatibility for some dos attacks [20:24:26 CEST] <durandal_1707> which is nonsense [20:25:13 CEST] <durandal_1707> now he must add ugly hacks to every and all decoder that dupes frames [20:25:28 CEST] <durandal_1707> but oh no [20:25:45 CEST] <durandal_1707> only qtrle got actual patch [20:28:29 CEST] <durandal_1707> why are some trivial codecs still fuzzed, perhaps they forgot they use bytestream2 API and actually check where and how much they write [20:30:24 CEST] <Lynne> this was for a codec and a patch someone actually reviewed, think about whether its possible a casual merged timeout patch broke all non-fate files [20:32:07 CEST] <durandal_1707> now if you call someone patch hack it is considered a hack [20:32:21 CEST] <durandal_1707> and harassment [20:32:32 CEST] <durandal_1707> :) [20:33:20 CEST] <durandal_1707> here, see what those fuzz patches do to my brain... [20:35:07 CEST] <durandal_1707> the most offending kind of patches are those that try to guess smallest posible packet size [20:44:13 CEST] <durandal_1707> Lynne: are there reference samples for aac celt that covers all stuff? [20:46:32 CEST] <juandl> Hello, if anyone has anything else to say about my patch I'm willing to listen to your feedback here. Patch is libavutil: AVEncodeInfo data structures. Or reply to the email thread [21:37:32 CEST] <Lynne> durandal_1707: nope, just samples, but from the bitstream I'm fairly certain they're mostly using all of it [21:39:42 CEST] <durandal_1707> we have single sample [22:05:44 CEST] <cone-191> ffmpeg 03Marton Balint 07master:a1c70148471c: ffplay: properly detect all window size changes [22:23:01 CEST] <cone-191> ffmpeg 03Marton Balint 07release/4.2:c8dcda22f170: ffplay: properly detect all window size changes [22:32:19 CEST] <Lynne> okay, wtf [22:32:35 CEST] <Lynne> how am I being agressive by stating "You are ignoring 2 developers, and this isn't the first time you're doing this, nor even the second." [22:33:58 CEST] <Lynne> the entire email contains a fact, 2 opinions and another fact [22:34:11 CEST] <durandal_1707> you are too agressive and direct [22:34:28 CEST] <durandal_1707> you nead to be sneaky like them [22:36:06 CEST] <Lynne> "I am under the slight amount of impression that you might have completely on accident unintentionally forgot to discuss at some occasions the opinions of some people who too are as involved in the project as everyone." [22:36:45 CEST] <Lynne> nope, sounds nothing like them [22:38:08 CEST] <Lynne> but I bet even if I had said that it would still be considered a passive aggressive response [22:38:09 CEST] <durandal_1707> also you must always be politically correct at all costs [22:41:38 CEST] <durandal_1707> also before you talk check number of commits you have in codebase [22:44:46 CEST] <Lynne> encoders and decoders are one commit each, timeouts, undefined behaviour and comments are as many as you want [22:45:21 CEST] <durandal_1707> life sucks [22:47:30 CEST] <durandal_1707> at least ffmpeg virtual one :) [22:49:52 CEST] <durandal_1707> why we still have crap sonic codecs? [22:50:15 CEST] <durandal_1707> that code is abandobed since forever [22:54:15 CEST] <durandal_1707> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/sonic.c;h=34d2… [22:57:49 CEST] <jamrial> Lynne: i mean, how else would you commit a new decoder? each commit needs to compile and work [22:58:21 CEST] <jamrial> if it's a decoder with more than one module (aac comes to mind) then one per feature would be fine [22:58:54 CEST] <jamrial> aside from that, you could pad it by adding the codec id and bumping version on different commits, but that's kinda pointless [22:59:43 CEST] <durandal_1707> that adds 3 commits per decoder [23:00:19 CEST] <durandal_1707> another one for changelog and you are at 4 [23:28:07 CEST] <cone-191> ffmpeg 03Marton Balint 07master:d770e0f401e7: avformat/mpegtsenc: fix incorrect PCR selection with multiple programs [23:28:08 CEST] <cone-191> ffmpeg 03Marton Balint 07master:47ea654bd8d1: avformat/mpegtsenc: factorize setting up services [23:28:09 CEST] <cone-191> ffmpeg 03Marton Balint 07master:9de40bf624a4: avformat/mpegtsenc: remove section_write_packet forward declaration [23:28:10 CEST] <cone-191> ffmpeg 03Marton Balint 07master:a4d984ad3319: avformat/mpegtsenc: use increasing numbers in default service names [23:28:11 CEST] <cone-191> ffmpeg 03Marton Balint 07master:88ac76be7960: avformat/mpegtsenc: fix PCR generation intervals [23:28:12 CEST] <cone-191> ffmpeg 03Marton Balint 07master:59744637673d: avformat/mpegtsenc: remove deprecated resend_headers option [00:00:00 CEST] --- Thu Aug 15 2019

1 0

ffmpeg.log.20190814
by burek 15 Aug '19

15 Aug '19

[00:01:46 CEST] <bencc> kepstin: ok so h264 hw acceleration is gpu thing and not cpu [00:01:55 CEST] <bencc> they also have nvidia gpus: https://cloud.google.com/compute/gpus-pricing [00:02:42 CEST] <bencc> should I expect order of magnitude improvement compared to cpu transcoding or is it not worth it? [00:02:49 CEST] <kepstin> the hardware encoder (it's *not* hardware accelleration) is dedicated hardware separate from the gpu and cpu, but intel bundles it with their gpu [00:03:52 CEST] <kepstin> nvidia's hardware encoder is one of the best around, as far as i know. they have specifications about how many streams and framerates their encoders support on particular cards on their site [00:04:54 CEST] <bencc> I'll search for the nvidia specs [00:04:57 CEST] <bencc> what about amd? [00:04:59 CEST] <kepstin> my understanding is that nvidia's hardware encoder does quality/filesize comparable to x264's "veryfast" to "medium" depending on settings you choose. [00:07:21 CEST] <kepstin> i think google's using amd's hardware encoder for the stadia platform? i don't really know much about its performance/quality. [00:08:07 CEST] <kepstin> the hardware encoders seem to be mostly useful for handling realtime/live encoding circumstances, where you'll be able to get N realtime streams depending on card specs and video resolution/framerate [00:08:47 CEST] <kepstin> if you're doing encoding for video on demand type applications, the additional compression you can get from a slower-than-realtime software encoder might be preferable. [00:10:30 CEST] <kepstin> with video on demand you can split an entire video into chunks that are encoded in parallel, so the whole encode can be done quickly even tho each chunk is encoded slower than realtime. [00:47:27 CEST] <bencc> kepstin: how can I split a video to chunks and combine it later? [00:47:47 CEST] <kepstin> segment muxer, concat demuxer [01:18:47 CEST] <bencc> thanks [02:35:54 CEST] <w1d3m0d3> /join #libre.fm [02:37:57 CEST] <barg> kepstin: ok, so if i do ffmpeg -i blah.mp4 -ss 0:05:00 -to 00:10:00 -c copy blah2.mp4 is that right, no need to re-encode, but should copy the codecs so it doesn't put default ones in? [02:42:14 CEST] <klaxa> yes, be aware that copying codecs will cut at gop boundaries [02:43:17 CEST] <nicolas17> what's the boundary for audio? [02:46:37 CEST] <barg> i don't know but the whole video is about 00:00:00-00:14:00 [02:50:36 CEST] <klaxa> nicolas17: don't know for sure, but a lot smaller than for videos, probably also depends on the codec [02:50:54 CEST] <klaxa> depending on how many samples they put in one "gop" or rather group of samples [02:51:46 CEST] <barg> I notice that when I do a line like ffmpeg -i VID_20190808_214609987.mp4 -acodec copy -vcodec copy -ss 00:10:30 987b_TEST.mp4 So, starting 10min 30sec in, Then it takes a while saying frame=0 before it begins. And the further the -ss, the longer it takes to start going beyond frame=0, I guess that's unavoidable? [02:52:28 CEST] <nicolas17> yes, it decodes all frames from the beginning until it reaches 0:10:30 [02:52:54 CEST] <c_14> you can put the -ss before the -i [02:52:55 CEST] <klaxa> you can put the -ss before [02:52:58 CEST] <klaxa> you sniper [02:53:04 CEST] <nicolas17> hm [02:53:22 CEST] <nicolas17> what is key_frame in the output of "ffprobe -show_frames"? [02:54:16 CEST] <klaxa> for video streams it's the start of gops [02:54:27 CEST] <klaxa> not sure about audio? [02:54:30 CEST] <nicolas17> I guess I found another bug / missing feature [02:54:44 CEST] <nicolas17> I get key_frame=1 for *every* frame in av1 video [05:08:25 CEST] <void09> is it possible to record the output of a full screen program in a way that it does not interfere with my current desktop work ? that is, so I can do other stuff while it's recording. something like a virtual monitor. [05:19:37 CEST] <nicolas17> -vcodec libx265 -profile:v slow [05:19:47 CEST] <nicolas17> what defines what 'slow' means there? is it in ffmpeg or in x265? [05:20:20 CEST] <nicolas17> er preset* [05:24:22 CEST] <void09> it's in ffmpeg, for x265 ? the encoding profile for x265 [05:26:41 CEST] <nicolas17> I think it's in x265 (eg. I can't find the string "placebo" in ffmpeg's source code) [05:26:47 CEST] <nicolas17> now to figure out *where* in x265 code [05:30:08 CEST] <void09> it's the cpu time allocated for the encode, from ultra fast to placebo. the faster the less cpu time needed and less efficient of an encode [05:30:43 CEST] <void09> hmm I'd have figured those string would be present in the ffmpeg code too [05:41:23 CEST] <nicolas17> found x265/doc/reST/presets.rst which explains what each preset does :) [08:06:39 CEST] <kepstin> nicolaus: if your ffmpeg is build with the dav1d decoder, that decoder should indicate frame properties better. [09:01:21 CEST] <Hackerpcs> how is the aac encoder nowadays? Would switching from fdk aac be advisable? [09:40:52 CEST] <furq> no [12:19:32 CEST] <DHE> Hackerpcs: it's good enough if you can't deal with the fdk license. but if you can deal, stick with fdk [13:52:29 CEST] <shroomM> hey [13:52:41 CEST] <shroomM> I have a question regarding outputting fragmented mp4 [13:53:26 CEST] <shroomM> when I use ffmpeg to output to a fragmented mp4 (-movflags frag_keyframe), the resulting file's first frame has a timestamp of 0.8s and not 0s as I'd expect [13:54:35 CEST] <shroomM> this seems to cause issues with a packager I'm trying to use to produce a DASH manifest [13:54:49 CEST] <shroomM> any idea what's the reason behind this ? [13:58:27 CEST] <shroomM> a cli "ffmpeg -i video.mov -an -g 48 -movflags frag_keyframe -b:v 1048576 -f mp4 foo.mp4" produces a file which shows this information: "Duration: 00:01:00.00, start: 0.083333, bitrate: 1484 kb/s" [13:59:48 CEST] <shroomM> removing the movflags part (ffmpeg -i video.mov -an -g 48 -b:v 1048576 -f mp4 foo2.mp4) gives me: "Duration: 00:01:00.00, start: 0.000000, bitrate: 1484 kb/s" [14:11:32 CEST] <shroomM> ah, found it, seems "negative_cts_offsets" makes the first frame to have the timestamp of 0 [14:13:44 CEST] <ritsuka> you either need to use negative ctts offsets, or an edit list [14:13:57 CEST] <ritsuka> but maybe your packaged doesn't like edit lists [14:33:20 CEST] <shroomM> ritsuka thanks, found that as well, yes [14:33:34 CEST] <shroomM> I'm just now looking at the movenc.c code to see what it all means [14:33:46 CEST] <shroomM> and I found there's an undocumented movflag, "dash" [14:33:51 CEST] <shroomM> should this be used [14:34:17 CEST] <shroomM> well, I'm not sure whether it's undocumented, I didn't see it on ffmpeg.org [16:14:10 CEST] <shroomM> ok, so the negative_cts_offsets doesn't have any effect if it's specified with the empty_moov movflag [16:14:48 CEST] <shroomM> "ffmpeg -i video.mov -an -g 48 -movflags frag_keyframe+empty_moov+negative_cts_offsets -b:v 1048576 -f mp4 foo.mp4" still produces an mp4 with "Duration: 00:00:10.13, start: 0.083333, bitrate: 3672 kb/s" :( [16:15:01 CEST] <shroomM> if I omit the empty_moov, then it's fine [17:24:25 CEST] <devinheitmueller> Question: has anyone put together a methodology to inject arbitrary frames if the real source stops delivering frames? I.e. encode colorbars on loss-of-signal. I can probably write some sort of filter from scratch, but wasnt sure if there was some wonky pipeline I could setup which uses the selectstream filter. [17:24:50 CEST] <BtbN> Twitch does that if your stream crashes and you enabled the option. [17:25:00 CEST] <BtbN> It does it by just replacing entire HLS segments [17:25:20 CEST] <devinheitmueller> This is a bit harder than the traditional flitering scenario, where filters are run when a frame arrives. In this case I want the filter to be used in the *absense* of frames. [17:25:27 CEST] <BtbN> An ffmpeg filter won't help you. If the input dies, the entire process stops. [17:25:46 CEST] <BtbN> Easiest to do this out of band [17:25:56 CEST] <devinheitmueller> Well in this case Im talking a realtime TS, so I dont get an EOF or anything. [17:25:57 CEST] <furq> yeah and if a frame is late then the filter has no input [17:26:42 CEST] <devinheitmueller> I know the libavfilter framework has an alternative entry point (request_frame) which I assume can be invoked even if the original source doesnt deliver a frame. [17:27:30 CEST] <BtbN> libavfilter simply is the entirely wrong place for that kinda thing [17:27:42 CEST] <BtbN> They are filters, nothing more [17:28:17 CEST] <BtbN> You would need to write an input protocol wrapper that has reconnect-logic and sends "Input is disconnected" intermediate data [17:29:47 CEST] <devinheitmueller> Hmm, that feels like the wrong approach. I can imagine all sorts of cases where I might want to arbitrary replace the source after the decode phase. For example, based on the blackdetect filter. [17:30:15 CEST] <BtbN> ffmpeg CLI has no provisions for arbitrarily replacing the source [17:30:24 CEST] <BtbN> You will have to write your own application for that [17:30:38 CEST] <devinheitmueller> Well Im not against having two sources (the real source, and one producing colorbars) [17:30:54 CEST] <devinheitmueller> And then some filter chooses which one to pass through. [17:31:09 CEST] <BtbN> If one of two sources dies, the whole chain dies with it [17:31:24 CEST] <devinheitmueller> Yeah, but the source isnt actually dying. It may very well come back. [17:31:30 CEST] <BtbN> That doesn't matter [17:31:34 CEST] <BtbN> it does not produce frames anymore [17:31:54 CEST] <BtbN> so either it blocks the entire chain until more data comes in, or it goes EOF and the chain finished up and ends [17:32:06 CEST] <devinheitmueller> Right, but it might start producing frames again 30 seconds later. It would be great to be able to throw up a please stand by message in the video during that duration. [17:32:29 CEST] <devinheitmueller> Presumably ffmpeg would continue to service the second source even if the first is blocked. [17:32:29 CEST] <BtbN> That's why you need a wrapped source does accounts for that [17:32:34 CEST] <BtbN> ffmpeg does not [17:32:52 CEST] <BtbN> that's not how any of the code works, and changing it to behave like that is pretty much impossible without a major rewrite of... everything [17:33:20 CEST] <BtbN> I don't see the issue with a wrapper-protocol that implements that kind of fallback behaviour [17:33:58 CEST] <devinheitmueller> Well the wrapper protocol approach would require me to deliver an entire alternative compressed stream with the same map layout. [17:34:34 CEST] <devinheitmueller> You would think people would have this issue with stuff like mosaics/multiviews. If one of the sources stops, you wouldnt expect the entire app to hang.. [17:34:46 CEST] <DHE> you'd have to write some kind of protocol, like http or whatever, that expects realtime data from the wrapped protocol and if it doesn't get it starts producing alternative frames. [17:35:16 CEST] <DHE> the main issue I see with that is it would need to provide these alternative frames in the same encoding as the original source (eg: h264 at specific resolution, probably same framerate, etc) [17:36:04 CEST] <devinheitmueller> Thats why I think it should be at the filter level. From within the filter its trivial to create video frames at the appropriate resolution and framerate. [17:36:51 CEST] <BtbN> Except that it's too late to do what you want to do at the filter level [17:36:52 CEST] <kepstin> filters don't handle realtime stuff like that. they just request frames from their sources or upstream filters, and then get activated again later when the frames are available. [17:38:21 CEST] <devinheitmueller> kepstin: My thought would be to have a filter where request_frame delivers the most recent frame from upstream, and if there is no such frame it creates one. Of course in that case it would be good to repeat the previous frame a certain number of times before switching to the secondardy frame source. [17:38:53 CEST] <BtbN> If there is no such frame, it blocks until there is one, or until EOF [17:38:59 CEST] <kepstin> how does it know that there's "no such frame"? all it does is request a frame, then it doesn't get run again until the frame is available. [17:39:40 CEST] <devinheitmueller> Yeah, I think thats part of the issue - I dont fully understand how the request_frame API is implemented. [17:40:02 CEST] <devinheitmueller> All my filters have used the more traditional filter_frame API, where the filter gets invoked when a frame arrives from upstream. [17:40:35 CEST] <kepstin> all the filter frame stuff is actually implemented in terms of the newer activate api, fwiw (there's some wrapper code in the filter core that adapts between the layers) [17:41:14 CEST] <devinheitmueller> Yeah, Im not shocked that the filter_frame is called from within the new API. Is there any documentation describing the activate api? [17:41:31 CEST] <devinheitmueller> PS. ffmpegs documentation is absolutely terrible. [17:41:40 CEST] <kepstin> (rough summary:) in the background, the filter_frame wrapper gets kicked when a downstream filter/sink wants a frame, then it requests a frame from the upstream filter/source, then when that frame is available it runs the filter_frame function. [17:42:04 CEST] <devinheitmueller> Ok, that makes sense. [17:43:07 CEST] <devinheitmueller> Hmm, ok I see the problem. I cant rely on the call to filter_frame telling the filter whether this is the frame arriving for the first time, or if its because the activate API invoked it. [17:43:53 CEST] <BtbN> It would also be a major API and ABI break to change that behaviour [17:44:06 CEST] <kepstin> the filter system's all pull-based, a new frame being buffered to a filter doesn't activate it iirc [17:45:03 CEST] <kepstin> i can't actually remember if that's true, the code's hard to follow :) [17:45:35 CEST] <devinheitmueller> kepstin: I think that was part of my misunderstanding. Because Ive always done filter_frame, I assumed it was pushed based. If it really is pull based, then I should be able to synthesize frames from scratch in the event the source isnt delivering any. [17:46:15 CEST] <kepstin> devinheitmueller: the problem is that the only way to know if an upstream filter is delivering frames, is to ask it for a frame, and then your filter doesn't get run again until a frame is available [17:46:16 CEST] <BtbN> except that the pull-function blocks if there is no frame [17:46:45 CEST] <BtbN> making it non-blocking would break the behaviour of all of the libav* family libs [17:46:47 CEST] <devinheitmueller> Ah, I see. [17:47:29 CEST] <durandal_1707> thats just how buffersrc buffersink works [17:49:39 CEST] <kepstin> in the activate based api, the pull function isn't blocking, it's asynchronous. You ask for frame, then return, and you get run again later once there's a frame sitting in your input buffer to read (or an eof/error indicator). [17:49:54 CEST] <devinheitmueller> I guess if I had a dedicated thread servicing the filters and feeding the result onto a FIFO, I could have the other end of the FIFO time out if no frames are delivered within a time period. [17:50:44 CEST] <kepstin> gonna be honest here, you probably could build what you want in the gstreamer graph system (which does support threads, things timed to clocks, etc). [17:51:10 CEST] <kepstin> or of course by using ffmpeg apis yourself and swapping between reading from different inputs based on knowledge you have of stream state. [17:51:41 CEST] <devinheitmueller> Oh Im totally not against calling the APIs directly. I dont need it to work in ffmpeg.c. That said, I want it to conform to the libavfilter API so I can upstream it. [17:52:23 CEST] <devinheitmueller> (would be nice if it worked from within ffmpeg.c of course, but thats not a showstopper) [17:52:49 CEST] <kepstin> this cannot be done in the libavfilter api, and putting it in the ffmpeg.c code would require some rewriting (which it probably needs, really, given the number of people who try to use it for realtime stuff) [17:53:16 CEST] <devinheitmueller> Oh dont get me started on the steaming pile of garbage that is ffmpeg.c. No disrespect intended. [17:53:43 CEST] <BtbN> It's pretty good for what it is. It tries to cater every possible usecase, and in most cases manages to do so. [19:33:02 CEST] <Hackerpcs> DHE: Thanks, it's only for personal use so no licensing issues. Sticking to fdk then [19:33:31 CEST] <durandal_1707> really? [19:41:45 CEST] <furq> Hackerpcs: wrong kind of license [19:42:04 CEST] <furq> fdk isn't gpl compatible so you can't distribute ffmpeg binaries with fdk [19:45:45 CEST] <Hackerpcs> ehm I just said it's for personal use? [19:46:22 CEST] <furq> oh [19:46:26 CEST] <furq> ok then [20:45:10 CEST] <Spring> is there a way to tell ffmpeg to not include the last image (in an incremental sequence of image files) for the input when encoding? [20:45:31 CEST] <Spring> eg: let's say I have 60 images and want to only include the first 59 of them for the encode [20:45:39 CEST] <durandal_1707> yes trim filter [20:50:50 CEST] <Spring> looks like -vframes <total frames> is perhaps the simpler method in my case since I only need to grab the first n number of frames [20:51:09 CEST] <durandal_1707> yes [20:52:50 CEST] <void09> what would be a good lossless codec to record on a dual core intel i7 mobile cpu, with a sata ssd drive connected over usb3? [20:53:34 CEST] <durandal_1707> resolution and framerate? [20:53:51 CEST] <void09> 1920x1080 60fps. I'm thinking something that can detect duplicate frames maybe, as the source video is 24fps [20:54:20 CEST] <void09> but recording at 24 fps might miss some frames I think , no ? [20:54:36 CEST] <another> ffvhuff e.g. [20:55:13 CEST] <durandal_1707> it doesnt detect dupe frames [20:55:16 CEST] <void09> that's what I am using at the moment. I could do with something even faster (less cpu intensive) as I have 2TB to spare [20:55:28 CEST] <void09> faster and dupe frame detection would be great [20:55:43 CEST] <void09> x264 is too much for that cpu I think [20:55:55 CEST] <durandal_1707> faster cant get much [20:56:01 CEST] <durandal_1707> than ffvhuff [20:56:12 CEST] <void09> the original huff ? [20:56:17 CEST] <durandal_1707> both [20:56:28 CEST] <void09> raw video then :D [20:57:13 CEST] <durandal_1707> waste of resources [20:57:40 CEST] <void09> I just want to not drop frames, I can re-encode after [20:58:19 CEST] <void09> is it possible to tell it not to drop frames, but somehow keep data it can't process fast enough in the RAM, like in a queue ? [20:59:17 CEST] <another> you can also try utvideo [20:59:21 CEST] <durandal_1707> that can not work [20:59:30 CEST] <durandal_1707> try netter hw [20:59:35 CEST] <durandal_1707> better [21:00:50 CEST] <durandal_1707> or gpu for encoding [21:01:20 CEST] <void09> can gpu be used to accelerate ffvhuff ? or x264 lossless [21:01:43 CEST] <durandal_1707> i doubt so [21:02:29 CEST] <petecouture> For building a RTMP server. Has placement of the listen parameter changed on the input? Im using an old script which is now throwing a socket error like its trying to connect instead of waiting for a connection. [21:02:30 CEST] <petecouture> https://pastebin.com/1s1aBhHg [21:02:34 CEST] <void09> blah, I guess I'll have to build another machine [21:03:26 CEST] <DHE> lossless H264 maybe, if the GPU supports it. [21:03:47 CEST] <DHE> of course, there's still colourspace losses as always [21:04:57 CEST] <void09> DHE no way to avoid those ? I am recording in rgb24 [21:05:18 CEST] <DHE> I strongly suspect no GPU supports RGB encoding, let alone with lossless [21:05:28 CEST] <void09> video I am recording is x264 so most likely yuv420 [21:05:48 CEST] <DHE> x264 does support higher colourspace modes if you ask for them [21:06:07 CEST] <void09> ok nevermind about codec and acceleration, just avoiding the colourspace loss [21:06:52 CEST] <Spring> what would be the simplest way to crop a pixel value beginning from the left side and a different crop value from the right side? My brain is a bit fizzled atm. [21:06:57 CEST] <DHE> yuv4:4:4 might work, and while it's not perfectly lossless it's probably close enough [21:07:55 CEST] <void09> you mean it would be a better pick for recording yuv420 as they share the same original colourspace? [21:08:05 CEST] <Spring> or does ffmpeg always require that the dimensions /after/ the first crop be resulting output? [21:08:46 CEST] <Spring> oh god, hold on, it's coming back to me now :p [21:08:58 CEST] <DHE> Spring: filters can be chained. if you only invoke 1 filter, don't be surprise that its output is the resulting video [21:09:49 CEST] <Spring> yeah, don't worry, I can achieve this how I used to by setting a beginning x/y coord (the offset from either the left/right side) then the crop dimensions instead. [21:10:13 CEST] <Spring> was a bit hazy for a minute [21:10:55 CEST] <Spring> (of course this particular way only works when I know the original dimensions but it'll do for now) [21:33:13 CEST] <void09> on a screen grab, any way to see or log which frame numbers were skipped? [21:33:21 CEST] <void09> dropped* [21:38:17 CEST] <Spring> has the syntax for metadata rotation in MP4 containers changed in the last few years? As I switched to a recent build and `-metadata:s:v rotate="270"` doesn't do anything now. [21:45:14 CEST] <Spring> yeah, switched back to a 2016 build (also from Zeranoe) and the rotation metadata works again. [22:39:36 CEST] <petecouture> When using the -listen 1 flag on input to create a RTMP server. Does the origin RTMP stream having to be publishing prior to starting the server or is there a way that ffmpeg can sit idle awaiting an input connection? [22:39:55 CEST] <petecouture> I know the common solution is to use gnix but Im seeing if it can be done via command line [22:45:42 CEST] <petecouture> I have the -timeout 60 flag set per the rtmp spec. Im assuming it would keep the listener open awaiting an attempt [22:50:30 CEST] <petecouture> Realize I probably have the input formatted incorrectly. What Ive found online is people listing the listen parameter for the HTTP server but there isnt an example of the RTMP server being used [23:37:32 CEST] <petecouture> another: This is the old script [23:37:33 CEST] <petecouture> https://pastebin.com/1s1aBhHg [23:37:41 CEST] <petecouture> Which includes the listen commad you can find on google [23:38:09 CEST] <petecouture> After reviewing all the rtmp docs I believe they are all wrong incorrectly listing how th eform the rtmp string based on the3 HTTP server settings [23:38:12 CEST] <another> i've seen that [23:38:40 CEST] <petecouture> New one [23:38:41 CEST] <petecouture> https://pastebin.com/ZfhFCb2i [23:38:52 CEST] <petecouture> with the listen and timeout parameters including within the UI string [23:39:13 CEST] <petecouture> Which I believe is the correct way based on the examples from the other rt* based connection documentation [23:39:18 CEST] <petecouture> Im pulling the ffmpeg source code now [23:40:14 CEST] <another> https://ffmpeg.org/ffmpeg-all.html#rtmp [23:40:31 CEST] <petecouture> Correct Ive been staring at that for a few days now [23:40:32 CEST] <another> the rtmp protocol has a -listen option [23:40:50 CEST] <petecouture> Correct but it doesnt document how the option is used [23:41:01 CEST] <petecouture> And it lists it as a parameter [23:41:07 CEST] <petecouture> included within the URL parameter lists [23:41:10 CEST] <another> which when i run it, opens a socket on the specified port [23:41:13 CEST] <petecouture> onlyt the example doesnt show how its used [23:41:19 CEST] <petecouture> your serious... [23:41:23 CEST] <petecouture> derr Encoder Error: ffmpeg exited with code 1: RTMP_Connect0, failed to connect socket. 61 (Connection refused) [23:41:26 CEST] <petecouture> This is the error i get [23:41:38 CEST] <BtbN> so, the server refused your connection then [23:41:59 CEST] <petecouture> The server is supposs to open the connection [23:42:04 CEST] <another> what version are you running? [23:42:06 CEST] <petecouture> and there isnt anything publishing to the URI yet [23:42:16 CEST] <petecouture> My goal is to open the socket and leave it listening [23:42:24 CEST] <petecouture> Or understand how that works [23:42:28 CEST] <BtbN> Can ffmpeg even act as rtmp server? I was only aware of client support. [23:42:39 CEST] <petecouture> With the listen flag its supposed to be able to [23:42:50 CEST] <petecouture> listen [23:42:51 CEST] <petecouture> Act as a server, listening for an incoming connection. [23:43:41 CEST] <petecouture> BtbN: This is one of those undocumented things where a Google search will bring up many bad examples. [23:43:56 CEST] <petecouture> another 4.1.4 [23:44:07 CEST] <petecouture> Which is this year, the listen flag was added in 2017 [23:44:08 CEST] <BtbN> RTMP_Connect0 indicated you are using librtmp. The listen flag is only implemented in the native rtmp code. Those two are mutually exclusive. [23:44:22 CEST] <petecouture> BtbN damit your right [23:44:29 CEST] <petecouture> So I have to rebuild ffmpeg [23:44:48 CEST] <BtbN> librtmp support really should just be removed at this point imo [23:45:06 CEST] <petecouture> I literally thought about that. [23:45:15 CEST] <petecouture> I was building ffmpeg with librtmp for raspi a year ago [23:45:33 CEST] <BtbN> You have to build with --disable-librtmp to get proper rtmp support. [23:45:50 CEST] <petecouture> <3 [23:46:35 CEST] <petecouture> Literally had a meeting last week were I said the issue amhybe because librtmp was built into ffmpeg but didnt go down that path& cats and dogs getting along this week. total anarchy& [23:56:26 CEST] <Classsic> Hi, somebody can point how can decode with qsv and encode with libx264 in windows?? [00:00:00 CEST] --- Thu Aug 15 2019

1 0

ffmpeg.log.20190722
by burek 14 Aug '19

14 Aug '19

[00:28:57 CEST] <nine_milli> blb [03:20:00 CEST] Last message repeated 1 time(s). [03:33:13 CEST] <sim590> I have an MKV file which is described by the following https://paste.debian.net/1092564/. I want to extract the audio from that file, process it in audacity and put it back in with ffmpeg. I did an extract that gave this https://paste.debian.net/1092565/ with the command `ffmpeg -i caméra.mkv -vn -c:a copy caméra-out.m4a`. Then, I want to put it back with the video, but when I do so, I have descyned audio [03:33:15 CEST] <sim590> over time. At first it's good, but over time audio desyncs... What parameter should I fix in the audio encoding? [03:33:43 CEST] <sim590> Clarification: the audio is desynced after processing it with audacity ... [05:28:20 CEST] <dastan> hello [05:28:33 CEST] <dastan> i finish compiling ffmpeg to work with qsv [05:28:43 CEST] <dastan> but when i try to use it it says Unknown encoder 'h264_qsv' [05:29:05 CEST] <dastan> why nothing is simple when we try to compile FFMPEG [05:29:09 CEST] <dastan> is frustrating [05:30:02 CEST] <nine_milli> blb [05:31:37 CEST] <dastan> blb? [07:37:12 CEST] <nine_milli> blb [08:58:42 CEST] <hendry> hi! How do I get media from hev1 to hvc1? https://amcrest.com/forum/ip-cameras-f18/hevc-not-playable-in-safari-t12664… [09:00:16 CEST] <JEEB> codec_tag I think when doing -c copy [09:15:04 CEST] <hendry> or maybe tag:v? be good if this one documented in the wiki [09:25:59 CEST] <JEEB> hendry: yes, -tag:v . the internal variable is codec_tag :p [09:26:18 CEST] <JEEB> hendry: it is documented in the full manpage https://www.ffmpeg.org/ffmpeg-all.html [09:26:23 CEST] <JEEB> "-tag[:stream_specifier] codec_tag (input/output,per-stream)" [09:37:53 CEST] <hendry> ended up with find . -name "*.mp4" | while read fn; do test -f "$fn" && ffmpeg -y -i "$fn" -c:v copy -tag:v hvc1 -c:a copy "../hevc/$(basename $fn)"; done [09:38:01 CEST] <hendry> went blazing fast [09:47:42 CEST] <hendry> Are things like -movflags +faststart importing with HEVC? [09:56:33 CEST] <JEEB> faststart is irrelevant to the codecs you're using [09:56:53 CEST] <JEEB> it just does two-pass so that it is able to write the index at the beginning [09:57:08 CEST] <JEEB> if you don't need the index at the beginning, you don't need faststart and the mp4 writing will go A->B [09:57:26 CEST] <JEEB> if you do need it, you need faststart and the mp4 writing will go A->B, and then A->B again [12:11:56 CEST] <ackjewt> I'm trying to transcode to XAVC (Sony flavor) with ffmpeg 4.1.3. ProRes 720p59.94 -> XAVC 720p59.94. Failing with "[libx264 @ 0x6caac00] FPS 59940/1000p not compatible with AVC-Intra" Command with debug output: https://paste.ubuntu.com/p/twvMBS73gk/ Any ideas? [12:13:34 CEST] <bencoh> /41/41 [12:13:40 CEST] <bencoh> (woops) [15:50:48 CEST] <kepstin> ackjewt: the framerate for ntsc video is 60000/1001, not 59.94 [15:51:02 CEST] <kepstin> (ffmpeg accepts the fraction syntax directly) [15:51:20 CEST] <fsphil> that's the field rate [15:52:03 CEST] <kepstin> well, by "ntsc" i mean the familiy of rates with the 1/1.001 factor [15:52:16 CEST] <fsphil> the frame rate is 30/1.001 [15:52:23 CEST] <kepstin> which includes 24/1.001, 30/1.001, and 60/1.001 in HD video formats [15:53:00 CEST] <kepstin> the video ackjewt is looking at is 720 lines tall, progressive, 60/1.001 *frame* rate. [15:53:35 CEST] <fsphil> don't mind me, I'm just being pedantic [16:28:32 CEST] <ackjewt> kepstin: thank you very much! I didn't know that i had to specify it that way. Its working as expected. [16:54:26 CEST] <nine_milli> blb [18:36:47 CEST] <dastan> hello [18:37:11 CEST] <dastan> i am getting too many errors building a qsv compilation in ubuntu 18.04 [18:37:18 CEST] <dastan> my errors are https://pastebin.com/yidsXXZx [18:37:28 CEST] <dastan> does someone can help me? [18:39:32 CEST] <dastan> is there a manual to do this in the correct way without loosing my virginity, any time that i need to compile ffmpeg is a nightmare [18:47:25 CEST] <dastan> someone know about QSV? [18:47:31 CEST] <dastan> please....help!!!! [18:58:39 CEST] <nine_milli> blb [18:59:31 CEST] <JEEB> dastan: I don't think this has too much to do with FFmpeg :P [18:59:36 CEST] <JEEB> QSV is always problematic [18:59:45 CEST] <JEEB> also if you want help, post your full command line and terminal output in the pastebin [18:59:53 CEST] <JEEB> then link here [18:59:57 CEST] <JEEB> preferably with -v verbose [19:06:40 CEST] <dastan> https://pastebin.com/5uR6stgj [19:06:45 CEST] <dastan> this is my configuration [19:07:18 CEST] <dastan> is the only who shows me the h264_qsv, but when i want to use it it gives me many errors [19:08:22 CEST] <JEEB> I hope you will re-read what I posted and think about it a bit. maybe then we'll get the possibility of helping you :P [19:09:00 CEST] <dastan> in which part i need to put the -v option [19:09:06 CEST] <dastan> i read what you write [19:09:31 CEST] <JEEB> usage command, you can put it after ffmpeg's binary if you want in the command line :P [19:09:51 CEST] <JEEB> it's a general option so I don't think it matters where you put it (before/after input etc) [19:12:36 CEST] <dastan> i put it in the .configure, in the make or in the make install [19:12:43 CEST] <dastan> or in all of them [19:12:48 CEST] <JEEB> *usage* [19:12:54 CEST] <JEEB> if you've got it compiled, that's it [19:13:00 CEST] <JEEB> you posted errors from *usage* [19:13:19 CEST] <JEEB> thus post the full command line and terminal output of the *usage* (preferably with -v verbose) [19:13:27 CEST] <JEEB> not on the IRC channel, but in pastebin or so [19:13:29 CEST] <dastan> a ok ok [19:13:29 CEST] <JEEB> and link here [19:13:38 CEST] <dastan> i am compiling it again [19:13:53 CEST] <dastan> i come back when it finish and i post the command [19:14:02 CEST] <JEEB> post the full, uncut output [19:14:10 CEST] <JEEB> on pastebin, with the command parameters [19:14:17 CEST] <JEEB> that's the only way to get help [19:14:20 CEST] <JEEB> :P [19:14:38 CEST] <JEEB> or atl east someone like me *attempting* to help you :P [19:16:06 CEST] <dastan> the first extrange thing is vainfo only works when i put i965 in /etc/environment [19:16:19 CEST] <dastan> if i put iHD gives me an error [19:16:46 CEST] <JEEB> well that just means there's an issue with vaapi getting loaded with a driver? :P [19:16:52 CEST] <JEEB> not much to do with FFmpeg [19:17:18 CEST] <JEEB> of course it means that if you are going to attempt to utilize that driver most likely FFmpeg will not be able to use vaapi [19:17:27 CEST] <JEEB> but I think you grasped that already :P [19:17:32 CEST] <dastan> i know probably is not a ffmpeg error [19:17:39 CEST] <JEEB> not probably [19:17:44 CEST] <JEEB> vainfo has nothing to do with FFmpeg [19:17:44 CEST] <JEEB> :) [19:17:49 CEST] <JEEB> it is a test app for vaapi [19:17:52 CEST] <dastan> i know [19:17:56 CEST] <dastan> its for sure [19:19:15 CEST] <dastan> i am searching if someone is using it with QSV support [19:19:34 CEST] <JEEB> intel made QSV really messy [19:19:38 CEST] <JEEB> both to build and use [19:19:45 CEST] <JEEB> so almost nobody is using it :P [19:20:01 CEST] <JEEB> heck, before you even needed a special intel kernel for it [19:20:23 CEST] <JEEB> so if you can get around just using vaapi encoding [19:20:25 CEST] <JEEB> use vaapi [19:20:27 CEST] <JEEB> much less problemos [19:20:55 CEST] <JEEB> https://trac.ffmpeg.org/wiki/Hardware/QuickSync [19:21:01 CEST] <JEEB> someone has written something on the wiki about it, though [19:21:10 CEST] <JEEB> no idea if it's any good [19:21:11 CEST] <JEEB> :P [20:27:29 CEST] <nine_milli> blb [22:50:00 CEST] Last message repeated 1 time(s). [00:00:00 CEST] --- Tue Jul 23 2019

1 0

ffmpeg-devel.log.20190813
by burek 14 Aug '19

14 Aug '19

[00:05:34 CEST] <thardin> there we go, 208542 is not a legal frame size in D-10 [00:17:20 CEST] <thardin> more parsing/grammar related errors, woo [02:23:28 CEST] <philipl> BtbN: on that cc trac ticket. I assume he's not using -hwaccel_output_format so isn't doing full transcode and gets poor performance. [02:24:30 CEST] <cone-647> ffmpeg 03Chip Kerchner 07master:3a557c5d88b7: lsws/ppc/yuv2rgb_altivec: Replace vec_lvsl/vec_perm with vec_xl [04:49:41 CEST] <cone-647> ffmpeg 03Zhong Li 07master:8cd96e13eea8: fate: add a case for ticket #3229 [11:38:48 CEST] <thardin> mrrr, mixing indentation and functional changes [11:39:42 CEST] <nevcairiel> get a diff viewer that doesnt suck :D [11:43:50 CEST] <thardin> let's see if I can configure kompare [11:46:23 CEST] <BtbN> philipl, in his original h264_cuvid pastes it's using software-nv12 as well. [11:58:39 CEST] <philipl> all kinds of suboptimal then. [12:10:56 CEST] <BtbN> But I thought we fixed the nvdec software-path being slow compared to cuvid [12:11:16 CEST] <thardin> so looking at #3077, the muxer expects 49999840 bps for NTSC [12:11:40 CEST] <thardin> but it should really be 49999840,16 bps [12:12:16 CEST] <thardin> else you obviously won't get every frame to be 208541 bytes [12:12:40 CEST] <kierank> thardin: in x264 we hack it to produce the exact frame size [12:12:49 CEST] <kierank> for this kind of condition [12:13:01 CEST] <thardin> kierank: lavc should have an option for strict cbr [12:13:22 CEST] <thardin> this isn't the only place where people want this [12:13:38 CEST] <kierank> the /1001 thing will still be a problem [12:13:52 CEST] <thardin> not if I want 49999840.16 bps [12:14:09 CEST] <thardin> or, 208541 bytes per frame as the spec says [12:14:11 CEST] <kierank> not sure how you can signal that [12:14:21 CEST] <thardin> you don't [12:14:26 CEST] <thardin> mxf doesn't have bit rate signalling at all, I think [12:15:12 CEST] <thardin> hm, it does for the mpegvideodescriptor. but that's of course only informative [12:15:30 CEST] <kierank> I mean signal that to lavc [12:15:42 CEST] <thardin> a flag should do it [12:16:06 CEST] <thardin> I looked at the rate control stuff a while back, got horrified, and immediately stopped looking [12:16:49 CEST] <thardin> d-10 doesn't actually require strict cbr tho, it's just that baptiste removed the code in the muxer that added padding and whatnot [12:17:08 CEST] <thardin> at least not cbr on the essence stream [12:17:20 CEST] <nevcairiel> mpeg2 has a special option to set the framesize iirc, opposed to the overall bitrate [12:17:28 CEST] <nevcairiel> i think i used it once to make strict dvd compatible video [12:18:49 CEST] <thardin> -rc_eq maybe? [12:19:20 CEST] <nevcairiel> maybe i'm also misremembering [12:23:28 CEST] <thardin> doesn't seem to help [12:26:33 CEST] <philipl> BtbN: I can't try his command line just yet. Won't be back with nvidia access for a couple of days [16:40:00 CEST] <cone-792> ffmpeg 03Nicolas George 07master:2b4c1a0f3cdb: tools/aviocat: add verbose mode. [16:40:01 CEST] <cone-792> ffmpeg 03Nicolas George 07master:6e1a2dc11236: lavf/aviobuf: make AVSEEK_SIZE usable from outside. [16:40:02 CEST] <cone-792> ffmpeg 03Nicolas George 07master:3add65e052cf: lavf/concat: implement FFSEEK_SIZE. [16:40:03 CEST] <cone-792> ffmpeg 03Andreas Rheinhardt 07master:de010d229a18: libavformat/subfile: Fix SEEK_CUR and SEEK_END seeking [17:53:53 CEST] <zandam> hello [17:54:19 CEST] <zandam> I have a scenario with multiple video source, from different ip cameras, and foreach video input I have to make multiple video processings: a live stream, a recording and one or more opencv elaborations. [18:25:53 CEST] <BtbN> https://devtalk.nvidia.com/default/topic/1060977 nice [18:27:14 CEST] <durandal_1707> nobody cares for corporate blackbox stuff [18:27:28 CEST] <BtbN> "Fixed the cuvidParseVideoData API in the NVCUVID driver to correctly propagate errors returned by the PFNVIDSEQUENCECALLBACK callback function to the application." [18:27:34 CEST] <BtbN> that only took them... 2 years? 3 years? [18:27:37 CEST] <BtbN> philipl, ^ [18:32:05 CEST] <BtbN> They also FINALLY implemented dynamic per-application render offloading [20:27:24 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:021f29506b49: avcodec/hevcdec: Check delta_luma_weight_l0/1 [20:27:25 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:8f92eb05e063: avcodec/4xm: Check for end of input in decode_p_block() [20:27:26 CEST] <cone-792> ffmpeg 03gxw 07master:a3e572d96fd1: avutil/mips: refine msa macros CLIP_*. [20:27:27 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:db78bc1297eb: avcodec/vp56: Consider the alpha start as end of the prior header [20:27:28 CEST] <cone-792> ffmpeg 03Lars Kiesow 07master:74d4bc0fa0e0: libavfilter/vf_scale: Ensure scaled video is divisible by n [20:27:29 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:1e2e47e34811: tools/target_dec_fuzzer: Print max_pixels and iterations at the end [21:15:47 CEST] <TekuConcept> When adding new hardware acceleration support, how do I update the configuration to link with the external library? [21:17:30 CEST] <TekuConcept> Everything compiles just fine, but I am getting linker errors. ffbuild/config.sh shows that my lib is not added as a linker dependency to avcodec [21:25:11 CEST] <Lynne> check_pkg_config will automatically add c/ldflags if its detected [21:25:20 CEST] <Lynne> what are you adding support for? [21:27:08 CEST] <TekuConcept> h264 aml hardware acceleration [21:28:05 CEST] <TekuConcept> I manually compiled and installed libamcodec so I don't think pkg_config is going to be very useful here [21:35:44 CEST] <Lynne> enabled libwavpack && require libwavpack wavpack/wavpack.h WavpackOpenFileOutput -lwavpack [21:36:02 CEST] <Lynne> or just copy https://github.com/LongChair/FFmpeg/commit/90735fcbc47fae185ed59f63a9e0350c… [21:38:23 CEST] <TekuConcept> The implementation in that repository is broken, but that is where I got the sources. I fixed up all the broken code and now just have linker issues. I'll give "require libamcodec" a try. [21:38:59 CEST] <Lynne> yes, that code is low quality and hacky [22:29:15 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:fbbc8ba67f19: avcodec/diracdec: Check that slices are fewer than pixels [22:29:16 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:52939a2c5772: avcodec/indeo2: Check remaining input more often [22:43:16 CEST] <Lynne> amd's working on a vulkan hwardware decoding extension [22:43:50 CEST] <Lynne> bets on how that will turn out will not be accepted, its just not profitable [22:44:06 CEST] <BtbN> Isn't Nvidia working on that as well? [22:44:18 CEST] <BtbN> Would be about time. One API for all OS, except Apples walled garden. [22:46:25 CEST] <Lynne> that's the intention, but I can't imagine it working well across all platforms, and there will be android specific hacks because android [22:47:23 CEST] <Lynne> an ideal api would accept something like host-mapped memory with relaxed alignment requirements so you could zero-copy decode from slices onto images [22:47:41 CEST] <Lynne> or at least single copy with an intermediary buffer [22:49:23 CEST] <Lynne> but the only way to have any agreement between everyone would be a single "give me a decode context, give me a whole frame packet, and I'll parse and decode it" [23:06:09 CEST] <TekuConcept> I'm back! require passes (initially I was using check_lib, which also passed), but the lib is still not added to the dependency list; thoughts? [23:07:15 CEST] <TekuConcept> where would ${name}_extralibs be appended to avcodec's list? [23:13:57 CEST] <BradleyS> speaking of vulkan, anyone taking a look at https://patchwork.ffmpeg.org/patch/14319/ [23:40:12 CEST] <durandal_1707> nope [23:47:34 CEST] <BradleyS> and then he dips, classic [00:00:00 CEST] --- Wed Aug 14 2019

1 0

ffmpeg.log.20190813
by burek 14 Aug '19

14 Aug '19

[00:05:17 CEST] <Thomas_J> The more I try to remember what I did previously, the more confused I'm getting. I think that I am going to go back to the start and try to get the internal ffmpeg rtmps working with librtmp. [00:06:09 CEST] <Thomas_J> (which is an external package) [00:06:45 CEST] <furq> that's not a thing [00:07:16 CEST] <BtbN> The librtmp backend in ffmpeg is horribly broken, I'd recommend not using it. [00:07:22 CEST] <BtbN> The native rtmp support works fine. [00:07:35 CEST] <furq> if you build with librtmp then it'll only use that for rtmp iirc [00:07:40 CEST] <furq> also it still depends on an external tls library [00:07:55 CEST] <Thomas_J> Thanks for letting me scratch my dandruff on this channel. I was hoping to run into JEEB here. He is the one that set me streight last month. [00:08:13 CEST] <furq> was it gnutls or ffmpeg that he patched [00:09:42 CEST] <Thomas_J> At this point, I'm not sure but it was a problem that lived in the current builds available on line before mid Jully. [00:10:22 CEST] <Thomas_J> July, not Jelly. [00:11:50 CEST] <Thomas_J> Those builds worked fine until Facebook closed down connecting without encryption. [00:12:45 CEST] <Thomas_J> Actually, they were builds available before the First of May. [00:13:01 CEST] <furq> as far as i can tell it was ffmpeg [00:13:08 CEST] <furq> so just build ffmpeg yourself but link it with your distro gnutls [00:13:45 CEST] <furq> you should generally just link with distro packages unless they're really old or you specifically need new features [00:14:05 CEST] <furq> or it's something that likes to break its abi a lot [00:14:54 CEST] <Thomas_J> Armbian doesn't seem to have gnutls available in it's repositories unless they are calling it something else. [00:15:38 CEST] <pink_mist> I'm practically certain they have _some_ form of SSL/TLS library available. nobody says you haveto use only and specifically gnutls [00:15:53 CEST] <pink_mist> do they? [00:15:54 CEST] <furq> libgnutls30-dev [00:16:33 CEST] <furq> wait there's a libgnutls28-dev but no libgnutls30-dev [00:16:36 CEST] <furq> nice work debian [00:17:27 CEST] <furq> Package: libgnutls28-dev (3.6.8-2) [00:17:28 CEST] <furq> dep: libgnutls30 (= 3.6.8-2) [00:17:29 CEST] <furq> ...ok [00:17:32 CEST] <Thomas_J> Yay! apt-get found that. [00:18:22 CEST] <furq> pink_mist: iirc he was having some issues with openssl not working [00:18:38 CEST] <Thomas_J> Back to work. no more compiling for me except for ffmpeg [00:18:57 CEST] <pink_mist> I have not seen any evidence that he's used openssl at all [00:19:12 CEST] <furq> that's because you weren't here five weeks ago when this started [00:19:45 CEST] <pink_mist> all he said when someone suggested openssl was that he didn't think facebook handshaked with ssl .... which is just mindboggling [00:19:54 CEST] <pink_mist> oh, five weeks ago [00:20:24 CEST] <pink_mist> Thomas_J: openssl does TLS too. [00:27:12 CEST] <Thomas_J> I am presently compiling right now. [00:27:35 CEST] <Thomas_J> All su far so good, still running. [00:32:10 CEST] <Thomas_J> This is the configuration that I used last month and ran well so I am trying it on this device: ./configure --prefix=/usr --enable-gpl --enable-version3 --enable-nonfree --logfile=/var/log/ffmpeg/build2.log --disable-doc --disable-htmlpages --disable-podpages --disable-txtpages --enable-static --enable-gnutls --disable-stripping [00:33:31 CEST] <Thomas_J> Not much there but it's all I need and it's still compiling. [00:45:16 CEST] <Thomas_J> Thanks much for putting up with my feldrecarb. This is going to take time so I'm going to diner. [07:01:31 CEST] <mbnt> Hello? [07:08:23 CEST] <mbnt> I have folders with videos in the following container, https://pastebin.com/ag7XGvzS can anyone advise on a good format to convert them to for the purposes of editing? [07:13:47 CEST] <Henry151> https://bpaste.net/show/Ofda [07:14:38 CEST] <Henry151> i have had this problem repeatedly happening, where I am trying to go from mkv to mp4 and to burn in the subtitles, and it is only getting the first 15 minutes or so of the video, any guidance? [07:20:00 CEST] <Henry151> sorry mbnt , i took a look but haven't got any guidance for you. [07:20:21 CEST] <mbnt> Henry151, That's okay, thanks for looking [07:20:29 CEST] <mbnt> We try [07:24:02 CEST] <Henry151> i can't figure out what's up with my situation.. i run my command, it's supposed to take the mkv as input and give me an mp4 as output; the mkv is like 1.4G and the MP4 that outputs shows up as 4.9G... but when I go to play the mp4 it's only the first fifteen minutes of the video [07:24:28 CEST] <Henry151> so i copied the mp4, and the copy is only 695MB .. it's like the file is only pretending to be 4.9G [07:24:57 CEST] <Henry151> i see the 4.9G when i do an "ls -lh" in the directory where it sits [07:25:41 CEST] <Henry151> but if i make a copy with "cp myvideo.mp4 copyofmyvideo.mp4" the copy command appears to complete successfully, but the copy is only 695MB [08:51:34 CEST] <mbnt> Henry151, Are you there? [08:57:32 CEST] <Henry151> yes! [10:48:07 CEST] <goel> Hi, I am trying to write in only keyframes from an mp4 video using libav. On some videos the keyframes are written in fine but on others I only see a black video and occassionally when I skip forward some distortion. [10:48:23 CEST] <goel> Is this because the keyframe itself does not have much information? [10:48:53 CEST] <goel> Sorry, just to clarify I am opening a sample mp4 and writing a new mp4 with only the keyframes from the sample. [10:49:23 CEST] <pink_mist> that would be my guess [10:49:46 CEST] <goel> Thank you pink_mist [10:52:21 CEST] <void09> trying to do a lossless screen capture. what pixel format do I want to use ? [10:52:46 CEST] <void09> I tried using huffyuv with yuv444p but it says it's not supported, and fell back to yuv 422p [11:03:13 CEST] <durandal_1707> ffvhuff [11:06:57 CEST] <void09> just found it.. thanks [11:07:32 CEST] <void09> but what is the default pixel format of the OS ? rgb or yuv444p ? [11:09:52 CEST] <pink_mist> which OS? (not that I know the answer either way) [11:11:15 CEST] <void09> well, modern ones like windows or linux [11:12:19 CEST] <void09> the video is probably 420, does that mean i should record in 444 and convert to 420 later without losing information? [11:12:34 CEST] <void09> the video i want to record [11:47:31 CEST] <goel> If I scale and output every key-frame (I picture type) in an mp4 to an image I get a complete image, however if I write only that key frame into an mp4 then sometimes the screen is black. Does every keyframe require the minimum GOP size of frames in order for a complete image to be formed? [12:10:13 CEST] <goel> Does anyone know how I can have an intra-only stream? [12:49:06 CEST] <bencoh> with a set of x264 options (unless ffmpeg now has a preset for that, but I doubt it) [13:14:29 CEST] <goel> Ok [13:54:09 CEST] <bencoh> goel: -intra might be what you're looking for by the way (haven't tested) [13:56:20 CEST] <goel> Yeah I saw that, however I looking to do it programmatically using libavcodec. [13:57:13 CEST] <goel> Basically I just want to only have key frames in my output video from the original video. At the moment it works for some mp4s but for others the first key frame shows and doesn't change for the duration of the video. [14:10:52 CEST] <Kadigan_KSB> Hmhm... I'm doing two-pass encoding, and I'm getting an error that "constant rate-factor is incompatible with 2pass". I assume this refers to "-crf", which I don't use (I use "-b:v"). What am I doing wrong to confuse ffmpeg here? [14:14:37 CEST] <DHE> 2pass mode is for when you specify -b because you want to nail the bitrate [14:14:46 CEST] <DHE> if you're not using -b, don't use -pass [14:16:40 CEST] <Kadigan_KSB> I'm using -b:v [14:16:56 CEST] <Kadigan_KSB> (specifically, I'm going for a specific filesize limit) [14:18:10 CEST] <Kadigan_KSB> Interesting... "-b:v 150k" is fine, but "-b:v 2m" causes the error. I assume that's supposed to be "-b:v 2M" and that's probably my issue, but how does that trigger the error? [14:20:35 CEST] <cehoyos> Cannot reproduce [14:20:41 CEST] <cehoyos> I get "too low bitrate" [14:21:56 CEST] <Kadigan_KSB> Switching "2m" to "2M" fixes the problem, so it's clearly that. All I can assume is that either "2m" (or possibly "m") somehow defines it as CRF mode, or otherwise it filters the "m" away as unknown and assumes I meant "-crf 2" due to it being too low otherwise [14:22:12 CEST] <Kadigan_KSB> (I'm using a fairly recent checkout - N-94251-gf83b46e218) [14:24:57 CEST] <cehoyos> Ok, you are using a farily recent checkout but you did not provide a command line [14:25:18 CEST] <BtbN> m just means /1000, and 150/1000 = 0, which means unset, and then it defaults to crf [14:25:21 CEST] <cehoyos> I tested the following:ffmpeg -f lavfi -i testsrc -pass n -t 1 -b:v 2m out.avi [14:57:20 CEST] <Henry151> did anybody get a chance to check out my situation i described above? [14:57:59 CEST] <DHE> Kadigan_KSB: 2m is 2 millibits (0.002 bits per second) which is effectively 0, which is unset [14:58:05 CEST] <DHE> 2M is 2 megabits (2,000,000 bits per second) [14:58:13 CEST] <Henry151> https://bpaste.net/show/Ofda if ya could take a look and let me know if you have any ideas about why the mp4 that came out was only 15 minutes long [15:16:50 CEST] <frogzilla09876> Hi! Probably I found some bug(?) in map option. I use "-map 0:m:language:pol" to select audio streams from .mkv files to .mp4 file. Today I found that some files got encoded _without_ any audio streams. I thought it will fail instead encoding video-only file (no '?' in -map) [15:17:19 CEST] <frogzilla09876> Input file has 1 video stream, 2 audio streams and multiple subtitle streams [15:30:50 CEST] <frogzilla09876> Lost connection last time. Any answer for my problem? [15:31:56 CEST] <durandal_1707> Henry151: why you get so many duped frames? [15:34:40 CEST] <durandal_1707> also where you store files? [15:36:04 CEST] <durandal_1707> frogzilla09876: have you read map option documentation? [15:44:19 CEST] <frogzilla09876> durandal_1707 yes. When another files didn't had audio stream with language=pol ffmpeg just exited. [15:44:46 CEST] <frogzilla09876> This time I got an video-only file which is worst case for me, because it looked like succesfull transcode [15:45:54 CEST] <durandal_1707> i do not think that ffmpeg works like that [15:46:44 CEST] <durandal_1707> you need to inspect video with ffprobe and pick processing on what it found [15:51:38 CEST] <frogzilla09876> Documentation for -map option stands that it will fail if it can't map stream. Index is ok, but match for language has no stream to match, so it should fail. For last few months it just failed, but for few files in last days I got video-only files. [15:51:45 CEST] <frogzilla09876> Still same ffmpeg version [16:01:49 CEST] <durandal_1707> hmm, if you can reproduce it then open bug report [17:04:49 CEST] <Kadigan_KSB> DHE: yeah, I'm not used to letter sizes having any weight (yes, that's my failure here)... and why the hell does ffmpeg allow for reading it as "2 millibits" when it clearly makes no sense in this context? ;D [17:05:29 CEST] <Kadigan_KSB> (though it would make sense then - if it assumes "-b:v 0" and skips it, it would then default to mode crf, whatever happens to be the default crf... and then promptly error out) [17:06:34 CEST] <phryk> How do I move the moov atom of an mp4 file to the beginning of it? [17:07:01 CEST] <kepstin> Kadigan_KSB: the same parser is used for other types of numbers - it makes sense for e.g. seconds (where you get milliseconds) [17:08:00 CEST] <kepstin> phryk: use the "-movflags faststart" option when muxing. A complete command that just remuxes an mp4 might look like `ffmpeg -i source.mp4 -map 0 -c copy -movflags faststart dest.mp4` [17:08:46 CEST] <kepstin> phryk: depending on your ffmpeg build, you might also have the "qt-faststart" tool available, which does the same thing but a bit faster. [17:10:47 CEST] <phryk> kepstin: thanks. don't have qt-faststart, but will evaluate -movflags faststart :) [17:10:57 CEST] <kepstin> phryk: note that you can use the -movflags faststart option while encoding to mp4, to avoid having to run a separate command later to reposition the moov. [17:11:25 CEST] <kepstin> (that option causes ffmpeg to do a second pass after the encode is complete where it rewrites the file with the moov at the start) [17:17:26 CEST] <phryk> kepstin: that worked. thanks. :) [17:31:15 CEST] <Kadigan_KSB> kepstin: okay, sure; wouldn't it make sense to somehow limit it to -sane- values, per context? The error I got is clearly a bug, as it was most uninformative as to what actually happened - and if you're going to put in the effort to show an error message saying "2 millibits: invalid range" or something, you can just as well put in the same effort into auto-ranging the variable... [17:32:44 CEST] <Kadigan_KSB> s/as/and [17:33:28 CEST] <Kadigan_KSB> But anyway. Thanks for explaining the issue, it's always good to know these things. [17:38:03 CEST] <kepstin> Kadigan_KSB: in particular, the numbers are parsed using the generic expression evaluator. to see the complete list of supported suffixes, take a look at https://www.ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation (have to scroll down a bit) [18:04:37 CEST] <Henry151> durandal_1707: I am not sure why I get so many duped frames... I am storing the files on my home server, which is also where I am running the ffmpeg command [18:05:34 CEST] <Henry151> i kept thinking i "had it" because the command seems to work, but then when I go to play the final output file, it turns out to be only the first 15 minutes of the video, then it just stops [18:06:21 CEST] <Henry151> this is like, third time of thinking "i got it! time to do it to my whole collection!" and then doing it to my whole collection and having dozens of these 15-minute-or-shorter mp4 videos [18:07:13 CEST] <Henry151> durandal_1707: i'm also not sure how to read the log, i'm not sure where you're seeing the duped frames or what that means exactly. [19:28:54 CEST] <dastan> hello people [19:29:21 CEST] <dastan> does anyone have a manual to compile FFMPEG in windows with the decklink SDK [19:29:22 CEST] <dastan> ? [19:39:23 CEST] <dastan> people??? [19:58:19 CEST] <pink_mist> dastan: there's lots of people here, but they all know that if they don't have an answer to your question, it's best to not say anything so your question remains visible to more people who might know the answer [20:00:46 CEST] <dastan> ok ok [20:00:50 CEST] <dastan> sory pink [20:01:07 CEST] <dastan> i am not a windows user, i use ffmpeg on linux [20:01:26 CEST] <dastan> but i need to make a working compilation for my work based on windows [20:20:08 CEST] <pink_mist> dastan: you can always use a linux VM, or WSL [20:24:06 CEST] <barg> if i do ffmpeg -i blah.mp4 -ss 0:00:00 -to 00:05:00 -a:c -v:c blah2.mp4 is that right, no need to re-encode, but should copy the codecs so it doesn't put default ones in? [20:25:13 CEST] <BtbN> -ss 0 is kinda pointless [20:25:22 CEST] <BtbN> cause starting from the start is what it does anyway [20:29:30 CEST] <kepstin> also "-a:c" and "-v:c" are incorrect syntax, you probably want to use "-c copy" (which will apply to all streams). [21:08:11 CEST] <void09> are yuv444 and rgb888 losslessly convertible to each other ? I've been googling and readin for an hour now and I still don't get it [21:20:37 CEST] <DHE> void09: not exactly [21:21:19 CEST] <void09> which is the one I want to use if I want a lossless screen capture? [21:23:02 CEST] <DHE> try ffprobe and see what it thinks it's capturing with. probably rgb but when in doubt, check [21:23:06 CEST] <BtbN> not entirely, the yuv/rgb formular are not perfect, and there's a bunch of different ones [21:27:54 CEST] <void09> how can i do ffprobe for the display (x11grab ?) [21:28:30 CEST] <kepstin> you can use the -f option with ffprobe to specify the input format. [21:28:44 CEST] <kepstin> but x11grab will pretty much always be rgb, i think [21:33:06 CEST] <void09> ok so I will go with rgb then. I assumed as well that's what the OS/gpu uses internally [21:34:34 CEST] <void09> the source video I want to capture is x264 which only uses yuv, so I guess the transformation from yuv420 to rgb is already lossy ? [21:35:18 CEST] <kepstin> in theory, yuv420rgbyuv420 is reversible if you use the exact same calculations/rounding for both conversions. [21:35:37 CEST] <kepstin> in practice ... probably won't happen, especially if you're using different software. [21:36:06 CEST] <void09> video player is the one that does yuv420 to rgb ? [21:36:32 CEST] <kepstin> either video player or graphics driver depending on the particular playback method used [21:38:21 CEST] <kepstin> why would you do screen capture of video playback anyways when you could just use the original video as input to ffmpeg? [21:38:34 CEST] <void09> theoretical experiments [21:41:15 CEST] <void09> if the video is 24 fps, what's the frame rate i should use for recording to make sure there's no frames missed? 24 ? [21:42:19 CEST] <kepstin> capture at screen framerate, then de-duplicate and dejudder afterwards [21:42:44 CEST] <void09> dejudder.. i'll have to read about that [21:43:33 CEST] <kepstin> typical screen framerate is 60hz, to play a 24hz video on it you hold one input frame for 2 output frames, then the next for 2 output frames. The timing difference is "judder". [21:44:09 CEST] <kepstin> er, one for 3 output frames, the next for 2 [21:44:38 CEST] <void09> right, so you get 2/5 of 60 [21:45:01 CEST] <kepstin> of course, many players sync to audio clock rather than screen frame timing, and monitor timings aren't exactly 60hz, and ntsc video's actually 24/1.001hz, so it's all a mess [21:45:10 CEST] <kepstin> just grab all the frames and hope you can fix it later :) [21:45:15 CEST] <void09> :D [21:45:37 CEST] <void09> do you think viewing a 24fps video on an 120hz monitor will appear a bit more smooth vs 60 ? [21:45:57 CEST] <kepstin> 24fps can be played perfectly smoothly on a 120hz monitor [21:45:59 CEST] <void09> cause then it will hold one input frame for 5 output frames, no.. judder [21:46:24 CEST] <void09> yes, but will anyone/most notice the difference? [21:46:40 CEST] <kepstin> also consider using kmsgrab rather than x11grab if your system supports it [21:48:52 CEST] <kepstin> it's mostly noticable on slowish pans and whatnot. i find it kind of annoying to the point where I usually use the 24hz mode when playing stuff on a tv which supports it. [21:49:00 CEST] <void09> that looks very complicated to use, but I will keep it in mind for the future [21:49:34 CEST] <void09> oh wow, I didn't think about that [21:49:49 CEST] <void09> maybe some video player has the option to this automatically ? [21:51:41 CEST] <kepstin> mostly not, because at least on linux there's no way to automatically revert it on app exit/crash. nothing really stopping it tho. I have a friend who made some video player wrapper scripts that use xrandr to do that. [21:52:35 CEST] <kepstin> i've heard that some players on windows might (at least when fullscreen?) use freesync/g-sync to time frames more accurately to avoid judder, which also sounds kinda neat. [21:58:44 CEST] <aam> Hey everyone, I'm using ffmpeg to stream rtmp and I was hoping to find a way to be able to pause videos but still keep the stream running. I'm not sure how to go about it but I was thinking maybe having another ffmpeg instance in between to "hold" the stream alive? But I'd also need a way to actually pause the first ffmpeg instance (I've read about suspending the process, but I'm not sure how terrible that [21:58:46 CEST] <aam> is) [21:58:52 CEST] <aam> sorry for the long message [22:00:37 CEST] <kepstin> aam: the ffmpeg cli tool wasn't really designed for doing live mixing sort of stuff, and doesn't really support this use case. consider using obs instead? a custom app using ffmpeg libraries could be done too. [22:01:52 CEST] <aam> Understandable, I'll have to find a obs equivalent that can run in the command line and I'll feed that to ffmpeg for streaming further [22:41:00 CEST] <Thomas_J> . [22:51:44 CEST] <Thomas_J> I need help with injesting external audio as 2nd channel. when I use "-f alsa" (libasound2 is installed), I get "Unknown input format: 'alsa'". Since tArmbian uses pulseaudio, I recompiled ffmpeg with "--enable-libpules", run ffmpeg using "-f pulse" and I get "plughw:CARD=rockchipes8316c,DEV=0: No such process". [22:53:06 CEST] <kepstin> Thomas_J: you used an alsa device name, which doesn't work with pulseaudio. you need to use a pulse source name. run `pacmd list-sources` [22:53:43 CEST] <Thomas_J> got it, thanks. [22:53:46 CEST] <kepstin> the stuff between the <> in the "name:" field is what you can use as an input name for pulse [22:53:52 CEST] <kepstin> or the string "default" works too [22:55:47 CEST] <Thomas_J> Intresting. My Pulse audio server is not running. [22:56:22 CEST] <kepstin> it's usually autostarted when an app tries to use it. [22:58:32 CEST] <kepstin> that said, your ffmpeg should support using alsa directly, i dunno what's up with that. probably you're missing the -dev packages for the alsa libraries. the config log will probably explain the problem. [23:00:52 CEST] <Thomas_J> aaaahhh, the -dev! [23:01:46 CEST] <Thomas_J> but pulseaudio not running is probably why audio is not working at all on this unit. [23:08:01 CEST] <void09> trygint to record screen with simplescreenrecorder, using ffvhuff and option "pixelformat=rgb" [23:08:59 CEST] <void09> i get tihs in the output log: [FastScaler::Scale] Warning: Pixel format is not supported (28 -> 2), using swscale instead. This is not a problem, but performance will be worse. [23:09:23 CEST] <kepstin> note that simplescreenrecorder uses gstreamer, so while it can use ffmpeg's encoders/decoders, that's the only things from ffmpeg it uses. [23:09:32 CEST] <void09> ohhhh [23:10:15 CEST] <kepstin> that sounds like something in the screen grabbing code is trying to use a gpu format converter, but can't. [23:10:33 CEST] <void09> but rgba works [23:10:34 CEST] <kepstin> check what format '28' is, it's possible that it's just a different rgb layout which you can request [23:10:37 CEST] <void09> i mean i get no error [23:10:49 CEST] <void09> how can I check that? [23:11:05 CEST] <kepstin> probably have to look into gstreamer header files :/ [23:11:28 CEST] <void09> well, the output file looks correct, using rgb0 [23:13:29 CEST] <kepstin> that should be good then. I bet the "rgb" layout is 24-bit, while the framebuffer is probably 32bit (with alpha or padding). [23:17:02 CEST] <w1d3m0d3> can I add a blank video track (1x1 black pixel for example) to an mp3? [23:17:51 CEST] <kepstin> w1d3m0d3: mp3 doesn't support "video" tracks, but ffmpeg sort of represents cover art as a video track. So you can put a single frame jpeg or png encoded "video' into an mp3 and i think it'll be saved as cover art? [23:18:19 CEST] <w1d3m0d3> er, I meant to create a new whatever video-supporting format, add that mp3 as the audio track and another 1x1 black video track to it kepstin [23:18:42 CEST] <kepstin> sure, no problem doing that [23:19:05 CEST] <kepstin> (i suppose your real question is "how can i..."?) [23:19:14 CEST] <w1d3m0d3> yes, that would be it, thanks [23:20:59 CEST] <kepstin> something like "ffmpeg -i input.mp3 -f lavfi -i "color=c=black" -map 0 -map 1 -c:a copy -c:v libx264 -shortest output.mkv" will do the trick. [23:21:45 CEST] <pink_mist> oh, does it default to 1x1? [23:21:56 CEST] <kepstin> nah, 320x240 [23:22:01 CEST] <w1d3m0d3> the dimensions were an example, any would work [23:22:18 CEST] <kepstin> but a single-color DC frame is tiny no matter the size :) [23:22:57 CEST] <kepstin> see https://www.ffmpeg.org/ffmpeg-filters.html#allrgb_002c-allyuv_002c-color_00… if you want to change the options on the color filter (change framerate, size, etc) [23:23:47 CEST] <kepstin> note that the color filter makes rgb video, and i think the libx264 encoder defaults to encoding yuv444p then. I recommend also adding "-pix_fmt yuv420p" to make it compatible with more players. [23:23:51 CEST] <kepstin> (just throw that before the output filename) [23:27:42 CEST] <w1d3m0d3> that worked, thanks [23:46:03 CEST] <bencc> can I use h264 hardware accelerations on google cloud skylake cpus or do I need a gpu? [23:56:25 CEST] <kepstin> bencc: i'm not sure exactly which cpus they're using, but most high-core-count xeon cpus contain only cpu cores, no gpu, and therefore also do not include the hardware encoder. [00:00:00 CEST] --- Wed Aug 14 2019

1 0

ffmpeg-devel.log.20190812
by burek 13 Aug '19

13 Aug '19

[00:44:16 CEST] <kierank> durandal_1707: it's not hack [00:44:25 CEST] <kierank> same way ffmpeg don't support all the drc and loudness stuff in ac3 [00:44:27 CEST] <kierank> it matters in real world [00:44:34 CEST] <kierank> but not in neckbeard players like mplayer [00:47:59 CEST] <durandal_1707> lies [00:56:39 CEST] <BradleyS> HandBrake does, feel free to borrow code but it's probably GPL 2.0 [00:57:24 CEST] <BradleyS> i forget what in ffmpeg is lgpl [00:59:17 CEST] <jamrial> everything except some ancient filters [01:13:18 CEST] <J_Darnley> I think I have some flac assembly under gpl [01:20:44 CEST] <cehoyos> Correct [01:33:20 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:cf3ca3363a84: LICENSE: Fix path to libswresample test file. [01:42:05 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:8abbe717f847: LICENSE: Remove a file that does not exist anymore. [01:47:38 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:9fdc7f1b0390: LICENSE: Add missing filters licensed under the GPL. [01:51:29 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:00aa096202ce: LICENSE: Clarify that lensfun is GPLv3+. [01:56:51 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:02c0268d5c0f: LICENSE: Update list of GPLv2 libraries. [02:27:13 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:aecf5cbd6802: LICENSE: Add missing libraries that need --enable-version3. [08:46:53 CEST] <cone-860> ffmpeg 03Michael Niedermayer 07master:cd460f4da04c: avcodec/hnm4video: Optimize postprocess_current_frame() [08:46:53 CEST] <cone-860> ffmpeg 03Michael Niedermayer 07master:9e0e9a5f3619: tools/target_dec_fuzzer: Limit number off all pixels decoded [09:00:22 CEST] <cone-860> ffmpeg 03Michael Niedermayer 07master:faa9cd312f02: tools/target_dec_fuzzer: Add missing breaks [11:15:09 CEST] <atbd> hi, i'm currently adding EPG support to libavformat/mpegts. For now, i succeed to packetize them in AVPacket. But i'd like to know if i can export a simplified struct to read them (EPGEvent struct) or do i need to export them through AVFrame sidedata or metadata ? Having a specialized struct to interact with users would also simplified writing EPG data [11:15:37 CEST] <atbd> If I can make it available where do I can put it ? [11:45:56 CEST] <Lynne> side data. [11:59:50 CEST] <atbd> okay thanks. Can I put the struct in libavutil like others describing sidedata ? [12:02:07 CEST] <Lynne> yes [12:02:42 CEST] <atbd> cool, ty ! [14:52:10 CEST] <durandal_1707> michaelni: if you do not reply i wil nak every single of your patches! [14:56:23 CEST] <kierank> durandal_1707: lol maybe michaelni blocked you [16:25:07 CEST] <ubitux> https://picsum.photos/ [16:25:30 CEST] <ubitux> didn't know that; can be useful to get (picture) sample for specific filters [16:28:02 CEST] <ubitux> mmh, looks like it's artificial filters; i was under the impression it was querying random pictures with special properties [16:28:09 CEST] <ubitux> i guess it's less useful then [16:41:48 CEST] <durandal_1707> michaelni please answer me [16:49:56 CEST] <durandal_1707> you are living proof that ffmpeg is just organization under your dictatorship [16:49:59 CEST] <nevcairiel> you sound like a whiny child, get yourself together, not everyone sits on irc 24/7 [16:51:43 CEST] <durandal_1707> why you tolerate michaelni dictatorship, you two share something in common? [17:00:50 CEST] <durandal_1707> im calling out for exraordinary ffmpeg meeting! [17:03:03 CEST] <durandal_1707> 1. topic is: michael unresponsive behaviour [17:06:26 CEST] <Lynne> "fixing" timeouts in one fuzzed paintbrush pcx file is more important than responding [17:06:38 CEST] <Lynne> as we speak thousands of bad people are sending youtube that one file causing their servers to cry because it decodes 2s slower than it could [17:12:48 CEST] <durandal_1707> its shame [17:30:08 CEST] <durandal_1707> i should switch to Libav... [17:32:29 CEST] <bencoh> >_> [17:34:39 CEST] <nevcairiel> even better make your own fork! [17:40:42 CEST] <durandal_1707> you clearly can not tolerate my presence, so why should i listen to you? [17:45:16 CEST] <jamrial> durandal_1707: please, calm down [18:13:24 CEST] <durandal_1707> i hereby relicense all my code to AGPL. please comply with this or i will be forced to remove all my contributions [18:15:33 CEST] <nevcairiel> good luck with that [18:16:46 CEST] <BtbN> Is CC extraction even the job of the hardware decoder? Or should the common h264 parsing code do it? [18:22:53 CEST] <kierank> BtbN: decoder [18:23:00 CEST] <kierank> Need reordering [18:23:07 CEST] <kierank> Ergo it's a decoder problem [18:23:25 CEST] <BtbN> So a53 CCs are broken on all native hwaccels? [18:23:31 CEST] <kierank> Hardware decoders are useless anyway [18:23:50 CEST] <kierank> Decoding h264 is fast and easy [18:24:08 CEST] <BtbN> Firefox and Twitch stats disagree [18:24:19 CEST] <BtbN> majority of peoples CPUs are too slow to decode 1080p60 [18:27:16 CEST] <durandal_1707> michaelni: i did not ask if you need help, i requested subscription. please comply. [18:28:39 CEST] <durandal_1707> but CC needs to be displayed by law [18:40:52 CEST] <kierank> BtbN: probably single threaded or otherwise crap decoding pipelinr [18:41:04 CEST] <kierank> I can decode that in CPU on some 50 dollar sbc [18:41:17 CEST] <BtbN> You underestimate how ship some peoples CPUs are [18:41:20 CEST] <BtbN> *shit [18:41:42 CEST] <BtbN> And even if the CPU can do it, it's a waste of resources and energy, cause the hwdec can do it way more efficiently [18:41:50 CEST] <durandal_1707> everyone use potatoes as computers [18:42:52 CEST] <kierank> Can't do 4:2:2 or 10-bit [18:43:07 CEST] <kierank> Or closed captions [18:43:08 CEST] <kierank> Or afd [18:43:17 CEST] <kierank> Or other things needed to watch correctly [18:43:32 CEST] <BtbN> a53 cc are not the job of the hardware [18:43:44 CEST] <durandal_1707> its blackbox [18:45:21 CEST] <nevcairiel> the native hwaccels should do stuff like CC or AFD just fine, since they behave much like a software decoder and only send s lices to the hardware [18:45:31 CEST] <nevcairiel> at least how ffmpeg builds them [18:45:33 CEST] <kierank> BtbN: it's the job of the hardware to reorder [18:45:42 CEST] <nevcairiel> not in ffmpeg, no [18:45:45 CEST] <BtbN> no it's not, ffmpegs parsers do it [18:45:51 CEST] <nevcairiel> we only decode slices with hardware [18:45:55 CEST] <nevcairiel> litereally anything else is software [18:46:16 CEST] <kierank> For all hardware? [18:46:39 CEST] <nevcairiel> for all that exposes that capability [18:46:51 CEST] <nevcairiel> which at least covers the one we were talking about regarding that issue [18:47:02 CEST] <kierank> Ok [18:47:18 CEST] <BtbN> I'd be very surprised if CCs are generally broken on all hwdecs. But I'd also be confused if it's only broken on nvdec, cause... how? [18:48:38 CEST] <nevcairiel> the ticket looks like he uses cuvid though [18:48:39 CEST] <nevcairiel> not nvdec [18:48:42 CEST] <nevcairiel> so there is your answer [18:50:09 CEST] <kierank> durandal_1707: you have answer from michaelni [18:51:15 CEST] <durandal_1707> 2nd one? 1st one i already read and replied here [18:56:10 CEST] <kierank> durandal_1707: reply on ml [19:00:31 CEST] <BtbN> hm, with the CUDA filters being freed now, I'd very inclined to officially slap a deprecated sign on cuvid [19:01:39 CEST] <BtbN> Only thing missing for full feature parity is vf_transpose_cuda, which I might find time too look into the next couple days [19:02:15 CEST] <BtbN> hm, and vf_crop_cuda I guess [19:02:23 CEST] <durandal_1707> write hw pad filter instead [19:03:39 CEST] <BtbN> Could just write one filter that exposes both the crop and the pad interface [19:17:41 CEST] <durandal_1707> anybody happy with my sierpinski video source? [19:21:15 CEST] <durandal_1707> be honest, stop hiding your feelings [19:22:10 CEST] <BtbN> sierpinski as in the fractal? [19:23:46 CEST] <durandal_1707> sierpinski carpet fractal [19:24:18 CEST] <BtbN> That seems like a decent video encoder test pattern [19:25:10 CEST] <durandal_1707> how so? its useless, i write only useless stuff [19:25:57 CEST] <BtbN> Hm? It's seemingly "random" tons of moving stuff. As compared to the other static test sources. [19:26:03 CEST] <BtbN> While not being white noise [19:26:55 CEST] <durandal_1707> i need to add colors and little of panning [19:27:13 CEST] <durandal_1707> it already have zoom [19:29:12 CEST] <Lynne> anything with sharp edges is a good encoder test pattern, unless you're av1 or vp9, then you deny their existance [20:01:11 CEST] <BtbN> I do not undestand what that guy is saying. [20:09:36 CEST] <nevcairiel> apparently its slower [20:12:02 CEST] <nevcairiel> probably needs to set the hwaccel output format? [21:36:52 CEST] <durandal_1707> typical ffmpeg developer behavior: https://youtu.be/U1FxfR3lg6Q [21:47:26 CEST] <Compn> durandal_1707, then ask on the ml to get security access with a vote [21:47:29 CEST] <Compn> like always [21:48:11 CEST] <Compn> i'm torn between voting foryou to have access just to stfu or starting a vote to have you removed for harassing michaelni [21:48:32 CEST] <Compn> i am not sure why kierank is encouraging your behavior either [21:49:35 CEST] <durandal_1707> you are all leader's peasant [21:50:32 CEST] <BradleyS> i haven't seen the source but it sounds like nyancat [21:51:05 CEST] <BradleyS> maholcat [21:51:24 CEST] <durandal_1707> what? [21:51:41 CEST] <BradleyS> your sierpinski source [21:52:04 CEST] <durandal_1707> watch video it explains everything [21:52:31 CEST] <durandal_1707> sierpinski have nothing to do with cat [22:04:00 CEST] <durandal_1707> cehoyos: do you have access to security ml? [22:05:07 CEST] <cehoyos> Yes, but I cannot recommend it [22:06:16 CEST] <durandal_1707> why? [22:08:34 CEST] <cehoyos> The amount of unreadable emails from Google is very large [22:10:30 CEST] <durandal_1707> how so? michaelni claims it get lower as code coverage stays same [22:18:36 CEST] <cehoyos> I missed an appointment a month ago because of the huge number of emails, I am not saying it gets lower or bigger [22:19:49 CEST] <BtbN> So far every project I have seen where Google dropped their Fuzzing mails was mostly annoyed by it. [22:20:08 CEST] <BtbN> Some super aggressive and short tampered person shows up, claiming to have found 900 security bugs. [22:20:25 CEST] <durandal_1707> huh? [22:20:52 CEST] <BtbN> Seen that happen at 5 independend projects. Always thought it was a troll at first. But it was actually Google having run a fuzzer. [22:22:41 CEST] <durandal_1707> this is different. now overflows and timeouts are of security importance [22:22:58 CEST] <durandal_1707> whats next step? [22:23:13 CEST] <BtbN> Yes, for some reason, everything a fuzzer finds, is automatically a security bug. [22:24:02 CEST] <durandal_1707> previously reports would be done differently [22:24:20 CEST] <durandal_1707> now its one big mess [22:24:21 CEST] <BtbN> Maybe the fuzzing stuff needs a dedicated ml of some kind? [22:26:48 CEST] <durandal_1707> aha, eureka: next step is fuzzing filters [22:29:05 CEST] <nevcairiel> its really only encoded bitstreams that can be fuzzed [22:29:14 CEST] <kierank> nevcairiel: you can fuzz aac encoder [22:29:19 CEST] <kierank> I found real bugs [22:30:03 CEST] <nevcairiel> probably unexpected float nan/inf [22:30:13 CEST] <nevcairiel> but integer stuff in filtering? [22:30:41 CEST] <BtbN> I'm sure you can find some super long running loops or edge cases by piping in the right garbage [22:30:46 CEST] <durandal_1707> nevcairiel: nope, there are even commits that fix bugs in one filter with using certain parameters [22:31:07 CEST] <nevcairiel> well i suppose can fuzz config parameters, instead of raw input data :D [22:31:13 CEST] <Lynne> with timeout bugs you need some really really really ridiculous probabilities to form the exact sequence to slow the decoder by 2s [22:33:30 CEST] <BtbN> Why is "encoder hangs for 2s" even an issue that needs fixed? Hangs forever with 100% CPU sure is, but hanging for 2s? [22:33:39 CEST] <kierank> nevcairiel: divide by zero [22:38:14 CEST] <Lynne> BtbN: After asking the same question so many times I still don't know [22:38:54 CEST] <thardin> hum, mxfenc regression [22:38:57 CEST] <Lynne> like how is a 2, even 10s delay on an astronomically improtably combination of bits a security issue [22:40:17 CEST] <Lynne> even the samples are treated the same way actually imporatant issues are like arbitrary code execution [22:41:00 CEST] <durandal_1707> because it may kill path that leads to real security one [22:43:01 CEST] <BtbN> a non-overflow path, where all it does is cause a loop to run for very long? [22:43:26 CEST] <durandal_1707> but it is like winning loterry [22:43:39 CEST] <Lynne> my favorite ones are the timeouts that get fixes by pseudo-SIMD like AV_RN/WNXX hack [22:44:26 CEST] <durandal_1707> yes [22:44:31 CEST] <thardin> you can DoS certain services with bugs like that [22:44:39 CEST] <BtbN> With a 2s hang? [22:44:44 CEST] <durandal_1707> lol [22:45:15 CEST] <thardin> well, if it's a tiny file and I can somehow upload a bunch of them quickly [22:45:24 CEST] <Lynne> they're not even hacks, you can't argue they don't speed every platform up but seeing some weird bitops instead of adds/mults is just dubious [22:46:03 CEST] <thardin> or just make the file longer. I'm sure there's plenty of cases [22:46:10 CEST] <durandal_1707> lets stop this nonsense, and let reports in old fashioned way? [22:46:20 CEST] <BtbN> trac would die [22:46:55 CEST] <durandal_1707> huh? not really [22:47:12 CEST] <BtbN> It's already struggling with the current volume of users hitting on it [22:47:17 CEST] <kierank> thardin: you should limit timeouts at the OS [22:47:31 CEST] <kierank> when handling untrusted data of any sort [22:49:06 CEST] <thardin> myes, sandboxing and so on [22:56:52 CEST] <tmm1> jkqxz: i bisected that vbr regression to https://github.com/FFmpeg/FFmpeg/commit/2562dd9e7831743ba6dc5680501fb7d26a2… [23:14:45 CEST] <thardin> bisecting #8077 [23:31:36 CEST] <jamrial> thardin: there were some recent changes to mxfenc mostly for h264 streams [23:34:30 CEST] <thardin> this is d10 tho, so mpeg2 [23:35:37 CEST] <cehoyos> Why do you want to bisect 8077? [23:35:49 CEST] <thardin> because I'm lazy [23:37:10 CEST] <cehoyos> You can also open the ticket;-) [23:45:18 CEST] <thardin> ah, now I see what you mean [23:48:18 CEST] <thardin> I don't really think this is a bug with mxfenc but rather the way the mpeg2 stream is encoded [23:48:40 CEST] <thardin> since it should be CBR but evidently isn't [23:52:50 CEST] <thardin> but then again, how could you make CBR with NTSC? [23:53:12 CEST] <thardin> 1001 doesn't divide 50000000 [23:58:24 CEST] <thardin> S356m has some specific frame size limits that I don't see mentioned in mxfenc.c [23:58:47 CEST] <thardin> or mxf.* [00:00:00 CEST] --- Tue Aug 13 2019

1 0

ffmpeg.log.20190811
by burek 12 Aug '19

12 Aug '19

[00:02:29 CEST] <jgb> who do i have to beg if i want to get this fixed: https://trac.ffmpeg.org/ticket/7912 [00:07:09 CEST] <nicolas17> wew [00:07:31 CEST] <nicolas17> I built ffmpeg git-master with libaom git-master to see if that encoded faster than whatever crap Debian Testing ships [00:07:34 CEST] <nicolas17> SIGFPE [00:09:11 CEST] <nicolas17> hm aom is unrelated, the exception happens in the audio encoding [00:15:58 CEST] <cehoyos> How can I reproduce? [00:16:30 CEST] <jgb> cehoyos how much do you need? [00:16:56 CEST] <cehoyos> nicolas17: How can I reproduce the exception? [00:17:15 CEST] <jgb> cehoyos how much money do you need? [00:18:30 CEST] <DHE> can you run the ffmpeg_g binary under gdb and get a stack trace or something? [00:18:32 CEST] <nicolas17> I have a few factors to rule out first... and I need to repro with an input that isn't 3GB [00:25:02 CEST] <jgb> i will pay $$$ to get this fixed: https://trac.ffmpeg.org/ticket/7912 [00:25:06 CEST] <nicolas17> this is *weird* [00:25:21 CEST] <nicolas17> https://pastebin.com/1zR9ykqq the crash is in the aac audio encoder but it only happens if I use aom as video codec?! [00:26:35 CEST] <jgb> i will pay $$$ to get this fixed: https://trac.ffmpeg.org/ticket/7912 [00:27:31 CEST] <nicolas17> DHE: ^ stack trace [00:27:37 CEST] <cehoyos> nicolas17: Please also provide the complete, uncut console output [00:28:45 CEST] <cehoyos> No division happens in line 680 of libavcodec/aacpsy.c afaict... [00:29:42 CEST] <DHE> doesn't have to be division [00:31:07 CEST] <cehoyos> I don't think the others can happen in a C program... [00:31:20 CEST] <jgb> cehoyos i will pay $$$ to get this fixed: https://trac.ffmpeg.org/ticket/7912 [00:32:42 CEST] <nicolas17> DHE cehoyos: https://pastebin.com/7cTddMBn [00:33:04 CEST] <DHE> nicolas17: disassemble [00:33:15 CEST] <nicolas17> I did, bottom of paste :) [00:33:27 CEST] <DHE> ah, so you did [00:33:37 CEST] <jgb> DHE i will pay $$$ to get this fixed: https://trac.ffmpeg.org/ticket/7912 [00:34:10 CEST] <DHE> jgb: due to my line of work I must refuse [00:34:10 CEST] <cehoyos> Please provide 0.ts [00:34:36 CEST] <nicolas17> https://vod-secure.twitch.tv/9a9548d02b0de016012b_kayradim_34830321904_1245… [00:34:47 CEST] <DHE> I also don't do unsolicited report unless I feel like it [00:34:50 CEST] <DHE> *support [00:36:00 CEST] <DHE> nicolas17: that's weird. what's "p spread_en[w+g-1]" (and all the other terms I guess) give? anything NaN or some kind of bonkers number? [00:36:29 CEST] <nicolas17> I just tried with 5 random .ts files from this HLS stream and they all SIGFPE, so I'm not sure if the input matters [00:36:50 CEST] <cehoyos> To me this looks like a compiler or hardware problem [00:37:13 CEST] <cehoyos> Do I understand correctly that it does not happen without video encoding? [00:37:29 CEST] <DHE> or if you used libx264 the crash would go away? [00:37:29 CEST] <cehoyos> Does it always happen at exactly the same position? [00:37:42 CEST] <cehoyos> Does it happen with -threads 1? [00:38:15 CEST] <nicolas17> it doesn't even get to print the status bar so it looks like the very beginning of the input [00:38:32 CEST] <nicolas17> still happens with -threads 1 [00:39:24 CEST] <nicolas17> I tried -c:v mpeg1video and it doesn't happen (I didn't build this ffmpeg with libx264 support, I can try that) [00:39:43 CEST] <DHE> that seems sufficient... [00:40:31 CEST] <nicolas17> I'll try using clang, maybe we can blame gcc [00:40:50 CEST] <cehoyos> Does the crash also happen with valgrind? [00:41:28 CEST] <DHE> I am leaning towards some kind of miscompile or hardware issue involving advanced instructions... [00:41:59 CEST] <DHE> maybe -threads 1 on both input and output. when debugging you should not see any lines like "[New Thread 0x7ffff757d700 (LWP 17706)]" and put it on a fixed CPU core/thread... [00:42:24 CEST] <nicolas17> hm, doesn't crash with valgrind (status bar goes to frame=11 and then gets glacial-slow for obvious reasons) [00:42:30 CEST] <DHE> taskset 0x01 ffmpeg -threads 1 -i input.ts [...] -threads 1 output.ts [00:42:49 CEST] <nicolas17> DHE: I totally forgot that -threads was a per-file option [00:42:58 CEST] <DHE> if I got that right. I don't normally use taskset [00:46:39 CEST] <cehoyos> Your command line is slow here but works / does not crash [00:46:58 CEST] <DHE> then it'll probably never finish on valgrind... [00:47:08 CEST] <DHE> did you try the taskset+single-thread command? [00:47:53 CEST] <DHE> actually taskset alone may force single-threaded operation [00:48:05 CEST] Action: DHE has some dual 20-core CPUs and ffmpeg goes a little bit crazy on those. :) [00:48:19 CEST] <DHE> *dual-socket [00:48:39 CEST] <nicolas17> ok I finally have a significant clue... with libaom 1.0.0 it doesn't crash [00:48:45 CEST] <nicolas17> this calls for a git-bisect [00:48:50 CEST] <DHE> oh my... [00:49:46 CEST] <cehoyos> I only have 1.0.0 [00:49:58 CEST] <DHE> you probably need to delete libavcodec/libaom*.o after each rebuild of libaom to make sure ffmpeg builds okay with the new version. [00:50:28 CEST] <cehoyos> You could also PRELOAD the dll... [00:50:38 CEST] <DHE> worried about header file changes in libaom [00:50:48 CEST] <DHE> is the ABI stable in git? [00:56:05 CEST] Action: DHE is test building a Git version of aom [01:05:16 CEST] <DHE> no crash with the commandline from your pastebin and sample 0.ts file [01:05:32 CEST] <DHE> (also I see the encoder is MUCH faster than it was when I first experimented with AV1) [01:07:12 CEST] <another> DHE: when i first switched to HEAD from 1.0.0 it was 40% faster [01:09:12 CEST] <DHE> another: I did a test encode of a 1080p video back when AOM made their big press announcement of the codec's "readiness". iirc it was like 10+ minutes per frame. now this is 720p but I'm getting 0.8fps [01:10:09 CEST] <nicolas17> when I tried 1.0.0 yesterday it did 35 frames in 6 minutes according to ffmpeg's status bar, but it took its sweet extra time to 'flush' at the end too [01:10:58 CEST] <DHE> internal buffering of frames is pretty common for rate estimation, motion compensation, and b-frames. even x264 want to buffer 30+ (more?) frames with default settings [01:13:01 CEST] <nicolas17> wow [01:13:12 CEST] <nicolas17> bisect is still running but from the list of remaining revisions I have an uhhh strong candidate [01:13:26 CEST] <nicolas17> https://aomedia.googlesource.com/aom/+/85d00fa8e23ea067c246d45b86f26c78bfcb… [01:13:36 CEST] <nicolas17> https://aomedia.googlesource.com/aom/+/85d00fa8e23ea067c246d45b86f26c78bfcb… better link [01:14:53 CEST] <DHE> that seems plausible [01:15:09 CEST] <nicolas17> yep, bisect finished and points there [01:16:50 CEST] <DHE> that seems like it could be a trac ticket. aac encoder may overflow, causes SIGFPE on new versions of AOM-AV1 [01:17:01 CEST] <DHE> (or just custom apps that make use of the same thing) [01:17:36 CEST] <DHE> actually I think I would blame aom more, a library tampering with global process configuration [01:17:50 CEST] <nicolas17> hrmmm [01:17:55 CEST] <nicolas17> is that per process or per thread? [01:19:13 CEST] <DHE> at this point I don't think it particularly matters. [01:19:39 CEST] <nicolas17> aom seems to be setting and *restoring* the state of floating point exceptions and precision [01:19:59 CEST] <nicolas17> within aom_codec_encode [01:21:43 CEST] <cehoyos> I was able to reproduce [01:22:01 CEST] <cehoyos> My knowledge of the C standatd is not sufficient to understand if there is a bug in FFmpeg or a bug in libaom [01:23:18 CEST] <DHE> nicolas17: did you try my taskset commandline? [01:24:30 CEST] <nicolas17> with taskset, and -threads 1 on both input and output... still FPE [01:25:02 CEST] <DHE> so that leaves me with the assumption that the "restore state" code isn't working properly [01:25:20 CEST] <DHE> on the plus side it looks like a debug feature, so doing a non-debug AOM build should eliminate it... [01:26:07 CEST] <cehoyos> Interestingly, it doesn't matter which define I pass to feenableexception(), everything !=0 crashes [01:26:20 CEST] <nicolas17> wut [01:26:30 CEST] <nicolas17> is aac triggering every possible exception? :P [01:26:59 CEST] <DHE> so it sounds like two different small errors that don't really coincide normally are now colliding hard [01:27:41 CEST] <cehoyos> Which two errors? [01:27:58 CEST] <another> could not reproduce [01:28:05 CEST] <cehoyos> How did you test? [01:29:24 CEST] <another> commandline in pastebin with {ffmpeg,aom}-git [01:30:16 CEST] <cehoyos> I put a call to feenableexcept() in aac_encode_init() and just did ffmpeg -i input -acodec aac -f null - [01:32:07 CEST] <another> debug build? [01:32:25 CEST] <nicolas17> I also found something questionable in the aom build system, build type "Release with debug info" enables CONFIG_DEBUG... I would expect it to be identical to Release except with -g [01:32:48 CEST] <nicolas17> another: it seems CMAKE_BUILD_TYPE=Release on AOM will not trigger this problem [01:33:38 CEST] <another> iC [01:34:10 CEST] <cehoyos> Crashes for INEXACT, OVERFLOW, UNDERFLOW and DIVBYZERO, not for INVALID [01:40:18 CEST] <cehoyos> And I can confirm that it is not possible to restore the exception state;-) [01:40:41 CEST] <nicolas17> hmm [01:40:47 CEST] <nicolas17> I think they're doing it wrong :) [01:42:00 CEST] <nicolas17> I think feenableexcept enables the exceptions you give it (|=), rather than set the mask of exceptions to *exactly* the ones you give it (=), so eg. feenableexcept(0) is always a no-op [01:42:44 CEST] <nicolas17> so passing the old set of exceptions to feenableexcept won't work, you need fedisableexcept [01:43:14 CEST] <cehoyos> Correct, I just came to the same conclusion [01:43:23 CEST] <cehoyos> You cannot restore with feenableexcept() [01:44:14 CEST] <cehoyos> I am nearly sure there will be no change in FFmpeg, but thank you for the report! [01:44:59 CEST] <nicolas17> yeah it seems the bug is in aom's FLOATING_POINT_RESTORE_EXCEPTIONS [01:46:04 CEST] <cehoyos> Yes [02:14:47 CEST] <DHE> avoiding overflow/underflow might be a good idea overall, but the priority would be aom fixing their stuff... [02:15:17 CEST] <cehoyos> Is floating point overflow / underflow undefined behaviour? [02:15:44 CEST] <DHE> no, but the state of the FPU exception of the CPU is an unkonwn unless explicitly set [02:15:50 CEST] <DHE> (which AOM tried to do and screwed up) [02:16:28 CEST] <DHE> maybe linux guarantees a certain default, but it's possible a custom app import ffmpeg changed it [02:17:29 CEST] <nicolas17> fedisableexcept((FE_DIVBYZERO | FE_UNDERFLOW | FE_OVERFLOW) & ~original_mask) does this look sane? [02:17:51 CEST] <DHE> there's a "set exact bits" function, why not use that? [02:19:05 CEST] <nicolas17> what function is that? [02:34:38 CEST] <nicolas17> filed aom bug [02:39:40 CEST] <DHE> there's a function fesetexcept they're all documented in the same man page [03:18:11 CEST] <nicolas17> next mystery [03:18:32 CEST] <nicolas17> I tried encoding 15 seconds of video with AV1 with different values of -cpu-used [03:19:40 CEST] <nicolas17> cpu-used 8: 19m57s; cpu-used 6: 21m30s; cpu-used 3: 22m1s; cpu-used 1: 23m6s and a segfault [03:23:48 CEST] <nicolas17> running under gdb, see you in 24 minutes [16:03:26 CEST] <Gdocal> Hello guys, I want to record video from images. But images generates in my own program (C#). I Don't want to save files to disk and read them back via ffmpeg. Is there any way to send images over tcp (or windows pipe) to ffmpeg and generate video ? [16:08:21 CEST] <pink_mist> incorporate the ffmpeg libraries in your program and do it all inside your program [16:09:38 CEST] <DHE> or output to a more boring format (eg: yuv420p, or RGB24) and pipe it into ffmpeg [16:09:50 CEST] <DHE> err, I guess drop the p on yuv420p [16:11:43 CEST] <lain98> unrelated to ffmpeg but i'm trying to find videos to test with my application that uses ffmpeg. can someone point me to public domain videos or videos without licensing issues that i can add to my git repo ? [16:12:27 CEST] <lain98> like what's lena.jpg for video ? [16:12:47 CEST] <TheAMM> I use the blender open movies for a few things [16:13:00 CEST] <TheAMM> but maybe you can grab a few of the samples ffmpeg's tests have [16:13:18 CEST] <TheAMM> I've never looked at them but they're out there somewhere [16:15:09 CEST] <another> there's also: https://media.xiph.org/video/derf/ [16:16:38 CEST] <lain98> i avoided the ffmpeg tests because they probably include iffy edge case videos [16:19:06 CEST] <Gdocal> but maybe there some way I can setup tcp server and force ffmpeg to read my stream of data, but as I said I have only pictures, is it possible to feed pictures via tcp and get video from it? [16:19:33 CEST] <another> video is basically just pictures [16:19:58 CEST] <BtbN> tcp would be horribly inefficient. Best to use the libraries directly [16:31:00 CEST] <lain98> also concerned that creative commons might not exactly be equivalent to public domain [16:35:41 CEST] <pink_mist> of course it isn't - public domain isn't a thing in some countries [16:35:48 CEST] <pink_mist> while creative commons is [16:36:22 CEST] <pink_mist> and there are different types of creative commons licenses, so it all depends on which one's in use [16:36:48 CEST] <pink_mist> but ... you should probably speak to a lawyer about this kind of thing. [16:57:09 CEST] <furq> CC0 is public domain (in jurisdictions where it exists) [16:57:26 CEST] <furq> it should also theoretically work in jurisdictions where it isn't but i'm not going to find out [17:03:09 CEST] <lain98> i thought of a better idea. i bet can generate a blank video in ffmpeg with just the frame number with drawtext [17:04:13 CEST] <durandal_1707> testsrc, testsrc2, smptebars, pal100bars etc [17:04:35 CEST] <durandal_1707> all creates testing video [17:04:51 CEST] <durandal_1707> these are video source filters [17:05:56 CEST] <lain98> thanks durandal_1707 [17:08:37 CEST] <lain98> this is pretty cool https://www.youtube.com/watch?v=tdTTbfUMn7w [17:49:42 CEST] <HickHoward> uhh [17:49:58 CEST] <HickHoward> does ffmpeg support e-ac-3 with dolby atmos decoding or something? [17:50:11 CEST] <durandal_1707> no atmos [17:50:22 CEST] <HickHoward> yikes [17:50:37 CEST] <HickHoward> what am i supposed to do? [17:52:27 CEST] <cehoyos> lain98: lena is copyrighted [17:53:47 CEST] <cehoyos> HickHoward: E-AC3 does not have an Atmos side-channel, it's just a marketing name for a bit signal in the bitstream [17:56:42 CEST] <HickHoward> so i got bamboozled into believing that E-AC-3 supports Dolby Atmos... [17:58:12 CEST] <HickHoward> oshit [17:58:32 CEST] <cehoyos> TrueHD does [18:03:22 CEST] <HickHoward> say, does ffmpeg support dolby atmos decoding *as a separate file* or... [18:03:25 CEST] <HickHoward> something? [18:05:20 CEST] <cehoyos> no atmos [18:05:44 CEST] <friki> Hi, I'm looking for articles, benckmarks, documentation, etc about ffmpeg running on SBC (raspberrypi and such). The purpose is encoding HD video (from an USB video source) or from a network fs (samba, nfs). [00:00:00 CEST] --- Mon Aug 12 2019

1 0

ffmpeg-devel.log.20190810
by burek 11 Aug '19

11 Aug '19

[00:03:11 CEST] <cone-156> ffmpeg 03Andriy Gelman 07master:90e965be6d90: tools/zmqsend: Avoid mem copy past the end of input buffer [00:03:11 CEST] <cone-156> ffmpeg 03Olivier Maignial 07master:c29d81e73641: avformat/rtpdec_mpeg4: Fix integer parameters size check in SDP fmtp line [12:03:56 CEST] <roxlu> hey, someone around who knows a bit about vaapi and the intel-media-driver? The va.h describes that one can get the preferred pixel format for a surface by providing a `VASurfaceAttrib` with it's value set to 0. Though this doesn't return the preferred pixel format; it only tells me I should pass a larger attrib buffer. Then, the second call does give me a pixel format. [16:01:12 CEST] <durandal_1707> Lynne: do you know why mlpenc does strange pointer mappings and castings? [16:03:39 CEST] <Lynne> like DecodingParams *seq_dp = (DecodingParams *) ctx->decoding_params+ ... [16:03:51 CEST] <durandal_1707> yea [16:05:01 CEST] <durandal_1707> cehoyos: i will revert your commit then from stereo3d filter [16:05:04 CEST] <Lynne> probably leftovers, that code is old [16:05:50 CEST] <durandal_1707> fix it properly [16:56:52 CEST] <cehoyos> durandal_1707: Don't forget to also remove support for DUBOIS and SIDE_BY_SIDE [16:57:22 CEST] <durandal_1707> why? [16:59:18 CEST] <cehoyos> Or ask the authors [17:00:07 CEST] <cehoyos> Some of them were not written by Reimar, Gordon Schmidt or Endre [17:00:24 CEST] <cehoyos> (not all dubois, not all side_by_side) [17:00:50 CEST] <durandal_1707> lies [17:09:31 CEST] <cehoyos> Lies? [17:09:40 CEST] <cehoyos> Not sure I understand. [17:37:01 CEST] <ramiro> durandal_1707: 10+ years old code, and not finished during the original gsoc. i remember thinking those casts would end up being a good thing, but now I can't even understand what they do anymore. [17:37:37 CEST] <durandal_1707> lol [17:53:39 CEST] <J_Darnley> Maybe they are casts c++ would require? [17:57:04 CEST] <durandal_1707> see math after cast... [18:40:21 CEST] <vel0city> michaelni: Regarding the huffman codes change, did you have a specific workaround for just the sym==0 case in mind? [18:41:51 CEST] <michaelni> well, i was thinking of just setting that one to 0 and just checking that one, if that works [18:42:12 CEST] <vel0city> ah gotcha [19:02:32 CEST] <vel0city> michaelni: I'm building under WSL so I can't use ffplay. I tried decoding the image you mentioned (to a .png) and it worked fine. Is there another way for me to try and repro? [19:03:56 CEST] <Lynne> vel0city: btw there is a gamma metadata (that png exports) to let anyone rendering know the gamma [19:04:13 CEST] <Lynne> do you think it could be used instead of doing that in the decoder? [19:04:41 CEST] <Lynne> mpv will read the gamma and use it, afaik [19:04:53 CEST] <vel0city> Lynne: but that's png-specific [19:06:25 CEST] <vel0city> you mean that there's some generic "color space" property that I can set from the decoder? [19:06:27 CEST] <durandal_1707> check that white level is not same as black level [19:06:50 CEST] <vel0city> durandal_1707: hm true [19:07:13 CEST] <durandal_1707> this gamma is custom always thing [19:07:42 CEST] <durandal_1707> there is no way to export it [19:08:43 CEST] <Lynne> vel0city: no, its not specific, its just a metadata string [19:09:53 CEST] <durandal_1707> there is other stuff done after gamma, making stuff imposible to be done [19:18:04 CEST] <Rathann> hi [19:18:23 CEST] <Rathann> I've just noticed that libavresample was deprecated back in 4.0 release [19:18:31 CEST] <Rathann> when is it going to be removed? [19:18:49 CEST] <Rathann> in 5.0? [19:18:59 CEST] <nevcairiel> typically at leas 2 years after the deprecation [19:19:38 CEST] <Rathann> ok, thanks [19:20:04 CEST] <nevcairiel> so possibly next year. We recommend migrating to swresample instead, the API is even quite similar [19:22:04 CEST] <Rathann> yes, I saw the work some downstream consumer did to switch [19:23:07 CEST] <Rathann> I co-maintain ffmpeg package in RPM Fusion and I've just gone over the remaining consumers and filed bugs against them [19:23:19 CEST] <Rathann> and came here to ask about the timeline they have ;) [19:28:10 CEST] <J_Darnley> Even if we remove it in master, won't it stick around in 4.0 and any other release it is in? [19:29:24 CEST] <Rathann> it's still there in 4.2, sure [19:32:27 CEST] <Rathann> but we (RPM Fusion/Fedora) usually try to keep just one latest version of any library in a given distribution release, so when FFmpeg stops providing libavresample in (I guess) 5.0, the dependent packages which still require it will break [19:32:45 CEST] <Rathann> so it's better start poking the maintainers in advance [19:34:27 CEST] <Rathann> about half of the packages depending on libavresample that we have in RPM Fusion for Fedora 29 are already ported to libswresample already [21:41:31 CEST] <durandal_1707> why am i not allowed to part of security team? [21:42:11 CEST] <kierank> durandal_1707: because you do not comply with secret procedure [21:44:36 CEST] <durandal_1707> what is needed to be part of security team? competency in what? [21:44:54 CEST] <kierank> Who knows [21:45:04 CEST] <kierank> Competence in muddying water I think [21:45:08 CEST] <kierank> And blocking change [21:46:35 CEST] <durandal_1707> blocking change is more to do with certain dev certainly not in security team [21:49:52 CEST] <durandal_1707> irc logs are still broken, i wonder why [22:04:24 CEST] <Lynne> thinking about it, even if dolby weren't dobly, I still don't think opus stood any chance of being considered for object based audio [22:05:14 CEST] <Lynne> because otherwise it would have had a decent system for signalling layout rather than the vorbis-like family mapping it got [22:05:53 CEST] <durandal_1707> patents matters also standards [22:06:38 CEST] <Lynne> patents matter most for that, usability is second, but at least someone working on ac4 thought of how channels should be signalled [22:07:05 CEST] <Lynne> and the spec says how, opus doesn't even say a word on mapping in the rfc [22:07:35 CEST] <durandal_1707> why you inspect ac4? [23:28:37 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:57987deefcdc: lavc/libx264: bit_rates > INT_MAX are not supported. [23:34:20 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:4b1687f23c13: lavc/libx264: Cast bit_rate to int64_t to avoid an integer overflow. [23:34:21 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:67114195694d: lavf/dump: Fix vbv_delay type specifier. [23:50:46 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:098ed8a73e68: lavf/dump: Fix cpb bitrate type after next major bump. [23:55:26 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:690cab32326e: lavc/libx264: Cast cpb bit_rates to int64_t to avoid an integer overflow. [23:59:42 CEST] <jgb> who do i have to beg if i want to get this fixed: https://trac.ffmpeg.org/ticket/7912 [00:00:01 CEST] --- Sun Aug 11 2019

1 0

ffmpeg.log.20190810
by burek 11 Aug '19

11 Aug '19

[04:57:31 CEST] <Henry151> hi folks, i used https://termbin.com/oopi this to convert some MKV files to mp4 and burn in the subtitle tracks; now, I went to watch one of them, and at the 12:48 minute mark it stops playback. I'm trying to play it back using the web player built-in to my ampache server. The stream link is here: https://romp.network/ampache/share.php?id=23&secret=7z2WpGmZ [04:57:48 CEST] <Henry151> Any suggestions on what I might have done wrong? [04:58:31 CEST] <Henry151> i can just download the mkv and watch the video but I'm trying to get these mkv's converted to mp4 with english subs burned in so that my family members can stream them from my ampache server. [04:59:07 CEST] <Henry151> my next step is i'm going to download the mp4 and see if it does the same thing in VLC. [05:18:20 CEST] <Henry151> ah that link won't work anymore because i accidentally overwrote the file [05:18:22 CEST] <Henry151> nevermind [05:18:36 CEST] <Henry151> but still any ideas about what i might have done wrong would be greatly appreciated [05:47:02 CEST] <Henry151> i adjusted the command by removing the "-tune animation" and I'm trying it again. It was deathly slow and it's still deathly slow, it's running at like 0.25x normal speed it's going to take freakin forever. And I also adjusted my tmux to have a longer scrollback because I couldn't even scroll back far enough to figure out what the heck went wrong before. [05:48:04 CEST] <Henry151> someone please help me get all the settings just right to achieve my desired results :) this is my current command: https://termbin.com/daft [05:49:25 CEST] <Henry151> i want it to be decent quality and "look nice" for streaming on a TV-size screen (my tv is 42") from my ampache server, in mp4 format, with the english subs burnt in.. and I want it to not friggin quadruple the file size like it did the first time, and not randomly cut out at 12 minutes, any help appreciated [05:56:31 CEST] <Henry151> what i really would like actually is to set up my ampache server to automatically transcode my MKV files into a streamable format, in such a manner that I can choose a subtitle track and have it all just work [05:56:35 CEST] <Henry151> halp meh plz [16:10:24 CEST] <ZeroWalker> anyone know how blurays work (the files essentially). I basically want to convert them single files, i usually do that with my dvds (merging the vob files). And i do this losslessly, that part is important. I simply do this out of convenience, but i am not that familiar with blurays, my guess is i can just take the m2ts files which seems to be normal out of the box. Thanks:) [16:11:05 CEST] <furq> ZeroWalker: you want the mpls files [16:11:13 CEST] <furq> mkvtoolnix will deal with them if they're decrypted [16:11:43 CEST] <furq> fwiw you should also be demuxing the pgcs from dvd ifos instead of just concating the vobs [16:12:05 CEST] <furq> but if they're movies then those will often give the same result [16:13:36 CEST] <durandal_1707> that is illegal to do [16:14:20 CEST] <ZeroWalker> oh the mlps, see them now, guessing they are chapters or something? And also i do use pgcs, problem with it is that sometimes it doesn't make 1 file for some reason, and i had to do a concate [16:14:25 CEST] <ZeroWalker> oh they are encrypted? [16:16:04 CEST] <furq> if you can play back the m2ts files then it's not encrypted [16:16:06 CEST] <ZeroWalker> i have just ripped mine and haven't noticed any such things, annoying if it's encrypted, as the decrypting part then is not something i want help with out of legal concerns of course. [16:16:16 CEST] <ZeroWalker> ah will try [16:16:41 CEST] <furq> obviously if it is encrypted then that's out of the scope of this channel [16:16:47 CEST] <furq> but it's not hard to find [16:17:35 CEST] <ZeroWalker> well i can "play" them in mpc-hc in a sense, it shows up, but doesn't seem to play correctly, it just kinda stays still, but seeking does at least make it change. [16:17:47 CEST] <ZeroWalker> guessing that's okay, as i would assume encrypted would break it completely? [16:18:00 CEST] <furq> yeah it's probably just failing to seek because it's mpegts [16:18:02 CEST] <ZeroWalker> yeah of course [16:18:28 CEST] <furq> if you're on windows then just open the mpls playlists in the mkvtoolnix gui [16:18:29 CEST] <ZeroWalker> ah, same reason why flv fails etc? [16:18:42 CEST] <ZeroWalker> will do [16:30:27 CEST] <livingbeef> How do I automatically extract subtitles? I can't do -map s:0 subs.ass because some text subs can't be converted into ass and I can't do -map s:0 subs because then ffmpeg doesn't know the format. And c:s copy will probably ignore -ss, won't it? [16:32:26 CEST] <livingbeef> well, -c:s copy doesn't work at all, so that's moot anywyas [16:33:36 CEST] <livingbeef> btw I do not care about proper filenames, it's just a temp file [16:34:27 CEST] <pink_mist> what text subs can't be converted into ass? [16:34:43 CEST] <pink_mist> picture subs can't without OCR, but text subs? [16:35:26 CEST] <livingbeef> Subtitle encoding currently only possible from text to text or bitmap to bitmap [16:35:33 CEST] <livingbeef> that's the error message ^ [16:35:52 CEST] <livingbeef> it was Stream #0:2 -> #0:0 (hdmv_pgs_subtitle (pgssub) -> ass (ssa)) [16:37:12 CEST] <pink_mist> ... so it's not text subs at all [16:37:21 CEST] <pink_mist> you need to OCR those [16:37:32 CEST] <pink_mist> which afaik is outside the scope of ffmpeg [16:37:43 CEST] <livingbeef> ah, the error message was misleading then [16:37:58 CEST] <livingbeef> what does OCR mean [16:38:01 CEST] <pink_mist> no it wasn't; it says it can only go from text to text, or from bitmap to bitmap [16:38:10 CEST] <pink_mist> OCR is "Optical Character Recognition" [16:38:32 CEST] <pink_mist> you were trying to go from bitmap to text [16:38:42 CEST] <pink_mist> which is what OCR is needed for [16:39:02 CEST] <livingbeef> well I just want a file that can be used in subtitles video filter [16:39:47 CEST] <livingbeef> the conversion isn't necessary, but then I have the issue that I do not know the format, because it can be different each time [16:49:35 CEST] <zeromind> well, the subtitles filter apparently only does text, you'll either need to use the overlay for the picture-based subs, or ocr them first, see https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo [16:50:09 CEST] <livingbeef> Ah. That sucks then [16:51:10 CEST] <livingbeef> well, thanks for the info [16:55:02 CEST] <ZeroWalker> furq, there's a lot to choose from after scanning the playlist, many seems to be duplicates, can't really tell which is the actual movie [17:12:31 CEST] <safinaskar> hi [17:16:13 CEST] <zeromind> livingbeef: you could try mpv for burning in the subtitles, it does not seem to care whether they are text or picture-based subs [23:59:32 CEST] <jgb> who do i have to beg if i want to get this fixed: https://trac.ffmpeg.org/ticket/7912 [00:00:01 CEST] --- Sun Aug 11 2019

1 0

ffmpeg-devel.log.20190809
by burek 10 Aug '19

10 Aug '19

[00:08:00 CEST] <jkqxz> tmm1: Different window size? [00:09:30 CEST] <tmm1> yea that seems like the only change [00:09:48 CEST] <tmm1> i'll try forcing the old value to see if that helps [00:13:32 CEST] <jkqxz> The old code would overflow the window size value, which is why it's come out so different. 6000k * 1000 > 2^32. [00:19:56 CEST] <tmm1> ahh ok, i was wondering why the math didn't make any sense [00:22:39 CEST] <tmm1> jkqxz: so you think its the driver that's broken and the random overflowed calculation before just happened to work? [00:23:57 CEST] <tmm1> the other difference i see is that .ICQ_quality_factor is passed now when it wasn't before [00:25:46 CEST] <tmm1> actually i bet that's it.. its getting clipped to 1 which would explain the low quality [00:40:14 CEST] <tmm1> no luck removing that or setting window size to what it was being calculated as before [00:40:30 CEST] <tmm1> afaict the rc params being passed in are identical but the behavior is still different [01:35:02 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07master:86d13e95e760: doc/fate: Document how to request samples upload access [03:22:11 CEST] <Chagall> are all pre-release commit hashes in APIchanges just xxxxxxxxxx? [03:30:02 CEST] <Chagall> hope I did it right [03:31:45 CEST] <jamrial> Chagall: the xs are just a placeholder since the hashes aren't known until committed, of course [03:32:03 CEST] <jamrial> they are usually replaced at the time of a release [03:32:11 CEST] <Chagall> I thought so :) [07:00:59 CEST] <Compnno> jkqxz, asukhanov_, hehe the only program i know that uses libavformat's debug motion vectors is fast5, a video forensics tool [10:21:39 CEST] <cone-353> ffmpeg 03Carl Eugen Hoyos 07release/4.1:02537719538b: lavc/tableprint_vlc: Remove avpriv_request_sample() from included files. [10:42:30 CEST] <philipl> BtbN: I'll take a look at the nvdec reconfigure stuff next week to see if can be used for this multi-resolution stuff. [10:56:02 CEST] <nevcairiel> there needs to be proper internal API support for this first [10:56:10 CEST] <nevcairiel> the patches on the ML all try to do it cheap and hackish [11:27:31 CEST] <BtbN> What patches now? I'm not seeing anything nvdec on the ML [11:27:48 CEST] <nevcairiel> not for nvdec, the general resolution change thing [11:28:14 CEST] <nevcairiel> because right now you get no chance to handle it on hwaccel level because the framework will always just re-create stuff [11:30:40 CEST] <BtbN> I mean, that works [11:30:55 CEST] <BtbN> And re-creating nvdec should be relatively cheap [11:31:08 CEST] <BtbN> The expensive stuff needs to be re-created anyway if the res changes [11:31:20 CEST] <nevcairiel> the point of this vp9 nonsense is that its supposed to carry reference frames over the res change boundary [11:31:26 CEST] <nevcairiel> someone was drunk when designing that shit [11:31:52 CEST] <BtbN> What patch even is this? I'm not seeing anything about that in the last weeks of ML backlog [11:35:40 CEST] <kurosu> Lynne / asukhanov_ / lotharkript: went over quickly the latest specs - I'm not happy about what I've commented (and I hope it brushes nobody the wrong way), but I don't see myself having another 30 minutes for it in the foreseeable future [11:36:37 CEST] <kurosu> also, maybe I'm overly "litigious"/process-obsessed, but this discussion really needs time to crystallize [11:37:19 CEST] <kurosu> this isn't an internal ffmpeg thingie, but something several users may have use of, so a wider audience is needed [11:37:52 CEST] <kurosu> eg please post that to the ffmpeg-devel thread [11:38:29 CEST] <kurosu> (I would recommend any other medium, like the actual ffmpeg user mailing list, but that's already overboard) [11:44:42 CEST] <durandal_1707> Lynne: i fixed 16 mlp for me, except last frame encoding [13:30:36 CEST] <mkver> If a function does not take ownership of a packet, it means that the packet must be untouched when the function returned as if the packet was const? It does not only apply to the packet's data, right? [13:31:47 CEST] <Lynne> it can't change a packet if the packet has been ref'd elsewhere [13:34:48 CEST] <mkver> And if the packet is not refcounted? [13:37:47 CEST] <Lynne> then modifying it is okay beause everything else made a copy of it [13:40:19 CEST] <mkver> So even if a function does not take ownership of a packet, one needs to have a spare copy of the packet (in case it's not refcounted) in order not to loose the pointer to the data because the packet may be modified? [13:40:40 CEST] <mkver> That's a strange definition of "not taking ownership". [13:41:00 CEST] <nevcairiel> i think you are confusing yourself and everyone else by talking in weird abstracts [13:41:28 CEST] <mkver> Ok, I have issues with av_write_frame. [13:43:00 CEST] <nevcairiel> "taking ownership" is usually only related to who is responsible for freeing the packet ultimately [13:43:55 CEST] <mkver> It's documentation says that this function does not take ownership of the packet fed to it. And contrary to av_interleaved_write_frame it does not directly unref the packet fed to it. But it nevertheless modifies the packet: It modifies the timestamps; it modifies the packet's data (if there is an automatically added bsf). [13:47:36 CEST] <mkver> If there is an automatically added bsf and the packet was refcounted and writable, the only reference to the original data will be lost. [13:48:13 CEST] <nevcairiel> if its refcounted and no other references exist, noone else seemed to care about the data [13:50:30 CEST] <nevcairiel> how else would you indicate to it that an in-place modification is ok? Any change to that would result in forceful data copies [13:55:59 CEST] <mkver> The caller might care about the data. He might want to reuse the data for other purposes, thinking that he will get his data back. After all, he thinks he still owns it. [13:57:42 CEST] <mkver> The problem with the caller receiving his data back can be solved by creating a new reference to the data like in https://github.com/mkver/FFmpeg/commit/4f7c39e344cf2aa0293354535ea09fdd9dbc… [14:01:25 CEST] <nevcairiel> and that'll make in-place bsfs impossible [14:01:46 CEST] <nevcairiel> free free to document the actual behavior, but changing it will be a hard sell [14:04:18 CEST] <mkver> Yes, I know. But I thought that this is exactly what not transferring ownership means. [14:04:46 CEST] <nevcairiel> ownership in reality only means that you still have to free it after [14:05:54 CEST] <mkver> For you, it is just about the responsibility to free data; and I thought it encompassed even the possibility of getting it back (in unmodified form). [14:08:08 CEST] <mkver> The good news is that the rest of the patchset does not depend on it; so I'll just send it with the expectation that this patch will not get applied. [15:18:02 CEST] <Lynne> durandal_1707: your patch is the same as one of jai's patches from last month [15:18:58 CEST] <durandal_1707> Lynne: yes, but his broke other stuff before it [15:19:15 CEST] <durandal_1707> try it than we can talk [15:42:20 CEST] <philipl> BtbN: https://trac.ffmpeg.org/ticket/8068 with links to patches. [15:43:17 CEST] <philipl> vp9 allows for resolution changes on non-key frames. As nevcairiel says - crazy shit. [15:45:30 CEST] <Lynne> durandal_1707: nope, doesn't fix issues [15:45:40 CEST] <Lynne> it works about the same as jai's patch [15:59:38 CEST] <durandal_1707> its certainly better than before [16:00:59 CEST] <durandal_1707> and im doing 16bit [16:05:03 CEST] <kurosu> vel0city: I wager your mails not having "Nick" as author/in the From: field are sent through git send-email ? [16:05:28 CEST] <kurosu> maybe msmtp or some email sender ("MUA"?) is misconfigured [16:05:56 CEST] <kurosu> Looking at 01/14, I see " Lossless JPEGs encoded in DNGs are commonly bayer-encoded" [16:06:55 CEST] <kurosu> then I interpret the following as always interpreting such cases as bayer? even if you say "commonly" ? [16:07:22 CEST] <kurosu> isn't there anything else that can make you infer this is absolutely the case ? [16:07:52 CEST] <kurosu> note: I may have to read all of the patchset, which I very likely won't [16:08:58 CEST] <Lynne> durandal_1707: the frame queue is used, it sets packet pts [16:13:21 CEST] <durandal_1707> Lynne: what a waste of resouces for that casd [16:14:03 CEST] <Lynne> well, no, that's all the afq does, it keeps track of input samples -> output samples to set pts [16:38:27 CEST] <durandal_1707> Lynne: well my patch is correct and previous state and leaks is not [16:45:38 CEST] <Lynne> yes, go ahead and apply it [16:55:56 CEST] <vel0city> kurosu: That code should not be there... I must have messed up rebasing or something. I will look into it. [17:04:23 CEST] <vel0city> not sure about the author matter, sendemail.from is my email. should it be something else? [17:11:42 CEST] <vel0city> yeah it should be my actual name - I see. fixed [17:22:40 CEST] <vel0city> kusosu: I remember now, it wasn't a git mess-up, I just decided to improve that code in an ensuing commit instead of rebasing it on the first one. If you look at 09/14 the assumption you mentioned is eliminated [17:23:24 CEST] <vel0city> I can change it if it's important [17:24:45 CEST] <vel0city> there are no known tests/files that break afaik, that's why I didn't do it in the first place [17:32:47 CEST] <vel0city> hm no, the one I pushed still looks messed up. will push a fix in a bit [17:43:34 CEST] <vel0city> here: https://github.com/VelocityRa/FFmpeg/commit/6a461ef5c90fcc71f5b30f3aaf21536… not pushing to ML yet, I will do so when I fix an unrelated regression [18:32:34 CEST] <vel0city> v12 sent. tell me if there's a better way to update revisions other than pushing all 14 commits every time. iirc I've asked and there isn't [18:36:15 CEST] <J_Darnley> Make commits with --fixup? [18:36:52 CEST] <J_Darnley> Then before pushing to origin do `git rebase origin/master -i --autosquash [18:37:20 CEST] <J_Darnley> But I guess we don't want to se those on the ML anyway [19:15:50 CEST] <vel0city> J_Darnley: I know how to do it with git, my question was about the ML. Say, if I update one of the commits, ie. "v11 02/14". Can I only send "v12 02/14" or do I have to send everything like I'm doing now? as far as I've been told, I have to re-send everything. [20:14:04 CEST] <J_Darnley> vel0city: ah I see [20:23:55 CEST] <roxlu> hi, someone around who has experience with the Intel Media Sdk on Linux? I'm looking into the library and wondering why they have these #ifdefs here https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/dec… [20:25:45 CEST] <BtbN> Because stuff is unsupported on Linux [20:28:13 CEST] <roxlu> BtbN: thanks, yeah I thought that, but that ifdef that I linked would mean software based decoding is not supported; but strangely I'm asking for a hardware decoder [20:28:48 CEST] <BtbN> Why are you even bothering with QSV on Linux? [20:29:12 CEST] <roxlu> BtbN: what would you recommend otherwise? [20:29:18 CEST] <BtbN> vaapi [20:29:32 CEST] <BtbN> Which Linux-QSV is just a wrapper around anyway [20:30:36 CEST] <roxlu> yeah that's what I thought, but using QSV would means that I can use the same api on Win/Linux [20:31:53 CEST] <BtbN> QSV on Linux is just a mess [20:32:05 CEST] <roxlu> what I don't understand yet, is why https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/dec… return MFX_PLATFORM_SOFTWARE [20:32:16 CEST] <roxlu> yeah ... it seems like it :) [20:34:40 CEST] <roxlu> BtbN: do you like the VA-API more? (is the api actually cleaner?) [20:35:14 CEST] <BtbN> No, it's horrible. But it's one pointless wrapper less [20:35:22 CEST] <BtbN> And it's actually well maintained and tested [20:35:28 CEST] <roxlu> hehe yeah [20:36:42 CEST] <roxlu> do you know about an h264 decode example? [20:42:47 CEST] <BtbN> ffmpeg -hwaccel vaapi -i somefile.mp4 ... [20:43:28 CEST] <roxlu> ok thanks [20:50:55 CEST] <roxlu> :C http://01org.github.io/libva_master_doxygen/ [20:56:15 CEST] <durandal_1707> its very calm, everybody hacking something [20:57:42 CEST] Action: roxlu trying to start with vaapi [21:00:13 CEST] <roxlu> if anyone knows a guide / readme that shows the steps involved that we be awesome :) [21:37:43 CEST] <kierank> durandal_1707: it because you are not talking [21:37:45 CEST] <kierank> everyone is cal [21:37:46 CEST] <kierank> m [22:07:44 CEST] <durandal_1707> calm [22:43:10 CEST] <roxlu> ok, so the VAAPI talks about profiles and entrypoints. which vainfo also shows: https://gist.github.com/roxlu/563fed3a152e843dc52169429dbe6891 [22:43:59 CEST] <roxlu> my understanding is that the profile + entry-point (VLD, IDCT) as basically the capabilities [22:44:16 CEST] <roxlu> but... for decoding should I use the VLD entry point? [22:44:46 CEST] Action: roxlu is aware that these aren't 100% ffmpeg specific questions [00:00:00 CEST] --- Sat Aug 10 2019

1 0