Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

September 2019

2 participants
80 discussions

ffmpeg-devel.log.20190929
by burek 30 Sep '19

30 Sep '19

[00:30:54 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:47a4528abc97: avformat/utils: Don't initialize in loops [00:30:55 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:bf79e4426a94: avformat/utils: Fix memleaks II [00:30:56 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:ada02cf85fff: avformat/utils: Don't create unnecessary references [00:30:57 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:cdba00ae113c: avformat/utils: Avoid copying packets unnecessarily [00:30:58 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:5c95af6b7c8e: avformat/utils: Improve parsing packets [00:30:59 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:9fdc2c7bc45b: avformat/utils: Remove unnecessary initializations [14:25:30 CEST] <durandal_1707> ceilf/truncf is not in C90 so FFmpeg cant use it? [14:29:58 CEST] <durandal_1707> FFmpeg should switch to C99 [14:34:02 CEST] <Lynne> ceilf is assumed to always be available, and truncf is automatically added if it doesn't exist [15:02:57 CEST] <durandal_1707> here you go: scroll filter [15:03:34 CEST] <durandal_1707> no more ideas to do [15:12:28 CEST] <Lynne> finish the decoder you started? [15:13:04 CEST] <Lynne> also tried arnndn, it sounded worse than anlmdn [15:19:23 CEST] <durandal_1707> Lynne: anlmdn is much slower and does not work for speech extraction at all, it just try to iron waves [15:24:14 CEST] <durandal_1707> Lynne: also what model you tried? i extracted std.rnnn -> default model used by rnnoise [15:41:40 CEST] <Lynne> I tried all, couldn't find the standard ("orig" in the rnnoise-models readme) one [15:42:20 CEST] <Lynne> it was much faster though, yes [15:52:22 CEST] <durandal_1707> Lynne: anlmdn is exponentially slower for high sample rates [16:10:47 CEST] <mkver> michaelni: Valgrind complains about jumps depending on uninitialized values in your recent fitsdec patch cfa19377. See http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-valgrind&time=2… [16:46:25 CEST] <durandal_1707> Lynne: i just checked, arnndn output is almost bit exact with rnnoise output, differences are pretty small [16:48:48 CEST] <durandal_1707> and yes, if you just listened at removed signal (with original/std model), arnndn is worse in typical scenarios than anlmdn [17:25:05 CEST] <michaelni> mkver, will fix it, thanks [17:34:41 CEST] <jamrial> mkver, michaelni: i sent a patch fixing it last night [17:35:54 CEST] <mkver> Sorry. Should have checked the ML before reporting it. [17:45:34 CEST] <cone-852> ffmpeg 03James Almer 07master:e3f0ecfc5788: avcodec/fitsdec: fix use of uninitialised values [17:48:36 CEST] <durandal_1707> is my change to qtrle and muxing fine? [17:50:59 CEST] <durandal_1707> https://patchwork.ffmpeg.org/patch/15327/ [17:51:11 CEST] <durandal_1707> https://patchwork.ffmpeg.org/patch/15286/ [18:23:08 CEST] <kierank> durandal_1707: yes [18:50:00 CEST] <cone-852> ffmpeg 03Andreas Rheinhardt 07master:f3333c3c67e8: avcodec/cbs_h2645: Fix potential out-of-bounds array access [18:50:01 CEST] <cone-852> ffmpeg 03Andreas Rheinhardt 07master:1929dd4eff93: avcodec/cbs_av1: Make overread check more robust [20:44:08 CEST] <cone-852> ffmpeg 03Paul B Mahol 07master:4a51075f4db1: doc/examples/muxing: fix underflow in duration of encoded streams [20:54:54 CEST] <durandal_1707> crap, my change is incorrect, this looks like mov strangeness [21:05:31 CEST] <jkqxz> cehoyos: The 10-bit RGB + 2-bit alpha format is a standard one for hardware. E.g. it's in OpenGL as GL_RGB10_A2, Vulkan as VK_FORMAT_A2R10G10B10_*, OpenCL as CL_RGBA + CL_UNORM_INT_101010_2. [21:06:02 CEST] <jkqxz> It's not a particularly useful intermediate, but it would be good to have it for direct rendering cases. [21:06:42 CEST] <cone-852> ffmpeg 03Paul B Mahol 07master:f1e17eb44657: avcodec/qtrleenc: fix undefined behaviour [21:07:53 CEST] <jkqxz> That VAAPI tonemap filter isn't what you want the ffmpeg utility for transcode cases, but it might be useful when rendering to output in a player. [21:10:12 CEST] <jkqxz> The inclusion of alpha there doesn't make any sense, though. The format should be 10-bit RGB with two ignored bits, like OpenCL's CL_RGB + CL_UNORM_INT_101010. [21:12:15 CEST] <jkqxz> I think there is a lot of confusion around alpha in the H.265 stuff they have, too. I'm not entirely sure because I don't have any hardware to look at, but I don't think the hardware they're talking about supports any alpha channel at all in H.265. [22:01:08 CEST] <cehoyos> jkqxz: There are hevc samples with alpha [22:01:33 CEST] <cehoyos> jkqxz: I now that the format is standard on Windows, my point is that it would be a new useless format in FFmpeg [22:01:38 CEST] <cehoyos> s/now/know [22:02:16 CEST] <cehoyos> Why is the vaapi tonemap filter not useful? Intel hardware is certainly more common than float formats... [22:03:15 CEST] <jkqxz> It's standard in hardware, independent of Windows. E.g. Linux DRM allows all variations: <https://cgit.freedesktop.org/mesa/drm/tree/include/drm/drm_fourcc.h#n137>. [22:04:54 CEST] <jkqxz> I mean I'm thinking it's not very useful in the FFmpeg utility specifically. It might be useful to have it in the library for players to use. [22:05:43 CEST] <cehoyos> I believe I also asked about the video players but no answers... [22:09:06 CEST] <jkqxz> On hevc+alpha - yes, but it comes as two independently-decodable layers. You get at most three components in a single-layer stream. [22:16:11 CEST] <cehoyos> jkqxz: It should come out as one frame from the decoder [22:16:20 CEST] <cehoyos> And the Intel developers claim it does [22:20:05 CEST] <cone-852> ffmpeg 03Michael Niedermayer 07master:47b0d0812e77: tools/target_dec_fuzzer: Adjust VP7 threshold [22:53:40 CEST] <rcombs> jkqxz: hmm, could you elaborate on the VAAPI tonemap filter, and how it differs from e.g. lavfi's? [22:53:58 CEST] <thardin> https://codecs.multimedia.cx/2019/09/going-to-the-7th-level-for-the-grail/ [23:13:44 CEST] <cehoyos> rcombs: It accepts a sane input format. [23:14:08 CEST] <rcombs> so does lavfi's OpenCL one, doesn't it [23:15:36 CEST] <JEEB> I think the only "insane" part of floating point linear RGB is that nobody added the swscale part for it. which, to be completely honest, I'm not really surprised about. [23:15:47 CEST] <JEEB> it's nice if the opencl one handles the most common cases, though. [23:15:59 CEST] <JEEB> because IIRC niklas talked rather well with the intel person making it [23:16:11 CEST] <JEEB> and thus it should technically be in a better state than the lavfi one? [23:16:56 CEST] <cehoyos> rcombs: No, it does not [23:21:13 CEST] <philipl> jkqxz: did you have a change to look at my hw transfer changes? [23:21:51 CEST] <philipl> *chance [23:25:27 CEST] <rcombs> cehoyos: in that OpenCL isn't well-supported in lavfi, or&? [23:26:18 CEST] <rcombs> JEEB: I end up concerned about it for perf reasons; seems like combining that math into a single pass would be faster [23:27:36 CEST] <JEEB> rcombs: could be [23:29:21 CEST] <cehoyos> Sorry, I misread above question: The hardware-based tonemap filters are more useful than the software filter (is what I was trying to say) [23:29:48 CEST] <cehoyos> Or: The vaapi filter will be once there is pipeline for what it outputs [23:34:18 CEST] <rcombs> I've been wanting to extract a bunch of utility functions out of vf_colorspace and into some generic lavfi or lavu APIs [23:34:56 CEST] <rcombs> like, getting conversion matrices, and applying transforms on individual colors (would be useful to drag drawutils.c out of BT601-land) [23:36:43 CEST] <JEEB> personally I would look into just pulling in zimg if the primary problem is that it's not part of the source code (although I'm pretty sure people will have issues with the fact that it's C++ and opted for intrinsics) [23:36:59 CEST] <JEEB> since you have AVX2 and AVX512 SIMD in zimg and the license is WTFPL [23:38:37 CEST] <rcombs> well, I'm saying that all the conversions should be built into vf_tonemap [23:38:55 CEST] <rcombs> so you can do 1-pass YUV->YUV [23:39:54 CEST] <JEEB> I'm not sure how well tone mapping works in YCbCr? [23:41:01 CEST] <rcombs> poorly, I'd imagine; you'd go to RGB and back [23:41:14 CEST] <rcombs> per-pixel [23:41:49 CEST] <rcombs> but that makes it just a few muls and no extra memory bandwidth requirement [23:42:11 CEST] <JEEB> so yea. the base steps would still be the same. main difference is that you'd just be holding it in a single filter vs having the linear rgb'ification separate [23:42:16 CEST] <rcombs> right [23:42:47 CEST] <JEEB> might need actual benchmarks to define it, but if it's worth it I'd say I'm OK with having that in there as long as it handles the content according to the input AVFrame [23:47:39 CEST] <rcombs> my _guess_ would be that you could do this today in the C filter (just by pulling in the matrix generation from vf_colorspace) and it'd be equivalent to or faster than the current route that uses ASM for the space conversion, because a few extra muls + int<->floats in the filter function are cheaper than round-tripping the floats through memory [23:48:00 CEST] <rcombs> but I haven't benched [23:52:02 CEST] <rcombs> hmmm, I wonder what the best way to handle multiple tonemap functions in ASM would be [23:52:48 CEST] <rcombs> there's the obvious "macro-ize it and duplicate the entire filter routine for each one" option [23:53:29 CEST] <rcombs> or you could do something along the lines of the C's switch/case, which is _probably_ pretty branch-predictor-friendly; not sure what that kind of thing does to your pipeline, though? [00:00:00 CEST] --- Mon Sep 30 2019

1 0

ffmpeg.log.20190929
by burek 30 Sep '19

30 Sep '19

[00:00:17 CEST] <JEEB> I don't think this was a regression ever :P [00:00:22 CEST] <JEEB> it jsut never worked correctly [00:00:25 CEST] <JEEB> (with gnutls) [00:01:09 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=bc1749c6e46099ec85110361db… [00:01:14 CEST] <JEEB> that's the relevant patch I think [00:03:35 CEST] <JEEB> (because IIRC the definition of a regression is: it used to work, now it doesn't) [00:05:41 CEST] <JEEB> anyways, I'm not sure if I 100% agree about regression fixes only because a lot of stuff just was incorrect to begin with [00:05:57 CEST] <JEEB> and only started breaking when someone on the "other side" of a line started using something [00:06:00 CEST] <JEEB> but I digress [00:07:21 CEST] <Thomas_J> I now have another problem. I am taking an rtsp feed in from an IP camera as map0 and adding a external sampled stereo feed as map1 and outputing to facebook via rtmps. The stream plays on facebook but the audio starts failing after a few seconde and ffmpeg throws a bunch of info lines, "[flv @ 0x55a96c1ee0] Delay between the first packet and last packet in the muxing queue is 10006000 > 10000000: forcing output". [00:08:07 CEST] <Thomas_J> When I write to a mp4 file instead, it runs smoothly. [00:14:51 CEST] <Thomas_J> Could this be caused from a buffer overrun? [05:23:32 CEST] <KodiakIT[m]> Not strictly ffmpeg related (outside of it being used on the back end I 'spose), but as #handbrake has only ~50 people I figure It can't hurt to ask here: Any ideas what's going on with the banding in the re-encoded video here? https://imgur.com/zrgxzUk [08:59:53 CEST] <cards> does #ffmpeg have the capacity to validate media, ie, detect if a file is truncated, detect if all the frames are intact, detect CRC and other parity corruption, whether the headers represents the content, etc etc [09:00:20 CEST] <cards> s/#// [11:15:01 CEST] <orue> Hi. I am trying to encode a video file from a ffv1 to h264 and I recognized a slight yellow/greenish color shift in the video output file. I assume that it is due to a colorspace shift? Is there a way to compensate such shifts reliably? [11:15:32 CEST] <orue> Ah forgot. I am trying to use cuda/nvenc https://pastebin.com/qQxak7G8 [11:45:35 CEST] <snooky> moin [19:35:57 CEST] <RazWelles> Hey, anybody know how to get debug information out of avcodec_encode_video2? Its silently crashing on me [19:36:46 CEST] <RazWelles> avcodec_encode_video2( output_context->streams[0]->codec, packet, picture, &got_packet); [19:38:52 CEST] <JEEB> don't use an AVCodecContext from lavf contexts :P [19:40:35 CEST] <JEEB> also I think by now for 3-4 years we've had a new API for decoding and encoding that decouples feeding and receiving [19:40:43 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [19:40:46 CEST] <JEEB> recommended reading [19:42:15 CEST] <RazWelles> Thank you.. x_x I'm reading deprecated everywhere and I'm having a hard time finding up to date information [19:43:28 CEST] <JEEB> you can find an AVCodec * to create a codec context by either using a name (to get a specific encoder or decoder), or by using a codec id [19:44:36 CEST] <JEEB> then you allocate the codec context with f.ex. avcodec_alloc_context3, and set the basic options depending on if it's video or audio [19:45:17 CEST] <RazWelles> Oh I think I found something I did wrong there then, I'm using avformat_alloc_output_context2 [19:45:32 CEST] <JEEB> that's for avformat [19:45:53 CEST] <RazWelles> ohh ok [19:46:51 CEST] <JEEB> it really depends on what encoder you're using exactly, but generally width/height/sample_aspect_ratio/pix_fmt and time_base seem to be a minimum set of things to set for video, for example [19:47:16 CEST] <JEEB> I usually create the encoder after the first AVFrame comes out of the decoder, because that way I don't need to guess things vOv [19:48:07 CEST] <RazWelles> What I have to do here is convert opencv mat's to avframes, so I'm filling the buffer manually [19:48:36 CEST] <RazWelles> I'm using the h.264 encoder [19:49:07 CEST] <pink_mist> which h.264 encodier? [19:49:11 CEST] <pink_mist> *encoder [19:49:15 CEST] <RazWelles> AV_CODEC_ID_H264 [19:49:38 CEST] <JEEB> that just picks *some* [19:49:45 CEST] <RazWelles> oof [19:49:55 CEST] <RazWelles> I think its using x264 [19:50:05 CEST] <JEEB> that's why the by name functions that give you an AVCodec are nice [19:50:13 CEST] <JEEB> you can specifically say "libx264" in that case [19:52:03 CEST] <RazWelles> I think I might have assembled a bad mental framework for how this stuff fits together. Is there an up to date resource I can read? I really appreciate the help here and don't want to inundate with dumb questions [19:52:04 CEST] <JEEB> but yea, get an encoder AVCodec, create a context for it, set basic values according to what you're going to be feeding to it, open the encoder and you can start using the stuff noted in the documentation link I posted [19:52:27 CEST] <JEEB> RazWelles: there are examples of varying quality under doc/examples [19:52:48 CEST] <RazWelles> How does that fit together with AvFormatContext? I think I'm using that to write to a file [19:53:08 CEST] <JEEB> avformat aka lavf is used for I/O and container level stuff [19:53:19 CEST] <JEEB> so avcodec handles the decoding to and from AVFrames [19:53:42 CEST] <JEEB> and then lavf either gives you AVPackets (reading) or eats your AVPackets (writing) [19:54:02 CEST] <JEEB> so you f.ex. can open an avformat context for mp4 [19:54:12 CEST] <JEEB> then you add the stream(s) that you need [19:54:45 CEST] <JEEB> call the write_header() function, and then push AVPackets received from an encoder to the avformat context [19:54:55 CEST] <JEEB> and when you're done, call the write_footer() function [19:54:59 CEST] <RazWelles> and I do that through receive_packet? [19:55:11 CEST] <JEEB> that gives you the AVPacket from the encoder [19:55:24 CEST] <JEEB> you can then take that into avformat [19:56:11 CEST] <JEEB> 1) set the AVStream index to the AVPacket you received 2) av_interleaved_write_frame [19:56:32 CEST] <JEEB> and yes, lavf uses _frame() in the functions [19:56:36 CEST] <JEEB> I am really sorry for that [19:56:40 CEST] <JEEB> it deals with AVPackets [19:57:09 CEST] <JEEB> so `av_read_frame` and `av_interleaved_write_frame` [19:57:14 CEST] <JEEB> actually read and write AVPackets [19:57:23 CEST] <JEEB> once again, sorry [19:58:29 CEST] <RazWelles> Not at all, I really appreciate this, was having a hard time piecing this together until now, thank you so much :) [20:39:24 CEST] <RazWelles> Are there any examples out there on using codecpar? [20:39:29 CEST] <RazWelles> Or is it just a warning I can ignore for now? [20:39:49 CEST] <JEEB> codecpar is utilized for accessing parameters from lavf contexts [20:39:54 CEST] <durandal_1707> RazWelles: see doc/examples/ [20:40:09 CEST] <JEEB> I'm not sure where you're touching a codecpar if you're not reading nor decoding stuff? [20:41:02 CEST] <RazWelles> I was setting parameters with the avcodeccontext param by param [20:41:06 CEST] Action: RazWelles takes a quick look under doc [20:55:44 CEST] <JEEB> RazWelles: with an encoder setting values to avcodeccontext is normal [20:55:52 CEST] <JEEB> not sure why you were setting them to the avcodecpar? [21:16:45 CEST] <RazWelles> So I seem to be able to make it to avcodec_send_frame, I created and set an avcodeccontext and I set the picture format to yuv420, but avcodec_receive_packet is where it crashes now [21:17:14 CEST] <RazWelles> I think I do an avcodec_send_frame and avcodec_recieve_packet one after the other correct? Using the same context? [21:18:52 CEST] <JEEB> RazWelles: since you're making the AVFrame, have you made sure your buffers are aligned and all? [21:19:01 CEST] <JEEB> and that values such as line-to-line stride is correc [21:19:03 CEST] <JEEB> *correc [21:19:04 CEST] <JEEB> *correct [21:20:21 CEST] <RazWelles> JEEB, I think I did, I'll double check though, by alignment do you mean setting the yuv planes? I might be using an old example where I'm setting and defining the buffer pointers myself via malloc, I couldn't get it working via get_buffer [21:20:50 CEST] <JEEB> you can get a pre-allocated AVFrame with specific pix_fmt, width and height IIRC [21:22:17 CEST] <RazWelles> Do I write to the buffer like picture->data[0][y*linesize[0]+x]? [21:22:57 CEST] <RazWelles> I'll try playing with get_buffer again [21:23:37 CEST] <durandal_1707> yes, but pixel format is important [21:24:00 CEST] <durandal_1707> if you use valgrind you can see if there are overreads/overwrites [21:24:03 CEST] <JEEB> https://ffmpeg.org/doxygen/trunk/group__lavu__frame.html#ga6b1acbfa82c79bf7… [21:24:08 CEST] <JEEB> this was it [21:24:12 CEST] <JEEB> av_frame_get_buffer [21:24:22 CEST] <JEEB> you feed it an AVFrame with the pix_fmt, width and height defined [21:25:57 CEST] <RazWelles> Ooh, I'll try setting it and accessing it again, I think I didn't have those defined before [21:26:19 CEST] <JEEB> that basically allocates you buffers with the required alignment [21:26:26 CEST] <JEEB> so you only need to copy over the line data [21:31:33 CEST] <RazWelles> My code is kind of blinding but is it alright if I post some of my code in a pastebin here? [21:31:45 CEST] <RazWelles> I set the get buffer alignment param to 0 because it says it does it automatically there [21:32:41 CEST] <RazWelles> https://pastebin.com/MWXWyBsZ [21:37:32 CEST] <durandal_1707> RazWelles: why you change picture->data[] pointers and linesize[] ? [21:39:26 CEST] <RazWelles> The original code for that example set the data[0] buffer to point to the malloc'ed memory block. the linesize 1 2 and 3 are different because YUV is Y full frame size, U and V half frame size [21:40:05 CEST] <RazWelles> Since I encode as YUV420p [21:41:43 CEST] <durandal_1707> RazWelles: remove that lines, they are incorrect [21:42:38 CEST] <JEEB> yea you don't need to set those, those are set by av_frame_get_buffer [21:42:50 CEST] <RazWelles> oh really? Does that account for the YUV format too? [21:42:59 CEST] <JEEB> you set the pix_fmt, width and height [21:43:13 CEST] <JEEB> that is enough for av_frame_get_buffer to just get you a buffer [21:43:16 CEST] <RazWelles> ooh ok [21:43:18 CEST] <JEEB> or buffers [21:43:55 CEST] <RazWelles> Hm.. still crashed for me [21:46:38 CEST] <durandal_1707> RazWelles: where it crashes now? [21:48:54 CEST] <RazWelles> Still at the same place, avcodec_receive_packet [21:49:16 CEST] <RazWelles> It does manage to send the frame though [21:49:53 CEST] <durandal_1707> what kind of crash? [21:52:09 CEST] <RazWelles> Oddly enough it's just silent [21:52:19 CEST] <RazWelles> I have the log level set to debug too [21:52:32 CEST] <RazWelles> I check for the return value but it never makes it to that [21:54:08 CEST] <durandal_1707> how you fill frame data[] ? [21:55:38 CEST] <RazWelles> Lines 36-52, I adapted it (maybe badly?) from the example code in ffmpeg's examples [21:56:04 CEST] <RazWelles> I wonder if I should try just not filling it and seeing if I can get blank packets through [21:56:37 CEST] <gunchyo> Hi, I cannot finish compiling ffmpeg from latest git https://paste.debian.net/plainh/e4af44b9 [21:56:48 CEST] <gunchyo> I have no libav* packages installed from Debian's repo to avoid conflicts [22:11:03 CEST] <RazWelles> I got it to stop crashing at avcodec_receive_packet durandal_1707, JEEB :o .. I had to allocate the packet pointer [22:11:10 CEST] Action: RazWelles does walk of shame [22:19:42 CEST] <ztube> Hey, is anyone here experienced with converting VOB to mkv? I have some issues regarding the metadata, e.g. the individual audio tracks and subtitles aren't assigned any language. I know how to assign the metadata manually but I would like to take this data from my input file [23:08:22 CEST] <kadiro> Hello, can we replace an embeded subtitle inside an mkv or we must copy video/audio track excluding subtitle and including a subtitle in the end? [23:08:54 CEST] <kadiro> I mean in the output [23:09:37 CEST] <pink_mist> I don't really understand what you think the difference of those two propositions are [23:09:44 CEST] <pink_mist> they sound like the same thing to my ears [23:11:56 CEST] <cehoyos> kadiro: Please provide ffmpeg -i output [23:12:03 CEST] <kadiro> pink_mist> let say I have a file called something.mkv that have video, audio and subtitle , i want to remove or replace that subtitle, do i need to copy video and audio only to another output and work on it or the ffmpeg can do that in the fly without taking many spaces as i don't have for other mkv files [23:12:11 CEST] <kadiro> cehoyos> ok [23:12:25 CEST] <pink_mist> kadiro: ffmpeg can do it in one operation [23:12:45 CEST] <pink_mist> kadiro: this operation will require you to copy it [23:13:16 CEST] <pink_mist> kadiro: you can't have ffmpeg output to the same file as your input, that will ruin everything [23:13:44 CEST] <kadiro> oh [23:17:32 CEST] <kadiro> cehoyos> sorry to be late as the command line didn't work, i did it manually: https://paste.ubuntu.com/p/dTDMm9zJQh/ [23:18:24 CEST] <kadiro> pink_mist> you mean it has to be something like: ffmpeg myfile <some_arguments> outputfile ? [23:18:54 CEST] <pink_mist> -i myfile, but yes [23:18:55 CEST] <kadiro> :( [23:19:11 CEST] <kadiro> pink_mist> can i just replace the subtitle by ovveriding it ? [23:19:33 CEST] <pink_mist> whatever media player you're playing it with can possibly do that [23:19:43 CEST] <pink_mist> I'm pretty sure mpv for instance has that ability [23:19:55 CEST] <pink_mist> I don't really use other media players, so I can't say much about others [23:20:00 CEST] <kadiro> pink_mist> I manage to play it on tv [23:20:44 CEST] <pink_mist> you'll need to ask your tv manufacturer then I guess [23:21:04 CEST] <kadiro> ok thank you pink_mist [23:35:52 CEST] <kadiro> pink_mist> If i do : ffmpeg -i input.mkv -srt input.srt -c:v copy -c:a copy output.mkv ... it will override the subtitle or it add it ? [23:36:41 CEST] <pink_mist> I'm the wrong person to ask, I don't honestly know ... my guess would be that should override the subtitle [23:36:49 CEST] <pink_mist> but you may need some -map invocation too [23:37:36 CEST] <kadiro> ah ok, is not the map used when we have multiple tracks? [23:38:40 CEST] <pink_mist> like I said: I don't know [23:38:52 CEST] <pink_mist> I would suggest you try it and see [23:39:04 CEST] <kadiro> ok sorry, thank you [23:41:12 CEST] <RazWelles> Any particular reason why avformat_alloc_output_context2 would fail to open a file? [23:51:43 CEST] <ztube> maybe sth like -map 0:s -map 1:s might add the subtitles [23:55:01 CEST] <kadiro> with this command : ffmpeg -i input.mkv -f ass -i input.ass -c:v copy -c:a copy test.mkv ==> ffmpeg work but the old subtitle is still there, with this: ffmpeg -i input.mkv -f ass -i input.ass -c:v copy -c:a copy -c:s mov_text test.mkv ==> ffmpeg say: [matroska @ 0x55d50c938360] Subtitle codec 94213 is not supported. av_interleaved_write_frame(): Function not implemented Error writing trailer of test.mkv: Function not implemented [23:55:48 CEST] <kadiro> ztube> will try that [23:56:25 CEST] <ztube> so if you want to replace the subtitle instead of adding i would use [23:57:22 CEST] <ztube> ffmpeg -i input.mkv -i input.ass -c:v copy -c:a copy -c:s copy -map 0:v -map 0:a -map 1:s test.mkv [00:00:00 CEST] --- Mon Sep 30 2019

1 0

ffmpeg-devel.log.20190928
by burek 29 Sep '19

29 Sep '19

[00:28:28 CEST] <philipl> Lynne: jkqxz: BtbN: https://github.com/philipl/FFmpeg/pull/1 [00:28:35 CEST] <philipl> Just used a PR on myself for convenience. [00:29:07 CEST] <philipl> That implements explicit HW transfer hooks and support in vf_hwupload and then bi-directional transfer support in hwcontext_vulkan [00:29:29 CEST] <philipl> The main thing that's still missing is proper handling for a hwcontext to declare support for hw pix fmts vs sw pix fmts. [00:29:45 CEST] <philipl> But it works well. [00:40:24 CEST] <BtbN> I still need to look at the whole Vulkan hwcontext stuff in itself. [01:04:43 CEST] <philipl> BtbN: that's in the tree history too. [01:40:11 CEST] <cone-789> ffmpeg 03Lou Logan 07master:04858650b178: ffmpeg_opt: remove errant space [02:03:50 CEST] <nevcairiel> this guy sure doesnt seem to get the hint :D [02:11:32 CEST] <BBB> is it maybe a feature request ? [02:11:46 CEST] <BBB> I mean, I don't think that means the bug should stay open [02:11:54 CEST] <BBB> but maybe he doesn't know trac is not for feature requests? [02:12:03 CEST] <BBB> and statign that explicitly might stop him from opening more such bugs [02:12:36 CEST] <nevcairiel> well feature request are sort of ok, but his post doesnt even make much sense [02:13:05 CEST] <nevcairiel> its like "I want this 3-letter thing that I think is important" [02:14:01 CEST] <cehoyos> BBB: He has opened a large number of tickets in the past, a high percentage invalid [02:15:42 CEST] <cehoyos> The issue here is (like in tickets before) that he - as nevcairiel correctly wrote - simply copies different buzzwords [02:16:42 CEST] <cehoyos> In this case, he combines HD-DVD, Bluray, HDV and XD-CAM with an old question from the user mailing list [02:17:39 CEST] <cehoyos> These are all missing features, but they are both well known and have little relationship (I doubt that HDV and Bluray would share much code although they both imply changes to the mpegts muxer) [02:39:32 CEST] <Chagall> MPEG-2 blu-ray format is not supported? [02:40:07 CEST] <Chagall> or just not encoding to it? [02:41:05 CEST] <Chagall> only found https://trac.ffmpeg.org/ticket/1766 [02:47:25 CEST] <Chagall> that's a questionable entry now that I read the description... [03:08:52 CEST] <kierank> I doubt anyone wants to make mpeg-2 blurays [03:08:56 CEST] <kierank> they are some historical quirk [03:09:08 CEST] <kierank> every blu-ray player can play h264 [03:11:29 CEST] <cehoyos> I always wanted this feature;-( [03:11:38 CEST] <cehoyos> I'd still love it. [03:20:35 CEST] <kierank> michaelni: in chunked decode mode with slice threads, in the case where thread A is on frame 0 and thread B has crossed to frame 1, how do you suggest thread B gets a new h264codeccontext? [03:20:51 CEST] <kierank> I guess this is what dav1d does [03:20:58 CEST] <kierank> and why it was easier to implement it outside of ffmpeg [03:22:52 CEST] <cone-789> ffmpeg 03James Almer 07release/4.1:3ecbb180ef3b: aformat/movenc: add missing padding to output track extradata [03:27:59 CEST] <cone-789> ffmpeg 03Jun Zhao 07release/4.1:4fbeaaa2208e: lavc/mpeg4audio: add chan_config check to avoid indeterminate channels [03:28:06 CEST] <kierank> ff_h264_queue_decode_slice [03:28:13 CEST] <kierank> https://github.com/FFmpeg/FFmpeg/blob/95e5396919b13a00264466b5d766f80f1a4f7… [03:28:18 CEST] <kierank> apparently already a case [03:28:20 CEST] <kierank> so this is doable [03:29:00 CEST] <cone-789> ffmpeg 03Jun Zhao 07release/4.2:61853f750353: lavc/mpeg4audio: add chan_config check to avoid indeterminate channels [03:42:41 CEST] <BBB> kierank: it can be done inside ffmpeg also, but we typically don't have a good separation between slice contexts, frame contexts and global contexts [03:42:51 CEST] <BBB> in dav1d, we made everything correct fromt he start, no hacks [03:42:59 CEST] <BBB> so everytime something didn't fit, we had to make it fit anyway [03:42:59 CEST] <kierank> yep, my exact problem right now [03:43:05 CEST] <BBB> slice always accesses a const frame [03:43:10 CEST] <BBB> frame always accesses a global const [03:43:18 CEST] <BBB> that means no races, no unexpected behaviour, etc. [03:43:24 CEST] <BBB> it's beautiful [03:45:44 CEST] <BBB> if i could redesign ffmpeg's threading, i would add that, yes [03:46:48 CEST] <kierank> I think I can fix the current problem I have though but it's messy as hell [03:46:54 CEST] <kierank> and probably going to create a fuzzing mess [06:23:39 CEST] <taliho> """""""""""""""""AZ< [13:26:17 CEST] <durandal_1707> Lynne: i got more boost with using SIMD in compute_gru() also did your thing with fmac_scalar [13:29:32 CEST] <durandal_1707> https://pastebin.com/pGm4NrpA [17:12:23 CEST] <durandal_1707> listening idea for some nice A->A or V->V filter [17:38:42 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:736c7c20e781: swscale/x86/swscale: Fix undefined left shifts of negative numbers [17:38:42 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:f7bc0386d935: avcodec/ffv1enc: Fix out-of-bounds-array access [17:38:42 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:e2646e23be69: swscale/utils: Fix invalid left shifts of negative numbers [17:38:42 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:b7f156e8cbdf: avcodec/dnxhdenc: Fix undefined left shifts of negative numbers [17:38:42 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:324487b596fb: avcodec/ituh263dec: Fix undefined left shift of negative number [17:38:43 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:5cf593adcd79: avcodec/jpeg2000dwt: Fix undefined shifts of negative numbers [17:38:43 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:fa211943265c: avfilter/vf_hqx: Fix undefined left shifts of negative numbers [17:38:44 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:4294dc3589a3: avfilter/vf_xbr: Fix left shift of negative number [18:17:35 CEST] <jamrial> durandal_1707: waifu2x [18:17:56 CEST] <durandal_1707> please no [18:18:44 CEST] <jamrial> oh well :p [18:21:17 CEST] <JEEB> we already have nnedi3 [18:31:22 CEST] <durandal_1707> ban this guy [19:24:46 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:f63cd1963e36: avcodec/hevc_cabac: Tighten the limit on k in ff_hevc_cu_qp_delta_abs() [19:24:47 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:1e95a3e8a725: avcodec/apedec: Fix several integer overflows in predictor_update_filter() and do_apply_filter() [19:24:47 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:cf41da2ad2ec: avcodec/apedec: Allocate decoded_buffer after successful ff_get_buffer() [19:24:47 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:7f7af9e294f8: avcodec/vc1: check REFDIST [19:24:47 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:181e138da720: avcodec/vc1: Check for excessive resolution [19:24:47 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:c722a69253a2: avcodec/vc1_block: Fix invalid shift with rangeredfrm [19:24:47 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:ced9a1cd0ab7: avcodec/vc1_pred: Fix invalid shifts in scaleforopp() [19:24:47 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:e75e7fe1601b: vcodec/vc1: compute rangex/y only for P/B frames [19:24:47 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:fbb314b6f2c2: avcodec/ralf: Fix integer overflow in decode_channel() [19:24:48 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:8335ba8ae999: avcodec/ituh263dec: Make the condition for the studio slice start code match between ff_h263_resync() and ff_mpeg4_decode_studio_slice_header() [19:24:49 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:017884bdc397: avcodec/motionpixels: Mark 2 functions as always_inline [19:25:23 CEST] <durandal_1707> ban this guy [20:44:50 CEST] <durandal_1707> Lynne: https://github.com/kfrlib/kfr [21:03:38 CEST] <jdarnley> Dammit! That's twice you've blue screened playign this file. [21:04:24 CEST] <durandal_1707> ?!? [21:04:49 CEST] <jdarnley> Yeah. [21:05:00 CEST] <JEEB> is hardware decoding related? [21:05:06 CEST] <JEEB> or is this pure software causing bluescreens? [21:05:11 CEST] <jdarnley> Maybe/probably [21:05:13 CEST] <JEEB> *pure user space [21:05:19 CEST] <jdarnley> I doubt it [21:05:26 CEST] <JEEB> :) [21:05:31 CEST] <jdarnley> could be HW overlay if that was pure software [21:06:09 CEST] <jdarnley> I'll use vlc instead, see if that does it too [21:10:34 CEST] <Fox_M> re [21:14:01 CEST] <Lynne> 149302 decicycles in fftwf_execute (FFTW_ESTIMATE), 16373 runs, 11 skips [21:14:03 CEST] <Lynne> 33486 decicycles in fftwf_execute (FFTW_MEASURE), 16348 runs, 36 skips [21:14:24 CEST] <Lynne> durandal_1707: even our fft is faster than fftw when FFTW_ESTIMATE is used ^^ [21:16:09 CEST] <Lynne> the 4.46 times speedup to not using bad fftw config puts both kfr and ippsp to shame or matches them [21:20:09 CEST] <Lynne> FFTW_MEASURE is barely 20% slower to run on startup tham FFTW_ESTIMATE, and its the default [21:27:51 CEST] <durandal_1707> Lynne: i think they have AVX for their FFT [21:31:28 CEST] <Lynne> so do we? [21:55:11 CEST] <cone-144> ffmpeg 03Limin Wang 07master:b4e7d3a0db94: avfilter/vf_framerate: limit the scene level max range [21:55:12 CEST] <cone-144> ffmpeg 03Limin Wang 07master:fd5fdca95337: avfilter/vf_framerate: refine the filter_slice code for better readiablity [21:55:13 CEST] <cone-144> ffmpeg 03Limin Wang 07master:86f0411a5270: avfilter/vf_framerate: remove duplicate code with macro-based function [22:11:11 CEST] <cone-144> ffmpeg 03Paul B Mahol 07master:216830aca4ff: avfilter/fifo: cosmetics [22:11:12 CEST] <cone-144> ffmpeg 03Paul B Mahol 07master:947e8ab329af: avfilter/fifo: use the name 's' for the pointer to the private context [22:32:26 CEST] <jdarnley> vlc to the rescue [22:32:47 CEST] <jdarnley> I should look at updating my video drivers and other software [22:41:30 CEST] <durandal_1707> users do not deserve ffmpeg [23:07:23 CEST] <cone-144> ffmpeg 03Paul B Mahol 07master:551e8dc14593: doc/filters: add more advanced silenceremove example [00:00:00 CEST] --- Sun Sep 29 2019

1 0

ffmpeg.log.20190928
by burek 29 Sep '19

29 Sep '19

[02:17:29 CEST] <Xatenev> hey [02:18:37 CEST] <Xatenev> i use ffmpeg with youtube-dl and its loosing metadata in the ffmpeg audio converting from mp4 to wav [02:18:37 CEST] <Xatenev> theres a command --postprocessor-args that (I assume) directly passes these arguments to ffmpeg [02:18:37 CEST] <Xatenev> I tried stuff with -map_metadata but I yet havent found any working commands [02:18:41 CEST] <Xatenev> any ideas what I have to use in there to make it map metadata? [02:22:18 CEST] <FooNess_> Out of curiosity, why are you going from mp4 to wav? Just to be clear, a lossy format's conversion to wav will not restore it to true lossless form. [02:23:25 CEST] <Xatenev> FooNess_: dunno, i wanted to prepare a configuration for a friend he said he needed wav. [02:24:29 CEST] <FooNess_> I see. [02:25:04 CEST] <Xatenev> converting it to mp3 seems to work fine. [02:25:10 CEST] <Xatenev> there must be something special with wav.. hm [02:25:42 CEST] <pink_mist> wav doesn't support metadata as far as I'm aware [02:26:00 CEST] <Xatenev> ahh [02:26:21 CEST] <Xatenev> As a derivative of RIFF, WAV files can be tagged with metadata in the INFO chunk [02:26:22 CEST] <Xatenev> from wikipedia [02:26:25 CEST] <Xatenev> or is that something else? [02:26:47 CEST] <FooNess_> That's not true; they actually can embed metadata. It's just that some programs may not be able to read it. [02:26:48 CEST] <FooNess_> https://en.wikipedia.org/wiki/WAV#Metadata [02:26:56 CEST] <FooNess_> > Applications may not handle this extra information or may expect to see it in a particular place. [02:27:03 CEST] <Xatenev> hm [02:27:05 CEST] <Xatenev> maybe windows can just not read it? [02:27:13 CEST] <Xatenev> does ffmpeg give me any way to check the metadata? [02:27:25 CEST] <Xatenev> (I cheecked the metadata with right click => settings )> [02:27:55 CEST] <pink_mist> guess I'm wrong then [02:27:58 CEST] <pink_mist> til [02:28:30 CEST] <Xatenev> ah [02:28:39 CEST] <Xatenev> ffmpeg -i in.wav -f ffmetadata in.txt shows me metatags [02:31:28 CEST] <pink_mist> I suppose I must have always used programs that couldn't read the metadata when I dealt with wav [02:31:41 CEST] <FooNess_> Yeah, it's hit or miss. [02:31:46 CEST] <Xatenev> thx !:) [02:31:47 CEST] <Xatenev> all clear then [06:31:32 CEST] <YellowOnion> What is "Queue input is backwards in time"? why does using a dshow input cause this error? [06:36:01 CEST] <markfilipak> If I want ffprobe with the largest possible scope, is there an easy call? I tried 'ffprobe -default' per its '-help' advice, but 'ffprobe -default' errored out. [06:36:23 CEST] <markfilipak> It wanted an argument. [06:44:29 CEST] <YellowOnion> looks like ffmpeg treats dshow as if i't can play it at any speed...and also ignores -re...wtf [14:53:51 CEST] <HickHoward> so uhhh [14:54:18 CEST] <HickHoward> i managed to find a HEVC video that ffmpeg reports as having "unspecified pixel format" [14:54:32 CEST] <durandal_1707> sample? [14:54:52 CEST] <HickHoward> hold on [14:55:04 CEST] <TheAMM> I've ran into some mkvs which claim the same for h264 [14:55:16 CEST] <HickHoward> it's an WWDC 2019 video about "HEVC Video with Alpha" [14:55:43 CEST] <HickHoward> it's already publicly available but if you want me to send a "sample file" to you i'll try to somewhat manage here [14:55:44 CEST] <TheAMM> I haven't poked at all of them (I have an automated project that goes through lots of video) but in the few I looked at, it's a case of malformed mkv and ffmpeg failing to resync [14:55:51 CEST] <cehoyos> HickHoward: This is supposed to play without alpha, please provide the sample [14:56:30 CEST] <TheAMM> and reports a video stream twice, one proper, then corruption happens and reports the same stream another time but without pixel format etc [14:56:53 CEST] <cehoyos> You don't have to explain what fails, just provide a lin [14:56:54 CEST] <cehoyos> k [14:57:39 CEST] <TheAMM> I'm explaining my experience with ffmpeg's demuxer [14:58:59 CEST] <HickHoward> https://www.sendspace.com/file/sgixkv [14:59:20 CEST] <HickHoward> this is the file in question [14:59:32 CEST] <HickHoward> the "HEVC video" i mentioned earlier [15:01:03 CEST] <cehoyos> Consider increasing the value for the 'analyzeduration' and 'probesize' options [15:01:06 CEST] <cehoyos> This works [15:01:21 CEST] <JEEB> I guess the parameter sets are further down in the file? [15:02:03 CEST] <cehoyos> But the file was created with FFmpeg and is therefore of very limited usefulness [15:02:30 CEST] <HickHoward> okay, just hold on [15:12:09 CEST] <HickHoward> yeah, i just did for that one mp4 file [15:12:16 CEST] <HickHoward> shows proper info now [16:01:06 CEST] <n00bV2> Hi peeps! [16:02:00 CEST] <n00bV2> Is it possible sombody could give me some advice on this: [16:02:03 CEST] <n00bV2> https://trac.ffmpeg.org/ticket/8208 [16:02:06 CEST] <n00bV2> please :) [16:09:17 CEST] <BtbN> I'd say bisect it [16:12:07 CEST] <n00bV2> What the source input? [16:12:29 CEST] <cehoyos> BtbN: What do you want to bisect [16:12:30 CEST] <cehoyos> ? [16:13:17 CEST] <cehoyos> n00bV2: What kind of advice do you need? The h264 decoder incorrectly returns a failure value in multithreaded decoding, ffmpeg ignored it in the past, prints it now. [16:14:18 CEST] <n00bV2> The advice I need is; Am I ok to just ignore this failure value or will it cause an issue with encodes? [16:14:25 CEST] <cehoyos> Did you read the gpl? [16:14:52 CEST] <BtbN> cehoyos, well, if it workes in 4.1 and doesn't in 4.2, that should be pretty easy to bisect? [16:15:02 CEST] <cehoyos> Did you look at the ticket? [16:15:24 CEST] <cehoyos> https://trac.ffmpeg.org/ticket/8208#comment:1 [16:16:25 CEST] <n00bV2> the gpl for ffmpeg? Probably at one point :p [16:16:45 CEST] <BtbN> Oh, so it's just more verbose logging, and the failure case was always there? [16:16:46 CEST] <n00bV2> I did look at the ticket and to the log corrupted packets and frame page [16:17:20 CEST] <BtbN> Is there any issue beyond it logging that? [16:17:38 CEST] <cehoyos> You question sounds as if you are asking for some "garantee", you should therefore read the no-warranty clause of the the (l)gpl [16:17:52 CEST] <cehoyos> Yes, the h264 decoder returns an error on multi-threading [16:18:16 CEST] <BtbN> But then it can't be the mentioned commit, because it does not add any additional failure cases, just logging [16:18:18 CEST] <cehoyos> Possibly when PAFF and MBAFF change [16:18:42 CEST] <cehoyos> That's why I asked what do you want to bisect, I wasn't sure what you meant [16:18:51 CEST] <cehoyos> s/change/switch [16:19:54 CEST] <n00bV2> my apologies, wasn't looking for a 100% guarantee. More of a general 'its ok to ignore, it doesn't impact encded output' [16:20:23 CEST] <cehoyos> As said: The reference decoder does not protest for the given sample (it often does) [16:20:53 CEST] <cehoyos> In addition, single-threaded decoding for the sample you provided shows no error, another strong indication that there is no issue for the sample you provided. [16:23:43 CEST] <n00bV2> ok. I think I've got the gist of what you're trying to say :) [16:26:03 CEST] <cehoyos> n00bV2: Sorry if you don't find the answers helpful, FFmpeg is not a stream analyzer (on the contraray, it is supposed to work fine for broken samples) and I am not convinced the reference decoder is considered a stream analyzer (stream analyzers are typically expensive). The fact that you provided one sample for which a particular warning message is wrong is no proof that the message is always wrong (I suspect this was your original [16:26:04 CEST] <cehoyos> question). [16:27:09 CEST] <n00bV2> not at all, I'm happy for the help I've had for you & the other people! [16:28:16 CEST] <n00bV2> And I think you're right, about that being kinda being my original question. [16:29:47 CEST] <n00bV2> But I do appreciate the help. even if I don't always understand it :) [17:53:22 CEST] <hedgehog90> Hi, I'm downsampling some videos to save space on my harddrive, but I notice that when I convert an mkv (to a lower quality mkv), the video bitrate according to mediainfo is not changing, even though the bitrate is 10% of what it was. How do I tell FFMpeg to write the correct metadata after conversion? [17:57:24 CEST] <hedgehog90> Anyone? I can't find any information about this online. [18:13:25 CEST] <n00bV2> hedgehog90: post the command line you're using [18:13:53 CEST] <hedgehog90> simply any command where the input and output are an mkv [18:14:10 CEST] <hedgehog90> so 'ffmpeg -i input.mkv output.mkv' [18:20:47 CEST] <n00bV2> i just did a quick test. input 57.3MB output 41.3MB [18:21:06 CEST] <n00bV2> Bit rate : [18:21:08 CEST] <n00bV2> 7 176 kb/s [18:21:22 CEST] <n00bV2> Bit rate : [18:21:24 CEST] <n00bV2> 5 327 kb/s [18:21:50 CEST] <n00bV2> seems to work my end :/ [18:24:01 CEST] <hedgehog90> Is that bit rate value according to mediainfo? [18:24:27 CEST] <n00bV2> MediaInfoLib - v18.03.1 [18:25:06 CEST] <hedgehog90> Mine's 19.07 [18:25:27 CEST] <hedgehog90> how odd [18:25:50 CEST] <n00bV2> you could try 18.03. Maybe do a complete console ouput. but don't paste here [18:25:58 CEST] <n00bV2> paste it on pastbin or something and put the link here [18:27:50 CEST] <hedgehog90> interesting, 18.03 displays the correct value [18:28:34 CEST] <n00bV2> so problem solved....sorta :p [18:29:20 CEST] <hedgehog90> yeah, 'sorta' :) [18:32:42 CEST] <furq> hedgehog90: mediainfo reads the mkvtoolnix NUMBER_OF_BYTES/DURATION/BPS tags [18:32:48 CEST] <furq> and ffmpeg just copies those across blindly [18:33:16 CEST] <furq> you can either unset those one by one with -metadata, use -map_metadata -1 to nuke all the metadata, or remux it with mkvtoolnix to write the correct values [18:34:05 CEST] <furq> i don't think ffmpeg will ever write those tags itself but maybe i'm wrong [18:34:25 CEST] <hedgehog90> Thanks, I should be able to remove those troublesome tags without remuxing though :) [18:34:47 CEST] <furq> yeah if you just want to fix one file then mkvpropedit or whatever willd o it [18:35:11 CEST] <furq> i don't think those are defined by any spec, it's some mkvmerge specific thing [18:35:27 CEST] <JEEB> yea, tags are just freeform text [18:36:10 CEST] <furq> i always just use mkvmerge --disable-track-statistics-tags [18:36:15 CEST] <furq> but other people aren't so kind [20:12:38 CEST] <Thomas_J> I am trying to compile ffmpeg-4.2.1. I am getting Unknown option "--enable-libasound". I have libasound-dev installed. I know it must be something stupid that I've done. [20:12:50 CEST] <Thomas_J> ./configure --prefix=/usr --pkg-config-flags="--static" --extra-libs="-lpthread -lm" --bindir="./bin" --enable-gpl --enable-version3 --enable-nonfree --logfile=/var/log/ffmpeg/build.log --enable-libasound --enable-libmp3lame --enable-libfdk-aac --disable-doc --disable-htmlpages --disable-podpages --disable-txtpages --enable-libx264 --enable-libx265 --enable-gnutls --enable-static --disable-stripping [20:13:27 CEST] <pink_mist> the error message is saying that's not a flag that ffmpeg's configure recognises [20:13:37 CEST] <pink_mist> it's not saying anything about whether it's installed or not [20:14:00 CEST] <DHE> is that just alsa? [20:14:03 CEST] <pink_mist> did you see that flag mentioned in ./configure --help? [20:14:46 CEST] <Thomas_J> I realize that but it has been a working flag before. I am using Alsa. [20:15:19 CEST] <pink_mist> well it may not be a working flag anymore [20:15:33 CEST] <pink_mist> (it clearly isn't, in fact) [20:16:54 CEST] <furq> yeah there is no flag for alsa [20:17:03 CEST] <furq> it's autodetected [20:17:10 CEST] <furq> you can only disable it [20:18:11 CEST] <Celmor[m]> how do I properly transcode HDR content from HEVC to h264, cause if I try to without taking precautions I get "colorless" [20:18:14 CEST] <Celmor[m]> output* [20:19:38 CEST] <Thomas_J> I see that now. Alsa recognition must be built in now. [20:20:16 CEST] <Thomas_J> Thanks [20:24:33 CEST] <cehoyos> Thomas_J: There was never a configure option --enable-libasound in FFmpeg. [20:26:40 CEST] <cehoyos> From a quick look, alsa is auto-detected for more than a decade [20:32:56 CEST] <kepstin> Celmor[m]: to convert from hdr to sdr, you need to apply tonemapping. ffmpeg does have a tonemap filter but i haven't personally used it. [20:33:18 CEST] <JEEB> kepstin: I was going to respond to him but then I wasn't sure what exactly he wanted to be done :) [20:33:24 CEST] <JEEB> just 10bit HEVC to 10bit AVC as-is [20:33:27 CEST] <kepstin> Celmor[m]: otherwise, it might be possible to get the hdr metadata correct in the output file so the player can tonemap if needed [20:33:34 CEST] <JEEB> or 10bit HEVC tone mapped to 8bit AVC [20:33:43 CEST] <Thomas_J> Boy! I am really confused now. I went back through the config strings used previously that I have saved not finding it. I ahve no idea how it got into my current config string??? [20:34:17 CEST] <JEEB> the tonemap filter works, but I think unfortunately the opencl one has the latest algorithm [20:34:20 CEST] <JEEB> (from mpv) [20:34:21 CEST] <Celmor[m]> I don't care about keeping HDR, I just want to look the color to look the same on a non-HDR display [20:34:34 CEST] <JEEB> although that as well I think at this point is outdated [20:35:02 CEST] <JEEB> Celmor[m]: so tone mapped to 8bit BT.709 and gamma [20:35:28 CEST] <JEEB> that is unfortunately not specified as a standard so every application or module has a slightly different take on it [20:35:41 CEST] <Celmor[m]> how do I use the tone map filter then? can't finde "tone" in the man page [20:35:46 CEST] <JEEB> Celmor[m]: https://www.ffmpeg.org/ffmpeg-all.html#tonemap-1 [20:35:50 CEST] <JEEB> it is there, even with an example [20:35:58 CEST] <JEEB> although yes, it requires you to build FFmpeg with the zimg library [20:36:04 CEST] <JEEB> https://github.com/sekrit-twc/zimg [20:36:31 CEST] <JEEB> that enables the zscale filter which is needed for the conversion to linear float and from BT.2020|PQ to BT.709|gamma [20:36:55 CEST] <JEEB> after that, the example listed should work [20:37:07 CEST] <cehoyos> How do I use tonemap without an external library? Or is that impossible? [20:37:25 CEST] <JEEB> I don't think anything else can convert to linear float RGB [20:37:47 CEST] <cehoyos> How was linear float acceptable...? [20:38:04 CEST] <JEEB> because the feature was needed but nobody wanted to touch swscale? [20:38:36 CEST] <JEEB> note: I don't like it, but unfortunately many people Just Use Zimg [20:38:40 CEST] <JEEB> me included :P [20:38:40 CEST] <cehoyos> No, I just saw it: It was a late try to damage the project;-) [20:38:50 CEST] <cehoyos> Too late;-) [20:39:41 CEST] <JEEB> but yea, I'd almost replace the common code for various things in swscale with zimg [20:40:03 CEST] <JEEB> it's the edge cases which only swscale will probably support (like paletted formats?) [20:40:19 CEST] <JEEB> or the general task of packing and unpacking formats [20:41:13 CEST] <cehoyos> tonemap_opencl seems to work on (nearly) "normal" pix_fmts [20:41:28 CEST] <JEEB> yea it might include the linearization there? [20:41:39 CEST] <JEEB> linearization+float [20:41:40 CEST] <cehoyos> And judging from the commit messages, it may have an additional feature [20:42:07 CEST] <JEEB> yea, niklas basically had words with him so it probably is closer to what was in mpv and libplacebo [20:42:11 CEST] <JEEB> although both probably have changed since [20:42:12 CEST] <Celmor[m]> how do you build FFmpeg with the zimg library? there's not an AUR package or similar by any chance? [20:42:32 CEST] <JEEB> Celmor[m]: probably packaged by arch I would guess? also you should check if the standard package does that? [20:42:37 CEST] <furq> does zimg still segfault if you crop a non-mod16 amount off the left hand side [20:42:47 CEST] <furq> or zscale rather [20:42:57 CEST] <JEEB> probably. zimg defines requirements for alignment [20:43:10 CEST] <furq> nice [20:43:12 CEST] <JEEB> that said, I think some internal filters will barf at that too [20:43:30 CEST] <JEEB> if you crop so that your lines no longer start aligned [20:43:57 CEST] <JEEB> because f.ex. the crop filter will attempt to not re-allocate buffers [20:43:58 CEST] <cehoyos> Yes, a warning should be printed [20:44:19 CEST] <furq> yeah that'd be nice [20:44:28 CEST] <furq> it took me longer than i'd have liked to realise i can crop,copy,zscale [20:48:23 CEST] <JEEB> let me see if there's a function or define to figure out the alignment [20:48:30 CEST] <JEEB> *required alignment [20:50:20 CEST] <JEEB> apparently if you're using 64 bit instructions it's 64, otherwise 32 [20:50:53 CEST] <JEEB> or is that byte :P [20:51:11 CEST] <JEEB> yes, bytes since AVX512 is what's discussed [20:51:15 CEST] <JEEB> 512 bits, 64 bytes [20:53:18 CEST] <Celmor[m]> I guess there's no ffmpeg with builtin z.lib packaged/ I can install z.lib itself but dunno how to build with/include it in ffmpeg [20:56:03 CEST] <cehoyos> johanvansickle indicates zimg... [20:56:18 CEST] <JEEB> make sure its .pc file is available to FFmpeg's configure and --enable-libzimg is the general gist [20:58:32 CEST] <cehoyos> The only static binary that I know of contains zimg [21:02:44 CEST] <JEEB> yea, I think he meant in arch [21:02:48 CEST] <JEEB> although I'm surprised [21:02:52 CEST] <JEEB> they usually package a lot of stuff [21:03:09 CEST] <JEEB> https://www.archlinux.org/packages/community/x86_64/zimg/ [21:03:10 CEST] <JEEB> yea [21:03:26 CEST] <JEEB> they seem to have added it for vapoursynth, which also utilizes it [21:04:29 CEST] <JEEB> so their FFmpeg isn't using it, but it's packaged alright [21:13:31 CEST] <furq> there are definitely some aur packages with zimg [21:13:36 CEST] <furq> ffmpeg-full obviously has it [21:14:17 CEST] <JEEB> aye [21:14:36 CEST] <Thomas_J> "ERROR: gnutls not found using pkg-config". I had this the last time I compiled with gnutls about 2 months ago and cant remember exactly how I fixed it. I think I linked the directory the gnutls.pc file was in to where pkg-config was looking but I can't remember where that is. I have gnutls.pc in "/usr/lib/aarch64-linux-gnu/pkgconfig/gnutls.pc" [21:15:34 CEST] <JEEB> if you're buildnig yourself, just set PKG_CONFIG_PATH=/usr/lib/YOUR_ARCH/pkgconfig/ [21:15:45 CEST] <JEEB> that appends [21:15:49 CEST] <JEEB> doesn't overwrite :) [21:16:25 CEST] <Thomas_J> That's what I've been looking for! Thanks. [21:27:54 CEST] <Thomas_J> I kinda remember now. it's gnutls looking for missing libs that aren't installed [21:28:46 CEST] <JEEB> :) [21:30:17 CEST] <Thomas_J> SUCESS! installed libunistring-dev and worked. [23:12:19 CEST] <Thomas_J> JEEB; Just a note, the ffmpeg binaries floating around in the debian repositories still haven't been updated yet to fix the problem of streaming rtmps to facebook. [23:12:52 CEST] <Thomas_J> My new compile is working. [23:13:00 CEST] <JEEB> right [23:13:23 CEST] <JEEB> I think I was trying to figure out which branches to back-port the patch and never did that [23:17:03 CEST] <Thomas_J> I am running ubuntu-server for Arm64. The version in that repo still drops the stream after connecting. [23:40:46 CEST] <cehoyos> Please do not back-port patches that do not fix a regression or a security issue. [23:48:06 CEST] <BtbN> Hm? Patches that fix bugs that aren't regressions are backported all the time. [23:59:36 CEST] <Thomas_J> I can see cehoyos' point. If someone added an update that fixed a security issue but created an issue with rtmps not working..., but is this really what happened? [00:00:00 CEST] --- Sun Sep 29 2019

1 0

ffmpeg-devel.log.20190927
by burek 28 Sep '19

28 Sep '19

[00:01:57 CEST] <Lynne> https://github.com/obsproject/obs-studio/blob/master/plugins/obs-outputs/ft… [00:02:47 CEST] <Lynne> if someone had told me that a streaming site NIH'd RTPM just so they could force disable b-frames to reduce latency and throw opus in because they could I wouldn't have believed them [00:04:48 CEST] <JEEB> Lynne: wait it's RTMP but NIH'd? [00:04:54 CEST] <JEEB> I thought it was UDP [00:05:12 CEST] <BtbN> Lynne, they didn't NIH anything. FTL is WebRTC + a few extensions. [00:10:00 CEST] <Lynne> BtbN: huh, I did see a webrtc string there but I thought an implementation had to be a lot bigger [00:11:11 CEST] <Lynne> like handle traffic flow, packet loss, bottlenecking etc. [00:11:33 CEST] <BtbN> They have a whole relatively big library to handle it, so, yeah, it's not light? [00:11:51 CEST] <JEEB> yea [00:13:16 CEST] <Lynne> BtbN: that library doesn't seem to be included or linked in obs? [00:13:30 CEST] <BtbN> iirc they use libftl? [00:13:44 CEST] <BtbN> Unless they re-implemented it by themselves? [00:14:30 CEST] <nevcairiel> they have the official ftl sdk as a git module linked in there, so yeah. [00:14:33 CEST] <Lynne> right, I just saw that [00:19:34 CEST] <Lynne> how bad do things have to be to extend webrtc to get lower latency than HLS? [00:20:11 CEST] <BtbN> HLS without hacks has 10+ seconds of delay at the very least [00:20:24 CEST] <BtbN> Also, this is the _ingest_ protocol [00:20:33 CEST] <BtbN> I don't think the Websites Player uses WebRTC [00:20:44 CEST] <nevcairiel> the player is HLS [00:21:05 CEST] <nevcairiel> HLS cant ingest [00:22:55 CEST] <Lynne> if its only on the streamer->server side isn't it pointless? it shouldn't have latency advantages over rtmp [00:23:17 CEST] <JEEB> rtmp is maintained by adobe who no longer maintain it [00:23:34 CEST] <JEEB> fragmented MP4 over HTTP or TCP or whatever, or something UDP is where it should be going [00:30:58 CEST] <Illya> anyone have some MPEG-TS samples with PSIP data? [01:05:33 CEST] <tmm1> Illya: yea i have some, are you looking for atsc or dvb? [01:11:34 CEST] <Illya> tmm1: atsc (isn't PSIP an atsc only thing?) [01:22:12 CEST] <tmm1> hm yea i guess the DVB tables are not called psip [01:23:05 CEST] <tmm1> looks like i have mostly dvb eit samples [01:23:49 CEST] <tmm1> the psip stuff is a PITA because you have to figure out the pids to listen on first (vs fixed 0x12 for all eit data on dvb) [01:24:34 CEST] <Illya> those samples might be useful for what I'm doing anyway [01:33:08 CEST] <tmm1> Illya: https://tmm1.s3.amazonaws.com/dvb-eit/cze-eit.mpg [01:33:48 CEST] <tmm1> at the same path: uk-eit-{hd,sd}.ts israel-{dvbt,dvt2-hd,dvbt2-sd}.ts [01:35:54 CEST] <tmm1> also france-eit.ts [01:35:56 CEST] <Illya> israel-*.ts seems to 403 but I got the rest [01:36:56 CEST] <tmm1> try now [01:37:03 CEST] <tmm1> https://tmm1.s3.amazonaws.com/dvb-eit/israel-dvbt.ts [01:37:16 CEST] <tmm1> i have one from greece also but its a bigger sample with video included [01:37:18 CEST] <Illya> Nice thanks got all of them. This should be enough [01:37:50 CEST] <Illya> Just doing titles from EIT for now [01:39:27 CEST] <tmm1> decoding the text can be tricky, there is some custom charset used which some (but not all) builds of iconv can decode [01:39:30 CEST] <Illya> actually I'll do descriptors as well, I guess what I meant is no ETT for now [01:39:41 CEST] <Illya> tmm1: funnily enough that's why I'm doing this [01:39:43 CEST] <tmm1> also the uk hd samples use some sort of huffman encoding to scramble the text [01:40:10 CEST] <tmm1> ah then you probably want the greek one too [01:41:19 CEST] <Illya> is the custom charset you're thinking of aribb24 because I have a WIP module for it (works with all standard builds of iconv) [01:41:51 CEST] <tmm1> https://tmm1.s3.amazonaws.com/dvb-eit/greece.ts [01:42:02 CEST] <Illya> or are there others I need to worry about as well? (I assumed most other things are just UTF-8) [01:42:07 CEST] <tmm1> no, that one is used in japan or something right [01:42:27 CEST] <Illya> yes [01:42:54 CEST] <tmm1> its been a few years let me look up what i'm thinking of [01:44:11 CEST] <tmm1> unfortunately almost none of them use utf8, its all iso8859 variants and there's a charset identifier in the eit tables that tells you how to decode [01:44:57 CEST] <tmm1> libdvbpsi does a good job with the tables, then you can use i_iso_639_code field to figure out how to decode the text [01:45:37 CEST] <Illya> most of those should be convertable with iconv though I'd imagine [01:50:06 CEST] <tmm1> https://lists.gnu.org/archive/html/bug-gnu-libiconv/2009-09/msg00002.html [01:51:04 CEST] <tmm1> this is what i was recalling.. vlc had to add ISO6937 itself because glibc iconv didn't have it (but libiconv does?) [01:56:00 CEST] <Illya> Hmm. Should I just be using libdvbpsi rather than writing EIT decoding myself? Not sure it'll be good to depend on libdvbpsi here for this simple functionality [01:57:26 CEST] <tmm1> not sure what're you doing.. there was a bit EIT decoding patchset on the mailing list recently too [01:57:31 CEST] <Illya> also interesting on the iconv issue, we might have to do the same as VLC for this (have an iconv wrapper) [01:58:17 CEST] <Illya> All I want to do is extract titles and descriptors from EIT [01:58:38 CEST] <tmm1> "DVB EPG decoder" [02:00:21 CEST] <tmm1> i think some of the patches were merged actually [02:00:33 CEST] <tmm1> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247789.html [02:00:36 CEST] <tmm1> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248692.html [02:02:13 CEST] <Illya> decoder is the misleading here I think, it just dumps the EIT with the wrong name [02:04:13 CEST] <Illya> anyway what I want to do with the EIT isn't so complex, I'll do a patch tomorrow or on the weekend and see what people think (maybe it's not useful), then work on aribb24 again. [02:06:27 CEST] <tmm1> extracting titles into AVProgram sounds like a great idea [02:06:56 CEST] <tmm1> should be fairly straightforward, i don't think you need all of libdvbpsi for that [02:08:14 CEST] <Illya> yeah was my thinking, and as marton said on the ML, complex supplementary information stuff (i.e. using libdvbpsi internally) isnt really within scope of the libraries [11:06:50 CEST] <cone-361> ffmpeg 03Limin Wang 07master:b9d479bac45b: avfilter/vf_scale: cosmetics [11:06:50 CEST] <cone-361> ffmpeg 03Limin Wang 07master:cde1d70a39ad: swscale/swscale: cosmetics [12:06:30 CEST] <BtbN> I'm a bit confused regarding the new max reference frame option there in nvenc. [12:06:47 CEST] <BtbN> maxNumRefFrames already existed, documented as "Specifies the DPB size used for encoding." [12:07:14 CEST] <JEEB> vOv [12:07:19 CEST] <BtbN> Now there is numRefL0 and numRefL1, saying "Specifies max number of reference frames in reference picture list L0/L1, that can be used by hardware for prediction of a frame." [12:07:44 CEST] <nevcairiel> technically you can have a difference between overall number of kept ref frames, and number of frames used per-frame from said list [12:08:49 CEST] <nevcairiel> hevc specifically drives that point home even more, since the DPB allows 16 frames, but per-frame you can only use 8 at most (IIRC) [12:09:21 CEST] <JEEB> yea [12:09:31 CEST] <JEEB> that was an interesting difference to AVC [12:10:04 CEST] <BtbN> hm, so it makes sense to have two separate options for it. But it makes me feel like avctx->refs would have matched better for the new option that was added, but now it's already tied to the DPB size [12:10:06 CEST] <JEEB> I guess it makes sense since you can keep more refs in your DPB, but usually you don't need so many per coded frame [12:16:00 CEST] <cone-361> ffmpeg 03Paul B Mahol 07master:044167a171d5: avformat/nut: add pcm_s64 support [12:45:11 CEST] <cone-361> ffmpeg 03Paul B Mahol 07master:35a12d2071ef: avformat/g729dec: set packet duration and correctly set timebase info [13:48:03 CEST] <cehoyos> BBB: Am I completely wrong? Or does the new RGB10 format actually help anybody? [13:48:14 CEST] <cehoyos> s/does/would [13:48:17 CEST] <BBB> let me have a look [13:48:37 CEST] <BBB> the intel format? [13:48:40 CEST] <BBB> a2rgb10 [13:48:41 CEST] <BBB> ? [13:48:58 CEST] <cehoyos> Nobody else comments, so it is unclear for me if I just write what everybody thinks or if it is exactly the other way round. [13:49:05 CEST] <cehoyos> Yes, A2R10G10B10 [13:49:18 CEST] <BBB> it seems like a hw thing to me [13:49:23 CEST] <BBB> that doesn't mean yes or no [13:49:40 CEST] <BBB> it just means that we're unlikely to ever see it be used in the more classic ffmpeg libs, like swscale or avcodec [13:49:44 CEST] <cehoyos> It seems to me that this pix_fmt is only added to be able to connect to vaapi filters with each other [13:49:48 CEST] <BBB> yes [13:49:50 CEST] <BBB> exactly [13:50:08 CEST] <BBB> it's a problem in our design that components can't connect using self-defined pixfmts [13:50:13 CEST] <cehoyos> Well, one thing is for sure: If the format will be added, then only if swscale (also) supports it. [13:50:18 CEST] <BBB> in gstreamer, you can have private pixfmts (sort of) [13:50:27 CEST] <BBB> i think that's a reasonable request [13:50:34 CEST] <cehoyos> But what is wrong with having the filter output GBRP10, so that other use cases will be supported? [13:50:42 CEST] <BBB> it requires conversion [13:50:51 CEST] <BBB> which is exactly what you're trying to not do with hw pipelines [13:51:02 CEST] <cehoyos> It always requires conversion because nothing in FFmpeg suport RGB10 [13:51:07 CEST] <Lynne> cehoyos: you misunderstand what the format is for and its use, but feel free to ignore me, after all who am I? [13:51:17 CEST] <BBB> right, but what if the whole app is using hwaccel? [13:51:18 CEST] <cehoyos> Correct;-) [13:51:36 CEST] <BBB> i agree that you need conversion to go in from avcodec [13:51:44 CEST] <cehoyos> But why can't the hw support GBRP10, aren't they controlling the drivers? [13:51:47 CEST] <BBB> but from then on, all intel hw components can use their internal private format [13:51:50 CEST] <BBB> which is great for intel [13:51:57 CEST] <BBB> (...) [13:51:58 CEST] <cehoyos> Or is my assumption that the hw could do it if they want it, simply wrong [13:52:03 CEST] <BBB> but yes, swscale conversion would be great [13:52:14 CEST] <BBB> i don't think hw can do tht for free [13:52:16 CEST] <cehoyos> That sounds like an even stronger reason to reject the patch, no? [13:52:26 CEST] <BBB> it's like asking x264 to input ... say, yuyv [13:52:27 CEST] <cehoyos> Not even for nearly free? [13:52:36 CEST] <BBB> i don't think so, i think it'd require actual effort [13:52:51 CEST] <cehoyos> As in: gpu time or developer time? [13:52:55 CEST] <BBB> it's cheaper than sw conversion, sure [13:53:02 CEST] <BBB> but it requires electricity, yes [13:53:05 CEST] <BBB> power [13:53:08 CEST] <cehoyos> ok [13:53:16 CEST] <BBB> so i think they'd like to prevent it if they can [13:53:20 CEST] <BBB> this is all built for scale [13:53:29 CEST] <BBB> but yes, swscale conversion is a must, i agree [13:53:36 CEST] <BBB> other than that i see no big issue [13:53:39 CEST] <BBB> it's quirky, yes [13:53:44 CEST] <BBB> but lots of hw things are quirky [13:54:20 CEST] <cehoyos> My suggestion was to add the conversion in the filter to avoid a format that has no other use case but if that's not true, the conversion if of course a solution. [13:56:25 CEST] <BBB> yeah i think it's ok... it obviously relies on people doing lots of hw filter chainings [13:56:33 CEST] <BBB> i don't know if that's a thing that's likely to happen [13:56:40 CEST] <BBB> but that's obviously what they're going for here [13:56:51 CEST] <BBB> (and then show minimal power consumption: see, hw is better than sw!!!112) [13:57:23 CEST] <BBB> i certainly agree with you that having an incompatible hdr pipeline for intel hw vs. the rest of ffmpeg is illogical [13:57:29 CEST] <BBB> we need to be able to convert from one to the other [13:57:38 CEST] <BBB> otherwise it's meaningless and we become just another corporate middleware [13:57:42 CEST] <BBB> screw that [13:58:14 CEST] <BBB> but there will likely be hw filters that only exist in hw and for which no sw alternative exists... not conversion, but certain types of specialized filters [13:58:21 CEST] <BBB> that's unfortunate, but i dont know how to solve it :( [14:02:03 CEST] <BtbN> Hardware works very different from software, and they often use weird pixel formats. [14:02:26 CEST] <BtbN> nvenc and cuvid have such conversion to more standard pixel formarts built in, but it does cost some performance, because it does convert back and forth in a shader [14:02:32 CEST] <BtbN> The native nvidia pixel format is tiled [14:02:41 CEST] <BtbN> And I'd expect it to be something similar for Intel [14:11:49 CEST] <durandal_1707> someone pushed invalid code about not ignoring invalid index in lavf [14:12:06 CEST] <durandal_1707> please REVERT IMMEDIATELY!!!!!!! [14:13:47 CEST] <cehoyos> Thank you! [14:26:19 CEST] <durandal_1707> forcing demuxer to always return packets with valid index is not friendly [14:26:41 CEST] <cone-361> ffmpeg 03Paul B Mahol 07master:bb697f30ab28: avformat/dhav: fix demuxer since recent breakage [14:28:37 CEST] <BtbN> cehoyos, I can't really think of any sane way to add a compatiblity shim for this. Using avctx->refs for the new option would be in line with how libx264 uses it though, and with what most users most likely expect. So I'm not too opposed to breaking it. [14:28:54 CEST] <BtbN> The only issue is, setting that option on older drivers and pre-turing cards will cause a failure. [14:29:16 CEST] <cehoyos> I really believe that we are (sometimes) using the "api" argument in the wrong way. [14:29:29 CEST] <cehoyos> I can only comment that: [14:29:31 CEST] <BtbN> Well, the ffmpeg cli arguments are also an API [14:29:39 CEST] <cehoyos> Not everybody has a turing card and (but) [14:29:58 CEST] <cehoyos> The options that work for x264 encoding with ffmpeg should also map to other encoders if possible [14:30:11 CEST] <BtbN> Yes, exactly why I think that breaking existing scripts with this change is not ideal [14:30:35 CEST] <cehoyos> I mean: We broke "api" in the past arguing it was not api (or other explanations), we should really brake it to increase usability [14:30:50 CEST] <cehoyos> Why does it not work on older infrastructure [14:30:51 CEST] <cehoyos> ? [14:30:57 CEST] <BtbN> x264 also has the equivalent of the what nvenc currently uses the -refs option for, "i_dpb_size". But libx264.c does not appear to set it [14:31:19 CEST] <BtbN> Because the option is not supported on pre-Turing, and setting it to anything but 0 there will cause nvenc init to fail [14:31:20 CEST] <cehoyos> Doesn't this indicate that it simply doesn't have to be set? [14:31:29 CEST] <cehoyos> if turing - else - ? [14:31:39 CEST] <BtbN> There is no sensible way to determine that from nvenc.c [14:31:49 CEST] <cehoyos> if (ret<0) ? [14:32:10 CEST] <BtbN> Well, the entire initialization will fail. It's not a single call to set just that parameter. [14:32:20 CEST] <cehoyos> Or does the driver assert on valid options? ;-) [14:33:00 CEST] <cehoyos> How does it work with the suggested patch applied for old hardware? [14:33:15 CEST] <BtbN> If you set the new option and have old hardware, init will fail. [14:33:22 CEST] <cehoyos> Wow [14:33:25 CEST] <BtbN> But existing commandline won't change behaviour. [14:33:33 CEST] <BtbN> There is a ton of options in nvenc that work like that. [14:34:01 CEST] <cehoyos> This sounds broken to me but if existing command lines fail users can easily adapt, no? [14:34:22 CEST] <BtbN> Generally, the new option is MUCH closer to what a user would expect -refs to do [14:34:34 CEST] <BtbN> The very limited hardware and driver support is unfortunate [14:34:36 CEST] <cehoyos> Then change it imo, but ask on the mailing list... [14:34:59 CEST] <BtbN> The old option is equivalent to x264 i_dpb_size: https://github.com/mirror/x264/blob/d4099dd4c722f52c4f3c14575d7d39eb8fadb97… [14:35:06 CEST] <BtbN> which ffmpeg does not even care to implement [14:39:25 CEST] <cehoyos> Which imo indicates that the option is not super-useful (but who knows) [14:39:52 CEST] <cehoyos> The logger missed the creation of the ticket but not my edit? [14:40:46 CEST] <BtbN> It's an option primarily used in interactive encoding sessions, where the player can signal the encoder that it didn't receive a certain frame, and the encoder can then react and exclude that frame from being used as a reference. [14:41:00 CEST] <BtbN> So, exposing it via the ffmpeg cli ist mostly useless [14:42:07 CEST] <BtbN> I also wonder what caused them to use an enum for this... http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=blob;f=include/ffn… [15:39:54 CEST] <cone-361> ffmpeg 03James Almer 07master:f96a8b015f2f: avcodec/mpeg4audio: add avpriv_mpeg4audio_get_config2() [15:39:55 CEST] <cone-361> ffmpeg 03James Almer 07master:d582cc17e1f6: avcodec: use avpriv_mpeg4audio_get_config2() [15:39:56 CEST] <cone-361> ffmpeg 03James Almer 07master:35bbaa665246: avformat: use avpriv_mpeg4audio_get_config2() [15:51:24 CEST] <cone-361> ffmpeg 03James Almer 07master:75c7484fcb18: avcodec/mpeg4audio: fix doxy for ff_mpeg4audio_get_config_gb() [15:51:25 CEST] <cone-361> ffmpeg 03Jun Zhao 07master:333109f46961: lavc/mpeg4audio: add chan_config check to avoid indeterminate channels [16:49:27 CEST] <durandal_1707> libavcodec/utils.c:1437:42: warning: adding 'unsigned long' to a string does not append to the string [-Wstring-plus-int] [16:49:30 CEST] <durandal_1707> return LICENSE_PREFIX FFMPEG_LICENSE + sizeof(LICENSE_PREFIX) - 1; [16:49:32 CEST] <durandal_1707> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~ [16:49:35 CEST] <durandal_1707> libavcodec/utils.c:1437:42: note: use array indexing to silence this warning [16:49:38 CEST] <durandal_1707> return LICENSE_PREFIX FFMPEG_LICENSE + sizeof(LICENSE_PREFIX) - 1; [16:49:40 CEST] <durandal_1707> ^ [16:49:43 CEST] <durandal_1707> & [ ] [16:50:25 CEST] <mkver> One would have to use array indexing to silence this warning: [16:52:35 CEST] <mkver> return &(LICENSE_PREFIX FFMPEG_LICENSE)[sizeof(LICENSE_PREFIX) - 1]; [16:53:13 CEST] <mkver> The parentheses are unnecessary if I am not mistaken, but they won't hurt. [16:58:31 CEST] <cehoyos> Aahh [17:48:17 CEST] <BtbN> Does anyone know what the correct restrictions of blurays are? The bluray_compat option of nvenc clamps avctx->refs to 0-6. Does it actually mean the dpb_size, or the number of references per frame? [17:50:40 CEST] <BtbN> ok, it's dpb_size: https://github.com/mirror/x264/blob/master/encoder/encoder.c#L997 [17:53:44 CEST] <cone-177> ffmpeg 03Zhong Li 07master:0686651aab1d: lavu/qsv: remove redundant version query [17:59:53 CEST] <taliho> is the AV_OPT_FLAG_EXPORT flag used for anything? [18:00:01 CEST] <taliho> I can't see it used anywhere except for writing the value of the flag in opt.c:1217 [18:01:59 CEST] <taliho> reason I'm asking is that I'd like to make ts_packetsize in mpegts.c a user settable parameter [18:02:26 CEST] <mkver> git grep says it is used un libavformat/http.c and libavformat/flvdec.c [18:02:44 CEST] <taliho> at the moment it's AV_OPT_FLAG_EXPORT | AV_OPT_FLAG_READONLY are set [18:07:41 CEST] <taliho> mkver: that's true, the flag is set there [18:08:11 CEST] <taliho> I'm trying to find how the flag is used something like flag & AV_OPT_FLAG_EXPORT [18:47:02 CEST] <cehoyos> What is "hdv"? [18:47:05 CEST] <cehoyos> Ticket 8295 [18:47:11 CEST] <cehoyos> Ticket 8205 [18:48:00 CEST] <gnafu> Does it relate to this? --> https://en.wikipedia.org/wiki/HDV [18:48:07 CEST] <nevcairiel> the guy obviously has no idea what he is talking about [18:48:26 CEST] <nevcairiel> throwing around marketing names instead of actual technical formats [18:48:55 CEST] <nevcairiel> basically all he mentions are mpeg2 transport stream variants [18:51:11 CEST] <cehoyos> It's also possible that he knows but does not speak English... [18:52:05 CEST] <durandal_1707> nope, just close stupid tickets [18:54:51 CEST] <cehoyos> gnafu: Thank you, a sample is in 6271 [19:00:17 CEST] <nevcairiel> you dont need to know english to know the difference between "mpeg2 transport stream" and "bluray" [19:13:55 CEST] <BtbN> Can anyone think of a situation that intentionally makes an nvenc function fail? I want to test the new GetLastError function, but everything that comes to mind is caught ahead of time. [19:15:11 CEST] <jamrial> BtbN: arguments outside the option's internall allowed range? [19:15:27 CEST] <BtbN> Those are all caught by capability checks [19:15:46 CEST] <BtbN> At least the ones that actually would cause a failure [19:17:04 CEST] <BtbN> I don't understand what Sami32 is asking at all. [19:17:28 CEST] <nevcairiel> I don't think he does [19:18:11 CEST] <BtbN> I'm just gonna throw ridiculous options at it until it gives up [19:20:02 CEST] <BtbN> yep, works. Told it to encode a 1080p stream with level 1.3: [h264_nvenc @ 000000000c1e0540] InitializeEncoder failed: invalid param (8): Invalid Level. [19:54:58 CEST] <cone-177> ffmpeg 03Ross Nicholson 07master:460f74495fa9: libavformat/rtsp: return error if rtsp_hd_out is null instead of crash [19:55:26 CEST] <j-b> Who cared about the decklink headers license? Was it you, BtbN ? [19:56:41 CEST] <BtbN> I cared about getting newer headers to build for coverity, but I'm not overly concearned with the license otherwise. [19:59:49 CEST] <j-b> Do you remember who did? [19:59:54 CEST] <j-b> kierank: ^^? [20:00:10 CEST] <kierank> carl i think [20:00:16 CEST] <kierank> it's the mismatch between the eula and the headers [20:00:18 CEST] <j-b> besides carl [20:00:18 CEST] <kierank> and which takes priority [20:00:20 CEST] <kierank> that old chestnut [20:00:27 CEST] <j-b> Yes, I think I fixed that during IBC. [20:01:22 CEST] <kierank> j-b: how did you fix it? [20:01:42 CEST] <j-b> kierank: by screaming on their booth, until the general dev relation manager came. [20:01:50 CEST] <kierank> I have asked them before to change it [20:01:52 CEST] <kierank> years ago [20:01:54 CEST] <kierank> but they didn't [20:02:13 CEST] <j-b> I got the email now, where they "want to fix this issue" [20:03:47 CEST] <cone-177> ffmpeg 03Timo Rothenpieler 07master:e929b2f248a9: avcodec/nvenc: switch to dedicated dpb_size option [20:03:48 CEST] <cone-177> ffmpeg 03Roman Arzumanyan 07master:567b5e33d9d7: avcodec/nvenc: add multiple reference frames support [20:03:49 CEST] <cone-177> ffmpeg 03Timo Rothenpieler 07master:51a23343d9c7: avcodec/nvenc: pass CUstream to nvenc when available [20:03:50 CEST] <cone-177> ffmpeg 03Timo Rothenpieler 07master:ab0ef1abdf53: avcodec/nvenc: make use of new GetLastErrorString function [20:06:04 CEST] <cehoyos> Regarding the decklink headers: It was a misunderstanding / mistake to ever mention the headers. The library that exchanges data structures with FFmpeg is non-free and not gpl-compatible. [20:07:36 CEST] <j-b> Nope, they have a driver and the library to talk to the driver is fully free now. [20:07:42 CEST] <j-b> or at least at the next release. [20:08:38 CEST] <cehoyos> I don't think we should declare a closed-source driver for an additional hardware gpl-compatible, especially since it appears FFmpeg developers are more strict now than they were in the past. [20:08:39 CEST] <BradleyS> i guess the question is whether various members of the open source community will forgive the old sins and let them back in [20:08:42 CEST] <BradleyS> or demand restitution [20:09:08 CEST] <j-b> drivers are part of the OS [20:09:27 CEST] <cehoyos> Yes, graphic card and network drivers [20:09:33 CEST] <j-b> else, you don't have nvdec, vdpau, or any hardware, besides vaapi [20:09:47 CEST] <j-b> decklink is like a graphic card [20:10:07 CEST] <cehoyos> FFmpeg developers argue that graphic card drivers are system drivers, the drivers for an additional card like a Matrox encoding card are not system drivers [20:10:11 CEST] <BradleyS> it's an hardware peripheral, the licenses make no distinction between graphic cards and other pcie cards [20:10:32 CEST] <kierank> in fact the api for hdmi is much better than anything linux provides [20:10:37 CEST] <BradleyS> they should back that up with the text of the license then [20:10:56 CEST] <j-b> yeah, I've never seen anyone argue that some drivers are not system drivers [20:10:56 CEST] <cehoyos> The gpl makes a distinction between system drivers that normally come with a system and other software, the Matrox and decklink drivers are not system drivers. [20:11:45 CEST] <JEEB> I don't remember exactly but at least for me the Matrox was mostly going off the scale regarding "general usefulness compared code added", not "it's not hardware" [20:12:20 CEST] <cehoyos> Sorry, but this is a horrible argument wrt FFmpeg, we support (even for writing) all kind of "useless" formats (and I am very happy about it) [20:12:27 CEST] <cehoyos> But the Matrox is certainly not a system driver [20:12:34 CEST] <cehoyos> Neither the decklink driver [20:15:59 CEST] <BradleyS> my understanding is kernel modules distributed in binary form do not need to be gpl compatible as long as they use the kernel through a well-defined interface and are not part of the kernel (compiled in) [20:16:14 CEST] <cehoyos> Your understanding of the opinion of the FFmpeg developers? [20:16:45 CEST] <BradleyS> my understanding of the current norm in linux device driver development as encouraged by linus and so far unchallenged in court [20:17:38 CEST] <BradleyS> i'm not saying i agree with it ethically, just saying many binary device drivers are distributed this way and most people except the hardliners are fine with it [20:18:23 CEST] <BradleyS> to say that some drivers are different than others based on their application, as opposed to how they are loaded by / access the kernel, seems unsubstantiated by the license [20:18:26 CEST] <cehoyos> Can you point me to the repository of the decklink driver? [20:18:51 CEST] <cehoyos> You mean unsubstantiated by the word "system drivers"? I tend to disagree. [20:19:51 CEST] <cehoyos> Or to say it differently: You claim that the Decklink developers have found a way to circumvent the incompatibility of their driver with the gpl and we should honor this achievement? [20:20:42 CEST] <BradleyS> i don't think anyone is suggesting honoring their work in this regard [20:21:18 CEST] <BradleyS> i for one am merely suggesting that if they're distributing a driver as a binary kernel module, by most current definitions that does not demand gpl compliance [20:21:29 CEST] <BradleyS> of course there is great debate on this still [20:21:33 CEST] <cehoyos> Nobody claimed that (afaict) [20:21:56 CEST] <BradleyS> [14:07:36] @j-b: Nope, they have a driver and the library to talk to the driver is fully free now. [20:22:18 CEST] <BradleyS> this would seem to be a binary kernel module and an open source library to talk to it [20:22:27 CEST] <j-b> yes, that is my understanding [20:22:30 CEST] <j-b> and that is NEW. [20:22:35 CEST] <cehoyos> Can you point me to the repository of the decklink driver? [20:23:29 CEST] <j-b> BradleyS: it is installed through DKMS, like all the other drivers. [20:23:49 CEST] <j-b> and loaded with modprobe [20:24:00 CEST] <BradleyS> thanks for clarifying, then it would indeed seem to at least align with the majority case in the wild [22:12:52 CEST] <cone-177> ffmpeg 03Lou Logan 07master:419e5e794285: doc/ffmpeg: -timelimit is in user time [22:29:37 CEST] <Lynne> durandal_1707: "There is not such function." -> vector_fmac_scalar(dst, src, 1.0, len) [22:31:39 CEST] <durandal_1707> Lynne: that is inefficient [22:32:23 CEST] <Lynne> it isn't, but feel free to just ignore me like everyone else [22:33:41 CEST] <durandal_1707> Lynne: lol, i will bench it, but it can be used almost anywhere [22:34:06 CEST] <durandal_1707> and adding LOCAL ALIGNED macros hurts my brain cells [23:09:15 CEST] <durandal_1707> Lynne: most of time is lost in compute_gru [23:30:17 CEST] <cehoyos> durandal_1707: What is wrong with ticket 6939? [23:32:14 CEST] <durandal_1707> cehoyos: --patch is unrecognized [23:32:19 CEST] <durandal_1707> *path [23:33:22 CEST] <cehoyos> true, should be fixed [23:47:53 CEST] <durandal_1707> cehoyos: what should be fixed? [00:00:00 CEST] --- Sat Sep 28 2019

1 0

ffmpeg.log.20190927
by burek 28 Sep '19

28 Sep '19

[11:07:26 CEST] <billybob> i am trying to use ffmpeg to fix a corrupted avi. When opening this file in a hex editor it has millions of 0's at the start and when running the standard input output command with ffmpeg it returns "invalid data found when processing input" [17:38:40 CEST] <horribleprogram> before I explode my computer [17:39:12 CEST] <horribleprogram> I want to write a script that changes every .mp4 in the current directory's TAG:title metadata to its filename [17:39:23 CEST] <horribleprogram> I don't even think I need a script, just a simple for loop [17:43:01 CEST] <horribleprogram> so there's no way to edit metadata without having to process the file and "reencode" it or w/e [17:43:13 CEST] <horribleprogram> I literally just need to change the goddamn TAG:title value [17:44:14 CEST] <horribleprogram> for title in *; do ffmpeg -i "$title" -metadata title="$title" [17:44:14 CEST] <kepstin> horribleprogram: there might be mp4 specific tools that can do that, but ffmpeg is not a tool designed for in-place file metadata editing. [17:44:29 CEST] <horribleprogram> kepstin: is there a bypass or something/ [17:44:55 CEST] <horribleprogram> I read something about "copy mode' [17:45:04 CEST] <horribleprogram> I'm not entirely sure what that is tho [17:45:12 CEST] <kepstin> horribleprogram: "-c copy", yeah [17:45:24 CEST] <horribleprogram> iight what's that do [17:45:55 CEST] <kepstin> that causes ffmpeg to copy the already encoded media from the old file to the new file, instead of doing a cpu-intensive encode to the selected output codec. [17:47:11 CEST] <horribleprogram> so would that speed up what I want [17:47:17 CEST] <horribleprogram> I'm processing about 40GB of .mp4s [17:47:39 CEST] <kepstin> yes, it would speed it up. It should in theory be almost as fast as copying the file with cp. [17:47:52 CEST] <horribleprogram> for title in *; do ffmpeg -i "$title" -metadata title="$title" -c copy "$title" [17:47:57 CEST] <kepstin> (reminder that you should never use the same filename for input file and output file with ffmpeg - it truncates the output file at the start of writing, which will delete the contents file that it's trying to read from) [17:48:09 CEST] <horribleprogram> FuCK [17:48:18 CEST] <DHE> oh dear [17:48:52 CEST] <horribleprogram> that's why the one I tested it on doesn't work anymore [17:49:28 CEST] <kepstin> ffmpeg is an encoding tool, not a metadata editing tool. It just happens to be able to change metadata in a file as a result of transcoding/remuxing it to a new file. [18:00:12 CEST] <void09> trying to test the just release svt-av1 v0.7, using their sample encoding line with ffmpeg: ffmpeg -i [input.mp4] -nostdin -f rawvideo -pix_fmt yuv420p - | ./SvtAv1EncApp -i stdin -n [number_of_frames_to_encode] -w [width] -h [height] [18:00:30 CEST] <void09> ffmpeg -i $movie -nostdin -f rawvideo -pix_fmt yuv420p - | ./SvtAv1EncApp -i stdin -n 792 -w 1920 -h 1080 -enc-mode 8 -q 25 -rc 0 -b out.ivf [18:00:36 CEST] <void09> that's the line I run [18:01:02 CEST] <void09> https://0bin.net/paste/r6C0jbMkZI+xjT5R#1+QULBY9aA3SMcz5te547-+VuJZKaTcfSHJ… [18:01:07 CEST] <void09> getting broken pipe error. any idea? [18:26:26 CEST] <void09> nvm, i am retarded [18:34:24 CEST] <horribleprogram> anything wrong with this before I start [18:34:48 CEST] <horribleprogram> for file in *; do ffmpeg -i "$file" -metadata title="$file" -c copy "${title%.mp4}-converted.mp4" [18:34:51 CEST] <horribleprogram> done [18:36:46 CEST] <furq> you probably want -map 0 -movflags faststart [18:37:01 CEST] <furq> you probably also want *.mp4 [18:38:07 CEST] <horribleprogram> set_running_app:printf:1: %.m: invalid directive [18:38:10 CEST] <horribleprogram> furq: ^ [18:38:50 CEST] <furq> i have no idea what that is [18:39:20 CEST] <bencoh> 59 [18:39:27 CEST] <bencoh> (woops. hello there) [18:39:34 CEST] <pink_mist> probably from ${title%.mp4} ... but it's a bash issue, not an ffmpeg issue [18:39:42 CEST] <furq> apparently that's a zsh thing [18:39:44 CEST] <DHE> that is definitely an xkcd #1084 right there [18:39:46 CEST] <pink_mist> oh, zsh [18:39:47 CEST] <furq> i wouldn't know how to fix that [18:39:50 CEST] <pink_mist> same thing [18:39:56 CEST] <pink_mist> not related to ffmpeg either way [18:40:28 CEST] <furq> it's not quite the same thing because that substition would work fine in bash [18:40:30 CEST] <horribleprogram> yeah figured [18:40:35 CEST] <furq> ut [18:41:03 CEST] <furq> fwiw i might use a dedicated mp4 muxer for this to avoid rewriting the whole file for faststart [18:41:12 CEST] <furq> but l-smash isn't packaged anywhere so that would involve building it yourself [18:41:26 CEST] <pink_mist> what's l-smash? [18:41:29 CEST] <furq> an mp4 muxer [18:42:16 CEST] <bencoh> yay, a japanese project main page :) [18:42:23 CEST] <furq> lol [18:42:30 CEST] <furq> ffmpeg will do it fine anyway [18:42:31 CEST] <pink_mist> https://repology.org/project/l-smash/versions <-- it looks to be packaged in plenty of places, furq =) [18:42:33 CEST] <furq> it'll just be a bit slower [20:11:00 CEST] <lyncher> hi. is it possible to convert SRT subtitles to dvd_subitles/dvb_subtitles with ffmpeg? [20:12:39 CEST] <JEEB> with the API, yes [20:12:43 CEST] <JEEB> with the ffmpeg.c client, no [20:13:17 CEST] <JEEB> basically we have code to have libass render the text [20:13:18 CEST] <JEEB> but [20:13:21 CEST] <cehoyos> How do convert them with the api? [20:13:24 CEST] <cehoyos> you [20:13:58 CEST] <JEEB> yes, I did notice the issue too late :P [20:14:22 CEST] <JEEB> the whole AVSubtitle (text) into image (which could be done with the subtitle filter but that takes in something different entirely) [20:14:41 CEST] <cehoyos> I am not convinced that works without major additional code. [20:14:43 CEST] <JEEB> so you'd have to have something like ffmpeg.c's sub2video except text to image, and then make an AVSubtitle out of it [20:15:14 CEST] <JEEB> so yes, sorry - I think I just stretched the definition of "with the API" :P [20:15:48 CEST] <cehoyos> ok, then I understand, I just don't think there is a filter you can use that outputs something that the dvbsub/dvdsub encoders accept. [20:16:11 CEST] <JEEB> yes, filters would output AVFrames, buut then you find yourself having to convert that back to AVSubtitle [20:16:28 CEST] <JEEB> hysterical raisins galore [20:16:29 CEST] <JEEB> :) [20:20:56 CEST] <cehoyos> But now that you mention it, it appears that once libavfilter learns what subtitles are, this could be a trivial task;-( [20:21:23 CEST] <JEEB> yes, you could have filters going one way or another [20:21:31 CEST] <JEEB> OCR and "render this onto canvas" [20:21:44 CEST] <JEEB> which we now already have, but have fun plugging them in ^_^ [20:22:08 CEST] <JEEB> OCR you can feed to, but I'm not sure if you can nicely receive the text samples [20:22:24 CEST] <JEEB> you have AVFrames with attached text I think [20:24:02 CEST] <JEEB> ("you can feed to" mostly meaning the sub2video thing in ffmpeg.c) [20:29:50 CEST] <durandal_1707> see ocr filter [20:31:51 CEST] <JEEB> yes I mentioned it :) [21:12:35 CEST] <ThugAim> so much stuff of FF I need to learn. Is there like a tutorial base that I can experiment weekly with? [21:14:13 CEST] <JEEB> there are examples under doc/examples in the code base [21:14:17 CEST] <JEEB> it really depends on what you want to do [21:14:46 CEST] <JEEB> then one good source of reading docs is to search for site:ffmpeg.org doxygen trunk KEYWORD [21:15:12 CEST] <JEEB> which leads you to such things as https://lists.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [21:15:32 CEST] <JEEB> (this is all generated from the source code of course, but sometimes I am lazy) [21:15:41 CEST] <JEEB> or do you mean the command line application? [21:15:57 CEST] <JEEB> for that search for ffmpeg-all.html and possibly look at some things in the trac wiki [21:16:01 CEST] <ThugAim> I'm in broadcasting and setup scripts to batch convert, move, adjust audio for received files that aren't to standard. [21:16:09 CEST] <ThugAim> I just feel there's much more I can do with it. [00:00:00 CEST] --- Sat Sep 28 2019

1 0

ffmpeg-devel.log.20190926
by burek 27 Sep '19

27 Sep '19

[00:30:32 CEST] <cehoyos> jamrial: I cannot fix this, the condition is simply wrong (but claims to fix an overread), I will revert the patch (that is definitely correct) unless you have a better suggestion [00:30:46 CEST] <cehoyos> 89f464e9c229006e16f6bb5403c5529fdd0a9edd [00:33:48 CEST] <jamrial> cehoyos: i have no better suggestion. even if that patch is correct, it's making the fate tests return invalid data errors, so reverting is better than leave it as is [00:35:02 CEST] <jamrial> michaelni: do you know what could be wrong with eb5d0f18ff609ba2280cea4e2c6286d216c8756b that's making two tiff tests fail? [00:38:24 CEST] <cone-183> ffmpeg 03Carl Eugen Hoyos 07master:dbd3dbb47661: Revert "lavc/tiff: correct the default value of YCbCrSubsampling to 2x2" [00:40:33 CEST] <michaelni> jamrial, i can probably not look at this before tomorrow afternoon, maybe morning but i probably wont have time before afternoon [00:40:48 CEST] <jamrial> michaelni: no hurry, thanks [00:57:04 CEST] <cone-183> ffmpeg 03Jun Li 07master:c23797bc336c: lavf/mov: Fix timestamp rescale on sidx atom [01:53:57 CEST] <cone-183> ffmpeg 03Andreas Rheinhardt 07master:e045be92cdf5: avformat/utils: Assert that stream_index is valid [01:53:58 CEST] <cone-183> ffmpeg 03Andreas Rheinhardt 07master:66d5e43b9909: avformat/utils: Fix memleaks [01:53:59 CEST] <cone-183> ffmpeg 03James Almer 07master:bae8844e3514: avformat/utils: unref packet on AVInputFormat.read_packet() failure [01:54:00 CEST] <cone-183> ffmpeg 03Andreas Rheinhardt 07master:fc20ba9e049e: avformat/utils: Move the reference to the packet list [02:19:23 CEST] <cone-183> ffmpeg 03Ting Fu 07master:9691e2a4264b: checkasm/vf_eq: add test for vf_eq [02:19:24 CEST] <cone-183> ffmpeg 03Ting Fu 07master:6aff2042d648: avfilter/x86/vf_eq: Change inline assembly into nasm code [02:19:25 CEST] <cone-183> ffmpeg 03Ting Fu 07master:4f589d668efd: avfilter/x86/vf_eq: add SSE2 version [02:56:04 CEST] <cone-183> ffmpeg 03Andreas Rheinhardt 07master:b6be2be765b3: avformat/utils: ensure that all packets in AVPacketList are reference counted [07:49:09 CEST] <cone-475> ffmpeg 03Zhong Li 07master:74007dd86a87: lavc/qsv: Fix MSDK initialization failure in system memory mode [07:49:09 CEST] <cone-475> ffmpeg 03Zhong Li 07master:525de9567903: lavc/qsv: add memory type message [11:01:25 CEST] <durandal_1707> michaelni: you broke exr decoder [11:01:36 CEST] <durandal_1707> http://trac.ffmpeg.org/ticket/8203 [11:12:47 CEST] <cone-803> ffmpeg 03Andreas Rheinhardt 07master:84974c6fb542: avcodec/wavpackenc: Fix undefined shifts [12:18:20 CEST] <cehoyos> durandal_1707: https://github.com/themindlessone/abledecoder [12:19:08 CEST] <cehoyos> Needs "envelope", currently not supported by FFmpeg, to get the key [12:19:22 CEST] <cehoyos> Using the key should be possible (but I didn't really understand what it does) [12:20:03 CEST] <cehoyos> https://github.com/themindlessone/abledecoder/blob/master/AbleChunk.cpp <- using openssl to get the "key" [12:20:26 CEST] <cehoyos> https://github.com/themindlessone/abledecoder/blob/master/SoundDataChunk.cpp <- decryption [13:55:06 CEST] <durandal_1707> mkver: sorry, i stolen one of your commits [13:55:17 CEST] <mkver> Yeah, I saw it. [14:04:49 CEST] <cone-803> ffmpeg 03Andreas Rheinhardt 07master:69473bec6f38: avcodec/pcm: Fix undefined shifts [14:16:28 CEST] <cone-803> ffmpeg 03Andreas Rheinhardt 07master:5886153dc3d3: avcodec/pcm: Cosmetics [14:16:29 CEST] <cone-803> ffmpeg 03Andreas Rheinhardt 07master:093b6894bfc2: avcodec/mpeg12dec: Sanitize start codes earlier [14:16:30 CEST] <cone-803> ffmpeg 03Andreas Rheinhardt 07master:646799b42fd5: avformat/movenc: Fix undefined shift [15:36:52 CEST] <michaelni> durandal_1707, ill post a patch to fix 8203, thanks [15:57:55 CEST] <cone-803> ffmpeg 03Paul B Mahol 07master:21838cad2fc4: swscale/output: fix signed integer overflow for ya16 [16:06:00 CEST] <cone-803> ffmpeg 03Paul B Mahol 07master:9b611deef176: avcodec/truespeech: fix left shift of negative value [16:20:51 CEST] <cone-803> ffmpeg 03Andriy Gelman 07master:80e1c93c87f1: avcodec/hevc_ps: Remove dead code in vps_id check [16:23:21 CEST] <cone-803> ffmpeg 03Paul B Mahol 07master:ccd18b4731f1: swresample/audioconvert: fix invalid left shift for 64bit sample format [16:29:31 CEST] <JEEB> and switching /48 [16:29:37 CEST] <JEEB> whoops [16:36:24 CEST] <durandal_1707> michaelni: why 10, what you are attempting to fix? [16:38:53 CEST] <michaelni> durandal_1707, the threshold is to avoid a regression causing OOM [16:51:32 CEST] <durandal_1707> how to auto update hashes of fate? [16:53:25 CEST] <nevcairiel> run it with GEN=1 [17:02:12 CEST] <cone-803> ffmpeg 03Paul B Mahol 07master:1ac0d5513e60: fate: update hashes after ya16 change [17:03:47 CEST] <jamrial> nevcairiel: what happened with your msvc fate clients? [17:20:16 CEST] <cone-803> ffmpeg 03James Almer 07master:1dbd3c61163c: avfilter/vf_eq: fix compilation with x86 asm disabled [18:19:06 CEST] <cone-803> ffmpeg 03Limin Wang 07master:af007e36d159: doc/filters: add 4x4 layout example for xstack filter [18:19:07 CEST] <cone-803> ffmpeg 03Gyan Doshi 07master:b9f8ab3ef490: doc/filters: warn about gaps/overlaps in xstack [20:21:57 CEST] <cone-803> ffmpeg 03James Almer 07master:58aa0ed8f107: aformat/movenc: add missing padding to output track extradata [21:03:30 CEST] <cone-803> ffmpeg 03James Almer 07release/4.2:2ec1b096b103: aformat/movenc: add missing padding to output track extradata [21:06:27 CEST] <cone-803> ffmpeg 03Andreas Rheinhardt 07master:8b0f94990611: avcodec/exr: Fix undefined left shifts of negative numbers [21:06:29 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:02fb6a214717: avcodec/sbcdec: Initialize number of channels [21:06:29 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:972a0a818ff7: avcodec/g729_parser: Check block_size [21:06:31 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:7dc0943d4aa0: avcodec/dstdec: Fix integer overflow in samples_per_frame computation [21:06:31 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:cfa193779103: avcodec/fitsdec: Prevent division by 0 with huge data_max [21:06:32 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:b2785cd3ac05: avcodec/hcom: Check that there are dictionary entries [21:06:34 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:581a895c5c8b: avcodec/alsdec: Avoid dereferencing context pointer in inner interleave loop [21:06:34 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:db614008bc8a: tools/target_dec_fuzzer: Check number of all samples decoded too, like max pixels [21:06:35 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:ec4ad6fb9ec4: tools/target_dec_fuzzer: Print samples decoded like pixels [21:06:37 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:2acbbe262325: avcodec/atrac3: Check block_align [21:06:37 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:c5a52eb5cd56: avcodec/loco: Check for end of input in the first line [21:06:39 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:87ddf9f1ef17: avcodec/4xm: Check index in decode_i_block() also in the path where its not used. [00:00:00 CEST] --- Fri Sep 27 2019

1 0

ffmpeg.log.20190926
by burek 27 Sep '19

27 Sep '19

[00:05:35 CEST] <DHE> -vf crop=newwidth:newheight:xoffset:yoffset (leaving out the offsets defaults to a center-of-frame crop) [00:22:16 CEST] <sagax> thanks [01:26:36 CEST] <brimestone> Hey guys, I have this file with this ffprobe data https://gist.github.com/brimestoned/728b975a913c16c74a1c65e31c4ef46a how do I use AVFormatContext to get specific values from the metadata shown on that link? [01:32:57 CEST] <klaxa> brimestone: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffprobe.c;h=2380417… [01:33:22 CEST] <brimestone> Wow thanks! [01:33:34 CEST] <klaxa> that's the exact code that prints what you pasted [01:33:47 CEST] <klaxa> you should be able to work it from there ;) [01:36:41 CEST] <brimestone> How do I remove the number on the left from the view? [01:37:05 CEST] <brimestone> Got it.. nvm [05:03:59 CEST] <ls3dev33> hi [05:04:23 CEST] <ls3dev33> hey guys.. good day. I am capturing a bunch of files that are already h264 .. problem is on channel changes video lags on start. Is there a way to segment the input by i-frame to speed up the channel changes ? currently i tried to segment into 6 second chunks but i guess the i-frame is an issue because doesn't always start at the 7th second mark [05:04:33 CEST] <ls3dev33> i can't force key frames because I'm not transcoding but.. any way to say segment 6 seconds but then make sure the start of each file is always an i-frame [05:22:33 CEST] <furq> -f segment -segment_time 6 out%04d.mp4 [05:22:45 CEST] <furq> the segments won't be six seconds long, they'll be as close as possible but cut on an idr frame [05:29:14 CEST] <lain98> < DHE> lain98: have you actaully run something like avformat_find_stream_info to populate it? [05:29:47 CEST] <lain98> yes i have. stream->codecpar->format is still -1 [05:31:28 CEST] <ls3dev33> furq than you will test.. does the segment_key also work ? [05:31:36 CEST] <ls3dev33> i'm also encrypting it [05:32:20 CEST] <ls3dev33> i'm using like -hls_list_size 5 -hls_key_info_file whatever.key [05:34:47 CEST] <ls3dev33> also i'm using HLS segment and it doesn't allow those options [06:23:09 CEST] <ls3dev33> @furq, i can't use keys with this segment version :( [08:40:18 CEST] <MoziM> how can a video have seperate audio tracks for language? [08:41:02 CEST] <JEEB> you have this thing called a container [08:41:15 CEST] <MoziM> oh... [08:41:25 CEST] <JEEB> a container can have multiple streams in it, including a video, audio or subtitles [08:41:29 CEST] <JEEB> some containers are more limited than others [08:41:33 CEST] <MoziM> it's beginning to make sense now -_- [08:41:48 CEST] <JEEB> for example, FLV only takes one video and audio. On the other hand MPEG-TS or MP4 or Matroska can have multiple of all [08:41:58 CEST] <MoziM> ya... so in this case i'm using the word "track" wrong right? an audio stream contains tracks [08:42:06 CEST] <MoziM> interesting... [08:42:07 CEST] <JEEB> well either word is "correct" [08:42:14 CEST] <JEEB> in MP4 streams are called tracks [08:42:23 CEST] <JEEB> in FFmpeg they're AVStreams [08:42:24 CEST] <JEEB> :) [08:42:38 CEST] <JEEB> so it depends on when something was come up with and what word someone came up with [08:42:40 CEST] <MoziM> but when talking about selectable audio between french and english it's a stream isn't it? [08:42:55 CEST] <JEEB> once again, either word is used in different places xD [08:43:00 CEST] <JEEB> in MP4 they're tracks [08:43:21 CEST] <JEEB> just saying that either word is not incorrect per se [08:43:52 CEST] <JEEB> it all just means that there's multiple "pipes" of things in a container :) [08:49:39 CEST] <MoziM> gotcha... [09:54:38 CEST] <hendry> when recording my desktop, sometimes... I end up with a file that can't be played. mpv reports "moov atom not found" when trying to play it [09:55:17 CEST] <hendry> when I try re-encode the file, I get Invalid data found when processing input" [09:56:30 CEST] <hendry> here is the log file https://s.natalian.org/2019-09-26/1569483654.mp4.log [09:58:29 CEST] <JEEB> hendry: basically you didn't let the writing finish? [09:58:55 CEST] <JEEB> mp4 files without fragmentation have a single thing at the end of the file which is required to decode it [10:00:10 CEST] <hendry> Killing the process should allow ffmpeg to finish writing? Or am I mistaken? https://github.com/kaihendry/recordmydesktop2.0/blob/master/x11capture#L70 [10:00:57 CEST] <hendry> https://github.com/kaihendry/recordmydesktop2.0/blob/master/x11capture#L70 sorry I do a kill -INT $pid [10:01:48 CEST] <hendry> Or is thre a better VAAPI accelerated intermediate format, other than mp4? [11:13:15 CEST] <lain98> same question as yesterday. how do i get the correct stream->codecpar->format value. Most of the other data in codecpar seems to be populated correctly but format is -1, when i'm quite sure the video is yuv420p [11:32:44 CEST] <Radiator> lain98 Are you reading or emitting a video ? Because if you are reading, you won't be able to set a pixel format. But emitting you will [11:33:19 CEST] <Radiator> The format is set by the codec you are using. CUDA use NS12 for example [11:43:53 CEST] <lain98> Radiator: i'm demuxing [11:44:01 CEST] <lain98> i want to know the pixel format [11:45:21 CEST] <Radiator> It's because it is the frame you receive that will give you the format [11:45:24 CEST] <lain98> i want to know the pixel format for something else. i know that i wont be able to set it [11:45:53 CEST] <lain98> so i cant know without decoding a frame ? [11:45:59 CEST] <Radiator> Yup [11:46:25 CEST] <Radiator> I mean, from what I know, you can only know the pix format once decoded [11:47:28 CEST] <lain98> doesnt look like what the documentation says [11:48:17 CEST] <lain98> int AVCodecParameters::format video: the pixel format, the value corresponds to enum AVPixelFormat. audio: the sample format, the value corresponds to enum AVSampleFormat. [11:50:40 CEST] <Radiator> It might be related to muxing. SInce from what you receive it indicate AV_PIX_FMT_NONE which isn't good. Plus the stream isn't fairly used on demuxing since it is your codec context that will be called to retreive the packets [11:51:22 CEST] <lain98> hmm okay [11:51:39 CEST] <lain98> so it would be meaningful if i was muxing instead of demuxing. [11:51:50 CEST] <lain98> and i have to set the format value when muxing [11:51:52 CEST] <lain98> ? [11:51:53 CEST] <Radiator> As well as your AVFormatContext [11:52:37 CEST] <JEEB> generally in muxing you don't need that at least for video [11:52:53 CEST] <Radiator> Yes you have to. Correct me if I'm wrong bu if you don't it finds a format suitable to the container [11:53:03 CEST] <lain98> all of this was just a workground to get bit depth. \ [11:53:06 CEST] <JEEB> and if you really need the pix_fmt or sample format I would only trust a value received from an AVFrame in the decoder [11:53:18 CEST] <JEEB> lain98: yes containers usually don't have that [11:53:49 CEST] <lain98> okay. [11:53:53 CEST] <JEEB> also I have streams that switch resolution in the middle for example. [11:53:57 CEST] <Radiator> lain98: Look at AVPixFmtDescriptor might help you [11:54:23 CEST] <JEEB> so if you "want the truth" you are in for pain [11:54:23 CEST] <JEEB> but the best bet is to just decode the first sample [11:54:23 CEST] <lain98> hmm [11:54:24 CEST] <lain98> actually [11:54:30 CEST] <JEEB> receive until you get an AVFrame, and boom [11:54:37 CEST] <JEEB> you have something [11:54:46 CEST] <Radiator> +1 JEEB [11:54:49 CEST] <JEEB> for example with H.264 you can fully reconfigure the stream [11:54:52 CEST] <lain98> i was using decoder api from nvidia. its giving me something wrong so i thought i could fallback on ffmpeg [11:55:02 CEST] <JEEB> bit depth, pixel format, resolution [11:55:05 CEST] <JEEB> it's all dynamic [11:55:23 CEST] <Radiator> lain98: You can configure ffmpeg to use the NVIDIA SDK as well [11:55:42 CEST] <Radiator> https://developer.nvidia.com/ffmpeg [11:56:13 CEST] <BtbN> I wouldn't follow anything they write there about how to build ffmpeg though, it's pretty bad. [11:56:20 CEST] <Radiator> But be aware that encoding with nvidia isn't the most efficient [11:56:26 CEST] <lain98> its a pain in the butt [11:56:34 CEST] <BtbN> Or rather, it's overly complicated and outdated. [11:57:53 CEST] <BtbN> It's correct about the nv-codec-headers, but configure does not need any special flags once those are installed (to somewhere pkg-config finds them) [11:57:54 CEST] <lain98> okay, i understand what i have to do. thanks [11:57:54 CEST] <Radiator> BtbN: I wouldn't say so, unless you follow blindfully their instruction you can run into some deep issues. But just using their flags to use the SDK and the hwaccel is pretty straigth forward and easy to do [11:58:06 CEST] <BtbN> Radiator, they instruct you to get the CUDA SDK for example. Which at this point, is entirely unused by ffmpeg. [11:58:35 CEST] <BtbN> And cuvid is long half-deprecated in favor of nvdec [11:59:02 CEST] <BtbN> same for scale_npp instead of scale_cuda [11:59:22 CEST] <Radiator> BtbN Unless you do hardware acceleration which then is used - And yes, cuvid is the black sheep of it all as well as a lot more of their other flags [11:59:45 CEST] <BtbN> "Unless you do hardware acceleration which then is used"? [11:59:51 CEST] <BtbN> Not sure what you mean by that. [12:00:23 CEST] <Radiator> Isn't nvdec and nvenc are used by ffmpeg ? [12:00:29 CEST] <BtbN> Yes? [12:00:32 CEST] <lain98> okay, ah yes i have another question [12:01:13 CEST] <Radiator> BtbN: But for the configuraton of ffmpeg using nvidia you just need to use "--enable-cuda-sdk --enable-nvdec --enable-nvenc" [12:01:33 CEST] <lain98> i was trying to demux a vp9+mp4 file. but AVStream->duration is something undefined [12:01:58 CEST] <BtbN> Radiator, --enable-cuda-sdk is deprecated and effectively does nothing at this point. FFmpeg does not need or use the CUDA SDK. [12:02:01 CEST] <lain98> even the ffmpeg application says its undefined [12:02:22 CEST] <Radiator> BtbN Oh I didn't know that [12:02:34 CEST] <BtbN> The last thing wich you still used to need the SDK for was nvcc, which was recently replaced with clang. [12:02:39 CEST] <lain98> webm container with vp9 codec [12:02:58 CEST] <lain98> ffmpeg output says "Duration: N/A, start: 0.000000, bitrate: N/A" [12:03:10 CEST] <lain98> i got this video off youtube [12:12:02 CEST] <lain98> okay, this is a know bug https://trac.ffmpeg.org/ticket/7800 [12:34:27 CEST] <lain98> webm is essentially mkv right ? [12:53:27 CEST] <cehoyos> webm is a subset of mkv [14:18:21 CEST] <kepstin> also note that the webm for youtube is built for dash streaming, and so might be missing some metadata typical of a standalone file. [14:18:35 CEST] <kepstin> iirc youtube-dl normally remuxes it [15:21:22 CEST] <taliho> JEEB: Re: Probing issue from yesterday [15:21:40 CEST] <taliho> JEEB: In case you are interested this solved it for me This patch solves it for me: http://ffmpeg.org/pipermail/ffmpeg-devel/2015-May/173594.html [15:25:41 CEST] <JEEB> taliho: hmm, I'll test that out [15:25:56 CEST] <JEEB> thanks for mentioning it, I will try to ping it if it works for me too [15:26:00 CEST] <cehoyos> The patch breaks S302M decding afaict [15:26:14 CEST] <JEEB> ah [15:26:50 CEST] <JEEB> so we need like with various other formats figure the more specific things to check [15:27:22 CEST] <JEEB> either for S302M or this stuff [15:27:35 CEST] <taliho> yes, I followed the messages. S302M has a private stream that probed and set as a audio codec [15:29:18 CEST] <taliho> michael proposed a patch that was merged, but it doesn't work for me because it still requires probing the private stream [15:30:24 CEST] <taliho> this is michaels patch: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/174035.html [15:31:19 CEST] <taliho> for me this doesn't work because the private stream is extrememly low rate serialized protobuf data, so it doesn't make sense to probe it [15:38:42 CEST] <JEEB> yea, probing works until it has enough data [15:38:48 CEST] <JEEB> and with low bit rate streams that can be a minute or more [15:45:53 CEST] <taliho> JEEB: my protobuf stream is ~50bits every 10 seconds. I'd have to wait days to get enough data for probing to exit :P [15:51:55 CEST] <cehoyos> taliho: Did you play with analyzeduration and probesize? [15:54:02 CEST] <JEEB> I think I played with those and probesize might have helped, but it would then of course be such a small amount of data that it wouldn't be getting much info on the other stuff [15:54:16 CEST] <JEEB> analyzeduration calculates within the probesize [15:54:29 CEST] <JEEB> if I find time to probe the radio streams I have access to I'll verify [16:00:54 CEST] <taliho> cehoyos: analyzeduration and probesize only help when the demuxer is initialized in avformat_find_stream_info() [16:02:14 CEST] <taliho> for me the issue is after initialization in ff_read_packet [16:02:49 CEST] <taliho> cehoyos: here there is a hard coded parameter #define MAX_PROBE_PACKETS 2500 [16:03:21 CEST] <cehoyos> maybe this should be user-settable? [16:04:57 CEST] <taliho> that's true, or I was thinking of adding an option that to disable probing of a private stream [19:19:53 CEST] <fling> Is there an audio filter for denoise by a pattern? [19:20:12 CEST] <fling> So I feed it with a pattern and it removes the noise from a stream [20:57:21 CEST] <inna> hey [20:57:43 CEST] <inna> can i cut out a piece from an mp4 without re-encoding? [20:57:52 CEST] <DHE> yes, but your cut must start on a keyframe [20:57:52 CEST] <inna> as in -v:copy [20:57:56 CEST] <DHE> -c:v copy [20:58:11 CEST] <inna> cool, thx [20:59:43 CEST] <inna> can ffmpeg catch streams? [21:20:49 CEST] <DHE> huh? [22:19:22 CEST] <inna> never mind [22:22:04 CEST] <arinov> inna: save streamed video into file? [22:22:36 CEST] <inna> saving multiple .ts in an .m8u [22:22:54 CEST] <arinov> dunno [00:00:00 CEST] --- Fri Sep 27 2019

1 0

ffmpeg-devel.log.20190925
by burek 26 Sep '19

26 Sep '19

[00:05:55 CEST] <mkver> Have there been changes to the mail server? My new patchset has been delivered almost instantaneously. [00:06:44 CEST] <BtbN> That's how mails usually go [00:08:34 CEST] <mkver> My mails have usually been stuck for several minutes. [00:17:28 CEST] <cone-380> ffmpeg 03Guo, Yejun 07master:104d44138be1: libavcodec/libx264: add a flag to output ROI warnings only once. [00:17:28 CEST] <cone-380> ffmpeg 03Guo, Yejun 07master:85e338ab0da6: libavcodec/libx265: add a flag to output ROI warnings only once. [05:24:14 CEST] <cone-478> ffmpeg 03Jun Zhao 07master:5f13859873a4: lavf/4xm: fix memory leak in error handing path [10:46:24 CEST] <JEEB> I'll attempt to post this on the mailing list tonight as well, but I'd like to get responses with regards to handling end-of-stream in MPEG-TS [10:46:30 CEST] <JEEB> should this be handled by: [10:46:54 CEST] <JEEB> a) the framework, utilizing whatever is the current way of doing end-of-stream if a stream disappears from its PMT [10:47:09 CEST] <JEEB> b) the API client, following the PMT updates through the AVProgram's pmt_version field [10:48:22 CEST] <cone-703> ffmpeg 03Pavel Skakov 07master:eb5d0f18ff60: lavc/tiff: correct the default value of YCbCrSubsampling to 2x2 [12:08:21 CEST] <durandal_1707> cehoyos: where is that sample? [12:08:44 CEST] <cehoyos> Uploading it now (400MB), will take ~15 minutes [12:16:29 CEST] <cehoyos> durandal_1707: http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket8199/ [12:17:09 CEST] <cehoyos> command line is: ffmpeg -ss 9:00 -i ds9-s01e05-repro-02.mkv -filter:v "dejudder,fps=30000/1001,fieldmatch,decimate" -f null - [12:51:22 CEST] <durandal_1707> silly one line bug [13:07:17 CEST] <jdarnley_obs> C has no guarantee about the actual order and position of arrays on the stack, right? [13:07:55 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:0d05aa052cdd: avfilter/vf_v360: add sinusoidal format [13:07:55 CEST] <jdarnley_obs> That would be relying on the implementation and arch, right? [13:07:56 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:2962101e407e: avfilter/vf_fieldmatch: fix more leaks [13:07:57 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:da9890f6c7d2: avfilter/vf_fieldmatch: forward status back from output to all input links [13:07:58 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:55b32584b80e: avfilter/vf_premultiply: forward status back from output to all input links [13:08:48 CEST] <jdarnley_obs> Basically, I can't assume that a checkasm test will always have arrays on stack in the order I write them in source. [13:10:11 CEST] <jdarnley_obs> Ah, but I think that doesn't matter in this case because I can make the ones used for assembly larger to contain the overwrite. [13:14:57 CEST] <cehoyos> vmovdqa %ymm1,(%rdi) <- how much alignment does rdi need here (avx2)? [13:15:11 CEST] <cehoyos> rdi 0x7fffffffcc70 140737488342128 [13:15:13 CEST] <jdarnley_obs> 32 bytes [13:15:19 CEST] <jdarnley_obs> 0x20 [13:15:46 CEST] <jdarnley_obs> or the 0x?0 number must be even [13:15:47 CEST] <cehoyos> Who is responsible for the alignment? FFmpeg or libx264? (ticket 8200) [13:16:53 CEST] <cehoyos> x264_8_load_deinterleave_chroma_fenc_avx2() is the crashing function [13:16:53 CEST] <jdarnley_obs> Probably ffmpeg, if it is reading from input data. [13:22:59 CEST] <jdarnley_obs> Does asan check arrays on the stack properly to see if there is an out of bound use of one? [13:23:31 CEST] <jdarnley_obs> Or do i need to malloc for that to work? [13:27:21 CEST] <nevcairiel> eh if there was a fundamental issue like that guy tries to claim, there would've been many errors before [13:28:23 CEST] <nevcairiel> there is probably some dumb reason like he disables asm in ffmpeg but enables it in x264 which means that ffmpeg uses less alignment by default [13:28:42 CEST] <JEEB> usually filters are related [13:28:51 CEST] <JEEB> like crop etc which don't touch the image bytes, but can f.ex. crop [13:29:07 CEST] <JEEB> or a filter which would generate a new image buffer but doesn't align it [13:29:21 CEST] <JEEB> I think with codec cropping you might not need decoding, even? [13:29:31 CEST] <cehoyos> No filters in his command line [13:29:41 CEST] <JEEB> yes [13:29:46 CEST] <cehoyos> no specific configure option for asm [13:29:57 CEST] <cehoyos> Is a minimum compiler needed for avx2? [13:31:31 CEST] <nevcairiel> no, only nasm/yasm is tested, but thats independent of the alignment determination [13:32:20 CEST] <JEEB> was there some arch etc check for the alignment to use with av_malloc and friends? [13:32:54 CEST] <nevcairiel> #define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16)) [13:32:54 CEST] <nevcairiel> thats it ^ [13:35:15 CEST] <nevcairiel> and on x86 all those HAVE's are true un less you disable them in configure [13:37:15 CEST] <cehoyos> He is using super new x264 with gcc 4.8.5 [13:37:35 CEST] <nevcairiel> its possible that something is j ust screwed up from the old compiler [13:38:38 CEST] <BBB> x264 expects 32byte alignment of stack [13:40:14 CEST] <BBB> is the stack 32byte aligned? [13:40:14 CEST] <BBB> in ffmpeg, it usually is not, so maybe need to manually re-align it upon x264 lib entry [13:40:14 CEST] <BBB> first of all, figure out if the buffer is stack or heap [13:40:14 CEST] <nevcairiel> shouldnt the x264 header set this attribute to make that happen, like we do in ffmpeg when called from msvc [13:40:14 CEST] <BBB> hopefully :) [13:40:14 CEST] <BBB> let's figure out if the $rdi is stack or heap [13:40:14 CEST] <BBB> cehoyos: p $rdi && p $rsp [13:40:14 CEST] <BBB> (as (void*)) [13:40:14 CEST] <cehoyos> BBB: ? [13:40:14 CEST] <BBB> what is the value of $rsp? [13:40:14 CEST] <cehoyos> rsp 0x7fffffffcc28 0x7fffffffcc28 [13:40:23 CEST] <BBB> ty, so it's stack [13:40:25 CEST] <BBB> what platform? win64? [13:40:34 CEST] <cehoyos> Red Hat [13:40:38 CEST] <BBB> ah [13:40:58 CEST] <BBB> lookslike a bug in x264 then [13:41:13 CEST] <BBB> I don't think that memory area is far enough from rsp to be allocated in ffmpeg, so it's likely internal to x264 [13:41:26 CEST] <BBB> one of the x264 devs would know better though [13:41:47 CEST] <BBB> it's possible it's a compiler bug also [13:45:40 CEST] <BBB> looks like this value in ac_energy_mb/plane: ALIGNED_ARRAY_32( pixel, pix,[FENC_STRIDE*16] );, line 246 of ratecontrol.c [13:45:56 CEST] <BBB> so that's likely the stack re-alignment code in x264 [13:46:00 CEST] <BBB> which requires compiler support [13:46:10 CEST] <BBB> so i support your conclusion to recompile with a newer compiler and try again [14:05:43 CEST] <jdarnley_obs> "upgraded" but still 4.8.5 [14:13:41 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:9c3e1c19376e: avfilter: add sierpinski video source [14:18:06 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:402dbd4633a7: avfilter/Makefile: fix case for sierpinski [14:50:36 CEST] <jdarnley_obs> dammit! why are no tools cacthing where this problem happens [15:04:32 CEST] <jdarnley_obs> oh wtf [15:04:39 CEST] <jdarnley_obs> I had no idea checkasm did that [15:05:00 CEST] <jdarnley_obs> the "ref" function here is ssse3 [15:05:27 CEST] <jdarnley_obs> I guess I assumed ref would always be the C [15:05:38 CEST] <jdarnley_obs> that would explain this overwrite [15:08:22 CEST] <durandal_1707> https://www.youtube.com/watch?v=fk1bxHi6iSI [15:17:35 CEST] <jamrial> jdarnley_obs: are you sure? sounds unlikely [15:18:15 CEST] <jdarnley_obs> It is what I saw in my copy [15:18:45 CEST] <jdarnley_obs> the ssse3 function was called from call_ref [15:19:03 CEST] <jdarnley_obs> but maybe I should double check that the source wasn't changed [15:22:28 CEST] <jdarnley_obs> yes, valgrind trapped on an invalid write [15:22:46 CEST] <jdarnley_obs> that was in ssse3 [15:22:57 CEST] <jdarnley_obs> going up I get to call_ref [15:23:36 CEST] <jdarnley_obs> maybe the cpp macros throw it off [15:24:01 CEST] <jdarnley_obs> or maybe I just broke things when I copied and hacked up checkasm for another project [15:31:10 CEST] <wbs> I think it might be that call_ref calls the "previous" version of the function, not necessarily the C function, as checkasm itself doesn't really know or care what is C and what is each simd instruction set - just previous and current function [15:31:55 CEST] <jdarnley_obs> yes, I do see the logic in that [15:32:29 CEST] <jdarnley_obs> I guess that would work for things (in theory) that don't have a C version [15:32:41 CEST] <jamrial> wouldn't that result in every version after the first one wrong to also fail? [15:32:54 CEST] <jdarnley_obs> whereas whatever with cpuflags 0 wouldn't [15:33:42 CEST] <wbs> jamrial: possibly [16:51:07 CEST] <durandal_1707> jamrial: looked at http://trac.ffmpeg.org/ticket/8183 its about av1 [16:51:44 CEST] <kierank> suhwan should get job at google [17:03:26 CEST] <cehoyos> durandal_1707: Why is sierpinski not gray8? [17:04:28 CEST] <durandal_1707> cehoyos: to make you happy [17:04:49 CEST] <cehoyos> Or is there colour? [17:05:30 CEST] <durandal_1707> yes, black and white [17:34:17 CEST] <cone-183> ffmpeg 03Michael Niedermayer 07master:f8406ab4b9f4: avcodec: add max_samples [17:34:17 CEST] <cone-183> ffmpeg 03Michael Niedermayer 07master:68c80dc31245: tools/target_dec_fuzzer: Set max_samples [17:34:17 CEST] <cone-183> ffmpeg 03Michael Niedermayer 07master:121bf1b3b8de: avcodec/decode: Check max_samples in get_buffer_internal() [17:35:11 CEST] <durandal_1707> michaelni: you added max_samples field to avcodec, I will revert it [17:47:25 CEST] <michaelni> durandal_1707, i wont stop you if you feel so strong about it. but we need something equivalent and it seemed that it was the preferred solution by most people who commented in the thread [17:49:22 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:d58752bcb923: avformat/aiffdec: fix signed integer overflow [17:56:05 CEST] <BBB> cehoyos: for 8200, the guy knows that after upgrading the compiler, he has to recompile x264 from source, right? [17:56:11 CEST] <BBB> just sayin' [17:56:30 CEST] <BBB> i can't verify from the bug whether he recompiled x264 after installing a newer compiler or not [18:04:46 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:1a17a66b0989: avformat/sdsdec: fix undefined behaviour [18:17:05 CEST] <durandal_1707> what you think about adding slice threading to *stack filters, in case of xstack and overlaps results may not be same with different number of threads [18:20:40 CEST] <philipl> Lynne: I've got a bunch of other stuff distracting me, but I have a plan for getting the transfer stuff all working and I've proven the key parts to myself. Maybe by the end of the week. [18:21:06 CEST] <cehoyos> BBB: I don't know, I will probably try to reproduce with old gcc later. [18:41:49 CEST] <Lynne> philipl: take your time, not like I know myself whether I'll even send it to the ML or the trash bin [18:42:35 CEST] <durandal_1707> Lynne: what? no trash bin please! its useful! [19:22:23 CEST] <jamrial> durandal_1707: fix sent to the ml [21:45:29 CEST] <Lynne> I wish the hdcd filter was a decoder... [21:45:48 CEST] <durandal_1707> Lynne: blasphemy [21:56:28 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:44095564d48b: avfilter/vf_stack: simplify main processing path [21:56:29 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:631f7acc6c48: avfilter/vf_stack: add slice threading [21:56:30 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:20242bc76292: avfilter/vf_zoompan: forward status back from output to input [21:56:31 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:ced3b8c61e96: avfilter/vf_zoompan: fix leaks [22:57:20 CEST] <cone-183> ffmpeg 03Limin Wang 07master:3def984a98c3: avcodec/dnxhdenc: return error if av_malloc failed [00:00:00 CEST] --- Thu Sep 26 2019

1 0

ffmpeg.log.20190925
by burek 26 Sep '19

26 Sep '19

[00:00:10 CEST] <kepstin> (also, ffvhuff is basically an improved huffyuv - if you're gonna be using ffmpeg/libavcodec to decode it later, prefer ffvhuff) [00:00:27 CEST] <kepstin> if only because it supports more pixel formats :) [00:17:20 CEST] <^Neo> hello! I'm working with some HEVC 1080i video and it appears that when I ffprobe/av_find_stream_info with the video it comes up as 1920x540p60 instead of 1920x1080i30... [00:17:36 CEST] <^Neo> I found some patches about supporting field paired HEVC streams and they look to be integrated in the latest FFmpeg [00:17:54 CEST] <^Neo> but was curious what people were doing to get the reported 1920x1080i resolution [00:43:24 CEST] <kepstin> ^Neo: you can use the tinterlace filter to turn the separate field images into full-height interlaced frames. [00:43:55 CEST] <^Neo> yeah, I just thought of that after I posted - duh! thanks for confirming what I thought [00:43:56 CEST] <kepstin> or weave [00:44:01 CEST] <kepstin> which is equivalent i think [00:44:52 CEST] <kepstin> i suppose weave is easier to use [03:05:07 CEST] <b0bby|> hello [03:08:09 CEST] <b0bby|> Scenario: I have a 4k file that takes a significant amount of processing power to decode. I would like to lower the quality to make it easier to playback. What is the fastest(computationally fastest) way to do this? The size of the files doesn't really matter as long as its not absurdly large(think raw video). [03:13:04 CEST] <klaxa> probably something like -c:v libx264 -profile:v baseline [03:20:50 CEST] <b0bby|> klaxa: does that keep a decent amount of quality? My goal is 1080p [03:22:52 CEST] <b0bby|> klaxa: better question, whats the catch of using baseline? [03:27:09 CEST] <klaxa> bigger file because of less expensive computations [03:27:16 CEST] <klaxa> you can control quality with -crf [03:27:26 CEST] <klaxa> do some test encodes to check [03:27:42 CEST] <b0bby|> klaxa: thats super cool [03:28:05 CEST] <b0bby|> klaxa: I suspected something existed but didn't know for sure [03:28:39 CEST] <klaxa> well if it's not fast enough there is even faster enocders with worse quality :P [03:29:16 CEST] <klaxa> or you could first tune it even more to fastness by using different presets [03:30:47 CEST] <b0bby|> klaxa: ok, do that presets effect quality heavily? [03:31:32 CEST] <klaxa> not sure tbh, just give it a try, i think the default is -preset medium faster values are fast, faster, ultrafast [03:31:35 CEST] <klaxa> afaik [03:31:58 CEST] <b0bby|> thanks for the help [03:38:11 CEST] <another> see also: https://trac.ffmpeg.org/wiki/Encode/H.264 [09:10:05 CEST] <lain98> how would i get the stream duration of a webm file. i enabled webm demuxer in the ffmpeg build. AVStream.duration does not seem to report correct value. even the ffmpeg application reports "Duration: N/A, start: 0.000000, bitrate: N/A" [10:42:58 CEST] <Radiator> Hello everyone ! I'm remuxing a stream from mpeg to h264 and converting the frame in a YUV420P format. When I use ffplay to display the output stream, the frame is all pixelised, grey and not scaled at all. Any idea why it would do that ? Using other containers works fine but h264 with YUV420P doesn't. [13:29:11 CEST] <safinaskar> what is best encoder for videos captured from screen? (in terms of file size) and why ffv1 and ffvhuff produce so big files compared to x264 -crf 0? [13:29:25 CEST] <safinaskar> wait a minute, i will show you sample video [13:31:07 CEST] <cehoyos> It seems you already found the best encoder for your use case... [13:31:34 CEST] <cehoyos> Feel free to test qtrle [13:33:26 CEST] <safinaskar> so, i am trying to find best encoder for videos captured from screen. to make video even smaller i heavily reduce count of different colors appearing in video. i. e. i apply strong filter, which collapses whole palette to very small number of colors. this is sample with typical video captured from my screen with such reduced palette: [13:33:27 CEST] <safinaskar> https://gitlab.freedesktop.org/gstreamer/gst-examples/uploads/0a23a18aa8016… . so, i need lossless encoder for such videos. i tried x264, ffv1 and ffvhuff. and i noticed that ffv1 and ffvhuff are a lot bigger than x264: [13:33:28 CEST] <safinaskar> https://gitlab.freedesktop.org/gstreamer/gst-examples/uploads/dce9129d8311d… , https://gitlab.freedesktop.org/gstreamer/gst-examples/uploads/3fd9ab069b198… . why? [13:33:56 CEST] <durandal_1707> because [13:35:30 CEST] <cehoyos> I believe you don't want yuv444p encoding [13:37:19 CEST] <safinaskar> cehoyos: ok [13:40:11 CEST] <safinaskar> -rw-r--r-- 1 user user 540M A5= 25 13:54 /mnt/tmp/sample.ffv1.mkv-rw-r--r-- 1 user user 4,8G A5= 25 14:08 /mnt/tmp/sample.ffvhuff.mkv-rw-r--r-- 1 user user 21M A5= 25 14:02 /mnt/tmp/sample.libx264-crf0.mkv [13:59:58 CEST] <lain98> https://www.ffmpeg.org/doxygen/3.2/structAVCodecParameters.html#abee943e65d… . However I get format = -1. Any clue ? [14:00:33 CEST] <lain98> format should be AVPixelFormat or AVSampleFormat enum according to documentation [14:01:42 CEST] <lain98> -1 corresponds to AV_PIX_FMT_NONE but i know the file is yuv420p [14:10:14 CEST] <cehoyos> safinaskar: the difference is that frame-exact seeking is not easily possible with the x264 encoding, use -g 1 to get a comparable result [14:15:08 CEST] <DHE> lain98: have you actaully run something like avformat_find_stream_info to populate it? [14:35:43 CEST] <termos> Any way to make h264 decoding more resilient? Getting 5+ decoding errors in a row results in stream not being able to continue working. I tried with -fflags +discardcorrupt which seems to make it a bit better [14:36:36 CEST] <BtbN> If too much data is missing to decode the stream, there is not much to be done about it. [14:40:49 CEST] <furq> you can try -err_detect ignore_err [14:52:45 CEST] <termos> hmm that's an interesting flag, will give it a tr [14:57:03 CEST] <safinaskar> cehoyos: i just tested x264 -g 1 and got big file (file size simular to ffv1). is there a way to use x264 with exact seeking? maybe some container will help? [14:57:29 CEST] <cehoyos> termos: "not being able to continue working" should never happen, if there is a sample input, please provide it. [14:57:36 CEST] <cehoyos> safinaskar: Yes, -g 1 [14:58:00 CEST] <cehoyos> afk [14:58:45 CEST] <kepstin> safinaskar: if you need to be able to copy (without re-encoding) on arbitrary frames, then you need to encode in intra-only, and therefore result will be big. [14:58:46 CEST] <DHE> sorry, your only other option is a player that can seek to a keyframe and then decode to the true desired seek position quietly [14:59:41 CEST] <kepstin> note that ffmpeg itself supports frame-accurate seeking when decoding h264 [14:59:57 CEST] <JEEB> *** [15:00:05 CEST] <JEEB> *** depends on container [15:01:02 CEST] <kepstin> yeah, needs a container that indicates keyframes, iirc? and definitely works best if there's an index. [15:01:12 CEST] <kepstin> mkv, mp4 are fine, for example. [15:01:24 CEST] <JEEB> keyframes and index (that is utilized in seeking functionality) [15:09:31 CEST] <safinaskar> Well. Let me finally describe my actual task. I want to capture screen. And then i want to play it using player which supports playing in both ways (back and forth). And also supports arbitrary seeking. Also my computer sometimes abruptly fails. And i want player to be able to play even such videos. I. e. even if computer powered off while [15:09:31 CEST] <safinaskar> recording video, player still should be able to play such video with all features enabled, i. e. playing back and forth, seeking, etc. Also I want videos to be small. Unfortunately, such task appears to be very difficult. First of all, it seems there is no player, which supports playing in back direction. There is unofficial mpv branch, which [15:09:32 CEST] <safinaskar> supports such playing, but I don't want to depend on unofficial branch. Also gst-play supports it, too, but gst-play is not supposed to be full-featured player, this is util to test gstreamer libs. So, I decided to write my own player. Using gstreamer libs, because they support playing in back direction. Now I am trying to choose encoder. libx264 [15:09:32 CEST] <safinaskar> compresses very well. Also (when I pack x264 into matroska container) seeking and playing in back direction works, too (in gstreamer). So, everything is ok. Unfortunately, problems arise when computer powers off. If I record such x264 video and then power off my computer, then gstreamer cannot seek on such broken video. So, now I am in search for [15:09:33 CEST] <safinaskar> encoder, which satisfy this 2 criteria: 1) it should compress well, similary to x264 2) when computer crashed while recording such video, gstreamer libs should seek this video anyway [15:10:14 CEST] <safinaskar> Currently I didn't find such codec. x264 seeks badly, when computer crashs. ffv1 seeks relatively good, but compresses badly [15:11:24 CEST] <furq> safinaskar: did you try remuxing the interrupted files [15:11:35 CEST] <furq> sounds like the container seek index was never built or is incomplete [17:17:00 CEST] <mlok> Hello, what do you think I should learn and know in order to effectively understand and modify FFMPeg source code written in C to create a new application? Thank you [17:17:40 CEST] <mlok> Should I improve C/C++ skills? Or perhaps understand how FFPlay works in terms of decoding video to start? [17:17:54 CEST] <pink_mist> you should probably not modify ffmpeg source code, you should just link to it ... and I'm pretty sure there are loads of examples of doing that kind of thing in the sources [17:18:10 CEST] <JEEB> doc/examples has various examples of varying quality [17:18:26 CEST] <JEEB> and yes, ffmpeg.c (the command line application) is just an API client [17:18:28 CEST] <JEEB> just like any other [17:18:30 CEST] <JEEB> :) [17:18:57 CEST] <JEEB> another thing to look at are the trunk doxygen documentation [17:19:02 CEST] <mlok> Thanks :) for example I would like to enerates output frames at a constant rate to feed to ffmpeg regardless of the state of the inputs [17:19:10 CEST] <mlok> *generate [17:19:18 CEST] <JEEB> site:ffmpeg.org doxygen trunk KEYWORD [17:19:32 CEST] <JEEB> mlok: so you basically need a time-based generator [17:19:46 CEST] <JEEB> you can use lavfi (libavfilter) to have a source, but you need to add the timings yourself [17:20:03 CEST] <mlok> JEEB: ahh ok, that sounds interesting [17:20:05 CEST] <JEEB> say, "if nothing came in in 250ms, stuff this into the chain" [17:20:31 CEST] <JEEB> mlok: I must say that the upipe framework did get multiple alternative inputs with back-ups implemented [17:20:34 CEST] <JEEB> so you might want to see how that was made [17:20:40 CEST] <JEEB> upipe also uses FFmpeg for some parts [17:20:46 CEST] <JEEB> (although it is broadcast oriented) [17:20:51 CEST] <mlok> Thanks, I'll check these things out [17:21:01 CEST] <Media_Thor> safinsakar: try MPEG2 video codec in MPEG2-TS container maybe, most you'll lose is 1/2 a sec gop. [17:21:33 CEST] <mlok> Media_Thor: Thanks [17:21:57 CEST] <mlok> This is mainly for RTMP which can drop causing FFMPEG to start transcoding into HLS [17:22:01 CEST] <mlok> *stop [17:27:37 CEST] <mlok> JEEB: If I wanted to create a web based GUI for FFMPEG, is it a good idea to use a wrapper or e.g. python bindings? [17:59:01 CEST] <taliho> anyone know if there is a way to disable probing on certain streams? [18:00:03 CEST] <taliho> I have an mpegts stream with one stream as binary data and ff_read_packet gets stuck trying to probe this stream [18:01:32 CEST] <taliho> I feel like this issue has come up a few times before [18:03:57 CEST] <taliho> I could try to add this as an option if there is any interest [18:04:50 CEST] <taliho> at the moment I have: [18:04:56 CEST] <taliho> : ./ffmpeg -y -loglevel trace -f mpegts -i udp://127.0.0.1:10001 -copy_unknown -map 0:d:0 -codec:d copy -f data udp://127.0.0.1:10002 [18:05:57 CEST] <taliho> maybe with a disable probing option it could be: [18:06:39 CEST] <taliho> : ./ffmpeg -y -loglevel trace -f mpegts -i udp://127.0.0.1:10001 -disable_probing:d:0 -copy_unknown -map 0:d:0 -codec:d copy -f data udp://127.0.0.1:10002 [18:14:11 CEST] <cehoyos> I don't think FFmpeg is the right tool for this job. [18:14:16 CEST] <cehoyos> Maybe tcpdump? [18:19:08 CEST] <DHE> probing should timeout as long as any data is being received at all (eg: joining a multicast group that's dead will hang) and ffmpeg will still be able to retroactively process the data that was used in probing [18:29:28 CEST] <void09> how does ffmpeg behave if you tell it to cut a video on non-I frame ? [18:31:54 CEST] <cehoyos> If you re-encode, there is no problem, if you remux, your request will not be 100% satisfied [18:33:45 CEST] <JEEB> taliho: usually due to the data stream being low bit rate [18:34:00 CEST] <JEEB> so the probing logic waits and waits until it gets enough [18:34:19 CEST] <JEEB> I've had that with broadcast radio channels [18:34:31 CEST] <JEEB> although it probably happens with any stream where there's a slowly enough growing data stream [18:34:34 CEST] <void09> "With the mp4 container it is possible to cut at a non-keyframe without re-encoding using an edit list. In other words, if the closest keyframe before 3s is at 0s then it will copy the video starting at 0s and use an edit list to tell the player to start playing 3 seconds in." [18:34:40 CEST] <void09> I assume this does not work for mkv ? [18:34:50 CEST] <JEEB> you have virtual timelines in matroska as well [18:35:14 CEST] <JEEB> they aren't really well supported in FFmpeg so you might want to look into mkvtoolnix's mkvmerge and the "ordered chapters" stuff [18:35:24 CEST] <JEEB> "ordered chapters" is how virtual time lines are called in Matroska [18:35:29 CEST] <cehoyos> FFmpeg does not support cutting with edit lists [18:35:33 CEST] <void09> :( [18:36:08 CEST] <void09> What I want to achieve is, make a script that splits a video into chunks at scene changes. without any re-encoding. [18:36:10 CEST] <JEEB> taliho: I think there's a patch on the ML to alleviate the low bit rate data stream probing problem [18:36:17 CEST] <cehoyos> The reason is that for cutting with edit lists you need an mp4 editor, FFmpeg is not a file editor, it is a transcoding application (that also supports remuxing) [18:37:38 CEST] <cehoyos> void09: What you want is not generally possible - there is no guarantee that the (original) encoder was smart enough to detect the scene change [18:37:38 CEST] <void09> so if the scene change frame is not an I-frame, I need the frames leading (and following, for the end of the video) up to the I-frame, to be included. but I also need some way of marking those padded frames so they are not considered when re-encoding, for my purposes [18:38:07 CEST] <void09> cehoyos: ffmpeg supports scene change detection, and giving it a good enough parameter for sensitivity, it's pretty much certain to be correct [18:38:12 CEST] <cehoyos> (And it is even possible that inserting an I frame at the "scene change" would not have resulted in a minimal file size / best quality) [18:38:42 CEST] <JEEB> void09: sounds like you want a project file format. something like EDL? [18:38:48 CEST] <JEEB> which then refers to files and has times [18:38:52 CEST] <cehoyos> It supports scene change detection (this is absolutely necessary for any transcoding application) but this is not related to the question you asked [18:38:55 CEST] <void09> JEEB: no idea what that is [18:39:04 CEST] <void09> I want to deploy a distributed encoder, just for fun [18:39:37 CEST] <cehoyos> What you want is not possible with current FFmpeg [18:39:37 CEST] <void09> cehoyos: I do not care or assume anything about the original encoder's efficiency. it will be mostly be BD anyway, and that has a fixed I-frame interval [18:39:39 CEST] <JEEB> then if youtube and others are fine with ffms2 then you should be too [18:40:15 CEST] <void09> cehoyos: it might not be possible with ffmpeg, but by embedding ffmpeg in a little script to add that functionality [18:40:25 CEST] <cehoyos> With a bad vp9 encoding, you end up with n files for n scenes, all the same size as the original encoding;-) [18:40:43 CEST] <void09> cehoyos: I want to try AV1 [18:40:51 CEST] <cehoyos> I don't think a little script will be sufficient, especially since edit lists are not written [18:41:39 CEST] <void09> well, it does not have to be edit lists. can be a text file that records the frame offsets that need to be ignored [18:41:46 CEST] <void09> or even embed that info in the filename [18:42:59 CEST] <JEEB> anyways I know taht some applications take in EDL files ("edit lists") which have references to files and timestamps [18:43:03 CEST] <void09> you say ffmpeg does not support cutting with edit list info. but does it support decoding with taking edit lists into consideration ? [18:43:11 CEST] <JEEB> partially [18:43:22 CEST] <JEEB> it can be quite the shitshow with the GOOG-provided implementation [18:43:31 CEST] <void09> GOOG? [18:43:44 CEST] <another> google [18:44:40 CEST] <giaco> hello [18:45:04 CEST] <giaco> I have an unknown udp stream coming from a camera, and I want to identify it [18:45:35 CEST] <giaco> I have setup an offline network with wireshark in the middle and I see the packet stream in the subnetwork [18:45:35 CEST] <JEEB> I'd just have a list somewhere of where you want to split [18:45:39 CEST] <JEEB> (for encoders) [18:45:51 CEST] <JEEB> and then utilize something like ffms2 to easily get frame accurate access [18:45:55 CEST] <void09> ok then, how would you write this.. first get the scene change frame nubmers. then tell ffmpeg to cut at thosse frame intervals (by remuxing and adding extra frames up to the nearest I-frames, not re-encoding). and then running ffmpeg again so to find the nearest previous and next I-frame for every split frame point, and record those in the file [18:45:58 CEST] <giaco> how can I identify the stream? Get some info out of it? [18:46:00 CEST] <JEEB> and just read it simultanceously [18:46:16 CEST] <JEEB> (from each node with different spots they'd access) [18:46:37 CEST] <JEEB> audio can be done separately since it generally is fast enough to just encode in a single blast [18:47:02 CEST] <void09> JEEB: yeah, audio will be done on the server that manages the jobs, once all the encoded pieces are received [18:47:31 CEST] <another> void09: look into the segment muxer [18:47:33 CEST] <void09> especially since i don't think there are I-frames in an audio stream ? [18:47:49 CEST] <JEEB> another: he just needs the nice split points for his *encoder* [18:47:50 CEST] <void09> so cutting audio into little pieces will reduce encoding efficiency [18:48:05 CEST] <JEEB> void09: there are. generally all audio frames are separately decode'able [18:48:19 CEST] <JEEB> the problem is, there is such thing as "encoder delay" which is a PITA to handle :P [18:48:20 CEST] <another> void09: you can also look into https://github.com/klaxa/dist-enc [18:48:47 CEST] <void09> another: that's one of the projects i was eyeing [18:48:48 CEST] <JEEB> basically the first XYZ samples in the first audio frame will be encoder initalization stuff [18:48:57 CEST] <another> i'm currently working on a rewrite of it [18:49:09 CEST] <void09> JEEB: yeah whatever, I think a 2 hour 5.1 opus encode will not be so straining, I have a 12 core machine [18:49:15 CEST] <JEEB> yes, as I said [18:49:22 CEST] <JEEB> the audio will go through liek breeze :P [18:49:24 CEST] <void09> but a 2 hour av1 optimum encode will take 2 months [18:50:07 CEST] <JEEB> void09: I used to do split encoding with HM with avisynth over wine, but nowadays you have vapoursynth. pipe from vspipe then your python-scripted output to an encoder like ffmpeg.c or so [18:50:23 CEST] <another> void09: you can also look into https://pyscenedetect.readthedocs.io/en/latest/ [18:50:38 CEST] <JEEB> so you index you input file once, and then ffms2 will provide frame exact access [18:50:43 CEST] <void09> PySceneDetect is a command-line application and a Python library for detecting scene changes in videos, and automatically splitting the video into separate clips [18:51:00 CEST] <void09> oh wow, i knew about PySceneDetect but didn't notice it can do splitting too [18:51:15 CEST] <JEEB> then you have a thing generated for each worker, which together with the vpy file would generate the wanted segments [18:51:17 CEST] <another> well, it just calling ffmpeg [18:51:34 CEST] <JEEB> and then you just stitch the outputs together and walk home happy [18:52:07 CEST] <void09> vpy ? [18:52:11 CEST] <void09> too much new info here :) [18:52:35 CEST] <JEEB> vapoursynth python. basically normal python but utilizing the vapoursynth module [18:52:56 CEST] <JEEB> and vapoursynth is just a convenient way of using ffms2 effectively, instead of writing custom C code [18:52:58 CEST] <another> void09: altough note that klaxa's tool is a bit buggy [18:53:36 CEST] <void09> I cannot believe nobody thought to do this already.. perfectly optimized cutting & distributed encoding [18:54:13 CEST] <taliho> JEEB: Re: Probing: did you mean this patch? https://patchwork.ffmpeg.org/patch/12239/ or is there another one? [18:54:29 CEST] <JEEB> void09: mostly because you can do business with it :P [18:54:40 CEST] <JEEB> some people would probably be afraid of telling you what I already did [18:54:57 CEST] <void09> lol what? [18:55:08 CEST] <taliho> JEEB: that's already merged, but it only applies to probing of mpegts packets size [18:55:11 CEST] <JEEB> I don't disagree [18:55:22 CEST] <JEEB> taliho: yea I do remember there was something regarding data streams [18:55:34 CEST] <JEEB> the simplest way to skip that is to just revert the commit that started probing them [18:55:48 CEST] <JEEB> or add a codec id for the type of data you're encountering [18:57:28 CEST] <taliho> yes, that's sounds easier: add a codec id and initialize it from command line [18:57:56 CEST] <taliho> I'll try this idea [18:58:06 CEST] <JEEB> I don't think you can do it from cli [18:58:18 CEST] <JEEB> you have to actually figure out how the data stream is being marketed in the MPEG-TS [18:58:35 CEST] <JEEB> in other words, it's simpler to check which commit started probing the data streams [18:58:41 CEST] <JEEB> and see if that's revertable :P [18:59:20 CEST] <taliho> ok I see, I'll have a look at the history [19:00:55 CEST] <JEEB> I'll have to try my luck later with the radio channels I've seen and if the change you linked doesn't help with the probe time then I'll have to figure out how to improve that [19:01:08 CEST] <JEEB> because with low rate data streams you can easily be waiting for a minute [19:01:14 CEST] <JEEB> for the probe to get enough data [19:02:17 CEST] <taliho> yep :( it's a pain [19:06:57 CEST] <void09> JEEB: there's business in cloud transcoding clips ? [19:07:20 CEST] <void09> video* [19:07:20 CEST] <JEEB> just look at the various services doing that? [19:07:20 CEST] <void09> unless you have a shit ton of video.. who would pay for that [19:07:20 CEST] <void09> noobs? [19:07:43 CEST] <JEEB> quite a lot of places just want video out quickly, with multiple variants [19:07:52 CEST] <JEEB> and ready to pay for it [19:08:13 CEST] <JEEB> some interfaces to automate it all into their media creation/receival systems, and voila :P [19:10:26 CEST] <void09> https://cloud.qencode.com/# - 2 hours of 1080p encoding . $57 [19:10:31 CEST] <void09> AV1* [19:14:20 CEST] <giaco> no hint on how to inspect an unknown udp stream? [19:16:54 CEST] <another> ffprobe ? [19:17:54 CEST] <JEEB> ffprobe -v verbose -i udp://blah [19:26:17 CEST] <giaco> JEEB: with wireshark I see that the stream gets broadcasted into my subnetwork (192.168.8.255) [19:26:46 CEST] <giaco> is it ffprobe -v verbose -i udp://192.168.8.255 ? [19:28:57 CEST] <another> you need to take the source ip [19:29:22 CEST] <DHE> you definitely need the port [19:29:26 CEST] <DHE> :1234 or whatever [19:30:07 CEST] <taliho> JEEB: The issue for me is that if an mpegts stream contains a binary stream (AVMEDIA_TYPE_DATA) it is assigned st->codecpar->codec_id = AV_CODEC_ID_NONE. So probe_codec() will continue probing because of utils.c:749 [19:30:24 CEST] <taliho> and probe_codec() cannot identify the codec becuase it's some random binary data [19:30:29 CEST] <JEEB> yup [19:30:34 CEST] <JEEB> and often low bit rate data [19:30:41 CEST] <taliho> so shouldn't I be create a dummy decoder (i.e. AV_CODEC_ID_DUMMY) and set it with: ./ffmpeg -f mpegts -codec:d:0 dummy -i udp://blah ... -map etc [19:30:41 CEST] <JEEB> so it's not gonna get much of it [19:30:55 CEST] <JEEB> taliho: usually the demuxer sets that [19:31:04 CEST] <JEEB> so I'd be surprised if you could do that :P [19:31:40 CEST] <taliho> I see. I'll have a look [19:31:43 CEST] <taliho> thanks [19:37:07 CEST] <AlexVestin> Im having issues freeing/closing resources when using the ffmpeg cuda implementation, does anyone know how to close the cuda session? [19:38:57 CEST] <AlexVestin> I've tried some combinations of using the driver API with the ffmpeg provided free methods but still hit the 2 encoding streams limit when doing encodings sequentially [19:39:24 CEST] <giaco> DHE: thanks [19:41:22 CEST] <kepstin> AlexVestin: specifically, you're using avcodec_free_context() to close and free the encoder? [19:42:33 CEST] <AlexVestin> kepstin it throws errors when called so I tried with the av_buffer_unref [19:43:09 CEST] <AlexVestin> Im basically using the setup from this SO post: https://stackoverflow.com/questions/49862610/opengl-to-ffmpeg-encode/503399… [19:43:18 CEST] <kepstin> av_buffer_unref has nothing to do with closing an encoder [19:47:34 CEST] <kepstin> AlexVestin: when you say "throws errors", you are of course putting those errors into a pastebin somewhere so we can see them, right? [19:48:08 CEST] <AlexVestin> hehe of course, it's a short one malloc_consolidate(): invalid chunk size [19:48:45 CEST] <kepstin> did you call the function on the wrong thing? It needs to be passed the address of a pointer to a heap-allocated AVCodecContext. [19:50:35 CEST] <kepstin> note that it frees the codec context, so to start encoding another stream you'll have to allocate and set up a new codec context. [19:51:50 CEST] <AlexVestin> yeah, two sessions work fine so I think the re-opening works [19:52:33 CEST] <AlexVestin> the context is allocated with c = avcodec_alloc_context3(codec); [19:53:03 CEST] <kepstin> in theory, it should be the avcodec_free_context() that closes the encoder and the cuda encoder context. Without that you'd *definitely* be leaking them. [20:18:56 CEST] <AlexVestin> Yeah I think I might be doing something wrong before I try to free the context, I'll try to isolate the problem [20:30:16 CEST] <AlexVestin> this reproduces the error: https://pastebin.com/b0z1cEsK [20:59:08 CEST] <AlexVestin> seems like these free the same memory https://github.com/FFmpeg/FFmpeg/blob/95e5396919b13a00264466b5d766f80f1a4f7… [21:02:17 CEST] <AlexVestin> (Or I get a `free(): double free detected in tcache 2` here at least) [21:11:04 CEST] <AlexVestin> it also gets freed here when hw_frames_ctx gets freed https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281… [21:13:17 CEST] <void09> blah, is there no video player that can jump to a very specific time or frame ? [21:14:50 CEST] <BtbN> That's oftentimes not trivially possible, and mostly not needed [21:16:52 CEST] <void09> I fail to understand what's not trivially possible about it [21:17:54 CEST] <void09> are there no timestamps/frame ids in an mkv video ? [21:20:18 CEST] <kepstin> very specific time is easy, many players support that (e.g. mpv) [21:20:24 CEST] <kepstin> at least for files with indexes [21:20:28 CEST] <kepstin> specific frame is hard [21:20:38 CEST] <void09> but for constant fps video, how is that hard? [21:20:52 CEST] <void09> you convert time into frame [21:20:56 CEST] <kepstin> indexes don't include frame numbers, so only way to get a specific frame is to decode from the start and count [21:21:13 CEST] <kepstin> a lot of video formats don't really do "constant fps" [21:21:34 CEST] <kepstin> constant fps just means that the pts increases by about the same amount (modulo rounding errors) each frame [21:22:21 CEST] <kepstin> if you know that a video is constant fps through other information, then you can feel free to do the conversion to time yourself, then seek to time. [21:22:46 CEST] <void09> yes, but i found no video player to allow this [21:22:52 CEST] <void09> only to the second [21:23:00 CEST] <kepstin> mpv supports subsecond seeking just fine [21:23:05 CEST] <void09> how? [21:23:17 CEST] <void09> oh, I forgot to mention, through a gui [21:23:33 CEST] <kepstin> well, you can write arbitrary guis in mpv with lua :) [21:23:43 CEST] <kepstin> the default gui probably doesn't have something for that, yeah [21:24:53 CEST] <kepstin> but you can tell mpv to start at a particular point in a video with frame accuracy by running with the --start option [21:27:37 CEST] <void09> I am trying to verify the accuracy of pyscenedetect scene detection (and the subsequent cutting) [21:28:30 CEST] <Hello71> heh [21:29:38 CEST] <void09> and it seems 1 frame off, at least. there's a scene ending at timecode 00:00:33.000. i play mpv with that timecode, paused, and i get the first frame of the next scene [21:29:47 CEST] <void09> or maybe i am missing some basic maths [21:32:33 CEST] <void09> scene starts are accurate though. it's just the end timecode corresponding with the first frame of the next scene [21:32:34 CEST] <void09> any idea? [21:33:45 CEST] <JEEB> end of a video frame usually is the start of the following one? [21:33:53 CEST] <kepstin> yeah, that seems right [21:34:01 CEST] <JEEB> as in, pts + duration = usually pts of packet+1 [21:34:03 CEST] <kepstin> a frame is displayed until the next frame replaces it [21:34:11 CEST] <kepstin> so the end of a frame is the moment that the next frame appears [21:35:10 CEST] <void09> damn, that makes sense [21:35:59 CEST] <void09> ffmpeg does support ignoring the first x frames and the last y frames, when decoding a video ? [21:36:25 CEST] <kepstin> you'd use the -ss and -to options to do that, normally. [21:36:35 CEST] <kepstin> but those take times, not frames [21:36:40 CEST] <kepstin> conveniently, you have times. [21:37:16 CEST] <TheAMM> There's the trim filter [21:37:38 CEST] <kepstin> (note that in this case, you'd normally want to use both -ss and -to as input options, so it can do fast seeking, and the timestamps -to uses are input timestamps) [21:37:50 CEST] <TheAMM> If you only have to skip a few frames and know exactly how many you want to skip [21:38:46 CEST] <kepstin> the trim filter operates on decoded video, and the reason it can work with frame numbers is because it sees every frame from the start and counts them. [21:39:38 CEST] <void09> I have times, I guess, it's just that frames looked like a better, more accurate, option [21:39:44 CEST] <void09> as they're just integers [21:40:20 CEST] <kepstin> mkv (as written by most muxers) stores frame timestamps in milliseconds [21:40:28 CEST] <kepstin> so millisecond timestamps are exact [21:42:26 CEST] <JEEB> void09: frames are more exact but the FFmpeg framework doesn't work in frames seeking-wise. so, uh, yea [21:42:34 CEST] <JEEB> write your own indexer or use ffms2 [21:42:43 CEST] <void09> timestamps will have to do then [21:43:19 CEST] <void09> problem is, when splitting a video with pyscenedetect, using -copy (uses mkvmerge instead of ffmpeg to split losslessly).. [21:43:51 CEST] <kepstin> keyframes don't necessarily line up with your detected scene cuts, so there's no guarantee that will work [21:43:58 CEST] <void09> I get no refference of the original time in the video file, and don't know how to compute the extra frames added when cutting [21:45:00 CEST] <void09> kepstin: yeah, that's what I am talking about. I want to get the extra frames in the video file, thare are not in the scene as detected by pyscenedetect, so i can ignore them (with ffmpeg -ss -to?) [21:45:34 CEST] <kepstin> void09: if you're doing stuff with ffmpeg, why not use ffmpeg with -ss and -to directly on the original file? [21:46:26 CEST] <void09> kepstin: I want to split a long video into scenes (the place where an encoder would put an I-frame), but without re-encoding bits that don't match with the I-frame [21:46:59 CEST] <void09> and with keeping track of how many extra frames are in each cut piece, so I can skip them when re-encoding the pieces [21:47:13 CEST] <kepstin> you should really be writing a custom application using ffmpeg apis [21:47:23 CEST] <void09> I'm not a coder :( [21:47:40 CEST] <JEEB> then ffms2 through vapoursynth and some python scripting? [21:47:42 CEST] <kepstin> also note that re-encoding only pieces of a video is hard unless you know the encoder and options used on the original [21:47:42 CEST] <void09> and this is not commercial, otherwise I'd hire someone [21:48:15 CEST] <void09> kepstin: not sure i follow that. why should it be hard ? [21:48:39 CEST] <JEEB> I think he means getting an exact cut with minimal re-encoding [21:48:43 CEST] <JEEB> which is not what you want [21:48:52 CEST] <JEEB> your stuff is jsut really easy to misunderstand :P [21:48:54 CEST] <void09> yeah, no re-encoding at all for me [21:49:05 CEST] <kepstin> if you don't re-encode, then you can't get exact seeking [21:49:14 CEST] <JEEB> you can [21:49:17 CEST] <JEEB> index with ffms2 or so [21:49:35 CEST] <void09> I'll have to look into that ffms2 of your later JEEB [21:49:55 CEST] <JEEB> index once, then frame exact access through that index [21:50:02 CEST] <JEEB> and frame based access [21:50:10 CEST] <JEEB> it uses FFmpeg underneath [21:50:14 CEST] <JEEB> the libraries [21:52:06 CEST] <void09> oh I see. so something ffmpeg should have had in the first place [21:52:32 CEST] <JEEB> dunno, it's a rather specialized use case and it's better served by an API client that specifically utilizes the functionality for that use case [21:52:36 CEST] <kepstin> nah, it's really a special case thing for people who explicitly need seeking by frame number [21:52:58 CEST] <JEEB> of course you could put it into ffmpeg.c [21:53:02 CEST] <kepstin> an external library makes sense, especially given that you should only get the frame number index if you opt in [21:53:20 CEST] <JEEB> but yea, vapoursynth is on linux probably the simplest way to utilize ffms2 [21:53:39 CEST] <JEEB> you can make yourself a vapoursynth python script that loads up a list of things [21:53:47 CEST] <void09> vapoursynth is another thing I have to look into [21:53:56 CEST] <kepstin> void09: i'm missing a bit of your overal use case for this stuff, it might be that we're getting into complex solutions to a simple problem. [21:53:56 CEST] <JEEB> like, if you have a file where you have exported how the jobs look like [21:54:09 CEST] <void09> kepstin: distributed "lossless" encoding [21:54:18 CEST] <JEEB> uhh [21:54:25 CEST] <JEEB> what does that lossless mean there? [21:54:27 CEST] <void09> I want to encode some movies into av1, and a 1080p 2 hour movie takes ~1-2months to encode on a single PC [21:54:33 CEST] <kepstin> so not lossless [21:54:45 CEST] <JEEB> void09: you're unneceassarily confusing people :P [21:54:47 CEST] <void09> lossless as in, i do not want to lose quality when distributing vs encoding on a single machine [21:54:54 CEST] <void09> sorry :) [21:54:59 CEST] <kepstin> void09: ah, right, i remember you. [21:55:11 CEST] <void09> lol yeah I obsess about this [21:55:24 CEST] <JEEB> anyways, do your scene detection and export a file that your vapoursynth script will take in on each worker [21:55:37 CEST] <JEEB> then have a network drive or something else that all the workers will access [21:55:44 CEST] <kepstin> if every worker has access to the full original file this is trivial [21:56:02 CEST] <void09> oh wow I have not thought of that [21:56:05 CEST] <kepstin> just get your seek points from the detection, then run ffmpeg with -ss -to to encode the segment, then concatenate after [21:56:09 CEST] <void09> giving access to the full file :O [21:56:22 CEST] <void09> omg [21:56:25 CEST] <JEEB> file + index [21:56:26 CEST] <JEEB> done [21:56:43 CEST] <void09> what would ffmpeg allow as a remote ? http works? [21:56:46 CEST] <kepstin> or index if you want to use frame numbers, but the extra accuracy may or may not be needed. [21:56:52 CEST] <kepstin> http works, ffmpeg can seek over http [21:56:56 CEST] <kepstin> make sure the file has an index [21:57:14 CEST] <void09> what kind of index ? [21:57:19 CEST] <kepstin> a seek index [21:57:28 CEST] <void09> is this something that mkv files usually have? [21:57:30 CEST] <kepstin> yes [21:57:39 CEST] <void09> oh, so nothing special then. yes, they are proper mkv files [21:59:24 CEST] <void09> thanks kepstin, I was so stuck on what I thought was the optimal solution, that I missed the obvious :) [23:34:43 CEST] <sagax> hi all! [23:34:49 CEST] <sagax> how to crop a video? i want to change the aspect ratio. [23:35:05 CEST] <sagax> change aspect ratio with crop [23:36:16 CEST] <sagax> through crop video [00:00:00 CEST] --- Thu Sep 26 2019

1 0