Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2019

1 participants
62 discussions

ffmpeg-devel.log.20191010
by burek 11 Oct '19

11 Oct '19

[00:04:16 CEST] <durandal_1707> michaelni: i have mjpeg sample that shows our mjpeg parser is buggy [00:15:40 CEST] <tmm1> definitely something strange going on with these trailing zeros in the slice [00:15:53 CEST] <mkver> And what is going on? [00:16:42 CEST] <mkver> These cabac zero words should initially be 0x00 00 03 (the last one is an emulation_prevention_three_byte). [00:18:56 CEST] <tmm1> it seems like in the original sample the first slice has 5 zero bytes at the end [00:19:00 CEST] <tmm1> is `-f h264` in annexb format? [00:19:03 CEST] <michaelni> durandal_1707, please provide a link or something. ill take a look (might be a few days as iam ATM a bit behind what i wanted to do) [00:19:14 CEST] <mkver> Yes. [00:20:02 CEST] <mkver> Can you upload your sample somewhere and explain what you did, what you expected and what you got? [00:20:10 CEST] <tmm1> it seems like it shouldn't be possible to see five 0x00 in a row without a start code emulation [00:20:20 CEST] <tmm1> yes see https://gist.github.com/tmm1/5737a57ea6b398d3e8d3cad4f12ebb49 [00:20:39 CEST] <mkver> It can be. It is allowed to add zeroes (arbirarily many) between annexb NAL units. [00:21:04 CEST] <mkver> Our code drops them. [00:21:51 CEST] <tmm1> i see, ok. if i alter ffmpeg to keep the trailing zeros in slices, when it regenerates the bitstream from cbc it escapes those trailing zeros with 0x03 bytes [00:22:54 CEST] <mkver> Yes, because it currently doesn't distinguish between zeros created by unescaping and zeros that were between NAL units. [00:23:45 CEST] <mkver> Also notice that the current code in assemble_fragment would not add a 0x03 escape at the very end of the NAL unit even if it should. [00:24:23 CEST] <mkver> That's currently no problem, because there is no need to do so (after all the trailing zeroes have been dropped) [00:28:21 CEST] <mkver> According to the standard, only parameter sets and the first NAL of an access unit need a four byte startcode; the others can have three byte startcodes. [00:29:08 CEST] <mkver> assemble_fragment tries to use three-byte startcodes whenever possible. that explains the difference at byte 149/150. [00:30:48 CEST] <mkver> Also notice that the h2645_parse functions are a bit buggy: If a NAL unit has a four byte startcode, they will add a zero byte at the end of the preceding NAL unit and treat the unit as if it had a three-byte startcode. [00:37:14 CEST] <tmm1> hmm interesting [00:37:44 CEST] <mkver> And what is actually your problem? [00:39:17 CEST] <tmm1> the problem is an android hardware decoder that's choking on the bitstream when i use h264_metadata_bsf [00:40:37 CEST] <tmm1> i think i managed to patch cbs so the input and output across h264_bitstream are bitexact, so now i should be able to verify if cbs is the issue or not [00:45:05 CEST] <mkver> Your sample uses four byte startcodes for the slices. Maybe it's that? Use a hex editor and prepend a zero to all occurences of 0x00 00 01 41 and 0x00 00 01 01. [00:47:49 CEST] <mkver> Alternatively, you could test whether the chomp bitstream filter also makes the output unplayable with your device. It would only remove the trailing zeroes after the slice, but leave the other startcodes alone. [00:55:22 CEST] <tmm1> ok it looks like the start code change doesn't matter [00:55:38 CEST] <tmm1> by keeping the trailing slice bytes it plays correctly on the device [00:55:39 CEST] <tmm1> https://gist.github.com/tmm1/5737a57ea6b398d3e8d3cad4f12ebb49#file-h264bsf-… [00:55:47 CEST] <tmm1> i will try chomp to verify as well, good idea [00:59:13 CEST] <mkver> Your patch will not make output bitexact if a slice ends in a cabac_zero_word. [01:00:51 CEST] <tmm1> chomp breaks playback in the same spot [01:00:55 CEST] <mkver> And if a slice is followed by another unit that uses a four byte start code, then a zero will be appended to that slice. [01:01:07 CEST] <tmm1> so that confirms the decoder wants the trailing zeros in the slices for some reason [01:05:43 CEST] <tmm1> now that i know what's going on.. is it worth pursing my patch to have ffmpeg keep trailing zeros for slices (i.e. would something like that get merged), or should i just find a simpler workaround/hack for this device [01:06:38 CEST] <mkver> Fixing h2645_parse to no longer move the first byte of a four-byte startcode to the end of the preceding NAL unit would get merged. [01:10:38 CEST] <mkver> But I don't know whether the other stuff would. I don't think that the non-cabac-zero-word zero bytes between slices should be kept; or if they can be kept at all. [01:11:49 CEST] <tmm1> yea it does seems silly to keep zero bytes stuffed in between NALs [01:12:33 CEST] <mkver> There is another complication here: If you modify the slice header and make it shorter, your code would add a zero at the end to make up for that; if you make it longer, your code would add less zeros than it would otherwise do. [01:13:32 CEST] <mkver> Also these zero bytes in between NALs are an annexb thing; they are actually illegal in mp4 (but decoders don't seem to care). [01:14:13 CEST] <tmm1> yea the patch would need a lot of work before being proposed, and still likely to get rejected since it doesn't make any sense outside this one broken device [01:14:33 CEST] <tmm1> i just did the bare minimum to make input/output identical so i could narrow down the hardware bug [01:14:43 CEST] <tmm1> the most straightforward patch that would fix my usecase is probably to update h264_metadata so it doesn't rewrite the bitstream when only PASS/EXTRACT options are used [01:15:43 CEST] <tmm1> or i could add another option to stuff some number of zeros between NALs and that would probably be an effective workaround too [01:18:32 CEST] <mkver> h2645_cbs always drops those zero bytes, even if you don't change a NAL unit and if you don't rebuild the NAL units from their decomposed form. [01:18:49 CEST] <mkver> I.e. it also happens in filter_units. [01:23:11 CEST] <tmm1> from lavc perspective it seems pretty reasonable that it removes these zeros [03:12:36 CEST] <cone-664> ffmpeg 03Jun Zhao 07master:88a9998fe8c7: lavfi/colorspace: typedef ThreadData as all other filters [03:12:36 CEST] <cone-664> ffmpeg 03Jun Zhao 07master:a0e03589d47f: lavfi/lenscorrection: remove unnecessary cast for void * [03:12:36 CEST] <cone-664> ffmpeg 03Jun Zhao 07master:cc52815b8204: lavfi/remap: remove unnecessary cast for void * [03:12:36 CEST] <cone-664> ffmpeg 03Jun Zhao 07master:7ab4fbdebcf1: lavfi/v360: remove unnecessary cast for void * [03:33:44 CEST] <cone-664> ffmpeg 03Jun Zhao 07master:da0c0c7247fb: lavfi/hqdn3d: add slice thread optimization [03:59:37 CEST] <cone-664> ffmpeg 03Steven Liu 07master:6f84c1e9078b: avformat/jvdec: fix memleak when read_header failed [03:59:38 CEST] <cone-664> ffmpeg 03Steven Liu 07master:9f0b9ae8bd84: avformat/iff: fix memleak when get st->codecpar->extradata failed in iff_read_header [04:27:26 CEST] <cone-664> ffmpeg 03Steven Liu 07master:aea82dfe225e: avfilter/vf_delogo: add auto set the area inside of the frame [04:27:27 CEST] <cone-664> ffmpeg 03Steven Liu 07master:a76a516e761a: avfilter/vf_delogo: make the interp value compute method simple [13:08:14 CEST] <durandal_1707> michaelni: did you got sample? [13:09:05 CEST] <michaelni> yes i downloaded the mjpeg file, did not yet had time to look at it [14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:4a3303d52096: avcodec/fitsdec: Fail on 0 naxisn [14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:080819b3b4b5: avcodec/exr: Allow duplicate use of channel indexes [14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:b3c25263d1ee: avcodec/scpr: Check minimum size of type 17 [14:36:12 CEST] <cone-984> ffmpeg 03Limin Wang 07master:6d18b62db96b: avcodec/magicyuv: remove duplicate code [14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:5de19160a3c0: avcodec/pcm: Check bits_per_coded_sample [14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:a5d29812ec36: avcodec/wmaprodec: Fix cleanup on error [14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:f6df99dba1ae: avcodec/dstdec: Check for input exhaustion [14:55:24 CEST] <BtbN> This ff_filter_process_command patchset really shows the downsides of using mailing lists. Over 100 new mails. [17:29:33 CEST] <durandal_1707> michaelni: why noise shaping is done only when resampling? [17:40:14 CEST] <michaelni> durandal_1707, is it? that sounds like it should not be limited that way [17:43:31 CEST] <cehoyos> Registration opens soon. [17:44:37 CEST] <BBB> soon [17:46:20 CEST] <durandal_1707> what? [17:53:57 CEST] <thilo> soon [17:56:59 CEST] <durandal_1707> michaelni: flags/swr_flags is 0 by default [17:58:16 CEST] <durandal_1707> thilo: registration for what? [17:58:42 CEST] <thilo> durandal_1707: VDD [18:13:39 CEST] <BradleyS> noise shaping by default is evil imho [19:18:40 CEST] <Lynne> haasn: if you're getting GPU freezes with intel: its a known driver bug, there's an issue open [19:19:52 CEST] <Lynne> its the same bug I've been getting, and its because their SIMD implementation seems to overread into DMABUF imported textures (which I think are somehow slightly different than native textures the driver allocates normally) [19:24:11 CEST] <BBB> should've written the driver in python and we would all have been save [19:26:40 CEST] <kierank> should've written it in rust [19:34:33 CEST] <durandal_1707> dav1d should be written in rust [19:35:19 CEST] <Chagall> as should ffmpeg [19:36:34 CEST] <durandal_1707> in your dreams [19:44:03 CEST] <JEEB> in theory writing a module in rust and pulling it around with the C FFI shouldn't be too hard [19:44:16 CEST] <JEEB> I've been playing in my mind if I should make a PoC of that at some point [20:12:53 CEST] <Lynne> rav1e has shown it was anything but easy and out of the box [20:13:26 CEST] <Chagall> yeah, I researched it a little for another project and it is a pain [20:14:38 CEST] <Chagall> you need a c-specific API and a header to go with it, which results in duplicated code and more difficult testing and maintenance [20:14:49 CEST] <Lynne> in general its not even hip to NIH anything in rust but suffering using inflexible crates is very much a thing [20:15:12 CEST] <JEEB> isn't the header generate'able with bindgen or so? or is bindgen just the other way? [20:15:33 CEST] <Lynne> I kinda dislike the string-based C api rav1e used, feels like a workaround sort of [20:15:55 CEST] <Chagall> JEEB: maybe, haven't tried using cbindgen [20:16:36 CEST] <Chagall> Lynne: I agree but I'm not sure exactly what are the reasons behind that design [20:16:46 CEST] <Chagall> I did think it was weird when I first really looked at it [20:17:08 CEST] <JEEB> but yea, bindgen at least lets you go the other way (relatively) nicely [20:17:09 CEST] <JEEB> https://github.com/jeeb/ffmpeg_ffi_test/blob/master/build.rs [20:17:13 CEST] <JEEB> of course > crates [20:17:19 CEST] <jamrial> Lynne: not really much different than x264's x264opts api [20:18:36 CEST] <JEEB> and getting av_version_info utilized ended up like https://github.com/jeeb/ffmpeg_ffi_test/blob/master/src/main.rs [20:18:45 CEST] <JEEB> so at least the other way (if you're OK with cargo) didn't seem too bad [20:18:53 CEST] <JEEB> the problem is if you need to manually generate the stuff the other way [20:26:32 CEST] <JEEB> -32 [21:06:56 CEST] <cone-436> ffmpeg 03Paul B Mahol 07master:b67af536be10: avfilter/vf_random: fix crash [21:53:25 CEST] <cone-436> ffmpeg 03Paul B Mahol 07master:1331e001796c: avfilter/vf_floodfill: finish early if source and destination fill matches [22:03:07 CEST] <Lynne> btw the 16 bit integer fft is actually used in the codebase, in the ac3_fixed encoder [22:54:42 CEST] <michaelni> durandal_1707, that mjpeg is not just mjpeg. that are blocks of 4(size)+7680 bytes interleaved with jpeg images (7680 smells like audio /4*25=48000 but didnt confirm what that data is) [22:55:27 CEST] <michaelni> the mjpeg parser has problems with the non mjpeg in there ... [22:56:06 CEST] <michaelni> i do have a patch that makes the mjpeg parser more robust (needs a bit more testing) i guess it cant hurt to make it more robust [22:56:46 CEST] <michaelni> but that file would probably best be handlled by a specific demuxer that seperates the non mjpeg out [22:58:33 CEST] <thilo> are you watching mjpeg-football? [22:58:49 CEST] <durandal_1707> yes [23:00:01 CEST] <thilo> not surprised [23:05:46 CEST] <durandal_1707> michaelni: binwalk sucessfully extract all jpg frames so its possible [23:08:17 CEST] <michaelni> sure its possible, but dont you agree that this is better handled with a demuxer that does something with the other data too? [23:13:37 CEST] <durandal_1707> michaelni: yes, but there are no headers and such [23:14:14 CEST] <michaelni> yeah, i noticed that too [00:00:00 CEST] --- Fri Oct 11 2019

1 0

ffmpeg.log.20191010
by burek 11 Oct '19

11 Oct '19

