Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2018

1 participants
62 discussions

ffmpeg-devel.log.20180125
by burek 26 Jan '18

26 Jan '18

[00:15:08 CET] <Chloe> wm4: one issue I found with WSL was that if I compile using it then it can freeze up the entire OS until make is completed, whereas msys2 doesnt do this. I wonder why this is [00:18:01 CET] <wm4> maybe the windows scheduler is bad [02:00:43 CET] <rcombs> wm4: what happened to your videotoolbox threading fix anyway [03:10:35 CET] <wm4> threading with videotoolbox is still pretty broken but I don't give a shit [03:39:40 CET] <jamrial> wm4: was that necessary? [03:39:57 CET] <wm4> what? [03:41:23 CET] <jamrial> your reply in the ml [03:41:32 CET] <jamrial> it's pointlessly aggressive [03:42:44 CET] <wm4> the reply to the post that michaelni can't maintain hevc because we don't want half of the code to be logging of obscure failure cases? [03:43:03 CET] <jamrial> yes [03:43:54 CET] <jamrial> he agreed to remove it. why not leave it at that? [03:44:11 CET] <wm4> well he's been asked multiple time to cut those log messages down, but he keeps doing it, so whatever [03:44:36 CET] <jamrial> also, i find it curious that this kind of error log is so disliked when cbs reports the exact same error for every single value, not just a few [03:45:54 CET] <jamrial> i understand disliking the logs he tried to add reporting values from internal calculations, but reporting an out of range value as defined in the spec? [03:46:54 CET] <wm4> I'd probably agree if there were actual files in the wild that had this problem, rather than just another made up file from fuzzing [03:47:39 CET] <jamrial> you know that even the conformance sample suite actuall has values with out of range values, right? [03:47:48 CET] <jamrial> eventually supperseded, yes, but still, they exist [03:48:45 CET] <wm4> so why did nobody care about that so far [03:49:59 CET] <jamrial> well, nobody found this one buggy sample in our suite because our hevc parser just didn't do range checks. until i tried to add a cbs test using it, and that one did complain about it [03:50:24 CET] <jamrial> then jkqxz dug a bit then found it was eventually superseeded because of said wrong value [03:50:58 CET] <wm4> there's still no problem with exiting without logging [03:51:17 CET] <wm4> there are far trickier things in the ffmpeg API that come with no logging to help debugging them [03:51:53 CET] <wm4> and we don't want to log every branch that's ever taken, right? (that would happen if this were consequently done) [04:13:33 CET] <rcombs> that sounds like something we call a "debugger" [17:03:46 CET] <wm4> such a garbage API... the http protocol has a timeout in microseconds protocol option, while the rtsp protocol has an option with the same name that means something else and is in seconds [17:03:58 CET] <JEEB> yup [17:04:02 CET] <JEEB> AVOptions for everyone! [17:04:05 CET] <wm4> what the fuck is consistency? [17:04:55 CET] <BtbN> There should be some document somewhere stating which units to expect in options [17:05:17 CET] <BtbN> so you only ever use seconds or something, and add respective suffixes if that would end up horrible [17:06:40 CET] <wm4> also there must be some overflow happening [17:06:48 CET] <wm4> BtbN: well it does? [17:06:52 CET] <wm4> it's still shit inconsistent [17:07:46 CET] <atomnuker> wm4: its either inconsistent avopts or more fields in avformatcontext [17:08:08 CET] <wm4> seems like you're part of the problem [17:08:14 CET] <wm4> "just do bullshit who cares" [17:08:46 CET] <nevcairiel> atomnuker: or you know, you could just make them consistent [17:09:21 CET] <SortaCore> yea, the timeout in rtsp was a dud [17:09:31 CET] <SortaCore> for one stream it just never finished attempting to connect [17:09:53 CET] <atomnuker> nevcairiel: can't, they'd have to go through regular deprecation for anything non experimental as far as I know [17:10:09 CET] <SortaCore> you can use the interrupt callback, but then it's set in the underlying tcpcontext, which means you either got to memory-hackery a reset for it, or create a more complicated callback [17:10:29 CET] <atomnuker> wm4: I care, that's why I suggest people to use already existing names for avopts [17:10:53 CET] <wm4> atomnuker: did you realize the problem? [17:11:03 CET] <wm4> the avoptions use the same name, but different units [17:11:05 CET] <SortaCore> he did, he mentioned units [17:11:19 CET] <atomnuker> I thought it was different everything, nvm then [17:11:21 CET] <SortaCore> *cough* [17:11:42 CET] <SortaCore> "<@BtbN> There should be some document somewhere stating which units to expect in options" [17:12:03 CET] <SortaCore> altho, you could cover that in the option descriptions [17:12:19 CET] <SortaCore> now it's time to move ffmpeg to std::chrono [17:12:32 CET] <nevcairiel> it would still be bad practice to have different units on options with the same name [17:12:34 CET] <wm4> and something in this horrible shitmess applies timeouts differently [17:12:45 CET] <wm4> so specifying a timeout of 6 seconds aborts immediately [17:15:09 CET] <wm4> probably some overflow undeed [17:15:13 CET] <wm4> *indeed [17:24:02 CET] <wm4> oh fucking lol [17:24:27 CET] <wm4> it fails with rtsp because merely setting the timeout makes it set RTSP_FLAG_LISTEN [17:27:27 CET] <SortaCore> *gestures at his messages at 9 mins past* [17:27:58 CET] <wm4> SortaCore: sigh [17:28:11 CET] <wm4> SortaCore: it fucking is described in the options descripotions [17:28:16 CET] <SortaCore> yea, it's useless :p [17:28:26 CET] <wm4> SortaCore: what am I supposed to do as API user, parse the descriptions? [17:30:08 CET] <wm4> the rtsp user agent option is also different from http, are you shitting me [17:30:51 CET] <SortaCore> lol yea [17:31:09 CET] <SortaCore> don't worry, I'm with you on this one, I've also experienced the useless timeout [17:37:16 CET] <wm4> user responded to my WONTFIX: "I understand completely, I've looked through the ffmpeg source before and ... I suppose garbage covers it :P" [17:37:22 CET] <wm4> I'm glad some users are so understanding [18:17:39 CET] <rcombs> what's anyone supposed to do with AV_PKT_DATA_MASTERING_DISPLAY_METADATA, anyway [18:19:36 CET] <atomnuker> use the max luminance for hdr, and if really advanced, use the white point and the rest to correct color [18:20:44 CET] <wm4> normally it gets transfered to the AVFrame side data [18:21:00 CET] <nevcairiel> this one doesnt really exist on packets anyway [18:21:05 CET] <nevcairiel> but as stream side d ata [18:21:24 CET] <nevcairiel> although i suppose it could [18:21:43 CET] <wm4> well stream side data uses the AV_PKT_ enum anyway [18:22:02 CET] <wm4> and there's some mechanism to attach stream side data to packets (not sure if it even works) [18:23:19 CET] <rcombs> if you're using lavf, are you supposed to feed it to a platform decoder [18:23:27 CET] <rcombs> or is it just always in SEI [18:23:53 CET] <nevcairiel> the stream sidedata can come from webm/matroska, ie. vp9 hdr, because it has no such SEI [18:23:59 CET] <nevcairiel> youtube hdr uses it [18:24:09 CET] <rcombs> ahh [18:24:23 CET] <nevcairiel> has the same content as the SEI data though, so same interpretation [18:24:28 CET] <rcombs> does HEVC ever not have it in SEI? [18:24:37 CET] <nevcairiel> who knows [18:24:45 CET] <nevcairiel> someone could put it in the container if they wanted to [20:44:22 CET] <cone-091> ffmpeg 03Josh Allmann 07master:ee88f31d34c8: libavformat/rtmpproto: Plug leak if sending bytes read report fails. [21:24:08 CET] <durandal_1707> atomnuker: why atrac9 is not complete still..? [21:27:39 CET] <atomnuker> because vulkan's almost complete [21:28:51 CET] <BtbN> https://developer.nvidia.com/sites/default/files/akamai/gameworks/VulkanDev… Vulkan Slides from nvidia. From 2016. Claiming CUDA<->Vulkan interop. [21:30:12 CET] <BtbN> https://github.com/KhronosGroup/Khronosdotorg/blob/master/api/vulkan/faq.md… [21:32:19 CET] <atomnuker> the weird thing is that nvidia also have an extension for external memory importing but I don't think its used for anything [21:34:03 CET] <BtbN> Isn't that even a KHR extension by now? [21:34:14 CET] <BtbN> And it can be used for various D3D/DirectX Surfaces [21:34:18 CET] <BtbN> but not CUDA, yet [21:34:26 CET] <BtbN> I think it will eventually, but they take their damn time [21:34:42 CET] <BtbN> And I kinda refuse to duplicate filters to CUDA just because nvidia has no interop [21:34:49 CET] <philipl> BtbN: I saw those slides before. It's actually very carefully ambiguous [21:34:56 CET] <atomnuker> https://developer.nvidia.com/sites/default/files/akamai/gameworks/VulkanDev… [21:35:00 CET] Last message repeated 1 time(s). [21:35:22 CET] <BtbN> That does not look ambigous to me at all [21:35:46 CET] <philipl> BtbN: huh, true. I saw different slides. [21:36:15 CET] <philipl> My conspiracy theory is that it's being held up by the same people who wanted to make sure OpenCL wasn't really usable on nvidia. [21:37:22 CET] <philipl> BtbN: I found an OpenGL shader implementation of yadif today. Not much use for an ffmpeg filter. Could be useful in mpv except it's GPL and not LGPL. [21:37:39 CET] <atomnuker> VK_KHR_external_memory and VK_NV_external memory, those are 2 separate extensions [21:38:00 CET] <BtbN> I think it works like it did at OpenGL [21:38:04 CET] <philipl> It started as an NV and was then promoted [21:38:12 CET] <BtbN> And it transistion from vendor extension to KHR to base [21:38:26 CET] <philipl> Yeah, so vulkan can import but there's no export on the cuda side [21:38:34 CET] <BtbN> that doesn't matter [21:38:55 CET] <BtbN> Mapping CUDA memory to a Vulkan texture is exactly what we need [21:39:08 CET] <BtbN> so Vulkan filters can operate on CUDA frames without copying [21:39:16 CET] <philipl> When I say 'export', I mean you can't pass a cuda memory pointer and have it work. [21:39:27 CET] <philipl> So you need to something on the cuda side to make it work, and that part is what's missing [21:39:30 CET] <BtbN> Once CUDA is implemented, it will work like that [21:39:51 CET] <BtbN> You will most likely just hand a devptr to Vulkan, and it will make it into a generic memory object [21:40:06 CET] <philipl> That sounds useful; they'll probably do something else. [21:40:20 CET] <BtbN> It works like that for D3D stuff [21:41:20 CET] <philipl> One can hope. [21:41:50 CET] <philipl> So where does that leave us? Pester our nvidia contacts? [21:43:40 CET] <BtbN> I don't think they can help much. The Interop will happen eventually [21:43:44 CET] <BtbN> might just take a few more years [21:46:50 CET] <atomnuker> at least nvidia are fast with their drivers to implement the latest extensions [21:47:35 CET] <atomnuker> though its questionable how usable they are as no one's ever tested them [21:48:23 CET] <atomnuker> until me no one wrote anything to use the ycbcr vkformats I think [21:51:54 CET] <Chloe> wm4: why cant we just depend on a net library? isnt that how you fix it in mpv [21:52:09 CET] <Chloe> i remember someone saying something about how libcurl fixed things [21:52:26 CET] <wm4> yeah ffmpeg could probably just use libcurl, I don't know [21:53:01 CET] <wm4> probably wouldn't get rid of all network code, since there are plenty of things that need raw tcp or udp [21:53:26 CET] <Chloe> but a majority of the annoying net code? [21:53:35 CET] <Chloe> or would it just not be useful overall [21:55:39 CET] <wm4> if you didn't get it yet, ffmpeg is a NIH shitshow [21:56:57 CET] <Chloe> It doesnt need to be [21:57:06 CET] <thardin> no no let's reimplement an http client but poorly and also with lots of segfaults [21:57:59 CET] <thardin> lavc is the good part [22:06:46 CET] <Chloe> was the ffm muxer removed? [22:09:48 CET] <jamrial> yes [22:16:16 CET] <atomnuker> Chloe: I think tmm1_ had some complaints with using libcurl in lavf [22:32:08 CET] <jamrial> jkqxz: were you planning on adding sei support to cbs_h265? i can help you with the boring work of defining some of the types if you want [23:04:34 CET] <wm4> heh ce seems really annoyed at me, that's nice [23:07:00 CET] <wm4> is asking me to go away every dozen threads a CoC violation yet? [23:09:28 CET] <Chloe> wm4: we dont have a CoC really, just some guidelines which dont really mean much [23:11:09 CET] <wm4> I'm pretty sure outright harassing me is even violating the lesser CoC we actually have [23:14:21 CET] <Chloe> wm4: I mean 'Be friendly and respectful towards others and third parties.', but we dont have anything which says what should happen if someone doesnt follow it, so it's pretty useless. [23:14:47 CET] <wm4> yes [23:14:53 CET] <wm4> it's unenforced [23:15:02 CET] <wm4> otherwise ce would be long gone [23:15:23 CET] <BtbN> It's getting pretty ridiculous, yes [23:15:25 CET] <wm4> (carl eugen hoyos, for the record) [23:16:19 CET] <wm4> he also cites me for attacking another dev today, I wonder what that refers to [23:16:37 CET] <wm4> because I was disapproving of michaelni starting another huge bikeshed for a simple fix? [23:16:38 CET] <atomnuker> I can't see how you think michaelni tried to drive the discussion into a bikeshed though, he just offered an advice [23:16:56 CET] <wm4> (and what was the second time) [23:17:39 CET] <wm4> atomnuker: well he clearly asked for changing the rtsp option to take a string or something [23:17:57 CET] <wm4> I don't see any "advice" (as in optional and not part of the patch review) there [23:19:40 CET] <wm4> also michaelni harassed me a lot in the past (like making me go through all that pointless crap when getting rid of the side data merging, or the AVFRamer.opaque_ref), so it's not like this is an isolated thing [23:19:43 CET] <wm4> so fucking excuse me [23:20:26 CET] <BBB> wm4: Im sorry you have to go deal with his behaviour [23:20:33 CET] <BBB> I think a lot of us just give up [23:20:47 CET] <BBB> :( [23:21:16 CET] <Chloe> I mean, how do you deal with something like this? What would a consequence be? [23:21:40 CET] <Chloe> If we can figure that out, then we can figure out how to put it in place, and then start fixing everything. [23:22:16 CET] <atomnuker> wm4: its an opinion, its not like he specifically requested you to change it, if you disagree just explain why you disagree and he'll either drop it or then go and bikeshed [23:23:07 CET] <atomnuker> immediately disregarding someone's opinion is rude [23:24:29 CET] <wm4> I'Ve also asked michaelni plenty of times he should make it clearer whether something is just advice or general thinking, or a patch review change request [23:25:04 CET] <wm4> on that topic, I also think an integer timeout in microseconds is good enough, rather than some overnegineered string+units thing [23:26:07 CET] <wbs> wm4: if I'm understanding it right (I didn't look close) something like that already exists, if you just set the right avoption type [23:26:31 CET] <wm4> yes, but this change is to harmonize behavior with the http protocol, not to rewrite everything [23:46:56 CET] <cone-091> ffmpeg 03Martin Storsjö 07master:85e10c0a9321: intreadwrite: Use __unaligned in MSVC for ARM64 as well [23:46:57 CET] <cone-091> ffmpeg 03Mark Thompson 07master:8e9be8ffba03: Merge commit '85e10c0a9321bfe0d2afe0f3983ab6a8df6e3fba' [23:47:52 CET] <jamrial> <+wm4> also michaelni harassed me a lot in the past (like making me go through all that pointless crap when getting rid of the side data merging [23:48:02 CET] <jamrial> can you drop that already? it was not pointless [23:48:22 CET] <jamrial> i was careless and did a merge wrong, and google came out of the woodworks because i broke chromium [23:48:41 CET] <jamrial> the abi concerns had a reason [23:49:34 CET] <cone-091> ffmpeg 03Josh Allmann 07master:a2a9e4eea0e4: rtmp: Plug leak if sending bytes read report fails. [23:49:35 CET] <cone-091> ffmpeg 03Mark Thompson 07master:b855b570c811: Merge commit 'a2a9e4eea0e4fde2ed8d3405b4f33f655b600c2d' [23:49:44 CET] <jamrial> the bump got rid of it all, so leave the past in the past, please [23:50:49 CET] <wm4> making it part of the bullshit was pretty much bullshit, but even beyond that it took tons of flaming to make the change _at_all_ [23:51:21 CET] <wm4> so, sorry if I base my current behavior on experiences in the past (it's called learning) [23:51:32 CET] <cone-091> ffmpeg 03Ruiling, Song 07master:559370f2c451: qsv: Skip the packet if decoding failure [23:51:33 CET] <cone-091> ffmpeg 03Mark Thompson 07master:04e4ab44d7c5: Merge commit '559370f2c45110afd8308eec7194437736c323d4' [23:52:59 CET] <jkqxz> Apply SIGPIPE ignoring? [23:53:30 CET] <jkqxz> Hmm, I did say tomorrow almost a week ago. [23:53:33 CET] <jkqxz> Sounds like yes. [23:55:25 CET] <iive> jkqxz, the argument against it, is that signal handling might have unknown effects on unknown architecture. So the only way to know what and where is to apply it. [23:57:06 CET] <jkqxz> We know exactly what effect ignoring it will have (the write will get an error and we can act sensibly, rather than the process being immediately hard-killed). [23:57:29 CET] <jkqxz> I'm much less sure about edge cases if we catch the signal and do something. [23:57:37 CET] <iive> jkqxz, that's what we want it to do. Apply it, and handle the bugs if they are ever found. [00:00:00 CET] --- Fri Jan 26 2018

1 0

ffmpeg.log.20180125
by burek 26 Jan '18

26 Jan '18

[00:00:34 CET] <TAFB_WERK> yeah, cpu sits around 6% for 15 mins to an hour before it freaks out [00:01:25 CET] <TAFB_WERK> alright, I'm off work, will have to continue another time, ttyl peeps [00:01:45 CET] <TAFB_WERK> https://www.youtube.com/c/Skyviewelectronics/live [00:01:50 CET] <TAFB_WERK> pipe stream is up, MUCH smoother [00:02:24 CET] <FishPencil> It might be smoother but it isn't a higher bitrate [00:02:35 CET] <FishPencil> and it's still choppy imo [00:02:36 CET] <friki> Hi, I've build ffmpeg with decklink but I still receive the error: "Unknown input format: 'decklink'" . Full ffmpeg output: https://pastebin.com/NqYXrK6E [00:05:07 CET] <sfan5> friki: it's using the wrong shared library at runtime [00:05:20 CET] <sfan5> either build with --disable-shared or fiddle with LD_LIBRARY_PATH [00:06:39 CET] <friki> sfan5: i'll try to rebuld with this option [00:08:58 CET] <friki> sfan5: you discovered that by this message "WARNING: library configuration mismatch"? [00:09:05 CET] <sfan5> yes [00:09:30 CET] <friki> good, thanks [00:09:31 CET] <sfan5> it's immediately obvious because --extra-version=1+b2 is something debian adds to their package versions [00:10:45 CET] <friki> hehe i se i've added also this extra version in my compilation. I'll start over also changing it [00:11:37 CET] <sfan5> oh indeed, well the configure lines still mismatch [00:14:20 CET] <friki> i think i don't need opencv. in my pervious compilation i need to remove it because of this error "ERROR: opencv not found". I think i've installed all dependencies (debian package: libopencv-imgproc-dev ) [00:15:11 CET] <friki> it will be great if i can get ffmpeg as much similar as debian's one (adding decklink) [00:15:32 CET] <friki> but it's not a big deal for now [00:36:34 CET] <ArsenArsen> I'm trying to use the C API but when doing it I get [mp4 @ 0x7fb0682635e0] Could not find tag for codec rawvideo in stream #0, codec not currently supported in container and I can't operate on it further. Code: https://gist.github.com/ArsenArsen/ef2a54e6348a840fee9c6f47e2ab8934 [01:01:04 CET] <friki> sfan5: same after recompile with --disable-shared :-/ https://pastebin.com/zxS3iqdx [01:02:10 CET] <furq> ArsenArsen: the warning is pretty self-explanatory, you can't mux rawvideo into mp4 [01:02:25 CET] <ArsenArsen> figured out where I went wrong, but not a solution [01:02:32 CET] <ArsenArsen> but thank you furq [01:03:16 CET] <furq> i would assume the solution is to use a muxer that supports rawvideo, like mkv or nut [01:03:30 CET] <furq> but my eyes glazed over as soon as i saw C++ so maybe the problem is different [01:03:53 CET] <ArsenArsen> Nope, the solution is decoding rawvideo and re-encoding it, just haven't implemented that yet [09:55:08 CET] <friki_> someone knows how to capture the second SDI input using bmdcapture (from bmdtools)? I know bmdtools are out of ffmpeg project, sorry for the offtopic [09:57:48 CET] <sfan5> friki_: did you get the decklink thing working yesterday? [09:59:11 CET] <friki_> sfan5: Morning! I get stuck at this point, after rebuild with "--disable-shared": https://pastebin.com/zxS3iqdx [09:59:47 CET] <sfan5> hmm that seems weird [09:59:58 CET] <sfan5> does readelf -d ./ffmpeg mention any libav*.so libraries? (it shouldn't) [10:01:17 CET] <friki_> In fact I prefere not to rebuild ffmpeg and keep the current installer version to avoid side efects with other installed softare. For this reason i've been using bmdcapture since some months ago. Now I have a new card with 2 SDI inputs I don't know how to run it with bmdcapture [10:03:13 CET] <sfan5> well as long as you don't try to install your custom ffmpeg system-wide, it won't interfere with anything else [11:46:58 CET] <Guest76> Hi, I'm using ffmpeg (2.8) for a video player I'm working on using mpegts over udp multicast. I noticed that my player hangs on the call to avcodec_decode_video2, but ffplay does not. How should I handle intermittent connections as to prevent this thread hang? (side note, I wished ffmpeg had a interrupt callback on the AVCodecContext also) [12:00:52 CET] <JEEB> progmanos: I am not sure why that one would hang [12:01:01 CET] <JEEB> the one that reads data from multicast, sure. [12:02:20 CET] <progmanos> av_read_frame does not hang because I set the udp timeout value and I'm using the interrupt callback. it's weird that it's only hanging in the call to avcodec_decode_video2 [12:02:47 CET] <progmanos> almost like the mpeg2 decoder gets stuck in an infinite loop [12:03:25 CET] <progmanos> does anyone know if a later minor release on the 2.8 mainline version fixed a issue related to this? [12:19:03 CET] <JEEB> no idea, I would just test latest master and I would recommend switching to the feed/receive API [12:19:14 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [12:19:17 CET] <JEEB> this API is <3 [12:40:53 CET] <Asuran> hi im trying to rescale a 1088x1920 vid to -vf scale=364:642 but it doesnt work no matter what i do i get not what i wanted and its ugly stretched to other ratio [12:47:45 CET] <friki_> sfan5: finally i got recompiled ffmpeg with decklink support :-) [i think "make clean" is required after changing some ./configure options] [12:50:37 CET] <JEEB> friki_: you should generally not build in the source root (even making a "lunix_build" directory in it, and then running the configure/make from there is OK), as you can then easily nuke it from the orbit and then build from zero again :) [12:52:23 CET] <friki_> JEEB: like: mkdir mybuild && cd mybuild && ../configure --enable-STUFF && make ? [12:54:30 CET] <friki_> JEEB: ok, i see now. Thanks for the tip! [12:55:31 CET] <JEEB> yup [12:58:08 CET] <friki_> next question... I'm trying to capture from secondary SDI channel from a "Decklink 4k Extreme". May be the ffmpeg syntax has changed? [12:58:57 CET] <JEEB> never looked into the decklink module's parameters so no idea [12:59:11 CET] <friki_> -i 'DeckLink 4K Extreme (2)' doesn't works for me [13:07:17 CET] <friki_> some commands showing "list_devices", "list_formats"... https://pastebin.com/MLGVD5yu [13:40:50 CET] <sfan5> -video_input sounds like it'd do that, http://ffmpeg.org/ffmpeg-devices.html#Options-3 [13:45:38 CET] <sfan5> though it doesn't seem to have options for secondary inputs [14:46:23 CET] <khali> good afternoon [14:47:24 CET] <khali> I have a few old AVC+MP3 videos using MP4 container which my TV refuses to read [14:48:01 CET] <khali> I found that this TV supports AVC+MP3 in MKV container though, so I'm going to convert all my old files using ffmpeg [14:49:02 CET] <khali> my current plan is the very simple and naive: ffmpeg -i movie.mp4 -c copy movie.mkv [14:49:47 CET] <khali> I just wanted to ask if anyone has suggestions of other options which would be recommended for such a conversion? [14:49:57 CET] <c_14> -map 0 potentially [14:50:02 CET] <c_14> if you have more than 1 audio track [14:50:56 CET] <c_14> btw. do you also have avc+mp3 mp4 files that the TV reads? Because in that case it might be something like the video profile that's causing the issue [14:56:08 CET] <khali> thanks c_14, indeed there are a few multilanguage files in the lot [14:56:40 CET] <khali> good question, let me check [15:07:16 CET] <khali> generating list... [15:08:44 CET] <khali> c_14: I checked, all my avc+mp3 mp4 files are rejected and only these [15:09:06 CET] <c_14> then it might just be the container, yeah [15:09:10 CET] <khali> also the fact that the same streams in MKV container are supported suggests that it's not a profile issue [15:09:13 CET] <c_14> or codec+container rather [15:09:47 CET] <khali> well it was an odd combination of codecs to use... I was young and lacked experience [15:13:50 CET] <khali> I always wondered why "-map 0" isn't the default [15:21:08 CET] <khali> thank you c_14, looks all good [16:06:53 CET] <alexpigment> khali: re your earlier post, the funny thing is that mp3 is supported in MP4 files, but up until this point, I thought Apple products were the only thing that didn't play them [16:07:20 CET] <alexpigment> which, of course, I assumed was a business-related decision since they have a stake in AAC [16:40:49 CET] <khali> alexpigment: sure it is supported, and VLC and ffplay are find with that [16:41:27 CET] <saml> is there IDE for filtergraph? [16:42:02 CET] <khali> but as I recall my father in law's Sony LCD did not support them either [16:42:04 CET] <saml> i want auto complete and visualization and step debugger and peek intermediate results between filter chains [16:42:11 CET] <khali> and neither does my brand new Panasonic [16:42:58 CET] <khali> I'm surprised as I actually expected all these screens to be powered by open-source players [16:43:12 CET] <alexpigment> khali: well, VLC and ffplay are going to play a lot of things that aren't exactly standard. but even major players on windows and all browsers handle them. quicktime and safari don't though. it sucks because the AAC license is pretty prohibitive [16:44:13 CET] <alexpigment> at least, if you're a business, you gotta pay VIA for just the AAC part - the fees for H.264 don't even come into play until you are at a very high number of units [16:46:47 CET] <SortaCore> on a call with libx264 licensors soon [16:46:58 CET] <SortaCore> let's hope I can get my code non-open-source-requiredy [16:47:14 CET] <SortaCore> don't want to impose that on all the fellas that will use my dll [16:47:15 CET] <alexpigment> :) [16:48:05 CET] <alexpigment> always good to be all squared away with licensing [16:50:01 CET] <furq> not relevant any more but browsers used to be real shaky with avc/mp3 in mp4 [16:50:05 CET] <furq> firefox didn't play that for ages [16:50:17 CET] <furq> even when avc/aac in mp4 and mp3 both played file [16:50:20 CET] <furq> fine [16:55:42 CET] <khali> yes, clearly limitation is most often about combinations, not individual support [17:17:04 CET] <saml> [a][b]scale2ref does it scale a to match b? or scale b to match a? [17:26:02 CET] <kepstin> saml: it says what it does in the example in the filter documentation. [17:29:45 CET] <saml> kepstin, scales a to b [17:29:53 CET] <saml> i verified by looking at Output: section [17:30:01 CET] <saml> hehehehhehehehehehehhehehehee such smart [17:43:37 CET] <saml> interesting about psnr filter. framerate -> scale2ref -> psnr yields better than scale2ref -> framerate -> psnr and framerate 50 yields better than framerate=fps=60 [17:43:48 CET] <saml> just way too many variables [17:44:37 CET] <saml> i calculate psnr just to detect abnormal code release [17:45:38 CET] <saml> does it make sense if videoencoder-v1 had X PSNR for few reference videos. but output of videoencoder-v2 gives lower PSNR ? [17:46:34 CET] <saml> i mean v1 and v2 outputs different sets of encodings based on same originals. and I want to compare psnr of both v1's output and v2's output [17:47:02 CET] <saml> to see if i've done a good job with v2 [17:47:26 CET] <saml> i guess it's same as optimizing ffmpeg arguments for psnr, which is useless [17:54:34 CET] <kepstin> saml: using the framerate filter on anything involving psnr seems like a terrible idea given how it interpolates frames. [17:55:20 CET] <kepstin> and psnr will not tell you if an encode will look good to a person, so :/ [18:04:48 CET] <SortaCore> read that as HolocaustUser... what is up with my brain [18:04:59 CET] <SortaCore> on a related note I finished the call [18:05:13 CET] <SortaCore> dude will talk to lawyers [18:08:16 CET] <SortaCore> now I'll play some Monstrum to relax [18:58:25 CET] <SortaCore> I escaped from the psychic monster of death [18:58:31 CET] <SortaCore> very relaxing [19:01:52 CET] <saml> kepstin, ah thanks. i missed interpoloation part [19:03:16 CET] <alexpigment> "<saml> i calculate psnr just to detect abnormal code release" [19:03:34 CET] <alexpigment> why don't you just keep an *encoded* video as your reference for PSNR [19:03:46 CET] <alexpigment> and run the same job you used to create *that* video in each release? [19:04:29 CET] <alexpigment> for example, i have source video A [19:04:40 CET] <saml> yeah that's what i'm doing [19:05:09 CET] <saml> psnr was first chosen cause it's shipped with virtually all ffmpeg where as vmaf comes optionally [19:05:20 CET] <alexpigment> then why are you dealing with different video specs? [19:05:41 CET] <saml> ah, i'm not doing -psnr (during encoding) [19:05:41 CET] <alexpigment> the frame rates, size, etc, should always match exactly if that's what you're doing [19:05:48 CET] <saml> i'm doing -filter_complex psnr [19:06:17 CET] <saml> oh i misunderstood. i have an original as reference. i'm comparing output of v1 and v2 [19:06:32 CET] <saml> *encoded* video [19:06:41 CET] <saml> yup that will work, i think [19:06:56 CET] <alexpigment> i think we're on the same page here [19:06:58 CET] <alexpigment> but just in case [19:07:19 CET] <alexpigment> you have an original video. you use ffmpeg in a known good state create an encoded video with known parameters [19:07:41 CET] <saml> it could be v2 will output different dimension, different framerate, ... etc than v1's output [19:07:44 CET] <alexpigment> you re-run that command later to detect problems with code changes by running that exact same ffmpeg command on the original [19:07:58 CET] <alexpigment> you compare encoded video A with encoded video B [19:08:16 CET] <alexpigment> saml: why? [19:08:56 CET] <alexpigment> if you want some science here, you need to keep an original video, and have a very specific set of ffmpeg parameters [19:09:16 CET] <saml> i can imagine a year from now, i (youtube, for example) would be encoding to different resolution [19:09:57 CET] <alexpigment> ok, so what is the point again, if it's not to "detect normal code release"? [19:10:00 CET] <saml> i do want to minimize variables. exact same ffmpeg argument but only ffmpeg version changed ... etc [19:10:08 CET] <alexpigment> i realize you may be changing specs [19:10:12 CET] <saml> but in a year, anything can change. i might not use ffmpeg anymore [19:10:16 CET] <alexpigment> but your PSNR test videos should not [19:10:41 CET] <saml> yeah i'm not really sure what i'm trying to detect or test [19:11:02 CET] <saml> let's say i upload the same video to youtube and to dailymotion. how do I compare their outputs? [19:11:07 CET] <saml> to choose a vendor, for example [19:11:33 CET] <alexpigment> well, assuming they support the same frame rate and resolution, you can compare the two [19:11:49 CET] <saml> i thought i could use -filter_complex psnr of youtube.mp4 and dailymotion.mp4 against original as reference and get some sense of each vendor's quality [19:12:13 CET] <alexpigment> no, you want to compare against something that has the exact same frame rate and resolution [19:12:25 CET] <saml> of course youtube.mp4 and dailymotion.mp4 will have different dimention, framerate, pixel format.. etc [19:12:34 CET] <alexpigment> saml: that's the variable you need to remove [19:12:38 CET] <saml> yup [19:12:51 CET] <alexpigment> they'll have the same pixel format, so ignore that [19:13:08 CET] <alexpigment> if they have different frame rates, then you are uploading a source file with a frame rate that X supports and Y doesn't [19:13:25 CET] <alexpigment> so upload a video that has a frame rate that both support (e.g. 29.97fps) [19:13:30 CET] <saml> yeah i tried artificially encoding a video with rgb24 instead of yuv420p, and it didn't affect psnr [19:13:52 CET] <alexpigment> rest safely knowing that yuv420p is here to stay for the foreseeable future on streaming sites [19:14:22 CET] <alexpigment> anyway, i see that you're really struggling with this project, and from the knowledge I gather, you're making this way harder than it should be [19:14:48 CET] <saml> some vendors does not keep original's framerate. if i upload 29.97 fps, output could be 30 [19:15:12 CET] <saml> yah i'm a noob. it's been a learning experience [19:15:13 CET] <alexpigment> saml: that would be very weird [19:15:20 CET] <alexpigment> but have a contingency plan [19:15:41 CET] <alexpigment> encode your ORIGINAL in as many different formats as you can at a lossless bitrate [19:16:02 CET] <alexpigment> upload the different formats - not the originals - as your tests [19:16:28 CET] <alexpigment> if you know some site is janky and doesn't preserve 29.97fps and instead uses 30fps like an idiot, then upload your 30fps video as a test [19:16:35 CET] <alexpigment> compare the psnr against that [19:16:49 CET] <saml> and calculate psnr(format1, output1) [19:16:53 CET] <saml> yeah that makes sense [19:17:06 CET] <saml> i didn't know about lossless bitrate [19:17:23 CET] <alexpigment> well, lossless codec, lossless bitrate, etc [19:17:33 CET] <saml> hrm that's a good idea [19:18:10 CET] <saml> so, find out output format of different vendors. encode orginal to match those dimension, framerate, using lossless codec. and upload them. and do psnr [19:18:36 CET] <alexpigment> so even if whatever you're uploading looks janky because of a conversion you did locally (say, for example, 59.94fps to 30fps), the PSNR is still going to be valid when comparing the video you uploaded to what the streaming service created from it [19:18:47 CET] <alexpigment> saml: yep [19:19:02 CET] <alexpigment> and hopefully you can find a format that all services support, so you only need one reference video [19:19:11 CET] <alexpigment> or at least, one reference video per resolution [19:19:13 CET] Action: saml googles for lossless codec [19:19:41 CET] <alexpigment> huffyuv is a common one [19:19:55 CET] <alexpigment> you can actually use x264 at -crf 0 as well [19:20:46 CET] <alexpigment> just for the sake of file size and making sure your video is well supported, i'd go with x264 at crf 0 [19:21:29 CET] <alexpigment> what makes that advantageous is that you're going to be comparing against services that are also likely encoding your video to x264 [19:44:13 CET] <trichy_guru> Hi There, I am a newbie to ffmpeg and I am working on a tool to find out if an image sweeps an entire screen. Example an overlay that just sweeps the screen indicating the start of commercial [19:48:26 CET] <kepstin> trichy_guru: sounds cool, good luck with that. That sort of image analysis is kinda hard to do. [19:58:43 CET] <lyncher> for what I've seen, inserting CEA-608 captions into a H264 file is just a matter of adding H264RawSEIUserDataRegistered structures into the stream [19:59:06 CET] <lyncher> what about H265? what data structure will carry 608/708 captions? [19:59:50 CET] <TAFB_WERK> alexpigment: I haven't had good luck with crf 0, not many things will play it :( [20:22:27 CET] <alexpigment> tafb_werk: well, that's because of the profile it uses i'd guess [20:22:31 CET] <alexpigment> yuv444pp [20:22:40 CET] <alexpigment> but a service transcoding the file should be fine [20:22:50 CET] <alexpigment> likewise, comparing psnr should be fine [20:23:09 CET] <alexpigment> it's still yuv420p though; the profile is just different [20:49:51 CET] <saml> is there acceptable psnr range? 50? [20:52:51 CET] <kepstin> saml: psnr doesn't really relate to human vision, so no, there's not really. I mean, if it's really low it's obviously terrible, but that's it& [20:58:29 CET] <saml> thanks [21:08:01 CET] <saml> what's good format (-f) for outputting to stdout? -f avi - works. but -f mp4 - doesn't with -vcodec libx264 [21:08:27 CET] <BtbN> mpegts [21:08:39 CET] <kepstin> saml: nut, maybe matroska [21:27:10 CET] <saml> what's a good filter for deinterlacing? nnedi? [21:28:58 CET] <kepstin> saml: that generally gives good results, but ffmpeg's implementation is really slow [21:29:13 CET] <saml> ah i see [21:29:36 CET] <kepstin> if you want something faster, yadif is ok [21:34:42 CET] <DHE> I'm using yadif. not bad [21:35:33 CET] <kepstin> it has some noticable artifacting on certain types of diagonal lines :/ [21:36:09 CET] <kepstin> but for a deinterlacer that can run in realtime (or faster) on cpu of a modern pc, it's quite decent. [21:47:40 CET] <sfan5> isn't bwdif generally better? [21:48:10 CET] <kepstin> I have less experience using bwdif, so can't really compare. [22:07:55 CET] <alexpigment> sfan: i've tested it a few times, but i don't recall the advantages [22:08:03 CET] <alexpigment> what is supposed to be better about bwdif? [22:08:43 CET] <alexpigment> /me reads documentation; answers own question [22:08:46 CET] <JEEB> I don't think there's any sort of consensus, but bwdif uses yadif and w3f deinterlacers with some sort of switching [22:08:54 CET] <JEEB> I think it's the least tested one [22:09:00 CET] <alexpigment> yeah [22:09:05 CET] <JEEB> (which makes sense since it's the newest) [22:09:24 CET] <alexpigment> is there a possibility to use dxva2 to access whatever hardware deinterlacer is present? [22:09:28 CET] <alexpigment> like with nvidia? [22:09:41 CET] <alexpigment> nvidia even has their own inverse telecine on hardware [22:10:01 CET] <JEEB> it's part of the video rendering stuff with DXVA2 afaik [22:10:03 CET] <alexpigment> nvidia's deinterlacer appears to be much better than yadif to my eyes [22:10:07 CET] <JEEB> so decoder just outputs [22:10:10 CET] <teratorn> can you launch ffmpeg to launch a listening port to receive an rtsp stream as an input? [22:10:21 CET] <JEEB> and then you're supposed to use the dxva renderer related stuff for deint [22:10:27 CET] <JEEB> (whatever it maps to with your GPU) [22:10:41 CET] <alexpigment> you're talking about ffmpeg specifically, right? [22:10:48 CET] <JEEB> no [22:10:57 CET] <JEEB> in general they're separated in DXVA2 [22:10:59 CET] <alexpigment> considering that windows media player does that sort of stuff on the fly with the hardware [22:11:10 CET] <JEEB> yes I just said it's not in the decoder [22:11:17 CET] <JEEB> not that you don't have it [22:11:18 CET] <alexpigment> gotcha [22:11:25 CET] <JEEB> > you're supposed to use the dxva *renderer [22:11:30 CET] <JEEB> * related stuff [22:11:43 CET] <JEEB> which meant "as opposed to decoding" [22:11:52 CET] <alexpigment> oh gotcha [22:12:09 CET] <JEEB> FFmpeg only supports decoding if I recall correctly, but players like mpv if I recall correctly can use the deint [22:12:19 CET] <teratorn> I see https://ffmpeg.org/ffmpeg-protocols.html#toc-rtsp, I guess that supports it [22:15:19 CET] <JEEB> alexpigment: actually it was d3d11 it seems [22:15:20 CET] <JEEB> https://mpv.io/manual/master/#video-filters-d3d11vpp [22:16:00 CET] <JEEB> dxva2 also has it IIRC, but I guess d3d11va was the newer thing so it got implemented just there for mpv [22:29:34 CET] <alexpigment> JEEB: yeah that rings a bell [22:29:51 CET] <alexpigment> i tried to get it working on this computer in MPV but it was a busy day, and didn't have time to effectively troubleshoot it [22:30:12 CET] <alexpigment> but someday i will not be busy, and that day i will try to figure out how to get around the error that it was giving [22:30:16 CET] <alexpigment> :) [22:56:17 CET] <alexpigment> anyone have any experience with beat detection for music? [22:57:12 CET] <alexpigment> it doesn't look like ffmpeg has a way to do it, so i was wondering what libraries were good to use [23:16:26 CET] <hoek> So I have this corrupted MPEG1 file shaved off a broken FAT USBstick via dd_rescue, and ffmpeg stops writing with 'Invalid mb type in I-frame at 18 15'. Can anyone point me to some docs on how to ignore broken/invalid frames and try the next valid frame in a file? [23:18:53 CET] <hoek> I'm trying a simple 'ffmpeg -i /broken_fat_fs/corrupted_file.mpg /tmp/rescued_file.mpg' [23:19:48 CET] <alexpigment> hoek: for things like that, i find that more tools is better [23:20:06 CET] <alexpigment> there's a program called VideoRedo for windows, which has a "Quickstream Fix" option [23:20:16 CET] <alexpigment> i think they have a trial version [23:20:21 CET] <alexpigment> anyway, maybe worth trying that first [23:20:45 CET] <alexpigment> it has helped me with a lot of videos that were otherwise broken [23:22:30 CET] <hoek> alexpigment: thx, will try! [23:38:54 CET] <zerodefect> Using the C-API, is it possible to dynamically adjust/update the video properties on the 'buffer' filter on a frame-by-frame basis? [23:39:56 CET] <JEEB> I don't know the 'buffer' filter, but there is a video filter framework and you can basically be as dynamic as you want regarding what you output [23:40:14 CET] <BtbN> the buffer filter does not have runtime reconfig [23:40:18 CET] <JEEB> but as I said, I have no idea what this 'buffer' filter is [23:41:20 CET] <kepstin> zerodefect: yes, but the docs are wrong, the interface is over in libavfilter/buffersrc.h rather than libavfilter/vsrc_buffer.h [23:41:40 CET] <zerodefect> Ok. I am using the overlay filter, so I want to adjust the spatial resolution of the overlay on the fly. [23:41:49 CET] <zerodefect> kepstin: Ah :) Let me look [23:42:28 CET] <kepstin> the 'buffer' (and 'abuffer') filters are designed specifically to be used programmatically, and have extra interfaces. They're pretty much useless in the ffmpeg cli. [23:42:34 CET] <JEEB> if you need to adjust the output resolution etc you might have to flush the filter chain and re-create it [23:42:49 CET] <kepstin> and yeah, a lot of filters won't be able to handle resolution changes [23:43:12 CET] <JEEB> if the output resolution is always the same then you can keep a lot of stuff the same as long as you remember to scale etc at required points [23:43:53 CET] <JEEB> for example if you have input->scale->output, that would work even with resolution changes I think. although in my case when I tested I had a PID switch there and thus switched around the decoder, too [23:44:40 CET] <JEEB> what makes a re-creation to be required I think is stuff like "I want to change the output resolution" etc [23:44:53 CET] <zerodefect> Ok. I'm only looking to change the overlay resolution. [23:45:21 CET] <JEEB> as long as you scale your overlay to be within the bounds of the video frame I think it should be OK [23:45:43 CET] <JEEB> although you would have to check the exact requirements from the code [23:46:19 CET] <zerodefect> Can I use the 'avfilter_graph_send_command' to adjust both properties on buffer and overlay? [23:46:23 CET] <kepstin> i think overlay doesn't care about that, it's simply not draw stuff that's outside the image boundaries [23:46:53 CET] <kepstin> zerodefect: read the code on the filters in question to see if they implement the command callback and what it does (if it's not listed in the docs) [23:46:57 CET] <JEEB> kepstin: I remember at one point checking the code but I might remember incorrectly [23:47:14 CET] Action: JEEB had some fun times learning to generate a filter chain [23:47:22 CET] <JEEB> (and then actually start it up) [23:47:59 CET] <JEEB> also I still wonder why ffmpeg.c doesn't utilize the function that dumps a graphical representation of the chain :P [23:48:04 CET] <kepstin> zerodefect: it looks like you have to use the custom interface on buffersrc to change peroperies at runtime. [23:48:08 CET] <JEEB> because that was rather nice for debugging [23:48:53 CET] <zerodefect> Ok. Thanks guys. [00:00:00 CET] --- Fri Jan 26 2018

1 0

ffmpeg-devel.log.20180124
by burek 25 Jan '18

25 Jan '18

[00:00:09 CET] <nevcairiel> just got my build finished and even with d3d11 input i can only get like 30% encode usage, but this is transcoding a blu-ray source, so maybe it gets better with smaller resolutions or something like that. mind you, still 320 fps [00:05:22 CET] <jkqxz> jamrial: The MJPEG code has a lot of Js in it which need to be disentangled. [00:06:41 CET] <nevcairiel> J for JPEG. [00:06:42 CET] <nevcairiel> :D [00:11:12 CET] <jkqxz> Any opinions on having an OpenCL project on GSoC? [00:13:28 CET] <jkqxz> atomnuker's Vulkan one is somewhat speculative and researchy, so I was thinking more straightforward practical stuff like scaling and deinterlacing. [00:15:52 CET] <atomnuker> deinterlacing yeah, but I think scaling's better suited for vulkan (unless you can sample from textures in a non-quantized way like you do in opengl) [00:16:19 CET] <jkqxz> Quantised how? [00:16:29 CET] <Chloe> nevcairiel: I'm quite ill atm, but as soon as I get well enough to look at a screen for more than 10 min I'll be able to send my patches for WSL and linked-lists [00:16:50 CET] <Chloe> sorry it's taking so long, I'd rather the patches be good, and I dont think there's really any rush anyway [00:17:36 CET] <jkqxz> (Are we still in the ABI-unstable period?) [00:18:14 CET] <atomnuker> jkqxz: nvm, I'm tripping, yeah, that'll be a fine project to do, add me as a backup mentor if you're thinking of adding it [00:18:47 CET] <atomnuker> we'll be able to use the code in vulkan too so that'll be cool [00:21:30 CET] <jamrial> jkqxz: sorta? strictly speaking, until we tag ffmpeg 4.0 we could still play with the ABI as there's nothing to be binary compatible with except previous git snapshots post bump [00:21:51 CET] <cone-031> ffmpeg 03Karthick Jeyapal 07master:046a9468688a: MAINTAINERS: Add dashenc maintainer [00:23:12 CET] <jkqxz> atomnuker: Yeah. Currently the CL code is built at runtime, but there is nothing stopping it being SPIRVified at build time instead and used in the same way with Vulkan. [00:23:42 CET] <wm4> I'd still like to make a new side data API, but since I don't know how to reconcile old and new APIs I didn't try anything yet [00:45:39 CET] <atomnuker> jkqxz: I was thinking of the code which created the LUTs with per-pixel weights, but yeah, there's code out there to turn opencl to spriv [00:46:22 CET] <atomnuker> though the glsl code in mpv which handles general scaling is just a few lines IIRC so duplication wouldn't be a problem [00:46:53 CET] <nevcairiel> scaling in general is just a simple kernel of varying size, isnt it [00:47:05 CET] <jkqxz> Well, you could spend the whole time writing different scaling algorithms. [00:47:15 CET] <jkqxz> nevcairiel: Generally yes. [00:48:52 CET] <nevcairiel> making those kernels is probably more involved then the shader to apply them [01:15:56 CET] <jkqxz> atomnuker: <https://0x0.st/sqw0.txt> [01:16:02 CET] <jkqxz> Maybe I've written too much. [01:24:48 CET] <jamrial> jkqxz: the qualification task reads like it's the same as the project proper [01:27:46 CET] <jkqxz> I guess it's meant to be "write anything which works", even if it's basically useless. [01:28:05 CET] <jkqxz> (I would regard a, say, vflip filter as satisfying that, even though it probably wouldn't be applied.) [01:28:21 CET] <atomnuker> I think scaling and color conversion should go in the same filter, it really doesn't make sense not to since you'd be wasting resources splitting them up [01:28:30 CET] <atomnuker> other than that looks fine [01:30:25 CET] <jkqxz> Combining them is significantly more work once you want proper colour conversion. (See how vf_colorspace and vf_scale are separate, say.) [01:31:19 CET] <nevcairiel> yeah doing it properly is quite involved [01:31:39 CET] <nevcairiel> of course if you go from 420 to rgb or something, you need to involve scaling, so having some automagic that resolves that would be nice [01:34:08 CET] <jkqxz> If they are separate then it should be doable reasonably well with relatively simple filtering, but I agree that a full scaler there gives you more options. [03:42:46 CET] <cone-076> ffmpeg 03James Almer 07master:172564ace9c5: configure: fix vaapi_encode_example dependencies [03:42:46 CET] <cone-076> ffmpeg 03James Almer 07master:f0320afab977: avfilter/Makefile: skip compiling vaapi_vpp.h when vaapi is not enabled [04:17:55 CET] <cone-076> ffmpeg 03Richard Shaffer 07master:8a4cc0a2567f: avformat: add option to parse/store ID3 PRIV tags in metadata. [04:43:27 CET] <cone-076> ffmpeg 03Vishwanath Dixit 07master:1948b76a1bea: avformat/hlsenc: closed caption tags in the master playlist [07:22:49 CET] <SortaCore> why does libopenh264 only have -profile option? [07:23:07 CET] <SortaCore> https://github.com/cisco/openh264/issues/1529#issuecomment-89064235 seems to indicate options are available in priv_data [07:33:16 CET] Action: SortaCore hunts for actual ffmpeg openh264 implementation [07:42:01 CET] <SortaCore> ...openh264 looks kinda botched [07:45:08 CET] <SortaCore> iRCMode is only ever set to rate-control quality mode, but iMaxQp/iMinQp is never set [07:45:27 CET] <SortaCore> shouldn't it be bitrate quality mode? [07:45:43 CET] <SortaCore> and there's an exposure of -profile but not -level? [07:46:37 CET] <SortaCore> can anyone shed some light on this [07:52:36 CET] <SortaCore> (I'll be getting to bed) [10:01:14 CET] <JEEB> if you feed stuff avfilter, did you lose AV_FRAME_DATA_*? [10:01:21 CET] <JEEB> *to avfilter [10:01:27 CET] <JEEB> I think you did if I recall correctly [11:31:32 CET] <cone-910> ffmpeg 03Jun Zhao 07master:4dbae00bac7a: lavfi/vf_xxx_vaapi: fix typo. [13:16:13 CET] <JEEB> hmm, with the ATSC caption side data, it seems like there can be multiple streams of them at the same time from the same video stream? [13:20:58 CET] <wm4> yeah, apparently [13:21:00 CET] <kierank> huh [13:21:03 CET] <kierank> should only be one [13:21:10 CET] <kierank> there's a fixed bitrate in atsc [13:21:21 CET] <kierank> the web guys do all sorts of weird shit but the broadcast ones have to be compliant [13:24:07 CET] <JEEB> hmm [13:24:24 CET] <JEEB> I just got noted that a video track could have multiple "tracks" of captions in broadcast [13:24:29 CET] <JEEB> haven't seen a sample yet [13:24:33 CET] <JEEB> and it was from ATSC broadcast [13:24:38 CET] <JEEB> English vs Spanish etc [13:25:23 CET] <JEEB> ok, it seems like a "track" is called a "channel" [13:25:28 CET] <JEEB> CC1,2,3 etc [13:26:13 CET] <wm4> aren't there 4 max? [13:26:48 CET] <JEEB> haven't looked into that yet [13:46:59 CET] <kierank> JEEB: yes multiple tracks internally [13:47:14 CET] <JEEB> yea, that's what I meant "within the same video track" [13:49:59 CET] <kierank> i thought you meant multiple SEIs [13:50:05 CET] <kierank> it's a single SEI with multiple internal tracks [13:50:08 CET] <JEEB> ah [17:43:59 CET] <jdarnley> Why is ffmpeg erroring out without analysing this file? [17:46:56 CET] <jdarnley> atomnuker: do you remember anything about the dirac parser? [18:07:56 CET] <durandal_1707> jdarnley: what you need? [18:09:07 CET] <jdarnley> I wish I knew. [18:09:18 CET] <jdarnley> How do I make ffmpeg read the frame dimensions out of this file? I'll start witht hat. [18:10:14 CET] <jdarnley> ffmpeg doesn't enter av_dirac_parse_sequence_header [18:15:56 CET] <durandal_1707> jdarnley: whats error you get? [18:16:25 CET] <durandal_1707> can you play it with other players? [18:16:40 CET] <durandal_1707> is file valid? [18:16:53 CET] <jdarnley> ha ha [18:17:01 CET] <jdarnley> It might be valid. [18:17:41 CET] <jdarnley> It was created with my own code in ffmpeg and can only be decoded by other code of mine I am trying to add to ffmpeg [18:18:04 CET] <jdarnley> [dirac @ 0x558e0756e6c0] Format dirac probed with size=2048 and score=100 [18:18:05 CET] <jdarnley> [dirac @ 0x558e0756e6c0] Before avformat_find_stream_info() pos: 0 bytes read:32768 seeks:0 nb_streams:1 [18:18:05 CET] <jdarnley> [dirac @ 0x558e0756e6c0] Could not find codec parameters for stream 0 (Video: dirac, 1 reference frame, none): unspecified size [18:18:05 CET] <jdarnley> Consider increasing the value for the 'analyzeduration' and 'probesize' options [18:18:05 CET] <jdarnley> [dirac @ 0x558e0756e6c0] After avformat_find_stream_info() pos: 248728 bytes read:248728 seeks:0 frames:0 [18:18:31 CET] <kierank> jdarnley: parser needs to parse the file [18:19:00 CET] <durandal_1707> split it into packets for decoder [18:20:14 CET] <jdarnley> cock! I did forget that 1 line change in the parser [18:22:54 CET] <jdarnley> so where did that commit disappear to? [18:55:00 CET] <atomnuker> jamrial: everything [18:55:20 CET] <atomnuker> keep in mind the parser doesn't support packets with distance to next packet == 0 [18:55:47 CET] <jamrial> i think you meant to ping jdarnley [18:59:12 CET] <SortaCore> the openh264 encoder is need of some extra parameters exposed [19:00:14 CET] <atomnuker> sorry, did mean jdarnley [19:19:58 CET] <SortaCore> unknown option --disable-ffserver? [19:20:37 CET] <durandal_1707> SortaCore: whats issue? [19:21:01 CET] <SortaCore> well, my previous configure was set to build static, and enable all the programs except ffserver [19:21:18 CET] <SortaCore> I just git pulled from master, and now the configure isn't recognising --disable-ffserver [19:21:46 CET] <SortaCore> It's not listed under program options in --help, so was ffserver removed entirely? [19:23:42 CET] <kierank> yes [19:24:07 CET] <SortaCore> ok [19:24:20 CET] <SortaCore> and there's a severe lack of openh264 options, is anyone working on that [19:25:09 CET] <SortaCore> there's profile but no level, no preset, tune etc, and the profile doesn't list options in ffmpeg.exe -help like it does in some other h264 codecs [19:27:08 CET] <SortaCore> no crf option, although there are qpMin/Max available in openh264, they're not set at all in ffmpeg [19:27:47 CET] <SortaCore> there also seems to be a bitrate, and quality mode rate controls, but the encoder always uses quality [19:28:25 CET] <nevcairiel> noone cares about openh264, and neither should you [19:28:25 CET] <SortaCore> also a complexity mode, not sure what that's about [19:29:22 CET] <SortaCore> I don't want to GPL my code due to libx264 licensing :p [19:29:32 CET] <nevcairiel> openh264 is a super terrible encoder though [19:29:53 CET] <nevcairiel> it only supports one profile, so no options needed there, and level is just a function of bitrate and other properties, manually setting it makes no sense [19:31:04 CET] <SortaCore> I saw code inside openh264's repo that indicated it had support for main and high [19:31:22 CET] <SortaCore> but ignoring that, the other params should be there [19:31:29 CET] <SortaCore> no point half-supporting something [19:32:09 CET] <nevcairiel> feel free to make a patch [19:32:14 CET] <nevcairiel> dont expect anyone else to waste their life :) [19:32:17 CET] <SortaCore> https://github.com/cisco/openh264/wiki/TypesAndStructures#eprofileidc [19:32:23 CET] <BtbN> might as well just use mpeg2 instead [19:32:40 CET] <nevcairiel> just because it defiens those enums doesnt mean it actually does something with it [19:32:45 CET] <nevcairiel> the docs clearly state its features [19:32:46 CET] <SortaCore> ...how do you guys know if it's a bad encoder? [19:32:58 CET] <BtbN> by looking at what it produces [19:33:06 CET] <SortaCore> produces from what? [19:33:15 CET] <BtbN> video oO [19:33:42 CET] <SortaCore> yea, but what program is producing it? [19:34:23 CET] <nevcairiel> that thing comes with its own console encoder thing you can use to test it [19:36:50 CET] <SortaCore> I'll look into it [19:37:08 CET] <SortaCore> what's the style guide and patch how-to for git noobs [19:37:14 CET] <BtbN> openh264 was designed for video-conferencing without paying roaylities [19:37:31 CET] <BtbN> It originally only supported baseline h264 [19:37:44 CET] <BtbN> and even on high, which I doubt it actually supports fully, it looks terrible [19:39:06 CET] <nevcairiel> the only "main" feature it even supports is using cabac, no other features are supported as far as I can tell [19:40:35 CET] <SortaCore> atm I'm not particularly concerned with quality [19:40:52 CET] <BtbN> just use mpeg2 then [19:41:18 CET] <SortaCore> I am providing an interface for all the h264 codecs, and the parameters like preset, profile etc, if they're there in the codec, the user should be able to set them [19:41:47 CET] <BtbN> the presets are highly encoder specific. Or even highly x264 specific. Same for crf. [19:41:49 CET] <SortaCore> I don't want to deny level when it's available in the codec [19:42:42 CET] <SortaCore> so out of curiosity, what do people use instead of h264 for their non-gpl code? [19:42:52 CET] <SortaCore> *instead of openh264 [19:43:08 CET] <nevcairiel> nothing [19:43:15 CET] <BtbN> some commercial encoder probably. Or they decice not to care. [19:43:19 CET] <Gramner> commercially licensed x264 [19:43:21 CET] <nevcairiel> x264 is the only good h264 encoder [19:43:30 CET] <nevcairiel> which is not pure commercial [19:43:49 CET] <rcombs> are there good pure-commercial ones? [19:44:01 CET] <rcombs> I know some people use main concept for some reason [19:44:13 CET] <BtbN> There's a H264 encoder in Windows [19:44:18 CET] <SortaCore> well, qsv and nvenc don't require GPL do they? [19:44:26 CET] <SortaCore> although redistribution is a bit odd [19:44:26 CET] <BtbN> those are hardware encoders. [19:44:32 CET] <RiCON> mainconcept used to come close to x264 in those tests [19:44:49 CET] <BtbN> But really, I think pretty much everyone except Browsers use x264 [19:45:03 CET] <rcombs> there's a software encoder in macOS as well but iirc it's worse than the hardware encoder [19:45:21 CET] <rcombs> dunno whose it is originally, but I think it's the same one apple uses for everything and it's real bad [19:45:26 CET] <tmm1_> huh i didn't know x264 had commercial licensing options [19:45:26 CET] <rcombs> (e.g. iTunes) [19:45:41 CET] <rcombs> dunno if it's the same as Compressor Dot App uses [19:46:17 CET] <SortaCore> hardware or software aside, the qsv/nvenc aren't gpl? [19:47:08 CET] <rcombs> well you can use quicksync via VAAPI [19:47:26 CET] <rcombs> and there's a different QSV implementation that's MIT these days [20:59:55 CET] <SortaCore> so er, what's the style guide and patch how-to for git noobs [21:01:12 CET] <atomnuker> http://ffmpeg.org/developer.html#Contributing [21:57:34 CET] <j-b> Heya, who owns the DTS decoder in libavcodec? [21:59:43 CET] <wm4> foo86 [21:59:44 CET] <durandal_1707> j-b: me, for legal stuf contact trump [22:00:05 CET] <j-b> durandal_1707: seriously you? [22:00:08 CET] <j-b> wm4: ah, ok [22:01:27 CET] <durandal_1707> j-b: you got some letters? [22:01:45 CET] <j-b> durandal_1707: no, I want to give money for the DRC feature :) [22:02:08 CET] <durandal_1707> drc? [22:02:31 CET] <j-b> https://trac.ffmpeg.org/ticket/6803 [22:28:40 CET] <nevcairiel> You know most people would pay you to get a decoder which violates the spec and removes that anti-feature =p [22:30:06 CET] <j-b> nevcairiel: sure. [22:30:17 CET] <j-b> nevcairiel: does not mean some people don't want it [22:30:44 CET] <nevcairiel> The problem with that feature is that it depends on the bitstream and will vary widely from file to file [22:30:51 CET] <nevcairiel> if you want range compression, should do that on raw audio [22:31:16 CET] <j-b> nevcairiel: I don't think I argued for the usefulness of this feature. [22:31:48 CET] <j-b> if I did seem to, then sorry. [22:31:57 CET] <nevcairiel> Wanting to throw money at it is basically that, isnt it [22:32:05 CET] <j-b> nevcairiel: it is not. [22:32:07 CET] <nevcairiel> unless you're crazy and have too much money? I would take some [22:32:12 CET] <j-b> idiotic users are idiots: https://trac.videolan.org/vlc/ticket/19024 [22:32:22 CET] <j-b> and we receive donations from idiotic users [22:32:42 CET] <nevcairiel> those are not a binding contract [22:33:04 CET] <j-b> nevcairiel: sure, what bounty can you take care of? [22:34:06 CET] <j-b> https://wiki.videolan.org/Bounties#Libavcodec_features [22:34:30 CET] <j-b> (feel free to suggest new ones) [22:35:26 CET] <nevcairiel> we got speedhq these days, btw [22:35:56 CET] <j-b> nevcairiel: all versions? [22:35:59 CET] <j-b> nevcairiel: who did it? [22:36:03 CET] <nevcairiel> metasound too [22:36:07 CET] <nevcairiel> no idea how complete those are [22:36:09 CET] <nevcairiel> but they exist [22:36:20 CET] <durandal_1707> metasound is incomplete [22:36:31 CET] <j-b> IIRC, metasound was not complete, yes [22:36:52 CET] <j-b> I'm wondering when we will bump MVC to 10.000¬ [22:37:10 CET] <nevcairiel> anton was working on that, but i havent seen him in months [22:37:16 CET] <durandal_1707> mvc should die [22:37:40 CET] <nevcairiel> for speedhq, http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=2a293ec7ac72723b5f07aa… [22:37:48 CET] <nevcairiel> apparently even had support in implementing this from NewTek [22:37:59 CET] <nevcairiel> This decoder can decode all existing SpeedHQ formats (SHQ05, 7, and 9), [22:37:59 CET] <nevcairiel> including correct decoding of the alpha channel. [22:38:03 CET] <nevcairiel> or so it claims [22:38:20 CET] <j-b> ah, sure, Sesse [22:38:36 CET] <j-b> FICV? [22:39:00 CET] <durandal_1707> what? [22:39:20 CET] <j-b> "Mirillis' Action! tool (FICV codec)" [22:39:32 CET] <nevcairiel> we have a decoder for that, but again no clue how good [22:40:33 CET] <j-b> Sad! [22:40:37 CET] <nevcairiel> you would think at some point someone would invent the ultimate screen capture codec and we wouldnt have a new one every couple years [22:41:23 CET] <j-b> lol :) [22:41:55 CET] <durandal_1707> there is ultimate screen capture codec [22:42:05 CET] <j-b> x264? [22:42:26 CET] <durandal_1707> no [22:42:28 CET] <nevcairiel> probably too slow [22:44:50 CET] <durandal_1707> j-b: see fourcc SCPR, your vlc lavc code have issues with playing it [22:45:16 CET] <j-b> oh? [22:45:20 CET] <j-b> durandal_1707: thx for the pointer [22:45:38 CET] <j-b> ScreenPressor [22:47:22 CET] <durandal_1707> there is v3 of codec, need to finish it [22:47:25 CET] <jkqxz> ... whatever hardware encoder you can use directly on the GPU to capture the screen completely for free? CPU overhead sucks. [22:48:37 CET] <j-b> JPEG2K? [22:49:09 CET] <j-b> oh, btw, we would pay for a JP2K decoder on GPU [22:50:12 CET] <nevcairiel> that seems slightly unlikely [22:50:14 CET] <jkqxz> OpenCL? [22:50:20 CET] <jkqxz> Doesn't sound very fun. [22:50:25 CET] <nevcairiel> for someone to implement, i mean [22:51:01 CET] <j-b> jkqxz: yup [22:51:07 CET] <j-b> but it's easy to find 30K on that [22:52:41 CET] <nevcairiel> the dca DRC thing looks pretty trivial fwiw, read index from bitstream, lookup scale factor in table, scale samples after reconstruction [22:52:42 CET] <jkqxz> Does it actually have to be faster than a CPU? Making a shitty one would be reasonably straightforward, I think. [22:54:01 CET] <jkqxz> (I.e. is this meant to be for increased speed or just for offload.) [22:54:17 CET] <atomnuker> lol, j2k entropy encoding on the gpu [22:54:29 CET] <atomnuker> j2k has possibly the slowest designed entropy coder ever [22:54:48 CET] <jkqxz> Yep, hence the question :P [22:54:59 CET] <atomnuker> the transform and quantization are all doable on the gpu and the cpu but that's a thousand of the overhead and really not a problem [22:55:13 CET] <atomnuker> *thousanth [22:58:25 CET] <atomnuker> well, its doable on the GPU completely [22:58:45 CET] <atomnuker> you just need so many tiles that its pointless to call it compressed anymore [22:59:03 CET] <jkqxz> "decoder" ^ [22:59:07 CET] <j-b> jkqxz: decoding, not encoding [22:59:20 CET] <j-b> and, as far as I know, this is for 256 tiles [22:59:31 CET] <j-b> nevcairiel: yes, it is not hard to do, I believe. [22:59:47 CET] <nevcairiel> although perhaps a bit unclear how it interacts with HD extensions [23:02:13 CET] <atomnuker> j-b: could I have a sample? none of the 2 encoders support tile size setting [23:03:16 CET] <j-b> atomnuker: a sample of those JP2K crap? [23:03:28 CET] <atomnuker> yep [23:03:33 CET] <j-b> atomnuker: any DCP should have this [23:03:46 CET] <j-b> IIRC, blocks of 64x64 that are independent [23:03:55 CET] <j-b> I can check tomorrow. [23:03:57 CET] <nevcairiel> luckily i've only very rarely seen jp2k stuff, distributing DCPs has not come into fashion yet [23:04:10 CET] <atomnuker> I've been looking for a jp2k DCP for ages, I can't find one anywhere and I don't have any private tracker regs [23:04:22 CET] <atomnuker> I've got a dnxhd dcp though [23:04:26 CET] <j-b> atomnuker: https://streams.videolan.org/streams/DCP/ [23:04:44 CET] <j-b> atomnuker: and I got around 25 at the office, totally around 4TB of DCPs, if you want. [23:05:01 CET] <nevcairiel> i get the occasional request to handle the separate mono pcm streams from DCP though, i just tell them to bugger off, but shrug [23:05:01 CET] <j-b> latest FFmpeg + openjpeg 2.3.0 is getting quite good at decoding those ;) [23:05:07 CET] <atomnuker> of full movies? [23:05:16 CET] <j-b> atomnuker: the ones at the office, yes. [23:05:28 CET] <atomnuker> I need to find an excuse to go to paris [23:06:03 CET] <j-b> atomnuker: can I ask why do you care about DCP? :D [23:06:07 CET] Action: j-b is curious [23:06:18 CET] <j-b> (besides, it's fun :) [23:06:52 CET] <atomnuker> its the ultimate form of source material you can get for encoding, and its not staged to "push encoders to the limit", its real content [23:06:57 CET] <atomnuker> and because its rare :) [23:07:19 CET] <nevcairiel> lossy compressed formats, and he calls that ultimate [23:07:25 CET] <j-b> well, my problem is mostly that decoders and encoders for that are very expensive. [23:07:55 CET] <atomnuker> nevcairiel: BDs are worse [23:08:12 CET] <nevcairiel> obviously [23:08:22 CET] <nevcairiel> but lossless would be the real ultimate source [23:08:55 CET] <atomnuker> j-b: I might do a hybrid j2k decoder if I find it interesting, just to prove they have their use [23:09:35 CET] <j-b> atomnuker: well, my issue is that KAKADU is way faster than ffmpeg or ffmpeg+openjpeg [23:09:53 CET] <atomnuker> how much faster, in terms of fps? [23:09:57 CET] <durandal_1707> then make it faster [23:10:02 CET] <j-b> atomnuker: twice? [23:10:12 CET] <durandal_1707> instead of paying for drc [23:10:14 CET] <nevcairiel> the native jp2k decoder in ffmpeg is barely optimized at all [23:10:24 CET] <j-b> durandal_1707: I can pay for both :) [23:10:31 CET] <j-b> durandal_1707: DRC is probably 1000¬ [23:10:49 CET] <durandal_1707> j-b: drc should be 100 max [23:10:53 CET] <j-b> durandal_1707: JP2K XYZ decoder on GPU or hybrid would be around 30k¬ [23:10:59 CET] <nevcairiel> 1000 for such a simple feature? [23:11:07 CET] <nevcairiel> how much do idiot users donate? :p [23:11:14 CET] <j-b> nevcairiel: depends. [23:11:19 CET] <j-b> usually 4¬ [23:11:23 CET] <j-b> sometimes 0.3 BTC [23:11:41 CET] <j-b> durandal_1707: nevcairiel: ok, let's say 500¬, ok? [23:11:57 CET] <nevcairiel> maybe i should've just shutup and just build it [23:12:19 CET] <durandal_1707> lol, we are on wrong side of shop [23:12:24 CET] <j-b> no. [23:12:42 CET] <j-b> Selling to B2B can make a shitload more money [23:13:00 CET] <j-b> nevcairiel: durandal_1707: seriously guys, if there are some features that can benefit us, we can add bounties. [23:13:48 CET] <durandal_1707> j-b: there is even j2k unmentored project [23:13:51 CET] <nevcairiel> if you find me some magic dolby spec i will fix truehd+atmos bitstreaming, but dolby hides their specs well :( [23:14:34 CET] <Chloe> j-b: any bounties for rewriting lavd to be a useful library? [23:15:06 CET] <durandal_1707> lol, thats vlc job [23:15:06 CET] <j-b> Chloe: sorry, no, since we don't care yet about lavd [23:15:21 CET] <Chloe> shame [23:15:22 CET] <j-b> Chloe: libavfi, probably [23:15:28 CET] <j-b> but lavd, not yet [23:15:40 CET] <Chloe> libavfi? [23:15:46 CET] <Chloe> libav's lavfi? [23:15:52 CET] <j-b> ffmpeg libavfilter [23:16:06 CET] <j-b> dunno the official shortname :) [23:16:08 CET] <Chloe> what do you need for lavfi [23:16:19 CET] <j-b> Chloe: because filters are fun [23:16:33 CET] <j-b> nevcairiel: weren't you the one mentionning EAC3->AC3 simple conversino? [23:16:47 CET] <durandal_1707> lavfi hhave more than 300 filters, its enough [23:16:55 CET] <nevcairiel> j-b: nah that wasnt me [23:17:04 CET] <j-b> nevcairiel: sorry then [23:17:15 CET] <Chloe> j-b: 'libVLC API for filters' this? [23:17:28 CET] <j-b> Chloe: libavfi module inside vlc [23:18:40 CET] <j-b> 451779 12:47 <+kierank> j-b: yes there are optional "aids" in the bitstream for set top boxes to transcode [23:18:46 CET] <Chloe> it doesnt matter actually, I dont have the hardware to compile vlc [23:18:58 CET] <j-b> <+kierank> j-b: it's in the spec somewhere, libavcodec skips over the field [23:19:04 CET] <j-b> nevcairiel: indeed, it was kierank [23:19:16 CET] <j-b> anyway, that is a feature that we could pay for too. [23:19:27 CET] <j-b> Chloe: ah? [23:19:32 CET] <kierank> pffft j2k [23:19:41 CET] <durandal_1707> Chloe: what? toaster? ask carl some money [23:19:46 CET] <Chloe> j-b: if you ever want lavd to be useful, hmu [23:19:57 CET] <j-b> Chloe: ok [23:20:11 CET] <durandal_1707> Chloe: we have money too [23:20:38 CET] <Chloe> durandal_1707: yes, I have a toaster with a 1060 :-) [23:20:46 CET] <Chloe> I think my CPU is actually faulty [23:21:00 CET] <j-b> Also, if some people like pain, I have requests on mp4 metadata... [23:26:25 CET] <Chloe> durandal_1707: we lack bounties though [23:27:08 CET] <kierank> durandal_1707: and libavfilter sucks [23:27:55 CET] <wm4> *dramatic music* [23:28:21 CET] <kierank> DONT INSULT THE GLORIOUS LEAD^H^H FFMPEG PROJECT [23:29:06 CET] <j-b> Chloe: would people be more interested in bounties if they were in BTC? [23:29:25 CET] <nevcairiel> personally i would be less interested =p [23:30:12 CET] <durandal_1707> kierank: thank you for your contributions to lavfi [23:30:21 CET] <kierank> api sucks [23:30:29 CET] <kierank> usable only from ffmpeg cli to printf nice values [23:30:29 CET] <j-b> still, interested I am, for this stupid DRC and for EAC3->AC3 [23:30:45 CET] <j-b> in addition to new codecs [23:31:26 CET] <durandal_1707> j-b: btc is dead [23:31:40 CET] <j-b> durandal_1707: I know, right> [23:33:01 CET] <wm4> even I have some severe issues with lavfi's API [23:33:22 CET] <Chloe> j-b: i doubt it [23:33:37 CET] <Chloe> and by 'we' i meant ffmepg themselves [23:39:38 CET] <wm4> tmm1_: do you remember who our effective hls.c maintainer is? [23:43:34 CET] <durandal_1707> carl [23:54:23 CET] <tmm1_> i'm not sure [00:00:00 CET] --- Thu Jan 25 2018

1 0

ffmpeg.log.20180124
by burek 25 Jan '18

25 Jan '18

[00:00:06 CET] <GyrosGeier> that's not exactly 24 hours, is it? [00:00:14 CET] <JEEB> somewhat over 26 or so? [00:00:25 CET] <GyrosGeier> mmh [00:00:41 CET] <GyrosGeier> my point is, does concat correct timestamps in consecutive files? [00:00:55 CET] <JEEB> which concat? :D [00:01:05 CET] <alexpigment> haha [00:01:10 CET] <JEEB> filter, demuxer, input thing? [00:01:15 CET] <JEEB> last one was protocol [00:01:24 CET] <GyrosGeier> hmmk [00:01:33 CET] <JEEB> because yes, everyone implemented concatenation on their own level for their own use case [00:01:44 CET] <alexpigment> i want to say demuxer does.. [00:02:17 CET] <alexpigment> or tries [00:02:25 CET] <kepstin> concat filter does a reasonable job of giving you correct timestamps, assuming all the input videos start at 0 [00:02:29 CET] <JEEB> yea [00:02:36 CET] <JEEB> the filter I think is the least insane one [00:02:40 CET] <alexpigment> well, right [00:02:41 CET] <JEEB> since it only deals with decoded stuff [00:02:56 CET] <alexpigment> if you're not re-encoding though, i think demuxer is better than protocol [00:03:12 CET] <alexpigment> if you're re-encoding, filter is always best [00:03:25 CET] <JEEB> no idea, all of them have sounded like "they work for my use case" things. and if they work for you, congratulations [00:03:35 CET] <alexpigment> well, they work until they don't [00:03:40 CET] <alexpigment> and that is a certainty [00:03:43 CET] <JEEB> yup [00:04:02 CET] <JEEB> I just see quite often people complaining that mp4 concatenation f.ex. doesn't work [00:04:20 CET] <JEEB> concatenation I think might have been worth it doing on the API client level [00:04:26 CET] <alexpigment> well, it doesn't, but i think it's because people expect magic out of something that is imperfect by nature [00:04:35 CET] <JEEB> ayup [00:04:42 CET] <alexpigment> videos are made weirdly, and ffmpeg just kinda deals with that as best it can [00:04:54 CET] <JEEB> no, the videos are OK. [00:04:59 CET] <kepstin> so, anyways, time to change AV_TIME_BASE to facebook flicks? (hah) [00:05:04 CET] <JEEB> kepstin: NO [00:05:06 CET] <JEEB> lol [00:05:23 CET] <JEEB> I really liked their "we're not even going to try to support the /1.001 rates" thing [00:05:35 CET] <alexpigment> ? [00:05:39 CET] <alexpigment> i didn't see this news [00:05:59 CET] <JEEB> alexpigment: they pushed a huge PR stunt about finding the least common denominator between a lot of audio and video rates [00:05:59 CET] <kepstin> JEEB: the hilarious thing is that they accidentally supported the /1.001 rates [00:06:19 CET] <JEEB> kepstin: huh? [00:06:30 CET] <kepstin> (i have a pull request against it to fix the docs to say that it does the ntsc rates fine) [00:06:35 CET] <JEEB> well the number is rather large so I wouldn't be surprising [00:06:38 CET] Action: GyrosGeier is building a CPU in VHDL that supports fractionals natively [00:06:39 CET] <JEEB> *surprised [00:06:49 CET] <kepstin> the number divides by 120000, so yeah [00:07:26 CET] <JEEB> but yes, congratulations to facebook for finding a common denominator :D [00:07:41 CET] <kepstin> they found it via brute force! they didn't even use a gcd function! [00:08:19 CET] <JEEB> lol [00:14:33 CET] <alexpigment> GyrosGeier: sounds cool. this is for an FPGA? [00:16:36 CET] <GyrosGeier> CPLD, for a CNC mill controller that gets lots of PWM input signals and needs to convert them to PWM outputs [00:16:42 CET] <alexpigment> ah [00:16:43 CET] <alexpigment> nice [01:30:01 CET] <x__> Can you give me a hand with ffmpeg? [01:30:08 CET] <x__> I'm getting an error with this command [01:30:09 CET] <x__> C:\Users\x\Videos>ffmpeg -i saída_parte_1.mp4 -i saída_parte_2.mp4 -i saída_part [01:30:09 CET] <x__> e_3.mp4 -i saída_parte_4.mp4 -filter_complex "[0:v:0][1:v:0][2:v:0][3:v:0]concat [01:30:09 CET] <x__> =n=4:v=1:[outv]" -vf scale=1920:1080 output.avi [01:30:33 CET] <x__> Filter concat has an unconnected output [01:30:40 CET] <x__> What is unconnected there? [01:32:53 CET] <furq> x__: either get rid of [outv] or add -map "[outv]" [01:33:05 CET] <furq> if you add a labelled output then you need to explicitly map it [01:33:12 CET] <furq> (or send it to another filter) [01:33:33 CET] <x__> furq, what is a labeled output? [01:33:43 CET] <furq> in that command, [outv] [01:34:03 CET] <x__> yes [01:34:59 CET] <x__> Filtergraph 'scale=1920:1080' was specified through the -vf/-af/-filter option for output stream 0:0, which is fed from a complex filtergraph. -vf/-af/-filter and -filter_complex cannot be used together for the same stream. [01:35:05 CET] <x__> furq, that is what I get now [01:35:11 CET] <furq> oh right i didn't read that far [01:35:20 CET] <x__> What do I use now? [01:35:35 CET] <furq> add ",scale=1920:1080" to the end of filter_complex [01:35:45 CET] <furq> and remove -vf obv [01:36:03 CET] <x__> furq, why? [01:36:16 CET] <x__> Is this a parameter specific to -filter_complex? [01:36:18 CET] <furq> like the error says, you can't have -vf and -filter_complex [01:37:07 CET] <x__> Now I'm getting yet another error [01:37:58 CET] <x__> furq, https://pastebin.com/UZbk10gX [01:38:50 CET] <kepstin> x__: you have to re-arrange your complex filterchain to apply the scale to the correct video stream before doing the concat. [01:39:07 CET] <furq> uh [01:39:09 CET] <x__> kepstin, Oh? [01:39:12 CET] <furq> concat,scale works fine here [01:39:21 CET] <x__> Ok, I'm confused [01:39:34 CET] <kepstin> the error is that there's a 720p and a 1080p video being fed into concat [01:39:39 CET] <furq> are all your inputs the same size [01:39:40 CET] <furq> yeah [01:39:51 CET] <furq> nvm i see what you're saying now [01:40:05 CET] <furq> if your inputs are different sizes then you need to scale before concat [01:41:42 CET] <x__> furq, So I can't scale on the fly? [01:42:09 CET] <kepstin> you can, you just have to put the scale filter earlier in the filter graph [01:42:13 CET] <kepstin> so something like '[0:v]scale=1920:1080[blah];[blah][1:v][2:v][3:v]concat=n=4:v=1:a=0' [01:42:18 CET] <furq> yeah what he said [01:44:44 CET] <x__> C:\Users\x\Videos>ffmpeg -i saída_parte_1.mp4 -i saída_parte_2.mp4 -i saída_part [01:44:44 CET] <x__> e_3.mp4 -i saída_parte_4.mp4 -filter_complex "[0:v:0]scale=1920:1080[1:v:0]scale [01:44:44 CET] <x__> =1920:1080[2:v:0]scale=1920:1080[3:v:0]scale=1920:1080 concat=n=4:v=1",scale=192 [01:44:44 CET] <x__> 0:1080 output.avi [01:45:08 CET] <x__> furq, I'm applying to each input because each seems to be a different resolution for some reason [01:45:38 CET] <x__> But now I get [01:45:39 CET] <x__> [AVFilterGraph @ 000000000702c880] Unable to parse graph description substring: [01:45:40 CET] <kepstin> x__: that's not the correct syntax, you need to do something similar to what I did in my example [01:45:54 CET] <x__> oh [01:45:58 CET] <x__> kepstin, what is the difference? [01:46:06 CET] <furq> you need labelled outputs in this case [01:46:17 CET] <x__> ok [01:46:35 CET] <x__> furq, and where do they go? What are labeled outputs? [01:47:04 CET] <kepstin> x__: anything in [] is a label. If it's after a filter, it's an output, if it's before a filter it's an input. [01:47:04 CET] <furq> [0:v]scale=1920:1080[tmp0];...;[tmp0][tmp1][tmp2][tmp3]concat [01:47:15 CET] <x__> oh [01:47:53 CET] <kepstin> if [] is inbetween two filters, it's a syntax error :) [01:48:17 CET] <kepstin> you use ; to separate independent parts of the filter chain [01:48:35 CET] <furq> , connects one filter's output to the next filter's input [01:48:53 CET] <furq> in cases where you can't do that you need explicitly labelled outputs that you can use as inputs [01:48:53 CET] <x__> Like this? [01:48:56 CET] <x__> [AVFilterGraph @ 000000000702c880] Unable to parse graph description substring: [01:48:59 CET] <x__> Sorry [01:49:12 CET] <x__> C:\Users\x\Videos>ffmpeg -i saída_parte_1.mp4 -i saída_parte_2.mp4 -i saída_part [01:49:12 CET] <x__> e_3.mp4 -i saída_parte_4.mp4 -filter_complex "[0:v]scale=1920:1080[tmp0][1:v]sca [01:49:12 CET] <x__> le=1920:1080[tmp1][2:v]scale=1920:1080[tmp3][3:v]scale=1920:1080[tmp4] concat=n= [01:49:12 CET] <x__> 4:v=1",scale=1920:1080 output.avi [01:49:23 CET] <furq> you're missing the ;s [01:49:40 CET] <furq> you're also missing the end quote [01:49:58 CET] <kepstin> nah, the end quote's there, but there's an extra scale on the end that's not doing anything useful [01:50:11 CET] <furq> oh right yeah [01:50:44 CET] <x__> Like this? [01:50:45 CET] <x__> C:\Users\x\Videos>ffmpeg -i saída_parte_1.mp4 -i saída_parte_2.mp4 -i saída_part [01:50:45 CET] <x__> e_3.mp4 -i saída_parte_4.mp4 -filter_complex "[0:v];scale=1920:1080[tmp0][1:v];s [01:50:45 CET] <x__> cale=1920:1080[tmp1][2:v];scale=1920:1080[tmp2][3:v];scale=1920:1080[tmp3] conca [01:50:45 CET] <x__> t=n=4:v=1" output.avi [01:51:55 CET] <furq> [tmp0];[1:v] [01:51:55 CET] <furq> etc [01:52:19 CET] <furq> tmp0 is the output of the first scale, 1:v is the input to the second scale [01:52:53 CET] <x__> C:\Users\x\Videos>ffmpeg -i saída_parte_1.mp4 -i saída_parte_2.mp4 -i saída_part [01:52:53 CET] <x__> e_3.mp4 -i saída_parte_4.mp4 -filter_complex "[0:v];scale=1920:1080[tmp0][1:v];s [01:52:54 CET] <x__> cale=1920:1080[tmp1][2:v];scale=1920:1080[tmp2][3:v];scale=1920:1080[tmp3] conca [01:52:54 CET] <x__> t=n=4:v=1" output.avi [01:52:57 CET] <x__> Like this then [01:52:59 CET] <x__> ? [01:53:05 CET] <furq> that's the same thing you pasted before [01:53:13 CET] <x__> crap [01:53:55 CET] <x__> https://nopaste.linux-dev.org/?1172794 [01:54:07 CET] <furq> http://vpaste.net/JzdWV [01:55:45 CET] <x__> furq, Now I get: [01:56:00 CET] <x__> Cannot find a matching stream for unlabeled input pad 0 on filter Parsed_concat_ [01:56:01 CET] <x__> 4 [01:56:36 CET] <kepstin> x__: please repaste the exact command you just ran. [01:56:42 CET] <x__> Ok [01:57:42 CET] <x__> kepstin, https://nopaste.linux-dev.org/?1172796 [01:57:57 CET] <furq> you've not given concat any inputs [01:58:03 CET] <kepstin> x__: that's not what furq told you to do :/ [01:58:30 CET] <x__> oh [01:58:33 CET] <x__> there's a bit missing there [01:58:42 CET] <x__> [tmp0][tmp1][tmp2][tmp3]concat=n=4:v=1" -> this [01:58:43 CET] <x__> right? [01:58:47 CET] <furq> yeah [01:58:55 CET] <kepstin> yes, the list of inputs for the concat filter is missing. [01:59:21 CET] <x__> Oh, ok [01:59:39 CET] <x__> Ok, now I just need to know how to speed up the video [02:00:12 CET] <kepstin> does the video also have sound that you want to keep in sync when you speed it up? [02:00:27 CET] <furq> http://vpaste.net/vCAdA [02:00:35 CET] <furq> 0.5 will double the speed, change that as needed [02:00:57 CET] <furq> i assume there's no audio since that's not being passed to concat, but if there is then you'll need to use atempo as well [02:01:56 CET] <x__> furq, I can also use the syntax PTS/factor, right? [02:02:00 CET] <x__> I need this 288 times faster [02:02:05 CET] <furq> sure [02:02:17 CET] <x__> Awesome :) [02:02:47 CET] <furq> you're obviously going to end up with a video that's like 8000fps [02:02:57 CET] <x__> furq, Works for me [02:03:00 CET] <furq> fair enough [02:03:03 CET] <x__> furq, this video is 48 hours long [02:03:04 CET] <x__> lol [02:03:11 CET] <x__> I want to shorten to 10 minutes [02:03:17 CET] <x__> It's a timelapse [02:03:22 CET] <furq> you can add ,fps=30 to the end of that if you want a proper timelapse [02:03:37 CET] <x__> can I use fps=60? [02:03:39 CET] <furq> sure [02:03:51 CET] <furq> i'm not really sure how a player will deal with an 8000fps video but the answer's probably not "well" [02:04:48 CET] <x__> furq, So fps=60 makes sure that's properly readable, right? [02:04:57 CET] <furq> it'll just drop most of the frames [02:05:06 CET] <furq> so yeah [02:05:17 CET] <x__> furq, Should I do anything else here? [02:05:25 CET] <furq> not that i can see [02:05:43 CET] <x__> How long does this take? [02:05:46 CET] <furq> probably a long time [02:06:07 CET] <x__> More than a day? [02:06:21 CET] <furq> depends on your cpu [02:06:29 CET] <x__> Core i7 4470 [02:06:32 CET] <furq> most of the frames will be dropped before encoding so it shouldn't be that bad [02:06:44 CET] <kepstin> hmm, but all of the frames are gonna be scaled [02:06:47 CET] <furq> yeah [02:06:54 CET] <kepstin> doing the speeding up before the scale might help there. [02:07:13 CET] <furq> i was hoping to avoid making the filtergraph more complicated lol [02:07:22 CET] <kepstin> yeah, i can see that :) [02:07:35 CET] <x__> kepstin, so where do I put the speeding up? [02:07:51 CET] <furq> remove setpts and fps from the end [02:07:54 CET] <furq> and put it before each scale [02:08:15 CET] <furq> so setpts,fps,scale [02:08:20 CET] <furq> once for each scale [02:09:47 CET] <x__> Like this? [02:09:47 CET] <x__> ffmpeg -i sa¡da_parte_1.mp4 -i sa¡da_parte_2.mp4 -i sa¡da_parte_3.mp4 -i sa¡da_parte_4.mp4 -filter_complex "[0:v]scale=1920:1080[tmp0];[1:v]setpts=PTS/288,fps=60,scale=1920:1080[tmp1];[2:v]setpts=PTS/288,fps=60,scale=1920:1080[tmp2];[3:v]setpts=PTS/288,fps=60,scale=1920:1080[tmp3]; [tmp0][tmp1][tmp2][tmp3]concat=n=4:v=1" output.avi [02:09:58 CET] <x__> OMG, it's a monster :P [02:10:39 CET] <furq> you missed the first one [02:11:52 CET] <x__> furq, fixed [02:12:00 CET] <x__> I just checked the quality of the aborted file [02:12:03 CET] <x__> it's so bad :P [02:12:47 CET] <x__> furq, Am I doing anything wrong? [02:13:11 CET] <kepstin> x__: you're not specifying any output codec or options, and you're using avi so the default codec is bad. [02:13:30 CET] <x__> kepstin, What should I do? [02:13:43 CET] <x__> I want to preserve as much of the original quality as possible [02:13:48 CET] <kepstin> x__: I recommend switching the output to mkv or mp4, which will also switch the default codec to h264 (x264) [02:13:57 CET] <x__> ok [02:14:00 CET] <kepstin> x__: then you can start looking at encoder options to set quality. [02:14:31 CET] <x__> kepstin, How do I do that? [02:14:35 CET] <kepstin> x__: with the libx264 codec, you set quality by saying "--crf 24" [02:14:41 CET] <kepstin> change the number lower for higher quality [02:14:56 CET] <x__> Can I use 0? [02:14:57 CET] <kepstin> 24 is a sort of medium default [02:15:10 CET] <kepstin> x__: yes, but that usually means lossless and your file will be huge [02:15:34 CET] <furq> just run it with the defaults and see if it looks good enough to you [02:15:36 CET] <x__> It'll be a 10 min file, so it works for me [02:15:36 CET] <kepstin> I recommend values around 18-25, you'll have to try some and see what they look like [02:15:42 CET] <furq> if it's a bit blocky then drop to -crf 20 or so [02:16:05 CET] <furq> 23 is the default which is reasonably good [02:16:17 CET] <x__> ok, so -f libx264? [02:16:29 CET] <furq> -c:v libx264 but you don't need to set that if the output file is mp4 [02:17:54 CET] <x__> And where do I put -crf 20? [02:18:14 CET] <furq> before the output filename [02:19:46 CET] <x__> ok [02:21:39 CET] <x__> C:\Users\x\Videos>ffmpeg -i saída_parte_1.mp4 -i saída_parte_2.mp4 -i saída_parte_3.mp4 -i saída_parte_4.mp4 -filter_complex "[0:v]setpts=PTS/288,fps=60,scale=1920:1080[tmp0];[1:v]setpts=PTS/288,fps=60,scale=1920:1080[tmp1];[2:v]setpts=PTS/288,fps=60,scale=1920:1080[tmp2];[3:v]setpts=PTS/288,fps=60,scale=1920:1080[tmp3]; [tmp0][tmp1][tmp2][tmp3]concat=n=4:v=1" -crf 15 output.mp4 [02:21:42 CET] <x__> So this should work [02:21:43 CET] <x__> Correct? [02:22:20 CET] <furq> looks ok to me [02:22:53 CET] <x__> Still blocky :/ [02:24:14 CET] <SortaCore> scale ya say [02:24:49 CET] <furq> http://vpaste.net/Kwwe5 [02:24:53 CET] <furq> in case you were wondering how dumb filterchains can get [02:25:19 CET] <x__> furq, Please exorcise that from my life :P [02:25:40 CET] <x__> Demon begone [02:25:53 CET] Last message repeated 1 time(s). [02:25:53 CET] <SortaCore> I'll have you know I was invited here [02:26:08 CET] <x__> SortaCore, I was talking about the complex filterchain :P [02:26:21 CET] <SortaCore> _whoosh_ [02:26:40 CET] <furq> i'm sure other people in here have even stupider filterchains [02:27:01 CET] <x__> furq, Even setting cbr to 0 makes the final video a bit blocky [02:27:06 CET] <x__> Is there anything else I can do? [02:27:12 CET] <furq> what are you watching it with [02:27:26 CET] <x__> *crf [02:27:38 CET] <x__> Eh [02:27:41 CET] <x__> windows media player [02:27:51 CET] <furq> try it with mpv or something [02:28:10 CET] <x__> furq, still grainy [02:28:11 CET] <SortaCore> try with BlockyVideoPlayer" [02:28:17 CET] <x__> SortaCore, lol [02:28:37 CET] <x__> this can't be right [02:29:07 CET] <SortaCore> is crf suitable for all resolutions? [02:29:14 CET] <furq> i don't understand the question [02:29:30 CET] <relaxed> but the answer is yes [02:29:47 CET] Action: SortaCore scribbles out 42 [02:30:31 CET] <x__> I just checked the aborted encoding from VSDC [02:30:36 CET] <x__> It's significantly better [02:30:48 CET] <x__> I think I'm missing out something [02:30:54 CET] <furq> if you're trying to watch it while it's still encoding then that won't work properly with mp4 [02:31:20 CET] <x__> furq, Nope, I aborted it at 00:24 [02:31:25 CET] <x__> (24 minutes) [02:31:31 CET] <x__> Just to check the quality [02:31:43 CET] <SortaCore> he means with ffmpeg's encodings [02:31:45 CET] <furq> i'm not entirely sure if that'll work [02:31:52 CET] <furq> try it with mkv instead of mp4 [02:31:59 CET] <furq> that should actually work if it doesn't complete properly [02:32:17 CET] <x__> mkv is also lossless, right? [02:32:36 CET] <furq> it'll be the same as mp4 [02:32:49 CET] <x__> furq, still grainy :/ [02:33:01 CET] <furq> shrug [02:33:05 CET] <furq> crf 0 should look identical to the input [02:33:14 CET] <x__> furq, It isn't though [02:33:15 CET] <SortaCore> maybe your inputs are grainy [02:33:20 CET] <x__> SortaCore, nope, just checked [02:33:29 CET] <x__> Maybe it's the scaling in each input [02:33:37 CET] <SortaCore> maybe your compy can't keep up with the amount of data? [02:33:46 CET] <furq> maybe add -sws_flags lanczos [02:33:56 CET] <x__> SortaCore, Then VSDC should also produce crappy input [02:34:02 CET] <furq> bicubic scaling shouldn't give blocky output though [02:34:07 CET] <furq> it'd just be a bit soft [02:34:47 CET] <SortaCore> x__: not if it handles it a different way [02:35:19 CET] <x__> I just checked [02:35:26 CET] <x__> this time it ran for 60 minutes of data [02:35:33 CET] <x__> And the output is 36 mb [02:35:41 CET] <x__> So this suggests there's some heavy compression going on [02:35:59 CET] <SortaCore> lookahead? [02:36:18 CET] <furq> that's only about 15 seconds of output isn't it [02:36:26 CET] <x__> Less than that [02:36:36 CET] <furq> well yeah that seems reasonable then [02:37:01 CET] <x__> furq, not if you consider that there's some heavy degradation in image quality [02:37:05 CET] <furq> pastebin the full command and output up until the status line [02:37:26 CET] <x__> Ok [02:38:18 CET] <x__> Running it now with the new flag [02:41:00 CET] <x__> furq, https://nopaste.xyz/?4ee80afabe1b4f33#gGdZ8fBQkibpJFKvI+mb6/j2UwEoeRGRJ/feQ… [02:41:13 CET] <x__> Windows' prompt can't store everything, so I apologize [02:43:04 CET] <x__> furq, Anything suspicious? [02:45:38 CET] <Diag> x__: only the curiously strong flavor of new altoids gum [02:51:16 CET] <x__> furq, Any clue? [03:00:57 CET] <x__> Anyone? [03:30:44 CET] <SortaCore> subnautica livestream time [03:33:59 CET] <x__> furq, I noted something [03:34:09 CET] <x__> That I was checking the wrong file :P I was always checking the avi [03:34:21 CET] <x__> now I'm checking the mkv file I'm generating and I'm getting a blank file [03:46:04 CET] <c3r1c3-Win> Was the RTMP server removed from FFMPEG? [03:49:15 CET] <pagenoare> hello. Im struggling with some issue. When I add a silent audio stream to the video via: ffmpeg -y -i input.mp4 -f lavfi -i aevalsrc=0 -c:v libx264 -crf 19 -preset slow -pix_fmt yuv420p -shortest output.mp4 I found something odd. The start: value changes to 0.036281. Why does it happen? [04:40:38 CET] <SortaCore> anyone have a libopenh264 library build guide? [06:19:25 CET] <SortaCore> I got libopenh264 built easily enough (just make with some params), but ffmpeg's pkg-config can't find it [06:19:43 CET] <SortaCore> I did make and make install with correct archs/os params [06:20:02 CET] <SortaCore> and I can see the pc file in the right place [08:09:09 CET] <TaZeR> is "winff" a legit gui for ffmpeg? [10:26:02 CET] <Megabyte> hello [10:26:09 CET] <Megabyte> I managed to get ffmpeg running [10:26:24 CET] <Megabyte> but after processing 11 hours of input, it'll freeze my computer [10:26:32 CET] <Megabyte> I tried /set affinity, but it doesn't work [10:26:38 CET] <Megabyte> what should I do? [10:37:08 CET] <Megabyte> bencoh, h4llo [11:10:36 CET] <androbod> hi guys! Is there any way to see HLS tags during ffmpeg process, if we have HLS on input ? [13:04:54 CET] <XoXFaby> I have a problem and I think I can solve it using ffmpeg but I don't know if it's the best idea [13:04:59 CET] <XoXFaby> So I wanted to ask for input here [13:05:43 CET] <XoXFaby> I am trying to store frames for a timelapse, but just storing the image alone would use massive amounts of space. So I had this idea to instead continously add the frames at the end of a video file using ffmpeg [13:06:22 CET] <XoXFaby> since that way I can take advantage of compression based on previous frames [13:06:35 CET] <XoXFaby> which should massively cut down on size on a landscape timelapse [13:07:23 CET] <XoXFaby> The process should basically be the same as encoding a video except instead of doing it all in one go I'm adding a frame every second or every 10 seconds [13:07:34 CET] <XoXFaby> Can I use FFMPEG for this and is this a good idea? [13:10:14 CET] <kikobyte> Hi BtbN, I'm currently looking into an issue with h264_nvenc, what happens is I'm getting intermittent segmentation fault in avcodec_encode_video2 -> ff_nvenc_encode_frame -> process_output_surface. Any chance you've seen that since August? [13:10:50 CET] <BtbN> Nope, I'm not aware of any crashes in there. [13:11:39 CET] <BtbN> Also, runtime resolution changes are not supported at all by ffmpeg.c for hardware formats. [13:12:02 CET] <BtbN> Encoders do not support changing resolution at runtime, that's why it inserts the scaler. [13:12:28 CET] <BtbN> The branch you linked is just old, ffmpeg.c was patched to not have that anymore, because it only masks a much deeper issue you have then. [13:12:37 CET] <kikobyte> BtbN, indeed, when that happens, it is after the graph was re-built, yet the resolution of nvenc is still the same. Still it works for most cases [13:12:57 CET] <BtbN> it's the same because you just so happen to have a scaler in your custom chain [13:13:04 CET] <BtbN> ffmpeg.c has no possible way to know that [13:13:22 CET] <BtbN> And it also causes a bunch of other issues, because the hw_frames_ctx changes, and it not exploding over that is pure luck [13:13:42 CET] <kikobyte> BtbN, yeah, I'm inserting the scaler exactly for that purpose [13:15:02 CET] <kikobyte> Could it be somehow related to the number of surfaces? I saw a commit which increases their count [13:16:06 CET] <BtbN> I doubt it [13:16:13 CET] <BtbN> Surface count was increased? [13:16:27 CET] <BtbN> Only thing I remember is decreasing the amount of surfaces in cuvid to the minimum [13:17:14 CET] <kikobyte> + int nb_surfaces = FFMAX(4, ctx->encode_config.frameIntervalP * 2 * 2);, was nb_surfaces = 0 [13:18:43 CET] <kikobyte> And then for rc_lookahead case it's being maxed against the old value. [13:20:35 CET] <kikobyte> Even though the commit (https://github.com/FFmpeg/FFmpeg/commit/8de3458a07376b0a96772e586b6dba5e934…) is indeed about reducing the number of surfaces [13:26:36 CET] <kikobyte> BtbN, what happens when the new resolution comes through the decoder and the gpu scale filter is being re-initialized (yet still producing the same output dimensions)? Does it affect the nvenc encoder in any way? Can it be so that the encoder is being reconfigured or something like that? [13:27:05 CET] <BtbN> In the worst case, it creates a new CUDA context, and nvenc won't be able to read the frames anymore [13:27:21 CET] <BtbN> a crash from the driver is what I'd expect to happen then [13:27:40 CET] <kikobyte> Who creates the context? [13:28:05 CET] <BtbN> Ideally the external API user and supplies it using a hw_device_context [13:28:20 CET] <BtbN> but ffmpeg.c is a bit special and the filter-re-init-code is not made with hw accel in mind at all [13:28:33 CET] <JEEB> ffmpeg.c is a bit "special" indeed [13:29:11 CET] <kikobyte> I remember I saw a diagnostic message that a cuvid context is being re-initialized - happens when the decoder gets new sps/pps with different dimensions [13:29:12 CET] <BtbN> if you want to be safe, put a hwdownload,format=nv12 after your scaler. That will feed nvenc software-frames and the ffmpeg_filters.c code will be able to work correctly [13:29:20 CET] <kikobyte> through cuvid_init I guess [13:29:40 CET] <kikobyte> I tried doing that, but I got freezes [13:29:59 CET] <BtbN> you should also try to use nvdec instead of cuvid, it should behave more sane as it's a native hwaccel [13:30:17 CET] <utack> XoXFaby if i were you i'd buffer something like 50 images lossless, encode them in a block, and then append them to a mkv [13:30:26 CET] <kikobyte> ...which I presume came later than 3.3? [13:30:35 CET] <utack> not saying this is THE solution, but it is a simple one [13:30:38 CET] <BtbN> It's in master [13:30:48 CET] <kikobyte> Yeah, expected that [13:31:28 CET] <XoXFaby> utack: that sounds doable. [13:31:33 CET] <XoXFaby> I'm doing this on a raspberry pi [13:32:01 CET] <XoXFaby> right now I'm taking the pictures as jpegs [13:32:09 CET] <Megabyte> Hello [13:32:16 CET] <Megabyte> I'm having a SERIOUS problem with ffmpeg [13:32:30 CET] <Megabyte> I can't get it to transcode very large amounts of data [13:32:30 CET] <utack> i guess you can buffer between 20-50 as bmp XoXFaby and then use x264? [13:32:44 CET] <Megabyte> after around 11 hours of transcoded data, it crashes my whole system with it [13:32:46 CET] <Megabyte> can you help me? [13:34:17 CET] <XoXFaby> hmm [13:34:49 CET] <kikobyte> BtbN, you suggestion to put frames through the hwdownload-format slowed fps roughly from 170 to 60, kind of expected given that pci-e gets extra load... [13:35:20 CET] <BtbN> nvidia is usually quite fast with that [13:35:28 CET] <XoXFaby> utack: I'm also concerned with the ability to later grab different portions of the data at different "framerates" [13:35:37 CET] <BtbN> unless you are operating a crazy loads, you shouldn't notice any impact [13:35:50 CET] <XoXFaby> i.e. if I record a day of video like this I wanna be able to grab 10 minutes worth of frames but also 6 hours worth of frames at 30 fps [13:36:28 CET] <kikobyte> Not that fast as it's usually requried. I was writing half a year ago a full gpu pipeline in DS with nv decoder / my own formatters / nv encoder, and keeping frames on gpu at all times was the only acceptable solution in terms of performance [13:36:46 CET] <XoXFaby> I assume it should be possible to just extra the frames at the times I need or similar [13:36:54 CET] <XoXFaby> extract* [13:37:28 CET] <BtbN> If you want to have reliable format changes at runtime, it'll be your only option. patching ffmpeg.c to support is will be hard to absolutely impossible. [13:38:16 CET] <kikobyte> BtbN, I'm also not that sure that the problem is on the encoder's input, because the segfault happens in process_output_surface routine [13:38:27 CET] <JEEB> it's scary how far you can get with ffmpeg.c, and then hit a wall where you need to make your own API client :P [13:38:42 CET] <utack> XoXFaby i am not sure how well frame exact seeking works, in the worst case you have to decode all frames from the beginning of the stream again [13:39:06 CET] <XoXFaby> Depending on the codec/container it should only be from the last keyframe, no? [13:39:18 CET] <BtbN> process_output_surface is a function in nvenc.c [13:39:40 CET] <BtbN> it extracts the bitstream from nvenc [13:39:41 CET] <utack> as i said, i am not sure about frame exact seeking [13:39:54 CET] <kikobyte> BtbN, yes, and I think that something might be broken with ctx->output_surface_queue [13:40:01 CET] <BtbN> unlikely [13:40:13 CET] <BtbN> does it crash without format changes? [13:40:37 CET] <kikobyte> Encoder in particular - not that I'm aware of [13:40:47 CET] <BtbN> Do you have a full backtrace? [13:40:51 CET] <kikobyte> but the format itself doesn't change [13:41:08 CET] <XoXFaby> The idea was that by recording a frame every second, I should be able to go all the way from grabbing 30 frames from 30 seconds to make a 1s clip or skipping frames in between to make 30fps clips that cover longer times. i.e. grabbing a frame every minute to make a 1s 30fps video from 30 minutes of data [13:41:09 CET] <BtbN> the hw_frames_ctx will likely change [13:41:26 CET] <kikobyte> BtbN, https://pastebin.com/4veqbB1S [13:42:34 CET] <BtbN> Why does it call from nvenc to libnvcuvid? [13:42:59 CET] <kikobyte> If I only knew. AFAIK, that's the decoder lib [13:43:12 CET] <BtbN> it is [13:43:41 CET] <Megabyte> Can anyone help me with ffmpeg? [13:44:01 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvenc.c;h=e4f6f0f… is what is crashing. Looks like something is horribly messed up there. [13:45:01 CET] <kikobyte> UnmapInputResource? [13:45:14 CET] <BtbN> I can't reasonably supports any release, so my only advice is to try git master. There were a lot of changes to nvenc and cuvid since 3.3, so it might be fixed. Or it might be ffmpeg.c causing corruption because it's operating in unexpected ways. [13:46:19 CET] <BtbN> What might happen with a format change is that the new filter pipeline creates a new CUDA context and destroys the old one. [13:46:24 CET] <kikobyte> Totally understandable, I've been making the same "use newer version first" statements for years for our SDK =) [13:46:52 CET] <BtbN> So the context the old frames are referencing might be gone, but nvenc still has frames in its pipeline using it. [13:46:57 CET] <BtbN> So when it tries to free them, it explodes. [13:47:06 CET] <XoXFaby> utack: I'm pretty sure I can actually extract the video I want very easily from using ffmpeg, just with -ss -to and setpts filtering to speed up the footage [13:47:07 CET] <kikobyte> Viable guess [13:47:17 CET] <XoXFaby> since ffmpeg will skip frames exactly how I need it to [13:48:05 CET] <XoXFaby> now I just need to figure out what the best video format is that I can append to like I need [13:50:31 CET] <utack> XoXFaby but the "ss" argument decodes all frames from beginning to the point where you seek [13:52:13 CET] <utack> appending files works very easily in a mkv file. https://mkvtoolnix.download/doc/mkvmerge.html [13:52:35 CET] <utack> unless you wanted to figure out how to keep ffmpeg opened, stalling while waiting for hte next frame, making one continuous file [13:52:52 CET] <XoXFaby> utack: ". The input will be parsed using keyframes, which is very fast" [13:53:19 CET] <XoXFaby> sounded like it wouldn't be an issue [13:53:41 CET] <XoXFaby> as for the frame thhing, I don't care how I do it, I just want to get it done [13:54:13 CET] <utack> where do you get the, from, can you directly use a pipe to send them to ffmpeg? [13:54:35 CET] <XoXFaby> where I'm getting the images from? [14:00:08 CET] <utack> i have not really found anything to wait for new images...i mean it is solvable i guess, but blocks seem easier, with minimal loss of efficiency [14:00:30 CET] <XoXFaby> so you're saying to save x frames, encode them into a block and then add them? [14:00:45 CET] <XoXFaby> presumable append the block to an mkv file [14:01:07 CET] <XoXFaby> how much overhead is there when saving a video file [14:01:09 CET] <XoXFaby> i.e [14:01:32 CET] <XoXFaby> different between 100 30 frame files or one 3000 frame file [14:02:26 CET] <utack> x264 has a default of about 250 keyframe interval, so beyond that would not make much sense [14:02:40 CET] <utack> but using half of it should barely make a difference [14:03:04 CET] <XoXFaby> I was thinking of the difference between appending them to one video file or just saving the blocks and then combining them as needed [14:03:36 CET] <XoXFaby> but I guess it shoudln't matter and one video file will be easier to deal with [14:04:40 CET] <utack> yeah or just save the blocks, that is still WAY more efficient than single jpeg files [14:05:27 CET] <XoXFaby> yeah of course [14:06:32 CET] <XoXFaby> I was just hoping to be able to add frames on at a time so I could grab a video going right up to the lastest frame at any moment [14:07:30 CET] <XoXFaby> I could prematurely pack and append the block when a video is requested [14:09:21 CET] <XoXFaby> You're saying I should pack blocks for 250 frames for x264? [14:13:24 CET] <utack> that is the default keyframe interval, i'd use less if these images are large, or seeking might take a while [14:14:50 CET] <XoXFaby> I was gonna go with 30 frame blocks so each block would be one keyframe interval [14:14:58 CET] <utack> sounds reasonable [14:15:03 CET] <XoXFaby> at least I hope this will work as I imagine [14:17:59 CET] <Megabyte> XoXFaby, can you help me? [14:27:11 CET] <kepstin> note that x264 by default doesn't have a fixed keyframe interval - the '250' value is a max [14:27:56 CET] <kepstin> (if you really want it fixed, there's an option you can specify via -x264-params to do that) [14:35:54 CET] <Megabyte> I tried running this command [14:35:55 CET] <Megabyte> C:\Users\x\Videos>C:\Software\ffmpeg-static\bin\ffmpeg.exe -i saída_parte_1.mp4 -vf scale=1920:1080 -filter:v setpts=PTS/144 -framerate 60 -cbr 0 output1.mp4 [14:36:10 CET] <Megabyte> But ffmpeg will give me a video with the sped up footage and then an empty footage [14:36:19 CET] <Megabyte> how do I trim the data to the sped up footage only? [14:38:52 CET] <kepstin> Megabyte: is there an audio track present? If so, the length will be set by the length of the audio track [14:39:05 CET] <Megabyte> kepstin, Oh, I see. I just removed it. [14:39:31 CET] <kepstin> Megabyte: easiest way to remove the audio is to just use the "-an" option [14:39:38 CET] <Megabyte> kepstin, also, it's not really scaling [14:39:41 CET] <Megabyte> I checked the output [14:39:45 CET] <Megabyte> and it's not 1920x1080 [14:39:59 CET] <Megabyte> I'm currently using? [14:40:00 CET] <Megabyte> C:\Users\x\Videos>C:\Software\ffmpeg-static\bin\ffmpeg.exe -i saída_parte_1.mp4 -vf scale=1920:1080 -filter:v setpts=PTS/144 -framerate 60 -cbr 0 output1.mp4 [14:40:32 CET] <Megabyte> sec [14:40:32 CET] <kepstin> Megabyte: you have two separate filter options: "-vf scale=1920:1080" and "-filter:v setpts=PTS/144" [14:40:42 CET] <kepstin> Megabyte: note that -vf and -filter:v are the same thing [14:40:51 CET] <kepstin> Megabyte: and so the second one overwrites the first [14:41:02 CET] <Megabyte> C:\Users\x\Videos>C:\Software\ffmpeg-static\bin\ffmpeg.exe -i saída_parte_1.mp4 -vf scale=1920:1080 -filter:v setpts=PTS/144 -framerate 60 -cbr 0 output1.mp4 [14:41:09 CET] <Megabyte> uh... [14:41:37 CET] <kepstin> Megabyte: remember from yesterday: to send the output from one filter into the input of the next filter, put a comma "," between them [14:42:26 CET] <Megabyte> kepstin, ok, like this? [14:42:27 CET] <Megabyte> C:\Users\x\Videos>C:\Software\ffmpeg-static\bin\ffmpeg.exe -i saída_parte_1.mp4 -vf scale=1920:1080,setpts=PTS/144 -an output1.mp4 [14:43:06 CET] <kepstin> Megabyte: exactly - although you should also set the output framerate ("-r 60") [14:43:47 CET] <Megabyte> Ok, like this? [14:43:47 CET] <Megabyte> C:\Software\ffmpeg-static\bin\ffmpeg.exe -i saída_parte_1.mp4 -vf scale=1920:1080,setpts=PTS/144 -an -r 60 output1.mp4 [14:44:00 CET] <kepstin> Megabyte: yes. [14:48:39 CET] <Megabyte> kepstin, I'll probably use a script and speed up every video individually [14:48:43 CET] <Megabyte> it's safer that way [14:49:07 CET] <Megabyte> I tried to concatenate all my videos into four to make it easier to handle them [14:49:23 CET] <Megabyte> but ffmpeg is making my computer crash [14:49:52 CET] <kepstin> ffmpeg shouldn't be making your computer crash& if it is, you probably have a hardware problem or cooling problem. [14:50:03 CET] <Megabyte> kepstin, I suspect it's a memory error [14:50:10 CET] <Megabyte> that is, it's crashing with VERY LONG footage [14:50:19 CET] <Megabyte> it's 48 hours of footage, after all [14:50:45 CET] <Megabyte> It always crashes when processing around 11 hours [14:51:08 CET] <Megabyte> I also checked with process lasso and when my computers starts to freeze is exactly when memory starts to get at 100% [14:52:25 CET] <Megabyte> Now that I stripped the audio it's going much slower [14:52:31 CET] <Megabyte> mmm... [14:52:42 CET] <XoXFaby> kepstin: does that mean it accepts varying keyframe intervals? [14:52:54 CET] <kepstin> XoXFaby: it just might be that the calculation of speed works differently without audio [14:52:56 CET] <XoXFaby> I'm not sure how all that plays in with mkv container [14:53:31 CET] <kepstin> XoXFaby: not sure what you mean. x264 allows and can put keyframes wherever it likes, and mkv's index doesn't care how the keyframes are spaced. [14:53:55 CET] <rk> i am using libavformat to mux a vp8 rtp stream into a webm file. When i see the info on the webm file obtained using mkv tool, i see the duration is too high. And, inside the track info, the frame rate is considered as 1000fps, while i set the time_base with frame rate of 25 fps. [14:53:56 CET] <XoXFaby> well I was planning to combine multiple short x264 clips in an mkv container [14:54:07 CET] <kepstin> XoXFaby: yep, i'd expect that to work fine. [14:54:08 CET] <XoXFaby> where basically each file would one be one keyframe "block" [14:54:51 CET] <kepstin> XoXFaby: depending on your settings when encoding with x264, you might end up having multiple keyframes in a single encoded chunk of video. If you want fixed-length gops, there's an extra option for that. [14:55:15 CET] <XoXFaby> do you have context one what I'm trying to do? [14:55:17 CET] <XoXFaby> might help with understanding [14:56:38 CET] Action: kepstin scrolls up a bit [14:57:08 CET] <kepstin> if you want the ability to do a quickly generated time-lapse, then using a fixed gop that's the length of the frame spacing would make sense [14:57:35 CET] <XoXFaby> right now the plan is to take 1 jpeg every second [14:57:48 CET] <XoXFaby> and then I want to be able to make timelapses out of that on demand, so the idea was to store them as video files [14:58:11 CET] <XoXFaby> and now I'm also thinking about how to handle it if I there is missing data, missing frames or missing video blocks [14:58:28 CET] <kepstin> you basically need to figure out "what's the smallest step in frames that I'll want to use when making the timelapse?" [14:58:48 CET] <XoXFaby> I mean ideally I want to be able to be second specific [14:59:03 CET] <XoXFaby> i.e. each frame [14:59:19 CET] <kepstin> well, each frame you just get by decoding the whole video [14:59:43 CET] <kepstin> the interesting thing is optimizing how to skip frames when doing a time lapse [15:00:06 CET] <XoXFaby> the problem is I can't just store the frames as they are, cause that takes way too much space, so I want to take advantage of keyframes [15:00:11 CET] <XoXFaby> therefore storing it as video [15:00:37 CET] <XoXFaby> which should still let me seek to any frame in between [15:00:51 CET] <XoXFaby> which would be handled by ffmpeg when I -ss [15:01:00 CET] <kepstin> Right. assuming you're storing it in a container with an index, yes; it'll seek to the nearest keyframe then decode to the exact frame you want [15:01:27 CET] <XoXFaby> exactly [15:02:02 CET] <XoXFaby> the idea now was to use mkv and either append the 1s clip every 30 seconds or keep the clips seperated and combine them on demand [15:02:11 CET] <kepstin> note that the index will only be written after the complete file is done/closed, so you'll have to figure out how to handle that [15:02:50 CET] <kepstin> writing to X second chunks and appending them to an mkv file could work, but will be quite disk intensive [15:03:04 CET] <XoXFaby> you mean io wise/ [15:03:35 CET] <kepstin> it might make sense to do something like write the chunks out as separate files, then combine them into e.g. a file per hour or per day at regular intervals. [15:04:32 CET] <XoXFaby> I have an idea [15:04:44 CET] <XoXFaby> My biggest worry now was about missing frames if I have to restart my scripts etc. [15:04:52 CET] <XoXFaby> or move the device [15:04:54 CET] <XoXFaby> all that [15:05:05 CET] <XoXFaby> maybe I should just pack all the blocks together whenever a gap happens [15:06:13 CET] <XoXFaby> hell I could even automate uploading to youtube whenever that's done [15:06:43 CET] <XoXFaby> do the same if there is no gap after a day [15:07:41 CET] <XoXFaby> one day of 30fps 1s footage would be 2880 clips, is that feasible to combine into one file? [15:12:28 CET] <kepstin> XoXFaby: I don't see why not. [15:13:13 CET] <kepstin> (if you wanted to do it with ffmpeg, you'd write a .ffconcat file to give it the list of input files, and then write to a single output with -c:v copy) [15:36:27 CET] <saml> good morning [15:38:57 CET] <XoXFaby> kepstin: do you think that's how I should do it? [15:39:17 CET] <XoXFaby> I just want to do it the best way, idk if ffmpeg or mkvmerge will be better [15:39:38 CET] <kepstin> XoXFaby: either should work, try both and see which you like better? [15:39:58 CET] <XoXFaby> what does ffmpeg actually do when copying like that? [15:40:11 CET] <XoXFaby> mkvmerge presumably would just add it to the container which should be very fast [15:40:21 CET] <kepstin> it reads the video frames from each file, then concatenates them to a single stream, then muxes them to a new file [15:40:40 CET] <kepstin> no transcoding needed, normally runs at disk speed [15:40:40 CET] <XoXFaby> I would assume that would take longer [15:40:53 CET] <XoXFaby> disk in this case is an sdcard [15:41:14 CET] <kepstin> i'd expect both to take about the same amount of time, io limited. [15:41:45 CET] <kepstin> if you really want to avoid extra writes on the sd card, I wouldn't bother - just leave the individual chunks as separate files [15:41:45 CET] <XoXFaby> I guess I'll just collect an hour of clips or something and try [15:41:53 CET] <XoXFaby> currently writing that part so I'll deal with it when I get there [15:42:30 CET] <XoXFaby> all I care about is speed, cause I will probably need to generate the file on demand [15:44:29 CET] <calmoo> Hi, I'm trying to mute a portion of audio in a video i'm editing, using this command: [15:44:30 CET] <calmoo> ffmpeg -i 13125.mp4 -af volume=enable='between(t,2215,2217):volume=0 -c:v copy 13125muted.mp4 [15:44:39 CET] <calmoo> on OSX [15:44:54 CET] <calmoo> but when I execute it, nothing happens, terminal just produces a ">" character on a newline [15:52:46 CET] <kepstin> calmoo: you have mismatched quotes [15:53:11 CET] <kepstin> calmoo: you have fancy unicode quotes, when they need to be plain ascii " and ' [15:53:56 CET] <kepstin> (also you have quotes inside quotes, which will cause problems with ffmpeg's filter parser [15:53:58 CET] <kepstin> ) [15:54:47 CET] <calmoo> ok [15:54:48 CET] <calmoo> ffmpeg -i 13125.mp4 -af "volume=enable=between(t,2215,2217):volume=0" -c:v copy 13125muted.mp4 [15:54:49 CET] <calmoo> when i do that [15:54:57 CET] <calmoo> [volume @ 0x7fc40e700d80] [Eval @ 0x7fff5ae0b710] Missing ')' or too many args in 'between(t' [volume @ 0x7fc40e700d80] Error when evaluating the expression 'between(t' for enable [AVFilterGraph @ 0x7fc40e700960] Error initializing filter 'volume' with args 'enable=between(t' [15:54:59 CET] <calmoo> i ge that error [15:55:51 CET] <kepstin> calmoo: the , inside the enable expression has to be escaped with \. This gets complicated because \ is also a special character inside double-quotes [15:56:17 CET] <kepstin> calmoo: I recommend doing this: -af 'volume=enable=between(t\,2215\,2217):volume=0' [15:56:43 CET] <kepstin> the single quotes let you use a \ inside the quotes. [15:56:59 CET] <calmoo> thankyou so much [15:57:03 CET] <calmoo> i've been trying to work this out for hours [15:57:06 CET] <calmoo> thanks!! it works [16:23:03 CET] <lyncher> hi. can you suggest a tool to visualize MPEG2 bitstream (GOP, I/P/B frames...)? [17:55:17 CET] <fsphil> I've a program that needs video at a fixed resolution and format, I've been using libswscaler but realised I could probably have used AVFilter. Is there a preferred method? [17:56:12 CET] <kepstin> fsphil: if scaling is all you need, using libswscale directly might be a bit simpler. [17:56:41 CET] <JEEB> depends on if you need AVFrames or not [17:56:42 CET] <fsphil> yeah just scaling. the only oddity might be handling interlaced video, my output is interlaced [17:56:57 CET] <JEEB> AVFilter takes in AVFrames, and outputs AVFrames [17:57:02 CET] <kepstin> fsphil: remember that the "scale" filter is just a wrapper around libswscale after all :) [17:57:08 CET] <JEEB> yup [17:57:09 CET] <fsphil> yeah [17:57:16 CET] <JEEB> (at least it's a wrapper that is not your problem to write) [17:57:26 CET] <fsphil> it was the source for the scale filter that I found when looking for an interlaced scale example [17:57:35 CET] <fsphil> made me wonder if I should just be using that instead [17:58:06 CET] <JEEB> personally at this point I would only utilize swscale if avfilter makes your life miserable [17:58:13 CET] <JEEB> otherwise I see the AVFrame support as a really good thing [17:58:27 CET] <kepstin> well, if your swscale usage is starting to get complicated, and in particular if you might want to do other stuff with frames too at some point, avfilter seems like a good idea. [17:58:30 CET] <JEEB> (granted, avfilter can be "fun" to create the filter chains in) [17:58:41 CET] <fsphil> at some point I'd like to provide an option for users to add their own filters, so I'll probably be adding avfilter anyway [17:59:06 CET] <JEEB> but yea, personally for me the biggest thing is: AVFrames [17:59:20 CET] <JEEB> because that's what you get from decoders and encoders are fed them [18:01:05 CET] <fsphil> thanks all. I'll have a play with avfilter [18:02:43 CET] <lyncher> I'm trying to add MPEG2_START_USER_DATA after a MPEG2_START_PICTURE.... do I need to add extra MPEG2_START_SEQUENCE_HEADER/MPEG2_START_EXTENSION before user data? [18:23:57 CET] <storrgie> How can I tell if my ffmpeg has decklink compiled/enabled? I'm using the vanilla ffmpeg on archlinux [18:25:05 CET] <lyncher> storrgie: run ffmpeg command and check if you have --enable-decklink in the configuration line [18:25:05 CET] <sfan5> $ ffmpeg [18:25:12 CET] <sfan5> look for the above [18:25:14 CET] <sfan5> damn someone was faster [18:25:30 CET] <lyncher> that one was easy :) [18:33:12 CET] <TAFB_WERK> I will pay money to anyone that can get this 4k ip camera streaming smooth and reliable to youtube: ffmpeg -rtsp_transport tcp -i rtsp:/admin:admin1234@skyviewe.com:65314/0 [18:37:53 CET] <BtbN> It's probably more about having a beast CPU than anything else. [18:38:07 CET] <BtbN> And pretty impressive internet upstream. [18:38:25 CET] <TAFB_WERK> transcoding only, don't need a good cpu [18:38:36 CET] <BtbN> ...? [18:38:40 CET] <BtbN> yes you do [18:38:51 CET] <TAFB_WERK> when I run that stream it uses 3% of my cpu, but ok [18:39:00 CET] <BtbN> you're not transcoding then [18:39:12 CET] <TAFB_WERK> -c copy [18:39:22 CET] <TAFB_WERK> mp4 to flv [18:39:22 CET] <BtbN> that's the exact opposite of transcoding [18:39:34 CET] <TAFB_WERK> i see [18:39:37 CET] <TAFB_WERK> it's not encoding [18:39:57 CET] <BtbN> Usually those IP webcames produce some massive and unoptimized streams. [18:40:07 CET] <BtbN> So you'll need massive internet upstream [18:40:24 CET] <TAFB_WERK> 4mbps is the ip stream, 50mbps is my upstream connection [18:40:45 CET] <BtbN> 4mbps for a 4K stream? I have my doubts about that. [18:41:01 CET] <TAFB_WERK> I can set it whatever I want, for testing I have it at 4mbps, it usually runs as 12mbps [18:41:27 CET] <BtbN> For those hw encoders I'd go for at least 25Mbps if you want anything half decent [18:41:38 CET] <BtbN> Does it output h264 at least? [19:01:30 CET] <TAFB_WERK> yep, h264 or h265 selectable [19:02:02 CET] <TAFB_WERK> can't change the res down to 1080p for re-encoding it :( [19:07:04 CET] <BtbN> I'm not even sure if YouTube live takes 4K [19:07:58 CET] <TAFB_WERK> it does, I've bean streaming to it, just super choppy, pixelation, and I have to restart ffmpeg all the time. [19:09:18 CET] <BtbN> is the stream fine if you play it locally? [19:09:37 CET] <BtbN> And if you stream 4K at 4mbps, pixelation is exactly what you will get [19:09:38 CET] <TAFB_WERK> only in internet explorer (activex), if I play it with ffplay it's a complete mess, same with vlc player [19:09:59 CET] <TAFB_WERK> that link I posted above, you can open it yourself to see [19:11:23 CET] <BtbN> You definitely can't stream HEVC to YouTube. And for 4K h264 you'll need something like 25mbps or more [19:11:28 CET] <TAFB_WERK> I was given this command, which stream is nice and smooth, but after an hour or so ffmpeg starts using 100% of a cpu core and the stream goes down. https://pastebin.com/YNP7nmmR [19:12:11 CET] <BtbN> Why is it split in two? [19:12:23 CET] <TAFB_WERK> only way to make it smooth, don't ask me [19:12:38 CET] <BtbN> that sounds more like something is wrong with your source [19:13:18 CET] <TAFB_WERK> if I'm staring at the cpu usage and I see ffmpeg spike I right away end the task and restart ffmpeg and it's fine. So if it is a problem with the source ffmpeg needs to recover better [19:13:40 CET] <BtbN> Depending on how broken it is, there is nothing to recover from [19:14:09 CET] <TAFB_WERK> i tried to find a software where "if a program is using xx% cpu end it automatically" but couldn't find it, that would be a partial solution to the problem. [19:14:39 CET] <BtbN> https://xkcd.com/1172/ [19:16:52 CET] <alexpigment> TAFB_WERK i think you just described modern antivirus software : [19:16:55 CET] <alexpigment> :) [19:17:16 CET] <alexpigment> norton at least warns about it - i'm sure there's an action to end on it [19:17:30 CET] <alexpigment> anyway, dumb logic for dumb users i guess... [19:28:21 CET] <kerio> BtbN: the youtube recommendations say 13-34mbps for 2160p30 [19:28:34 CET] <kerio> 20-51 for 2160p60 [19:28:41 CET] <BtbN> seems about right [19:28:53 CET] <BtbN> highly depends on the content obviously, that's why it's such a huge range [19:29:01 CET] <TAFB_WERK> 2160p30 so no problems [19:29:29 CET] <TAFB_WERK> 4mbps looks crisp and clean because the image is mostly static [19:51:14 CET] <Johnx_> I am testing udp stream for errors using ffmpeg, and I have noticed that at times common header connection error and decoding errors are just not present. for example: `[h264 @ 0x33c1280] SPS unavailable in decode_picture_timing [h264 @ 0x33c1280] non-existing PPS 0 referenced [h264 @ 0x33c1280] decode_slice_header error` [19:51:34 CET] <Johnx_> I am trying out why is this happening [19:52:20 CET] <Johnx_> the ffmpeg log indicates that it did process x ammount of audio and y ammount of video [19:52:42 CET] <Johnx_> just why sometimes no errors are printed out [20:13:19 CET] <kevc45> How can I embed cover art into a lossless using FFmpeg from the command line? Here's what I'm using: https://hastebin.com/ofadiyiqew.sh [20:18:28 CET] <relaxed> kevc45: can't see your pastebin, but I don't think our flac demuxer supports cover art [20:18:43 CET] <alexpigment> kevc45, you're trying to put cover art in a wav file [20:18:45 CET] <alexpigment> that's not supported [20:18:45 CET] <relaxed> er, flac muxer [20:19:32 CET] <alexpigment> when it says "wave files have exactly one stream", it means that no other streams (or pretty much anything else) can be put into the file [20:19:35 CET] <alexpigment> you need a different file format [20:25:12 CET] <zerodefect> I'm looking to use the C-API to control the 'overlay' libavfilter. It it possible to explicitly set the x,y position of the overlay on a frame-by-frame basis (similar to what is done via cmd line). I see there is an 'eval' => 'frame' mode by I don't quite understand how this works programmatically. [20:25:22 CET] <zerodefect> *Is it possible [20:27:04 CET] <kepstin> zerodefect: just like on the command line, you can set the parameters of the filters to strings containing expressions that will be evaluated. [20:28:40 CET] <kepstin> zerodefect: however, the overlay filter also supports receiving commands while it's running to dynamically change parameter values. [20:28:51 CET] <kepstin> which can be done programmatically from your code. [20:29:55 CET] <zerodefect> kepstin: Understood. For all the filters I've used thus far, I've set the properties on initialisation when calling 'avfilter_graph_create_filter()'. I'm guessing that I need to somehow update the properties? [20:30:20 CET] <kepstin> zerodefect: if you can just set the properties to an expression when you start and that's good enough, do that. [20:32:11 CET] <zerodefect> kepstin: That would suffice for me for the most part, but admittedly I am looking to do some crazy positioning [20:32:17 CET] <kepstin> if you want to do the calculations in your code instead of writing an expression that runs in the overlay filter, look into this function: https://www.ffmpeg.org/doxygen/2.3/group__lavfi.html#gaaad7850fb5fe26d35e5d… [20:33:19 CET] <kepstin> I believe that the overlay filter takes the commands "x" and "y", and the arg should be the expression that you want to assign. [20:33:56 CET] <kepstin> (it can be just a plain number or a full expression) [20:34:49 CET] <zerodefect> Terrific. Thanks :). I'll see how I get on. [20:36:04 CET] <zerodefect> Out of curiousity. The way that FFmpeg can chain overlays...is that inefficient? Would it be more efficient to handle multiple overlays in a single pass? [20:36:29 CET] <kepstin> zerodefect: ah, filters that take commands usually have the commands documented in the ffmpeg-filters doc, e.g. https://www.ffmpeg.org/ffmpeg-filters.html#overlay-1 [20:37:06 CET] <zerodefect> kepstin: Yeah, have the bookmarked. [20:37:36 CET] <kepstin> zerodefect: if the overlays have alpha-blending I think you have to do the full calculations anyways, so it wouldn't make much difference. But for opaque overlays, maybe? [20:39:10 CET] <zerodefect> kepstin: That makes sense [20:40:15 CET] <kepstin> (this is why for people tiling a bunch of videos, we recommend using hstack/vstack rather than overlaying them on top of each other) [20:41:29 CET] <nicolas17> does anyone know of a way to do real-time OCR on video to find if a specific text string is visible? it's for screen capturing so I think it should be easier than eg. a camera looking at printed text [20:42:10 CET] <kevc45> Can I at least embed any metadata to a .wav? Here's what I've got, and it does nothing: https://hastebin.com/loretadojo.bat [20:43:32 CET] <zerodefect> kepstin: Interesting. I wasn't familiar with those filters. [20:43:38 CET] <kepstin> kevc45: yeah, you can put some text metadata into wav files, but very few programs know how to do anything with it. You'd really be better off using flac or something. [20:43:50 CET] <kepstin> zerodefect: they're kinda new, relatively speaking :) [20:46:27 CET] <zerodefect> kepstin: If you were going to try create a multiview of say 4 inputs (2x2 view)...which would be the best filter in that case? [20:46:45 CET] <kepstin> two hstacks and a vstack or two vstacks and an hstack. [20:47:36 CET] Action: kepstin normally uses hstacks to make the rows, and a vstack to stack the rows together. [20:49:47 CET] <zerodefect> kepstin: Ok. That's what I thought. [20:50:45 CET] <nicolas17> I guess I could just make bitmaps with the text I want to detect and then find the bitmap, rather than trying to do general OCR [21:04:25 CET] <FishPencil> Can FFmpeg correct the contrast of a video? I have some media that's showing black at R: 16, G: 16, B: 16, when it should obviously be 0s [21:05:01 CET] <kepstin> FishPencil: that sounds like an incorrect conversion between limited/full range rather than a contrast issue [21:05:38 CET] <FishPencil> kepstin: Possibly, but it's not the player, the media is that way [21:07:31 CET] <zerodefect> FishPencil: You could still convert it from limited up to full range. [21:07:33 CET] <kepstin> the standard storage for video is limited range. if it's correctly flagged in the file, then the player should be correcting it when displaying on a pc screen [21:08:03 CET] <kepstin> so it sounds like you have a file in limited range (this is normal) which is incorrectly marked as being full range. [21:08:14 CET] <FishPencil> That sounds right [21:08:37 CET] <FishPencil> Can FFmpeg fix that? [21:09:16 CET] <kepstin> hmm. I'm actually not totally sure. I know it can while re-encoding (there's some filters with specific options to use there), but I don't know if you can fix it without re-encoding. [21:10:32 CET] <FishPencil> I'll be converting it anyway, so if I could fix it during that stage that'd be fine [21:11:29 CET] <zerodefect> FishPencil: Your other option is to keep it limited range and then ensure the file wrapper is marked limited range? [21:11:57 CET] <FishPencil> zerodefect: I think that's what kepstin was suggesting [21:12:23 CET] <FishPencil> I just don't know how to set that in FFmpeg [21:13:29 CET] <zerodefect> FishPencil: This is the filter you want to use: https://www.ffmpeg.org/ffmpeg-filters.html#colorspace [21:13:49 CET] <zerodefect> ...if you want to do a conversion. Fundamentally, there are 2 ways to skin this [21:14:06 CET] <zerodefect> I'm not well-versed with the cmd line tool though [21:14:46 CET] <FishPencil> I'm happy to keep it limited and tag it properly [21:16:40 CET] <kepstin> FishPencil: I think doing -vf colorspace=irange=limited:range=limited will override the the input video's range and make ffmpeg treat the video as limited range from that point on. [21:16:58 CET] <kepstin> it won't actually make any changes to the video itself. [21:18:07 CET] <FishPencil> lemme test [21:23:59 CET] <FishPencil> I don't think that filter is written right [21:25:37 CET] <kepstin> hmm. you could try using the scale filter instead. Same basic idea, -vf scale=in_range=pc:out_range=tv [21:25:51 CET] <kepstin> er, sorry [21:26:03 CET] <kepstin> -vf scale=in_range=tv:out_range=tv [21:26:12 CET] <kepstin> the first one I gave will make it worse ;) [21:28:24 CET] <FishPencil> -vf scale=in_range=pc:out_range=tv puts the color at RGB 30 [21:28:36 CET] <kepstin> like I said, that one will make it worse [21:29:19 CET] <kepstin> hmm. but it shouldn't actually be at RGB30 [21:29:28 CET] <kepstin> that should still render as 16 on a correct player [21:29:34 CET] <FishPencil> No change with -vf scale=in_range=tv:out_range=tv, RGB is 16s [21:29:43 CET] <kepstin> it sounds like your player is getting it wrong [21:30:15 CET] <FishPencil> ffplay handles it the same [21:30:17 CET] <kepstin> FishPencil: I'd appreciate a pastebin of the full ffmpeg output from that last command. [21:30:30 CET] <kepstin> ffplay is not a good reference player for colour stuff. Try mpv [21:30:40 CET] <kepstin> that said, I think it gets limited/full range right. [21:34:59 CET] <FishPencil> Taking a screenshot with MPV results in the same, 16s [21:35:20 CET] <kepstin> FishPencil: alright. Can you get me the ffmpeg output from that command, please? [21:35:37 CET] <kepstin> I want to check what it thinks the pixel formats and stuff are. [21:37:26 CET] <FishPencil> kepstin: do you want a specific loglevel [21:37:35 CET] <kepstin> nah, just the default's fine [21:41:19 CET] <kepstin> I don't need the full video or anything, feel free to stop it after a few seconds... [21:42:25 CET] <FishPencil> kepstin: https://gist.githubusercontent.com/anonymous/b0d4f1d0946095b3f5b12393ff183b… [21:44:48 CET] <kepstin> hmm, vc1 stuff from a blu-ray, great fun. It looks like the pixel formats are all fine, ffmpeg thinks it's yuv420p tv range on both the input and output. [21:45:58 CET] <FishPencil> perhaps it's actually encoded wrong [21:47:01 CET] <kepstin> yeah, I'm thinking that's actually the case, since the input *is* being interpreted as tv range. [21:48:55 CET] <kepstin> hmm, that scale option doesn't seem to actually be doing anything in my quick testing. [21:48:57 CET] <FishPencil> So if it thinks the input is TV, does that mean it's actually worse than 16s as [21:49:37 CET] <FishPencil> So it's like TV*2 or something [21:49:45 CET] <kepstin> that would mean the value being stored in the original video 32 when it should be 16, yes. [21:52:54 CET] <kepstin> alright, try just using -vf scale=in_range=tv:out_range=pc [21:53:07 CET] <kepstin> that should fix it :/ [21:53:50 CET] <kepstin> you *might* also need a ",scale=in_range=tv:out_range=tv" after that, but i'm not sure. [21:54:14 CET] <FishPencil> the first frame is "black", so this should work right? ffmpeg -i i.m2ts -vframes 1 -vf scale=in_range=tv:out_range=pc -y o.png [21:54:18 CET] <FishPencil> o.png is 16s [21:54:54 CET] <kepstin> FishPencil: the conversion to png adds and extra yuv-rgb step, it would be better to encode to a video to compare [21:55:24 CET] <FishPencil> -vf scale=in_range=tv:out_range=pc,scale=in_range=tv:out_range=tv actually is 0s [21:56:47 CET] <FishPencil> So for my clarification, we're taking the input, expanding it to pc, then faking that it's tv? I'm not clear on what's going on [21:58:01 CET] <kepstin> yeah, what that's doing is taking the input (32-223), running a tv-pc conversion, which gives you 16-239, then retagging it as tv range, where 16 is the correct value for black [21:58:11 CET] <kepstin> then the remaining code and players should handle it correctly. [21:59:40 CET] <FishPencil> So much for these companies knowing how to write media [22:00:10 CET] <FishPencil> kepstin: I really appreciate the help [22:05:39 CET] <kepstin> make sure you check the entire video tho, I wouldn't be surprised if there was e.g. a pre-credits thing with wrong black levels but then the actual movie is correct :/ [22:07:01 CET] <FishPencil> kepstin: Looks all the same, from beginning to credits. That'd be real fun though [22:07:23 CET] <FishPencil> kepstin: Would this be noticed on bluray players/tv's? [22:07:52 CET] <JEEB> if you do a limited YCbCr to full RGB conversion and the result is still limited RGB - yes [22:07:55 CET] <kepstin> FishPencil: yes, but it would honestly be hard to distinguish from lcd backlight bleed on cheaper tvs. [22:08:11 CET] <JEEB> we've also had some BDs/DVDs where people forgot to limit their YCbCr to limited range [22:08:30 CET] <JEEB> so after actually standards compliant players did the conversion you'd lose quite a bit of stuff :D [22:09:04 CET] <JEEB> (I know one DEEN show that was just full range, and then another which was like 16-255 for some reason) [22:09:51 CET] <kepstin> if anyone watched this on a modern oled or hdr lcd in a dark room, they'd *definitely* notice :) [22:12:00 CET] <JEEB> this is what someone who watched on a normal player as-is would have gotten https://kuroko.fushizen.eu/screenshots/seitokai_no_ichizon/1289_tv_601.png [22:12:12 CET] <JEEB> properly handled: https://kuroko.fushizen.eu/screenshots/seitokai_no_ichizon/1289_pc_601.png [22:12:16 CET] <JEEB> :D [22:12:36 CET] <FishPencil> Is there a way to seek to the first keyframe? I want to do -ss 00:10:00 -i i.mkv -vframes 1 o.png [22:15:54 CET] <kepstin> FishPencil: you can use -noaccurate_seek to have the seek go to the nearest keyframe before the selected seek point. [22:16:08 CET] <kepstin> or use filters to select the first keyframe after the seekpoint. [22:48:26 CET] <TAFB_WERK> I will pay money to anyone that can get this 4k ip camera streaming smooth and reliable to youtube without re-encoding because of slow cpu (link open to the public: ffmpeg -rtsp_transport tcp -i rtsp:/admin:admin1234@skyviewe.com:65314/0 ). Current live stream link that works for 15 minutes to 1 hour before the stream locks up: https://pastebin.com/YNP7nmmR [22:52:47 CET] <FishPencil> TAFB_WERK: Why aren't you going straight into YouTube's rtmp?Why the pipe [22:55:47 CET] <FishPencil> TAFB_WERK: And I'm almost positive you'll need to re-encode [22:58:09 CET] <TAFB_WERK> FishPencil: right to youtube works for about 30 seconds before youtube drops the stream [22:59:10 CET] <TAFB_WERK> the link to pastebin works, but after 15 mins or an hour, ffmpeg starts using 100% of the core it's running on :( [22:59:24 CET] <TAFB_WERK> normally it's using about 6% of the cpu [23:03:49 CET] <TAFB_WERK> some peeps asked to see the live stream on youtube: https://www.youtube.com/c/Skyviewelectronics/live [23:03:58 CET] <TAFB_WERK> that'll run for approx 15 mins to an hour before it goes down. [23:04:20 CET] <TAFB_WERK> that's only 4mbps, I usually run it at 12mbps [23:04:55 CET] <TAFB_WERK> i'm happy with the smoothness, if we can stock ffmpeg from locking up or whatever, that would be good [23:06:44 CET] <FishPencil> TAFB_WERK: What os/hardware/ffmpeg version are you running this from [23:07:11 CET] <TAFB_WERK> ffmpeg version N-89881-g1948b76a1b Copyright (c) 2000-2018 [23:07:21 CET] <TAFB_WERK> windows 7 ultimate x64 [23:07:46 CET] <TAFB_WERK> i5 3470 with 8gb ram [23:09:05 CET] <TAFB_WERK> it was originally running on windows 10 but thought I'd try windows 7 if it fixed the ffmpeg freezing but nope, same issue. [23:11:15 CET] <FishPencil> TAFB_WERK: What does FFmpeg tell you when the stream dies [23:12:02 CET] <TAFB_WERK> nothing, ffmpeg pretends everything is fine, just using 100% cpu. I'll wait till it dies and do a screen cap. [23:14:07 CET] <FishPencil> I would rerun with ffmpeg -loglevel verbose or debug, saving the log to a file. I'd be curious to see that [23:14:29 CET] <FishPencil> It will probably be quite large [23:16:08 CET] <TAFB_WERK> do I have to put that in both parts of the pipe? [23:17:03 CET] <FishPencil> why are you piping anyway [23:18:24 CET] <FishPencil> ffmpeg -rtsp_transport tcp -allowed_media_types video -i "rtsp://admin:admin1234@192.168.0.65:554/0" -b:a 2k -c:a aac -c:v copy -f flv "rtmp://a.rtmp.youtube.com/live2/xxx-xxxx" [23:18:24 CET] <TAFB_WERK> only way to make it smooth, super choppy without the pipe (I think because the camera has a slightly variable framerate) [23:18:29 CET] <sfan5> if you have it installed, running ffmpeg inside gdb would be useful [23:18:38 CET] <sfan5> so you could get a backtrace of all threads [23:18:51 CET] <FishPencil> sfan5: He needs debug symbols for that [23:19:07 CET] <TAFB_WERK> FishPencil: you can't stream to youtube without audio, and the camera stream has no audio [23:19:17 CET] <FishPencil> ffmpeg -rtsp_transport tcp -allowed_media_types video -r 30 -i "rtsp://admin:admin1234@192.168.0.65:554/0" -b:a 2k -c:a aac -c:v copy -f flv "rtmp://a.rtmp.youtube.com/live2/xxx-xxxx" [23:19:35 CET] <TAFB_WERK> ok, testing. [23:19:54 CET] <sfan5> FishPencil: then he should probably get a debug build with symbols [23:19:59 CET] <FishPencil> you need to add the nullsrc then, and the loglevel [23:21:12 CET] <FishPencil> TAFB_WERK: I can get you a windows FFmpeg build with debug symbols if you're comfortable using gdb [23:21:24 CET] <TAFB_WERK> FishPencil: sure [23:21:40 CET] <TAFB_WERK> FishPencil: that link you gave me streams for about 22 seconds then youtube drops the stream [23:23:16 CET] <FishPencil> ffmpeg -loglevel debug -rtsp_transport tcp -allowed_media_types video -r 30 -i "rtsp://admin:admin1234@192.168.0.65:554/0" -b:a 2k -c:a aac -c:v copy -f flv "rtmp://a.rtmp.youtube.com/live2/xxx-xxxx" > out.log 2>&1 [23:23:25 CET] <FishPencil> paste out.log somewhere [23:23:47 CET] <TAFB_WERK> i think we need to inject fake audio stream in there [23:25:23 CET] <TAFB_WERK> ffmpeg -loglevel debug -rtsp_transport tcp -allowed_media_types video -r 30 -i "rtsp://admin:admin1234@192.168.0.65:554/0" -i anullsrc -b:a 2k -c:a aac -c:v copy -f flv "rtmp://a.rtmp.youtube.com/live2/xxx-xxxx" > out.log 2>&1 [23:25:26 CET] <TAFB_WERK> trying that, 1 sec. [23:26:59 CET] <TAFB_WERK> nope, my anullsource didn't work [23:27:17 CET] <sfan5> it's -f lavfi -i anullsrc [23:27:27 CET] <TAFB_WERK> k. [23:29:34 CET] <TAFB_WERK> stream is up https://www.youtube.com/c/Skyviewelectronics/live [23:29:44 CET] <TAFB_WERK> choppy, pixely [23:30:17 CET] <FishPencil> Ah, good old Vibe [23:30:38 CET] <FishPencil> one step at a time TAFB_WERK, that out.log when it dies [23:37:29 CET] <TAFB_WERK> I'm not sure it ever dies when I'm not running the pipe command [23:37:56 CET] <FishPencil> just q or ctrl+c it then [23:38:03 CET] <TAFB_WERK> k. doing it now... [23:39:24 CET] <TAFB_WERK> https://pastebin.com/De2ZX8wa [23:41:19 CET] <FishPencil> Applying option b:a (video bitrate (please use -b:v)) with argument 2k. [23:41:20 CET] <FishPencil> curious [23:42:25 CET] <TAFB_WERK> can't apply video bitrate with -c copy [23:42:28 CET] <TAFB_WERK> weird [23:43:09 CET] <sfan5> weird? that's expected behaviour [23:43:34 CET] <FishPencil> Curious that it says video bitrate for b:a [23:43:50 CET] <FishPencil> it doesn't appear to actually be doing that though [23:43:56 CET] <sfan5> I imagine the -b option has that description [23:44:02 CET] <sfan5> would explain explain why it says to use -b:v [23:44:08 CET] <sfan5> s/explain/also/ [23:47:57 CET] <FishPencil> I somewhat doubt that the quality is any better with the pipe [23:48:58 CET] <TAFB_WERK> i'll fire it up without the pipe again and watch it close, then I'll fire it up with the pipe, one moment [23:50:35 CET] <TAFB_WERK> live stream is up without pipe https://www.youtube.com/c/Skyviewelectronics/live [23:50:40 CET] <TAFB_WERK> very choppy, gets in fits [23:53:40 CET] <FishPencil> If this is the pipe one they look the same to me [23:55:51 CET] <FishPencil> I would say it's possible the lack of pthreads is to blame, but it doesn't sound like the cpu is overloaded [00:00:00 CET] --- Thu Jan 25 2018

1 0

ffmpeg-devel.log.20180123
by burek 24 Jan '18

24 Jan '18

[00:34:31 CET] <nevcairiel> peloverde: the mp4-style -> annexb converter (which plays a similar rule as the ADTS muxer in this scenario) has a lot of magic to try to detect if the stream already has in-band headers and then doesn't insert them, not sure if such complexity might be warranted for the ADTS muxer as well, or if that would even work properly [01:26:27 CET] <wm4> BtbN: btw. what happened to moving our nvenc headers copy to a different repo? [01:53:39 CET] <atomnuker> http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary [02:03:45 CET] <wm4> yes, but we still have the internal headers in our repo? [02:09:03 CET] <atomnuker> yeah, seems like they're still in the main repo [06:39:23 CET] <deanoman_> hey all, does ffmpeg have any plans to have an update function built-in (similar to what youtube-dl does? e.g. ffmpeg.exe /U) [09:39:06 CET] <av500> bonjour [09:40:40 CET] <wm4> bontschurr [09:42:34 CET] <av500> would anybody know why MPEG4 timestamps are now (well, recently) being output in order? as I recall, they used to be out of order previously [09:43:04 CET] <nevcairiel> it depends on your source [09:43:26 CET] <av500> avi [09:47:48 CET] <nevcairiel> which timestamp field are you looking at? pkt_pts/pkt_dts shouldnt have changed, but if you use best_effort_timestamp (or what its called), it might try to be smart about that [09:50:07 CET] <av500> looking at an mpeg4 ASP file with B frames [09:50:15 CET] <av500> both pts and dts are in order [09:50:24 CET] <av500> and I dont think they were in the past [09:52:16 CET] <wm4> well avi has only frame numbers [09:52:25 CET] <av500> hmm [09:52:27 CET] <wm4> not even "real" DTS [09:52:31 CET] <av500> yes [09:52:36 CET] <av500> maybe me recollection was wrong [09:52:43 CET] <nevcairiel> real DTS is a matter of interpretation anyway [09:52:43 CET] <wm4> and from what I'm aware, lavf always exported them as in order DTS [09:52:45 CET] <av500> thing is I was using my own parser in the past [09:52:48 CET] <nevcairiel> whats real, the mpeg description? [09:53:00 CET] <wm4> nevcairiel: well, ffmpeg shifts them by the codec delay [09:53:00 CET] <av500> and recently switched to lavf for avi [09:53:19 CET] <av500> so maybe its just me reordering reordered timestamps [09:56:02 CET] <nevcairiel> in my experience mpeg4 in avi reading pkt_pts results in out of order timestamps, well, if you have a pts anyway, avidec probably doesnt even set it [09:56:09 CET] <nevcairiel> assuming your mpeg4 stream has re-ordering [09:56:20 CET] <cone-051> ffmpeg 03Jorge Ramirez-Ortiz 07master:9b1ec2483504: avcodec: v4l2_context: remove unnecessary code [09:58:24 CET] <av500> nevcairiel: yes, I think it used to output out of order timestamps [09:58:28 CET] <av500> but now I get in order ones [10:02:17 CET] <wm4> looks like I just use the dts and offset it by the codec reported b frame delay [10:02:27 CET] <wm4> that's kind of shitty though [10:03:48 CET] <av500> maybe its just noise, as said I recently switch to lavf for avi, so maybe I never noticed that before [10:08:09 CET] <JEEB> you should see if lavf can do actual timestamps for muxing into ISOBMFF by taking a raw H.264 or HEVC stream with b-frames etc, and looking at the end result [10:08:13 CET] <JEEB> IIRC that still fails [10:08:53 CET] <nevcairiel> it fails unless the h264 bitstream has the delay hints [10:09:22 CET] <nevcairiel> but creating h264 timestamps out of thin air is also quite a bit of work otherwise [10:15:21 CET] <JEEB> sure, it's not easy but muxers like L-SMASH do handle it so when it fails most users are rather disappointed [10:16:27 CET] <nevcairiel> users need to get over expectations some day =p [10:16:41 CET] <nevcairiel> more importantly, learn not to save such streams without timestamps [10:57:43 CET] <BtbN> wm4, headers are in a different repo, I have a patch that uses them in ffmpeg, but it explodes horribly in msvc, and I haven't had a chance to fix that yet. [19:50:56 CET] <jya> anyone familiar with the Windows Media Foundation audio decoder? (in particular AAC) [19:52:05 CET] <BtbN> why would you ever want to deal with it, specially when ffmpeg is involved? [19:54:02 CET] <nevcairiel> i dont actively use it anymore, but i have some basic experience with it [19:54:49 CET] <wm4> I once wrote a ffmpeg wrapper for it [19:55:19 CET] <nevcairiel> the feature support of the aac decoder is pretty low, so there really wasnt a point [19:55:38 CET] <nevcairiel> although it can do one thing ffmpeg cant do, it can transform LATM/LAOS to ADTS [19:55:59 CET] <nevcairiel> (although that was only a curiosity, not that i ever needed that) [20:01:02 CET] <jya> BtbN: I don't have the luxury to use ffmpeg here unfortunately [20:01:19 CET] <jya> was disappointed to see that ffmpeg didn't write a WMF backend I could copy :) [20:01:28 CET] <jya> seeing you guys had done a CoreAudio one [20:01:37 CET] <BtbN> That's what ffdshow is for? [20:02:26 CET] <jya> I want to retrieve the channel layout without have to manually decode each element (which would be patent enfringing) [20:03:45 CET] <nevcairiel> have it decode the extradata (in case of raw) or the first frame (in case of adts) and read MF_MT_AUDIO_CHANNEL_MASK ? [20:04:03 CET] <jya> there's a MF_MT_AUDIO_CHANNEL_MASK attribute, but it seems to only be used for me to set the value [20:04:06 CET] <jya> not retrieve [20:04:16 CET] <jya> nevcairiel: that was my first attempt [20:04:36 CET] <jya> that attribute also isn't an IMFSample attribute [20:05:20 CET] <nevcairiel> i dont think it even supports PCEs, so it probably only has one channel layout per channel count anyway [20:05:49 CET] <jya> https://msdn.microsoft.com/en-us/library/windows/desktop/dd317906(v=vs.85).… "In an audio media type, specifies the assignment of audio channels to speaker positions. " so seems that it's for defining what we want on the output side [20:05:52 CET] <jya> rather useless [20:06:15 CET] <nevcairiel> you would call GetOutputCurrentType and then probe that for MF_MT_AUDIO_CHANNEL_MASK [20:06:30 CET] <jya> hmm, got idea.. let me see [20:06:40 CET] <jya> damn, my 3yo wants me to read his book... bbl [20:07:38 CET] <nevcairiel> mft->GetOutputCurrentType(0, &mt); uint32_t mask = MFGetAttributeUNIT32(mt, MF_MT_AUDIO_CHANNEL_MASK, 0); [20:07:40 CET] <nevcairiel> or such [20:08:03 CET] <nevcairiel> minus typo in the function names [20:08:41 CET] <wm4> I don't think the MF API makes it easy or even possible to retrieve the "native" channel layout in most cases, but I don't remember [20:10:48 CET] <nevcairiel> i only use video decoders currently through MF, and at least those properties can all be retrieved through the same API [20:12:09 CET] <wm4> yeah, video was different [20:19:20 CET] <jya> nevcairiel: what do you mean by MF? Media Foundation? [20:19:28 CET] <nevcairiel> of course [20:19:31 CET] <jya> that's what we use, MFT (T for transform) [20:19:35 CET] <nevcairiel> noone calls it WMF =p [20:19:55 CET] <jya> oh I misread, video decoders [20:19:55 CET] <jya> right [20:20:09 CET] <jya> we also use it for AAC and MP3 [20:24:04 CET] <jya> nevcairiel: that worked [20:24:25 CET] <jya> mDecoder->GetOutputMediaType(type); then query type [20:26:13 CET] <nevcairiel> i dont recognize that particular function name though, its not one on IMFTransform [20:26:28 CET] <nevcairiel> unless thats a wrapper of yours [20:28:19 CET] <jya> nevcairiel: you're right, this is our wrapper around GetOutputCurrentType [20:29:52 CET] <jya> it's a wrapper around our ref counted (similar to std::shared_ptr but mscom aware) pointers [22:24:32 CET] <cone-031> ffmpeg 03Jacob Trimble 07master:9f07cf7c00f3: avutil/aes_ctr: Add method to set 16-byte IV. [22:24:32 CET] <cone-031> ffmpeg 03Michael Niedermayer 07master:94d4237a7a29: avcodec/hevc_cabac: Move prefix check in coeff_abs_level_remaining_decode() down [22:24:32 CET] <cone-031> ffmpeg 03Michael Niedermayer 07master:6e1a167c5564: avcodec/dxtory: Fix bits left checks [22:53:00 CET] <SortaCore> what's the status of nvenc so far? [22:53:16 CET] <nevcairiel> "working fine"? [22:57:00 CET] <BtbN> nvenc is pretty feature complete right now I'd say [23:03:02 CET] <SortaCore> d3d11 working? [23:03:05 CET] <SortaCore> I saw talks about it [23:05:21 CET] <wm4> I once tried to feed d3d11 to mediafoundation encoders - would have been nice if that had worked [23:06:31 CET] <nevcairiel> setting up surface input to MF is a bit tricky [23:07:57 CET] <nevcairiel> anyhow d3d11 input to nvenc works fine [23:08:12 CET] <wm4> didn't get it to work, nor did I see anyone else getting it to work - though surface output with decoders worked fine [23:08:38 CET] <nevcairiel> might depend on the specific MFT in question i guess [23:08:45 CET] <nevcairiel> its probably not that strictly specified [23:09:30 CET] <SortaCore> all my commandlines for nvenc encoding so far have 0% GPU usage [23:09:51 CET] <SortaCore> is it like QSV, where it can use a software implementation instead of hardware? [23:09:52 CET] <nevcairiel> its not supposed to have gpu usage, it uses separate hardware to do the work afterall [23:09:56 CET] <BtbN> that's not surprising, given that nvenc does not use the gpu. [23:10:16 CET] <nevcairiel> if you're on windows 10 fcu, the taskmanager can show the video engine usage [23:10:31 CET] <SortaCore> I was watching with Process Explorer [23:11:02 CET] <nevcairiel> process explorer can also differentiate between gpu (3d) usage and encode usage, although one needs to know how to do that [23:11:49 CET] <SortaCore> task manager: Not Responding x100 [23:12:10 CET] <SortaCore> ah, I see it on task manager [23:14:29 CET] <SortaCore> ...briefly drifted to 1% [23:16:26 CET] <BtbN> nvenc does cause significant video engine load [23:16:50 CET] <SortaCore> I'm not rousing anything out of it atm [23:17:10 CET] <SortaCore> I get a tiny spike at the start then nothing [23:19:39 CET] <SortaCore> can I have an idiot's full cmdline so I know I'm using it properly [23:23:42 CET] <SortaCore> I've tried dxva2, d3d11va2 hwaccel inputs, and given it a strict lossless preset, 5.1 and high profile, nothing [23:24:49 CET] <jkqxz> What are you even trying to do? Get the GPU load to go up? [23:25:04 CET] <SortaCore> well, atm yes [23:25:05 CET] <jkqxz> Try doing something which uses the GPU, like CUDA or something. NVENC doesn't use the GPU. [23:25:24 CET] <SortaCore> I just want to know it's using hardware and not some fallback CPU thing [23:25:32 CET] <jkqxz> It uses separate hardware on the same chip, which shares memory and some other stuff but not the GPU. [23:25:48 CET] <jkqxz> NVENC doesn't have a software fallback as far as I know. [23:26:02 CET] <SortaCore> yea, I was directed to Task Manager which is showing me graphs for video encode/decode, but they're all 0% with brief spikes of 1% at the start of the encoding only [23:26:33 CET] <SortaCore> so I want to put it under some heavy load so I know it's being used properly [23:27:28 CET] <sfan5> the nvidia-smi tool (linux) differs between Graphics and Compute, using nvenc via e.g. OBS shows a process using compute and raises gpu load 0% -> 26% [23:27:44 CET] <sfan5> i wouldn't rely on the windows task manager showing you exactly what you want anyway [23:28:47 CET] <BtbN> It shows video engine load, it works fine [23:38:00 CET] <nevcairiel> the task manager since fcu shows pretty detailed and pretty accurate gpu loads of all sorts of various internal sections of the gpu [23:39:52 CET] <nevcairiel> using a trivial ffmpeg -i file.mkv -c:v h264_nvenc test.mkv shows an average of ~40% encode usage with spikes to nearly 100% at the end of the file [23:39:56 CET] <nevcairiel> doesnt get simpler then that [23:41:35 CET] <BtbN> you can easily make it hit 100% with testsrc [23:42:37 CET] <nevcairiel> i was going to test with d3d11 input now, that can probably do that as well [23:42:57 CET] <nevcairiel> but i need to recompile since my build was actually quite old [23:43:02 CET] <nevcairiel> so that takes a while on windows =p [23:43:39 CET] <wm4> on another channel we just discussed how the rpi is a not so good device because it takes 25 mins to compile ffmpeg [23:43:55 CET] <wm4> and then someone said it takes as much on a modern Intel CPU with windows [23:43:57 CET] <BtbN> 25 min for compiling on a Pi seems very optimistic [23:44:08 CET] <nevcairiel> yeah i dont think it finishes in that time [23:44:12 CET] <wm4> I think a rpi3 can reach that [23:45:00 CET] <atomnuker> that's not bad, my old laptop took that long [23:45:08 CET] <jkqxz> On Windows you can't even configure in that time... [23:45:45 CET] <atomnuker> takes 35 on my rpi3 iirc [23:46:47 CET] <SortaCore> I think my input source was too wimpy [23:47:33 CET] <SortaCore> 6fps at 704x480 [23:48:19 CET] <atomnuker> jkqxz: hey what happened to the mjpeg hwaccel? [23:48:22 CET] <SortaCore> plus it was a stream, so the gpu had a lot of spare time between frames, instead of the muxer doing as many as possible [23:48:43 CET] <nevcairiel> one of these days i should finish figuring out how to do a build through wsl to avoid this waiting [23:48:52 CET] <wm4> I think Chloe did that [23:49:00 CET] <nevcairiel> its not like its hard [23:49:01 CET] <wm4> and it was indeed faster [23:49:04 CET] <nevcairiel> i'm just lazy [23:49:17 CET] <nevcairiel> and i have plenty stuff to do while shit compiles in the background [23:49:36 CET] <jkqxz> atomnuker: I was hoping that YUVJ would FOAD. But it hasn't, so I'll actually have to work out what to do with that stuff. Maybe at some point. [23:50:03 CET] <wm4> like sword fighting with coworkers? [23:50:20 CET] <nevcairiel> i wish, i work from home =p [23:50:32 CET] <atomnuker> maybe if we bother durandal_1707 a bit more he'll repost the patches with the fixes he already has [23:51:48 CET] <jamrial> jkqxz: you could just ignore yuvj and only implement yuv + color_range [23:52:10 CET] <jamrial> it's not like yuvj was going to be removed right away. deprecation periods and all that [23:52:38 CET] <SortaCore> oddly on QSV, 40% GPU "3D" usage, 10% Video Decode usage, and no sign of a Encode usage... [23:52:59 CET] <SortaCore> how would I know if my GPU supports encoding? [23:53:06 CET] <jamrial> unless you mean that the yuvj stuff not being unfucked actually makes it harder [23:53:27 CET] <wm4> does the utils.c code translate yuvj to normal pixfmt+color_range? [23:56:27 CET] <nevcairiel> why would utils.c do that [23:59:22 CET] <wm4> nevcairiel: why not... at least if the pixfmts array contains no J formats [00:00:00 CET] --- Wed Jan 24 2018

1 0

ffmpeg.log.20180123
by burek 24 Jan '18

24 Jan '18

[00:00:38 CET] <therage3> but for NTSC regions as well? [00:00:43 CET] <alexpigment> upsampling from 44.1 to 48 hasn't ever been that noticeable to me, and i've done it with various degrees of professional tools [00:00:58 CET] <therage3> because if that's the case, I don't follow what problem ChocolateArmpits is even having, if that's a standard format [00:01:17 CET] <therage3> it depends on what program/algorithm you use. Sox has a very good resampler so it may not be that bad [00:01:20 CET] <ChocolateArmpits> therage3, it's specifically for NTSC rates [00:01:38 CET] <therage3> but low-CPU intensive algorithms that employ linear interpolation may sound like ass [00:01:45 CET] <ChocolateArmpits> Other rates like 25p or 24000/1001 have equal number of samples per frame [00:02:14 CET] <therage3> ChocolateArmpits I see [00:02:41 CET] <ChocolateArmpits> So the issue I'm having is related to concatenating files with minimal loss. Because the audio has to fit a pattern, any following files have to be repatternized, which can lead to either a single sample loss or a single sample missing. [00:03:31 CET] <ChocolateArmpits> Because files have fixed length, you can't guess what the missing sample should be, so I imagine padding a zero-sample is the only way out of this [00:03:50 CET] <ChocolateArmpits> While during a loss you just have to deal with a lost sample [00:04:00 CET] <alexpigment> what about repeating the nearest sample? [00:04:14 CET] <ChocolateArmpits> well that sounds like an option yes [00:04:15 CET] <alexpigment> seems safer, although i doubt you'd notice a zero sample anyway [00:04:59 CET] <alexpigment> on the other hand, is it possible to alternate your methods from video to video [00:05:47 CET] <ChocolateArmpits> Well upon extracting the segment back, a padded sample should disappear. I the other situation though there's nothing to do with a sample that was removed. [00:05:54 CET] <ChocolateArmpits> In* [00:06:45 CET] <ChocolateArmpits> Basically I found no tools that do this justly, including ffmpeg, they start mixing ending and starting samples from different files together [00:07:12 CET] <ChocolateArmpits> Which with enough files can lead to sync issues [00:07:38 CET] <alexpigment> yeah, i've seen that, but in my experience it has less to do with samples and more to do with just a mismatch between audio and video lengths [00:07:49 CET] <alexpigment> i've always wanted a "pad audio" option [00:08:20 CET] <alexpigment> well, lemme rephrase [00:08:30 CET] <alexpigment> an audio pad option that doesn't require re-encoding [00:09:02 CET] <ChocolateArmpits> Well in mxf the frame lengths are fixed, there's typically no variability there. The only difference is the distribution of audio samples. The audio is uncompressed btw. [00:10:59 CET] <alexpigment> right, you've got a very different case you're working with [00:11:15 CET] <alexpigment> generally a lot less problems with professional standards :) [00:19:39 CET] <alexpigment> chocolatearmpits: http://www.motunation.com/forum/viewtopic.php?t=39678&p=331142 [00:19:46 CET] <alexpigment> the second post seems interesting [00:19:53 CET] <alexpigment> not really sure if it's applicable for what you're trying to do [00:19:58 CET] <ChocolateArmpits> I already was there lol [00:20:04 CET] <alexpigment> oh :) [00:20:08 CET] <alexpigment> well, there's that [00:20:16 CET] <ChocolateArmpits> There's really little content about it, they all speak about smpte, but no doc pops up in google [00:21:43 CET] <alexpigment> hmmm [00:22:06 CET] <alexpigment> there are probably 5 people that could talk your ear off about this sort of thing [00:22:21 CET] <alexpigment> and there are billions who will just scratch their heads and look at you funny [00:22:47 CET] <alexpigment> once you get to a certain level of technical, good info and people that possess it are hard to find [00:24:07 CET] <alexpigment> and in some cases, like with interlaced video, there is more incorrect information than correct on the internet ;) [06:34:57 CET] <deanoman> hey all, does ffmpeg have any plans to have an update function built-in (similar to what youtube-dl does? e.g. ffmepg.exe /U) [06:39:08 CET] <deanoman> hey all, does ffmpeg have any plans to have an update function built-in (similar to what youtube-dl does? e.g. ffmpeg.exe /U) [06:50:02 CET] <phunyguy> Hi, I am trying to convert some flag files with embedded album art, and am running into a snag. https://pastebin.com/BerkukMb [06:50:07 CET] <phunyguy> flac*** [06:51:32 CET] <furq> add -vn if you just want to strip the album art [06:51:44 CET] <phunyguy> It appears to be flipping stream 0:0 and stream 0:1 in the output because it thinks it is a video. First, how can I revert the streams to the proper locations, and just copy the second stream? The conventional methods of -map and -c:v copy did not appear to work. It put the streams in the proper order but still failed to encode [06:51:54 CET] <phunyguy> I don't want to strip the album art [06:52:04 CET] <furq> try using .oga instead then [06:52:09 CET] <phunyguy> I want to copy it to the new file, along with the rest of the metadata [06:52:16 CET] <furq> also it's 2018, you should probably be using opus [06:52:18 CET] <phunyguy> derp. Thanks. [06:52:27 CET] <phunyguy> think my phone would support it? [06:52:36 CET] <furq> if it's android then sure [06:52:40 CET] <phunyguy> ok. [06:52:49 CET] <furq> opus is better supported than vorbis these days [06:53:01 CET] <phunyguy> I'll look into opus. Let me test the oga theory first. [06:53:12 CET] <furq> .oga and .ogg use different muxers [06:53:16 CET] <phunyguy> (been a while since I've done this, can you tell?) [06:53:24 CET] <furq> yeah it's not super intuitive [06:54:25 CET] <furq> ffmpeg has a specific "ogg audio" muxer [06:54:39 CET] <furq> i assume the only difference is that it doesn't try to encode the video stream to theora [06:55:01 CET] <furq> much like the m4a and mp4 muxers [06:55:03 CET] <phunyguy> yep, it stripped the art [06:55:11 CET] <phunyguy> I think it needs to be .ogg to keep it [06:55:33 CET] <phunyguy> think opus would handle this better? [06:55:42 CET] <furq> .opus is just ogg [06:55:51 CET] <furq> but the muxers have different defaults so maybe that'll work better [06:56:24 CET] <furq> also get rid of -q:v if you're using opus [06:56:39 CET] <furq> or -q:a rather [06:58:36 CET] <phunyguy> probably a different format, year [06:58:37 CET] <phunyguy> yeah* [06:58:55 CET] <phunyguy> so far it is keeping the album art... let's see when it gets to the problem one [06:59:11 CET] <phunyguy> it's actually encoding as one stream [06:59:49 CET] <phunyguy> or I am stupid. [07:00:26 CET] <furq> doesn't seem to work here either [07:00:28 CET] <phunyguy> It's still doing weird things. [07:00:30 CET] <phunyguy> Stream #0:1 -> #0:0 (mjpeg (native) -> theora (libtheora)) [07:00:31 CET] <phunyguy> Stream #0:0 -> #0:1 (flac (native) -> opus (native)) [07:00:36 CET] <furq> there's a closed bug report for vorbis album art [07:00:40 CET] <furq> or ogg album art rather [07:00:43 CET] <furq> so i assume that should work [07:00:55 CET] <furq> but -f opus and -f oga both just ignore the album art here [07:01:20 CET] <phunyguy> well I expect -f oga to. As that makes it an audio only container [07:01:42 CET] <phunyguy> maybe opus is the same way. [07:01:58 CET] <phunyguy> because it still needs to use an ogg container to hold the "video" stream. [07:03:20 CET] <phunyguy> ' [07:03:29 CET] <phunyguy> ^ cat [07:03:53 CET] <phunyguy> yeah it got to the problem album and failed. [07:04:09 CET] <phunyguy> it's attempting to convert png to theora [07:04:22 CET] <phunyguy> and flopping stream 0 and 1 [07:06:37 CET] <phunyguy> starting to think that stripping the art is unavoidable... unless something like mp4 will work [07:07:04 CET] <furq> opus in mp4 isn't well supported and vorbis in mp4 isn't a thing at all [07:07:11 CET] <phunyguy> the problem is, having all that album art as cover.jpg on my pone clutters up my picture albums. lol. super annoying [07:07:22 CET] <phunyguy> I meant another codec as a whole [07:07:26 CET] <phunyguy> probably aac [07:07:36 CET] <furq> the builtin aac encoder is ok now [07:07:40 CET] <furq> not as good as opus though [07:07:55 CET] <furq> album art should definitely work with -f ipod or .m4a [07:08:12 CET] <phunyguy> I can up the quality and sacrifice filesystem space for working album art [07:08:24 CET] <phunyguy> will make me cry a little inside using -f ipod tho [07:10:27 CET] <phunyguy> no go with m4a. [07:10:52 CET] <furq> they're the same thing [07:11:12 CET] <furq> you can use -f ipod if you really want to use .mp4 instead of .m4a and you don't want to rename afterwards [07:12:45 CET] <furq> https://trac.ffmpeg.org/ticket/4448 [07:12:46 CET] <furq> oh fun [07:12:52 CET] <furq> i guess that doesn't actually work then [07:13:34 CET] <furq> you could just strip the art and then postprocess it with vorbiscomment [07:13:36 CET] <phunyguy> nope, doesn't [07:13:38 CET] <phunyguy> lol [07:13:55 CET] <phunyguy> furq: yeah was hoping to avoid that. [07:14:06 CET] <phunyguy> since the script i created is supposed to be dynamic [07:14:44 CET] <phunyguy> also I get a warning about opus being experimental. [07:14:48 CET] <phunyguy> so that's fun. [07:14:50 CET] <furq> -c:a libopus [07:14:56 CET] <furq> the builtin opus encoder sucks, same as the builtin vorbis encoder [07:14:59 CET] <phunyguy> oh I did it wrong then [07:15:50 CET] <phunyguy> of course I don't have it compiled in. Why would I? This is gentoo [07:16:04 CET] <furq> lol [07:16:26 CET] <furq> well if it is gentoo then presumably it should at least be easy to include libfdk-aac [07:16:34 CET] <furq> which is a better aac encoder than the builtin one [07:17:34 CET] <phunyguy> that's enabled [07:17:57 CET] <furq> that should be more or less the same as vorbis in terms of quality [07:18:09 CET] <phunyguy> yep, just the container thing sucks [07:18:21 CET] <phunyguy> I think I am stuck without album art in files. [07:18:30 CET] <phunyguy> I mean, I can post-process, but blech [07:18:36 CET] <furq> m4a is all right [07:18:48 CET] <phunyguy> yes but that doesn't put album art in [07:18:53 CET] <furq> uh [07:18:55 CET] <furq> m4a should do [07:19:01 CET] <phunyguy> it didn't in my test [07:19:02 CET] <furq> i've definitely used ffmpeg for that [07:19:36 CET] <phunyguy> I tried -f m4a and -f ipod [07:19:42 CET] <phunyguy> both had no album art [07:23:48 CET] <phunyguy> I think is too much variation on how the encoding software has written this album art over the years. [07:25:19 CET] <phunyguy> and dumping the art beforehand is tough, because not everything has it [07:28:24 CET] <phunyguy> I think my best option is to remove the album art from the flacs, dump to a folder .jpg, and just have the script copy the jpg, and encode pure audio with ffmpeg [07:28:39 CET] <phunyguy> deal with the clutter on the phone another way [07:29:21 CET] <phunyguy> or... OR... [07:30:00 CET] <phunyguy> the organizing software I use has the option of dumping a cover.jpg AND embedding. I bet I can just have the script check for cover.jpg and postprocess if so [07:51:28 CET] <OneSploit> kepstin: I got disconnected yesterday, so you say gm107 supports only h264 right ? [07:53:34 CET] <OneSploit> whenever I use h264_nvenc my opengl framerate drops from 60fps to 30-40fps and I see 100% CPU usage instead of 70-80% like usual [08:08:49 CET] <theperfectpunk> I can't get to set my average bitrate in ffmpeg when encoding h264 [08:09:22 CET] <theperfectpunk> I'm using the following parameters : [08:09:23 CET] <theperfectpunk> ffmpeg -i Trailer.mp4 -c:v h264_qsv -b:v 80000k -bufsize 120M -minrate 80M -maxrate 80M -preset veryslow -c:a libmp3lame -b:v 320k out_trailer.mp4 [08:09:39 CET] <theperfectpunk> ffmpeg -i Trailer.mp4 -c:v h264_qsv -b:v 80M -bufsize 120M -minrate 80M -maxrate 80M -preset veryslow -c:a libmp3lame -b:v 320k out_trailer.mp4 [08:12:15 CET] <theperfectpunk> pastebin : https://pastebin.com/MaunSXRC [08:17:27 CET] <theperfectpunk> I have tried on multiple video files, the bitrate won't go higher than 3200k [08:17:55 CET] <theperfectpunk> I'm using ffmpeg version N-89674-g57d0c24132 [08:18:44 CET] <OneSploit> I have no clue how to set decent quality for recording game with ffmpeg using h264_nvenc coded [08:18:53 CET] <OneSploit> files look like shit and are big [08:23:25 CET] <theperfectpunk> OneSploit: libx264 does the [08:23:27 CET] <theperfectpunk> same [08:24:13 CET] <theperfectpunk> OneSploit: libx264 also doesn't go higher than 3200k [08:24:46 CET] <theperfectpunk> I have tried it on 3.4.1 too, same result [10:35:06 CET] <durandal_1707> furq: how do you know that builtin opus encoder sucks? [10:50:47 CET] <durandal_1707> occivink: how is your filter going? [10:53:48 CET] <occivink> nowhere yet, I've had other priorities these days [10:53:51 CET] <occivink> but thanks for checking on me [10:55:34 CET] <furq> durandal_1707: why else would it be marked as experimental [11:26:29 CET] <rav_> Hi, I am using libavformat to mux two RTP audio and video streams into a webm file. I recieve these streams as two different RTP streams on my server. Now, how do I set pts and dts values on AVPacket from these RTP timestamps ? [12:29:39 CET] <Sam___> Does anyone know why my subtitle disappear on long text? [12:30:15 CET] <Sam___> or how i can solve it, im ready to pay for this small solution [13:27:31 CET] <sybariten> Hey [13:28:10 CET] <sybariten> i'm trying to affect the bitrate, and it seems i am always getting the same filesize in the end. Input is a somewhat weird screencast, encoded as wmv . See anything strange with this command line ? [13:28:38 CET] <sybariten> ffmpeg -i "/data/temp/correction-201801221432-1.wmv" -ss 00:40:10 -t 00:02:45 -c:v libx264 -b:v 6M "/data/temp/correction-20180122 1432-1.mp4" [13:28:59 CET] <sybariten> I've been doing this with 1M , 6M, 0.5M ... the resulting file is always around 4.7 megabytes [13:29:41 CET] <sybariten> i get _heaps_ of warnings though, in the console [13:30:00 CET] <sybariten> [libfaac @ 0x1691540] Queue input is backward in time43.32 bitrate= 219.4kbits/s dup=3770 drop=0 [13:30:01 CET] <sybariten> [mp4 @ 0x1678ce0] Non-monotonous DTS in output stream 0:1; previous: 7206922, current: 7197689; changing to 7206923. This may result in incorrect timestamps in the output file. [13:30:34 CET] <BtbN> seems like x264 only needs a fraction of the bitrate you allowed it to use [13:30:43 CET] <BtbN> So it will hapily leave most of it unused [13:31:18 CET] <BtbN> See the wiki article about h264 encoding for more info on x264 encoding modes [13:32:22 CET] <sybariten> Hmmm ok [13:32:37 CET] <sybariten> maybe i should check what kinda bitrate i actually got, in the end. Is VLC reliable for that? [13:32:57 CET] <BtbN> Just look at the file size? [13:33:11 CET] <BtbN> You know how long it is, and you know the size. [13:34:11 CET] <sybariten> almost three minutes at almost 5 megabytes [13:41:13 CET] <DHE> sybariten: at the end of encoding, x264 prints a bunch of statistics. can you pastebin that? [13:46:11 CET] <sybariten> DHE: sure, they are here together with the last part opf the warnings.... https://pastebin.com/ZKvj8zRq [13:47:29 CET] <sybariten> Uh sorry, this was for a slightly different test run though...! So the numbers arent exactly as i said before. Resulting file = 1.7 Mbyte [13:48:17 CET] <sybariten> So the combined audio+vidoe bitrate is maybe 234 kilobits? [13:48:41 CET] <kepstin> sybariten: that should basically only happen if you have nearly blank/still video [13:48:59 CET] <sybariten> kepstin: well you know, it's a screencast .... it's very still! [13:49:16 CET] <sybariten> You see a web pagfe for a long time [13:49:46 CET] <kepstin> based on those stats, it literally cannot increase the quality any higher to make the video bigger with the encoding mode you have selected. [13:49:57 CET] <sybariten> kepstin: i see. Ok fine. [13:50:11 CET] <kepstin> you could do lossless, that would make it bigger. [13:50:37 CET] <sybariten> The audio gets very fragmented though, i notice now. There are regular drops, sort of like when you're listning to a bad web stream or web conference. And this is not in the source file. So i need to look into how the audio is coded [13:51:15 CET] <kepstin> that's probably related to the timestamp issues ffmpeg is complaining about [13:54:40 CET] <DHE> sybariten: yeah, with qp values in the single-digit range x264 is already making a super-high-quality video [13:54:45 CET] <sybariten> kepstin: i would guess so too! [13:56:21 CET] <OneSploit> sybariten: qp? [13:56:27 CET] <OneSploit> you mean preset=qp ? [13:56:53 CET] <iive> quantizer parameter [13:57:08 CET] <OneSploit> what parameters do I need to get decent video? [13:57:24 CET] <OneSploit> I got this https://vimeo.com/252321808 [13:57:28 CET] <OneSploit> looks aweful [13:57:50 CET] <Sam___> Anyone who is able to help me, regarding subtitle [13:58:06 CET] <iive> qp controls the loss and thus is most influential on quality. however [13:58:36 CET] <iive> crf is mostly used, since it tunes qp depending on a number of other factors. [13:59:01 CET] <OneSploit> I think I used crf=11 [13:59:05 CET] <Sam___> my subtitles disappear when there is long text, how can i solve this? [13:59:07 CET] <iive> crf=18 should give excelent quality. For temp stuff I find 22 acceptable. [13:59:24 CET] <OneSploit> ok so my video should be resonable [13:59:27 CET] <OneSploit> but it looks horrible [14:00:43 CET] <sfan5> OneSploit: are you sure that those artifacts are not present in the source video? [14:00:46 CET] <iive> I don't see anything wrong in the video [14:01:06 CET] <iive> e.g. the text on the left is quite crisp. [14:01:11 CET] <OneSploit> sfan5: I dont think they are [14:01:29 CET] <OneSploit> I use 5000 kbps preset=fast,crf=11,keyinit=1 [14:01:39 CET] <OneSploit> whatever keyinit means.. dunno but was there [14:01:52 CET] <iive> keyframe interval... [14:02:03 CET] <OneSploit> and Matroska MKV [14:02:05 CET] <iive> 1 means every frame is keyframe [14:02:21 CET] <sfan5> use either crf or bitrate, but not both [14:02:21 CET] <OneSploit> oh what value should it be than? [14:02:34 CET] <sfan5> and don't fiddle with the keyint setting [14:02:35 CET] <q66> (also it's keyint, not keyinit) [14:02:51 CET] <OneSploit> sfan5: I think simplescreenrecorder has bitrate field, so it will use both [14:03:00 CET] <q66> it can't use both [14:03:05 CET] <q66> they're different rate control methods [14:03:20 CET] <Sam___> Anyone who is able to help me regarding my subtitle issue, would appreciate it [14:03:21 CET] <OneSploit> ok so I should get rid of crf [14:03:30 CET] <OneSploit> and use keyint=1 [14:03:39 CET] <OneSploit> but what kbps is suitable ? [14:03:42 CET] <q66> no [14:03:47 CET] <sfan5> you should get rid of keyint=1 and use crf [14:03:51 CET] <q66> don't use kbps, use crf, and don't mess with keyint [14:04:03 CET] <sfan5> Sam___: just ask your question, someone might be able to answer [14:04:07 CET] <OneSploit> but my recorder always sets kbps [14:04:12 CET] <sfan5> oh nvm you did already [14:04:17 CET] <OneSploit> it has field for it [14:04:47 CET] <iive> Sam___, I assume text subtitles. are you muxing them into a file? are you embedding them into the video? [14:04:52 CET] <sfan5> well you could use a beter software [14:04:55 CET] <sfan5> better* [14:05:08 CET] <sfan5> but if you set kbps to some high-enough value, it should be fine [14:05:10 CET] <OneSploit> sfan5: like obs which does not work and crashes... [14:05:20 CET] <sfan5> yes yes I know that you hate obs for no good reason [14:05:32 CET] <OneSploit> I really want to like it [14:05:35 CET] <OneSploit> trying hard [14:05:35 CET] <Sam___> I'm using filter complex to view subtitle on my live stream, stream is showing subtitle perfectly, until there is long speech/long text, then stream doesnt show subtitle but shows the next phrase instead. [14:06:12 CET] <OneSploit> sfan5: oh and another thing, obs I have in debian packages has no game source [14:06:30 CET] <OneSploit> only source is Xsh or something which particulary records whole desktop instead of opengl window alone [14:06:35 CET] <Sam___> So basically my stream skips long subtitles [14:06:36 CET] <sfan5> i doubt debian would ship something so broken [14:06:45 CET] <OneSploit> wanna screenshot? [14:06:50 CET] <OneSploit> as a proof [14:07:07 CET] <sfan5> nah [14:07:15 CET] <OneSploit> also I compiled obs, same issue, no "game source" or anything that resembles opengl app source [14:07:39 CET] <OneSploit> but simplescreenrecorder has no issus with that, except forcing me to use kbps [14:08:47 CET] <OneSploit> sfan5: so I hope you can understand my hesitation when it comes to obs.. I keep giving it a chance, but I dont think it's willing to cooperate [14:09:10 CET] <iive> Sam___, so it is likely a bug with the subtitle filter. You might have to report a bug. Can you make a small sample file that reproduces the issue? [14:11:43 CET] <Sam___> iive, yeah might be able to [15:57:00 CET] <csguth> hello hello [15:57:38 CET] <csguth> Can someone help me with building ffmpeg + x264 on win10 (msvc2015) ? I'd like to use it on pjsip. [15:58:28 CET] <JEEB> FFmpeg can be built with MSVC, but not sure how easy x264 is to build with it. I remember trying some years ago but I don't remember if I succeeded [15:58:50 CET] <csguth> x264 is pretty straightforward.. [15:59:08 CET] <csguth> my problem is with ffmpeg, the configure script is messing with cflags and ldflags. [15:59:15 CET] <csguth> this is my command line: [15:59:40 CET] <csguth> ./configure --toolchain=msvc --enable-shared --disable-static --enable-libx264 --enable-gpl --prefix=$PWD/install_prefix --extra-cflags="-I../x264-snapshot-20180118-2245/install_prefix/include" --extra-ldflags="-L../x264-snapshot-20180118-2245/install_prefix/lib" [16:00:20 CET] <JEEB> thank you for using --prefix <3 [16:00:30 CET] <csguth> haha [16:00:33 CET] <JEEB> anyways, in theory the cflags should come from pkg-config [16:00:34 CET] <csguth> you're welcome [16:00:39 CET] <JEEB> which x264 installs [16:00:43 CET] <JEEB> (the .pc file) [16:00:48 CET] <JEEB> prefix/lib/pkgconfig [16:00:48 CET] <csguth> I see.. [16:01:04 CET] <csguth> let me try without the flags. [16:01:08 CET] <JEEB> so you have to set PKG_CONFIG_PATH=/prefix/lib/pkgconfig to tell pkg-config to check there a well [16:01:19 CET] <csguth> btw, I'm building ffmpeg 2.6.13 [16:01:23 CET] <JEEB> uhhhh [16:01:27 CET] <JEEB> ok [16:01:29 CET] <csguth> yeah, you're right.. [16:01:38 CET] <csguth> I just ommited PKG_CONFIG_PATH in my command [16:01:46 CET] <JEEB> I am not sure when MSVC support was added [16:02:00 CET] <JEEB> and there have been improvements to it along the years [16:02:09 CET] <csguth> It seems like its using msvc.. [16:02:09 CET] <JEEB> I think the support was added circa 2013 [16:02:22 CET] <csguth> but it's trying to use /L../x264... [16:02:31 CET] <csguth> Instead of /LIBDIR or something like this [16:02:36 CET] <JEEB> ok, that then comes from the .pc file [16:02:39 CET] <JEEB> most likely? [16:02:46 CET] <csguth> I hope so... [16:02:52 CET] <csguth> I'm running configure [16:03:16 CET] <csguth> With the right PKG_CONFIG_PATH :) [16:03:33 CET] <JEEB> so either you tell configure to give additional params to pkg-config (it might have had an option to convert options from GCC style to MSVC, otherwise just edit the .pc file) [16:03:56 CET] <JEEB> there's --pkg-config-flags=FLAGS [16:04:04 CET] <JEEB> for additional flags to be given to pkg-config [16:04:08 CET] <csguth> uhhhh [16:04:30 CET] <JEEB> and if you can't find an option to do the conversion, then just modify the .pc file [16:04:37 CET] <csguth> ok [16:04:49 CET] <csguth> I didn't try this yet.. [16:05:21 CET] <csguth> let me wait for the configure command (without pkg flags) to finish. [16:05:22 CET] <JEEB> ok, there seems to be --msvc-syntax in pkg-config [16:05:33 CET] <JEEB> looking at https://linux.die.net/man/1/pkg-config [16:05:39 CET] <csguth> Yep, there is.. I used it in some other project. [16:08:37 CET] <csguth> trying with --pkg-config-flags="--msvc-syntax" [16:13:11 CET] <csguth> hmm [16:13:31 CET] <csguth> still not working.. but now I believe the problem is the win32 syntax for file paths.. [16:13:46 CET] <JEEB> yea, msys can be weird :P [16:13:48 CET] <csguth> I'm gonna change the .pc file to use /c/Program Files/ ... [16:13:55 CET] <csguth> instead of C:\... [16:14:14 CET] <csguth> ooppps [16:14:30 CET] <csguth> the .pc file is using /c/... [16:15:15 CET] <csguth> config.log is pointing "ignoring unknown option '/libpath:C:/path/to/lib' [16:16:39 CET] <csguth> on cl.exe [16:17:05 CET] <csguth> how strange.. [16:17:10 CET] <csguth> cl is using /libpath [16:17:15 CET] <csguth> and link is using -I [16:17:18 CET] <csguth> ¬¬ [16:18:33 CET] <csguth> I guess it's using both flags on both programs.. nevermind. [16:53:20 CET] <TAFB> if I want to convert a 4k "REMUX.HEVC.DTS-HD.MA.5.1" down to 1080p but I want it to be super sharp (whenever I've tried to use ffmpeg to reduce ther resolution it always blurs it a bit), what's the secret? [16:54:55 CET] <TAFB> I'm using "ffmpeg -i 4k.mp4 -vf scale=1920:-1 1080p.mp4" [16:59:01 CET] <TAFB> -sws_flags lanczos+print_info?????? [17:00:21 CET] <c_14> have you tried using a different scalar? [17:00:22 CET] <c_14> say bicubic? [17:01:54 CET] <TAFB> bicubic is the default, no? [17:02:13 CET] <c_14> yeah [17:02:36 CET] <TAFB> there is for sure some blurring filter going on with bicubic [17:04:56 CET] <TAFB> i'm going to try lanczos on a short clip and see if it's sharper [17:18:46 CET] <DHE> there's also the colour depth. yuv420 is standard but yuv444 will give a better image. [17:19:02 CET] <DHE> but a lot of video players, especially hardware like smart TVs, will only accept yuv420 [17:22:26 CET] <TAFB> yuv444 works with h264? [17:22:52 CET] <TAFB> i think that might help because I see lots of colour banding after the converting (even with crf 0) [17:22:58 CET] <DHE> yes, but it requires a player with Main444 or High444 etc profile support. The defaults of Main and High only specify yuv420 [17:23:31 CET] <DHE> okay, apparently there is no such thing as Main444. but you get the idea [17:27:39 CET] <TAFB> ok, running a test convert now with -pix_fmt yuv444p [17:33:39 CET] <TAFB> -sws_flags neighbor seems to look sharpest, yuv444 got rid of the colour banding :) looking real nice now, thanks! [18:14:08 CET] <myName_> I have week cpu, I want to save mjpeg stream to images as jpeg files, ffmpeg -i http://..... image%d.jpeg but then I see that ffmpeg save t me only 2.5~3 images per secondes. (that ok i know i have week cpu) but when i add filter to save only 2 images per seconds i see that ffmpeg saved only 0.6~0.8 images per secondes, why?? ffmpeg -i http://..... -vf fps=2 images%d.jpeg [18:15:21 CET] <kepstin> myName_: maybe the problem is that decoding the video is slow. [18:15:36 CET] <myName_> how can i fast decoding?? [18:19:49 CET] <Johnx_> Quick question regarding ffmpeg, i have a python script that uses ffmpeg to check for udp streams for errors. I have noticed that when ffmpeg is paired with sleep or timeout, it doenst output any errors other than just header connection info: https://pastebin.com/VnPMQe70 [18:20:52 CET] <Johnx_> the moment sleep or/and timeout is removed, i get the usual list of errors, like co-located , etc... [18:21:36 CET] <Johnx_> any suggestions on what can be done to get ffmpeg to output all decoding errors when paired with sleep and timeout [18:21:46 CET] <Johnx_> i am on cent 7 [18:22:39 CET] <myName_> kepstin: how can i fast decoding ? that mjpeg stream not 264 . i cna't use preset ultrafast [18:23:51 CET] <kepstin> myName_: actually, if the original stream is jpeg, there's no reason to encode or decode at all. Try adding the "-c copy" option. [18:24:29 CET] <c_14> can't adjust the fps to drop images then though [18:25:23 CET] <myName_> kepstin: that mjpeg stream 1, when i use decode i see i get only 20 fps not 25 so i see 0.8x (so that not good video) 2, now i tried to get 2-3 images per seconds [18:32:49 CET] <c_14> have you ever tried with -c copy? [18:33:20 CET] <myName_> c_14, yes when i use -c copy i get only 0.8x speed [18:34:04 CET] <kepstin> myName_: what are you writing the files to? Is it an SD card or something? maybe that's too slow. [18:34:52 CET] <myName_> kepstin yes it is , [18:38:37 CET] <myName_> kepstin: but on top conad i see that my prolem is cpu not io [18:39:20 CET] <kepstin> What percentage is iowait? [19:01:45 CET] <myName_> kepstin: what do you mean? how can i check it ? [19:10:37 CET] <saml> what's difference between -psnr and -filter_complex psnr? looks like -psnr is taking one input and during encoding process, it calulates psnr [19:10:49 CET] <saml> not sure how -psnr would work if I specify different -r and -s [19:11:17 CET] <saml> -filter_complex psnr requires both reference and main video to have same dimension and framerate [19:28:09 CET] <saml> so, -psnr -tune psnr is good. but -filter_complex psnr no good bro [19:28:15 CET] <saml> oh man psnr just die [19:40:06 CET] <kepstin> saml: the psnr filter is a filter that can be used to calculate psnr between any two arbitrary video streams, and it runs in the filter chain before the encoder. The '-psnr' option, tells the encoder to calculate the psnr between its input and its output [19:41:54 CET] <kepstin> saml: the "-tune psnr" option of course does something completely different - it tells the x264 encoder to encode the video optimized in a way to make psnr as high as possible. This makes the visual quality lower. [19:51:07 CET] <saml> so, I do this ffmpeg -i 4k.webm -psnr -tune psnr -pix_fmt rgb24 -r 10 -s 480x270 -vcodec libx264rgb -acodec aac a.mp4 [19:51:15 CET] <saml> I get 43 Average PSNR [19:51:29 CET] <saml> now I do this ffmpeg -i a.mp4 -i 4k.webm -filter_complex "scale2ref [vid][ref]; [vid][ref] psnr" -f null - [19:51:37 CET] <saml> a.mp4 is the output of previous encoding [19:51:42 CET] <saml> I get 27 PSNR [19:52:02 CET] <saml> i also tried more complex filter graph scale2ref [vid][ref]; [vid] format=pix_fmts=yuv420p [vid_f]; [ref] format=pix_fmts=yuv420p [ref_f]; [vid_f] framerate [vid_fr]; [ref_f] framerate [ref_fr]; [vid_fr][ref_fr] psnr [19:52:18 CET] <saml> that barely gives me 1 more PSNR (27.8) [19:52:57 CET] <saml> i think, once video is scaled during encoding, i cannot use psnr filter to calculate "original" psnr values that were calculated during encoding [19:53:14 CET] <saml> that also means what i'm doing with psnr filter is useless almost [19:53:22 CET] <saml> hehehehehehhehehehehehehehehehehehehehehehe [19:53:42 CET] <kepstin> well, I don't know what you're trying to do with the psnr filter, but yes - attempting to make it show the same number as a different thing is quite useless [19:55:56 CET] <sfan5> are you taking the psnr of the upscaled video there? [20:05:46 CET] <saml> sfan5, yes [20:06:05 CET] <sfan5> i wouldn't expect that to work [20:06:20 CET] <sfan5> you should scale the reference down and then compare ref & output [20:06:33 CET] <saml> ah i thought i was scaling reference down, actually [20:06:56 CET] <saml> yeah i'm scaling ref down [20:07:05 CET] <sfan5> my mistake, then [20:07:40 CET] <saml> or i'm wrong [20:08:14 CET] <saml> https://www.ffmpeg.org/ffmpeg-all.html#scale2ref i'm assuming first argument is video. second input is ref. [20:08:22 CET] <saml> oh yeah i'm wrong [20:08:42 CET] <saml> i should pass ref first so that ref will be scaled down to vid [20:08:44 CET] <saml> thanks [20:10:19 CET] <myName_> how can i faster the encoder when i save mjpeg stream to avi file [20:12:24 CET] <saml> by scaling ref down, i get PSNR up to 29.4 [20:12:26 CET] <saml> win [20:12:44 CET] Action: saml looks into vmaf [20:13:26 CET] <sfan5> why would you ever optimize your video for high PSNR though? [20:39:39 CET] <saml> sfan5, no idea [20:40:03 CET] <saml> i think some books are written for psnr as main example [20:47:56 CET] <myName_> how can i faster the encoder when i save mjpeg stream to avi file [20:51:39 CET] <BtbN> More cores [20:51:48 CET] <BtbN> Or faster ones [20:53:56 CET] <saml> are you implementing gyfcat or something? [20:55:40 CET] <sfan5> gfycat uses h.264 w/o audio inside .mp4 as a gif replacement [20:55:43 CET] <sfan5> so no mjpeg involved [20:56:13 CET] <saml> ah i see. [20:56:25 CET] <saml> i didn't know what mjpeg was [20:56:27 CET] <myName_> how can i faster the encoder when i save mjpeg stream to avi file [20:56:46 CET] <saml> myName_, do you have command line that you're using? [20:57:02 CET] <saml> or are you using libraries? [20:58:37 CET] <myName_> saml: ffmpeg -i http://......(mjpeg stream) -c:v copy 1.avi [20:59:35 CET] <saml> if you're using copy as codec... i wonder if bottleneck is http request [20:59:38 CET] <kepstin> myName_: if that can't do realtime, then either your storage device is too slow, network is too slow, or cpu is too slow (in that order) and there's not really much we can do about it. [21:00:09 CET] <saml> have you tried curl http://.... -o a.mjpeg; ffmpeg -i a.mjpeg -c:v copy 1.avi [21:04:19 CET] <alexpigment> myName_ are you the same person as "sdds" from yesterday? [21:33:09 CET] <SortaCore> what's the profile/level etc support of openh264? [21:33:18 CET] <SortaCore> https://github.com/cisco/openh264/blob/master/README.md says just constrained baseline up to level 5.2 [21:35:38 CET] <SortaCore> https://github.com/cisco/openh264/blob/master/codec/encoder/core/src/encode… says main/high as well [21:40:22 CET] <JEEB> SortaCore: since constrained baseline is a subset of main/high I wouldn't be surprised if you can set the stream to be advertised as main/high [21:40:35 CET] <JEEB> but I don't think openh264 actually can encode more than constrained baseline [21:41:40 CET] <kepstin> i'm pretty sure the decoder can't decode anything above baseline either [21:41:47 CET] <DHE> the level is more a measure of CPU power than anything else, so 5.2 is possible if you have a beast of a CPU... [21:41:53 CET] <DHE> then again baseline is probably really easy to do [21:42:28 CET] <SortaCore> so decoding is probably ok with everything, but encoding is constrained baseline only? [21:42:38 CET] <JEEB> no, decoding is most likely limited, too :P [21:42:50 CET] <JEEB> DHE: to be exact level is "how much memory the decoder requires to decode this" [21:42:51 CET] <JEEB> :P [21:42:55 CET] <SortaCore> _nuu_ [21:43:04 CET] <JEEB> since it controls bit rate / amount of reference frames [21:43:27 CET] <JEEB> and the latter decides how much memory the decoder has to hold to keep those [21:43:32 CET] <kepstin> last I checked, their decoded didn't implement features required to decode any profiles higher than constrained baseline [21:43:39 CET] <kepstin> so it'll fail to decode main or high [21:43:42 CET] <JEEB> yea [21:44:02 CET] <JEEB> otherwise firefox etc could use those cisco binaries for all the H.264 :P [21:44:03 CET] <DHE> JEEB: it also decides number of macroblocks, which is effectively image resolution [21:44:17 CET] <DHE> *per second, so framerate as well [21:44:26 CET] <JEEB> yes [21:44:31 CET] <JEEB> that's where the ref count comes IIRC [21:44:49 CET] <JEEB> size in macroblocks VS amount of refs basically [21:44:49 CET] <DHE> ref frames for RAM, blocks*framerate for CPU power [21:45:07 CET] <DHE> so, both [21:45:18 CET] <SortaCore> rawr [21:45:24 CET] <JEEB> basically the less macroblocks the more refs because a single image takes less memory [21:45:43 CET] <JEEB> but generally decoders that actuall care about levels aren't using a CPU anyways :P [21:51:59 CET] <SortaCore> I'm trying to set up this interface for a developer to select encoding settings - trying to work out what codecs support which parameter types [21:52:08 CET] <SortaCore> like preset [21:53:15 CET] <ChocolateArmpits> SortaCore, run ffmpeg -help encoder=[encoder name] [21:54:00 CET] <ChocolateArmpits> to get a list of encoders: ffmpeg -encoders [22:01:11 CET] <SortaCore> yea, that helps a bit Choc [22:01:30 CET] <SortaCore> although, with the number of options available, I'd need an AI to work out the best :p [22:02:25 CET] <SortaCore> what's trellis? [22:06:08 CET] <GyrosGeier> SortaCore, https://en.wikipedia.org/wiki/Trellis_modulation [22:06:33 CET] <GyrosGeier> this maps a bitstream to another bitstream of the same length [22:07:25 CET] <GyrosGeier> but with better error correction properties [22:07:28 CET] <SortaCore> okay, is color primary and color range passed to libx264 encoder if called via C++? [22:07:48 CET] <SortaCore> so trellis is good [22:08:06 CET] <GyrosGeier> it depends on your use case [22:08:14 CET] <GyrosGeier> if you have a noisy channel, yes [22:08:22 CET] <GyrosGeier> otherwise, it's useless [22:08:33 CET] <JEEB> wrong trellis [22:08:40 CET] <GyrosGeier> oh? [22:09:24 CET] <GyrosGeier> I thought it was used for transport streams to improve error detection [22:09:32 CET] <JEEB> this was about libx264 [22:09:38 CET] <GyrosGeier> sorry for the confusion then [22:09:42 CET] <JEEB> where trellis quantization is utilized for various things :P [22:09:56 CET] <JEEB> there's even a thing called psy-trellis :P [22:10:07 CET] <SortaCore> well, I'm using trellis in multiple encoders [22:10:21 CET] <JEEB> anyways, generally for x264 you just give the user the presets, tunes and profile+level if limitation is needed. if you really need more custom stuff, let them pass libx264 API key=value pairs into x264-params [22:10:24 CET] <SortaCore> is it all the same concept in all of them [22:10:27 CET] <JEEB> that's my general opinion [22:10:59 CET] <SortaCore> that's basically what I'm doing [22:11:21 CET] <JEEB> for streaming etc you need some additional parameters like VBV/HRD maxrate/bufsize and HRD signaling mode, but those start going into "I know my stuff" territory [22:11:22 CET] <SortaCore> but because QSV doesn't have tune support, I can at least tell the user when they pick QSV and then pick tune, it will be ignored [22:13:11 CET] Action: GyrosGeier needs a sane preset for reencoding an NTSC DVD [22:13:33 CET] <SortaCore> because codecs have the habit of aborting in avcodec_open2 when the values are unsupported - instead of just picking something close [22:13:34 CET] <GyrosGeier> 480i [22:13:47 CET] <SortaCore> and they don't provide any useful error info in QSV's case [22:14:27 CET] <SortaCore> I'm getting a stream and it has JPEG color range, and not sure if libx264 is getting passed that, as the output mp4 files come up as full color range [22:14:35 CET] <GyrosGeier> if I attempt to deinterlace, the resulting video is not sanely compressible anymore [22:15:03 CET] <JEEB> SortaCore: you have to work pretty hard to get libx264 to mark YCbCr as full range [22:15:12 CET] <JEEB> in libx264 itself as well as libavcodec [22:15:29 CET] <JEEB> so if you're taking stuff in that's marked as limited range, that should stay as-is :P [22:16:45 CET] <ChocolateArmpits> GyrosGeier, imo most deinterlacers are catastrophic except for qtgmc. [22:17:37 CET] <GyrosGeier> I've tried "-flags +ilme" to keep the content interlaced [22:18:01 CET] <ChocolateArmpits> GyrosGeier, you need -x264-params tff/bff=1:interlaced=1 also the "full set" is -flags +ildct+ilme [22:18:42 CET] <GyrosGeier> some of the material was shot with an NTSC camera from the back of a fighter plane, the two fields look nothing alike :P [22:18:43 CET] <ChocolateArmpits> for tff/bff pick your field order [22:18:48 CET] Action: GyrosGeier reboots and tries [22:19:05 CET] <ChocolateArmpits> as in it's either "tff" or "bff" [22:19:53 CET] <alexpigment> ChocolateArmpits: the x264-params part is unnecessary is the source is interlaced, in my experience [22:20:19 CET] <alexpigment> the "-flags +ildct+ilme" will preserve the interlacing and make x264 use MBAFF [22:20:48 CET] <ChocolateArmpits> well I punch in everything to cover any imaginary situation [22:20:49 CET] <alexpigment> honestly, i think one of those flags is even unnecessary, but i've never gotten around to remembering which one it is, because it doesn't hurt anything to specify both [22:21:00 CET] <SortaCore> JEEB: No, it's dropping it, maybe due to YUVJ codec? https://pastebin.com/raw/q5h1dYiE [22:21:33 CET] <JEEB> "Stream #0:0: Video: h264 (High), yuvj420p(pc, bt709, progressive)" [22:21:35 CET] <alexpigment> ChocolateArmpits: understandable [22:21:35 CET] <JEEB> > pc [22:21:42 CET] <JEEB> that is *full* range [22:21:57 CET] <JEEB> so yes, ffmpeg.c is actually passing that information through there :P [22:22:00 CET] <SortaCore> YUVJ420P is YUV420P with jpeg color range though? [22:22:09 CET] <JEEB> yes, but the metadata is more important tbh [22:22:10 CET] <kepstin> jpeg range is the same thing as full range [22:22:13 CET] <kepstin> aka pc range [22:22:20 CET] <JEEB> or well, that's where you should see it [22:22:27 CET] <JEEB> at some point the "J" pix_fmts will go away [22:22:38 CET] <JEEB> they're an old leftover from ye olden days :P [22:22:47 CET] <SortaCore> yea, I'm just seeing the output file in MediaInfo, and it says "full range" where I'm expecting "jpeg range" [22:22:54 CET] <SortaCore> if they're synonyms then no prob [22:22:57 CET] <JEEB> yes [22:23:06 CET] <JEEB> full range is the generic way of saying it [22:23:25 CET] <JEEB> tv/limited range is the generic way of saying 16-235/240 [22:24:06 CET] <alexpigment> GyrosGeier: fwiw, I usually keep things interlaced if I'm being lazy, but you really need to first decide if your content is telecined, fake interlaced (e.g. 30p native) or true interlaced. I have a different process for each scenario, personally [22:24:09 CET] <SortaCore> what is the pc part? [22:24:36 CET] <JEEB> ffmpeg.c/ffprobe.c note it as "tv" (16-235/240) or "pc" (0-255) [22:24:50 CET] <JEEB> 99% of all video in the world is TV/limited range :P [22:25:02 CET] <JEEB> and pretty much just screen capture formats encode in full range [22:25:06 CET] <kepstin> SortaCore: pc as in "personal computer". PC screen output is full range. [22:25:37 CET] <GyrosGeier> hm [22:25:43 CET] <SortaCore> alright, I've also seen "mpeg range" knocking about [22:25:47 CET] <kepstin> (notably, this means that since 99% of video is limited range, all pc video players have to convert to full range for display) [22:25:59 CET] <JEEB> SortaCore: that's what some things call limited range since video is 99% limited range [22:26:03 CET] <JEEB> :P [22:26:04 CET] <kepstin> mpeg range is another synonym for tv range or limited range [22:26:04 CET] <GyrosGeier> the DVD has a big NTSC logo on it, so I suspect it's proper 30000/1001 [22:26:20 CET] <kepstin> jpeg = pc = full in contrast to mpeg = tv = limited [22:26:20 CET] <alexpigment> GyrosGeier: yes, but there are best practices for the source format [22:26:35 CET] <SortaCore> three names for the same thing (thumbs up) :p [22:26:36 CET] <alexpigment> for example, for film sourced material, it's best to detelecine [22:27:02 CET] <JEEB> interlaced fields can be thought of as a container :P [22:27:14 CET] <SortaCore> could someone put a code comment in where the color ranges are defined? [22:27:15 CET] <JEEB> content can be whatever, as many people have seen during the years [22:27:38 CET] <SortaCore> with the a.k.a's, should leave less questions in future [22:27:50 CET] <GyrosGeier> hmmm [22:28:01 CET] <GyrosGeier> the source material is Super8 and 16mm [22:28:28 CET] <kepstin> GyrosGeier: in that case it'll be telecined. do you know the original film framerate? [22:28:43 CET] <kepstin> it's probably either 12 or 24, in which case it would be the normal 2:3 telecine pattern. [22:28:44 CET] <alexpigment> GyrosGeier: oh fun. the detelecining process for that is kinda wonky [22:28:53 CET] <alexpigment> super8 is 16 or 18 i thought... [22:28:58 CET] <kepstin> oh, great [22:28:59 CET] <JEEB> SortaCore: https://ffmpeg.org/doxygen/trunk/pixfmt_8h.html#a3da0bf691418bc22c4bcbe6583… [22:29:02 CET] <GyrosGeier> well, probably "mixed" [22:29:20 CET] <alexpigment> in this scenario, i'd just stay with interlaced ;) [22:29:25 CET] <GyrosGeier> so I'd have to switch in the middle of the stream [22:29:27 CET] <kepstin> GyrosGeier: well, what you can do depends entirely on how the framerate conversion was done :/ [22:29:28 CET] <JEEB> although it still utilizes the "MPEG"/"JPEG" nomenclature :P [22:29:30 CET] <SortaCore> yea, they're defined as RGB ranges, that's fine, but the alternative names of the ranges would help too [22:29:43 CET] <JEEB> ... [22:29:46 CET] <SortaCore> so future people don't get puzzled like I did [22:29:48 CET] <JEEB> where do you see RGB there? [22:29:55 CET] <JEEB> "the normal 219*2^(n-8) "MPEG" YUV ranges" [22:29:59 CET] <SortaCore> I meant the numbers [22:30:10 CET] <JEEB> they're not RGB ranges [22:30:34 CET] <SortaCore> force of habit [22:31:25 CET] <SortaCore> but yea, if by their names they also had their alternative names, it would clarify things [22:31:57 CET] <GyrosGeier> do I need "-g 300"? [22:32:22 CET] <kepstin> GyrosGeier: you don't "need" it, why do you have it in the first place? [22:33:03 CET] <kepstin> GyrosGeier: increasing the gop size (~keyframe interval) can improve encoding efficiency but it'll make seeking slower. [22:33:29 CET] <alexpigment> i personally like to use -g [same as framerate], but i know others would probably think that's excessive [22:33:46 CET] <alexpigment> i just care more about seeking than I do small file sizes [22:34:02 CET] <kepstin> same as framerate gives a keyframe every second, which will give responsive seeking but larger files, particularly in video that's generally low motion [22:34:03 CET] <alexpigment> and i prefer to feel like i'm using an appliance than a computer when I use my HTPC :) [22:35:01 CET] <GyrosGeier> with just -flags +ildct+ilme and 1024kbps, the quality is bad [22:35:16 CET] <alexpigment> do you need it to be 1024kbps? [22:35:23 CET] <alexpigment> that seems low to me [22:35:25 CET] <GyrosGeier> ah [22:35:52 CET] <GyrosGeier> the source material is MPEG2 with 8500kbps [22:36:04 CET] <kepstin> source bitrate is irrelevant, of course. [22:36:13 CET] <kepstin> GyrosGeier: unless you are targetting a specific filesize, you should use the "-crf" option instead of setting a bitrate. The default is -crf 24 i think? [22:36:21 CET] <kepstin> lower numbers are higher quality - adjust to taste. [22:36:42 CET] <kepstin> generally around 18 and lower is considered "very high" quality. [22:37:47 CET] <GyrosGeier> with -crf 24, it uses 693kbps [22:38:30 CET] <GyrosGeier> hm, that option does nothing [22:38:52 CET] <kepstin> GyrosGeier: hmm, wait a minute, what codec are you encoding with? [22:39:54 CET] <GyrosGeier> ah [22:39:55 CET] <alexpigment> does it start with a v and end with p8? ;) [22:40:00 CET] <GyrosGeier> that is part of the problem [22:40:15 CET] <GyrosGeier> Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 720x480 [SAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc [22:40:18 CET] <kepstin> GyrosGeier: you'll probably want to add a "-c:v libx264" in there :) [22:40:40 CET] <kepstin> hmm, the sar on that video is wrong [22:40:59 CET] <kepstin> (it's close enough that most people won't notice tho) [22:41:30 CET] <alexpigment> kepstin: how so? [22:41:48 CET] <kepstin> ntsc "4:3" video in a 720x480 frame has a sar of 10/11 [22:41:53 CET] <alexpigment> hmmmm [22:41:59 CET] <alexpigment> are you sure? [22:42:08 CET] <alexpigment> is it possible you're thinking of 704x480? [22:42:23 CET] <kepstin> 704x480 has the same sar [22:42:46 CET] <kepstin> you turn 720x480 into 704x480 by cropping off 8px on each side [22:42:49 CET] <GyrosGeier> now encoding is a lot slower, I take that as a good sign [22:43:19 CET] <alexpigment> kepstin: that actually depends, in my experience [22:43:30 CET] <kepstin> which means that the 720x480 is actually slightly *wider* than 4:3, and it contains stuff on the edges that's normally out of frame when shown on a tv [22:43:33 CET] <alexpigment> you can use the full 720x480 if you want, but most broadcast doesn't [22:43:42 CET] <SortaCore> how do you invoke NVENC for encoding? [22:43:57 CET] <alexpigment> sortacore: -c:v h264_nvence [22:44:00 CET] <alexpigment> gah [22:44:04 CET] <alexpigment> h264_nvenc [22:44:09 CET] <SortaCore> yea, that's using cpu though [22:44:18 CET] <alexpigment> it uses some for decoding [22:44:19 CET] <SortaCore> 0% GPU usage [22:44:26 CET] <alexpigment> well, that's another story :) [22:44:27 CET] <GyrosGeier> yes, the result is way better now [22:44:52 CET] <kepstin> alexpigment: whether or not there's stuff in the extra pixels in 720x480 depends, there's usually something in there. But either way, displaying 720x480 as 4:3 is wrong. [22:45:04 CET] <SortaCore> I tried putting the input into dxva2, and it switched the pixel format to NV12 in output, but still 0% GPU usage [22:45:05 CET] <GyrosGeier> alexpigment, IIRC NTSC only guarantees 400 pixels vertically to be visible [22:45:20 CET] <alexpigment> ? [22:45:28 CET] <alexpigment> i work a lot with 480i [22:45:33 CET] <kepstin> that's not relevant, we're talking about horizontal here ;) [22:46:09 CET] <kepstin> and ntsc doesn't have anything named "pixels" in any specifications anywhere ;) [22:46:25 CET] <GyrosGeier> at least the 640x400 usable pixels on my Amiga are close to the edges of my CRT :/ [22:46:42 CET] <alexpigment> anyway, i've got a bunch of material that's 720x480. it's all 8:9 [22:47:19 CET] <kepstin> alexpigment: it *should* be 10/11, whatever's giving you the 8/9 number is doing something wrong (it's assuming that the 720x480 corresponds to 4:3, which is incorrect) [22:47:19 CET] <GyrosGeier> can I use multiple threads or OpenCL to speed up encoding? [22:47:33 CET] <alexpigment> kepstin: do you have any 480i? you mind just double checking? [22:47:34 CET] <SortaCore> any ideas about nvenc? *stares hard at it* [22:47:50 CET] <alexpigment> sortacore: do you have a monitor plugged into the nvidia gpu? [22:47:56 CET] <SortaCore> yep [22:48:01 CET] <alexpigment> recent drivers? [22:48:06 CET] <SortaCore> updated last week [22:48:15 CET] <alexpigment> do you have mediainfo, by chance? [22:48:19 CET] <SortaCore> I have intel and nvidia cards, one screen plugged into both [22:48:26 CET] <SortaCore> yea, I just updated it a couple minutes ago [22:48:30 CET] <alexpigment> if so, you can verify whether x264 info is being written into the file [22:48:31 CET] <SortaCore> using it to look at color range [22:48:42 CET] <SortaCore> nani [22:48:48 CET] <kepstin> alexpigment: one thing to note is that a lot of old mpeg file formats are usually mistagged as to aspect ratio [22:49:00 CET] <kepstin> alexpigment: and ffmpeg doesn't read the aspect ratio of dvd vobs correctly [22:49:09 CET] <alexpigment> kepstin: maybe so. i record in 480i daily [22:49:14 CET] <alexpigment> it's always 8:9 [22:49:21 CET] <alexpigment> not sure why it's always been wrong [22:49:26 CET] <alexpigment> looks right [22:49:33 CET] <alexpigment> circles are circles, etc [22:49:33 CET] <kepstin> hmm, well, then all your video is just very slightly too narrow :/ [22:49:58 CET] <kepstin> it's only a <1% difference, so it's hard to tell [22:50:00 CET] <kepstin> iirc [22:50:17 CET] <kepstin> er wait, no, it's about 3% [22:50:29 CET] <SortaCore> alexpigment: x264? [22:50:46 CET] <GyrosGeier> bframes=3 b_pyramid=2 -- that's a fairly low profile [22:51:00 CET] <SortaCore> I'm getting a h264 rtsp stream, I'm transcoding it with a hwaccel'd encoder, hopefully [22:51:01 CET] <alexpigment> SortaCore: i was just asking in case it was punting and using x264 instead [22:51:15 CET] <SortaCore> Stream #0:0: Video: h264 (h264_nvenc) (Main) (avc1 / 0x31637661), nv12, 704x480, q=-1--1, 2000 kb/s, 6.25 fps, 12800 tbn, 6.25 tbc [22:51:16 CET] <GyrosGeier> should I tune that, given that all modern players will have space for quite a few reference frames? [22:51:37 CET] <SortaCore> I either get NV12 or YUV420P, but in either case no GPU usage [22:51:38 CET] <GyrosGeier> hmm wait [22:51:56 CET] <GyrosGeier> lots of "Past duration 0.999992 too large" [22:52:02 CET] <kepstin> alexpigment: if you want to know *why* it's 10/11 and why a lot of stuff gets it wrong, go and read https://lurkertech.com/lg/video-systems/#pixelaspect :) [22:52:17 CET] <GyrosGeier> is that bad? [22:52:23 CET] <kepstin> GyrosGeier: can you please share your full command line and a bigger chunk of output? [22:52:41 CET] <kepstin> GyrosGeier: that message can indicate that you're getting dropped frames, which might be noticable. [22:52:43 CET] <alexpigment> kepstin: again, i think it's because you're assuming that my content is 704x480; it's not [22:52:55 CET] <GyrosGeier> $ ffmpeg -i stream.dump -c:v libx264 -crf 24 -flags +ildct+ilme ~/Sir_No_Sir.mkv [22:52:55 CET] <kepstin> alexpigment: i'm assuming your content is 4:3 ntsc [22:53:15 CET] <kepstin> alexpigment: which, if it's sampled at the standard rate for 720x480 or 704x480, has a sar of 10/11 [22:53:26 CET] <kepstin> doesn't matter which res it is, the sar is the same [22:53:41 CET] <kepstin> 704 just has less of the width of the signal than 720 does [22:53:51 CET] <GyrosGeier> the errors start at 5 minutes into the stream [22:54:24 CET] <alexpigment> GyrosGeier: is it possible that the frame rate changes at some point in the stream? [22:54:28 CET] <kepstin> GyrosGeier: that error indicates that ffmpeg guessed that the framerate was constant, but partway through the stream it started getting frames at a faster rate. [22:55:06 CET] <GyrosGeier> alexpigment, is that legal for DVDs? [22:55:21 CET] <SortaCore> *FBI kicks down door* [22:55:24 CET] <alexpigment> sadly, it's legal for a lot of video ;) [22:55:31 CET] <GyrosGeier> looking at the output file, A-V sync seems good at 10 minutes in [22:55:31 CET] <alexpigment> SortaCore: lol [22:55:34 CET] <SortaCore> *FBI droops head and walks out slowly* [22:55:41 CET] <kepstin> GyrosGeier: ffmpeg's dvd handling is weird, particularly for content that was encoded in mixed pseudo-progressive and interlaced/telecined [22:56:04 CET] <kepstin> GyrosGeier: don't worry, it'll maintain sync fine. but the video mgiht be juddery. [22:56:30 CET] <GyrosGeier> kepstin, I'm feeding it a PS stream, read using mplayer -dumpstream [22:56:49 CET] <kepstin> GyrosGeier: just a moment, i'm looking up the filter to fix it [22:57:46 CET] <kepstin> GyrosGeier: add "-vf repeatfields" - that filter will turn the video into a constant 30/1.001fps interlaced stream instead of the mixed 24 & 30 that ffmpeg sometimes does. [22:59:29 CET] <alexpigment> kepstin: fyi, i'm looking through tons of sources over here. if you can find a non-widescreen NTSC video that *ffmpeg* reports at something other than 8:9, i'll be very surprised [22:59:33 CET] <GyrosGeier> so I can't have an output file that switches framerate together with the input? [22:59:49 CET] <JEEB> why not? [23:00:03 CET] <JEEB> FFmpeg's framework is 100% timestamp based and mp4/matroska etc are timestamp based [23:00:08 CET] <kepstin> alexpigment: stuff in mpeg containers (mpeg-ps particularly) will usually be wrong. Most DV content should be correct. [23:00:15 CET] <alexpigment> kepstin: i understand what you're saying intellectually. i'm not saying *you're* wrong, but between you and ffmpeg, one of you is [23:00:33 CET] <alexpigment> well in that case, i never use DV [23:00:41 CET] <alexpigment> always MPEG-2 and H.264 sources [23:01:21 CET] <kepstin> alexpigment: what container? [23:01:22 CET] <alexpigment> and always in ps or ts, for that matter [23:01:27 CET] <kepstin> (this depends mostly on the container) [23:01:31 CET] <GyrosGeier> hmm [23:01:38 CET] <kepstin> i'd expect h264 in mpeg-ts to generally be correct. [23:01:40 CET] <GyrosGeier> -vf repeatfields doesn't help [23:02:05 CET] <alexpigment> kepstin: i mean if you think it's a big enough deal to investigate ffmpeg, i'd be happy to send samples [23:02:06 CET] <GyrosGeier> also, the output codec complains [23:02:07 CET] <GyrosGeier> [libx264 @ 0x557f3d763f00] interlace + weightp is not implemented [23:02:15 CET] <alexpigment> GyrosGeier: that's ignorable [23:02:28 CET] <alexpigment> it always says that for H.264 interlaced encoding [23:02:32 CET] <JEEB> alexpigment: if you have samples where metadata is read incorrectly that's worth it [23:02:40 CET] <GyrosGeier> Past duration 0.999992 too large 46272kB time=00:05:47.77 bitrate=1089.9kbits/s speed=4.25x [23:02:43 CET] <GyrosGeier> Last message repeated 84 times [23:02:46 CET] <kepstin> alexpigment: ffmpeg is just telling you what the files say, and mpeg container poorly specified the aspect ratio field. so a lot of writing software gets it wrong. [23:02:46 CET] <GyrosGeier> the repeat counts got smaller [23:02:49 CET] <alexpigment> JEEB: well, until a few minutes ago, i didn't have any reason to think that the metadata was incorrect [23:02:51 CET] <JEEB> I think the only case where I've had aspect ratio read wrong were some funky MXF files [23:02:54 CET] <GyrosGeier> before it was ~260 [23:03:11 CET] <JEEB> MPEG-PS/TS I've had noted right so far [23:03:21 CET] <kepstin> I have a few blu-rays with SD content (h264 in mpeg-ts), I should check those. [23:03:33 CET] <alexpigment> JEEB: when you encode to another format (e.g. h.264), ffmpeg is saying it's 10:11 for NTSC? [23:03:48 CET] <kepstin> but yes, I've almost always seen mpeg-ps (vob files from dvds) with incorrect values. [23:03:50 CET] <JEEB> alexpigment: oh is this the "analogue" aspect ratios thing? [23:04:20 CET] <JEEB> like 16:11 for PAL 16:9 [23:04:23 CET] <JEEB> (SAR) [23:04:25 CET] <kepstin> JEEB: yep, alexpigment has some files which are 720x480 but marked with a display aspect of 4:3. [23:04:46 CET] <JEEB> uhh [23:04:55 CET] <JEEB> there's SD NTSC content just fine? [23:05:04 CET] <JEEB> that is 4:3 (DAR?) [23:05:26 CET] <kepstin> ntsc sd 4:3 content has a sar of 10/11, so 720x480 is very slightly wider than 4:3 [23:05:28 CET] <JEEB> as I think you're not talking about 40:33 SAR being incorrectly reported as 4:3? [23:05:53 CET] <kepstin> but this file is mistagged as 8/9 sar = 4/3 dar [23:05:53 CET] <GyrosGeier> there are probably some in-game cutscene movies in 720x480 4:3 [23:06:02 CET] <JEEB> right [23:06:23 CET] <JEEB> the problem with DVDs is that they don't have exact aspect ratios, same for normal MPEG-PS/TS I think [23:06:32 CET] <JEEB> the aspect ratio flag just says "16:9" or "4:3" IIRC [23:06:39 CET] <JEEB> only with H.264 you got the parameter sets' proper values [23:06:47 CET] <JEEB> where people started flagging the correct values [23:07:04 CET] <alexpigment> sorry, back. anyway, i just now remember something i ran into a while back where if i didn't specify an output aspect ratio of 4:3, the result would be slightly off. maybe this whole 8:9 thing is an ffmpeg bug and i was just working around it [23:07:20 CET] <GyrosGeier> kepstin, can this still be improved if -vf repeatfields doesn't solve the "Past duration" problem? [23:07:24 CET] <alexpigment> (testing) [23:07:39 CET] <JEEB> if it's the "analogue" aspect ratios for SD then that's kind of a problematic thing [23:07:52 CET] <kepstin> GyrosGeier: you can explicitly tell ffmpeg to do vrf output with the option "-vsync 0" - might help [23:08:10 CET] <JEEB> I thought VFR was by default :P [23:08:18 CET] <JEEB> only with containers that can't do VFR does it duplicate/cut [23:08:19 CET] <alexpigment> JEEB: all of these are digital sources. not sure if that is what you're talking about [23:08:44 CET] <kepstin> alexpigment: modern digital video equipment still follows the old analogue standards. [23:08:50 CET] <kepstin> as close as possible [23:09:15 CET] <alexpigment> well, lemme know what happens with that m2ts file you were talking about earlier [23:09:20 CET] <JEEB> alexpigment: things that are (on paper) mostly utilized for things that came from old digitizations (such as DVD and SD BD for example) utilize somewhat different aspect ratios [23:09:21 CET] <alexpigment> i'm happy to provide samples as necessary [23:09:42 CET] <JEEB> I can't link you the BD spec that says them explicitly but you'll have to trust me that these values noted here are correct [23:09:46 CET] <JEEB> http://www.x264bluray.com/home/480p-ntsc [23:09:48 CET] <JEEB> http://www.x264bluray.com/home/576p-pal [23:09:57 CET] <alexpigment> JEEB: no worries. i'm just saying that ffmpeg is saying 8:9 [23:10:04 CET] <alexpigment> i don't distrust anyone [23:10:18 CET] <kepstin> alexpigment: you should distrust your files and just manually set the sar to fix it :) [23:10:18 CET] <JEEB> 8:9 what? [23:10:23 CET] <alexpigment> it's just that i cannot find a single 720x480 NTSC 4:3 video that ffmpeg doesn't report as 8:9 SAR [23:11:06 CET] <alexpigment> so if it's suppose to be 10:11, either ffmpeg is wrong, or the entire industry is seemingly doing it wrong :) [23:11:10 CET] <JEEB> well that is exact 4:3 [23:11:17 CET] <JEEB> which is what the flag says with MPEG-2 [23:11:28 CET] <JEEB> the problem is that with a lot of stuff that actually means something different [23:11:43 CET] <kepstin> basically, some digital engineers decided to sample the analog signal at 13.5MHz for the 720-wide ntsc, and 12+3/11 for the 640-wide ntsc (square pixels). and so 720-wide stuff, if you multiply those fractions out, ends up being 10/11 sar compared to 640-wide stuff. [23:11:47 CET] <JEEB> it means the values I noted in those two x264bluray links (those are simplified) [23:12:19 CET] <alexpigment> JEEB: yes, i've been to this site many times [23:12:33 CET] <JEEB> of course then you get headaches from people comparing DVD playback on the PS3 or something, and telling you that their DVD seems to be encoded as proper 16:9 :| [23:13:02 CET] <JEEB> (as on a 16:9 screen the thing would get cropped otherwise) [23:13:07 CET] <kepstin> if you see 720 or 704 wide ntsc files intended for 4:3 with a sar other than 10/11, then the files are incorrectly tagged with display aspect. [23:13:38 CET] <JEEB> then again I have modern 16:9 DVDs where the "analog" aspect ratio gives seemingly round balls :P [23:13:45 CET] <alexpigment> well anyway, i can confirm the issue i referenced above. a while back i noticed that things weren't exactly right with the aspect ratio when converting to h.264. so i just put -aspect 4:3 and called it a day. that's still true today. that makes me think the 8:9 is actually being used by ffmpeg, not just reported wrong [23:14:09 CET] <kepstin> alexpigment: if you used -aspect 4:3 then you were the person who set the 8:9 dar and made the files wrong. [23:14:14 CET] <alexpigment> no [23:14:21 CET] Last message repeated 1 time(s). [23:14:21 CET] <alexpigment> that's after the fact [23:14:31 CET] <JEEB> 8:9 SAR is 4:3, the proper one :P [23:14:32 CET] <alexpigment> i had to put -aspect 4:3 in the output settings to correct the aspect ratio issue [23:14:39 CET] <JEEB> with 720x480 [23:14:47 CET] <JEEB> the analogue one is different [23:15:06 CET] <JEEB> now, if you master BDs at least there the SD BDs' aspect ratio is defined [23:15:18 CET] <alexpigment> i have some blu-ray sd material [23:15:24 CET] <alexpigment> confirming with that. 1 minute [23:15:37 CET] <JEEB> it should give the same SAR value as on x264bluray.com [23:15:42 CET] <JEEB> if it's H.264 [23:15:50 CET] <kepstin> hmm, I have my bd stuff on an online HD, I should check it too [23:15:57 CET] <JEEB> if it's MPEG-2 Video you only have non-exact aspect ratios [23:15:58 CET] <kepstin> I can never remember which m2ts on this disk was SD tho [23:16:12 CET] <JEEB> which is the problem, as the field just says "16:9" or "4:3" [23:16:15 CET] <alexpigment> it says 8:9 [23:16:21 CET] <JEEB> huh [23:16:25 CET] <JEEB> mpeg-2 video or H.264 [23:16:45 CET] <alexpigment> mpeg-2 in thise case [23:16:49 CET] <JEEB> ok, yes [23:16:51 CET] <alexpigment> i can find some h.264 sd blu-ray stuff though [23:16:53 CET] <alexpigment> lemme look around [23:17:04 CET] <JEEB> that will get assigned that because the field is called "4:3" [23:17:15 CET] <JEEB> it's context dependant :P [23:17:27 CET] <JEEB> which sucks, really [23:17:53 CET] <kepstin> but "4:3" on a 720 or 704 wide ntsc mpeg-2 file means you're supposed to infer that it's 10/11 sar. I wonder how much it would break if we added some heuristics to fix that in ffmpeg? [23:18:14 CET] <JEEB> yes, I have wondered that too [23:18:34 CET] <JEEB> at least most people will ?!?!?! since they don't know about the "analog" aspect ratios [23:18:36 CET] <alexpigment> ok, so 720x480 AVC encoded blu-ray stuff reports 10:11 [23:18:44 CET] <kepstin> blah, my blu-ray has the sd stuff in mpeg2 [23:18:44 CET] <JEEB> yes, because AVC has a proper aspect ratio field [23:19:00 CET] <alexpigment> kepstin: can you at least confirm the 8:9 thing? [23:19:10 CET] <JEEB> with mpeg-2 video there's no question [23:19:12 CET] <alexpigment> just so we can get off the "this is right" convo :) [23:19:13 CET] <JEEB> as I've noted X times already [23:19:20 CET] <kepstin> yes, ffmpeg is printing the incorrect aspect ratio from the mpeg2 video files. [23:19:28 CET] <alexpigment> JEEB: no worries. just trying to settle that part of the discussion so it doesn't come up again [23:19:33 CET] <JEEB> "incorrect" in the context [23:19:47 CET] <JEEB> the darn field is "4:3" which is how FFmpeg interprets it without context [23:19:50 CET] <JEEB> :D [23:20:19 CET] <kepstin> yes, given that I know this particular case is ntsc analogue video captured as 720x480, I know that it's incorrect. [23:20:27 CET] <alexpigment> well, i do have a recorder box (Hauppauge HD PVR 2), which doesn't seem to right to the field you refer to, so it gets treated as 8:9 as well [23:20:29 CET] <JEEB> or it comes from a media [23:20:39 CET] <alexpigment> brb [23:20:41 CET] <JEEB> which is specified as the analog aspect ratios [23:20:48 CET] <JEEB> so it's basically context-based information [23:20:49 CET] <kepstin> alexpigment: the hauppauge stuff generally writes mpeg2 in mpeg-ts, so it's the same problem again. [23:21:00 CET] <alexpigment> kepstin: no, it's H.264 [23:21:09 CET] <alexpigment> but yes, in mpeg-ts [23:21:19 CET] <JEEB> H.264 has the aspect ratio in parameter sets [23:21:25 CET] <JEEB> there's exactly zero reason to write it incorrectly [23:21:28 CET] <JEEB> since the value is exact [23:21:31 CET] <JEEB> unlike mpeg-2 video [23:21:35 CET] <kepstin> oh, the HD capture? it's just streaming the stuff off-air as it received over atsc (in NA) [23:21:44 CET] <alexpigment> no [23:21:47 CET] <alexpigment> it's recording from HDMI [23:21:56 CET] <alexpigment> HDMI in > H.264 hardware encoder > computer [23:21:59 CET] <kepstin> ok, so HDMI is another mess [23:22:17 CET] <kepstin> there's some HDMI specs that say 720x480 *is* actually 4:3 [23:22:23 CET] <JEEB> yes [23:22:28 CET] <GyrosGeier> [libx264 @ 0x557de7208f00] non-strictly-monotonic PTS [23:22:29 CET] <kepstin> but other devices assume it matches the old analogue specifications [23:22:48 CET] <kepstin> most dvd players will output 720x480 as if it was 10/11 [23:23:04 CET] <kepstin> but if your capture card used the other spec, it might record as 8/9 [23:23:06 CET] <alexpigment> kepstin: like i was saying earlier, you *can* write to the other 16 pixels for 4:3 720x480. just that most people don't (and shouldn't) [23:23:18 CET] <JEEB> that's not the point [23:23:25 CET] <JEEB> the point is that H.264 has an exact aspect ratio field [23:23:33 CET] <JEEB> so if something wrote 4:3 that is supposed to be 4:3 [23:23:34 CET] <JEEB> pronto [23:23:53 CET] <JEEB> with mpeg-2 video the field is context sensitive, unfortunately [23:24:07 CET] <kepstin> 704 and 720 are captured from analogue at the same luma sampling rate, and therefore should have the same sar, for equipment that is compatible with the analogue specs. [23:24:10 CET] <JEEB> because they didn't have a freeform field [23:24:26 CET] <JEEB> or maybe they did, but people went stupid [23:24:40 CET] <JEEB> in any case, MPEG-2 Video -> context sensitive , AVC -> not context sensitive [23:24:47 CET] <kepstin> I think with mpeg2 you can write correct values if you fiddle with the fields in strange ways. [23:25:01 CET] <kepstin> but the default presets just list 4:3 and 16:9 basically [23:25:07 CET] <JEEB> yup [23:26:10 CET] <JEEB> alexpigment: but yea - the end result is that FFmpeg is reading the aspect ratio field correctly, *but* lacks the possible context dependent logic as it expects values to be exactly what it says on the tin [23:26:43 CET] <alexpigment> JEEB: well, in the absence of context, maybe it should default to assuming 10:11? [23:27:12 CET] <alexpigment> again, i went through tons of files from different sources, only the blu-ray sourced h.264 video said 10:11 [23:27:43 CET] <JEEB> that just means that someone actually flagged them as 4:3 DAR [23:27:54 CET] <JEEB> and if the content is not such then the flag is INCORRECT [23:28:16 CET] <JEEB> and yes, the BD spec requires you to use the exact value (for a reason) [23:28:19 CET] <alexpigment> it feels like you're doing a 180, but i think instead there's a communication issue here [23:28:27 CET] <JEEB> no I don't [23:28:40 CET] <JEEB> the one where there's context based decision making included is MPEG-2 VIDEO [23:28:43 CET] <JEEB> MPEG-2 [23:28:45 CET] <JEEB> CAPISCI? [23:28:48 CET] <alexpigment> right [23:28:50 CET] <JEEB> H.264 is not affected [23:29:00 CET] <JEEB> it has EXACT VALUES and YOU ARE SUPPOSED TO TAKE THEM AT FACE VALUE [23:29:00 CET] <alexpigment> i've got lots of H.264 that *is* [23:29:03 CET] <alexpigment> ok [23:29:08 CET] <alexpigment> i'll drop it [23:29:11 CET] <JEEB> so if something wrote 4:3 DAR [23:29:16 CET] <JEEB> it is 4:3 DAR [23:29:21 CET] <JEEB> unlike mpeg-2 video [23:29:22 CET] <alexpigment> this was a tangent anyway while we were talking to gyros [23:29:35 CET] <JEEB> I hope the point came through, though? [23:29:40 CET] <alexpigment> no, it didn't [23:29:42 CET] <JEEB> with mpeg-2 video there might be leeway for FFmpeg to fix it [23:29:50 CET] <alexpigment> it seems like you could default to 10:11 for mpeg2 [23:29:52 CET] <JEEB> If and only if there's some context available [23:29:56 CET] <alexpigment> but somehow that doesn't work, and i don't understand. [23:30:00 CET] <alexpigment> and at this point, i don't care [23:30:23 CET] <JEEB> no, I didn't say it doesn't work - I am just not capable of saying if it would work with everything with such a casee [23:30:44 CET] <JEEB> the only thing I tried to then really note is that with H.264 this context-dependant thing doesn't exist [23:30:45 CET] <alexpigment> cool. i'm done with the convo [23:31:01 CET] <JEEB> since all related specifications tell you to utilize the exact values, which are available [23:31:04 CET] <JEEB> ok [23:31:07 CET] <JEEB> it seems like I'm really bad at explaining [23:31:08 CET] <JEEB> sorry [23:31:12 CET] <JEEB> (Ž4@) [23:31:50 CET] <JEEB> mpeg-2 video -> there could be changes made but it's so context dependant that I am not sure if it should be the API client or the FFmpeg itself to do the decision [23:31:57 CET] <alexpigment> it's ok. it just came up because kepstin thought it was weird that a video was being reported as 8:9. and i see that number every day, so *not weird to me!*. i don't really care about it, since it doesn't affect me in any meaningful way [23:32:01 CET] <JEEB> h.264 -> no context dependant stuff [23:32:10 CET] <kepstin> conclusion: when mpeg2 was made, computer video was a mess, and the aspect ratio stuff poorly specified. WHen h264 was made, the aspect ratio field actually works correctly. There's a lot of legacy or converted (without correction) content around [23:32:54 CET] <kepstin> and either way, the difference is only about 3%, and if your 720 frames have content right to the edge (no black bars), people probably won't notice [23:33:38 CET] <JEEB> yup [23:36:50 CET] <GyrosGeier> hmm, encoding output looks good [23:37:01 CET] <GyrosGeier> thanks kepstin and alexpigment [23:37:23 CET] <GyrosGeier> one last thing: the PS has closed captions, can I convert these to mkv subtitles? [23:37:57 CET] <JEEB> if it's the US captions you will have fun with that [23:38:18 CET] <JEEB> (mostly because the darn things are in the video track) [23:38:41 CET] <GyrosGeier> the shiny blinky bits at the top? [23:38:42 CET] <JEEB> you will receive a side data packet [23:39:02 CET] <JEEB> they used to be in the video frame but now they're just as additional packets in the video track [23:39:12 CET] <alexpigment> GyrosGeier: hmmm, i've never thought about if there's a way to convert those [23:39:24 CET] <GyrosGeier> stackoverflow says [out+subcc] [23:39:26 CET] <alexpigment> i just always crop and pad as necessary [23:39:33 CET] <JEEB> GyrosGeier: that's the ffmpeg.c way [23:39:40 CET] <JEEB> I thought you were using the API [23:39:48 CET] <JEEB> so I started explaining how to generate the new track [23:39:49 CET] <JEEB> :) [23:40:09 CET] <GyrosGeier> JEEB, I'm on the command line [23:40:18 CET] <JEEB> yea then there's probably some way to get them [23:40:24 CET] <GyrosGeier> just ripping all my DVDs and the older BluRays [23:40:31 CET] <JEEB> I've only seen them extracted through the API with mpv [23:40:52 CET] <alexpigment> that could be a fun project for someone... ;) [23:40:54 CET] <JEEB> (find side data, create a new track on your side, open a new decoder and feed it the side data packets) [23:42:07 CET] <GyrosGeier> with [out+subcc], I don't get an audio stream [23:42:23 CET] <JEEB> did you select your audio stream? [23:42:30 CET] <JEEB> if you do a -map all automatic stream selection goes away [23:42:44 CET] <GyrosGeier> no -map [23:42:56 CET] <JEEB> uhh, can you post what you tried then on pastebin or so? :P [23:43:10 CET] <GyrosGeier> ffmpeg -f lavfi -i 'movie=stream.dump[out+subcc]' -vsync 0 -c:v libx264 -crf 24 -flags +ildct+ilme ~/Sir_No_Sir.mkv [23:43:18 CET] <JEEB> right [23:43:20 CET] <JEEB> lavfi input [23:43:37 CET] <GyrosGeier> I get a video and a subtitle (ass) stream [23:44:09 CET] <JEEB> you will probably want to add another input with your original input [23:44:18 CET] <JEEB> and then map things from the first and second as needed [23:44:33 CET] <JEEB> (probably video and audio from the original input, and then subtitles only from the lavfi inpu [23:44:52 CET] <GyrosGeier> ah [23:46:14 CET] <GyrosGeier> ffmpeg -i stream.dump -f lavfi -i 'movie=stream.dump[out+subcc]' -vsync 0 -c:v libx264 -crf 24 -flags +ildct+ilme ~/Sir_No_Sir.mkv [23:46:17 CET] <GyrosGeier> that looks good [23:46:51 CET] <GyrosGeier> okay, finishing touch: add language tags to audio and subtitles [23:47:20 CET] <alexpigment> -metadata:s:a:0 language=eng [23:47:28 CET] <alexpigment> or whatever the language is [23:47:47 CET] <alexpigment> then i think you can also do -metadata:s:s:0 language=eng (correct me if i'm wrong on that) [23:48:02 CET] <JEEB> I think that should be correct [23:48:09 CET] <JEEB> metadata mapped on stream, subtitle, 0th [23:48:35 CET] <alexpigment> https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes <-- here are the language codes [23:49:44 CET] <GyrosGeier> yup [23:50:34 CET] <GyrosGeier> hmm [23:51:20 CET] <GyrosGeier> the "[libx264 @ 0x55c64bdd1560] non-strictly-monotonic PTS" appears right where it started complaining about the "Past duration" [23:51:31 CET] <GyrosGeier> so I guess that is gone now too [23:51:32 CET] <alexpigment> oh that ol' gem [23:51:48 CET] <alexpigment> i can't recall exactly what that is, but i've been seeing it from time to time lately [23:51:59 CET] <alexpigment> the others here probably know what it is and why [23:52:09 CET] <JEEB> it's that your PTS aren't going forward well enough :P [23:52:13 CET] Action: kepstin has explained it before [23:52:31 CET] <alexpigment> yeah, i'm getting deja vu, so you probably explained it yesterday [23:52:52 CET] <kepstin> it means that ffmpeg thinks that at some point in the stream the video should be cfr, but the frame timestamps are too close together for the cfr rate [23:53:01 CET] <kepstin> iirc, this is done at the end of the filter chain [23:53:33 CET] <alexpigment> is it ingorable? [23:53:42 CET] <JEEB> umm, it doesn't have too much to do with CFR [23:53:48 CET] <kepstin> not always. it indicates that frames are being dropped [23:53:56 CET] <JEEB> umm [23:53:58 CET] <JEEB> that got to libx264 [23:54:15 CET] <JEEB> so it clearly went through ffmpeg.c [23:54:17 CET] <kepstin> oh, i'm talking about the Past duration error [23:54:21 CET] <JEEB> right [23:54:28 CET] <alexpigment> haha [23:54:29 CET] <JEEB> I was talking about the non-strictly monotonic PTS [23:54:33 CET] <alexpigment> yes, new topic ;) [23:54:56 CET] <JEEB> the past duration message usually has some specifics there but can get overwritten on the terminal by some new messages :P [23:55:10 CET] <kepstin> hmm, that reminds me, I should fix the concat filter so it doesn't give past duration errors when the second file is higher framerate than the first [23:55:26 CET] <GyrosGeier> I suspect that the timestamps in the PS are just discontinuous because someone spliced together two PS streams without adjusting the timestamps, and if you try to fix it, you introduce more errors [23:55:32 CET] <alexpigment> kepstin: does that apply to VFR video? [23:55:46 CET] <kepstin> concat filter copies the framerate from the first file, indicating cfr if the first file is cfr, so if the second file is different then you get that message [23:56:15 CET] <alexpigment> i'm just wondering if you'd run into that when concat'ing two VFR files, and just incidentally one is higher than the other [23:56:34 CET] <alexpigment> i don't think i've ever tried to concat two files with obviously different frame rates, but i've seen the message in question [23:56:35 CET] <JEEB> also man, ffmpeg.c's "vsync" code [23:56:41 CET] <JEEB> I do not want to look at that stuff again [23:56:48 CET] <kepstin> alexpigment: if the first file is correctly detected as vfr, and therefore has the value '0/1' in the framerate field, then concat will output vfr and it'll work. [23:56:52 CET] <JEEB> so many if/elses [23:57:08 CET] <alexpigment> i see [23:57:23 CET] <kepstin> because concat simply copies the framerate from the first file to the output [23:57:37 CET] <JEEB> it's always the best feeling when lavf/lavc give you correct timestamps [23:57:47 CET] <JEEB> and then ffmpeg.c proceeds to murder it with vengeance [23:57:49 CET] <GyrosGeier> aren't there "absolute" timestamps in PS normally? [23:57:52 CET] <kepstin> I have a half-done patch to fix it by checking that all the files are the same framerate, and then either using that in the output or setting it to vfr if any are different. [23:58:57 CET] <JEEB> anyways, I should post a patch to make at least mpeg-ts demuxer to be able to handle wrap-arounds by itself [23:58:59 CET] <GyrosGeier> at least I remember that when I decode DVB, I get the current time minus 6 hours shown as current position (presumably because the station restarts the encoder at 6 AM) [23:59:06 CET] <JEEB> having the clients always handle it is :| [23:59:23 CET] <JEEB> GyrosGeier: doesn't necessarily mean encoder start but just the last wrap-around ) [23:59:26 CET] <JEEB> :) [23:59:38 CET] <JEEB> 33bit integer and the time base is 90000 [23:59:38 CET] <GyrosGeier> hmm [23:59:50 CET] <JEEB> (yes, 33bit - I didn't write that wrong) [00:00:00 CET] --- Wed Jan 24 2018

1 0

ffmpeg-devel.log.20180122
by burek 23 Jan '18

23 Jan '18

[00:04:49 CET] <BBB> kierank: in my limited experience with the broken concept of vp8 alt-ref frames, Ive found that ffplay does sometimes behave weirdly if timestamps of the files are not 100% proper, maybe related to that? ffmpeg ignores that, mostly [00:06:05 CET] <nevcairiel> how would it messing up with timestamps cause the decoder to suddenly misbehave [00:06:44 CET] <cone-320> ffmpeg 03Jun Zhao 07master:dfdeed5a2c8f: lavfi: VAAPI VPP common infrastructure. [00:06:45 CET] <cone-320> ffmpeg 03Jun Zhao 07master:19214f005140: lavfi: use common VAAPI VPP infrastructure for vf_scale_vaapi. [00:06:46 CET] <cone-320> ffmpeg 03Jun Zhao 07master:92704c480e81: lavfi: use common VAAPI VPP infrastructure for vf_deinterlace_vaapi. [00:06:46 CET] <kierank> yeah, I haven't touched any timestamp code [00:06:47 CET] <cone-320> ffmpeg 03Jun Zhao 07master:fcf5eae4bf24: lavfi: add ProcAmp (color balance) VAAPI video filter. [00:06:48 CET] <cone-320> ffmpeg 03Jun Zhao 07master:9bba10c174c8: lavfi: add denoise and sharpness VAAPI video filters. [00:06:49 CET] <cone-320> ffmpeg 03Mark Thompson 07master:bda5ad305e90: v4l2_m2m: Fix free of the wrong pointer in an error path [00:06:52 CET] <kierank> nor can I reproduce what carl sees locally [00:08:03 CET] <wm4> I'd definitely say that it's the responsibility of the reporter to dig deeper if the dev can't reproduce any issue and has made an effort trying to reproduce it [00:18:21 CET] <atomnuker> jkqxz: had a chance to test hwcontext_vulkan? [00:33:05 CET] <jkqxz> BtbN: ldts [00:33:58 CET] <jkqxz> Though I assume you mean that pointer-free thing I just fixed (I did introduce it, after all). [00:34:06 CET] <jkqxz> atomnuker: Just looking at it now. [00:34:43 CET] <jkqxz> VK_ERROR_NOT_PERMITTED_EXT doesn't exist in my headers. [00:35:09 CET] <jkqxz> So I guess either that needs some ifdefs or configure needs to check for some version? [00:36:43 CET] <jkqxz> The rgb24 upload/download sequence works. [00:38:11 CET] <jkqxz> (On radv.) [00:39:09 CET] <atomnuker> awesome, can you print dedicated_alloc_req.prefersDedicatedAllocation + dedicated_alloc_req.requiresDedicatedAllocation after pfn_vkGetImageMemoryRequirements2KHR [00:39:34 CET] <atomnuker> curious to see if it works, your vulkaninfo did say radv supports that extension [00:40:24 CET] <jkqxz> [AVHWFramesContext @ 0x55bde7e3fb40] dedicated_alloc_req.prefersDedicatedAllocation = 0 [00:40:27 CET] <jkqxz> [AVHWFramesContext @ 0x55bde7e3fb40] dedicated_alloc_req.requiresDedicatedAllocation = 0 [00:43:30 CET] <wm4> I thought vulkan doesn't support rgb24 for most things [02:58:18 CET] <cone-320> ffmpeg 03James Almer 07master:388a0f7869a8: avcodec/mpeg12dec: fix preprocessor check for mpeg1_nvdec hwaccel [05:03:20 CET] <Compn> reviewing ml mod queue [05:03:26 CET] <Compn> since llogan is afk for a week or two [05:03:27 CET] <Compn> Subject: A New Form Of Cat To Human Communication [05:03:35 CET] <Compn> spam subject lines are getting interesting ! [05:03:45 CET] <Compn> i do wish to know about this new form of cat to human communication. [05:11:11 CET] <Compn> mod queue cleared [05:20:25 CET] <atomnuker> reminds me of https://0x0.st/sq_V.webm [05:51:28 CET] <Compn> bug seems familiar .... [05:53:25 CET] <atomnuker> peloverde: https://trac.ffmpeg.org/ticket/6974 [09:00:36 CET] <nevcairiel> sounds like an encoding thing to me, is the in-band pce not repeated or something like that? [09:03:06 CET] <nevcairiel> or more importantly, does it support writing in-band pce for adts usage at all? [09:06:32 CET] <nevcairiel> .. apparently the adts muxer writes the in-band pce data, but it only does it once, that should probably be repeated instead [09:07:10 CET] <Taemojitsu_> Can someone test something for me? I think ffplay and ffmpeg now limit fps to screen refresh rate, but would like to confirm it isn't some window manager setting [09:07:38 CET] <nevcairiel> ffplay may do that, but ffmpeg most certainly doesnt, it has no display [09:08:30 CET] <Taemojitsu_> I see it with 'ffmpeg -filter_complex color=black:r=120 -f opengl -', it's limited to my screen refresh rate of ~60 [09:09:18 CET] <Taemojitsu_> I don't know if it's always worked like this, but I'm sure that in the past ffplay would speed up videos faster than refresh rate if it fell behind with -noframedrop [09:11:14 CET] <Taemojitsu_> I request that someone test ffplay, such as with 'ffmpeg -filter_complex color=black:r=120 -t 10 black.mp4' then 'ffplay -noframedrop black.mp4', and see if it's limited to refresh rate due the video falling behind (M-V increasing) [09:11:51 CET] <nevcairiel> You should probably go to #ffmpeg, this channel is for development of ffmpeg, not support [09:12:32 CET] <Taemojitsu_> I'm trying to get confirmation of a bug before I file a bug report, which is unfortunately all I can do since I don't know any programming languages [09:13:01 CET] <Taemojitsu_> I did try #ffmpeg, no responses. [09:13:09 CET] <nevcairiel> then wait [09:13:17 CET] <nevcairiel> this channel is not appropriate for such requests [13:16:43 CET] <CoreX> is there anyway to get this sorted because we really dont want to update to ffmpeg 3.* as we have stuff on ffmpeg 2.* that we need https://pastebin.com/raw/E0wCaj6J [13:17:10 CET] <CoreX> better yet what can be done to use newer x264 with ffmpeg [13:17:16 CET] <CoreX> ffmpeg 2.* [13:21:29 CET] <JEEB> this channel is for the development of FFmpeg, not development with FFmpeg - so your questions would be correct on #ffmpeg [13:22:53 CET] <nevcairiel> old ffmpeg, old libraries [13:22:58 CET] <nevcairiel> you should update everything together [13:23:38 CET] <nevcairiel> or stick to versions you know that work [13:26:14 CET] <nevcairiel> presumably 2.8 is still maintained however, so maybe such a patch will make it to its next release [13:26:34 CET] <nevcairiel> nevertheless, expecting an old branch to work with much newer libraries is always going to get you into trouble [13:37:19 CET] <CoreX> trying ffmpeg.2.8.13 now if not working then i will just stick with old versions for abit [15:49:24 CET] <durandal_1707> help: missing ideas what to do next [15:54:14 CET] <BBB> write a native av1 decoder [15:54:21 CET] <BBB> write an av1 encoder [15:56:00 CET] <durandal_1707> something thats not that [15:57:16 CET] <jkqxz> Add AV1 support to AVI muxer/demuxer, because the name. [15:57:33 CET] <wm4> reserve that for apil 1st [15:57:37 CET] <wm4> april even [15:58:01 CET] <nevcairiel> i'm sure someone will do that anyway [15:58:09 CET] <wm4> av1 in flv! [15:58:11 CET] <nevcairiel> does av1 have b frames? [15:58:19 CET] <nevcairiel> if not, its proably trivial to put it into avi anyway [15:58:35 CET] <wm4> that sounds like a question nobody involved is allowed to answer [15:58:47 CET] <nevcairiel> or more accurately, does it have re-ordering? [15:59:08 CET] <nevcairiel> vp9 could probably go into avi without too many problems [15:59:25 CET] <nevcairiel> not that i have ever seen that [16:02:12 CET] <Gramner> add a powerpoint muxer! [16:03:46 CET] <atomnuker> durandal_1707: ilbc decoder [16:05:12 CET] <kierank> nevcairiel: no [16:05:15 CET] <kierank> wm4: the spec is on github [16:05:20 CET] <kierank> https://github.com/AOMediaCodec/av1-spec [16:05:38 CET] <wm4> oh so it was done with a spec from the start, neat [16:05:40 CET] <JEEB> wm4: funny enough someone mentioned they'd want to hack AV1 in FLV for RTMP [16:05:53 CET] <JEEB> "so that people don't have to change their infra" :< [16:06:23 CET] <JEEB> although at least they noted that they might want to get the identifier also agreed by adobe [16:06:29 CET] <JEEB> so it's at the very least official [16:07:23 CET] <nevcairiel> JEEB: good luck with that, adobe didnt even add hevc [16:07:33 CET] <JEEB> yea [16:07:41 CET] <JEEB> I know that won't happen because it didn't happen with HEVC [16:08:10 CET] <JEEB> but at least it was better than with those certain people and not even trying to have it ratified by adobe [16:08:29 CET] <atomnuker> wm4: lol no, the spec will be complete and valid quite some time after the bitstream freeze and then after the hard bitstream freeze [16:08:39 CET] <wm4> aw [16:09:40 CET] Action: wm4 stares at huge constant tables in C [16:09:51 CET] <wm4> better than formatting it informally I guess [16:14:58 CET] <atomnuker> don't look at av1/common/quant_common.c if you're afraid of big tables [16:15:15 CET] <atomnuker> ~15000 lines of dense, packed to 80cols tables [16:15:52 CET] <bencoh> could as well ship that as a blob ... [16:16:09 CET] <atomnuker> not sure how much of that is needed or can be generated at the start/runtime [16:17:11 CET] <ldts> jkqxz: thanks!. btw what is CID? (RE: fixes CID #142.7821 and #142.7822) I couldnt find any reference in bug tracker. [16:17:22 CET] <atomnuker> I wonder whether the adaptable zigzag code switched to using static tables or if they're still done on runtime [16:17:57 CET] <atomnuker> ironically the latter is quite expensive to do in hardware yet it was accepted iirc [16:18:09 CET] <jkqxz> ldts: Coverity ids. [16:18:48 CET] <ldts> ah ..ok googling the documentation now (didnt know we run Coverity) [16:18:49 CET] <jkqxz> You should probably get access to that. Not sure who is an admin that can add you, though? [16:19:04 CET] <jkqxz> Someone here... [16:20:47 CET] <ldts> ah I can see coverage.ffmpeg.org. ok will find out about getting access. [16:21:19 CET] <wm4> atomnuker: how much KB stripped binary code is that? [16:21:47 CET] <wm4> jkqxz: probably michaelni [16:33:13 CET] <atomnuker> wm4: 428k unstripped, 424k stripped [16:33:37 CET] <wm4> for the tables, or including other stuff? [16:34:54 CET] <atomnuker> the entire file which only has the tables [16:35:04 CET] <atomnuker> but that's not the biggest object file, not by far [16:35:35 CET] <atomnuker> 3.9M ./CMakeFiles/aom_dsp_encoder.dir/aom_dsp/variance.c.o [16:35:56 CET] <atomnuker> 3.7M stripped [16:37:00 CET] <ldts> wm4: jkqxz: going to push (my first) your fix to v4l2_get_pts on 32 bit ABI [16:37:12 CET] <atomnuker> though its only 1500 lines it has several functions for each block size, including rectangular [16:37:59 CET] <wm4> ldts: fine with me [16:38:18 CET] <wm4> ldts: btw. is there any reason why the kernel API uses timeval for PTS and not just a 64 bit value? [16:38:56 CET] <ldts> I dont know, seems to be historical [16:40:12 CET] <ldts> I'll come back to you if I find out its origin [16:40:37 CET] <durandal_1707> atomnuker: i already did ilbc, but cant finish it, too much effort [16:41:33 CET] <atomnuker> what's left to finish it? I think daddesio might be interested, he's into voice codecs [16:42:16 CET] <wm4> ldts: I'd guess it's something about the API returning wallclock timestamps for media capture uses... [16:42:31 CET] <jamrial> kierank: so the av1 bitstream is frozen then? [16:42:39 CET] <daddesio> hiya [16:42:55 CET] <durandal_1707> i told here numerous times i wrote it and nobody gives a crap [16:44:11 CET] <atomnuker> first time I'm hearing there's been an attempt at a native ilbc decoder [16:55:14 CET] <daddesio> durandal_1707: what's left to finish it? :P [16:58:50 CET] <durandal_1707> daddesio: rewrite several percent of lines [17:20:54 CET] <ldts> wm4: jkqxz: so I am supposed to have write/push access to git://source.ffmpeg.org/ffmpeg? - no specific port/credentials needed? [17:21:50 CET] <wm4> ldts: did you give your ssh key to anyone? if not, then unlikely [17:22:11 CET] <ldts> yes, to michaelni [17:22:35 CET] <wm4> then you probably can push [17:22:54 CET] <ldts> just dry-run returns access denied (so was wondering if that is the right repo) [17:24:29 CET] <wm4> I use git@source.ffmpeg.org:ffmpeg as push URL, but I think that's equivalent to yours [17:25:57 CET] <ldts> um that is probably what it is [17:25:58 CET] <ldts> let me try that [17:27:10 CET] <ldts> yeah that is better. thanks! [17:27:35 CET] <cone-355> ffmpeg 03Mark Thompson 07master:2e96f5278095: v4l2_m2m: Fix integer overflow in timestamp handling [17:27:47 CET] <wm4> ah, wouldn't have thought that it makes a difference [17:28:49 CET] <ldts> that is probably gitolite doing some validation (and I need to push as git user I guess) [17:35:12 CET] <kierank> jamrial: iiuc no [17:35:15 CET] <kierank> but soft freeze [17:43:53 CET] <atomnuker> jkqxz: what do you think should be made public from hwcontext_vulkan's private device context? I think you said it should pretty much all be public [17:57:06 CET] <durandal_1707> someone forgot to bump minor of lavfi numerous times [18:02:14 CET] <jamrial> durandal_1707: just bump minor once now. the last filter addition was two commits ago after all [18:02:46 CET] <durandal_1707> not me [19:33:39 CET] <vrd> Hello everyone, I'm Vishal , and want to contribute to ffmpeg's works :) Could anyone please tell me which mentored projects are still available for grabs , in terms of the qualifying tasks?Thanks in advance !:D [19:41:59 CET] <omerjerk> Please go through the list of tasks at - http://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018 [19:46:20 CET] <vrd> Thank you for the reply :) I had looked at the list of projects a while ago, but was wondering if any of these tasks have been resolved, since I am quite late to the scene... [19:46:35 CET] <klaxa> are you? [19:47:12 CET] <vrd> :D If you put it that way... [19:47:41 CET] <klaxa> i have been following the ML and i haven't seen anyone claim anything so far, i might be wrong though, so maybe search the ML archive for gsoc or something similar [19:48:04 CET] <klaxa> tbh, i was also thinking of participating again this year [19:48:34 CET] <klaxa> but i'm also not even enrolled in my master's program yet :V [19:49:00 CET] <klaxa> but i will be during the summer [19:49:25 CET] <vrd> Okay...:D Well I wish you all the best in that voyage! [19:51:48 CET] <vrd> BTW, ML is for 'Mailing List' right? :D [19:52:15 CET] <klaxa> yes [19:53:17 CET] <vrd> Thanks ! :) [20:24:50 CET] <omerjerk> Feel free to ask in the mailing list in case of any doubts. [20:26:35 CET] <BtbN> Do we have any samples with h264 video and resolution changes? [20:26:52 CET] <nevcairiel> yes, there even is a fate test for that [20:26:57 CET] <nevcairiel> so a sample is in fate [20:27:19 CET] <nevcairiel> http://fate-suite.ffmpeg.org/h264/reinit-large_420_8-to-small_420_8.h264 [20:34:35 CET] <BtbN> you can do res changes in raw h264? [20:35:20 CET] <BtbN> yeah, that indead breaks on any kind of hw chain [20:35:43 CET] <BtbN> Because it wants to insert a vf_scale on the re-init [20:35:55 CET] <BtbN> And I don't understand why it doesn't try to do so on the initial filter chain [20:36:28 CET] <BtbN> I mean, fixing it trying to insert that scaler is easy. But I suspect something else is going on. [20:37:26 CET] <BtbN> Maybe we should make up a fake hwaccel format, that is actually all software, just so the hw stuff can be tested with fate? [20:48:03 CET] <wm4> maybe it needs to drain the old filter chain on format changes [20:49:35 CET] <BtbN> It seems to be building an entirely new chain [20:49:38 CET] <BtbN> and it fails while doing so [20:49:47 CET] <BtbN> because it inserta a vf_scale into it [20:53:21 CET] <BtbN> this code in ffmpeg.c is a mess [20:54:02 CET] <wm4> I don't think ffmpeg.c inserts vf_scale, only libavfilter, but dunno [20:54:04 CET] <wm4> and sure, it's a mess [20:54:08 CET] <BtbN> it does [20:54:53 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg_filter.c;h=87… [20:55:03 CET] <BtbN> and it's exactly that which is failing [20:55:22 CET] <BtbN> This google-fork has it changed like that: https://github.com/fuchsia-mirror/third_party-ffmpeg/blob/master/ffmpeg_fil… [20:55:26 CET] <BtbN> which seems sensible to me [20:55:42 CET] <BtbN> but I'd like to understand why it only runs into that on runtime-res-changes. It looks to me like that should always explode [20:58:32 CET] <nevcairiel> the google fork doesnt have it changed, its just old [20:58:35 CET] <nevcairiel> thats how it used to look [20:59:07 CET] <nevcairiel> the reason is of course that encoders dont support res changes [20:59:15 CET] <nevcairiel> so you have to retain a fixed output size [21:02:29 CET] <BtbN> oh, so it indeed is there intentional [21:03:13 CET] <BtbN> So I guess this needs logic for every possible hw format to insert a scaler... [21:03:31 CET] <BtbN> Or res changes are plain not supported for hwaccel [21:05:59 CET] <BtbN> For nvdec/cuvid, adding hwdownload and format=nv12 to the end of the chain solves the issue [21:06:41 CET] <jkqxz> Not supported in general. It's the hwcontext information changing that is the real problem - you end up needing to recreate everything. [21:06:50 CET] <BtbN> I guess in a more general sense, the logic should be extended to only insert a scaler if the resolution actually changed, and not just is set in general [21:07:06 CET] <BtbN> then just having your own scale filter in the filter chain, so the output res is fixed to begin with, won't cause you any issues [21:08:01 CET] <BtbN> cause in this limited case, just commenting out the auto-inseted scaler works just fine [21:08:02 CET] <jkqxz> Some components would be able to keep the same output hardware context and therefore avoid the need to reconfigure everything after that point, but that runs into inflexibility in reconfiguring libavfilter. [21:08:14 CET] <BtbN> but there's a scale_npp in the chain that always outputs the same res [21:09:03 CET] <BtbN> Why would the hwcontext need re-configuration? [21:09:10 CET] <BtbN> Only a potential hw_frames_ctx would [21:09:38 CET] <jkqxz> hw_frames_context holds the hardware context information about a link. [21:09:58 CET] <jkqxz> If you change it, you need to reconfigure the thing on the other end of that link. [21:10:15 CET] <BtbN> Isn't it only a hw device ctx? [21:10:24 CET] <jkqxz> And we don't have the infrastructure to do that in any sane way, so "not supported" is the only general answer. [21:28:48 CET] <wm4> wouln't fixing that require inserting hwdec specific scale filters [21:29:02 CET] <nevcairiel> among other things [21:29:04 CET] <wm4> I mean there's no reason why an encoder couldn't change the hwframes ctx, or is there [21:29:17 CET] <wm4> as long as it uses the same device [21:29:19 CET] <nevcairiel> i wonder why encoders want a hwframes ctx anyway [21:29:27 CET] <nevcairiel> most dont even access it beyond the device inside of it [21:29:40 CET] <wm4> because that's how hwdec AVFrames work [21:29:56 CET] <nevcairiel> why couldnt it work with a device ctx instead [21:30:21 CET] <wm4> dunno, it might need the surface size or sw_format for example [21:31:15 CET] <nevcairiel> take nvenc for example, it doesnt access anything of the frames ctx except getting to the device ctx [21:32:02 CET] <wm4> doesn't matter, the invariant for cuda frames is that they have a frames context set [21:32:22 CET] <nevcairiel> doesnt have to be cuda frames, nvenc takes d3d11 as well [21:33:31 CET] <nevcairiel> in practice this is giving me some headaches, I have an external source of d3d11 frames that I want to encode, and I cant really make a fully functional hwframes ctx, because I cant let it allocate the frames for me [21:33:48 CET] <nevcairiel> now in practice i can basically create an empty hwframes ctx and because nvenc never touches it, stuff doesnt break [21:33:51 CET] <nevcairiel> but its just ugly [21:34:31 CET] <wm4> I think that's how it's supposed to work [21:34:51 CET] <wm4> personally I'd probably prefer if AVFrame.data[0] just pointed to s truct containing all info [21:35:08 CET] <wm4> instead of weirdly attaching a frame pool to the AVFrame [21:36:20 CET] <nevcairiel> so basically, this hwframes thing doesnt really consider wrapping external frames [21:36:54 CET] <wm4> depends how you look at it [21:37:22 CET] <nevcairiel> creating a hwframes context and manually creating an AVBufferPool just to have it empty is just awkward [21:37:57 CET] <wm4> I don't think you have to create an AVBufferPool (the hwframes code might do that internally, sure) [21:38:22 CET] <nevcairiel> wouldnt it allocate frames then? [21:38:29 CET] <nevcairiel> not that it really hurts to do that, but its just ugly [21:39:45 CET] <wm4> no, if you don't set an initial pool size it won't [21:40:10 CET] <wm4> (although merely creating a vaapi hwframes context will create and destroy a small "test" surface to probe some properties) [21:41:09 CET] <wm4> (well, "small" - it allocates one according to the frame size fields) [21:42:22 CET] <nevcairiel> i should probably just test if this works. Sending a faux hwframes context through avfilter if scaling is required and/or to nvenc [21:42:28 CET] <nevcairiel> also i should finish the d3d11 vpp filter [21:44:22 CET] <nevcairiel> silly people complaining that downscaling UHD in software is too slow :) [22:08:47 CET] <BtbN> nevcairiel, wm4, at least nvenc only uses the hw_frames_ctx to get the CUDA context. And it works perfectly fine with only a hw_device_ctx. [22:09:31 CET] <BtbN> The scale filters have their own hw_frames_ctx inside of them anyway [22:09:54 CET] <BtbN> So the frames that reach the encoder would actually come from the same frames context [22:10:15 CET] <BtbN> I don't think ffmpeg.c should insert hw specific filters [22:10:31 CET] <BtbN> but it should not try to insert an sw filter into a chain that can't possibly support it. [22:11:02 CET] <BtbN> It's then up to the user to have a filter graph that supports res changes, like any of the scale filters manually in them [22:11:52 CET] <wm4> ffmpeg.c can't know if vf_scale supports hw, but I guess it can assume that it doesn't [22:12:29 CET] <BtbN> it could check its input formats for the one it has at hand [22:48:30 CET] <peloverde> atomnuker: ADTS muxer should take a header_rate AVOption TS muxer and segment muxer should set it according to some magic when nesting [22:48:38 CET] <peloverde> if we ever get an SBR encoder similar is needed [22:53:05 CET] <peloverde> Though that probably breaks stuff if there are already multiple PCEs in the stream and they vary [22:54:11 CET] <peloverde> aac transport layering is a debacle [22:54:19 CET] <peloverde> how does segmenting avc hander header changes? [00:00:00 CET] --- Tue Jan 23 2018

1 0

ffmpeg.log.20180122
by burek 23 Jan '18

23 Jan '18

[00:03:43 CET] <ddubya> mooyoul, audio has i-frames too [00:04:13 CET] <ddubya> but if you use PCM audio you can cut anywhere, compressed formats have limitations [00:05:20 CET] <mooyoul> ah yeah [00:05:40 CET] <mooyoul> but i use wav audio for input, it has same problem also [00:06:03 CET] <ddubya> hmm [00:06:05 CET] <mooyoul> let there are a wav file named "long-audio.wav" [00:06:37 CET] <mooyoul> if i segment that audio via "ffmpeg -i long-audio.wav -f segment -segment_time 5 segment-%03d.wav" [00:07:06 CET] <mooyoul> and re-encode them via "ffmpeg -i segment-000.wav -c:a libfdk_aac -b:a 96k -cutoff 18000 encoded-000.mka" [00:07:37 CET] <mooyoul> and concat them via "printf "file '%s'\n" ./*.mka > mylist.txt" and "ffmpeg -f concat -i mylist.txt -c copy merged.mka" [00:07:41 CET] <mooyoul> i can hear gaps too [00:09:48 CET] <ddubya> but if you concat the wav files no gaps right. Generate a sine wave in your source file to make it super obvious [00:11:02 CET] <mooyoul> Yeah, concat wav files is okay. they don't have any gaps ;) [00:12:38 CET] <ddubya> so back to my last idea. What if you cut the files so they're a multiple of 1024 samples (this is the frame size of aac) [00:14:58 CET] <illuminated> can somebody find in the manual what the -re option does? [00:15:19 CET] <illuminated> I've seen it one time in some of the documentation, but I forgot what it does, and I can't find it in the manual anymore [00:15:25 CET] <furq> it forces reading at the input framerate [00:15:40 CET] <ddubya> mooyoul, if your audio is 44.1khz then the cut time would be 4.992290249 s [00:15:45 CET] <illuminated> furq thx [00:15:55 CET] <furq> you use it when you want to pretend a file is actually a stream [00:16:00 CET] <furq> usually for sending a file to a streaming server [00:16:20 CET] <illuminated> awesome thanks furq [00:16:31 CET] <mooyoul> okay, i'm trying [00:17:22 CET] <furq> 23:03:43 ( ddubya) mooyoul, audio has i-frames too [00:17:23 CET] <furq> ?? [00:17:54 CET] <mooyoul> hmm that also has gaps [00:17:56 CET] <furq> mooyoul: you might want to try using m4a or something instead of mka [00:18:09 CET] <ddubya> furq, sure it does, you can't cut it on any packet and expect it to work [00:18:43 CET] <mooyoul> i tried other containers like m4a or ts [00:18:47 CET] <ddubya> maybe i-frames is the wrong term, key-frames is better [00:18:52 CET] <kepstin> ddubya: for most audio codecs, you can cut on any packet (but you might need to discard the first N decoded samples) [00:19:23 CET] <mooyoul> but other containers also have same problem [00:19:38 CET] <mooyoul> so i'm assuming it is not container related problem [00:19:39 CET] <kepstin> in particular, there's generally no packets in audio codecs which are special such that they're easier to cut on [00:19:45 CET] <illuminated> I love ffmpeg [00:20:31 CET] <furq> mooyoul: i take it you need to encode before the split and then concat the encoded files [00:20:56 CET] <furq> i've never really dug into it but i've had issues with gaps appearing with -f concat [00:23:29 CET] <mooyoul> ah yeah and it is not related to input source, because i have same problem even i use aac or mp3 encoded input [00:23:52 CET] <mooyoul> weird thing is when i re-encode concat-ed output, gap are gone! [00:24:31 CET] <kepstin> concatenating encoded audio files in general won't work, because the last packet of the previous stream will usually be padded, and the first packet (at least) of the next stream will have encoder delay [00:25:01 CET] <kepstin> but if you just concatenate the packets, then the player won't skip the samples that were added, so there'll be a discontinuity/gap [00:26:50 CET] <kepstin> end result: if you want to seamlessly/gaplessly concatenate encoded audio files, you'll need to decode then re-encode them [00:28:40 CET] <mooyoul> ohhhh... thank you kepstin. [00:29:46 CET] <mooyoul> hmmmm..should i give up encoding huge audio file in parallel servers? [00:30:53 CET] <kepstin> honestly, the audio usually encodes so many times faster than video that it's probably not worth the effort [00:31:06 CET] <kepstin> encode the audio on one box, encode the segmented video on a bunch of other boxes [00:32:20 CET] <mooyoul> yeah audio encoding much faster than video encoding [00:32:45 CET] <mooyoul> but i needed to end audio encoding job in 5 minutes [00:33:25 CET] <mooyoul> because there are some execution time limit (i'm running ffmpeg in aws lambda) [00:33:45 CET] <kepstin> I mean, in theory if you know the encoder delay of your specific encoder and cut the audio on exact frame boundaries, then you can encode the audio such that you can discard the preroll/delay frames from the next stream during concatenation [00:33:51 CET] <kepstin> a lot of custom work required there [00:34:16 CET] Action: kepstin just has an autoscaling aws spot instance fleet to run encoder jobs on. [00:50:02 CET] <s``> How can I find out whether an AVPacket is a b-frame or a p-frame? I get AVPackets with avcodec_receive_packet from a h264_vaapi codec. [00:53:42 CET] <kepstin> s``: I don't think there's any way to tell without parsing/decoding the result. The packet flags can only indicate whether it's a keyframe or not. [00:59:20 CET] Action: sis say hola [00:59:50 CET] <sis> anyone alive? [01:00:14 CET] <sis> en mi epoca los canales de irc eran un poco mas interactivos [01:00:33 CET] <sis> y eso que la velocidad era de 14.400 bps [01:03:11 CET] <therage3> well, thing is, this is mostly a support channel [01:03:20 CET] <therage3> so unless someone asks something, conversation isn't that frequent [06:31:24 CET] <rogerschicken> is it possible to change fffmpeg profile without reencoding? if i use -vcodec copy, it seems to override and not change the profile at all [06:31:51 CET] <rogerschicken> sorry, h264 profile, not ffmpeg [08:50:34 CET] <Taemojitsu> I think recent versions of ffplay and ffmpeg were changed to not update faster than screen refresh rate, can someone test something for me? [08:52:30 CET] <Taemojitsu> Create a file with fps faster than your refresh rate with 'ffmpeg -filter_complex color=black:r=120 -t 10 black.mp4', then play it with ffplay. (video output from ffmpeg is also limited for me, but I'm more confident ffplay worked differently in the past.) [08:52:56 CET] <Taemojitsu> That is, play it with 'ffplay -noframedrop black.mp4'. [08:56:55 CET] <Taemojitsu> Basically, I used to be able to play 1080p 60fps video with ffplay and -noframedrop, with occasional slowdowns before ffplay could catch back up. Now it's consistently too slow and less than 100% CPU, because ffplay never catches back up and my refresh rate is around 59.7, so even a low-resolution 60fps video falls behind with -noframedrop. I'd like to isolate the problem to a change in ffplay/ffmpeg. [10:10:49 CET] <Taemojitsu> For anyone who saw my question, the solution is to pass the environment variable vblank_mode=0, as shown here: https://stackoverflow.com/questions/17196117/disable-vertical-sync-for-glxg… [10:52:51 CET] <thunfisch> Hey there! Does anyone know if using vaapi on intel with the h264_vaapi encoder supports baseline profile? I've not been able to set it. [10:53:10 CET] <thunfisch> it defaults to high [10:53:43 CET] <jkqxz> Nothing supports baseline profile. You probably want constrained baseline. [10:55:31 CET] <thunfisch> yes. [10:55:37 CET] <thunfisch> still, any idea? [10:56:31 CET] <thunfisch> https://paste.xinu.at/1ch1pb/ that's what i'm getting now. [10:58:07 CET] <jkqxz> "constrained_baseline" (or 578). [11:00:28 CET] <thunfisch> same error :() [11:00:46 CET] <thunfisch> ah, 578 seems to work [11:00:48 CET] <thunfisch> thank you! [11:01:04 CET] <thunfisch> any documentation about that? couldn't find it via google:/ [11:32:04 CET] <ravi_> Hi, I am muxing vp8 video and opus audio streams (RTP streams) into a webm file. After i mux, when i play the video in vlc, it says "VLC does not support the audio and video format 'undf' . Unfortunately there is no way for you to fix this". And, the "duration" filed in the Segment info of the file is too high (79064652.240s). Do i have to set duration for the audio/video tracks ? [11:32:52 CET] <ravi_> Is there anything else I need to set to get appropriate duration for the file and make it play ? Also, when I chekc the Codec details in the Media information of VLC it says for audio track the Codec in undf. [11:33:18 CET] <sfan5> you usually don't need to set the duration of tracks [11:33:45 CET] <sfan5> seems like vlc is not recognizing opus, can it play opus in other files? [11:47:33 CET] <ravi_> nope it is not playing opus [11:48:27 CET] <sfan5> sounds like you need to update VLC then [11:48:57 CET] <ravi_> but the "duration" and "Default duration" of video track are not valid. Like i said, th eduration in segment info is too high. [11:51:13 CET] <Daglimioux> Hello there. I'm having troubles when compiling some webm videos into a mosaic mp4 output and I cannot find which is the error that is causing the command being executed forever. First of all, I get an error when it is compiling that says "Invalid profile 6", which I couldn't find any information on internet. Secondly, I get an error that says "Invalid data found when processing input" [11:51:55 CET] <Daglimioux> The second error is mentioned in many forums, but their workarounds are to try enabling the missing demuxers. I have all demuxers for webm, as mentioned in docs and for mp4 [11:51:56 CET] <jkqxz> thunfisch: Oh right, the names got added more recently than 3.4. [11:52:41 CET] <ravi_> i am setting pts and dts values of each packet to respective rtp timestamps . Is that correct ? [11:52:49 CET] <jkqxz> thunfisch: The numbers are just profile_idc + constraint_set flags, <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/avcodec.h;h=8fbbc…>. [11:53:41 CET] <Daglimioux> And the main problem is that the video compilation keeps running forever... I don't know if those errors are who cause this behaviour [12:07:13 CET] <OneSploit> Hi [12:18:17 CET] <s``> when is use the h264_vaapi from the cli everything is working fine, i can play it in chromium, and the pts dts values are the same. when i use it in my program which is based on the vaapi_encode.c and muxing.c example, I get a video where the pts values is lower than the dts values in the p frames, so some player (chromium, ios) can't play it well. Do you have an idea how can I fix that or where can I find the packet reorder/magic code? [12:18:55 CET] <OneSploit> do you guys know if http://deb-multimedia.org/ contains ffmpeg that is build with nvenc ? [12:19:43 CET] <furq> ffmpeg from apt should have nvenc [12:19:48 CET] <furq> unless you're on some ancient debian [12:19:57 CET] <OneSploit> oh [12:20:06 CET] <OneSploit> that's wired, let me check [12:20:13 CET] <OneSploit> furq: from official one? [12:20:39 CET] <furq> yeah [12:20:57 CET] <OneSploit> hmm so I don't need to rebuild [12:28:50 CET] <OneSploit> furq: I wonder what should I use to get fast screencasting, it seems my CPU usage jumps a lot when I try to cast something with standard encoder [12:29:16 CET] <furq> probably obs and nvenc [12:30:35 CET] <OneSploit> obs is not packaged for Debian and crashes for me [12:31:19 CET] <furq> it's in debian stable now [12:31:21 CET] <furq> obs-studio [12:31:48 CET] <thunfisch> jkqxz: nice, thank you! will bookmark that. [12:32:15 CET] <OneSploit> furq: oh.. somehow I missed that, thanks [12:32:19 CET] <furq> you can probably just use ffmpeg and xcbgrab for simple stuff [12:32:34 CET] <OneSploit> furq: I used simplescreenrecorder [12:32:45 CET] <OneSploit> but I wonder about that obs what it gives [12:32:50 CET] <furq> if you want to capture sdl/opengl etc then you'll want something like obs [12:33:00 CET] <furq> it's generally just better at screen capturing lol [12:33:23 CET] <furq> it uses the ffmpeg libs internally for more or less everything else it does [12:33:34 CET] <furq> but all the screen capturing stuff is custom afaik [12:38:12 CET] <s``> bye [12:38:13 CET] <s``> wow, if I set the hwframe's pts, everything just working, thank guys [12:39:34 CET] <OneSploit> furq:can select only Software (h264) in OBS as encoder... [12:39:35 CET] <OneSploit> wired [12:39:52 CET] <OneSploit> obs-studio version 19.0.3 [12:39:58 CET] <Daglimioux> I have a command that throws some "minimal" errors, but keeps executing. The problem is that it keeps running forever and I don't know if those errors are the problem here. Anyone that could help me with that? I can link the command if needed [12:40:08 CET] <furq> are you using ffmpeg from the debian repos [12:40:21 CET] <OneSploit> furq: yes [12:40:22 CET] <furq> if you have obs 19 then i guess ffmpeg -version should return 3.4.1 [12:40:38 CET] <OneSploit> ffmpeg version 3.4.1-1+b2 [12:40:40 CET] <furq> weird [12:41:11 CET] <furq> does h264_nvenc show up in ffmpeg -codecs | grep nvenc [12:42:44 CET] <OneSploit> yes [12:43:12 CET] <furq> shrug [12:43:21 CET] <furq> i've never used obs on *nix so i wouldn't know where to start [12:43:27 CET] <furq> maybe try their irc [12:45:19 CET] <OneSploit> ok solved [12:45:27 CET] <OneSploit> it does not depend on libnvidia-encode1 but needs it [12:55:13 CET] <OneSploit> furq: do you know what input source should I use in obs to record only opengl app window and not whole desktop :) [12:55:20 CET] <OneSploit> works on simple screen recorder [12:55:26 CET] <OneSploit> I guess I should ask at some obs channel [13:03:56 CET] <Daglimioux> Okay, I've found that one of those "minimal" errors is "Error while decoding stream #0:0: Invalid data found when processing input". Any suggestion why is this happening? I can see the video properly on VLC, without errors, with the right time duration, etc. [13:44:03 CET] <Daglimioux> I got an error when trying to build x264 library: AVComponentDescriptor has no member named depth. Any suggestion? [15:00:03 CET] <kikobyte> Hi guys, I'm having problems with scale_npp filter on ffmpeg 3.3.5 (w/ hwaccel cuvid: h264_cuvid -> scale_npp=-1:1520 -> h264_nvenc). My input is an mpeg-ts file with resolution changing over time, and during initialization the scale_npp filter gets properly inserted, I see "[Parsed_scale_npp_0 @ 0x3b12840] w:768 h:432 -> w:2702 h:1520", while on resolution change I see scaler_out_0_1 and auto_scaler_0 trying to make it into the gra [15:01:01 CET] <kikobyte> ffmpeg -loglevel 50 -y -f mpegts -hwaccel cuvid -c:v h264_cuvid -i dump_multires.ts -vf scale_npp=-1:1520 -map 0:a -map 0:v -c:a libopus -b:a 256k -c:v h264_nvenc -b:v 24M -maxrate 28M -bufsize 28M -g 60 -flags:v +global_header -profile:v baseline -preset:v fast -zerolatency 1 -forced-idr 1 -aud 1 -bsf:v dump_extra -strict -2 -f mpegts -muxdelay 0.1 out1.ts [15:02:41 CET] <kikobyte> Works as expected when the input file has fixed video resolution, but once it changes, I get output like https://pastebin.com/5gvLapeu [15:11:25 CET] <BtbN> I don't think random resolution changes are supported by it. [15:15:52 CET] <kikobyte> BtbN: How one can see if an input resolution change is supported by the filter? I would think into the AVFilter::process_command field defined by the scale filter, but missing in scale_npp, but that seems to change the output resolution. Any hints on what should be done/investigated/implemented to make this working? I could do it myself if I got some clues. [15:16:34 CET] <BtbN> scale_npp is basically abandoned, you should look into scale_cuda if you want to add that feature. [15:18:30 CET] <kikobyte> https://ffmpeg.org/ffmpeg-filters.html doesn't have any notion of scale_cuda, but it does for scale_npp (without any deprecation warnings), and there are reasons why I cannot switch to ffmpeg 3.4, which has got the scale_cuda filter. [15:19:16 CET] <kepstin> well, you can't really expect that this'll get fixed in 3.3 at this point... [15:24:05 CET] <BtbN> it won't get backported to any current release branch either way [15:50:14 CET] <aruns> Hi, how do you guys tend to compress JPEGs in FFMPEG? [15:50:36 CET] <aruns> Atm, I am doing ffmpeg -i /path/to/image.jpg /path/to/output.jpg [15:54:23 CET] <kikobyte> kepstin: BtbN: I don't expect backports or fixes, a hint would be enough for me to make the necessary changes in my fork. At least something I could start looking from [16:38:00 CET] <Daglimioux> Is it usual that a mosaic compilation keeps the process running forever if one of the videos duration is 18 minutes length and the other one's duration 1 minute length? [16:38:37 CET] <Daglimioux> I mean if all videos has to be the same length to do a compilation [16:39:29 CET] <durandal_1707> full output missing [16:40:55 CET] <Daglimioux> Do you mean that I must add something like a "black screen" for the other missing 17 minutes? [16:41:19 CET] <durandal_1707> Daglimioux: no [16:47:18 CET] <Daglimioux> durandal_1707: then? [16:47:50 CET] <durandal_1707> Daglimioux: no enough data provided [16:53:02 CET] <Daglimioux> durandal_1707: the problem is that I have a compilation with 3 videos and a "black screen" in a 2x2 mosaic compilation. When I do it with other videos it works perfectly, but there is one compilation that keeps running forever. The only difference I found so far, is that 2 of those videos are 18 minutes length and the third one is only 1 minute length or so. Could be that the problem? [16:54:04 CET] <durandal_1707> no, provide full command line [16:54:08 CET] <Daglimioux> There is no errors at all. Only a "Invalid data found when processing input", but I don't think that is the problem (?) as it is converted from webm to mp4 [16:54:13 CET] <Daglimioux> ah okay, one sec [17:03:11 CET] <Daglimioux> ffmpeg -i video1.webm -i video2.webm -f lavfi -i color=s=640x360:color=black:d=1 -i video3.webm -i audio1.opus -i audio2.opus -i audio3.opus -i audio4.opus -filter_complex "amix=inputs=4:dropout_transition=0; [0:v] scale=640x360, setdar=0 [r1c1]; [1:v] scale=640x360, setdar=0 [r1c2]; [3:v] scale=640x360, setdar=0 [r2c2]; [r1c1][r1c2] hstack=2 [r1]; [2][r2c2] hstack=2 [r2]; [r1][r2] vstack=2" -c:a libfdk_aac -b:a 96k -c:v libx264 [17:03:14 CET] <Daglimioux> -preset ultrafast -y output.mp4 [17:03:20 CET] <Daglimioux> thats the full command [17:07:54 CET] <adgtl-> Folks, I am getting this error "Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument" for https://gist.github.com/8b428c4e2d4d4e48b41ffb022494794d [17:08:57 CET] <durandal_1707> Daglimioux: so it hangs? which version? [17:09:39 CET] <Daglimioux> ffmpeg version N-86400-ga3b5b60 Copyright (c) 2000-2017 the FFmpeg developers [17:11:02 CET] <adgtl-> I am just trying to run "ffmpeg -i 4485.mp4 -i 4485.opus -strict -2 -codec copy output.mp4" [17:11:11 CET] <adgtl-> Do you folks need these files? [17:11:27 CET] <adgtl-> Can someone confirm that -codec copy really works for opus too? [17:12:27 CET] <OneSploit> furq: question nvidia 960M does not have hevc_nvenc ? [17:13:15 CET] <ZeroWalker> when cutting with -ss and -t, is it possible to have it lossless but re-encode the partly in order to make the cut precise? [17:13:45 CET] <c_14> not with commandline ffmpeg [17:13:58 CET] <c_14> I mean [17:14:22 CET] <c_14> I guess you could make the cut with -c copy, then find where it actually cut, do another encode of the part it missed and then combine them [17:14:24 CET] <c_14> but [17:14:36 CET] <adgtl-> c_14: to me? [17:14:45 CET] <c_14> to ZeroWalker [17:14:58 CET] <adgtl-> can someone help me? [17:15:11 CET] <adgtl-> Getting error as said above [17:15:12 CET] <ZeroWalker> ah, [17:15:53 CET] <durandal_1707> adgtl-: what are you doing? [17:17:24 CET] <adgtl-> durandal_1707: I have .mp4 without audio and .opus with audio.. I want to create single .mp4 with audio and video [17:17:32 CET] <adgtl-> and without re-encoding.. just by codec copy [17:17:41 CET] <adgtl-> I am not able to successfully process that [17:19:02 CET] <durandal_1707> adgtl-: hmm, try -aco [17:19:19 CET] <durandal_1707> -acodec copy [17:20:09 CET] <durandal_1707> otherwise pastebin full uncut ffmpeg output [17:21:13 CET] <kepstin> adgtl-: putting opus in mp4 is not supported by many programs, so you'll probably want to re-encode to aac. [17:21:52 CET] <therage3> or if the end player can handle mkv container, use that [17:22:00 CET] <therage3> since mkv can have just about anything [17:22:01 CET] <kepstin> (i forget whether an opus mapping for mp4 even exists) [17:23:02 CET] <c_14> kepstin: there is one, but I'm not sure it's finalized yet [17:23:34 CET] <c_14> was still a draft last I checked [17:24:48 CET] <kepstin> adgtl-: anyways, the answer is "yes, you can use -codec copy on opus - but you can't put opus into mp4 container" [17:24:54 CET] <adgtl-> durandal_1707: updated gist with -acodec copy https://gist.github.com/8b428c4e2d4d4e48b41ffb022494794d [17:25:14 CET] <adgtl-> kepstin: so error is legit? [17:25:24 CET] <kepstin> adgtl-: "[mp4 @ 0x170fb80] Could not find tag for codec opus in stream #1, codec not currently supported in container" [17:25:44 CET] <Daglimioux> durandal_1707: Yep, it hangs when reaches the longest video duration (at 18 mins or so). The version I get from ffmpeg -version is: ffmpeg version N-86400-ga3b5b60 [17:25:50 CET] <adgtl-> kepstin: so what's best solution to avoid re-encoding and do quickest conversion to mp4? [17:26:02 CET] <kepstin> adgtl-: you can't put opus in mp4 so you have to re-encode. [17:26:11 CET] <kepstin> adgtl-: if you don't need mp4, then use mkv instead. [17:27:11 CET] <therage3> adgtl-: i'd just use mkv if whatever place you want to play it on supports that [17:27:45 CET] <durandal_1707> Daglimioux: well, it should not happen, so try latest version [17:28:44 CET] <adgtl-> kepstin: what's command to create mkv? [17:28:48 CET] <Daglimioux> durandal_1707: I tried but I get an error when I try to configure the x264 library: AVComponentDescriptor has no member named depth but I couldn't find anything related on internet :S [17:29:07 CET] <kepstin> adgtl-: change the file extension on the output filename from .mp4 to .mkv [17:29:09 CET] <adgtl-> therage3: it's web browsers which will be playing these video files? [17:29:10 CET] <therage3> adgtl-: just specify the output as ending in mkv extension, that should probably be ebough [17:29:23 CET] <durandal_1707> Daglimioux: update your libx264 [17:29:26 CET] <kepstin> adgtl-: web browsers generally don't support mkv, so you're out of luck. [17:29:30 CET] <adgtl-> therage3: and chrome, firefox, internet explorer etc support mkv? [17:29:39 CET] <adgtl-> kepstin: lol.. what should I do now [17:29:39 CET] <therage3> adgtl-: ah, there you go, then that's a bit unfortunate [17:29:53 CET] <adgtl-> anyways.. issue is that re-encoding takes more time.. I want something quick [17:29:56 CET] <Daglimioux> durandal_1707: I did. I followed the ffmpeg installation instructions, but I keep having that error [17:29:58 CET] <adgtl-> without re-encodding [17:30:13 CET] <kepstin> adgtl-: re-encode the audio to aac is the fastest/easiest way to turn that into a file that web browsers can play. [17:30:27 CET] <Freex> Hi all [17:30:27 CET] <kepstin> adgtl-: no need to re-encode the video tho. [17:30:53 CET] <Freex> Can someone provide me with the dev and shared Windows files for the FFmpeg 2.8.13 release? [17:31:11 CET] <kepstin> adgtl-: so something like "ffmpeg -i 4485.mp4 -i 4485.opus -c:v copy -c:a aac -b:a 128K output_yes.mp4 [17:31:30 CET] <adgtl-> kepstin: what's that 128K there? [17:31:31 CET] <durandal_1707> Daglimioux: new version of libx264 or ffmpeg have issues compilling? [17:31:37 CET] <adgtl-> kepstin: I need highest quality possible [17:31:40 CET] <kepstin> adgtl-: the bitrate for the audio encode. [17:31:45 CET] <adgtl-> kepstin: okay [17:32:32 CET] <Daglimioux> durandal_1707: Okay nevermind, something should be in conflict with x264. Now it is compiling, let me check with new version. Sorry about that [17:33:03 CET] <adgtl-> kepstin: "[aac @ 0x161b020] The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it." [17:33:10 CET] <kepstin> adgtl-: upgrade to a newer ffmpeg [17:33:24 CET] <therage3> adgtl-: what? [17:33:28 CET] <therage3> wait, what version are you on? [17:33:44 CET] <kepstin> probably 2.8 or something [17:33:54 CET] <kepstin> iirc the aac encoder experimental flag was removed in 3.0 [17:34:04 CET] <therage3> yeah, because that's an old version that gave that message [17:36:38 CET] <adgtl-> kepstin: It's "ffmpeg version 3.4.1" [17:36:46 CET] <adgtl-> kepstin: ? [17:36:54 CET] <adgtl-> it's more than 3.0 [17:36:59 CET] Action: therage3 raises eyebrow [17:37:02 CET] <NapoleonWils0n> hi all [17:37:28 CET] <NapoleonWils0n> im just trying to help someone record a video which has north american closed captions [17:37:30 CET] <kepstin> adgtl-: according to that error message it's not. You would not see that message with ffmpeg 3.4.1. [17:37:37 CET] <kepstin> adgtl-: from your pastebin: "ffmpeg version 2.8.11-0ubuntu0.16.04.1" [17:38:10 CET] <NapoleonWils0n> if i do an ffprobe -i url, i can see the closed captions are in the h264 video stream [17:38:15 CET] <adgtl-> kepstin: yeah.. on server "ffmpeg version 2.8.11-0ubuntu0.16.04.1" [17:38:20 CET] <therage3> adgtl-: if you have two ffmpeg versions, the one you call may be the older one. the new one has to be in your PATH [17:38:30 CET] <therage3> I see [17:38:34 CET] <therage3> that's why [17:38:53 CET] <adgtl-> not sure how to upgrade to latest ffmpeg on ubuntu [17:39:00 CET] <therage3> adgtl-: https://launchpad.net/~jonathonf/+archive/ubuntu/ffmpeg-3 [17:39:01 CET] <Daglimioux> durandal_1707: Is it normal when executing ./configure to show "Unknown option --enable-libopus", "Unknown option --enable-libx264", etc.? I don't remember that message when issued the same command with my current version of FFMpeg [17:39:14 CET] <therage3> adgtl-: ... did you click that link I just showed you? [17:39:30 CET] <adgtl-> sudo apt-get install ffmpeg says ffmpeg is already the newest version [17:39:35 CET] <therage3> it's a PPA for newer versions of ffmpeg [17:39:36 CET] <NapoleonWils0n> i did see this cmd on stackoverflow for extract closed captions: ffmpeg -f lavfi -i "movie=test.ts[out0+subcc]" -map s output.srt [17:39:40 CET] Action: therage3 blinksblinks [17:39:40 CET] <kazuma_> NapoleonWils0n "ffmpeg -i url -c copy out.mp4" would just copy all streams including the subtitles to mp4 or whatever [17:40:14 CET] <NapoleonWils0n> hi all the closed captions arent in a seperate stream but in the vide stream [17:40:33 CET] <kazuma_> they have there own stream [17:40:33 CET] <NapoleonWils0n> im already doing a -c:a copy -c:v copy [17:40:42 CET] <kazuma_> the video audio and subs are all individual streams [17:41:33 CET] <NapoleonWils0n> when i do an ffprobe i get this [17:41:35 CET] <NapoleonWils0n> Stream #0:18: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p, 416x240, Closed Captions [17:42:19 CET] <NapoleonWils0n> ithought closed captions where different from subs which are in there own stream [17:42:25 CET] <kazuma_> try schange your -map s to -map 0:18 [17:42:26 CET] <kazuma_> then [17:42:50 CET] <NapoleonWils0n> right cheers mate, just trying to do someone a favour [17:47:31 CET] <adgtl-> what's next version better than b:a 128K ? [17:47:40 CET] <adgtl-> 320? [17:47:57 CET] <adgtl-> I need something better quality [17:50:00 CET] <c_14> usually 192 then 256 then 320 [17:50:16 CET] <ddubya> is it possible to decode with cuvid/nvdec and also do hardware scaling [17:51:34 CET] <ddubya> nvm I see scale_npp [18:07:12 CET] <NapoleonWils0n> answering my own question on how to extract closed captions from a video [18:07:17 CET] <NapoleonWils0n> use http://ccextractor.sourceforge.net [19:07:54 CET] <kikobyte> BtbN: The issue with dynamic resolution adjustment when NPP filter is in use seems to originate from ffmpeg_filter.c:configure_output_video_filter, which inserts "scale" filter whenever ofilter->width || ofilter->height is true. Disabling this logic when there is a non-null hw_device_ctx seems to fix the problem. Note: that might be needed for current master as well [19:22:59 CET] <junglistric> anyone have success building ffmpeg .so with Android NDK r16b and OSX or Linux? [19:31:43 CET] <BtbN> kikobyte, that way you won't get scaling anymore at all tho? [19:34:52 CET] <sfan5> junglistric: yes works fine [19:35:31 CET] <junglistric> @sfan5 test [19:35:43 CET] <sfan5> no need to use @ on irc [19:36:00 CET] <junglistric> sfan i get various errors with various scripts [19:36:17 CET] <sfan5> put them on a pastebin site [19:39:09 CET] <junglistric> https://pastebin.com/e23VqtcP [19:40:19 CET] <kikobyte> BtbN, in HW pipeline I create NPP scale filter myself, I just don't need an additional CPU scale filter which is otherwise inserted automatically by this logic any time the output dimensions are specified. I see messages [Parsed_scale_npp_0 @ 0x2e1c8a0] w:1920 h:1080 -> w:2702 h:1520 once the resolution changes to FullHD, and everything works fine with the command line recommended on the NVIDIA-ffmpeg website [19:41:13 CET] <sfan5> junglistric: something is wrong with your compiling setup, __DARWIN_NULL doesn't exist anywhere in the Android headers [19:41:14 CET] <kikobyte> BtbN, I might have missed something important though... But this logic just tries to create a scale filter right after my NPP scale filter. [19:41:39 CET] <BtbN> ffmpeg.c always inserts a classic scaler. Which often just does nothing [19:42:37 CET] <thebombzen> kikobyte: if it autoinserts a scale filter that doesn't do anything, there's not really any performance issue as it just basically does memcpy [19:42:58 CET] <kepstin> it shouldn't even doing memcpy, if it does that it's a performance issue :) [19:43:05 CET] <BtbN> it does litterally nothing if there's nothing to scale [19:43:09 CET] <BtbN> just passes on the frame [19:43:24 CET] <BtbN> it has no idea about hw frames anyway [19:43:26 CET] <thebombzen> ah, so it's even faster. however it's worth mentioning that npp_scale doesn't take planar formats (IIRC) [19:43:31 CET] <junglistric> yeah it's actually just from /usr/include/sys/_types.h, not sure why the compiler is picking that up [19:44:10 CET] <thebombzen> since npp_scale doesn't use planar formats, only packed formats like nv12 often times you need swcale to convert it between yuv420p and nv12 [19:45:04 CET] <sfan5> junglistric: your ./configure line should have --enable-cross-compile --target-os=android --cross-prefix=arm-linux-androideabi --arch=armv7-a or similar [19:45:19 CET] <thebombzen> scalars like zimg only take planar formats, so if you use zimg to scale to bgr0, actually it scales it to gbrp and swscale converts it from gbrp to bgr0 [19:46:28 CET] <junglistric> okay but i wanted to compile .so for a virtual device in android studio [19:47:13 CET] <sfan5> so you want to compile ffmpeg *inside* android studio? [19:47:28 CET] <Daglimioux> durandal_1707: It worked with the update. Sorry for the late reply, thanks for everything [19:47:45 CET] <junglistric> no not that route, but compile .so for a virtual device, not a physical device [19:48:13 CET] <junglistric> i imagine the cross-compile parameters would be the same? [19:48:28 CET] <sfan5> should be, yes [19:49:57 CET] <kikobyte> BtbN, probably, it does nothing, but in HW case it prevents graph from being built, because it cannot negotiate `cuda` format [19:50:38 CET] <BtbN> So you mean the code that re-negotiates on resolution change is not aware of hw frames? [19:54:19 CET] <kikobyte> BtbN, not sure about saying it in this particular way, because from that code you still can access some hw-specific stuff, but that code always creates "scale" filter, regardless of whether the pipeline is GPU or not. And "scale" filter, as I understand, can't agree on "cuda" format for the buffers [19:54:41 CET] <BtbN> well, if it always did that, even the simple case wouldn't work [19:54:54 CET] <junglistric> thanks sfan5 [19:57:58 CET] <kikobyte> BtbN, maybe I'm messing things up with this one, but the solution (disable insertion of the "scale" filter when there is an active hw_device_ctx) works for my particular purpose. Found the fix here: https://github.com/fuchsia-mirror/third_party-ffmpeg/blob/master/ffmpeg_fil… after I nailed things down to the place where the unwanted filter is being inserted. If you compare it to 3.3 branch, that's one of the only few change [20:00:45 CET] <BtbN> This code is always called, not just on format-changes [20:01:02 CET] <BtbN> so something must be up why it works on the initial setup, but not on re-negotiation [20:01:41 CET] <junglistric> sfan5 i've gotten this far but with the some other errors popping up https://pastebin.com/DCnJhrC1 [20:02:04 CET] <junglistric> seems like the linker is not finding these object files, but this happens even if I put then in the linker path [20:03:57 CET] <kikobyte> BtbN, maybe, but, unfortunately, at this point I have no other ideas - I'm not that familiar with ffmpeg code base, so I'm doing what I can at the moment - highlighting the issue and something which I consider an acceptable - oh, let's put it this way - workaround. ^_^ [20:04:26 CET] <sfan5> junglistric: I usually use android-ndk-*/build/tools/make_standalone_toolchain.py to create a toolchain, no idea about using the prebuilt ones directly [20:04:36 CET] <BtbN> the workaround seems like a sensible addition to me, as the vf_scale.c filter is entirely unaware of hw frames [20:04:43 CET] <BtbN> I'm more wondering why it works in the first place [20:05:02 CET] <BtbN> Do you have a small sample that triggers the issue? [20:09:42 CET] <kikobyte> BtbN, do you need the source media file itself? I have pasted the command line arguments, can paste again [20:10:03 CET] <BtbN> Just interested in the file [20:10:11 CET] <BtbN> unless it's something huge [20:10:41 CET] <kikobyte> 100MiB of an internal testing footage, let me double check if I can share it [20:11:09 CET] <BtbN> any video file that cuvid can decode and that has format changes will work I guess [20:12:22 CET] <kikobyte> BtbN, that's my understanding as well [20:13:55 CET] <kikobyte> BtbN, sorry, I cannot share that particular video, would you like me to find another one tomorrow? [20:14:09 CET] <BtbN> I'll find something [20:14:42 CET] <kikobyte> BtbN, thanks for your help, again. I'm off for today, see you! [20:33:40 CET] <OneSploit> Hi, can someone tell me if GeForce 960M has h245 (hvenc) capability ? [20:37:05 CET] <OneSploit> hevc_nvenc I mean [20:37:50 CET] <relaxed> OneSploit: No, https://www.geforce.com/hardware/notebook-gpus/geforce-gtx-960m/specificati… [20:40:08 CET] <DHE> relaxed: really? it says shadow play is supported [20:44:47 CET] <BtbN> I have trouble deciphering if "h245 (hvenc)" means h264 or hevc [20:45:16 CET] <BtbN> But keep in mind, with mobile cards in Optimus setups, there is a good chance the video de/encoding unit is entirely disables [20:45:31 CET] <DHE> yeah that's confusing... [20:46:24 CET] <DHE> assuming he means h265 HEVC, I would assume not. but not enough information here to make a call [20:49:41 CET] <kepstin> OneSploit: 960M should be a GM107, which as far as I can tell *does* have an encoder block [20:50:43 CET] <DHE> question is whether is supports h265... first gen maxwell? [20:51:00 CET] <kepstin> yeah, first gem maxwell, which is apparently the same as kepler [20:51:02 CET] <kepstin> so h264 only [20:51:26 CET] <kepstin> oh, huh, gm107 is listed as second gem maxwell [20:51:35 CET] <kepstin> so still h264 only, but it can do HP444 [20:53:50 CET] <kepstin> good luck to anyone with a 940M or 945M tho, you'll get (at random?) either a GM107 or GM108, and the GM108 doesn't have nvenc at all. [21:17:24 CET] <lyncher> hi all. I'm trying to add "user data" (608) to a MPEG2 video (libavcodec)... how can I get the current time? can I just count frames? [21:18:14 CET] <lyncher> and where should I inject the user data packets? after a MPEG2_START_PICTURE?? [21:18:18 CET] <ddubya> lyncher, current time ~ pts [21:19:58 CET] <ddubya> I wonder if you can make a "user data" stream type and mux it like anything else. [21:21:53 CET] <lyncher> I'm looking to mpeg2_metadata.bsf and pts is not available at that level [21:23:12 CET] <lyncher> the only reference to a "time_code" is made at MPEG2RawGroupOfPicturesHeader [21:28:36 CET] <ddubya> when you demux the stream you can read pts values [21:29:54 CET] <ddubya> but I don't know what you mean by (608) data. Is that another mpeg stream type or something else [21:30:20 CET] <lyncher> CEA-608: closed captioning data [21:31:07 CET] <lyncher> I suppose it has to be added at the end of frame data [21:32:58 CET] <ddubya> i'm on the wikipedia page, it says there are two different ways its done [21:33:35 CET] <lyncher> what is the link that you're reading? [21:33:46 CET] <ddubya> https://en.wikipedia.org/wiki/EIA-608 [21:34:21 CET] <ddubya> actually they list 3 ways [21:35:23 CET] <lyncher> it seems that I've to add that info after MPEG2_START_SEQUENCE_HEADER [21:35:35 CET] <lyncher> (defined cbs_mpeg2.h2) [21:42:52 CET] <ddubya> lyncher, I don't see anywere user_data is going into the bitstream. It appears to be decoded but not encoded [21:43:14 CET] <lyncher> I'm trying to add that code in h264_metadata.c [21:43:41 CET] <lyncher> to receive some CEA-608 data and add it after MPEG2 GOP header [21:43:49 CET] <ddubya> I did find this in mpeg4 encoder https://github.com/FFmpeg/FFmpeg/blob/8e950c9b4235bb66f3bf53608417c7cbc8148… [21:44:34 CET] <lyncher> I'm trying to add that without reencoding the video stream [21:45:21 CET] <ddubya> so just remuxing then? [21:45:22 CET] <lyncher> assuming that the received video is already MPEG2, I'm trying just to add that user data and have the remuxer to write them to the final stream [21:46:44 CET] <lyncher> there's a git repo which has an approach to encode user data to the stream: https://github.com/jpoet/ffmpeg [21:46:56 CET] <ddubya> If you simply copy packets from av_read_packet into av_write_interlaved_frame for example, I don't think anything is going to look at the packet payload itself [21:46:57 CET] <lyncher> (not merged with ffmpeg) [21:47:52 CET] <lyncher> but I'm forcing the packets to go by a patched bsf [21:48:01 CET] <ddubya> oic [21:49:02 CET] <sdds> how can I recorde live video with ffmpeg and save to file but takes only 3 frames per seconds? [21:49:41 CET] Last message repeated 1 time(s). [21:49:41 CET] <lyncher> I'm still missing the question about the timecodes.... how can I have access to the video timecodes inside the BSF [21:49:56 CET] <ddubya> sdds, I don't know how to record, but you can always change the frame rate into the encoder to whatever you want [21:50:33 CET] <sdds> what do you mean? [21:50:46 CET] <alexpigment> sdds: just put -r 3 after your input [21:50:49 CET] <sdds> i use not like ffmpeg -i http://..... 1.avi [21:51:11 CET] <sdds> but then i get faster video [21:51:18 CET] <alexpigment> that's if you put it before the input [21:51:19 CET] <ddubya> ffmeg -i input -r frame-rate output [21:52:03 CET] <sdds> but then the output is like 25 frames per seconds so i get slower video [21:52:20 CET] <alexpigment> sdds: you're missing up input and output frame rates [21:52:22 CET] <ddubya> not if you set it to 3 fps [21:52:30 CET] <alexpigment> *mixing [21:52:40 CET] <ddubya> yeah, put the "-r" after the "-i" [21:53:08 CET] <ddubya> if you put it *before* it means change the *input* frame rate [21:53:19 CET] <ddubya> after, change the output [21:53:34 CET] <ddubya> but I think that syntax was deprecated? [21:54:23 CET] <alexpigment> ddubya: you mean specifying the term -framerate vs -r before the input? [21:54:32 CET] <alexpigment> i haven't messed with it in a bit, but i think that's right [21:54:58 CET] <alexpigment> at least, i don't see anyone using -r before the input anymore, so it makes sense that's it's deprecated [21:58:32 CET] <sdds> if i put -r before the input the output reamain 25 frames per sconds [21:58:47 CET] <ddubya> sdds, so put it after.... [21:58:50 CET] <sdds> so i need to put -r before the input and -r after the input? [21:59:06 CET] <ddubya> no, only -r after the input [21:59:14 CET] <sdds> put it after takes 25 frames per seconds from the input and drop some ... [21:59:27 CET] <ddubya> isn't that what you wanted [21:59:40 CET] <sdds> I want to save dbandwith [21:59:47 CET] <sdds> bandwidth* [22:00:23 CET] <alexpigment> sdds: either there are words that you're thinking but not saying, or you are very confused [22:00:23 CET] <klaxa> that won't work the way you hope for [22:00:49 CET] <sdds> i will try to explain again [22:01:40 CET] <ddubya> if you want it to play at 25 fps and only keep every 5th frame for example in the output, is that the idea? [22:01:55 CET] <ddubya> so it would appear to play back 5x faster [22:01:58 CET] <sdds> I have live stream that I want to save for file. but i don't need to save real video like 25-30 frames per seconds , I need only 3 frames per secondes. I want to takes those frames from the live stream [22:02:21 CET] <alexpigment> sdds: presumably you're fine with / want a 3fps video, right? [22:02:25 CET] <sdds> I dont want to takes 25 frames and save only 4 , i want to takes ony 4 [22:02:26 CET] <klaxa> you will need to download the whole stream regardless though, you will need to discard the frames locally [22:02:36 CET] <klaxa> you cannot tell the remote server to only send every nth frame [22:02:51 CET] <alexpigment> sdds: it's kinda the same thing [22:03:00 CET] <klaxa> well he said he wanted to save bandwidth [22:03:07 CET] <klaxa> in that regard the idea is not wrong [22:03:15 CET] <klaxa> but in practice it doesn't really work like that [22:03:24 CET] <klaxa> you could put a proxy with ffmpeg inbetween [22:03:30 CET] <alexpigment> i guess i didn't assume he meant the bandwidth coming to *him* [22:03:54 CET] <sdds> so i must download all stream? i can't ask get only low frames per seconds? [22:03:57 CET] <ddubya> yeah it its input frame rate your after, its a capture setting. [22:04:16 CET] <ddubya> You can reduce the rate of the recording device if its an option [22:04:31 CET] <ddubya> but you haven't said what that is [22:04:38 CET] <sdds> sorry it is not to save bandwidth, the proble is that i have low cpu, and i don't want to use stream copy, [22:04:59 CET] <alexpigment> <-- even more confused now [22:05:00 CET] <alexpigment> :) [22:05:01 CET] <sdds> so if i get lower fram per secnds the cpu will be good [22:05:22 CET] <sdds> haha [22:05:29 CET] <alexpigment> stream copying is always less CPU than re-encoding fwiw [22:05:53 CET] <sdds> but i want to re-encoding becuase i wand to overlayer or soething like that [22:06:11 CET] <sdds> so i want to re-encode only less frames per secondes [22:06:25 CET] <alexpigment> sdds: have you tried just adding -r 3 after the input? what is the problem with that process? that'll help explain the problem [22:06:58 CET] <ddubya> yeah if you put -r 3 after input, your ouput will be 3 frames per second. Basically a slide show. But it will also be 10x easier to encode [22:07:59 CET] <sdds> ddubya: but i dowanload all the stream and ffmpeg will drop 27 frames per secondes? [22:08:16 CET] <alexpigment> exactly [22:12:59 CET] <sdds> alexpigment: so what -r before the input mean? [22:13:20 CET] <alexpigment> it means you re-interpret the original frame rate [22:13:29 CET] <alexpigment> and therefore change the speed of the video [22:13:47 CET] <alexpigment> which, by your explanation above, you don't want to do [22:13:55 CET] <sdds> fr what it good? if i want slower/faster video? [22:14:02 CET] <alexpigment> sure, among other things [22:14:04 CET] <sdds> that not save bndwidth or cpu? [22:14:08 CET] <alexpigment> no [22:14:24 CET] <alexpigment> if your video's frame rate is being interpreted incorrectly, for example [22:14:43 CET] <sdds> and -r after the input mean how much fram re-encode? [22:14:47 CET] <alexpigment> like if you know your video is 60fps but ffmpeg thinks it's 30fps, you would specify the frame rate 60 before the input [22:14:48 CET] <sdds> and rest frames drop? [22:14:53 CET] <alexpigment> yes [22:15:17 CET] <sdds> alexpigment: do you know aout stream with ffserver or another way? [22:15:24 CET] <alexpigment> nope [22:15:31 CET] <alexpigment> that's for the more intelligent people around here ;) [22:15:50 CET] <sdds> ok , i want to task 1 more please [22:15:53 CET] <sdds> can you please? [22:16:26 CET] <alexpigment> task or ask? [22:16:30 CET] <sdds> ask [22:16:31 CET] <alexpigment> sure [22:16:33 CET] <sdds> I want mjpeg stream what i want to save for file, what is the diffrent if i save to mjpeg / avi/mp4? [22:17:07 CET] <alexpigment> mjpeg is a compression scheme that is pretty simple; it's like a series of jpegs right after each other [22:17:11 CET] <alexpigment> because of this, it's not very efficient [22:17:24 CET] <klaxa> ffserver has also been dropped from git master :P [22:17:54 CET] <alexpigment> modern codecs like H.264 (which you commonly find in MP4 or MKV files) use compression between multiple frames, so the file sizes are smaller for the same level of compression [22:18:05 CET] <klaxa> if your devices support matroska you can give this a try: https://github.com/klaxa/mkvserver_mk2 [22:18:17 CET] <sdds> kalxa: i dont found another integrity way how to straem with ffmpeg [22:19:41 CET] <sdds> alexpigment: so what it the better file to save mjpeg stream to save on quality but with not much cpu [22:21:57 CET] <alexpigment> sdds: mjpeg should be fairly low on CPU i think [22:22:21 CET] <alexpigment> but you could also use -c:v libx264 -preset ultrafast [22:23:18 CET] <alexpigment> the presets for x264 are usually named after speeds (ultrafast, veryfast, faster, medium, slow, etc), but those are also a reflection of the CPU usage [22:24:09 CET] <alexpigment> given that everything supports h.264 natively, if not at a hardware level, it's good to use it if you can [22:24:27 CET] <sdds> thank you [22:25:17 CET] <sdds> my problem is when i record stream 1920x1080 i see that because i have weak cpu i can re-encode only 2 frames per seconds from 25 [22:28:39 CET] <sdds> klaxa: can you explain me on mkvserver_mk2 please?\ [22:28:47 CET] <alexpigment> sdds: add -preset veryfast [22:28:55 CET] <alexpigment> sorry [22:29:00 CET] <alexpigment> -preset ultrafast [22:29:02 CET] <alexpigment> is what i meant [22:29:18 CET] <sdds> on witch protocols is that support ?rtsp over http? rtsp multi-cast? [22:29:53 CET] <klaxa> mkvserver_mk2 only supports http [22:30:25 CET] <sdds> so how can I stream rtsp multicast with ffmpeg? [22:30:36 CET] <ayum> Hi, I am using ffmpeg read the stream from v4l2 and alsa device, but the v4l2 driver seems exists some bug, sometime the captured frame has no timestamp, to solve this problem, I use "setpts=N/FRAME_RATE/TB" and "asetpts=N/SR/TB" filter drop all timestamps, is it okay? [22:34:54 CET] <b0bby__> what does num:den syntax is deprecated, please use num/den or named options instead? [22:35:00 CET] <b0bby__> mean? [22:35:13 CET] <alexpigment> numerator, denominator [22:35:45 CET] <alexpigment> so if you have some fraction somewhere, use 8/5 instead of 8:5 [22:36:02 CET] <alexpigment> (presumably. it seems pretty obvious that's what it means) [22:39:22 CET] <kepstin> ayum: doing that will probably cause desync between your audio and video [22:40:52 CET] <b0bby__> alexpigment: Thanks! [22:40:54 CET] <ayum> @kepstin, I am using fps filter to change the frame rate, but once ffmpeg captured the frame without timestamp. it will print more than 10000 buffers cached, and memory use out of it soon [22:41:42 CET] <ayum> @kepstin, and once I use setpts filter to drop the timestamp, let ffmpeg create new one. the problem gone. [22:42:28 CET] <kepstin> well, the fps filter using too much memory on large timestamp gaps is a separate bug :/ [22:42:36 CET] Action: kepstin hits that all the time [22:43:11 CET] <alexpigment> i'm not really aware of this issue, and i'm not trying to derail the conversation, but how much memory are we talking about? [22:43:56 CET] <kepstin> depends on the length of the timestamp gap [22:44:06 CET] <kepstin> i've seen it use multiple gigs and trigger the oom killer [22:44:32 CET] <alexpigment> ah, that is a lot [22:44:42 CET] <kepstin> the issue is that the fps filter queues up all of the avframes to fill the timestamp gap at the same time [22:44:48 CET] <alexpigment> is it just storing the intermediate frames in memory as raw data? [22:44:57 CET] <alexpigment> gotcha [22:45:08 CET] <kepstin> the frame data itself is shared, i think, it's just the avframe structures [22:45:20 CET] <kepstin> it needs to be rewritten using the activate callback to generate single frames at a time on request. [22:45:30 CET] <ayum> @kepstin, I seen there is a "framerate" filter, what's the difference between framerate and fps filter? I tested both before, both will use many memory once the timestamp not set [22:45:52 CET] <kepstin> ayum: 'framerate' filter blends frames together to "smoothly" fill in gaps [22:46:04 CET] <kepstin> (it generally doesn't give good results, imo) [22:46:08 CET] <ayum> @kepstin, oh, okay [22:46:59 CET] <ayum> @kepstin, do you have solution for it if the some frame's timestamp not set? instead of use setpts filter? [22:47:25 CET] <kepstin> ayum: the issue you're having probably isn't a not-set timestamp, it's probably a gap in timestamps [22:48:39 CET] <alexpigment> i wonder if genpts before the input would address the problem [22:48:39 CET] <ayum> @kepstin, I added a few av_log() statements to the libavcodec/v4l2.c, it print that the kernel's v4l2 driver returned 0 value in the timestamp structure. [22:49:12 CET] <ayum> genpts? [22:49:41 CET] <alexpigment> ffmpeg -fflags +genpts -i input ... [22:50:01 CET] <alexpigment> honestly, i know very little about when this is needed, but it sounds related to all of this [22:50:12 CET] <ayum> @alexpigment, thanks, I will try it later [22:50:50 CET] <alexpigment> yeah, it's worth trying. i make no guarantees about the validity of the recommendation though ;) [22:51:31 CET] <kepstin> I think using the genpts flag should give basically the same result as the setpts filter [22:51:50 CET] <kepstin> which means loss of a/v sync. [22:52:54 CET] <kepstin> but really, you should be complaining to the kernel devs about v4l giving you bad timestamps, i guess. [22:54:24 CET] <ayum> @kepstin, yes, I will try report this bug to the HDMI capture card's company. [22:54:57 CET] <kepstin> oh, is it not an upstream (open-source kernel) driver? [22:58:52 CET] <ayum> I just tried -fflags +genpts, it seems not works. [22:59:19 CET] <alexpigment> i figured it wouldn't - just wanted to throw that out there in case it was different than what you tried before [23:00:44 CET] <ayum> @kepstin, yes, it's not a open source driver, I have to download the driver source code from the website, compile and install it manually. [23:56:31 CET] <ChocolateArmpits> More of a technical question. Is there any suggested approach when a source doesn't have enough audio samples to fully fit the ntsc cadence pattern? [23:57:30 CET] <therage3> interpolation comes to mind [23:57:44 CET] <alexpigment> hmmm [23:57:52 CET] <therage3> that's used by CD players when they have read errors they can't fix [23:58:08 CET] <alexpigment> few enough samples that it's noticeable but enough that you're mentioning NTSC specifically? [23:58:44 CET] <ChocolateArmpits> alexpigment, well the pattern is 1602,1601,1602,1601,1602 to fit 48kHz audio if you've heard of it [23:59:31 CET] <alexpigment> ah, deeply technical :) [23:59:37 CET] <therage3> is this an Opus file or something? [23:59:45 CET] <therage3> like, why do you have 48kHz? [23:59:48 CET] <ChocolateArmpits> nah, mxf [23:59:57 CET] <alexpigment> 48 is standard for broadcast video [23:59:58 CET] <therage3> ah [00:00:00 CET] --- Tue Jan 23 2018

1 0

ffmpeg-devel.log.20180121
by burek 22 Jan '18

22 Jan '18

[01:13:56 CET] <SortaCore> is there a reason the metadata is stripped if it's set before av_write_header? [01:14:27 CET] <SortaCore> bug or by design 🤔 [01:34:18 CET] <cone-981> ffmpeg 03Gyan Doshi 07master:6c1c6c6c71fc: avfilter/drawtext - implement fix_bounds [01:37:47 CET] <cone-981> ffmpeg 03Mark Thompson 07master:a0c624e29973: avcodec: v4l2_m2m: fix races around freeing data on close [01:37:48 CET] <cone-981> ffmpeg 03Jorge Ramirez-Ortiz 07master:5d5de3eba4c7: avcodec: v4l2_m2m: remove unnecessary timeout. [01:37:49 CET] <cone-981> ffmpeg 03Jorge Ramirez-Ortiz 07master:0b9b7f0b46a8: avcodec: v4l2_m2m: context: fix raising warning on POLLERR [02:03:35 CET] <jkqxz> atomnuker: map_to/from is for mapping individual frames. frames_derive_to/from is for creating new frames contexts on a different device. [02:04:08 CET] <jkqxz> The latter may be needed if there is extra hardware-specific information about the frames context required. [02:04:29 CET] <atomnuker> ah, I see [02:05:15 CET] <atomnuker> I wanted to get vaapi->opencl running so I could see if I could replicate what it does in vulkan but it failed with "Assertion dst->format == AV_PIX_FMT_OPENCL failed at libavutil/hwcontext_opencl.c:2827" [02:06:08 CET] <jkqxz> Frame mapping requires that you have made the derived frames context, but the derivation step only actually does anything in the hwcontext implementation if it needs to. [02:06:08 CET] <atomnuker> -vf 'hwmap=derive_device=opencl,hwmap=derive_device=vaapi:reverse=1,format=vaapi' is my filter line, before the input file I select vaapi device normally as well as vaapi format [02:06:40 CET] <jkqxz> Don't put the reverse there. [02:06:58 CET] <jkqxz> Reverse-hwmap is only for making the destination frames in the sink, which you aren't there. [02:07:29 CET] <atomnuker> same error [02:08:16 CET] <jkqxz> Hmm. Does mapping back and forth work? Try actually doing something in OpenCL? [02:11:41 CET] <jkqxz> Hmm. The second derive has created a new device and therefore barfed. Why did it do that? [02:12:51 CET] <atomnuker> dunno, this was part of an example you posted on the patchset [02:12:54 CET] <jkqxz> Oh, it didn't. I'm misreading the messages. [02:13:14 CET] <atomnuker> tried to put unsharp opencl but got failed to map frame, function not implemented [02:13:24 CET] <atomnuker> (after hwmap opencl) [02:13:27 CET] <jkqxz> It all works if you actually do something in OpenCL. Mapping to another API and back is pointless. [02:14:00 CET] <jkqxz> "./ffmpeg_g -v 55 -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD129 -hwaccel_output_format vaapi -i in.mp4 -an -vf 'hwmap=derive_device=opencl,unsharp_opencl,hwmap=derive_device=vaapi:reverse=1' -c:v h264_vaapi -frames:v 10 out.mp4" [02:17:07 CET] <atomnuker> that works as long as I feed that into a vaapi encoder, any way to skip this? [02:18:27 CET] <atomnuker> got it working, I just put a vaapi_deinterlace filter right after [02:18:28 CET] <jkqxz> 'hwmap=derive_device=opencl,format=opencl,hwmap=derive_device=vaapi' [02:19:13 CET] <jkqxz> works. The filter failed to deduce that the frames between the mappings should have format opencl, so it was mapping vaapi -> vaapi -> vaapi with the OpenCL mapping, hence the error. [02:20:15 CET] <jkqxz> Or libavfilter failed to deduce, because query_formats happened too early to tell. [02:21:11 CET] <jkqxz> Should probably add something to vf_hwmap to spot that case. (It's basically the same problem as hwdownload often needing a format instance after it to tell it the target format.) [02:22:10 CET] <jkqxz> Your needs-encoder case will be the same thing as well. [02:23:01 CET] <jkqxz> Anyway, I should sleep at some point. I'll have another look at Vulkan tomorrow after I deal with the VAAPI filter stuff. [02:23:12 CET] <atomnuker> k, thanks [03:48:52 CET] <cone-981> ffmpeg 03Carl Eugen Hoyos 07master:251f0bcb7be9: lavf/rawdec: Also probe the last byte of mjpeg streams. [04:50:53 CET] <cone-981> ffmpeg 03James Almer 07master:9462b2b82053: avcodec/hevc_ps: add a function to uninitialize parameter set buffers [04:50:54 CET] <cone-981> ffmpeg 03James Almer 07master:1f0cf1b2f4ef: avcodec/hevcdec: use ff_hevc_uninit_parameter_sets() [04:50:55 CET] <cone-981> ffmpeg 03James Almer 07master:2159d4bbc3e6: avcodec/hevc_parser: use ff_hevc_uninit_parameter_sets() [05:19:06 CET] <mistym> Is there a way to access info on whether an AVPacket is a duplicate frame from within a muxer? I noticed the CLI tool visualizing that data, but not sure how to access it. [05:22:47 CET] <mistym> (Context: the format I'm muxing has the ability to skip frames; the header can increment the timebase to indicate skipped frames. [05:27:33 CET] <mistym> And AFAIK the only compatible video codec, Cinepak, will be able to drop duplicated frames in this case because the only thing being written will be two "reuse strip" commands. [06:59:31 CET] <cone-981> ffmpeg 03sfan5 07master:777d6c677b1d: dashdec: Make use of frame rate specified in Representation [06:59:32 CET] <cone-981> ffmpeg 03Brendan McGrath 07master:2472dbc7a770: avformat/hlsenc: Check that data is set [06:59:33 CET] <cone-981> ffmpeg 03Brendan McGrath 07master:1f48c5c0671b: dashdec: Only free url string if being reused [06:59:34 CET] <cone-981> ffmpeg 03Colin NG 07master:8db4ef3e6d93: avformat/dashdec.c: Download dash content with byte range info [06:59:35 CET] <cone-981> ffmpeg 03Colin NG 07master:7a63da891023: libavformat/dashdec: Fix for ticket 6658 (Dash demuxer segfault) [06:59:36 CET] <cone-981> ffmpeg 03Colin NG 07master:78e884f3fb1d: libavformat/dashdec: Fix for ticket 6856 (filename limited to 1024) [14:05:14 CET] <kierank> carl reviews, always so useful [17:34:00 CET] <Chloe> is there an easy way to run fate for several commits? perhaps with git bisect? [17:46:31 CET] <BtbN> make a bisect script that does it [17:47:03 CET] <nevcairiel> you can make a script and use git bisect run, but its usually more effort then doing that manually for the few steps it takes [17:51:15 CET] <BtbN> A generic "do a fate run" script is nice to have though, and it rarely changes [19:05:08 CET] <kierank> michaelni: how do I reproduce this https://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/224375.html [19:05:15 CET] <kierank> and do you know how it could happen [19:11:18 CET] <JEEB> the "only happens with ffplay" thing is quite funky [22:37:26 CET] <cone-320> ffmpeg 03Carl Eugen Hoyos 07master:55bdee7b0726: lavc/svq3: Do not write into memory defined as const. [22:52:53 CET] <cone-320> ffmpeg 03Jorge Ramirez-Ortiz 07master:15a05d2b73c6: MAINTAINERS: add myself for avcodec/v4l2_ [22:52:54 CET] <cone-320> ffmpeg 03Michael Niedermayer 07master:56a53340ed4c: avcodec/truemotion2: Fix integer overflow in TM2_RECALC_BLOCK() [22:53:43 CET] <BtbN> no idea if the new v4l2 maintainer is in here, but he should definitely have a look at what coverity reports about some recent commits [22:54:51 CET] <Compn> probably bring it up on the mailing list ? [00:00:00 CET] --- Mon Jan 22 2018

1 0

ffmpeg.log.20180121
by burek 22 Jan '18

22 Jan '18

[00:04:10 CET] <relaxed> SilenceDogood: maybe, -disposition:a:0 0 -disposition:a:1 default [00:09:13 CET] <SilenceDogood> relaxed doesn't work [00:09:15 CET] <SilenceDogood> :( [00:11:14 CET] <relaxed> does it now list the stream as default? [00:11:28 CET] <relaxed> pastebin the command and output [00:14:33 CET] <SilenceDogood> ffmpeg -i oz.mkv -f concat -i floyd-loop.txt -map 0:v -map 1:a -map 0:a -c:v copy -c:a:0 aac -c:a:1 copy -shortest -metadata:s:v:0 stereo_mode=1 -metadata:s:a:0 language=eng -metadata:s:a:0 title="Pink Floyd: The Dark Side of the Moon Immersion Edition (2011) 5.1 Surround Mix" -metadata:s:a:1 title="The Wizard of Oz 3D (2013) 5.1 Surround Mix" -metadata title="The Dark Side of Oz 3D" -disposition:a:0 default -disposition:a:1 0 - [00:14:40 CET] <SilenceDogood> That's the command [00:15:14 CET] <SilenceDogood> VLC opens with the Wizard of Oz video default [00:15:28 CET] <SilenceDogood> I meant audio [00:15:36 CET] <SilenceDogood> VLC opens with the Wizard of Oz audio by default [00:15:45 CET] <SilenceDogood> However, MPV opens with the Pink Floyd audio by default like it's supposed to. [00:16:35 CET] <relaxed> that's becuase mpv is a much better player [00:17:05 CET] <relaxed> *because [00:17:22 CET] <SilenceDogood> OK [00:17:27 CET] <SilenceDogood> now what about subtitles [00:17:40 CET] <SilenceDogood> I want it to come with the subtitles from the Wizard of Oz 3D blu ray [00:18:44 CET] <SilenceDogood> They come out as SUB files from mkvtoolnix [00:19:02 CET] <SilenceDogood> but when I try to name them filename.English.sub, they don't show up [00:20:19 CET] <SilenceDogood> I'm probably encountering the same problem as this guy https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=17&t=4846 [00:23:44 CET] <relaxed> add -i subtitles.sub and after all the inputs -disposition:s:0 default [00:25:48 CET] <relaxed> oh, and -c:s copy [00:35:24 CET] <SilenceDogood> relaxed, no, that doesn't work. this was discussed earlier in the channel [00:36:02 CET] <SilenceDogood> ffmpeg has some kind of bug where it only supports certain kinds of subtitles [00:36:20 CET] <SilenceDogood> if you try to direct copy subtitle streams which ffmpeg doesn't support, it screws up the audio [00:36:30 CET] <JEEB> uhh I don't know how you read into that [00:36:41 CET] <JEEB> I told you that it might be broken input, or a bug in FFmpeg [00:36:52 CET] <JEEB> the format itself was supported just fine [00:38:03 CET] <manuelg> I've tried to make a 2x2 mosaic here, anyone know what I've done wrong? https://imgur.com/a/rzGFb [00:38:13 CET] <SilenceDogood> JEEB, well I know the input's fine [00:38:26 CET] <JEEB> no you don't [00:38:28 CET] <SilenceDogood> or at least as much as I can know, since you haven't specified any way to test for errors [00:38:46 CET] <SilenceDogood> I can watch the movie with subtitles in oz.mkv and they show up fine. [00:39:25 CET] <manuelg> ffmpeg command I used: https://pastebin.com/K7t6qQQ1 [00:39:33 CET] <JEEB> you can check the timestamps of packets in a track with mkvinfo (for matroska) or ffprobe -show_packets -show_streams -show_format -of json FILE [00:39:39 CET] <JEEB> if you really want to start going into that [00:39:52 CET] <JEEB> but I guessed you are just not interested in actually looking at if everything else is just ignoring broken data [00:39:57 CET] <JEEB> or if it's a bug in FFmpeg [00:40:39 CET] <JEEB> also if you have a relevant sample (can be just the subtitles) then please just report a bug with the sample; in the worst case you will just get told that your sample is broken [00:40:53 CET] <SilenceDogood> OK I want to look into that [00:41:06 CET] <SilenceDogood> But I got no errors going from MakeMKV to BD3D2MK3D to that mkv [00:41:12 CET] <JEEB> well d'uh [00:41:44 CET] <JEEB> the latter could just fine be ignoring those things and makemkv of course wouldn't be noting anything if for it it's "everything as usual" [00:42:03 CET] <JEEB> but at this point without any extra info it can be either a broken sample or a bug, that one I'm not going one way or another [00:42:39 CET] <JEEB> thus if you don't want or cannot look into it further you can use something to separate just the subtitle track, and then check if the same thing happens with the separated subtitle track as well [00:42:50 CET] <JEEB> (or if you want you can just cut the first 100MiB of your mkv or something) [00:43:02 CET] <JEEB> as long as it has enough data to make the issue happen [00:43:22 CET] <SilenceDogood> JEEB OK. Where would I send the data? [00:44:23 CET] <JEEB> there's an FTP for that stuff IIRC, but I never remember the credentials to it :P so in my opinion you could just upload the sample somewhere sane (doesn't require registration or multiple hoops or contain malware) [00:44:32 CET] <JEEB> and then link that over at the issue tracker (trac.ffmpeg.org) [00:44:35 CET] <SilenceDogood> OK [00:45:28 CET] <SilenceDogood> I will do that soon, thank you. [00:45:33 CET] <manuelg> JEEB are you able to take a look at my issue? i would appreciate the help :) [00:46:07 CET] <SilenceDogood> OK I've gotta go do other stuff. Thanks JEEB, furq, everyone who helped. :) [00:47:46 CET] <furq> manuelg: use hstack and vstack [00:49:04 CET] <furq> [0:v][1:v]vstack[l];[2:v][3:v]vstack[r];[l][r]hstack[out] [00:49:14 CET] <furq> you'll probably need to setpts them all separately before that [00:49:31 CET] <manuelg> do you need to setpts if they're mjpegs? [00:49:39 CET] <furq> that has nothing to do with it [00:49:43 CET] <manuelg> i'm not sure i understand what i'm actually doing haha [00:49:50 CET] <furq> but if these are network streams then the pts values will probably be desynced [00:50:02 CET] <manuelg> okay [00:50:06 CET] <manuelg> I'll try h/vstack [00:50:08 CET] <furq> i mean you can try it without that and see if it works [00:50:31 CET] <manuelg> i'll give it a try [00:50:39 CET] <furq> nullsrc[n];[0:v][1:v]vstack[l];[2:v][n]vstack[r];[l][r]hstack[out] [00:50:48 CET] <furq> i didn't notice you only actually have three inputs [00:50:58 CET] <manuelg> Yeah [00:51:07 CET] <manuelg> Oh wait [00:51:14 CET] <manuelg> I had a filter turned on in VLC [00:51:49 CET] <manuelg> okay - the file renders fine... but I get "stream number does not match registered feed" on ffserver [00:52:04 CET] <furq> oh, ffserver [00:52:12 CET] <furq> good luck getting help with that, it's basically unsupported at this point [00:52:22 CET] <furq> and it's actually been removed from 3.4 onwards iirc [00:52:28 CET] <manuelg> ah. [00:52:33 CET] <manuelg> is there any replacement? [00:52:41 CET] <furq> not in ffmpeg [00:52:52 CET] <relaxed> ffmpeg can stream, correct? [00:52:55 CET] <JEEB> there are various media servers that handle actual streaming, like nginx-rtmp [00:52:56 CET] <furq> if you just need any streaming server then most people in here are using nginx-rtmp for that now [00:53:06 CET] <furq> if you specifically need rtsp or something then i wouldn't know what to recommend [00:53:07 CET] <JEEB> FFmpeg can feed streaming servers or output UDP streams etc [00:53:30 CET] <manuelg> i haven't got any need for a specific protocol, just something that vlc can play really [00:53:37 CET] <furq> yeah nginx-rtmp will do a fine job then [00:53:48 CET] <manuelg> i'll have a look at nginx [00:53:53 CET] <manuelg> thank you! [00:54:00 CET] <furq> the rtmp module isn't builtin so you'll need to build nginx yourself [00:54:06 CET] <furq> it's not too difficult though [00:54:27 CET] <manuelg> damn, there's not just a nice package I can install? [00:54:36 CET] <furq> unless they finally got the dynamic module thing figured out [01:08:56 CET] <relaxed> manuelg: is this only for your local network? [01:10:21 CET] <manuelg> Yeah [01:11:12 CET] <relaxed> oh! then write a script that uses mpv to play the streams [01:12:13 CET] <relaxed> it can use ffmpeg's filters too, so you can achieve the same thing [01:12:21 CET] <manuelg> sadly i cant install mpv on the clients [01:13:20 CET] <manuelg> my plan is to just distribute a single link to those that need it, to enter into vlc [01:13:41 CET] <furq> yeah if this is for multiple users then you'll need a server [01:13:52 CET] <manuelg> it is on a server [01:14:11 CET] <furq> i meant a streaming server [01:14:16 CET] <furq> ffmpeg itself is very unsuitable for that [01:14:22 CET] <relaxed> streaming rtp wouldn't work? [01:14:41 CET] <furq> can that server multiple clients [01:14:43 CET] <furq> serve [01:14:55 CET] <relaxed> good question, I don't know [01:14:59 CET] <furq> all of ffmpeg's server stuff will only serve one client afaik [01:15:06 CET] <furq> and then kill the process when they disconnect [01:15:39 CET] <manuelg> ffserver seemed to do it, although if its unsupported I'd rather not use it [01:16:20 CET] <relaxed> ffmpeg + nginx-rtmp is probably the way to go [04:05:15 CET] <hiihiii> hello [04:05:25 CET] <hiihiii> is any one here on a windows machine [04:06:40 CET] <hiihiii> I'm trying to setup ffmpeg to be a invoked as an encoder in programs screen capturing programs like hypercam and whatnot [04:07:24 CET] <hiihiii> I'm aware that ffmpeg on itself can capture desktop [04:07:48 CET] <hiihiii> but I'm wondering if I can do it the other way that would be better [04:08:23 CET] <BtbN> Just use OBS? [04:09:05 CET] <hiihiii> I'm sorry I didn't want to make the question longer but I think I might need to [04:09:35 CET] <BtbN> There is absolutely no reason to deal with hypercam and stuff, OBS does it better and is free [04:12:05 CET] <hiihiii> what I really wan't is to be able to invoke ffmpeg as an encoder from within another program similarly to "ffdshow VFW", "Xvid", "x264 VFW", etc on OBS and Heypercam [04:13:02 CET] <hiihiii> I have an simulator in which I need to capture the output without frame loss and with 60fps [04:13:40 CET] <BtbN> OBS uses ffmpeg/x264 as a library. It does not invoke a commandline utility. [04:14:09 CET] <hiihiii> oh, can you configure it with a command line? [04:14:16 CET] <BtbN> what? [04:14:34 CET] <hiihiii> I mean can it axcept additional options/filters in its gui [04:14:54 CET] <BtbN> to some very limited degree [04:15:07 CET] <BtbN> it does not mimic full ffmpeg.c [04:15:11 CET] <hiihiii> so can I set something like -vsync 1 [04:15:45 CET] <hiihiii> anyway OBS is not an option because I can't use that with the simulator [04:16:01 CET] <BtbN> why not? It can capture pretty much everything [04:16:27 CET] <hiihiii> but it runs as a separate process [04:17:28 CET] <hiihiii> the simulator has that window which lets you pick an encoder and that runs hand in hand with the simulator [04:17:33 CET] <c3r1c3-Win> Why is that an issue? (Also wouldn't ffmpeg run as a separarte process as well?) [04:18:04 CET] <c3r1c3-Win> Hmm...interesting. [04:20:16 CET] <hiihiii> i.e. the simulator outputs the result as frame(image) then waits for the encoder to do its thing before rendering the next frame [04:20:49 CET] <hiihiii> I can't run the simulator and a screen capturing program separately [04:21:20 CET] <hiihiii> but I also don't get quite the results that I wan't from the video output I get [04:21:33 CET] <hiihiii> they are 59.18fps [04:21:51 CET] <hiihiii> and I'm not sure how many frame were duplicated or dropped [04:23:08 CET] <hiihiii> and these encoders are old with not much options [04:37:48 CET] <hiihiii> in other words can I list ffmpeg as one of windows' encoders in the "video compression" window drop list https://i.imgur.com/GoZl5rf.png [04:39:15 CET] <hiihiii> when you click configure you get to set other stuff https://i.imgur.com/CfuV11N.png [06:21:34 CET] <Fyr> guys, is it possible to sort metadata? I see title, NUMBER_OF_FRAMES, BPS etc. I want: title, DURATION, NUMBER_OF_FRAMES, NUMBER_OF_BYTES etc. [07:08:30 CET] <ddubya> has cuda, nvenc, opencl been dropped, I don't see the options anymore in ./configure [07:10:58 CET] <ddubya> nvm wrong branch doh [07:47:01 CET] <Sean5512> Hello wondering if anybody can help me with a quick newbie question re: ffmpeg and homebrew. I need to reinstall ffmpeg with ssl support. I was told to use "brew reinstall ffmpeg --with-openssl" but does this erase all of my other settings? [08:10:50 CET] <Fyr> JEEB, long time ago you showed a snippet in which you added too much options to FFMPEG. were you using bash? [08:11:37 CET] <Fyr> I need FFMPEG to process >8192 characters and I'm stuck in Windows CMD/PowerShell command line limit. [08:11:44 CET] <Fyr> sometimes it expands, though. [08:12:23 CET] <Fyr> I tried ffmpeg $(Get-Content parameters.txt) [08:12:55 CET] <Fyr> it works, only returns fucked up codepage. [09:30:39 CET] <garyserj> why does this ffmpeg -ss 192 -i inputfile.mp4 -c copy -t 1 output3.mp4 <-- creates a file that is 6 seconds long! [09:32:30 CET] <furq> garyserj: -c copy cuts the video stream at the closest keyframes [09:33:14 CET] <garyserj> it's a video of a sports game.. there are lots of frames a second! [09:37:09 CET] <garyserj> I guess maybe I don't understand the difference between frames and keyframes? [11:13:28 CET] <cousin_luigi> Greetings. [11:13:40 CET] <cousin_luigi> What are the plans for the next release? [11:15:13 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/Changelog#L4 [11:15:48 CET] <cousin_luigi> I'll rephrase the question: what are the blockers for 3.5 ? [13:06:58 CET] <foo> If I want to get the highest quality audio from a video, in mono, is this what I want? ffmpeg -i native.mp4 -ac 1 mono.flac [13:25:17 CET] <BtbN> Just use -c copy [13:25:26 CET] <BtbN> There is no point in re-encoding lossy audio as something lossless [13:25:32 CET] <BtbN> the lost information won't come bac [13:25:35 CET] <BtbN> k [13:27:26 CET] <furq> i don't think that works if you want to downmix to mono [13:29:36 CET] <foo> hmm, throws Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument with ffmpeg -i native.mp4 -c copy -ac 1 mono.flac [13:29:46 CET] <foo> BtbN / furq - thanks for chiming in :) [13:32:45 CET] <BtbN> Why downmix to mono though? If you re-encode mono to flac it's most likely going to end up WAY bigger than the original stereo or whatever [13:33:07 CET] <BtbN> So just keeping the original encode and letting the player downmix to mono if it needs to is still better [13:33:11 CET] <foo> BtbN: The API I'm passing this to requires mono :( [14:08:23 CET] <Fyr> guys, when muxing with MKVToolnix, it adds so much metadata, like BPS, NUMBER_OF_FRAMES etc. what are they for? [14:08:51 CET] <Fyr> I don't know which players use those data. [14:09:05 CET] <JEEB> that's a really good question, since as it's just metadata you can't really trust it [14:09:21 CET] <JEEB> for frames you can just parse the clusters [14:09:37 CET] <Fyr> yes, moreover, this toolset can't find the right data. [14:10:00 CET] <Fyr> MKVToolnix doesn't set the right FPS for VC-1. [14:10:34 CET] <JEEB> do remember that currently matroska can't handle a lot of frame rates (such as the /1001 ones) exactly [14:10:35 CET] <Fyr> it sets it to 24 .05, while it's really 24000/1001. =) [14:10:49 CET] <JEEB> but yes, as it should be the average 24.05 sounds weird [14:11:08 CET] <JEEB> not that I know how mkvtoolnix calculates it [14:11:17 CET] <JEEB> effectively everything sane ignores that metadata [14:11:27 CET] <JEEB> at most passing it through "because it's metadata" [14:11:31 CET] <JEEB> (as metadata) [14:15:34 CET] <JEEB> I hear people are finally adding a fractional number type into matroska which would fix the /1001 stuff I'd say [14:24:49 CET] <Fyr> can FFMPEG make use of chapters in xml? [14:25:19 CET] <JEEB> nope [14:25:30 CET] <Fyr> =( [14:25:30 CET] <Fyr> the toolnix keep the chapters in this format, it would be wonderful if FFMPEG can reading when muxing. [14:25:51 CET] <JEEB> I mean, the first XML parser usage in FFmpeg was added with the DASH "demuxer" some time ago :P XML parsing in general tends to be messy so people generally keep away from it [14:26:16 CET] <JEEB> but sure, if someone puts in a patch for ffmpeg.c implementing that it might get accepted [14:26:33 CET] <JEEB> the matroska specifics in there are a thing, though [14:26:49 CET] <JEEB> since it's actually the virtual timeline that can have segment links etc [14:28:42 CET] <Fyr> JEEB, do you have Linux on your workstation? [14:29:07 CET] <Fyr> I was stuck in 8192-characters limit on Windows. [14:29:16 CET] <JEEB> at home I use windows and then use a linux vm for development purposes [14:29:38 CET] <Fyr> I had to install a Linux onto VM to mux a file. [14:30:09 CET] <Fyr> can FFMPEG read parameters from a file? [14:30:17 CET] <JEEB> ffmpeg.c you mean [14:30:24 CET] <Fyr> =( [14:30:27 CET] <JEEB> dunno :P [14:30:30 CET] <JEEB> probably not [14:30:52 CET] <JEEB> anyways, this seems to be the limit you're hitting https://support.microsoft.com/en-us/help/830473/command-prompt-cmd--exe-com… [14:31:01 CET] <Fyr> yes [14:32:04 CET] <Fyr> using PowerShell I can add ininite options, however, it doesn't fully support UTF-8. [16:17:08 CET] <OneSploit> I am trying to recompile ffmpeg with the same parameters as Debian had, plus enabled nvenc but I get error ERROR: libiec61883 not found [16:17:16 CET] <OneSploit> though libiec61...dev is installed [16:17:18 CET] <OneSploit> any help? [16:18:57 CET] <JEEB> see ffbuild/config.log [16:19:11 CET] <OneSploit> nvm error message was not correct config.log pointed the missing library [16:19:18 CET] <OneSploit> JEEB: yes, thanks :) [16:22:33 CET] <b0bby__> hello [16:23:26 CET] <b0bby__> I have a complex filter that does some stuff with a video and and image(no audio stuff) but I need to map the audio stream from input 1 to my output. How should I do this?? [16:24:37 CET] <OneSploit> JEEB: test.c:(.text+0x151d): undefined reference to `cvRound' [16:24:40 CET] <OneSploit> opencv fails [16:24:52 CET] <OneSploit> I wonder maybe some version mismatch [16:25:03 CET] <JEEB> yes, newer opencv versions broke C support IIRC [16:25:26 CET] <JEEB> not sure if debian patched something to get through that, or just disabled opencv? [16:26:12 CET] <OneSploit> ah I downloaded from git, but you are right I should download the source with Debian patches and just add extra flags there [16:27:15 CET] <JEEB> but yea, officially opencv just said that they only support C++ now so C API clients like FFmpeg just broke with new enough versions [16:28:19 CET] <OneSploit> I just want Nvidia acceleration to stream desktop with ffmpeg [16:28:32 CET] <OneSploit> suprisingly it seems like something not standard [16:29:08 CET] <JEEB> if you don't need f.ex. opencv I think it's OK to just disable it :P [16:29:19 CET] <OneSploit> f.ex ? [16:29:26 CET] <JEEB> after all, you don't need to replace the kitchen sink FFmpeg binaries [16:29:35 CET] <JEEB> esp. if you're using the command line thing only [16:29:48 CET] <OneSploit> I am using simple screen recorder [16:30:04 CET] <OneSploit> with optirun to preload optimus nvidia 960M [16:30:24 CET] <OneSploit> if that makes sense to you... [16:33:53 CET] <OneSploit> seems to be compiling.. will see [16:35:17 CET] <sfan5> I'd suggest just using OBS [16:48:25 CET] <OneSploit> dunno if OBS has short keys to start recording and what is worst it crashes at every possible step [16:49:48 CET] <OneSploit> sfan5: its not build for Debian packages, so probably has some issues no one wanted to package it... I usually stay away from software that cannot be packaged.. [16:52:10 CET] <sfan5> I wouldn't assume that just from the fact that there's no debian package [16:53:06 CET] <OneSploit> sfan5: I build it and tried it [16:53:15 CET] <sfan5> besides, there's a PPA for ubuntu; by using debian you're limiting yourself quite severely [16:53:27 CET] <OneSploit> sfan5: worst experience I ever had so far with open software [16:54:11 CET] <sfan5> let me guess: it required a newer FFmpeg version, which is absolute hell to get working on debian? [16:54:29 CET] <therage3> the thing with Debian and its package repos for the stable branch is that everything is woefully outdated [16:54:33 CET] <OneSploit> sfan5: dunno, it was just crashing when I tried to click wizard or properties [16:54:44 CET] <therage3> that's why I don't use that distro for non-server scenarios [16:55:02 CET] <OneSploit> therage3: I am using sid since 1996, no reason to switch to other distro beause some people opinion online [16:55:10 CET] <Fyr> guys, I'm trying to extract chapters with: [16:55:10 CET] <Fyr> $ ffmpeg -i video.mkv -f ffmetadata metadata.txt [16:55:10 CET] <Fyr> I get: [16:55:10 CET] <Fyr> >>Output file is empty, nothing was encoded [16:55:18 CET] <Fyr> how to extract the metadata? [16:55:34 CET] <sfan5> Fyr: use mkvextract for that, much simpler [16:55:50 CET] <JEEB> yea, but ffmpeg.c doesn't take that in :P [16:55:57 CET] <sfan5> right [16:55:59 CET] <JEEB> wow, didn't even know that ffmetadata was a thing [16:56:02 CET] <JEEB> rip [16:56:11 CET] <sfan5> what I'd do in this case is write a python script to convert the XML to something else [16:56:11 CET] <therage3> well, you can see how well it's going for you, OneSploit. I'm just saying, the issue you're having could be due to what I pointed out [16:56:24 CET] <JEEB> well he's on sid at least [16:56:28 CET] <JEEB> which is the rolling part [16:56:34 CET] <OneSploit> openvc was too new [16:56:49 CET] <therage3> still nowhere near as updated as other rolling releases like Fedora rawhide or Arch-based distros [16:56:55 CET] <OneSploit> therage3: OBS wasnt' crashing because ffmpeg [16:56:57 CET] <OneSploit> it was GUI crashing [16:57:09 CET] <JEEB> yea, opencv just decided they'd drop all of the C API clients [16:57:12 CET] <therage3> same diff, something else which needed a newer version, perhaps [16:57:24 CET] <therage3> who knows. I'd run it in CLI and see what error it reports [16:57:26 CET] <JEEB> and not like anyone maintains the opencv stack in FFmpeg anyways [16:57:28 CET] <therage3> that helps to debug that [16:57:46 CET] <JEEB> (some student got the filters in and that's pretty much the end of it) [16:58:15 CET] <OneSploit> my ffmpeg is still compiling [16:58:19 CET] <OneSploit> will see how it works [16:58:27 CET] <therage3> hm [16:58:28 CET] <OneSploit> just trying to have this nvidia part enabled [16:59:20 CET] <JEEB> Fyr: but yea no idea about how that thing works or why it told you it had no metadata in the input :P enable -v verbose or so and start checking the logging? [16:59:32 CET] <Fyr> ok [17:01:58 CET] <OneSploit> therage3: I came here to get help on compiling ffmpeg and not advices which distro is better ;-) [17:02:46 CET] <therage3> i'm not telling you which distro is better, i told what could be the root cause of the issue and how to debug your problem. [17:02:55 CET] <therage3> Use whatever distro you want. [17:11:27 CET] <OneSploit> JEEB: it compiled with these options with debian patches ! :) [17:11:29 CET] <OneSploit> and works :) [17:31:41 CET] <bburky> If I am using an image sequence as input, is there any way I can specify a different crop per frame? [17:33:08 CET] <bburky> Or the same thing I thing: can I specify frame numbers in a filter? [17:35:46 CET] <OneSploit> sfan5: h264_nvenc also works just fine with simplescreenrecorder, and that software is at least not crashing in GUI [17:36:03 CET] <OneSploit> sfan5: I recommend to use it, its really good, much better than OBS [17:36:14 CET] <sfan5> lmao [17:37:27 CET] <sfan5> you don't even seem to know what OBS does beyond "screen recording", yet you are convinced that some random application is better [17:40:50 CET] <OneSploit> sfan5: you should try it out, maybe it's not brewing coffe, but at least it's not crashing and does this simple thing its intended to do, screen recording and screen casting [17:41:07 CET] <OneSploit> or simply, it just works :) [17:51:42 CET] <skyfmww> Hello all. Anyone can help with streaming mosaic from 3 ip cameras to youtube? [17:59:22 CET] <DHE> ffmpeg -i input1 -i input2 -i input3 -filter_complex "[0:v][1:v][2:v]hstack[outvideo]" -map [outvideo] (codec_options) (youtube_output) [18:35:01 CET] <bburky> Also, is there any chance image metadata is accessible in from a filter? [18:36:34 CET] <skyfmww> Thanks for reply. Found that example already but can't manage to put it all together with all that parameters I have for input streams. IPCs have 640x382 on substream while its being detected as 640x360 on ffmpeg/probe that shows garbage in resulting frame [18:42:47 CET] <skyfmww> This string seems to be working for 1 channel (there's issues YT reporting about stream quality) ffmpeg.exe -f lavfi -i anullsrc -rtsp_transport tcp -i rtsp://stream -t 1:00:00 -pix_fmt yuv420p -profile:v baseline -s 640x386 -bufsize 2048k -vb 500k -maxrate 1000k -deinterlace -c:v libx264 -c:a aac -strict experimental -f flv rtmp://a.rtmp.youtube.com/live2/KEY [19:23:42 CET] <stsbqm> x265 "preset" behaves differently than described and expected. [19:24:01 CET] <stsbqm> Until now, I assumed that the Preset option did not change the quality of the result in conjunction with CRF. [19:24:12 CET] <stsbqm> Only the file size should increase due to reduced compression. [19:24:20 CET] <JEEB> that's not true for either x264 or x265 [19:24:36 CET] <JEEB> because the presets can change how the encoder "sees" the input [19:24:46 CET] <JEEB> due to enabling/disabling things as well as changing algorithms [19:25:01 CET] <JEEB> so you never got the same quality with the same CRF value across presets [19:25:13 CET] <ddubya> when encoding audio, is it necessary to pad the end with zeros out to a full frame to avoid losing any samples at the end [19:26:01 CET] <JEEB> audio encoders tend to only take audio frames of a certain sample count [19:26:09 CET] <JEEB> and bark at you if you push in more or less [19:26:21 CET] <ddubya> even at end of stream? [19:26:33 CET] <JEEB> well, any non-null avframe :P [19:26:38 CET] <JEEB> which you push into an encoder [19:26:52 CET] <ddubya> ok [19:27:32 CET] <louisc> I'm trying to stream a cropped section of my screen to an rtmp server using ffmpeg. I've adapted a command I found on the "EncodingForStreamingSites" examples on the ffmpeg wiki, but when I run it, ffmpeg says video filters cannot be applied to input url: https://pastebin.com/nWX173qe [19:28:20 CET] <JEEB> louisc: your -vf option ends up being applied to the second input because you have an -i INPUT after it [19:28:52 CET] <JEEB> you should first define all inputs and then give parameters for the first output, and then the output path/url [19:30:41 CET] <stsbqm> JEEB: But the deviations are considerable and behave exactly the opposite. See also https://trac.ffmpeg.org/wiki/Encode/H.265 "& The visual quality will be the same." [19:30:57 CET] <JEEB> that's bullshit then [19:31:01 CET] <JEEB> it was never true [19:31:23 CET] <louisc> JEEB: so the order should be like, input 1, input 2, vf 1, vf 2, output? [19:31:23 CET] <JEEB> same CRF with different presets never gave same visual output nor did it ever promise to do that [19:31:49 CET] <JEEB> louisc: you can only have one -vf if I recall correctly [19:32:02 CET] <JEEB> do you only want to apply filtering to specific streams? [19:32:48 CET] <louisc> I think the -vf on the first line is to crop the screen capture, and the -vf on the third line is to format the libx264 output? [19:33:00 CET] <JEEB> uhh [19:33:10 CET] <JEEB> do you only have one video input? [19:33:17 CET] <JEEB> or is the other one video as well? [19:33:23 CET] <JEEB> do you want to apply the filters to both? [19:34:13 CET] <JEEB> if you only have a single video input then you can get through with a single vf chain [19:34:29 CET] <JEEB> -vf "crop=400:400:0:0,format=yuv420p" [19:34:47 CET] <louisc> JEEB: -f avfoundation -i "1:1" is my screen and my microphone. the first -vf is for cropping the screen input to a 400x400 box. but yeah, I've kind of just mashed two different scripts together. so now what you're saying makes sense [19:34:51 CET] <louisc> I can only do one -vf [19:36:43 CET] <louisc> maybe it's the "-i :0.0+0,0" thing that's throwing it off. I'm not actually sure what that is [19:37:30 CET] <JEEB> all I see is that you have two inputs there and I was asking if you had a single video input or multiple [19:37:42 CET] <JEEB> and if you had multiple if you needed to filter only one of them or all of them [19:37:51 CET] <JEEB> because -vf would apply the video filter to all selected video tracks [19:38:09 CET] <louisc> JEEB: only wanting a single video input, the screen capture from avfoundation [19:38:29 CET] <JEEB> ok, then the -vf I posted back there with both crop and the yuv420p'ification should work :P [19:39:15 CET] <Fyr> guys, ffmpeg ignores metadata from the metadata file. [19:39:15 CET] <Fyr> https://pastebin.com/Zawy6TvU [19:39:15 CET] <Fyr> how do I to make him not to? [19:40:00 CET] <JEEB> didn't you have to specify what to apply -map_metadata to ? [19:40:41 CET] <Fyr> JEEB, I gave the link to the -report log. [19:41:09 CET] <JEEB> -map_metadata[:metadata_spec_out] infile[:metadata_spec_in] (output,per-metadata) [19:41:31 CET] <Fyr> JEEB, what options should I set? [19:41:34 CET] <JEEB> Fyr: I looked at that but I'm just not sure if that's how it worked [19:41:50 CET] <JEEB> I've once used that option so don't expect me to remember every little thing in ffmpeg.c by heart :P [19:41:53 CET] <Fyr> I used the options like in the example from the ofical help. [19:42:03 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html [19:42:05 CET] <JEEB> has some examples [19:42:29 CET] <JEEB> too bad it has no link to the option so I can't link straight to it [19:44:02 CET] <JEEB> also wasn't map_chapters a separate thing from map_metadata? at least it's the next thing in help [19:44:15 CET] <JEEB> although as I noted I'm not even sure if you're setting the parameters right to map_metadata [19:44:28 CET] <JEEB> since I remember it had some funkiness [19:44:37 CET] <JEEB> regarding which is the input and which is the output [20:10:06 CET] <GyrosGeier> hi [20:10:14 CET] <GyrosGeier> I have a stream dump off a DVD [20:10:31 CET] <GyrosGeier> now I'd like to encode this with a better codec to get better compression [20:10:43 CET] <GyrosGeier> default settings are useless [20:11:21 CET] <GyrosGeier> My first thought is to leave the interlacing, and the manual mentions -ilme, but the version in Debian complains about that option [20:24:22 CET] <furq> GyrosGeier: what do you mean by default settings [20:26:35 CET] <furq> if you just mean ffmpeg -i foo.mkv bar.mkv then that doesn't do any deinterlacing at all [20:26:55 CET] <GyrosGeier> yes, and it encodes to ~800kbps [20:27:18 CET] <furq> well yeah you're going to want to set -crf and -preset [20:27:19 CET] <GyrosGeier> which doesn't resolve anything finer than a macroblock [20:28:40 CET] <GyrosGeier> hmm [20:29:02 CET] <GyrosGeier> what's a sensible preset for 720x480 NTSC? [20:35:36 CET] <stockstandard> Can anyone in here please help diagnose a problem with ffmpeg? I am trying to set "-preset, ultrafast" but getting the following error: Codec AVOption preset (Configuration preset) specified for input file #0 (/library/Movies/Harry Potter and the Chamber of Secrets (2002)/Harry Potter and the Chamber of Secrets (2002) Bluray-2160p.mkv) is not a decoding option. [20:36:14 CET] <c_14> put -preset after the input video [20:36:19 CET] <c_14> (and before the output video) [20:36:28 CET] <c_14> options go before the things they affect [20:36:39 CET] <stockstandard> Am using the following script: https://github.com/mdhiggins/sickbeard_mp4_automator/blob/master/README.md with the following command "python /sickbeard_mp4_automator/manual.py -i "/library/Movies/Baywatch (2017)" -a;" [21:22:35 CET] <Cu5tosLimen> hi [21:22:51 CET] <Cu5tosLimen> I want to cut multiple parts from video [21:22:53 CET] <ddubya> aac has CODEC_CAP_SMALL_LAST_FRAME and yet truncates my file [21:22:54 CET] <Cu5tosLimen> with timecodes [21:23:10 CET] <Cu5tosLimen> like from 1:00 to 2:00 and then 2:30 to 3:00 etc [21:23:40 CET] <JEEB> ddubya: have you gotten everything from the encoder? [21:23:51 CET] <JEEB> the encoder might still be buffering data [21:24:55 CET] <ddubya> JEEP, yeah, I'm submitting a small last frame and then flushing with null frame [21:26:03 CET] <JEEB> have you then called the receive function until it says it has no more data around? [21:26:12 CET] <JEEB> (I hope you are using the push/pull API) [21:28:31 CET] <ddubya> JEEB, not my code... I'm figuring it out. I think I see their mistake now [21:29:49 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [21:29:50 CET] <ddubya> nvm still at a lost :-P [21:30:14 CET] <JEEB> this is the base documentation on the "new" (not really new at this point) dec/enc API grouping [21:33:56 CET] <therage3> Is Lavf some form of encoder ffmpeg uses? [21:34:46 CET] <ddubya> argh I send a full frame and still the truncation [21:35:11 CET] <ddubya> maybe not flushing right [21:37:16 CET] <furq> therage3: libavformat [21:37:28 CET] <furq> if you're asking why that's in the tool metadata in mkvs [21:37:48 CET] <therage3> That's why I asked, because I didn't use any encoder of that name [21:37:51 CET] <therage3> Yet that's in the metadata [21:37:56 CET] <therage3> I was massively confused [22:45:12 CET] <ddubya> if a codec as CODEC_CAP_SMALL_LAST_FRAME will it always also have CODEC_CAP_VARIABLE_FRAME_SIZE [22:45:32 CET] <ddubya> it seems to me one has nothing to do with the other [23:10:40 CET] <garyserj> One crazily case is this one $ffmpeg -ss 191 -i vid.mp4 -c copy -t 6 someoutput2.mp4<ENTER> produces a file that is 10s 403ms. Even though I specified 6 seconds. So it is just over 4 seconds too long! It is almost 50% longer than I specified. Why? And what can I do about it? [23:12:53 CET] <ddubya> transcode it. Your start or end time doesn't fall on an I-Frame so you get the nearest one, which can be quite far away from the desired location [23:13:20 CET] <ddubya> -c copy is your problem [23:15:11 CET] <ddubya> any codec with interframe compression is going to have that issue [23:15:55 CET] <s``> Hi! Do you know what can cause if a h264 mp4 video isnt playing well on chromium or ios? It is good on vlc and firefox. here is it: http://irl.hu/dl/out.mp4 [23:16:38 CET] <mooyoul> Hello guys!\ [23:17:29 CET] <garyserj> ddubya: That mp4 is AVC/AAC. What codec vcodec and acodec should I change it to? [23:17:31 CET] <ddubya> s``, nice cat video. Try disabling B-frames [23:17:46 CET] <mooyoul> I have an question about re-encoding segmented audio [23:18:44 CET] <mooyoul> I have about 3 minutes 30 seconds video, i segmented an audio with 'segment' muxer with segment_time 5 option. [23:18:51 CET] <ddubya> garyserj, I'm no expert but there should be some I-frames only AVC profile for you [23:19:41 CET] <mooyoul> if i concat segmented audio without re-encoding them, it plays without hearing "gap" (or "silence") [23:20:10 CET] <ddubya> garyserj, if you are willing to transcode the outpu t(don't use -c copy) it doesn't really matter what codec you use [23:20:24 CET] <mooyoul> but if i re-encode these segments and concat re-encoded audios, i can hear "gap" on each segment point (e.g. 5 sec) [23:20:29 CET] <ddubya> for the *input* you would want some iframes-only codec/profile [23:21:17 CET] <garyserj> ddubya: can you show me an example ffmpeg command for a file e.g. blah.mp4 ? [23:21:42 CET] <ddubya> mooyoul, the re-encode isn't guaranteed to preserve the file length exactly. It might add more to conform with the code [23:21:46 CET] <ddubya> code/codec [23:22:36 CET] <mooyoul> I just want to split audio to small chunks and re-encoded them in individual servers, and concat them without hearing gaps [23:24:16 CET] <mooyoul> ah yeah, duration of output was quite different with input. output was a little bit shorter than input (about < 1s) [23:26:11 CET] <foo> If I want to get the highest quality audio from a video, in mono, is this what I want? ffmpeg -i native.mp4 -ac 1 mono.flac - I asked this earlier and there was some talk about -c copy, but I couldn't get that to work properly. I unfortunately need it to be mono audio for an API I'm passing this to [23:26:15 CET] <garyserj> ddubya: ah thanks. i see this works ffmpeg -ss 191 -i vid.mp4 -vcodec libx264 -acodec libmp3lame -t 6 someoutput3.mp4 [23:29:56 CET] <s``> ddubya: thanks! its working without b-frames. [23:31:24 CET] <ddubya> mooyoul, if you carefully select a codec you can get the desired result [23:31:51 CET] <ddubya> not sure what. I recently found aac would match length exactly provided that I used recent ff version. [23:32:54 CET] <mooyoul> ah yeah, if i encode segments to self-container format like pcm, i can hear audio without gaps [23:33:14 CET] <mooyoul> but if i encode segments to aac or mp3, it produces "gap" between segments. weird... [23:33:38 CET] <furq> foo: that won't work at all with -c copy [23:33:47 CET] <furq> if this is just to pass it to an api then that command is fine [23:33:54 CET] <foo> furq: ok, so great - thank you! [23:33:55 CET] <furq> the objection was because that isn't very efficient [23:34:22 CET] <furq> there are a lot of germans in this channel and efficiency is very important to them [23:35:00 CET] <foo> furq: I value efficiency too, thank you. :) "efficiency" in that transcoding isn't necessary, right? [23:35:15 CET] <furq> it is necessary if you need to downmix it [23:35:22 CET] <furq> that would normally be a stupid thing to do but obviously not in this case [23:35:50 CET] <ddubya> mooyoul, it might work with aac/mp3 if you cut the files precisely to a mulitple of the codec frame size (I think aac is 1024 samples) [23:37:58 CET] <furq> foo: fwiw you could use -map_channels with -c copy to just get the left or right channel [23:38:13 CET] <furq> emphasis on "could" because that's not going to give good results a lot of the time [23:38:34 CET] <furq> -map_channel rather [23:38:42 CET] <foo> furq: oh, interesting, how does it currently know which channel to use? [23:38:50 CET] <furq> it doesn't, -ac does a proper downmix [23:38:57 CET] <foo> ah, downmix [23:39:05 CET] <furq> map_channel just copies a single channel [23:39:08 CET] <foo> What's strange is the resulting audio seems to have more background noise than the main video [23:39:14 CET] <foo> (but that may just be due to it being mono?) [23:39:17 CET] Action: foo still learning audio ropes [23:39:32 CET] <furq> yeah that might just be some stereo separation thing [23:39:39 CET] <JEEB> https://play.google.com/store/apps/details?id=com.YoStarJP.AzurLane&hl=ja [23:40:30 CET] <foo> furq: ok, thanks [23:41:11 CET] <JEEB> did I really post that URL here or is my backlog showing weird things? [23:41:19 CET] <furq> you really posted it [23:41:25 CET] <JEEB> I dun good [23:59:47 CET] <mooyoul> ddubya, how can i cut audio safely? I know segment muxer handles video safely by reference i-frame internally, but i can't sure that segment muxer handles audio safely like video. [00:00:00 CET] --- Mon Jan 22 2018

1 0