Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2019

1 participants
62 discussions

ffmpeg-devel.log.20190305
by burek 06 Mar '19

06 Mar '19

[00:00:02 CET] <jkqxz> lrusak_: Sure. Use the external allocation route for hwcontext, and make your decoder support the hw_frames_ctx interface. [00:02:20 CET] <jkqxz> You can kindof do it with VAAPI now, but it's a pain to make objects with the right constraints (tiling, alignment etc.) to actually decode to. [00:37:48 CET] <lrusak_> jkqxz: by external allocation route do you mean using av_buffer_pool_init2 to allow specifying our own allocation function? [00:43:10 CET] <vel0city> lrusak_: o/ whatchu working on? :) [00:43:48 CET] <jkqxz> Yes. Though if you never allocate directly from it then it's not actually necessary to have an allocation function - for a decoder that means supplying a get_buffer2 callback which will return one of your frames. [00:46:08 CET] <lrusak_> ah ok, Thank you, I knew abou tthe get_buffer2 callback but wasn't sure if that was the best method or not. I guess it allows us to allocate our own buffers in our own buffer pool and provide them to ffmpeg directly [00:46:57 CET] <lrusak_> vel0city: zero-copy SW decoding :) or something like that to improve our SW decoding performance [00:48:23 CET] <jkqxz> If you're SW decoding then you don't need necessarily need to consider the hwcontext stuff at all. If your code can supply the software-mapped buffers then you can give them to get_buffer2 like any other frame. [00:48:57 CET] <jkqxz> (Though it may be useful to have it anyway if you're using it in other cases, and it can do the mapping for non-weird cases.) [00:49:01 CET] <vel0city> lrusak_: neat [00:51:26 CET] <lrusak_> jkqxz: gotcha, thanks for the pointers. I'll give that a try and come back if I get stuck. [00:53:39 CET] <amaim_> Hello there, I'm trying to get a grip on the already working codes to be able to do the "Qualification Task", but I was wondering how can I know which files/headers/structures that may come in handy from such huge libraries? I'm sure the question is trivial but I'm an extreme noob and new to open source, thanks for your time. [00:55:47 CET] <jkqxz> amaim_: It very much depends what areas you are interested in. [00:56:34 CET] <amaim_> I'm currently checking the HEIF SUPPORT project, I need to write a trivial (!) heif muxer as the Qualification Task [00:56:53 CET] <jkqxz> The libraries are quite modular, so a place to start would be to look at an example of the type of component you are interested in (e.g. a decoder) and understand how that works. [00:57:24 CET] <amaim_> I've been trying to understand for example the bmp related code since I've experienced, but the amount of custom structures, functions used is huge :D [00:57:38 CET] <amaim_> and each time I go to one of the included files I find more included files [00:58:31 CET] <amaim_> Sorry, I'm sure the amount of noobness in my questions is irritating but I'm totally new to this :D [00:59:21 CET] <JEEB> so the mess that is HEIF is ISOBMFF-based [00:59:30 CET] <JEEB> ISOBMFF muxing is handled by libavformat/movenc.c [00:59:48 CET] <jkqxz> I'm not quite sure what that task means by a "trivial (!) heif muxer". Maybe one which takes a single HEVC frame intra-frame of a fixed size and puts that into a file, with most of it hard-coded? [01:00:36 CET] <jkqxz> Though the standards in this area are quite complex, so there is a lot of boilerplate to get through there. [01:01:19 CET] <amaim_> @JEEB Thanks for the information. [01:02:09 CET] <amaim_> @jkqxz thanks, I don't know either I think I will have to speak to the mentor to know exaclty, thanks anyways [01:04:16 CET] <JEEB> I hope you have seen the comments in the initial patch for reading HEIF which was never merged [01:04:44 CET] <JEEB> although of course in theory muxers are indeed simpler, since they only need to support what they consider are needed [01:05:16 CET] <JEEB> granted, with HEIF nothing tends to be too simple :P [01:05:18 CET] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/215003.html [01:05:28 CET] <JEEB> this is the initial HEIF patch set for reading, and the rant [01:05:43 CET] <JEEB> amaim_: also I hope you have the HEIF specification [01:06:03 CET] <amaim_> Well as a total beginner, should I abandon this? you all seem to say it's complicated xD [01:06:21 CET] <amaim_> Should I pick another format? or ? [01:07:04 CET] <JEEB> I don't mean you should abandon it, I'm just noting that it will not be a walk in the park [01:08:00 CET] <JEEB> anyways, for specifications it seems like HEIF spec is available for free [01:08:02 CET] <JEEB> https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html [01:08:14 CET] <JEEB> grab 14496-12 and 23008-12 [01:08:28 CET] <JEEB> 14496-12 is ISOBMFF (which colloquially gets called "mp4") [01:08:40 CET] <JEEB> which is based on the Apple MOV format originally [01:08:51 CET] <JEEB> 23008-12 then is HEIF, which is based on ISOBMFF [01:10:26 CET] <amaim_> Currently reading the HEIF initial patch and the guy seems mad about the format xD [01:10:35 CET] <amaim_> Thank you so much JEEB! really [01:10:43 CET] <JEEB> yes, since it seems to be such an overcomplicated mess [01:10:48 CET] <amaim_> What about DICOM? would you consider it easier? [01:10:56 CET] <JEEB> I don't even know what that is :P [01:11:21 CET] <amaim_> Oh heheh [01:11:24 CET] <amaim_> Alright great [01:12:45 CET] <JEEB> also I would rather look at the HEIF spec to see how complex a basic single image would be [01:13:22 CET] <JEEB> movenc should already handle putting HEVC (the video format) into MP4 [01:13:58 CET] <JEEB> so you figure out what sort of MP4 based monstrocity HEIF is [01:14:13 CET] <JEEB> and see how complex it feels like getting a basic thing flying [01:14:30 CET] <JEEB> (and then you'd have to verify it against applications that take HEIF in, such as some Apple stuff) [01:16:17 CET] <amaim_> Alright noted, I'll try to and hopefully I succeed [01:16:18 CET] <JEEB> also I recommend you figure out what muxers are in FFmpeg world if you are going to poke them [01:16:40 CET] <amaim_> Yes I've been trying to get a general info about that [01:16:55 CET] <amaim_> Are there good educative examples you would recommend? [01:17:56 CET] <JEEB> not sure how educative or good, but you can see the basics in movenc.c for example. it has X different muxers utilizing the same core. [01:18:02 CET] <JEEB> scroll to the very end of the file [01:18:11 CET] <JEEB> you will see definitions of AVOutputFormats [01:18:26 CET] <JEEB> that is the base structure that defines an output format [01:18:56 CET] <JEEB> then you have function pointers in it [01:19:05 CET] <JEEB> like init, write header/packet [01:19:11 CET] <JEEB> write trailer [01:19:18 CET] <JEEB> and finally deinit [01:19:28 CET] <JEEB> which of these a format implements depends on the format [01:20:11 CET] <JEEB> but basically then the API user will initialize a muxer, set up streams etc, write the header, and then write one or more packets [01:20:51 CET] <JEEB> then after the API user is done with muxing, the trailer is written and finally the context can be closed :) [01:21:01 CET] <JEEB> you can see how those function pointers match up with these things [01:21:08 CET] <JEEB> the framework basically abstracts that [01:22:18 CET] <JEEB> amaim_: for a much simpler example that only has "write me a header" and "write me a packet" there is libavformat/yuv4mpegenc.c (see how it doesn't have an initialization thing, footer thing, or deinit thing) [01:23:34 CET] <amaim_> Thank you for the amazing details, I'll study every line you have said thoroughly, If I succeed know that you are the one who gave me the first push, thank you! [01:24:22 CET] <JEEB> but yes, for HEIF you will either have to grow movenc.c, or you make a separate file which then utilizes helpers from movenc.c [01:24:52 CET] <JEEB> but something like yuv4mpegenc might give you a moment to grasp how the interface works [01:25:00 CET] <JEEB> anyways, night'o [01:25:09 CET] <amaim_> I'll look at it, great! [01:25:12 CET] <amaim_> Good night :D [01:41:44 CET] <diamondman> I have found myself trying to draw text/shapes to non standard displays with non square pixels such as https://github.com/diamondman/att26a or yarn in a scarf. If I just use standard rasterization, text looks stretched on these bizarre mediums. I know this is not explicitly video related, and therefore not the right place to ask, but since video deals with these types of transformations, I was hoping someone may have [01:41:44 CET] <diamondman> a pointer on where I should start. I would greatly appreciate any suggestions. [01:48:54 CET] <J_Darnley> Drawing them how? Your self or with some ffmpeg features? [01:50:34 CET] <J_Darnley> https://raw.githubusercontent.com/diamondman/att26a/master/docs/images/AT%2… [01:50:39 CET] <J_Darnley> I will guess yourself [01:51:46 CET] <J_Darnley> There are some terms you can search for: aspect ratio, anamorphic [01:52:33 CET] <diamondman> J_Darnley: I guess I meant generally... like somehow taking pixel data from any output that renders to square pixels (like ffmpeg or freetype) and getting them to look right in these other forms. It is very likely I simply don't know what I don't know here yet. [01:52:53 CET] <diamondman> J_Darnley: Thanks, I will look up those terms :) [01:53:39 CET] <J_Darnley> You probably need to define the shape of your pixels and apply the reverse tansform for that. [01:54:06 CET] <J_Darnley> basic example, pixel aspect ratio of 2:1 [01:54:22 CET] <J_Darnley> each pixel is twice as wide as it is tall [01:54:56 CET] <J_Darnley> so that would widen the image by a factor of 2 [01:55:36 CET] <J_Darnley> So to get the right shape you need to reduce width to half [03:11:01 CET] <diamondman> J_Darnley: Thanks for input. I will see what I can do with that :) [12:58:13 CET] <j-b> Yo [18:57:31 CET] <kurosu> jamrial: for anything win32, do you use the mingw32 shell, or mingw64 + cross-compiler ? [18:57:57 CET] <kurosu> I no longer have the will to build myself gcc & co to be multilib, but that used to be my preferred way [18:59:20 CET] <kurosu> actually, the next question is dav1d-oriented, so... [19:01:26 CET] <nevcairiel> for myself, technically i "cross-compile" for 64-bit windows, as-in the win64 toolchain is prefixed, while my win32 toolchain is not prefixed, both use mingw-w64 of course. Judging from the terms you use, thats probably from the toolchains that msys2 packages for you? [19:01:45 CET] <jamrial> kurosu: i use the msys2's mingw32 shell (msys2_shell.cmd -mingw32) [19:02:05 CET] <kurosu> ok, thanks, that was what I started to do [19:02:13 CET] <jamrial> and the mingw32 packages for gcc, binutils and such [19:02:18 CET] <kurosu> I just find it cumbersome to have basically a duplicate system [19:02:37 CET] <kurosu> while I just do validating using mingw32, no actual dev or benchmarking [19:02:53 CET] <jamrial> for nasm and such the msys package can be shared between the two shells [19:04:27 CET] <jamrial> nevcairiel: yeah, he's setting up msys2 and its toolchains are cleanly split [19:05:35 CET] <nevcairiel> i never liked their setup, i like being able to use both from the same shell, even if i have to prefix my 64-bit tools [19:06:05 CET] <nevcairiel> although I always was too lazy to build a proper multi-lib compiler [19:06:13 CET] <nevcairiel> hence, prefixing =p [20:17:17 CET] <durandal_1707> lol, doom9 shares cracks [21:00:53 CET] <durandal_1707> why nobody wants to improve my patch/work on scalarproduct_float? that is very sad and devastating to know [21:07:30 CET] <durandal_1707> everybody is on #dav1d [21:09:20 CET] <jamrial> durandal_1707: we can't really add avx for it until the next bump, to at least increase the required alignment [21:09:26 CET] <jamrial> unless we make it branchy [21:10:03 CET] <jamrial> checking both alignment and element count [21:10:38 CET] <durandal_1707> aligned no more relevant [21:10:49 CET] <durandal_1707> we should just remove that restriction [21:10:56 CET] <nevcairiel> didnt someone tell me that avx can deal with unaligned input anyway [21:12:43 CET] <jamrial> yes, except on instructions that specify alignment, like movdqa/movaps [21:39:23 CET] <BBB> aligned is still preferred [21:45:47 CET] <kurosu> there's minimal (or at least way way smaller) penalty to unaligned data nowadays [21:46:53 CET] <durandal_1707> what about adding scalarproduct2_float? [21:49:45 CET] <kurosu> nevcairiel: missed your comment re mingw64, but yes [21:50:24 CET] <kurosu> I don't care like you might do about distributable packages, so I just needed a compiler, not a load of various libs [21:51:10 CET] <kurosu> in old times, I was just adding -m32 to cflags (ie on the configure command line), and was done with this part [21:51:48 CET] <kurosu> now, I probably have half a gig of additional build chain & assorted tools [21:52:15 CET] <kurosu> not the end of the world, even on a ssd [21:57:24 CET] <nevcairiel> Luckily the number of libraries etc are pretty low [21:57:33 CET] <nevcairiel> basically zlib and some pthreads variant [22:20:16 CET] <atomnuker> kurosu: somewhat, sometimes its hardly measurable [22:20:56 CET] <atomnuker> but nowadays timing of movu == mova for aligned data [23:05:43 CET] <lynne> hi, is there any way to disable v4l2_m2m? --disable-everything --disable-autodetect --disable-hwaccels still leaves it enabled [23:07:37 CET] <kierank> jamrial: iirc there is avx for some functions and they just fail if you use your own allocator [23:07:49 CET] <kierank> So it was always a problem [23:07:59 CET] <kierank> I saw this like 5 years ago [00:00:00 CET] --- Wed Mar 6 2019

1 0

ffmpeg.log.20190305
by burek 06 Mar '19

06 Mar '19

[00:00:06 CET] <furq> it was probably the mingw pthreads lib [00:00:16 CET] <JEEB> (or if you can get a backtrace of that, go report that to whomever provided that pthreads wrapper) [00:00:32 CET] <JEEB> yes, at this point of time in 2019 most likely the mingw-w64 pthreads wrapper [00:00:45 CET] <GuiToris> hello, how would you get the right values for the perspective filter? [00:00:56 CET] <GuiToris> I'd like to match to separate videos [00:02:55 CET] <kevinnn> JEEB: would you happen to be able to link me to an example of how to manually implement this with the UDP protocol? Instead of relying on ffmpeg for receiving h264 units, decoding them and threading those processes? [00:03:13 CET] <kevinnn> so that I don't have to depend on pthreads [00:03:40 CET] <JEEB> I was meaning to within the UDP protocol within libavformat [00:03:45 CET] <JEEB> but you can of course do it yourself as well [00:04:03 CET] <kevinnn> I figured that might be a better approach [00:04:14 CET] <kevinnn> but I can't find any nice examples to do it [00:04:36 CET] <JEEB> also, no idea because I would look into stuff like that after I see it could be worth some effort :P [00:08:15 CET] <kevinnn> so you don't think its worth my effort? [00:08:28 CET] <kevinnn> instead I should do something with libavformat? [00:09:04 CET] <JEEB> no, I just mean that if I would start looking into it I would probably start my pay-o-meter or something :P (or someone would have to spring a very curious interest in things within me) [00:09:23 CET] <JEEB> and my default solution would be to make it within libavformat so that everything using libavformat can gain from it [00:09:57 CET] <kevinnn> hmm, I am not quite following how I could do this within libavformat [00:10:15 CET] <JEEB> implement the separate I/O thread within libavformat/udp ? [00:10:25 CET] <JEEB> just like the pthread variant is done right now [00:10:47 CET] <JEEB> anyways, I don't remember if the pthreads version was just exiting normally or crashing for you [00:11:06 CET] <JEEB> if it's crashing then you might be able to boink the internest of the party that provides the pthreads windows wrapper for you [00:11:25 CET] <kevinnn> for some reason even after I compiled with pthreads the output still suggested that I hadn't linked it properly [00:11:27 CET] <JEEB> you would just need to come up with a backtrace + bug report :P [00:11:52 CET] <kevinnn> like it still had the circular buffer error [00:12:04 CET] <JEEB> if things are not going fast enough then that will happen yes [00:12:13 CET] <kevinnn> any simple tips to get it to compile correctly? [00:12:23 CET] <kevinnn> oh so it may have compiled correctly still? [00:12:34 CET] <JEEB> no idea [00:13:09 CET] <kevinnn> so how do I get started on creating a separate I/O thread within libavformat/udp [00:13:35 CET] <JEEB> you can already see the implementation of the pthreads version :P [00:13:48 CET] <JEEB> it's in the UDP protocol layer in libavformat [00:13:51 CET] <JEEB> udp.c most likely [00:16:30 CET] <kevinnn> okay thank you, I'll take a look [00:19:05 CET] <JEEB> also I recommend you try and find information on how Windows networking documentation recommends you handle high bandwidth UDP. just make sure it's applicable for modern windows (NT6+) [00:43:00 CET] <bencc> is there something like libass that is up to date? [00:43:12 CET] <bencc> for example, I need to control text padding [00:43:18 CET] <bencc> and auto line breaks [00:43:38 CET] <JEEB> libass is pretty up to date? [00:43:46 CET] <JEEB> it's relatively actively developed, even [00:44:38 CET] <bencc> I see \fspy vertical spacing tag in the planned features of v5.0 [00:44:39 CET] <bencc> https://github.com/libass/libass/wiki/ASS-v5.0 [00:44:51 CET] <bencc> from 2017. is it possible to use it? [00:45:15 CET] <bencc> last release is from 2017 [00:45:31 CET] <bencc> how is it to date? [00:46:15 CET] <furq> well afaik the spec is defined by libass so i don't see how anything else could be more up to date [00:46:23 CET] <furq> or the same team [00:47:01 CET] <bencc> I'm trying to put text box annotations to a video [00:47:28 CET] <bencc> a semi transparent rect with a text in it at specific time/position [00:49:36 CET] <bencc> maybe this: https://github.com/libass/libass/commit/a7807b03b0d1f25f448c14e88e0d8aa6ef4… [00:49:41 CET] <bencc> but I'm not sure how to use it [00:51:41 CET] <JEEB> bencc: I'd probably recommend #libass on this network for ASS stuff [00:51:57 CET] <JEEB> also something called ASS v5 has come and gone :P [00:52:13 CET] <bencc> come and gone? [00:52:28 CET] <JEEB> as in, different people have come and come up with something that they'd call ASS v5 [00:52:46 CET] <JEEB> the best bet is to just start adding extensions to libass if you want something. as long as it seems sanely specified [00:53:10 CET] <JEEB> and for ASS basics there's the Aegisub tutorial :P [00:53:19 CET] <JEEB> for what BorderStyles etc are [00:59:25 CET] <furq> bencc: i take it you have way too many annotations to make it feasible to do this with drawbox/drawtext [01:00:17 CET] <bencc> furq: drawbox/drawtext means I need to have a long command line command? [01:00:30 CET] <furq> yeah or use -filter_complex_script [01:00:36 CET] <furq> that's just putting the very long command in a file though [01:20:03 CET] <cstk421> i am setting up a youtube live stream from a camera via rtsp. What i am looking to do is have ffmpeg take snapshots of it every 60 secs or so and create a timelapse video that updates as more and more images are taken. Is this possible ? any guides I can read to set this up? [02:03:28 CET] <fructose> When trying to cut between -ss and -t, is there a way to get ss to seek to the last DTS time while ensuring audio stays synced? [02:15:25 CET] <cstk421> Csman so youtube has an 8 hour time limit on streaming live and then it auto archives the stream. Does anyone know if after the 8 hours are reached if it starts the stream again and goes for another 8 hours automatically ? [03:40:09 CET] <Mista_D> How would one add "days" to timecode/timestamp with a drawtext filter please? Need to see how long live feed can run without interuptions... [06:17:48 CET] <psachin> Hi #ffmpeg. Any can help me to convert the video from MKV to MP4(PS4 compatible)? The close I got was using the command `ffmpeg -i input.mkv -c:v mpeg4 -c:a libmp3lame -b:a 128K output.mp4`. But the output video is not identified by PS4 console. [06:21:34 CET] <CVJoshua> Hi, I'm reading the docs for -frame_drop_threshold, they say "The default is -1.1.". I'm wondering what the behaviour of negative values is. Does it cause ffmpeg drop frames immediately, or never? And why is the default -1.1 instead of -1.0? [06:35:42 CET] <another> psachin: try -tag:v xvid [06:35:49 CET] <another> see also: https://trac.ffmpeg.org/wiki/Encode/MPEG-4 [06:36:02 CET] <another> but you probably want something more modern [06:36:07 CET] Action: psachin checking... [06:36:17 CET] <another> https://trac.ffmpeg.org/wiki/Encode/H.264 [06:38:14 CET] <another> psachin: according to the ps4 manual (https://manuals.playstation.net/document/en/ps4/music/mp_format_m.html) it should support mkv [06:45:57 CET] <psachin> another: Hmm. I discovered that the output video doesn't match the exact MKV specs as described on the page. Anyways I'll try the H.264 as you suggested. [06:46:52 CET] <another> have you tried the original video? [06:58:38 CET] <beandog> psachin, here you go - https://dvds.beandog.org/doku.php?id=ps4 [06:58:52 CET] <beandog> somewhat helpful [06:59:08 CET] <beandog> also https://manuals.playstation.net/document/en/ps4/videos/mp_format_v.html [06:59:31 CET] <beandog> it's pretty fussy about what'll accept [07:54:35 CET] <psachin> another: Yes. It is not identified either. [07:56:32 CET] <psachin> beandog: In your example command, does the original MKV video was identified on PS4? [09:33:49 CET] <Ariyasu> psachin [09:35:56 CET] <Ariyasu> ffmpeg -i input.mkv -vcodec libx264 -preset slow -profile:v high -level 4.2 -crf ## -acodec aac -b:a 128k output.mkv [09:36:17 CET] <Ariyasu> pick a crf value depending on the content, somewhere between 18 to 22 should do it [09:36:27 CET] <Ariyasu> and that should play back fine on your ps4 [09:37:33 CET] <Ariyasu> if you do [09:37:47 CET] <Ariyasu> ffmpeg -t 10 -i input.mkv -vcodec libx264 -preset slow -profile:v high -level 4.2 -crf 21 -acodec aac -b:a 128k output.mkv [09:38:04 CET] <Ariyasu> it will just encode a 10second sample video, which you can use to test it on your ps4 [09:38:07 CET] <psachin> Ariyasu: Currently I'm trying `ffmpeg -i input.1080p.BluRay.x264.DTS-HDC.mkv -c:v libx264 -c:a libmp3lame -b:a 48K output.mkv` [09:38:16 CET] <Ariyasu> it it works you can remove the -t 10 and rework all your files [09:38:41 CET] <psachin> Ariyasu: Ohk. Using -t is new info for me [09:38:44 CET] <Ariyasu> you havent set the level to 4.2 so im pretty sure it will fail to play back [09:39:00 CET] <Ariyasu> you can run another instance in parallel to check [09:39:16 CET] <Ariyasu> ffmpeg -t -i input.1080p.BluRay.x264.DTS-HDC.mkv -c:v libx264 -c:a libmp3lame -b:a 48K test.mkv [09:39:20 CET] <Ariyasu> ern [09:39:25 CET] <Ariyasu> ffmpeg -t 10 -i input.1080p.BluRay.x264.DTS-HDC.mkv -c:v libx264 -c:a libmp3lame -b:a 48K test.mkv [09:39:43 CET] <Ariyasu> like that, and test it, if it dosnt work, you can kill your running job and start over [09:50:19 CET] <beandog> plus I don't think it'll playback mp3 [09:51:13 CET] <beandog> oh, nvm, docs say it does in mkv [10:38:03 CET] <psachin> Ariyasu: beandog This works "ffmpeg -t 3 -i input.mkv -c:v libx264 -c:a libmp3lame -preset slow -profile:v high -level -crf 21 4.2 -b:a 128K output.mkv" [10:38:46 CET] <psachin> Oops sorry -- "ffmpeg -t 3 -i input.mkv -c:v libx264 -c:a libmp3lame -preset slow -profile:v high -level 4.2 -crf 21 -b:a 128K output.mkv" [10:39:00 CET] <psachin> Thank Guys!! [11:11:57 CET] <beandog> cool :) [11:11:59 CET] <beandog> have fun [12:43:26 CET] <Shibe> hi i cant quite seem to figure out how to capture kmsgrab and pulseaudio at the same time [12:43:28 CET] <Shibe> sudo ffmpeg -f kmsgrab -framerate 60 -i - -f pulse -i INPUT -vf 'hwmap=derive_device=vaapi,scale_vaapi=w=1280:h=720:format=bgr0' -c:v h264_vaapi /tmp/output669.mkv [12:43:31 CET] <Shibe> heres what i have now [12:43:35 CET] <Shibe> but it says input/output error [12:50:02 CET] <durandal_1707> Shibe: you put "-f pulse -i INPUT" in wrong position [12:52:49 CET] <Shibe> durandal_1707: what would be the correct way? [12:55:33 CET] <durandal_1707> Shibe: put it before "-f kmsgrab" [12:57:46 CET] <Shibe> durandal_1707: sudo ffmpeg -f pulse -i INPUT -f kmsgrab -framerate 60 -i - -vf 'hwmap=derive_device=vaapi,scale_vaapi=w=1280:h=720:format=bgr0' -c:v h264_vaapi output.mkv [12:57:50 CET] <Shibe> still seems to be giving input/output error [13:04:37 CET] <Shibe> https://pastebin.com/raw/R4yaA337 [13:06:32 CET] <durandal_1707> Shibe: replase INPUT with 0 [13:06:53 CET] <durandal_1707> INPUT does not work here for me with pulse [13:08:04 CET] <Shibe> durandal_1707: replacing it with -i default seems to be working [13:08:06 CET] <Shibe> thanks! [13:08:14 CET] <Shibe> though it's picking up on my mic not my speaker output but i'll figure it out [15:37:09 CET] <Hello71> also instead of sudo I think you can add yourself to video group [15:37:24 CET] <Hello71> wait, no, that's for v4l [15:37:44 CET] <Hello71> wait, no it isn't. [16:14:59 CET] <th3_v0ice> If I send a packet that has smaller DTS then the previous DTS, is the muxer sending it or buffering it? (RTMP output) [16:17:11 CET] <DHE> depends on if they're in different streams and if you use av_[interleaved]_write_frame with or without the interleaved bit [16:20:35 CET] <th3_v0ice> Its the same stream. So interleaved will buffer it and av_write_frame will just send it. Do I need to arrange packets in order of increasing DTS in that case? [16:22:18 CET] <DHE> for the same stream that is mandatory, yes [16:22:35 CET] <DHE> you will get errors if you don't, and I'm not sure if it will actually send what you give it at all [16:26:59 CET] <Mavrik> IIRC the out-of-order packets get dropped on muxer layer [16:51:54 CET] <th3_v0ice> Ok guys, thanks! [22:05:12 CET] <brimestone> hey guys, can FFMpeg use AMD GPU? [22:05:49 CET] <JEEB> for decoding there's vaapi (lunix) and dxva2 and d3d11va (windows) [22:06:08 CET] <JEEB> for encoding there's vaapi (lunix) and there was something for windows but I'm not sure if that ever got merged :P [22:06:10 CET] <brimestone> Nothing for macOS? [22:06:13 CET] <JEEB> no [22:06:22 CET] <JEEB> unless the mac hwdec APIs work [22:06:29 CET] <pink_mist> I thought macOS used nvidia anyway [22:06:30 CET] <JEEB> those are generic [22:06:42 CET] <brimestone> How would I test that? [22:06:51 CET] <brimestone> If hwdec API is working? [22:08:09 CET] <JEEB> either with an FFmpeg build with videotoolbox enabled, or an mpv that was built with FFmpeg that had vt enabled [22:08:38 CET] <JEEB> (found my macos building documents that mention --enable-videotoolbox when building for macos [22:29:36 CET] <brimestone> JEEB: how do I test if video toolbox is enabled or not? [22:29:50 CET] <JEEB> in what? [22:30:17 CET] <brimestone> Like ffmpeg -protocols to see which protocols are supported [22:31:00 CET] <JEEB> ffmpeg -hwaccel videotoolbox -i blah.mp4 -f null - [22:31:25 CET] <JEEB> also it could be that ffmpeg -hwaccels lists them [22:31:38 CET] <JEEB> yes, seems like that's the case [22:33:07 CET] <brimestone> Hey! I get videotoolbox opencl videotoolbox (2 video toolbox) [22:34:24 CET] <Sesse> hi. when transcoding using the ffmpeg command line tool, is there any way I can override the autodetected input ycbcr information? I have JPEGs that I know for sure have left chroma placement, limited ycbcr range and rec709 coefficients [22:35:14 CET] <Sesse> but I'm fairly certain libavcodec won't mark them as such, so I'd need to override :-) [22:35:35 CET] <JEEB> yes. scale/zscale filters let you override what the input is, and you can use the normal override parameters on the encoding side if you just need to encode it in some way [22:35:45 CET] <Sesse> let's see [22:35:57 CET] <JEEB> (note: swscale might do funky things by default so always keep log level at least verbose) [22:36:00 CET] <JEEB> -v verbose [22:36:12 CET] <JEEB> that shows the generated filter chain if such was generated [22:36:43 CET] Action: JEEB wonders if he should add an option to ffmpeg.c that tells libavfilter to not insert implicit format conversions [22:36:44 CET] <Sesse> -vf scale looks great for this [22:38:08 CET] <Sesse> hsub doesn't exist, though, even though the manual claims it should [22:38:22 CET] <Sesse> neither does ohsub [22:39:11 CET] <JEEB> not sure if swscale handles that [22:39:19 CET] <Sesse> https://ffmpeg.org/ffmpeg-filters.html#scale-1 [22:39:34 CET] <Sesse> but it's fine, the subsampling is detected correctly, and I guess I can just do -pix_fmt to set the output [22:39:56 CET] <JEEB> http://ffmpeg.org/ffmpeg-filters.html#zscale-1 [22:40:02 CET] <JEEB> zimg which is what zscale uses [22:40:11 CET] <JEEB> does handle input/output chroma location being different [22:40:16 CET] <JEEB> and other things [22:40:30 CET] <Sesse> well, I want output to be left, too [22:40:33 CET] <Sesse> so that's perfect :-) [22:40:38 CET] <Sesse> ie., having in and out be the same [22:40:42 CET] <JEEB> ok [22:41:04 CET] <Sesse> my JPEGs are essentially made at H.264 spec [22:41:08 CET] <brimestone> JEEB, videotoolbox only uses CPU :( both of my D500 are idle while CPU is high. [22:41:42 CET] <Sesse> but ok, let's try zscale [22:42:02 CET] <JEEB> Sesse: if you don't need to scale etc then just set the metadata with the general options that ffmpeg.c has [22:42:08 CET] <JEEB> which sets the AVCodecContext values I think [22:42:19 CET] <JEEB> brimestone: I am not wholly surprised :P [22:42:35 CET] <Sesse> [AVFilterGraph @ 0x5647242df200] No such filter: 'zscale' [22:42:36 CET] <Sesse> pah [22:42:45 CET] <JEEB> yea, you need to have built with zimg for it [22:42:52 CET] <Sesse> JEEB: I do need to scale, I want 420p in the end [22:42:54 CET] <JEEB> very nice if you want gamma correct scaling among other things [22:42:57 CET] <Sesse> even though my input is 422p [22:43:05 CET] <JEEB> ok [22:43:29 CET] <Sesse> well, OK, I guess I could live with 422 on disk, but it's kind of wasteful for my use [22:44:24 CET] <Sesse> let me try to find the metadata options in ffmpeg.c [22:45:03 CET] <shibboleth> anyone know how to force kodi to use tcp for rtsp? [22:45:38 CET] <Foaly> i'd just cut the two pixels off rather than scaling [22:46:26 CET] <Sesse> JEEB: I can't find any relevant options in ffmpeg_opt.c [22:47:16 CET] <Sesse> JEEB: question: if I just do a normal transcode from e.g. mpeg-2 (center chroma) to h.264 (left chroma), is there nothing that will shift the chroma placement for me? [22:47:30 CET] <JEEB> zscale seems like it could do it [22:47:36 CET] <Sesse> no, I mean without any options [22:47:37 CET] <JEEB> since it lets you set input and output of it [22:47:55 CET] <Sesse> like, ffmpeg -i whatever_dvd.vob -c:v libx264 test.mp4 [22:48:30 CET] <JEEB> highly unlikely anything will touch that stuff if the pixel format matches. in the best case it will just set the values on the libx264 side accordingly :P [22:48:37 CET] <Sesse> oh wow :-)I [22:48:39 CET] <Sesse> :-) [22:48:45 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html ctrl+F "primaries" [22:48:55 CET] <JEEB> and the other options nearby [22:49:01 CET] <JEEB> those set the AVCodecContext values [22:49:43 CET] <Sesse> ok... except no chroma placement [22:49:50 CET] <JEEB> chroma_sample_location [22:49:56 CET] <JEEB> you just had to scroll a bit more [22:50:08 CET] <Sesse> huh, are we looking at the same file? [22:50:12 CET] <Sesse> ah, we're not [22:50:12 CET] <JEEB> yes [22:50:18 CET] <JEEB> well I just linked ffmpeg-all.html [22:50:19 CET] <JEEB> :P [22:50:29 CET] <Sesse> yes, and somehow I managed to look in another tab nevertheless [22:50:32 CET] <Sesse> so my mistake :-P [22:50:53 CET] <JEEB> but do note that most likely any automated conversion will only look at the pixel format [22:51:05 CET] <JEEB> so that's metadata forcing only [22:51:08 CET] <JEEB> effectively [22:52:06 CET] <Sesse> well, yes, it's a shame that ffmpeg doesn't really understand color [22:52:33 CET] <JEEB> you basically have to do conversions like that with zimg via zscale and set things manually [22:52:37 CET] <Sesse> mm [22:53:01 CET] <JEEB> which I think in many cases is better than ffmpeg.c or libavfilter adding some auto-conversion somewhere because it feels like it [22:53:13 CET] <Sesse> but something like 422 -> 420 necessarily has to assume something about chroma placement [22:53:26 CET] <JEEB> probably [22:53:54 CET] <JEEB> most likely swscale does it in the MPEG-2/H.264 way [22:53:59 CET] <JEEB> as opposed to the older MPEG-1 way [22:54:03 CET] <JEEB> although I might be 100% incorrect [22:54:05 CET] <Sesse> MPEG-2 and MPEG-1 has the same [22:54:07 CET] <Sesse> H.264 is different [22:54:15 CET] <JEEB> huh, did I misremember that [22:54:35 CET] <Sesse> MPEG-2 is mostly MPEG-1 + interlacing support [22:54:43 CET] <Sesse> (there are some other minor differences [22:54:44 CET] <Sesse> ) [22:55:26 CET] <JEEB> Sesse: also btw in my API usage I specifically disable any automated format conversions in libavfilter, which is why I thought about adding an option for that in ffmpeg.c. the last thing you want is swscale deciding to add a random swscale conversion somewhere >_> [22:56:00 CET] <Sesse> =) [22:56:26 CET] <JEEB> avfilter_graph_set_auto_convert(filter_graph, AVFILTER_AUTO_CONVERT_NONE); [22:56:32 CET] <JEEB> "none, thank you" [22:59:26 CET] <Sesse> so I converted MJPEG -> H.264 with -chroma_sample_location left and -chroma_sample_location center, decoded the first frame of both H.264 files to PNGs using ffmpeg, and the end result got the same md5sum :-/ [23:00:06 CET] <JEEB> yes, as I said - those options are just the metadata. all the default automagic conversions are based on swscale and that currently only looks if the pix_fmt matches or not [23:00:21 CET] <Sesse> wonder if VLC does differently [23:00:24 CET] <JEEB> you need something like zscale [23:00:37 CET] <Sesse> JEEB: yeah, but it essentially means ffplay will play videos wrong [23:00:38 CET] <JEEB> basically you need to use a filter that can do things proper :P [23:00:39 CET] <Sesse> which I didn't know [23:00:58 CET] <JEEB> most likely yes [23:01:11 CET] <JEEB> I would only trust mpv's gpu renderer and VLC's new libplacebo based renderer for video rendering :P [23:01:21 CET] <JEEB> (and with non-GPU stuff, zimg) [23:01:29 CET] <JEEB> (which is the library that zscale uses) [23:01:37 CET] <Sesse> for GPU stuff, I trust my own library (movit) :-) [23:02:30 CET] <JEEB> libplacebo is basically mpv's stuff moved into a separate library (and VLC has since taken it into usage in vulkan at least) [23:02:52 CET] <JEEB> and then zimg is a thing from a person I expected it the least from :P [23:02:56 CET] <JEEB> but it has been very useful [23:03:00 CET] <JEEB> https://github.com/sekrit-twc/zimg [23:03:06 CET] <brimestone> Can OpenCL be use to accelerate filter? [23:04:21 CET] <JEEB> Sesse: but most video things will most likely just ignore stuff like chroma location [23:04:35 CET] <JEEB> I would guess most renderers in VLC, as well as the default Windows things [23:09:32 CET] <Sesse> JEEB: sad, but probably true [23:10:35 CET] <JEEB> they just expect top left for HD pretty much [23:10:40 CET] <JEEB> I would guesstimate [23:11:23 CET] <JEEB> anyways, the three things I check things against I've noted: mpv's gpu renderer, libplacebo stuff as long as the metadata is passed to the thing, zimg [23:13:38 CET] <Sesse> let's try mpv, then [23:14:33 CET] <Sesse> on visual inspection, I see zero difference between left and center (on yuv422, so unscaled) [23:14:41 CET] <Sesse> that's with mpv's gpu renderer [23:14:59 CET] <Sesse> wait, it was never set correctly according to ffprobe [23:15:05 CET] <JEEB> and you can press i or shift+i to see the metadata passed [23:15:27 CET] <JEEB> (or the logs) [23:15:44 CET] <Sesse> it writes about primaries, coloar matrix, levels, gamma [23:15:49 CET] <Sesse> but no chroma positioning [23:16:12 CET] <Sesse> (on shift+i) [23:16:19 CET] <JEEB> https://mpv.io/manual/master/#video-filters-vf [23:16:26 CET] <JEEB> see the format filter [23:17:01 CET] <JEEB> oh geez, does that not have the chroma location in there :P [23:17:09 CET] <Sesse> indeed not :-P [23:17:17 CET] <Sesse> chroma info is sort of an odd outlier anyway [23:17:22 CET] <JEEB> video/filter/vf_format.c: int chroma_location; [23:17:26 CET] <JEEB> but it's in the sauce [23:17:34 CET] <Sesse> ffmpeg conflates chroma format and pixel format [23:17:42 CET] <Sesse> but they're really quite different things [23:17:59 CET] <JEEB> nah, they're separate values and read from f.ex. H.264 or HEVC metadata [23:18:07 CET] <JEEB> it's just that the conversion system is 100% pix_fmt based [23:18:08 CET] <JEEB> ;P [23:18:13 CET] <JEEB> it just ain't looking anywhere else [23:18:26 CET] <Sesse> sure, but it should have put them in entirely different structs IMHO :-P [23:18:39 CET] <Sesse> chroma upsampling and gamma handling are, well, not really related [23:18:44 CET] <JEEB> wait what [23:18:48 CET] <JEEB> where does it collate them [23:19:07 CET] <JEEB> chroma_sample_location is just left/topleft/blah/blah [23:19:14 CET] <Sesse> for one, it calls ycbcr primaries colorspace [23:19:16 CET] <JEEB> and color_trc [23:19:21 CET] <JEEB> is the transfer function [23:19:22 CET] <Sesse> where it isn't a color space at all [23:19:34 CET] <JEEB> true [23:19:44 CET] <JEEB> but that's still not pix_fmt [23:19:48 CET] <Sesse> sure [23:19:58 CET] <Sesse> but it should have lived together with ycbcr pix_fmt information [23:20:14 CET] <Sesse> I mean, ffmpeg pretty much assumes you can do filters on ycbcr data [23:20:16 CET] <Sesse> which isn't really true [23:20:27 CET] <JEEB> it's there together with it in both AVCodecContext and AVFrames [23:20:35 CET] <JEEB> in a perfect world the framework for filters would do itw ell [23:20:37 CET] <Sesse> they can never ever be gamma-correct, then (except some special cases like mirror) [23:20:54 CET] <JEEB> unfortunately, currently the automated filtering thing uses swscale [23:20:57 CET] <JEEB> which is from early 2000s [23:21:01 CET] <JEEB> you can guess how that goes :P [23:21:07 CET] <Sesse> mm [23:21:15 CET] <JEEB> the name for colorspace might be bad, but the values are all there :P [23:21:32 CET] <Sesse> yeah, I know [23:21:36 CET] <JEEB> and they are both in AVCodecContext as well as AVFrames which are each frame that come out of stuff [23:21:40 CET] <Sesse> oh, and don't get me started on yuv422j :-P [23:21:41 CET] <JEEB> so in theory the thing's set [23:21:57 CET] <JEEB> someone just has to rewrite the whole giant big pile of legacy [23:22:05 CET] <JEEB> which is the default conversion routines [23:22:18 CET] <JEEB> until then, manual filter chain it is :P [23:22:19 CET] <Sesse> sounds like a small and easy task with no chance of controversy or regressions :-) [23:22:23 CET] <JEEB> ayup [23:22:29 CET] <JEEB> esp. since swscale has some really esoteric stuff there [23:22:44 CET] <Sesse> the mmx routines regressed 2% [23:23:10 CET] <JEEB> thankfully at this point people really probably wouldn't care too much about MMX, but they probably would care about some paletted stuff or something if that were to go away - or something [23:23:23 CET] <JEEB> (You could almost leave swscale there for the esoteric stuff) [23:23:31 CET] <JEEB> and move to zimg for the normal stuff [23:23:40 CET] <JEEB> unfortunately, piles of legacy [23:23:45 CET] <JEEB> and people already can handle it manually [23:23:54 CET] <Sesse> yeah, I remember trying to post patches to actually respect the color metadata given in the mux, instead of blindingly assuming JPEGs were center chroma [23:23:58 CET] <Sesse> and getting ignored [23:24:07 CET] <Sesse> meanwhile people were optimizing cinepak decoding :-) [23:24:27 CET] <JEEB> you did? at this point unless the thing did something wrong I'd say such a patch would go in just fine [23:24:29 CET] <Sesse> (OK, I wasn't fully ignored -- I was refused, and my followup questions were ignored) [23:24:33 CET] <JEEB> huh [23:24:35 CET] <JEEB> funky [23:24:47 CET] <JEEB> anyways, I'm getting brainderp'd at $dayjob [23:24:50 CET] <Sesse> enjoy [23:25:02 CET] <JEEB> so I often have less than normal amounts of time to give stuff [23:25:10 CET] <JEEB> like there was a patch for the FFmpeg examples to update some of them :P [23:25:15 CET] <JEEB> and I still haven't reviewed it [23:25:19 CET] <JEEB> nor has anyone else seemingly cared [23:25:51 CET] <JEEB> meanwhile the thing I do have time for - sometimes - is trying to get ARIB captions going internally (I already got an (L)GPLv3 wrapper in) [23:26:02 CET] <JEEB> but there's a whole history about a certain text encoding handling not going into any upstream iconv [23:26:11 CET] <Sesse> joy [23:26:21 CET] <JEEB> Sesse: also I'm not sure if it's documented but chroma-location is in the format filter in mpv [23:26:26 CET] <JEEB> I just looked at the sauce [23:26:37 CET] <Sesse> mm, ok [23:26:42 CET] <JEEB> so it can be overridden if not provided correctly [23:26:47 CET] <Sesse> well, I just said -chroma_sample_location left and hoped it would beo k [23:27:01 CET] <Sesse> if no players do it correctly anyway... [23:27:27 CET] <JEEB> see if ffprobe -v verbose your_output_h264.mp4 shows it [23:27:32 CET] <JEEB> if yes, it should get applied [23:27:40 CET] <Sesse> it doesn't (which is funky) [23:27:46 CET] <JEEB> then something didn't get somewhere [23:27:53 CET] <Sesse> anyway, I'm converting to 420 now too, so who knows what it will do :-) [23:27:56 CET] <Sesse> I'll just accept broken chroma [23:28:06 CET] <JEEB> for future reference, build with zimg :) [23:28:18 CET] <JEEB> that's the sw implementation I more or less trust [23:28:50 CET] <JEEB> Sesse: ahahahaha [23:28:51 CET] <Sesse> well, I don't generally build ffmpeg :-) [23:28:56 CET] <JEEB> libx264.c [23:29:05 CET] <JEEB> guess if that value from AVCodecContext is read [23:29:14 CET] <Sesse> ha :-P [23:29:20 CET] <JEEB> classic [23:29:26 CET] <Sesse> well, in theory it should have been stored in the mux... [23:29:49 CET] <JEEB> generally you don't want to trust container metadata unless you're against a wall [23:30:01 CET] <JEEB> since it can be more easily mucked with [23:30:02 CET] <JEEB> or lost [23:30:04 CET] <JEEB> in remux [23:30:07 CET] <Sesse> well, so in this case I'm doing MJPEG [23:30:14 CET] <Sesse> and JPEG doesn't really have metadata [23:30:20 CET] <Sesse> there's only JFIF, which specifies MPEG-2-like data [23:30:29 CET] <Sesse> (rec. 601, center chroma, that kind of stuff) [23:30:45 CET] <JEEB> also you are really making me want to check H.262 [23:30:58 CET] <Sesse> and then ffmpeg has a magic, private comment, where you can override one of those [23:31:10 CET] <Sesse> CS=itu709 or something like that [23:31:18 CET] <Sesse> CS=ITU601 [23:31:49 CET] <Sesse> which you'd think specified bt.601 [23:31:56 CET] <Sesse> but no, it specifies limited ycbcr range :-P [23:32:06 CET] <Sesse> (I think it originates with mplayer) [23:32:09 CET] <JEEB> I bet that's also from the depths of early 2000s [23:32:10 CET] <JEEB> yea [23:32:22 CET] <JEEB> anyways, can you give me the keyword to search for in H.262 (MPEG-2 Video) [23:32:33 CET] <JEEB> I really want to double-check it with my eyes :P [23:33:07 CET] <JEEB> ah-ha [23:33:10 CET] <JEEB> it actually is in annex D.9 [23:34:10 CET] <JEEB> http://up-cat.net/p/e5b126c3 [23:38:13 CET] <JEEB> looks like left-mid according to the 4:2:0 image in figure 6-1 in 6.1.1.8 [23:39:19 CET] <Sesse> yeah, you're right, wikipedia confirms [23:39:24 CET] <Sesse> In MPEG-2, Cb and Cr are cosited horizontally. Cb and Cr are sited between pixels in the vertical direction (sited interstitially). [23:39:27 CET] <Sesse> In JPEG/JFIF, H.261, and MPEG-1, Cb and Cr are sited interstitially, halfway between alternate luma samples. [23:40:08 CET] <JEEB> yea, I did remember JPEG and MPEG-1 being similar but dissimilar to MPEG-2 and further [23:40:33 CET] <JEEB> I don't remember what started using top-left, was it BT.709? [23:41:00 CET] <Sesse> unsure if the bt.* standards talk much about chroma placement [23:41:12 CET] <Sesse> mostly about rgb color space and ycbcr coefficients [23:41:37 CET] <JEEB> I think some of them surprisingly do [23:41:43 CET] <JEEB> not sure which tho [23:43:41 CET] <JEEB> jesus christ [23:43:57 CET] <JEEB> already forgot the darn chroma sample loc type [23:44:00 CET] <JEEB> image in H.264 [23:44:08 CET] <JEEB> that is probably one of the most confusing images I have ever seen [23:44:30 CET] <Sesse> haha [23:45:00 CET] <JEEB> under annex E.2 (VUI semantics( [23:45:29 CET] <Sesse> I don't have the standard before me (I don't think I've ever read it) [23:45:52 CET] <Sesse> thankfully never really needed to understand the details of the codec [23:45:59 CET] <JEEB> https://www.itu.int/rec/T-REC-H.264 [23:46:09 CET] <JEEB> it's mostly the metadata fields etc [23:46:28 CET] <JEEB> which generally interest me. my codec expertise as such ends at my baby's first Ut Video encoder [23:46:39 CET] <JEEB> which was just left/median prediction and huffman [23:47:09 CET] <Sesse> I did a better-than-JPEG still image codec at some point, for GPU purposes [23:47:13 CET] <Sesse> but the encoder was too slow :-) [23:48:30 CET] <JEEB> and yes, in that latest edition Figure E-1 is as flawless as ever [23:49:46 CET] <JEEB> anyways, sleep for me. way overdue for that. [23:50:27 CET] <JEEB> feel free to poke me with a link to the JPEG patch thread to see if it was just bikeshedding or actual possible issues [23:50:27 CET] <Sesse> good night, and thanks [23:50:36 CET] <JEEB> either in pm or here [23:50:42 CET] <Sesse> yeah, no, I found a local workaround [23:50:42 CET] <JEEB> o/ [23:50:48 CET] <Sesse> which was easier for my case :-) [00:00:00 CET] --- Wed Mar 6 2019

1 0

ffmpeg-devel.log.20190304
by burek 05 Mar '19

05 Mar '19

[13:04:50 CET] <cone-697> ffmpeg 03Martin Vignali 07master:9cb576fc1e3d: fate/qtrle : change 32b test to output bgra instead of rgb24 [13:04:51 CET] <cone-697> ffmpeg 03Martin Vignali 07master:5496a734882c: avcodec/qtrle : avoid swap in 32bpp decoding on little endian [13:04:52 CET] <cone-697> ffmpeg 03Martin Vignali 07master:3278ea67c8f2: avcodec/qtrle : 32bpp dec copy two raw argb value at the same time [13:04:53 CET] <cone-697> ffmpeg 03Martin Vignali 07master:88d0be1c0eea: avcodec/qtrle : improve 24bbp decoding speed [15:29:53 CET] <durandal_1707> the QMF thing makes ac4 really slow, from 200x to 50x for stereo [15:31:28 CET] <durandal_1707> there is no AVX for scalarproduct_float .. [15:33:59 CET] <j-b> QMF? [15:37:52 CET] <durandal_1707> j-b: Quadrature Mirror Filter, ac-4 version of aac's SBR [15:39:00 CET] <JEEB> who here updates the site? [15:39:01 CET] <JEEB> <@DEATH> https://ffmpeg.org/download.html says 4.1.1, why am I getting a 4.1 tarball? [15:39:08 CET] <atomnuker> moral: think before you put easy to implement in hardware unsimdable filters in your codecs [15:39:50 CET] <atomnuker> and really they should have done sbr in the frequency domain before invtx [15:41:41 CET] <durandal_1707> JEEB: if one click on more releases, there is 4.1.1 [15:42:13 CET] <cone-697> ffmpeg 03Guo, Yejun 07master:402bf262375d: configure: add missing pthreads extralibs dependency for libvpx-vp9 [15:42:14 CET] <cone-697> ffmpeg 03Guo, Yejun 07master:d9b2668766e3: configure: use vpx_codec_vp8_dx/cx for libvpx-vp8 checking [15:42:28 CET] <durandal_1707> atomnuker: this is just vanilla qmf analysis + qmf sythesis (actual decoding may be even slower) [15:43:05 CET] <JEEB> durandal_1707: yea but the big download butan seems to lead to 4.1 still [15:43:11 CET] <JEEB> which might not be what we want [15:44:40 CET] <atomnuker> you can't even do the subsample-for-analysis trick opus does to save time during decoding [15:44:47 CET] <j-b> durandal_1707: ok [16:18:54 CET] <cone-697> ffmpeg 03James Almer 07master:db332832a17c: configure: allow enabling libvpx vp9 modules when vp8 is disabled [16:47:42 CET] <kierank> durandal_1707: should be trivial to write avx, no? [16:56:31 CET] <durandal_1707> kierank: dunno [17:07:14 CET] <nevcairiel> should be relatively easy, just need to take care not to overread since it only guarantees 16-byte data [17:19:44 CET] <durandal_1707> nevcairiel: that is not an issue, problem is to sum higher values in registers [17:20:26 CET] <nevcairiel> that should be no different to sse, no? [17:23:37 CET] <durandal_1707> i get different result, so no [17:28:12 CET] <jamrial> scalarproduct_float needs 16 byte aligned buffers, and length a multiple of 4, so avx is not possible [17:28:47 CET] <nevcairiel> anything is possible, just some care being taken [17:29:20 CET] <durandal_1707> that is just limitation of current function as in lavu, which is very stupid, expecially aligned buffer to 16 [17:30:14 CET] <atomnuker> yeah, I remember those alignment limitations were annoying for opus [17:30:43 CET] <atomnuker> somehow I managed to use them even though nothing looked aligned at first [17:58:47 CET] <jamrial> most of these were written years ago before avx was a thing [17:59:26 CET] <jamrial> changing the alignment requirement isn't a problem in most codecs, but the lax elem number constrains probably is [18:03:34 CET] <durandal_1707> jamrial: length is 64 so it is multiple of 4 last time i checked [18:04:20 CET] <jamrial> in your ac4 code, yes. but that's not the only decoder using this [18:11:12 CET] <durandal_1707> i will use my own scalar product code [18:12:19 CET] <j-b> durandal_1707: I would say focus on correctness before speed. [18:13:09 CET] <kierank> J_Darnley: can you review the v210 patch someone wrote [18:13:27 CET] <J_Darnley> oh probably [18:13:33 CET] <J_Darnley> I must have missed it [18:14:54 CET] <J_Darnley> I found it [18:27:17 CET] <J_Darnley> Wow. Is this doing something other than planar output? [18:27:52 CET] <J_Darnley> Whys it doing so much stuff? [18:30:35 CET] <J_Darnley> no, it is planar [18:40:37 CET] <lrusak_> jkqxz: can you help clarify some things for me regarding AVDRMFrameDescriptor? Is it possible to allocate buffers (dumb/gbm) that we can have ffmpeg decode a frame into? I've been looking at hwcontext_drm and am not really sure if this is achievable. Any direction would be great. [20:04:32 CET] <durandal_1707> here is my SIMD code for scalarproduct_float: https://pastebin.com/wJjRQSTQ [20:29:29 CET] <jamrial> that doesn't work with 4 element buffers, or 12 element buffers, or 24, etc [20:29:42 CET] <jamrial> also, the horizontal add at the end is unnecessarely complex [20:30:37 CET] <durandal_1707> jamrial: i posted that code to troll you into writting proper version [21:48:12 CET] <durandal_1707> jamrial: what would you use for hadd? [21:51:58 CET] <jamrial> vextractf128 + addps, then do the horizontal add as it's done for sse [00:00:00 CET] --- Tue Mar 5 2019

1 0

ffmpeg.log.20190304
by burek 05 Mar '19

05 Mar '19

[08:25:44 CET] <L29Ah> [ffmpeg] filter: Channel 1 clipping 10 times. Please reduce gain. [08:25:45 CET] <L29Ah> huh what? i only have negative gains (using mpv --af=equalizer=f=87:t=h:width=5:g=-10,equalizer=f=300:t=h:width=700:g=-7,equalizer=f=1000:t=h:width=2000:g=-5) [18:03:21 CET] <logicWEB> hello :-) I'm encoding video from a bunch of files using the `-i Frame%05d.png` style syntax. I find that if I have only that input, then `-ss 20:00` seeks to 20 minutes worth of frames in pretty much instantly, but if I have two sources (e.g., a second source for audio), then the image source (is that implicitly using `image2`?) seems to insist on actually reading & decoding every single frame up to the seek point [18:04:07 CET] <logicWEB> `ffmpeg -framerate 30000/1001 -i Frame%05d.png -ss 20:00 ...` <-- starts up right away [18:04:25 CET] <logicWEB> `ffmpeg -framerate 30000/1001 -i Frame%05d.png -i Source.m2ts -map 0:v -map 1:4 -ss 20:00 ...` <-- takes a long time to start up [18:04:38 CET] <logicWEB> is this a bug? should I consider reporting it as such? [18:06:36 CET] <logicWEB> I read about input seeking vs. output seeking, but a) I want my seek to apply identically to both inputs so the audio lines up, and b) if I only have the one input, the seek runs quickly [18:07:12 CET] <logicWEB> I'm a bit worried about `ffmpeg -s TIMESTAMP -i Frame%05d.png -s TIMESTAMP -i AudioSource.m2ts ...`, but is that actually the correct way to do it, specifying the same timestamp multiple times? [18:07:37 CET] <logicWEB> (worried because I'm unfamiliar with it and am unsure about whether it will actually do exactly what I want in terms of lining up the two disparate sources) [18:08:02 CET] <logicWEB> er, I did a brain fart on that last command line, read my `-s` as `-ss` :-P [18:14:01 CET] <logicWEB> I'm just speculating here, but is it that the input options set up an object describing the input as a whole, and then an output seek `-ss` after that goes to that object and says, as an action "seek to this time", and if your only input is image frames, then that action goes to the `image2` format handler, which says, "oh hey, I know how to do that, I'll just not bother reading X frames" [18:14:27 CET] <logicWEB> but if you have multiple inputs and are picking inputs, then the _overall_ input object is a multiplexer, and the multiplexer handles that seek action by pulling that many seconds of input from each source and discarding? [18:14:28 CET] <kepstin> logicWEB: you should be using -ss as an input option (before the -i), separately on each input [18:15:01 CET] <kepstin> logicWEB: i'm surprised that -ss after -i with image2 demuxer is fast, it really shouldn't be (there's no special case for that) [18:15:40 CET] <kepstin> note that `ffmpeg -s TIMESTAMP -i Frame%05d.png -s TIMESTAMP -i AudioSource.m2ts` only seeks one of the two inputs [18:16:11 CET] <kepstin> in that case the ... well, `-ss` not `-s`, will cause seeking only in the `-i AudioSource.m2ts` [18:16:29 CET] <kepstin> note that seeking in m2ts files is probably slow in either case, since there's no seek index. [18:16:31 CET] <logicWEB> kepstin: and if I specify the same exact fractional second time as `-ss` to two different inputs, I don't ever have to worry about them both handling it 100% accurately? I seem to recall in the past there was some issue about how input seeking had the potential to be based on an estimate or otherwise inaccurate, but then there's a footnote on one page saying that as of a particular version that's no longer the case? [18:16:50 CET] <kepstin> logicWEB: unless you travel 10 years back in time, it's not an issue. [18:16:56 CET] <logicWEB> okay, good to know :-) [18:17:23 CET] <logicWEB> why would `ffmpeg -ss TIMESTAMP -i Frame%05d -ss TIMESTAMP -i AudioSource.m2ts` only seek the audio source? what is the syntax to make it seek both? [18:17:36 CET] <kepstin> oh, i just misread that [18:17:38 CET] <kepstin> that's correct [18:18:41 CET] <logicWEB> cool beans then, I'll try that out the next time I'm encoding with multiple inputs. in the time since I asked the question, the slow output seek finished so now it's already encoding :-P [18:19:33 CET] <logicWEB> for what it's worth, I almost always specify output seeking out of habit, and it's a habit I haven't broken because it's never been slow when there's only one input. I have a _suspicion_ that when the video source isn't being multiplexed, the seek operation goes directly to the input format handler and the input format handler doesn't _have_ to implement it by decoding & discarding the time you want to skip [18:19:54 CET] <logicWEB> I'm just guessing about the cause, but I'm 100% certain that when I specify an MKV file as input and _output_ seek it, it starts up right away, I do it all the time without thinking :-P [18:20:00 CET] <kepstin> but yes - if you use '-ss' before `-i`, it asks the demuxer to use file format specific knowledge to seek, and then ffmpeg internally handles making sure it's accurate to the exact frame. If you use `-ss` after all `-i`, then ffmpeg decodes all videos, runs through the filter chain, and then discards up until it gets an output timestamp matching `-ss` [18:20:53 CET] <kepstin> note the difference between input timestamp and output timestamp - if you have filters than modify timestamps (like setpts) this can be a noticable change :) [18:21:04 CET] <logicWEB> ah yes that is a good point, thanks :-) [18:22:29 CET] <logicWEB> the project I'm working on right now is trying to make a movie on DVD look as nice as possible, and the authors of this DVD frequently made micro-adjustments to input framerate and their software handled it by cutting or duplicating individual fields, so there is random interpolation _all over the place_, it's a huge mess, so I extracted every frame of the movie and then I'm putting it back together [18:22:39 CET] <kepstin> and there's no special case for speeding up output `-ss` with one input file, since it has to look at output timestamps anyways. [18:22:41 CET] <logicWEB> and to my pleasant surprise, passing 170,000 frames of input and combining it with the audio track from the original MPEG-2 stream actually lined up exactly [18:23:35 CET] <kepstin> (although.. maybe there is if you don't specify any filtering? I haven't actually checked that, to be honest) [18:24:33 CET] <kepstin> logicWEB: huh, that's really weird. was it not a standard telecine pattern? [18:24:35 CET] <logicWEB> well in any case, whether there is or isn't, I'm clearly not doing it the way it's _meant_ to be done, and I'll make a conscious effort going forward to put all my `-ss`es before my `-i`s [18:25:33 CET] <kepstin> logicWEB: having periodic field duplications is one way of handling ntsc film to pal (24 frames per second to 50 fields per second), for example [18:25:35 CET] <logicWEB> it's different patterns all over the place :-P one that showed up in quite a few animations was AA AB BB BC BC CC, but then here and there you'll get a spurt of AA AB BB BC CC CD or AA AB AB BB BC BC CC CD CD DD [18:25:52 CET] <logicWEB> and in some places AA BC CB DD [18:25:58 CET] <kepstin> ouch, that's just nasty. [18:26:02 CET] <logicWEB> er AA BC CD DD [18:26:22 CET] <kepstin> like, only a single field of `B`? :( [18:27:11 CET] <kepstin> but yeah, that sort of thing does sound like someone did edits on a telecined film using equipment for interlaced video. [18:27:20 CET] <logicWEB> yes. there was one part also that did AB AB CC DD, like, just had a random interpolated frame that was half of two other frames, repeated twice, and then jumping straight to the following frame, making it impossible to reconstruct the original [18:28:14 CET] <logicWEB> the other thing I did with this project is pass every single frame through an edge-preserving upscaler, it's a bit of an experiment, but I think it has mostly improved the quality, except in the credits which are combed all to hell and hurt the eyes to look at [18:28:25 CET] <logicWEB> sigh :-P [18:28:47 CET] <logicWEB> I shake my fist at whoever though up the idea of passing interlaced frames as though they were progressive to the MPEG-2 encoder [18:29:06 CET] <kepstin> oh, yeah, credit rolls are fun. A lot of the time the credit text itself is 60i overlaid over telecined 24fps [18:29:10 CET] <kepstin> and that's just impossible. [18:29:38 CET] <logicWEB> really gives you the impression that the people doing that editing don't _really_ understand the video format [18:30:14 CET] <logicWEB> anyway thanks very much for your time :-) [18:30:16 CET] <kepstin> i mean, if you're actually viewing the 60i video realtime on an interlaced tv, it looked good enough. [18:30:32 CET] <kepstin> but if it got partly detelecined by the dvd encoder software,... [18:31:00 CET] <logicWEB> right but interlaced TVs have been in the minority since ... I dunno, 15 years ago now? 20? :-P [18:31:04 CET] <JEEB> kepstin: there was an avisynth thing into which you would feed the telecine pattern, and it would deint to 60/1.001Hz, then double that to 120/1.001 as that can be divided by 24/1.001 [18:31:34 CET] <JEEB> and it would both inverse telecine and apply the interlaced credits nicely [18:31:45 CET] <JEEB> it was lol slow, but nice [18:31:55 CET] <logicWEB> that does sound nice :-) [18:32:01 CET] <kepstin> JEEB: my impression was that the 120/1.001 thing was mostly a workaround for avi not supporting vfr natively, so you picked a LCM of 30, 60, 24 as the framerate [18:32:10 CET] <JEEB> kepstin: that's different [18:32:15 CET] <JEEB> 120/1.001 in AVI was a VFR thing [18:32:17 CET] <JEEB> "null frames" [18:32:25 CET] <JEEB> this was an avisynth script [18:32:34 CET] <JEEB> avisynth is what came before vapoursynth [18:32:38 CET] <JEEB> frame server :P [18:32:38 CET] <logicWEB> of course there's not really much you can do when the interlaced frame has been encoded as progressive and the frequency of the comb is too high for accurate representation at the bitrate it's encoding at, causing the detail (especially in the red channel) to bleed across scans [18:33:50 CET] <kepstin> logicWEB: sometimes it helps to make sure you force swscale to to an 'interlaced' conversion from 4:2:0 to 4:2:2 or 4:4:4 [18:34:15 CET] <JEEB> kepstin: http://up-cat.net/p/ab797e4f [18:34:20 CET] <kepstin> depends on the exact circumstances tho [18:34:31 CET] <logicWEB> does that help with decoding existing video that has already been mangled, or just getting better output when encoding? [18:34:46 CET] <JEEB> that's from one of my encode scripts from ye olden days [18:35:06 CET] <logicWEB> in this project, I've had frames where the frame I want is the bottom field of frame X plus the top field of frame X + 1, but when I reconstruct it, I find that detail from the top of X and the bottom of X + 1 has bled into my reconstructed frame [18:35:10 CET] <kepstin> logicWEB: in some cases it can help with decoding poorly encoded video back to fields. [18:35:18 CET] <kepstin> but depends on exactly how the video was encoded [18:35:27 CET] <kepstin> just another thing to throw into your toolbox to try out :) [18:35:29 CET] <JEEB> the last time I used it in anger was against an interlaced scrolling text that told you to not pass the content over the interwebs and that copyright is a thing [18:35:31 CET] <logicWEB> I think the answer to that question for this particular project is "badly" :-D [18:36:11 CET] <kepstin> JEEB: ah, I see - the idea is to get the deinterlaced 60i scroll overlaid on 24p video without any judder? [18:36:22 CET] <JEEB> kepstin: yes. that's why it gets doubled to 120Hz [18:36:29 CET] <JEEB> as that is modulo 24 [18:36:52 CET] <JEEB> oh how convenient [18:37:01 CET] <JEEB> I actually had been testing it by encoding that part separately [18:40:04 CET] <JEEB> kepstin: https://megumin.fushizen.eu/random/ivtc_txt60mc_sample.mkv [18:40:06 CET] <JEEB> this is how the result looked [18:40:15 CET] <JEEB> which was pretty good I guees [18:41:10 CET] <JEEB> (given that it was indeed mismatching rates between the parts) [18:41:33 CET] <JEEB> now, of course just ignoring the overlay would have been 100% as valid [18:41:52 CET] <JEEB> since people would be watching the video after all, not the overlay :P [18:46:52 CET] <brimestone> How would one get FFMpeg with libssh on macOS? [18:47:21 CET] <JEEB> you build it? [18:47:42 CET] <JEEB> or you utilize something else to give you access to that storage over ssh (if that's really the best alternative for you) [18:51:16 CET] <brimestone> But, building FFMpeg with libssh is better for me.. [18:51:29 CET] <JEEB> sure, if it works for ye that's fine too [18:52:35 CET] <brimestone> unfortunately brew doesn't do --options anymore, which mean I have to build it from the ffmpeg source.. unless you know where I can download a compiles (with --enable-libssh) [18:53:05 CET] <JEEB> it's not too hard to build unless whichever libssh FFmpeg utilizes is hard to build [18:53:19 CET] <JEEB> I actually kept 100% out of homebrew when building my FFmpeg on mac [18:53:30 CET] <JEEB> had to build some tools first, but that's just details ;) [18:53:49 CET] <JEEB> https://kuroko.fushizen.eu/docs/buildan_mpv_macos.txt [18:53:54 CET] <brimestone> Im always weary about building it myself.. I may exclude stuff that are unknowingly important [18:54:24 CET] <JEEB> for decoding FFmpeg contains 99% of all stuff in itself [18:54:35 CET] <JEEB> for encoding you probably know what formats you will be encoding in [18:54:36 CET] <JEEB> if in any [18:55:11 CET] <brimestone> I do.. well, assuming 3dlut is built in to avfilter and I dont have to enable anything [18:55:34 CET] <JEEB> 3dlut is a filter not a video or audio format [18:55:46 CET] <JEEB> for example AVC/H.264 is a video format, and you need libx264 to *encode* with it [18:55:57 CET] <brimestone> Yeah, so should be built in yeah? [18:56:00 CET] <JEEB> for decoding the AVC/H.264 decoder is internal and enabled by default [18:57:09 CET] <JEEB> brimestone: yes, lut3d is a filter that comes with FFmpeg itself most likely since it got enabled with my FFmpeg config, which is rather minimal [18:57:33 CET] <JEEB> or the correct wording is "does not depend on external libraries that you'd have to build first" [18:58:41 CET] <brimestone> right.. thanks. [18:59:34 CET] <JEEB> brimestone: or alternatively you could look up how you could modify that homebrew recipe [18:59:47 CET] <JEEB> and add the option an dependency yourself [18:59:58 CET] <brimestone> look up? [19:00:10 CET] <JEEB> figure out [19:00:18 CET] <brimestone> Oh got, it. :) [19:00:31 CET] <JEEB> since IIRC homebrew supported modifying the rules of making the packages [19:01:49 CET] <brimestone> I was using http as source protocol and have several computer transcode segment, but I get only make it work for byte-rage 0-100000 the 100000-200000 wont work.. [19:02:39 CET] <brimestone> So I tried to do -ss and -t but it causes the server to load the whole file and not just the byte-range that -ss -t requires. [19:06:50 CET] <brimestone> JEEB, maybe something will stand out? https://gist.github.com/brimestoned/f625c5205a4ad20b5140a9a0cbbd8f5b [19:07:59 CET] <JEEB> maybe the lack of initial structures at all? [19:08:04 CET] <kepstin> brimestone: with mov files, ffmpeg needs to read some initialization data for the codecs that's either at the start or end of the fil [19:08:14 CET] <JEEB> mov is not a format you can just randomly access in [19:08:17 CET] <JEEB> (or mp4) [19:08:32 CET] <kepstin> brimestone: you can't decode mov from an arbitrary point, you need to use -ss and then ffmpeg will make multiple requests [19:09:19 CET] <kepstin> ffmpeg will make different requests to read the file headers, seek index, and then it'll make a request at the byte range where the video it wants to decode is. [19:10:25 CET] <brimestone> Yes, I tried that.. but its actually causing the server to load the entire file (17GB+) instead of doing range reads [19:10:47 CET] <kepstin> did you put -ss before -i ? [19:10:53 CET] <brimestone> Yes... [19:10:57 CET] <brimestone> Should it be after? [19:11:06 CET] <brimestone> -ss is before -I and -t is after -i [19:12:54 CET] <kepstin> so in that case, ffmpeg *should* be doing a byterange request with the start point of where it's reading video from, but it'll say it's reading until the end (it doesn't know exactly where it's gonna stop at that point - it'll signal the stop by disconnecting from the server) [19:15:09 CET] <brimestone> Yes! Thats what I expected it to do. So I thought I would do a ffprobe and find the actual byte offset of where the k frame ares and split it "properly" but still same issue [19:15:44 CET] <kepstin> do you have a log of the actual https requests firefox is making with -ss? [19:16:14 CET] <kepstin> but yes, this cannot work unless ffmpeg is allowed to do its own seeking, because of the design of the mp4 format. [19:16:16 CET] <brimestone> I can create it from the debug log. Let me re-create it now [19:16:37 CET] <kepstin> er, mov, but basically the same thing [19:16:56 CET] <brimestone> But the source is not mp4, its a ProRes mov and all of the frames are k frames [19:17:08 CET] <brimestone> ohh.. [19:17:22 CET] <brimestone> Let me re-create the problem and post the logs on the gist. [19:20:35 CET] <brimestone> Got the log. https://gist.github.com/brimestoned/f625c5205a4ad20b5140a9a0cbbd8f5b [19:22:37 CET] <kepstin> with -ss 10, it probably just decided that the seek point was close enough to the start of the file that it wasn't work closing the connection and re-opening at the seek point? [19:22:46 CET] <brimestone> Then eventually, it failed. moov atom not found | Statistics: 0 bytes read, 3 seeks [19:23:13 CET] <kepstin> hmm. strange. i would have expected it to try seeking to the end of the file to find the moov [19:23:40 CET] <kepstin> but if you're http streaming mov or mp4 files, you should really use qt-faststart or -movflags faststart to move the moov to the start of the file [19:24:08 CET] <brimestone> Well its not streaming.. its just statically serving that file.. [19:24:17 CET] <kepstin> same thing [19:24:39 CET] <kepstin> if you're decoding/playing it while it downloads, then it's streaming :) [19:24:52 CET] <brimestone> Which got my to look to maybe libssh would give me ease.. but turns out, compiling it just gives me never ending errors [19:25:37 CET] <kepstin> anyways, it sounds like the solution to your problem is to make your mov file streaming friendly by remuxing it to move the moov to the start of the file, then ffmpeg with -ss should behave nicely. [19:26:19 CET] <kepstin> but it is strange the ffmpeg is unable to seek to the end of the file to read the moov [19:27:17 CET] <brimestone> haha.. chicken and the egg. What Im trying to do is to build a distributed transcoder.. where the server host a source file and n numbers of transcoders computer would transcode segment of the file and return it back to the server then the server would concat it all together [19:28:38 CET] <kepstin> if you want to do that, then the source file has to be in a format that can be read in a segmented fashion. The usual thing to do is to have one server convert the file to segments first (low cpu, high io operation), and then encode those in parallel (high cpu, low io), and then merge them again when done on one box (low cpu, high io) [19:29:32 CET] <kepstin> audio is usually faster to encode and is tricky to segment (due to encoder delays and frame sizes), so I recommend having the audio encoded separately [19:29:41 CET] <kepstin> (in full) [19:29:47 CET] <brimestone> interesting.. [19:30:05 CET] <brimestone> Yes, thats also on my list of things to do... if I can't get the libssh working.. [19:30:53 CET] <brimestone> I could share the file to the transcoders via smb, but thought, libssh + certificates would be easy to deploy [19:31:06 CET] <kepstin> also, strange to be doing this on mac os, I don't know where you'd find a bunch of big high cpu servers running mac os to do transcoding on ;) [19:31:17 CET] <kepstin> most linux ffmpeg build should have working libssh, i'd expect? [19:33:22 CET] <brimestone> well, initially I was planing to use ubuntu to do this, but not sure how to handle "ProRes" license. [19:33:49 CET] <brimestone> By doing it on the Mac, then I get Apple ProRes license.. [19:34:24 CET] <brimestone> Then, thought about adding Docker + Kubernetes or Swarm, but not sure yet. [19:34:45 CET] <kepstin> ffmpeg uses an internal decoder, not the system one, fwiw - but you'd have to talk to your lawyer about whether that changes anything [19:45:02 CET] <brimestone> kepstin: I'm now a little confused.. should I try to do this in a "distributed" fashion? Or should I just stick with a single machine arch. [19:46:45 CET] <kepstin> completely depends on your requirements. ffmpeg should behave similarly enough on different systems that it won't really make a difference. [20:37:02 CET] <brimestone> Thats odd, my machine at home failed to install libssh [20:53:26 CET] <brimestone> But on my laptop at work, it just worked! [21:59:01 CET] <kevinnn> Does anyone have a nice example of how to parse an RTSP stream manually with libav? [21:59:29 CET] <kevinnn> specifically I noticed that ffmpeg/libav do not handle i-frames well [22:00:15 CET] <kevinnn> And I cannot use libav's built in rtsp client because I am on windows and I cannot figure out how to get ffmpeg to compile with win threads [22:00:46 CET] <JEEB> umm, all of my mingw-w64 toolchains and I think even MSVC by default hit the default windows thread wrapper [22:01:00 CET] <JEEB> and I don't have issues with I-frames anywhere (UDP or TCP) [22:01:15 CET] <JEEB> not that I'm using rtsp, but if you're not using FFmpeg's rtsp protocol either... [22:06:05 CET] <kevinnn> https://pastebin.com/qKciKE5v [22:06:08 CET] <kevinnn> JEEB [22:06:22 CET] <kevinnn> sorry to post my code but that is how I am decoding each packet [22:06:30 CET] <kevinnn> and the screen just does not look right [22:06:35 CET] <kevinnn> sorry it is a bit of a mess [22:07:41 CET] <mozzarella> guys [22:08:05 CET] <mozzarella> how can I set the speed of the output to be 240 times that of the original [22:08:23 CET] <mozzarella> original/input [22:15:20 CET] <JEEB> kevinnn: are you sure whatever you're doing with the I/O etc is not making you lose packets? [22:15:34 CET] <JEEB> if you try to read the stream with something like mpv, does it work? [22:15:42 CET] <JEEB> https://mpv.srsfckn.biz/ [22:15:46 CET] <JEEB> since you were on windows [22:15:51 CET] <JEEB> mpv "rtsp://blah" [22:16:22 CET] <JEEB> basically want to compare with something else using FFmpeg to decode video :P [22:16:46 CET] <kevinnn> we have tested it on VLC on windows and it worked okay there, but that was on a linux based system [22:17:56 CET] <JEEB> VLC utilizes FFmpeg's decoder when hardware decoding is disabled [22:18:13 CET] <JEEB> mpv just utilizes FFmpeg for pretty much all bits of it :P [22:18:46 CET] <JEEB> anyways, if swdec works then FFmpeg's H.264 decoder shouldn't have issues with your H.264 stream and the issue is somewhere else [22:19:02 CET] <JEEB> either receiving or depacketizing [22:19:29 CET] <JEEB> (and receiving issues can also be due to the sender and/or your network) [22:20:18 CET] <JEEB> I know that UDP rtsp tends to break with a *lot* of network stuff, while TCP works. so whenever you compare different reception of an RTSP stream you should check if it's using TCP or UDP RTSP [22:22:14 CET] <kevinnn> okay I am going to download and install mpv real quick and check to make sure it can stream correctly on my windows computer. But I am fairly certain it will work [22:22:19 CET] <kevinnn> also we are using UDP [22:22:30 CET] <kevinnn> so it must be depacketizing... [22:22:37 CET] <kevinnn> which is in the code I posted [22:22:46 CET] <JEEB> no install needed for mpv, it's just extract and call from command line [22:22:46 CET] <kevinnn> does it appear incorrect? [22:23:26 CET] <JEEB> I didn't check your decoding code too hard, but unless you're re-using AVFrames etc it should be OK [22:23:40 CET] <JEEB> also for the record, mpv defaults to TCP RTSP, you will have to set a separate parameter to udp [22:23:44 CET] <JEEB> *for UDP [22:23:48 CET] <JEEB> while the FFmpeg default is UDP [22:24:04 CET] <JEEB> so always check what the client attempts to connect with [22:24:05 CET] <kepstin> a common cause of receive issues on udp is that the application is running too slowly, and the os receive buffer fills so packets are lost. [22:24:29 CET] <kepstin> also your code has some strange variable naming, lots of "x264 decoder" stuff, but the x264 library is an encoder only :) [22:26:38 CET] <kevinnn> JEEB: okay how do I get mpv to use UDP? [22:26:51 CET] <kevinnn> can't find it in the options [22:27:11 CET] <forgon> I want to compress a video I created, but do not know which options I have. Could someone point me to a good link? [22:27:11 CET] <kevinnn> oh I found it! [22:27:14 CET] <JEEB> https://mpv.io/manual/master/#options-rtsp-transport [22:27:20 CET] <JEEB> yes, this thing :P [22:27:39 CET] <kevinnn> okay I think it is working... [22:27:44 CET] <kevinnn> but there is no GUI [22:27:53 CET] <forgon> I chose libx264 as video codec. [22:27:53 CET] <kevinnn> it just says it is playing [22:28:19 CET] <JEEB> mpv is very minimal, you just get on-screen controls on the video surface [22:28:42 CET] <JEEB> for more detailed logs see --log-file=mpv_sucks.log and then the log file it writes [22:28:45 CET] <kevinnn> onscreen controls? [22:29:04 CET] <kevinnn> so it is normal not to have visual output? [22:29:25 CET] <JEEB> no, if you have video it should be there [22:29:27 CET] <JEEB> https://user-images.githubusercontent.com/680386/47966850-2d349f00-e057-11e… [22:29:40 CET] <JEEB> that's the amount of controls you get by default on-screen :P [22:30:14 CET] <kevinnn> but no GUI even pops [22:30:21 CET] <kepstin> forgon: there's a convenient ffmpeg wiki page for that, here: https://trac.ffmpeg.org/wiki/Encode/H.264 [22:30:30 CET] <pink_mist> did you forget to build mpv with lua support? [22:30:33 CET] <JEEB> kevinnn: then no data is coming out or something else? [22:30:46 CET] <kevinnn> build? I didn't build mpv [22:30:47 CET] <kepstin> forgon: you generally want to use CRF mode, and the only options you might want to change there are usually "-crf" and "-preset" [22:30:50 CET] <JEEB> pink_mist: he's using the lachs0r's builds and he specifically switched to UDP for RTSP [22:30:54 CET] <pink_mist> ah [22:33:23 CET] <JEEB> kevinnn: anyways, rtsp has worked for me on a local network during testing (albeit TCP only because UDP would just get packets dropped by the network equipment) [22:33:42 CET] <JEEB> what about `ffprobe -v verbose rtsp://STUFF` [22:37:08 CET] <kevinnn> JEEB: for some reason mpv does not work with my rtsp stream... I am going to do some digging to figureout why.. [22:38:19 CET] <JEEB> that's why I noted you'd also check with ffprobe [22:49:58 CET] <forgon> While reading about codecs, I constantly run across x265 as alternative to x264. Is there a reason not to use it? [22:50:52 CET] <JEEB> not optimized (in both psychovisuals and speed) encoding, encodes into a format that is less supported by hardware (but you might be OK with that) [22:51:21 CET] <JEEB> if your use case is to just encode at a very low bit rate where things look really crap, then HEVC (which is what x265 encodes) might be worth it [22:51:29 CET] <JEEB> but only if you put the extra time into it [22:52:14 CET] <pink_mist> I've had issues software decoding x265 stuff too :/ [22:52:31 CET] <pink_mist> as in, stutters because my cpu can't keep up :/ [23:05:48 CET] <another> depends on cpu, load and resolution [23:22:44 CET] <pink_mist> my cpu was a 3.7GHz Core i3-6100 with 2 cores (4 threads), and the resolution was a 4k video played back on a 1080p screen, nothing else was causing any load [23:23:52 CET] <brimestone> hey guys, how would I approach this (speed). Source file is (ProRes 4K 444 10Bit LogC) and I want to create a 480x270 with 3dlut filtered. Should I scale the video to 480x270 then apply the lut? [23:29:35 CET] <kepstin> scaling then applying the lut will be faster than applying the lut then scaling. [23:32:22 CET] <kepstin> (if the resolutions were closer, it would be harder to say - iirc the lut3d filter needs rgb data, and I assume you're gonna want to convert to yuv420p after, so there's multiple conversions involved) [23:32:53 CET] <kepstin> i could be wrong about the rgb thing :) [23:34:34 CET] <kepstin> just checked, it is rgb. [23:40:46 CET] <kepstin> brimestone: in the end, your filter chain's probably gonna look like 4K yuv444p10le -> scale -> 480x270 rgb (of some sort, probably "bgr0" - should match bit depth of lut) -> lut3d -> scale -> 480x270 yuv420p [23:42:22 CET] <brimestone> it looks good, just need to figure out how to make it fast. [23:42:33 CET] <brimestone> Only getting about 0.0983xRT [23:42:40 CET] <brimestone> ~2.1 fps [23:43:20 CET] <kepstin> are you doing video encoding as well? [23:43:44 CET] <kepstin> I'd expect the slowest parts of an ffmpeg command doing that filter combination to be the video decoding on input and encoding on output [23:43:58 CET] <kepstin> after that, the downscale and conversion from 4k to 280x270 [23:45:12 CET] <kepstin> it would be worth running with no output - replace your output file with "-f null /dev/null" - to see if the output is the bottleneck [23:45:19 CET] <kepstin> (and remove and -c options) [23:45:25 CET] <brimestone> Im basically doing this. https://gist.github.com/brimestoned/9cc865bd12d66586b0d4f5ff7b35f543 [23:45:40 CET] <kepstin> also try dropping the filter chain and see how fast it can manage decoding only [23:45:52 CET] <kepstin> ok, so i see your issue [23:45:57 CET] <kepstin> you're not downscaling :) [23:46:09 CET] <kepstin> each -vf option *replaces the entire filter chain* [23:46:29 CET] <kepstin> you need to use `-vf scale=480:270,lut32=/path/to/file` [23:46:40 CET] <brimestone> Oh... let me try that. [23:46:42 CET] <kepstin> fixing my typo of course [23:47:13 CET] <kepstin> right now it's slow because libx264 is encoding 4k video (possibly 10bit even) [23:48:36 CET] <kepstin> i'd expect libx264 to be complaining that you're exceeding the level limits on that encode too, and you should have noticed that the output video resolution (next time, please also include the console output of the ffmpeg command in your paste) was incorrect. [23:50:45 CET] <brimestone> wow.. its faster! [23:54:06 CET] <kevinnn> Hi all, does "[udp @ 00395860] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)" jeopardize performance? [23:54:16 CET] <kevinnn> and if it does how can I get rid of it? [23:54:43 CET] <kepstin> kevinnn: it means that your build can't run the receive in a separate thread, which means it has a higher chance of dropping packets [23:54:55 CET] <kepstin> and the answer is to find or build an ffmpeg with working threads. [23:55:21 CET] <kevinnn> I am on windows and it is a crazy pain to get it to build with pthread support [23:55:29 CET] <kevinnn> and pre-built ones i can use? [23:55:33 CET] <JEEB> that UDP protocol feature is specifically implemented with only native pthreads (or wrappers of thereof) [23:55:49 CET] <JEEB> also man, are you still on about this stuff? are you that guy I helped before? [23:56:10 CET] <linext> ffmpeg has been working very well for recording security cam video stream. thanks for the help [23:56:28 CET] <kevinnn> yes I am that guy :) and I appreciate the continued support [23:57:06 CET] <kevinnn> right but I am a linux guy. and getting pthread to compile nicely with ffmpeg on windows is a nightmare [23:57:15 CET] <kevinnn> one I have yet to get right yet [23:57:17 CET] <JEEB> uhh [23:57:22 CET] <JEEB> on linux pthreads is what you use [23:57:27 CET] <JEEB> so linux is not your problem [23:57:32 CET] <JEEB> not sure why you mention it [23:57:37 CET] <linext> the -c copy argument was very helpful for reducing the CPU usage from 25% to 5% [23:58:07 CET] <kevinnn> I mention it because compiling this stuff on windows is a pain in comparison to how things are built in linux [23:58:17 CET] <kevinnn> and integrated into visual studio [23:58:34 CET] <kevinnn> are there any pre-built binaries available with pthread built in? [23:58:43 CET] <JEEB> I'd say it's pretty much the same :P integration for visual studio I have no idea and I have no interest of. as long as the libraries and headers are around it gets found and that's as much as I care [23:58:54 CET] <JEEB> kevinnn: I think if you want that feature the best alternative would be to have it implemented in the UDP protocol [23:59:08 CET] <JEEB> which is either you coding it, or putting up a bounty on it [23:59:34 CET] <JEEB> because last time you tried whatever pthreads wrapper it crashed IIRC [23:59:40 CET] <JEEB> so I'm not going to waste time with that [00:00:00 CET] --- Tue Mar 5 2019