[00:13:11 CEST] <oldfriend83> and now? [00:13:22 CEST] <JEEB> uh-huh [00:14:19 CEST] <oldfriend83> hello, gus. Can anybody tell me why ffmpeg crashes when I set in overlay option Y coordinate with negative value? [00:15:59 CEST] <oldfriend83> https://pastebin.com/eP1tK4MU [00:19:30 CEST] <durandal_1707> oldfriend83: use latest ffmpeg version. not some old one. [00:25:55 CEST] <oldfriend83> durandal_1707: thank you [08:32:59 CEST] <lain98> i have a video with variable frame rate. i want to transcode it with smaller gop size. i use the command ffmpeg -i in.mp4 -g 10 out.mp4 but output video is constant frame rate. [16:32:17 CEST] <DHE> th3_v0ice: it's just called "format", shared with audio sample format and video pixel format [16:33:21 CEST] <kepstin> th3_v0ice: do you get a playback problem if you try to play it with ffplay? if so, can you post the complete log? [16:56:45 CEST] <th3_v0ice> kepstin: ffplay actually plays the video but it takes a while to start. It also prints the warning about unspecified pixel format. [17:29:07 CEST] <giaco> hello [17:30:05 CEST] <giaco> I'm playing with ffmpeg blackframe videofilter to detect dark frames: I successfully tune the params to get desired frames according to console output, but I'm not succeeding getting an output file [17:56:58 CEST] <kepstin> giaco: the blackframe filter should be just passing the frames through (it just attaches some metadata to them), it shouldn't be doing anything that prevents you from encoding an output file [17:57:19 CEST] <kepstin> giaco: maybe give an example of your command line and what you expect it to do? [19:36:17 CEST] <brimestone> Hey guys, is there a way to add close caption (not subtitle) to an MXF file using an srt file? [19:38:43 CEST] <DHE> if you mean EIA closed captions, there is no such encoder in ffmpeg right now [19:39:15 CEST] <brimestone> I see.. but you can extract from it correct? [19:40:04 CEST] <JEEB> you can get them from the video stream if they're included in it, yes [19:40:13 CEST] <JEEB> there's parsing from MPEG-2, H.264 and HEVC [19:40:15 CEST] <JEEB> and a decoder [19:40:35 CEST] <brimestone> Ahh so ffmpeg can decode but not encode? [19:44:57 CEST] <JEEB> brimestone: it can also of course pass those things through as long as the encoder side can put those in correctly [19:46:38 CEST] <brimestone> JEEB, DHE said no CC encoder in FFmpeg right now.. [19:46:52 CEST] <JEEB> no encoder for the closed caption data [19:46:57 CEST] <JEEB> but if you decode say H.264 with them [19:47:06 CEST] <JEEB> the caption data packets will be attached as side data [19:47:19 CEST] <JEEB> and as long as those don't get lost in your API usage, and as long as the video encoder can handle them [19:47:26 CEST] <DHE> and you can pass them unmodified to an output h264 or h265 stream [19:47:36 CEST] <JEEB> they will then be packaged in the encoder in the whatever format you're encoding [19:47:58 CEST] <brimestone> ahh.. as long as they already exist and not creating CC from an srt file [19:48:25 CEST] <JEEB> yup, making the closed caption packets out of nothing is what FFmpeg can't atm do since nobody wrote an encoder :) [19:48:28 CEST] <JEEB> watches are pelcome [19:48:43 CEST] <Chagall> I deleted all my installed ffmpeg libs, rebuilt from scratch and ran make install but ffmpeg still reports a config mismatch, what to do? [19:48:45 CEST] <brimestone> I see. [19:48:50 CEST] <brimestone> Thanks for the clarification. [19:49:12 CEST] <JEEB> Chagall: time to look at where the hell you're loading solibs from [19:49:17 CEST] <JEEB> strace or something [19:49:36 CEST] <DHE> an prior build not cleaned up? [19:49:49 CEST] <DHE> rm libav*/*.{so,a} [19:49:51 CEST] <DHE> something like that [19:58:04 CEST] <Chagall> ./usr/lib/x86_64-linux-gnu/libavcodec.so [19:58:05 CEST] <Chagall> derp [20:46:16 CEST] <SpeakerToMeat> Hello [20:46:24 CEST] <SpeakerToMeat> Question, doesn't x264 encoding support level 6? [20:47:25 CEST] <BtbN> "level 6"? [20:47:40 CEST] <DHE> as opposed to level 4.1 ? [20:48:10 CEST] <SpeakerToMeat> I need 6, as I'm encoding a 7680x740 file, afaik [20:48:15 CEST] <DHE> I don't think x264 itself cares. it doesn't have realtime requirements by itself, which is what the level really means [20:48:26 CEST] <SpeakerToMeat> Oh. I see [20:48:31 CEST] <DHE> ffmpeg does have some internal limit of 4096x4096 images iirc, due to 32 bit risks [20:48:43 CEST] <SpeakerToMeat> level is not a spec in the codec but a "equipment needs to support level x to play something this big/fast" [20:49:14 CEST] <DHE> yes, and x264 can constrain your encoding parameters or call you out if you tell if what level you want to meet and your options actually exceeds it [20:49:27 CEST] <SpeakerToMeat> Nod [20:49:37 CEST] <SpeakerToMeat> Well it IS encoding (without specifying a level), so... [20:49:54 CEST] <JEEB> SpeakerToMeat: x264 can support it, but unfortunately there were some additional things added into levels 6.x :P [20:50:06 CEST] <SpeakerToMeat> at 0.0043x but it is encoding supposedly for 7680x740 [20:50:34 CEST] <JEEB> namely it will utilize longer motion vectors [20:50:45 CEST] <JEEB> because for some bloody reason the H.264 spec contains that for level 6.x [20:50:55 CEST] <JEEB> which is why generally if you can, limit yourself to 5.2 :P [20:51:04 CEST] <SpeakerToMeat> hmmmm [20:51:13 CEST] <JEEB> x264 should output which level it's utilizing [20:51:19 CEST] <JEEB> if not by default, then -v verbose should bring it out [20:51:29 CEST] <SpeakerToMeat> Yeah sadly at that pixel size no go for 5.x [20:51:31 CEST] <JEEB> by default it selects the lowest matching your frame size etc [20:52:05 CEST] <JEEB> SpeakerToMeat: are you planning on having that thing decoded by a) older software decoders b) hardware decoders ? [20:52:12 CEST] <JEEB> if not, then don't care [20:52:25 CEST] <SpeakerToMeat> Interesting: "profile High, level 5.1 [20:52:38 CEST] <JEEB> yea, level frame size limitations are in 16x16 blocks [20:52:47 CEST] <SpeakerToMeat> Yeah no it's recent hardware and software that will decode it so. [20:52:50 CEST] <JEEB> not exact width/height [20:53:02 CEST] <SpeakerToMeat> Yeah macroblocks [20:53:06 CEST] <SpeakerToMeat> afaik [20:53:08 CEST] <JEEB> yup [20:53:36 CEST] <SpeakerToMeat> So what do you say about level 6... it enforces longer vectors? or it permits longer vectors and x264 goes happy with them? [20:53:48 CEST] <JEEB> it permits and x264 does default to them [20:53:51 CEST] <SpeakerToMeat> And, what's the harm/pro of longer motion vectors? [20:53:53 CEST] <JEEB> noticed it when encoding 2160p60 [20:54:04 CEST] <JEEB> (the rate isn't really related) [20:54:19 CEST] <JEEB> but yea, in the best case hwdec just says "nope, that level I don't support" [20:54:26 CEST] <JEEB> in the worst case your hwdec will just barf at it [20:54:41 CEST] <SpeakerToMeat> My guess is longer vectors make for a much longer encoding process but shouldn't affect quality or decoding speed [20:54:56 CEST] <SpeakerToMeat> Or am I wrong [20:55:09 CEST] <JEEB> it's mostly for encoder freedom, but note that until then the spec had motion vectors of specific length [20:55:19 CEST] <JEEB> thus any decoder that didn't specifically add support for longer ones "just in case" [20:55:25 CEST] <JEEB> would just give fabulous artifacts [20:55:26 CEST] <JEEB> :) [20:55:43 CEST] <SpeakerToMeat> Hah yeah, true [20:56:07 CEST] <SpeakerToMeat> Well x264 has a good truckload of options which afaik ffmpeg passes on... so, I guess it should be possible to reign those in... I hope [20:56:19 CEST] <JEEB> level most definitely [20:56:22 CEST] <SpeakerToMeat> At least without killign the expanded macroblock size capability [20:56:35 CEST] <JEEB> the motion vector lenght stuff I'm less sure about [20:56:36 CEST] <SpeakerToMeat> Yeah I mean achieving a level 6 with a defualt/short vector size [20:56:51 CEST] <JEEB> that said, a lot of hwdec just nope with level 6 [20:56:52 CEST] <SpeakerToMeat> If I'm idle one of these days I have to give the source a look [20:57:54 CEST] <JEEB> https://code.videolan.org/videolan/x264/commit/6f8aa71ce797be01fd2ebe53c072… [20:58:17 CEST] <JEEB> seems hard-coded [20:58:33 CEST] <SpeakerToMeat> My gods, thank god this is a short video (25 seconds), the encoding speed is atrocious [20:59:00 CEST] <SpeakerToMeat> I need an nvenc with the image quality and options granularity of x264 [21:00:00 CEST] <SpeakerToMeat> JEEB: Isn't it "i_mv_range" ? [21:00:24 CEST] <JEEB> true [21:00:28 CEST] <JEEB> that is actually a parameter :P [21:01:02 CEST] <JEEB> but only if that's exported [21:01:03 CEST] <SpeakerToMeat> Yuppers, on one hand it is a parameter so it grows the maximum value but you could still set it in theory [21:01:04 CEST] <SpeakerToMeat> yet..... [21:01:26 CEST] <SpeakerToMeat> checkasm.c line 1984..... [21:02:00 CEST] <JEEB> I think that's just updating the test [21:02:03 CEST] <furq> wait since when was there a level 6 [21:02:07 CEST] <JEEB> 2016 [21:02:11 CEST] <furq> nice [21:02:33 CEST] <JEEB> I'm a masochist that does 2160p60 with slow presets so I noticed it with my first 3D render :P [21:02:55 CEST] <furq> doesn't 5.2 support 2160p60 [21:03:03 CEST] <SpeakerToMeat> JEEB: it's seteable [21:03:09 CEST] <SpeakerToMeat> JEEB: "--mvrange <integer> Maximum motion vector length [-1 (auto)]" [21:03:16 CEST] <JEEB> SpeakerToMeat: great :) [21:03:26 CEST] <JEEB> the bigger problem is just that a lot of hw decoders will just barf at you [21:03:29 CEST] <JEEB> with level 6.x [21:03:33 CEST] <SpeakerToMeat> Nod [21:03:43 CEST] <furq> a lot of them will barf at 5 as well [21:03:47 CEST] <JEEB> furq: yes it does, just that my slower preset usage would have led to level 6.x by default :) [21:03:53 CEST] <furq> oh right yeah [21:04:16 CEST] <SpeakerToMeat> furq: But I'm nto sure it supports 7680x740 :P [21:04:36 CEST] <JEEB> anyways, at least I noticed with my first ever render :P [21:04:44 CEST] <SpeakerToMeat> Yet... it encoded at level 5.1 so x264 thinks it does [21:04:46 CEST] <furq> if that's not a typo then it should [21:04:50 CEST] <JEEB> "wait that stuff at ~40s looks weird" https://megumin.fushizen.eu/videos/mmd_stuff/yukarin_conqueror_sample.mp4 [21:04:54 CEST] <furq> that's way fewer macroblocks than 2160p [21:04:59 CEST] <JEEB> yea [21:05:28 CEST] <gmaciolek> I have an FFMPEG (n4.2.1) instance I'm running (via bash script, but straightforward on that end) that's processing a directory of .jpg files into an animated gif, using an "inline" usage of palettegen/paletteuse. for some reason, it's only giving me a 24 frame output, regardless of there being ~45 input frames. A simpler version of the same command (without the 'vf' mess) makes the expected result. [21:05:29 CEST] <SpeakerToMeat> Btw any idea why premiere (cs6) will insist an mjpeg (in mov) is prog whereas ff and mediainfo insists it's interlaced? [21:05:54 CEST] <BtbN> Can mjpeg even be interlaced? [21:06:00 CEST] <gmaciolek> Also, this only seems to happen on *some* of my image sets (!?) I can provide them if helpful. [21:06:13 CEST] <SpeakerToMeat> can't all formats be? in theory? [21:06:15 CEST] <furq> gmaciolek: pastebin the command line and output [21:06:29 CEST] <BtbN> I mean, you can just make half-height images and call them fields, sure. [21:06:37 CEST] <gmaciolek> furq: Working on it - what's a good pastebin these days? [21:06:47 CEST] <kepstin> BtbN: i'm pretty sure i've heard of interlaced mjpeg stuff, iirc mov has signalling for it [21:07:00 CEST] <furq> vpaste or clbin or something [21:08:11 CEST] <kepstin> hmm, might be wrong about that, but i'm pretty sure people have thrown interlaced video into mjpeg before [21:10:08 CEST] <BtbN> I'd imagine a weaved picture to look horrible when encoded with mjpeg [21:10:10 CEST] <SpeakerToMeat> Some days I feel the impulse to hexedit a file to check what's the real truth [21:10:20 CEST] <kepstin> looks like it's normally done with a separate image per field [21:10:34 CEST] <gmaciolek> Functional, no-split: http://vpaste.net/QRKRi [21:10:44 CEST] <SpeakerToMeat> BtbN: Not really, mjpeg should add no degradation to interlacing that any other codec wouldn't [21:11:08 CEST] <BtbN> other codecs encode interlaced as two separate images [21:11:26 CEST] <BtbN> or at least have special handling for the fact it's fields, not images [21:12:04 CEST] <gmaciolek> Broken, incomplete frame list, w/split: http://vpaste.net/vwuvt [21:12:40 CEST] <kepstin> BtbN: i just read the mov spec - each "frame" in the container consists of the jpeg data for both fields in the frame concatenated [21:12:54 CEST] <kepstin> (there's an offset stored to find the start of the second field) [21:14:22 CEST] <kepstin> https://developer.apple.com/standards/qtff-2001.pdf page 95 if you're curious [21:15:58 CEST] <gmaciolek> furq: If you're interested in the set of images, it's 12 megs. full-disk images of the GOES-16 weather satellite, and I've uploaded them here: https://kb1ysq.com/ffmpeg/ [21:16:11 CEST] <gmaciolek> (zipped and .tar.gz for convenience) [21:17:00 CEST] <SpeakerToMeat> Question, is there any player that'll do 1:1 playback? mpv and vlc all fit to screen so I can't see the true pixels... [21:17:19 CEST] <SpeakerToMeat> I don't care if it overflows my screen, I just need to see a section to see how the fine detail ended up [21:17:28 CEST] <gmaciolek> SpeakerToMeat: you can set them to be unscaled [21:17:49 CEST] <SpeakerToMeat> with which player? I tried setting vlc... it still constrained it to screen size [21:18:09 CEST] <gmaciolek> Take it out of fullscreen mode, and I *think* it works. [21:18:38 CEST] <SpeakerToMeat> Also, do you know of any player you can ask not to pad the video? I want to see black only where there's black, so I can see the true boundaries [21:19:12 CEST] <gmaciolek> Again, outside of fullscreen mode, both should do that unless you're specifying an aspect ratio or some such thing [21:19:31 CEST] <SpeakerToMeat> gmaciolek: Ooook.. if I take vlc off maximized, it WILL do it if I unselect always fit [21:19:35 CEST] <gmaciolek> If you have black borders on a window-sized VLC video with default settings, those borders are in your source material [21:19:42 CEST] <kepstin> mpv by default will downscale if the window would otherwise be larger than the screen, but there's probably a way to override that [21:20:14 CEST] <gmaciolek> kepstin: Yeah, I was about to try that, but I had to find a 4k video for my 2560x1440 screen heh [21:20:31 CEST] <kepstin> you could always playback with cropping if you need to see 1:1 detail of a section of thevideo [21:20:40 CEST] <gmaciolek> I'm also using a tiling window manager, so, my setup isn't exactly typical. And yeah - good call re: cropping [21:22:52 CEST] <kepstin> (note also that mpv will by default do scaling to correct aspect ratio if the video doesn't match your screen, tho this isn't a problem with most HD video formats) [21:26:36 CEST] <SpeakerToMeat> At least vlc complied as long as it wasn't maximized [21:28:08 CEST] <gmaciolek> Oh my - if I'm processing this without using the split, but just using it once after another (with palettenet and paletteuse), I get an error now! [21:33:46 CEST] <gmaciolek> here's the error where it bails/quits, near the bottom - http://vpaste.net/NLbA0 [21:34:25 CEST] <kepstin> gmaciolek: there's no possible way to have both palettegen and paletteuse in a single pipeline, that doesn't make sense [21:34:46 CEST] <gmaciolek> https://i.imgur.com/bhDRe2q.png [21:34:56 CEST] <furq> kepstin: it works fine if you ignore the fact that it buffers every frame [21:35:09 CEST] <gmaciolek> kepstin: There are several examples using it, and, I'm having similar issues now without doing it in one pipeline [21:35:11 CEST] <kepstin> well, if the buffers overflow then you'll lose some video [21:35:16 CEST] <gmaciolek> Or at least, I'm getting a visible error [21:35:42 CEST] <furq> i take it you got that png from palettegen [21:35:45 CEST] <gmaciolek> Take a look at my most recent vpaste and/or the screenshot of the error (so you get color syntax) [21:36:15 CEST] <gmaciolek> yes, command being ffmpeg -framerate 8 -pattern_type glob "*.jpg" -vf "palettegen" that-file.png [21:36:33 CEST] <furq> weird [21:36:34 CEST] <gmaciolek> (I don't probably need the framerate there, I just copied/pasted) [21:36:49 CEST] <gmaciolek> furq: If you want to try it with the same images, https://kb1ysq.com/ffmpeg/ [21:37:14 CEST] <gmaciolek> I'm a bit too bleary-eyed to try to move this to another machine right now [21:37:30 CEST] <kepstin> gmaciolek: can you run that with -v verbose so i can see what the filter setup did? [21:37:46 CEST] <furq> https://clbin.com/gV62t [21:37:49 CEST] <furq> that's what i use fwiw [22:13:45 CEST] <gmaciolek> kepstin: http://vpaste.net/xTnJe [22:18:12 CEST] <gmaciolek> kepstin: with color, as an image: https://i.imgur.com/As78Qy3.png [22:19:54 CEST] <kepstin> gmaciolek: there's some weirdness there - are your input jpeg files a mix of color and greyscale? [22:20:58 CEST] <kepstin> it looks like partway through one of the scalers is getting reconfigured from yuv to gray and stuff breaks after that [22:21:17 CEST] <gmaciolek> hmmm. They're the output from imagemagick's "convert" - scaling images down from 5k x 5k ish to 1080x1080 [22:21:34 CEST] <gmaciolek> I can probably specify more details re: the output format? [22:22:38 CEST] <furq> you could just do the scaling with ffmpeg [22:23:07 CEST] <gmaciolek> furq: Yeah, actually - I think I'll do that. [22:23:23 CEST] <gmaciolek> The current workflow is related to trying to minimize data moved over the wire, but, that's not needed anymore I think [22:23:56 CEST] <furq> just make sure you scale before split or else it'll use way more memory [22:24:15 CEST] <gmaciolek> hmm. Looks like the easiest kludge for that is to replace my "convert" with an ln -s heh [22:26:33 CEST] <SpeakerToMeat> Do you people have an opinion on this book? https://courses.streaminglearningcenter.com/courses/produce-videos-with-ffm… [22:27:58 CEST] <gmaciolek> Hm. Can I specify a maximum dimension, rather than e.g. a height? if I scale it as e.g. "scale=1080:1080" I assume it'll screw up the aspect ratio if the source isn't square, rather than using it as a max? [22:28:34 CEST] <furq> 1080:-1 if you know width is always >= height [22:28:40 CEST] <furq> otherwise you need to get fancier [22:29:08 CEST] <kepstin> gmaciolek: yes, the 'force_original_aspect_ratio' option to the scale filter allows that [22:30:39 CEST] <kepstin> you can also play around with using expressions for the height/width, but that options makes it a bit simpler, at least if all your stuff has the same input/output sar. [22:32:34 CEST] <gmaciolek> I'm going to pull my eues opit iof cI can 't find my glasses - IO don't even know how to change text size in urxvt /: [22:32:38 CEST] <gmaciolek> be back in a few [22:34:01 CEST] <SpeakerToMeat> you might need 1080:-2 in some cases [22:34:07 CEST] <SpeakerToMeat> or -2:1080 as you preffer [22:40:13 CEST] <kepstin> if you're using the force_original_aspect ratio option, then you'd use force_divisible_by=2 instead [22:40:48 CEST] <jpb> question on the loop filter - it seems that loop requires a "size" parameter. is there no option to just loop the entire file? [22:41:25 CEST] <kepstin> jpb: the loop filter buffers the entire uncompressed video in ram, so that's typically a bad idea [22:41:41 CEST] <jpb> ah - that's why. ok [22:42:01 CEST] <kepstin> jpb: consider using the the -loop input option instead [22:42:27 CEST] <kepstin> (which causes ffmpeg to seek back and re-read the file from the start when it reaches the end) [22:42:54 CEST] <jpb> that would be "stream_loop" ? [22:42:57 CEST] <kepstin> er, wait, let me make sure i have the right option there [22:43:01 CEST] <kepstin> yeah, stream_loop [22:43:13 CEST] <jpb> k, thx! [23:01:33 CEST] <gmaciolek> furq is there an advantage to your mkgif() vs your mkgif_long() ? [23:05:03 CEST] <kepstin> gmaciolek: for short videos it should be a bit faster [23:05:52 CEST] <gmaciolek> kepstin: with a 1080x1080 (we can call it 1920x1080 for ballpark), outputting to a GIF with a whole set of JPEG files as an input, what kind of buffer size are we talking for ~48 frames? [23:06:06 CEST] <gmaciolek> is that 1080*1080*8*48 bytes? [23:06:35 CEST] <kepstin> 1080*1080*4*48 assuming it's buffered as bgr0 or something similar [23:07:16 CEST] <kepstin> i think the buffering between filter elements is capped by frame count rather than memory size, but i don't remember the actual limits offhand [23:07:33 CEST] <gmaciolek> oh, yes, hm. so ~210 megs for that, so. Fine for most of my VMs, probably not something I want to run on an embedded system, especially if it gets larger/longer [23:11:52 CEST] <kepstin> huh, looks like there's actually no explicit limit, it'll just go until it runs out of ram or memory space. fun. [23:22:53 CEST] <gmaciolek> hm. [23:23:18 CEST] <gmaciolek> actually, scratch that hm - there may be an output size discrepancy, but that may be PEBKAC - my input image set may have changed [23:27:06 CEST] <gmaciolek> Yep - same file sizes. And, it looks like the processing time is a bit slower on the one with the pipeline / ppm conversion, on the order of 68 seconds vs 49 seconds for my batch of 7 conversions; I think I can take that, for the added wiggle room [23:37:26 CEST] <gmaciolek> Also, I can write out the ... can I? I wrote out the input file list to a temp file this time, and had ffmpeg read that, instead of making a bunch of symlinks. But, I have to sort that file anway. I wonder if I can do named pipes to save some disk IO... hmm... [23:43:49 CEST] <cehoyos> To whoever asked: FFmpeg's mjpeg encoder does not support interlace, so if you put an interlaced image into the encoder, you will get (very) bad quality if you don't increase the bitrate by a very factor / you will get significantly higher bitrate than with similar non-interlaced images. This is not true for encoders that do support interlaced input. [23:49:01 CEST] <kepstin> nothing stopping you from using the separatefields filter before encoding to mjpeg (and recombining them with weave filter after decoding), but that's unlikely to be compatible with other apps. [23:53:44 CEST] <gmaciolek> Ever wonder how different the world would be if - for example - the US color TV standard hadn't decided to be backward-compatible with B&W? And they'd decided to drop interlacing too? [23:54:21 CEST] <pink_mist> surely they've done that with digital tv signals though? [23:54:37 CEST] <BtbN> most digital TV signals are still interlaced for... bullshit reasons [23:55:04 CEST] <pink_mist> wow, that's very unfortunate [23:55:48 CEST] <gmaciolek> good lord [23:57:37 CEST] <kepstin> if your just set your digital tv encoder to output 60i, then you can send mixed 24p (telecined), 30p (split into fields) and 60i content without any discontinuities/reconfiguration :/ [23:58:46 CEST] <gmaciolek> I mean, these displays aren't using scanlines anymore, generally, and if they are, do they actually interlace their writes? [23:58:48 CEST] <kepstin> gotta make sure the transitions into commercials which might be different framerate from the show don't have any video dropouts/glitches on cheap hardware. [23:59:03 CEST] <kepstin> nah, the tvs all run motion-compensated deinterlacing before display [23:59:07 CEST] <gmaciolek> Because I can't imagine 60i displaying .. [23:59:09 CEST] <gmaciolek> exactly [23:59:11 CEST] <kepstin> usually with >1 frame lag [23:59:16 CEST] <gmaciolek> ughdfshjaf [23:59:31 CEST] <kepstin> (not that that's an issue with tv stuff, as long as the a/v sync is ok) [23:59:55 CEST] <gmaciolek> I imagine it's somewhat of an issue if you have multiple TVs in the same space on, but yeah [00:00:00 CEST] --- Fri Oct 11 2019

1 0

ffmpeg-devel.log.20191009
by burek 10 Oct '19

10 Oct '19

