Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2019

1 participants
62 discussions

ffmpeg-devel.log.20190930
by burek 01 Oct '19

01 Oct '19

[00:00:41 CEST] <Lynne> why would you want assembly for something that's potentially subjective or incorrect at some point? [00:01:21 CEST] <rcombs> is objectivity related to desired performance? [00:02:11 CEST] <Lynne> you'll spend a lot of work on something that you might need to potentially rewrite completely [00:02:39 CEST] <rcombs> ¯\_(Ä)_/¯ in N years we'll all be on ARM anyway [00:03:29 CEST] <rcombs> and the actual tone-mapping function (which is generally the bit people quibble about) is quite a small part of the overall filter [00:03:34 CEST] <Lynne> with intrinsics, because the ARM ISA is a deliberately designed trash heap [00:04:00 CEST] <rcombs> eh I've written a fair bit of aarch64 and found it pretty pleasant tbh [00:04:13 CEST] <rcombs> documentation complaints aside [00:04:33 CEST] <rcombs> ("zip" and "unzip" docs can get fucked) [00:04:57 CEST] <Lynne> were you paid for it? I forced myself to do it for free and never want to look at it again [00:05:13 CEST] <rcombs> I was [00:05:55 CEST] <rcombs> (though I've also done some ARM reverse-engineering and binary patching for video game fan TL stuff, and that wasn't bad either) [00:06:15 CEST] <rcombs> I find NEON easier to work with than SSE2 tbh [00:06:54 CEST] <rcombs> they use 3-operand instructions for a lot of stuff where intel used 2, and the result is operations that are a lot easier to wrap your head around [00:08:44 CEST] <Lynne> but its so so soooo slow [00:09:02 CEST] <rcombs> see eg pmaddwd vs smlal [00:09:27 CEST] <Lynne> that's what destroyed me, the deemphasis opus function has an 8.2x speedup with avx and I barely managed to get 2.26x or so [00:09:45 CEST] <Lynne> different reg sizes, but that was for both opus functions [00:09:53 CEST] <Lynne> and the 15 point fft was slower than C [00:10:26 CEST] <rcombs> might help that my target was Hurricane and not, like, A53 or w/e [00:14:28 CEST] <rcombs> I got around 4.7x on what I was working on [00:15:05 CEST] <Lynne> oh yeah and lack of instructions like mults that accept memory as input, lack of shufps, different xor name making you nih xor because no docs, store and load register incrementors being useless [00:16:18 CEST] <rcombs> yeah the lack of good addressing modes is pretty obnoxious [00:16:51 CEST] <Lynne> small things, but 23 or so full registers go out quicker and because renaming isn't a thing you can't reuse temporary registers immediately [00:17:44 CEST] <rcombs> I mean, maybe it's not a thing on _your_ target [04:10:36 CEST] <cone-536> ffmpeg 03Jun Zhao 07master:79597639cb0a: lavf/utils: change the log level to warning if can't get duration [04:10:36 CEST] <cone-536> ffmpeg 03Jun Zhao 07master:12e6057fb005: lavf/nutdec: add logging context to log [04:10:36 CEST] <cone-536> ffmpeg 03Jun Zhao 07master:541c6356289f: lavf/utils: correct the duration estimation method for nut demuxer [04:10:36 CEST] <cone-536> ffmpeg 03Jun Zhao 07master:f5e867570ef4: lavf/utils: Cosmetics: fix indentation for estimate_timings [04:10:36 CEST] <cone-536> ffmpeg 03Jun Zhao 07master:6ca3d34ff849: lavf/utils: support duration estimate method dump [06:06:31 CEST] <philipl> jkqxz: https://github.com/philipl/FFmpeg/pull/1 [06:06:41 CEST] <philipl> Lynne: updated with what could be final approach to hw -> hw transfers [10:23:46 CEST] <jkqxz> philipl: Can you explain how your new valid_hw_transfer_src_formats field differs from what is returned by av_hwframe_transfer_get_formats()? [10:25:30 CEST] <jkqxz> It's also unclear to me why the transfer_data_(to|from)_hw are added. [10:27:07 CEST] <jkqxz> The if hw-hw condition inside av_hwframe_transfer_data() isn't right - a mapped frame has an attached hw_frames_ctx to support unmapping. [10:27:34 CEST] <jkqxz> (Given two devices, you can hwmap a frame from one and hwupload it to the other.) [10:31:27 CEST] <jkqxz> In hwupload I don't think you want to create a new device out of nowhere, that's not really something that should happen inside a filter. [10:32:03 CEST] <jkqxz> Add a derviation path like hwmap has? (Just for the device, not doing anything with the frames.) [12:16:14 CEST] <a1rwulf> hey [12:16:31 CEST] <a1rwulf> i have some trouble to understand the rtsp code. anyone that can help me with it? [12:18:00 CEST] <BtbN> jkqxz, the thing with CUDA<->Vulkan is, that you can't truly map. It's effectively a copy. [12:25:49 CEST] <cone-125> ffmpeg 03Paul B Mahol 07master:9c9d5bf257df: avfilter/f_metadata: add ends_with() function for comparing ends of strings [12:25:50 CEST] <cone-125> ffmpeg 03Paul B Mahol 07master:a6e2cf5eb044: avfilter/f_metadata: do not memleak expr [12:58:38 CEST] <cone-125> ffmpeg 03Paul B Mahol 07master:8b36968ef465: avfilter/trim: drop all audio frames instead of asserting [15:19:07 CEST] <BtbN> I still do not understand what that dude actually wants. [15:23:34 CEST] <thardin> sounds like they want a preset for this [15:24:17 CEST] <BtbN> But what _is_ "this"? Do they just mean mpeg-2 with 720p content? [15:25:35 CEST] <thardin> "As i said in precedent explaination attempt, that is to avoid to have to set the bufsize, maxrate and others video settings. [15:25:38 CEST] <thardin> Like FFmpeg already do for other formats as DVDs for exemple." [15:25:51 CEST] <J_Darnley> So he wants a new -target option? [15:26:05 CEST] <thardin> they could just document this on a wiki somewhere [15:26:21 CEST] <thardin> surely there's a ps3dev wiki or so [15:26:44 CEST] <J_Darnley> That's the one with preset limits and whatnot in ffmpeg's world. [15:27:10 CEST] <J_Darnley> *pre-set [15:28:57 CEST] <J_Darnley> Does he post a document listing the exact settings he wants to use? [15:29:12 CEST] <J_Darnley> I'll translate them into a target option. [15:53:53 CEST] <cehoyos> J_Darnley: If you know how to do this for HD-DVD (and possibly test it), this is certainly welcome but this should really not be triggered by Sami32: I doubt that he has access to a HD-DVD player. [15:55:36 CEST] <J_Darnley> No, I don't. If he provides a command line for the settings, I will translate that into a -target option. Otherwise he is SOL to get me to do anything. [15:57:47 CEST] <BtbN> I don't think he means HD-DVD. Cause PS3 uses Blurays. [15:57:57 CEST] <BtbN> And I also have doubts about PS3 not supporting h264 [15:58:14 CEST] <J_Darnley> Wasn't it xbox360 that had hddvd? [15:58:56 CEST] <BtbN> https://manuals.playstation.net/document/en/ps3/current/video/filetypes.html "MP4 file format: H.264/MPEG-4 AVC High Profile (AAC LC)" [15:59:44 CEST] <BtbN> looks all very standard to me [16:00:10 CEST] <BtbN> It does list "AVCHD (.m2ts / .mts)" though, which I guess is what he means? [16:00:50 CEST] <nevcairiel> there is no telling what he means, since he is still mixing random technical terms with no knowledge of their meaning [16:01:17 CEST] <nevcairiel> and AVCHD is an off-shoot of Blu-ray [16:01:37 CEST] <BtbN> And on top of that, should already be supported by ffmpeg just fine? [16:02:17 CEST] <nevcairiel> he does mostly mention HDV, which is the predecessor to AVCHD [16:02:49 CEST] <BtbN> It does not even list that as supported format for the PS3 [16:03:12 CEST] <nevcairiel> (both bein camcorder recording formats, primarily, both based on mpeg-ts, HDV primarily around mpeg2, AVCHD on H264) [16:34:25 CEST] <philipl> jkqxz: I admit the hw_formats stuff ended up not making a practical difference, but I was motivated by wanting to communicate the distinction between supported hw formats and sw formats, and in theory a context might support a different set of sw formats for a given hw format. None of that actually applies in the cuda/vulkan situation, and we don't really use the input formats list in any way except [16:34:31 CEST] <philipl> in how the upload and download filters use them so I can certainly buy that it's not worth making the distinction at the moment. [16:35:12 CEST] <philipl> The seprate to/from hw function initially stemmed from their presence being part of the transfer mode detection logic, which I scraped, and then I left them in for code clarity. I can roll them back into the regular transfer functions. [16:36:20 CEST] <philipl> With respect to detecting the transfer mode, why would it go wrong? Because a derived hwframes doesn't have a real context's ability to do transfers? [16:38:21 CEST] <philipl> and then with respect to device derivation, I agree that today there is a strong relationship between the cuda and vulkan devices, but you can imagine future scenarios where it might be possible to do transfers between unrelated devices; the other data point here is that hwupload_cuda creates a device out of thin air so if we want to replace it with regular hwupload without loss of functionality, [16:38:27 CEST] <philipl> you need to be able to do that. [16:38:28 CEST] <philipl> but I can change it if you prefer. [16:51:52 CEST] <cone-670> ffmpeg 03Paul B Mahol 07master:6e9e14e62e99: avfilter/split: use av_asprintf() [16:51:52 CEST] <cone-670> ffmpeg 03Paul B Mahol 07master:7851e2f368d8: avfilter/af_join: use av_asprintf() [16:54:09 CEST] <cone-670> ffmpeg 03Paul B Mahol 07master:5161b279d611: avfilter/af_join: cosmetics [17:29:49 CEST] <BradleyS> i'm not in the loop on the ps3 discussion beyond irc, but i can say handbrake has a 1080p30 preset targeting ps3/ps4 that's pretty standard [17:30:13 CEST] <BradleyS> x264 medium, high profile level 4.0, no tune, crf 22 [17:30:23 CEST] <BradleyS> aac + ac3 audio [17:30:42 CEST] <BradleyS> mp4 container [17:31:38 CEST] <BradleyS> if the op seems to need to set vbv parameters, perhaps they've failed to set the encoder level which would handle that [17:32:53 CEST] <BradleyS> most older devices such as ps3 require level 4.0 or 4.1, we use 4.0 for all 1080p for compatibility and portability [17:33:31 CEST] <kierank> does x264 set vbv by default for level now? [17:33:41 CEST] <kierank> in the past you had to force it [17:33:49 CEST] <BradleyS> i believe so [17:34:38 CEST] <BradleyS> we don't set it manually, x264 reports it being set and adjusts based on the level chosen, so it would seem so [17:35:28 CEST] <BradleyS> i'm guessing the op set nothing which probably means auto, so he's getting a higher level and bit rate spikes the ps3 would not support [17:40:15 CEST] <JEEB> I don't think it still does VBV by default [17:40:21 CEST] <JEEB> unless something changed [17:43:02 CEST] <j45> BradleyS: handbrake sets vbv based on provided profile and level for x264. something rodeo did for us ages ago [17:43:36 CEST] <BradleyS> i stand corrected, then the op should set vbv to enforce the bit rate maximums for the required level [17:47:48 CEST] <BradleyS> i'm not sure a ps3 target is warranted as he's just targeting high profile level 4.0 with vbv-bufsize=31250 vbv-maxrate=25000 [17:48:10 CEST] <BradleyS> which is essentially what we use for all 1080p30 h.264 [17:49:17 CEST] <BradleyS> unless you want to get into targets for all common devices like we do with the preset system for handbrake ;) [18:58:46 CEST] <durandal_1707> i gonna apply scroll vf, anybody against? [19:38:57 CEST] <cone-670> ffmpeg 03Paul B Mahol 07master:a746359ede6c: avfilter: add scroll video filter [20:16:10 CEST] <Lynne> https://www.lineageos.org/engineering/Bluetooth-SBC-XQ/ [20:16:23 CEST] <Lynne> that was a nice writeup on sbc, didn't expect anything technical [20:41:25 CEST] <cone-670> ffmpeg 03Vladimir Panteleev 07master:c888adf590ee: libavfilter: add photosensitivity filter [20:41:26 CEST] <cone-670> ffmpeg 03Paul B Mahol 07master:056bc9393ea7: avfilter/vf_photosensitivity: fix memleak [21:02:17 CEST] <durandal_1707> Lynne: are you still working on vulkan? [21:26:44 CEST] <durandal_1707> how to name filter which would mix one short audio with another longer audio at random(user picked) position? [21:46:24 CEST] <Lynne> durandal_1707: av_useaudacity [21:46:29 CEST] <Lynne> *af_ [21:46:41 CEST] <durandal_1707> haha [21:50:41 CEST] <durandal_1707> Lynne: its doable, no need for GUI to add commercial breaks to your favorite shows! [21:55:25 CEST] <Chagall> I have an AV1 in MP4 file with timebase of 15360, and remuxing it to IVF sets frame rate to 1 and time scale to 15360, which is not correct (it should be 512 framerate for 15360 timescale, or 30fps). any idea what's going on? the fps is detected correctly from ffmpeg/ffprobe's side but based on the IVF header format described at https://wiki.multimedia.cx/index.php/IVF the header-provided fps is definitely wrong [21:56:09 CEST] <Chagall> eh, I guess that's more for the user channel, mb [22:45:59 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:675f62a202be: avcodec/aptx: Fix multiple shift anomalies [22:46:00 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:75fefb1fb7ac: avcodec/utils: Check sample_rate before opening the decoder [22:46:01 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:97450d2b6a08: avcodec/dxv: Check op_offset in dxv_decompress_yo() [23:24:57 CEST] <J_Darnley> Oh my god. I found it again. [23:24:59 CEST] <J_Darnley> http://rinkworks.com/stupid/ [23:43:03 CEST] <beastd> J_Darnley: OMG! That website just kills time instantly. It's entertaining, but I should really stop reading now... [23:44:04 CEST] <cehoyos> +1 [23:49:59 CEST] <Illya> tmm1: I'm not sure anyone is using the EIT title field, none of those samples use it, some more samples I found didn't have it set but set the short event descriptor instead [23:50:34 CEST] <Illya> probably better just to leave it out I think [00:00:00 CEST] --- Tue Oct 1 2019