1 0

ffmpeg-devel.log.20190303
by burek 04 Mar '19

04 Mar '19

[06:08:43 CET] <cone-249> ffmpeg 03Gyan Doshi 07master:fda793f6fa76: configure: select rotation filters for ffmpeg [06:30:00 CET] <cone-249> ffmpeg 03Gyan Doshi 07master:73b62f302695: doc/protocols: move option follow entry to correct section [10:21:53 CET] <BtbN> nothing in that yadif_cuda ticket makes sense [10:40:14 CET] <durandal_1707> nobody working on full DNG support in FFmpeg? [12:18:18 CET] <kurosu> can confirm maseck's numbers for cdef_dir_8bpc_avx2: 96->86 on HSW [12:18:38 CET] <j-b> that is cool. [13:19:21 CET] <cone-249> ffmpeg 03Michael Niedermayer 07master:1eb35eb50ed3: avcodec/diracdec: Correct max pixels check [13:19:22 CET] <cone-249> ffmpeg 03Michael Niedermayer 07master:b8ecadec0582: avcodec/bethsoftvideo: Check block_type [13:19:23 CET] <cone-249> ffmpeg 03Michael Niedermayer 07master:5cf42f65b60d: avcodec/gdv: Check for truncated tags in decompress_5() [13:19:24 CET] <cone-249> ffmpeg 03Michael Niedermayer 07master:951bb7632fe6: avcodec/aic: Check remaining bits in aic_decode_coeffs() [13:19:25 CET] <cone-249> ffmpeg 03Michael Niedermayer 07master:b819472995f5: avcodec/qpeg: Limit copy in qpeg_decode_intra() to the available bytes [17:07:20 CET] <philipl> BtbN: Yeah. Nothing makes sense. I don't know how people get into these situations. [17:35:59 CET] <JEEB> durandal_1707: mp4 has bit rate info since it literally reads the index, btw. I went through that with the guy [17:36:06 CET] <JEEB> and I'm not going to waste any more time on that person [17:36:15 CET] <durandal_1707> lol [17:36:48 CET] <JEEB> how libavformat/-codec decide to set a bit rate to something is more or less random and/or guesswork so that's the best reply you can give the guy [18:13:25 CET] <durandal_1707> could we guess audio bitrate from some info like we do for video? [18:13:57 CET] <JEEB> we probably do already [18:34:25 CET] <durandal_1707> JEEB: not really, ff_guess_coded_bitrate() only do for raw video [18:34:56 CET] <JEEB> ok, dunno. but really, I'm not liking adding more and more random guesswork just because users complain that there's no bit rate value somewhere [18:35:17 CET] <JEEB> I think we already report bit rates in way too many places where we're potentially just guesstimating it [18:44:38 CET] <cone-799> ffmpeg 03Paul B Mahol 07master:a367a932d36a: avcodec/utils: remove commented out obsolete code [18:57:37 CET] <taliho> Hello, I've been looking over the libavformat/mpegts.c code. The function mpegts_read_header currently needs to buffer 8192bytes to identify raw packet size (i.e. 188, 192 or 204 bytes). To avoid having to buffer 8192bytes, I would like to modify this part of the code so that it is similar to av_probe_input_format (dynamic buffer until a good score is identified). Anyone have feedback or objections? [18:59:31 CET] <JEEB> taliho: so adding a read_probe there? [18:59:43 CET] <JEEB> into AVInputFormat of MPEG-TS [19:01:34 CET] <JEEB> in theory it makes sense but I do wonder how much the framework would like that you don't have any streams or anything [19:02:04 CET] <JEEB> if I understand it correctly you just want to be able to open the demuxer without any buffer handled [19:02:27 CET] <JEEB> since in mpegts_read_header it also checks for SDT/PAT [19:11:57 CET] <taliho> in mpegts_read_header, the only role of buffering 8192bytes is to first set the variable raw_packet_size. I looked at git blame, and the size of buffer appears to have changed from 1024 -> 5*1024 -> 8*1024 bytes. I was thinking why not iteratively check the score (for 188/192/204). If the score is high enough, then we do not need to continue to buffer data, else grow the buffer and check again. [19:12:33 CET] <JEEB> yes, but if your idea is to minimize buffering? [19:12:57 CET] <JEEB> then you would be basically wanting the thing to read a minimum amount of stuff and not wait for SDT/PAT? [19:12:58 CET] <taliho> JEEB: once raw_packet_size is set, only then set SDT/PAT [19:13:09 CET] <JEEB> ah [19:13:14 CET] <JEEB> yes now I see [19:13:22 CET] <JEEB> it was there even more in the beginning of the function [19:13:34 CET] <taliho> yes [19:19:07 CET] <JEEB> taliho: anyways, what is your idea of your change other than just utilizing any buffer that you have around and then possibily implementing the probe callback for further probing? [19:25:53 CET] <taliho> JEEB: I believe this change would reduce latency to real-time streaming. I.e. For a 100kbps stream, having to buffer 8192bytes is 0.65 seconds of latency [19:27:40 CET] <JEEB> no, I understand that [19:27:46 CET] <JEEB> I was just interested in the changes otherwise [19:28:16 CET] <taliho> oh I see, for now that's the only change :) [19:28:30 CET] <JEEB> being what exactly? [19:28:42 CET] <JEEB> your comments didn't exactly show me what exactly you thought of changing [19:28:52 CET] <JEEB> I get the idea of what you're attempting to affect [19:29:17 CET] <JEEB> but I don't yet grasp what exactly you are planning on doing to get that effect [19:29:34 CET] <taliho> I see [19:29:58 CET] <JEEB> also does libavformat even successfully open the demuxer if you don't get *any* streams etc? [19:31:22 CET] <JEEB> also so that ffmpeg.c etc could keep getting similar results, what about making a probe function then that would do similar stuff just to get some stuff initialized? [19:31:44 CET] <JEEB> if what I'm saying makes any sense :P [19:33:14 CET] <taliho> that's a good question, I know once you open the stream. You know the number of AVStreams present. I would have to check if the stream is not valid [19:34:15 CET] <JEEB> the AVStream count can raise with time, of course. that by itself is not a problem [19:34:29 CET] <JEEB> I just wonder if lavf had any stupid limitations [19:39:28 CET] <taliho> that's a good question, I know once you open the stream. You know the number of AVStreams present. I would have to check if the stream is not valid [19:39:54 CET] <JEEB> you only know that if you have read enough of the input [19:40:01 CET] <taliho> sorry, posted wrong message [19:40:10 CET] <JEEB> I'm talking about a case where you open an AVInputFormat without any data in the buffer [19:41:14 CET] <JEEB> since effectively to have "zero buffering" during opening that's what you'd do [19:41:23 CET] <JEEB> and then you would just start reading packets [19:42:54 CET] <taliho> yes, I believe the function avio_read() blocks if you are waiting for data [19:49:10 CET] <taliho> JEEB, just to summarize this is what I would like to modify: In function mepgts_read_header: Modify the way that ts_raw_packet_size is evaluated. Then, continue with the flow of the code after the check (ts->raw_packet_size <= 0) [19:53:34 CET] <taliho> To evaluate raw_packet_size: 1) Read a buffer 1024bytes 2) Calculate the score for packets 188/192/204. If the score is above a threshold, then set raw_packet_size. Else read another packet, and recalculate the probe scores. Continue until a limit is reached, else set a default ts_raw_packet_size=188 [20:06:05 CET] <BtbN> philipl, I'd say it's a permission error on /dev/nvidia, but then again, nothing would work in the first place then?! [20:22:57 CET] <cone-799> ffmpeg 03Paul B Mahol 07master:17008a010753: avcodec/hcom: check that index into array is valid [22:43:46 CET] <cone-799> ffmpeg 03Jan Ekström 07master:4635f649534b: lavc/libx265: signal CPB properties through side data [23:51:23 CET] <philipl> BtbN: unless he's selectively using sudo and not telling us, which is sort of what I read out of the last couple of comments. [00:00:00 CET] --- Mon Mar 4 2019