[03:59:06 CEST] <cone-253> ffmpeg 03Raphaël Zumer 07master:eeb1c515a867: avformat/ivfenc: Comment the length field encoding process [03:59:06 CEST] <cone-253> ffmpeg 03Raphaël Zumer 07master:d3807467b258: avformat/ivfenc: Change the length fields to 32 bits [03:59:06 CEST] <cone-253> ffmpeg 03Raphaël Zumer 07master:9d92403add22: avformat/ivfdec: Change the length field to 32 bits [05:27:39 CEST] <cone-253> ffmpeg 03Zhong Li 07master:949a1b3e2f75: lavc/qsv: remove vaapi device free function [05:27:40 CEST] <cone-253> ffmpeg 03Linjie Fu 07master:5345965b3f08: lavc/qsvdec: Add GPU-accelerated memory copy support [09:35:48 CEST] <cone-920> ffmpeg 03Paul B Mahol 07master:29327794b0be: doc/filters: mention rubberband supported commands [09:35:48 CEST] <cone-920> ffmpeg 03Paul B Mahol 07master:24b6e968a216: doc/filters: document atempo command [09:57:22 CEST] <cone-920> ffmpeg 03Paul B Mahol 07master:1ebac3cda9f4: avfilter/af_adelay: fix buggy behaviour [11:31:23 CEST] <durandal_1707> its bollocks when I reply with "gonna apply set ASAP!", usual suspect appears [11:35:41 CEST] <durandal_1707> THIS IS IT, I HAD ENOUGH OF YOU GUYS [11:36:19 CEST] <BtbN> I can't tell anymore if he's trolling or not... [11:36:27 CEST] <j-b> I'm going to call "Nicolas" without looking at the ml [11:36:34 CEST] Action: j-b opens mutt [11:36:55 CEST] <j-b> \o/ [11:37:28 CEST] <thardin> API changes do need a bit of discussion before being pusehd [11:38:50 CEST] <BtbN> It is a _very_ minimal API change, but getting mad if more than 24h of review time are requested if also a bit over the top. [11:39:23 CEST] <thardin> myeah [11:39:41 CEST] <j-b> Well, that's why you need a development policy [11:41:18 CEST] <BtbN> Not really, you need people who don't jump at each other over every little disagreement, and this would be resolved within two mails. [11:42:29 CEST] <j-b> And that never happens [11:42:47 CEST] <j-b> since 10y+ I've been around, it never happens [11:43:26 CEST] <j-b> You need guidelines, to say "you need to wait 1w for API changes" [11:47:01 CEST] <thardin> guidelines only get you so far if the actual problem is toxic people [11:54:29 CEST] <j-b> No, because you can tell them: "this is the policy" and they don't storm out [11:54:54 CEST] <j-b> API changes require 1week review, makes it that Paul wouldn't get pissed here, for example [12:01:33 CEST] <nevcairiel> if you cant request an extension for a day or so because you are busy right now without someone getting mad, policys dont help at all [12:03:12 CEST] <nevcairiel> paul always likes to play the victim card, but he is the source of many problems himself [12:05:47 CEST] <BtbN> On an unrelated note, I would really welcome a switch to something that's not the ML. Though I'm also not too much a fan of Gitlab. My primary experience with Gitlab involves horrible code with security issues, that's slow and laggy and with an unintuitive UI on top. [12:06:38 CEST] <BtbN> I really like GitHubs UI. Would be nice if they had a variant to self-host. [12:06:40 CEST] <nevcairiel> I don't mind the UI, but I find Gitlab slow. Everytime I open a dav1d MR, it takes half a minute for all the content to load [12:07:11 CEST] <BtbN> Yeah, something in Gitlab is horribly inefficient [12:07:31 CEST] <BtbN> We have an instance at work, with maybe 20 users in total, so usually only a single user hitting the server. [12:07:34 CEST] <BtbN> And it still is slow [12:09:52 CEST] <j-b> > Such interpretation is not in documentation. [12:09:56 CEST] <j-b> And there you go. [12:11:54 CEST] <nevcairiel> there is actually some timings in the documentation, which states a "reasonable timeframe" for "small patches" is at least 3 days. [12:12:51 CEST] <nevcairiel> there is also a clause that people can ask for more time [12:51:37 CEST] <durandal_1707> michaelni: could you review my patches, at least I deserve that because of how much your patches I had reviewed, also do not forget to apologize to Lynne [13:34:28 CEST] <Lynne> I think nicholas's issue is he's dictatorially maintaining a whole library [13:34:44 CEST] <Lynne> and blocking whatever he sees that he doesn't like [13:35:46 CEST] <Lynne> yet he hasn't written anything recently, what he wrote were mostly framework-side patches year(s?) ago, and durandal_1707 does most the work on lavfi that isn't hardware-related [13:43:11 CEST] <Lynne> I do like the patch btw, it makes variable parameters far easier for filters last I looked at trying to add some to vulkan, but its not up to me :/ [13:44:33 CEST] <nevcairiel> The patch wasnt even rejected, it was only said that it needs a review [13:44:42 CEST] <nevcairiel> and more time should be allowed for that [13:45:47 CEST] <Lynne> I know right? he didn't ask for review specifically though, I think he just looked up the rules because they were in his favor now and decided to quote them [13:46:17 CEST] <nevcairiel> I do agree with him however that there is no need to rush an addition to the public api after only a day [13:47:54 CEST] <BtbN> Is this even public API? [13:48:07 CEST] <nevcairiel> of course, opt.h is an installed header [13:48:23 CEST] <BtbN> But it's only ever used in internal filters and codecs? [13:49:11 CEST] <nevcairiel> its an installed header, therefor its public API. Anyone could be using our opt system if they wanted to [13:49:34 CEST] <BtbN> Certainly not of this flag though, since the function evaluating it is not public. [13:50:39 CEST] <nevcairiel> maybe thats a good argument for not even having it in public API if its useless in there, and thus t he patch should change [13:51:44 CEST] <BtbN> All that stuff can't really be used outside of ffmpeg, can it? So while the header is public, it's not really part of the normal API. [16:35:06 CEST] <Mystnom> Hi, I have a scenario where I might need to remove an element from the begin position of a dynamic array, I see av_dynarray_add_nofree which adds element to dynamic array, is there any util available to remove element from dynamic array [16:38:00 CEST] <durandal_1707> Mystnom: if this is about developing FFmpeg itself, welcome to channel, otherwise you better ask on #ffmpeg [16:38:26 CEST] <Mystnom> Yes its about developing a new filter in FFmpeg [16:39:36 CEST] <durandal_1707> i'm afraid you will need to implement own structure and algorithm to handle that, depends what stuff will those arrays hold [16:42:46 CEST] <Mystnom> Thanks, will work on it. Just wanted to be sure there is no util already available within FFmpeg [16:43:41 CEST] <durandal_1707> depends what array will hold, and also you gonna use queue, stack or something completely different [16:44:31 CEST] <durandal_1707> for example libavfilter/af_dynaudnorm.c implements queue for its stuff [16:44:58 CEST] <durandal_1707> there is also audio fifo, for storing fifo of audio samples [16:45:51 CEST] <durandal_1707> other filters works on few items, so they just use memmove with simle array [16:45:58 CEST] <durandal_1707> *simple [17:26:08 CEST] <BtbN> That dude is still going... [18:30:13 CEST] <cone-206> ffmpeg 03Paul B Mahol 07master:3d262f9f326f: avfilter/af_anlms: increase max limit for mu [19:05:06 CEST] <cone-206> ffmpeg 03Paul B Mahol 07master:1cdb7c583984: doc/filters: add more examples for afftfilt [19:14:07 CEST] <Lynne> michaelni: are you ignoring me or hoping I would go away? [19:22:06 CEST] <jamrial> Lynne: stop it. you're not achieving anything by harassing someone to get an apology out of them [19:22:59 CEST] <jamrial> you're just proving Compn right, acting in such an obsessed way [20:12:27 CEST] <tmm1> hm h264_metadata_bsf is corrupting one of my samples in some subtle way [20:15:51 CEST] <tmm1> http://0x0.st/zwnW.png [20:21:15 CEST] <jamrial> tmm1: post the sample if you can and command line that reproduces it [20:26:20 CEST] <tmm1> jamrial: https://gist.github.com/tmm1/5737a57ea6b398d3e8d3cad4f12ebb49 [20:31:06 CEST] <tmm1> maybe h264_analyze is lying to me? [20:31:47 CEST] <tmm1> still strange that one byte is missing [20:34:54 CEST] <kepstin> iirc there's some variable length, optional, or filler fields in the h264 initialization data, so it's entirely possible to change the length without changing the meaning. [20:35:42 CEST] <kepstin> 1 byte difference is kinda odd tho [20:36:19 CEST] <tmm1> it also says the I slice nal starts with 0x800000 instead of 0x000000 [20:37:00 CEST] <tmm1> i noticed this after some android hardware decoder was choking on input if h264_metadata_bsf existed in the pipeline [20:39:35 CEST] <Lynne> jamrial: you think its all my fault too, probably [20:40:23 CEST] <Lynne> and you're okay with this dictatorship as long as you're on the right side too [20:40:34 CEST] <durandal_1707> Lynne: its not your fault, did you got angry mails? [20:40:36 CEST] <jamrial> tmm1: the 0x80 is the last byte of the previous nal, the itut t35 sei [20:41:35 CEST] <jamrial> your sample then starts a new nal with 00 00 00 01 (zero_byte + start_code_prefix_one_3bytes), while the bsf changes that to 00 00 01 (start_code_prefix_one_3bytes) [20:42:49 CEST] <jamrial> the spec apparently says the former must only happen with nals of type sps/pps, or in the very first nal of an access unit [20:50:44 CEST] <jamrial> Lynne: i'm seeing a pretty one sided outrage [20:51:07 CEST] <jamrial> i don't even know what pissed you so much from michael, but "ignored me" is in no way a justification for your reaction [20:52:15 CEST] <durandal_1707> Lynne thinks his patches are no longer welcomed [20:52:59 CEST] <jamrial> that's obviously not true [21:01:02 CEST] <tmm1> hmm, so i guess this android decoder expects the extra 0 byte like it originally exists [21:01:14 CEST] <tmm1> and removing it confuses h264_bitstream as well [21:10:31 CEST] <tmm1> i'm trying to find the part of the spec that says sps/pps or start of access unit [21:12:10 CEST] <tmm1> ah B.1.2 [21:35:11 CEST] <Lynne> durandal_1707: *her patches [21:45:36 CEST] <durandal_1707> i told michaelni to apologize but i failed miserably [21:46:37 CEST] <interester> and ... [21:47:35 CEST] <interester> guys, tell me please why I can't write onthe channel ffmpeg? I'm getting message "#ffmpeg Cannot send to nick/channel" [21:48:41 CEST] <durandal_1707> interester: need to register nick [21:48:58 CEST] <durandal_1707> because of spam, channel is limited [21:50:52 CEST] <interester> @durandal_1707: thank you, but can you tell me where I can do this? [21:51:26 CEST] <durandal_1707> google for: registed nick on irc freenode [21:51:31 CEST] <durandal_1707> *register [21:51:38 CEST] <interester> :) thanks a lot [22:12:13 CEST] <oldfriend83> I'm registered username, but still can't write on your channel ffmpeg, any thoughts? [22:21:27 CEST] <jamrial> you're not identified. you need to do run the "/msg NickServ identify" command [22:21:35 CEST] <jamrial> you should have gotten the notice from NickServ about it when you logged in after registering your name [22:28:22 CEST] <oldfriend83> I'm registered via mIRC, God knows where was that message [22:41:09 CEST] <oldfriend83> Ok, I got this "oldfriend83 has now been verified." BUT! yun't believe, I'm still can't write there anything [22:42:00 CEST] <BtbN> You are not logged in, no. [22:51:09 CEST] <tmm1> is there any alternative to h264bitstream that's better maintained? [22:51:20 CEST] <oldfriend83> BtbN: I'm still not logged in, right? [22:51:44 CEST] <BtbN> Just check your whois [22:51:56 CEST] <BtbN> NickServ will also clearly tell you if you successfully identified [22:53:55 CEST] <oldfriend83> as I undersand identification and logging in atre different thing? [22:54:11 CEST] <oldfriend83> *things [22:56:39 CEST] <oldfriend83> Ok, tell me please where and how do I log in? [22:57:03 CEST] <BtbN> Just read the NickServ help. [22:57:39 CEST] <philipl> BtbN: did you look at that cuviddec chroma patch? I didn't quite get what problem it was solving [23:01:52 CEST] <BtbN> It appears to query the chroma format of the video and pass it to the caps check. [23:02:07 CEST] <BtbN> Just so it can bail out early if cuvid does not support 422 or 444 I guess? [23:03:36 CEST] <BtbN> The patch seems fine to me generally, it just seems odd that the capability check for 8 bit is plain removed. I'm not aware of any format where 10 or 12 bit decoding is supported, but 8 bit isn't. [23:11:19 CEST] <tmm1> ok if i add an extra zero_byte in front of every H264_NAL_SLICE then the diff is less noisy, and I see that 5 bytes are missing from the contents of every slice [23:21:35 CEST] <jamrial> tmm1: sure, but you shouldn't need to. that decoder choking on it is misbehaving [23:30:04 CEST] <tmm1> yea but i need a workaround until the vendor fixes their decoder. i suppose i could just not modify the bitstream since all i'm using h264_metadata is for extracting [23:31:10 CEST] <jamrial> tmm1: just change the relevant code in cbs_h2645_assemble_fragment() cbs_h2645.c locally to always write the zero_byte [23:34:38 CEST] <tmm1> right that's what i did, now i'm comparing the diff again because some bytes are still different and its still not playing [23:34:54 CEST] <tmm1> so that extra zero_byte doesn't matter, its something else [23:35:17 CEST] <mkver> Maybe cabac zero bytes at the end of the slices that get dropped? [23:36:04 CEST] <tmm1> yep, comparing hexdump shows bytes missing at the end of the slice data [23:36:14 CEST] <mkver> (Sorry, I am not privy to the start of your conversation, so that could have already been ruled out.) [23:36:33 CEST] <tmm1> where are those removed? [23:36:44 CEST] <mkver> At the end of the NAL slices. [23:37:03 CEST] <tmm1> i see a "Deleted trailing zeros from slice data" in cbs_h264_read_nal_unit but that code isn't triggering [23:37:41 CEST] <mkver> It's deleted in cbs_h2645_fragment_add_nals [23:39:48 CEST] <tmm1> thanks [00:00:00 CEST] --- Thu Oct 10 2019

1 0

ffmpeg.log.20191009
by burek 10 Oct '19

10 Oct '19