1 0

ffmpeg.log.20190930
by burek 01 Oct '19

01 Oct '19

[00:01:06 CEST] <kadiro> ztube> it worked thanks but i'm wondering why mpv doesn't show the subtitle as it did for the original one [00:01:57 CEST] <ztube> Np :D. You are talking about showing it as default or doesn't it exist at all for mpv? [00:02:33 CEST] <kadiro> ztube> when i start it from command line i can see that it have subtitle but not loaded it [00:02:44 CEST] <ztube> does mpv list the subtitle when using cli? Maybe mpv does not support ass, would be strange however [00:03:26 CEST] <ztube> what about vlc? [00:03:27 CEST] <kadiro> the original one: (+) Subs --sid=1 --slang=eng (*) (ass) , the output: Subs --sid=1 (ass) [00:03:51 CEST] <kadiro> ztube> yes it list it [00:04:23 CEST] <c_14> It's probably either not marked as default, or has a different language tag [00:04:24 CEST] <kadiro> ztube> i will install vlc [00:06:09 CEST] <ztube> oh you are talking about the missing language information? Yea I am struggling with that atm, too. For you something like -metadata:s:1 language=eng should suffice [00:06:40 CEST] <kadiro> ah [00:07:07 CEST] <ztube> Sorry, I mean -metadata:s:s:0 language=eng [00:07:21 CEST] <ztube> The other one propably changes your audio language [00:08:38 CEST] <kadiro> ztube> ok, the original mkv have one video, one audio and subtitle ttf [00:09:05 CEST] <ztube> -metadata:s:s:0 language=eng should change the language of your first subtitle stream [00:09:18 CEST] <kadiro> this is it https://paste.ubuntu.com/p/dTDMm9zJQh/ [00:09:33 CEST] <kadiro> ok [00:12:11 CEST] <kadiro> ztube> with mpv: Subs --sid=1 --slang=eng (ass) but no subtitle appear, same thing with vlc [00:12:49 CEST] <kadiro> it look the subtitle exist but not allowing to see it [00:13:05 CEST] <ztube> does the ttf font still exist in the resulting file? [00:13:19 CEST] <kadiro> ztube> no it's gone :D [00:13:59 CEST] <ztube> -map_metadata 0 [00:14:40 CEST] <ztube> maybe that works, I'm not that experienced with ffmpeg myself [00:16:14 CEST] <kadiro> ok thank you [00:17:57 CEST] <ztube> so neither mpv nor vlc show the subtitles if you activate it? [00:19:01 CEST] <ztube> Judging from the snippets of mpv's output it looks like the subtitle was not selected [00:19:54 CEST] <kadiro> ztube> in vlc when i activate it manually it show the original subtitle not the new one [00:27:24 CEST] <kadiro> hmm some progress when i add -map 0:3 i can see the ttf in the resulted file [00:30:23 CEST] <ztube> that's strange [00:30:40 CEST] <ztube> how many subtitles are there in test.mkv then? [00:34:38 CEST] <kadiro> ztube> only one ass file [00:35:18 CEST] <kadiro> when i add ' -disposition:s forced ' it show the old subtitle [00:37:31 CEST] <kadiro> ztube> oh my god, the subtitle i used it is the same as the original lol i was stupid O.o [00:37:53 CEST] <kadiro> I didn't check the content before [00:38:08 CEST] <kadiro> thank you very much ztube [00:40:53 CEST] <kadiro> Problem fixed thank you all for your time and sorry for my stupid questions [00:56:33 CEST] <RazWelles> I need a separate avcodeccontext for the encoder, and the avformatcontext stream? [00:56:43 CEST] <RazWelles> but I need to configure them the same, right? [01:35:30 CEST] <DHE> You need an avformatcontext for a file reader or writer, and an avcodeccontext for a decoder or encoder [01:39:47 CEST] <pink_mist> you need to set it as default, no idea how to do that in ffmpeg [01:39:53 CEST] <pink_mist> oh gah, was scrolled up [01:49:43 CEST] <Scrxtchy> I have a vp0 webm with alpha channel, is it currently possible to convert this to an animated webp maintaining the alpha channel? [01:50:59 CEST] <Scrxtchy> using -c:v libvpx-vp9 returns [webp @ 000001eec118dec0] Only WebP is supported; Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument [02:05:07 CEST] <RazWelles> DHE: thank you, do they need to be configured with the same settings? IE, should I make a method that configures each the same way [02:05:29 CEST] <RazWelles> the avformatcontext's video stream seems to need a context too [02:05:36 CEST] <RazWelles> So maybe I configure them the same? [02:07:43 CEST] <DHE> if you're decoding, avformat_find_stream_info should get you all the populated fields you need but you need to allocate and prep your own decoders. if you're encoding you allocate the context, avformat_new_stream a bunch of times for each video and audio stream, and when it's all ready call avformat_write_header to get started [02:12:36 CEST] <RazWelles> DHE: I see.. for encoding, do I need a new avcodeccontext for both the stream and the encoder, or use the same one? [02:14:03 CEST] <DHE> you only need 1 context per stream that needs is... 1 video, 1 audio typically. [02:14:28 CEST] <DHE> so 1 avformatcontext containing 2 streams, 1 avcodeccontext for the video and another for the audio [02:15:40 CEST] <RazWelles> DHE: do I use the same context for the encoder for encoding frames to packets? [02:18:05 CEST] <DHE> that's an encoder's job - convert AVFrame to AVPacket. what you do with it is entirely up to you [02:18:29 CEST] <DHE> heck I have a program that encodes audio once but writes it to 3 different files [03:04:58 CEST] <RazWelles> Hm.. even though I add the stream, use the new stream's encoding context, and set packet stream index to 0 [03:05:02 CEST] <RazWelles> My files come out bad [03:05:10 CEST] <RazWelles> VLC plays nothing and doesn't list a codec [04:29:50 CEST] <RazWelles> So [04:29:53 CEST] <RazWelles> I'm going a little insane here. [04:30:02 CEST] <RazWelles> I finally decided to compile the demo, encode.c [04:30:07 CEST] <RazWelles> It doesn't spit out a valid video. [04:31:05 CEST] <RazWelles> oh, smplayer can play it [04:31:07 CEST] <RazWelles> vlc can't [05:27:25 CEST] <RazWelles> Is there an example that covers using add_new_stream and uses the new send_frame/receive_packet api as well? [05:27:50 CEST] <RazWelles> All the examples I come across with adding a stream only use avcodec_encode_video2 [05:37:41 CEST] <kingsley> If you happen to have the time, are so inclined, and it would be convenient, comfortable, and all those good things, I'd be happy to receive informed advice on whether ffmpeg's (or melts, mesa's or kdenlive's) GPU support is currently robust enough to justify yours truly paying about an extra $US 650 for a Radeon VII instead of buying an old used AMD video card from an electronics recycler. [05:41:05 CEST] <kepstin> kingsley: media stuff really doesn't have anything to do with gpu shader performance, for the most part [05:41:26 CEST] <kepstin> kingsley: honestly, a ryzen apu has a newer video decoder/encoder block than VII, and "enough" gpu power for most video playback shaders. [05:41:52 CEST] <kepstin> other than that, you might as well get a cheap polaris card or wait for the upcoming low-end navi stuff [05:44:02 CEST] <kepstin> if you're on an intel platform, recent intel chips have decent video decoder support in the integrated graphics. [05:46:31 CEST] <kingsley> kepstin: Thank you for your thoughts. Aside from playing back decoded video, do you happen to know if AMD's Radeon VII encodes/renders video faster? You know, like for editing video and creating content? [05:48:13 CEST] <kepstin> kingsley: very little linux video editing software makes use of gpu compute, as far as i know. And getting opencl working on any radeon card to get that working is kind of a mess. [05:48:32 CEST] <kepstin> you'd be better off spending the money on more cpu. [05:49:44 CEST] <kepstin> if you're doing hardware video encoding specifically, the nvidia gpus are generally considered to have better hardware encoding than other vendors, but require proprietary drivers to use the hardware. [05:58:25 CEST] <kingsley> kepstin: I happened to notice you mentioned OpenCL. I'm curious about how well it might be sped up by an AMD Radeon VII. Please feel free to elaborate on your concern that getting opencl working on any radeon card is kind of a mess. [05:59:14 CEST] <kepstin> whether using opencl provides any speedup depends on the application and hardware and drivers, can't make any sort of general call there. [06:00:47 CEST] <kepstin> for getting opencl working on radeon cards, there *is* support in mesa, but it's limited to an older opencl version and is in my experience kinda buggy. There's also AMD's "ROCm" runtime, but it's not integrated well into linux distributions and might require some manual install work depending on the distro. [06:01:58 CEST] <kepstin> imo, even if you really want a high end amd gpu, you'd be better off getting an rx 5700 over a radeon vii at this point - the rx 5700 has the newer hardware encoder/decoder block, and video software is unlikely to use the 64bit float stuff that the radeon vii's good at. [06:06:46 CEST] <furq> kingsley: https://browser.geekbench.com/opencl-benchmarks [06:07:07 CEST] <furq> that doesn't affect the decode/encode perf at all though [06:11:09 CEST] <kingsley> kepstin: Thank you for elaborating. [06:11:30 CEST] <hendry> what's the relasonship between Intel's https://trac.ffmpeg.org/wiki/Hardware/QuickSync & https://trac.ffmpeg.org/wiki/Hardware/VAAPI? Is VAAPI the new stuff? [06:12:19 CEST] <kepstin> vaapi is an api [06:12:42 CEST] <kepstin> both the intel and amd hardware encoder/decoder are exposed via vaapi on current linux systems [06:15:51 CEST] <hendry> kepstin: ok [06:16:23 CEST] <hendry> I'm experiencing missing frames in my screencast. fps 60 seems to have no affect. looking at the log https://s.natalian.org/2019-09-30/losingframes.mp4.log can you tell it's dropping frames? [06:16:54 CEST] <kingsley> furq: Thanks for the link to Geekbench's OpenCL benchmarks. If I understand correctly, AMD'd Radeon VII definitely accelerates them. I wonder how much the Radeon VIIs accelerate other applications, like rendering video on Linux. [06:18:58 CEST] <kepstin> hendry: it's most likely bottlenecked on the screen capture part (x11grab interface). Consider trying kmsgrab [06:19:47 CEST] <kepstin> kingsley: using opencl requires that the application be specifically coded to do so. Most linux video applications aren't (there's a few ffmpeg filters that are for example, but most aren't). [06:20:10 CEST] <kepstin> kingsley: so you need to check with specific applications for support and expected performance improvements [06:20:50 CEST] <kingsley> furq: I was just told in the IRC channel for a video editor named "kdenlive" that, atm, kdenlive and mlt don't have hw acceleration, but this will change eventually. [06:21:09 CEST] <kepstin> kingsley: and opencl won't affect video encoding itself at all - video encoding is either run all on cpu, or all on special dedicated hardware (not gpu compute) [06:22:20 CEST] <kepstin> (there's an asterisk on that statement: x264 technically has opencl support, but using it lowers quality, and is sometimes even slower than the cpu only mode) [06:23:49 CEST] <kingsley> kepstin: I read your advice. Thank you very much for so generously sharing your expertise. Both are fine qualities! [06:27:26 CEST] <kepstin> for people doing video work on linux, the general recommendation is "powerful cpu" and the second recommendation, specifically for people who need the cpu for other work and want to offload video encoding, is to get a midrange recent-generation nvidia card for the hardware encoders (or a quadro for >2 concurrent streams). [06:29:01 CEST] <kepstin> on not-linux, it's a bit different, since the video software there tends to be better optimized for using gpu hardware [06:35:15 CEST] <kingsley> At the moment, it seems to me there's a significant jump from using prewritten code on a cheap video card to writing ones own custom code, maybe with something like PyOpenCL, for a more expensive and faster GPU. [06:38:48 CEST] <kingsley> kepstin: Do you happen to have any thoughts on PyOpenCL and/or ROCm? [06:39:33 CEST] <kepstin> my only thoughts on ROCm are that I'm on a linux distro that's not officially supported, so i'm still trying to get it installed and working ;) [06:41:10 CEST] <kingsley> kepstin: Do you happen to have any thoughts on why ROCm would be desirable? [06:43:52 CEST] <kepstin> supports newer version of opencl (2.0 instead of 1.2) and should be better optimized on newer cards [11:13:33 CEST] <termos> I keep getting these messages "mmco: unref short failure" followed by streams not being able to continue and my mp4 muxer reporting "Application provided duration: -2048 / timestamp: 25556992 is out of range for mov/mp4 format" right after. Is there a way to survive such decoding errors? [11:15:56 CEST] <termos> is it best to not just rescale timestamps from demuxing -> encoding -> muxing but generate them myself in say AV_TIME_BASE? [12:23:15 CEST] <a1rwulf> hello [12:23:45 CEST] <a1rwulf> i have an ip camera that can serve a multicast through rtsp, but ffmpeg seems to struggle with the stream [12:24:11 CEST] <JEEB> have you tried switching the mode? [12:24:16 CEST] <JEEB> the default is UDP [12:25:05 CEST] <a1rwulf> I tried to debug the problem and I struggle to understand how the lower_transport_mask flag works in rtsp.c [12:25:50 CEST] <a1rwulf> as far as I can follow it's initialized to 0 and then unconditionally set to: rt->lower_transport_mask &= (1 << RTSP_LOWER_TRANSPORT_NB) - 1; [12:26:05 CEST] <JEEB> -rtsp_transport tcp f.ex. should give you TCP [12:26:28 CEST] <JEEB> also default is 0 [12:26:35 CEST] <a1rwulf> before doing the rtsp setup command it does a lookup into: ff_log2_tab [12:26:43 CEST] <a1rwulf> and that results in UDP unicast always [12:26:56 CEST] <a1rwulf> but I want to request a UDP multicast [12:26:57 CEST] <JEEB> hmm [12:27:02 CEST] <JEEB> at least TCP has worked before [12:27:08 CEST] <JEEB> but I have not tried udp_multicast [12:27:51 CEST] <a1rwulf> the ffmpeg -i output is: [rtsp @ 0x55567102a500] Nonmatching transport in server reply - which is exactly unicast vs. multicast [12:28:10 CEST] <a1rwulf> if I hardcode the lower_transport flag to 2, it can dump the stream information [12:28:20 CEST] <JEEB> also the &= only should filter invalid values out [12:29:06 CEST] <BtbN> Are you sure it's not the server always unconditonally using one specific mode? [12:32:12 CEST] <a1rwulf> ah so in ff_rtsp_connect the lower transport flag should already be initialized correctly and the bitmasking is just sanatizing the value? [13:38:26 CEST] <a1rwulf> I got a bit further, if I add -rtsp_transport udp_multicast to the commandline option, it works as expected [13:38:53 CEST] <JEEB> yes, that was expected [13:39:11 CEST] <JEEB> so the mapping part seems to work [13:39:38 CEST] <a1rwulf> it still seems to be decided to use udp unicast, before any negotiation happened with the rtsp server [13:39:47 CEST] <a1rwulf> if I omit the parameter [13:40:27 CEST] <a1rwulf> should the unicast/multicast decision part of the DESCRIBE method? [13:41:44 CEST] <JEEB> standard udp is the default mode for the rtsp module [13:41:51 CEST] <JEEB> so that's expected [13:42:11 CEST] <JEEB> if you think there's some automated way to figure out which it is, then you'll have to add that code yourself IFF that is spec-wise correct [13:42:20 CEST] <JEEB> otherwise just specify rtsp_transport as required [13:43:33 CEST] <a1rwulf> the camera can server unicasts through rtsp://cameraip/stream1 and multicasts through rtsp://cameraip/stream1m [13:43:54 CEST] <a1rwulf> so I thought the client can determine automatically [13:44:23 CEST] <JEEB> if there is a standardized way to get that, sure :P [13:44:24 CEST] <a1rwulf> vlc works, but I tcpdumped the rtsp packets and it also asks for unicast but gets multicast [13:44:34 CEST] <a1rwulf> but it doesn't bailout [13:44:44 CEST] <a1rwulf> so it's not entirely correct as well [13:45:15 CEST] <JEEB> so far the idea with the rtsp module seems to have been "define what you want, then we'll attempt to get that" [13:45:42 CEST] <a1rwulf> ok - i understand [13:45:58 CEST] <a1rwulf> I'm currently reading the specs and try to figure out, how this is intended to work [13:46:35 CEST] <JEEB> :) [14:09:05 CEST] <realies> how would you remove the video from a video + multitrack audio when you don't know how many tracks exactly are in the audio? [14:12:03 CEST] <ztube> ffmpeg -i input.mkv -vn -c copy -map 0:a out.mkv [16:04:17 CEST] <a1rwulf> JEEB: Standard says: unicast / multicast: This parameter is a mutually exclusive indication of whether unicast or multicast delivery will be attempted. One of the two values MUST be specified. Clients that are capable of handling both unicast and multicast transmission need to indicate such capability by including two full transport-specs with separate parameters for each. [16:11:28 CEST] <Radiator> Hey, I try to find a good rtsp server and I found ffserver which was abandoned (to my knowledge). Ffmpeg advice to use the mkvserver_mk2 but I cannot make it work for a reason. Plus they use a bit of deprecated functions which is a red flag for my company. Do any of you knows any servers that could fullfil my requirements ? [16:12:44 CEST] <Radiator> I used vlc but for security reasons we cannot use it... I've tried live555 too but we need to redirect an udp stream to rtsp (which vlc do perfectly) but live555 cannot do that (or I'm very bad at using it) [16:13:59 CEST] <Radiator> I've heard of wowza but it is overprices plus we are in a closed loop [16:17:15 CEST] <a1rwulf> you'll probably need to write your own server then [16:21:15 CEST] <JEEB> I think there's some software still maintained with RTSP [16:21:22 CEST] <JEEB> didn't the live555 peopple have something? [16:22:04 CEST] <Radiator> Seems like but I just found out there's major secure breach in live555MediaServer [16:22:40 CEST] <JEEB> fun times [16:22:57 CEST] <Radiator> I guess I'll just have to either develop a server or force vlc to my company ... [16:25:50 CEST] <delsol> did -x264-params go away or change with ffmpeg 4.2? [16:27:24 CEST] <JEEB> no? [16:27:26 CEST] <DHE> no. did you build with libx264 [16:27:28 CEST] <DHE> ? [16:27:32 CEST] <JEEB> have you built your ffmpeg.c with libx264 module enabled? [16:27:39 CEST] <JEEB> because the option comes from the module [16:27:52 CEST] <DHE> ffmpeg -h encoder=libx264 [16:29:20 CEST] <delsol> Well shit. LOL. [16:29:31 CEST] <delsol> my older ffmpeg was. Guess this one isn't. [16:38:18 CEST] <a1rwulf> Radiator: you cannot use vlc but you are allowed to use live555? [16:38:29 CEST] <a1rwulf> that is quite odd, as vlc depends on live555 [16:39:15 CEST] <shanee> Hi. I'm trying to strip all non-audio from an mp3 file. But when I look in the hex editor it includes version strings "Lavf lame" and starts with ID3 (I would expect to have removed all ID3?). What's the correct way to remove all non-audio data? (At the moment I'm using: -map_metadata -1 -fflags +bitexact) [16:40:27 CEST] <Radiator> a1rwulf: No, I was looking around and doing security checks for it. Just found out that it a massive drain with many leaks. So live555 just won a ticket for the "not4us" train [16:40:44 CEST] <cehoyos> shanee: That's typically not a good idea: If a bug will be discovered in the encoder, decoders are unable to detect the buggy encoder and cannot adapt decoding. [16:42:30 CEST] <shanee> cehoyos, Ah. I didn't know that was a thing. That's quite cool! But in this case, it's a closed loop. I'm trying to fit as many small mp3 clips onto an embedded device to play with libmad. [16:43:13 CEST] <cehoyos> You already found out how to remove the version information, no? [16:43:20 CEST] <cehoyos> Did you run ffmpeg -h muxer=mp3 ? [16:44:58 CEST] <cehoyos> And do you realize that the bitrate will have a significantly higher impact on file size than the id3 tag? Did you test variable bitrate encoding? [16:54:33 CEST] <delsol> shanee: how small is the device? [16:55:04 CEST] <a1rwulf> Radiator: yeah, it's hard to find something that 100% fits for your usage. but also probably writing them from scratch is timeconsuming ;) [16:56:26 CEST] <Radiator> Yup, the worst is that my boss asked me to find a secure server to emit RTSP from UDP just today for tomorrow midday. THey have a meeting and here I am trying everything but nothing seems to work beside vlc :/ [16:56:54 CEST] <Radiator> I really don't understand how to make live555 works but anyway, I'm off topic. [16:57:17 CEST] <a1rwulf> lol [16:57:18 CEST] <Radiator> Thanks and good day to everyone ! [16:57:23 CEST] <shanee> cehoyos, I did miss a few of those. And they do reduce the meta data a bit. [16:57:30 CEST] <a1rwulf> yeah, I'm familiar with those requests [16:57:39 CEST] <a1rwulf> have a good one, Radiator [16:58:00 CEST] <shanee> delsol, To be fair. Not that small. I have about 500kb for sounds. It just seemed like a "free" 1-2% saving on space. [16:58:21 CEST] <delsol> 500kb is tiny. [16:58:22 CEST] <shanee> But I might just not worry about the remaining metadata now. It's not that big of a deal. [16:58:40 CEST] <delsol> what is this, a device for ants? [16:59:23 CEST] <shanee> Ha. Embedded. We do kits club where they can upload sound effects and mess about with them. [16:59:39 CEST] <shanee> The audio quality is pretty terrible. But it doesn't matter that much. [17:01:22 CEST] <shanee> cehoyos, I think I'm already using variable bitrate encoding. LAME's option -qscale:a 9 suggests it's 45 to 85kbit/s so I guess that's already variable? [17:01:36 CEST] <delsol> (It is strange that we live in a world where a bottom basement quality cheap device is thousands of times faster and more capable than the "top of the line" Mac Plus (4mb ram, 40MB SCSI hard drive, external 800KB Floppy) [17:01:50 CEST] <delsol> that I had growing up [17:03:47 CEST] <shanee> delsol, Yep. You can buy a microcontroller (a full computer!) for about $0.02 now and it'll still be more capable and faster than a 1980s CPU. [17:04:24 CEST] <delsol> yeah, its just insane how far we've come. That mac plus was NOT cheap back in the day. [17:05:34 CEST] <delsol> shit, I bet all said and done, it cost as much as a Honda Civic. [17:05:44 CEST] <delsol> (likely more) [17:21:37 CEST] <kepstin> shanee: if you have something fast enough to decode it, you should switch to opus rather than mp3. Can reduce the file bitrate more then :) [17:26:55 CEST] <shanee> That would be probably be sensible. I'll definitely think about it. (But there's already a working libmad for this device, so it's kind of tempting to push ahead rather than writing a port) [18:16:52 CEST] <realies> you can't have multi channel pcm/wav audio? :o [18:18:01 CEST] <realies> [wav @ 0000027d5f8abc00] WAVE files have exactly one stream Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument when trying to ffmpeg -i test.mov -vn -c copy -map 0:a test.wav [18:20:08 CEST] <realies> test.mov has two aac streams and that's it [18:24:56 CEST] <kepstin> you can have multiple channels in wav but not multiple streams [18:26:19 CEST] <realies> I see [19:01:15 CEST] <realies> can you export all audio streams to separate files without knowing how many streams there are? [19:01:55 CEST] <kepstin> realies: you can use ffprobe to find out how many streams there are and then build an ffmpeg command that extracts them all. [19:02:32 CEST] <realies> kepstin, assuming that would involve -map-ing things around and having multiple export files? [19:03:35 CEST] <kepstin> realies: yeah, the final command would look like "ffmpeg -i input.mp4 -map 0:2 output-1.wav -map 0:3 output-2.wav" or so. [19:04:16 CEST] <realies> kepstin <3 [19:04:59 CEST] <realies> I guess I should also make a note of the stream format for each stream and append the extension to the export filename to prevent any transcoding [19:05:34 CEST] <kepstin> well, you'd have to pick an appropriate container, not all codecs have a native container. [19:05:37 CEST] <kepstin> (and also use -c copy) [19:11:55 CEST] <realies> kepstin, oh, how should I ensure I cover the ones that can't have their audio stream on their own without a container? [19:13:16 CEST] <kepstin> realies: there's not really any better option than making a list of the codecs you care about, and mapping to an appropriate container for each. [19:17:23 CEST] <realies> kepstin, what would be such a codec format I've meant... and where do I find more about it? [19:19:30 CEST] <kepstin> well, vorbis is an example. It's normally stored in an ogg container for a standalone audio file. [19:27:27 CEST] <TheDcoder> Hi, I have recorded a raw H256 stream but when I use play it using ffplay, I get this warning: Found duplicated MOOV Atom. Skipped it [19:27:49 CEST] <TheDcoder> The video plays well for the first few seconds but it starts getting "smudged"(?) after that... [19:28:00 CEST] <TheDcoder> is there anyway to fix the duplicate MOOV Atoms? [19:31:55 CEST] <cehoyos> TheDcoder: You most likely did not record "a raw H256" (should be 265) stream: Only mov/mp4 files have MOOV atoms [19:32:19 CEST] <cehoyos> If they are damaged, they are typically difficult to repair. [19:33:22 CEST] <TheDcoder> cehoyos: Sorry yes, I think I recorded a H.264 video contained in a mp4 container... the source is a live video feed [19:33:50 CEST] <TheDcoder> I think I need to move the MOOV Atoms to the beginning I found some commands and I am going to try them now :) [19:34:03 CEST] <cehoyos> You should instead "record" the live video feed with cat, wget, curl, tcpdump, mplayer -dumpstream or similar [19:34:23 CEST] <cehoyos> (If it is not rtsp) [19:34:32 CEST] <cehoyos> which is difficult to "dump" [19:34:43 CEST] <TheDcoder> Unfortunately it is not that easy... I wrote an extension which intercepts the raw data sent to the buffer [19:35:21 CEST] <TheDcoder> so I am trying to decode that data now... [19:38:16 CEST] <TheDcoder> looks like -movflags faststart isn't supported anymore :-/ [19:38:55 CEST] <JEEB> it is [19:39:18 CEST] <JEEB> it just requires a second pass, as it always has [19:40:04 CEST] <TheDcoder> I see... maybe my command is not correctly formatted [19:40:23 CEST] <TheDcoder> I am trying it use it while merging two files (audio and video) [19:40:45 CEST] <realies> kepstin, very useful but wondering how to find out about the most common codec and their containers [19:40:45 CEST] <TheDcoder> ffmpeg -i Test.mp4 -i Test.m4a -movflags faststart -c copy "Test.mkv" [19:41:32 CEST] <kepstin> TheDcoder: movflags isn't an option for mkv [19:41:40 CEST] <JEEB> ah yes :P [19:41:45 CEST] <TheDcoder> oh! [19:41:46 CEST] <TheDcoder> yes [19:43:00 CEST] <TheDcoder> great, it has MOOVed the flags to the start when I used mp4 [19:43:17 CEST] <TheDcoder> but unfortunately, that doesn't seem to be the issue :-/ [20:04:04 CEST] <kepstin> TheDcoder: sounds like you might have multiple concatenated video streams made with different encoders or encoder settings [20:04:52 CEST] <kepstin> Not many containers can represent that properly [20:05:02 CEST] <TheDcoder> I am pretty sure the stream is using the same encoder (it is done locally in the browser as far as I can see), but you mgiht be right about multiple concatenated videos [20:18:27 CEST] <TheDcoder> can ffmpeg automatically detect multiple mp4 containers within a single file and split them? [20:18:39 CEST] <TheDcoder> There is a fair possibility that this might be happening [20:19:07 CEST] <TheDcoder> My extension just dumps all the of the intercepted data from the buffer into a single file... that might be the problem [20:19:38 CEST] <TheDcoder> I see many errors like "decode_slice_header error" and "first_mb_in_slice overflow" when using ffplay [20:30:16 CEST] <realies> does -map 0:1 refer to input 0 stream index 1? [20:33:06 CEST] <delsol> I'd like to quicksync accelerate this: ffmpeg -framerate 15 -video_size 1024x768 -f x11grab -i :0 -vcodec libx264 -crf 30 -x264-params scenecut=10:keyint=450 -pix_fmt yuv420p -preset ultrafast [20:33:55 CEST] <delsol> Is there an easy way to do that I'm not seeing, or is there a more extensive list of quicksync examples somewhere? [20:37:13 CEST] <DHE> realies: yes [20:37:40 CEST] <DHE> delsol: well you're explicitly requesting libx264 so you get software encoding. have you actually found a quicksync example and tried it? [20:39:41 CEST] <delsol> ahh... gotcha. I haven't found any x11grab examples actually [21:02:03 CEST] <DHE> the source doesn't matter much. you can splice a file transcode with quicksync together with an x11grab transcode with software encoding [21:03:10 CEST] <delsol> Ok, so now it just seems to complain about pixel format. [21:03:51 CEST] <delsol> ffmpeg -v verbose -hwaccel qsv -c:v h264_qsv -framerate 15 -video_size 1024x768 -f x11grab -i :0 -pix_fmt yuv420p -preset ultrafast file.mkv [21:04:04 CEST] <delsol> [NULL @ 0x1961c80] missing picture in access unit with size 3145728[h264_qsv @ 0x1945e80] Decoding pixel format '(null)' is not supportedError while decoding stream #0:0: Function not implemented [21:05:22 CEST] <kepstin> delsol: you've put the option in the wrong place - needs to go after the input, before the output. [21:05:29 CEST] <kepstin> stuff before the input is decoder options [21:06:35 CEST] <sergeanthacker> Looking to see if ffmpeg does what I need or if I need to look elsewhere. I need to take an audio file and inject other audio files into it at specific time markers. For example, I have have a 45 minute mp3 file and want to inject a different 15 second audio file into it every 5 minutes. Am I going down the right rabbit hole with ffmpeg? [21:10:34 CEST] <delsol> kepstin: can you expand on that? what'd I do wrong? [21:11:08 CEST] <kepstin> delsol: options before -i apply to the input (so they are for demuxer, decoder, etc) [21:11:26 CEST] <kepstin> delsol: options after the -i and before the output filename apply to the output (so they are for the encoder, muxer, etc) [21:12:13 CEST] <kepstin> delsol: so your command says "please use h264_qsv to decode what you get from x11grab", and then h264_qsv goes "huh? this isn't h264 encoded video" [21:13:59 CEST] <delsol> Ahhhhh [21:14:01 CEST] <durandal_1707> sergeanthacker: you could make 2nd audio files you create with ffmpeg so that you pad 15 seconds audio cca 4 min 45 seconds with silense and than mix that audio with 1st audio with amix filter [21:14:35 CEST] <durandal_1707> also you will need to adjust volume somehow [21:15:02 CEST] <delsol> ffmpeg -v verbose -framerate 15 -video_size 1024x768 -f x11grab -i :0 <---- Input [21:15:11 CEST] <sergeanthacker> durandal_1707: awesome! thanks [21:15:54 CEST] <kepstin> delsol: note that some options in ffmpeg (like -v and -hwaccel) are global options, it doesn't matter where they are placed [21:16:19 CEST] <kepstin> er, wait, i'm wrong about that [21:16:26 CEST] <kepstin> -hwaccel is an input option apparently [21:17:06 CEST] <durandal_1707> sergeanthacker: i forgot you will need to also loop created 5 minute file to become 45 minute long [21:17:28 CEST] <kepstin> the "-hwaccell qsv" option is a weird special case for doing transcode - i.e. decoding then re-encoding all in hardware. it's not appropriate for doing encoding only. [21:18:08 CEST] <sergeanthacker> durandal_1707: noted. About to read the docs just wanted to check that it's possible first. [21:19:21 CEST] <durandal_1707> sergeanthacker: so not nice way to do it, i could write audio filter which would do just that, mix short audio with another audio at some specified moment [21:20:54 CEST] <kepstin> sergeanthacker: the way i'd probably do it is to have a separate input for each 5 minute segment (using -ss and -to to select a part of the source file) and for each insert section, and then concatenate them with a filter. [21:21:29 CEST] <kepstin> if you're going for some sort of "commercial break every 5 minutes" type thing [21:21:35 CEST] <sergeanthacker> durandal_1707: to set expectations with the business gods... is it reasonably quick enough to do ondemand or do I want to pre-mix. [21:21:52 CEST] <sergeanthacker> kepstin: ah yeah. that's basically what I'm doing [21:22:56 CEST] <durandal_1707> sergeanthacker: on demand? you mean put break at will? only with new filter.. and only if if will use not long break, because it would buffer it in memory [21:23:13 CEST] <delsol> kepstin: so is there an easy way to accomplish what I'm trying to do? [21:24:00 CEST] <kepstin> delsol: yes, you just need to use h264_qsv (or depending on your system config, maybe h264_vaapi) as an encoder. [21:25:30 CEST] <sergeanthacker> durandal_1707: yeaah, so I could insert a commercial when they click the download link so that I could rotate commercials on the fly [21:25:33 CEST] <kepstin> delsol: note that there's some quirks about using hardware encoders with a software video source. you probably want to reference the "encode-only" stuff listed on https://trac.ffmpeg.org/wiki/Hardware/QuickSync or the "encoding" section of https://trac.ffmpeg.org/wiki/Hardware/VAAPI [21:29:17 CEST] <sergeanthacker> Thanks for the help peeps! [21:29:43 CEST] <furq> would it not be easier to do that with the concat demuxer [21:30:06 CEST] <kepstin> hmm, yeah, if all the codecs match then concat demuxer could do it as a copy [21:30:20 CEST] <furq> even if you don't need to copy [21:30:22 CEST] <kepstin> might get some audible glitches at the cut points tho [21:30:24 CEST] <furq> it just seems a lot easier to script [21:32:54 CEST] <furq> sergeanthacker: https://clbin.com/hUHuD [21:33:11 CEST] <furq> something like that [21:33:37 CEST] <delsol> ffmpeg -v verbose -framerate 15 -video_size 1024x768 -f x11grab -i :0 -c:v h264_qsv -pix_fmt nv12 file2.mp4 [21:33:38 CEST] <sergeanthacker> ah, yes, I was thinking about having them just upload multiple files with the segments so that there isn't any accidental overlap and it doesn't have to be at a specific time [21:33:41 CEST] <delsol> [h264_qsv @ 0x1f6c940] Error initializing an internal MFX session: unsupported (-3)Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height[AVIOContext @ 0x1f6d780] Statistics: 0 seeks, 0 writeouts [21:33:43 CEST] <sergeanthacker> that does sound a lot better [21:33:44 CEST] <delsol> closer [21:33:50 CEST] <furq> well source.wav is just one file there [21:34:12 CEST] <furq> and you can put the breaks wherever you want [21:34:13 CEST] <sergeanthacker> ohhh cool [21:34:21 CEST] <furq> should be easy enough to write a script that generates that from a list of timestamps [21:34:50 CEST] <furq> but like kepstin said all the codecs need to match up and you might get audio artifacts if you copy [21:35:13 CEST] <sergeanthacker> thanks! I have starting points now to try some different ways [21:35:29 CEST] <kepstin> the audio artifacts will be present even if you don't copy, they're a result of concatenating encoded audio [21:35:42 CEST] <kepstin> but if all the segment cuts are on silence, that's normally not an issue [21:36:40 CEST] <kepstin> delsol: you're missing the hwupload filter, please read the links I sent you in my previous message. [21:37:39 CEST] <furq> sergeanthacker: also "input" there should be "inpoint", obviously [21:37:45 CEST] <furq> i forgot what words mean [21:38:18 CEST] <sergeanthacker> haha. me all the time [21:38:56 CEST] <durandal_1707> thats not flexible solution [21:43:53 CEST] <kepstin> hmm. i'm curious, who runs the ffmpeg twitter account? [21:46:28 CEST] <durandal_1707> kepstin: why are you curious? [21:46:54 CEST] <kepstin> dunno, if they're here i guess i'd wave hi at them? :) [21:47:10 CEST] <durandal_1707> be honest! [21:50:30 CEST] <beastd> kepstin: I guess it's still Lou running the FFmpeg twitter account . [21:50:31 CEST] <relaxed> is it llogan ? [21:50:52 CEST] <beastd> should be [21:51:08 CEST] <relaxed> he's not on irc that much anymore [21:52:26 CEST] <kepstin> i guess that makes sense, the writing style didn't seem to match anyone i regularly chat with here. [21:53:09 CEST] <durandal_1707> kepstin: is there enough text to guess writing style? [21:56:41 CEST] <Chagall> I have an AV1 in MP4 file with timebase of 15360, and remuxing it to IVF sets frame rate to 1 and time scale to 15360, which is not correct (it should be 512 framerate for 15360 timescale, or 30fps). any idea what's going on? the fps is detected correctly from ffmpeg/ffprobe's side but based on the IVF header format described at https://wiki.multimedia.cx/index.php/IVF the header-provided fps is definitely wrong [21:57:18 CEST] <kepstin> probably, yeah? particularly if you include the replies on twitter. [22:00:15 CEST] <durandal_1707> Chagall: give "ffmpeg -i file.mp4/file.ivf" output, and pastebin that and both outputs of commands you run [22:01:02 CEST] <Chagall> durandal_1707, http://paste.debian.net/plainh/aa25807a [22:02:21 CEST] <Chagall> all I do is ffmpeg -i 1494863015.y4m -vcodec copy 1494863015.ivf and run that through my software that gets framerate from the IVF header [22:02:21 CEST] <delsol> ffmpeg -v verbose -framerate 15 -video_size 1024x768 -f x11grab -i :0 -c:v h264_qsv -pix_fmt nv12 file2.mp4 [22:02:38 CEST] <delsol> roughly 2/3rds of the load of the libx264 [22:03:04 CEST] <Chagall> my program output: http://paste.debian.net/plainh/b45e27ce [22:03:14 CEST] <durandal_1707> Chagall: y4m is uncompressed video [22:03:22 CEST] <Chagall> er, mp4, sorry [22:04:59 CEST] <durandal_1707> Chagall: that output of yours program is timebase [22:05:18 CEST] <Chagall> the second number is supposed to be the framerate in the IVF header [22:05:33 CEST] <Chagall> it's not there for this file but it works fine for other AV1 IVF samples I have [22:06:00 CEST] <Chagall> e.g. with Chimera: Frame rate: 23.976 (24000/1001) [22:06:46 CEST] <Chagall> rather wrong than "not there" [22:07:49 CEST] <durandal_1707> Chagall: how many frames? perhaps it tries to guess frame rate? [22:09:04 CEST] <Chagall> it's >100 frames [22:09:47 CEST] <Chagall> I can reproduce with chimera by the way [22:09:52 CEST] <Chagall> https://drive.google.com/drive/folders/1h__jouFjK5WsimWw1lvjHE-nRyEMBsBJ [22:10:14 CEST] <Chagall> ffmpeg -i Chimera....ivf -vcodec copy chimera.mp4, then back to ivf [22:10:30 CEST] <Chagall> the framerate in the IVF header becomes 1 [22:11:26 CEST] <RazWelles> Hey, can I do variable frame rate custom timestamps without using a muxer? [22:11:55 CEST] <RazWelles> I got video output using straight up write packets to file but I couldn't get muxing to work- all the examples I could find used the non-send-frame/receive-packet api's [22:17:49 CEST] <durandal_1707> Chagall: if I remux ivf to mp4 i get extremly high frame rate with ffmpeg [22:20:03 CEST] <Chagall> that's weird, ffmpeg always has the correct frame rate for me [22:20:06 CEST] <JEEB> the mp4 muxer specifically raises the time scale because it wants to be able to offset the audio without an edit list [22:20:41 CEST] <JEEB> see the for loop where it amplifies the value [22:21:20 CEST] <Chagall> that seems ok, it just needs to output the right framerate value for IVF [22:21:35 CEST] <JEEB> aye [22:21:46 CEST] <JEEB> I'd check how the IVF muxer tries to figure it out [22:22:13 CEST] <Chagall> I'll take a look [22:22:18 CEST] <durandal_1707> Chagall: no, mp4 is unplayable and have big fps [22:22:32 CEST] <JEEB> o_O [22:22:58 CEST] <JEEB> that definitely sounds like something's awry [22:23:01 CEST] <Chagall> durandal_1707, maybe build version/config issues? [22:23:31 CEST] <Chagall> if it is fresh from master it must be very recent, mine is from a couple of weeks ago [22:24:28 CEST] <Chagall> http://paste.debian.net/plainh/ddf90983 stats for mine [22:35:49 CEST] <delsol> kepstin: thanks for the help. I got it working, and automated screen recording again. Haven't started testing on other hardware, but hopefully it all works there too. :) [22:37:05 CEST] Action: delsol hopes it works exactly the same on J1900. [22:45:50 CEST] <safinaskar> how to encode lossless vp9 the fastest way? and how to encode lossless vp9 the slowest way (i. e. with the smallest file size)? [22:46:29 CEST] <safinaskar> in other words, what options control fast/small ratio in lossless mode? (i already know that i need to add "-lossless 1" to enable lossless) [22:57:53 CEST] <kepstin> i suppose the -quality and -speed options might still have an effect in lossless mode [22:58:01 CEST] <kepstin> haven't actually checked that, tho [22:59:11 CEST] <safinaskar> -quality?! [22:59:19 CEST] <safinaskar> quality is always same in lossless mode [22:59:33 CEST] <kepstin> the setting "-quality" doesn't mean what you think it means :) [22:59:39 CEST] <kepstin> it's kinda poorly named [23:00:11 CEST] <safinaskar> ok, thanks [23:00:26 CEST] <kepstin> it has three settings, "best", "good", and "realtime", which actually change the encoder between different modes. The default, and the one you should use most of the time, is "good" [23:00:37 CEST] <kepstin> "best" is similar to libx264's "placebo" mode [23:00:55 CEST] <kepstin> and "realtime" is a funky special purpose mode for realtime streaming with dynamic quality adjustment [23:01:33 CEST] <kepstin> when you're using "-quality good", then the "-speed" option works sort of like libx264's "-preset" option, in that it adjusts encoding speed vs. efficiency tradeoffs. [23:04:07 CEST] <kepstin> (-cpu-used and -speed are the same option, it has multiple aliases) [23:08:11 CEST] <kepstin> that said, i think the options for -speed mostly affect rate control/rdo, which isn't applicable when doing lossless. [23:12:14 CEST] <cehoyos> Chagall: You mix up "time-base" and "framerate". You are not the first and not the last to do it;-) [23:13:02 CEST] <Chagall> cehoyos, I do? [23:13:25 CEST] <cehoyos> Yes, the ivf header does not store a frame-rate, each frame contains a timestamp [23:14:32 CEST] <Chagall> I guess it's my reference that has it wrong then [23:14:42 CEST] <Chagall> do you have a link to an actual specification? I couldn't find one [23:15:22 CEST] <cehoyos> Each frame has a timestamp: It could be 1, 2, 3, 4, 5, ... or 30, 60, 90, 120, ... - both do not tell you how fast to play the file, you also need the time_base as reference [23:15:42 CEST] <cehoyos> As was explained above, FFmpeg' [23:16:05 CEST] <Chagall> ffmpeg is the spec? lol [23:16:16 CEST] <cehoyos> s mp4 muxer sets an extremely high time_base (which does not effect the framerate), when remuxing again, you get the same high time_base for ivf. [23:17:03 CEST] <cehoyos> In all cases, time_base does not tell you the framerate of the file (although it indicates the highest possible framerate because framerate cannot be higher than the inverted timebase) [23:18:45 CEST] <cehoyos> No, but if the specification would say that the field contains the "framerate" (which I cannot rule out), then the question is: Why is there a pts field and what is it supposed to contain... [23:18:57 CEST] <kepstin> i see there's a random wiki page that lists one of the fields in the ivf header as "frame rate", but ffmpeg's demuxer code says that's actually the denominator of the time base fraction [23:19:11 CEST] <Chagall> ok, that makes sense, thanks [23:19:17 CEST] <cehoyos> Reductio ad absurdum [23:21:10 CEST] <kepstin> it just happens that if you're using a framerate that's an integer number of frames per second, then the most common timebase to use is 1/framerate [23:21:17 CEST] <kepstin> so people get that confused all the time :/ [23:24:18 CEST] <Chagall> btw, seems ivfenc.c does not write number of frames [23:25:04 CEST] <Chagall> and google seems to agree that it is a field that exists https://chromium.googlesource.com/chromium/src/media/+/master/filters/ivf_p… [23:25:40 CEST] <Chagall> unless there is a reason for it to be ignored, I can send a patch for that [23:29:42 CEST] <cehoyos> I tried to fix the wiki [23:30:16 CEST] <cehoyos> FFmpeg does write the video duration [23:31:26 CEST] <cehoyos> (I don't think writing the number of frames makes any sense) [23:33:34 CEST] <ztube> Hey, is anyone in here experienced with converting VOB files to mkv? I have some issues regarding the metadata, since my audio/subtitle tracks are not assigned any language. I know how to do it manually, but I would like ffmpeg to get this data from the input file for automation. [23:36:16 CEST] <kepstin> vob files on their own don't have metadata like language, etc. in them. [23:36:50 CEST] <kepstin> there's dedicated dvd ripping tools that read the full dvd structure to get that info. [23:38:32 CEST] <ztube> So is there any way to parse the IFO files with ffmpeg? I personally don't like using non-free tools such as makemkv and since I am using a headless server GUI is not an option as well [23:47:31 CEST] <kepstin> ztube: i think handbrake has a cli mode you could look in o. [23:48:30 CEST] <kepstin> that said, i dunno if handbrake can copy the video without re-encoding [23:48:56 CEST] <ztube> Okay thank you, I'll try. But isn't handbrake just some kind of wrapper for ffmpeg? [23:49:35 CEST] <kepstin> it uses ffmpeg libraries for encoding. but it has proper dvd reading support iirc [23:54:22 CEST] <sergeanthacker> was able to get what i wanted with the nodejs fluent-ffmpeg pretty quickly [23:56:09 CEST] <sergeanthacker> I opted for chopping the audio up and merging so that I can reuse the segments to trade out ads easily [23:56:27 CEST] <sergeanthacker> little slow so i'll have to cache but fine with that [23:57:46 CEST] <ztube> Apparently there is no way to prevent handbrake from reencoding the file :/ [00:00:00 CEST] --- Tue Oct 1 2019

1 0