1 0

ffmpeg.log.20190303
by burek 04 Mar '19

04 Mar '19

[00:13:15 CET] <ricemuffinball> why does x264 have such a crappy version # system [00:14:09 CET] <furq> did you ask in #x264 [00:14:20 CET] <ricemuffinball> yes, that room is deaed [00:14:37 CET] <furq> well then keep asking it every five minutes until they answer you [00:14:48 CET] <ricemuffinball> thank you ffmpeg for not using crappy version # system like x264 [00:20:58 CET] <BtbN> don't they just count up? [00:23:12 CET] <pink_mist> apparently that's crappy [00:23:43 CET] <pink_mist> perhaps they should restart at -1 and count down [00:26:21 CET] <ricemuffinball> lol @ even an user from x264 cannot give me the latest version of x264 [00:27:01 CET] <ricemuffinball> [15:19] <ricemuffinball> why does x264 have such a crappy version # system [00:27:02 CET] <ricemuffinball> [15:20] <JEEB> in what sense [00:27:03 CET] <ricemuffinball> [15:21] <ricemuffinball> what is the lastest version of x264 now [00:27:04 CET] <ricemuffinball> [15:21] <ricemuffinball> i bet most people don't even know [00:27:05 CET] <ricemuffinball> [15:22] <JEEB> do you mean the master or stable branch? [00:27:05 CET] <another> linext: if you just want to record, you should put '-c copy' after the input [00:27:06 CET] <ricemuffinball> [15:22] <ricemuffinball> because of crappy version # system [00:27:07 CET] <ricemuffinball> [15:22] <ricemuffinball> stable [00:27:08 CET] <ricemuffinball> [15:23] <JEEB> and yes, the version number is twofold. the most user visible one is just a number going upwards and the hash mentioned there is more useful looking at the history. the number is mostly to see if one version is later in the history than the other [00:27:09 CET] <ricemuffinball> [15:23] <JEEB> then separately there's API versions which change every time a thing is changed in the API (feature added, removed etc) [00:27:10 CET] <ricemuffinball> [15:23] <ricemuffinball> lol you can't even name it right now [00:27:11 CET] <ricemuffinball> [15:23] <ricemuffinball> even you can't even say it [00:27:12 CET] <ricemuffinball> [15:23] <ricemuffinball> i know latest version of ffmpeg and x265 right now [00:27:13 CET] <ricemuffinball> [15:24] <ricemuffinball> 4.1.1 3.0 [00:27:14 CET] <ricemuffinball> [15:24] <ricemuffinball> yet you can't even name x264 version # after 5 min [00:27:18 CET] <BtbN> can you not? [00:33:11 CET] <linext> another: added, what's it do? [00:33:18 CET] <linext> was the video being re-encoded? [00:33:39 CET] <JEEB> if you don't set an encoder then FFmpeg picks [00:33:53 CET] <JEEB> you have lists for different containers and it will pick the first that it has an encoder for [00:34:14 CET] <linext> is it better to let ffmpeg re-encode in case the stream has errors? [00:43:04 CET] <DHE> I just realized I have patches to submit against ffmpeg still sitting... [04:04:06 CET] <Felishia> does anyone know how I can use ffmpeg to crop a 3gp file? [04:04:11 CET] <Felishia> every time I try I get errors [04:04:32 CET] <Felishia> Automatic encoder selection failed for output stream #0:1. Default encoder for format 3gp (codec amr_nb) is probably disabled. [04:04:57 CET] <Felishia> The specified picture size of 1920x1080 is not valid for the H.263 codec. [04:05:10 CET] <Felishia> Valid sizes are 128x96, 176x144, 352x288, 704x576, and 1408x1152. Try H.263+ [04:05:25 CET] <Felishia> Unknown encoder 'H.263+' [04:11:45 CET] <DHE> you probably want -c copy on your commandline [04:14:22 CET] <pink_mist> does that work with cropping? [04:14:56 CET] <klaxa> no [04:20:44 CET] <Felishia> DHE: it wurked :D [04:20:48 CET] <Felishia> thanks thanks [04:34:29 CET] <pink_mist> well okay then [08:27:40 CET] <cards> Q: When FFMPEG merges an H624 MPEG AVC video with an MPEG AAC (mp4a) audio, it uses Opus Audio codec. Even changed the sample rate from 44100 Hz to 48000 Hz [08:27:49 CET] <cards> Why doesn't it just keep the original AAC [08:56:10 CET] <furq> cards: -c:a copy [08:56:18 CET] <furq> not sure which container you were using that defaults to opus though [08:56:41 CET] <cards> It was put into an mkv [08:56:54 CET] <furq> vorbis is still the default for mkv for some reason [08:57:01 CET] <furq> maybe it's opus if you don't have libvorbis [08:57:08 CET] <cards> huh. [08:57:24 CET] <cards> I thought it should be able to containerize AAC just fine without re-encoding [09:01:27 CET] <furq> it can, it's just not the default [09:37:30 CET] <fling> cards: use -c copy to prevent any reencoding [09:39:02 CET] <cards> fling, thanks. I'll mention that too for the yt-dl project, which sends the command to ffmpeg [09:39:52 CET] <fling> cards: you don't need this for youtube-dl [09:39:58 CET] <fling> cards: youtube-dl does not reencode by the default [09:40:05 CET] <cards> it does by default [09:40:18 CET] <fling> cards: give me an example, I never seen this behavior. [09:40:26 CET] <cards> https://www.youtube.com/watch?v=2ZL0tbOZYhE [09:40:31 CET] <fling> And the command is? [09:40:58 CET] <cards> no parameters beside that url [09:41:09 CET] <fling> No config file also? [09:42:13 CET] <cards> none [09:42:46 CET] <fling> cards: no reencode happening here, just merging into mkv with ffmpeg [09:43:05 CET] <cards> check the audio codec now [09:43:10 CET] <cards> was AAC now Opus [09:43:20 CET] <furq> well yeah youtube serves both [09:43:29 CET] <fling> cards: was? [09:43:36 CET] <cards> um. that m4a was AAC. Now it's Opus. [09:43:41 CET] <furq> youtube-dl has always done that with youtube for some reason [09:43:49 CET] <furq> it defaults to h264 and opus in mkv [09:43:51 CET] <fling> cards: what do you mean by was? When you uploaded it? [09:43:57 CET] <cards> no [09:44:03 CET] <cards> when you downloaded it, it started off as AAC [09:44:20 CET] <cards> when it gets packaged into your mkv, it becomes Opus [09:44:26 CET] <cards> this all happened on your computer [09:44:41 CET] <furq> what [09:44:50 CET] <furq> what command did you run [09:45:13 CET] <cards> youtube-dl.exe https://www.youtube.com/watch?v=2ZL0tbOZYhE [09:45:20 CET] <fling> cards: it downloads opus -> youtube-dl -x https://www.youtube.com/watch?v=2ZL0tbOZYhE [09:45:26 CET] <fling> cards: Stream #0:0(eng): Audio: opus, 48000 Hz, stereo, fltp (default) [09:45:48 CET] <cards> really? [09:45:54 CET] <furq> yeah [09:45:59 CET] <cards> When is it deciding to switch between AAC and Opus [09:46:02 CET] <fling> cards: use ffprobe to check it for yourself [09:46:05 CET] <furq> are you assuming it's mp4 because it says it's downloading an mp4 [09:46:08 CET] <furq> because that's just the video [09:46:14 CET] <cards> that's just the video [09:46:14 CET] <furq> assuming it's aac [09:46:17 CET] <cards> I'm talking about the audio [09:46:24 CET] <Mavrik> Yeah, youtube is serving both split for awhile now. [09:46:26 CET] <furq> well yeah where does it say aac [09:46:26 CET] <fling> it is downloading opus in webm container [09:46:31 CET] <cards> i know it's split [09:46:39 CET] <fling> Not just both but a lot of formats [09:46:40 CET] <cards> but it downloads the m4a not the webm [09:46:56 CET] <cards> i'm going to try again with -k so it keeps the downloads [09:47:00 CET] <cards> after merge [09:47:14 CET] <fling> cards: try `youtube-dl -F https://www.youtube.com/watch?v=2ZL0tbOZYhE` [09:47:44 CET] <furq> [youtube] playlist Crew Demo-1 Mission: Collected 2 video ids (downloading 2 of them) [09:47:47 CET] <furq> huh [09:47:50 CET] <furq> how is this a playlist [09:48:07 CET] <furq> the second video, whatever it is, doesn't have opus audio yet [09:48:08 CET] <cards> spacex does that. it's "switch view" [09:48:10 CET] <furq> so that might be the problem [09:48:50 CET] <cards> so you can switch between video feed and google earth trajectory feed [09:49:12 CET] <furq> anyway you can just use -f mp4 if you want to force it to use aac for both [09:49:31 CET] <cards> i don't know if that's the problem. looking at the console, it doesn't start playing with the 2nd video until the 1st video is already made into mkv [09:49:37 CET] <furq> the webm is usually higher quality though [09:49:50 CET] <cards> I want the AAC codec though [09:55:33 CET] <cards> so if I use --merge-output-format mp4, is it supposed to prefer downloadking the AAC .m4a so that it can be merged into an mp4 container [10:24:45 CET] <cards> There's nothing I can do to tell youtube-dl which format audio to download. if it would just download the AAC .m4a, it could be merged into the .mp4 container. But it's downloading mixed formats which raises a WARNING CANNOT MERGE [10:25:11 CET] <cards> so I guess this isn't exactly ffmpeg's fault afterall [10:32:25 CET] <another> cards: of course you can select what to download [10:32:49 CET] <another> -f [10:33:57 CET] <another> -f m4a+mp4 [10:35:47 CET] <another> -f bestvideo+m4a [10:38:14 CET] <another> you might wanna play with the formats a bit. it can be a bit tricky to have youtube-dl always select what you want [10:52:21 CET] <ricemuffinball> what does these 2 do? strong-intra-smoothing=0:rect=0 and should i use 0 or 1 [13:37:00 CET] <match_it> hi all. A question: Is ffserver still alive ? [13:39:43 CET] <JEEB> match_it: no. it has been removed quite some time ago. there was a completely separate "proper" API client made which might attempt into the future to be an "ffserver", but it's not the same thing. [13:40:58 CET] <JEEB> for most use cases you can either utilize ffmpeg.c itself and in cases where something has to be provided to external clients through HTTP or so, some media server (which can be either a separate application or a module in an existing HTTP server) [13:42:20 CET] <match_it> thanks JEEB - so, what you suggest as media server ? [13:42:34 CET] <JEEB> what is your use case? [13:43:43 CET] <match_it> my case is to upstream from some sources to a VPS server and then to broadcast to Web players [13:44:11 CET] <match_it> some sources are some clients (let's say 12) [13:44:23 CET] <match_it> broadcast to 200 clients [13:44:50 CET] <JEEB> well, in theory even ffmpeg.c can itself output HLS or DASH into any HTTP server as long as you white list your encoders to be able to POST/RENAME/DELETE [13:45:04 CET] <JEEB> so you don't really need any more of a media server there [13:45:13 CET] <JEEB> if the HTTP "streaming" things are what you need [13:45:43 CET] <JEEB> for example https://www.ffmpeg.org/ffmpeg-all.html#hls-2 [13:45:51 CET] <JEEB> the output for this can be a HTTP URL [13:49:20 CET] <match_it> JEEB , in your experience, is a standard VPS suitable for 200 viewers (at 480/320px) over http ? [13:50:37 CET] <match_it> It's my first experience to output video for so many clients, I would figure out if I'm completely wrong [13:54:07 CET] <JEEB> no idea, you could use locust or something to script a load test if you want. but you don't really need a lot of CPU for just serving content (since you're not doing dynamic packaging), it's mostly I/O and bandwidth that you should be calculating [13:54:31 CET] <match_it> infact [13:54:55 CET] <match_it> thanks JEEB [13:55:00 CET] <match_it> thanks all [13:55:45 CET] <BtbN> match_it, you will run into bandwidth issues with way fewer viewers, even if you have a gigabit line for yourself [13:55:55 CET] <DHE> can confirm [13:57:07 CET] <match_it> mmmm [13:57:51 CET] <match_it> p2p protocols can help ? [13:59:35 CET] <ricemuffinball> why doesn't opus file show bitrate whenever it's muxed into video file? [14:00:49 CET] <JEEB> ricemuffinball: probably because calculation of the bit rate is not implemented in whatever container you are dealing with [14:01:14 CET] <ricemuffinball> jeeb it works with other audio codec [14:01:16 CET] <JEEB> which depending on the file format can mean going through the whole thing start to finish [14:01:38 CET] <JEEB> ricemuffinball: and my comment still stands. if the value's not there the calculation is not there [14:01:42 CET] <ricemuffinball> jeeb so are you blaming the container or the opus ? [14:01:46 CET] <JEEB> no [14:02:02 CET] <ricemuffinball> i just want to know whose fault it is then [14:02:15 CET] <JEEB> I have no fricking idea :P [14:02:31 CET] <ricemuffinball> jeeb i think you do know [14:02:48 CET] <JEEB> no I do not unless I start digging in the code and to be honest it's a goddamn sunday [14:03:02 CET] <JEEB> not to mention that it depends on the container 100% and you haven't even told that part [14:03:16 CET] <ricemuffinball> jeeb mkv [14:04:52 CET] <JEEB> ok, so at the very least to get an accurate average bit rate you would have to parse all the indexes. not sure what the worst case thing for that is. but anyways, you're welcome to check how other audio formats' bit rate is set in that case in libavformat's matroska related files [14:05:58 CET] <ricemuffinball> i do remember aac having this issue with mkv as well (but not on mp4) [14:06:15 CET] <ricemuffinball> but over the years it got fixed [14:06:33 CET] <BtbN> Why is that issue even an issue? [14:06:53 CET] <ricemuffinball> btbn because it showed perfectly fine with mp4 [14:07:01 CET] <BtbN> And why does it matter? [14:07:06 CET] <ricemuffinball> btbn i care [14:07:59 CET] <furq> if this is mediainfo then it only works for mkv if the audio stream is cbr [14:08:07 CET] <furq> or if there's only one vbr stream in the file, more accuraetly [14:08:12 CET] <ricemuffinball> i care if audio i am listening to is 128k or 256k or 80k etc [14:08:27 CET] <BtbN> What if it's VBR? [14:08:37 CET] <furq> if it's vbr it didn't work last i checked [14:08:39 CET] <JEEB> many players calculate their own averages anyways [14:08:48 CET] <furq> also yeah your player will tell you the real bitrate if it's any good [14:08:48 CET] <JEEB> like mpv does if you press big-i [14:08:59 CET] <JEEB> you get it in the stats over a running window [14:09:09 CET] <furq> either I works [14:09:13 CET] <JEEB> because unsurprisingly quite a few things are VBR nowadays [14:09:25 CET] <JEEB> yes, big-i just keeps it around until you press that around [14:09:46 CET] <furq> BtbN: mediainfo does it by just subtracting the cbr bitrate(s) from the total bitrate of the file [14:10:02 CET] <furq> if there's more than one vbr stream then it has no way of guessing [14:10:11 CET] <JEEB> well, you can do the full file parsing [14:10:15 CET] <JEEB> or at least indices if it's mp4 [14:10:24 CET] <furq> sure but they understandably don't want to do that [14:10:26 CET] <JEEB> anyways, in libavformat I have no idea how it sets the AVStreams' bitrate field [14:10:36 CET] <ricemuffinball> if mediainfo has a way to find this, why doesn't mediainfo work with opus/mkv [14:10:43 CET] <furq> because of all of the things i just said [14:11:30 CET] <ricemuffinball> so whose fault is this [14:11:42 CET] <ricemuffinball> everybod is blaming each other [14:11:51 CET] <mux> yours [14:12:03 CET] <furq> it's both mediainfo and matroska's fault and they both know about it and have no intention of fixing it [14:12:04 CET] <JEEB> I don't think anyone here is blaming anyone [14:12:13 CET] <furq> "fixing" [14:12:22 CET] <JEEB> it's just reasons why some applications would not be doing the full monty [14:12:27 CET] <JEEB> to get the data [14:12:42 CET] <JEEB> because getting the overall size of a multiplexed track is not always simple [14:12:52 CET] <JEEB> + overall duration at hte same time [14:13:14 CET] <ricemuffinball> furq wow, i like that you are only one here who has balls to say that [14:13:27 CET] <ricemuffinball> <furq> it's both mediainfo and matroska's fault [14:13:39 CET] <furq> thanks for omitting the bit where i said it's not a problem [14:13:48 CET] <ricemuffinball> furq who do you say is more of a fault? [14:14:06 CET] <furq> 13:11:51 ( mux) yours [14:14:06 CET] <ricemuffinball> furq, you sure opus has no fault in this? [14:14:10 CET] <furq> starting to come around to this point of view [14:14:32 CET] <match_it> JEEB : I think to roll back to ver 3.4 - do you know if ffserver was discontinued for any particular reason ? [14:14:47 CET] <JEEB> match_it: nobody wanted to maintain it and it was barely working for many use cases [14:14:47 CET] <ricemuffinball> i remember aac/mkv had this problem too when aac/mp4 mp3/mkv mp3/mkv all worked fine [14:15:14 CET] <JEEB> if the audio format has a bit rate field that's a possible lead. or the first X megabytes of packets are parsed and a guesstimate is formed [14:15:38 CET] <JEEB> but neither of those are the actual data because things can change [14:15:41 CET] <JEEB> of course users don't care :P [14:15:45 CET] <JEEB> they just want to see a number [14:15:54 CET] <JEEB> whether that number is the reality or not is whole different [14:15:55 CET] <ricemuffinball> furq also if ffprobe cannot acomplish this either, shouldn't you also fault ffmpeg [14:17:44 CET] <pink_mist> it's not a fault [14:17:48 CET] <pink_mist> it's intended [14:19:22 CET] <JEEB> ricemuffinball: this is basically the reason why often bit rate is omitted: https://megumin.fushizen.eu/screenshots/dvbinspector/2017-05-mx_mux.png [14:19:35 CET] <JEEB> if you take for example the light blue as audio, and yellow as video [14:20:15 CET] <JEEB> of course it still doesn't explain apparent randomness in if you get a value or not :P [14:20:22 CET] <JEEB> which is a bad thing, yes [14:20:52 CET] <ricemuffinball> jeeb but that doesn't explain why aac/mp4 worked fine but aac/mkv didn't work 6 years ago [14:21:10 CET] <JEEB> of course not, see my second/third sentences [14:21:15 CET] <ricemuffinball> and mp3 always worked [14:21:23 CET] <JEEB> ahahahahaha [14:21:24 CET] <JEEB> no [14:21:36 CET] <JEEB> I'm pretty sure you can feed a raw mp3 file [14:21:44 CET] <JEEB> and get a completely bogus value out of it [14:22:02 CET] <JEEB> often mp3 encoders were rather static so you did often get a relatively close value [14:22:41 CET] <JEEB> you would probably always get *a* value, which is all that matters to a user [14:22:52 CET] <JEEB> whether that value was bogus or not didn't seem to matter [14:26:01 CET] <ricemuffinball> i just came across another aac/mkv file that does not show bitrate [14:26:20 CET] <ricemuffinball> ffmpeg -i R:\a.mkv -vcodec copy -acodec copy -movflags faststart R:\b.mp4 [14:26:32 CET] <ricemuffinball> i did this and ffprobe the b.mp4 and it shows [14:27:40 CET] <ricemuffinball> i am so confused [14:27:40 CET] <pink_mist> I'm pretty sure JEEB already explained why to you [14:28:15 CET] <ricemuffinball> pink_mist not about not working with mkv and working with mp4 [14:28:24 CET] <pink_mist> yes he did [14:28:29 CET] <ricemuffinball> where? [14:28:46 CET] <pink_mist> 14:10 <JEEB> or at least indices if it's mp4 [14:29:06 CET] <ricemuffinball> that doesn't explain anything [14:29:19 CET] <pink_mist> yes it does [14:34:52 CET] <ricemuffinball> furq does ffprobe depend on mediainfo to fix a problem first to get it working [14:35:28 CET] <JEEB> not at all, but it is highly unlikely to make it any more consistent unless someone cares to make a full parsing mode [14:36:05 CET] <JEEB> of course, what you care about is not consistness nor correctness of the value. you just want *a* value. or am I incorrect? [14:36:08 CET] <ricemuffinball> then why did they type: <furq> it's both mediainfo and matroska's fault [14:36:41 CET] <ricemuffinball> jeeb of course i care about correctness of the value [14:37:13 CET] <JEEB> ok, then I'll have to break the bad news to you that it probably is currently bogus in a lot of cases. congratulations. [14:37:14 CET] <ricemuffinball> Audio: Opus 48000Hz stereo 3072kbps [A: Stereo (opus, 48000 Hz, stereo) [default]] [14:37:29 CET] <ricemuffinball> that value means nothing [14:37:49 CET] <JEEB> and not only in FFmpeg or related tools [14:40:02 CET] <ricemuffinball> i just got this error: opus in MP4 support is experimental, add '-strict -2' if you want to use it. [14:40:18 CET] <JEEB> yup, that was never finished. and I hate that message because -2 is "experimental" which is human-readable [14:40:26 CET] <ricemuffinball> why is that experimental, youtube uses opus mp4 all the time [14:40:39 CET] <JEEB> yup, and nobody waited for the specification to finsh [14:40:40 CET] <BtbN> Because there's no spec I assume [14:40:44 CET] <JEEB> there is a spec [14:40:46 CET] <JEEB> just never finished [14:40:54 CET] <ricemuffinball> then why is youtube using opus/mp4 [14:40:59 CET] <BtbN> Because [14:41:00 CET] <JEEB> http://opus-codec.org/docs/opus_in_isobmff.html [14:42:09 CET] <JEEB> neither mozilla nor google decided to wait for it to get finished since it was considered "good enough" for the youtube use case. although I think youtube still uses opus in webm (matroska)? [14:43:01 CET] <ricemuffinball> if the spec is unfinished why doesn't opus/mp4 have this bitrate issue? Stream #0:1(und): Audio: opus (Opus / 0x7375704F), 48000 Hz, mono, fltp, 59 kb/s (default) [14:43:28 CET] <JEEB> because mp4 if it is indexed has an index, and libavformat calculates the average bit rate over the index [14:43:39 CET] <JEEB> st->codecpar->bit_rate = sc->data_size * 8 * sc->time_scale / st->duration; [14:43:49 CET] <JEEB> data size * 8 => size of stream in bits [14:44:00 CET] <BtbN> That 59kb/s looks very inaccurate [14:44:14 CET] <JEEB> it's an average, that's what it is probably [14:44:18 CET] <BtbN> And says nothing over the quality really [14:44:25 CET] <JEEB> of course not [14:44:34 CET] <ricemuffinball> btbn let me extract just the opus and i will do the ffprobe [14:44:39 CET] <BtbN> It could be 300kbps during high complexity, but the audio is very simple most of the time [14:45:08 CET] <JEEB> anyways, I will go enjoy the outside and for a while, it's a nice sunday weather with snow here :P [14:47:39 CET] <ricemuffinball> i extracted just the audio to a.mka : Bit rate : 59.7 kb/s [14:48:20 CET] <BtbN> so? [14:48:26 CET] <BtbN> Still doesn't mean much [14:48:29 CET] <ricemuffinball> <BtbN> That 59kb/s looks very inaccurate : so you are wrong [14:49:03 CET] <BtbN> I feel like you just don't want to understand... [14:49:33 CET] <BtbN> That bitrate is the AVERAGE. It says nothing about the quality or really anything important. [14:49:46 CET] <ricemuffinball> i can always find the audio bitrate if i extract just the audio file and ffprobing it [14:50:08 CET] <BtbN> I don't get what you're going at, and I don't care anymore. Have a nice day. [14:50:46 CET] <Blacker47> youtube uses dash where audio and video are not muxed. [14:51:01 CET] <ricemuffinball> JEEB youtube would never use MKV, since browsers have problem with mkv [14:52:16 CET] <ricemuffinball> Blacker47 i dbout that [14:52:35 CET] <ricemuffinball> youtube uses mp4/webm [14:52:46 CET] <pink_mist> ricemuffinball: hint: webm *IS* mkv [14:52:54 CET] <pink_mist> ricemuffinball: also, it certainly does use DASH too. [14:52:54 CET] <bencoh> sorta [14:52:57 CET] <ricemuffinball> pink_mist no it's not [14:53:12 CET] <ricemuffinball> mkv does not work on firefox [14:53:23 CET] <Blacker47> [14:52:46] <pink_mist> ricemuffinball: hint: webm *IS* mkv <-- what? [14:55:16 CET] <ricemuffinball> webm only supports opus/vorbis audio [14:55:23 CET] <ricemuffinball> mkv supports a lot of audio [15:09:31 CET] <another> ricemuffinball: i suggest you read up a bit about webm, mkv, dash [15:09:41 CET] <another> wikipedia is a good place to start [15:10:06 CET] <another> also youtube-dl with -F might give you some insight [15:10:52 CET] <another> and since you seem to be *really* into bitrates: https://megumin.fushizen.eu/screenshots/dvbinspector/2017-05-mx_mux.png [15:11:09 CET] <another> damn. wrong link. https://github.com/zeroepoch/plotbitrate [15:11:58 CET] <Mavrik> oh man, where was this project when I needed it :P [15:15:27 CET] <another> it's sometimes broken [15:15:32 CET] <another> like on mp3 [15:27:46 CET] <ricemuffinball> somebody in #opus is saying opus supports 44.1khz and 96khz, is this BS? [15:28:17 CET] <durandal_1707> nope [15:28:55 CET] <ricemuffinball> somebody here told me opus only support 48khz [15:32:33 CET] <durandal_1707> sure, just use mpeg-h then [15:33:00 CET] <ricemuffinball> huh [16:01:43 CET] <another> i guess you can make a custom version of opus that does https://wiki.xiph.org/OpusFAQ#What_is_Opus_Custom.3F [16:02:07 CET] <another> but unless you have really good reasons, you probably shouldn't [17:03:41 CET] <ricemuffinball> <opus-dev> ffmpeg is unquestionably great software for multimedia, but some of the decisions that were made about its behaviour can only be described as stupid. [17:04:01 CET] <ricemuffinball> wow [17:04:59 CET] <ricemuffinball> opus people dissing on ffmpeg [17:05:10 CET] <Kuukunen> yea, maybe a group of developers who disagree with the decisions should band together and make a fork... it's open source after all! [17:06:30 CET] <durandal_1707> ricemuffinball: ask him what decisions [17:06:35 CET] <Ke> if you would fork every software that had some * in it, you even would run out of disk space before going insane [17:07:46 CET] <Ke> you could just as well go all templeos [17:09:03 CET] <DHE> I've found some things in ffmpeg that needed changing, but all my diff can fit on a single screen [17:11:55 CET] <ricemuffinball> durandal_1707 that ffprobe/ffmpeg doesn't properly work with opus and mkv [17:12:18 CET] <durandal_1707> nonsense [17:13:45 CET] <ricemuffinball> well they are blaming on ffmpeg [17:14:13 CET] <ricemuffinball> and they won't take responsibility of birate not showing properly [17:19:20 CET] <durandal_1707> ricemuffinball: ffmpeg/ffprobe show bitrate only if it is stored in bitstream. [17:19:41 CET] <ricemuffinball> does mp4 store in bitstream? [17:19:45 CET] <durandal_1707> ffmpeg may calculate it in some cases too [17:19:53 CET] <ricemuffinball> opus/mp4 store in bitstream? [17:20:28 CET] <durandal_1707> ricemuffinball: search source code for bit_rate [17:20:43 CET] <ricemuffinball> durandal_1707 yes or no [17:21:36 CET] <durandal_1707> ricemuffinball: no [17:21:58 CET] <ricemuffinball> then why does opus/mp4 bitrate show fine with ffprobe [17:22:33 CET] <ricemuffinball> if it's not stored in bitstream [17:24:50 CET] <durandal_1707> ricemuffinball: from container or codec itself? there are 2 bit_rates [17:25:13 CET] <ricemuffinball> from mp4 container [17:25:16 CET] <durandal_1707> opus as codec itself does not have such metadata [17:25:34 CET] <durandal_1707> ricemuffinball: that is mp4 feature and not opus one [17:26:08 CET] <ricemuffinball> then why opus/mkv cannot display audio bitrate [17:26:33 CET] <ricemuffinball> opus people are blaming on ffmpeg [17:28:37 CET] <durandal_1707> ricemuffinball: ffprobe with opus/mkv shows bit_rate just fine [17:28:47 CET] <ricemuffinball> not here [17:29:01 CET] <durandal_1707> your fault [17:29:08 CET] <ricemuffinball> how is that my fault [17:29:15 CET] <ricemuffinball> i am using 4.1.1 binary [17:29:34 CET] <durandal_1707> and how you got opus/mkv? [17:29:54 CET] <ricemuffinball> i muxed it using ffmpeg [17:29:59 CET] <durandal_1707> how? [17:30:32 CET] <ricemuffinball> using the mux command [17:30:48 CET] <mux> using the ricemuffinball command [17:31:00 CET] <ricemuffinball> mux huh? [17:31:07 CET] <durandal_1707> full uncut FFmpeg console output missing [17:31:18 CET] <ricemuffinball> durandal_1707 huh? [17:32:30 CET] <pink_mist> ricemuffinball: he means that if you actually want help with your issue, you need to show the exact commandline you used, and the full output it generated, not just "using the mux command" [17:33:09 CET] <ricemuffinball> oh [17:34:01 CET] <ricemuffinball> ffmpeg -i R:\a.mp4 -vcodec copy -acodec copy R:\b.mkv [17:35:11 CET] <durandal_1707> ricemuffinball: and a.mp4 have bitrate info? [17:35:18 CET] <ricemuffinball> durandal_1707 correct [17:35:54 CET] <ricemuffinball> durandal_1707 6 years ago aac/mkv had the same issue [17:36:05 CET] <durandal_1707> can you share/upload a.mp4 somewhere? [17:36:28 CET] <ricemuffinball> yes if i can cut it [17:36:56 CET] <CounterPillow> I've heard there's some juicy shit in here [17:37:22 CET] <ricemuffinball> CounterPillow who told you that [17:37:42 CET] <CounterPillow> Oh there is the juicy shit in question. [17:38:44 CET] <ricemuffinball> durandal_1707 how did ffmpeg fix the aac/mkv issue 6 years ago [17:39:17 CET] <andy1978> How is it supposed to get the object type for a mp4 container from the codec_id? There is a list in isom.c, in my example I'm looking for AV_CODEC_ID_H264 which results in 0x21 which I have to give as fourcc. But isn't there a public API for this? [17:39:52 CET] <JEEB> andy1978: so what are you trying to do exactly? [17:40:09 CET] <JEEB> that would then help us help you what you could/should use [17:40:33 CET] <ricemuffinball> where can i download ffmpeg from 6 years ago [17:40:45 CET] <CounterPillow> There's a version control system [17:41:01 CET] <durandal_1707> ricemuffinball: some developer posted patch on mailing list fixing bug and voila... [17:41:05 CET] <CounterPillow> you can check out any commit of ffmpeg you'd like, going very far back. [17:41:22 CET] <durandal_1707> yes, even into dark ages [17:41:35 CET] <ricemuffinball> durandal_1707 and how do i find the name of that dev [17:41:46 CET] <ricemuffinball> who fixed the aac/mkv bitrate bug [17:42:21 CET] <CounterPillow> by searching [17:43:02 CET] <durandal_1707> ricemuffinball: find right commit, by doing bisect [17:43:22 CET] <ricemuffinball> no idea how to do that [17:43:48 CET] <durandal_1707> https://git-scm.com/docs/git-bisect [17:43:57 CET] <ricemuffinball> ffmpeg-3.2.4-win32-static.zip is oldest i can find [17:44:29 CET] <durandal_1707> you need to build it yourself, if you seek that guy [17:46:28 CET] <durandal_1707> but i could not reproduce bitrate bug with -c:a copy from mp4 to mka for opus stream created by ffmpeg [17:46:37 CET] <iive> if you are still after the opus thing, it is probably in libopus [17:46:58 CET] <ricemuffinball> durandal_1707 are you serious [17:47:16 CET] <ricemuffinball> durandal_1707 wait, why mka and not mkv [17:47:25 CET] <CounterPillow> literally the same thing [17:47:30 CET] <iive> a for audio [17:47:33 CET] <iive> v for video [17:47:35 CET] <ricemuffinball> no, mkv has video on it [17:47:50 CET] <CounterPillow> it's literally the same container [17:48:00 CET] <ricemuffinball> but mka doesn't have bitrate bug [17:48:02 CET] <ricemuffinball> only mkv [17:48:15 CET] <durandal_1707> lets seee... [17:48:54 CET] <ricemuffinball> durandal_1707 6 years ago aac/mkv had the same issue [17:49:04 CET] <ricemuffinball> when aac/mp4 worked fine [17:52:35 CET] <andy1978> JEEB: Okay, from the beginning: I want to use CvVideoWriter_FFMPEG to create a video. This expects a fourcc. The format is guessed using "av_guess_format". After that the codec_id is retreived using "av_codec_get_id(fmt->codec_tag, fourcc)". This returns AV_CODEC_ID_H264 if I give "0x21" as fourcc. But I use the opposit way. How to I retrieve the tag for a given container and codec [17:53:49 CET] <andy1978> The relevant code is here: https://github.com/opencv/opencv/blob/master/modules/videoio/src/cap_ffmpeg… [17:56:18 CET] <ricemuffinball> did ffmpeg used to have libvo_aacenc ? [17:56:32 CET] <JEEB> yes, but it was found to be crap even compared to the internal encoder, and thus removed [17:56:40 CET] <ricemuffinball> jeeb , i see [17:56:47 CET] <ricemuffinball> even worse than faac ? [17:56:51 CET] <JEEB> yes [17:56:53 CET] <JEEB> it was very, very bad [17:56:55 CET] <ricemuffinball> jeeb , i see [17:57:00 CET] <JEEB> google then licensed fraunhofer's fdk-aac [17:57:03 CET] <JEEB> which made sense [17:57:20 CET] <JEEB> (which is why fdk-aac is open source at all - the releases come through GOOG) [17:57:44 CET] <ricemuffinball> you mean google used libvo_aacenc before licensing fdk-aac ? [17:57:48 CET] <JEEB> yes [17:57:59 CET] <JEEB> both are extracted from the android code [17:58:11 CET] <JEEB> as in, someone cuts out the library since it's useful for others [17:58:15 CET] <ricemuffinball> why didn't google juse use faac then [17:58:15 CET] <JEEB> or that's how it felt at first [17:58:28 CET] <JEEB> because faac had licensing issues among other things. also tried to be GPL if I recall [17:58:31 CET] <JEEB> GOOG no want GPL [17:58:57 CET] <JEEB> (basically faac contained reference code which was not compatible with the license under which faac was) [17:59:02 CET] <ricemuffinball> so google owns fdk-aac now completely ? [17:59:48 CET] <JEEB> it licenses it and probably has some sort of copyright on what is released as part of android. then any additions on top of that are copyright of the people adding things [18:00:31 CET] <ricemuffinball> so it it safe to assume aac codec you see on youtube videos are most likely fdk-aac [18:01:02 CET] <JEEB> no idea. what youtube does internall can be rather random and have its own reasons [18:01:03 CET] <ricemuffinball> although i see more and more opus now on youtube [18:01:18 CET] <ricemuffinball> opus/vp9 [18:01:23 CET] <JEEB> andy1978: ok, do you really mean av_guess_format? [18:01:28 CET] <JEEB> or is it av_guess_codec? [18:01:51 CET] <andy1978> JEEB: This would be a workaround what I want: https://bpaste.net/show/0486d72291ec [18:02:51 CET] <JEEB> for me it sounds like you want the H.264 AVCodec, and then you can get its default values for stuff [18:02:58 CET] <ricemuffinball> jeeb what do you think about libav people [18:03:43 CET] <JEEB> I've contributed to Libav as well. They're enjoying their life doing other things mostly now. and then there's people who only use a limited feature set and for them having knowledge of what exactly is there in the code is useful [18:03:58 CET] <JEEB> there is no animosity between most people from either project. thankfully. [18:04:14 CET] <JEEB> and at this point why would there be any [18:05:05 CET] <ricemuffinball> didn't they steal from ffmpeg and created their own [18:05:08 CET] <JEEB> no? [18:05:12 CET] <ricemuffinball> traitors [18:05:14 CET] <durandal_1707> ffmpeg does not parse BPS(-eng/...) as bitrate from matroska stuff [18:05:21 CET] <JEEB> durandal_1707: and to be honest it shouldn't [18:05:29 CET] <JEEB> like, that data has nothing to do with reality [18:05:33 CET] <JEEB> unlike mp4 indexes [18:05:44 CET] <durandal_1707> but, but it is used [18:05:47 CET] <ricemuffinball> JEEB are you kidding me [18:05:58 CET] <JEEB> if we start reading that crap we might as well accept that we just want a value [18:05:59 CET] <durandal_1707> https://github.com/HandBrake/HandBrake/issues/1609 [18:06:01 CET] <JEEB> not a correct value [18:06:07 CET] <JEEB> but some value [18:06:18 CET] <ricemuffinball> jeeb: then explain this: 6 years ago aac/mkv had the same issue and ffprobe couldn't read the bitrate [18:06:30 CET] <JEEB> fuck if I know and I don't honestly give a fuck. [18:06:43 CET] <JEEB> I already wasted enough time trying to explain you how different formats are different [18:07:02 CET] <JEEB> and that for having an exact average on every clip you would have to possibly index the whole file [18:07:11 CET] <JEEB> but I don't know the internal guesstimate logic anyways [18:07:24 CET] <JEEB> -> when and how FFmpeg decides to set a stream's bit rate is random [18:07:31 CET] <ricemuffinball> jeeb how is ffprobe figuring out the birate on aac/mkv then [18:07:33 CET] <ricemuffinball> now [18:07:48 CET] <JEEB> I don't care. [18:07:57 CET] <JEEB> please stop highlighting me [18:08:20 CET] <ricemuffinball> you are making this channel look bafd [18:08:27 CET] <JEEB> if someone added a hack I don't really care [18:08:41 CET] <JEEB> if the AAC bit stream happens to have a bit rate field, I don't really care [18:08:58 CET] <ricemuffinball> i cared 6 years ago, and i care now [18:09:10 CET] <JEEB> great for you [18:09:49 CET] <JEEB> my opinion is that FFmpeg should be honest in giving people numbers like that, which it currently in some cases is - and in some cases isn't. at that point it's just arbitrary and you should never expect the value. [18:10:04 CET] <JEEB> for mp4 there usually is an index from which you can calculate the full size of a single stream within the container [18:10:10 CET] <JEEB> thus you get bit rates there [18:10:21 CET] <ricemuffinball> jeeb are you saying bitrate info that ffprobe is diplaying now is incorrect? [18:10:23 CET] <JEEB> why AAC in matroska (with other streams) gets a bit rate? no effing idea [18:10:45 CET] <JEEB> ricemuffinball: 100% depends, it is everything from calculation (mp4 with an index available) to guesstimates [18:11:19 CET] <ricemuffinball> jeeb they look pretty accurate to me [18:11:34 CET] <JEEB> for your specific examples, maybe [18:11:41 CET] <JEEB> I'm just telling you the whole range of shit in there [18:12:04 CET] <ricemuffinball> durandal_1707 do you have any idea what jeeb is talking about, because i don't [18:12:56 CET] <ricemuffinball> jeeb are you saying MKV is flawed container? [18:13:32 CET] <JEEB> not really, after all being able to get the full accurate size of a stream is not really something really required for playback or seeking [18:13:59 CET] <durandal_1707> mkv have bunch of statistics that ffmpeg do not write [18:14:12 CET] <JEEB> because they're not linked to the actual file [18:14:17 CET] <ricemuffinball> jeeb also webbrowsers does not seem to like mkv [18:14:37 CET] <JEEB> ricemuffinball: please stop talking to me [18:14:47 CET] <ricemuffinball> that's harsh [18:15:12 CET] <durandal_1707> just do: /ignore ricemuffinball [18:15:41 CET] <JEEB> andy1978: so you have an output file name that leads to an AVFormat format, and then you'd use av_guess_codec to get the default AVCodecID for the format guessed [18:15:52 CET] <JEEB> and then from that AVCodecID I bet you could get its default 4cc if you really need it [18:19:18 CET] <JEEB> andy1978: although the fourcc also depends on the output container in some cases [18:19:34 CET] <andy1978> JEEB: yes, which is the case for mp4 [18:20:18 CET] <JEEB> anyways, I'm still trying to grasp why exactly you need a fourcc for the whole shebang [18:20:27 CET] <JEEB> other than possibly some 3rd party interface only takes those [18:20:28 CET] <andy1978> JEEB: for others 4cc is used but for mp4 it's the "object type" as listed here: http://mp4ra.org/#/object_types [18:20:48 CET] <JEEB> but if you're muxing with libavformat [18:21:12 CET] <JEEB> then I'm not sure if that's needed as long as you have initialized the muxer and using the correct AVCodecIDs for the AVStreams that you add [18:21:49 CET] <andy1978> JEEB: I think the best would be to drop the fourcc in the API and directly use the AVCodecID [18:22:25 CET] <JEEB> andy1978: is this our API or what where you think it's required? [18:22:29 CET] <JEEB> I'm still kind of confuzzled with that [18:22:38 CET] <JEEB> since you seem to be opening a new AVFormatContexxt [18:22:40 CET] <JEEB> *xt [18:22:56 CET] <andy1978> JEEB: No, the API I'm talking about is the OpenCV one, not the ffmpeg :-D [18:23:25 CET] <JEEB> ok, so you're initializing the encoder through that instead of libavcodec? [18:23:31 CET] <JEEB> or what exactly? [18:23:44 CET] <andy1978> JEEB: But the OpenCV API expects the fourcc (which is really the fourcc for all other container formats than mp4, but the object type for mp4) [18:24:06 CET] <JEEB> well for something like H.264 I bet it really doesn't matter which you pass it as long as you pass some of the general ones :P [18:24:19 CET] <JEEB> although I'm still not grasping what exactly is needed here [18:24:35 CET] <andy1978> JEEB: btw, thank you very much for helping [18:26:59 CET] <JEEB> andy1978: so something like this most likely http://svn.ffmpeg.org/doxygen/trunk/group__lavf__misc.html#gabe1a7b68240782… [18:27:53 CET] <andy1978> JEEB: The OpenCV VideoWriter class (which I want to use in a wrapper for GNU Octave) expects a filename and fourcc to initialize the encoder. It internally uses av_guess_format for the format and "av_codec_get_id(fmt->codec_tag, fourcc)" to get the codec_id. And here is the problem: To get a H264 encoded video in a mp4 container I have to pass "foo.mp4" and fourcc=0x21 [18:28:38 CET] <JEEB> yes [18:28:41 CET] <JEEB> whch should work [18:28:45 CET] <JEEB> with the function I just posted [18:29:40 CET] <JEEB> since it takes in the list of tags from your AVOutputFormat [18:29:48 CET] <JEEB> and then the AVCodecID [18:30:04 CET] <JEEB> then you pass it a pointer to the unsigned int where you want your tag [18:31:39 CET] <andy1978> JEEB: wouldn't be this basically the same as https://bpaste.net/show/0486d72291ec ? [18:31:59 CET] <JEEB> more or less, just a newer interface for it [18:32:09 CET] <JEEB> also 0x21 doesn't sound like a valid fourcc [18:33:14 CET] <JEEB> it's just a ! [18:39:03 CET] <andy1978> JEEB: yes, but av_codec_get_id returns AV_CODEC_ID_H264 for this https://bpaste.net/show/79dfc6c64cf0 [18:40:14 CET] <JEEB> uhh, that's the AVCodecID [18:40:29 CET] <JEEB> and that's 100% dependant on the compiler and version due to how enums can work [18:40:47 CET] <JEEB> for example looking at what clang came up with AV_CODEC_ID_H264 is 0x1b [18:40:49 CET] <andy1978> I'm just comparing the IDs, that they are equal [18:41:53 CET] <andy1978> as you can see, they are both 0x1c here, possible that the would be 0xdeadbeef on arm but thats not the point :-D [18:42:44 CET] <JEEB> that's because you're getting the AVCodecID from that function, which still has nothing to do with fourccs... [18:43:31 CET] <JEEB> like, there's "get me the default AVCodecID for this output format" [18:43:41 CET] <andy1978> JEEB: okay, this is a very valuable info for me. until know I thought "tag" and "fourcc" would be used interchangably [18:43:46 CET] <JEEB> and then there's av_codec_get_tag2 to get the tag from that [18:44:07 CET] <JEEB> andy1978: it more or less is, but I'm just failing to see the logic in there that's all [18:45:33 CET] <JEEB> since usually if you need a tag of the default AVCodecID, you would go 1) get your AVOutputFormat , 2) get the default AVCodecID for that container for video|audio|subtitles, 3) get the tag from the AVOutputFormat.codec_tag list with av_codec_get_tag2 [18:45:45 CET] <JEEB> I forgot the exact function for 2) but I'm pretty sure it's in the doxy [18:46:32 CET] <JEEB> av_guess_codec [18:46:34 CET] <JEEB> that was it [18:46:34 CET] <andy1978> JEEB: for 2) yes, fmt->video_codec [18:46:46 CET] <andy1978> gives the default codec for that format [18:47:10 CET] <JEEB> dunno, there's an API function that so I've used it always [18:47:14 CET] <JEEB> *for that [18:47:22 CET] <andy1978> JEEB: have you had a look at isom.c around line 37? [18:47:35 CET] <JEEB> yes but I'm not sure if that has anything to do with that [18:47:43 CET] <JEEB> you just need a fourcc for H.264 (f.ex.) [18:47:50 CET] <andy1978> just to be clear that we are talking about the same "oject type" [18:48:01 CET] <JEEB> you wouldn't be utilizing that fourcc for the muxing since you've already gotten it [18:48:14 CET] <JEEB> the encoder shouldn't care which fourcc you give it as long as you give it some matching H.264 [18:49:09 CET] <JEEB> and if the FourCC is the only thing passed through, then you could just re-parse that into an AVCodecID in the last part of your chain most likely [18:49:25 CET] <JEEB> and then you can once again create an AVOutputFormat and just add a stream with that AVCodecID [18:49:50 CET] <JEEB> either I'm missing something, or you don't actually have a problem [18:50:13 CET] <andy1978> the problem is, that av_codec_get_id returns 0 is I give h264 as tag: https://bpaste.net/show/3de2ea0aeeda [18:51:05 CET] <JEEB> so that's the thing after the encoding that receives the FourCC? [18:51:11 CET] <JEEB> so you've been talking about two parts of it now [18:51:23 CET] <JEEB> one where you have to get the FourCC for the default AVCodecID [18:51:34 CET] <JEEB> and another where you receive a FourCC from the encoding part? [18:51:43 CET] <JEEB> because you seem to be trying to do two different things [18:52:18 CET] <andy1978> JEEB: let me read your answers again and again, I'm not that fast :-D [19:02:15 CET] <andy1978> JEEB: hm, even "av_codec_get_tag" returns 0x21 (a single !) for mp4 AVOutputFormat and default video_codec. [19:02:56 CET] <andy1978> JEEB: I have to read and understand your points and dig deeper into the code, thank you much for your time [19:04:15 CET] <JEEB> andy1978: anyways AVCodecTag is a struct [19:04:33 CET] <JEEB> and then there's the "tag" which is something [19:04:50 CET] <JEEB> the MKTAG thing [19:05:03 CET] <JEEB> (aka an int) [19:06:12 CET] <JEEB> andy1978: also I'm still not sure if you need this sort of stuff but there's stuff like avformat_get_riff_video_tags and avformat_get_mov_video_tags (and same for audio) [19:07:22 CET] <JEEB> andy1978: and I still wasn't sure if you are talking about one side of the puzzle ("I just need to feed a 'fourcc' to an API"), or the other ("I get a 'fourcc' from an API and need to open a muxer to write encoded packets") [19:07:33 CET] <JEEB> since your code seemed to try and handle both [19:14:23 CET] <andy1978> JEEB: My initial question was just the first part "I need to get a fourcc to feed into an API" so that I get H264 in a mp4 container [19:15:44 CET] <JEEB> argh, I'm getting tackled in inconsistencies. you say "feed a FourCC to get H.264 in a specific container", while FourCCs would only decide the format into which/from which to encode/decode [19:16:17 CET] <JEEB> thus that interface should be the encoder interface, which then probably would pass the FourCC through? [19:16:29 CET] <JEEB> together with the file name [19:16:50 CET] <JEEB> anyways, please continue :P [19:19:22 CET] <andy1978> JEEB: nono, I said "feed into an API to get H264 in mp4". I already described that inside the function av_guess_format is used to guess the container format from the filename and then the fourcc is used to get the codec [19:19:49 CET] <JEEB> ok, so the interfaces for encoding and muxing are not separate? interesting [19:20:30 CET] <JEEB> anyways, this still confuses me [19:20:58 CET] <JEEB> since you've been talking about both generating a FourCC like thing, as well as receiving one and going back to AVCodecID for it [19:21:37 CET] <andy1978> waht confused me is that "h264" isn't a valid tag for mp4 containers and instead a mysterious object-type has to be used [19:21:56 CET] <the_gamer> how ro record pulse audio? i tried https://trac.ffmpeg.org/wiki/Capture/Desktop but there is no audio in the output [19:26:53 CET] <JEEB> andy1978: well ff_mp4_obj_type shouldn't get utilized if you are looking at an mp4 AVOutputFormat's codec_tag list [19:27:11 CET] <JEEB> it would be utilizing codec_mp4_tags from movenc.c [19:36:25 CET] <andy1978> ah yes, ff_mp4_muxer [19:38:19 CET] <JEEB> anyways, I could write a simple test app of trying to neutrally round trip from an avcodecid to codec tag and back [19:38:22 CET] <JEEB> but :effort: [19:38:48 CET] <JEEB> it definitely seems possible, even without the format being mixed in there [23:15:27 CET] <superbia> hello there, can i use ffmpeg to record system audio (what goes trough my speakers) ? [23:16:15 CET] <JEEB> depends highly on the OS and audio system utilized etc [23:16:32 CET] <JEEB> for linux there's both an alsa and a pulse module so I would think you could [23:16:55 CET] <JEEB> for windows there's directshow but you'd have to make sure that your audio output would be exported to that sub-system [23:16:59 CET] <JEEB> for macos I don't even know [23:17:05 CET] <superbia> is there an easy way for me to check? [23:17:18 CET] <JEEB> which thing are we speaking of here? [23:17:37 CET] <superbia> it's linux, i have alsa and pulse [23:19:41 CET] <JEEB> alright, then try something like this https://ffmpeg.org/ffmpeg-devices.html#Examples-8 [23:21:22 CET] <superbia> [NULL @ 0x55b1893c4980] Unable to find a suitable output format for 'ffmpeg' [23:21:35 CET] <superbia> that could be my fault. i probably didn't install all of the codecs yet? [23:23:01 CET] <superbia> https://bpaste.net/show/bec0f4bc9af7 [23:23:31 CET] <JEEB> yup, you just put "ffmpeg" there twice [23:23:54 CET] <JEEB> so it parsed it as an output path [23:24:10 CET] <JEEB> which is why it couldn't figure out which container for output you wanted, because "ffmpeg" has no extension :P [23:25:03 CET] <superbia> i am listening to the recording, i think it recorded my mic [23:25:30 CET] <JEEB> check pactl or so what sort of inputs you have [23:25:37 CET] <JEEB> then you should be able to set that name as the input [23:27:45 CET] <superbia> whath's the command [23:27:54 CET] <superbia> i can't find one to list the devices in the manuals [23:28:37 CET] <JEEB> pactl list sink-inputs? [23:29:38 CET] <JEEB> or for a full list of things, just pactl list [23:31:23 CET] <superbia> i think i found it, is this it ? https://wiki.archlinux.org/index.php/PulseAudio/Examples#ALSA_monitor_source [23:33:45 CET] <superbia> brb reboot to check if it's working [23:43:17 CET] <superbia> the pulse_monitor device shows in audacity, so atleast i can record it, but i get some weird sound jerkyness [23:43:24 CET] <superbia> as if my cpu is too slow or something like that [23:48:43 CET] <superbia> JEEB: this command works perfectly $ ffmpeg -f alsa -i pulse_monitor /tmp/pulse.mp3 [23:49:06 CET] <superbia> after i modified my .asoundrc (linked earlier) [23:49:09 CET] <JEEB> cool [23:49:12 CET] <JEEB> glad it's working [23:51:59 CET] <superbia> i am just not sure if other params are correct, like bitrate and other stuff [23:52:17 CET] <superbia> since i know pretty much nothing about that stuff [23:59:01 CET] <superbia> ty for help !, bedtime [00:00:00 CET] --- Mon Mar 4 2019