[00:07:00 CEST] <AlexVestin> is there a way to remove the artifacts in the high frequencies with AAC? I'm a bit confused since it seems to be relatively noticable using the FFmpeg binaries [00:11:05 CEST] <AlexVestin> The difference between with mp3: https://fysiklabb.s3.eu-west-3.amazonaws.com/short.mp3 and AAC: https://fysiklabb.s3.eu-west-3.amazonaws.com/short.aac [00:12:52 CEST] <BtbN> What ffmpeg version? [00:13:21 CEST] <AlexVestin> n4.2 [00:25:16 CEST] <AlexVestin> had a friend test the zeranoe build for windows with the same result [01:39:29 CEST] <Retal> Guys, i forgot how to check all available presets like (fast, ultrafast) for cuda? [01:44:53 CEST] <DHE> ffmpeg -h encoder=h264_nvenc # or whatever [01:45:11 CEST] <Retal> DHE: oh thanks! [02:35:14 CEST] <kepstin> hmm, I guess AlexVestin has just hit a file that ffmpeg's aac encoder doesn't handle well. that's 160kbps, it should be fine... [13:43:04 CEST] <cards> Strange observation. ffprobe -colors lists "NavajoWhite == #ffdead" [13:52:08 CEST] <alsuren> less of an ffmpeg-specific question and more of a question about h.264/http-live-streaming: If I have a hls stream (with the index in a .m3u8 file) and I shuffle the sections around, I get a bunch of "Playlist vs segment duration mismatch" errors when I run apple's mediastreamvalidator against it, and it only plays the first few chunks when I feed it into a browser. [13:53:09 CEST] <alsuren> is there a stream clock encoded in the h.264 chunks or something, and if there is, does anyone know of a way around it? [13:55:05 CEST] <BtbN> Of course there are timestamps in mpeg-ts [13:55:16 CEST] <BtbN> If you swap around segments, it will cause chaos [13:56:02 CEST] <alsuren> ideally, I would like to be able to write a smart server that can serve a custom .m3u8 random-ish walk through a library of videos, but keep the .ts segments hosted on a cdn [13:56:39 CEST] <BtbN> You will have to signal the discontinuity where it occurs then [13:57:44 CEST] <alsuren> can I encode a discontinuity into each of the segments before I upload it to CDN or something? [14:03:07 CEST] <DHE> the playlist files has something like #EXT-X-DISCONTINUITY you can put into the sequence to indicate that a break in timestamps in the video segments at this point in time is expected [14:03:16 CEST] <DHE> (check the RFC for exact specs as this is all from memory) [14:04:02 CEST] <BtbN> Not sure how well a player copes if you put that in front of every single segment though [14:04:08 CEST] <BtbN> it'll probably still break shit [14:04:29 CEST] <alsuren> I guess I'll find out :D [14:05:07 CEST] <alsuren> I now have a bunch of reading to do. Thank you both for pointing me in the right direction. [14:05:31 CEST] Action: DHE is ass deep in the RFC (for other reasons) [14:15:55 CEST] <alsuren> works like a charm and the results are quite fun to watch. Thanks again. [15:30:22 CEST] <Freneticks> hey I use master_pl_name for master playlist but there is no CODEC in my playlist [15:30:27 CEST] <Freneticks> is there a way to have it ? [15:45:55 CEST] <classsic> Hi, is there a "correct" method to check if rtsp stream stop transmit? like ffmpeg -i rtsp:// -f flv rtmp:// , but when source stop (ip camera), ffmpeg process stay like zombie process [17:07:55 CEST] <Fenrirthviti> re: OBS/ffmpeg avopts stuff, the example code provided uses priv_data: https://www.ffmpeg.org/doxygen/trunk/decoding_encoding_8c-example.html and that code was written ages ago and hasn't really been touched as not many people are actually using the custom ffmpeg output mode [17:08:27 CEST] <Fenrirthviti> We'll probably remove the priv_data if there's no reason to keep it in though. [17:09:08 CEST] <BtbN> I haven't yet tested if setting it on the context itself will set private options as well [17:09:25 CEST] <BtbN> It might need "try set on priv_data, if fails, try on ctx itself" logic [17:09:43 CEST] <Fenrirthviti> Yeah, I'm (and the rest of the team) isn't clear exactly why we use priv_data there, but the consensus is "that's what the docs said to do" more than anything else [17:09:58 CEST] <BtbN> Probably because the old example does, and it worked. [17:10:03 CEST] <Fenrirthviti> indeed [17:10:49 CEST] <BtbN> I'm not setup to build OBS, but it shuld be trivial to test if it still can set stuff like x264 params with the ->priv_data removed. [17:11:03 CEST] <Fenrirthviti> yeah we're poking at it now [17:12:12 CEST] <Fenrirthviti> I've never been happy with how we set opts in the first place, I wish we just parsed the CLI syntax instead of using opt=value [17:12:17 CEST] <Fenrirthviti> maybe can fix that too [17:12:21 CEST] <BtbN> I'm also still a bit confused why OBS opted to re-implement an entire second nvenc encoder. It seems like it was just to be able to pass in d3d11 frames, which ffmpeg could have taken as input just fine as well. [17:12:41 CEST] <BtbN> I think the CLI syntax works pretty much the way OBS already parses them? [17:13:29 CEST] <Fenrirthviti> I mean we get people who will type like "-crf 22" in the field and that doesn't get parsed [17:13:34 CEST] <Fenrirthviti> you have to type crf=22 [17:13:45 CEST] <kepstin> the cli has some special cases for a few options, but for the most part it just takes the key=value and passes it as avoptions to the contexts [17:14:07 CEST] <BtbN> ffmpeg.c calls av_opt_set_from_string [17:14:49 CEST] <Fenrirthviti> then again we might have already fixed that and I'm just misremembering cause of how little ffmpeg output mode gets used [17:15:18 CEST] <BtbN> We use ffmpeg output mode at ESA as botched second rtmp output, to have two different audio feeds. [17:15:48 CEST] <Fenrirthviti> yeah that's the more common use case I see [17:15:58 CEST] <Fenrirthviti> or UDP multicast stuff for those who don't like NDI [17:15:59 CEST] <BtbN> It's a bit annoying, since there is zero stream monitoring. [17:16:23 CEST] <Fenrirthviti> being able to do multiple outputs is pretty high on our list of things we want to implement [17:16:34 CEST] <Fenrirthviti> it's entirely a UI limitation, and UI is the worst. [17:16:42 CEST] <BtbN> Yeah, same video feed, different audio feeds. Would be super nice [17:17:10 CEST] <Fenrirthviti> we have a ton of drafts and design docs for how it could work, just need to find the time to basically rewrite large parts of the UI [17:17:46 CEST] <BtbN> I have considered adding libobs support for ffmpeg, but that would be quite a dependency cycle. [17:18:18 CEST] <BtbN> But specially the various capture capabilities it has would be nice to have as inputs [17:18:27 CEST] <Fenrirthviti> we've been asked for headless support for ages [17:18:34 CEST] <JEEB> I think someone had a WIP patch set for the newer windows capture API [17:18:38 CEST] <JEEB> for libavdevice [17:18:38 CEST] <Fenrirthviti> tons of use cases there [17:18:55 CEST] <JEEB> I meant to take a look at it at some point [17:19:04 CEST] <BtbN> JEEB, yeah, desktop duplication API. It didn't even look that bad. Wonder why it was never sent. [17:19:25 CEST] <JEEB> probably because the person felt that they didn't have the time to "go through it and finish it up" [17:19:28 CEST] <BtbN> But libobs has support for hooked game capture and various non-standard capture cards. [17:20:08 CEST] <Fenrirthviti> most of that is dshow hacks, iirc [17:20:13 CEST] <Fenrirthviti> unless you mean the decklink plugin [17:20:26 CEST] <BtbN> The asortment of dshow hacks is quite useful though [17:20:36 CEST] <Fenrirthviti> I believe those are all available in libdshow [17:21:06 CEST] <Fenrirthviti> sorry, libdshowcapture https://github.com/obsproject/libdshowcapture [17:23:11 CEST] <kepstin> hmm, no C api? I assume you link that statically with obs, so it probably doesn't have a stable abi either? [17:23:48 CEST] <JEEB> I'm pretty sure if you start adding an external lib utilizing dshow into FFmpeg, you would then get people asking why you don't add that stuff to the dshow libavdevice [17:24:12 CEST] <BtbN> Because it's a lot of messy code [17:25:13 CEST] <Fenrirthviti> I'm not 100% on how Jim treats the ABI for libshowcapture off the top of my head. [17:41:35 CEST] <Freneticks> Do you know if it's possible to play HEVC on firefox/chromium ? [17:42:12 CEST] <JEEB> Freneticks: I know some of the chromium code has some HEVC-related stuff there but not more than that. on desktop builds you're not going to get it anyways. [17:50:15 CEST] <Rodn3y> On Android and Chromebooks you might get HEVC playback, but certainly not on desktop. [17:51:09 CEST] <kepstin> Freneticks: hevc basically only works on safari and edge [17:51:19 CEST] <kepstin> and on edge only on system configurations with a hardware hevc decoder [17:52:54 CEST] <kepstin> note that the feature requests for firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1332136 and chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=684382 were both closed as "wontfix" [17:53:14 CEST] <JEEB> yea they both want to keep HEVC out of the desktop space [17:54:02 CEST] <JEEB> not supporting hwdec is probably a stance since that's what they're doing on ARM/mobile [17:54:12 CEST] <JEEB> but swdec is like "nope, not gonna do that" [17:55:40 CEST] <Freneticks> yeah too much patent problem [17:55:51 CEST] <Freneticks> AV1 is the future [17:56:14 CEST] Action: kepstin wonders why google is developing their own av1 decoder instead of using dav1d [17:57:34 CEST] <JEEB> kepstin: because they can throw man-hours at a problem. and they love having the control on stuff [17:57:53 CEST] <JEEB> it mentions android but it was slower than even libaom on ARM last tested I think? [18:08:40 CEST] <kepstin> looks like they only have one dev working on it, so maybe it's just a side project from someone who just wanted to make a video decoder [18:11:39 CEST] <kepstin> the use of the apache 2.0 license is interesting, since it includes an explicit patent grant [18:15:28 CEST] <Fenrirthviti> Also just to come full circle since we've been testing, the person who was trying to use maxrate/bufsize with hevc_nvenc was doomed to begin with because those options don't do anything [18:16:07 CEST] <Fenrirthviti> tested with ffmpeg direct and in OBS, same results, the options aren't doing anything. Probably doesn't support them. [18:16:17 CEST] <kepstin> they get passed to the nvidia apis, but who knows what they do there :/ [18:16:21 CEST] <Fenrirthviti> yeah, indeed. [18:16:24 CEST] <kepstin> might even be different on different cards [18:16:32 CEST] <Fenrirthviti> It's correct they weren't being passed, which we have fixed now [18:16:42 CEST] <Fenrirthviti> But they don't do anything even when passed, so, yeah [18:17:15 CEST] <JEEB> yes, it's always fun with those OtherEncoders when you expect them to work as well as libx264 - even if options were mapped to something in teh called upon API :/ [18:18:32 CEST] <Fenrirthviti> Ah wait, maybe it is working. It's in bits, not kilobits. [18:18:45 CEST] <Fenrirthviti> so was being treated as an invalid range [18:18:57 CEST] <JEEB> yup [18:19:03 CEST] <JEEB> historical thing in avcodec [18:19:54 CEST] <kepstin> i think the option parser should accept unit suffixes like 'K' on that? [18:19:59 CEST] <Rodn3y> It does yeah [18:20:07 CEST] <JEEB> yup [18:20:21 CEST] <JEEB> if you pass them as AVOptions instead of just setting a value into the avcodeccontext [18:20:21 CEST] <Rodn3y> The guy complaining that it didn't work just kinda forgot a few zeroes... [18:27:11 CEST] <Fenrirthviti> Rodn3y is the one on our team messing with it :P [18:36:36 CEST] <Rodn3y> So yeah, seems like BtbN had the right idea. Without rewriting this (which really has to happen at some point...), the smallest fix is to try priv_data first, and then context if that fails. [18:37:17 CEST] <Rodn3y> This stuff has been mostly unchanged for the past 5 years so it's due for some updates. Unfortunately other, bigger, fires keep coming up :p [18:38:43 CEST] <BtbN> You could also do d3d11 frame input straight into ffmpeg with some work. Various filters and mappings and encoders can take it. [18:41:51 CEST] <Rodn3y> I think Xaymar's ffmpeg encoders plugin actually does that [18:42:34 CEST] <Fenrirthviti> It does, yeah, as of a few days agoo [18:43:50 CEST] <Bugz000> hey guys i'm trying in vain to get a text overlay and image overlay (dynamic) on a ffmpeg stream [18:44:18 CEST] <Bugz000> the text updates just fine, however the image does not [18:44:37 CEST] <Bugz000> and i can't seem to get filter_complex to work right [18:45:15 CEST] <Bugz000> https://pastebin.com/wm3QYyz6 this shows and updates the text and shows the image but doesn't update the image [18:45:31 CEST] <Bugz000> https://stackoverflow.com/a/49467812 [18:45:39 CEST] <Bugz000> i'm trying to follow this [18:46:06 CEST] <Bugz000> all i've achieved so far is making myself feel stupid so an ffmpeg guru could please put me out of my misery [18:46:18 CEST] <Bugz000> haha [18:47:04 CEST] <Bugz000> https://i.imgur.com/rW185Ne.png [18:47:11 CEST] <BtbN> I don't see an image anywhere in that filters [18:47:21 CEST] <Bugz000> oh woops [18:47:38 CEST] <Bugz000> wrong one sec [18:47:44 CEST] <Bugz000> i got like 50 here -facedesk- [18:48:01 CEST] <Bugz000> https://pastebin.com/T1p1PvPV [18:48:26 CEST] <kepstin> Bugz000: that makes no sense, if you have two -vf options, only the last one is used (the other is ignored) [18:48:34 CEST] <kepstin> you probably need to be using -filter_complex here [18:48:49 CEST] <Bugz000> this is for Shinobi but i think this is more of an FFMPEG question than Shinobi, and i've got a feeling i need to be using the input flags [18:49:00 CEST] <kepstin> although it might make sense to use an input for the image rather than a filter [18:49:07 CEST] <Bugz000> https://pastebin.com/aJF1DWuc [18:49:16 CEST] <Bugz000> i'm trying filter complex here [18:49:38 CEST] <Bugz000> https://i.imgur.com/BFaLOFq.png [18:49:41 CEST] <kepstin> alright, that looks more like something that has a chance of working [18:49:53 CEST] <Bugz000> throws an error though [18:50:10 CEST] <kepstin> that error doesn't matchteh command you run, so ? [18:50:23 CEST] <Bugz000> that's what confused me [18:50:58 CEST] <kepstin> get this working directly with the ffmpeg cli first, we can't really help you with other applications. [18:51:16 CEST] <Bugz000> i can pull the whole ffmpeg command [18:52:11 CEST] <Bugz000> https://pastebin.com/jf90Mei5 [18:52:20 CEST] <Bugz000> this is what the application is running total [18:52:56 CEST] <Bugz000> oh hey, -boundary_tag shinobi [18:53:36 CEST] <kepstin> for some reason its adding mjpeg related options to your command, you need to tell it not to do that [18:53:52 CEST] <Bugz000> it's taking an RTSP stream in and pushing out as mjpeg [18:54:04 CEST] <Bugz000> but i can change formats [18:54:30 CEST] <kepstin> so, it's taking one rtsp in, and one image in, and outputting to hls [18:54:50 CEST] <kepstin> and the image in is using mjpeg options but then you've overridden it to -f image2, which means the mjpeg options fail [18:55:12 CEST] <Bugz000> ohright [18:55:14 CEST] <kepstin> that's just a really weird command all around [18:55:31 CEST] <Bugz000> i have literally no idea what i'm doing dude so it's a miracle i've got this far [18:55:57 CEST] <kepstin> it's using libx264 output options, but the output encoder is set to 'pam"? :/ there's no way pam works with hls [18:56:07 CEST] <kepstin> oh, no, there's a copy in there too [18:56:16 CEST] <kepstin> too many conflicting options overriding each-other [18:56:19 CEST] <Bugz000> LOL -facedesk- [18:56:31 CEST] <Bugz000> okay okay so let's go default and see if that's "normal" [18:56:36 CEST] <kepstin> copy doesn't work with filters of course, [18:56:40 CEST] <Bugz000> undo everything i've done [18:56:47 CEST] <Bugz000> well, put in storage [18:58:02 CEST] <Bugz000> https://pastebin.com/9K4fVpHB [18:58:18 CEST] <kepstin> that's still horribly messed up and broken [18:58:31 CEST] <Bugz000> it is outputting as HLS now [18:58:34 CEST] <Bugz000> not mjped [18:58:38 CEST] <Bugz000> mjpeg* if that helps [18:58:54 CEST] <kepstin> it has -c:v otuput option specified *3* different times, each overriding the last [18:59:03 CEST] <kepstin> the final one that takes effect is -c:v copy [18:59:45 CEST] <kepstin> oh, there's actually two separate outputs in that command [18:59:54 CEST] <kepstin> one is being encoded with x264, the other one is using copy [19:00:42 CEST] <kepstin> i have no idea what's up - if that command line is generated by a tool, you'll have to talk to the devs of the tool to see what they're trying to do and fix it :/ [19:00:52 CEST] <Bugz000> yah i'm speaking with the dev now actually [19:01:14 CEST] <Bugz000> what would you say is wrong with it ? i know this has provisions for sending data off to a motion detection library [19:01:15 CEST] <kepstin> adding the text overlay filter stuff you're talking about to that command isn't trivial [19:02:06 CEST] <Bugz000> the text works fine, shows and updates [19:02:10 CEST] <kepstin> actually, this command looks correct for sending one encoded h264 hls stream alongside reduced resolution+color mjpeg data to another hls stream [19:02:15 CEST] <Bugz000> however the image overlay does show- getting it dynamic is tricky [19:02:35 CEST] <Bugz000> ah thats good [19:03:15 CEST] <kepstin> it still has some weirdness in that it's using multiple -c:v options on the second output, and has some unused parameters like -tune [19:04:16 CEST] <kepstin> looks like it's actually a command designed for three outputs, but the second output filename is missing [19:04:23 CEST] <kepstin> oh, wait, no, i just missed it [19:04:27 CEST] <kepstin> it is a three output command [19:04:31 CEST] <kepstin> weird [19:04:49 CEST] <Bugz000> uhhh again there's povisions to pipe this stream to other shinobi servers for multiple tiers [19:04:54 CEST] <Bugz000> iirc [19:05:07 CEST] <Bugz000> i suspect that could be it [19:05:15 CEST] <kepstin> it outputs one h264 re-encoded hls stream, one greyscale pam image stream, and one pass-through copy stream [19:06:19 CEST] <kepstin> anyways, as i mentioned, it is not trivial to add the filters you want to this command. That's because doing so requires using -filter_complex, which means that you're going to need to use -map options on each of the outputs separately to pick the right streams for the output [19:06:40 CEST] <alsuren> @DHE @BtbN I thought you might like the toy I made to test out your advice https://shuffle.glitch.me/ [19:07:09 CEST] <Bugz000> damn [19:07:14 CEST] <kepstin> so yeah, you're probably not going to be able to do it without modifying whatever tool is generating the command [19:07:25 CEST] <Bugz000> i'll go poke the dev and show him [19:07:38 CEST] <Bugz000> he's pretty active so he might get this working [19:07:39 CEST] <Bugz000> :D [19:09:09 CEST] <Bugz000> oh may i ask what would be the hardware overheads of outputting the two extra streams? [19:09:39 CEST] <Bugz000> i mean if they're not used surely it would be beneficial to not even have them outputting right [19:10:04 CEST] <Bugz000> or does it only open a "socket" and only actually start crunching data if something wants it [19:12:36 CEST] <Bugz000> https://i.imgur.com/nhTEtiT.png i only ask because a full 1080p 25fps stream from my ip camera is very low bandwidth [19:13:09 CEST] <Bugz000> put through ffmpeg and it easilly pumps out the same data at over 20mb/s, the inflation is a little insane [19:17:38 CEST] <kepstin> Bugz000: ffmpeg processes all outputs all the time. THe second output in that command is to a pipe, so if nothing reads it then it will block ffmpeg from proceeding. The third output is doing a copy, not re-encoding, so it's fairly low overhead other than disk io. [19:17:55 CEST] <Bugz000> ah good [19:18:43 CEST] <kepstin> actually, it's putting that third output into memory, so it's not even disk io :) [19:20:13 CEST] <kepstin> the first one is doing video encoding, but it's pretty unlikely you're getting anywhere near 20 mbyte/s (i'd bet it's even under 20mbit/s). And that's also to memory, not disk. [19:24:05 CEST] <Bugz000> rofl i just tried HEVC output and my browser is crying [19:24:28 CEST] <Bugz000> https://i.imgur.com/JZ5vR9W.png [19:25:46 CEST] <saml> is HEVC battery good on mobile? [19:27:52 CEST] <kepstin> i'd expect it to probably be fairly similar to h264 when using hardware decoding on mobile [21:22:04 CEST] <snatcher> what's the most flat/compressed (same audio in different formats converted to it will be mostly identical) audio format? [21:25:13 CEST] <snatcher> also what's the better to perform drc in such a case? loudnorm? [21:33:32 CEST] <kepstin> not sure what you mean with the first statement [21:34:02 CEST] <kepstin> audio codec compression has nothing to do with dynamic range compression [21:36:04 CEST] <kepstin> the "loudnorm" filter does do some dynamic range compression, in that it'll lower the overall loudness of loud sections of audio, and increase the loudness of quiet sections, but it doesn't operate like the dynamic range compression that mastering engineers typically use [21:37:32 CEST] <kepstin> it's more useful for stuff like "i have a recording where people talking quietly is mixed with loud music, and i want to make it so i don't have to adjust the playback volume constantly" [21:40:43 CEST] <snatcher> kepstin: i see, so better to use compand, anyway still not sure what format and bitrate/frequency(lowest?) use to get persistent result from different formats [21:41:15 CEST] <kepstin> i'm not sure what you're trying to do, so i can't really help you [21:41:56 CEST] <kepstin> if you want to make sure the output audio format makes no changes to the audio when encoding, use a lossless format like flac [21:44:12 CEST] <kepstin> if your goal is to try to match audio for fingerprinting/comparison, then merely converting it to a common format (bit depth, sample rate, etc.) generally isn't sufficient [21:44:49 CEST] <kepstin> (but often is a first step when you're doing feature extraction) [21:45:55 CEST] <snatcher> kepstin: same audio in different formats/quality, how can i make sure content is not the same? idea is: downmix all input files to stereo, drc(better before or after conversion to specific format?), convert to some flat/persistent format/quality, compare chromaprints [21:46:15 CEST] <kepstin> snatcher: just go straight from original files -> chromaprints [21:46:25 CEST] <kepstin> the chromaprint stuff already does all the required normalization [21:46:38 CEST] <kepstin> https://oxygene.sk/2011/01/how-does-chromaprint-work/ is an interesting read :) [21:47:59 CEST] <snatcher> kepstin: are you sure there is no way to improve it with additional conversions? while i get different chromaprints between the same audio in flac/opus(320) [21:48:19 CEST] <kepstin> they will be different, yes, you need to use a threshold when comparing them [21:48:26 CEST] <kepstin> see the blog post i linked [21:49:13 CEST] <kepstin> note that when you're using the online acoustid service, it does serverside thresholding/comparison of the chromaprints [21:49:34 CEST] <kepstin> in that case, you can just go by "do i get the same acoustid back?" [21:49:53 CEST] <durandal_1707> it will fail miserably if i areverse audio [21:50:37 CEST] <kepstin> durandal_1707: yes? it's not intended to handle that sort of thing... [21:51:14 CEST] <kepstin> chromaprint/acoustid sort of came out of the musicbrainz project as a way to detect which particular recording/track and audio file was, so metadata could be looked up automatically [21:53:53 CEST] <kepstin> it's not designed to be robust enough against noise, or to work for arbitrary bits of audio, to work as a "shazaam" style thing, and it's not designed to work around changes people make like speed, phase, etc. for use in automatic copyright matching stuff. [22:11:30 CEST] <snatcher> kepstin: do you mean -silence_threshold chromaprint option? [22:13:50 CEST] <kepstin> snatcher: i'm not sure what that does, tbh. [22:15:47 CEST] <snatcher> seems with value >=21000 outputs the same fingerprint for any(?) file [22:22:02 CEST] <kepstin> my guess is that the purpose of that is to better match files that start/end with different amounts of silence, but don't quote me on that. [00:00:00 CEST] --- Thu Oct 10 2019

1 0

ffmpeg-devel.log.20191008
by burek 09 Oct '19

09 Oct '19

