July 2019 - Ffmpeg-devel-irc - lists.ffmpeg.org

ffmpeg-devel.log.20190717
by burek 18 Jul '19

18 Jul '19

[00:15:03 CEST] <juandl> Hello everyone, I'm trying to implement a filter following this guide mostly: https://fossies.org/linux/ffmpeg/doc/writing_filters.txt but when I try to run it using "-lavfi myfilter" I get "No such filter: myfilter" am I missing something? [03:33:12 CEST] <Lynne> why is pwc, one of the big four auditors, the last strongholds of modern day slavery, interested in categorizing random codecs we've supported? [03:34:14 CEST] <Lynne> fun thing to do: go to urbandictionary and search for definitions for each company's name [09:14:27 CEST] <kurosu> Gah, I don't know what this UlfZibis tries/thinks he is achieving... [10:14:12 CEST] <nevcairiel> feels like it'll get worse before it gets better with this guy [10:27:32 CEST] <kurosu> nevcairiel: I'm bikeshedding, but I'd have closed this one with invalid - I wouldn't even want to acknowledge that kind of "bug" reports [10:27:37 CEST] <kurosu> thanks for doing it anyway [10:28:28 CEST] <nevcairiel> he send his FFSIGN change to the ML as well, in case you didnt see that [10:42:00 CEST] <durandal_1707> don't be so negative, he tries to code something useful [11:18:03 CEST] <kurosu> "Because anyone I ask including mathematicians, is the opinion that the sign of 0 is positive." <- that could be read as coming from a high horse [11:18:10 CEST] <kurosu> hopefully durandal_1707 is right [11:22:04 CEST] <thardin> I get the feeling sgn(0) == 0 [11:22:53 CEST] <jdarnley> But what if you're running on a sign-magnitude machine? sign(-0) should be negative? [11:23:09 CEST] <rcombs> I dunno what mathematicians he asked but conceptually zero is neither positive nor negative [11:23:22 CEST] <thardin> wikipedia thinks sgn(0) == 0 at least [11:23:55 CEST] <rcombs> (floating-point negative zero is a curiosity of the way IEEE floats are implemented, and while it can be meaningful for certain applications, it's not reflective of how real numbers work in a mathematical sense) [11:24:41 CEST] <jdarnley> But what matters is what the hardware does, at least following from his MAX/MIN comments [11:26:00 CEST] <rcombs> which comments? [11:26:01 CEST] <j-b> How do you define the sign of 0? [11:26:21 CEST] <jdarnley> by what the sign bit says lol [11:26:47 CEST] <thardin> rcombs: you can certainly define a number system which has a negative zero [11:26:55 CEST] <rcombs> thardin: sure but it's not reals [11:27:00 CEST] <thardin> of course it wouldn't be \mathbb{R} [11:27:01 CEST] <rcombs> nor integers [11:27:04 CEST] <thardin> aye [11:27:05 CEST] <jdarnley> this one https://trac.ffmpeg.org/ticket/8022 [11:27:12 CEST] <thardin> reminds me of how super-dense time works [11:27:29 CEST] <thardin> which is a union of a real and an integer [11:28:00 CEST] <rcombs> jdarnley: oof [11:28:41 CEST] <rcombs> that kinda hurts to look at [11:30:27 CEST] <rcombs> I'm kinda curious what the guy's trying to do [11:31:23 CEST] <rcombs> seems like he's probably (relatively) new at software and trying to work his way around the codebase for some sort of project, and has an unfortunate tendency to report things he doesn't understand as bugs instead of asking why they are the way they are [11:31:45 CEST] <rcombs> part of why that hurts is that it reminds me of me like 5 years ago [11:31:56 CEST] <kurosu> rcombs: make ffmpeg palatable to mathematicians? [11:32:09 CEST] <rcombs> (and still occasionally) [11:32:32 CEST] <rcombs> kurosu: make C palatable to mathematicians [11:32:57 CEST] <kurosu> Google tells me he might be/have been a Java programmer [11:33:29 CEST] <rcombs> if you wanted a rigorously correct version of the sign function for reals and integers, you'd have something like ((x) > 0) ? 1 : ((x) < 0) ? -1 : 0 [11:33:43 CEST] <rcombs> (not sure if that's the right operator precedence, nested ternaries etc) [11:34:11 CEST] <rcombs> but of course the point isn't to be rigorously correct [11:34:45 CEST] <rcombs> even if that didn't add any bugs, you wouldn't want it, because it'd add an extra comparison that might survive the optimizer in some cases [11:36:48 CEST] <thardin> you can just say "FFSIGN is FFSIGN" [11:36:57 CEST] <thardin> as I see someone already did [11:37:07 CEST] <kurosu> the psign* x86 instruction does vector*vector(FFSIGN(x)), so some people share our rationale [11:39:13 CEST] <rcombs> this reminds me, are there any good time profiler navigation UI tools for linux [11:39:52 CEST] <rcombs> I'm really used to Instruments.app on macOS and haven't found anything like that, perf seems a lot more difficult to interpret [11:42:32 CEST] <rcombs> usually if I need to test perf for something on linux I just end up writing a unit test in checkasm, or something similar in whatever project it's in [11:42:53 CEST] <rcombs> which is useful, and works well for a single tight loop, but not as well for telling you where all your cycles are going in a whole program [11:43:54 CEST] <kurosu> rcombs: no idea, maybe https://developer.amd.com/amd-uprof/ (possibly proprietary, previous version codexl had at least a github repo) [11:44:21 CEST] <rcombs> if on Intel I guess there's VTune [11:44:32 CEST] <rcombs> I should try that out sometime [11:45:41 CEST] <kurosu> VTune has a commercial license iirc, dunno how it might intersect with open source development [11:46:50 CEST] <JEEB> https://software.intel.com/en-us/system-studio/choose-download [11:46:58 CEST] <JEEB> > free commercial license [11:47:18 CEST] <rcombs> afaik it's "free but it'll nag you about renewing the free license periodically" [11:47:21 CEST] <JEEB> yea [11:47:42 CEST] <rcombs> doesn't help much if you wanna do ARM stuff though [11:47:56 CEST] <JEEB> yea [11:49:13 CEST] <rcombs> VTune apparently provides ridiculous amounts of info on where your bottleneck in the CPU's pipeline is, so it's useful even when trying to optimize a single tight loop [11:54:44 CEST] <jdarnley> rcombs: see if the perf website has any featured links for a front-end [11:54:53 CEST] <jdarnley> they probably don't [11:55:30 CEST] <durandal_1707> ncurses is best front-end [12:07:07 CEST] <kierank> rcombs: afaiu it's just perf [12:07:11 CEST] <kierank> with a gui [12:07:16 CEST] <kierank> but might be useful [13:34:36 CEST] <_bluez> Hey! Can anyone tell me if (in mov demuxer) I can get the location of mdat before it is actually parsed? [13:35:48 CEST] <_bluez> I need to read some bytes from the beginning of mdat [13:37:24 CEST] <JEEB> sounds like you need to export that somehow :P [13:38:40 CEST] <_bluez> like while probing? [13:42:13 CEST] <_bluez> export how? [13:50:56 CEST] <JEEB> you might want to detail what exactly you want and why you cannot do that while parsing mdat? [13:58:49 CEST] <_bluez> In heif files, the information about grid of tiles e.g. how many rows and cols is present at the top (for apple files at least) of mdat [13:59:43 CEST] <_bluez> but now that I think of it maybe I wont need that information until later ':D [14:00:52 CEST] <_bluez> I'll try to do that and ask again if not possible [14:01:21 CEST] <_bluez> Sorry ':D [14:07:19 CEST] <JEEB> _bluez: sounds like it's a specific box that you just have to parse from mdat or so? [14:08:29 CEST] <JEEB> and you could export it either track-specific or global depending on if it's global metadata or track-specific metadata [14:10:14 CEST] <_bluez> its not exactly a box but yeah kinda like that... its an item entry just like a picture or tile, except it has those information instead of image data [14:12:47 CEST] <_bluez> but how do i export and from which part in the code? [14:43:53 CEST] <durandal_1707> kurosu: it works with all samples i have [14:44:20 CEST] <kurosu> durandal_1707: I suspect (for malformed bitstreams that some transcoding services will have to handle) you may need to flush one codec or the other [14:44:55 CEST] <kurosu> or there's a special property of the coding structure that allows it for non-devious files, but is not generally guaranteed [14:45:59 CEST] <kurosu> I'd probably alloc the decoder on demand, and ask_for_sample if it changes within a file/decoder instance/... [14:47:27 CEST] <kurosu> that or we wait for Google's fuzzing reports to come in [17:26:56 CEST] <mkver> durandal_1707: Did you test compilation with my matroska patch with MSVC? [17:28:31 CEST] <durandal_1707> mkver: nope, let FATE handle it :) [17:28:53 CEST] <durandal_1707> wait for some MSVC guru to appear [21:48:19 CEST] <durandal_1707> jamrial: have you seen that MSVC fails on fate? do you have MSVC to test patch on ml? [21:48:56 CEST] <mkver> I have already talked to James. He has no MSVC. [21:49:09 CEST] <durandal_1707> crap [22:22:06 CEST] <durandal_1707> ^ nevcairiel ? [22:26:10 CEST] <nevcairiel> i can run it a bit later [22:26:46 CEST] <mkver> Thanks, nevcairiel! [22:57:01 CEST] <cone-588> ffmpeg 03James Almer 07master:056865a1d679: avcodec: clarify the allocation requirements for intra_matrix and inter_matrix fields [23:20:05 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:a7e02cf3ad6f: avcodec/ivi: Ask for samples with odd tiles [23:20:06 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:fff2bdc8b835: avformat/takdec: Free buffer on error pathes [23:20:07 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:bb326795d135: avformat/takdec: Check for multiple streaminfo [23:20:08 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:15008db0fac6: avcodec/parser: Check next index validity in ff_combine_frame() [23:20:09 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:1707dbdf49b2: avcodec/dnxhd_parser: remove unneeded code [23:20:10 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:827faa18cfd0: avcodec/dnxhd_parser: Optimize insufficient buf size case [23:20:11 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:f6d1b18b3d58: avformat/rawdec: Make the raw packet size configurable [23:20:12 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:2d900d8fe0aa: avcodec/dnxhd_parser: Fix parser when input does not have nicely sized packets [00:00:00 CEST] --- Thu Jul 18 2019

1 0

ffmpeg.log.20190717
by burek 18 Jul '19

18 Jul '19

[00:26:19 CEST] <nine_milli> blb [02:18:11 CEST] <gschanuel9> night! [02:18:11 CEST] <gschanuel9> i'm trying to join 15 mp4 videos into a matrix 3x5. I've found some command lines to do a 2x2 [02:18:44 CEST] <furq> gschanuel: https://ffmpeg.org/ffmpeg-filters.html#xstack [02:20:44 CEST] <gschanuel> very informative indeed. think I got it :) [02:42:15 CEST] <gschanuel> actually, i thought i'd got it, but didn't [02:42:19 CEST] <gschanuel> ffmpeg -i 09JtDCQ5.mp4 -i 9IDNRtPP.mp4 -i bO_HGIwN.mp4 -i c2LRRnjO.mp4 -i CfK13HXE.mp4 -i EOTAq9L9.mp4 -i Fa+IueML.mp4 -i lPK8LXKp.mp4 -i MLChV65X.mp4 -i O0xIVcFM.mp4 -i PPiVss5k.mp4 -i SRLpxv7x.mp4 -i tXI6sMKq.mp4 -i zC1a+ig6.mp4 -i zzultimo2.mp4 -i zzultimo.mp4 -filter_complex "xstack=inputs=15:layout=w0_h0|1_0|2_0|0_1|1_1|2_1|0_2|1_2|2_2|0_3|1_3 [02:42:19 CEST] <gschanuel> |2_3|0_4|1_4|2_4" [02:42:55 CEST] <gschanuel> it failed with [Parsed_xstack_0 @ 0x5586369c2500] Failed to configure output pad on Parsed_xstack_0 [02:43:07 CEST] <gschanuel> Error while processing the decoded data for stream #14:0 [02:43:25 CEST] <gschanuel> does that mean my #14th video was corrupted? [02:57:28 CEST] <kepstin> gschanuel: please pastebin the *complete* output (preferably with -v verbose to debug filterchain stuff) [03:19:15 CEST] <gschanuel> https://gist.github.com/a46723508259bf6a75916633f763e86e [03:20:43 CEST] <gschanuel> https://gist.github.com/f5679ab7671ec3adcef88053e4e50515 [03:23:15 CEST] <gschanuel> sorry.. damn.. i'm bit high already, cold night ask some alcool XD [03:25:03 CEST] <gschanuel> wanna make a meme for a friend [03:25:38 CEST] <klaxa> SRLpxv7x.mp4 seems to be b0rked? [03:25:59 CEST] <klaxa> what does ffprobe show for it? (pastebin again) [03:26:52 CEST] <gschanuel> https://gist.github.com/7282458e9f28dfc06debe8b7b4595ce8 [03:27:03 CEST] <gschanuel> ha! i was faster now huh! [03:29:19 CEST] <gschanuel> i believe this is the first time I really mean lol [03:33:33 CEST] <gschanuel> forget it.. i'm not even reading the outputs .. not able to rationalize much atm.. [03:38:56 CEST] <DHE> I feel like this is a common enough thing that there should be a "ystack" filter or something that just takes width, height, and auto-assigns streams left-to-right, then top-to-bottom. [03:40:20 CEST] <klaxa> i can't find anything obviously wrong... [03:47:29 CEST] <MikeJoel> is there a way to rotate the video - took some mp4 videos off my phone and for some reason they are all on their sides :/ [03:51:03 CEST] <nine_milli> blb [03:55:00 CEST] <MikeJoel> sorry lost power [03:55:14 CEST] <MikeJoel> I had asked about rotating video [03:55:25 CEST] <furq> is there some way i'm missing of getting a color source in rgb without having to convert it afterwards [03:56:20 CEST] <furq> the least stupid way i can think of is color=white,format=rgb24,drawbox [03:56:23 CEST] <furq> which seems pretty stupid [04:07:00 CEST] <klaxa> have something (`yes`?) write raw octets and use -f rawvideo -pix_fmt rgb24 ? [04:07:17 CEST] <klaxa> and -s and -r obv. [04:07:29 CEST] <furq> funnily enough i am already doing that for the palette in this script [04:07:38 CEST] <furq> so that would work [04:07:58 CEST] <klaxa> sounds like the next most reasonable thing to do [04:08:01 CEST] <furq> well [04:08:08 CEST] <furq> except for the fact that stdin is already occupied [04:08:24 CEST] <klaxa> named pipes? :> [04:08:45 CEST] <furq> that's less than ideal [04:09:53 CEST] <furq> i'm surprised this hasn't come up before honestly [04:30:07 CEST] <MikeJoel> Is there a way to rotate a video while converting? [05:18:10 CEST] <furq> doh [05:18:18 CEST] <furq> so apparently the issue i was having was an entirely different part of the command [05:18:33 CEST] <furq> apparently yuvj444p to gray fucks up the range [05:19:50 CEST] <furq> MikeJoel: if it's mp4 then you probably won't need to reencode [05:19:55 CEST] <furq> mp4 has rotation metadata you can set [05:20:21 CEST] <furq> or which you can delete because if these are off a phone then that metadata might already be set wrong [05:20:48 CEST] <furq> you can check with ffprobe and then set it with -metadata:s:v:0 rotate=90 [05:29:50 CEST] <kepstin> DHE: i have part of the prototyping done for a filter that does that. (take n inputs and an output video size, scale+tile the inputs into a grid). i should finish that some time... [05:44:52 CEST] <MikeJoel> furq: thanks [06:49:54 CEST] <kepstin> https://www.kepstin.ca/dump/Screenshot%20from%202019-07-17%2000-45-43.png still needs work, it doesn't actually generate output frames yet :) [09:10:01 CEST] <MoziM> why are there fps values that are floating numbers? [09:28:01 CEST] <MoziM> https://code.likeagirl.io/finding-out-im-autistic-at-30-e5754ce9462a?source… [09:55:36 CEST] <durandal_1707> gschanuel: did you managed to do xstack into 3x5 matrix? [10:31:50 CEST] <MoziM> woops wrong channel sorry [12:26:13 CEST] <suryajagtap> how to stream a local file using ffmpeg [13:44:46 CEST] <lain98> i'm trying to transcode a video to change pix_fmt from yuv420p to nv12. the command runs fine but the output file still reports yuv420p. I used ffmpeg -i input -pix_fmt nv12 output. ffmpeg -i output still reports yuv420p [13:46:39 CEST] <Mavrik> lain98: what are you transcoding to? [13:46:44 CEST] <Mavrik> Most video formats don't support nv12 [13:46:58 CEST] <Mavrik> or, more accurately, most encoders. [13:49:01 CEST] <lain98> x264 [13:49:12 CEST] <lain98> Mavrik, [13:49:21 CEST] <lain98> x264 mp4 [13:51:30 CEST] <BtbN> h264 does not have a pixel format [13:51:43 CEST] <BtbN> It's the decoder that decides what pixel format to put the decoded data in [13:52:05 CEST] <JEEB> hardware decoders usually utilize nv12, while sw decoders historically use the fully planar formats (yuv420p etc) [13:52:28 CEST] <Mavrik> Hmm, good point. [13:52:35 CEST] <JEEB> esp. true with H.264. so when you decode with swdec H.264 you will get yuv420p. which has the same data as nv12 [13:52:51 CEST] <Mavrik> I may have explained that wrong: H.264 has it's own way of storing data and "NV12" doesn't make sense in that world [13:53:03 CEST] <JEEB> nv12 just is half-packed, (luma is same as yuv420p, chroma interleaved) while yuv420p has all planes separate :P [13:53:07 CEST] <lain98> could i use mkv [13:53:13 CEST] <JEEB> the container really doesn't matter [13:53:39 CEST] <JEEB> lain98: H.264 codes 4:2:0 content and if you get nv12 or yuv420p out of a decoder depends 100% on what the decoder does; the actaul content is the same [13:54:01 CEST] <JEEB> lain98: if you need nv12 for some part of the process that you're doing then you can always do a conversion process in the middle if needed [13:54:04 CEST] <lain98> okay [13:54:06 CEST] <lain98> thanks [13:54:07 CEST] <JEEB> after all, it's just the location of the data [13:54:42 CEST] <JEEB> NV12 has it [luma] [CrCbCrCbCr...] while yuv420p is [luma] [CrCrCr...] [CbCbCb...] [13:54:45 CEST] <JEEB> :P [13:54:56 CEST] <JEEB> GPU based things seem to like the former [13:55:55 CEST] <JEEB> (also I think the order is actually YCbCr, but details~) [14:24:45 CEST] <pomaranc> is there any way to use frame metadata from ocr to create a text subtitle track? [14:30:06 CEST] <DHE> from ffmpeg-all I rather doubt it without doing a custom application [14:30:48 CEST] <pomaranc> yeah, that's what I thought too after reading it [14:34:28 CEST] <JEEB> yea, you'd need the AVSubtitle (image) -> AVFrame (tesseract) -> AVSubtitle (text) stuff to be around [14:35:36 CEST] <JEEB> the first part is already there in the sub2video logic in ffmpeg.c [14:35:46 CEST] <JEEB> which plasters the AVSubtitleRectangles onto a canvas [14:35:54 CEST] <JEEB> so you can then feed them to a video filter chain [14:35:55 CEST] <JEEB> buut [14:36:15 CEST] <JEEB> then you need something to read the results of that and convert them to text based AVSubtitles based on the metadata [14:39:50 CEST] <durandal_1707> asked numerous times and answered in myriad variations by JEEB [14:41:08 CEST] <kurosu> oh wow imm5, what a weird beast [14:42:01 CEST] <kurosu> durandal_1707: does the "thing" effectively allows to switch between h264 and h265 on a frame basis? is it intra-only or ? [14:42:19 CEST] <durandal_1707> it is not intra only [14:42:30 CEST] <kurosu> otherwise, I have no idea how the codec cannot be constant (but why signal it on the frame header?) through a gop ? [14:43:04 CEST] <kurosu> err, wrong window |-[ [14:53:14 CEST] <pomaranc> JEEB: thank you [14:53:22 CEST] <pomaranc> that's useful info [16:45:04 CEST] <dodgepong`work> Hi all. Does anyone know anything about hardware decoding of webm files that have an alpha channel? [16:45:58 CEST] <nine_milli> blb [16:46:36 CEST] <durandal_1707> webm is dead [16:47:01 CEST] <dodgepong`work> What should people be using instead for video with alpha transparency that is easy to work with? [16:47:11 CEST] <dodgepong`work> And supports hardware decoding [16:47:32 CEST] <DHE> webm is just a container. I assume you mean vp9 (the codec) [16:48:09 CEST] <dodgepong`work> Well, unfortunately VP9 by itself doesnt support alpha, so Chrome decided to support alpha transparency in the webm container by adding a mono alpha stream [16:48:18 CEST] <dodgepong`work> alongside the VP9 stream [16:48:28 CEST] <DHE> oh that's funky... [16:48:33 CEST] <dodgepong`work> Indeed [16:48:37 CEST] <dodgepong`work> And yet, its still widely used [16:48:38 CEST] <MoziM> how can a video have a bitrate of 0? [16:49:05 CEST] <DHE> probably means the bitrate isn't measured [16:49:17 CEST] <MoziM> why? [16:49:41 CEST] <dodgepong`work> @durandal_1707 Why do you say webm is dead, and what do you suggest as an alternative? [16:49:44 CEST] <DHE> because video is almost always VBR and hence difficult to measure without actually reading the whole file and calculating [16:51:58 CEST] <MoziM> oh... [16:52:37 CEST] <durandal_1707> dodgepong`work: webm is google product iiuc [16:52:40 CEST] <MoziM> i guess my video player caches the bit rate when it encounters a new video [16:52:49 CEST] <MoziM> so new videos would read 0 [17:13:46 CEST] <durandal_1707> dodgepong`work: for local stuff, i use nut container [17:23:27 CEST] <dodgepong`work> @durandal_1707 does nut work with common editors and creation programs like After Effects [17:24:53 CEST] <durandal_1707> deetwelve: i do not use such products, sorry [17:25:01 CEST] <durandal_1707> dodgepong`work: ^ [17:25:20 CEST] <dodgepong`work> I see [17:25:30 CEST] <dodgepong`work> Thanks for the info, I had never heard of nut before [18:36:13 CEST] <sine0> hey guys, is it possible to record a radio stream in ffmpeg, like from stream.pls from the uk bbc that works in vlc network stream [18:37:39 CEST] <durandal_1707> yes [18:38:38 CEST] <sine0> I have tried ffpmeg -y -i bbc.co.uk/blah/stream.pls output.mp3 [18:38:49 CEST] <sine0> as a blog post mentioned, could you advance on that (it didnt work) [18:39:01 CEST] <sine0> perhaps they work with headers or something... [18:39:44 CEST] <durandal_1707> sine0: if you want help, pastebin actuall ffmpeg full output [18:42:07 CEST] <sine0> https://pastebin.com/Q5XNix3U [18:47:01 CEST] <durandal_1707> sine0: ffmpeg does not support playlist format yet (pls) so you need to download manually and extract http stream [18:47:34 CEST] <durandal_1707> extract steam from pls file [18:48:08 CEST] <c_14> sine0: if you open the pls file in a text editor there should be a url there, give that to ffmpeg [18:49:19 CEST] <sine0> ok thanks [18:49:43 CEST] <durandal_1707> or use mpv for playback, it can capture stream too [18:49:57 CEST] <nine_milli> blb [18:54:07 CEST] <CoreX> download the pls open in texteditor take link and paste into youtube-dl and let it save for you [19:22:32 CEST] <Classsic> hi, somebody have this issue: when push rtsp to rtmp local server, the speed is greater than 1, and fps input itŽs ok. but when push to public server, get the half speed on fps. [19:22:53 CEST] <Classsic> this only happen on windows static build, on linux, work perfectly. [19:24:20 CEST] <Classsic> is like windows throttle the bandwidht when push rtmp to public address. [20:21:27 CEST] <sine0> Does anyone know if its possible to rip from netflix [20:21:50 CEST] <sine0> i know it wouldnt be a popular thing to post on the internet as they are probably aggressive but is it possible [20:21:58 CEST] <sine0> other than just a screen recorder [20:22:11 CEST] <BtbN> It's copy protected. You can't screen record it. [20:23:46 CEST] <durandal_1707> why are you asking here for ways to break laws? [20:23:55 CEST] <sine0> good point it was just a thought [20:24:01 CEST] <JEEB> sine0: technically it seems like it's possible since I see stream rips pop up on the internet, but don't ask me about the solutions :) [20:24:12 CEST] <sine0> JEEB: thats what im saying fella [20:24:26 CEST] <JEEB> keywords would probably be "widevine" and something else :P [20:24:29 CEST] <BtbN> People usually use HDCP strippers and a capture card for that. [20:24:36 CEST] <BtbN> Which is also very much not legal. [20:24:51 CEST] <JEEB> I think you only need that for the 4K stuff that has a "secure path only" license [20:25:04 CEST] <JEEB> the rest should not be that high security level? not that I know since I don't use netflix :) [20:25:15 CEST] <BtbN> Anything higher than 720p is [20:25:42 CEST] <JEEB> also this reminds me that some old old samsung TVs actually used widevine with libavformat :P [20:25:51 CEST] <JEEB> there's still a source dump of theirs in a repo [20:26:09 CEST] <JEEB> of course it has nothing to do with current widevine EME [20:26:16 CEST] <JEEB> and mostly a fun factoid :) [20:26:38 CEST] <JEEB> but at this point with EME I'd probably just have the EME thing decrypt it for me if I was looking into that stuff :P [20:27:35 CEST] <durandal_1707> ways to break law are strictly prohibited here, last warning, next step is ban :) [20:33:19 CEST] <esaym153> so I need to downmix a 5.1 movie to 2 channel. I know about the "-ac 2" flag. But that grabs the first audio stream (which is 5.1 but not english). I need to grab the second audio stream. [20:33:33 CEST] <esaym153> I've tried all combos of stuff like "-ac:a:1" but that doesn't work [20:33:47 CEST] <JEEB> stream selection by default is automagic and it picks stuff according to some rules [20:33:59 CEST] <JEEB> see the mapping options (-map) in ffmpeg-all.html [20:34:16 CEST] <JEEB> that lets you define which exact streams you want from your input (all automagic gets disabled) [20:39:05 CEST] <esaym153> ok, I think -map 0:2 -ac 2 did it [20:39:06 CEST] <esaym153> thanks [20:41:37 CEST] <JEEB> np [20:43:36 CEST] <JEEB> esaym153: also many 5.1 mixes when mixed down to stereo can be really low in volume. check -af "aformat=channel_layouts=stereo,loudnorm=I=-24,aresample=sample_rate=48000" [20:43:45 CEST] <JEEB> instead of just -ac 2 [20:44:14 CEST] <esaym153> JEEB: yea, I've got a formula. I do this all the time, just never had the issue of two 5.1 streams in the same file [20:44:24 CEST] <JEEB> alright [20:45:54 CEST] <kepstin> esaym153: yeah, if you don't explicitly specify any -map options, then ffmpeg by default will pick one video stream + one audio stream from the file (whichever stream is marked as default, or the first one otherwise, i think) [20:46:31 CEST] <JEEB> it has some "pick best" logic, so it does look at bit rates and channel counts etc [21:36:22 CEST] <sine0> hey you GUYZ [21:36:38 CEST] <sine0> the pls file contents still didnt work https://bpaste.net/show/VfKU [21:40:35 CEST] <nine_milli> blb [21:42:15 CEST] <durandal_1707> sine0: you are supposed to extract http links from it [21:43:36 CEST] <durandal_1707> or as already mentioned download mpv, from https://mpv.io .... [21:44:57 CEST] <furq> https://clbin.com/ryxAg [21:44:58 CEST] <furq> works fine here [21:55:53 CEST] <sine0> durandal_1707: yea there are 2 http links in it, I assume they are the streams [21:56:22 CEST] <sine0> furq: do you think the quotes matter [21:56:25 CEST] <sine0> around the rul [21:56:26 CEST] <furq> i know the quotes matter [21:56:31 CEST] <sine0> you knowz it mate [00:00:00 CEST] --- Thu Jul 18 2019

1 0

ffmpeg-devel.log.20190716
by burek 17 Jul '19

17 Jul '19

[00:02:24 CEST] <durandal_1707> kierank: so how would you design new stuff? that is not trivial [00:02:57 CEST] <kierank> durandal_1707: the way j-b doesn't like [00:03:13 CEST] <nevcairiel> the way every other media framework works [00:03:16 CEST] <kierank> "everything is a filter" [00:03:44 CEST] <nevcairiel> everything has the same api, you just define what it accepts based on type information [00:04:28 CEST] <Lynne> durandal_1707: you could write a new demuxer that nihs avi if the files are guaranteed to not be vfw or otherwise weird avi [00:04:45 CEST] <Lynne> or hack avi, the whole format's a hack anyway [00:06:54 CEST] <durandal_1707> Lynne: but that makes mixed h264+hevc within imm5 not nicely supported [00:07:15 CEST] <nevcairiel> can it actually change frame by frame? [00:07:30 CEST] <nevcairiel> who would make such a thing? :d [00:07:43 CEST] <durandal_1707> users could concat files [00:11:31 CEST] <jamrial> users could concat a lot of stuff. doesn't mean it needs to be supported [00:12:01 CEST] <jamrial> if removing that consideration we can make this use an autoinserted bsf, then i think it would be much better [00:12:18 CEST] <durandal_1707> nooooooooo!!!!!!!!! [00:13:03 CEST] <kierank> already the case i think [00:13:04 CEST] <kierank> with latm [00:13:13 CEST] <kierank> can have concatenation of any aac flavour in latm [00:13:49 CEST] <Lynne> wouldn't suprise me if the avi demuxer already deals with concat'd files [00:14:33 CEST] <nevcairiel> thats why latm is its own decoder that handles the latm header and then invokes the aac decoder :d [00:18:25 CEST] <durandal_1707> yes, i want to keep imm5_decoder [00:22:28 CEST] <Lynne> no reason to have more unless there's no other way though [00:22:45 CEST] <durandal_1707> there is no other way [00:23:18 CEST] <durandal_1707> there is also imm6 (i need to find samples for it) [00:23:30 CEST] <durandal_1707> i want we have imm4/imm5/imm6 combo [00:24:02 CEST] <durandal_1707> besides tdsc alread uses jpeg in similar way [00:35:28 CEST] <jamrial> are those IMM5_units hardcoded parameter sets NALUs? [00:42:04 CEST] <nevcairiel> of course they are, dont you recognize a sps/pps when you see one? :D [00:46:04 CEST] <mkver> durandal_1707: My review is up and contains a suggestion on how to avoid that imm5_buffer. [00:46:43 CEST] <jamrial> mkver: he left [00:47:25 CEST] <mkver> My bad. [00:47:50 CEST] <jamrial> also, by growing the packet he would already be making it writable [00:48:50 CEST] <mkver> He's growing the packet? [00:49:19 CEST] <jamrial> no, your suggestion [00:49:38 CEST] <jamrial> but maybe i misread what you said [00:50:28 CEST] <mkver> I don't want to grow the packet; I intend to make it smaller (so that only the parts that need to be preserved (+ the desired size at the front) are preserved when the packet is made writable. [00:50:44 CEST] <mkver> This is very similar to the truehd_core bsf. [00:51:09 CEST] <jamrial> yeah, my bad, you said increment pkt->data and i mistakenly read it as growing the packet to insert the hardcoded bytes [01:03:24 CEST] <mkver> Strange that neither of us complained that imm5_buffer never gets freed... [01:37:37 CEST] <jamrial> there's a lot of stuff leaking in that patch :p [01:37:49 CEST] <jamrial> i pointed a few, but yeah, missed that one [01:45:58 CEST] <mkver> Speaking of memleaks, my mpeg4_unpack_bframes patch here: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/246435.html fixes a memleak (of side data) that an earlier patch of yours created. [01:47:37 CEST] <jamrial> not sure how many scenarios can there be with side data here, but nice catch [01:51:33 CEST] <mkver> The probability of side data leaking is so big that you explicitly mentioned it in the commit message of bd60116794b4baaf9a6fedfc68cb1ac4a383bb2d :D [02:05:17 CEST] <jamrial> not big, just there :p [11:14:51 CEST] <durandal_1707> how to copy dictionary options from one avctx to another? [11:18:11 CEST] <JEEB> hmm, request_channel_layout... does that actually do downmix in AC3 or does it only set the coeffs etc? [11:18:38 CEST] <JEEB> or more specifically, does it apply the DRC that the stream might have info on [11:18:44 CEST] <nevcairiel> it doesnt downmix as such, if a format contains substreams with an embedded downmix, it'll only decode those [11:18:51 CEST] <JEEB> ah [11:18:54 CEST] <JEEB> alrighty [11:20:45 CEST] <nevcairiel> actually for ac3 it sort-of downmixes, using downmix coefficients in the ac3 stream [11:22:27 CEST] <nevcairiel> overall that option is very rarely used :d [11:24:55 CEST] <JEEB> yea, I just noticed it because there were FATE tests [11:25:01 CEST] <JEEB> (for ac3 specifically) [11:25:37 CEST] <JEEB> I am doing DRC/normalization post downmix usually, but I wonder if this gives a "closer" result to what the plastic boxes do for 5.1->stereo for example :P [11:30:33 CEST] <rcombs> durandal_1707: the avctx doesn't keep around its options as an AVDictionary at runtime; you'd need to iterate the AVOptions table and read them manually, I'd expect [11:31:05 CEST] <nevcairiel> I wouldnt really bother with that outside of a few key options like maybe threading [11:33:37 CEST] <kurosu> Wow, that #8022 is something... [11:34:05 CEST] <kurosu> I'd be headdesking if the guy was not obviously clueless and meaning well [11:34:23 CEST] <nevcairiel> not sure how he even got to that conclusion [11:36:10 CEST] <kurosu> Well, you have to start somewhere, and that somewhere is probably often this, or "compilers have known about this for years" [21:50:16 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:27f40b1dcdff: avformat/matroskadec: Don't abort resyncing upon seek failure [21:50:17 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:310f326b4354: avformat/matroskadec: Add function to reset status [21:50:18 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:8a286e745d0e: avformat/matroskadec: Use proper levels after discontínuity [21:50:19 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:559e3422c78b: avformat/matroskadec: Refactor some functions [21:50:20 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:a3db9f62a42a: avformat/matroskadec: Introduce a "last known good" position [21:50:21 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:c1abd95ad096: avformat/matroskadec: Link to parents in syntax tables [21:50:22 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:b31c9b72e5e6: avformat/matroskadec: Redo level handling [21:50:23 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:865c5370078f: avformat/matroskadec: Make cluster parsing level compatible [21:50:24 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:a9f051519e2a: avformat/matroskadec: Don't reset cluster position [21:50:25 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:38255cdcf815: avformat/matroskadec: Combine arrays [21:50:26 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:3ed2755baaf3: avformat/matroskadec: Redo EOF handling [21:50:27 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:7087fc95b258: avformat/matroskadec: Reuse positions [21:50:28 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:60f75c997636: avformat/matroskadec: Typos, nits and cosmetics [21:50:29 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:512030513743: avformat/matroskadec: Don't skip too much when unseekable [21:50:30 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:04b62bd7ceb4: avformat/matroskadec: Improve invalid length error handling [21:50:31 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:3c70b941d5d1: avformat/matroskadec: Accept more unknown-length elements [21:50:32 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:9c6d14ab84e4: avformat/matroskadec: Fix probing of unknown-length headers [21:50:33 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:71c908817ec6: avformat/matroskadec: Accept more unknown-length elements II [21:50:34 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:6854127a7698: avformat/matroskadec: Reindent after previous commit [21:50:35 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:730ac1ae8039: avformat/matroskadec: Use file offsets for level 1 elements [21:50:36 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:806ac7da6927: avformat/matroskadec: Improve check for level 1 duplicates [21:51:29 CEST] <jamrial> bogus annoying warning gone [21:54:00 CEST] <kurosu> one patch per character removed ? :D [21:54:30 CEST] <kurosu> more seriously, would the author consider submitting samples to test each fix (or some) [21:54:43 CEST] <jamrial> mkver: ^ [21:55:10 CEST] <mkver> I didn't think that you would commit all in one go. [21:56:40 CEST] <jamrial> i didn't. this is half the patchset after all :p [21:56:53 CEST] <mkver> lol [23:18:22 CEST] <JEEB> howaboutsynergy: anyways you'd probably get a lot more traction by explaining what bad is happening to you without the patch etc [23:18:38 CEST] <JEEB> by itself that thread on hte trac issue is mostly about API misuse [23:18:44 CEST] <JEEB> or that's how it seems to be [23:19:05 CEST] <howaboutsynergy> well I don't remember :D I thinkn that some video(s) had bit size 0 and somewhere later the buffer wouldn't be NULL and it would be accessed [23:20:01 CEST] <howaboutsynergy> so maybe, if someone would set bit size 0 somehow in the video file, some weird hacks could be constructed? [23:20:21 CEST] <howaboutsynergy> anyway, I've been using that patch ever since, so maybe that's why I haven't encountered anything since then [23:20:44 CEST] <howaboutsynergy> here's links (on this channel also): https://trac.ffmpeg.org/attachment/ticket/4749/handlebit_size0.patch or a more up to date(with git) one: https://github.com/howaboutsynergy/q1q/blob/998b270964ea1ca79ecc2d94e7a4362… [23:21:16 CEST] <howaboutsynergy> wish I had a reproduction video or something, but to a dev. the patch should be self-explanatory, me thinks [23:21:49 CEST] <durandal_1707> give proper patch or nobody takes you seriously [23:21:52 CEST] <JEEB> well, without context just looking at that diff and the trac issue thread [23:22:10 CEST] <howaboutsynergy> yeah ok, my bad, sorry for the trouble:) [23:22:21 CEST] <JEEB> esp. the place where the original author of the patch notes that he has no idea if that value actually happened or not [23:22:23 CEST] <durandal_1707> off course patch is fine [23:22:32 CEST] <JEEB> well great there durandal_1707 [23:22:55 CEST] <JEEB> it might have ended with no info from the person, but yunno [23:23:08 CEST] <JEEB> you made sure that happened, kinda :P [23:24:23 CEST] <durandal_1707> i do not think our bitreader would choke on 0 size of bitstream [23:24:55 CEST] <durandal_1707> at best, few invalidreads would happen [23:25:12 CEST] <JEEB> well that's why I was trying to figure out the context :P esp. since https://trac.ffmpeg.org/ticket/4749 had weird comments about zero not actually happening to the guy etc [23:25:33 CEST] <JEEB> if the guy couldn't provide any context to the change, too bad [23:26:45 CEST] <durandal_1707> also that patch does not apply any more ... [23:27:25 CEST] <JEEB> the github one seemed to be the version he was keeping up-to-date [23:27:49 CEST] <JEEB> durandal_1707: also I'm not trying to say the patch is valid :P I was trying to figure out /why/ that change would have been done [23:28:06 CEST] <JEEB> -> getting the "why" usually helps trying to figure if the change is right [23:28:20 CEST] <JEEB> esp. given the context of the ticket I wanted to ask him why he was applying that patch still :P [23:31:58 CEST] <durandal_1707> ask him via creating issue on his github page [23:32:27 CEST] <JEEB> I don't care /that/ much. he was here after all, so that was close to zero effort :P [23:32:36 CEST] <durandal_1707> its probably remnant of old days when we would not check for return values of init_get_bits or size of input packet [23:32:36 CEST] <JEEB> at this point we have driven him out [23:32:46 CEST] <JEEB> durandal_1707: quite possible [23:34:13 CEST] <durandal_1707> anyway 0 bitsize is pointless so should error out early anyway, maybe michaelni want to comment? [00:00:00 CEST] --- Wed Jul 17 2019

1 0

ffmpeg.log.20190716
by burek 17 Jul '19

17 Jul '19

[00:17:29 CEST] <Thomas_J> No matter where II put "-filter "adelay=2s" at, I get a different error message. https://pastebin.com/fqC6sGfF [00:19:59 CEST] <durandal_1707> Thomas_J: you need to move it after last " -i " [00:21:16 CEST] <Thomas_J> I tried it there and it gave me "Filtergraph 'adelay=2s' was defined for video output stream 0:0 but codec copy was selected. [00:21:16 CEST] <Thomas_J> Filtering and streamcopy cannot be used together." [00:22:17 CEST] <durandal_1707> -filter:a [00:22:22 CEST] <durandal_1707> or shorter -af [00:22:25 CEST] <Thomas_J> OOHHHHHH [00:29:08 CEST] <Thomas_J> Very interesting. I guess I need to specify 2 channels of audio delay. The right channel is ahead of the left by 2 seconds. [00:29:35 CEST] <durandal_1707> 2|2 [00:29:56 CEST] <furq> !filter adelay @Thomas_J [00:29:57 CEST] <nfobot> Thomas_J: http://ffmpeg.org/ffmpeg-filters.html#adelay [00:30:10 CEST] <furq> almost forgot i had that thing [00:35:11 CEST] <Thomas_J> Delaying audio has caused a 4 second A/V spread now. It seams that it moved the video instead of the audio. [00:39:20 CEST] <Thomas_J> Audio was 2 seconds ahead of audio. I used -filter:a "adelay=2s|2s" and now the audio is ahead of the video by 4 seconds. [00:39:46 CEST] <Thomas_J> That doesn't make sense. [01:11:48 CEST] <Thomas_J> I can't find any information on why adelay advances the audio instead of delaying it. All I've Googled, just copies what's in the ffmpeg docs and adds no insight. [01:29:08 CEST] <KittyCat> hmm, the two videos I could provide as a test for my issue are 60+MB each. I tried using ffmpeg to create a small snippet (using -vcodec copy -acodec copy), but the resulting file doesn't cause the issue [01:36:57 CEST] <Thomas_J> I got it working with -itsoffset but I ahd to increade the input audio buffer to 2048 with "thread_queue_size". [01:38:53 CEST] <Thomas_J> Forgive my spelling. My fingers are old and they don't type straight anymore. [04:51:50 CEST] <nine_milli> blb [05:46:02 CEST] <ossifrage> I think my brain is leaking out my ear, I used to have a clever way to generate cr/cb continuous color patterns and I now I can't remember how I did it... [05:52:16 CEST] <noahmg123> I'm trying to get this video file into a good format for my friend on Windows. But no matter what codec or other options I use with ffmpeg, it doesn't appear to do anything. I'm using VLC as a baseline to see if it can play the file, and it always gives a codec error talking about h264. [05:52:41 CEST] <noahmg123> I don't really care about the codec error, I just want it in a form Windows Media Player can play [05:53:02 CEST] <noahmg123> (but I don't have access to Windows, so I'm using VLC as my sort-of proxy) [05:54:26 CEST] <noahmg123> Converting to WMV with wmv2 and wmva2 codecs still has VLC complaining. [06:00:31 CEST] <andrew_46> What is vlc's complaint? [08:22:07 CEST] <MoziM> is concatonating 2 video files typically a fast operation? [08:35:23 CEST] <sector_surfer> Hi there [08:35:46 CEST] <sector_surfer> will ffmpeg ever support sample AES encryption? [08:36:37 CEST] <JEEB> if someone implements it? [08:37:14 CEST] <sector_surfer> I'm trying to download a TV show and I get the manifest url [08:37:17 CEST] <sector_surfer> from here [08:37:18 CEST] <sector_surfer> https://www.9now.com.au/murder-lies-and-alibis/season-1/episode-4 [08:37:51 CEST] <sector_surfer> do you have any idea when it will be implemented? [08:38:17 CEST] <JEEB> when someone cares? it's open source, after all [08:38:19 CEST] <sector_surfer> is there anything else I can do to obtain the video in future? [08:38:52 CEST] <JEEB> if it's drm you need the license/key handling anyways [08:40:37 CEST] <JEEB> and I think if you stick yourself to the eme module, that thing will do the decryption for you [08:41:30 CEST] <sector_surfer> EME Module? I'm sorry, I have no knowledge of programming. what do I need to do to get this eme module? [08:42:09 CEST] <JEEB> eme is the encrypted media extensions stuff :p [08:42:21 CEST] <sector_surfer> and where do I get it? [08:42:25 CEST] <JEEB> your browser of choice probably has at least one :p [08:42:37 CEST] <JEEB> either google's or ms's [08:43:15 CEST] <JEEB> i know people rip stuff so in that sense you "just" need to hook into its interfaces :p [08:43:28 CEST] <JEEB> and then you should get decrypted content [08:44:11 CEST] <sector_surfer> so once the eme in the browser starts working, how do I then obtain the unencrypted stream? I have no idea what you mean by hooking into the interface, I wouldn't even know where to start [08:44:17 CEST] <sector_surfer> all this seems a little beyond me [08:45:02 CEST] <JEEB> someone probably has written stuff for this already. after all, the kodi modules for services utilize it :p [08:45:15 CEST] <sector_surfer> you're talking to a newby here so I might need to speel things out a bit more [08:45:35 CEST] <sector_surfer> I mean you might need to spell thing out a bit [08:46:55 CEST] <JEEB> but yea, even if someone from FFmpeg implements sample aes, you would still need to figure out how to gwt the key since in most cases you're dealing with drm and not like with hls where you have a link to the encryption key in the manifest [08:47:05 CEST] <JEEB> *get the key [08:47:42 CEST] <sector_surfer> erm. how to I obtain the key? [08:48:34 CEST] <JEEB> most likely not at all, or through one of the implementations of the drm system [08:48:56 CEST] <sector_surfer> it uses a m3u8 manifest. is the key in there? [08:49:15 CEST] <JEEB> if it's non-drm, maybe? [08:49:43 CEST] <JEEB> although if it has references to fairplay etc then it's apple drm :p [08:50:34 CEST] <sector_surfer> Yes, it's fairplay [08:50:36 CEST] <sector_surfer> ugh [08:51:03 CEST] <sector_surfer> unfairplay [08:51:18 CEST] <JEEB> then you probably want to check if there's a dash manifest (usually .mpd) available as well [08:51:28 CEST] <sector_surfer> OK [08:51:37 CEST] <sector_surfer> one moment [08:51:49 CEST] <JEEB> that usually has pr/wv references but at least for those you have the browser module [08:52:13 CEST] <JEEB> that said, unless someone has coded you a thing using thta you are not getting decrypted stuff [08:53:07 CEST] <JEEB> so yea, with that I cannot help since I have not looked into it otherwise than since the interfaces are standardized it should be possible [08:53:42 CEST] <JEEB> and you can find people decrypting them on the interwebs since they end up shared :p [08:54:27 CEST] <sector_surfer> I've no idea where I should look [08:54:32 CEST] <JEEB> in other words, sample aes is a pita to implement, and it still doesn't help you with getting the key :p [08:55:29 CEST] <sector_surfer> hmmm, I've just checked, and there are no references to an .mpd file anywhere, only an .m3u8 [08:56:31 CEST] <JEEB> so the stream would only work on apple devices in that case? which is unlikely. [08:56:51 CEST] <sector_surfer> https://www.9now.com.au/murder-lies-and-alibis/season-1/episode-4 [08:57:03 CEST] <sector_surfer> will it let you play it? [09:03:15 CEST] <sector_surfer> Ah. I got the key? [09:03:22 CEST] <sector_surfer> er.. I mean. I got the key! [09:03:36 CEST] <sector_surfer> It's using an unsecured http server [09:04:24 CEST] <JEEB> if it's fairplay that's not the key most likely [09:05:29 CEST] <JEEB> if you can play it in a browser you should pay attention at what traffic it does, but with drm the key if in manifest is encrypted with another that you get from the fairplay or whatever server if your license is valid :p [09:07:14 CEST] <sector_surfer> #EXT-X-KEY:METHOD=SAMPLE-AES,URI="skd://assetId=df82c09b-3d62-44fc-94b0-ee9754cc4128 [09:08:26 CEST] <sector_surfer> variantId=fairplay",IV=0xca9cbfbf9b99af3a0962dab4d9282f68,KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1" [09:15:09 CEST] <sector_surfer> I give up........ for now [10:20:06 CEST] <MoziM> how to merge flv files with ffmpeg? [10:20:51 CEST] <MoziM> ffmpeg -f concat -safe 0 -i input.txt -c copy output gives me the error 'Line 1: unknown keyword 'flv'' [10:25:23 CEST] <MoziM> flv [10:34:28 CEST] <durandal_1707> MoziM: pastebin input.txt [10:44:19 CEST] <MoziM> durandal_1707: https://termbin.com/3rkoz [12:12:39 CEST] <MoziM> durandal_1707: any ideas? i can get images to work fine but trying to concat video clips is always failing... [12:16:33 CEST] <durandal_1707> MoziM: dunno, check that you have valid ascii chars there [12:17:08 CEST] <durandal_1707> the error given does not make sense [12:47:08 CEST] <k-man> a while ago i used the libfdk_aac codec to encode some files - but in debian buster, I don't seem to have that encoder available in ffmpeg [12:47:17 CEST] <k-man> any ideas on how to work around this? [12:47:23 CEST] <pink_mist> compile ffmpeg yoursefl [12:47:25 CEST] <pink_mist> *self [12:48:00 CEST] <k-man> pink_mist: yeah, I have a vague memory of doing that once before [12:48:03 CEST] <k-man> must have been what I did [12:49:12 CEST] <pink_mist> some of the things ffmpeg can be built with will not allow debian to actually distribute the binary legally, so they don't build with everything [12:49:35 CEST] <pink_mist> dunno if that's the case for libfdk_aac or not though [12:49:53 CEST] <k-man> righto [12:49:55 CEST] <k-man> thanks pink_mist [13:43:19 CEST] <Kadigan_KSB> pink_mist, k-man - it is. libfdk-aac has a non-GPL-compatible license (https://trac.ffmpeg.org/wiki/Encode/AAC) [13:43:47 CEST] <JEEB> yes, so the combined work cannot be distributed [13:44:25 CEST] <Kadigan_KSB> It's also absolutely fabulous, and usually the reason I go through the pain of setting up a build env. :) [13:44:55 CEST] <JEEB> thankfully the internal AAC encoder is no longer audible pop bad [13:44:59 CEST] <JEEB> so I generally just use it [13:45:22 CEST] <JEEB> I do have some use cases where I need fdk-aac with, and in those cases I build myself on a box [13:45:30 CEST] <JEEB> or just make it not need any GPL components [13:45:33 CEST] <JEEB> like libx264 [13:45:49 CEST] <JEEB> since LGPL + fdk-aac license seems to be kind of OK? [13:45:57 CEST] <Kadigan_KSB> Eh, we've gotten used to it, and I figure - I'm not all that Linux-savvy, might as well take the exercise when it shows up. Also, first tentative steps in cross-compiling for Win-x64 and all that. [13:46:06 CEST] <JEEB> sure [13:46:11 CEST] <JEEB> learning to cross-compile is generally worth it [13:46:22 CEST] <JEEB> I moved to that when FFmpeg's configure script took 10+ min to finish :P [13:46:25 CEST] <JEEB> (on native windows) [13:46:46 CEST] <JEEB> thankfully a nice soul then improved that, but at that point I already had my cross-compilation setup done [13:47:06 CEST] <JEEB> also I do publish some of my binaries so I keep fdk-aac 100% separate from any GPL sysroots [13:47:21 CEST] <Kadigan_KSB> Yeah, I never got through it, <native> Windows or not... thankfully my Linux (and Linux-like) boxes now outnumber my Windows boxes, so I have plenty of hardware to use for it. [13:48:00 CEST] <Kadigan_KSB> It's kind of funny. I'm mainly a Windows guy, and that's my primary desktop. And yet... :D [13:48:04 CEST] <Kadigan_KSB> But anyway. [13:54:29 CEST] <k-man> i rememeberd i used a build script from github before [13:54:37 CEST] <k-man> just used that [13:54:43 CEST] <k-man> had to fix a bug in it first though [13:55:30 CEST] <k-man> so i'm trying to convert mp3 to m4b files. is there some way, in the ffmpeg command to encode the new file at the same bitrate as the source file? [13:57:00 CEST] <JEEB> no, and it shouldn't matter [13:57:15 CEST] <JEEB> having the same bit rate after already once lossily encoding a thing doesn't mean anything [13:59:56 CEST] <k-man> oh yes, i agree with that. i just want to avoid the m4b files being much larger than the source mp3 files [16:26:13 CEST] <MoziM> how to remove duplicate frames but keep the time scale? [16:47:44 CEST] <kepstin> MoziM: https://ffmpeg.org/ffmpeg-filters.html#mpdecimate [16:55:16 CEST] <nine_milli> blb [17:01:10 CEST] <N4ppeL> hey, does anyone know about an option to "just use decoding" on ffmpeg CLI? some codecs support output format "rawvideo", which I suppose is exactly that, but somehow not all codecs do (on a potential target environment I have a ffmpeg with only h264 available and it doesnt list rawvideo as supported format) Internally it is however always handled [17:01:11 CEST] <N4ppeL> with raw data and I was wondering if there is a way to grab that data and send it to a canvas for display [17:12:21 CEST] <BtbN> So... you want a video player? [17:14:21 CEST] <N4ppeL> well a bit more than that, but yes, I need the display-ready frames from the encoded mp4 file [17:16:01 CEST] <BtbN> Well, all decoders output some raw pixel data, in various formats, but most commonly yuv420p or nv12 [17:16:13 CEST] <BtbN> You can do with it whatever you please [17:16:55 CEST] <N4ppeL> but how can i use just the decoder using ffmpeg CLI? [17:17:10 CEST] <N4ppeL> ffmpeg always wants an output format and the ones supported with that build are always encoded again [17:17:25 CEST] <BtbN> Sure, but it's relatively pointless, cause it'll just throw the decoded frames away if you don't send them anywhere [17:17:55 CEST] <BtbN> What are you actually trying to do? On-Disc raw pixel data isn't usually very useful, due to its sheer size [17:18:07 CEST] <N4ppeL> well I would send it to a output file / framebuffer [17:19:18 CEST] <BtbN> Use the rawvideo "encoder" [17:19:30 CEST] <BtbN> But like I said, raw pixel data for any video is _huge_ [17:19:40 CEST] <BtbN> and likely can't be read from or written to disk in real time [17:20:11 CEST] <N4ppeL> yeah i know, videos are only 2s 512x512 and there should be a maximum of 6-9 videos displayed simultaneously, so I suppose its managable [17:20:39 CEST] <BtbN> What are you _actually_ trying to do? [17:20:48 CEST] <N4ppeL> problem with players is they wont synchronize the videos [17:21:07 CEST] <N4ppeL> so i need to handle framebuffers manually [17:21:20 CEST] <BtbN> So your actual problem is you want to play a bunch of videos in a mosaic in sync? [17:21:39 CEST] <N4ppeL> yeah I guess [17:21:46 CEST] <BtbN> Cause there's a filter for that [17:22:07 CEST] <N4ppeL> mh [17:22:08 CEST] <BtbN> That turns multiple input videos into one output video with the inputs tiled/overlaid/whatever [17:22:19 CEST] <N4ppeL> well the thing is sources change [17:22:40 CEST] <BtbN> so? [17:23:01 CEST] <N4ppeL> I have one huge video 4096x4096 which isnt streamable obviously so the full resolution is only displayed when you zoom in [17:23:12 CEST] <N4ppeL> i cant just encode one video in advance ;) [17:23:28 CEST] <BtbN> You'll have to write custom software for that then [17:23:42 CEST] <N4ppeL> yep [17:24:09 CEST] <N4ppeL> but as said, the ffmpeg built with only h264 codec cant "encode" rawvideo (doesnt support format rawvideo) [17:24:13 CEST] <N4ppeL> but then there is no other way ? [17:24:33 CEST] <BtbN> That's really nothing you can hack together with a bunch of shell scripting with the ffmpeg cli, you need a proper software [17:25:43 CEST] <N4ppeL> yeah but at somepoint i need decoding functionality from somewhere [17:26:11 CEST] <BtbN> Use libavcodec directly [17:27:55 CEST] <N4ppeL> hm yeah. If I want to do that I have to build it myself [17:30:59 CEST] <BtbN> ? [17:31:19 CEST] <BtbN> You have to build your own software yourself either way [17:31:28 CEST] <BtbN> And apparently already have a custom built ffmpeg cli tool [17:31:42 CEST] <N4ppeL> yeah that was already built [17:31:47 CEST] <N4ppeL> not by me [17:32:25 CEST] <N4ppeL> but yeah if there's no option for what I need in what I already have i need to build new stuff, sure :D [17:32:57 CEST] <N4ppeL> thanks anyway :) [18:02:13 CEST] <NoImNotNineVolt> so i'm using avconv to try to transcode a s16le audio stream from stdin to an rtp output... [18:02:53 CEST] <NoImNotNineVolt> e.g. `rtl_fm -f 104300000 -M wbfm -s 200000 -r 48000 - | avconv -f s16le -i pipe:0 -acodec libmp3lame -ab 32k -ac 1 -f rtp rtp://192.168.1.42:1234`, and i'm getting "Value inf for parameter 'time_base' out of range" errors [18:03:59 CEST] <NoImNotNineVolt> my understanding is that time_base is supposed to be 1/sample_rate, but every time i try to pass that in to avconv explicitly, i get "Codec AVOption time_base () specified for output file #0 (rtp://192.168.1.42:1234) is not an encoding option." [18:04:54 CEST] <NoImNotNineVolt> (i can `| aplay -r 48000 -f S16_LE` the output of rtl_fm just fine) [18:05:17 CEST] <NoImNotNineVolt> any ideas? [18:15:58 CEST] <kepstin> NoImNotNineVolt: this is the ffmpeg channel, we don't support avconv here. If you retry with ffmpeg, please give us the *complete* log output of the command (use a pastebin site) [18:19:10 CEST] <kepstin> NoImNotNineVolt: i dunno about avconv, but ffmpeg defaults to 1-channel, 44.1kHz sample rate on the input - you need to make sure you specify -sample_rate and -channels as input options. [18:21:09 CEST] <nine_milli> blb [19:25:56 CEST] <MoziM> i deleted all duplicate frames in my video using the following ffmpeg -i output.mp4 -vf mpdecimate,setpts=N/FRAME_RATE/TB compressed_output.mp4 and the output video had these stats https://termbin.com/da6g [19:26:13 CEST] <MoziM> but when i try to play it in a video player i can't skip ahead very well... but it plays fine [19:27:11 CEST] <MoziM> also when i try to skip to the end nothing is playing :\ i'm guess the actual video's length is smaller than the container it's in? sorry if that's not the correct way of describing it [19:32:14 CEST] <NoImNotNineVolt> kepstin: -sample_rate, that did it, thanks! [19:33:09 CEST] <kepstin> MoziM: i'm not sure what you're trying to do with that setpts filter... [19:33:25 CEST] <kepstin> MoziM: if you want the video to play back at the same speed as originally, just delete that setpts. [19:47:35 CEST] <NoImNotNineVolt> so, maybe `-f rtp rtp://somehost:1234` isn't what i want... just read https://trac.ffmpeg.org/wiki/StreamingGuide and apparently i should get one more piece. [20:42:17 CEST] <NoImNotNineVolt> okay, so, i guess that's where i'm lost. the streaming guide specifically recommends nginx-rtmp-module but doesn't suggest what kind of output to feed it. [20:43:05 CEST] <NoImNotNineVolt> e.g. do i just `-f rtp rtp://localhost:1935/live` my ffmpeg if i've done the basic nginx-rtmp-module config? [20:47:37 CEST] <kepstin> the nginx rtmp module takes, as you might imagine, rtmp input [20:49:15 CEST] <furq> NoImNotNineVolt: rtmp is h264/aac in flv [20:49:22 CEST] <furq> but if you're only streaming audio then why not use icecast [20:59:30 CEST] <NoImNotNineVolt> because i've heard of nginx but not icecast? :P [21:00:27 CEST] <NoImNotNineVolt> icecast it is. [21:09:06 CEST] <JEEB> &34 [21:17:31 CEST] <NoImNotNineVolt> so close! i'm getting audio through to a client running vlc player... but the pitch is all off :P [21:22:20 CEST] <NoImNotNineVolt> there we go. sample rate / channel settings were off. [21:22:36 CEST] <NoImNotNineVolt> thanks for the ffmpeg help and icecast recommendation. [21:32:33 CEST] <whitestone> hello [21:33:21 CEST] <whitestone> does someone know when using the hls demuxer to not use the last segment of video? [21:33:31 CEST] <whitestone> i know is witth the option live_start_index [21:33:57 CEST] <DHE> if it's a live stream, the default is to start close to the end so as to give that "live" feeling [21:34:02 CEST] <whitestone> and the negative values are from the end [21:34:38 CEST] <whitestone> yes its a live stream [21:35:05 CEST] <whitestone> i am downloading a HLS from youtube and i am creating a local repository in HLS too [21:35:53 CEST] <DHE> if you're writing your own HLS, setting the video type to EVENT (-hls_playlist_type event) is probably what you want. it allows for a live stream but users will be encouraged to start playback from the beginning [21:36:11 CEST] <whitestone> but, i am a little short of resources [21:37:15 CEST] <whitestone> yes, the second process is taking the local repository and is putting it in a decklink card [21:37:48 CEST] <whitestone> but sometimes the second process goes faster than the one is decoding the HLS from youtube [21:38:04 CEST] <whitestone> so i want to give to the second process a little of delay [21:39:11 CEST] <whitestone> i didnt find examples about what i want to do in the internet, thats because i am asking here [21:43:33 CEST] <whitestone> does someone know how to use that option [21:43:34 CEST] <whitestone> ? [22:06:36 CEST] <nine_milli> blb [23:05:01 CEST] <Trieste> Hi, if I do `ffmpeg foo bar.wav` and `ffmpeg foo -f wav - > baz.wav`, the bar.wav and baz.wav files are same size, but differ in a couple of bytes (seemingly just in the header), what gives? [23:05:31 CEST] <Trieste> (wouldn't care if it didn't mean that the next tool fails on baz.wav but not on bar.wav for some reason) [23:06:57 CEST] <durandal_1707> both commands are invalid iiuc [23:07:36 CEST] <howaboutsynergy> hey uhm, does anyone wanna apply this patch? https://trac.ffmpeg.org/attachment/ticket/4749/handlebit_size0.patch or a more up to date(with git) one: https://github.com/howaboutsynergy/q1q/blob/998b270964ea1ca79ecc2d94e7a4362… [23:08:04 CEST] <howaboutsynergy> it's supposed to handle the case when bit_size == 0 (too) [23:08:41 CEST] <howaboutsynergy> 'cause you know, that should (also) return AVERROR_INVALIDDATA; [23:10:44 CEST] <JEEB> howaboutsynergy: that looks like a ticket that nobody went back to 4 years ago... [23:11:04 CEST] <howaboutsynergy> the patch tho? :) [23:11:16 CEST] <howaboutsynergy> doesn't it make sense? [23:12:02 CEST] <JEEB> do you have a case which makes it bork. that makes checking things much simpler [23:12:24 CEST] <howaboutsynergy> I don't [23:12:43 CEST] <furq> Trieste: looks like the wav muxer writes some values to the header at the end [23:12:51 CEST] <furq> which it obviously can't do if the output isn't seekable [23:12:52 CEST] <JEEB> also the patch by itself isn't really self-documenting and at least the github patch has no author/commit message info [23:13:51 CEST] <howaboutsynergy> JEEB, ah you mean it should've been made via `git format-patch` to be considered? [23:13:56 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/wavenc.c#L408 [23:14:23 CEST] <Trieste> furq, oh right [23:17:12 CEST] <JEEB> howaboutsynergy: or otherwise having that information [23:17:24 CEST] <JEEB> howaboutsynergy: also fyi the development *of* FFmpeg channel is #ffmpeg-devel [23:17:34 CEST] <howaboutsynergy> oh [23:17:41 CEST] <JEEB> this is the user facing channel and a lot of developers aren't here, unfortunately [23:17:48 CEST] <howaboutsynergy> oh right, it's in the title too [23:17:58 CEST] <howaboutsynergy> thanks! [00:00:00 CEST] --- Wed Jul 17 2019

1 0

ffmpeg-devel.log.20190715
by burek 16 Jul '19

16 Jul '19

[03:22:47 CEST] <cone-905> ffmpeg 03Jun Zhao 07master:af5f77011321: doc/codecs: Add missing documentation for nointra [03:46:27 CEST] <Compn> btw a better email for the photosensitive patch might be thecybershadow+ffmpeg(a)gmail.com [03:46:46 CEST] <Compn> if someone can relay that to the ml for me, i dont have mail stuff setup [11:53:02 CEST] <durandal_1707> j-b: found IMM5 with HEVC instead of H264 in the wild [11:53:11 CEST] <j-b> O_O [15:58:55 CEST] <cone-962> ffmpeg 03Steven Liu 07master:234a5e058d7b: avformat/hlsenc: use old way for fragment mp4 in HLS PUT method [15:58:56 CEST] <cone-962> ffmpeg 03Steven Liu 07master:ac22835db947: fate: add hls fmp4 segment type test case [16:20:41 CEST] <cone-962> ffmpeg 03James Almer 07master:7cb4f8c962bd: avcodec: remove reference to AVPacket's destruct field [16:28:01 CEST] <durandal_1707> jamrial: when you gonna apply matroska patches? [16:34:24 CEST] <jamrial> durandal_1707: you can look at them and push them as well, you know? :p [23:38:43 CEST] <durandal_1707> mkver: ask michaelni to give you commit rights [23:41:49 CEST] <jamrial> imm5_decoder_select="h264_decoder hevc_decoder" [23:41:54 CEST] <jamrial> what? [23:42:22 CEST] <jamrial> holy shit, what is this codec? [23:42:54 CEST] <durandal_1707> special CCTV codec for Police force [23:47:34 CEST] <mkver> Are you intentionally not sending the timing info to the decoder? [23:48:09 CEST] <durandal_1707> mkver: i feel stupid right now, what you mean exactly? [23:48:39 CEST] <Lynne> no need for one if all frames are intra frames [23:48:44 CEST] <mkver> You use a new packet structure and don't simply send the provided packet to the decoder. [23:49:11 CEST] <mkver> The approach you use implies that data might be copied even when the original packet was refcounted. [23:49:37 CEST] <jamrial> not might, will [23:49:47 CEST] <jamrial> since he's sending a non ref counted packet to send_frame [23:49:53 CEST] <jamrial> so it will be made refcounted, copying data [23:50:26 CEST] <durandal_1707> can i reuse old packet somehow? [23:51:18 CEST] <Lynne> can't this be handled in lavf? [23:51:29 CEST] <mkver> You could just send avpkt and remove hpkt completely. [23:52:11 CEST] <nevcairiel> he modifies the packet content in various cases, that needs handling still then [23:52:11 CEST] <jamrial> mkver: there's the case where he uses imm5_buffer. in that case he does need a new packet [23:53:19 CEST] <jamrial> unless he can just use an offset to change avpkt data and size [23:53:29 CEST] <kierank> durandal_1707: interesting design [23:53:50 CEST] <jamrial> this is kinda awful either way [23:54:19 CEST] <durandal_1707> kierank: coders called themself "Zeus team" iiuc [23:54:21 CEST] <kierank> is this not doable using a parser [23:54:57 CEST] <durandal_1707> kierank: nope, you mean bitstream filter [23:55:15 CEST] <kierank> can't parsers drop data? [23:55:23 CEST] <durandal_1707> nope [23:55:39 CEST] <durandal_1707> michaelni forbids it [23:57:04 CEST] <durandal_1707> if you guys have some good solution, that enables DR1, I'm all ears [23:57:29 CEST] <Lynne> lavf? [23:57:55 CEST] <kierank> durandal_1707: it's part of the stream inside stream inside codec inside codec problem [23:58:02 CEST] <kierank> unfixable without ffmpeg rewrite [23:59:59 CEST] <durandal_1707> Lynne: lavf? you want to add big hack to AVI demuxer? [00:00:00 CEST] --- Tue Jul 16 2019

1 0

ffmpeg.log.20190715
by burek 16 Jul '19

16 Jul '19

[05:15:37 CEST] <nine_milli> blb [06:38:35 CEST] <KittyCat> I think I found an issue with libavcodec 58.35.100 (the current version in debian 10). I'm currently building the git version to see if the problem persists, but in the mean time, I figured to ask if it might be (or have been) a known issue [06:40:07 CEST] <KittyCat> basically, the issue is with some files (some VP9 videos, but not all), avcodec_send_packet and avcodec_receive_frame will both return AVERROR(EAGAIN) in succession, which the documentation says shouldn't ever happen [06:41:43 CEST] <KittyCat> once avcodec_receive_frame returns AVERROR(EAGAIN), avcodec_send_packet will then succeed, but not before [06:47:05 CEST] <KittyCat> the general flow in my program is it sends encoded packets until avcodec_send_packet gives AVERROR(EAGAIN), at which point I call avcodec_receive_frame to get a single frame. then it goes back and sends more encoded packets until AVERROR(EAGAIN), then receives another single frame [06:50:41 CEST] <KittyCat> hoever, I've noticed occasionally, I'll get a frame from avcodec_receive_frame, but the next call to avcodec_send_packet will return AVERROR(EAGAIN), as if there's still more frames to get and not enough space in the codec's internal buffer for another. but the following avcodec_receive_frame call will also return AVERROR(EAGAIN). [06:51:22 CEST] <KittyCat> once that happens, avcodec_send_packet will accept the packet fine [07:58:57 CEST] <KittyCat> still happens with latest git [09:20:49 CEST] <nine_milli> blb [15:26:43 CEST] <snooky> hi all [16:25:23 CEST] <kepstin> KittyCat: you need to call avcodec_receive_frame until it returns eagain. it might return multiple frames before accepting more packets [16:26:52 CEST] <kepstin> KittyCat: that is kinda weird behaviour tho, but it could just be internal state is messaged up because you weren't doing things in the expected order? [16:30:48 CEST] <JEEB> the dec/enc APIs have been documented rather well [16:31:12 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [16:31:24 CEST] <JEEB> so if something is not according to these general ideas, something might be welp [16:34:49 CEST] <kepstin> the docs do say "the only guarantee is that an AVERROR(EAGAIN) return value on a send/receive call on one end implies that a receive/send call on the other end will succeed, or at least will not fail with AVERROR(EAGAIN)." [16:34:58 CEST] <kepstin> which seems not to be the case here :) [16:36:14 CEST] <kepstin> but the recommendation is that apps call the send() function once, then call receive() in a loop until it returns EAGAIN [16:37:48 CEST] <kepstin> KittyCat: if you have some reproducing code and a sample video, probably worth filing an issue for this. [17:04:45 CEST] <nine_milli> blb [18:21:24 CEST] <Polochon_street> Hi! I'm using ffmpeg for audio analysis, and I'm observing very subtle inconsistent results when I decode and resample the same song across different linux distros: I have an int16_t* array of samples, and, for the same song, they vary by usually just one depending on the distro [18:22:03 CEST] <Polochon_street> the decoding code is here https://github.com/Polochon-street/bliss/blob/master/src/decode.c ; do you think it's ffmpeg-related, and I'm forgetting a rounding argument or something, or it's just platform-specific and nothing can be done about it? [18:25:58 CEST] <zap0> smells like floating point rounding [18:26:37 CEST] <zap0> " vary by usually just one" one what? [18:27:43 CEST] <Polochon_street> f.ex. p ((int16_t*) song->sample_array)[7] gives 1180 on one distro and 1181 on the other one [18:34:48 CEST] <kepstin> what input codec and ffmpeg versions are you looking at? [18:34:53 CEST] <cehoyos> It is very unlikely that the difference you see is due to the "distro" [18:35:21 CEST] <cehoyos> Possible reasons are different FFmpeg versions, different hardware and different compiler (options) [18:36:45 CEST] <Polochon_street> the file is mp3, and I'm not using the same ffmpeg version on the different distros [18:36:55 CEST] <Polochon_street> so I guess that would explain the behavior [18:37:06 CEST] <kepstin> iirc you might be getting a float vs int mp3 decoder in different versions and setups [18:37:24 CEST] <cehoyos> You do know that the default mp3 decoder outputs floats (not int16_t)? [18:37:47 CEST] <Polochon_street> cehoyos: I'm converting whatever I get to `int16_t` as pre-processing [18:38:09 CEST] <cehoyos> This conversion depends on the hardware, not the distro [18:38:40 CEST] <Polochon_street> hm, I guess this difference is explained then [18:38:43 CEST] <cehoyos> But if you are using different FFmpeg versions, this discussion is moot as mp3 decoding is not bit-exact by definition (there is no "correct" output) [18:38:52 CEST] <kepstin> Polochon_street: also consider trying the "-bitexact" option, which switches some algorithms in ffmpeg from "fasted available on this hardware" to "generic and reproducable" [18:38:54 CEST] <zap0> Polochon_street which floating point rounding method have you set for your compiler [18:38:56 CEST] <Polochon_street> thanks for the input :) [18:39:13 CEST] <kepstin> but i dunno if that'll help in this particular case, especially across a range of ffmpeg versions [18:39:40 CEST] <cehoyos> There is no *single* correct output, there are many correct outputs for mp3 decoding [18:39:53 CEST] <cehoyos> (Contrary to h264, hevc etc.) [18:40:06 CEST] <Polochon_street> so maybe using something with a single correct output for my tests would help? :D [18:40:18 CEST] <Polochon_street> zap0: whatever CMake use as default for gcc, I think [18:40:22 CEST] <cehoyos> Maybe using a single FFmpeg version would help [18:40:41 CEST] <Polochon_street> cehoyos: well, I don't control the ffmepg version used by my users :D [18:40:45 CEST] <kepstin> a single ffmpeg version in bitexact mode should provide the same results across different hardware. [18:41:04 CEST] <kepstin> in this case, the differences should be small enough to simply not matter :/ [18:41:23 CEST] <cehoyos> Well, you simply cannot expect bit-exact output for mp3 decoding just as you cannot expect one specific FFmpeg version from your users. [18:41:54 CEST] <Polochon_street> cehoyos: of course, that's why I'm saying that maybe changing my test file format is a first nice step :) [18:42:15 CEST] <kepstin> bitexact mode in ffmpeg just means "the same output regardless of hardware", not "a standardized output" :) [18:42:24 CEST] <cehoyos> (Note that bugs in - for example - flac decoding have been found in the past, so not even for formats that are bit-exact can you be sure that FFmpeg will return the right data) [18:42:42 CEST] <kepstin> but yeah, probably not worth looking at for this case [18:43:03 CEST] <Polochon_street> I could use bitexact for testing at least as well, yep [18:43:16 CEST] <cehoyos> I am not convinced that "bitexact" will fix the issue you see, but you can of course test, it will change some routines that are known to output different data [18:43:16 CEST] <Polochon_street> thanks for the input guys, much appreciated [18:43:27 CEST] <kepstin> cehoyos: for testing purposes, your input should really be a lossless format. I would recommend flac if you don't want to store plain wav files [18:44:00 CEST] <cehoyos> A format that has a "correct" output is sufficient imo [18:44:07 CEST] <cehoyos> a single correct output... [18:44:11 CEST] <kepstin> if you want to craft test input with exact sample values, then you can't use a lossy format because it won't preserve the sample values [18:44:26 CEST] <kepstin> otherwise a lossy format with a defined spec decoder output would work, yes [18:50:49 CEST] <Polochon_street> kepstin: WAV should do the trick, right? [18:51:20 CEST] <cehoyos> wav is a fileformat that can take many codecs, for example mp3 [18:51:23 CEST] <kepstin> wav (with pcm audio) would work, but it's kinda big :) [18:51:53 CEST] <Polochon_street> I have > song.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz [18:52:07 CEST] <kepstin> note also that resampling (sample rate conversion) isn't guaranteed to give the same output between ffmpeg versions either [18:52:08 CEST] <Polochon_street> I cut the file down to 10s to have a not-too-big file [18:52:29 CEST] <kepstin> so you'd want to pre-convert to 22050 to avoid having your program do a resample [18:52:45 CEST] <Polochon_street> good point [19:08:43 CEST] <nine_milli> blb [20:12:42 CEST] <glittershark> hi all - I posted on ffmpeg-user too, but figured I'd ask here as well - anyone ever see ffmpeg only return one frame when splitting a multi-minute video? [20:12:58 CEST] <glittershark> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2019-July/044797.html has my logs [20:20:31 CEST] <Mavrik> glittershark, you didn't write out your full command-line [20:20:41 CEST] <furq> it's halfway down the post [20:20:53 CEST] <furq> $ ffmpeg -i video.mpg -r 2 -s 640x480 'output/frame_%06d.jpg' [20:21:38 CEST] <glittershark> yeah, sorry, that text got pretty dense [20:28:20 CEST] <Mavrik> oh [20:28:40 CEST] <Mavrik> I have a suspicion that DTS errors might be at fault [20:29:21 CEST] <glittershark> yeah so do I [20:29:47 CEST] <Mavrik> Since your timestamps are all over the place [20:29:48 CEST] <Mavrik> :) [20:30:16 CEST] <glittershark> yeah >.> it's a pretty wild video [20:30:18 CEST] <glittershark> VLC plays it though [20:30:20 CEST] <Mavrik> Can you try reencoding the video to something like h.264 (ffmpeg -i <vid> -codec:v libx264 output.mp4) and see if it's still watchable? [20:30:50 CEST] <glittershark> will do [20:32:02 CEST] <glittershark> nope, output.mp4 is .03s long [20:32:19 CEST] <glittershark> https://pastebin.com/dEtPqqMC [20:39:49 CEST] <Mavrik> Yeah, it seems that ffmpeg's decoder hates that video then :( [20:41:12 CEST] <glittershark> dang [20:41:52 CEST] <zap0> in my experience, MP4 and anything less than 1sec is a bad combo. most players do not like it [20:42:17 CEST] <glittershark> The original video is 3 minutes long [20:42:21 CEST] <glittershark> it's just... very broken [20:43:24 CEST] <glittershark> If nobody on the mailing list has any ideas then this is for work, so I'll probably just get approval to throw money at someone on https://ffmpeg.org/consulting.html [20:43:43 CEST] <glittershark> was kinda holding out hope that someone had run into a video that had this exact problem before though :P [20:48:24 CEST] <Mavrik> glittershark, the other option is to just use vlc to convert the video to something else [20:48:29 CEST] <Mavrik> assuming that will repair the timestamps [20:48:33 CEST] <glittershark> hmm [20:48:39 CEST] <glittershark> vlc does conversion? [20:48:55 CEST] <glittershark> oh I guess from the UI [20:49:00 CEST] <glittershark> wonder if there's a CLI... [20:49:29 CEST] <Mavrik> there's also cli [20:49:33 CEST] <Mavrik> cvlc or something [20:49:42 CEST] <Mavrik> The commandline is pretty arcane, but UI can help assemble it [20:53:29 CEST] <glittershark> oh great [20:53:32 CEST] <glittershark> > main video output error: Failed to compensate for the format changes, removing all filters [20:53:36 CEST] <glittershark> VLC is giving up too [20:53:41 CEST] <glittershark> it still plays the video though... [21:05:42 CEST] <zap0> re-film it off the screen! [21:06:31 CEST] <glittershark> lol [21:06:37 CEST] <glittershark> xvfb here I come [21:07:38 CEST] <durandal_1707> -genpts [21:09:47 CEST] <glittershark> durandal_1707: you mean -fflags -genpts? [21:10:16 CEST] <glittershark> neither -fflags -genpts or -fflags +genpts work [21:17:03 CEST] <nine_milli> blb [21:27:40 CEST] <kepstin> glittershark: also consider trying "-vf fps=2" rather than the "-r 2" output option, the fps filter might have better behaviour here. [21:28:10 CEST] <kepstin> oh, hmm, probably won't help in this case :) [21:29:30 CEST] <kepstin> glittershark: hmm, i wonder if it maybe has an editlist? try using the "-ignore_editlist 1" input option. that could explain the weird start time and duration [21:29:57 CEST] <JEEB> I recommend just disabling the advanced edit list stuff [21:30:01 CEST] <JEEB> not edit list stuff completely [21:30:08 CEST] <JEEB> unless the mp4 file is borked [21:30:28 CEST] <JEEB> -advanced_editlist 0 [21:30:40 CEST] <JEEB> sad that you have to set this stuff, but we can all thank GOOG for it :P [21:38:45 CEST] <lmat> whoa, ffplay got an overhaul! (command line UI anyway...) Looks good! [21:49:22 CEST] <glittershark> Disabling editlist didn't help, unfortunately [21:49:32 CEST] <glittershark> thanks for the suggestion though kepstin + JEEB [22:14:26 CEST] <cehoyos> glittershark: Please provide your input file [22:36:57 CEST] <durandal_1707> cehoyos: he can not share private files [22:37:21 CEST] <cehoyos> Then how is the issue supposed to be fixed? [22:41:12 CEST] <durandal_1707> cehoyos: clairvoyance [22:46:51 CEST] <pink_mist> he did say he would probably get approval to throw money at a contributor who presumably would be allowed to see the file after signing enough of his soul away [22:53:17 CEST] <cehoyos> This does not sound like a smart move to me (but it isn't my money) [22:53:56 CEST] <pink_mist> you're one of the ones listed under consulting.html aren't you? so it potentially could be your money :P [22:54:29 CEST] <cehoyos> I doubt it... [23:40:48 CEST] <Thomas_J> I need to ad a 2 second delay for audio input and "-itsoffset 2"doesn't seem to be working for me. when I add this to the command string, I get silence with a short audio burst at about every 2 second intervals. [23:42:31 CEST] <durandal_1707> Thomas_J: you probably need adelay filter [23:46:00 CEST] <Thomas_J> If I use a delay filter on audio input, this won't try to decode the video stream, will it? [23:47:00 CEST] <Thomas_J> Could I just increase the audio input buffer size? [23:47:01 CEST] <kepstin> you can filter audio (re-encoding it) while using -c:v copy at the same time [23:47:24 CEST] <durandal_1707> itsoffset is global for both audio and video last time i checked [23:47:48 CEST] <Thomas_J> Good. My audio in is a seperate input off of a captyre device. [23:48:26 CEST] <cehoyos> It is possible that itsoffset does not like "live" input [23:58:55 CEST] <nine_milli> blb [00:00:00 CEST] --- Tue Jul 16 2019

1 0

ffmpeg-devel.log.20190714
by burek 15 Jul '19

15 Jul '19

[06:10:48 CEST] <Compn> also, its nice that michaelni found an interesting usecase bug in the new filter [11:19:28 CEST] <Guest80733> ls [12:44:33 CEST] <ePirat> oops forgot I can't edit tickets on ffmpeg and now the description is a bit weird& whatever [12:58:07 CEST] <nevcairiel> why can you not edit tickets [14:43:21 CEST] <Lynne> what's the point of vpermilps taking an imm8 when it becomes just a slower shufps? [14:49:06 CEST] <jamrial> Lynne: one source reg instead of two [15:02:07 CEST] <Lynne> also 1 more byte [17:05:03 CEST] <jamrial> robUx4: are you planning to push your hevc/h264 sei patches? [17:16:19 CEST] <cone-234> ffmpeg 03Paul B Mahol 07master:37e69b40dfd1: avfilter/vf_blend: add 9bit support [17:23:40 CEST] <robUx4> jamrial: it would be nice, I don't remember the state of the review [17:29:50 CEST] <jamrial> robUx4: i lgtm both of them weeks ago :p [17:30:11 CEST] <cone-234> ffmpeg 03Paul B Mahol 07master:3d78ad43f781: avfilter/vf_threshold: use time_base from framesync [17:40:30 CEST] <cone-234> ffmpeg 03Paul B Mahol 07master:74236f675eb4: avfilter/vf_maskedmerge: always use framesync timestamps [17:47:17 CEST] <cone-234> ffmpeg 03Paul B Mahol 07master:6882427841e6: avfilter/vf_midequalizer: always use framesync timestamps [17:55:46 CEST] <robUx4> jamrial: ok then whoever can push... [17:56:32 CEST] <jamrial> robUx4: you don't have push access? [17:56:40 CEST] <jamrial> i can do it, but i assumed you did [18:05:29 CEST] <cone-234> ffmpeg 03Steve Lhomme 07master:f2ad6238e4c0: avcodec/hevcdec: set the SEI parameters early on the AVCodecContext [18:05:30 CEST] <cone-234> ffmpeg 03Steve Lhomme 07master:8788dd67b851: avcodec/h264_slice: set the SEI parameters early on the AVCodecContext [18:05:32 CEST] <robUx4> I don't think so [18:05:35 CEST] <robUx4> thanks [18:23:08 CEST] <cone-234> ffmpeg 03Paul B Mahol 07master:077bf9058f16: avfilter/vf_displace: use time_base from framesync [18:23:09 CEST] <cone-234> ffmpeg 03Paul B Mahol 07master:be822eb6f880: avfilter/vf_remap: use time_base from framesync [18:23:09 CEST] <cone-234> ffmpeg 03Paul B Mahol 07master:54fc8d370eb8: avfilter/vf_remap: add option to control output format [18:32:10 CEST] <cone-234> ffmpeg 03Paul B Mahol 07master:166977a200a1: doc/filters: document new remap filter option [19:15:52 CEST] <cone-234> ffmpeg 03Paul B Mahol 07master:97698b15a2b5: avfilter/vf_hysteresis: use time_base from framesync [23:06:54 CEST] <cone-956> ffmpeg 03Andreas Rheinhardt 07master:3469cfab4adb: dump_extra: Don't add extradata if it already exists [23:06:54 CEST] <cone-956> ffmpeg 03Michael Niedermayer 07master:84669b187226: avcodec/iff: Add "else" to make code look prettier [23:06:54 CEST] <cone-956> ffmpeg 03Michael Niedermayer 07master:62d10ec35c30: avformat/vividas: Fixes overflow in shift in recover_key() [23:06:54 CEST] <cone-956> ffmpeg 03Michael Niedermayer 07master:39a6a79bcbe3: avformat/xmv: Make bitrate 64bit [00:00:00 CEST] --- Mon Jul 15 2019

1 0

ffmpeg.log.20190714
by burek 15 Jul '19

15 Jul '19

[02:14:10 CEST] <nine_milli> blb_ [09:02:00 CEST] Last message repeated 1 time(s). [17:28:28 CEST] <hypercore> is ffmpeg multicore? [17:28:38 CEST] <durandal_1707> yes [17:28:56 CEST] <hypercore> durandal_1707: is it a good use case for creating animated gifs with text? [17:29:09 CEST] <durandal_1707> gifs are history [17:29:11 CEST] <hypercore> (if my goal is to minimize render time) [17:33:38 CEST] <hypercore> durandal_1707: assuming it has to be gifs, would ffmpeg be a good tool for this? [17:34:10 CEST] <durandal_1707> depends what exactly you need [17:35:56 CEST] <hypercore> durandal_1707: i want to create a gif which shows each word from a string [17:35:58 CEST] <pink_mist> hypercore: unlikely that you'll see any benefit from multicore ... making gifs should be very light on resource usage ... your bottleneck will probably be reading the input data from disk and writing the output data back out to disk I bet ... nothing that using multiple cores will do anything about [17:37:05 CEST] <hypercore> pink_mist: oh ok, so an nvme would be more beneficial? [17:37:12 CEST] <pink_mist> probably [17:37:39 CEST] <pink_mist> I mean, I can't say for certain since I've never benchmarked it [17:37:42 CEST] <pink_mist> but that would be my guess [17:38:53 CEST] <hypercore> pink_mist: i did try this a while ago using some c++ library, and from what i recall it took quite a few seconds to create a gif like this (consisting of several hundred images), but i never considered my bottleneck was IO [17:39:20 CEST] <hypercore> (this was on my laptop using a conventional ssd) [17:41:05 CEST] <pink_mist> well I can't speak about some c++ library I don't even know the name of - it might be inefficient as hell for all I know :P but for ffmpeg, assuming your CPU isn't from the 486 era I wouldn't expect the bottleneck to be CPU time [17:43:02 CEST] <hypercore> pink_mist: can ffmpeg be used to generate the image files that the gif consists of ? [17:43:33 CEST] <pink_mist> I don't know .. probably depends on what your input data is [17:43:34 CEST] <hypercore> i.e. can it render some text to a (newly created image) [17:43:41 CEST] <hypercore> just a word [17:43:55 CEST] <hypercore> ie. [a-z] [17:44:03 CEST] <hypercore> well [A-Za-z] [17:44:18 CEST] <hypercore> probably digits too [17:44:26 CEST] <pink_mist> I would expect that you could put it in some subtitle format, and have libass render it into a video frame which ffmpeg could give you as an image [17:44:42 CEST] <pink_mist> assuming your ffmpeg is built with libass support [17:45:07 CEST] <pink_mist> I've never looked into that kind of thing though, so I don't rightly know [17:45:25 CEST] <pink_mist> better to ask other people here [18:06:25 CEST] <hypercore> pink_mist: ok thanks anyway [20:04:48 CEST] <nine_milli> blb_ [20:07:57 CEST] <joelkraehemann> hi all [20:08:20 CEST] <joelkraehemann> I would love to do a screencast using my nvidia quadro 2000 and ffmpeg [20:08:54 CEST] <joelkraehemann> I just don't get the desired framerate of 30fps for my 4k display ... [20:09:06 CEST] <joelkraehemann> I just get 12fps :/ [20:13:42 CEST] <joelkraehemann> https://developer.nvidia.com/ffmpeg [20:13:48 CEST] <joelkraehemann> ^^ just found this [22:49:41 CEST] <nine_milli> blb_ [00:00:00 CEST] --- Mon Jul 15 2019

1 0

ffmpeg-devel.log.20190713
by burek 14 Jul '19

14 Jul '19

[00:10:10 CEST] <michaelni> Compn, testing for "no change" is a good idea [01:00:28 CEST] <Compn> brb [12:30:27 CEST] <cone-917> ffmpeg 03Paul B Mahol 07master:60e6db2f5bf6: avfilter/af_aiir: do not ignore k option for audio filtering [12:46:12 CEST] <Mathieu_Du> Hey o/ [12:46:23 CEST] <JEEB> ohai [12:47:29 CEST] <Mathieu_Du> I've got a follow-up patch to a patch I initially got merged that's been stuck for quite some time, was wondering if someone could give it a look again, it's really simple :) [12:47:49 CEST] <Mathieu_Du> mail thread is "mpeg12enc: Use all Closed Captions side data" [12:53:53 CEST] <JEEB> I will guess you already pinged it on the ML? [13:08:40 CEST] <Mathieu_Du> yep, a few times [13:32:38 CEST] <JEEB> anyways, I'll not be able to do much today but I will attempt to check it out tomorrow if nobody's poked it by then [13:50:37 CEST] <Mathieu_Du> thanks JEEB :) [14:44:25 CEST] <cone-917> ffmpeg 03Michael Niedermayer 07master:1dbb67d39b21: avcodec/mpc8: Fixes invalid shift in mpc8_decode_frame() [14:44:26 CEST] <cone-917> ffmpeg 03Michael Niedermayer 07master:9b5249a441a3: tools/target_dec_fuzzer: Remove redundant av_free() [14:44:27 CEST] <cone-917> ffmpeg 03Michael Niedermayer 07master:6aaa01afe4fb: avcodec/huffyuv: remove gray8a (the format is listed but not supported by the implementation) [14:44:28 CEST] <cone-917> ffmpeg 03Michael Niedermayer 07master:9ffa32b81bed: avcodec/huffyuvdec: Check vertical subsampling in hymt [14:44:29 CEST] <cone-917> ffmpeg 03Michael Niedermayer 07master:18c808ffbed8: avcodec/pngdec: Check that previous_picture has same w/h/format [15:47:08 CEST] <cone-917> ffmpeg 03Paul B Mahol 07master:80dacbedbacf: avfilter/af_aiir: calculate group delay too [19:08:39 CEST] <cone-913> ffmpeg 03Andreas Rheinhardt 07master:a2572e3c670d: avformat: Don't suggest deprecated function [20:51:40 CEST] <cone-913> ffmpeg 03Jernej Fijacko 07master:f86f213a6d3d: avcodec/dvbsub: add support for Display Definition Segment to DVB Subtitle encoder [22:31:40 CEST] <Compn> durandal_1707, you know its easier to ignore other people's comments than to fight them right ? [00:00:00 CEST] --- Sun Jul 14 2019

1 0

ffmpeg.log.20190713
by burek 14 Jul '19

14 Jul '19

[00:25:10 CEST] <iive> linext, yep. [01:22:03 CEST] <linext> iive, i was looking for the next episode but there appears to not be one [01:22:57 CEST] <iive> just 12 episodes and incomplete story. I guess S3 would carry on. [02:05:21 CEST] <nine_milli> blb_ [02:13:49 CEST] <bray90820> So I have an mkv that i converted with ffmpeg -i "video.mkv" -c copy "video.mp4" which plays VLC but won't play in quicktime [02:18:20 CEST] <another> depends on the codecs i guess [02:18:49 CEST] <bray90820> Also the same video that I coped with "video.mkv" -c:a copy "video.mp4" had audio issues the volume changes in Quicktime but not VLC [02:19:29 CEST] <bray90820> another: Would mkv and mp4 be the codecs [02:23:20 CEST] <bray90820> So no the codec is AC3 for both videos at least for the audio [02:23:26 CEST] <bray90820> mpgv for video [02:31:46 CEST] <another> mkv and mp4 are containers [02:43:12 CEST] <bray90820> Yes that's why I corrected myself [02:43:36 CEST] <bray90820> So why is the video weird in quicktime and fine in VLC [02:49:44 CEST] <iive> ac3 have dymaic range compression. probably you get normal sound too low and then too strong explosions and stuff. in that case... they made it that way. vlc kind of "normalize" the sound level. [02:50:39 CEST] <iive> as for the video... what is the video codec? [03:11:19 CEST] <kepstin> bray90820: it just might be that the video codec settings aren't compatible with quicktime. [03:11:51 CEST] <kepstin> bray90820: if i could see the output from ffmpeg when you did the conversion, i could probably say why it didn't work [07:09:10 CEST] <SoItBegins> Im trying to use the tpad filter but ffmpeg says it doesnt exist. Huh? [07:28:19 CEST] <furq> SoItBegins: that filter isn't in any release yet [07:28:36 CEST] <SoItBegins> furq: Yeah, figured it out. Trying to install HEAD now. [09:07:46 CEST] <nine_milli> blb_ [11:38:59 CEST] <MoziM> 23.976040 [17:58:21 CEST] <olavx200> I have a bunch of audio files which only outputs audio to one channel (right) and i would like to have the channel output audio to both channels (left and right). How can i modify the files to contain the same audio on the left as on the right. [18:00:04 CEST] <furq> olavx200: -af "pan=mono|c0=FR" [18:09:33 CEST] <olavx200> Thanks, that is what i am looking for. [19:49:46 CEST] <Thomas_J> I don't understand. I am inputing a camera streaming mp4 at 720p and using a -c:v copy for output. the video is going out at 640x480, 4:3 aspect and not 720p. [19:52:52 CEST] <Thomas_J> Could this be something that Facebook is insisting on during the handshake? [20:13:33 CEST] <furq> Thomas_J: no [20:13:50 CEST] <furq> either facebook is reencoding it or your camera isn't actually outputting 720p [20:14:16 CEST] <furq> there's no mechanism for a protocol to change the encoding parameters like that [20:14:54 CEST] <furq> also if this is a raspberry pi then i doubt it would be able to do realtime 480p x264 encoding [20:39:21 CEST] <friendofafriend> Thomas_J: What is your command line? You have to specify the image size when capturing from a camera by v4l. [20:41:17 CEST] <Thomas_J> I just looked at the debug out and found this which doesn't make sense. I have the camera set to 720p. ;;; [20:41:19 CEST] <Thomas_J> Stream #0:0, 0, 1/1000: Video: h264 (Main), 1 reference frame ([7][0][0][0] / 0x0007), yuvj420p(pc, bt709, progressive, left), 640x480 (0x0) [SAR 4:3 DAR 16:9], 0/1, q=2-31, 30 fps, 30 tbr, 1k tbn, 90k tbc [20:41:41 CEST] <Thomas_J> Metadata from the camera? [20:41:55 CEST] <friendofafriend> That's saying the camera is not set to 720p. [20:43:14 CEST] <friendofafriend> Use the video_size flag to explicitly set the size, like: ffmpeg -f v4l2 -framerate 25 -video_size 640x480 -i /dev/video0 output.mkv [20:43:19 CEST] <Thomas_J> Exactly, but I go to it's GUI and set it to 720p and it acknowledges this when set. [20:43:22 CEST] <friendofafriend> Check out https://trac.ffmpeg.org/wiki/Capture/Webcam [20:43:59 CEST] <Thomas_J> My input is an rtsp stream. [20:44:40 CEST] <friendofafriend> OK, then verify its output with: ffprobe "rtsp://whatever_the_uri" [20:44:52 CEST] <Thomas_J> Thanks [20:44:58 CEST] <friendofafriend> Always welcome. [20:48:13 CEST] <Thomas_J> Interesting. The camera's primary output is as I set it, 1080p but the secondary output has gone rogue. [20:48:52 CEST] <Thomas_J> This is no cheap camera but it is a POS. [20:49:21 CEST] <Thomas_J> It's an Amazon speciall. [20:51:48 CEST] <Thomas_J> If the primary is working properly then to heck with it. I intend to crop and resize the display port on the input anyway. [20:53:53 CEST] <Thomas_J> Irony is that I may just stream to Facebook with a final 640x480 anyway. It's just that the camera is scanning a 16:9 aspect and sending it as 4:3. [20:56:32 CEST] <Mysterytrain> I Have a buncha videos for which I want to rip out the audio. is there a way to tell ffmpeg to just grab the first audio stream? Normally I've been going: for i in *.mkv;do ffmpeg -i "$i" -map 0:1 -c:a mp3 "${i%mkv}mp3";done is there a shortcut to just do the first audiostream? [20:58:07 CEST] <Lyphe0> -map a:0 [21:01:11 CEST] <Mysterytrain> ah nifty [21:01:32 CEST] <DHE> I think you mean 0:a [21:02:16 CEST] <DHE> or maybe even 0:a:0 since 0:a has some selection logic, meaning what's 'first' is less consistent [21:06:57 CEST] <Mysterytrain> yeah my method doesn't always work, because sometimes 0:1 is subtitle or video and i have to ffprobe each video to double check that the audio streams are consistent throughout the batch [21:07:14 CEST] <Mysterytrain> so, that will help immensely :) [21:36:32 CEST] <Lyphe0> DHE: whats wrong with a:0? if theres only one input, its equivalent to 0:a:0, no? [22:03:39 CEST] <DHE> Lyphe0: I am unable to find anything in the ffmpeg-all.html indicating this is acceptabe to -map [22:06:30 CEST] <Lyphe0> read https://www.ffmpeg.org/ffmpeg-all.html#Stream-specifiers-1 [22:07:49 CEST] <DHE> that is specific to things like -c which might be annotated with -c:a:0, but not for -map [22:10:52 CEST] <Lyphe0> huh yeah, the according to the doc, and input file id is in fact mandatory [22:11:17 CEST] <Lyphe0> but hey, it works anyway, so ¯\_(Ä)_/¯ [22:11:36 CEST] <Lyphe0> -the [22:11:59 CEST] <furq> looks like a:0 just autoselects input file 0 [22:12:28 CEST] <furq> $ ffmpeg -f lavfi -i sine -f lavfi -i testsrc -map v:0 -f null - [22:12:31 CEST] <furq> so that throws an error [23:01:55 CEST] <SortaCore> Hey fellas... just a quick one, I'm running a file through null muxer to get the duration from output... is it okay to use codec copy or will that mess with the timing? The official example doesn't use copy so I'm suspicious [23:02:25 CEST] <furq> it might mess with the timing [23:02:36 CEST] <furq> the default for the null muxer is to just decode and discard, so it won't take very long anyway [23:03:10 CEST] <SortaCore> heh, compared to codec copy it's very slow, but yea, I get ya [23:03:16 CEST] <SortaCore> thanks furq [23:03:22 CEST] <SortaCore> ciaooo [23:11:53 CEST] <nine_milli> blb_ [00:00:00 CEST] --- Sun Jul 14 2019

1 0