1 0

ffmpeg-devel.log.20190302
by burek 03 Mar '19

03 Mar '19

[05:15:47 CET] <arturaganov> Hi. I've found only one mentored project on the GSOC page. Is it still vacant? May be there are some another projects for GSOC? [20:09:25 CET] <durandal_1707> shivamgoyal: post your questions on ffmpeg mailing list too, not all devs are here on irc [00:00:00 CET] --- Sun Mar 3 2019

1 0

ffmpeg.log.20190302
by burek 03 Mar '19

03 Mar '19

[00:51:41 CET] <ricemuffinball> i noticed that there are like 10 different AAC codecs , all producing different quality. is there like 10 different opus and vorbis too? [00:52:47 CET] <furq> not for opus [00:53:06 CET] <ricemuffinball> furq so there is only ONE opus? [00:53:11 CET] <furq> as far as i know [00:53:15 CET] <furq> there's definitely only one in ffmpeg anyway [00:53:26 CET] <furq> aside from the experimental internal one which you can ignore [00:53:45 CET] <ricemuffinball> if opus is free, won't there be like 10 different OPUS from 10 different people [00:54:07 CET] <furq> aac and mp3 aren't free and there are hundreds of those [00:54:13 CET] <pink_mist> no, opus is free enough that 10 different people has no legal need to make their own [00:54:16 CET] <ricemuffinball> furq that's true [00:54:25 CET] <furq> vorbis is free and all of the vorbis encoders i know of are forks of libvorbis [00:54:42 CET] <ricemuffinball> how many vorbis are there [00:54:52 CET] <ricemuffinball> is there more than 3 ? [00:54:55 CET] <furq> idk there used to be a bunch of "tuned" vorbis encoders like aotuv and lancer [00:55:03 CET] <furq> but a lot of that stuff got folded back into mainline iirc [00:56:13 CET] <furq> anyway as far as ffmpeg is concerned there's only one of each of those encoders you need to care about [00:56:26 CET] <furq> unless you want to build ffmpeg yourself with libfdk-aac [00:56:30 CET] <ricemuffinball> how many different aac does ffmpeg support [00:56:38 CET] <furq> two [00:56:46 CET] <furq> it used to support more but the builtin encoder is good now [00:57:22 CET] <ricemuffinball> which 2? [00:57:37 CET] <furq> aac (internal) and fdk-aac (not gpl compatible so not included in any prebuilt binaries) [00:57:51 CET] <furq> aac is decent quality, fdk is probably a bit better and it supports he-aac [00:58:00 CET] <furq> but you need to build ffmpeg yourself to use it [00:58:23 CET] <ricemuffinball> so it only supports one if you don't build it yourself [00:58:28 CET] <furq> right [00:58:43 CET] <furq> if you just want cbr lc-aac then the internal encoder is the only one you need to care about [00:58:55 CET] <ricemuffinball> aac (internal) is that similar to faac one [00:59:05 CET] <furq> no because faac sucks [00:59:10 CET] <ricemuffinball> i see [00:59:26 CET] <ricemuffinball> so faac is removed from ffmpeg competely? [00:59:28 CET] <furq> yeah [00:59:59 CET] <ricemuffinball> what about aac that google/youtube uses [01:00:05 CET] <furq> shrug [01:00:14 CET] <furq> nobody knows for sure what google uses [01:00:25 CET] <furq> fdk is part of android so it seems likely that they'd use that for youtube [01:00:40 CET] <furq> also because youtube is using ffmpeg on the backend [01:01:08 CET] <ricemuffinball> i remember it was called ..... [01:02:41 CET] <ricemuffinball> i can't remember [01:02:52 CET] <ricemuffinball> but it had 2 "O" in the lib name [01:04:00 CET] <ricemuffinball> anybody know? [01:37:17 CET] <ricemuffinball> why is opus converting 44.1K to 48K ? [01:39:30 CET] <ricemuffinball> why is opus converting 44.1K and my 96k audio to 48K ? [01:39:34 CET] <another> because opus has only 8, 12, 16, 24 and 48kHz sampling rate [01:39:37 CET] <furq> https://wiki.xiph.org/OpusFAQ#How_do_I_use_44.1_kHz_or_some_other_sampling_… [01:39:54 CET] <ricemuffinball> that's horrible [01:40:05 CET] <furq> it's justified pretty well in the link i just posted [01:40:29 CET] <ricemuffinball> i want to keep my 96K to 96K [01:40:35 CET] <ricemuffinball> and 44.1K to 44.1K [01:41:29 CET] <another> why? [01:41:52 CET] <another> if that is important to you, why are you using a lossy codec at all? [01:42:13 CET] <ricemuffinball> does vorbis do this too? [01:42:14 CET] <another> because chances are you can't hear a difference [01:42:30 CET] <another> relevant reading: https://people.xiph.org/~xiphmont/demo/neil-young.html [01:42:30 CET] <furq> vorbis doesn't resample 44.1 but it also doesn't support 96k [01:42:49 CET] <furq> there's no benefit to keeping 44.1, it'll be resampled on playback anyway [01:43:09 CET] <another> and it makes opus a lot easier [01:43:40 CET] <another> every rate it supports is a divisor of 48 [01:44:14 CET] <ricemuffinball> ffmpeg aac doesn't change 96k to 48k [01:45:59 CET] <another> aac supports higher sampling rates [01:46:14 CET] <another> which may or may not be useful [01:46:55 CET] <furq> that's being quite generous [01:47:10 CET] <another> well if you want to record bats... [01:47:10 CET] <ricemuffinball> not sure why opus didn't make it to support 44.1K [01:47:15 CET] <ricemuffinball> it's popular khz [01:47:40 CET] <ricemuffinball> and 96khz [01:48:45 CET] <another> it makes the codec a lot simpler [01:49:13 CET] <another> and 96kHz is just overkill anyway [01:49:14 CET] <ricemuffinball> then it has to resample [01:49:25 CET] <ricemuffinball> 96k is standard that dvd-audio use [01:49:37 CET] <another> it's still overkill [02:07:20 CET] <ricemuffinball> opus clearly not the best: http://bernholdtech.blogspot.com/2013/03/Nine-different-audio-encoders-100-… [02:07:43 CET] <iive> recompression? [02:07:56 CET] <iive> also 2013 [02:08:04 CET] <ricemuffinball> but there are samples [02:08:10 CET] <ricemuffinball> you can hear [02:08:17 CET] <pink_mist> was opus even done in 2013? [02:08:22 CET] <pink_mist> I don't think it was [02:09:07 CET] <pink_mist> hmm, seems initial releases was in 2012 [02:09:24 CET] <ricemuffinball> listen to the samples [02:09:36 CET] <pink_mist> but that's an OLD version [02:09:36 CET] <iive> it doesn't matter, the test is reencoding 100 times the same sample [02:09:43 CET] <pink_mist> latest version was released in 2018 [02:09:54 CET] <pink_mist> and as far as I'm aware it's supposed to be magnitudes better [02:10:31 CET] <another> i faintly seem to remember that there was a bug related to this which got fixed [02:10:46 CET] <ricemuffinball> iive so? best audio codec should still sound the best compared to others [02:11:11 CET] <iive> ricemuffinball, nope [02:11:59 CET] <iive> you want codec that encodes the original sound into something that sounds good the first time you do it. [02:12:47 CET] <ricemuffinball> Have you ever wondered how different codecs are affected by re-encoding / re-compressing? Of course, recompressing audio is a bad idea, but sometimes can't be avoided. Quality loss will inevitably occur, but are some codecs more resilient than others? To clear things up, I did a test with the following encoders: [02:13:19 CET] <ricemuffinball> like that person said, sometimes it can't be avoided [02:13:31 CET] <iive> it can. don't reencode audio [02:14:57 CET] <iive> if you care about audio quality [02:15:01 CET] <ricemuffinball> does reencoding to wav 1000 times cause quality loss too? [02:15:13 CET] <iive> it is lossless. [02:15:17 CET] <ricemuffinball> so no? [02:15:23 CET] <iive> flac, alac. [02:16:00 CET] <iive> look, different codecs use different acoustic models. they are going to cut different things. [02:17:22 CET] <ricemuffinball> iive but that nero-aac sample is impressive even after 100 reencode [02:17:45 CET] <iive> but we don't know why [02:18:01 CET] <another> https://hydrogenaud.io/index.php?topic=114317.0 [02:18:12 CET] <iive> it may not use any acoustic model, so it sounds bad from the first encode. [02:18:15 CET] <another> here is a more recent reenconding test [02:19:15 CET] <ricemuffinball> another thanks , good link [02:19:59 CET] <another> but anyway, these test are interesting but not really relevant [02:22:31 CET] <furq> lol [02:23:36 CET] <furq> i agree that opus is very disappointing for when you want to reencode the same file 1,000 times [02:23:42 CET] <furq> i don't see how the developers could have overlooked this [02:24:23 CET] <ricemuffinball> furq but listen to nero aac [02:24:31 CET] <furq> it doesn't matter at all [02:24:55 CET] <iive> ricemuffinball, read the comments of the article you have given [02:29:36 CET] <furq> more to the point it doesn't really matter which is The Best Audio Codec [02:29:47 CET] <furq> vorbis, opus and a good aac encoder will all sound great at 128k [02:30:26 CET] <ricemuffinball> i would like to see 100 reencoding test for video as well [02:30:55 CET] <furq> i'd be pretty confident x264 would do quite badly in a test like that if you used normal settings [02:30:59 CET] <ricemuffinball> furq not after 100 times [02:31:15 CET] <ricemuffinball> furq really? what makes you say that [02:31:33 CET] <furq> psy [02:32:31 CET] <ricemuffinball> i can't find anything online for 100 video test [02:32:43 CET] <furq> that's because it's not a useful thing to test [02:33:28 CET] <ricemuffinball> people might download from youtube and reupload it [02:33:41 CET] <ricemuffinball> and if that happens over and over again [02:33:54 CET] <Hello71> then they're doing it wrong. [02:34:12 CET] <furq> people might do a lot of awful things [02:34:16 CET] <furq> that doesn't mean it should be optimised for [02:35:54 CET] <ricemuffinball> help me find 100 video test [02:36:02 CET] <ricemuffinball> i am curious now [03:17:46 CET] <iive> ricemuffinball, make your own. [03:18:31 CET] <ricemuffinball> iive i don't have a decent computer to [03:18:44 CET] <iive> you just need shorter sample [03:19:14 CET] <ricemuffinball> nor i know how to do the scripting [03:19:55 CET] <ricemuffinball> okay, even if i got the short sample, how do i script that [03:49:52 CET] <ricemuffinball> why does x264 have such a crappy version # system [04:05:04 CET] <DHE> they have a version numbering system? [04:05:13 CET] <DHE> I thought it was just git versions and an ABI compat counter [04:13:33 CET] <ricemuffinball> DHE yes a crappy one [04:26:28 CET] <DHE> it's not a version numbering system. it's an ABI compatibility system, designed to prevent weirdness or outright crashes [05:08:22 CET] <debianuser> Hello. Recently someone in #mplayer mentioned that "encoding 8bit source as 10bit prevents a rounding error in motion compensation. that allows the encode to get smaller, sometimes up to 30%". Now I want to try it for some of my x264 files, so the question is: how can I tell ffmpeg to encode 8bit at 10bit? ;) I know the other params, but what's a proper way to expand 8bit to 10bit? Is there a filter? [05:14:40 CET] <klaxa> looks like setting -pix_fmt yuv420p10le is enough [05:15:14 CET] <klaxa> it used to require linking a different libx264 [05:22:28 CET] <useri0> hey everyone, i asked earlier but still wondering if anyone knows what is the correct options i should add to my ffmpeg command to avoid seeing those : https://zerobin.net/?53bf9baa955dbae8#gve/ha3KCwuULnr+Df+/PVVyichHDxEcXyMgF… [05:22:38 CET] <debianuser> klaxa: No special filters needed? It's just I thought expanding bit depth is not just adding zero bits at the end, I mean, 00000000 would turn into 0000000000, but 11111111 should become 1111111111, not 1111111100. So I just wanted to make sure it'd do the right thing... [05:22:55 CET] <useri0> i have the log level set to "warning" [05:30:31 CET] <debianuser> klaxa: Ah! I also needed at least `-vprofile high10` in addition to `-pix_fmt yuv420p10le`... Trying to encode with that and see what happens. Thanks for your hint! [08:08:03 CET] <ricemuffinball> opus clearly not the best: http://bernholdtech.blogspot.com/2013/03/Nine-different-audio-encoders-100-… [09:15:42 CET] <ricemuffinball> when convert just a audio file to opus , do i use .opus or .ogg [09:16:53 CET] <TheAMM> The container will be OGG, but some say to prefer .opus as the extension, but not all software support the .opus extension [09:17:19 CET] <TheAMM> For example Android's media scanner ignores .opus, so you'll have to use .ogg on it [09:17:26 CET] <TheAMM> (This may have been fixed already) [09:18:04 CET] <TheAMM> The file will be the same, it's just preferences regarding the name [09:18:17 CET] <ricemuffinball> then why some people prefer .opus [09:18:45 CET] <TheAMM> Because it contains Opus audio inside and OGG, instead of the older OGG Vorbis [09:19:06 CET] <TheAMM> inside an* [09:19:58 CET] <TheAMM> It's just more explicit and the Opus authors recommend you to use .opus, too [09:20:43 CET] <ricemuffinball> what are the option parameters for opus [09:20:46 CET] <TheAMM> Personally I prefer .ogg because .opus feels like .h264 which implies raw h264 stream instead of a container [09:21:01 CET] <TheAMM> ffmpeg -help encoder=libopus [09:21:02 CET] <ricemuffinball> i can't find the docs [09:22:11 CET] <ricemuffinball> audio E...A.... Favor faithfulness to the input [09:35:59 CET] <ricemuffinball> ffmpeg -i input.flac -acodec libopus output.opus : what is the command to skip first 50 seconds [09:38:07 CET] <TheAMM> ffmpeg -ss 50 -i in.flac -c:a libopus -b:a 160k out.opus [09:40:21 CET] <ricemuffinball> does -ss 50 have to be before -i input ? [09:41:13 CET] <TheAMM> No, but -ss after -i means the input will be decoded and discarded up until that point [09:41:29 CET] <TheAMM> -ss before -i will do a fast seek [09:42:01 CET] <ricemuffinball> what does -ss after -i do then, slow seek ? [09:42:10 CET] <TheAMM> <TheAMM> No, but -ss after -i means the input will be decoded and discarded up until that point [09:42:36 CET] <ricemuffinball> what is that mean in real world though? slower seek ? [09:42:56 CET] <TheAMM> It means the unused part will be decoded instead of skipped [09:43:04 CET] <TheAMM> Decoding is slower than not decoding [09:43:37 CET] <TheAMM> It's not a "slower seek" because no seeking is done, but arguing about terminology might confuse you [09:43:47 CET] <TheAMM> So just ignore that [09:44:23 CET] <ricemuffinball> let me rephrase -ss after -i will create bigger file? [09:44:32 CET] <TheAMM> No [09:45:29 CET] <ricemuffinball> let me rephrase -ss after -i will result in longer encoding time? [09:45:38 CET] <TheAMM> Yes [09:46:01 CET] <TheAMM> It'll be marginal on audio only and a modern CPU, but yes [09:46:09 CET] <TheAMM> I'm gonna go do something else so don't expect respond after this [09:46:14 CET] <TheAMM> Someone else will pick up, maybe [09:46:16 CET] <ricemuffinball> i see, but final opus file will be the same though right ? [09:46:23 CET] <TheAMM> Should be [09:46:31 CET] <ricemuffinball> i see, i got you now , thanks [09:58:31 CET] <ricemuffinball> ffmpeg -ss 50 -i in.flac -c:a libopus -b:a 160k out.opus : what is the command to skip the last 10 seconds and first 50 seconds [10:00:25 CET] <fling> ricemuffinball: ffmpeg -ss 50 -t $(($input_stream_length_in_seconds - 10)) -i in.flac -c:a libopus -b:a 160k out.opus [10:01:03 CET] <ricemuffinball> wow it's complicated [10:01:10 CET] <ricemuffinball> for last 10 seconds [10:01:18 CET] <ricemuffinball> first 50 seconds is just -ss 50 [10:01:39 CET] <fling> ricemuffinball: $(()) is for calculating length [10:01:49 CET] <fling> ricemuffinball: it is your shell thing, not complicated [10:02:01 CET] <ricemuffinball> would that work in cmd.exe [10:02:11 CET] <fling> ricemuffinball: idk, probably not. [10:02:19 CET] <ricemuffinball> i need it to work in cmd.exe [10:02:21 CET] <fling> ricemuffinball: try specifying length directly [10:02:33 CET] <ricemuffinball> i have 50 files [10:02:34 CET] <fling> ricemuffinball: then replace $(()) with something working in cmd.exe [10:02:53 CET] <ricemuffinball> i want to convert all of them with skip the last 10 seconds and first 50 seconds [10:02:55 CET] <fling> or install perl and script it with ffplay [10:03:37 CET] <ricemuffinball> why does ffmpeg support first 50 without scripts but not last 10 [10:03:43 CET] <fling> ricemuffinball: ffmpeg does not accept to skip from the back. It accepts length [10:04:36 CET] <fling> probably because it does not know the actual input stream length until it reads it, but it reads it while encoding. [10:04:41 CET] <furq> uh [10:04:43 CET] <furq> -sseof 10 [10:05:18 CET] <ricemuffinball> furq wait, there is a command? [10:06:07 CET] <furq> sure but it won't do what you want [10:06:13 CET] <furq> you can either seek from the start or the end, not both at once [10:06:41 CET] <ricemuffinball> are you kidding me [10:06:48 CET] <ricemuffinball> why can't i do both at once [10:07:01 CET] <ricemuffinball> if both commands exisst [10:07:51 CET] <fling> oh!! [10:07:58 CET] <fling> furq: sounds good [10:08:11 CET] <fling> ricemuffinball: you could run ffmpeg twice [10:08:21 CET] <fling> ricemuffinball: cut from the start first, then cut from the end [10:08:29 CET] <ricemuffinball> but that will degrade quality [10:08:38 CET] <fling> furq: I missed this one. Is it a recently added flag? :P [10:08:53 CET] <fling> ricemuffinball: use -c copy to not reencode [10:09:16 CET] <ricemuffinball> fling i see [10:09:39 CET] <ricemuffinball> for %%f in (*.wav) do ( [10:09:40 CET] <ricemuffinball> echo Converting "%%f" [10:09:40 CET] <ricemuffinball> [10:09:40 CET] <ricemuffinball> ffmpeg -ss 50 -i "%%f" -acodec libopus -vbr on "%%~nf.opus" [10:10:30 CET] <ricemuffinball> somebody should report a bug that i cannot do both at once [10:12:48 CET] <ricemuffinball> what is the second command i use then [10:16:02 CET] <fling> ffmpeg -sseof 10 -i "%%~nf.opus" -acodec $copy "%%~nf-cut.opus" [10:18:55 CET] <ricemuffinball> fling why dollar sign [10:19:00 CET] <ricemuffinball> before copy [10:20:02 CET] <fling> a typo! [10:20:05 CET] <fling> remove it [10:20:06 CET] <fling> -c copy [10:20:48 CET] <ricemuffinball> ffmpeg -sseof 10 -i "%%~nf.opus" -acodec -c copy "%%~nf-cut.opus" so this? [10:25:36 CET] <ricemuffinball> is it ffmpeg -sseof 10 -i "%%~nf.opus" -acodec copy "%%~nf-cut.opus" or ffmpeg -sseof 10 -i "%%~nf.opus" -c copy "%%~nf-cut.opus" [10:34:00 CET] Last message repeated 1 time(s). [10:43:50 CET] <another> same [10:44:25 CET] <ricemuffinball> another are you sure? [10:44:31 CET] <ricemuffinball> they do exactly same thing? [10:44:48 CET] <another> if you look at the documentation (https://ffmpeg.org/ffmpeg-all.html) you'll find that -acodec is an alias for -c:a [10:45:27 CET] <ricemuffinball> but i typed: -acodec copy and -c copy [10:46:10 CET] <another> -c copy selects streamcopy for all streams [10:47:52 CET] <ricemuffinball> so if a video has 1 video and 3 audio, it will do copy all 4 ? [10:48:06 CET] <another> yes [10:48:17 CET] <ricemuffinball> and -acodec copy will do only 3 audio? [10:50:24 CET] <ricemuffinball> -sseof value must be negative; aborting what am i doing wrong here [10:52:51 CET] <another> use a negative value? [10:53:32 CET] <another> again: you can find a lot of the answers to your questions in the documentation https://ffmpeg.org/ffmpeg-all.html [10:55:25 CET] <ricemuffinball> didn't work [10:55:41 CET] <ricemuffinball> ffmpeg -sseof -10 -i "%%~nf.opus" -c copy "%%~nf-cut.opus" [10:55:46 CET] <ricemuffinball> didn't work [10:56:05 CET] <ricemuffinball> it only included the last 10 seconds [10:56:08 CET] <ricemuffinball> instead of cutting [10:58:38 CET] <ricemuffinball> is this a bug [11:20:53 CET] <perseiver> Hi, I know how to use ffmpeg and now I want to write my own application that will use ffmpeg. I am following the tutorial in link http://dranger.com/ffmpeg/ [11:21:09 CET] <perseiver> But the code present in it seems to be deprecated. [11:21:52 CET] <perseiver> I am facing lots of problem to compile code as well as run successfully without "Segmentation fault" [11:24:45 CET] <perseiver> Is there any best tutorial out there? How current developer using ffmpeg? where they got inspired to write best code using ffmpeg. Please let me know if anyone here to advice me. As you all know "The learning get more enjoyable if the code is compiled successfully and reflecting, though the code may be million of lines" [11:26:46 CET] <ricemuffinball> perseiver you mean like GUI frontend? [11:28:06 CET] <DHE> I wrote such an app (non-GUI service). Have you checked where it crashes under a debugger? [11:28:20 CET] <perseiver> ricemuffinball sometime GUI, but most of the time in background application. [11:30:45 CET] <JEEB> perseiver: there's examples for different parts in doc/examples [11:30:57 CET] <JEEB> if you are attempting to utilize the API [11:31:24 CET] <JEEB> the transcoding one is probably the newest over-all one which contains how to read and write inputs/outputs as well as decode/encode and filter I think? [11:31:36 CET] <perseiver> yes, I am trying to utilize the power of ffmpeg in my application [11:31:41 CET] <JEEB> and this is a general guide on how to use the decoding/encoding APIs https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [11:32:14 CET] <JEEB> perseiver: which exact APIs you will require will of course depend on what exactly you're requiring [11:32:36 CET] <JEEB> as in, do you just repackage read data to another container? that's just libavformat APIs generally [11:32:46 CET] <JEEB> if you need decoding and/or encoding, libavcodec [11:33:24 CET] <perseiver> ok JEEB [11:34:59 CET] <JEEB> also I mostly work within FFmpeg's libraries, but I have written some things with the API, so I know the API is not impenetrable ;) (also I think a week or two ago someone successfully did his first API client nicely) [11:35:21 CET] <JEEB> not sure which day but you should be able to search with that URL I just posted from the IRC logs [11:35:39 CET] <JEEB> since it's the page I generally post when people ask about API usage :) [11:35:54 CET] <JEEB> and then when they actually tell what they're trying to accomplish people go into further specifics [11:47:08 CET] <perseiver> Ok JEEB, I have tried one example program decode_video.c from url https://www.ffmpeg.org/doxygen/trunk/decode_video_8c-example.html . It got compile successfully, But I am not getting benefit from it. As per document it will decode the video, I am passing .264 video and .avi file, but it just complaining "codec not found". It seems I am making wrong. the code is compiled successfully and I am able to execute it. But, the result is opposite. [11:47:08 CET] <perseiver> what the code will decode? [11:50:56 CET] <JEEB> you should check out the transcoding example [11:51:19 CET] <JEEB> I'm not sure if the decoding example cares about anything else than decoding, and I don't think it uses FFmpeg's APIs to read the data to demux it [11:51:30 CET] <JEEB> that's why I mentioned it [11:52:10 CET] <JEEB> also of course make sure that your copy of FFmpeg actually has the codec(s) you require [11:53:16 CET] <JEEB> but the basic gist is - if you need to read a file and demux the streams from the input -> libavformat , if you need to decode already demuxed packets -> libavcodec [11:56:29 CET] <JEEB> like, if you are trying to read a random file, you should first open it up with https://ffmpeg.org/doxygen/trunk/group__lavf__decoding.html#ga31d601155e903… [11:56:38 CET] <JEEB> which you can find from the transcoding example being utilized [11:57:13 CET] <JEEB> or the demuxing_decoding.c example as well it seems looking at the "Examples:" list (although I'm not sure if that example uses the newer API) [12:31:58 CET] <ricemuffinball> this is not working: ffmpeg -sseof -10 -i "%%~nf.opus" -c copy "%%~nf-cut.opus" i am trying to cut last 10 seconds [16:44:14 CET] <hans_> why isn't ffmpeg doing what i want? [16:45:29 CET] <hans_> i have a video file containing both audio and video, i want to extract the video and encode it in "pcm_f32le" format (whatever that is, idk), and this command `ffmpeg -i in.mkv -vn -c:a pcm_f32le "out.uni" 2>&1 | pastebinit` gives me this https://paste.fedoraproject.org/paste/CAvTa25zp85S5J1osWWv4Q/raw?password=E… [16:46:05 CET] <acresearch> people, just a quick question, if i want to fuse two audio files together (both .mp3) such as have one become the start of the other, what command can i use without loosing any quality? [16:46:07 CET] <JEEB> 32bit float, le [16:46:14 CET] <JEEB> is what pcm_f32le is [16:46:32 CET] <JEEB> (le being little endian although I'm not sure how much that matters in floating point) [16:46:41 CET] <hans_> JEEB, that explains f32le but not pcm :p [16:46:47 CET] <JEEB> pcm is just raw audio [16:47:01 CET] <JEEB> pulse code modulation [16:47:54 CET] <JEEB> hans_: what it says is that the container writing thing doesn't know what container you want [16:47:59 CET] <hans_> well.. i got a game that understands this file https://paste.fedoraproject.org/paste/kanJrceN8T8x6B0mMOI2Sg/raw?password=Z… any idea how to encode other audio files in the same format? [16:48:04 CET] <JEEB> from the output file extension ".uni" [16:48:20 CET] <richar_d> ffmpeg uses the extension of the output file to automatically select a container format [16:48:24 CET] <JEEB> oh, it's tracker stuff [16:48:36 CET] <JEEB> I don't think you can encode into that [16:48:49 CET] <kepstin> acresearch: note that in general, concatenating lossy audio without re-encoding will have a discontinuity at the join, sometimes audible. but that said, you should be able to use the concat demuxer in ffmpeg to do it. [16:49:00 CET] <hans_> oh dang, some audio format that ffmpeg doesn't support? wow [16:49:09 CET] <kepstin> tracker isn't an audio format [16:49:23 CET] <kepstin> it's more like midi, it's a set of instructions for how to generate audio [16:49:26 CET] <hans_> well the game gets it's music from files like that one.. [16:49:45 CET] <JEEB> hans_: basically in input it works since someone made a module to render the tracker audio into raw PCM audio [16:49:55 CET] <JEEB> which is what you push into your audio output [16:50:29 CET] <JEEB> but for output you can't just take raw PCM audio samples and expect it to be encode'able into pre-defined set of instruments etc [16:50:56 CET] <JEEB> in theory it's possible by comparing the sounds from music etc into the set of instruments used by a tracker format [16:51:04 CET] <hans_> and i can't take mp3 files and convert them to `raw PCM` either, i guess? [16:51:09 CET] <JEEB> no, that part is OK [16:51:18 CET] <hans_> well that's what i wanna do, basically [16:51:19 CET] <JEEB> since mp3 is just encoded raw PCM samples [16:51:24 CET] <kepstin> i mean, some tracker formats can include pcm samples, so in theory you could just include the entire audio as samples :/ [16:51:33 CET] <acresearch> kepstin: hmmmm so i should not do it with ffmpeg ha? maybe re-add the audio to audacity and re-export? [16:51:33 CET] <kepstin> but that would be kinda strange and also big [16:51:40 CET] <JEEB> hans_: but you wanted to make that tracker format? [16:51:44 CET] <JEEB> not raw PCM [16:52:03 CET] <kepstin> acresearch: if you have the original audio before encoding to mp3, then you should concatenate the original audio and then encode that. [16:52:16 CET] <acresearch> kepstin: pl [16:52:18 CET] <acresearch> ok [16:53:19 CET] <JEEB> hans_: basically, there's a module that has the set of instruments those "uni" tracker files use and you get raw PCM out of it. you cannot easily reverse that process [16:54:45 CET] <hans_> is there some easy-ish way to convert mp3 files to those "uni" tracker files? [16:55:06 CET] <JEEB> not really, I mean you basically are using "notes" or "instructions" in those tracker files [16:55:18 CET] <JEEB> so your app would have compare random sounds to the most "likely" match [16:55:27 CET] <hans_> oh i see, thanks for the explanation [16:55:36 CET] <JEEB> it's kind of like MIDI and this stuff https://www.youtube.com/watch?v=CVq4rSEjgnA [16:55:37 CET] <kepstin> hans_: that's like saying "is there some easy way to convert mp3 to sheet music for my band to play?" [16:55:38 CET] <hans_> that sounds like a major task indeed [16:55:52 CET] Action: JEEB kind of wants some old-school roland stuff [16:56:00 CET] <hans_> roland? [16:56:36 CET] <JEEB> MIDI synthetizer [16:57:10 CET] <JEEB> tracker music is similar, you have a set of pre-defined "notes" on X different tracks [16:57:27 CET] <JEEB> just that tracker stuff game out of the game development and demo areas [16:57:39 CET] <JEEB> as opposed to official music things :) [16:58:25 CET] <hans_> this command seems to do SOMETHING, not sure what: ffmpeg -i in.mp3 -f f32le -acodec pcm_f32le out.raw [16:58:30 CET] <JEEB> yes [16:58:33 CET] <JEEB> raw PCM you will get [16:58:56 CET] <JEEB> since mp3 and aac and a lot of ther "normal" audio formats contain the actual audio samples [16:59:14 CET] <JEEB> as opposed to just the "notes" and tracks and timings :) [17:03:48 CET] <kepstin> mp3 is a method for compressing pcm audio to reduce its size. If you decode it, you get pcm audio back [17:04:04 CET] <kepstin> (although it's a lossy codec, so you won't get quite the same pcm audio back, it'll just be similar) [18:38:54 CET] <Hello71> if you have the original samples it shouldn't be too hard [18:39:02 CET] <Hello71> something something fourier something. that's all I got [18:42:11 CET] <ricemuffinball> this is not working: ffmpeg -sseof -10 -i "%%~nf.opus" -c copy "%%~nf-cut.opus" i am trying to cut last 10 seconds [18:45:53 CET] <JEEB> ricemuffinball: does ffmpeg.c give a duration for the file you're attempting to handle? unlike -ss or -t, I'd guess -sseof requires the duration info to be somewhere [18:46:42 CET] <JEEB> I try not to use things that require the duration to be known or require frame-exactness with ffmpeg.c since it doesn't create an index [18:46:42 CET] <ricemuffinball> ffmpeg.c ? [18:46:47 CET] <JEEB> the command line application [18:46:51 CET] <JEEB> as opposed to the libraries/API [18:47:12 CET] <ricemuffinball> no idea what you are talking about [18:47:21 CET] <ricemuffinball> i just use ffmpeg.exe [18:47:33 CET] <JEEB> yes, ffmpeg.c is what compiles into ffmpeg.exe [18:47:48 CET] <JEEB> thus I call it ffmpeg.c as to separate it from other things that are contained with FFmpeg (the project) [18:47:56 CET] <ricemuffinball> i just want to cut last 10 seconds of a audio file [18:48:04 CET] <ricemuffinball> how do i do that [18:48:33 CET] <JEEB> do you get any warnings from that command [18:48:40 CET] <ricemuffinball> let me check [18:49:00 CET] <JEEB> as I noted I don't utilize sseof myself, but it does warn you if there's no duration known, for example [18:50:01 CET] <ricemuffinball> no, NO error what so ever [18:50:13 CET] <ricemuffinball> i just created a opus file of last 10 seconds onlky [18:50:16 CET] <ricemuffinball> IT* [18:50:36 CET] <JEEB> right, which is what sseof means. it seeks to the last 10 seconds [18:50:48 CET] <ricemuffinball> i want to cut last 10 seconds [18:50:50 CET] <JEEB> as in, seeks to X seconds before the duration [18:50:57 CET] <JEEB> ok, usually you'd use -t [18:51:00 CET] <JEEB> for that [18:51:12 CET] <JEEB> if you don't know the duration then you'd need something like teof [18:51:21 CET] <ricemuffinball> ffmpeg -sseof -10 -i "%%~nf.opus" -c copy "%%~nf-cut.opus" where do i put the -t ? [18:51:30 CET] <JEEB> you remove the -sseof first of all [18:51:45 CET] <JEEB> you don't want to start from 10 seconds before end after all [18:52:04 CET] <JEEB> -t is generally an encoding option, and thus you put it after the input file, and before the output file name [18:52:14 CET] <JEEB> you put the duration there that you want [18:52:23 CET] <JEEB> and it will stop after that duration [18:52:36 CET] <JEEB> unfortunately there's no teof as far as I can see [18:52:47 CET] <JEEB> so you cannot say -teof -10 [18:53:22 CET] <ricemuffinball> so how do i accomlish what i want to do [18:53:39 CET] <JEEB> you take the full duration, minus ten seconds and put that into -t [18:53:43 CET] <JEEB> currently that is the way you would do it [18:53:53 CET] <ricemuffinball> so how do i do that [18:54:25 CET] <JEEB> well, for example if you want the first 90 seconds you do -t 90 or so? [18:54:36 CET] <JEEB> it does take in some sort of timestamps as well if you want that [18:55:48 CET] <ricemuffinball> i wanted to cut first 20 seconds of audio file and you do -ss 20 , and that worked great [18:56:08 CET] <JEEB> yes, that seeks to point 20s [18:56:11 CET] <JEEB> and starts from there [18:56:19 CET] <ricemuffinball> now i just want to do cut last 10 seconds [18:56:55 CET] <JEEB> I cannot see an option for that as-is [18:57:04 CET] <JEEB> you can only say the maximum duration [18:57:08 CET] <JEEB> which is -t [18:57:29 CET] <JEEB> you will have to first run ffprobe on the file and check if it comes out with a duration [18:57:37 CET] <JEEB> then you use that minus your ten seconds as the duration [18:57:42 CET] <Ariyasu> you can script a solution using mediainfo cli to dump source duration into a vairable, then use -ss and t [18:57:49 CET] <Ariyasu> to start 10s before the end and run for 10s [18:58:02 CET] <JEEB> that's not what he wants [18:58:16 CET] <JEEB> he already seemed to try and use sseof which seeks to end-X seconds [18:58:27 CET] <JEEB> and he wanted specifically everything but the last 10 seconds [18:58:34 CET] <JEEB> thus -t duration-10 [18:58:35 CET] <Ariyasu> ahh my bad [18:58:48 CET] <Ariyasu> yeah [18:59:26 CET] <ricemuffinball> i can't believe nobody has complained before about this [18:59:45 CET] <ricemuffinball> it's a very common thing to do [19:00:21 CET] <JEEB> yes, also it's a very common thing that can go wrong with ffmpeg.c, unfortunately. which is why people don't implement that by default. mostly because tehre's a lot of file formats that require indexing to get that stuff exact. [19:00:27 CET] <JEEB> in your case of course it would probably work [19:00:32 CET] <JEEB> as it seems to work with -sseof as well :P [19:00:47 CET] <JEEB> you can feel free an open a feature request on trac if you want [19:00:57 CET] <ricemuffinball> jeeb are you ffmpeg dev ? [19:00:59 CET] <JEEB> yes [19:01:09 CET] <ricemuffinball> i see [19:01:21 CET] <ricemuffinball> and nobody has ever requested this before on trac ? [19:01:37 CET] <JEEB> no idea. possibly someone has, but nobody has been interested in hacking it up so far [19:02:14 CET] <ricemuffinball> jeeb so you think making ffmpeg to do this is really hard? [19:02:22 CET] <JEEB> making it always work is hard [19:02:31 CET] <JEEB> making it work for your use case, probably not that hard [19:02:54 CET] <ricemuffinball> why do you say it's not hard for "my case" [19:03:09 CET] <ricemuffinball> because it's audio only? [19:03:10 CET] <JEEB> because most likely you have some sort of signaled duration in the file, and seeking seems to work relatively well [19:03:34 CET] <JEEB> there are many file formats that are meant for A->B reading only [19:03:41 CET] <JEEB> and where duration is not something that matters [19:04:05 CET] <JEEB> at that point FFmpeg's libraries will attempt to guess things, or just not provide duration info [19:04:08 CET] <ricemuffinball> huh, not sure what you are trying to say [19:04:22 CET] <ricemuffinball> every media file has duration. what are you talking about [19:04:34 CET] <JEEB> every media file has a duration after you have read through it at least once [19:04:37 CET] <JEEB> fully [19:04:50 CET] <JEEB> there are formats which do not tell you outwards that there's a duration [19:04:58 CET] <JEEB> or how to seek to a specific point [19:05:18 CET] <JEEB> in your case, or with mp4 (at least non-fragmented mp4) or properly indexed mkv [19:05:27 CET] <ricemuffinball> jeeb you mean like corrupted video/audio file? [19:05:28 CET] <JEEB> you have an index and a duration field or duration can be calculated easily [19:05:31 CET] <JEEB> no, not corrupted [19:05:48 CET] <JEEB> let's take that you save some stuff from the digital TV for example [19:05:59 CET] <JEEB> that format is 100% made for A->B consumption [19:06:10 CET] <JEEB> so it plays nicely and all that jazz [19:06:18 CET] <JEEB> but nowhere does it say how long something is [19:07:06 CET] <JEEB> or if the stream is of not constant bit rate, seeking will not be exact as it is guesstimated by the guesstimated duration and the bit rate [19:07:28 CET] <JEEB> that said basic ss also would have issues with this [19:08:16 CET] <JEEB> anyways, I'm not against an option like sseof for duration [19:08:47 CET] <JEEB> it just might get hard to explain to people why it gets the duration wrong I bet ^^; [19:08:56 CET] <JEEB> (with some sorts of inputs) [19:10:04 CET] <JEEB> ricemuffinball: anyways, feel free to make a feature request on trac. if it gets to be a duplicate then someone will mark it as such, and that's all (if you have the time you can of course search trac.ffmpeg.org for similar duration-related tickets if one exists) [19:23:07 CET] <ricemuffinball> opus clearly not the best: http://bernholdtech.blogspot.com/2013/03/Nine-different-audio-encoders-100-… [19:28:40 CET] <JEEB> ricemuffinball: I would care much more about 1st gen losses than Nth gen losses. although you can read in the comments regarding why opus took it badly (because the tools that handled it weren't removing the encoder delay and thus the content was always with a different alignment) [19:28:56 CET] <JEEB> which is funny because I thought the opus command line decoder took away the encoder delay [19:29:19 CET] <JEEB> also I find it funny that only nero (which hasn't been updated in quite a while) and QT AAC encoders were tested [19:29:28 CET] <JEEB> f.ex. fraunhofer's open source thing was left out [19:29:34 CET] <JEEB> or FFmpeg's [19:29:49 CET] <ricemuffinball> jeeb i guess, but NeroAAC is very impressive on that test [19:30:32 CET] <durandal_1707> should I kick this nick? [19:31:07 CET] <JEEB> it also depends on how the encoder handles things. very "simple", or "mechanic" things can lead to re-coding of stuff to be the same [19:33:20 CET] <JEEB> although as noted, even if it is good at so many passes, it doesn't mean it's as good with a single pass encoding [19:33:24 CET] <JEEB> which is what you generally handle [19:34:02 CET] <match_it> hello, I'm trying to upload (feed) a video from my computer to my vps server through h264 format but I still receive conversion fail [19:34:30 CET] <match_it> the source is an mp4 file from youtube [19:42:01 CET] <match_it> here is the output [19:42:03 CET] <match_it> https://ibin.co/4YpY9QM2BUam.png [19:43:11 CET] <JEEB> will your other side take in stuff at more than real-time? [19:43:26 CET] <JEEB> because it seems like the connection got reset by the other side [19:44:16 CET] <JEEB> also do you want to copy, or do you want to re-encode? [19:44:38 CET] <JEEB> because you are not setting a video encoder, and the default is to pick a default for a format and re-encode :P [19:48:21 CET] <JEEB> -re before your input path will sleep() accordingly to make it seem like realtime, and -c copy after input path will copy the stream from the mp4 file [22:33:29 CET] <illuminated> in a video file in the stream identifiers you have 0:1 0:2 etc.. if you have a video file, is it possible to have a 1:0 or something? The way I see it used is when you're combining streams from multiple sources. Like 0:1 is the second stream of the first source file and 1:0 is the first stream of the 2nd source file.. [22:57:21 CET] <BtbN> The first number refers to the input number [22:57:31 CET] <BtbN> so if you have only one -i, there will only ever be 0 [23:42:01 CET] <ricemuffinball> i have this video that starts the video with 960x540 then changes to 1280x720 after 20 minutes. how is this possible? [23:44:33 CET] <BtbN> TV channels do that a lot, where ads are different res and they don't bother to re-encode the low res ones, so they just switch resolution [23:45:33 CET] <ricemuffinball> but this is mp4 file [23:46:27 CET] <BtbN> I'm not sure if mp4 supports multiple streams like that [23:46:33 CET] <BtbN> You usually see it in mpeg-ts [23:47:31 CET] <ricemuffinball> https://pastebin.com/cDbVmkrN [23:47:43 CET] <ricemuffinball> but it changes to 720 after 20 min [23:48:43 CET] <ricemuffinball> so i am trying to do this: ffmpeg -ss -00:20:50 -i D:\1.mp4 -c copy R:\2.mkv: why won't this work [23:49:08 CET] <JEEB> because you're using ss and not sseof? [23:49:19 CET] <JEEB> normal ss with a negative value makes zarro sense [23:49:20 CET] <BtbN> mp4 has only one set of extradata per stream. I highly doubt it can res change [23:49:28 CET] <JEEB> BtbN: it can just fine :) [23:49:32 CET] <BtbN> how? [23:49:50 CET] <ricemuffinball> jeeb you are right, i have to remove the negative [23:50:06 CET] <JEEB> 1) it supports multiple initialization data segments (and those can be separately noted in the samples) and 2) you can just put the parameter sets in-band [23:50:13 CET] <JEEB> so you can either do it in-band or out-of-band [23:51:49 CET] <ricemuffinball> after doing -ss 00:20:00 and ffprobing the file: i get this: https://pastebin.com/jsBGZPqL [23:52:09 CET] <BtbN> If you want to normalize resolution, you'll have to re-encode at least the parts that are wrong [23:52:18 CET] <JEEB> "wrong" [23:52:22 CET] <JEEB> but yes [23:52:31 CET] <JEEB> if it changes resolution then not too sure what you're going to do with that [23:54:14 CET] <JEEB> in some cases mediainfo doesn't really give you an insight unless you exactly know what it interprets as something :P [23:54:27 CET] <linext> anything i could be doing better with the video recording script? https://i.imgur.com/mSkI7Ub.png [23:55:56 CET] <ricemuffinball> Stream #0:0: Video: h264 (Main), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 1k tbn, 60 tbc (default) [23:57:02 CET] <illuminated> BtbN: thanks for the clarification m8. [00:00:00 CET] --- Sun Mar 3 2019