[04:39:10 CEST] <cone-580> ffmpeg 03Zhong Li 07master:6f0dd6b4ab65: lavc/qsv: fix a memory leak in ff_qsv_set_display_handle() [04:39:10 CEST] <cone-580> ffmpeg 03Zhong Li 07master:8df91de9aa26: lavfi/normalize: remove the unused pointer [07:37:29 CEST] <cone-580> ffmpeg 03elliottk 07master:14941d386acd: Change libvpxenc default to crf=32. [07:48:39 CEST] <cone-580> ffmpeg 03Steven Liu 07master:db99b32a1bfc: avformat/hlsenc: add logging context to log [07:48:40 CEST] <cone-580> ffmpeg 03Steven Liu 07master:5db50dbf060f: avformat/udp: add logging context to log [07:48:41 CEST] <cone-580> ffmpeg 03Steven Liu 07master:35236fd729a3: avformat/rtmpptoto: add logging context to log [07:48:42 CEST] <cone-580> ffmpeg 03Steven Liu 07master:17236a2c402b: avformat/avidec: add logging context to log [07:48:43 CEST] <cone-580> ffmpeg 03Steven Liu 07master:4ff97342ceef: avformat/network: add logging context to log [07:48:44 CEST] <cone-580> ffmpeg 03Steven Liu 07master:cdf8253a061c: avformat/mmst: add logging context to log [07:48:45 CEST] <cone-580> ffmpeg 03Steven Liu 07master:8c16c133d035: avformat/mms: add logging context to log [07:48:46 CEST] <cone-580> ffmpeg 03Steven Liu 07master:76ab5ebbeea6: avcodec/mpegvideo_enc: add logging context to log [07:48:47 CEST] <cone-580> ffmpeg 03Steven Liu 07master:4aa391388a67: avcodec/videotoolbox: add logging context to log [07:48:48 CEST] <cone-580> ffmpeg 03Steven Liu 07master:aea36b63571e: avcodec/pngdec: add logging context to log [07:48:49 CEST] <cone-580> ffmpeg 03Steven Liu 07master:acc1256654fc: avfilter/vf_crop: add logging context to log [07:48:50 CEST] <cone-580> ffmpeg 03Steven Liu 07master:3dead10fa305: avfilter/vf_scale_qsv: add logging context to log [07:48:51 CEST] <cone-580> ffmpeg 03Steven Liu 07master:9b2155ad3f54: avfilter/boxblur: add logging context to log [07:48:52 CEST] <cone-580> ffmpeg 03Steven Liu 07master:985ed65117c7: avfilter/vf_pad: add logging context to log [08:24:27 CEST] <cone-580> ffmpeg 03Limin Wang 07master:a77fb510c268: avutil/avstring: support input path as a null pointer or empty string [08:24:28 CEST] <cone-580> ffmpeg 03Limin Wang 07master:61aa77272a25: avformat/hlsenc: remove the unnecessary null pointer check [08:24:29 CEST] <cone-580> ffmpeg 03Limin Wang 07master:28bb73cee77e: avformat/hlsenc: replace with av_dirname to get the directory [08:24:30 CEST] <cone-580> ffmpeg 03Limin Wang 07master:afab93ccd097: avformat/hlsenc: replace with av_freep for all av_free [09:00:05 CEST] <cone-580> ffmpeg 03vectronic 07master:e81c686a95b1: avformat/http: add ff_http_do_new_request2 for options [09:00:05 CEST] <cone-580> ffmpeg 03vectronic 07master:b21c5ef501d1: avformat/hls: pass http offset options to http request [09:00:06 CEST] <cone-580> ffmpeg 03vectronic 07master:e149be38a86f: avformat/hls: fix missing segment offset reset on last segment when http_multiple is enabled. [10:43:31 CEST] <cone-580> ffmpeg 03Andreas Rheinhardt 07master:ffb32d35eee6: avformat/mpeg: Remove set-but-unused variable [10:50:21 CEST] <durandal_1707> Lynne: your patches are not rejected [11:56:17 CEST] <cone-580> ffmpeg 03Paul B Mahol 07master:6023b9fbfef0: avfilter/af_anlms: add support for commands [13:12:00 CEST] <mkver> michaelni: Sorry, I didn't look for whether there are other flac patches on the ML. [13:42:16 CEST] <michaelni> mkver, no problem [14:12:03 CEST] <Lynne> durandal_1707: not rejected isn't "are welcome" [14:13:18 CEST] <durandal_1707> Lynne: please cite where michaelni said that [14:51:25 CEST] <Lynne> durandal_1707: nowhere, its what I feel like [14:52:13 CEST] <Lynne> I'm still waiting for an apology or even *something*, so far its as usual - ignoring [14:53:20 CEST] <durandal_1707> i cant help you with changing unacceptable michaelni behaviour, he is in position to dictate lot of things [15:53:53 CEST] <kierank> Lynne: sorry about that [15:53:58 CEST] <kierank> durandal_1707 is basically correct here [15:57:13 CEST] <Lynne> I don't even deserve a few words of apology? [15:57:46 CEST] <Lynne> how is that even acceptable michaelni? [16:00:50 CEST] <kierank> Lynne: I think he is incapable of understanding [16:02:26 CEST] <michaelni> Lynne, iam a human being, and since yesterday you are fingerpointing at me for things i do not even know what it is about now. I just want a peacefull relation with everyone. and i like to work on the code and technical things. I do not want to be pulled into all this drama, this is not ignoring anyone [16:06:36 CEST] <durandal11707> michaelni: you do not like to work on code and tehnical things [16:06:51 CEST] <durandal11707> you work on what you are being paid for [16:08:47 CEST] <durandal11707> if you workded on tehnical things, you would contribute new decoder/filter or finnaly improve swscale [16:09:14 CEST] <j-b> Can you avoid this kind of tone? [16:09:21 CEST] <j-b> This is not helpful [16:09:46 CEST] <j-b> improving security is as useful as new filters. [16:09:54 CEST] <j-b> swscale is hard for everyone. [16:10:30 CEST] <durandal11707> not really [16:11:09 CEST] <durandal11707> for both last two aspects [16:12:15 CEST] <j-b> Your opinion, it is. [16:12:28 CEST] <j-b> A lot of people care more about security than about new filters. [16:13:07 CEST] <durandal11707> security takes few lines of code and at most 5 minuts of thinking [16:13:14 CEST] <j-b> and there are tons of libraries doing audio/video filters [16:13:21 CEST] <j-b> not many doing codecs [16:13:30 CEST] <j-b> security can take a LOT more than 5minutes [16:13:38 CEST] <j-b> because you need a correct fix, not breaking the rest [16:13:39 CEST] <durandal11707> even more doing being "security" researches [16:13:44 CEST] <j-b> not just a quick fix [16:14:05 CEST] <durandal11707> i only see quick and rushed fixes [16:14:07 CEST] <durandal11707> on ml [16:14:22 CEST] <kierank> I think that has gotten a lot better now [16:14:28 CEST] <j-b> security research is a huge market, with thousands of people working on that full time [16:14:29 CEST] <kierank> very few if any horrible hacks [16:14:36 CEST] <BBB> while timeout: adjust some random threshold slightly [16:14:39 CEST] <BBB> done [16:14:39 CEST] <durandal11707> be honest, and admit how long you work on "security" [16:14:43 CEST] <kierank> BBB: lol [16:14:55 CEST] <BBB> can I patent bash quasi scripts? [16:14:56 CEST] <j-b> BBB: :D if only [16:15:13 CEST] <BBB> maybe if I write it carefully, it'll qualify for some ML/AI award [16:16:05 CEST] <j-b> Cleaning and maintenance is less fun, but is very useful for all the users. [16:16:08 CEST] <BBB> I think you guys are under-valuing what durandal11707 is saying here. ffmpeg certainly isn't the easiest codebase to work with, but I think we could learn a lot from the approach dav1d took when it comes to integer overflows [16:16:45 CEST] <BBB> remember the idct overflows? there is *none*, and I didn't cast anything to unsigned or crappy shit like that [16:16:53 CEST] <thilo> durandal_1707: yeah, and it seems like the next iteration of why we actually should have such a meeting is just going on...... nothing to be done if no dev has interest in it. popcorn and watching seems to be too good [16:17:20 CEST] <BBB> ffmpeg is not perfect and durandal11707 is simply pointing out that some of our approaches to security are not ideal [16:17:34 CEST] <BBB> I think it's a fair discussion point [16:17:38 CEST] <j-b> The issue is the tone. [16:17:39 CEST] <kierank> BBB: the timeout hacks are worse than the integer underflow [16:17:47 CEST] <BBB> :) there, thank you [16:17:48 CEST] <j-b> 16:06 < durandal11707> michaelni: you do not like to work on code and tehnical things [16:17:55 CEST] <BBB> it's ok to be a bit critical [16:17:55 CEST] <j-b> this is totally unacceptable tone. [16:18:03 CEST] <BBB> we have no code of conduct, sadly [16:18:26 CEST] <BBB> except for the melania one "be best" [16:18:31 CEST] <BBB> which is just hilarious [16:18:39 CEST] <BBB> :-/ [16:26:57 CEST] <jamrial> kierank: the timeout hacks are mostly gone ever since i made the fuzzer reference counted [16:27:18 CEST] <kierank> jamrial: yes s/are/were/ [16:27:19 CEST] <kierank> sorry [16:28:15 CEST] <jamrial> before that, yeah, i agree there were lots of crazy unecessary checks when the real issue was that the fuzzer was doing a lot of copies [16:28:34 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:c552c3ef70dc: avcodec/flac_parser: Make expected_frame_num, expected_sample_num 64bit [16:28:35 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:fe7fbf3a2273: avcodec/jpeglsdec: Return error codes from ls_decode_line() [16:28:36 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:675c6d1e1710: avcodec/jpeglsdec: Apply transform only to initialized lines [16:28:37 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:711ad71aea78: avcodec/sunrast: Check for availability of maplength before allocating image [16:28:38 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:bf0ba75c4a92: avcodec/sunrast: Check that the input is large enough for the maximally compressed image [16:28:39 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:9a0d36e562d5: avformat/mpsubdec: Clear queue on error [16:28:40 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:4a660fac9899: avcodec/truemotion1: Check that the input has enough space for a minimal index_stream [16:28:41 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:7f0498ed4619: avcodec/ituh263dec: Check input for minimal frame size [16:28:42 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:c371e50b4f12: libavcodec/dxv: Remove redundant seek [16:28:43 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:dd9e6d077ea3: avcodec/dxv: Subtract 12 earlier in dxv_decompress_cocg() [16:29:03 CEST] <jamrial> i think BBB or someone else suggested some of those could be revised, if anything to clean things up a bit [16:33:20 CEST] <j-b> everything can be improved, but tone is unacceptable. dav1d shows that we can work together without insulting, and calmly, and with PR [16:35:54 CEST] <kierank> not sure PR would work in ffmpeg tbh [16:35:55 CEST] <kierank> too many patches [16:36:25 CEST] <durandal11707> j-b: i state facts, i now know that stating facts is in violation of your rules [16:39:03 CEST] <j-b> durandal11707: stop putting words in my mouth that I have not said. [16:39:19 CEST] <j-b> I say you can say the same things without being attacking someone [16:39:39 CEST] <j-b> like "I think we should focus less on security, and more on features" [16:39:47 CEST] <j-b> instead of "you are not working well" [16:39:55 CEST] <j-b> difference is ad hominem [16:40:10 CEST] <kierank> j-b: do you not agree that the behaviour for security issues was very antagonising in the past? [16:40:15 CEST] <kierank> from michaelni [16:40:27 CEST] <kierank> just saying essentially "your opinion doesn't matter, it is security" [16:40:29 CEST] <j-b> kierank: I am mixed. [16:40:33 CEST] <nevcairiel> Two wrongs don't make a right, etc [16:40:39 CEST] <j-b> fixing security issues is very hard [16:40:40 CEST] <kierank> nevcairiel: true [16:40:52 CEST] <j-b> and security fixes were not all amazing [16:40:57 CEST] <j-b> but as you just said: [16:41:16 CEST] <j-b> 16:14 <@kierank> I think that has gotten a lot better now [16:41:18 CEST] <j-b> 16:14 <@kierank> very few if any horrible hacks [16:41:22 CEST] <kierank> sure [16:41:28 CEST] <kierank> but you can understand why people are still upset [16:41:33 CEST] <j-b> No. [16:41:38 CEST] <j-b> annoyed, yes. [16:41:41 CEST] <j-b> upset, no. [16:41:46 CEST] <j-b> insulting, never. [16:42:00 CEST] <j-b> 16:35 <@kierank> not sure PR would work in ffmpeg tbh [16:42:04 CEST] <j-b> 16:35 <@kierank> too many patches [16:42:07 CEST] <j-b> I disagree [16:42:15 CEST] <durandal11707> i'm always feeling insulted [16:42:15 CEST] <j-b> we now lose half of the patches [16:42:17 CEST] <kierank> wouldn't be too different https://patchwork.ffmpeg.org/project/ffmpeg/list/ [16:42:23 CEST] <kierank> just pages and pages of patches [16:42:27 CEST] <kierank> impossible to navigate [16:42:27 CEST] <j-b> kierank: no, because it would be the main page [16:42:33 CEST] <j-b> and you can close [16:42:35 CEST] <j-b> and have groups [16:42:59 CEST] <j-b> for example, if you have 10 versions of a 30 patches PR, it makes 300 entries on patchwork, and just one PR on gitlab [16:43:08 CEST] <j-b> that you can close, merge and tag [16:43:14 CEST] <jamrial> kierank: patchwork is a mess because more often than not i can't detect applied patches, and redone patches show up as separate entries [16:43:23 CEST] <j-b> Exactly that ^^ [16:44:03 CEST] <jamrial> at first i started manually tagging the stuff i pushed that it did not detect, but eventually gave up [16:44:06 CEST] <jdarnley> Non-linear history is the worst. I kow ffmpeg already has with merges from Libav but that is no reason to make it worse. [16:44:37 CEST] <j-b> jdarnley: how is that relevant? [16:44:57 CEST] <jdarnley> because PRs enocourage that nonsense [16:45:02 CEST] <j-b> https://code.videolan.org/videolan/dav1d/commits/master [16:45:11 CEST] <j-b> not one non-linear commit [16:45:14 CEST] <j-b> not a single one [16:45:25 CEST] <jamrial> jdarnley: everything gets rebased before the pr is merged [16:45:33 CEST] <j-b> just configure correctly gitlab [16:45:41 CEST] <jdarnley> well I am impressed it lets you do that [16:45:47 CEST] <jdarnley> and good job [16:45:49 CEST] <j-b> not only it lets you do that [16:45:52 CEST] <j-b> it can ENFORCE that [16:46:03 CEST] <j-b> no merge if no-rebase [16:46:08 CEST] <j-b> no merge if no-CI passing [16:46:17 CEST] <j-b> no merge if a discussion is still open [16:46:18 CEST] <j-b> etc... [16:46:44 CEST] <j-b> I absolutely hate non-linear history, jdarnley [16:48:30 CEST] <j-b> And if a PR is not-good, or too old, you can automatically close it, tagging it like "good-idea" and then you can search the tag to get ideas [16:58:53 CEST] <BBB> or you can have an unsorted wiki with good-and-bad ideas [17:00:46 CEST] <j-b> which gets outdated, when someone implement the MR [17:03:01 CEST] <durandal11707> what skills michaelni have that he was not able to fix simple timeouts that started popping all the time from google fuzzing reports, he should retire already [17:03:49 CEST] <kierank> durandal11707: outrageous comment [17:04:08 CEST] <BBB> yeah let's not go there [17:05:20 CEST] <thardin> I don't super-enjoy all these "important" fuzzing patches, but I can kind of see the point that michael made about them holding up more useful fuzzing of the related codecs and formats [17:05:34 CEST] <j-b> durandal11707: so, you think you can that better? [17:06:03 CEST] <thardin> I think we could open up the development of timeout patches a bit more, since they're non-critical [17:06:44 CEST] <thardin> them just appearing on the ML from on high is not the best way to do things [17:06:50 CEST] <kierank> well the security list is secret [17:06:53 CEST] <kierank> they "don't need any help" [17:07:02 CEST] <kierank> ffmpeg security should not be run by a secret cabal [17:07:06 CEST] <thardin> yeah but timeouts are not a security issue [17:07:09 CEST] <thardin> like [17:07:13 CEST] <thardin> come on [17:07:19 CEST] <kierank> I would largely agree [17:07:46 CEST] <thardin> maybe infinite loops, but "this runs slowly for this input" is ridiculous to put on the same level as "this is a potential RCE" [17:08:14 CEST] <thardin> the latter I totally accept may need to be kept kind of cabal-ish [17:08:14 CEST] <j-b> careful, timeouts can be security issues [17:08:34 CEST] <j-b> oss-fuzz gives a lot of things the "timeout" tag [17:08:40 CEST] <j-b> when it can be busy loops [17:08:43 CEST] <j-b> or other things [17:09:38 CEST] <thardin> I struggle to imagine a use case where using CPU is a problem where there is not already CPU limits in place [17:09:47 CEST] <kierank> vlc [17:09:53 CEST] <kierank> pc locks up with a file [17:09:56 CEST] <kierank> uses all cpus 100% [17:10:14 CEST] <thardin> so just kill vlc [17:10:20 CEST] <thardin> such serious [17:10:21 CEST] <kierank> may not be that easy [17:10:23 CEST] <kierank> on windows [17:10:28 CEST] <kierank> if it's using all the resources [17:10:37 CEST] <thardin> lol [17:11:01 CEST] <thardin> in that case send it upsteam to microsoft [17:11:55 CEST] <j-b> same for transcoding servers [17:12:06 CEST] <thardin> time limits on jobs [17:12:07 CEST] <j-b> you can DDOS someone by sending a lot of video [17:12:08 CEST] <kierank> transcoding servers are different imo, should be limits in container [17:12:10 CEST] <kierank> or something [17:12:13 CEST] <thardin> if you don't use them, you deserve to be punished [17:12:14 CEST] <kierank> it's end users running vlc [17:12:20 CEST] <kierank> where they have no knowledge of this [17:12:21 CEST] <j-b> sure, but if you get 10000 jobs [17:12:30 CEST] <kierank> rate limit [17:12:33 CEST] <kierank> not ffmpeg related [17:12:38 CEST] <kierank> same as getting 100gbit of traffic [17:13:17 CEST] <thardin> I can accept "this is holding up fuzzing". I cannot accept "this costs money for people with shitty business models who can't admin their servers" [17:14:48 CEST] <thardin> it's not hard to create videos that compress really well, and is even more effective when services accept .zip files [17:15:17 CEST] <j-b> Sure, but you cannot deny that DDOS can be an issue, and so busy-loops are. [17:15:36 CEST] <j-b> Not as important than OOB r/w, but still problematci [17:15:42 CEST] <thardin> I think you mean DoS [17:15:46 CEST] <thardin> DDoS is way out of scope [17:15:47 CEST] <j-b> yes [17:15:49 CEST] <j-b> sorry [17:15:58 CEST] <thardin> but again, time limits [17:16:30 CEST] <thardin> I did think of one case though: if there's a fork bomb-ish kind of bug lurking in there somewhere [17:16:33 CEST] <j-b> again, vlc on the desktop [17:16:48 CEST] <j-b> dismissing timeouts from oss-fuzz is too easy. [17:16:56 CEST] <thardin> but a single process bringing the system to a halt is an OS bug [17:17:23 CEST] <BBB> is vdd registration open? [17:18:09 CEST] <durandal11707> closed, no more place left [17:19:17 CEST] <j-b> thardin: you cannot blame always the user. [17:19:47 CEST] <j-b> CVE have an entry mode for busy-loop. [17:19:55 CEST] <j-b> You may not care about those, but they exist. [17:21:38 CEST] <durandal11707> yet, not such thing is ever fixed, because of timeouts fuzzing is restarted all the time [17:21:47 CEST] <thardin> my point is more that we could open the timeout fix development a bit [17:22:57 CEST] <durandal11707> and what about all side cases when allocation fails and memory leak happens? [17:23:08 CEST] <thardin> vlc using a lot of cpu would be annoying, but not catastrophic [17:23:46 CEST] <j-b> if someone wants to help fixing those bugs, it's easy to get access to those bugs. [17:25:48 CEST] <durandal11707> how many now bugs are on queue? [17:29:37 CEST] <j-b> I say around 90 [17:30:09 CEST] <j-b> and one for dav1d [17:31:01 CEST] <michaelni> for ffmpeg ossfuzz issues Not counting anything that might have been missed, I have 13 issues in my inbox that do not have fixes in some form posted to the ML. [17:32:05 CEST] <durandal11707> so lot of dupes that get fixed with single patch? [17:32:50 CEST] <j-b> Very likely [17:32:57 CEST] <j-b> or patches around [17:33:25 CEST] <michaelni> there are also about 2 weeks worth of patches on ffmpeg-devel which are not applied yet and a few that have comments and require changes [17:48:50 CEST] <jdarnley> BBB: dang, I forgot to check back on it [17:49:08 CEST] <jdarnley> or rather durandal11707 ^ [17:50:59 CEST] <jdarnley> oh well, no holiday for me [17:52:54 CEST] <jdarnley> on an unrelated note, I need to finish cleaning off my KB because this one from my brother is driving me nuts [17:53:02 CEST] <j-b> jdarnley: but seriously, you should look at gitlab and what we do with dav1d. It's very sane (and saner than github) [17:54:27 CEST] <cone-741> ffmpeg 03Zhao Zhili 07master:971c890c056d: avfilter/formats: remove unnecessary unreference [17:56:05 CEST] <durandal11707> jdarnley: what you forgot to check? [17:56:10 CEST] <jdarnley> vdd [17:57:09 CEST] <j-b> mail incoming tonight [18:05:13 CEST] <durandal_1707> no more ac4 samples appeared in wild? [18:05:51 CEST] <kierank> thankfully no [18:06:00 CEST] <kierank> I think you can ask french people with dvb-t2 card to capture some [18:06:16 CEST] <durandal_1707> alrady done, not much useful [18:06:41 CEST] <durandal_1707> i need full reference suite [18:06:51 CEST] <durandal_1707> otherwise decoder will not be complete [18:07:08 CEST] <kierank> I was at dolby office this morning [18:07:08 CEST] <durandal_1707> and its ten times more complicated than ac3 [18:07:11 CEST] <kierank> should have asked [18:08:37 CEST] <j-b> durandal_1707: I will have some very soon. [18:08:43 CEST] <j-b> (matter of weeks) [18:08:55 CEST] <j-b> and might have a dolby decoder. [18:25:15 CEST] <Lynne> michaelni: you pulled me into this drama [18:26:01 CEST] <Lynne> you made everyone hate me because you either intentionally or unintentionally kept talking about non-technical things like my tone [18:26:28 CEST] <Lynne> and you ignored me, along with all my opinions, questions, and requests [18:26:35 CEST] <Lynne> the drama is all your fault [18:26:53 CEST] <Lynne> and you're doing nothing to fix it by once again saying "can't we all get along?" [18:27:04 CEST] <Lynne> we can't get along until I get an apology! [19:04:51 CEST] <BtbN> Shouldn't this also be operating in c, not priv_data? https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/encode_video.c#L1… [19:05:51 CEST] <BtbN> It should also find private options if you call it on the main ctx? [20:06:13 CEST] <durandal_1707> michaelni: please apologize to Lynne [20:30:21 CEST] <Compn> Lynne, michaelni is doing smart thing by ignoring non-technical matters [20:30:35 CEST] <Compn> Lynne, it would be smart if you did the same [20:33:36 CEST] <Compn> Lynne, also I suggest for you to seek some mental health evaluation. you seem obsessed with michael and it is not healthy. [20:37:50 CEST] <Lynne> Compn: I'm also human and I'd like to be treated as such [20:38:24 CEST] <Lynne> wouldn't you apologize if you accidently caused someone to fall on the street? [20:40:54 CEST] <Lynne> honestly, I find it offensive that you're suggesting I'm somewhat mentally fixated on what you think is some frivolous apology I'm asking for [20:41:44 CEST] <Lynne> ignoring is how this all got started [20:48:32 CEST] <Compn> there is no "this" and no one owes you anything. [20:49:09 CEST] <durandal_1707> i will just ban Compn [20:49:35 CEST] <durandal_1707> Lynne: do you know which algortihm speex use for its noise suppression? [22:10:28 CEST] <Lynne> durandal_1707: LPC to detect the period, some heuristics to make sure its lowere freq than speech, then a filter at that period to remove the noise [22:10:41 CEST] <Lynne> I can't imagine it using anything else [22:33:41 CEST] <durandal_1707> i reviewed bunch of patches! and nobody reviews my patches! nicely done! keep going folks! [00:00:00 CEST] --- Wed Oct 9 2019

1 0

ffmpeg.log.20191008
by burek 09 Oct '19

09 Oct '19

[04:51:56 CEST] <transhuman> hi! whats the magic command to convert .mp4 file to mpg losslessly (best quality) [04:52:14 CEST] <transhuman> conversion comes out real lousy [04:54:41 CEST] <nicolas17> mpg = MPEG1? [04:56:42 CEST] <nicolas17> you won't get lossless, you might get reasonable quality by using a much higher bitrate than the mp4 uses [04:56:59 CEST] <Ultima> Correct me if i'm wrong, but converting crappy quality to a better quality format is still going to be crappy. The source needs to be good to have good quality. [04:57:25 CEST] <transhuman> thanks I figured it out , both of you were right [04:59:31 CEST] <transhuman> one last question is there an ffmpeg command to take a video of a pan of an area and stitch together one large high resolution image? [04:59:59 CEST] <transhuman> I can do this in windows with REgiStax [05:56:03 CEST] <xtemp09> guys, why does FFMPEG keeps copying an unsupported codec, while I deliberately are trying to get rid of it using -map -0:1? [06:33:16 CEST] <Media_Thor> xtemp09: do you have a pastebin url? [06:53:53 CEST] <xtemp09> Media_Thor, it seems to be chapters. [06:54:21 CEST] <xtemp09> ffprobe -show_streams -show _format shows something like chapters/ [06:54:58 CEST] <xtemp09> though, I don't unerstand why ffmpeg keeps copying them even if I set -map -0:1. [06:55:28 CEST] <xtemp09> and why does it show them as a stream, while it's not supposed to like like a stream. [06:55:53 CEST] <xtemp09> though, FFMPEG says when muxing: "Unsupported codec with id 100359 for input stream" [10:32:23 CEST] <alexpacio_> Hello there. I just tried to capture my desktop on Windows 10 using DirectShow filters but, whatever I'm going to use, I'm always stuck at 20fps. No bottlenecks, I also tried with many encoders and formats on transcoding procedure. My output is a network flow (rtsp, native udp or tcp) [10:32:52 CEST] <alexpacio_> Do you know if is it feasible to obtain 60fps on 1080p from a desktop capture? [10:34:09 CEST] <BtbN> You must have installed some 3rd party tool for dshow to capture the desktop, and I'd blame that for a cap at clean 20 fps. [10:35:56 CEST] <alexpacio_> BtbN: yes, also tried with gdigrab but results are even worse. Can you recommend me a directshow filter that is able to obtain 60fps? [10:36:22 CEST] <BtbN> no [10:36:34 CEST] <BtbN> I'd say just use OBS [10:37:44 CEST] <alexpacio_> BtbN: OBS is able to obtain very easily 60fps but it does introduce a huge latency. I need to stream the desktop in realtime in order to manage my desktop from far [10:38:05 CEST] <BtbN> I'm not aware of OBS introducing "huge latency". [10:38:27 CEST] <BtbN> Most streams have just a few seconds. [10:39:39 CEST] <alexpacio_> BtbN: I'm trying to obtain something that gives me back display at near 200-300ms of delay max [10:39:51 CEST] <alexpacio_> do you mean it is possible with OBS? [10:40:02 CEST] <BtbN> You're gonna have to write custom software for that. Neither obs nor ffmpeg are written with real time in mind. [10:41:09 CEST] <BtbN> The video encoder alone easily introduces more latency than that, due to reorder delay and look-ahead buffering. [12:32:33 CEST] <lokke> [ot] - hello world - is anyone of you guys able to tell me if (and if yes then how) i can add the information to a .mp3 file if it is comming from a ablum; EP; maxi; single etc.? [12:32:50 CEST] <lokke> album* [12:36:28 CEST] <DHE> id3 tag editor? [12:37:49 CEST] <lokke> DHE: but into wich field? could not find a standart for it [12:40:38 CEST] <pink_mist> there probably isn't a standard field for that [12:40:43 CEST] <pink_mist> I don't know though [14:58:11 CEST] <kepstin> for what it's worth, musicbrainz picard puts it in a TXXX tag in mp3, look for "release type" in https://picard.musicbrainz.org/docs/mappings/ [14:59:05 CEST] <kepstin> so yeah, no standard field [14:59:38 CEST] <void09> any way to count the visible visual glitches in a video caused by corrupted stream ? [15:03:41 CEST] <DHE> if the stream is obviously corrupted there should be log messages, usually prefixed with something like [h264 @ 0x12345678] so you can count those [18:01:54 CEST] <jpb> hi - i've written up a how to on using xstack for making video mosaics and would like to add it to the wiki. [18:02:32 CEST] <jpb> would someone be willing to critique it for me, to make sure my terminology and usage is correct? [18:03:00 CEST] <durandal11707> jpb: anybody that with unbanned mail can edit wiki [18:03:39 CEST] <jpb> i already have an account there and i've been using the sandbox. i'm now ready to put it on the wiki page [18:05:10 CEST] <jpb> it will take me a bit to finish it off, and i'll post it after that. [18:05:31 CEST] <klaxa> cool, good stuff! [18:15:41 CEST] <MrSassyPants> ok with the new hevc_nvenc how do I clamp the bitrate in VBR [18:15:49 CEST] <MrSassyPants> as in, max-rate, max bitrate, whatever [18:16:54 CEST] <BtbN> What do you mean, "new hevc_nvenc"? And it takes pretty much the same parameters h264_nvenv does, except for some minor codec specific differences. [18:19:13 CEST] <MrSassyPants> well probably not as new as it is to me [18:21:13 CEST] <MrSassyPants> it's for OBS. obs has a gui that lets you set things like bitrate and "encoder settings", for example "cq=23 rc-lookahead=32 nonref_p=1" [18:21:47 CEST] <MrSassyPants> but because the hevc_nvenc stuff is jank AF, it doesn't have an explicit gui for it, just the generic "via ffmpeg" gui [18:22:10 CEST] <MrSassyPants> so I assumed the encoder settings would allow me to set a max bitrate [18:22:16 CEST] <MrSassyPants> but I have not found the setting [18:22:32 CEST] <MrSassyPants> its not max-bitrate or maxrate [18:23:19 CEST] <MrSassyPants> ffmpeg -h encoder=hevc_nvenc doesn't mention anything bitrate wise, beyond the switch to set it to VBR [18:26:48 CEST] <kepstin> the vbv controls are all done via generic encoding options, so they don't show up in the encoder-specific help [18:27:26 CEST] <MrSassyPants> I tried "max-rate" and such in the "muxer settings" field [18:27:32 CEST] <MrSassyPants> didn't work either [18:29:50 CEST] <MrSassyPants> is there some way to get at these generic encoding options [18:29:55 CEST] <MrSassyPants> from within obs [18:30:02 CEST] <kepstin> hmm. the ffmpeg cli options for that are -maxrate and -bufsize (usually both are needed), but i don't know what names obs will use for those [18:30:23 CEST] <MrSassyPants> It's probably not using the cli [18:32:23 CEST] <kepstin> i just checked, the option names for avoptions are "maxrate" and "bufsize", those should work in obs [18:32:46 CEST] <kepstin> note that maxrate on its own without bufsize is meaningless with most encoders (i dunno about nvenc specifically) [18:33:01 CEST] <MrSassyPants> noted [18:34:03 CEST] <MrSassyPants> Either option does not seem to be recognized by the encoder settings [18:34:24 CEST] <kepstin> what causes you to think that? [18:34:38 CEST] <MrSassyPants> Failed to set maxrate=50000 [18:34:42 CEST] <MrSassyPants> Failed to set bufsize=128000 [18:34:55 CEST] <MrSassyPants> recording proceeds regardless [18:35:11 CEST] <MrSassyPants> but I'm not even going to test for actual impact on bitrates [18:35:19 CEST] <kepstin> huh, weird. those are avoptions that should work on the avcodeccontext. no idea what's going wrong, you're gonna have to talk to obs folks about how to set those [18:35:33 CEST] <MrSassyPants> it's probably not the right context? [18:36:17 CEST] <kepstin> obs might have dedicated fields in its settings for maxrate and buffer size [18:36:26 CEST] <kepstin> if it does, use those rather than manually specifying the options [18:36:40 CEST] <MrSassyPants> I get the same error, except with "invalid muxer settings" if I add that to the "muxer settings" [18:38:04 CEST] <kepstin> muxer is obviously wrong, they're codec settings. you're gonna need to get help from the obs folks, this is kind of out of scope for ffmpeg support. [18:38:05 CEST] <BtbN> well, it's not a muxer setting. [18:38:26 CEST] <kepstin> we know the options to set, we know where to set them, we don't know how to make obs set them. [18:38:27 CEST] <BtbN> I feel like OBS sets the avoptions on the wrong context, so it only recognizes the codec own ones [18:38:28 CEST] <MrSassyPants> it would be "ffmpeg gets those on the cli" settings but obs doesn't have that [18:38:40 CEST] <MrSassyPants> I think that's the case, BtbN [18:39:06 CEST] <MrSassyPants> And it only allows for a "rate" option (-b:v I suppose) but not -maxrate or -bufsize [18:39:55 CEST] <kepstin> they should be setting the options as AVOption on the AVCodecContext for the encoder, which would mean the generic AVOption stuff for codec-independent options would work. I dunno how they'd get that wrong :/ [18:47:12 CEST] <BtbN> found the function: https://github.com/obsproject/obs-studio/blob/master/plugins/obs-ffmpeg/obs… [18:47:19 CEST] <BtbN> av_opt_set(context->priv_data, name, value, 0) [18:47:28 CEST] <BtbN> so yeah... only codec-private options are gonna work [18:50:51 CEST] <transhuman> so for anyone who is interested. I found a good solution for stitching a video of images together in a large hires image, not sure how good it works yet (still trying it out) but its called AviStack2 it pretty much automates the process, but using a good camera that's high res with like 80 frames a second and a tripod with slow steady motion gets best results [18:51:11 CEST] <transhuman> for taking images of space at least [18:53:53 CEST] <MrSassyPants> BtbN, so can I trick the codec into setting a max rate? [18:54:07 CEST] <BtbN> no [18:54:24 CEST] <BtbN> You set the apropiate option. If OBS does not expose it, it can't be set. [18:54:48 CEST] <MrSassyPants> worst of all I got a custom cobbled together version of OBS too [18:54:55 CEST] <DHE> you should still be able to set standard values like "maxrate" as they're exposed generically by the options layer [18:55:03 CEST] <MrSassyPants> DHE, doesn't work [18:55:11 CEST] <BtbN> DHE, see https://github.com/obsproject/obs-studio/blob/master/plugins/obs-ffmpeg/obs… [18:55:25 CEST] <BtbN> they are for some reason calling ac_opt_set on priv_data. So no global options... [18:55:42 CEST] <MrSassyPants> you can set "rate" as in -b:v [18:55:42 CEST] <DHE> oh geez... [18:55:50 CEST] <MrSassyPants> per a gui thing [18:56:14 CEST] <DHE> maybe C++ has it right with "private" fields... [18:56:33 CEST] <BtbN> Just open a bug with them. [18:56:35 CEST] <MrSassyPants> but I'd rather define a maxrate (so my HDD doesn't get overloaded when recording explosions) and rely on ABR or target constquality or whatevs [18:56:50 CEST] <BtbN> If I'm not missing something, all that's needed to fix it is to remove the "->priv_data" there. [18:56:57 CEST] <MrSassyPants> the bug is essentially that hevc_nvenc is not yet considered a supported codec [18:57:15 CEST] <BtbN> No, the bug is that they use a private field. [18:57:21 CEST] <MrSassyPants> I have to access it through the generic option on a specifically cobbled together custom obs [18:57:39 CEST] <MrSassyPants> well can one of you guys open that? I'm way out of my field there [18:57:42 CEST] <BtbN> OBS can't sensibly support HEVC, as rtmp does not support it. So you can't stream it. Nothing would be able to play it either. [18:57:59 CEST] <MrSassyPants> and explaining "you shouldn't be using this function, you should be using that function" is also much better if you're doing it o_o [18:58:21 CEST] <BtbN> They don't appear to have an issue tracker on GitHub anymore [18:58:41 CEST] <MrSassyPants> most browsers don't support HEVC, streaming it doesn't make much sense at this point, twitch doesn't support it... [18:58:50 CEST] <MrSassyPants> It's great for recording though [18:59:18 CEST] <MrSassyPants> as in, recording high quality footage in parallel (or in stead) of streaming, editing/uploading that later [18:59:33 CEST] <BtbN> Does it even have any benefits? nvenc can't be that much better at hevc than h264 [18:59:52 CEST] <MrSassyPants> because the limiting factor is literally the hard drive bandwidth, when lots of explosions are going on, the 5400rpm HDD gets overloaded [19:00:10 CEST] <MrSassyPants> so I gotta write to the SSD, BUT if I record like 50gb of stuff a day, that's going to wear down the SSD [19:00:40 CEST] <BtbN> Your HDD can't sustain 50~100Mbit/s? [19:00:48 CEST] <MrSassyPants> it can sustain 50-100mbit [19:01:04 CEST] <MrSassyPants> high quality 4k footage with explosions exceeds that [19:01:12 CEST] <BtbN> 4K... [19:01:16 CEST] <MrSassyPants> exceeds 50-100mBYTE [19:01:22 CEST] <BtbN> I highly doubt that [19:01:38 CEST] <BtbN> Why would 4 times the pixels need 8 times the bandwidth? [19:01:40 CEST] Action: kepstin notes that on a 500gb ssd, 50gb/day is 0.1 drive writes per day, which is within spec for most consumer ssds [19:02:02 CEST] <MrSassyPants> twitch allows CBR 6mbyte/s at 1080p@60fps [19:02:07 CEST] <MrSassyPants> it looks like ass [19:02:17 CEST] <MrSassyPants> even with the highest quality encodery [19:02:22 CEST] <BtbN> 6 Mbit [19:02:26 CEST] <BtbN> per second [19:02:28 CEST] <MrSassyPants> mBYTE [19:02:29 CEST] <BtbN> no [19:02:44 CEST] <MrSassyPants> I'm uploading to twitch daily these days [19:02:47 CEST] <kepstin> https://stream.twitch.tv/encoding/ says 6000 kbps [19:02:53 CEST] <BtbN> You are still getting bits and bytes confused. [19:02:58 CEST] <MrSassyPants> yeah they mean 6 megabyte per second [19:03:00 CEST] <kepstin> kbps = kilo-bits per second [19:03:02 CEST] <BtbN> no they don't [19:03:21 CEST] <BtbN> a 6MByte/s stream would be slightly insane, that's like 500 Mbit or so [19:03:35 CEST] <BtbN> *50 [19:03:53 CEST] <MrSassyPants> ok maybe [19:04:09 CEST] <MrSassyPants> Anyhow I found the problem to be the hard drive bandwidth [19:04:20 CEST] <kepstin> MrSassyPants: for historical reasons, all codec bitrates are measured in bits [19:04:24 CEST] <MrSassyPants> ok [19:04:34 CEST] <MrSassyPants> yeah you're right [19:04:37 CEST] <MrSassyPants> it's 6mbit [19:05:01 CEST] <furq> if your hard drive can't sustain 50mbps then it's probably failing really badly [19:05:06 CEST] <furq> or you're writing other stuff to it at the same time [19:05:08 CEST] <MrSassyPants> anyhow, the write buffer obs/ffmpeg uses is very small [19:05:17 CEST] <MrSassyPants> and nvenc is still jank [19:05:35 CEST] <MrSassyPants> high bitrates cause frame loss [19:05:51 CEST] <kepstin> note that about the highest bitrate i've seen is ultra-hd bluray, which maxes out at around 100mbit/s with all streams combined. [19:06:13 CEST] <MrSassyPants> it works on the SSD (for muc higher bitrates) but when I found myself uploading 60gb in one day I decided I need to stop wearing it down [19:06:29 CEST] <BtbN> 60gb a day is pretty much nothing for an SSD [19:06:52 CEST] <MrSassyPants> the "omg the SSD is gonna wear down if you write 20gb a day for a year" thing people used to be afraid of [19:06:57 CEST] <kepstin> (100mbit/s is around 12mbyte/s, which will leave a 5400 rpm hard drive mostly idle when doing linear writes) [19:07:00 CEST] <MrSassyPants> because nobody actually writes 20gb to a drive every day [19:07:07 CEST] <furq> it depends how cheap the ssd is really [19:07:24 CEST] <furq> those new cheapo qlc ssds last a lot less long [19:07:30 CEST] <MrSassyPants> kepstin, yes, it shouldn't bother the HDD, but somebody forgot to set a write buffer [19:07:58 CEST] <MrSassyPants> additional information [19:08:05 CEST] <MrSassyPants> it's also an encrypted drive? [19:08:11 CEST] <kepstin> MrSassyPants: you honestly shouldn't need to, the os should be buffering those writes :/ [19:08:12 CEST] <MrSassyPants> as in dm-crypt [19:08:16 CEST] <furq> could be cpu overhead then [19:08:23 CEST] <kepstin> what os? [19:08:29 CEST] <furq> if it happens when your game gets overly busy [19:08:33 CEST] <MrSassyPants> kepstin, it should, but in this case we're talking nvenc, which probably does weird things [19:08:55 CEST] <MrSassyPants> like straight from asic to memory via pci-e or something [19:09:26 CEST] <MrSassyPants> It's jank AF and obs barely knows what they're doing either [19:10:25 CEST] <MrSassyPants> and hevc is not high on their priority list [19:10:41 CEST] <MrSassyPants> because it's not really a web streaming encoding [19:13:56 CEST] <BtbN> There is zero difference for obs and ffmpeg if the packets are coming from h264_nvenc or hevc_nvenc. Or libx264. It works the exact same for all of them. [19:14:15 CEST] <MrSassyPants> I'm not sure that's true [19:14:33 CEST] <BtbN> If you say so... [19:14:53 CEST] <BtbN> They both output bitstream in system ram. And the same muxer code generates what's written to disk from it. [19:14:58 CEST] <MrSassyPants> I mean for starters, obs actually supports h264_nvenc and libx264 [19:15:22 CEST] <BtbN> That only means it has hardcoded option-mappings for them, nothing more. [19:15:23 CEST] <MrSassyPants> while for hevc_nvenc I have to use the generic custom option [19:16:53 CEST] <MrSassyPants> I had a mysterious problem at high (constant quality/variable bitrate) settings with hevc, recordings would turn into white mosaics periodically, and it seemed to get worse the higher the quality/bitrate went [19:17:33 CEST] <MrSassyPants> Someone had the idea it was hdd write lag breaking the stream somehow and thus I tried on the SSD and there it didn't happen [19:17:45 CEST] <MrSassyPants> jank [19:18:06 CEST] <MrSassyPants> but a (working) maxbitrate setting would almost certainly be preferrable [19:20:49 CEST] <kepstin> if you've got other things doing io on the hdd that could cause issues, sure [19:21:06 CEST] <kepstin> any sort of mixed io causes hdd performance to absolutely plummet. [19:21:30 CEST] <jpb> ok, done - comments, criticism welcome (flames to /dev/null, plz) : https://trac.ffmpeg.org/wiki/Create%20a%20mosaic%20out%20of%20several%20inp… [19:25:50 CEST] <kepstin> heh, that reminds me, i was planning to make an automatic video mosaic filter at some point (you just give it N inputs and an output video size, and it scales and fits them automatically). I should finish that at some point... [19:28:13 CEST] <a90c> hi is there a way to extract .srt file from mp4? [19:32:01 CEST] <kepstin> a90c: if the mp4 file contains text subtitles in a format that ffmpeg understands, it should be as simple as "ffmpeg -i input.mp4 output.srt" [19:32:19 CEST] <kepstin> (you may need to use additional options to select the correct stream if there are multiple) [19:32:39 CEST] <jpb> kepstin: i'd be happy to write that up as well ;-) [19:35:17 CEST] <a90c> kepstin: yes i tried it. i guess its format that ffmpeg could not understand. [19:35:56 CEST] <phobosoph> ffmpeg is awesome! it can do so much more than mpeg, its name is due to historical reasons,rgith? [19:40:04 CEST] <kepstin> a90c: if you could pastebin the console output of "ffmpeg -i file.mp4" for your file, we might be able to help more. [19:40:16 CEST] <a90c> ok [20:26:32 CEST] <norbert> hi folks, question: I use -threads 2 but noticed the CPU usage is still going to around 350%; is this intended behavior? or perhaps I should use another command-line parameter? [20:30:27 CEST] <norbert> (this is when mp4 transcoding) [20:30:57 CEST] <furq> -threads is specific to one input or output [20:31:14 CEST] <furq> so if you set it as an output option then any decoding and filtering aren't constrained by it [20:33:58 CEST] <norbert> furq: do you mean I'd need to use something like "ffmpeg -threads 1 -i in.avi -threads 1 out.mp4" to get 2 threads? (1 for in, 1 for out) [20:37:21 CEST] <norbert> I'm using it after -i, so for the output, which according to https://superuser.com/questions/792525/how-to-change-ffmpeg-threads-setting… is correct [20:37:28 CEST] <norbert> strange that the input would cause such high CPU loads [20:42:15 CEST] <kepstin> norbert: note that if you want to limit cpu usage you should do so using something external to ffmpeg, e.g. cpu affinity mask or cgroup cpu quota [20:44:08 CEST] <norbert> ok, I see [20:44:56 CEST] <norbert> like "cpulimit -l 50 ffmpeg ..." [20:45:06 CEST] <norbert> and then get rid of the -treads I previously used [20:46:02 CEST] <kepstin> it probably still makes sense to use a -threads option (probably around the same as the number of threads you're making available to ffmpeg) since the auto-detection might try to match the number of cpus in your system, which could mean there's too many threads. [20:46:45 CEST] <kepstin> (and stuff that doesn't use autodetection, like libvpx, won't be multithreaded at all unless you have a -threads option) [20:46:59 CEST] <norbert> ok [20:49:14 CEST] <furq> -threads is advisory when you're using an external library for encoding anyway [20:49:23 CEST] <furq> what that library does with it is up to the library [20:49:41 CEST] <furq> e.g. x264 will use extra threads for lookahead [20:51:33 CEST] <kepstin> i don't think the 'cpulimit' tool will really do what you want, it looks like it's designed in the days of single-cpu systems and it doesn't make use of any kernel features for cpu control (it just sends sigstop/sigconf to the process) [20:51:40 CEST] Action: kepstin would not recommend using it [20:52:47 CEST] <norbert> kepstin: hm [20:53:56 CEST] <norbert> "nice" then? [20:55:23 CEST] <norbert> are you sure cpulimit isn't suitable, it's mentioned a lot on sites such as stackexchange [20:58:20 CEST] <kepstin> cpulimit probably works ok on single-threaded processes, i guess. [20:58:59 CEST] <DHE> there's cpu throttling in the `cpu` cgroup on linux [20:59:43 CEST] <DHE> if you need to throttle a single-threaded application [20:59:43 CEST] <DHE> like, even when the CPU is idle you want it to sleep a lot [20:59:43 CEST] <kepstin> repeating myself, my suggestions were either to use a cpu affinity mask or cgroup cpu quota [21:01:17 CEST] <kepstin> the former will limit cpu usage by only allowing the process to run on a set number of cpu threads, which works well for "limit to 200%" case; the later lets you tell the cpu scheduler how much cpu time the process is allowed to execute. [21:05:10 CEST] <norbert> a CPU affinity mask would require me to write a C program? [21:05:18 CEST] <norbert> I'm calling ffmpeg from PHP [21:06:38 CEST] <norbert> I feel inclined to simply use "nice -19 ffmpeg ..." instead of trying to limit CPU usage [21:07:45 CEST] <kepstin> is this a cli tool? a web service? what else is running on the system that makes you want to limit ffmpeg cpu usage anyways? [21:10:00 CEST] <norbert> it's a LAMP-like system, so I want Apache and such to keep serving pages quickly while ffmpeg does its job in the background [21:10:40 CEST] <norbert> the PHP file that calls ffmpeg is a simple encode.php script [21:11:12 CEST] <norbert> (well, 'simple', it's not something I can convert to something else easily) [21:12:52 CEST] <kepstin> sounds like you should be using a background jobs queue, then you could do something like apply cpu limits in the systemd service that starts the queue worker [21:13:04 CEST] <kepstin> pretty straightforwards then. [21:13:25 CEST] <norbert> I don't know anything about systemd [21:13:50 CEST] <norbert> it is a queue, and there's a cronjob checking if transcoding is necessary [21:32:23 CEST] <Retal> Hello guys, I have transcode command: [21:32:23 CEST] <Retal> ffmpeg -hwaccel cuvid -c:v mpeg2_cuvid -i INPUT -vf hwdownload,format=nv12,hwupload_cuda -preset fast -acodec aac -ar 44100 -ac 2 -b:a 96k -vcodec h264_nvenc -b:v 3500k -maxrate 5000k -bufsize 7000k -g 150 -qmin 1 -qmax 50 -f flv OUT [21:32:23 CEST] <Retal> When i addin deinterlace command -vf yadif, transoding doesn't start [21:37:22 CEST] <kepstin> Retal: please share the complete failing command and the console output [21:38:04 CEST] <kepstin> but I can probably guess the issue - you can only have one video filter pipeline, so if you add a second -vf it overwrites the previous one [21:38:41 CEST] <kepstin> you need to add the yadif filter inside your existing -vf option (and at a point where the video frames are in system memory) [21:42:50 CEST] <Retal> kepstin: https://pastebin.com/prD8dkPn [21:43:16 CEST] <kepstin> yep, exactly as i thought. [21:44:06 CEST] <Retal> so it shuld be like : -vf yadif,hwdownload,format=nv12,hwupload_cuda ? [21:47:00 CEST] <Retal> tryed, doesnt work [21:52:31 CEST] <Kobaz> so i'm trying to convert wmv to 264 ffmpeg -i 9995.16954.1570326624.77208.1.wmv -c:v libx264 output.mp4 [21:52:46 CEST] <Kobaz> the wmv plays fine... the resulting mp4/264 is really choppy [21:53:06 CEST] <Kobaz> like it'll freeze at 6 seconds, 9 seconds, the video just stops for a bit and then resumes [21:57:34 CEST] <kepstin> Retal: repeating myself "a point where the video frames are in system memory" [21:57:50 CEST] <kepstin> Retal: so after the hwdownload filter, since that's the filter that downloads frames to system memory [22:00:24 CEST] <Retal> kepstin: thank you so much, it works! [22:12:02 CEST] <Retal> guys what mean -g 150? [22:20:12 CEST] <kepstin> Retal: it's documented here: https://www.ffmpeg.org/ffmpeg-codecs.html#Codec-Options - sets the GOP size [22:20:23 CEST] <kepstin> (roughly, keyframe interval) [22:26:57 CEST] <Retal> kepstin: in my command i have -g150, when i remove it i think trascoding quality is better, but maybe i am wrong [22:28:02 CEST] <kepstin> Retal: i have no idea what the default is with nvenc. But in general, when you're encoding with bitrate then having a longer keyframe interval will increase quality [22:28:25 CEST] <kepstin> because keyframes are big (use lots of bit), having fewer of them means more bits for other stuff [22:29:33 CEST] <kepstin> but having longer keyframe interval means seeking in the file is slower, and recovery from errors (e.g. lost frame when streaming) takes longer. [22:29:37 CEST] <Retal> kepstin: thank you [22:41:45 CEST] <auser0> i have a string that has a dict in it and named x = [{'number': '717*****, 'name': 'Ed Mxxxx', 'flat': 7, 'street': 'Whxxxx'}] , i want to get the x['name'] without the Mxxx part, how can i do this? [22:42:00 CEST] <auser0> oh wrong channel [22:42:18 CEST] <kepstin> i was gonna say... :) [22:42:32 CEST] <auser0> sure :) [22:42:34 CEST] <auser0> how haha? [22:43:02 CEST] <kepstin> auser0: btw, don't split peoples names on whitespace, it's not uncommon for people to be referred to by multiple names in normal speech. [22:43:48 CEST] <auser0> ya i agree [22:46:41 CEST] <norbert> well, thanks for all the info; gotta go [22:46:44 CEST] <norbert> :) [00:00:00 CEST] --- Wed Oct 9 2019