1 0

ffmpeg-devel.log.20190301
by burek 02 Mar '19

02 Mar '19

[12:56:25 CET] <durandal_1707> got from 0.3 to 129 real time speed [13:10:55 CET] <durandal_1707> atomnuker: can i have imdct for 1536, 768, 384, 192 and 96 ? [13:15:26 CET] <atomnuker> I did actually look into it this morning, and that one is nasty [13:16:05 CET] <atomnuker> well, not really, its far far better than 15, but still to make one of those you need either 12 or 24 or 48 [13:16:55 CET] <atomnuker> I think for a generic fft capable of those and powers of two and multiples of 15 the kiss-fft approach is better [13:17:29 CET] <atomnuker> and it would save on needing to prereindex [13:18:30 CET] <atomnuker> one thing I'm wondering is if such an approach could match the speed for our transform [13:24:56 CET] <nevcairiel> In another project i recently switched from KissFFT to PFFFT, which is considerably faster and has SIMD, and supports very variable sizes, although I have no clue how to make a IMDCT out of a FFT =p [13:25:31 CET] <durandal_1707> does mpeg-h have specification somewhere? [13:28:07 CET] <JEEB> yes, check ISO/IEC and chiarliglione's site for drafts [13:28:29 CET] <nevcairiel> its mpeg, so probably not for free [13:39:45 CET] <JEEB> depends. ISOBMFF and HEVC are free for example [13:39:56 CET] <JEEB> (although then 14496-15 isn't free for some reason) [13:40:05 CET] <JEEB> which is why the meeting document archives [13:40:11 CET] <JEEB> and chiarliglione's site [13:40:18 CET] <JEEB> are nice for draft DOC files :P [14:01:16 CET] <kierank> nevcairiel: just move some values around iirc [14:19:29 CET] <durandal_1707> cant open docx with libreoffice [14:25:13 CET] <JEEB> huh, mine can (surprisingly OK) [14:25:21 CET] <JEEB> although I guess depends on the exact document? [14:25:41 CET] Action: JEEB is currently on 6.1.5.2 [14:26:05 CET] <durandal_1707> ISO-IEC_23008-3_(E)_(CD of 3DA).docx - whatever that is [14:26:33 CET] <JEEB> will check when I have the time. if needed I can print out a PDF at home from MS Office [14:57:17 CET] <tronifier> Hello everyone. [15:02:30 CET] <tronifier> clear [15:06:14 CET] <jdarnley> Dont shock the patient. Hes still concious. [15:28:40 CET] <durandal_1707> who gonnna REed ProRes and Blackmagic RAW ? [15:31:11 CET] <gnafu> Elvis. [16:41:02 CET] <cone-953> ffmpeg 03Paul B Mahol 07master:007c13e51e73: avfilter/af_anlmdn: add output mode option [18:11:54 CET] <shivamgoyal> Hi, I have written a XV video file to flv converter ( It is also working on the provided "1.xv" and "5.xv" files) as my qualification task for GSoC 2019. I just need some guide on how to combine the code with existing ffmpeg codebase. [20:23:27 CET] <durandal_1707> can i become ML maintainer so I can ban nicolas and carl? PLEASE! [21:29:59 CET] <durandal_1707> should i post WIP ac4 patches to ML? [22:43:53 CET] <cone-959> ffmpeg 03Marton Balint 07master:fe36dcbff20e: avformat/mpegtsenc: factorize writing registration_descriptor [22:43:53 CET] <cone-959> ffmpeg 03Marton Balint 07master:837f2c97984a: avformat/mpegtsenc: write format_identifier HEVC for HEVC streams [22:43:53 CET] <cone-959> ffmpeg 03Marton Balint 07master:24e0e149ada6: avformat/utils: be more strict about stream specifiers [22:43:53 CET] <cone-959> ffmpeg 03Marton Balint 07master:d4ae28e4942b: avformat/utils: be even more strict about stream specifiers [22:43:53 CET] <cone-959> ffmpeg 03Marton Balint 07master:57580e2ab68d: avformat/utils: fix indentation [22:43:53 CET] <cone-959> ffmpeg 03Marton Balint 07master:9f8854cb5ad9: avcodec/avpacket: add some assertions to ensure pkt->data is not null if pkt->size > 0 [22:43:54 CET] <cone-959> ffmpeg 03Marton Balint 07master:902e9334aabb: avcodec/get_bits: use unsigned integers in show_bits and get_bits [22:43:54 CET] <cone-959> ffmpeg 03Marton Balint 07master:694d9d536853: avcodec/get_bits: add assertion to limit ouptut value of get_bits [23:40:32 CET] <cone-959> ffmpeg 03Michael Niedermayer 07master:4801eea0d465: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int() [23:40:33 CET] <cone-959> ffmpeg 03Michael Niedermayer 07master:b7140a4db574: tools/target_dec_fate.sh: Add support for lines that are comments [23:40:34 CET] <cone-959> ffmpeg 03Michael Niedermayer 07master:3b23eb283a32: tools/target_dec_fate.list: Add testcases for #2000 to #4000 [00:00:00 CET] --- Sat Mar 2 2019

1 0

ffmpeg.log.20190301
by burek 02 Mar '19

02 Mar '19

[00:00:10 CET] <another> yes [00:01:27 CET] <ricemuffinball> how is that different from this then? ffmpeg -i input.mkv -vcodec copy -acodec copy R:\output.ts [00:02:22 CET] <another> should be the same as the bsf should be inserted automatically [00:02:49 CET] <ricemuffinball> what is bsf? [00:03:13 CET] <another> bitstream filter [00:05:04 CET] <ricemuffinball> and what does bitstream filter exactly do [00:05:24 CET] <another> https://ffmpeg.org/ffmpeg-bitstream-filters.html#h264_005fmp4toannexb [00:06:02 CET] <JEEB> basically the packaging of the AVC stream is different between MP4/MKV and MPEG-TS [00:06:09 CET] <another> basically it moves a few bits and bytes to different positions, so that they fit the standard [00:06:31 CET] <ricemuffinball> i see [00:06:39 CET] <JEEB> before /33 [00:06:51 CET] <ricemuffinball> is that mean ffmpeg -i input.mkv -vcodec copy -acodec copy R:\output.ts this command will create corrupted ts file since i didn't use bsf option? [00:07:02 CET] <JEEB> no [00:07:19 CET] <JEEB> with old FFmpeg it would fail, with new FFmpeg it would auto-insert the bit stream filter [00:07:28 CET] <ricemuffinball> jeeb i see [00:07:36 CET] <ricemuffinball> what is considered old [00:07:40 CET] <ricemuffinball> and new [00:08:22 CET] <JEEB> seems like automatic bsf was added in 2016 [00:08:30 CET] <JEEB> late 2016 [00:08:38 CET] <JEEB> so if your FFmpeg is older than that it would error out [00:08:49 CET] <ricemuffinball> another WOW that method worked [00:08:54 CET] <JEEB> if your FFmpeg is newer than that it would attempt to auto-insert [00:09:14 CET] <another> nice [00:09:52 CET] <ricemuffinball> what does "-bsf:a aac_adtstoasc" do [00:10:05 CET] <JEEB> same thing for AAC [00:10:14 CET] <JEEB> ADTS packaging to ASC packaging [00:10:45 CET] <JEEB> I think ADTS is what's used in MPEG-TS? [00:10:57 CET] <ricemuffinball> what if i don't add the "-bsf:a aac_adtstoasc" option then does it create corrupted file? [00:10:59 CET] <JEEB> or was this the MPEG-4 AAC vs MPEG-2 AAC thing? [00:11:07 CET] <JEEB> no [00:11:24 CET] <JEEB> it will either error out or auto-insert if needed [00:11:39 CET] <another> JEEB: "Convert MPEG-2/4 AAC ADTS to an MPEG-4 Audio Specific Configuration bitstream." -- https://ffmpeg.org/ffmpeg-bitstream-filters.html#aac_005fadtstoasc [00:11:58 CET] <JEEB> ok, so I remembered it correctly'ish :) [00:12:29 CET] <ricemuffinball> i wonder why ffmpeg -safe 0 -f concat -i list.txt -c copy output.mp4 created corrupted file [00:12:57 CET] <ricemuffinball> but ffmpeg -i "concat:intermediate1.ts|intermediate2.ts" -c copy -bsf:a aac_adtstoasc output.mp4 DID WORK [00:16:00 CET] <ricemuffinball> what does -safe 0 do [00:19:30 CET] <another> https://ffmpeg.org/ffmpeg-all.html#Options-35 [00:21:30 CET] <ricemuffinball> another any idea why one method didn't work but ts method worked [00:22:06 CET] <another> nope. had the same problem before [00:22:37 CET] <ricemuffinball> another exact same problem? [00:22:54 CET] <ricemuffinball> where it created garbage video @ second video mark [00:23:00 CET] <another> something similar. can't remember what exactly [00:23:14 CET] <ricemuffinball> another and ts method worked for you ? [00:23:41 CET] <another> yes. [00:27:05 CET] <ricemuffinball> another do you remember if the video showed up like this: https://imgur.com/a/U9ISgXA [00:27:54 CET] <another> it's been too long [00:28:18 CET] <another> i just know it worked with ts [00:29:25 CET] <ricemuffinball> why isn't vob/ts container popular [00:29:47 CET] <ricemuffinball> like mp4/mkv/avi [00:33:26 CET] <Hello71> it sucks [00:34:22 CET] <ricemuffinball> how does it suck [00:35:01 CET] <Hello71> according to wikipedia, vob is ps [00:35:04 CET] <Hello71> and mpg is certainly popular [00:35:10 CET] <ricemuffinball> PS ? [00:35:33 CET] <Hello71> bus I assume mp4 provided some benefits over mp2 [00:36:33 CET] <ricemuffinball> Hello71 what is "ps"? [00:36:45 CET] <Hello71> google it. [00:37:27 CET] <ricemuffinball> no luck [00:41:32 CET] <ricemuffinball> hello program stream [01:27:00 CET] <ricemuffinball> how do i tell mp4 file i have has mov atom in the beginning or end [02:33:02 CET] <ricemuffinball> is it stupid to encode a 8bit video source to 10 bit video ? [02:33:27 CET] <another> why would you do that? [02:34:23 CET] <ricemuffinball> i didn't, that's why i asked [02:35:15 CET] <another> i see no benefits in there [02:36:41 CET] <ricemuffinball> [17:35] <iive> encoding 8bit source as 10bit prevents a rounding error in motion compensation [02:36:41 CET] <ricemuffinball> [17:35] <iive> that allows the encode to get smaller, sometimes up to 30% [02:36:41 CET] <ricemuffinball> [17:35] <iive> that's why it got so popular with h264 at first. [07:14:27 CET] <errl> hi everyone, having some problem with the cli in this paste is the command and the error message: https://pastebin.com/raw/yhU1CGpy [07:15:10 CET] <errl> when i'm attempting to apply the filters on my input, sometimes the command completes successfully, but other times the command fails with the message there [07:15:24 CET] <furq> errl: it's getting oom killed [07:15:58 CET] <furq> not really sure why, i don't see any filters in there that would use a ton of memory [07:16:18 CET] <errl> are you sure? how could that be, I am monitoring htop and it doesn't seem as though ffmpeg is using much memory at all [07:16:40 CET] <furq> shrug [07:16:44 CET] <furq> "signal: killed" is an oom killer message [07:17:14 CET] <errl> i've just tried running the command again and htop reports the process is using 300M [07:18:29 CET] <errl> i am using 4.1.1 if that means anything, perhaps downgrading is a solution? [07:18:41 CET] <furq> you could try [07:18:45 CET] <furq> i'm not sure it'd make any difference [07:18:56 CET] <furq> if you're sure you're not running out of memory, you have swap etc then it's worth a try [07:19:23 CET] <furq> you should be able to see in dmesg whether it got oom killed [07:19:46 CET] <errl> the vm i'm using actually doesn't have swap, but it has plenty free ram, could that be the culprit? [07:20:12 CET] <furq> maybe [07:20:54 CET] <errl> ok, i will try that [08:40:57 CET] <cn2348> Hi, I've got a file recorded by a mobile phone that changes its dimensions during the runtime (landscape -> portrait and then back portrait -> landscape), is there a way to normalize this to only landscape? [08:42:13 CET] <cn2348> Using the cclock transpose filter with landscape passthrough results in non monotous dts warnings and the output is chopped? [08:43:51 CET] <cn2348> Just passing the file to ffmpeg and letting it reencode with no other options also results in a somewhat weird output [08:44:33 CET] <cn2348> During the orientation change there are shortly no frames and reencoding adds some kind of weird looking slur during that period [10:00:04 CET] <ricemuffinball> is it stupid to encode a 8bit video source to 10 bit video ? [10:03:57 CET] <furq> usually yes [10:06:13 CET] <ricemuffinball> why not "always yes" [10:06:22 CET] <furq> sometimes the space savings are worth it [10:06:34 CET] <furq> animation usually benefits an appreciable amount [10:06:47 CET] <furq> the problem with 10-bit h264 in particular is that nothing supports it [10:07:08 CET] <ricemuffinball> even on computer playback ? [10:07:17 CET] <furq> it's supported in software obviously [10:07:21 CET] <furq> but nothing else will play it [10:07:50 CET] <ricemuffinball> what about on smartphone with software? [10:08:08 CET] <furq> that will either run badly or kill your battery [10:08:20 CET] <ricemuffinball> i see [10:09:27 CET] <ricemuffinball> even if there is lack of support why would it cause "space savings" when it's going from 8 bit to 10bit [10:10:01 CET] <furq> https://gist.github.com/l4n9th4n9/4459997 [10:11:25 CET] <ricemuffinball> furq is the "space saving" also happen for 8 bit x265 to 10 bit x265 [10:11:56 CET] <furq> probably [10:12:02 CET] <furq> i know very little about x265 [10:12:12 CET] <furq> 10-bit h265 is actually better supported than 10-bit h264 though [10:12:16 CET] <furq> a lot of newer phones etc can decode it [10:13:52 CET] <ricemuffinball> yes, a lot of other people said the same thing [10:51:14 CET] <useri0> hello everyone, i get this message sometimes : Last message repeated 130046 times [10:51:25 CET] <useri0> how do i reduce the number of repeated times ? [10:51:58 CET] <durandal_1707> useri0: and actual message is? [10:52:25 CET] <useri0> durandal_1707, http://prntscr.com/mrqyir [10:54:01 CET] <durandal_1707> you can not do much about it [10:55:56 CET] <useri0> how so ? [10:56:11 CET] <useri0> is there a way to counter attack it at least? [10:56:51 CET] <useri0> durandal_1707, https://video.stackexchange.com/questions/24462/timestamps-are-unset-in-a-p… [10:57:01 CET] <useri0> how right that solution is ? [10:58:23 CET] <durandal_1707> it is not always perfect [10:58:31 CET] <durandal_1707> you can try.... [11:00:28 CET] <useri0> i would better avoid it then [11:00:37 CET] <useri0> but what does the error actually means ? [11:03:18 CET] <useri0> someone said in the comments at this link, to use -re, would that be efficient enough maybe? [11:03:57 CET] <durandal_1707> dunno, cant do guessing [11:06:42 CET] <useri0> okay thanks [11:25:48 CET] <useri0> durandal_1707, if i want to place :'-use_wallclock_as_timestamps 1' , where should i place it here : ffmpeg '-loglevel', 'warning', '-i', xx.mp4, '-codec', 'copy', xx_.mp4 [11:26:25 CET] <durandal_1707> before -i i think [11:26:57 CET] <useri0> okay thanks [11:30:35 CET] <useri0> says : http://prntscr.com/mrri61 [13:41:09 CET] <th3_v0ice> What are the steps to convert audio that has 1536 samples (AC3) to 1024 samples (AAC). I am using swr_convert() now and I am not sure that this is the right approach. [13:42:42 CET] <BtbN> There should be no special steps to that really [13:44:06 CET] <Mavrik> FIFO queue? :) [13:44:09 CET] <th3_v0ice> So just a fifo buffer? [13:44:55 CET] <th3_v0ice> If FIFO buffer is the right answer, what would be best way to handle timestamps? [15:38:43 CET] <brejeiro> Hello, I'm recording my screen using ffmpeg on windows, and it works great. The thing is, I'll need to create chapters in my video at certain times. I know I could just create a Metadata file afterwards, but precise time and automation are needed for the task. So let's say I started recording my desktop, then I started a program, and at some point I finish one task and will start another one. This is the time actually need, and nee [15:39:28 CET] <brejeiro> Is it possible that I could run some command at that point to get the precise time/frame of the video? Or even create the chapter there? [15:39:36 CET] <brejeiro> Was I clear? [15:53:48 CET] <goodgrief> Hi! [15:54:08 CET] <goodgrief> Does anybody have an example with using of afftdn filter? [15:54:56 CET] <goodgrief> Documentation is poor, and I haven't found examples in google :( [16:08:26 CET] <durandal_1707> goodgrief: you can use it in one go, or two pass [16:10:30 CET] <durandal_1707> goodgrief: do you want examples? [16:11:03 CET] <goodgrief> durandal_1707: it will be nice if you have one [16:12:03 CET] <durandal_1707> it depends on audio noise [16:12:13 CET] <goodgrief> white noise [16:12:40 CET] <durandal_1707> what kind of audio music or speech? [16:12:51 CET] <goodgrief> human voice [16:15:39 CET] <svara> Hi all, I wrote some C++ code that dumps a h265 stream to a file. I can convert this into an mp4 by using ffmpeg from the command line (simply with "-c copy"); but I would like to include this functionality directly in my own program. It seems like this should be possible with, e.g., libavformat (?), but I can't really find documentation or just some starting point for this. Can anyone point me in the right direction? [16:15:45 CET] <durandal_1707> goodgrief: you could use ladspa or lv2 filters? but they are less or no configurable [16:16:44 CET] <durandal_1707> goodgrief: https://github.com/werman/noise-suppression-for-voice [16:17:11 CET] <durandal_1707> so you would use ffmpeg -i noise.wav -af ladspa=.... [16:17:51 CET] <Mavrik> svara: there's examples of API usage in examples/ subdir of ffmpeg source [16:18:46 CET] <durandal_1707> goodgrief: for afftdn, you just adjust noise floor, nf option and than nr noise reduction option [16:19:26 CET] <durandal_1707> that is basic usage, there is more complex one [16:24:08 CET] <svara> Mavrik: perfect, thanks - for reference, the relevant example is https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/muxing.c [16:28:54 CET] <goodgrief> durandal_1707: it works now! Thank you for help! [20:39:25 CET] <ChocolateArmpits> Has anyone encountered any performance issues pertaining to running multiple powershell sessions and executing "cmd /c ffmpeg" commands? I have found that by running 8 or more powershell sessions with ffmpeg getting executed via cmd /c the cpu usage of each instance of ffmpeg would go up way beyond than if cmd /c wasn't used [20:40:19 CET] <ChocolateArmpits> This is the first time that I'm seeing this, of course I didn't have to run 10 instances of ffmpeg at once, but this still is awfully odd [20:41:19 CET] <ChocolateArmpits> don't even know how to report this [20:45:40 CET] <DHE> but launching ffmpeg 10 times via other methods is better? [20:46:23 CET] <ChocolateArmpits> If I launch it directly in powershell, not via "cmd /c", but start-process cmdlet, then it performs as expected [20:46:49 CET] <ChocolateArmpits> I initially used "cmd /c ffmpeg [parameters]" to more easily pass complex strings without requiring escaping [20:47:07 CET] <ChocolateArmpits> I didn't think there would be any problems [20:47:24 CET] <ChocolateArmpits> But upon going to a higher number of processes the problems started showing up [20:47:46 CET] <ChocolateArmpits> It should be known the cpu usage of ffmpeg increases, not of powershell or cmd [20:48:01 CET] <ChocolateArmpits> across all active instances running the same manner [20:48:12 CET] <ChocolateArmpits> And only starts creeping up with 8 or more processes [20:49:19 CET] <ChocolateArmpits> Normally the utitlization would be at about 50%, but with the """bug""" it can easily skyrocket to 100% when realtime processing is concerned [20:49:32 CET] <DHE> so it's not powershell-specific [20:49:50 CET] <ChocolateArmpits> I'd say there's maybe some combination of running ffmpeg inside cmd and that inside of powershell [20:50:05 CET] <ChocolateArmpits> but the cpu usage problems happen with ffmpeg [20:51:31 CET] <ChocolateArmpits> Actually, even running the processes in that sequence already produces somewhat worse performance than just running ffmpeg in either cmd or powershell, but, as I said before, starting with 8 processes it completely shits itself [20:52:31 CET] <ChocolateArmpits> so I do have a workaround, but the issue is something that maybe could get some conclusion [20:53:02 CET] <ChocolateArmpits> I guess the situation is unique enough that it's only on me to carry on [20:55:54 CET] <kepstin> only things I can think of is either that console output is handled differently causing load issues, or it's not actually running the same ffmpeg command in the end. [20:56:35 CET] <ChocolateArmpits> The commands were identical, I ran the tests manually both times [20:57:22 CET] <ChocolateArmpits> Could ffmpeg performance spike because of the shell environment? [21:01:07 CET] <kepstin> console environment shouldn't matter, but try running with the "-nostats" option to make sure. [21:04:38 CET] <ChocolateArmpits> okay I'll try that when I have the time [21:05:22 CET] <ChocolateArmpits> btw stopping any of the 8 processes so only 7 are active, sees the cpu usage drop across all others [21:25:49 CET] <ricemuffinball> does youtube use FLV or mp4 or something else [21:30:39 CET] <kepstin> mp4 and something else, yes [21:31:00 CET] <ricemuffinball> isn't mp4 horrible for streaming [21:31:10 CET] <kepstin> nah, it's fine if used correctly [21:31:37 CET] <kepstin> but note that youtube serves stuff up with dash to modern browsers, i think? [21:31:48 CET] <ricemuffinball> dash? [21:32:00 CET] <ricemuffinball> what is that [21:32:09 CET] <kepstin> a segmented adaptive streaming system [21:33:01 CET] <ricemuffinball> but regular mp4 doesn't have that [21:33:27 CET] <kepstin> no, the dash stuff is mostly important if you want to be able to switch quality levels dynamically during playback [21:34:04 CET] <ricemuffinball> i see, is that what dash does? [21:36:28 CET] <kepstin> dash metadata, along with a set of specially prepared webm, mp4, or mpeg-ts files, allows a player to pick quality formats dynamically and switch seamlessly. [21:37:11 CET] <kepstin> the individual webm or mp4 files from the dash streams can also be downloaded and played individually in most cases. [21:38:08 CET] <ricemuffinball> i always use mkv because i can playback the mkv file during encoding process, i cannot do that with mp4 [21:38:28 CET] <kepstin> yes, that's a design issue with mp4. [21:38:47 CET] <kepstin> that's fine for VOD use cases like youtube, because the video is fully encoded before anyone starts watching it [21:38:48 CET] <ricemuffinball> right, wouldn't it be easiler for youtube to just use mkv [21:39:42 CET] <kepstin> browsers don't play mkv (well, they do, but only in the form of webm which has restricted codecs) [21:39:43 CET] <ricemuffinball> did youtube used FLV in the past? [21:40:14 CET] <kepstin> youtube used to use a flash player, I don't remember which codecs/formats they used at the time. [21:40:36 CET] <kepstin> but flash could play mp4 files for quite a long time, iirc. [21:41:27 CET] <TheAMM> FLV and certain MP4s, iirc there might've been some h264 level limit [21:41:32 CET] <ricemuffinball> kepstin browser don't like mkv? really? i didn't know that [21:41:45 CET] <ricemuffinball> i wonder why that is [21:41:53 CET] <TheAMM> RTMP (or was it RTSP?) too, but I don't know about that [21:42:20 CET] <TheAMM> ricemuffinball: chrome can play mkv in <video> if the codecs are proper [21:43:08 CET] <TheAMM> But for reasons unknown, won't play video/x-matroska inline [21:43:17 CET] <TheAMM> not even audio/flac [21:43:46 CET] <ricemuffinball> video/x-matroska inline ?? what is that [21:44:04 CET] <kepstin> ricemuffinball: browsers implement a restricted set of containers and codecs, mostly to limit exposure to possible security issues, and as a way to influence people to use specific codecs that the browser makers want to promote [21:44:15 CET] <ricemuffinball> kepstin i see [21:44:32 CET] <TheAMM> Here's H.264 and Opus in mkv playing with <video> https://mygi.ga/IHt/adSLI.mkv/embed [21:44:33 CET] <ricemuffinball> so browsers like mp4 and webm ? [21:45:06 CET] <ricemuffinball> it doesn't play [21:45:35 CET] <TheAMM> :shrug:, works for me on linux chrome [21:46:05 CET] <ricemuffinball> theamm do you have another mkv link [21:46:21 CET] <kepstin> yeah, if you want support across multiple browsers, you need to stick with mp4 or webm [21:46:35 CET] <kepstin> (or sometimes both) [21:46:44 CET] <kepstin> (but usually just mp4 is enough) [21:46:51 CET] <TheAMM> https://mygi.ga/iXk/aecmI.mkv/embed This is just h264 [21:47:38 CET] <kepstin> 'epiphany' (the gnome webkit-based browser) used to just use gstreamer to play <video> tags, it would play anything you had plugins installed for. It would even render ass subtitles and stuff :) [21:47:40 CET] <ricemuffinball> theamm so no sound? [21:47:58 CET] <kepstin> i dunno if that's still the case [21:48:27 CET] <TheAMM> libmpv for blink when [21:49:09 CET] <ricemuffinball> TheAMM plays fine on edge browser but doesn't work with firefox [21:49:24 CET] <ricemuffinball> firefox doesn't like mkv i guess [21:49:30 CET] <TheAMM> That's what I've heard people say a lot [21:49:32 CET] <kepstin> firefox is the most restrictive, it explicitly whitelists specific containers and codecs. [21:49:38 CET] <TheAMM> firefox doesn't like 4:4:4 webms either [21:49:47 CET] <ricemuffinball> what is 4:4:4 mean [21:49:51 CET] <TheAMM> It should, someone said, but last I tried, it didn't [21:50:02 CET] <TheAMM> YUV 4:4:4, subsampling (or the lack of) [21:50:10 CET] <kepstin> hmm, I was sure I had 4:4:4 webms with vp9 working in firefox at some point. [21:50:21 CET] <TheAMM> Most video is YUV 4:2:0 [21:50:37 CET] <TheAMM> Wikipedia has explanations unless someone here wants to tldr [21:50:52 CET] <TheAMM> I'm gonna do the daily hibernation now [21:50:57 CET] <ricemuffinball> is 10bit x264/x265 also YUV 4:2:0 [21:51:20 CET] <TheAMM> Likely, but yuv420p10 instead of yuv420p [21:51:48 CET] <kepstin> the 4:4:4 and 4:2:0 syntax is kinda strange / hard to understand - but the basic idea is that the human eye is less sensitive to certain colour information, so that information is sent at lower resolution than the rest of the signal. [21:51:54 CET] <ricemuffinball> what is the point of using 4:4:4 over 4:2:0 then [21:52:06 CET] <TheAMM> All the data? [21:52:06 CET] <kepstin> with 4:4:4 it's sent at full resolution, with 4:2:0, the colour data is sent at 1/4 resolution [21:52:09 CET] <kepstin> saves a lot of space [21:52:23 CET] <kepstin> well, 4:4:4 is a lot bigger [21:52:38 CET] <ricemuffinball> bigger as in file size? [21:52:42 CET] <kepstin> yes [21:53:09 CET] <ricemuffinball> can average people tell the difference between 4:4:4 and 4:4:2 [21:53:15 CET] <ricemuffinball> 0 i mean [21:53:41 CET] <kepstin> on most "natural" video content, no. [21:53:50 CET] <TheAMM> Depends on the scene [21:54:12 CET] <TheAMM> Since most video you see is 4:2:0 and you're not going "why does all video look bad", it's fine [21:54:15 CET] <kepstin> on artificial content (cg, screen capture, etc.) it's noticable as colour fringes on sharp transitions, especially diagonal. [21:54:21 CET] <TheAMM> But say if you're recording your monitor [21:54:27 CET] <TheAMM> yeah, like kepstin said [21:54:39 CET] <kepstin> if you have coloured small text in a screen capture, it's really noticable. [21:54:49 CET] <TheAMM> Especially red edges are obvious [21:55:35 CET] <ricemuffinball> if 4:2:0 is most used, what is second most used [21:55:37 CET] <kepstin> because of how YUV works, green (which your eyes are more sensitive to) is effectively sent at higher resolution than red and blue when using 4:2:0 [21:56:00 CET] <kepstin> ricemuffinball: 4:2:0 is so common that "second most used" is basically meaningless, everything else is niche [21:56:14 CET] <ricemuffinball> kepstin i see [21:56:28 CET] <TheAMM> Depends on the definition [21:56:32 CET] <kepstin> but it's probably either 4:4:4 (no subsampling) or 4:2:2 (1/2 sampling, used for interlaced media as a compromise) [21:56:43 CET] <ricemuffinball> so 4:4:4 a lot rarer/niche than 10bit video ? [21:57:01 CET] <TheAMM> eh [21:57:11 CET] <ricemuffinball> becuse most videos are 8bit video [21:57:16 CET] <kepstin> 10bit is going to be more common than 4:4:4, since it's going to be used for HDR video [21:57:22 CET] <kepstin> but that hdr video will still be 4:2:0 [21:57:58 CET] <kepstin> but that's "is going to be"... not "is right now" [21:58:06 CET] <kepstin> right now I have no idea which is less popular :) [21:59:32 CET] <ricemuffinball> does it save a lot of file space by using 4:2:0 over 4:4:4 [22:00:26 CET] <kepstin> *before* compression, 4:2:0 video is œ the size of 4:4:4 video [22:00:35 CET] <kepstin> after compression, the difference isn't as big [22:00:52 CET] <ricemuffinball> i see [22:01:21 CET] <ricemuffinball> so for raw , it's twice as big: that's big difference [22:02:07 CET] <kepstin> this is also an interesting thing with TV screens and HDMI - some TV screens can play 4K video with 4:2:0 sampling at 60Hz, but if you switch to RGB or 4:4:4 sampling, they can only do 30Hz. [22:02:19 CET] <kepstin> since the video's twice as big :) [22:04:19 CET] <ricemuffinball> i thought raw video file size = bit x resolution x resolution x fps x duration [22:04:57 CET] <ricemuffinball> where do you calculate the 4:4:4 [22:05:13 CET] <kepstin> it's in the "bit" video, which should actually be "bit per pixel" [22:06:04 CET] <ricemuffinball> so for 1 second 10 bit 1920-1080 30 fps = 10 x 1920 x 1080 x 30 x 1 [22:06:16 CET] <kepstin> 8-bit 4:4:4 video is 24 bit per pixel. 10-bit 4:4:4 video is 30 bit per pixel (sometimes rounded up to 32 or even 48). 8-bit 4:2:0 video is 12 bit per pixel. [22:07:34 CET] <ricemuffinball> 8-bit 4:2:0 video is not 8 ? [22:07:39 CET] <ricemuffinball> when doing calculation? [22:07:48 CET] <kepstin> For 4:2:0, that's 8 Y + Œ×8 U + Œ×8 V [22:08:07 CET] <kepstin> since the U and V are subsampled, to Œ resolution [22:08:50 CET] <ricemuffinball> oh you are right people use 24bit for 8 bit [22:09:02 CET] <ricemuffinball> 3 x 8 [22:09:28 CET] <kepstin> that's for 8 bit per channel, 3 channels, no subsampling, yes. [22:10:17 CET] <ricemuffinball> i remember when windows let me choose on display settings 24bit color or 16bit color or even 32bit color [22:10:43 CET] <kepstin> those are RGB colour modes, which are a different thing from YUV, but the ideas are basically the same [22:11:02 CET] <ricemuffinball> you can easily tell the difference choosing 24 and 16bit on windows settings [22:11:17 CET] <kepstin> 16 bit RGB colour is kind of neat, actually, since it's 5 bit of red, 6 bits of green, 5 bits of blue [22:11:30 CET] <ricemuffinball> i see [22:11:34 CET] <ricemuffinball> why more green? [22:12:05 CET] <kepstin> same reason as why YUV 4:2:0 has higher resolution for green - human eyes are more sensitive to it [22:12:12 CET] <ricemuffinball> i see [22:12:22 CET] <ricemuffinball> what is 32bit color then on windows settings [22:12:38 CET] <kepstin> 8R + 8G + 8B + 8 nothing [22:12:52 CET] <ricemuffinball> huh? so it's pointless [22:13:05 CET] <kepstin> it's just rounding it to even 32bits with padding, because that's faster to work with [22:13:20 CET] <ricemuffinball> i don't get it [22:13:27 CET] <kepstin> then a single pixel is an aligned 32bit read, rather than 3 separate 8bit reads. [22:14:07 CET] <ricemuffinball> so it has to do with how computer likes the number 32 than 24 ? [22:14:10 CET] <kepstin> it's just an implementation detail of computer processors - you can make some times of image processing faster, but you have to waste 8 bits per pixel [22:15:05 CET] <ricemuffinball> did it really make it faster though by choosing 32bit color over 24bit color [22:15:06 CET] <Foaly> well, if you're working with lots of data, packing may actually be faster [22:15:24 CET] <Foaly> because more fits in the cache [22:15:33 CET] <kepstin> ricemuffinball: depends on the image processing in question and the computer processor [22:15:56 CET] <ricemuffinball> with newer windows, i don't have a choice to choose the color depth [22:15:58 CET] <kepstin> windows decided on using 32bit for most stuff, and memory and bandwith have been increasing, so.. :/ [22:16:47 CET] <kepstin> the overhead on the array index calculations for 24bit image data may or may not be worse than the cache problem. depends on the processor :) [22:17:54 CET] <kepstin> (then there's the difference between planar and packed formats, each of which behaves better or worse for different operations) [22:20:44 CET] <ricemuffinball> kepstin this one website is saying extra 8bit is for alpha [22:20:55 CET] <ricemuffinball> whatever that is [22:21:11 CET] <ricemuffinball> 32-bit color [22:21:11 CET] <ricemuffinball> Like 24-bit color, 32-bit color supports 16,777,215 colors but has an alpha channel it can create more convincing gradients, shadows, and transparencies. With the alpha channel 32-bit color supports 4,294,967,296 color combinations. [22:22:26 CET] <Foaly> screens can't display alpha [22:22:41 CET] <kepstin> ricemuffinball: if you're making a semi-transparent image, you can use the extra 8-bits for an alpha channel, which says how transparent each pixel is [22:22:42 CET] <Foaly> there are 10 bit per channel screens though [22:24:04 CET] <kepstin> ricemuffinball: alpha doesn't add new colours, it just is an instruction on how to blend colours when you draw one image over top of another image. [22:32:11 CET] <ricemuffinball> what is best lossy audio codec these days? [22:32:58 CET] <klaxa> opus [22:32:58 CET] <another> depends on your definition of best [22:33:06 CET] <another> or what klaxa said [22:33:30 CET] <ricemuffinball> best quality per bitrate [22:33:37 CET] <klaxa> opus [22:33:57 CET] <ricemuffinball> klaxa are you just saying opus because it's "free" [22:34:02 CET] <durandal_1707> ac4 [22:34:40 CET] <ricemuffinball> ac4 ? never heard of it [22:35:04 CET] <Foaly> free is a good reason though [22:35:07 CET] <klaxa> same, but it seems to exist [22:35:28 CET] <ricemuffinball> klaxa i don't know about quality of opus but opus never seem to able to display bitrate correctly [22:35:31 CET] <klaxa> ricemuffinball: opus out-performs all other formats at the time of opus release (afaict) [22:36:04 CET] <ricemuffinball> klaxa that's the downside of opus [22:36:18 CET] <klaxa> that it's better than everything else? [22:36:28 CET] <ricemuffinball> but opus never seem to able to display bitrate correctly [22:36:38 CET] <durandal_1707> huh? [22:36:39 CET] <klaxa> https://opus-codec.org/comparison/ [22:36:48 CET] <klaxa> https://auphonic.com/blog/2012/09/26/opus-revolutionary-open-audio-codec-po… [22:37:06 CET] <ricemuffinball> youtube seems to like to use opus a lot [22:37:43 CET] <another> it's basically the default on yt [22:38:05 CET] <kepstin> ricemuffinball: it sounds like the issue is that the player you're using can't display opus bitrate correctly, which isn't opus fault :/ [22:38:11 CET] <ricemuffinball> does youtube use opus because it's free? [22:38:23 CET] <klaxa> no, because it's the best quality per bitrate [22:38:25 CET] <klaxa> just what you want [22:38:29 CET] <ricemuffinball> keptstin true but it does that for every player [22:38:50 CET] <durandal_1707> ricemuffinball: https://www.dolby.com/us/en/technologies/AC-4.html if you want costly solution [22:38:58 CET] <ricemuffinball> if every player has problem, shouldn't that be opus's fault [22:39:05 CET] <kepstin> ricemuffinball: it's a vbr codec, maybe it's just not behaving like you expect? [22:39:07 CET] <klaxa> or rather, it's more acceptable at lower bitrates than mp3 or aac [22:39:54 CET] <kepstin> ricemuffinball: depending on the player, it should show either an "average" bitrate over the entire file length, or the bitrate indicator may update as the file plays, showing the current bitrate at that moment [22:40:23 CET] <ricemuffinball> https://github.com/HandBrake/HandBrake/issues/1944 [22:41:05 CET] <kepstin> well, that's certainly a handbrake bug alright. [22:41:25 CET] <ricemuffinball> they are blaming on opus [22:41:33 CET] <ricemuffinball> handbrake people are blaming on opus [22:42:00 CET] <ricemuffinball> what should i type then [22:42:08 CET] <ricemuffinball> if they are trying to blame on opus [22:42:26 CET] <kepstin> no, they are having buggy handling of a particular codec implementation which doesn't report a bitrate for vbr data. [22:42:47 CET] <kepstin> they either need to calculate it themselves e.g. by averaging based on stream size, or just not show it. [22:42:48 CET] <ricemuffinball> isn't aac also VBR [22:43:06 CET] <klaxa> dunno man, vanilla music on android is showing me 137kbps for an opus file [22:43:09 CET] <klaxa> ffmpeg reports that as well [22:43:10 CET] <kepstin> aac can be vbr or abr, you might get different results [22:43:14 CET] <klaxa> i created that with ffmpeg [22:45:01 CET] <ricemuffinball> ffprobe has problem with this too [22:45:09 CET] <ricemuffinball> i just noticed [22:45:20 CET] <ricemuffinball> this is definitely OPUS fault [22:45:21 CET] <klaxa> well it's using the same library calls as ffmpeg [22:45:28 CET] <klaxa> then explain why my files work [22:45:29 CET] <klaxa> please [22:45:57 CET] <ricemuffinball> Stream #0:1: Audio: opus, 48000 Hz, stereo, fltp (default) [22:46:15 CET] <ricemuffinball> what is fltp ? [22:47:05 CET] <another> floating point [22:47:20 CET] <ricemuffinball> what is that exactly [22:47:28 CET] <durandal_1707> aliens [22:48:05 CET] <klaxa> numbers are not integers but floating points [22:48:26 CET] <klaxa> they can represent numbers between integers, but have drawbacks [22:48:34 CET] <ricemuffinball> ffprobe is not displaying bitrate on opus either [22:49:18 CET] <durandal_1707> afaik opus does not have such info stored in its bitstream it needs to be manually calculated [22:49:44 CET] <ricemuffinball> durandal_1707 i see, is opus the only audio format that has this issue? [22:50:11 CET] <ricemuffinball> where it does not have such info stored in bitstream [22:50:16 CET] <durandal_1707> ricemuffinball: nope, there are others for sure, it is just metadata [22:50:28 CET] <klaxa> ricemuffinball, i queried you a link [22:50:31 CET] <klaxa> with a file that works [22:50:34 CET] <klaxa> would you try that? [22:51:20 CET] <ricemuffinball> sure let me try [22:51:24 CET] <ricemuffinball> sorry didn't see the PM box [22:51:29 CET] <klaxa> no problem [22:52:05 CET] <another> could also be related to the container [22:52:20 CET] <ricemuffinball> Duration: 00:03:46.89, start: 0.000000, bitrate: 137 kb/s [22:52:20 CET] <durandal_1707> yes... [22:52:22 CET] <klaxa> oh yeah [22:52:32 CET] <another> opus in mp4 has per stream bitrate information [22:52:53 CET] <another> Duration: 00:06:53.43, start: 0.000000, bitrate: 96 kb/s Stream #0:0(und): Audio: opus (Opus / 0x7375704F), 48000 Hz, stereo, fltp, 94 kb/s (default) [22:53:41 CET] <klaxa> in the end, this metadata is nothing but stream_size/stream_duration [22:53:45 CET] <klaxa> and can be calculated on the fly [22:53:52 CET] <durandal_1707> ac4 have bitrate info in its bitstream - but that is also optional and not mandatory to have such metadata.... [22:55:08 CET] <ricemuffinball> durandal_1707 you seems to really like ac4 [22:55:22 CET] <ricemuffinball> durandal is it better than opus? [22:55:27 CET] <klaxa> paid shill, get out lol /s [22:55:33 CET] <durandal_1707> lol [22:56:13 CET] <klaxa> well it's not wrong comparing to the latest money-bought tech [22:56:17 CET] <durandal_1707> ricemuffinball: dunno, i cant do blind ABX as there is no encoder available freely [22:56:43 CET] <durandal_1707> but it is current trend in broadcast [22:57:00 CET] <ricemuffinball> i cant do blind ABX ? what is that even mean [22:57:26 CET] <durandal_1707> https://en.wikipedia.org/wiki/ABX_test [22:59:30 CET] <ricemuffinball> so whose fault is that opus doesn't display bitrate properly [22:59:40 CET] <ricemuffinball> somebody needs to get blamed [22:59:46 CET] <durandal_1707> nobody [22:59:47 CET] <another> why? [23:00:08 CET] <ricemuffinball> <kepstin> well, that's certainly a handbrake bug alright. [23:00:25 CET] <ricemuffinball> because people are blaming eachother [23:03:12 CET] <ricemuffinball> how comes this doesn't work: ffmpeg -i input1.wmv -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts [23:03:15 CET] <another> i think you're taking this a bit too seriously [23:03:59 CET] <ricemuffinball> another, i want to know what bitrate opus is using since opus is getting more and more popular now [23:05:59 CET] <klaxa> take the stream-size divide it by the stream-length [23:06:03 CET] <klaxa> you get the average bitrate [23:07:20 CET] <ricemuffinball> if it's that simple, why can't players/ffprobe get it right [23:07:35 CET] <ricemuffinball> and handbrake [23:08:27 CET] <ricemuffinball> Audio: Opus 48000Hz stereo 3072kbps [A: Stereo [eng] (opus, 48000 Hz, stereo)] [23:08:53 CET] <ricemuffinball> that's wrong by the way [23:10:40 CET] <klaxa> metadata is used if available and if not, then... not, correctness is not verified (usually impossible) [23:10:53 CET] <klaxa> whoever muxed that did a bad job [23:14:32 CET] <kepstin> hmm, i'm actually kind of surprised that ffprobe doesn't calculate per-stream bitrates when you use the -count_frames option [23:14:44 CET] <kepstin> guess nobody ever wrote that code. [23:15:31 CET] <ricemuffinball> and nobody has filed a bug report on ffmpeg? [00:00:00 CET] --- Sat Mar 2 2019

1 0