1 0

ffmpeg-devel.log.20191007
by burek 08 Oct '19

08 Oct '19

[10:53:45 CEST] <j-b> 'morning [11:01:16 CEST] <durandal_1707> good day [11:03:05 CEST] <xtemp09> guys, I'd like to make FLAC multithreaded. is there a FFMPEG guide to figure out its source? [11:03:15 CEST] <durandal_1707> no [11:03:37 CEST] <xtemp09> so far i see that it's written in C, is it alright if I contribute in C++14? [11:04:27 CEST] <xtemp09> people use the latest GCC to compile FFMPEG. [11:04:47 CEST] <durandal_1707> only C [11:05:04 CEST] <xtemp09> durandal_1707, what C? [11:05:09 CEST] <xtemp09> *which [11:05:42 CEST] <J_Darnley> c89 except for some select c99 features [11:05:57 CEST] <xtemp09> thanks [11:06:25 CEST] <xtemp09> so far I see, one of the select features is inline. [11:06:51 CEST] <J_Darnley> What's the struct features? designated initializers? [11:16:12 CEST] <cone-571> ffmpeg 03Paul B Mahol 07master:5b4010e88686: avfilter/vf_nnedi: fix possible double free [11:39:11 CEST] <cone-571> ffmpeg 03Paul B Mahol 07master:0c4137bcb742: avfilter/af_afftfilt: fix possible invalid memory access [11:40:45 CEST] <BtbN> Why does he open a ticket on our tracker, and then continues to point out it's not our bug? [12:08:47 CEST] <cone-571> ffmpeg 03Paul B Mahol 07master:651a0f63080f: avfilter/vf_showpalette: remove timeline flag [12:20:54 CEST] <cone-571> ffmpeg 03Paul B Mahol 07master:c303d0979fb0: avfilter/vf_normalize: typedef all structs [15:07:22 CEST] <Lynne> jamrial: for ignoring me, accusing me of being aggressive to dodge any of my questions, then when I finally lost it made fun of me [15:07:43 CEST] <Lynne> how is aggravating someone to this level considered okay? [15:07:53 CEST] <Lynne> why am I the guilty one for responding to troll answers that I had no choice but respond to because I cared at one point about the project? [15:08:24 CEST] <jamrial> i have never seen him make fun of anyone. you may have misread his reply... [15:09:09 CEST] <Lynne> he did it either not intentionally or very intentionally in a way that made me guilt of everything [15:10:16 CEST] <Lynne> I can't even do anything, he'll say "its your fault for getting angry (haha)" and everyone will support him [15:58:32 CEST] <talih0> rcombs: hello, I saw that you author of libavformat/chromaprint.c [15:58:51 CEST] <talih0> :rcombs Can you review my patches? http://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/251055.html [17:30:00 CEST] <cone-571> ffmpeg 03Paul B Mahol 07master:9a53e0125290: avfilter/formats: guard against double free [18:11:30 CEST] <cone-571> ffmpeg 03Paul B Mahol 07master:0633d87ae6e6: avfilter/af_adelay: add option which changes how unset channels are delayed [20:57:37 CEST] <kylophone> 5 [20:57:42 CEST] <durandal_1707> 6 [21:02:14 CEST] <JEEB> * [21:09:45 CEST] <mkver> ? [21:11:10 CEST] <durandal_1707> ! [21:16:53 CEST] <JEEB> was (5 6 *) valid lisp-like? [21:17:21 CEST] <cone-925> ffmpeg 03Andreas Rheinhardt 07master:361fb42e1e53: avcodec/filter: Remove extra '; ' outside of functions [21:45:57 CEST] <cone-925> ffmpeg 03Andriy Gelman 07master:4cb124a800d0: doc/formats: Update documentation for chromaprint [22:02:41 CEST] <Lynne> ...I am being ignored again; aren't I? [22:02:58 CEST] <durandal_1707> Lynne: about what? [22:03:01 CEST] <Lynne> michaelni [22:03:18 CEST] <durandal_1707> i see no new reply/thread [22:03:28 CEST] <durandal_1707> about what specifically? [22:03:55 CEST] <Lynne> an apology [22:04:45 CEST] <Lynne> am I that awful, useless, worthless and not worth dealing with to be outright ignored by someone who's saying he's just another developer and no one special? [22:05:27 CEST] <nevcairiel> honestly by making this huge deal about some off-hand comments, you are as bad as everyone else in the drama circle [22:06:33 CEST] <Lynne> am I really? for falling into a trollish conversation because I had no choice and I cared? [22:07:25 CEST] <durandal_1707> nevcairiel is michaelni best friend [22:07:42 CEST] <Lynne> what about people here? everyone who shared my opinions yet never said anything at all, just eating popcorn and enjoying themselves? [22:08:01 CEST] <nevcairiel> no, i just dislike all this drama nonsene. "I wont send patches unless X apollogizes", what is this, high-school? [22:08:12 CEST] <kierank> Lynne: about fuzzing? [22:08:21 CEST] <kierank> or about insults? [22:08:37 CEST] <durandal_1707> Lynne: you can not expect anything from such *high* entities, they are full of themselfs [22:09:13 CEST] <Lynne> kierank: everything [22:09:34 CEST] <kierank> I think the fuzzing stuff is nowhere near as bad as it used to b [22:09:34 CEST] <kierank> be [22:09:43 CEST] <kierank> but yes private insults we can't really comment on if we don't see them [22:09:52 CEST] <kierank> It's why we need a CoC [22:09:56 CEST] <Lynne> nevcairiel: and what am I supposed to do? just shut up like everyone and deal with it? [22:15:24 CEST] <nevcairiel> from what I remember off-hand, you got offended often by the perceived "tone" of emails, there werent even directly offending statements in them - but what is important here is that some people just don't write perfect english so that they can accurately imply a certain "tone", michael is among those, his mails are more often then not half-broken english, so giving people the benfit of the doubt is a first step towards actually [22:15:24 CEST] <nevcairiel> communicating [22:34:03 CEST] <cone-925> ffmpeg 03Andreas Rheinhardt 07master:69dd8d3a2a3d: avformat/flac_picture: Avoid allocation of AVIOContext [22:34:04 CEST] <cone-925> ffmpeg 03Andreas Rheinhardt 07master:5e546864b093: avcodec/flac_parser: Use native endianness when possible [22:34:05 CEST] <cone-925> ffmpeg 03Andreas Rheinhardt 07master:d03c3e851764: avcodec/flac_parser: Don't allocate array separately [22:34:06 CEST] <cone-925> ffmpeg 03Andreas Rheinhardt 07master:e5e5be4c7f60: avcodec/flac_parser: Fix off-by-one error [22:57:06 CEST] <Lynne> nevcairiel: no, you have this the other way around completely [22:57:40 CEST] <Lynne> michael got offended that I was being aggressive in my emails and made a big deal about how every single email of mine was such [22:57:53 CEST] <Lynne> which meant there was no room for any technical discussion at all [22:58:41 CEST] <Lynne> and I don't meant some, I mean _every_ one of my emails [22:59:06 CEST] <Lynne> that can't be anything but trolling or incredible ignorance [22:59:32 CEST] <durandal_1707> Lynne: ignore michaelni, i will hold your back [22:59:56 CEST] <Lynne> what use is that? michaelni is a "developer", and we're both developers [23:01:22 CEST] <Lynne> ignoring other developers and trolling them to have everyone hate them without consequences isn't something developers like us can do [23:02:30 CEST] <durandal_1707> Lynne: get real, they can do nothing to you, nobody sane hates you [23:02:49 CEST] <JEEB> it sounds like that whole thing needs a reset and if baseless accusations are made then that should be brought up and dealt with :P [23:03:24 CEST] <cone-925> ffmpeg 03Andreas Rheinhardt 07master:047a6d396f69: avcodec/flac_parser: Fix number of buffered headers [23:03:25 CEST] <cone-925> ffmpeg 03Andreas Rheinhardt 07master:a1701e7591e5: avcodec/flac_parser: Remove superfluous checks [23:03:26 CEST] <cone-925> ffmpeg 03Andreas Rheinhardt 07master:87b30f8af8c6: avcodec/flac_parser: Don't modify size of the input buffer [23:03:27 CEST] <cone-925> ffmpeg 03Andreas Rheinhardt 07master:5873feac54da: avcodec/flac_parser: Don't leave stale pointer in memory [23:03:28 CEST] <cone-925> ffmpeg 03Andreas Rheinhardt 07master:1d54309c8ac1: avcodec/flac_parser: Cosmetics [23:08:36 CEST] <durandal_1707> thilo: nothing happened with meeting, as expected... [23:12:02 CEST] <durandal_1707> cehoyos: why you insulted Lynne ? [23:12:14 CEST] <cehoyos> today? [23:12:22 CEST] <durandal_1707> no, before [23:22:49 CEST] <Lynne> durandal_1707: that can be worse than do nothing. how would you like to have all your patches rejected for no good reasons, have code you maintained be altered by another developer who understands nothing without your approval, and your "why"s be answered by "its for the good of the project; you're being aggressive; shut up"? [23:23:13 CEST] <Lynne> wouldn't you feel useless? demotivated? [23:24:19 CEST] <Lynne> JEEB: not like it will turn out any different: "you're being aggressive" with constant attempts to derail the discussion and days of delay [00:00:00 CEST] --- Tue Oct 8 2019

1 0

ffmpeg.log.20191007
by burek 08 Oct '19

08 Oct '19

[01:57:22 CEST] <classsic> Hi, somebody can pointme on error: "Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly" [02:41:32 CEST] <kode54> classsic: are you programming your own ffmpeg libavformat multiplexing? [02:41:43 CEST] <kode54> the transport packets should have timestamps on them [02:42:04 CEST] <kode54> if it's just parsing a file from disk, then it's some sort of legacy format that isn't being read with proper timestamps [02:42:50 CEST] <kode54> (for example, H.264 and similar video streams encode the IBBBBPBBBBPBBB etc sequence really as IPPPPPBBBBBBBBBBBBBI.... etc [02:43:08 CEST] <kode54> then they use container timestamps to detangle the encode/decode order into the playback order [02:43:40 CEST] <kode54> basically, it encodes first the I frame, then all the forward prediction frames, then all the bidirectional prediction frames [07:52:12 CEST] <Tatsh> anyone know why when i add `-f alsa -i hw:1,0` to a command, the video output becomes yuv420p(progressive), where as before it was yuv420p ? [10:54:31 CEST] <termos> hmm I'm having a hard time setting "enable_er" flag on h264 decoding, am I suppose to set it. Tried setting it on the AVOptions for avformat_open_input and av_opt_set_int-ing it on the codec_context->priv_data [15:32:52 CEST] <Randolf> I'm using "ffmpeg -f concat -safe 0 -i files.lst ..." to join a number of .AVI files from my camera, and it's working well. (On the same command line I'm also overlaying a mostly-transparent PNG and a timestamp, which is also working well.) How can I add a half-second-long gap of black silence between each of the videos? Thanks. [15:33:49 CEST] Action: Randolf is using ffmpeg 3.4.6 on Ubuntu Linux 18.04.01 LTS. [15:36:56 CEST] <BtbN> You should update that ffmpeg, it's old. [15:37:19 CEST] <BtbN> Otherwise, create a compatible video clip (exact same codecs and parameters) and put it in between the segments? [15:40:43 CEST] <Randolf> BtbN: Oh, okay. I guess Ubuntu's "apt" system is sorely outdated. I'll bug them about that. [15:41:04 CEST] <BtbN> They won't do any updates, they prefer to be "stable". [15:41:20 CEST] <DHE> if you run a 1.5 year old OS, you get 1.5 year old software packages [15:41:29 CEST] <DHE> doubly so for an LTS branch [15:42:24 CEST] <DHE> (not necessarily a bad thing in general, just be aware of it) [15:42:30 CEST] <Randolf> BtbN: I was reading various options on Google for that, but found none that actually worked. Even generating a .avi or .mp4 using ffmpeg resulted in a video clip that isn't compatible with the .AVI files my camera created (lots of errors show up on the screen when I try to include this in my files.lst file), so I'll just have to create the black video clip with my camera. [15:43:02 CEST] <Randolf> DHE: That makes sense. [15:43:13 CEST] <BtbN> That'd probably be the easiest option. Put the cap on, mute the mic, and record for a few seconds. [15:43:24 CEST] <Randolf> BtbN: Yup. [15:46:40 CEST] <Randolf> Thanks for all your help everyone. [17:32:08 CEST] <giaco> hello [17:32:59 CEST] <giaco> I need some help to workaround TCP h264 client issues [17:35:30 CEST] <giaco> i have a TCP stream at http://192.168.0.1/videostream.asf, I can successfully play it with ffplay, but after a while the client stops receiving any data and the image freeze [17:35:51 CEST] <giaco> Client (ffmpeg) doesn't complain and wait endlessly [17:36:16 CEST] <giaco> if I stop and restart ffplay it streams correctly for some more time, then problem repeats [17:37:07 CEST] <giaco> what's the problem? TCP? Streaming server? HTTP? Client? How can I profile and workaround this? [17:40:19 CEST] <kepstin> hard to say without any other details or logs, but the issue is probably that the server just stopped sending data, but without actually closing the connection (otherwise ffplay would have exited) [17:45:36 CEST] <kepstin> could also possibly be a clock desync issue. i forget whether ffplay has a mode to display video as fast as its received rather than retime it to the local clock. [17:47:04 CEST] <kepstin> consider using mpv with the --untimed option [17:48:20 CEST] <kepstin> (if the stream has audio, you might also need one of the --video-sync display-* options) [18:22:49 CEST] <InTheWings> Lavc58.42.100 throws "[vc1 @ 0x61b0000bd080] Failed to open codec in avformat_find_stream_info" for every raw VC-1 samples. Was not happening with Lavf58.20.100 [18:23:46 CEST] <InTheWings> example https://streams.videolan.org/samples/archive/all/vc1%2Bvc1%2B%2B%2Bartifact… [18:25:49 CEST] <kepstin> huh, that's weird. despite the message it still plays in ffplay. [18:43:43 CEST] <InTheWings> seems it was parsing extradata earlier, not it's late [18:46:08 CEST] <InTheWings> codec starts now with invalid state (no extradata) when using libaformat. Unsure if there's a way to get the parameters update [18:46:17 CEST] <shreds> Hi! I've been using ffmpeg for a while for various projects in the past but now I'm stuck on something. I have a crappy server serving video over m3u8. I can dump it to mp4 totally fine but after a few minutes FFMPEG says "ffmpeg EOF on sink link / No more output streams to write to, finishing." and stops normally. The thing is, the stream shouldn't end. I guess it's because of a crappy connection or something. My [18:46:18 CEST] <shreds> question is: is there any way of adding a timeout so FFMPEG can wait until the video output works again? [18:48:20 CEST] <shreds> here's an example of commands I send to ffmpeg: ffmpeg -v trace -i https://live_feed.com/chunklist_b2592000.m3u8 -movflags frag_keyframe+empty_moov -f mp4 test_file.mp4 [18:52:50 CEST] <shreds> I'm trying -timeout at the moment [19:02:14 CEST] <giaco> kepstin: thanks for the answer [19:10:16 CEST] <BtbN> shreds, the server is signalling that the stream ended it seems [19:10:34 CEST] <BtbN> also, why are you re-encoding without specifiying any parameters on the codecs? [19:11:11 CEST] <shreds> i just want to copy whatever source uses [19:11:15 CEST] <shreds> I just found out about -reconnect -reconnect_at_eof -reconnect_streamed and -reconnect_max trying these out atm [19:11:27 CEST] <BtbN> Well, then tell it to just copy the streams? [19:11:28 CEST] <kepstin> shreds: if you want to copy, you explicitly have to tell ffmpeg to do so [19:11:37 CEST] <shreds> I added -c:v copy -c:a copy [19:11:43 CEST] <BtbN> Just use -c copy [19:11:55 CEST] <shreds> ok -c copy will be enough for both audio and video? [19:12:15 CEST] <BtbN> The whole point of it is that it affects everything. [19:12:16 CEST] <furq> -c with no stream specifier applies to all streams [19:13:01 CEST] <shreds> I see! [19:13:35 CEST] <shreds> now looks like ffmpeg -v trace -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 2 -timeout 999999 -t 999999 -i https:/live_feed.com/f386e3b206814e1f8c8c1c71c0f8e748/chunklist_b2592000.m3u8 -c copy -movflags frag_keyframe+empty_moov test.mp4 [19:13:51 CEST] <shreds> (don't mind the huge timeouts, just trying for the sake of it) [19:13:52 CEST] <kepstin> shreds: i don't think the reconnect otpions apply to hls [19:14:08 CEST] <shreds> oh :( reconnect_at_eof sounded like what I needed [19:14:28 CEST] <shreds> since my problem is the feed going EOF on sink link / No more output streams to write to, finishing. [19:14:32 CEST] <kepstin> hls is already doing periodic polling of the playlist file, reconnecting each time if needed [19:14:42 CEST] <shreds> I'm starting to believe it's my internet connection dropping out [19:14:45 CEST] <shreds> ok I see [19:15:29 CEST] <kepstin> so the problem is that the playlist has either stopped updating (and you hit the -max_reload limit, which defaults to 1000) or the server has explicitly indicated eof [19:16:12 CEST] <giaco> if I have a video+audio stream over TCP and I need to stream it over an unreliable link (3G), how should I configure the client (ffmpeg/ffplay) to get a best effort service? [19:16:40 CEST] <shreds> @kepstin the stream should never end since it's an always online camera feed. so I'm wondering whether it's my net dropping or theirs [19:16:52 CEST] <shreds> when I check the stream via VLC I never have issues [19:16:55 CEST] <giaco> I mean. What can I do when I have TCP instead of UDP as server but I want to get something out of it? [19:17:05 CEST] <shreds> or whatever player i.e. mpv [19:17:20 CEST] <kepstin> shreds: ffmpeg logs would be helpful [19:17:34 CEST] <shreds> @kepstin gimme a sec I'll send some [19:19:18 CEST] <kepstin> giaco: you're probably gonna need a more robust client that supports reconnecting / buffering in that case. [19:20:19 CEST] <giaco> kepstin: is ffmpeg/ffplay capable? Do you have any suggestion? [19:20:47 CEST] <kepstin> giaco: streaming using a segmented format (hls, dash) rather than over a single tcp stream to allow the player more control might be a good idea. [19:21:11 CEST] <kepstin> other than that i can't really say, since you haven't really said much about what your actual requirements are... [19:23:43 CEST] <giaco> kepstin: but what if I don't have control on the camera? Let me explain. I have one of those cheap chinese ip cameras. The only endpoint I have is a http stream. I could put a raspberry between the camera and the gateway, but I still need to learn how to handle a unrealiable device over TCP. I need an intelligent client and I'm looking at a properly nfigured ffmpeg, but I'm not sure [19:24:14 CEST] <shreds> @kepstin here's my latest attempt's log: https://gist.github.com/tbergeron/d8be3b3c46c6966f0829c744b29bbf0d thx for the help btw [19:25:16 CEST] <shreds> always stops around 20mb of data [19:27:34 CEST] <kepstin> shreds: huh, that's icecast, not hld. That's weird, normally an .m3u8 input indicates hls [19:27:38 CEST] <kepstin> not nls* [19:27:59 CEST] <kepstin> that said, i can't tell because you've redacted the input url [19:29:50 CEST] <shreds> I tried with multiple input URLs, even copied random feed URLs I found off the web to try and the same always happen no matter the format. For example this is a local TV feed in my province: https://teleqmmd.mmdlive.lldns.net/teleqmmd/f386e3b206814e1f8c8c1c71c0f8e74… same happens with that one [19:30:10 CEST] <shreds> and yes I just realized that's icecast when I noticed "Ice-MetaData: 1" [19:30:44 CEST] <BtbN> The error you posted indicates a clean EOF though, no connection error. Unless the icecast client interprets it as such [19:31:28 CEST] <shreds> I'll try to provide a better example [19:31:33 CEST] <kepstin> shreds: that example link is an HLS livestream, hmm. [19:32:26 CEST] <kepstin> shreds: i've confirmed that it works fine with ffmpeg as an input, it's successfully reloading the playlist and getting new segments :/ [19:34:39 CEST] <shreds> yeah just noticed that one is different! :-/ I'm trying with that one to see if it records longer than my initial m3u8/icecast one. I'll provide logs [19:35:32 CEST] <shreds> for now it seems to work, had to remove "-movflags frag_keyframe+empty_moov" though [19:35:34 CEST] <kepstin> please don't use -v trace, it's too noisy [19:35:43 CEST] <kepstin> -v verbose is a good start [19:35:56 CEST] <shreds> ok I agree lol it's kinda crazy [19:37:02 CEST] <kepstin> i suggest avoiding mp4, it's not a good format for live stuff in general. consider using mkv, or even mpegts [19:39:02 CEST] <shreds> ok I'll follow your guidelines since you seem to know ffmpeg way better than me hehe do I just need to change the output filename or specify also -f mkv or something like that? [19:39:18 CEST] <shreds> I've been reading the docs for a week or so and there's still so much stuff left to learn woah [19:41:56 CEST] <kepstin> changing the output filename to .mkv would be sufficient here, yeah. [19:42:03 CEST] <shreds> awesome thx [19:42:17 CEST] <kepstin> (if you don't specify a -f option, ffmpeg automatically guesses the output format from the filename) [19:43:10 CEST] <shreds> that's good to know! [19:45:58 CEST] <kepstin> if you don't specify a -c option, ffmpeg automatically picks some codecs (which probably aren't the ones you wanted) and re-encodes everything using the default settings (which probably aren't what you want). [19:46:25 CEST] <kepstin> so, it's best practise to always specify the -c option and any appropriate options for the codec you picked :) [19:48:30 CEST] <shreds> oh damn ok! I understand now why it's so important to specify them! :O [19:48:36 CEST] <shreds> wow didn't know that but it makes so much sense [19:51:53 CEST] <shreds> makes so much sense, it even seems to have improved what I'm trying to do. now with -c copy it seems to pick up the right codecs and don't crash so far ( logs http://ix.io/1XVv ) [19:53:12 CEST] <Chagall> it would be nice if going from one container to another would prioritize -vcodec copy when possible [19:54:45 CEST] <Chagall> i.e. use the same codec without having to write it out when the input codec is not the default for the output container [19:58:14 CEST] <shreds> @kepstin had no errors for the past 20 mins :O first time I can write more than 20mb of video! thx the -c copy and mkv tip really helped I believe, you rock! [19:59:02 CEST] <kepstin> shreds: it's possible that without -c copy, it was simply running too slow due to transcoding the video, so the next segment it tried to read had already been deleted [19:59:53 CEST] <shreds> makes so much sense when you think about it this way, I was worried I had stumbled upon an esoteric bug but I'm getting my hopes up at the moment hehe [20:07:07 CEST] <giaco> what is better for point-to-point stream: mpegts + udp or rtp? [20:07:43 CEST] <giaco> with rtp I need one port for each stream, right? [20:07:57 CEST] <giaco> do I have any alternative? [20:21:20 CEST] <jpb> giaco: check to see if rtsp is available on the device. if so, that's probably the easiest to use [20:26:52 CEST] <giaco> jpb: it is not. I've been doing reverse engineering for hours but no luck. I'e found http+mjpeg, http+h264 and a proprietary udp protocol but no rtsp [21:51:40 CEST] <shreds> @kepstin here's an update: ffmpeg doesn't stop anymore which is GREAT! but the resulting mkv in VLC: has no sound and displayed duration is wrong. Jumping forward/backward is almost impossible. Maybe I should try straight mpegts? does that problem ring a bell to you? [21:52:56 CEST] <shreds> Duration is weird, the duration should say 1 hour but in VLC it says 11 minutes and in Plex it says 2 hours LOL [21:57:58 CEST] <kepstin> duration on any file as its being written can't be determined reliably [21:58:08 CEST] <kepstin> once you stop ffmpeg, it'll update the duration in the file header [21:58:50 CEST] <kepstin> seeking is pretty meh in files without indexes, regardless of format, but i dunno if mpegts might work better for your use case. [21:58:59 CEST] <kepstin> would have to see ffmpeg output to say what's up with the audio [21:59:59 CEST] <shreds> *I mean once I stopped ffmpeg and it has been written on the disk [22:00:22 CEST] <shreds> I'll run another test and send the output log [22:01:31 CEST] <kepstin> if you stop ffmpeg properly (by hitting 'q' in the console, or by sending it SIGINT - e.g. Ctrl-C in the console) then it should update the file with a seek index and duration. [22:01:39 CEST] <kepstin> before exiting [22:02:55 CEST] <shreds> ok hum that should be okay I guess, I had called "kill <pid> on it (without -9) so I guess it should send SIGINT to that process properly? [22:03:23 CEST] <kepstin> hmm, that does SIGTERM, not SIGINT. Those might be handled differentlly [22:03:47 CEST] <shreds> oh maybe! [22:04:04 CEST] <kepstin> try kill -sINT (kill -2) [22:04:24 CEST] <furq> just kill -INT works [22:04:36 CEST] <furq> it should always be 2 though [22:06:03 CEST] <shreds> ok I'll try kill -2 <pid> maybe that'll make ffmpeg properly finish the file thx [22:14:35 CEST] <shreds> @kepstin here's the log of my last test: http://ix.io/1XWj [22:14:38 CEST] <shreds> seems to work with -2! [22:14:51 CEST] <shreds> my test is shorter but jumping in the video works and audio too [22:16:12 CEST] <shreds> resulting video plays MUCH better wow thanks [23:02:11 CEST] <void09> anyone had success with either croppign a video or pan scan it without re-encoding (or manually adjusting player settings) ? [23:02:41 CEST] <void09> i tried mkvtoolnix, but no player i tried respects the header info about crop pixels. only changing aspect ratio works. [23:03:17 CEST] <JEEB> yea because those values have a history for just using it to fix the H.264 video stream [23:03:39 CEST] <JEEB> and in that case you should just fix the H.264 stream [23:03:50 CEST] <JEEB> and thus I think the only thing that added support was Haali's demuxer? [23:04:05 CEST] <JEEB> maybe vlc also keeps that info, but not sure [23:04:13 CEST] <void09> i tried vlc/mplayer/mpv/smplayer [23:04:29 CEST] <void09> so what is the solution to this ? none ? [23:05:00 CEST] <void09> it would be nice to have these adjustments embedded in the file as meta data, and players apply them [23:05:28 CEST] <JEEB> is this about 4:3 blu-ray stuff that's encoded as 16:9 due to blu-ray rules? :P [23:05:59 CEST] <Chagall> I thought 4:3 blu-ray is legal, just not widely used [23:06:06 CEST] <JEEB> hmm [23:06:11 CEST] <JEEB> I would have to peek into the PDF [23:06:19 CEST] <void09> no, it's a tvrip: https://ptpimg.me/112913.png [23:06:21 CEST] <JEEB> IIRC it said only 16:9 is legal [23:07:00 CEST] <void09> converted that one to 4:3 and it looks proper, but like this : https://ptpimg.me/2383w4.png [23:07:33 CEST] <void09> it can be zoomed in to almost perfect 16:9 [23:07:39 CEST] <void09> pan-scanned* [23:07:57 CEST] <Chagall> JEEB: https://en.wikipedia.org/wiki/Blu-ray#Video [23:08:11 CEST] <Chagall> ah, display aspect ratio is still 16:9 [23:08:30 CEST] <JEEB> yea, SD can be 720xYYY [23:08:36 CEST] <JEEB> with a non-1:1 AR [23:08:51 CEST] <JEEB> basically they added bw compat against DVD mastered content [23:08:59 CEST] <JEEB> so you can use the same extras etc [23:09:06 CEST] <Chagall> I assumed the 1440x1080 res could display in 4:3 [23:09:32 CEST] <void09> this is what I am aiming for, to be displayed in the player, without touching video settings : https://ptpimg.me/k69q72.png [23:09:33 CEST] <Chagall> the SD support is nice but sadly some companies prefer releasing shitty upscales [23:10:09 CEST] <JEEB> I like the 720p60/1.001 support most :P [23:10:53 CEST] <JEEB> and yea just found one of the tables [23:11:15 CEST] <JEEB> Allowed combinations of parameters for 1920x1080 video format [23:11:50 CEST] <JEEB> only 16:9 aspect ratio for display approved, but you can have 1920x1080 or 1440x1080 [23:12:01 CEST] <void09> no ideas ? :\ [23:12:09 CEST] <JEEB> same for the 720p format in the spec [23:13:20 CEST] <kepstin> the 1440x1080p anamorphic format is probably for compat with avchd [23:13:35 CEST] <JEEB> quite likely [23:14:11 CEST] <cehoyos> Or dvb [23:15:31 CEST] <JEEB> avchd was heavily utilized by blu-ray writers recording digital tv in japan, so quite likely it came from that way too [23:15:53 CEST] <JEEB> mostly due to japan being one of the few countries where empty BD media actually made sense cash-wise [00:00:00 CEST] --- Tue Oct 8 2019

1 0

ffmpeg-devel.log.20191006
by burek 07 Oct '19

07 Oct '19

[00:33:17 CEST] <Lynne> oh no [00:33:53 CEST] <Lynne> I think I know the reason why the fixed mdct does not use the scale value at all, despite aacdec meticulously adjusting it for fixed/float [00:34:52 CEST] <Lynne> I think aacdec_fixed compensates for whatever weird per-frequency scaling the mips int32 outputs using the scalefactors [02:00:32 CEST] <philipl> jkqxz: https://github.com/philipl/FFmpeg/pull/1 [02:00:41 CEST] <philipl> Addressed your feedback, as I understood it, except still need to implement device derivation for hwupload. [02:01:17 CEST] <philipl> Lynne: are you still going to pursue getting the vulkan hwcontext merged? [02:15:17 CEST] <Lynne> philipl: not posting to the ML at all unless I get an apology from michaelni [02:16:27 CEST] <Lynne> and even then who knows, carl and nicholas hate me so much they'll likely halt all my patches at review [02:17:14 CEST] <jamrial> Lynne: what happened? apology for what? [03:38:31 CEST] <cone-251> ffmpeg 03James Almer 07master:3b4e9a31ea26: avformat/matroskadec: don't rescale mastering display values [11:34:33 CEST] <cone-317> ffmpeg 03Mengye Lv 07master:9f353e376b16: avutil/common: Fix underflow for ROUNDED_DIV with unsigned integer [11:34:33 CEST] <cone-317> ffmpeg 03Jun Zhao 07master:b0e682244816: avcodec/decode: fix indentation [11:34:33 CEST] <cone-317> ffmpeg 03Jun Zhao 07master:d9bb12ee39ff: lavc/options_table: Correct the flags for AVCodecContext.flags2 [11:34:33 CEST] <cone-317> ffmpeg 03Jun Zhao 07master:a27c0781dded: doc/codecs: Update documentation for flags/flags2 [15:12:12 CEST] <cone-307> ffmpeg 03Paul B Mahol 07master:e37edc70bd88: avfilter: add anlms filter [15:36:48 CEST] <cone-307> ffmpeg 03Paul B Mahol 07master:da9337c911c9: avfilter/vf_gblur: add support for commands [15:47:17 CEST] <cone-307> ffmpeg 03Paul B Mahol 07master:66d45af13c04: avfilter/vf_avgblur: add support for commands [18:45:45 CEST] <cone-307> ffmpeg 03James Almer 07master:5f758c31f9af: avformat/matroskaenc: use r_frame_rate as fallback to set a track's DefaultDuration [20:03:01 CEST] <philipl> jkqxz: BtbN: Lynne: Hopefully final iteration of the vulkan/cuda transfer stuff. [20:03:05 CEST] <philipl> https://github.com/philipl/FFmpeg/pull/1 [20:03:13 CEST] <cone-307> ffmpeg 03Andreas Rheinhardt 07master:670fd3b0ec8f: avformat/mpjpegdec: Avoid allocation of AVIOContext [20:03:14 CEST] <cone-307> ffmpeg 03Andreas Rheinhardt 07master:e3650dcfc9cd: avcodec/cinepakenc: Fix invalid shifts [20:03:15 CEST] <cone-307> ffmpeg 03Michael Niedermayer 07master:22bec0d33f42: avcodec/h2645_parse: Use av_fast_realloc() for nals array [20:03:16 CEST] <cone-307> ffmpeg 03Michael Niedermayer 07master:81b53913bbb9: avformat/subtitles: Check nb_subs in ff_subtitles_queue_finalize() [20:33:01 CEST] <cone-307> ffmpeg 03Paul B Mahol 07master:a1e5c35a6e43: doc/filters: fix few more typos [20:55:36 CEST] <BtbN> philipl, what's the primariy limitation on it right now? As in, for a full GPU chain, you would do nvdec -> memcpy to Vulkan, -> filter with Vulkan filters -> map to CUDA -> nvenc? [20:58:22 CEST] <philipl> BtbN: that's what you'd do [20:58:30 CEST] <philipl> but it's memcpy back to cuda too [20:58:35 CEST] <BtbN> meh [20:58:41 CEST] <philipl> because the array mismatch [20:59:01 CEST] <BtbN> This will get a mess once you need a CUDA filter, the a Vulkan one, then a CUDA one again [20:59:13 CEST] <philipl> hypothetically, it would still work [20:59:22 CEST] <BtbN> yes, but more and more copies [20:59:37 CEST] <BtbN> We could probably give nvenc support to take in Vulkan frames [20:59:46 CEST] <BtbN> where it maps it correctly internally [21:00:54 CEST] <philipl> fudge the array stuff, sure. [00:00:00 CEST] --- Mon Oct 7 2019

1 0

ffmpeg.log.20191006
by burek 07 Oct '19

07 Oct '19

[00:10:42 CEST] <la_mettrie> i have 1.3 G large and 20 minutes long avi-file. trying to figure out how to make it considerably smaller mkv file [00:11:25 CEST] <la_mettrie> (reducing the size may mean reducing the quality, then i want to reduce quality which has the least visible effect) [00:38:41 CEST] <DHE> well what's it like now? pastebin the output of ffprobe on it [00:38:51 CEST] <DHE> get an idea of what we're dealing with [00:39:55 CEST] <la_mettrie> okay, i haven't been dealing a lot with videos and thought that it's excessively big but now i heard that maybe it isn't [00:40:15 CEST] <DHE> could be. depends what it is. that's why I ask for ffprobe output [00:40:47 CEST] <DHE> might be as simple as the audio is uncompressed and turning it into AAC is a huge win in a matter of 30 seconds of compression [00:42:21 CEST] <la_mettrie> well, here's the output https://pastebin.com/raw/z4iUdk7X [00:42:48 CEST] <DHE> mpeg4 classic... well that's old. [00:43:11 CEST] <DHE> also vorbis in an AVI... [00:43:46 CEST] <DHE> but for 480p yeah that's pretty big... [00:44:41 CEST] <DHE> try this: ffmpeg -i videofile.avi -c:a copy -c:v libx264 -qp 23 output.mkv # this may take 3-10 minutes depending on CPU power [00:45:15 CEST] <la_mettrie> danke [00:57:02 CEST] <la_mettrie> ok, the resulting file has sound broken [01:19:34 CEST] <DHE> la_mettrie: darn.. okay. but was the image quality ok? [01:19:38 CEST] <DHE> plus file size and all that [01:34:49 CEST] <Atlenohen> Hey, so ffmpeg support two versions of FFV1, didn't know that. Since when? [01:35:20 CEST] <Atlenohen> I'd like to read somewhere what the benefits of version 3 are (level) [01:35:36 CEST] <Atlenohen> Avisynth can't decode it tho [02:47:15 CEST] <trfl> I'm trying to use ffmpeg to verify mkv files for errors; currently I have the following command: ffmpeg -y -hide_banner -nostdin -v info -err_detect +crccheck+bitstream+buffer+careful+compliant+aggressive+explode -xerror -i "$fn" -codec copy -f null - [02:48:09 CEST] <trfl> I am expecting this to return non-zero for most/all errors, however certain conditions print a warning yet return 0, for example: [matroska,webm] Element at 0x8888888 ending at 0x9999999 exceeds containing master element ending at 0x9494949 [02:48:55 CEST] <trfl> am I expected to check the stderr for anything that's colorcoded red? is there anything I have misunderstood so far, for example how to set the err_detect flags? [09:04:09 CEST] <la_mettrie> when trying to play avi-file with VLC, it complains that file's index is missing or broken. then VLC let's generate index or to play file without it. when playing without index, there's glitch on the screen now and then. [09:04:24 CEST] <la_mettrie> now should something be done for this while before uploading to youtube and other places? [09:04:36 CEST] <la_mettrie> *lets [09:04:57 CEST] <la_mettrie> *while -> file [09:10:36 CEST] <la_mettrie> okay, mplayer seems not to play that file all [09:23:16 CEST] <la_mettrie> probably ffmpeg could somehow generate that index so that it would be always there [09:45:01 CEST] <la_mettrie> okay, now it's possible that i fixed the problem by using a different command to impose the sound on the video [09:52:40 CEST] <la_mettrie> cannot believe how fastly ffmpeg inserted that 20 min long OGG to a mkv file (of the same duration) [00:00:00 CEST] --- Mon Oct 7 2019

1 0