Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2016

1 participants
62 discussions

ffmpeg-devel.log.20161025
by burek 26 Oct '16

26 Oct '16

[03:06:25 CEST] <cone-656> ffmpeg 03Michael Niedermayer 07master:c1173437fc3e: avcodec/ffv1enc: Fix storing RGB48 without explicitly set level [05:09:49 CEST] <cone-656> ffmpeg 03Michael Niedermayer 07master:85d23e5cbc9a: avcodec/interplayvideo: Check side data size before use [05:15:07 CEST] <philipl> http://imgur.com/a/6rhiY [05:47:42 CEST] <TD-Linux> wow I never realized those were physical cards [05:56:13 CEST] <Compn> that looks like a small case [06:37:19 CEST] <Matador> Hows it goin ? [06:40:16 CEST] <Matador> Anyone want to squash a huge bug and save the planet ? :) [06:45:40 CEST] <Compn> which one ? qsv ? [06:46:01 CEST] <Compn> theres a patch to fix it on the ml [06:50:19 CEST] <Matador> nice [06:50:40 CEST] <Matador> should fix a few bugs like.. https://trac.ffmpeg.org/ticket/5848 [06:51:54 CEST] <Matador> this is going to save the world [06:52:53 CEST] <Matador> Intel CPU h264.. using ~50% CPU encoding standard h264 720p sort of thing.. using ~50 watts roughly (1/2 the TDP) [06:53:11 CEST] <Matador> qsv uses few watts gpu, and < 10% CPU same setting [06:53:24 CEST] <Matador> like 30-40 watt savings per encode [06:56:31 CEST] <rcombs> somehow I doubt the world's primary consumer of power is QSV encodes [06:57:31 CEST] <Matador> Many people use transcoding even though they dont even know it [06:57:44 CEST] <Matador> like OBS, Wirecast, Handbrake, Adobe programs, etc.. [06:58:24 CEST] <Matador> Whoever is responsible for solving QSV crash in ffmpeg, gets all the praise and a $$ financial bounty from me [07:02:24 CEST] <rcombs> hear that, jkqxz? [07:02:52 CEST] <Matador> just checkin the threads now [07:03:18 CEST] <rcombs> actually that reminds me of something [07:03:37 CEST] <Compn> Matador : i think jkqxz is the one who posted the patch [07:04:18 CEST] <rcombs> michaelni: I think I offered a bounty on an swscale thing years ago, and then you pointed out there was already an option for what I wanted, and I walked it back [07:04:32 CEST] <rcombs> if you think that was unfair I can pay out whatever I originally offered [07:05:21 CEST] <Matador> I'm checkin Compn [07:05:28 CEST] <Matador> because there are a few patches [07:06:15 CEST] <Matador> I'm seein a patch from "Nablet Developer" [07:07:41 CEST] <rcombs> the Developer family has produced many great engineers for generations [07:08:05 CEST] Action: Compn going sleep sleep [07:08:07 CEST] <Compn> nigh [07:08:36 CEST] <Matador> so I guess I should try a new build [07:26:36 CEST] <rcombs> if a decoder receives a drain packet, then is flushed, should it be able to be used again afterwards (with new data)? [07:26:47 CEST] <rcombs> or if it's flushed, then receives a drain packet [07:26:50 CEST] <rcombs> (i.e. size=0) [07:31:34 CEST] <Compn> huh sam zoy guy made a patch [07:43:33 CEST] <philipl> Compn: mini itx case so i didn't have a slot for the adapter. had to use the u.2 connector. [10:34:02 CEST] <rcombs> oh, I wonder if an issue wm4 had a patch for [12:51:02 CEST] <wm4> rcombs: no [12:51:30 CEST] <rcombs> OK, separate seeking issue [13:10:07 CEST] <michaelni> rcombs, i dont remember and no i dont think its unfair and It happens all the time btw, just recently someone ofered me 5k for some feature we already have IIRC. Of course if you want to donate something ... [13:10:41 CEST] <rcombs> hah, nice [13:46:36 CEST] <cone-402> ffmpeg 03Carl Eugen Hoyos 07master:134233972e79: lavc/utvideoenc: Set bits_per_coded_sample for rgba. [16:49:57 CEST] <ubitux> M_PI is not available in C11, wuut [16:50:20 CEST] <bencoh> how is it called now? :/ [16:50:45 CEST] <ubitux> it doesn't exist [16:50:48 CEST] <bencoh> wtf [16:51:28 CEST] <nevcairiel> does it have M_TAU? :D [16:53:25 CEST] <bencoh> hm, apparently it wasn't supposed to be in c99 either, so we're all just abusing compiler-specific sugar [16:58:26 CEST] <atomnuker> the fortran way is to just #define M_PI (atan(1)*4) [17:12:46 CEST] <Chloe> ubitux: none of the standards define M_PI iirc [17:13:25 CEST] <ubitux> yeah, unfortunately [17:30:30 CEST] <iive> yeh, new C standards put all kinds of crap, but having a PI ... [17:31:33 CEST] <bencoh> huhu ... [18:25:20 CEST] <DHE> slightly off-topic, is there documentation online about the H264 bitstream format? I want to write my own bsf for h264. [18:28:44 CEST] <nevcairiel> The spec has all you need [19:26:11 CEST] <Compn> DHE : do you need a copy of the spec? [19:27:42 CEST] <DHE> Compn: I guess.. [19:55:24 CEST] <ubitux> the specs is free afaik [19:56:05 CEST] <ubitux> https://www.itu.int/rec/T-REC-H.264 [19:57:15 CEST] <DHE> the old versions have links, but the current "in force" version doesn't on my screen.. [19:57:32 CEST] <ubitux> do you really need the "current"? [19:58:11 CEST] <DHE> ... probably not [20:03:07 CEST] <tmm1> rcombs: did you have a WIP patch for videotoolbox decoder + reordering frames? [21:12:36 CEST] <rcombs> tmm1: I had one that used timestamps, but that doesn't help for streams that lack those [21:19:09 CEST] <BBB> DHE: also, feel free to ask questions in this channel (or in #x264dev), theres a fair number of devs with h264 experience here [21:20:44 CEST] <tmm1> rcombs: would be interested in trying it out if you have it available somewhere [21:21:25 CEST] <rcombs> tmm1: might be very out of date: https://gist.github.com/3b30aa3f2e68dbe726d63a19319c601e [21:27:31 CEST] <tmm1> rcombs: thanks [21:31:32 CEST] <DHE> BBB: thanks, I'm hoping that being able to break the stream down into SEI fragments (if that's the term) will meet my needs. [21:33:31 CEST] <ubitux> for subtitles negociation (query formats) in lavfi; should we have something filter that supports text|bitmap? [21:36:41 CEST] <ubitux> i guess that will do [21:53:06 CEST] <rcombs> ubitux: I don't quite understand the question [21:53:37 CEST] <rcombs> ubitux: are you asking if there should be a filter that converts text subs to a series of bitmaps? (seems sane enough) [21:54:22 CEST] <ubitux> the question is on what basis the filters will decide whether they support or not the given input subtitles (and what they can output) [21:54:46 CEST] <ubitux> similar to pix fmt for video, i was guessing filter will just say "i support text" "i support bitmap" "i support both" [21:55:01 CEST] <ubitux> not sure what to do about teletext yet though [21:55:14 CEST] <ubitux> one of/the only one without caps [21:55:34 CEST] <rcombs> maybe teletext should export two AVCodecs [21:55:54 CEST] <rcombs> one for decoding as text and one for as bitmaps [21:56:40 CEST] <rcombs> ubitux: what do you think of the concept of having a pair of filters for text->bitmap (libass) and bitmap->text (tesseract)? [21:57:17 CEST] <ubitux> i'm fine with that but i belive the text->bitmap will be [V][S] [V] [21:58:04 CEST] <rcombs> yeah, generally, but I think it'd be good to have the rendering separable from the overlaying [21:58:24 CEST] <rcombs> so that if we want to do overlay directly onto hardware surfaces, the subtitles filter doesn't have to handle that itself [21:58:34 CEST] <ubitux> yes, it might be useful to have a [S] [V] which outputs bitmaps of different size too [21:58:45 CEST] <ubitux> i did that with the api a while ago, i would love to do it thanks to lavfi [21:58:53 CEST] <ubitux> (to extract every subtitle "picture") [21:59:43 CEST] <rcombs> relatedly: is there a format available that matches what libass outputs (series of [alpha-only bitmap + RGBA color]), rather than series of RGBA bitmaps? [22:00:32 CEST] <ubitux> i don't understand the question [22:00:56 CEST] <rcombs> so, imagine that you're trying to blend subtitles into a hardware surface-backed frame [22:01:19 CEST] <rcombs> libass outputs a series of alpha-only bitmaps, each with an RGBA color value [22:01:48 CEST] <rcombs> if you're going to do a text->bitmap filter, and then a separate blend-bitmaps-into-hardware-surface filter [22:02:21 CEST] <rcombs> then blending the alpha-only bitmaps into a single RGBA bitmap to send to the second filter would usually be inefficient [22:02:47 CEST] <rcombs> it'd (usually) be faster to just have the second filter take the alpha-only bitmaps and upload those [22:02:54 CEST] <rcombs> this is what mpv does [22:02:58 CEST] <rcombs> for playback [22:04:14 CEST] <rcombs> does that make sense? [22:10:22 CEST] <ubitux> not sure: decoders output alpha-only bitmaps, don't they? they can't blend it themselves. then there is nothing else than libass doing rasterization. so yeah, maybe a libass filter would take text and output directly into the final surface (so the filter would take both in text and in video) [22:17:05 CEST] <rcombs> ubitux: my issue with doing it in the subtitles filter is that the process for blending might be significantly different depending on the frame type (software, VAAPI, DirectX, etc&) [22:17:30 CEST] <rcombs> which is fine if there are routines for this exposed somewhere (drawutils?) [22:17:50 CEST] <rcombs> I just don't want to have to duplicate all that code everywhere that wants to draw stuff efficiently [22:17:59 CEST] <ubitux> but didn't you say libass can output there directly? [22:18:13 CEST] <ubitux> s/output there/blend on these surfaces/ [22:18:23 CEST] <rcombs> libass outputs alpha-only bitmaps; it doesn't know anything about hardware surfaces [22:18:56 CEST] <ubitux> i thought it had blending code, but i guess i'm confused with mpv? [22:19:09 CEST] <ubitux> (where is the blending code asm?) [22:19:33 CEST] <ubitux> vf overlay handles the blending relatively fast but no asm so far iirc [22:19:37 CEST] <rcombs> I've been looking into doing RGBA blending within libass, but that's down the line, and won't be the most efficient option in all cases [22:20:34 CEST] <rcombs> (I look forward to getting rid of sub2video; that's often a significant perf hit right now) [22:20:52 CEST] <ubitux> i should have the lavfi part "soon"© [22:21:01 CEST] <ubitux> then i'll have to deal with encoding [22:21:08 CEST] <ubitux> and the chain is complete [22:23:41 CEST] <ubitux> non working code (at all) @ https://github.com/ubitux/FFmpeg/compare/subtitles-frame-tmp [22:23:54 CEST] <ubitux> but it gives an overview [22:24:12 CEST] <ubitux> sub frame with ref counting should be working, lavfi structure soon in place [22:24:20 CEST] <ubitux> anyway. [22:32:31 CEST] <ubitux> mmh, so we configure the input graph before opening the codec context [22:32:34 CEST] <ubitux> that's interesting [22:55:31 CEST] <jamrial> ubitux: if you mean in ffmpeg.c, the upcoming merges afaik shake that up a bit [23:07:24 CEST] <ubitux> i'm patiently waiting then [23:17:56 CEST] <cone-567> ffmpeg 03Yogender Gupta 07master:f524275ef938: avfilter/scale_npp: fix passthrough mode [23:36:44 CEST] <michaelni> btw, anyone wants to write release notes for 3.2 ? [23:39:20 CEST] <llogan> "See Changelog" [00:00:00 CEST] --- Wed Oct 26 2016

1 0

ffmpeg.log.20161025
by burek 26 Oct '16

26 Oct '16

[00:11:27 CEST] <Phi> Can someone confirm the avcodec.h line 102 [00:12:27 CEST] <Phi> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob_plain/HEAD:/libavcodec/avcode… [00:12:48 CEST] <Phi> In the scenario you're decoding from one, stripping pictures out for display, then re-encoding [00:15:16 CEST] <Mavrik> Confirm what exactly? [00:15:23 CEST] <Phi> For decoding, call avcodec_receive_frame [00:15:28 CEST] <Mavrik> (Your link doesn't include line numbers, I suggest linking doxygen next time.) [00:15:31 CEST] <Phi> For encoding, call avcodec_receive_packet [00:15:36 CEST] <Phi> both are receive [00:16:02 CEST] <Phi> do I then still have to call av_write_frame to output to MP4? [00:16:14 CEST] <Phi> or is that handled by the encoder? [00:17:03 CEST] <Mavrik> You have to write your data to muxer youself. [00:17:09 CEST] <Mavrik> This a codec api. [00:17:14 CEST] <Mavrik> Which is separate from muxers :) [00:17:57 CEST] <Phi> rats [00:18:01 CEST] <Phi> I'm suing [00:18:27 CEST] <Phi> ...wait, what? [00:18:40 CEST] <Phi> you receive a packet from the encoder, then you write a frame? [00:22:57 CEST] <DHE> you send AVFrame's to the encoder, and receive AVPacket's from it [00:23:57 CEST] <Phi> urgh [00:24:02 CEST] <Phi> the thing is I have RTSP involved [00:24:46 CEST] <Phi> so does av_receive_frame from RTSP's FormatContext return a H264 frame or NALs to decode to H264 then decode to YUV420P then encode to a new output H264 then pass that into the MP4 [00:32:05 CEST] <Phi> there's like 8 different formats involved XD [00:34:12 CEST] <Phi> any idea DHE? [00:37:16 CEST] <DHE> an AVFrame is uncompressed (give or take colourspace ratios). avcodec_receive_frame gives an AVFrame as output. therefore it's a decoder [00:39:08 CEST] <Phi> so the output is a H264... [00:39:42 CEST] <DHE> *thunk* [00:39:46 CEST] <DHE> I said uncompressed [00:40:05 CEST] <Phi> if it makes you feel better, I'm new to video [00:40:21 CEST] <Phi> prior to this project I hadn't even worked with any rendering code [00:40:59 CEST] <Phi> so the avcodec_receive_frame is a YUV420P AVFrame? [00:41:52 CEST] <Phi> hm, I just worked out I'm decoding in two different ways [00:42:28 CEST] <Phi> but yeah, is it a YUV420P AVFrame? [00:45:08 CEST] <Phi> sempai [00:47:03 CEST] <klaxa> if your video was YUV420P then it should decode to a YUV420P AVFrame [00:47:48 CEST] <DHE> it most likely is. there's a "format" field in the AVFrame which should be equal to AV_PIX_FMT_YUV420P [00:58:31 CEST] <Phi> I shall observe [00:59:13 CEST] <Phi> so what's the method for converting YUV420P to BGR24? [00:59:20 CEST] <Phi> I was using the decode2 [00:59:28 CEST] <Phi> *avcodec_decode_video2 [01:00:42 CEST] <Phi> pfft [01:00:43 CEST] <Phi> XD [01:00:57 CEST] <Phi> so I was decoding from YUV420P to YUV420P [01:01:49 CEST] <DHE> avcodec_decode_video2 is the old API, combining avcodec_send_packet and receive_frame in one call [01:02:13 CEST] <Phi> what's confusing is avcodec_receive_frame receives to a AVPacket [01:02:33 CEST] <Phi> *av_read_frame [01:03:10 CEST] <DHE> ah, that's not avcodec. that's part of avformat. it reads a packet from an AVFormatContext [01:03:21 CEST] <Phi> hmm [01:03:47 CEST] <Phi> well atm I need an image to RGB24, and the frame to be passed to a H264 AVFormat encoder [01:04:52 CEST] <douglasbay> how can ffmpeg create private data in the adaptation field of a mpegts? I can create an asset with an adaptation field but the private data is 0 [01:05:39 CEST] <Phi> so I go av_read_frame to a packet, then pass it to avcodec_decode_video2 and get a YUV420P AVFrame (or AVPicture), then pass the YUV picture to a sws_scale and convert, and after that pass the packet to av_write_frame [01:06:32 CEST] <Phi> it looks like they scrapped got_picture [01:16:57 CEST] <Phi> I'm puzzled about avcodec_send_frame, it expects an AVCodecCtx but those are deprecated [01:20:12 CEST] <DHE> no, only some fields in it are [01:20:57 CEST] <Phi> AVStream->codec is marked as deprecated, what else should I use? [01:22:03 CEST] <klaxa> codec_par i think [01:22:44 CEST] <klaxa> *codecpar [01:25:29 CEST] <Phi> avcodec_send_packet wants a AVCodecCtx [01:26:23 CEST] <Phi> *avcodec_send_frame [01:26:53 CEST] <klaxa> Phi: what i do (and this doesn't go all the way down to decoding actually) is: https://github.com/klaxa/mkvserver_mk2/blob/master/server.c#L200 [01:27:02 CEST] <klaxa> not sure if that helps [01:28:32 CEST] <Phi> errr [01:28:40 CEST] <Phi> do you encode? [01:28:43 CEST] <klaxa> no [01:28:49 CEST] <klaxa> i only do (de)muxing [01:28:59 CEST] <Phi> hm [01:29:00 CEST] <klaxa> but i allocate the codec context [01:29:21 CEST] <Phi> I'll keep an eye on it [01:29:43 CEST] <klaxa> i took this from doc/example/remuxing.c and tried to remove the deprecation warnings [01:30:01 CEST] <Phi> I'm getting an error -1 when I'm using avformat_write_header [01:30:03 CEST] <klaxa> by looking at other code that already used the new codecpar api [01:30:09 CEST] <Phi> so I may need your code [01:32:29 CEST] <Phi> the thing is, I could keep a copy of the pointer to the codec context [01:32:34 CEST] <Phi> but it does seem kinda pointless [01:36:33 CEST] <Phi> DHE, if AVCodecCtx is not used why is AVStream::codec deprecated? [01:36:55 CEST] <Phi> ...why are my messages on this chat always a bit off with what I'm actually trying to say. [01:37:10 CEST] <Phi> if AVCodecCtx is used why is AVStream::codec deprecated? [01:37:29 CEST] <Phi> I changed the chat background colour to red [01:37:33 CEST] <Phi> maybe that'll fix up some things [01:42:49 CEST] <klaxa> why is it indeed [01:43:06 CEST] <klaxa> i would guess performance [01:43:44 CEST] <klaxa> seeing that now you have to explicitly allocate the codec with the help of codecpar i would assume that before this change codec was allocated and eventually not always needed [01:44:06 CEST] <Phi> I don't think it was allocated [01:44:39 CEST] <Phi> aformat_new_stream doesn't take any codec parameters, or even options [01:44:39 CEST] <klaxa> oh? well i don't know that [01:44:39 CEST] <klaxa> *then [01:44:41 CEST] <Phi> just a raw AVFormatContext and AVCodec [01:45:01 CEST] <Phi> I think they're not quite sure what they're doing, tbh [01:45:21 CEST] <Phi> probably a mislaid deprecation warning somewhere [01:45:56 CEST] <DHE> ffmpeg is many layers. the codec layer is just that - the codec. how you store it on disk is none of its concern as long as it gets back AVPacket's split up proprely [01:46:21 CEST] <DHE> streams are an avformat thing where a bunch of AVPacket's in sequence go to a single decoder [01:47:08 CEST] <Phi> in this case, I need the encoder [01:47:19 CEST] <Phi> hm [01:47:31 CEST] <Phi> can I just pass avformat_write_frame and pass the YUV420P stuff? [01:47:46 CEST] <DHE> no, it wants AVPackets [01:47:49 CEST] <Phi> the issue is up until now (and the reason I upgraded to v12) was the output MP4 always had the source H264 profile [01:48:22 CEST] <Phi> the other reason was that I spent so long trying to fix the output MP4 profile that v12 was released :p [01:51:31 CEST] <Phi> okay, so I have an AVPacket from an RTSP FormatContext's av_read_frame [01:51:44 CEST] <Phi> I also have an AVFrame from that AVPacket, presumably in YUV420P [01:52:44 CEST] <Phi> ...so how does that work [01:53:39 CEST] <DHE> .. well what do you want to do with them? [01:57:44 CEST] <Phi> I have RTSP FormatContext, and I want an output RGB24 image, and a MP4 FormatContext with a different H264 profile [02:00:50 CEST] <Phi> if I have multiple YUV420Ps in one AVPacket, I just need one RGB image [02:02:41 CEST] <Phi> does that help Mr. DHE [02:10:29 CEST] <Phi> klaxa: Do you have any encoding examples of v12? [02:10:39 CEST] <Phi> I've been through the git and they're lacking [02:11:47 CEST] <klaxa> v12 being what? [02:12:12 CEST] <klaxa> and probaly not, the project i linked was the first project i wrote with libav* [02:12:21 CEST] <klaxa> and still is [02:21:56 CEST] <Phi> v12 is the more recent one [02:22:01 CEST] <Phi> came out this Oct [02:22:09 CEST] <Phi> ...well, beta1 did [02:22:54 CEST] <Phi> yeah, both did, 2016-10-02 [02:27:29 CEST] <klaxa> the more recent what? [02:30:35 CEST] <DHE> Phi: the only way I know of to convert between formats is either swscale or a filter (which will just invoke swscale) [02:32:43 CEST] <llogan> Phi: what's v12? [02:32:59 CEST] <Phi> Libav 12 "Not Enough Trocadero" [02:33:05 CEST] <Phi> https://libav.org/download/ [02:33:10 CEST] <llogan> why are you asking FFmpeg about Libav stuff? [02:35:20 CEST] <Phi> because I get libav DLLs that ffmpeg C++ examples use [02:35:40 CEST] <llogan> Why don't use use the FFmpeg libraries? [02:37:09 CEST] <Phi> would there be any difference in usage? [02:37:36 CEST] <llogan> Maybe you are (understandably) confused about the name? libav* is the collective name of the FFmpeg libraries. Libav is a fork of FFmpeg, and they conviently decided to name themselves using a name FFmpeg histoically used. [02:37:36 CEST] <klaxa> yes [02:38:37 CEST] <Phi> no, not at all :p [02:38:46 CEST] <Phi> I shouldn't confuse libav with libav or libav* [02:39:19 CEST] <furq> i assume that was sarcasm, but just to be on the safe side [02:39:24 CEST] <furq> do not use anything from libav.org [02:40:27 CEST] <llogan> if you do want to use the fork, i suggest asking for help at #libav [02:42:14 CEST] <llogan> otherwise, just use the FFmpeg libraries instead [02:42:28 CEST] <Phi> so which would you recommend? [02:42:37 CEST] <llogan> Obviously I'm biased. [02:42:42 CEST] <furq> it's hard to guess which one #ffmpeg would recommend [02:42:45 CEST] <llogan> since I'm in #ffmpeg [02:43:00 CEST] <Phi> yes, but you must have reasoning for your bias [02:43:09 CEST] <Phi> we're all logical men here *snork [02:43:28 CEST] <furq> is libav actively developed any more [02:43:41 CEST] <llogan> I don't know what c++ examples you are referring to, but if they are using ffmpeg then there is little reason to use something else [02:43:43 CEST] <furq> it seemed to run out of steam a good while ago [02:43:47 CEST] <Phi> their last release was the 2nd, so it looks like it [02:43:55 CEST] <furq> also yeah if you're looking at ffmpeg's examples then obviously use ffmpeg's libs [02:44:28 CEST] <Phi> actually since one is a fork of the other then the examples don't really clarify things [02:44:46 CEST] <furq> it's a fork from like 2011 or so [02:44:54 CEST] <furq> there's been a lot of api changes since then [02:44:58 CEST] <Phi> why was it forked? [02:45:10 CEST] <furq> because some people got mad at michael niedermayer for some reason [02:45:21 CEST] <furq> the same reason any fork happens except with names changed [02:46:04 CEST] <Phi> never met the bloke [02:46:14 CEST] <Phi> guess that's another thing to add to my time travel list [02:47:43 CEST] <Phi> is there a difference in license? [02:48:33 CEST] <furq> i don't think that would be possible [02:49:24 CEST] <DHE> can't just change the license of someone else's code when forking it [02:49:43 CEST] <DHE> which includes when "someone else" is a whole team of people [02:51:02 CEST] <furq> you can do it if you have their permission, but somehow i don't think that was on offer [02:52:07 CEST] <furq> afaik the only reason libav ever had any relevance is that one of the forkers was also the debian ffmpeg maintainer, and he went ahead and decided that ffmpeg was dead and replaced it with libav for two releases [02:52:29 CEST] <furq> which is why we will eternally have ubuntu 12 users in here asking about it [03:02:34 CEST] <klaxa> what i found the worst offense was that the binary shipped was broken even! https://files.klaxa.eu/2014-08-16-002239_1280x800_scrot.png [03:03:19 CEST] <klaxa> (it was a puny laptop and i didn't have the time to compile ffmpeg) [03:03:38 CEST] <klaxa> literally took more than an hour back then instead of a few minutes now [03:13:03 CEST] <Phi> weeeelp [03:13:20 CEST] <Phi> the ffmpeg libraries result in my dll not working [03:13:51 CEST] <Phi> if only the program that used it provided error messages instead of "this dll no longer exists on this temporal plane" I'd be able to debug [03:16:03 CEST] <Phi> multidimensional irrational calculus is not my forté [03:19:47 CEST] <Phi> well, the probability engine gives me answer 42 [03:20:00 CEST] <Phi> which is... toolchain is GCC, not MSVC [03:20:21 CEST] <Phi> time to grab the source I guess [03:22:56 CEST] <Phi> well, I guess i can play some games on the clock while it downloads/makes [05:08:49 CEST] <Phi> well, recompile finished, time to see if it works [05:12:57 CEST] <t4nk748> hey, when i using -map 0:0 -map 0:1 -map 1:0 , how can I say the second audio stream is the default ? so that when i play the movie it choose the second audio automatically [05:19:22 CEST] <Phi> "external symbol _AcquireCredentialsHandleA is unresolved" [05:19:49 CEST] <Phi> looks like Secur32.dll [05:22:26 CEST] <Phi> linking Secur32.lib fixed it [05:23:50 CEST] <Phi> now my dll works, yay [05:30:12 CEST] <furq> t4nk748: -disposition:a:0 default [05:30:15 CEST] <furq> er [05:30:21 CEST] <furq> -disposition:a:1 default [05:44:28 CEST] <t4nk748> furq: thank you :) [05:49:22 CEST] <t4nk748> furq: i did it now but it didn't work! http://pastebin.com/mAGKAw4D [06:06:17 CEST] <Phi> alright folks, actual bug [06:06:19 CEST] <Phi> http://pastie.org/private/jt8mbywhjmkzjmfakou93g [06:06:38 CEST] <Phi> avcodec_open2 fails with error -542398533: Generic error in an external library [06:41:06 CEST] <Phi> broken ffmpeg default settings detected [06:47:58 CEST] <Karun> Hello. Is there any way to determine the format of a video file? I used an ffmpeg Java wrapper and I got "mov,mp4,m4a,3gp,3g2,mj2;" for an mp4 file. [06:49:36 CEST] <furq> those are all more or less the same format [06:50:49 CEST] <Karun> furq: Ah. Okay. So there's no way to get mp4 as the format? :) [06:52:23 CEST] <furq> http://vpaste.net/COooW [06:52:45 CEST] <Karun> furq: Awesome! Thank you so much. [06:52:49 CEST] <furq> http://www.ftyps.com/ [06:53:16 CEST] <furq> i don't know how reliable the tag is though [06:53:44 CEST] <furq> i imagine qt vs isom is a safe bet [06:54:37 CEST] <Karun> The java wrapper makes a key value map that has this - (major_brand,mp42) [06:55:07 CEST] <Karun> keyvalue bag* [08:54:24 CEST] <babadoc> hey guys [08:54:38 CEST] <babadoc> i have a question [08:54:48 CEST] <babadoc> if ffmpeg says a video is " Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p" [08:55:12 CEST] <babadoc> is that the .mp4 mime type? [08:55:19 CEST] <babadoc> i cant figure it out [08:55:38 CEST] <babadoc> is the mime type .h264 [08:55:54 CEST] <furq> that's the video codec [08:56:08 CEST] <babadoc> okay, so how can i find the extension that the video is suppose to be using [08:56:17 CEST] <babadoc> i ran ffmpeg -i msnamedfile.webm [08:56:21 CEST] <babadoc> and it gave me the codec [08:57:31 CEST] <furq> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4': [08:57:51 CEST] <babadoc> uh [08:58:27 CEST] <babadoc> where can i find that [08:58:34 CEST] <babadoc> ffmpeg -i should show it correct [08:58:50 CEST] <furq> yes [08:58:54 CEST] <furq> although you should be using ffprobe for this [08:59:00 CEST] <babadoc> okay [09:00:43 CEST] <furq> http://vpaste.net/cdn0K [09:01:42 CEST] <babadoc> http://pastebin.com/06Ww9p56 [09:01:47 CEST] <babadoc> okay, so let me see [09:01:54 CEST] <furq> Input #0, mpegts, from 'Oct24_2016_22_40_34.webm': [09:02:04 CEST] <furq> so the extension should be .ts [09:05:49 CEST] <babadoc> .ts? [09:05:52 CEST] <babadoc> what the hell is that [09:06:07 CEST] <beauty> ls [09:07:10 CEST] <beauty> how to know a fuction whether is thread safety??? [09:07:19 CEST] <beauty> for example avcodec_decode_video2 [09:12:53 CEST] <babadoc> alright thanks furq [09:12:58 CEST] <babadoc> you really have been a big help [09:13:05 CEST] <babadoc> :) [09:14:39 CEST] <babadoc> aw man furq [09:14:43 CEST] <babadoc> i have another problem [09:15:11 CEST] <babadoc> 76.91.0.160:8080 [09:15:20 CEST] <babadoc> if you go there you can see what the problem is.. [09:16:00 CEST] <babadoc> i tried putting the .ts file into a html video tag and it doesn't load the video, yet it still shows the correct time [09:16:03 CEST] <babadoc> its really weird [09:17:06 CEST] <babadoc> it works if i encode the video into mkv though. [09:17:13 CEST] <babadoc> i can watch it in a video tag [09:18:06 CEST] <furq> ts isn't supported in browsers [09:18:12 CEST] <furq> neither is mkv, so i don't know how that's working [09:18:23 CEST] <furq> remux it to mp4 [09:18:31 CEST] <nonex86> beauty: read the documentation [09:18:52 CEST] <nonex86> beauty: usually it warned about thread safety [09:18:55 CEST] <babadoc> you want me to show you what i mean [09:18:57 CEST] <babadoc> here [09:19:00 CEST] <babadoc> let me host the mkv file [09:19:16 CEST] <babadoc> wait [09:19:21 CEST] <babadoc> are mpeg files supported in browser? [09:19:26 CEST] <furq> no [09:19:39 CEST] <furq> only mp4 is supported in video tags in every browser [09:19:48 CEST] <furq> if mkv works i assume it's using a plugin [09:19:53 CEST] <babadoc> i dont have any [09:19:59 CEST] <babadoc> here [09:20:02 CEST] <babadoc> i can try hosting the mkv file [09:20:04 CEST] <babadoc> tell me if it loads [09:21:07 CEST] <babadoc> look, the link is http://192.168.0.5:8080/last25minutes.mkv [09:21:12 CEST] <babadoc> shit [09:21:14 CEST] <babadoc> dont click that [09:21:24 CEST] <furq> i don't think it would really matter if i did [09:21:27 CEST] <babadoc> 76.91.0.160:8080 go here and play it [09:21:28 CEST] <babadoc> yeah [09:21:30 CEST] <babadoc> i know its private [09:22:18 CEST] <furq> yeah that just downloads [09:22:21 CEST] <babadoc> wait [09:22:34 CEST] <babadoc> going to just the base ip? [09:22:38 CEST] <babadoc> with the port [09:22:40 CEST] <babadoc> 76.91.0.160:8080 [09:22:43 CEST] <babadoc> that downloads? [09:22:51 CEST] <furq> no [09:22:54 CEST] <furq> that just doesn't do anything [09:22:59 CEST] <babadoc> ... [09:23:20 CEST] <babadoc> is it a blank page [09:23:27 CEST] <furq> it has two broken video tags [09:23:31 CEST] <babadoc> two [09:23:32 CEST] <babadoc> okay [09:23:39 CEST] <ritsuka> just remux it to mp4& [09:23:43 CEST] <furq> ^ [09:24:05 CEST] <babadoc> for me it has only 1 broken [09:24:10 CEST] <ritsuka> h.264 -> mp4, vpwhatever -> webm [09:24:15 CEST] <babadoc> https://i.gyazo.com/e331aba8b25ce4c167fbf37ab84a0c93.png [09:24:20 CEST] <babadoc> look! it only has 1 broken [09:24:24 CEST] <babadoc> the mkv is working and i have no plugins [09:24:35 CEST] <ritsuka> yes it could work on your browser, but not on the 99% of the other browsers [09:24:48 CEST] <furq> the only interesting thing i could have got out of that image is what browser and os you're using, and you cropped that out [09:25:02 CEST] <babadoc> well [09:25:06 CEST] <babadoc> im using os x yosemite [09:25:07 CEST] <babadoc> and chrome [09:25:10 CEST] <babadoc> the most recent version [09:25:22 CEST] <babadoc> here "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36" [09:25:26 CEST] <babadoc> thats mine [09:26:00 CEST] <ritsuka> chrome probably uses the same demuxer for mkv and webm [09:26:06 CEST] <babadoc> hm. interesting [09:26:15 CEST] <babadoc> the only thing i care about is watching it on my end [09:26:16 CEST] <ritsuka> but it won't work in safari, firefox, etc& [09:26:20 CEST] <furq> https://www.youtube.com/watch?v=27jvjVkpCUA&t=6m18s [09:26:22 CEST] <furq> also this is more like it [09:26:23 CEST] <babadoc> because int he end im uploading it to youtube [09:26:37 CEST] <furq> if you're uploading it to youtube it makes literally no difference what container you use [09:26:41 CEST] <babadoc> yeah i kow [09:26:42 CEST] <babadoc> know [09:26:49 CEST] <babadoc> but i want to watch it on my end before i upload it to youtube [09:26:59 CEST] <babadoc> without downloading the 5gb file [09:27:22 CEST] <babadoc> which was accomplished with the mkv file that i copied [09:28:06 CEST] <babadoc> but i have to run ffmpeg -t 00:25:00 -i -c copy -bsf:a aac_adtstoasc first25minutes.mkv [09:28:10 CEST] <babadoc> with the webm video [09:28:16 CEST] <babadoc> and that runs very fast [09:28:21 CEST] <babadoc> like in a couple of seconds [09:28:34 CEST] <babadoc> but i dont want to copy it into a new file [09:28:36 CEST] <ritsuka> your original file is a .ts one, not webm :P [09:28:40 CEST] <babadoc> i know [09:28:45 CEST] <babadoc> i screwed up the filenames [09:28:54 CEST] <furq> i'm pretty sure i already recommended sshfs for this [09:28:55 CEST] <babadoc> that is the problem [09:29:03 CEST] <babadoc> what is sshfs [09:29:08 CEST] <furq> and by "i'm pretty sure" i mean i already checked the logs and i did [09:29:29 CEST] <babadoc> um [09:29:42 CEST] <babadoc> i have no recollection of this [09:30:02 CEST] <furq> you can mount your home directory on your server as a filesystem on your home computer [09:30:05 CEST] <furq> over ssh [09:30:18 CEST] <babadoc> okay [09:30:22 CEST] <furq> and then just play the files in a proper video player [09:30:38 CEST] <babadoc> i see [09:30:43 CEST] <babadoc> i will try to use this [09:30:49 CEST] <furq> https://github.com/osxfuse/osxfuse/wiki/SSHFS [09:30:53 CEST] <furq> i guess you want to read that [09:32:57 CEST] <babadoc> okay, i will try this [09:49:08 CEST] <babadoc> thanks furq, once again [09:49:11 CEST] <babadoc> you saved the day [09:49:26 CEST] <babadoc> i can't thank you enough [10:07:02 CEST] <gour> morning [10:08:45 CEST] <gour> i've ~TB of captured hi8 video footage stored as *.DV (http://pastebin.com/K1tPjkkV) and wonder what would be the best way to convert to some lossless format for archival purposes and still being able to use it as source material for video projects to be played on today's machines? [10:09:19 CEST] <furq> probably ffv1 or lossless x264 [10:10:05 CEST] <furq> everything else either compresses much worse, is too obscure, or decodes too slowly [10:11:27 CEST] <gour> furq: what will be estimated increase of space when converting to ffv1/x264? what resolution is realistic to get from such sources? [10:12:39 CEST] <furq> what's wrong with the format it's in now [10:12:51 CEST] <furq> or are you planning on capturing it again [10:14:06 CEST] <furq> actually nvm dv is digital isn't it [10:14:15 CEST] <furq> there's a clue in the name [10:15:09 CEST] <gour> no, i'd just convert from the current *.dv format into something better, if possible [10:15:37 CEST] <gour> the paste shows output of ffmpeg -i file.dv [10:15:49 CEST] <furq> the size increase depends on the source really [10:16:10 CEST] <gour> current DV is ~12G/hr [10:16:13 CEST] <furq> if it's already 28mbit at 576p then it shouldn't be that bad [10:17:01 CEST] <furq> 576p 4:2:0 rawvideo is only 118mbit [10:18:11 CEST] <gour> which format you would recommend then? [10:18:39 CEST] <furq> x264 is probably more widely compatible [10:18:45 CEST] <gour> thanks [10:18:58 CEST] <jya> how can I configure ffplay to use the Apple Audio Toolbox decoder? [10:19:36 CEST] <furq> gour: https://en.wikipedia.org/wiki/FFV1#Video_archiving [10:19:51 CEST] <furq> i think any h264 decoder can decode lossless h264, but i could be wrong [10:20:34 CEST] <furq> i'd probably pick whichever one runs faster and compresses better [10:20:35 CEST] <gour> furq: after converting to x264, is it realistic to produce output suitable for HD resolutions? in the past i was just creating DVDs (PAL res) [10:21:10 CEST] <furq> for a given definition of suitable [10:22:14 CEST] <furq> it's obviously not going to look great [10:28:01 CEST] <gour> even HD (1280x720) would be bad? [10:28:38 CEST] <pomaranc_> furq: decoder does not care if the input is losless [10:30:14 CEST] <furq> i've seen some hd releases which are upscaled from sd sources [10:30:23 CEST] <furq> they can look ok with enough filtering but it's never going to look as good [10:31:08 CEST] <gour> furq: i see...well, the main thing is that i preserve material the best i can [10:31:09 CEST] <furq> i wouldn't really know how you'd go about filtering it other than a lanczos/spline scale and then sharpening [10:31:13 CEST] <furq> there's doubtless much fancier stuff you can do [10:33:59 CEST] <gour> furq: e.g.? [11:02:57 CEST] <bencoh> hqx? :] [12:07:59 CEST] <pomaranc> can ffmpeg handle 12-bit h265 input? [13:42:40 CEST] <MINIMAN10000> gah! [13:43:11 CEST] <MINIMAN10000> ffmpeg -r 60 -i bugs.webm out.webm did make the video play at 60 fps but did not modify the audio playback rate [13:50:22 CEST] <MINIMAN10000> why is changing audio playback rate so bad why can't it just take any arbitrary audio playback rate [14:02:03 CEST] <MINIMAN10000> what the heck [14:02:18 CEST] <MINIMAN10000> ffmpeg -i final.flac -i bugs.webm -r 60 out.webm should be forcing the frame rate of the output file to 60 fps [14:02:39 CEST] <MINIMAN10000> i guess what i need is my input framerate forced then? [14:09:23 CEST] <MINIMAN10000> I ended up having to use audacity since I don't know of any sane way of handling it with ffmpeg which is disappointing :| hopefully it's just me not knowing a setting. [14:25:12 CEST] <nonex86> MINIMAN10000: honestly speaking cant understand, what do you want [14:26:28 CEST] <DHE> I think to speed up the video, both framerate and audio pitch [14:26:32 CEST] <MINIMAN10000> so the video was 25 fps. I wanted it to playback at 60 fps and have the audio play at that rate as well [14:26:43 CEST] <MINIMAN10000> DHE: I wanted pitch unchanged [14:26:52 CEST] <c_14> setpts atempo [14:27:17 CEST] <DHE> still confused [14:27:22 CEST] <c_14> https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20… [14:27:22 CEST] <MINIMAN10000> not only could I not figure out how to use atempo, you have do weird chaining because it only accepts 0.5 to 2 [14:28:36 CEST] <c_14> atempo=2,atempo=1.2 [14:30:31 CEST] <MINIMAN10000> I'll try out of curiosity but the inability to use any float value is more than enough reason to avoid doing it in ffmpeg. [14:31:27 CEST] <c_14> you can use floats [14:31:33 CEST] <MINIMAN10000> any float [14:31:45 CEST] <MINIMAN10000> it only accepts was it 0.5 to 2 [14:31:47 CEST] <c_14> write a patch modifying the atempo filter [14:31:54 CEST] <MINIMAN10000> sounds fair enough [14:32:09 CEST] <c_14> It's a deficiency in the used algorithm afair [14:32:33 CEST] <MINIMAN10000> I mean it sounds like you could have it be recursive or something [14:33:06 CEST] <c_14> iterative, but yes [14:33:42 CEST] <MINIMAN10000> Bugs bunny 60 fps http://puu.sh/rV1Bn/0bf2df626c.webm Is what I was making. The quality sounds better than the audacity tempo http://puu.sh/rV0TS/99b35f4f94.webm [14:35:19 CEST] <MINIMAN10000> nah nvm they sound the same [14:35:40 CEST] <MINIMAN10000> they sound weird when he says nighty night. but I assume that's just how it is. [14:37:44 CEST] <MINIMAN10000> It was a slow motion scene so I figured there were more frames drawn so I wanted to see the scene played back at 60 fps to sorta get an idea of what an old cartoon would look like at 60 fps [14:42:35 CEST] <nonex86> MINIMAN1000: use smooth video project [14:42:59 CEST] <nonex86> MINIMAN1000: or any other motion estimation software then [14:43:46 CEST] <nonex86> *motion interpolation [14:44:36 CEST] <JEEB> FFmpeg does have nowadays motion estimation [14:44:41 CEST] <JEEB> I mean, interpolation [14:44:53 CEST] <JEEB> please look at the docs regarding that stuff [14:45:45 CEST] <nonex86> JEEB: real interpolation or just frame blending? [14:47:55 CEST] <MINIMAN10000> Huh I didn't know that. First time I just frame interpolation was SVP ( Smooth video project ) but the free version is highly restricted in what it can do. [14:48:01 CEST] <MINIMAN10000> First time I saw* [14:48:20 CEST] <bencoh> you could have a look at avisynth as well [14:48:33 CEST] <MINIMAN10000> think i ran into a video trying to find SVP lol [14:49:02 CEST] <nonex86> some post in the net advise to use ffmpeg + vapoursynth plugin [14:49:08 CEST] <MINIMAN10000> Like the more I think about it the cooler frame interpolation on anime seems. [14:49:14 CEST] <nonex86> so i guess no native support in ffmpeg exists [14:49:18 CEST] <MINIMAN10000> ah [14:49:29 CEST] <nonex86> at least i cant find any reference [14:49:37 CEST] <JEEB> nonex86: actual motion interpolation [14:50:02 CEST] <nonex86> JEEB: interesting, but i cant find any reference to it :( [14:50:50 CEST] <nonex86> found this post https://ubuntuforums.org/showthread.php?t=2304500 dated 2015 nov [14:52:34 CEST] <bencoh> nonex86: https://ffmpeg.org/ffmpeg-filters.html#minterpolate [14:52:51 CEST] <nonex86> bencoh: thanks! [14:56:27 CEST] <nonex86> well, i checked my ffmpeg build, it not contains minterpolate filter and i cant find any reference in configure script... [14:59:44 CEST] <bencoh> nonex86: Date:Tue Aug 23 17:50:35 2016 +0530 avfilter: added motion estimation and interpolation filters [15:00:01 CEST] <bencoh> dunno which version you're using but it's still quite "young" :) [15:20:14 CEST] <nonex86> benoch: i see... well, my version is 3.1.4, release [15:46:10 CEST] <mad_ady> Hello all! I'm trying to build ffmpeg from source for an embedded device running ubuntu. [15:46:56 CEST] <mad_ady> I have the dependencies and I'm building it with "debuild -b -uc -us" [15:47:31 CEST] <mad_ady> the build process takes a while but eventually fails on some tests in ffprobe_xml [15:47:39 CEST] <mad_ady> make[2]: Target 'check' not remade because of errors. [15:47:53 CEST] <mad_ady> How do I build it "the debian way" skipping checks? [16:30:14 CEST] <nwoki> hi all. Is there a way to specify which of two webcams to use when streaming (via cmd line). [16:30:33 CEST] <nwoki> as of now I get a dialog which requires me to specify which webcam to use [16:40:54 CEST] <ChocolateArmpits> nwoki: Have you looked at the directshow page? https://trac.ffmpeg.org/wiki/DirectShow [17:29:40 CEST] <bencoh> 9 [17:29:40 CEST] <bencoh> woops [17:30:37 CEST] <ozette> 8 [17:31:05 CEST] <SchrodingersScat> 7 [17:32:22 CEST] <tontonth> 6.1 [17:34:23 CEST] <ozette> bencoh: you iniated a countdown chain, it simply can not be stopped. [17:35:12 CEST] <nonex86> Chuck Norris can do anything... even stop countdown chain [17:35:35 CEST] <ozette> oh noes [18:39:29 CEST] <Phi> mook [18:40:03 CEST] <Phi> I'm getting "broken ffmpeg default settings detected" with libx264 [18:40:10 CEST] <Phi> any idea how to fix? [18:40:22 CEST] <Phi> in the C++ [18:40:33 CEST] <Phi> not the cmdl [18:54:37 CEST] <BtbN> don't use some old ffmpeg version. [19:34:49 CEST] <zeryx> can I do something like ffmpeg -i something.mp4 -codec copy something.mp4? [19:35:19 CEST] <furq> if you mean overwriting the input file then no [19:35:32 CEST] <zeryx> essentially mutating it yeah [19:35:41 CEST] <zeryx> I don't want to create a new file between stages [19:36:42 CEST] <furq> that would just delete the input file [19:36:52 CEST] <furq> there are container-specific tools that can make limited inplace changes [19:36:58 CEST] <furq> if you want to edit metadata or something [19:41:44 CEST] <zeryx> ah kk [19:53:20 CEST] <thebombzen> so, I've got a high-FPS video I'm trying to slow down without re-interlacing the frames. but FFmpeg doesn't want to respect -vsync 0 for some reason. [19:54:10 CEST] <thebombzen> if I run ffmpeg -i input.mov -map 0:v -vf 'setpts=PTS*12.0' -c:v ffv1 output.nut [19:54:17 CEST] <ATField> Hello! If I have an original videofile, and a supposedly losslessly cut fragment from that videofile, can I check somehow whether or not that fragment is really a lossless cut (a cut without reencoding, any quality loss, etc)? [19:55:10 CEST] <thebombzen> the original video starts at lightly under 240 fps (i.e. 239.84) and it re-encodes it to 240 fps. so I tried using -vsync 0 but that actually changed nothing. [19:56:23 CEST] <thebombzen> not only did -vsync 0 not change the output fps compared to without it, it also didn't change the output tbr or tbc. am I missing something here? [19:56:52 CEST] <thebombzen> also, why is it outputting 240 fps instead of the input, which is 239.84? [19:57:41 CEST] <ChocolateArmpits> ATField: Use PSNR or compares eyeball waveforms in an NLE [19:57:45 CEST] <ChocolateArmpits> compare* [19:59:12 CEST] <ChocolateArmpits> thebombzen: Did you try setting the rate manually via -r ? [19:59:50 CEST] <thebombzen> ChocolateArmpits: I don't want to do that because I can't figure out the exact input framerate. 239.84 is weird. [20:00:13 CEST] <thebombzen> I know for example that 29.97 is actually 30000/1001, but 239.84 isn't a multiple of 1/1001. [20:00:35 CEST] <JEEB> it seems to be 24000/1001 * 10 [20:01:00 CEST] <JEEB> well not exactly it seems [20:01:14 CEST] <JEEB> >>> 240000 /1001 [20:01:15 CEST] <JEEB> 239.76023976023976 [20:01:15 CEST] <thebombzen> exactly. [20:01:29 CEST] <thebombzen> I don't want to use -r unless it's exact because that would drop frames. [20:01:51 CEST] <thebombzen> which is why I want to just take the timestamps and multiply them by 12, and get something that is "slightly less than 20 fps" [20:02:14 CEST] <thebombzen> the problem is using -vf 'setpts=PTS*12' combined with -vsync 0 still forces it to 240 fps and I don't know why, given that I'm using -vsync 0. [20:03:16 CEST] <thebombzen> I feel that I should be able to slow the video down by an integer multiple without any sort of forced framerate choice, using just setpts. but I don't know exactly how to achieve that given that -vsync 0 doens't like me. [20:03:57 CEST] <geri> how accurate is recording with the following setting? ffmpeg -f gdigrab -framerate 30 -i desktop out.mpg [20:04:12 CEST] <geri> is it likely that the framerate changes? [20:05:28 CEST] <thebombzen> okay so I used ffprobe to give me more info. apparently the r_frame_rate is 240/1 but the avg_frame_rate is 361440/1507 [20:05:47 CEST] <thebombzen> which is approximately... 239.84. Now, why would those be different. what is the actualy difference between those? [20:07:00 CEST] <ATField> ChocolateArmpits: Thanks. Is there a way to do that through ffmpeg commands? And if not, which NLE program would you recommend for that? [20:07:35 CEST] <Mad7Scientist> I have this thought -- if you take an HD h264/AVC video and compare it to the same video at 1/4 the pixel count encoded at MPEG2 at the same bit rate, if the viewer is far enough away to not see the resolution difference will the mpeg2 version look better? [20:07:39 CEST] <ATField> ChocolateArmpits: Also, is extracting the same frame from both files for comparison a viable option? Or it would mess things up \ be too convoluted? [20:07:39 CEST] <Maxz> hi, I choose ismv as container for storing a live video. I choose it because I can read while it is still not finished. My biggest issue now is it takes a lot of seek operations to read the file using "ffprobe". For example: 3.1G ismv file take "17406 seeks" (ffprobe -v 9 -loglevel 99 file.ismv). My question is: There is a way to accelerate this, keeping ismv? [20:08:33 CEST] <Mad7Scientist> geri, Windows I assume? [20:08:47 CEST] <Chocola2> ATField: Well ideally you would want to cut the part in the original video to match the start and duration. Are you sure it starts with a keyframe ? As for your next question, this is well possible but be sure to use same player. You can then compare the images using psnr filter in ffmpeg [20:09:02 CEST] <geri> Mad7Scientist: Windows 10 [20:09:36 CEST] <ChocolateArmpits> ATField: Be sure to have several image samples for comparison so you are more sure about this [20:09:39 CEST] <thebombzen> ATField: theoretically you could convert both to raw frames in the same pixel format and use diff. but I think it'd probably pretty inefficient. [20:09:57 CEST] <thebombzen> well they should already be the same pixel format. otherwise it's not lossless. [20:10:31 CEST] <ChocolateArmpits> thebombzen: depending on the format converted images could include additional time-based metadata which can invalidate results unless you know the addresses the mismatch can happen at [20:11:24 CEST] <geri> Mad7Scientist: is there a way to get a unix/utc timestamp in millisec, which tell me when the frame is recorded? [20:11:35 CEST] <geri> has been [20:13:10 CEST] <ChocolateArmpits> geri: are you sure there is timecode data or that timestamps match real time ? [20:14:08 CEST] <thebombzen> so what is the actual difference between r_frame_rate and avg_frame_rate? [20:14:20 CEST] <thebombzen> does it mean the framerate of the input video is non-constant if these overlap? [20:14:32 CEST] <geri> ChocolateArmpits: i would like to know the real time (e.g. utc) timestamp for a frame recorded... is that possible? [20:14:34 CEST] <thebombzen> if these are not equal* [20:14:56 CEST] <ChocolateArmpits> thebombzen: https://gist.github.com/yohhoy/50ea5fe868a2b3695e19 [20:16:46 CEST] <ChocolateArmpits> geri: As I said, it depends on either of those factors, if none are present or if they do not pertain to real world time then that might be impossible, unless there's some ancillary data written too somehow, which would be application specific [20:17:12 CEST] <geri> ChocolateArmpits: could i change the source ffmpeg? [20:17:21 CEST] <ChocolateArmpits> For what? [20:17:34 CEST] <geri> ChocolateArmpits: to save the timestamp at which a frame has been recorded [20:17:44 CEST] <ChocolateArmpits> There's a setpts filter [20:18:04 CEST] <ChocolateArmpits> and a timeclock option to use in the equation [20:18:22 CEST] <thebombzen> ChocolateArmpits: that being said, multiplying the PTS by 12 should divide the TBR by 12, but even with -vsync 0 we still end up with 240 fps/tbr. What am I missing? [20:18:30 CEST] <thebombzen> why does -vsync 0 do nothing? [20:18:31 CEST] <geri> setpts filter will be called each frame or how should i understand it? [20:18:55 CEST] <ChocolateArmpits> geri: it sets timestamps for each video frame [20:18:58 CEST] <ChocolateArmpits> https://ffmpeg.org/ffmpeg-filters.html#setpts_002c-asetpts [20:19:29 CEST] <ChocolateArmpits> Read the documentation [20:19:40 CEST] <geri> ok [20:19:46 CEST] <ChocolateArmpits> I have tried wallclock some time ago but it lagged really bad on Windows [20:20:00 CEST] <ChocolateArmpits> so see for yourself further [20:20:01 CEST] <ATField> Okay, thanks! And just to make sure, ffmpeg -ss [..] -i IN.mkv -t [..] -c copy OUT.mkv and ffmpeg -i IN.mkv -ss [..] -to [..] -c copy OUT.mkv are guaranteed to make lossless cuts, right? [20:20:03 CEST] <ATField> Also, is there a way to preserve timestamps (so they dont get reset, see: https://trac.ffmpeg.org/wiki/Seeking) without using the Output seeking order and having to wait? [20:20:03 CEST] <geri> ChocolateArmpits: where does the lag come from? [20:20:32 CEST] <ChocolateArmpits> geri: I have no idea, and I haven't tested this with any other system or any newer build [20:20:37 CEST] <thebombzen> ATField: generally do ffmpeg -ss [..] -copyts -i in.mkv [20:20:40 CEST] <ChocolateArmpits> investigate yourself to see how it works for you [20:21:15 CEST] <thebombzen> and yea ATField it will make lossless cuts but they won't be accurate. [20:21:21 CEST] <geri> ChocolateArmpits: i wrote a screen recording app for windows... i try to see if ffmpeg is better and how it works internally.... [20:21:53 CEST] <thebombzen> geri: if you want to screenrecord on windows I recommend OBS. It does have the downside of being a GUI but it's still FOSS and works great. [20:22:09 CEST] <ATField> thebombzen: They ended up being accurate two times in a row, which is what made me suspicious that theyre true lossless cuts. I guess it was just lucky and both cuts started at a proper-type keyframe. [20:22:13 CEST] <geri> thebombzen: i only need a console application... [20:22:34 CEST] <thebombzen> then I'd recommend the Directshow capture device [20:22:56 CEST] <ChocolateArmpits> thebombzen: avg_frame_rate isn't in the timestamps, r_frame_rate is [20:23:06 CEST] <ChocolateArmpits> so it's using those with 240/1 rate [20:23:09 CEST] <thebombzen> geri: see: https://trac.ffmpeg.org/wiki/Capture/Desktop#Windows [20:23:13 CEST] <geri> thebombzen: have you used OBS? [20:23:28 CEST] <geri> thebombzen: i dont have direct show filter installed... [20:23:53 CEST] <thebombzen> geri: which is why when you click the link I provided, you realize that the "directshow filter" is actually a link to where you can install it. [20:24:58 CEST] <thebombzen> ChocolateArmpits: then, if I use -vf setpts=PTS*12 -vsync 0, why does it still have 240 fps/tbr? Why doesn't it decrease to 20? [20:25:31 CEST] <thebombzen> and geri yes I have used OBS. I wouldn't say it "works great" if I had never used it. [20:26:04 CEST] <ChocolateArmpits> thebombzen: Are you sure you are transcoding the input ? [20:26:57 CEST] <ChocolateArmpits> Also [20:26:59 CEST] <ChocolateArmpits> >Each frame is passed with its timestamp from the demuxer to the muxer. [20:27:10 CEST] <ChocolateArmpits> I guess vsync may override setpts [20:27:22 CEST] <ChocolateArmpits> I don't know why would you use the two [20:27:38 CEST] <ChocolateArmpits> unless it was -vsync 1 or 2 [20:29:53 CEST] <thebombzen> ChocolateArmpits: because I want the muxer to determine the tbr based on the timestamps of the frames it receives. [20:30:45 CEST] <thebombzen> the input stream has the frames separated by 1/240 of a second. the output will have them separated by 1/20 of a second. the muxer should see that and determine "20 tbr" [20:32:52 CEST] <ChocolateArmpits> You're not making sense. -vsync 0 is not needed when you have that setpts set [20:33:30 CEST] <ChocolateArmpits> -vsync 0 passes timestamps from demuxer to the muxer, what I'm guessing is overwriting the setpts timestamps so you end with 240/1 again [20:33:49 CEST] <ChocolateArmpits> muxing happens after encoding that happens after filtering [20:35:02 CEST] <JEEB> btw, the least insane timestamp mangling in ffmpeg.c seemed to be `-vsync passthrough -copyts` [20:35:21 CEST] <JEEB> although the ways of ffmpeg.c are always dark and treatcherous [20:50:52 CEST] <thebombzen> ChocolateArmpits: although, the results are the with with and without -vsync 0. that's what's bugging me. [20:51:33 CEST] <ChocolateArmpits> thebombzen: then why not use -r 20 ? [20:51:39 CEST] <ChocolateArmpits> without all others [20:52:01 CEST] <thebombzen> well using -r 20 without setpts won't slow the video down by 12x. it'll just drop frames. [20:52:21 CEST] <ChocolateArmpits> as an input option [20:52:39 CEST] <thebombzen> huh. lemme see what that does. [20:54:37 CEST] <thebombzen> yea that does the trick. weird. [21:00:54 CEST] <zeryx> is there a faster way to cat images together forming a video file? [21:01:01 CEST] <zeryx> I'm doing image operations on each frame, then catting them back together [21:01:07 CEST] <furq> faster than what [21:01:43 CEST] <zeryx> right now I'm using ffmpeg -r 25 -f concat -i /path/to/catfile.cat catted_video.mp4 [21:01:52 CEST] <zeryx> where r is actually just whatever the input video's fps was [21:02:04 CEST] <Maxz> zeryx: https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images [21:02:06 CEST] <zeryx> can I offload work to the gpu for encoding? [21:02:18 CEST] <furq> ffmpeg -framerate 25 -i img%03d.png out.mp4 [21:02:24 CEST] <furq> assuming your images are numbered in sequence [21:02:32 CEST] <zeryx> yeah cat file, should be identical right [21:02:33 CEST] <ChocolateArmpits> zeryx: look up h264_nvenc [21:02:52 CEST] <Maxz> h264_qsv too [21:02:57 CEST] <furq> there's no need to create a concat file [21:03:04 CEST] <zeryx> there is, long story [21:03:05 CEST] <furq> i would also suspect the concat demuxer is slower than image2 [21:03:12 CEST] <zeryx> wait what [21:03:16 CEST] <zeryx> the demuxers are different? [21:03:21 CEST] <zeryx> shouldn't they be totally identical? [21:03:34 CEST] <ChocolateArmpits> what demuxers? [21:03:52 CEST] <zeryx> concat vs. image2 (assuming image2 is the ffmpeg -framerate 25 -i img%03d.png out.mp4 guy) [21:04:16 CEST] <furq> well you're currently using image2 for every image and then concat [21:04:29 CEST] <furq> i don't think image2 uses the concat demuxer for multiple images [21:04:31 CEST] <furq> i could be wrong though [21:04:58 CEST] <ChocolateArmpits> best to separate those two in your head. concat is used to merge multiple files, image2 for image sequences [21:05:36 CEST] <ChocolateArmpits> Read documentation on formats https://www.ffmpeg.org/ffmpeg-formats.html [21:05:36 CEST] <furq> encoding an image sequence is merging multiple files [21:05:39 CEST] <zeryx> like, that's not really how the documentation explains it? [21:06:47 CEST] <zeryx> so using the image2 demuxer is faster than using the concat file like what I've been using? [21:07:13 CEST] <furq> it's definitely faster in the sense that you don't need to create a concat file [21:07:22 CEST] <zeryx> thats instantaneous though [21:07:31 CEST] <zeryx> like ~2 ms [21:07:34 CEST] <furq> i would imagine it runs faster but i don't actually know that [21:07:38 CEST] <zeryx> vs. 5 min to split & then re-encode a video [21:07:43 CEST] <zeryx> a 6 min video* [21:07:47 CEST] <zeryx> on a really powerful machine [21:07:53 CEST] <furq> and if it is then it's probably unnoticeable if you're encoding [21:07:54 CEST] <zeryx> trying to optimise this [21:08:03 CEST] <furq> but concat seems like a weirdly roundabout way to do it [21:08:11 CEST] <zeryx> by re-encode I mean literally concating images together at a certain fps to create a video file [21:08:19 CEST] <zeryx> the word concat might not mean the same thing [21:08:32 CEST] <zeryx> concatenating images to generate a video file is what I'm doing [21:08:45 CEST] <furq> well yeah that's what image2 does [21:09:01 CEST] <zeryx> so that's the go-to approach? I haven't seen much documentation suggesting that method online [21:09:13 CEST] <furq> i've never seen anyone doing it another way [21:09:21 CEST] <zeryx> ./shrug [21:10:05 CEST] <furq> it saves a command if nothing else [21:25:04 CEST] <zeryx> furq I think you're right [21:25:07 CEST] <zeryx> the fps seems to be higher [21:25:34 CEST] <zeryx> one more question, if I set the output of an image sampling operation to jpg, is it possible to set the compression value? [21:25:47 CEST] <furq> -q:v [21:25:57 CEST] <furq> 2 is best quality, 31 is worst [21:26:16 CEST] <zeryx> interesting, so would 2 be equivalent to a png file (no compression at all)? [21:26:43 CEST] <furq> max quality is still lossy [22:21:43 CEST] <boxk> Hi, do you know how to avoid the audio/video not sync when cutting a slice of a file? I noticed for some files I export I have a perfect match of the audio/video frames but with some they have a difference of 1 which makes the video unsynced. [22:23:46 CEST] <Phi> "<BtbN> don't use some old ffmpeg version." [22:24:04 CEST] <Phi> I literally downloaded it from ffmpeg.org and make'd it yesterday [22:24:16 CEST] <Phi> away with your sass [22:24:36 CEST] <relaxed> which version did you download? [22:25:54 CEST] <zeryx> when extracting audio from a file, is it possible to make audio type generic? [22:26:07 CEST] <zeryx> IE can I just extract the audio without any kind of conversions so I can re-attach it later? [22:26:08 CEST] <Phi> relaxed: whatever was on the git.ffmpeg.org [22:27:19 CEST] <relaxed> zeryx: yes [22:27:39 CEST] <zeryx> how? can I not denote a file extension when extracting? [22:27:48 CEST] <zeryx> right now I'm extracting as "file.aac" [22:28:16 CEST] <relaxed> ffmpeg -i input -map 0:a -c:a copy output.aac [22:28:39 CEST] <zeryx> but will that be aac audio container output or whatever the original output is? [22:29:11 CEST] <c_14> zeryx: -c copy -f matroska (I don't know of any audio codec that doesn't go in matroska) [22:29:27 CEST] <c_14> Assuming the audio stream isn't necessarily aac [22:29:41 CEST] <c_14> The aac format (should) reject non-aac [22:30:43 CEST] <zeryx> c_14: can you be more specific? [22:30:57 CEST] <c_14> About the command? [22:31:06 CEST] <zeryx> yeah, where does that bit fit in? [22:31:09 CEST] <c_14> ffmpeg -i input -map 0:a -c:a copy output.mkv [22:31:35 CEST] <c_14> You can also use the .mka extension to clue that the container only contains audio [22:34:02 CEST] <zeryx> :+1: [22:34:04 CEST] <zeryx> nice [23:03:51 CEST] <Maxz> 182 [23:05:40 CEST] <debkad> hello, i'm currently trying to download a .ts stream from .m3u8 url, the problem is sometimes my connection goes off or disconnect, when i try to resume, the download start from the begining, if i stop ffmpeg the resulted .ts file is unreadable ( moove atom ..), how can i resume from where ffmpeg hang? [23:07:00 CEST] Last message repeated 1 time(s). [23:09:32 CEST] <debkad> if ffmpeg is not the right tool for that please tell me, i will use something else [23:11:00 CEST] <debkad> ffmpeg is hanging on 43 min from about one hour [23:12:14 CEST] <debkad> !ping [23:17:11 CEST] <Phi> we hear you debkad [23:17:20 CEST] <Phi> that doesn't necessarily mean we have a clue :p [23:17:27 CEST] <debkad> :( [23:18:49 CEST] <Phi> you will probably have to pass a start time parameter [23:18:58 CEST] <Phi> not sure how you would go about that [23:20:10 CEST] <debkad> Phi: thank you, i will gives that a shot, will copy the .ts file, hope it will not resulted in not reading [23:21:15 CEST] <refrijerator> Hi, my mic is such that if I record my voice, I need options "arecord -f S16_LE -d 5 out.wav" (Recording WAVE 'out.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono). Else my voice sounds all chipped and unclear. I want to record a desktop video, I try "ffmpeg -f alsa -ac 1 -i hw:0 -ar 8000 -f x11grab -video_size 1200x750 -r 30 -i :0.0+50,0 -strict -2 output.mp4" and I get error "Option sample_rate not found." (If I don't s [23:21:52 CEST] <refrijerator> *garbage* [23:22:38 CEST] <refrijerator> I found option -ar in the manual, but it does not exist? how then does it know I asked for option sample_rate? [23:24:09 CEST] <klaxa> either put it before -i hw:0 to use it as an input option for hw:0 or put it after -i :0.0+50,0 to use it as an output option [23:24:21 CEST] <klaxa> not sure which one is appropriate here [23:24:51 CEST] <furq> debkad: the moov atom is specific to mp4 [23:25:09 CEST] <furq> ts is specifically supposed to work if it's truncated [23:25:20 CEST] <ATField> I am having an audio\video sync problem, and I think its because 1. the originals Frame rate (MediaInfo shows "Frame rate: 93.750 fps (512 spf)") doesnt get passed onto the converted outcome file, and that 2. the original audio stream thats 1:39:18.621-long changes into a 1:41:05.237 one after conversion. How can I fix this / what parameters should I use? The -ar param. seems to... [23:25:21 CEST] <ATField> ...be about... [23:25:23 CEST] <ATField> ...Sampling Rate (KHz, is 48.0 on both files), and not frame rate. [23:25:48 CEST] <furq> ATField: pastebin the command line and full output [23:25:56 CEST] <debkad> furq: ah yes thank you, i used a specific parameter in the first try, that make sens [23:26:35 CEST] <debkad> i know use only -c copy [23:26:58 CEST] <furq> https://www.ffmpeg.org/ffmpeg-protocols.html#http [23:27:04 CEST] <furq> you can try some of the reconnect options in there [23:27:27 CEST] <ATField> furq: Just to make sure: should I post the command line logs of the conversion from original to output, the MediaInfo data, or both? [23:27:36 CEST] <debkad> furq: that was for me? [23:27:37 CEST] <furq> the first one [23:27:40 CEST] <furq> yes [23:27:48 CEST] <debkad> oh thank you so much [23:27:58 CEST] <ATField> Ok, Ill go reconvert it to make the logs. [23:28:09 CEST] <refrijerator> klaxa: you saved me, thank you very much [23:28:31 CEST] <furq> ATField: if you don't have them to hand then the command line and mediainfo might be enough [23:29:00 CEST] <furq> or ffprobe -show_streams output [23:29:09 CEST] <klaxa> :) [23:30:00 CEST] <llogan> refrijerator: use -sample_rate, not -ar for ALSA input option (possibly doesn't make a difference though) [23:30:25 CEST] <debkad> furq: i think i must use those three reconnect_* options? [23:30:49 CEST] <furq> probably [23:30:55 CEST] <furq> i've not needed them in a while [23:30:58 CEST] <refrijerator> llogan: thanks [23:31:26 CEST] <NapoleonWils0n> hi all [23:31:38 CEST] <llogan> refrijerator: and -channels instead of -ac (see "man ffmpeg-devices") [23:31:43 CEST] <furq> i wonder if reconnect_streamed being off by default means it'll start from the beginning [23:32:27 CEST] <NapoleonWils0n> i have a script that auto restart when the stream cuts out [23:32:31 CEST] <NapoleonWils0n> https://github.com/NapoleonWils0n/kodi-playercorefactory/blob/master/bash-s… [23:32:35 CEST] <CFS-MP3b> Is it possible for ffmpeg to segment on demand? By this I mean - instead of segmenting by segment length, segment when an external event happens, such as a signal being sent [23:33:07 CEST] <NapoleonWils0n> are auto bitstream filters enabled in latest version on git [23:33:13 CEST] <llogan> refrijerator: ...and -framerate instead of -r for x11grab. [23:33:33 CEST] <llogan> and you don't need "-strict -2" [23:33:35 CEST] <NapoleonWils0n> is it possible to enable auto bit stream filters using any config options [23:33:54 CEST] <debkad> furq: i will work on those options, that really helpful, thanks again [23:34:23 CEST] <refrijerator> llogan: strict 2 was needed, else audio did not work (I don't know aac, sthg like this), I run ffmpeg version 2.8.6 [23:34:32 CEST] <llogan> your ffmpeg is old [23:35:09 CEST] <refrijerator> it is in the stable branch in my distribution, gentoo [23:35:31 CEST] <llogan> 2.8.6 that was old when old was young [23:35:54 CEST] <refrijerator> ok, I will keep that in mind, but seems to do what I wanted for now [23:36:03 CEST] <debkad> my ffmpeg ( compiled from git if i remember) is ffmpeg version N-81995-gd790e48 [23:36:34 CEST] <debkad> is that ok? [23:36:37 CEST] <NapoleonWils0n> i see automatic bitstream filtering in the changelog on github [23:37:16 CEST] <NapoleonWils0n> im running 3.1.5 at the moment, is it a config option or am i just running an old version [23:37:54 CEST] <furq> the latest release usually doesn't have all the changes from git [23:38:13 CEST] <NapoleonWils0n> cheers furq [23:38:29 CEST] <NapoleonWils0n> so will have to wait for the changes to flow downstream [23:38:35 CEST] <furq> that change is probably part of the 3.2 branch [23:38:47 CEST] <furq> you could just use git head [23:38:50 CEST] <NapoleonWils0n> right ill keep an eye out [23:40:03 CEST] <NapoleonWils0n> stupid question but what would be the timeframe for 3.2.0 "release" [23:40:06 CEST] <Substring> hihi ! i'm trying to capture video from stdin as well as the sound output with ffmpeg through ALSA. my audio device has no capture feature, i'd just like to record what i hear on the speakers. Is that possible ? [23:40:21 CEST] <NapoleonWils0n> Sustring yes it is possible [23:40:35 CEST] <NapoleonWils0n> i have done it myself i dig out a link to the code i used [23:40:45 CEST] <Substring> NapoleonWils0n, oh thanks :) [23:41:59 CEST] <NapoleonWils0n> just trying to find it [23:42:47 CEST] <NapoleonWils0n> https://github.com/NapoleonWils0n/cerberus/blob/master/ffmpeg/ffmpeg-screen… [23:43:02 CEST] <NapoleonWils0n> you create a alsa loopback device [23:43:21 CEST] <Substring> but it has no capture device [23:43:29 CEST] <Substring> (it's on a raspberry pi) [23:43:59 CEST] <NapoleonWils0n> i think you also need the ~/.asoundrc [23:44:14 CEST] <NapoleonWils0n> with the alsaloop back device [23:44:56 CEST] <Substring> oh so the .asoundrc is making th emagic ? [23:44:58 CEST] <debkad> Substring: the video is inside your machine? [23:45:24 CEST] <Substring> debkad, it's not even a video, it's the display of the pi [23:45:27 CEST] <NapoleonWils0n> Substring you need to create the alsa loopback device with code like this [23:45:29 CEST] <NapoleonWils0n> sudo modprobe snd-aloop pcm_substreams=1 [23:46:05 CEST] <debkad> Substring: you want to capture the whole screen including the sound? [23:46:13 CEST] <NapoleonWils0n> im using filter complex to fix an issue where the audio was only coming out the left speaker [23:46:19 CEST] <NapoleonWils0n> so you probably dont need that [23:46:33 CEST] <Substring> debkad, yes i am [23:46:36 CEST] <NapoleonWils0n> you can capture both you mic and any audio that is playing [23:46:53 CEST] <debkad> ok i think the loop idea from NapoleonWils0n worth a try [23:46:58 CEST] <NapoleonWils0n> what you need to do is set the application to use the alsa loopback device [23:47:16 CEST] <NapoleonWils0n> so in vlc for example you need to change the output audio device to alsa loopback [23:47:31 CEST] <NapoleonWils0n> note you wont be able to hear the audio playing but it will record [23:47:41 CEST] <Substring> well, i'd better make the loopback device the default output then [23:47:47 CEST] <Substring> oh ! [23:47:50 CEST] <Substring> wll [23:47:54 CEST] <debkad> o_o [23:47:58 CEST] <Substring> that's just to test if I can do some screen casting [23:48:19 CEST] <NapoleonWils0n> i have used that technique on several screencasts for youtube [23:48:36 CEST] <debkad> sound very logic [23:49:00 CEST] <debkad> NapoleonWils0n: i guess it is a kind of a virtual device? [23:49:10 CEST] <Substring> debkad, i"m not using any software on which you can set on which device you want the sound output [23:49:22 CEST] <NapoleonWils0n> debkad yes exactly its a virtual audio device [23:49:55 CEST] <NapoleonWils0n> Substring you can set the loopback device to be default temporaily while you record [23:49:56 CEST] <debkad> Substring: yeah i understand that, the virtual loop device can capture the sound stream [23:50:16 CEST] <NapoleonWils0n> then you can then switch back when your finished recording [23:50:37 CEST] <ATField> furq: Here are: 1. the notes http://pastebin.com/k9LLcLan , 2. the mediainfo data: http://pastebin.com/S8ZFKFcS , http://pastebin.com/DypjaQRG. The command used for creating OUTPUT.ogg was a generic b ffmpeg -i "INPUT.dts" -c:a libvorbis -q:a 4 OUTPUT.ogg c. [23:51:18 CEST] <Substring> That's some great help you gave me here :) One more question : i'd like the video to be encoded with h264_omx and not libx264 ... what is the command line ? [23:51:37 CEST] <NapoleonWils0n> i havent used h264_omx before [23:52:02 CEST] <Substring> well, then on a general matter : how do you define the encoder ? [23:52:10 CEST] <llogan> -c:v <encoder name> [23:52:35 CEST] <NapoleonWils0n> script is here: [23:52:37 CEST] <NapoleonWils0n> https://github.com/NapoleonWils0n/cerberus/blob/master/ffmpeg/ffmpeg-screen… [23:52:44 CEST] <NapoleonWils0n> -c:v libx264 -preset veryfast -crf 18 -profile:v high [23:52:52 CEST] <NapoleonWils0n> -c:a libfdk_aac -ac 2 -ar 44100 -b:a 128k [23:53:02 CEST] <debkad> Substring: you can use ffmpeg -formats to see the available formats [23:53:22 CEST] <NapoleonWils0n> you dont need the filter complex in that code that was just a fix for my laptop [23:53:41 CEST] <NapoleonWils0n> steps are create the alsa loopback device [23:54:00 CEST] <NapoleonWils0n> use asoundrc to set it as your default audio device [23:54:03 CEST] <debkad> -codecs* my bad [23:54:09 CEST] <NapoleonWils0n> then record with ffmpeg [23:54:17 CEST] <NapoleonWils0n> -f alsa -ac 2 -ar 44100 -i hw:0,0 \ [23:54:23 CEST] <NapoleonWils0n> -f alsa -ac 2 -ar 44100 -i loopout \ [23:54:53 CEST] <llogan> -f alsa -channels 2 -sample_rate 44100 [23:54:56 CEST] <NapoleonWils0n> obviously you need to work out the address of the mic [23:55:45 CEST] <Substring> h264_omx is working fine (just the compression is awful ... nevermind) [23:56:36 CEST] <NapoleonWils0n> Substring i have some bash scripts for ffmpeg here: [23:56:38 CEST] <NapoleonWils0n> https://github.com/NapoleonWils0n/kodi-playercorefactory [23:56:50 CEST] <NapoleonWils0n> and videos: [23:56:51 CEST] <Substring> my ffmpeg is not compiled with the non free option [23:56:52 CEST] <NapoleonWils0n> https://www.youtube.com/channel/UCriRR_CzOny-akXyk1R-oDQ [23:57:05 CEST] <NapoleonWils0n> i always use the non-free [23:57:23 CEST] <NapoleonWils0n> pain otherwise [23:57:27 CEST] <Substring> libfdk_aac is part of the non free [23:57:48 CEST] <NapoleonWils0n> yes i found it usually better quality [23:57:58 CEST] <Substring> libaac works not bad either [23:58:45 CEST] <llogan> support for libfaac has been removed from FFmpeg [23:59:39 CEST] <Substring> aac [23:59:49 CEST] <Substring> just the aac codec [00:00:00 CEST] --- Wed Oct 26 2016

1 0

ffmpeg-devel.log.20161024
by burek 25 Oct '16

25 Oct '16

[01:04:29 CEST] <tmm1> is there a way to disable a CONFIG_EXTRA option via the cmd line [01:16:29 CEST] <jamrial> tmm1: no [05:30:56 CEST] <jya> wondering why the difference in the default scaling list used in fffmpeg (https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_ps.c#L43) vs what's in the spec stable (and used by chrome https://cs.chromium.org/chromium/src/media/filters/h264_parser.cc?q=kDefaul… , or mesa: [05:30:56 CEST] <jya> https://fossies.org/linux/mesa/src/gallium/state_trackers/omx/vid_dec_h264.…) [05:31:14 CEST] <jya> for h264 that is... [06:04:12 CEST] <philipl> Does anyone know how android slow-motion video metadata is encoded? The files report themselves as being 30fps and if played at 30fps, play at the slow motion speed, but the editor lets you mark which section you want slow and it plays the rest in realtime. Is it even encoded in the file? [06:09:32 CEST] <rcombs> philipl: I have the same question about iOS's similar feature [06:09:52 CEST] <rcombs> iirc some people talked about VFR wrt that? but dunno any details [06:10:38 CEST] <philipl> https://developer.android.com/reference/android/media/MediaFormat.html [06:10:42 CEST] <philipl> They talk about temporal layering [06:11:02 CEST] <philipl> and there's a com.android.video.temporal_layers_count property in the container metadata [06:11:18 CEST] <philipl> so perhaps this (where I don't really know what 'this' is) is it [06:11:50 CEST] <philipl> android certainly isn't VFR. The file is constant rate and the audio is also slowed down to match the video [06:11:51 CEST] <rcombs> is it BMFF? [06:12:04 CEST] <philipl> yes [06:12:46 CEST] <rcombs> maybe look around for unusual atoms in boxdumper/mp4info/such [06:12:55 CEST] <rcombs> if there's nothing else interesting in metadata [06:14:57 CEST] <philipl> Will poke around. [06:23:57 CEST] <philipl> I have an ios slow mo file here too. They seem to do the opposite. The base metadata and timestamps are realtime [06:24:00 CEST] <philipl> So it's a 120fps file [06:32:02 CEST] <philipl> There are some unknown boxes. [07:01:18 CEST] <philipl> rcombs: I think they use h.264 svc. The base layer is the slow motion and then presumably, there are other layers that indicate the realtime sections. [07:01:29 CEST] <rcombs> iOS or Android? [07:01:34 CEST] <philipl> android. [07:01:36 CEST] <rcombs> also, ew, SVC [07:01:53 CEST] <philipl> ios could be the same, with a the realtime as the base layer. [07:02:05 CEST] <rcombs> also, wait, what? That doesn't sound like a sane use of SVC [07:02:10 CEST] <rcombs> just to encode metadata? [07:02:32 CEST] <rcombs> they both have the base layer encode every frame, right? [07:02:37 CEST] <rcombs> and just have timestamps differ [07:02:50 CEST] <philipl> i agree it's weird, but it's not in the container metadata [07:03:08 CEST] <philipl> and they keep calling them temporal layers which is svc jargon. [07:03:30 CEST] <philipl> yes. in both cases, the base layer has all frames. [07:07:22 CEST] <philipl> We don't attempt to parse any svc metadata do we? [07:29:10 CEST] <rcombs> philipl: afaik no [07:29:44 CEST] <rcombs> (not saying you're wrong, just saying it's dumb, which isn't unusual for android media things) [07:30:30 CEST] <rcombs> I don't know enough about SVC to say how you would find out any more [07:32:33 CEST] <rcombs> I guess it could make sense if they used it to skip decoding frames they don't need? Would they duplicate frames at different rates for that (SVC stuff maybe, I dunno how that works?), or do they have really funky-looking GoPs where every 4-or-so frames suspiciously doesn't reference any of the previous 3? [08:50:16 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:d13740f3a207: lavc/parser: export field order if not already set [08:50:16 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:f271a9bd991b: lavc/h264_parser: export field order in more cases [08:50:17 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:ba53504e57b6: lavc/utils: avcodec_string: dump field order when known [08:50:18 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:54350f06e117: ffprobe: report field order for video streams [08:50:19 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:8a24e03684ca: MAINTAINERS: add myself for audiotoolbox [10:20:15 CEST] <nevcairiel> jya: looks to me like one of those is in zigzag order, probably ffmpegs [10:30:10 CEST] <mateo`> philipl: the slow-mo media recorded on android are reported at 30fps but ... you'll find the following metadata in the mp4 container: com.android.capture.fps [10:30:57 CEST] <mateo`> which reports the correct fps [10:45:59 CEST] <rcombs> mateo`: the question is how the whole "set some parts to slow and other parts to full-speed" thing works [10:50:45 CEST] <nevcairiel> isnt SVC spatial not temporal [10:51:28 CEST] <nevcairiel> guess its both [10:51:50 CEST] <nevcairiel> (Temporal scalability is already enabled by H.264/MPEG-4 AVC. SVC has only provided supplemental enhancement information to improve its usage.) [10:51:53 CEST] <nevcairiel> so much for that [10:51:53 CEST] <nevcairiel> :D [10:52:29 CEST] <jya> nevcairiel: oh that makes sense.. thank you ! [10:52:52 CEST] <jya> doh, how didn't I figure that one out [10:55:40 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:a246fef16338: lavf/mux: add avformat_init_output [10:55:41 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:c7cd6ad8509c: lavf/segment: add deinit function [10:55:42 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:45f5c5573203: lavf/segment: fix writing separate header with auto BSF [10:55:43 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:e83d5d7e58ff: lavf/movenc: add deinit function [10:55:44 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:c972a28fc3de: lavf/dashenc: add deinit function [10:55:45 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:42cb050a0502: lavf/movenc+dashenc: add automatic bitstream filtering [10:55:46 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:d99d7cbdfc70: lavf/rawenc: add automatic bitstream filtering for H264+HEVC [10:55:47 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:a6da754ef9a7: fate/h264: make mp4toannexb test use auto-BSF [10:55:48 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:ed4e081a362d: fate/aac: add automatic bsf test [10:55:49 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:3b3f979894a0: fate/hevc: add automatic bsf test [10:56:22 CEST] <nevcairiel> \o/ [10:56:32 CEST] <rcombs> it's one of those days [10:58:04 CEST] <nevcairiel> probably a ticket or two which can be closed now? [10:58:42 CEST] <rcombs> oh, good point [10:59:25 CEST] <rcombs> but I can't be arsed to find them [10:59:29 CEST] <nevcairiel> hehe [10:59:32 CEST] <rcombs> it's damn difficult to find trac issues relevant to a topic [10:59:35 CEST] <nevcairiel> they'll turn up [10:59:49 CEST] <rcombs> because everyone posts their full ffmpeg output [10:59:56 CEST] <rcombs> and it includes a bunch of names of unrelated shit [11:00:23 CEST] <nevcairiel> the search also finds closed tickets, which isnt very helpful [11:00:32 CEST] <rcombs> wtb something to get banner output excluded from search [11:02:02 CEST] <rcombs> nevcairiel: hey, happen to have some MKV files with header stripping laying around? [11:02:17 CEST] <rcombs> I need to test to make sure Roku really did fix their shit [11:02:23 CEST] <nevcairiel> cant you just create one [11:02:46 CEST] <nevcairiel> take for example dts, has a fixed sync start word, and shove it into mkv with the option turned on [11:02:49 CEST] <rcombs> probably, but I tend to prefer existing samples to make sure I don't fuck it up [11:03:04 CEST] <rcombs> allegedly, at some point it was fixed, but only for some specific codecs [11:03:13 CEST] <rcombs> or, like, for audio but not for video or something [11:03:13 CEST] <nevcairiel> that sounds odd [11:03:17 CEST] <rcombs> (how do you fuck up that badly) [11:03:32 CEST] <nevcairiel> you would probablky have to go out of your way to fix it only for one type [11:03:36 CEST] <nevcairiel> but you know, hardware makers [11:03:37 CEST] <rcombs> right? [11:03:53 CEST] <rcombs> thus my skepticism [11:04:12 CEST] <nevcairiel> for video the best you can probably get is a h264 stream with one 0 stripped from the 4-byte length code =p [11:05:01 CEST] <rcombs> you could just set the length-size field to 3 bytes :3 [11:05:09 CEST] <nevcairiel> thats not valid [11:05:13 CEST] <rcombs> oh really? [11:05:21 CEST] <wm4> yay for matroska saving 1 byte per packet [11:05:21 CEST] <rcombs> why is the field even there, then [11:05:24 CEST] <nevcairiel> (some files do it though, but officially out of spec) [11:05:31 CEST] <nevcairiel> it can be 2, technically [11:05:44 CEST] <nevcairiel> although for HD video 2 is probably too small [11:05:48 CEST] <rcombs> yeah [11:05:52 CEST] <rcombs> whose spec, anyway [11:06:07 CEST] <nevcairiel> its the mov/mp4 spec thing [11:06:07 CEST] <rcombs> isn't the MP4 bitstream format not part of MPEG-4 Part 10 [11:06:13 CEST] <rcombs> which one [11:06:24 CEST] <rcombs> (aren't there like 12) [11:06:24 CEST] <nevcairiel> let me find it [11:06:30 CEST] <rcombs> nah don't bother [11:06:35 CEST] <nevcairiel> ISO_IEC_14496-15 [11:06:42 CEST] <rcombs> I'm just being annoyed at the state of multimedia standards [11:06:42 CEST] <nevcairiel> Carriage of NAL unit structured video in [11:06:42 CEST] <nevcairiel> the ISO Base Media File Format [11:07:37 CEST] <rcombs> y'know I once had to recover a .mp4 from a device that had shutdown midway through writing the sample table [11:07:52 CEST] <nevcairiel> The value of this field shall be one of 0, 1, or 3 corresponding to a [11:07:52 CEST] <nevcairiel> length encoded with 1, 2, or 4 bytes, respectively. [11:07:58 CEST] <rcombs> ended up writing a script to split packets based on AUDs [11:08:00 CEST] <nevcairiel> 3 isnt speced [11:08:04 CEST] <nevcairiel> although i have seen files use it [11:08:06 CEST] <nevcairiel> so much for that [11:08:06 CEST] <nevcairiel> :D [11:08:14 CEST] <rcombs> whose idea was it for cameras to record in a format like this shit [11:08:20 CEST] <nevcairiel> rcombs: lucky they put AUDs in mp4 [11:08:28 CEST] <rcombs> lol single giant monolithic header [11:08:57 CEST] <rcombs> hope you never run out of battery [11:10:20 CEST] <nevcairiel> and yeah header stripping is mostly useless, the savings are usually extremely minimal [11:10:33 CEST] <nevcairiel> and requires two pass processing to even find a common header [11:10:54 CEST] <rcombs> does the header have to be common to literally all packets [11:10:55 CEST] <nevcairiel> mosu just forced it in mkvmerge for a while to get broken hardware people to fix their shit =p [11:10:58 CEST] <nevcairiel> yes [11:11:05 CEST] <rcombs> wew [11:11:17 CEST] <wm4> indeed, that's one good thing mkv has over mp4: it's actually streamable [11:11:32 CEST] <rcombs> lol fragmented MP4 [11:11:41 CEST] <wm4> I'll never understand how mp4 got such widespread use in streaming [11:11:54 CEST] <wm4> or why things like fragmented mp4 have to exist [11:12:13 CEST] <nevcairiel> i was meaning to try to get $works streaming module to output streaming mkv, but I havent found a real usecase yet that interested me [11:12:20 CEST] <wm4> even hls seems reasonable in comparison (...ok maybe not) [11:12:45 CEST] <nevcairiel> we have way too many streaming formats anyway [11:12:54 CEST] <rcombs> nevcairiel: I use it for streaming to Chrome and mpv [11:12:56 CEST] <nevcairiel> hls, hds, dash, probably fogetting some more arcane ones [11:12:56 CEST] <rcombs> and Roku [11:13:12 CEST] <rcombs> it works better than HLS on some stupid devices [11:13:30 CEST] <rcombs> because they have a tendency to try to buffer entire MPEGTS segments in memory instead of downloading them progressively [11:13:37 CEST] <nevcairiel> we currently do hls or plain mpegts streams, which works for android and some other things, but i may remember someone complaining that roku fails [11:13:44 CEST] <rcombs> whereas if you give them a monolithic MKV stream, they handle it fine [11:14:01 CEST] <rcombs> yeah, Roku falls over on HLS segments larger than some particular threshold [11:14:10 CEST] <wm4> <rcombs> because they have a tendency to try to buffer entire MPEGTS segments in memory instead of downloading them progressively <- don't you have to do this [11:14:12 CEST] <rcombs> just freezes up and sits there [11:14:16 CEST] <wm4> to not get playback dropouts [11:14:19 CEST] <rcombs> wm4: no? [11:14:22 CEST] <rcombs> and lavf doesn't [11:14:26 CEST] <wm4> lol [11:14:38 CEST] <nevcairiel> well it depends [11:14:43 CEST] <wm4> my main motivation to add a buffered packet queue to mpv was because of lavf's hls [11:14:50 CEST] <nevcairiel> buffering can help if you have varying connection stability [11:14:58 CEST] <rcombs> well yes buffering is good [11:15:07 CEST] <nevcairiel> but you dont have to buffer entire segments if that exceeds your memory availability [11:15:08 CEST] <wm4> so effectively mpv will buffer at least 1 hls fragment or so in memory so lavf starts downloading the next one [11:15:09 CEST] <rcombs> but there's no reason you have to buffer by segment [11:15:31 CEST] <wm4> because recreating the tcp connection and such increases latency by "too much" [11:15:40 CEST] <nevcairiel> these rokus are cheap-ass hardware devices, they dont exactly come with plenty memory [11:15:52 CEST] <wm4> of course ideally lavf would just start buffering fragments asynchronously [11:16:13 CEST] <rcombs> wait, they still open a new TCP socket per request? [11:16:14 CEST] <nevcairiel> cant you do keep-alive and use the same http connection for hls [11:16:16 CEST] <rcombs> wat? [11:16:27 CEST] <wm4> dunno, but fairly sure lavf can't do this [11:16:27 CEST] <rcombs> lavf HTTP even supports pipelining [11:16:32 CEST] <wm4> oh it does? [11:16:39 CEST] <rcombs> yeah, dunno if HLS uses it though [11:16:41 CEST] <rcombs> you have to try [11:16:50 CEST] <rcombs> it's not automatic or anything [11:17:01 CEST] <nevcairiel> i'm not a big fan of any streaming support in lavf, it seems all a bit wonky [11:17:14 CEST] <nevcairiel> i expose some but when someone reports a problem i usually just tell them that i dont care [11:17:29 CEST] <nevcairiel> (not to mention that testing streaming problems is often impossible) [11:17:32 CEST] <rcombs> HTTP/1.1 lets you send the next request before you finish receiving the response to the first [11:17:44 CEST] <rcombs> but I dunno if lavf supports that [11:17:49 CEST] <nevcairiel> how would that work [11:17:59 CEST] <rcombs> and it'd be at least non-trivial to handle in hlsdec.c [11:18:04 CEST] <rcombs> nevcairiel: literally just that [11:18:17 CEST] <wm4> yeah, lavf is generally wonky for anything [11:18:19 CEST] <rcombs> you send the next request before you've finished reading the response to the current one [11:18:30 CEST] <nevcairiel> typical pipelining is just to request a new file once the previous finishes, not while its still running o.o [11:18:54 CEST] <rcombs> sure, but in e.g. HLS, you can send the next one early [11:19:04 CEST] <rcombs> so you don't have to wait an RTT to start getting additional packets [11:19:10 CEST] <nevcairiel> i guess [11:19:19 CEST] <nevcairiel> but without re-opening the connection the overhead is probably fine [11:19:27 CEST] <rcombs> yeah, that's the bigger thing [11:19:31 CEST] <nevcairiel> now if you do a new connection every time [11:19:33 CEST] <nevcairiel> thats painful [11:19:52 CEST] <rcombs> esp. with TLS [11:20:04 CEST] <rcombs> though that gets cheaper with 1.3 [11:20:21 CEST] <nevcairiel> 10 years until widespread adoption? =p [11:20:50 CEST] <rcombs> nah, new TLS stuff tends to get decent adoption reasonably quickly these days [11:20:57 CEST] <rcombs> I mean, just look at how quickly HTTP/2 caught on [11:21:11 CEST] <nevcairiel> with all the servers running old-ass distributions? [11:21:12 CEST] <nevcairiel> we'll see [11:21:43 CEST] <wm4> http 2 gets any use? [11:21:44 CEST] <rcombs> guess it depends what you mean by widespread [11:21:46 CEST] <rcombs> wm4: sure [11:22:49 CEST] <rcombs> https://w3techs.com/technologies/details/ce-http2/all/all [11:22:57 CEST] <rcombs> over 10% now [11:22:59 CEST] <nevcairiel> google uses all sorts of these things to just get 1% efficiency, like QUIC, but not sure i consider google and some other big names using it wide-spread :D [11:23:15 CEST] <rcombs> and all the major CDNs do it [11:23:37 CEST] <rcombs> including cloudflare [11:23:52 CEST] <nevcairiel> guess that automatically makes it available in many places [11:24:21 CEST] <nevcairiel> but who knows how much its worth if the backend behind cloudflare only talks http1 [11:24:41 CEST] <rcombs> plenty if it's static resources [11:25:43 CEST] <rcombs> and client support is there [11:40:06 CEST] <jya> nevcairiel: looking at various h264 implementation, that would make them all wrong then, or just ffmpeg [11:41:10 CEST] <jya> like the MESA/OMX (author is AMD), when no table is defined, they simply memcpy the default table (non zigzag) [11:41:14 CEST] <jya> same with chrome [11:41:35 CEST] <jya> the zigzag is only ever applied from the data read from the sps/pps [11:42:17 CEST] <nevcairiel> you have to apply zigzag somewhere [11:42:26 CEST] <nevcairiel> either you pre-zigzag the table or you do it later [11:42:42 CEST] <nevcairiel> and when dealing with hardware, ffmpeg has to un-zigzag the tables before giving it to the hardware [11:42:49 CEST] <jya> nevcairiel: I'm fairly certain they never apply the zigzag on the default scale values [11:43:53 CEST] <nevcairiel> well it works, doesnt it [11:44:39 CEST] <jya> that the MESA code: https://fossies.org/linux/mesa/src/gallium/state_trackers/omx/vid_dec_h264.…, just plain memcpy on the default scales. [11:44:54 CEST] <jya> well, I'm yet to find a video getting into that case anyway :) [11:45:07 CEST] <jya> so maybe that's why it works ! [11:46:20 CEST] <nevcairiel> it mostly depends on the expectation of the API, does it want these zigzaged or plain, hardware probably prefers plain most of the time [11:47:56 CEST] <jya> nevcairiel: is the scale tables zigzagged? [11:48:02 CEST] <jya> in the SPS that is [11:48:30 CEST] <nevcairiel> in the bitstream? dont think so [11:50:45 CEST] <jya> hmmm... so looking at the dxva2_h264.c , it uses the value as-is, so I'm guessing it takes zigzag stuff [11:51:07 CEST] <nevcairiel> actually it unzigzags it [11:51:20 CEST] <nevcairiel> qm->bScalingLists4x4[i][j] = pps->scaling_matrix4[i][ff_zigzag_scan[j]]; [11:52:12 CEST] <nevcairiel> (note that there is a work-around mode above because some old hardware expected the wrong stuff) [11:52:33 CEST] <jya> oh... [11:52:48 CEST] <jkqxz> Mesa codec stuff is meant to be a thin shim layer for access to the hardware. The OMX implementation happens to be large and complex because OMX specifies a whole-stream decoder, and so they have to reimplement all of the parsing there. Looking at the VDPAU or VAAPI implementations in mesa will give a better impression of how much it actually does. [11:52:53 CEST] <nevcairiel> long long ago, first gen AMD decoders i think [11:53:13 CEST] <jya> ok... so I'm going to store it as the original... no zigzag [11:56:18 CEST] <jya> nevcairiel: if you zigzag twice you get back to the original ? (haven't thought about it really) [12:00:06 CEST] <nevcairiel> not exactly [12:00:13 CEST] <nevcairiel> but you can reverse it of course [12:00:49 CEST] <nevcairiel> like the line of code above, if you loop over "j" and then read it zigzagged from one and write it non-zig to the other, you basically reverse it [12:01:26 CEST] <jya> i see... thanks for pointing that out [12:01:33 CEST] <nevcairiel> during sps/pps parsing its the other way around, you read value "j" and then write it into zigzag[j] [12:01:58 CEST] <jya> cool! [12:13:09 CEST] <jya> nevcairiel: would you know of any samples where scaling tables are declared? i tried a few videos I have, and all of them use default stuff (eg. all 16) [12:13:40 CEST] <nevcairiel> i would assume one of the conformance samples would have one [12:15:59 CEST] <nevcairiel> http://fate-suite.ffmpeg.org/h264-conformance/FRext/Freh1_B.264 this one supposedly [12:19:32 CEST] <jya> what container is that? [12:19:36 CEST] <nevcairiel> none [12:20:03 CEST] <JEEB> raw annex b [12:20:09 CEST] <jya> ah... will be hard for me to verify if my code is valid [12:20:20 CEST] <nevcairiel> well you can just remux it with ffmpeg if you need to [12:20:45 CEST] <jya> ffmpeg will understand .264 to be annexb? [12:20:48 CEST] <JEEB> yes [12:21:03 CEST] <JEEB> or do -f h264 before input [12:34:36 CEST] <jya> nevcairiel: nope :( no defined scale tables in that one [12:40:49 CEST] <jkqxz> Er, yes it does. <http://sprunge.us/YeWb> [12:54:28 CEST] <jya> jkqxz: [12:55:05 CEST] <jya> jkqxz: the pps size is 6 bytes long. [12:55:35 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:73ead477ddd9: lavf: add AV_DISPOSITION_TIMED_THUMBNAILS [12:55:36 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:697400eac07c: lavf/mov: improve `tref/chap` chapter handling [12:55:37 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:490c6bda0e35: lavf/mov: reindent [12:55:39 CEST] <jya> oh sorry, I was looking in the pps [12:58:49 CEST] <jya> jkqxz: which tool did you use to print that? [12:58:51 CEST] <jkqxz> Yeah, the scaling lists can be in the SPS and/or the PPS. This one has them in the SPS. [12:59:10 CEST] <jkqxz> The reference decoder (JM). [13:04:40 CEST] <jya> well, the mp4 i converted i got with ffmpeg, seq_scaling_matrix_present_flag is 0 [13:04:47 CEST] <jya> what's going on in that stuff [13:07:08 CEST] <jya> i get a length of 20 bytes in the SPS [13:13:56 CEST] <jkqxz> You're reading the file as AVCC rather than annex B? (I see a byte value 20 early in it.) [13:20:00 CEST] <jya> jkqxz: no, I converted the .264 file into a .mp4 [13:20:09 CEST] <jya> the sps becomes 22 bytes then [13:21:51 CEST] <jya> ffmpeg -i ~/Downloads/Freh1_B.264 -c:a copy ~/Downloads/Freh1_B.mp4 ; the level_idc goes from 22 to 13 etc [13:23:48 CEST] <jkqxz> Copy the video ("-c:v copy") rather than the (nonexistent) audio? [13:25:06 CEST] <jya> jeez.. bad copy/paste :( [13:25:41 CEST] <jya> better go to bed now... [17:15:20 CEST] <thegeek_> @michaelni: I mentioned a segmentation fault in FFv1 here the other day, I can repro now with a small diff to the muxing.c sample. https://trac.ffmpeg.org/ticket/5906 [17:22:31 CEST] <RiCON> jkqxz: tried latest two qsv patches: https://i.fsbn.eu/pub/qsv/ [20:22:22 CEST] <jkqxz> RiCON: Looks like VC-1 and H.264 8-bit are fine, assuming the output was correct. MPEG-2 doesn't work where mine does - can you share the input stream so I can try it? H.265 8-bit appears to not manage to initialise at all, not sure what's going on there. For the other two, H.26[45] 10-bit is indeed not supported. [20:24:53 CEST] <RiCON> jkqxz: uploaded to the same dir [20:28:05 CEST] <RiCON> i don't have any other mpeg-2 sample so it might just be that one [20:34:23 CEST] <jkqxz> Ok, I do get the same behaviour with it. I will investigate further; maybe tomorrow if I have time. [20:34:36 CEST] <JEEB> talking of hwdec vc1, I still remember the 9600M of mine only doing it through the driver's SW decoder :D [20:34:52 CEST] <JEEB> MPEG-2 and AVC worked fine, but VC-1 was given the short stick [20:40:46 CEST] <tmm1> rcombs: lmk if i can provie any more information on this audiotoolbox deadlock ^^ [21:26:18 CEST] <wm4> tmm1: I think there are some cases where videotoolbox errors on streams that are perfectly fine hw-decodable on the same hw with vaapi or dxva [21:26:37 CEST] <wm4> but which doesn't have to do with the extradata case [21:26:56 CEST] <wm4> I think the same streams work if hardware decoding isn't forced [21:27:11 CEST] <wm4> never investigated this too deeply [21:54:22 CEST] <tmm1> wm4: if you have some samples i can take a look, it definitely seems very finicky [21:54:30 CEST] <tmm1> even moreso on iOS [21:54:48 CEST] <tmm1> i saw mpv has that hack where it switches back to software decoding after the first frame decode failure from VT [21:55:53 CEST] <wm4> that's because of a hard to fix ffmpeg issue [21:56:06 CEST] <wm4> which happens because VT doesn't really fit in as hwaccel [22:04:28 CEST] <tmm1> i saw some talk of writing a vt decoder instead of using it as an hwaccel /cc rkern [22:04:52 CEST] <wm4> also cc rcombs [22:05:19 CEST] <wm4> I think rcombs got stuck with the reordering logic, since VT likes to return frames in decode order [22:05:38 CEST] <wm4> and reordering requires dealing with the codec details (h264 in particular) [22:08:23 CEST] <cone-915> ffmpeg 03Ronald S. Bultje 07master:be885da3427c: vp9: change order of operations in adapt_prob(). [22:08:24 CEST] <cone-915> ffmpeg 03Ronald S. Bultje 07master:f141ac4d0bf1: vf_colorspace: don't spam console with warnings if range is unspecified. [22:08:25 CEST] <cone-915> ffmpeg 03Vittorio Giovara 07master:ba53d3ae8bfb: vf_colorspace: Add support for iec61966-2.1 (sRGB) transfer [22:18:47 CEST] <rkern> I'd rather a vt decoder over the hwaccel. rcombs, does anything else besides reordering need to be done? [22:33:20 CEST] <ubitux> it's pretty much blocking [22:33:32 CEST] <ubitux> because you don't want to duplicate the reordering logic [22:36:09 CEST] <nevcairiel> i still dont get whats wrong with a hwaccel [22:36:14 CEST] <nevcairiel> let the code we have do the work [22:39:51 CEST] <wm4> it doesn't quite fit architecturally, and we probably won't be able to use VT's async decoding mode [22:40:37 CEST] <ubitux> yes you can't do async properly [22:40:49 CEST] <ubitux> (and async is mandatory if you want to decent performance) [22:41:01 CEST] <nevcairiel> leave it to apple to build something that doesnt work like anything else - using the same hardware :p [22:41:47 CEST] <wm4> of course [22:42:03 CEST] <wm4> apple loves this kind of stuff [22:46:04 CEST] <rkern> What's the issue with async? [22:48:02 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=3b9171090f2676f5f… [22:48:13 CEST] <ubitux> am i being dumb again? [22:48:25 CEST] <ubitux> or the frame_sample_aspect in the loop makes no sense? [22:50:02 CEST] <ubitux> aside from that and the last err check, this whole loop is identical between audio and video; it should probably be homogenised and shared [22:50:35 CEST] <wm4> rkern: hwaccels use the hwaccel backend in synchronous mode obviously [22:51:15 CEST] <wm4> ubitux: seems like it picks the first valid aspect or something? [22:51:54 CEST] <ubitux> ist doesn't change in that loop [22:52:00 CEST] <ubitux> nor frame_sample_aspect [22:52:05 CEST] <ubitux> unless i'm missing something obvious [22:52:18 CEST] <wm4> why is this code so hideous [22:52:33 CEST] <wm4> why doesn't it do &decoded_frame->sample_aspect_ratio or whatever [22:53:49 CEST] <wm4> ubitux: maybe it being in the loop is a merge error? [22:54:11 CEST] <ubitux> might be [22:54:17 CEST] <ubitux> i guess i'll send a few patches [22:55:05 CEST] <tmm1> sounds like kVTDecodeFrame_EnableTemporalProcessing is just ignored altogether.. [22:55:31 CEST] <ubitux> yes it is [22:55:50 CEST] <ubitux> there are a ton of "funny" things with VT [22:56:17 CEST] <wm4> yeah, rcombs investigated this "fun" [22:56:29 CEST] <wm4> seems like you really have to do it manually [22:57:03 CEST] <tmm1> yea looks like everyone else is doing manual reordering, based on pts? [22:57:55 CEST] <nevcairiel> pts is not a concept i would ever accept [22:57:58 CEST] <nevcairiel> timestamps are volatile [22:58:12 CEST] <nevcairiel> either do it correctly or dont bother [22:58:37 CEST] <wm4> I know chromium does it by duplicating the h264 picture output logic [22:58:43 CEST] <wm4> which is annoying [23:09:12 CEST] <ubitux> tmm1: 2 other "fun" things: [23:09:21 CEST] <ubitux> - pushing more than 3 packets to VT will cause a fatal deadlock when the application is going in background on iOS [23:09:31 CEST] <ubitux> so you have to create a lock by yourself [23:09:50 CEST] <JEEB> lol [23:09:50 CEST] <ubitux> - The decode callback can actually be called after VTDecompressionSessionWaitForAsynchronousFrames() [23:10:07 CEST] <ubitux> (on some relatively old iOS versions) [23:10:13 CEST] <ubitux> so you actually have to count the frames too [23:11:35 CEST] <ubitux> i also have to investigate some funny business related to h264 extradata [23:11:44 CEST] <ubitux> but that will be another story [23:16:59 CEST] <tmm1> gosh [23:56:22 CEST] <rkern> tmm1: I've had some luck with avfoundation... Maybe the indev could be modified to accept files too. [23:56:33 CEST] <rkern> Won't work for all use cases though. [00:00:00 CEST] --- Tue Oct 25 2016

1 0

ffmpeg.log.20161024
by burek 25 Oct '16

25 Oct '16

[00:16:42 CEST] <MrMonkey31> "Requested output format 'mkv' is not a suitable output format"? [00:17:27 CEST] <MrMonkey31> they call it something different, don't they?... [00:18:05 CEST] <klaxa> matroska [00:18:18 CEST] <MrMonkey31> got it... thx! [00:25:25 CEST] <raj> ffmpeg comes with win10? [00:25:53 CEST] <raj> oh, nm, it came with imagemagick [00:28:47 CEST] <AnonRunzes> so [00:29:00 CEST] <AnonRunzes> can I post a sample whose codec is undiscovered? [00:35:04 CEST] <raj> is there something wrong with this: ffmpeg -i "C:\Users\Raj\Downloads\M2U00115.MPG" "C:\Users\Raj\Desktop\M2U00115.mp4" [00:35:25 CEST] <raj> I'm getting "Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height" [00:36:25 CEST] <BtbN> do you want to add a -c copy? [00:38:02 CEST] <raj> what's that mean? [00:39:48 CEST] <raj> I didn't add any options because this example didn't show any either: http://www.alexkuo.info/?p=253 [00:40:17 CEST] <klaxa> my guess would be odd height or width input resolution? [00:41:19 CEST] <raj> I don't really want anything to change, it's just that I sent my video to someone using final cut pro and she said she couldn't import the mpg, and can I send her an mp4 instead [00:41:50 CEST] <raj> &to be clear, she was trying to import the video into final cut pro but apparently couldn't [00:42:02 CEST] <furq> pastebin the command line and full output [00:44:23 CEST] <raj> ok, I just added -vcodec copy and -acodec copy and it seemed to work [00:52:29 CEST] <raj> Now she's telling me it's just a green screen with sound [00:52:38 CEST] <raj> She's on a Mac, I'm on a PC [00:53:19 CEST] <raj> She's missing some video codec I suppose, but how do I figure out which one? [00:54:54 CEST] <raj> Here's the output from my conversion: http://paste.ofcode.org/eAFQnqEkFrEQdAUttjxRRh [00:59:59 CEST] <raj> would really appreciate some help as it's time sensitive [01:04:51 CEST] <klaxa> raj: seems like it doesn't have the mpeg2 codec, you can try to re-encode [01:05:09 CEST] <klaxa> for that the first command was right, can you pastebin the output of the first command? [01:37:50 CEST] <ItWasntMe2013> Someone mentioned in an earlier chat that h264 has the automatic bit rate change ability in real time. i.e. I can dynamicly change the bitrate as I set it without needing to restart ffmpeg each time... similar to what skype does, does anyone have any info on that? [01:42:08 CEST] <raj> klaxa, I had her install https://support.apple.com/kb/dl1396?locale=en_US and it worked [01:48:00 CEST] <klaxa> ah nice good [01:48:36 CEST] <DHE> ItWasntMe2013: you'd have to use libav yourself. there isn't a method to change bitrates dynamically in the command-line tool [01:53:52 CEST] <raj> klaxa, did doing that conversion from mpeg to mp4 reduce any quality? [01:54:33 CEST] <klaxa> the one you pasted not [01:54:41 CEST] <raj> ok cool [01:54:54 CEST] <raj> I thought converting just inherently may reduce some quality of some sort [01:55:00 CEST] <raj> glad to know it doesn't [01:59:52 CEST] <klaxa> what you did was remuxing [02:04:39 CEST] <raj> thanks klaxa [02:29:30 CEST] <Mad7Scientist> ItWasntMe2013, you can always set quality -q 0 to 31 and ffmpeg will adjust the bit rate [02:29:51 CEST] <Mad7Scientist> But I assume you're wanting something more advanced [02:30:26 CEST] <Mad7Scientist> I would think real time streaming systems would need to be able to change it to a specific value in real time [02:32:16 CEST] <klaxa> most services just offer multiple quality encodings and the clients decide which one they want [02:32:52 CEST] <AnonRunzes> so [02:33:04 CEST] <AnonRunzes> how can I batch process all the files to .wav on ffmpeg? [02:36:01 CEST] <DHE> shell scripting required [02:36:27 CEST] <AnonRunzes> huh [02:36:44 CEST] <DHE> klaxa: for pre-rendering and multiple clients. the skype example requires real-time measurements and on-the-fly codec reconfiguration. in extreme cases forcing a keyframe [02:38:27 CEST] <klaxa> ah true [02:52:57 CEST] <ItWasntMe2013> Mad7Scientist: yeah I've done that, but what I really want is some sort of mechanism that I can control the quality in real time, just like skype does... I'm sure that skype isnt making multple profiles and doing ABR streaming, [03:00:50 CEST] <jpsharp> Anyone have any suggestions on how to convert an occasionally-changing GIF into a RTMP stream that doesn't make ffmpeg freak out over changing DTSs? [03:03:38 CEST] <klaxa> does something like this work? (while true; cat image.gif; done) | ffmpeg -f image2pipe -i - <stuff> ? [03:03:47 CEST] <klaxa> not sure if that's a good way though [03:07:03 CEST] <jpsharp> Hmmm. i wasn't aware of image2pipe, so let me look at that. [03:07:17 CEST] <MrMonkey31> is it normal to use a sharpen after downscaling a video? I'm just wondering what the standard practices are [03:09:23 CEST] <ItWasntMe2013> DHE: but I thought there was a way to do this in real time in ffmpeg without needed to restart the encoding... I'm ok to provide my own signalling, I have some good ideas on that, but I just want to adjust ffmpeg on the fly and not need to restart it each time [03:12:16 CEST] <furq> MrMonkey31: the default resize algorithm is bicubic, you probably want to use something sharper like lanczos or spline [03:12:36 CEST] <furq> -sws_flags spline [03:12:38 CEST] <MrMonkey31> furq, oh for sure [03:14:38 CEST] <MrMonkey31> but I've noticed with still images even after a lanczos rescale, a sharpen just does a world of improvement for appearance [03:15:59 CEST] <DHE> ItWasntMe2013: there's no built-in mechanism to do that. you'll have to add one yourself by modifying ffmpeg, or make an app using libav [03:20:08 CEST] <MrMonkey31> I'm going with 'scale=-1:720, unsharp=5:5:1.30:5:5:0.0' and hoping the extra sharpness doesn't cause the frames to like, block up. scaling down from 1080p [03:27:08 CEST] <furq> depends on taste i guess [03:27:48 CEST] <furq> if you're using crf it'll probably just use more bitrate rather than causing blocking [03:43:43 CEST] <jpsharp> klaxa: Brilliant. The image2pipe worked perfectly. I've been arguing with this for days. [05:11:14 CEST] <BinaryBench> Hey, so I'm still working on creating trying to achieve extremely low latency (approx. 25ms + internet latency). Atm I am using: "ffmpeg -f dshow -i video="UScreenCapture" -r 30 -vcodec libx264 -pix_fmt yuv444p -tune zerolatency -preset veryfast -x264opts crf=20:vbv-maxrate=6000:vbv-bufsize=200:intra-refresh=1:slice-max-size=1500:keyint=30:ref=1 -f mpegts udp://localhost:6666" to stream and "ffplay -fflags nobuffer -sync ext -i [05:12:24 CEST] <BinaryBench> eam, however this is getting me about 600ms [06:38:45 CEST] <BinaryBench> Anyone? [06:39:31 CEST] <CoJaBo> BinaryBench: try to narrow down which part of it is adding latency [06:39:49 CEST] <furq> isn't that more latency than you were getting yesterday [06:39:56 CEST] <furq> or were you measuring it wrong [06:40:09 CEST] <CoJaBo> like maybe try some other/dummy input method [06:42:26 CEST] <BinaryBench> furq: I was guesstimating, I actually broke out the screenshots this time :P [06:44:09 CEST] <BinaryBench> CoJaBo: That is what I am attempting to do, I so far I've ruled out both capture & play back as I've subtracted the latency of just doing "ffplay -f dshow -i video="UScreenCapture"" [06:45:28 CEST] <furq> i don't actually know how little latency ffplay has with -fflags nobuffer [06:45:36 CEST] <furq> you might want to test with some other players with the cache disabled [06:46:03 CEST] <furq> it's --cache=no with mpv [06:47:09 CEST] <BinaryBench> furq: With just that ffplay command, the latency came out to 50ms [06:48:21 CEST] <BinaryBench> which makes me think the latency isn't coming from ffplay [06:48:57 CEST] <furq> it's using a different protocol and demuxer though [06:49:36 CEST] <furq> you might want to ask in #x264 as well [06:49:52 CEST] <BinaryBench> cd #x264 [06:49:56 CEST] <BinaryBench> oops :P [06:50:01 CEST] <furq> close enough [06:53:56 CEST] <BinaryBench> furq: Hum, you seem to know about encoding and what not, what would be your suggestion for super low-latency streaming? [06:54:18 CEST] <furq> pretty much what you've already got [06:54:25 CEST] <furq> i've never needed <1s latency [06:57:32 CEST] <BinaryBench> I'm trying to do something like Steam in-home streaming, but I would like to have more control over it and be able to use it for non-games [06:58:12 CEST] <TD-Linux> I would use webrtc or plain RTP. I've generally found gstreamer or other tools to be more cut out for this than ffmpeg.c [06:58:21 CEST] <Prelude2004c> hey guys.. good day [06:58:37 CEST] <TD-Linux> (though I don't doubt that it's possible) [06:58:52 CEST] <Prelude2004c> anyone know why i would be getting : error opening key file /tmp/key-VxKaKGZKix/file.key ? the file was created with openssl rand 16 [07:00:10 CEST] <BinaryBench> TD-Linux: can't ffmpeg use rtp? [07:00:53 CEST] <TD-Linux> it can. [07:02:02 CEST] <BinaryBench> TD-Linux: I'm kinda new to this, but what does ffmpeg do besides manage the streams between the capture device & the encoder & the udp port? [07:02:32 CEST] <JEEB> it has a fuckload of possible places to buffer things in, it has demuxers, muxers, protocol implementations, decoders and encoders [07:03:07 CEST] <JEEB> and ffmpeg.c is a wonky command line interface of some of the features available [07:04:23 CEST] <JEEB> I know libx264 the library can do very low latency, but then your issue becomes the whole thing around it in FFmpeg's libraries and whatever the command line app is doing if you're calling that [07:06:13 CEST] <BinaryBench> JEEB: Hum, so what might be my issue is this case? Or is there something besides Ffmpeg that would fit my needs better? [07:08:53 CEST] <JEEB> I have no effing idea since I've never looked into how much latency all the components have [07:09:15 CEST] <JEEB> I just know that by default the libraries buffer a lot and do other stuff [07:11:29 CEST] <JEEB> so while FFmpeg's libraries provide you with the wrappers for a whole lot of stuff, you will have to go check yourself how much latency each and every thing is bringing to you, since they're most definitely not "low latency by default" in many cases [07:11:59 CEST] <Prelude2004c> hey, can anyone help ? not sure what to do.. i did everything based on what i have read [07:12:19 CEST] <Prelude2004c> why would ffmpe gnot want to open up the file.key ? its done with openssl rand 16 > file.key [07:24:07 CEST] <Prelude2004c> nobody knows this riddle ? :P [07:33:57 CEST] <Prelude2004c> oh boy [07:55:46 CEST] <babadoc> hello [07:56:01 CEST] <babadoc> is there anyone here [07:56:38 CEST] <babadoc> if there is, does anyone know how to host video files on my server so i can stream them? [07:56:40 CEST] <babadoc> i dont want to use plex [07:56:47 CEST] <babadoc> i tried using nodejs [07:56:59 CEST] <babadoc> the http-server package [07:57:14 CEST] <babadoc> that worked, but only if i converted the file to mkv [07:57:35 CEST] <babadoc> the original file is a mp4 file that i misnamed as a webm [07:57:44 CEST] <babadoc> Any thoughts? [07:57:52 CEST] <furq> literally any web server [07:58:05 CEST] <babadoc> could you give me some names? [07:58:08 CEST] <furq> nginx [07:58:15 CEST] <babadoc> i tried embedding the webm and hosting it [07:58:18 CEST] <babadoc> it doesn't work thats the probme [07:58:22 CEST] <babadoc> problem* [07:58:36 CEST] <babadoc> i can port forward the link to show you what i mean [07:58:40 CEST] <babadoc> its on my IP [07:58:51 CEST] <babadoc> would you like me to port forward it? [07:58:59 CEST] <furq> just install nginx [07:59:12 CEST] <babadoc> and then host the index.html server? [07:59:13 CEST] <furq> there's really no trick to it [07:59:15 CEST] <babadoc> file* [07:59:22 CEST] <furq> you don't need to embed the file in html or anything [07:59:29 CEST] <furq> your browser will play it directly [07:59:49 CEST] <furq> just put the videos in some directory nginx can see [08:00:13 CEST] <babadoc> i will try using nginx. [08:00:23 CEST] <babadoc> i don't have any prior experience with it though. [08:00:32 CEST] <babadoc> it will be my first time using it [08:00:44 CEST] <furq> the only thing you optionally need other than literally anything which serves http is a server which supports range requests, so that you don't need faststart mp4s [08:01:03 CEST] <furq> although it's still better to have them [08:01:18 CEST] <Prelude2004c> hey,, still stuck so i am going to ask the question again.... so i am running a codec copy on a source that i am simply taking in and segmenting out into m3u8.. i loaded up the file.key and file.keyinfo and all seems well and binary exists... when i restart ffmpeg session i get : /tmp/key-9GLLgUAh5Y/file.key .. file is there.. i checked [08:01:22 CEST] <Prelude2004c> not sure where to look [08:01:44 CEST] <babadoc> i understand thanks [08:01:54 CEST] <babadoc> nginx supports range rquest? [08:02:02 CEST] <furq> yes [08:04:07 CEST] <babadoc> ok [08:09:41 CEST] <Prelude2004c> furq, your pretty good at this stuff... any points ? am i overlooking something simple ? [08:31:50 CEST] <babadoc> furq i need to edit the nginx config file to a specific directory right [08:32:07 CEST] <babadoc> because it is currently set as /var/www/html [08:32:27 CEST] <babadoc> if i change that to /users/baba/videofiles/ will that host the files? [08:34:53 CEST] <furq> as long as the nginx user has read permissions in that directory, sur [08:34:53 CEST] <furq> e [09:24:20 CEST] <babadoc> dude [09:24:22 CEST] <babadoc> fruq [09:24:23 CEST] <babadoc> furq [09:24:27 CEST] <babadoc> literally [09:24:34 CEST] <babadoc> i have to set up all this shit in nginx [09:24:42 CEST] <babadoc> holy crap [09:24:55 CEST] <babadoc> furq is there any simpler way? [09:25:03 CEST] <babadoc> ;( [09:26:46 CEST] <babadoc> can i serve video using ffserver? [09:38:45 CEST] <babadoc> furq is ffserver working [09:38:50 CEST] <babadoc> is it broken [09:38:59 CEST] <danan391> I'm facing an issue when updating FFmpeg using brew. "clang is unable to create an executable file." Anyone familiar with that? [09:39:05 CEST] <babadoc> brew [09:39:11 CEST] <babadoc> what version of mac os are you using [09:39:32 CEST] <danan391> 10.11.06, el cap [09:39:38 CEST] <babadoc> same as mine [09:39:47 CEST] <babadoc> what command did you ru [09:39:48 CEST] <babadoc> run [09:40:14 CEST] <danan391> brew update & brew upgrade [09:40:25 CEST] <babadoc> you could try reinstalling ffmpeg [09:40:52 CEST] <JEEB> babadoc: it exists and still builds but nobody in the FFmpeg community wants to touch it or knows how it is supposed to be used :p [09:41:19 CEST] <JEEB> in other words, if you are going to use it, you'll have to maintain it or rewrite it [09:41:37 CEST] <danan391> What happens with custom configures then? I installed libvorbis and a few others, will they be kept after the reinstall? [09:53:44 CEST] <babadoc> lol jebb [09:53:48 CEST] <babadoc> is there no manpage anywhere? [09:53:56 CEST] <babadoc> its just this thing that came with ffmpeg? [09:53:57 CEST] <babadoc> lol [10:43:17 CEST] <trfl> anyone happen to know whether ffmpeg supports userdata in hevc elementary streams? I'm being handed an rtp stream created with mainconcept, which apparently lets you include up to 1kB of metadata per frame, but ffmpeg chokes horribly on it (can barely display a couple columns of blocks for each frame) [10:43:51 CEST] <trfl> or rather, anyone know whether that's even allowed by the hevc es spec (if there is such a thing) [11:29:52 CEST] <hkjh> please witch codec must i use when streaming a webm video file to icecast ? [11:34:53 CEST] <hkjh> any response ? [11:35:58 CEST] <Mavrik> well, webm contains vp8 or vp9 by standard. [11:36:06 CEST] <Mavrik> I guess VP8 would be better supported. [11:36:15 CEST] <Mavrik> Does IceCast suppport that? [11:45:31 CEST] <tdr> WebM (VP8/VP9), are both listed as supported here: http://icecast.org/faq/ [13:05:53 CEST] <trfl> its a shame people leave so quickly... he reminded me that I bumped into an issue where streaming vp8 to icecast was impossible due to ffmpeg not exposing a method for setting the mimetype forwarded to icecast, so it would default to audio/vorbis [13:06:10 CEST] <trfl> I should probably create an issue for that :p [13:12:38 CEST] <trfl> oh sweet, it's been fixed already! [13:17:40 CEST] <trfl> welp, spoke too soon. If you use -f tee to write the webm to a file in addition to icecast, -content_type is dropped [13:38:33 CEST] <ozette> anyone knows if it's possible to view the bitrate of a video in the browser? [13:38:54 CEST] <ozette> preferably firefox or google chrome [13:39:36 CEST] <tdr> that depends on how it is being served out [13:42:19 CEST] <ozette> regardless of how the video is encoded? [13:43:10 CEST] <ozette> i am streaming a video by sending chunks of the original file, but i have no idea how fast this happens [13:44:04 CEST] <ozette> and i imagine the client tries to playback with the bitrate of the original video [13:44:31 CEST] <tdr> ozette, the player serving it out would have to have some hotkey (like youtube or netflix does) to say "oh hey, display the video properties too) [13:45:10 CEST] <ozette> hmm, i know youtube has some 'stats for nerds' button somewhere [13:45:43 CEST] <tdr> the browser itself just hands that portion of the screen off the the libraries etc that know how to process it. it would have to tell the player (hosted on the url or downloaded as part of the page) to display those peices [13:46:07 CEST] <ozette> but this player i set up myself, from a graphical interface point of view, the options are limited [13:46:18 CEST] <tdr> then i'm guessing no. [13:46:22 CEST] <tdr> find a different player [13:46:54 CEST] <ozette> so a browser doesn't know? there's no network or media statistics or anything? [13:46:59 CEST] <ozette> laaaame [13:48:44 CEST] <tdr> the browser itself is semi-dumb [13:49:17 CEST] <ozette> we need smartbrowsers then, just like we needed smartphones [13:49:21 CEST] <tdr> no [13:49:38 CEST] <tdr> you need a better streaming server app [13:49:42 CEST] <ozette> :< [13:50:56 CEST] <tdr> i could just like and say you need IE 6 and windows mediaplayer version 2 [13:51:01 CEST] <tdr> s/like/lie [13:51:23 CEST] <ozette> how so? [13:51:59 CEST] <ozette> i'm mostly interested in .. [13:52:55 CEST] <ozette> if the bitrate encoding of a video matters at all when played over the network [13:53:44 CEST] <ozette> and i'm trying to find out if different videos are played with different bitrates or with a constant bitrate in my media player [13:54:31 CEST] <tdr> ozette, you could fake check that by using something like iptraf-ng or similar on linux or on windows just any tool checking yoru network use [13:54:43 CEST] <ozette> i want to improve my streaming server, the videos i'm handling are huge, so processing already takes a while, and may take even longer if i decide to resample to lower qualities [13:55:13 CEST] <ozette> i just installed mediainfo [13:59:04 CEST] <ozette> can't seem to call it from cli though [16:39:13 CEST] <Filarius> with writing to ffmpeg StdIn from my app, how should I indicate end of writing ? [16:40:15 CEST] <DHE> traditionally you close() your end of the pipe facing ffmpeg's stdin [17:57:07 CEST] <geri> hi, how can i create an avi video from a series of .bmp images (ScreenShootx.bmp) ...x is a number ? [18:01:37 CEST] <geri> ffmpeg -r 30 -i ScreenShot%d.bmp out.avi [18:01:44 CEST] <geri> which codec does it use by default? [18:05:31 CEST] <c_14> Whatever's the default for avi, check `ffmpeg -h muxer=avi' [18:15:44 CEST] <geri> c_14: isnt it it set the same for each binary? [18:15:51 CEST] <geri> ffmpeg binary [18:15:55 CEST] <c_14> Not necessarily [18:16:00 CEST] <c_14> Depends on how it's built [18:16:17 CEST] <c_14> If, for example, you disable the codec it would choose by default it might fall back to something else or fail. [18:16:34 CEST] <geri> i used the prebuilt binary [18:16:42 CEST] <c_14> i.e. matroska defaults to libx264 if available but falls back to mpeg4 [18:16:42 CEST] <geri> ok [18:17:01 CEST] <geri> it says default video: mpeg4 [18:18:10 CEST] <geri> c_14: is ffmpeg also able to capture my desktop screen? [18:18:40 CEST] <c_14> https://trac.ffmpeg.org/wiki/Capture/Desktop [18:21:19 CEST] <geri> ffmpeg -list_devices true -f dshow -i dummy ... only shows my integrated webcam + audio for recording... [18:22:28 CEST] <BtbN> What else did you expect to find there? [18:25:16 CEST] <geri> BtbN: i asked how to record my desktop screen [18:25:37 CEST] <BtbN> That's not what dshow does. Dshow is used for input devices like webcams. [18:25:51 CEST] <BtbN> gdigrab or something like that captures the screen. [18:32:27 CEST] <geri> ok, is there a way to extract the timestamp of each recorded frame? [18:37:51 CEST] <geri> BtbN: it would work if you have a dshow filter? [18:44:47 CEST] <livingBEEF> Any idea how the make process figures out which libx265 so version to link? Because I have only 95 installed, but it links to 87 [18:45:43 CEST] <livingBEEF> So trying to execute ffmpeg only says "libx265.so.87 not found" [19:32:16 CEST] <Filarius> Hello, any help on error http://pastebin.com/efG3Yjmr ? trying to make wrapper on C# [19:48:36 CEST] <Filarius> hm, I will look for simplier code on C# [21:17:25 CEST] <foxpie> Hi, I'm very novice with ffmpeg. I'm basically using someone else's code to try and convert and eventually concatenate small raw videos. I'm having a hard time understand the problem with command. Can I post my questions here? [21:19:19 CEST] <c_14> Well, it should technically be possible. So it all comes down to you. [21:21:22 CEST] <questionGirl> ffmpeg -i 1.mp4 out.mp4 [21:21:22 CEST] <questionGirl> ffmpeg version 2.7.1 Copyright (c) 2000-2015 the FFmpeg developers [21:21:22 CEST] <questionGirl> built with gcc 4.9.3 (crosstool-NG 1.20.0) 20150311 (prerelease) [21:21:22 CEST] <questionGirl> configuration: --prefix=/usr --incdir='${prefix}/include/ffmpeg' --arch=i686 --target-os=linux --cross-prefix=/usr/local/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- --enable-cross-compile --enable-optimizations --enable-pic --enable-gpl --enable-shared --disable-static --enable-version3 --enable-nonfree --enable-libfaac --enable-encoders --enable-pthreads --disable-bzlib --disable-protocol=rtp [21:21:22 CEST] <questionGirl> --disable-muxer=image2 --disable-muxer=image2pipe --disable-swscale-alpha --disable-ffserver --disable-ffplay --disable-devices --disable-bzlib --disable-altivec --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libmp3lame --disable-vaapi --disable-decoder=amrnb --disable-encoder=zmbv --disable-encoder=dca --disable-encoder=ac3 --disable-encoder=ac3_fixed --disable-encoder=eac3 [21:22:47 CEST] <questiongirl> I'm using an older version of ffmpeg - the one bundled with my synology NAS. [21:23:56 CEST] <thebombzen> uh... do you have a question [21:24:03 CEST] <thebombzen> or are you just going to post your configuration [21:24:43 CEST] <questiongirl> the question was at the beginning... [21:24:58 CEST] <questiongirl> what is the problem.. I'm simply using "-i" as a param.. [21:25:10 CEST] <thebombzen> I don't see a question [21:25:11 CEST] <questiongirl> But I don't understand the error message [21:25:24 CEST] <questiongirl> or how I can make this work [21:25:38 CEST] <thebombzen> I also don't see an error message. Note this: questionGirl [~foxpie(a)24.48.36.29] has quit IRC: Excess Flood [21:25:57 CEST] <questiongirl> I pasted a huge amount of data from my console and got booted for flooding, did you see that data? [21:26:09 CEST] <thebombzen> nope. because that's spam. most likely it kicked you because you were spamming us. paste the entire output on a paste site like http://pastebin.com/ [21:26:12 CEST] <questiongirl> ha... [21:26:22 CEST] <thebombzen> you also didn't ask a question. [21:26:29 CEST] <questiongirl> What's the secret to pasting the outoput oif my console then? :) [21:27:04 CEST] <questiongirl> The last line in my console is: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [21:27:11 CEST] <thebombzen> there's no secret. go to a website like pastebin.com and literally copy/paste it onto that site. then provide a link. [21:27:19 CEST] <questiongirl> but I'm simply using the defaults everything. [21:27:27 CEST] <questiongirl> ok [21:28:33 CEST] <questiongirl> http://pastebin.com/xafsJmj2 [21:28:45 CEST] <questiongirl> my question: How can I fix this? [21:29:52 CEST] <questiongirl> The original stream is (from what I am reading) in DASH format [21:30:17 CEST] <questiongirl> and I am told that I need to "convert it" for them eventually concatenate it. [21:30:35 CEST] <questiongirl> The video clips are from a Ubiquiti G3 camera [21:30:47 CEST] <questiongirl> ffmpeg is being run on a synology NAS. [21:31:19 CEST] <thebombzen> who told you you have to "convert it" [21:31:21 CEST] <thebombzen> who is "them" [21:31:31 CEST] <thebombzen> cause the command you're running is pointless [21:31:32 CEST] <questiongirl> I meant "then" [21:32:01 CEST] <questiongirl> It does seem pointless... I somehow agree. I got the code from the script here: https://community.ubnt.com/t5/UniFi-Video/Extracting-recorded-video-on-the-… [21:32:02 CEST] <thebombzen> you're converting a h.264 video and aac audio in the same container. I'm not sure why you're doing that. [21:32:48 CEST] <furq> it's best to ignore about 95% of ffmpeg advice given on forums [21:32:51 CEST] <questiongirl> The OP told me that this line was doing the equivalent of "moov atoms - see qtfaststart" [21:32:56 CEST] <furq> it isn't [21:33:34 CEST] <furq> the actual command is -i foo.mp4 -c copy -movflags faststart bar.mp4 [21:33:39 CEST] <furq> but i don't think you even need to do that [21:33:41 CEST] <BtbN> Or just qt-faststart [21:33:43 CEST] <questiongirl> in any case, the line I am really interested in executing the the other ffmpeg call a few lines below.. [21:33:46 CEST] <furq> you should just be able to concat the clips directly [21:34:00 CEST] <furq> you probably also want to upgrade to a newer ffmpeg [21:34:32 CEST] <thebombzen> first of all, upgrade FFmpeg. second of all, there is a whole bunch of documentation on it. [21:34:32 CEST] <questiongirl> upgrading is an issue... no ipkg on my nas, I would need to compile for my cpu... need toolchain and other stuff I am not familiar with. [21:34:47 CEST] <furq> https://www.johnvansickle.com/ffmpeg/ [21:35:01 CEST] <furq> judging by the cc in your ffmpeg configure line, the x86 builds should work [21:35:14 CEST] <thebombzen> also, if you search Google for "concatenate files with ffmpeg" this is literally the first result: https://trac.ffmpeg.org/wiki/Concatenate [21:35:22 CEST] <thebombzen> the documentation that describes exactly how to do that [21:35:39 CEST] <furq> the bash script in the op is making me really unhappy [21:36:05 CEST] <questiongirl> he did put the concatenation part: ffmpeg -y -f concat -safe 0 -i Segs.txt -filter_complex "[0:v]setpts=0.25*PTS[v];[0:a]atempo=2.0,atempo=2.0[a]" -map "[v]" -map "[a]" out.mp4 [21:36:36 CEST] <furq> yeah but he also put `for File in $(ls ${InDir}/*.mp4)` [21:36:40 CEST] <questiongirl> I tried to build on his work... since he is taking the raw output of a UBNT camera, and concatenating the 10second clips and accelerating them [21:37:30 CEST] <furq> that command ought to work on the clips you already have [21:37:46 CEST] <thebombzen> wait [21:37:48 CEST] <furq> although you probably want to add -r 30 or else you'll end up with 120fps [21:38:00 CEST] <furq> or 100fps or whatever 4x the source fps is [21:38:15 CEST] <thebombzen> $(ls *.mp4) is just... *.mp4. [21:38:18 CEST] <furq> it sure is [21:38:20 CEST] <thebombzen> also furq I think that's wrong [21:38:38 CEST] <thebombzen> I think ffmpeg will match the input framerate even with a pts filter. that's what -vsync 0 is used for 99% of the time I use it. [21:39:50 CEST] <furq> so it does [21:41:14 CEST] <questiongirl> In his for loop, he is also creating a txt file that contains a list of all the files that can be inputed to ffmpeg. [21:41:48 CEST] <furq> for f in "$indir"/*.mp4; do echo "file '$f'" >> concat.txt; done [21:42:01 CEST] <questiongirl> he replaced his initial "ffmpeg -i" call to using mp4box... but again, I am not certain why. He told me that otherwise his later ffmpeg call wouldn'T work. [21:42:12 CEST] <furq> he did that because his initial ffmpeg command reencodes the streams [21:43:39 CEST] <questiongirl> ok, I'll try to download the latest ffmpeg for my atom cPU, hoping the x64 build works. [21:43:54 CEST] <furq> your current build is i686 so you probably want the x86 build [21:45:44 CEST] <questiongirl> but my cpui is 64 bits architecture... [21:46:12 CEST] <furq> shrug [21:46:16 CEST] <furq> listen to your heart [21:46:39 CEST] <JEEB> and the OS? you can't run 64bit binaries on a 32bit system :P [21:46:44 CEST] <questiongirl> And I gather you state that the initial ffmpeg (later changed to a mp4box call) is useless, but I'm sure there is reason why he did so (his next call wasn't working). [21:47:02 CEST] <questiongirl> Roxette? [21:47:05 CEST] <furq> well it's definitely wrong [21:47:08 CEST] <furq> it may or may not be useless [21:47:23 CEST] <furq> if it's not useless then you actually want ffmpeg -i foo.mp4 -c copy -movflags faststart bar.mp4 [21:47:25 CEST] <questiongirl> anyway, what would be the "good call"? :) [21:47:28 CEST] <furq> ^ [21:48:05 CEST] <chuprin> hi guys. is any public logs of this room available? i asked a question yesterday but webchat at freenode disconnected so i couldnt get replies [21:48:11 CEST] <furq> i don't see why that would be needed but i've never had to deal with dash segments [21:48:16 CEST] <questiongirl> noted about the faststart. I'll try with and without. [21:48:22 CEST] <furq> chuprin: http://ffmpeg.gusari.org/irclogs/ [21:48:28 CEST] <chuprin> thanks [21:50:18 CEST] <questiongirl> my nas has a hardware tranconding engine (chip..?)... will ffmpeg make use of it by default? [21:50:50 CEST] <furq> probably not, but you don't need it for this anyway [21:51:54 CEST] <questiongirl> if I have hundreds of clips I want to concatenate each day and to avoid bringing the cpu to its knee.. [21:52:10 CEST] <questiongirl> but I'll test and hopefully you are right and it is not required. [21:52:32 CEST] <furq> the clips are already encoded in the right format, you're just concatenating them [21:53:47 CEST] <questiongirl> but also accelerating them to 4x so I can review them faster [21:54:40 CEST] <Phi> heyo ladies [21:54:53 CEST] <Phi> and fellahs [21:54:57 CEST] <furq> you do need to encode to do that with ffmpeg, but it's possible to do it without reencoding [21:55:10 CEST] <furq> you could either do it in your player or use mp4box/l-smash or something to change the fps [21:56:53 CEST] <questiongirl> indeed, I often use vlc to play files at 4x, but in this case, I would like a new file to be created. mp4box isn't available on my nas. [21:57:27 CEST] <questiongirl> I wouyld like to use 1 command to concat+reendode @ 4x... [21:57:33 CEST] <questiongirl> reencode [21:59:12 CEST] <questiongirl> I'm sorry, I don't have the dev skills to fully understand the doc and come up with the 1 line that will do all this :( [22:09:27 CEST] <furq> http://vpaste.net/1Ld01 [22:09:29 CEST] <furq> something like that [22:11:41 CEST] <questiongirl> hey, reading the documentation for concat where you pointed me (https://trac.ffmpeg.org/wiki/Concatenate#samecodec) he uses the exact same for loop [22:11:51 CEST] <questiongirl> to generate his list [22:12:08 CEST] <questiongirl> oh no... wait [22:12:14 CEST] <questiongirl> he uses the way you suggested :) [22:24:31 CEST] <questiongirl> ok, I manage to download the x86 version of ffmpeg (running the git version). Tried the EXACT same command at on the example in the website: ./ffmpeg -f concat -i mylist.txt -c copy output [22:24:52 CEST] <questiongirl> get the error message: Unable to find a suitable output format for 'output'. output: Invalid argument [22:25:13 CEST] <questiongirl> Tried to substitute output --> output.mp4 but not working either. [22:25:24 CEST] <questiongirl> I know, I'm stumbling in the dark here. [22:29:58 CEST] <Phi> can ffmpeg accept a text file of inputs? [22:30:13 CEST] <questiongirl> yes, using the -i [22:30:18 CEST] <questiongirl> argument [22:30:39 CEST] <questiongirl> you need to put "file foo.mpg" on each line [22:30:49 CEST] <questiongirl> so, "file" plus the filename [22:43:42 CEST] <Phi> welp [22:43:52 CEST] <Phi> so it turns out libav* v12 is like, radically different to v11 [22:49:34 CEST] <Phi> and it looks like they haven't implemented it fully yet [22:55:19 CEST] <Phi> "track 0: could not find tag, codec not currently supported in container" [22:55:28 CEST] <Phi> really, a H264 codec isn't supported in an MP4 container [22:56:09 CEST] <JEEB> did you post the full log? [22:56:11 CEST] <Phi> good thing you told me before the entire internet had me fooled [22:56:18 CEST] <JEEB> on a pastebin-like thing [22:56:28 CEST] <Phi> ...yeah [22:56:36 CEST] <Phi> I'll post the whole thing and its helpfulness [22:57:04 CEST] <JEEB> ok, because ISOBMFF totally has AVC supported in it, so either you've built something weirdly or something's not like you think it is [22:57:10 CEST] <Phi> http://pastie.org/private/cojft7e98actrkv3sqz8a [22:57:28 CEST] <Phi> v12 has a very pointlessly verbose RTSP log for some reason [22:57:53 CEST] <JEEB> that's API usage? [22:58:14 CEST] <JEEB> I just don't see lavf's usual output of available input streams [22:58:31 CEST] <JEEB> and the stream mapping which happens [22:58:53 CEST] <JEEB> thus I can't say jack shit out of that, unfortunately [22:59:07 CEST] <Phi> me neither [22:59:07 CEST] <JEEB> might want to add extra logging regarding those things [22:59:18 CEST] <JEEB> like when you probe the streams from input etc [22:59:33 CEST] <Phi> just realised the password's in there [22:59:35 CEST] <JEEB> and how you then create the stream mappings towards output [23:00:04 CEST] <Phi> Barbra Streisand effect [23:00:19 CEST] <Phi> I'll post the code [23:02:11 CEST] <Phi> http://pastie.org/private/uas6irhmiuyzjefpl08frq [23:03:16 CEST] <Phi> it's an unholy mix of v11 and v12, I wonder if I can find a nice conversion guide [23:04:35 CEST] <JEEB> I should really code some API usage again :P I haven't done it in ages (since late 2013 or so) [23:04:50 CEST] <JEEB> I mostly code inside the libraries so my changes don't generally change how an API is used [23:05:58 CEST] <chuprin> will try to ask again& i got a problem when i fetch http stream which reference to key file by https. ffmpeg fails when server respond with self-signed certificate in this case. could someone point me out where TLSContext is initialized during opening HLS stream? im not familiar with C. to be honest, i almost completely dont understand code and magic behind it. where is tls_open is used and why it doesnt respect -verify opti [23:05:59 CEST] <chuprin> key file. [23:07:25 CEST] <chuprin> log http://pastebin.com/TE3ruPxw [23:08:23 CEST] <andrey_utkin_> Does anybody know of charity officially registered in UK or Ireland, dedicated to support of FOSS? [23:19:25 CEST] <Phi> I wonder if there's a v12 guide point blank :p [00:00:00 CEST] --- Tue Oct 25 2016

1 0

ffmpeg-devel.log.20161023
by burek 24 Oct '16

24 Oct '16

[00:01:13 CEST] <cone-176> ffmpeg 03Philip Langdale 07master:ee7d6738ca69: avcodec/cuvid: Allow reinitialization of decoder [00:12:34 CEST] <cone-176> ffmpeg 03Carlos Fernandez 07master:728ccae8a2c9: lavf/mpegts: add missed fixes to scte35 section callback [00:23:44 CEST] <BodecsB> Hi! May I ask about avf_concat? [00:38:22 CEST] <Compn> BodecsB : sure, but this channel is for development, if you have a bug report ask in #ffmpeg [00:40:20 CEST] <BodecsB> I am on writing a new feture into it, namely handling a command. [00:41:11 CEST] <BodecsB> I would like to ask about flush_segment() function. [00:41:22 CEST] <Chloe> Just ask [00:41:59 CEST] <BodecsB> I see it handles the cases when audio streams are shorter than video stream by send_silence() funtion. [00:43:29 CEST] <BodecsB> I tested its behaviour I in cases when video stream(s) are shorter it repeats the last video frame. But I do not see the handling of this case. Which part handles this? [00:44:33 CEST] <BodecsB> Or it is hanled by the last video_buffer sink in filter chain? [00:54:44 CEST] <BodecsB> I see I misstyped some character. So my real question is: What happens when video stream is shorter than audio stream? [03:24:05 CEST] <cone-054> ffmpeg 03Zhou Xiaoyong 07master:b9cd9226609b: avutil/mips: loongson add mmi utils header file [03:24:05 CEST] <cone-054> ffmpeg 03Zhou Xiaoyong 07master:89ec4adad6cb: avcodec/mips: loongson optimize mmi load and store operators [11:58:13 CEST] <cone-279> ffmpeg 03Andreas Cadhalpun 07master:2506a7cc09ca: faq: use relative links to own documentation [13:07:17 CEST] <cone-279> ffmpeg 03Michael Niedermayer 07master:051517648b00: avutil/x86/emms: Document the emms_c() vs alloc/free relation. [17:45:45 CEST] <ubitux> in the end, i'm adding the subtitles frame to lavfi because it simplifies everything [17:45:56 CEST] <ubitux> it's just a shitton of glue code everywhere [19:39:05 CEST] <RiCON> BtbN: any idea what's causing this: https://i.fsbn.eu/s5zr.txt ? [19:39:39 CEST] <BtbN> RiCON, did you rebase the set yourself? [19:39:44 CEST] <BtbN> Or apply the one from the ml? [19:39:45 CEST] <RiCON> yes [19:39:55 CEST] <RiCON> git am'd the bundle with the set [19:39:57 CEST] <BtbN> there was a new patch for cuvid in between [19:40:04 CEST] <BtbN> that uses a cuvid function [19:40:11 CEST] <BtbN> I'll rebase the set, one moment [19:42:12 CEST] <RiCON> oh, philipl's commit, right [19:43:05 CEST] <BtbN> https://github.com/BtbN/FFmpeg/ [20:07:29 CEST] <RiCON> BtbN: yes, that fixed it [20:19:42 CEST] <cone-539> ffmpeg 03Clément BSsch 07master:58672347cb20: lavfi: remove 2 unused lavc includes [20:38:19 CEST] <BtbN> RiCON, for all the warnings... I have no idea how to make MSVC happy there. [20:38:45 CEST] <BtbN> Or rather, gcc on windows. [20:38:59 CEST] <BtbN> There is no typeof() in C. [20:40:47 CEST] <RiCON> http://stackoverflow.com/a/27632640 ? [20:41:35 CEST] <BtbN> GetProcAddress returns a FARPROC [20:41:52 CEST] <BtbN> And it aparently can't be implicitly casted to a function pointer without a warning. [20:42:10 CEST] <BtbN> So I'd have to add a cast to the correct type of the function to each single one. [20:42:20 CEST] <BtbN> Which would massively blow up the source [21:09:55 CEST] <jamrial_> BtbN: compat/w32pthreads.h just casts GetProcAddress to void* [21:10:10 CEST] <jamrial_> and generates no warnings [21:10:19 CEST] <BtbN> hm, I think I tried that already? [21:10:23 CEST] <BtbN> I'll try that [21:33:40 CEST] <BtbN> yes, seems to do the trick. Guess I messed something up the last time. [22:29:55 CEST] <atomnuker> michaelni: got any advice on how to check if a forward float DCT is correct? [22:30:21 CEST] <atomnuker> I'm writing an opus encoder and I've modified the imdct15 to apparently do a forward transform [22:31:07 CEST] <atomnuker> but checking the output is difficult since I don't have a full encoder, the output isn't normalized and I don't really know an easy way to play fwritten() float samples back [22:38:09 CEST] <michaelni> atomnuker, i think theres some mdct test in tests/fft.c, maybe that can be used [00:00:00 CEST] --- Mon Oct 24 2016

1 0

ffmpeg.log.20161023
by burek 24 Oct '16

24 Oct '16

[00:04:21 CEST] <Phi> lol furq [00:04:30 CEST] <Phi> I worked out the reason the writing application was different [00:04:40 CEST] <Phi> I've spent so long trying to get this to work my build was out-dated [01:11:57 CEST] <Guest15626> I've got a performance issue with my use of ffmpeg in my rtmp streaming application [01:12:56 CEST] <Guest15626> if I stream a static image for some number of minutes, and then switch to a different image or video, my CPU and network utilization skyrocket for some period of time [01:13:21 CEST] <Guest15626> it will eventually normalize, but this period of high utilization is crippling [01:13:47 CEST] <Guest15626> I suspect it may have to do with my AVCodecContext settings [01:14:05 CEST] <Guest15626> I'm using ME_HEX as my me_method [03:10:55 CEST] <Phi> welp [03:10:59 CEST] <Phi> the beta is a completely confusing mess [03:11:09 CEST] <Phi> seems slightly more logical [03:11:15 CEST] <Phi> but half-baked too [03:11:32 CEST] <Phi> and a connection with RTSP results in every single character spewed out in a new log line [03:18:16 CEST] <s0126h> why does x265 have proper version system but x264 has crappy version system [03:23:51 CEST] <furq> because they're not developed by the same people [03:24:15 CEST] <furq> not that i think anything is wrong with x264's version numbering [03:27:19 CEST] <klaxa> doesn't x264 just increase by 1 with every release? [03:28:53 CEST] <furq> there's the core number and the revision number [03:29:15 CEST] <furq> if the core number changes then there are breaking api changes [03:29:28 CEST] <klaxa> sound pretty sane to me [03:29:38 CEST] <furq> it's slightly roundabout but broadly fine [03:29:52 CEST] <furq> makes more sense than linux's version numbering anyway [03:44:52 CEST] <s0126h> klaxa how is x264 version system sane [03:45:15 CEST] <furq> what exactly is confusing about it [03:45:21 CEST] <klaxa> newer version, higher number [03:45:35 CEST] <klaxa> why does it have to be like 1.0 and stuff? [03:45:42 CEST] <klaxa> nobody made it a mandatory rule [03:45:43 CEST] <s0126h> furq have you not seen x264 version system [03:45:59 CEST] <furq> no i have never seen it [03:46:09 CEST] <furq> that's why i didn't just explain how it works [03:46:43 CEST] <s0126h> klaxa is that why 99% people use x.x version system [03:47:05 CEST] <klaxa> why is it so important to you that they do that? [03:47:16 CEST] <furq> do you have a complaint other than "it's different from the thing i like" [03:47:21 CEST] <s0126h> because i like to know what version i am using [03:47:29 CEST] <klaxa> but it tells you, no? [03:47:34 CEST] <furq> can you not count over 100 or something [03:47:37 CEST] <klaxa> core X revision Y [03:48:02 CEST] <s0126h> i see bunch of core 64 [03:48:12 CEST] <klaxa> >klaxa@neu ~> x264 --version [03:48:13 CEST] <klaxa> >x264 0.148.2699 a5e06b9 [03:48:13 CEST] <klaxa> >[...] [03:48:19 CEST] <klaxa> it even does the X.X thing for me [03:48:24 CEST] <klaxa> 0.148.2699 [03:48:31 CEST] <s0126h> so what is core 64 then [03:48:40 CEST] <furq> what kind of question is that [03:50:07 CEST] <s0126h> if i have a x265 video that is 1.7 and current version is 2.1, then i have some perspective of how far behind is 1.7 from current version [03:50:07 CEST] <klaxa> the more important thing is to know when which number has to change [03:50:27 CEST] <s0126h> with x264, i have no clue of that perspective [03:50:28 CEST] <klaxa> really though? [03:50:43 CEST] <furq> how is 2.1 vs 1.7 more illuminating than 148 vs 64 [03:50:43 CEST] <klaxa> that's an illusion though [03:50:57 CEST] <klaxa> just look at linux 2.6.insane_high_number [03:51:01 CEST] <furq> all you know in either case is that one number is a bit higher than the other [03:51:08 CEST] <furq> you'd have to check the release dates anyway [03:51:12 CEST] <klaxa> ^ [03:51:54 CEST] <s0126h> if i have PS2 and i know current version is ps4 , then i know i am behind 2 generation.. but if i have xbox1 and current version is xbox-ONE, i am like WTF [03:52:15 CEST] <furq> yeah to work that one you'd have to know things [03:52:17 CEST] <furq> god forbid [03:52:20 CEST] <furq> +out [03:52:38 CEST] <s0126h> calling xbox-one: horrible idea [03:52:49 CEST] <s0126h> and i am microsoft fan [03:53:16 CEST] <klaxa> i'm a fan of many things, microsoft is not one of them [03:54:20 CEST] <s0126h> if you think x264 has good version system, then that is like saying microsoft xbox uses good version system [03:54:44 CEST] <furq> your opinions are bad and you should stop mentioning them [03:54:45 CEST] <klaxa> x264 doesn't jump backwards though [03:55:02 CEST] <klaxa> yeah this has gotten rather off-topic [03:55:03 CEST] <s0126h> okay what is latest version of x264 now? [03:55:17 CEST] <furq> damn, he's right [03:55:29 CEST] <furq> if only x264 used x.y.z versioning we would always know the latest version number [03:56:31 CEST] <s0126h> i see x264 core 65 [03:56:55 CEST] <s0126h> with no revision Y [03:57:13 CEST] <s0126h> what kind of version system adds revision Y later [03:57:20 CEST] <s0126h> but didn't in the beginning [03:59:15 CEST] <s0126h> klaxa explain that [03:59:31 CEST] <klaxa> benevolence of the developer [03:59:58 CEST] <s0126h> huh [04:07:10 CEST] <s0126h> anybody else [04:17:46 CEST] <tobiasBora> Hello, [04:19:33 CEST] <tobiasBora> I would like to know if there is a way to cut precisely a video at a given time [04:19:35 CEST] <tobiasBora> I tried : [04:19:37 CEST] <tobiasBora> ffmpeg -i 2016-10-23\ 02-14-27.mp4 -ss 10.45 -to 01:20 -copyinkf -c copy 02.mp4 [04:19:46 CEST] <furq> probably not with -c copy [04:19:51 CEST] <tobiasBora> but the problem is that the beginning frames are very strange [04:19:56 CEST] <furq> the cut segment has to start on a keyframe [04:20:17 CEST] <tobiasBora> furq: I do need to full recode the whole video only for a few seconds at the beginning ? [04:20:37 CEST] <furq> no? [04:20:56 CEST] <tobiasBora> you know better than me ^^ [04:20:57 CEST] <furq> if you want an exact cut at any timestamp you'll need to encode the segment you're cutting [04:21:06 CEST] <furq> otherwise the segment has to start on a keyframe [04:21:27 CEST] <furq> and maybe end on one too, i forget now [04:21:41 CEST] <tobiasBora> encode only a segment is not a problem, the problem is to encode the whole video [04:21:56 CEST] <tobiasBora> the frame must have the same size ? [04:21:57 CEST] <furq> there's no need to do that [04:22:06 CEST] <furq> if you're reencoding it can be whatever size you want [04:22:54 CEST] <tobiasBora> And if I'm not reencoding the whole video ? [04:24:10 CEST] <furq> uh [04:24:14 CEST] <furq> that's what i meant [04:24:30 CEST] <furq> at no point will i suggest anything to do with reencoding the whole video [04:25:41 CEST] <furq> just replace `-copyinkf -c copy` with `-c:v libx264 -c:a copy " and that command should work fine [04:25:48 CEST] <furq> s/ "/`/ [04:26:53 CEST] <s0126h> tobiasBora what do you think about x264's version system [04:31:46 CEST] <tobiasBora> furq: -c:v libx264 will re-encode everything no ? [04:32:14 CEST] <furq> why would it do that [04:33:20 CEST] <tobiasBora> so how would you re-encode it using libx246 ? [04:33:35 CEST] <furq> if you want to reencode the whole thing then remove -ss and -to [04:34:06 CEST] <s0126h> tobiasBora what do you think about x264's version system [04:34:11 CEST] <tobiasBora> Oh [04:34:17 CEST] <tobiasBora> s0126h: What do you mean ? [04:34:43 CEST] <s0126h> tobasbora do you use x264 ? [04:35:29 CEST] <tobiasBora> furq: Well I use ogg when I can. But sometimes x264 has one advantage : it's faster to convert Mov to x264 rather than MOV to ogg. [04:35:52 CEST] <tobiasBora> * s0126h ^ [04:36:43 CEST] <tobiasBora> furq: Oh ^^ I wanted to say, is it possible to reencode only the first part which is not linked with a key frame, and then say "just read the key frame" [04:37:07 CEST] <tobiasBora> so that it would encode 5 seconds, and copy 1 hours. [04:37:22 CEST] <furq> oh right [04:37:28 CEST] <s0126h> tobiasBora is OGG is just container? [04:37:31 CEST] <s0126h> what do you mean OGG? [04:37:42 CEST] <furq> no, but that command only cuts 80 seconds [04:37:43 CEST] <s0126h> tobiasBora OGG is just container [04:38:08 CEST] <s0126h> i am sure you can put x264 on OGG too [04:38:17 CEST] <furq> you probably could reencode the first gop and then stitch it to the rest, but not in one command [04:38:18 CEST] <tobiasBora> s0126h: Yes, but by ogg I mean everything linked with vorbis [04:38:34 CEST] <furq> you can't put h264 in ogg [04:38:45 CEST] <s0126h> you can't? [04:38:49 CEST] <tobiasBora> h264 isn't free right ? [04:38:53 CEST] <furq> no [04:38:56 CEST] <s0126h> then what video can you put on OGG? [04:38:57 CEST] <furq> and no [04:39:00 CEST] <furq> theora [04:39:09 CEST] <furq> maybe vp8/9 these days [04:39:29 CEST] <s0126h> ogg allows vp* video but not x26* ? [04:39:34 CEST] <s0126h> interesting [04:40:08 CEST] <tobiasBora> yes vp* is ok [04:40:20 CEST] <furq> vp8 works, vp9 doesn't [04:40:23 CEST] <furq> at least in ffmpeg [04:40:32 CEST] <furq> whether anything will play anything but theora i don't know [04:41:09 CEST] <tobiasBora> really ? [04:41:16 CEST] <tobiasBora> oh [04:41:21 CEST] <s0126h> tobiasBora i condone using x264 [04:41:21 CEST] <tobiasBora> webm is not ogg right ? [04:41:28 CEST] <furq> webm is based on mkv [04:41:44 CEST] <s0126h> tobiasBora sorry i mean i frown upon people using x264 [04:42:01 CEST] <s0126h> and i recommend people using x265 [04:42:10 CEST] <tobiasBora> how [04:42:18 CEST] <s0126h> x264 has crappy version system [04:42:26 CEST] <furq> just use x264 [04:42:31 CEST] <tobiasBora> ahah [04:42:33 CEST] <furq> it's still the best [04:42:43 CEST] <s0126h> x265 is better and better version system [04:43:08 CEST] <tobiasBora> One thing I hate is that in mp4 I cannot test my file before the end of the encoding, while I can with webm [04:43:24 CEST] <s0126h> tobiasBora true/agreed that's why i use .mkv [04:43:28 CEST] <furq> if it works with webm it should work with mkv [04:43:56 CEST] <s0126h> i think mkv is superior than .mp4 [04:44:14 CEST] <tobiasBora> what is the difference between all these containers ? [04:44:34 CEST] <furq> none of them were invented by the people who invented the other containers [04:44:59 CEST] <s0126h> and MOV is worse than mp4 [04:45:09 CEST] <furq> mov and mp4 are more or less the same [04:45:47 CEST] <furq> mp4 is an IEC standard, if that matters to you [04:46:46 CEST] <tobiasBora> it's possible to be IEC standard and proprietary ? [04:47:28 CEST] <furq> aren't most ISO standards proprietary [04:48:56 CEST] <furq> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnu… [04:49:00 CEST] <furq> a bargain for 58 CHF [04:50:13 CEST] <s0126h> flv is also horrible container [04:50:31 CEST] <tobiasBora> What about avi ? [04:50:49 CEST] <furq> avi is ancient [04:51:00 CEST] <furq> just use mkv [04:51:12 CEST] <furq> it supports everything and it's open [04:51:28 CEST] <furq> if you happen to need mp4 you can just remux [04:51:41 CEST] <s0126h> why was avi popular before h264 [04:51:58 CEST] <furq> what does h264 have to do with it [04:52:29 CEST] <s0126h> because avi became unpopular after h264 [04:53:15 CEST] <furq> most modern codecs don't work in avi without hacks [04:54:12 CEST] <s0126h> then why was avi popular even before h264 [04:54:34 CEST] <s0126h> - "even" [04:55:31 CEST] <furq> familiarity i guess [04:55:55 CEST] <tobiasBora> both h264 and mp4 are proprietary ? [04:56:00 CEST] <furq> yes [04:56:22 CEST] <s0126h> tobiasBora almost everything is proprietary [04:56:42 CEST] <tobiasBora> webm + vp* is not ! [04:56:53 CEST] <s0126h> vp9 certainly is [04:57:34 CEST] <s0126h> tobiasBora if you invented vp9 or mp3,, would you give it away for free when you can make money off it [04:57:55 CEST] <tobiasBora> vp9 is proprietary O_o [04:58:05 CEST] <furq> vp9 is open-source and license-free [04:58:15 CEST] <tobiasBora> hum yes [04:58:33 CEST] <s0126h> tobiasBora you are obviously lying [04:58:43 CEST] <tobiasBora> VP9 est un codec vidéo ouvert et sans redevance [04:59:03 CEST] <tobiasBora> VP9 is an open and royalty free[1] video coding format developed by Google. [04:59:05 CEST] <tobiasBora> Wikipedia [04:59:07 CEST] <s0126h> furq if you invented vp9 or mp3,, would you give it away for free when you can make money off it [04:59:46 CEST] <furq> why are you asking me [04:59:54 CEST] <s0126h> why not [04:59:57 CEST] <s0126h> just a question [04:59:58 CEST] <tobiasBora> Well yes, fees and royalties kill innovation [05:00:49 CEST] <s0126h> furq by not answering the question, it gives away what your honest answer is [05:02:20 CEST] <furq> i already told you i use x264 [05:02:26 CEST] <furq> because it has the best version numbers [05:03:08 CEST] <s0126h> furq if you invented vp9 or mp3,, would you give it away for free when you can make money off it [05:05:02 CEST] <furq> http://4.bp.blogspot.com/_tK5X1ZCnM_w/SoQ2eszv8oI/AAAAAAAABII/nH4VDE1xQLs/s… [05:05:05 CEST] <furq> they say a picture is worth 1000 words [05:06:07 CEST] <s0126h> ?? [05:09:19 CEST] <s0126h> why do people lie in freenode? damn it's only irc, no need to lie [06:31:49 CEST] <solenodic> is there any way to re-encode a file in a streaming fashion (e.g. write to the new file at the same FPS as the actual video instead of instantly writing it) [06:33:48 CEST] <furq> -re [06:35:10 CEST] <solenodic> thanks [07:28:18 CEST] <BinaryBench> Greetings [07:29:26 CEST] <BinaryBench> I'm trying to stream from one computer to another with as low latency as possible from Windows to Mac, what's the best way to do this? [07:29:47 CEST] <BinaryBench> atm I'm doing: ffmpeg -f dshow -i video="UScreenCapture" -r 30 -vcodec libx264 -pix_fmt yuv444p -tune zerolatency -preset ultrafast -f mpegts udp://localhost:6666 [07:30:06 CEST] <BinaryBench> However this is still giving me approx 300ms latency [07:31:20 CEST] <JEEB> libx264 itself is very low latency, so it's mostly the FFmpeg things around it that you have to try and optimize [07:31:23 CEST] <furq> are you sure it's encoder latency and not playback latency [07:31:48 CEST] <JEEB> and then of course you have the playback side in whatever you're using [07:32:06 CEST] <furq> you need to mess with the vbv to get the lowest possible latency, but 300ms seems quite high [07:32:09 CEST] <BinaryBench> furq: I'm not sure which it is, it may be play back [07:32:27 CEST] <furq> it could also be from the capture driver [07:32:30 CEST] <BinaryBench> I don't think it's internet latency as I'm testing on localhost atm [07:32:46 CEST] <furq> what are you playing it with [07:32:56 CEST] <BinaryBench> UScreenCapture [07:33:13 CEST] <furq> test it with ffplay -fflags nobuffer [07:34:36 CEST] <BinaryBench> furq: that helped a good deal, but still not quite as fast as what I'm looking for [07:35:06 CEST] <furq> maybe test with `-f lavfi -i testsrc` instead of dshow to rule out the capture device [07:36:33 CEST] <BinaryBench> furq: how do I see the latency? [07:37:03 CEST] <furq> that is a good point [07:37:07 CEST] <furq> maybe the tee muxer [07:37:11 CEST] <BinaryBench> (before I was just viewing a timer & subtracting the difference [07:37:14 CEST] <BinaryBench> ) [07:37:20 CEST] <BinaryBench> Hum, tee muxer? [07:37:30 CEST] <furq> last time i used that i just compared the video timestamp and the ffmpeg timestamp, but that was to a remote rtmp server [07:37:40 CEST] <furq> it's not accurate enough to measure sub-500ms latency [07:38:26 CEST] <BinaryBench> Hum, well, any ideas? [07:40:56 CEST] <furq> tee would be -f tee -map 0:v "[f=mpegts]pipe:1|[f=mpegts]udp://127.0.0.1:6666" | ffplay -fflags nobuffer - [07:41:04 CEST] <furq> i guess that's useful for checking if there's some kind of network latency [07:42:12 CEST] <furq> https://web.archive.org/web/20150507012544/http://x264dev.multimedia.cx/arc… [07:42:17 CEST] <furq> that has some pointers on reducing x264 latency [07:42:44 CEST] <furq> specifically comment #8 [07:47:52 CEST] <BinaryBench> furq: what would the packet size be? [07:50:49 CEST] <furq> probably your router's MTU [07:52:10 CEST] <JEEB> libx264 itself is capable of very low latencies, it's usually the rest around it that causes additional latency [07:53:56 CEST] <BinaryBench> JEEB, what usually is the culprit? [07:54:32 CEST] <JEEB> can't really say because I have no idea which thing in your case is causing it :P [07:54:41 CEST] <furq> BinaryBench: you can probably ignore slice-max-size [07:55:02 CEST] <furq> if that is your mtu then i imagine that'll do more harm than good without jumbo frames [07:55:04 CEST] <JEEB> I mean, you are using ffmpeg cli which is in turn using the libraries in some way, which in turn... [07:55:04 CEST] <BinaryBench> furq: How do I add parameters to libx264 in ffmpeg? [07:55:10 CEST] <JEEB> -x264-params [07:55:15 CEST] <JEEB> and then key=val [07:55:27 CEST] <JEEB> with : as the delimiter between settings [07:55:52 CEST] <furq> those are mapped in ffmpeg -maxrate, -bufsize and -intra-refres [07:55:55 CEST] <furq> +as [07:56:03 CEST] <furq> -intra-refresh [11:00:44 CEST] <Ecco> Hi guys [11:01:15 CEST] <Ecco> I'd like to encode a video that allows for fast random access (i.e. going to frame #x is as fast as possible) [11:01:32 CEST] <Ecco> My understanding is that I'll need to make every frame a keyframe. Is that correct? [11:01:49 CEST] <Ecco> If that is the case, would any codec behave significantly better than a succession of JPEG files? [11:03:02 CEST] <JEEB> do you need lossy or lossless? [11:03:54 CEST] <Ecco> JEEB: I can deal with lossy [11:04:26 CEST] <JEEB> -c:v libx264 -preset slowest_you_can_take -crf XX (highest that still looks OK for you) [11:04:40 CEST] <JEEB> usually though for quick seeking I use ~3-4 picture GOPs [11:04:48 CEST] <Ecco> ok [11:04:59 CEST] <Ecco> Thanks for the command line, but what about the "theoretical" question? [11:05:59 CEST] <JEEB> you just need short enough GOPs for the fastest seeking at all times, all-intra is not necessary, but of course the last resort [11:06:49 CEST] <Ecco> Ok, got it. Thanks :) [11:07:17 CEST] <JEEB> also trying out -tune fastdecode might also be worth a try depending on what you're decoding the stuff on [11:07:34 CEST] <Ecco> ok [11:07:43 CEST] <Ecco> thanks [11:37:56 CEST] <furq> Ecco: x264 should be much smaller than a bunch of jpegs [11:38:09 CEST] <furq> even with -g 1 [11:48:45 CEST] <Ecco> furq: thanks [14:36:27 CEST] <pyBlob> I'm using ffplay on arch, and somehow the playback window does not react to keystrokes [14:36:41 CEST] <pyBlob> also clicking on the window doesn't do seeking [16:31:09 CEST] <iMath> for a ffmpeg time 00:05:25.80, what does ".80" mean? [16:37:12 CEST] <__jack__> sub-seconds [16:37:29 CEST] <c_14> milliseconds [16:38:05 CEST] <iMath> sub-seconds and milliseconds are the same? [16:46:24 CEST] <DHE> milliseconds are 1/1000 [16:46:30 CEST] <DHE> .80 would be 8/10 [16:50:25 CEST] <LinuxLoader> Hi , did someone have issues with ffprbe under centos7 , stream is comming to the interface ( udp stream ) but no info is shown [16:50:46 CEST] <DHE> check for things like iptables blocking said stream [16:50:54 CEST] <LinuxLoader> none rules [16:50:58 CEST] <LinuxLoader> ipforward is ok [16:51:13 CEST] <DHE> multiple interfaces? [16:51:13 CEST] <iMath> DHE: what does ".80" mean in ffmpeg ? [16:51:27 CEST] <DHE> iMath: I already answered that question [16:51:34 CEST] <LinuxLoader> yep , one for uplink one for udp stream [16:51:53 CEST] <DHE> LinuxLoader: for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $i ; done [16:52:01 CEST] <LinuxLoader> i tried with ffmpeg from some repos , and manualy compiled , same shit [16:52:10 CEST] <LinuxLoader> yep , and rpfilter is ok :) [16:53:01 CEST] <LinuxLoader> fsck :( deam [16:53:20 CEST] <iMath> DHE: still cannot understand [16:53:38 CEST] <LinuxLoader> DHE 10x man ... but strange [16:53:42 CEST] <LinuxLoader> net.ipv4.conf.default.force_igmp_version=2 [16:53:42 CEST] <LinuxLoader> net.ipv4.conf.all.force_igmp_version=2 [16:53:42 CEST] <LinuxLoader> net.ipv4.conf.all.rp_filter=0 [16:53:42 CEST] <LinuxLoader> net.ipv4.ip_forward=1 [16:53:47 CEST] <LinuxLoader> in sysctl [16:54:00 CEST] <DHE> don't trust the 'all' setting for rp_filter. check 'default' and the interface involved [16:54:07 CEST] <LinuxLoader> din`t work :) [16:54:35 CEST] <LinuxLoader> 10x again ... got rly stuped right now , lost 2 days in that [16:54:35 CEST] <DHE> hmm... those tricks do it for me... [16:54:58 CEST] <DHE> strace -f your ffprobe and see if it's recv()ing the data. [16:58:01 CEST] <LinuxLoader> just got engry that only centos is supported for intel quick sync in kernel [17:08:59 CEST] <Thaconut> I've compiled ffmpeg with x11grab. How can I pipe the contents of screen 0 to a new mplayer instance running on screen 1? [17:09:20 CEST] <Thaconut> "ffmpeg -video_side 640x480 -framerate 25 -f x11grab -i :0.0+0,0 - | mplayer - " says its unable to find a suitable output format for 'pipe:' [17:09:41 CEST] <Thaconut> *video_size [17:11:32 CEST] <klaxa> add -f matroska [17:11:47 CEST] <klaxa> before - [17:12:05 CEST] <Thaconut> klaxa: I'll try that [17:12:14 CEST] <klaxa> (since '-' has no file extension ffmpeg can't guess what format you want, so you have to say it explicitly) [17:12:51 CEST] <Thaconut> Ooh it's doing something now [17:13:23 CEST] <Thaconut> Its not crashing anymore (although now mplayer won't open) [17:13:25 CEST] <Thaconut> Thanks! [17:27:49 CEST] <Mad7Scientist> apparently mp3 won't go under -ar 8000 -b:a 8k [17:30:03 CEST] <BtbN> not exactly surprising [17:30:29 CEST] <BtbN> you are merely giving it one bit per sample. [17:31:11 CEST] <BtbN> And that sample rate alone is enough to ruin any kind of audio [17:35:02 CEST] <iive> technically 44khz stereo is 1,4mbps, so encoded at 128kbps gives similar ratio. [17:35:17 CEST] <iive> it's just that mp3 is not optimized for low bitrates. [17:43:56 CEST] <DHE> well, it's hard to argue with a 50% bitrate increase even if you're starting from crap [18:19:21 CEST] <sopparus> anyone know if quick sync ork on freebsd? [18:25:57 CEST] <BtbN> QSV only somewhat "works" on Windows. [18:26:53 CEST] <sopparus> I see [18:27:13 CEST] <BtbN> In theory it exists on linux, but i'd forget about that. [18:29:44 CEST] <relaxed> vaapi should work on freebsd [18:39:44 CEST] <Mad7Scientist> How do I just see info about the input file and then exit? [18:54:09 CEST] <BtbN> by using ffprobe. [19:07:46 CEST] <Mad7Scientist> thanks [19:08:22 CEST] <Mad7Scientist> How can youtube have a 640x480 video like this: Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 589 kb/s, 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc (default) [19:08:36 CEST] <Mad7Scientist> That looks almost as good as a DVD which is almost 10 times the bit rate? [19:15:02 CEST] <JEEB> Mad7Scientist: first of all it probably doesn't look too good (in general). but dvd is mpeg-2 video, has a bufsize of 1.5mbits (which is like less than a quarter of a second with 8mbps maxrate). and dvds have very short GOPs, usually a second or less. [19:15:51 CEST] <JEEB> dvds are not really a high quality medium given the limitations [19:16:27 CEST] <JEEB> blu-rays at least have the capacity of being utilized as such [19:17:18 CEST] <JEEB> (40mbps maxrate, 1 second bufsize, avc is permitted) [19:18:06 CEST] <BtbN> why are they using that short of a bufsize though? [20:20:51 CEST] <Mad7Scientist> What's GOP? [20:21:27 CEST] <c_14> https://en.wikipedia.org/wiki/Group_of_pictures [20:23:02 CEST] <JEEB> BtbN: DVD is old [20:23:14 CEST] <JEEB> it was designed in the early-to-mid 1990s [20:29:17 CEST] <BtbN> But even then [20:29:24 CEST] <BtbN> such a short gop interval and buffer size [20:29:40 CEST] <BtbN> it's not like you need to be able to enter the "stream" at any point [20:31:20 CEST] <JEEB> well it was made for the hardware designs they had back then [20:31:35 CEST] <JEEB> and 1.5 megabits was quite a bit more than how it feels now [20:31:45 CEST] <JEEB> like twenty+ years later [20:55:07 CEST] <DHE> sorta does. DVDs did have chapter seeking, time seeking, and the expectation that the player would run at "1x" speed. so under those requirements it makes sense... [20:55:17 CEST] <DHE> sure, by today's standards that's laughable [21:15:37 CEST] <Mad7Scientist> mpeg2 produces higher quality than mpeg4 at the same higher bit rates though [21:15:44 CEST] <Mad7Scientist> so 4mb should be plenty [21:17:12 CEST] <JEEB> which MPEG-4 spec are you talking of? Part 2 (MPEG-4 Visual) or Part 10 (MPEG-4 Advanced Video Coding) [21:17:53 CEST] <JEEB> in either case, the bit rates where the difference between MPEG-2 Visual and MPEG-4 AVC go away are nowhere near the rates that DVDs use [21:18:16 CEST] <JEEB> it's just that DVD is shit and the limitations youtube has picked for itself are shit, but less shit [21:18:44 CEST] <JEEB> also youtube is utilizing stuff from 2003 and later, while DVDs utilize tech from early 1990s [21:28:25 CEST] <Mad7Scientist> Is MPEG-4 AVC similar or the same as h264? [21:30:19 CEST] <JEEB> yes [21:30:38 CEST] <JEEB> AVC is the ISO/IEC name, and then those specs made in co-operation with ITU-T also get an identifier there [21:30:48 CEST] <JEEB> H.264 is AVC's and H.265 is HEVC's [22:39:22 CEST] <chuprin_> hi. guys. is there any way to allow insecure connection when i use hls stream as input. ffmpeg unable to open key file because server use self signed certificate [22:39:47 CEST] <chuprin_> piece of log http://pastebin.com/TE3ruPxw [22:47:41 CEST] <DHE> chuprin_: might try adding "-verify 0" to the commandline just before "-i ..." [22:47:50 CEST] <DHE> I'm not sure if that will work since it's a sub-request of the hls layer... [22:49:31 CEST] <DHE> from a code examination, I'm guessing not... [22:51:51 CEST] <chuprin_> hm& "Reading option '-verify' ...Unrecognized option 'verify'." pasted just before -i [22:52:09 CEST] <chuprin_> ffmpeg version 3.1.4 [23:32:15 CEST] <Mad7Scientist> Does taking something that is h264 / AVC and recompressing it in mpeg2 affect the quality and size of the mpeg2 video? [23:33:17 CEST] <Mad7Scientist> I went from 1080 youtube to -s 960x540 and it looks great [23:33:22 CEST] <furq> compared to what [23:33:29 CEST] <Mad7Scientist> to what I'm used to [23:34:06 CEST] <Mad7Scientist> but I wonder if having it already compressed in the previous lossy format makes the mpeg2 compression require less of a bit rate [23:34:58 CEST] <BtbN> it makes it lose quality [23:35:13 CEST] <furq> if it does make it smaller then it's from quality loss, yeah [23:35:30 CEST] <furq> if the source is youtube then it's probably been aggressively denoised [23:36:32 CEST] <Mad7Scientist> At a certain distance nobody can really tell 1080p from 540p [23:37:04 CEST] <furq> most people can tell blu-ray 1080p from youtube 1080p though [23:37:05 CEST] <Mad7Scientist> But they may still be able to see the other things done to reduce bit rate that vary between formats [23:37:17 CEST] <furq> it's very obvious with some sources [23:37:21 CEST] <Mad7Scientist> right and they can see that from a distance [23:38:18 CEST] <Mad7Scientist> I need an actual proper source of 1080p to experiment with [23:40:38 CEST] <furq> https://media.xiph.org/video/derf/ [23:40:48 CEST] <furq> there are some 1080p rawvideo samples near the bottom [23:45:51 CEST] <Mad7Scientist> thanks [23:50:18 CEST] <Mad7Scientist> 40GB video clips! [00:00:00 CEST] --- Mon Oct 24 2016

1 0

ffmpeg-devel.log.20161022
by burek 23 Oct '16

23 Oct '16

[00:05:18 CEST] <nevcairiel> jkqxz: did you test the vc1 decoding? it seems to rely on the parser setting coded_width/height and pix_fmt, but i dont think the vc1 parser does that (but it could be made to do that) [00:07:25 CEST] <nevcairiel> unless it does that secretly somewhere that i didnt spot yet [00:24:44 CEST] <jkqxz> nevcairiel: Once, it was a very cursory "see one thing work and then ignore it because I don't care" test. [00:24:50 CEST] <jkqxz> Let me try again. [00:34:38 CEST] <jkqxz> Ah. From my command history, I used -hwaccel (rather than -c:v) to test that, which silently does nothing (decodes on CPU, which of course succeeds). [00:34:45 CEST] <jkqxz> Indeed it fails to get the pix_fmt. [00:41:08 CEST] <RiCON> jkqxz: trying with mpv on an ivy cpu, mpeg2 and h264 don't work, they do without the patch [00:42:06 CEST] <jkqxz> (MPEG-2 might not work for the same reason.) [00:42:54 CEST] <jkqxz> (That I totally failed at testing it, I mean.) [00:43:08 CEST] <jkqxz> How does it fail? What media SDK version? [00:43:21 CEST] <RiCON> i'm using mfx_dispatch [00:46:16 CEST] <RiCON> https://i.fsbn.eu/old-mpeg2.txt https://i.fsbn.eu/new-mpeg2.txt https://i.fsbn.eu/old-h264.txt https://i.fsbn.eu/new-h264.txt [00:48:07 CEST] <jkqxz> The parser for H.264 has messed up somehow. [00:49:50 CEST] <jkqxz> Not sure about MPEG-2. [00:51:35 CEST] <jkqxz> MPEG-2 does work for me when I run it properly. [00:52:16 CEST] <RiCON> i'll check with just ffmpeg [00:52:31 CEST] <RiCON> -hwaccel qsv or -c:v qsv_? [00:52:37 CEST] <jkqxz> The latter. [00:58:26 CEST] <RiCON> https://i.fsbn.eu/ffmpeg-new-mpeg2.txt https://i.fsbn.eu/ffmpeg-new-h264.txt [01:36:52 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07release/3.1:2fece989f824: doc/examples/demuxing_decoding: Drop AVFrame->pts use [01:36:53 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07release/3.1:de487cb765ca: avcodec/utils: Clear MMX state before returning from avcodec_default_execute*() [01:36:54 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07release/3.1:6456a7416e8f: avcodec/mpegvideo_enc: Clear mmx state in ff_mpv_reallocate_putbitbuffer() [01:36:55 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07release/3.1:9e6586ceb2f2: avformat/mxfdec: Check size to avoid integer overflow in mxf_read_utf16_string() [01:41:10 CEST] <RiCON> jkqxz: seems to work with the patch [01:41:39 CEST] <RiCON> the mpeg2 still no [01:42:25 CEST] <RiCON> right, the diff just changed h264 [01:47:19 CEST] <jkqxz> I don't think that problem is related to qsv, then. Your file is annex B but parsed as AVCC, maybe? [01:47:47 CEST] <jkqxz> Does libav/avconv work? [01:50:56 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07release/3.1:2a5c41e3e4a7: Chagelog: update [01:52:00 CEST] <RiCON> i don't have it compiled to check [02:13:29 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07n3.1.5:HEAD: doc: fix spelling errors [02:19:08 CEST] <kierank> Good to see the scte-35 stuff got pushed in spite of all the objections [02:19:16 CEST] <kierank> Such maturity [02:23:12 CEST] <RiCON> jkqxz: mpeg-2 seems to not work as well, but h264 works [02:24:13 CEST] <RiCON> https://i.fsbn.eu/mpeg2-libav.txt [03:18:59 CEST] <cone-212> ffmpeg 03Kagami Hiiragi 07master:41da4f8cb3a7: lavc/libvpxenc: fix -auto-alt-ref option type [03:57:22 CEST] <cone-212> ffmpeg 03Carl Eugen Hoyos 07master:6969bed12c6f: lavf/rtpdec_g726: Map mime type G726 to g726le. [10:19:18 CEST] <nevcairiel> jkqxz: the h264 stuff is an interesting problem - mostly coming from the fact that the libav h264 parser actually can't parse avcc h264 streams, so it also has no attempts to handle it - but ours can, so it then tries to handle it, and gets confused in qsv because it gets passed through a bsf first :d [10:21:25 CEST] <nevcairiel> an easy solution would be to either strip or convert the extradata in the internal avctx in ff_qsv_process_data [10:56:32 CEST] <jkqxz> The altenative being to add more complexity to the parser to identify which type a stream is independent of the extradata? [11:08:10 CEST] <nevcairiel> you need the extradata to parse avc [11:10:00 CEST] <nevcairiel> the actual decoder has some hackery to try to detect annexb streams with an avc extradata header because that sometimes happens in broken files (usually not the other w ay around though since that would be much harder) [11:10:09 CEST] <jkqxz> Yes, but it could spot that later packets are actually annex B. [11:10:12 CEST] <nevcairiel> i suppose the parser could adapt that, but meh [11:16:03 CEST] <jkqxz> Hmm, ok. You first solution with stripping the extradata is probably the right one - there is no actual use for it there (the current qsv decoder never touches it at all). [11:16:27 CEST] <nevcairiel> the parser reads it of course, but annexb extradata is supposed to be in the stream anyway [11:17:39 CEST] <nevcairiel> a more complete solution would be to put the pre-converted extradata somehow in QSVContext inside qsvdec_h2645 and then use that for the internal avctx, the bsf produces it anyway in the codecpar [11:18:52 CEST] <nevcairiel> that way it would make sure nothing is lost [11:20:01 CEST] <nevcairiel> that would be much easier if parsers were updated to codecpar yet [11:26:43 CEST] <jkqxz> I'm not seeing what you are suggesting is then done with the extradata? [11:27:12 CEST] <nevcairiel> use that for the internal avctx so it contains annexb extradata and the parser can read it without getting confused [11:32:21 CEST] <jkqxz> Which shouldn't make a difference against not having it at all because it's already in the annex B stream, but yes I suppose it is more correct. [14:28:12 CEST] <cone-061> ffmpeg 03Michael Niedermayer 07master:70dc6bbf1bf0: avcodec/svq1enc: Clear MMX state after svq1_encode_plane() [14:28:13 CEST] <cone-061> ffmpeg 03Michael Niedermayer 07master:493ad519ddee: avcodec/cavsdec: Clear MMX state after MB decode loop [14:28:14 CEST] <cone-061> ffmpeg 03Michael Niedermayer 07master:966c5c7bb8ba: avcodec/utils: Move emms_c() before memory allocation functions in avcodec_encode_video2() [14:28:15 CEST] <cone-061> ffmpeg 03Michael Niedermayer 07master:de0cd0ffc9e4: avcodec/mpegvideo_enc: Add missing emms_c() to clear MMX state after SIMD use [14:28:16 CEST] <cone-061> ffmpeg 03Michael Niedermayer 07master:2c1d38d1e1c2: avcodec/snowenc: Clear MMX state after edge drawing and picture encode [14:28:17 CEST] <cone-061> ffmpeg 03Michael Niedermayer 07master:f5495c970cf2: avutil/avassert: Add av_assertX_fpu() [15:06:32 CEST] <Matador> weee QSV talk.. keep it goin [19:24:13 CEST] <cone-061> ffmpeg 03Andreas Cadhalpun 07master:178eebd79e5b: mpegts: handle AVMEDIA_TYPE_UNKNOWN correctly [20:52:28 CEST] <cone-061> ffmpeg 03James Almer 07master:cc71fa319fd7: avformat/matroskaenc: write DisplayWidth and DisplayHeight elements only if they differ from PixelWidth and PixelHeight [23:35:13 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/1b1615481b18ec7cee64eadbe1608e71d5… [23:35:23 CEST] <philipl> Tested with a TV stream with resolution changes [23:54:43 CEST] <BtbN> should be fine, feel free to push (without using cvdl for master, of course) [23:54:57 CEST] <philipl> of course. [00:00:00 CEST] --- Sun Oct 23 2016

1 0

ffmpeg.log.20161022
by burek 23 Oct '16

23 Oct '16

[00:39:57 CEST] <Phi> hey folks [02:25:09 CEST] <{{{}}}> hey there, im on linux mint and i followed this guide to build ffmpeg: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [02:26:28 CEST] <{{{}}}> when i tried to use the play() function in python using pydub, it defaults to ffmpeg and i get this error: PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \ Invalid Syntax [02:28:20 CEST] <t4nk860> Hi, I have a small question regarding lossless compression using x264 (or x265,vp9): [02:29:48 CEST] <t4nk860> I used `ffmpeg -i $input -c:v libx264 -crf 0 $output` [02:29:52 CEST] <t4nk860> for lossless compression [02:30:19 CEST] <t4nk860> However, the resulting frames seem to be different (different output for some image processing algo) [02:30:33 CEST] <t4nk860> Does crf 0 not produce perfectly lossless? [02:30:55 CEST] <t4nk860> If not, what can I do to obtain lossless performance? [02:31:08 CEST] <furq> use -qp 0 if you want to be sure it's lossless [02:31:14 CEST] <furq> -crf 0 is only lossless with 8-bit output [02:32:00 CEST] <furq> you can also check the frames are identical with the framehash muxer [02:32:26 CEST] <t4nk860> Thanks for the feedback. I will try with qp 0 [02:36:45 CEST] <DHE> t4nk860: there's still colourspace conversion loss before x264 even gets the frames. consider libx264rgb or yuv444 mode depending on what you're up to exactly. [02:37:17 CEST] <furq> it should default to yuv444p if the input is rgb [02:41:19 CEST] <{{{}}}> okay woops i figured out why i got that error. i have a new one now. [02:41:29 CEST] <{{{}}}> it isnt finding ffplay, do i need to install that package seperately? [02:42:14 CEST] <t4nk860> DHE: Thanks for pointing this out. Yes, I am manually specifying the format to be yuv444p (even if it might not be necessary) [02:44:49 CEST] <t4nk860> furq: Will the `-qp 0` flag also work for vp9, x265? ( https://trac.ffmpeg.org/wiki/Encode/VP9 says to explicitly state -lossless 1 flag... but was wondering the original soln will work) [02:45:15 CEST] <furq> i have no idea [02:45:28 CEST] <furq> i doubt it [02:46:43 CEST] <furq> apparently qp 4 is lossless in x265, but i don't know if -qp is actually mapped to anything in libx265 [02:47:00 CEST] <furq> you might need -x265-params qp=4 (or whatever the syntax is) [02:47:53 CEST] <furq> -x265-params lossless=1 [02:50:39 CEST] <t4nk860> cool.. ll try it out [14:37:56 CEST] <beauty> hello [14:38:21 CEST] <beauty> what's the aligned data and none-aliged data?? [14:38:51 CEST] <JEEB> aligned allocation of data so that the ways it's handled can be optimized [14:40:05 CEST] <beauty> could you give a example? [14:48:41 CEST] <DHE> SSE-style instructions work in 128 bit typically. but that means if your memory allocation isn't a multiple of 128 bits your program may crash while doing image processing [14:51:29 CEST] <beauty> thanks [15:03:02 CEST] <Phi> moop [15:03:31 CEST] <Phi> can anyone tell me how to access libx264's internal data while encoding? [15:03:59 CEST] <Phi> AVCodecCtx::priv_data has null x264 encoder and stuff [15:04:11 CEST] <Phi> also hi [15:17:51 CEST] <BtbN> "libx264's internal data"? [15:36:07 CEST] <DHE> x264 only exposes a configuration data structure with things like bitrate, keyframe interval, image size, etc. and even then there's an API to deal with only the text names/values so you can minimize a lot of xx264 structure data access [16:01:41 CEST] <Phi> yea DHE, but in this case, I'm passing options to libx264 via libav* and they're being ignored [16:02:26 CEST] <Phi> to get more debugging info I need to access whatever libav* is accessing, because what it's exposing as output options seems to have no bearing on the *actual* options [16:03:41 CEST] <Phi> vis a vie, I set profile to "baseline" in any option I can, and it just sets it to high [16:05:49 CEST] <Phi> from what I understand you can encode a H264 stream from one profile to another, but it's not doing that, it insists on reflecting the input profile/level [16:08:07 CEST] <Phi> I did see notes that you can't downgrade a profile in x264_param_set_profile(), but the input and output should be completely unrelated [16:08:46 CEST] <Phi> unless I have to decode every frame to an image, then encode the image to the new stream, I'm at a loss [16:09:11 CEST] <BtbN> There is no such information carried over at all. [16:09:23 CEST] <BtbN> x264 takes raw images in, and produces h264. [16:09:32 CEST] <BtbN> All according to the options you pass it. [16:09:42 CEST] <Phi> I've passed baseline in every option I can find [16:09:58 CEST] <Phi> codeccontext->profile, av_opt_set(codecctx->priv_data, "profile" ... [16:10:17 CEST] <BtbN> likely some other option you pass overrides it. [16:10:24 CEST] <BtbN> baseline has quite a few constraints [16:10:39 CEST] <Phi> well, atm I'm just passing baseline, all the other options are defaults [16:11:47 CEST] <BtbN> what chroma format? What resolution? [16:12:01 CEST] <Phi> YUV420p, and whatever the RTSP is [16:12:26 CEST] <Phi> I tried two methods - av_copy_context from the RTSP, and av_context_defaults with manually setting width, height, etc [16:12:49 CEST] <Phi> http://stackoverflow.com/questions/40053873/ffmpeg-rtsp-stream-to-mpeg4-h26… [16:13:01 CEST] <BtbN> encoding baseline works fine for me. You are doing something wrong. [16:13:25 CEST] <Phi> I hope I am, otherwise the libav* guys are doing something wrong :3 [16:14:23 CEST] <Phi> X264Context *x4 = (X264Context *)video_file_stream->codec->priv_data; // is that valid? [16:14:33 CEST] <Phi> because x4->enc, the encoder, is always null [16:15:06 CEST] <BtbN> X264Context is a private struct inside of libx264.c [16:15:16 CEST] <BtbN> you can't access it from the outside anyway, except for setting AVOptions [16:15:33 CEST] <BtbN> *via setting AVOptions [16:15:43 CEST] <Phi> I'm doing read-only trying to read variables for debugging [16:15:46 CEST] <BtbN> priv_data is called private for a reason [16:16:17 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L677 [16:16:17 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L729 [16:16:39 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L905 [16:16:47 CEST] <BtbN> looks fine, and works fine, for me. [16:17:04 CEST] <Phi> not at all for me XD [16:17:13 CEST] <BtbN> you're doing something wrong then. [16:18:22 CEST] <Phi> well, the code's in the link I posted [16:18:57 CEST] <Phi> so to clarify, to set profile I merely change avcodecctx->profile, before I encode the first frame? [16:21:11 CEST] <Phi> is it required I call avcodec_open before the first frame? [16:22:58 CEST] <BtbN> Of course you have to open the encoder before you can use it. [16:23:04 CEST] <Phi> weirdly not [16:23:16 CEST] <Phi> when I do it tends to error [16:23:25 CEST] <Phi> and I still get an MP4 without one [16:23:32 CEST] <Phi> so I'm guessing something is screwed up before then [16:24:03 CEST] <Phi> the examples I've seen don't include calling avcodec_open [16:24:18 CEST] <Phi> to clarify, I'm doing it inside an AVFormatContext's stream [16:27:12 CEST] <Phi> so, it's av_guess_format for MP4 [16:27:27 CEST] <Phi> avformat_alloc_context for the format [16:27:49 CEST] <Phi> set oformat for that context to the av_guess_format [16:28:24 CEST] <Phi> set filename for format context to oformat's filename [16:28:38 CEST] <Phi> avcodec_find_encoder for the formatcontext's video codec [16:28:56 CEST] <Phi> then call avio_open2 on format context's pb [16:29:04 CEST] <Phi> then call avformat_new_stream [16:29:19 CEST] <Phi> then I set options [16:29:27 CEST] <Phi> then avcodec_open2 [16:29:31 CEST] <Phi> then avformat_write_header [16:29:36 CEST] <Phi> then av_write_frame to infinity [16:29:49 CEST] <Phi> is that the right order? [16:44:00 CEST] <rzz> hi, does anyone have experience in switching audio track from 3d mkv? [16:44:35 CEST] <rzz> I seem to get lot of stuttering and dropped frames [16:45:01 CEST] <beauty> https://ffmpeg.org/doxygen/trunk/doc_2examples_2decoding_encoding_8c-exampl… [16:45:11 CEST] <beauty> fwrite(decoded_frame->data[0], 1, data_size, outfile); [16:45:32 CEST] <beauty> the audio can't be played in example program. [16:47:00 CEST] <beauty> Is it beacause the decoded data is AV_SAMPLE_FMT_FLTP ,but the way to write data[0] to file is wrong? [16:49:56 CEST] <Phi> sorry, new to libav* [17:52:45 CEST] <AlienCat> hey [17:53:13 CEST] <AlienCat> I am trying to convert an SILK V3 amr file [17:53:34 CEST] <AlienCat> ffmpeg -i msg.amr -c:v opus glass.wav [17:53:42 CEST] <AlienCat> but it doesn't work [17:54:00 CEST] <AlienCat> Invalid frame size (732): Could not seek to 4174. [17:54:07 CEST] <AlienCat> got this mp3 error [18:14:49 CEST] <BtbN> AlienCat, you realize opus is an audio codec? [18:14:59 CEST] <AlienCat> yea [18:15:06 CEST] <BtbN> But you are telling it to use it as video codec. [18:15:07 CEST] <AlienCat> I wanna conver audio [18:15:35 CEST] <BtbN> and are also telling it to create a wav file, which is raw uncompressed pcm [18:17:31 CEST] <Phi> BtbN, on a separate note I'm getting av_log passed "libx264 : profile Constrained Baseline, level 3.1", but output is still High [18:19:43 CEST] <AlienCat> so what should I type? [18:28:13 CEST] <BtbN> depends on what you want. You want a wav file? Encode it with opus? [18:32:51 CEST] <AlienCat> I wanna force input opus [18:33:05 CEST] <AlienCat> then convert it to ogg or something [18:41:26 CEST] <Phi> BtbN, can you demo it for me? [18:41:40 CEST] <Phi> I set to Baseline, and it's set to Constrained Baseline, and the output is High [18:43:41 CEST] <BtbN> ffmpeg -f lavfi -i testsrc2 -c libx264 -profile baseline out.mkv [18:49:26 CEST] <Phi> that works, I'm going to try the RTSP [19:01:03 CEST] <BtbN> there is nothing left of the input container/codec, once it reaches libx264 [19:01:37 CEST] <JEEB> other than timestamps :P [19:08:44 CEST] <Phi> one can only hope [19:08:53 CEST] <Phi> I still have a dopey system [19:09:08 CEST] <jpsharp> I need a suggestion on how to get ffmpeg to convert a single frame (but occasionally changing) gif into an rtmp stream. I can get a static stream going, but it never recognizes the new gif if I change it out. And if I kill ffmpeg and start a new stream with a new gif, the far end clients freak out. [19:09:18 CEST] <Phi> the RTSP seems to work, although I'm getting a shedload of "Past duration 0.(some number) too large" [19:09:58 CEST] <jpsharp> Are you streaming a camera Phi? [19:10:54 CEST] <Phi> a network one, I'm just outputting to a MP4 [19:11:48 CEST] <Phi> I set the profile to Baseline via options passed to avcodec_open2, if I read back x264's internal codec it's Constrained Baseline, and the resulting file is High [19:11:53 CEST] <Phi> so it makes no sense [19:14:03 CEST] <Phi> av_log shows "libx264 : profile Constrained Baseline, level 3.1" [19:14:09 CEST] <Phi> output file is *still* High [19:14:19 CEST] <bencoh> Phi: unless you're passing options to x264 *after* setting profile [19:14:58 CEST] <bencoh> profile/level should be set last [19:15:19 CEST] <bencoh> (since it's a constraint) [19:16:26 CEST] <Phi> I'll double-check, but I don't think so [19:17:29 CEST] <Phi> hm, I do avcodec_get_context_defaults3, then I set the profile [19:17:38 CEST] <Phi> then I do avcodec_open2 [19:18:14 CEST] <Phi> I'll drop the defualts call and see if it works [19:23:38 CEST] <Phi> nope, same [19:23:58 CEST] <Phi> I set it to baseline (not constrained baseline), libx264 log shows constrained baseline, output file is high [19:25:35 CEST] <BtbN> are you looking at the right output file? Are you sure you are writing anything? [19:25:37 CEST] <Phi> makes me want to headbutt the wall [19:25:45 CEST] <BtbN> does it work with ffmpeg cli? [19:25:47 CEST] <Phi> it's a new filename every time, incrementing based on existing files [19:25:58 CEST] <bencoh> try setting profile after _open() ? [19:25:59 CEST] <Phi> commandline works, yeah [19:26:16 CEST] <BtbN> after avcodec_open2, it won't have any effect [19:26:22 CEST] <bencoh> (not sure it which order those should be called tbh) [19:26:27 CEST] <bencoh> ah nvm then [19:26:33 CEST] <Phi> I'll try it anyway, won't kill me [19:26:45 CEST] <BtbN> they are only passed to libx264 during init [19:26:53 CEST] <bencoh> right [19:30:14 CEST] <Phi> you guys know how to use avformatcontext? [19:32:17 CEST] <Phi> yeah, no difference [19:39:22 CEST] <Phi> avio_open2, then avformat_new_stream, right? [19:45:30 CEST] <Pet0r> hi - I'm trying to encode an input file with the hevc_nvenc encoder, it seems to work with any -preset option just fine, but if I try to actually use "lossless" or "losslesshp", I get "[hevc_nvenc @ 0000023098f10780] No NVENC capable devices found" [19:45:42 CEST] <Pet0r> any other presets work fine and are certainly HW accelerated [19:52:27 CEST] <AlienCat> ffmpeg -f -acodec libopus -i msg.amr glass.ogg [19:52:43 CEST] <AlienCat> still complains aboput mp3 [19:54:47 CEST] <Pet0r> never mind ,eventually found the answer to my own question - lossless is Pascal only and I'm on Maxwell [20:13:56 CEST] <Phi> and on my end... the profile is still too damn High [20:25:55 CEST] <Phi> this is such a trippy program [20:26:16 CEST] <Phi> BtbN, whyyy [20:29:12 CEST] <furq> have you disgraced any altars recently [20:31:19 CEST] <Phi> ...maybe [20:31:46 CEST] <Phi> I've just noticed "writing application" is Lavf56.1.0 in my program, but from ffmpeg it's libx264 [20:31:56 CEST] <Phi> (in metadata in the mp4s) [20:32:20 CEST] <Phi> so... even though libx264 is writing to av_log... it's not being used? [20:37:46 CEST] <HorikawaOtane> Have a mild question. [20:38:00 CEST] <HorikawaOtane> How would one go about selecting the gpu for scale_npp? [20:40:19 CEST] <BtbN> it uses the one of the context it gets passed. In itself it doesn't have any context creation logic. [20:42:49 CEST] <HorikawaOtane> i see [20:42:55 CEST] <HorikawaOtane> so how would one create a context for it? [20:43:06 CEST] <HorikawaOtane> is there some global variable i need to pass in or something? [20:43:11 CEST] <HorikawaOtane> like GPU=1 ffmpeg <stuff> [20:43:54 CEST] <BtbN> Either cuvid, hwupload_cuda or ffmpeg_cuvid.c does it. [20:44:13 CEST] <BtbN> They all have their own options for device selection [20:46:12 CEST] <AlienCat> okay I think I found my problem [20:46:23 CEST] <AlienCat> there are no opus demuxer [21:00:33 CEST] <Phi> BtbN, I set the codec to libx264, but the output file looks like it's produced by "Lavf56.1.0" [21:01:07 CEST] <BtbN> so? lavformat is what creates the output file. [21:02:31 CEST] <Phi> ffmpeg produces one that says libx264 [21:03:04 CEST] <Phi> ...no, not quite [21:03:12 CEST] <Phi> I have vastly different output data for them [21:03:25 CEST] <furq> i was going to say, it shouldn't [21:03:30 CEST] <furq> the writing application is supposed to be the muxer [21:03:33 CEST] <furq> which is libavformat [21:03:47 CEST] <furq> if you wrote it with mkvmerge it'd say mkvmerge [21:04:22 CEST] <Phi> http://pastie.org/private/la1exrsqbws16tf56a7csa is the faulty one made by my app [21:04:54 CEST] <Phi> http://pastie.org/private/eof0iwihqsynnzuvis7fua is the ffmpeg one [21:05:16 CEST] <Phi> my one doesn't even say the writing library [21:06:55 CEST] <furq> it does [21:07:14 CEST] <furq> it says a different version of lavf for some undoubtedly fun reason [21:07:38 CEST] <furq> it's missing the encoding settings though [21:07:54 CEST] <furq> i thought that was something libx264 dealt with internally [21:07:58 CEST] <HorikawaOtane> So - another question [21:08:10 CEST] <HorikawaOtane> Is there any particular reason to use nvresize vs scale_npp? [21:15:33 CEST] <Phi> furq: it says the writing application, not the writing library :( [21:15:52 CEST] <furq> oh right [21:16:17 CEST] <BtbN> nvresize? [21:16:57 CEST] <HorikawaOtane> yeah [21:17:18 CEST] <BtbN> Is that some external application? [21:17:19 CEST] <HorikawaOtane> nvresize is an ffmpeg patch by nvidia - https://developer.nvidia.com/ffmpeg [21:17:24 CEST] <BtbN> Oh, that. [21:17:38 CEST] <BtbN> Well, you need to patch ffmpeg with an incredibly messy external patch set. [21:17:50 CEST] <BtbN> Which I doubt still applies. [21:17:53 CEST] <HorikawaOtane> oh i guess the key with nvresize is that you can also export to multiple resolutions simultaneously [21:17:57 CEST] <HorikawaOtane> and nah, it doesn't patch cleanly now [21:18:25 CEST] <HorikawaOtane> but nvresize also doesn't seem to allow you to set your scaling method... [21:18:38 CEST] <HorikawaOtane> whereas scale_npp accepts interp_algo [21:19:45 CEST] <Phi> hmm [21:20:20 CEST] <Phi> I want to test by someone else writing an app [21:20:26 CEST] <Phi> but that'll take ages [21:22:17 CEST] <BtbN> nvresize is a pre-compiled cuda kernel which does the scaling with exactly one algorithm. [21:22:34 CEST] <BtbN> No idea what Algorithm it even is [21:22:39 CEST] <BtbN> Something simple I'd guess [21:27:05 CEST] <Phi> sempaiii [00:00:00 CEST] --- Sun Oct 23 2016

1 0

ffmpeg-devel.log.20161021
by burek 22 Oct '16

22 Oct '16

[01:31:13 CEST] <atomnuker> BBB: about the vf_colorspace patch, is there really a need to use srgb and have iec61966-2.1 as an alias [01:42:39 CEST] <BBB> Im not 100% sure [01:43:05 CEST] <BBB> I dont think I have much of an opinion on aliases, I think theyre ok, they help people that are not intimately familiar with how this stuff work and make it sound a little bit easier [02:03:44 CEST] <cone-535> ffmpeg 03Tobias Rapp 07master:e3196b686233: avformat/mxfdec: Detect field_order based on video_line_map [02:14:15 CEST] <Zeranoe> Should the default/recommended FFmpeg build for Windows be the git version or the release versions? With the redesign the releases were set as the default. [02:15:07 CEST] <iive> atomnuker: look at it from a different angle, iec61966-2.1 is the proper name and srgb is the alias [02:15:20 CEST] <iive> i'd say aliases are ok. [02:26:00 CEST] <llogan> Zeranoe: git [02:26:38 CEST] <llogan> redesign look snice [02:31:55 CEST] <jamrial> llogan: should it really? we're talking about windows binaries. the kind people download once and will use till the end of time, or until whatever they want to do can't be done with it [02:32:28 CEST] <llogan> i'm tired of telling windows users to use the git version for x new feature [02:35:33 CEST] <jamrial> llogan: you're aware that until now Zeranoe's page offered nightly git builds by default, right? [02:35:48 CEST] <jamrial> people will not stop making questions where the reply is "get a newer version" [02:39:42 CEST] <jamrial> by offering a stable release as recommended and nightlies as "bleeding edge, can be unstable", there will be less chances for people downloading a highly unstable build thinking it was a perfectly functional one, and sticking with it for who knows how long [02:41:04 CEST] <llogan> yes, i am aware. [02:41:42 CEST] <llogan> i disagree that they are [generally] highly unstable [02:41:54 CEST] <llogan> we usually recommend general users to use git [02:43:24 CEST] <jamrial> i didn't say they are generally highly unstable. i said there's a chance they may be [02:44:02 CEST] <llogan> and there's a chance that an encountered bug in a release version is fixed in git [02:44:41 CEST] <llogan> in the time that the site has had the new design i had to tell at least one user to use the git version, not the release version [02:47:30 CEST] <jamrial> that for example wouldn't have happened if 3.2 hadn't been delayed, but that's just as anecdotic [02:47:35 CEST] <jamrial> with a release every three months new features make it to stable releases pretty fast [02:48:27 CEST] <jamrial> maybe a note saying "if something is missing from the release version, try a nightly build" or something like that could help in this regard [02:48:49 CEST] <llogan> if people come asking for help and just downloaded a release they are often going to be told to use git version. if they report a bug they *will* be told to use git version. [02:49:33 CEST] <llogan> yes, a note mentioning the differences would be helpful [02:59:23 CEST] <Zeranoe> So to summarize: Switch to the git builds and add a tooltip to the release toggle with something like "Note that the git builds are generally considered more stable and are the only officially supported version." The tooltips I'm referring to can be seen when hovering over the linking types. [03:17:39 CEST] <Zeranoe> The tooltip will read "Release versions of FFmpeg generally contain more bugs, less features, and are not supported on the bug tracker or mailing list." Hopefully that works for everyone. [03:33:14 CEST] <llogan> Zeranoe: for git tooltip maybe something like: "Recommended for general users. More features, bleeding-edge but usually stable, required version if reporting bugs." and release: "Recommended for distributors and others who require a stable release version". [03:42:38 CEST] <Compn> when something breaks its nice to see a bug report from a git nightly build user anyway [03:53:28 CEST] <Zeranoe> So is the git version or the release version more stable? [04:03:11 CEST] <Zeranoe> The wording is now "Nightly git builds contain more features, are usually stable, and are the required version for submitting bugs." and "Release builds are recommended for distributors, but cannot be used when submitting bugs." [04:03:32 CEST] <llogan> release is more "stable". git will have more bug fixes that may be missing in release, but git may have bugs not in release. release versions within the same release branch will not have backward incomaptible API changes and no major new features. [04:05:34 CEST] <llogan> got to go. [04:10:34 CEST] <cone-535> ffmpeg 03Mark Reid 07master:3b82be9e3b7e: libavformat/mxfdec: export track name metadata [04:10:35 CEST] <cone-535> ffmpeg 03Mark Reid 07master:263f8fd7e5c1: libavformat/mxfdec: don't assume first stream index to be primary [04:10:36 CEST] <cone-535> ffmpeg 03Mark Reid 07master:6902e1c7fab3: libavformat/mxfdec: add metadata streams for external referenced sourclips [04:10:37 CEST] <cone-535> ffmpeg 03Mark Reid 07master:0cfd6ccedeaa: tests/fate: add mxf metadata streams test [06:15:44 CEST] <cone-535> ffmpeg 03Matt Oliver 07master:798c6ecce50f: openssl: Support version 1.1.0. [06:16:57 CEST] <Matador> Zeranoe: Hello there [06:17:57 CEST] <Zeranoe> Matador: Hi [06:37:14 CEST] <Matador> Zeranoe : nice to see you around here [06:37:34 CEST] <Matador> Zeranoe : I've used those builds and recommended others also [06:37:48 CEST] <Zeranoe> Matador: Thank you for the kind words [06:38:05 CEST] <Matador> I hope you saw on forum, about qsv/mfx issue :| [06:38:43 CEST] <Matador> I even tried compiling ffmpeg myself on Ubuntu, what a PITA.. but still qsv/libmfx broken on latest git... really sad gotta use a April edition :| [06:40:35 CEST] <Zeranoe> Matador: Which post are you referring to? [06:41:27 CEST] <Matador> https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=4360 [06:41:58 CEST] <Matador> I just noticed another -- https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=4171 [06:42:14 CEST] <Matador> Let me know how much $$ donation you'd like to work on a fix ? :) [06:44:26 CEST] <Matador> there is another titled -- ffplay crashes with h264_qsv codec (Intel QuickSync/QSV) [06:44:45 CEST] <Zeranoe> Matador: This is a very complex issue. See https://trac.ffmpeg.org/ticket/4832 [06:45:37 CEST] <Matador> ya no doubt [06:47:21 CEST] <Matador> Let me know if money will help get a few coders on this full time, I'm willing to put up a bounty here :) [06:53:10 CEST] <Zeranoe> Matador: Do you have a machine to test with? I have trouble reliably reproducing it on my 4790K? [08:07:53 CEST] <rcombs> oh man I forgot I pushed that termios fix [08:08:03 CEST] <rcombs> `make -j<x> fate` doesn't break my terminal anymore [08:08:08 CEST] <rcombs> I am the happiest person [08:56:23 CEST] <cone-535> ffmpeg 03Rodger Combs 07master:ecb53e11014b: lavf/segment: decide whether to rename based on list URI [14:19:45 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:6c5b98d40b8e: avcodec/dnxhdenc: Move allocation out of radix_sort() [14:19:45 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:4f96f9d1118e: avcodec/utils: Clear MMX state before returning from avcodec_default_execute*() [14:19:45 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:03ec6b780cfa: avcodec/mpegvideo_enc: Clear mmx state in ff_mpv_reallocate_putbitbuffer() [14:57:33 CEST] <jkqxz> jamrial: nevcairiel: Has anyone started on the suggested libmfx replacement from libav? [14:57:46 CEST] <nevcairiel> not to my knowledge [15:00:38 CEST] <jkqxz> Ok, I will start on it then. I don't imagine it will be overly complex, but I wouldn't want to duplicate anything someone else has already done. [15:04:39 CEST] <ubitux> is anyone aware of ffmpeg muxed mp3 with "random" durations reported in various players? [15:05:12 CEST] <ubitux> i have someone reporting me that vlc at playback time reports a wrong duration (fixed at playback) [15:05:15 CEST] <ubitux> just like quicktime [15:05:27 CEST] <BtbN> Isn't that just what happens with VBR mp3? [15:05:38 CEST] <ubitux> maybe; what's the explanation here? [15:05:51 CEST] <ubitux> i'm assuming the wrong one is due to a bitrate estimation [15:05:59 CEST] <BtbN> I think plain mp3 simply has no information about its length [15:06:04 CEST] <BtbN> So it's calculated from size and bitrate [15:06:10 CEST] <BtbN> which obviously fails for vbr [15:06:10 CEST] <ubitux> because a generated sine of the same duration leads to a different "random" duration [15:06:46 CEST] <ubitux> how is the correct duration computed? [15:06:50 CEST] <BtbN> putting mp3 in some container. [15:07:01 CEST] <BtbN> by decoding the entire file I guess [15:07:13 CEST] <ubitux> ffprobe reports the correct duration [15:07:22 CEST] <ubitux> i'm pretty sure it's not decoding everything [15:08:32 CEST] <BtbN> where even is the mp3 decoder? In which file in avcodec, that is [15:09:12 CEST] <ubitux> mpegaudio*.c? [15:09:16 CEST] <BtbN> mpegaudio_parser.c it seems [15:09:18 CEST] <nevcairiel> raw mp3 files have headers for vbr info [15:09:32 CEST] <nevcairiel> not sure if avformat writes that [15:09:35 CEST] <nevcairiel> but it probably should [15:09:53 CEST] <jamrial> mpegaudiodec_{float,fixed,template} [15:10:20 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mp3enc.c#L513 [15:12:37 CEST] <ubitux> basically this file `ffmpeg -f lavfi -i sine -t 4:38 out.mp3` is reported as 5:17 in playback in vlc and 4:38 in pause [15:12:46 CEST] <ubitux> (and reported as 5:18 in quicktime) [15:13:17 CEST] <ubitux> ffprobe reports as 4:38 [15:13:29 CEST] <nevcairiel> maybe vlc doesnt read the xing tag [15:13:35 CEST] <nevcairiel> (quicktime most probably does not) [15:13:59 CEST] <ubitux> you mean vlc doesn't read it at playback [15:14:11 CEST] <ubitux> but just in playlist/pause mode? [15:14:16 CEST] <BtbN> it also seems to be somehow tied to mp3->pics_to_write [15:14:29 CEST] <BtbN> which is set to s->nb_streams - 1 [15:14:47 CEST] <BtbN> the xing tag is only written if it's 0, so if there is exactly one stream [15:14:55 CEST] <BtbN> which makes sense I guess? [15:15:12 CEST] <nevcairiel> well if vlc is inconsistent in two modes, i would look for an explanation at vlc [15:15:42 CEST] <jamrial> BtbN: depends, can't xing be written if id3v2 has a cover image? [15:16:14 CEST] <BtbN> no ides if it can't. But it isn't. [15:16:30 CEST] <nevcairiel> BtbN: it is, just later [15:16:32 CEST] <nevcairiel> after the images [15:16:51 CEST] <nevcairiel> mp3_queue_flush writes the xing tag [15:16:56 CEST] <nevcairiel> which is called after the images are done writing [15:19:44 CEST] <nevcairiel> because the id3v2 tag with the images has to be the first thign in the file [15:37:03 CEST] <BtbN> Yeah, what ffmpeg writes looks fine to me. [15:37:15 CEST] <BtbN> So I'd blame what VLC reads, or rather doesn't read. [15:44:00 CEST] <BBB> michaelni: your patch series does exactly what scares me so much, it adds emms_c() in all kind of places which are practically untestable on a non-musl setup [15:44:56 CEST] <BBB> michaelni: I thought all these encoders used mpegenc, cant we add the emms_c() in a general location inside mpegenc so its generalized in a single location where at least its shared? [15:47:14 CEST] <Chloe> what does emms_c() do for non 32bit x86? [15:59:04 CEST] <BBB> Im not sure theres a guarantee that were not using x87 fpu on 64bit, so although you typically dont need it, I think it still calls emms on 64bit [15:59:13 CEST] <BBB> (you could have hand-written assembly or a silly compiler) [15:59:22 CEST] <BBB> (x87fpu assembly, I mean) [16:01:14 CEST] <Chloe> right ok, if there are cases where x87 may still be used then I guess it's just best to do it unconditionally. [16:04:10 CEST] <michaelni> BBB, i didnt use musl to test or find these [16:04:24 CEST] <BBB> right, you used your asserts [16:04:33 CEST] <BBB> but that doesnt change the fact that theres emms_c sprinkled all over :) [16:05:08 CEST] <BBB> nor that it only covers memory allocation functions, not all libc functionality [16:05:17 CEST] <BBB> but lets ignore that second one for now [16:05:27 CEST] <BBB> sicne musls only concern is memory allocation functions [16:06:05 CEST] <michaelni> also these get triggered on x86-64 with cpuflags all you dont need to force mmx [16:08:34 CEST] <michaelni> "<BBB> michaelni: I thought all these encoders used mpegenc, cant we add the emms_c() in a general location inside mpegenc so its generalized in a single location where at least its shared? <-- not that i see, the code directly calls all kinds of SIMD and ref/unref stuff [16:09:23 CEST] <BBB> hm& ok [16:09:28 CEST] <BBB> that kinda sucks, but what can you do, right? [16:53:10 CEST] <cone-212> ffmpeg 03Hiroyuki OYAMA 07master:47f74df29cb1: avformat/rtmpproto: Fix RTMP control message handling error in listen mode. [17:11:26 CEST] <cone-212> ffmpeg 03Steven Liu 07master:4d92bd3ca225: avcodec/vda: define av_vda_default_init2 when CONFIG_H264_VDA_HWACCEL equ 0 [17:30:49 CEST] <Zeranoe> jkqxz: What libmfx replacement are you referring to? [17:33:03 CEST] <jkqxz> Replace the libmfx implementation in ffmpeg with the one in libav, because it works and is incompletely awful. [17:33:25 CEST] <RiCON> Zeranoe: this patch fixes those relocation errors you were getting with gcc 6.x: https://raw.githubusercontent.com/Alexpux/MINGW-packages/master/mingw-w64-g… [17:33:48 CEST] <jkqxz> Also because the current one is blocking further merges. [17:34:23 CEST] <Zeranoe> jkqxz: Any timeframe for that? I'm curious if that will resolve some issues I've been seening [17:35:07 CEST] <jkqxz> I am trying to do it now. [17:35:42 CEST] <jkqxz> Later today for an initial patch, maybe? It probably won't be complete at that point. [17:35:43 CEST] <Zeranoe> RiCON: Interesting [17:38:12 CEST] <jkqxz> I have working encode or decode separately so far, and I've tried to preserve current functionality - all except A53 CC (which seems to currently be broken anyway) look fine. [17:38:16 CEST] <Zeranoe> RiCON: It looks like it hasn't made it into git yet. https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libstdc%2B%2B-v3/config/o… [17:39:02 CEST] <RiCON> i don't know if it's actually a gcc issue nor do I know if anyone forwarded the patch to gcc [17:39:54 CEST] <RiCON> it was just something i tried a few months ago based on a similar commit for the cygwin part [17:43:05 CEST] <Zeranoe> RiCON: Do you know if it's x86_64 specific or could something like CFLAGS="-U_GLIBCXX_USE_WEAK_REF" be used? [17:43:13 CEST] <RiCON> it's x86_64 specific [17:43:47 CEST] <RiCON> i never tried with a specific CFLAG [17:46:37 CEST] <RiCON> either way, it's not a FFmpeg issue nor with any lib in particular, it's with gcc and/or static libstdc++ [17:47:22 CEST] <RiCON> c++ libs that don't use exceptions also work without it, like x265 [17:47:26 CEST] <Zeranoe> RiCON: I appreciate the info [19:42:45 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07master:93c39db5f154: aiff: check block_align in aiff_read_packet [19:42:46 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07master:b0a043f51b8c: dcstr: fix division by zero [19:42:47 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07master:1966ea012fd7: cavsdec: unref frame before referencing again [19:42:48 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07master:a92f8edf0c51: mpeg12dec: unref discarded picture from extradata [20:18:07 CEST] <jkqxz> Zeranoe: On ML. Testing on Windows would be welcomed :) [20:18:42 CEST] <Zeranoe> jkqxz: Do you have a repo/branch set up? [20:19:10 CEST] <JEEB> if you are lazy to grab patches from the ML, check the patchwork [20:19:21 CEST] <BtbN> https://patchwork.ffmpeg.org/patch/1104/ [20:19:21 CEST] <JEEB> you can get a file you can then git am into your repo from that one as well [20:22:43 CEST] <Zeranoe> jkqxz: Have you seen this? https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195544.html [20:23:43 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:c495f4ffde1e: avformat/mxfdec: Fix mixed declaration and code [20:23:44 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:fecb3e82a4ba: avformat/mxfdec: Check size to avoid integer overflow in mxf_read_utf16_string() [20:24:52 CEST] <ubitux> jkqxz: oh nice, thanks! [20:25:47 CEST] <cone-212> ffmpeg 03Marton Balint 07master:2f3015c25aae: lavd/decklink_dec: add option to disable drawing bars on signal loss [20:25:48 CEST] <cone-212> ffmpeg 03Marton Balint 07master:dfc561a38e94: lavd/decklink_dec: fix indentation [20:31:45 CEST] <jkqxz> Zeranoe: I had not seen that. Urgh, is it really a dependency on the processor rather than the API version? [20:31:57 CEST] <Zeranoe> As far as I can see the CO3 options are defined but aren't actually being set [20:32:11 CEST] <Zeranoe> jkqxz: It appears so. I'm unable to even use QSV due to those [20:32:28 CEST] <nevcairiel> the whole qsv thing should have runtime feature selection, not compile time [20:32:32 CEST] <nevcairiel> but noone bothered to build that [20:32:41 CEST] <Zeranoe> I agree [20:33:27 CEST] <jkqxz> You aren't accidentally building against newer headers (such as those in mfx_dispatch) than the libfx you actually run with? [20:33:31 CEST] <Zeranoe> jkqxz: I would see a reason to keep those CO3 options, but as I said they aren't even being used from what I've seen [20:33:32 CEST] <jkqxz> *libmfx [20:34:05 CEST] <Zeranoe> jkqxz: I don't use mfx_dispatch and build the latest version myself. That version is also being used on the machine. [20:34:07 CEST] <nevcairiel> its also really not worth caryng about, qsv is just broken as f' even when its implemented properly, the drivers still randomly stall and give you endless busy signals [20:34:32 CEST] <nevcairiel> caring* [20:35:36 CEST] <Zeranoe> nevcairiel: Only with FFmpeg from what I've tested. Intel provides a "sample encoder" that does not hang with the same input, and it's implemented very similarly. That's while stressing the CPU while encoding (normally causes the hang) [20:35:58 CEST] <nevcairiel> i got all sorts of random tools to freeze up the same way [20:36:16 CEST] <nevcairiel> and various reports of that on intels forum [20:36:32 CEST] <BtbN> OBS put the QSV encoder in a seperate process and just kills it and restarts it if it doesn't respond anymore... [20:36:45 CEST] <Zeranoe> Wow.... That's bad [20:37:22 CEST] <nevcairiel> and last I checked the "official" linux libmfx doesnt even interface with the hardware properly so it doesnt provide a hardware device for you [20:37:30 CEST] <nevcairiel> hence the hacky code in ffmpeg that queried the dev nodes [20:37:52 CEST] <nevcairiel> lucas fork of it has that added into it however, and libav probably only ever cared to work with that [20:37:59 CEST] <Zeranoe> Apparently Libav's implementation is better though? [20:40:39 CEST] <jkqxz> The hwcontext layer hides that nastiness in libav. You build with either DXVA2 or VAAPI and it uses the hwcontext for that to make the device. [20:43:25 CEST] <jkqxz> (In current ffmpeg, using encode and decode separately at the same time on Linux without X is broken - it segfaults in libmfx because the first open makes itself the DRM master on the card, and then the second dies horribly. Amusingly, linking card0 to renderD128 makes it work.) [20:47:56 CEST] <jkqxz> Zeranoe: I guess that change makes sense given what you've said. Do you test on anything older as well? [20:48:58 CEST] <Zeranoe> jkqxz: There are numerous reports of the same issue on my forum with similar hardware. [20:49:31 CEST] <Zeranoe> jkqxz: Though I haven't tested the fix on other hardware than mine. [21:03:12 CEST] <cone-212> ffmpeg 03Carlos Fernandez 07master:d53a120ad63f: lavc: add SCTE-35 CUI codec ID [21:03:13 CEST] <cone-212> ffmpeg 03Carlos Fernandez 07master:5db3c9476c79: lavf/mpegts: SCTE-35 extraction from mpegts [21:15:22 CEST] <jamrial> i thought people in general were against this scte-35 patchset [21:15:50 CEST] <JEEB> oh wait, it went into lavc? funky [21:15:51 CEST] <Chloe> yes [21:15:59 CEST] <JEEB> I thought it was a container concept [21:16:22 CEST] <jamrial> or rather, some people against, others just neutral, but nobody except the submiter actually in favor [21:17:48 CEST] <Chloe> wm4 was against it, I felt that it could have been done differently. There were still some outstanding issues, which were never solved. But it's not like anything is going to stop random stuff being commited [21:17:52 CEST] <Matador> Cant wait for a QSV fix [21:19:59 CEST] <BtbN> Well, complain to Intel [21:20:06 CEST] <BtbN> Nobody else can fix it. [21:24:46 CEST] <Zeranoe> What if I told you Intel thinks it's our fault.... [21:27:00 CEST] <BtbN> That their stuff fails in essentialy every application using it? Yeah sure [21:27:45 CEST] <Zeranoe> Sometimes it's easier to blame the other guy [21:28:17 CEST] <BtbN> Intel Software development has gone downhill the last few years [21:28:21 CEST] <BtbN> specially the open source stuff [21:28:27 CEST] <BtbN> but QSV is especially bad [21:58:01 CEST] <CFS-MP3> jamrial don't know... I'm getting some feedback about the SCTE-35 stuff, so there's definitely some interesting other than my personal one [21:58:29 CEST] <CFS-MP3> Never understood the being against supporting an industry standard anyway [21:58:51 CEST] <JEEB> I don't think anyone here is against implementing SCTE-35 in FFmpeg [21:59:01 CEST] <Chloe> It's not that, it's how it's implemented, and how it fits (or rather, doesn't fit) into ffmpeg. [21:59:36 CEST] <CFS-MP3> Chloe do you mean my specific implementation or the way SCTE-35 fits in the MPEG-TS? [22:00:01 CEST] <CFS-MP3> If it's my implementation I'm happy to discuss it, if it's the specification not much we can do I guess except deal with it as well as we can [22:00:32 CEST] <Chloe> I think there were issues with both. Particularly regarding the timestamps, what was done about that in the end? [22:01:26 CEST] <CFS-MP3> What needed to be done that wasn't done? Timestamps in cues are relative to the PCR... what's the specific problem with it? [22:03:26 CEST] <Chloe> How does it work with the AVPacket timestamps? [22:03:51 CEST] <Chloe> Actually don't bother. It doesn't even matter anymore. [22:19:16 CEST] <tmm1> is there a way to tell ffmpeg/ffplay to use a specific decoder [22:19:38 CEST] <BtbN> -c [22:21:13 CEST] <tmm1> ah right, as an input option [22:21:19 CEST] <tmm1> works for ffmpeg but not ffplay [22:21:44 CEST] <tmm1> n/m got it, thanks [23:59:55 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07master:c8a6eb58d7eb: doc: fix spelling errors [00:00:00 CEST] --- Sat Oct 22 2016

1 0

ffmpeg.log.20161021
by burek 22 Oct '16

22 Oct '16

[00:00:57 CEST] <b6s3d> furq [00:05:32 CEST] <b6s3d> this command seams to work: ffmpeg -i "$file" -b 450k -s 320x240 -vcodec libxvid -ab 128k -ar 48000 -acodec aac -strict -2 "$outfile";done [00:05:44 CEST] <b6s3d> though it outputs some errors i am going to use it [00:57:46 CEST] <sha0> Where can I find the OS requirements for FFMPEG? [01:11:25 CEST] <llogan> sha0: to compile? [01:11:43 CEST] <sha0> llogan: Sorry, no. For the prebuilt, downloadable packages. [01:11:53 CEST] <babadoc> Hello. [01:12:04 CEST] <sha0> For example, what is the minimal Windows version? [01:12:07 CEST] <babadoc> I would like to ask a question about installing ffmpeg on a 32 bit ubuntu server. [01:12:24 CEST] <babadoc> The installation process is the same, yes? [01:13:02 CEST] <c_14> The same as? [01:13:10 CEST] <babadoc> The same as this: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [01:13:24 CEST] <c_14> Why wouldn't it be [01:13:38 CEST] <babadoc> Because h265 doesn't seem to install correctly. [01:13:56 CEST] <babadoc> Throwing me an error such as "make: *** No rule to make target 'distclean'. Stop." [01:14:33 CEST] <c_14> sha0: you'd probably have to ask on the zeranoe forum [01:14:38 CEST] <babadoc> I don't think it is a necessity, because h264 installs correctly. [01:14:47 CEST] <c_14> babadoc: just don't distclean [01:14:48 CEST] <llogan> sha0: you should ask Zeranoe if you're referring to his builds. I believe XP support was dropped a year or two ago. [01:15:04 CEST] <sha0> c_14: Oh, I see. llogan: D'oh. Sucks to be me. [01:15:04 CEST] <babadoc> distclean? I am sorry, I don't follow. [01:15:22 CEST] <c_14> babadoc: distclean just removes objects and stuff in the build directory for that project. It in no way influences the actual built and installed files [01:15:44 CEST] <c_14> And is therefore not an important part of the build process [01:15:49 CEST] <babadoc> Oh, I see. [01:16:06 CEST] <llogan> that confuses users at times. i may remove it. on the other hand some users go back and re-configure with different options and experience issues. [01:17:42 CEST] <babadoc> The end goal of installing ffmpeg for me was to extract frames from certain times in a .webm video that I have. I tried following this tutorial https://trac.ffmpeg.org/wiki/Create%20a%20thumbnail%20image%20every%20X%20s… [01:18:12 CEST] <furq> babadoc: https://www.johnvansickle.com/ffmpeg/ [01:18:12 CEST] <babadoc> But, I could not extract frames from other times than 1 second in. [01:18:19 CEST] <furq> if you don't need non-free codecs then just use those [01:20:26 CEST] <babadoc> furq: I don't quite follow. Sorry. I have the codecs from that tutorial (libvpx, libopus, etc) installed, if that is what you are asking me. Could you elaborate? [01:21:39 CEST] <babadoc> I tried clicking on your name to mention you, but it doesn't seem to be working. [01:21:50 CEST] <babadoc> (I haven't used IRC before) [01:24:02 CEST] <llogan> not sure why anyone would use XP [01:28:04 CEST] <babadoc> It really is quite peculiar... why the command "ffmpeg -i input.webm -ss 00:00:14.435 -vframes 1 out.png" would work, but... Oh... [01:28:26 CEST] <babadoc> It seems that ffmpeg takes quite longer to seek and take frames from video than i had anticipated. [01:28:36 CEST] <babadoc> How irritating. [01:29:11 CEST] <babadoc> Is there any workaround to the slow seek times in ffmpeg? [01:30:01 CEST] <babadoc> To clarify: I don't mean the GUI type of seeking, I mean seeking for frames in a webm video via ffmpeg CLI using a command like this: "ffmpeg -i input.webm -ss 00:00:14.435 -vframes 1 out.png" [01:30:59 CEST] <llogan> use -ss as an input option [01:31:40 CEST] <babadoc> http://pastebin.com/KZ4Xx8wU is the error log [01:31:43 CEST] <babadoc> its quite short [01:32:13 CEST] <babadoc> Logan, you want me to use the -ss option too? I am not sure how I would add that and still have the command work. [01:32:43 CEST] <llogan> that console output is not complete and is missing the command so I don't know what you are intending to show with it [01:32:55 CEST] <babadoc> Oh, sorry. I shall complete it. [01:35:19 CEST] <babadoc> http://pastebin.com/qLmTHSCH [01:35:23 CEST] <babadoc> Sorry. [01:35:37 CEST] <babadoc> Any more information you need? [01:35:52 CEST] <furq> babadoc: i meant that you probably don't need to compile ffmpeg [01:36:06 CEST] <furq> the only reason to compile it instead of using those static binaries is if you need non-free codecs like libfdk-aac [01:36:31 CEST] <babadoc> I installed it using that tutorial. [01:36:40 CEST] <babadoc> Trying to run sudo apt install ffmpeg would not work [01:36:55 CEST] <babadoc> asked me to use --fix-missing and that would not work either [01:37:00 CEST] <babadoc> Easier to install via source. [01:37:15 CEST] <babadoc> The only way was to install via source. [01:40:17 CEST] <babadoc> The OS the server is running is ubuntu 16.0.4, not 16.0.2, if that matters. [01:47:08 CEST] <llogan> you don't need to install the binary furq was referring to. you just execute it [01:48:29 CEST] <babadoc> Execute the x86 build on the FFmpeg static builds list that furq referred to? [01:48:33 CEST] <babadoc> https://www.johnvansickle.com/ffmpeg/ [01:48:48 CEST] <babadoc> (The first download on the list) [01:49:52 CEST] <Phi> Moop [01:49:54 CEST] <Phi> Hey folks [01:50:02 CEST] <Phi> any idea how to turn on libx264 logging in ffmpeg? [01:50:44 CEST] <babadoc> Isn't enabled by default? [01:52:46 CEST] <Phi> would it be outputting to av_log then? [01:53:46 CEST] <babadoc> Yes, I think. [01:53:55 CEST] <babadoc> But don't take my word for it. [01:54:02 CEST] <babadoc> Look [01:54:12 CEST] <babadoc> http://pastebin.com/raw/qLmTHSCH [01:54:22 CEST] <babadoc> That outputted errors for h264, and I just ran a normal command [01:54:55 CEST] <Phi> the paste expired [01:55:05 CEST] <babadoc> Not the raw one. (It did?) [01:55:19 CEST] <babadoc> Did the raw one expire? [01:55:49 CEST] <Phi> well, I'm having excruciating difficulty trying to change a H264 profile when moving from RTSP->MP4 [01:55:53 CEST] <Phi> I think it did [01:55:56 CEST] <Phi> it redirects me out of the raw [01:56:02 CEST] <babadoc> http://pastebin.com/unrTJtiW [01:56:09 CEST] <babadoc> See? [01:56:13 CEST] <babadoc> It posts errors [01:56:21 CEST] <babadoc> I don't think there is a verbose option for ffmpeg [01:56:48 CEST] <furq> there is, but he's not using ffmpeg [01:57:08 CEST] <babadoc> What do you mean furq? [01:57:23 CEST] <furq> i assume from av_log that he's using the libraries directly [01:57:38 CEST] <babadoc> Ah. But he did state that he was using ffmpeg. [01:57:41 CEST] <Phi> yea, C++y [01:57:47 CEST] <babadoc> Oh. I see. [01:57:52 CEST] <Phi> sorry, the terminology isn't very obvious [01:57:56 CEST] <Phi> I'm new to the whole thing [01:58:04 CEST] <babadoc> Don't worry, so am I. [01:58:07 CEST] <furq> yeah the libav fork nonsense has made it really annoying [01:58:15 CEST] <furq> you can't say "libav" now without people thinking you mean avconv [01:58:21 CEST] <babadoc> lol, just fork ALL the things [01:58:27 CEST] <furq> libav* is the best compromise i've seen [01:58:27 CEST] <Phi> fork that [01:58:32 CEST] <Phi> not very knife behaviour [01:58:37 CEST] <furq> and screw libswresample [01:58:45 CEST] <babadoc> haha [01:59:29 CEST] <babadoc> So furq... do you know what I could do? [01:59:40 CEST] <Phi> everyone's giving me this very clever, accurate advice about how to change the profile [01:59:50 CEST] <Phi> and the C++ is like "nope, profile must be high or the sun explodes" [02:00:04 CEST] <Phi> I must have tried over a hundred different ways by now, it's been weeks :P [02:00:06 CEST] <furq> babadoc: move -ss before -i [02:00:13 CEST] <babadoc> haha, phi [02:00:19 CEST] <babadoc> Okay furq, will do. [02:00:36 CEST] <Phi> you think I'm exaggerating [02:00:37 CEST] <furq> failing that, if you're reencoding then use the trim filter [02:00:55 CEST] <Phi> if I wasn't paid by the hour I'd be totally miffed [02:01:06 CEST] <furq> i'm pretty sure i remember trying to help you with this a few weeks ago, so i don't think you're exaggerating [02:01:16 CEST] <babadoc> You guys are professionals, huh [02:01:20 CEST] <babadoc> I'm only 15 [02:01:26 CEST] <Phi> I'm so professional you don't even know [02:01:32 CEST] <babadoc> haha [02:01:35 CEST] <furq> sadly my knowledge of the api doesn't extend beyond saving a png [02:01:51 CEST] <babadoc> Gif works natively too Phi [02:01:55 CEST] <Phi> that's the annoying part, I can read the RTSP fine, even save an MP4 [02:02:04 CEST] <Phi> snapshots and displaying the frames, easy [02:02:23 CEST] <Phi> but changing the profile of the MP4? nah [02:02:35 CEST] <Phi> no matter what I do it locks it back to whatever the RTSP is doing [02:03:08 CEST] <Phi> at this rate I'm going to have to byte-scan every single packet and replace the profile in any headers with my one :p [02:03:26 CEST] <Phi> not CPU-intensive or hacky at all [02:04:07 CEST] <babadoc> hahahaha [02:04:25 CEST] <babadoc> that really sucks :( [02:04:44 CEST] <babadoc> hey phi, what are you trying to accomplish? [02:04:52 CEST] <Phi> I like the juxtaposition of your last two messages there [02:05:11 CEST] <Phi> Once I get the video done, that'll be it [02:05:15 CEST] <Phi> for the most part [02:05:23 CEST] <Phi> it's for a CCTV system, ironically [02:05:28 CEST] <babadoc> lol what [02:05:35 CEST] <Phi> using network cams [02:05:40 CEST] <babadoc> yeah, i get that [02:05:46 CEST] <babadoc> i know what a CCTV system is [02:06:00 CEST] <Phi> I even managed to write a motion detection for it in a couple of days [02:06:10 CEST] <Phi> from scratch :P [02:06:13 CEST] <babadoc> oh, you have to encode whatever format the cctv cameras output with ffmpeg [02:06:21 CEST] <babadoc> and its not working, huh [02:06:26 CEST] <Phi> well, with C++ [02:06:36 CEST] <babadoc> with c D: [02:06:39 CEST] <Phi> and I can get a MP4 output, but I can't change the video profile - to baseline, high, etc [02:07:03 CEST] <Phi> I guess C, since ffmpeg is C, but you can invoke it in C++ all the same, so... [02:07:17 CEST] <babadoc> i see [02:07:21 CEST] <Phi> the MP4 timing is all off as well [02:07:22 CEST] <babadoc> i took a small class in c++ over the summer [02:07:27 CEST] <babadoc> it was like one week [02:07:32 CEST] <babadoc> and i HATED it [02:07:42 CEST] <babadoc> you have to add the ; at the end of everything [02:08:02 CEST] <Phi> really; [02:08:06 CEST] <Phi> that must have sucked; [02:08:11 CEST] <babadoc> >:(((( [02:08:19 CEST] <furq> better that than ASI [02:08:20 CEST] <babadoc> lol [02:08:23 CEST] <Phi> but at least you don't have to work on your punctuation; [02:08:35 CEST] <babadoc> i have no idea what ASI is [02:08:41 CEST] <Phi> just run-on everything. // syntax error 'everything' not defined [02:08:41 CEST] <furq> automatic semicolon insertion [02:08:55 CEST] <babadoc> oh, [02:09:01 CEST] <babadoc> lol phi [02:09:03 CEST] <furq> javascript requires semicolons to terminate statements, but the compiler will insert them for you [02:09:06 CEST] <furq> except when it doesn't [02:09:13 CEST] <babadoc> good luck lol [02:09:20 CEST] <babadoc> go back and look through your code for years [02:09:30 CEST] <babadoc> trying to find the one error [02:09:35 CEST] <furq> on the rare occasion i have to write some js i put them in myself to save the hassle [02:09:38 CEST] <Phi> I actually like C++ because it dies easily over the tiniest thing [02:09:46 CEST] <Phi> so you get much better typing skills [02:09:53 CEST] <babadoc> well, that can be a benefit at times [02:09:59 CEST] <babadoc> because then you know there is an error [02:10:14 CEST] <babadoc> sometimes you can't tell [02:10:14 CEST] <furq> i guess the stakes are higher when you have to wait half an hour and then get an 18,000 line error message [02:10:24 CEST] <babadoc> ha [02:10:36 CEST] <Phi> speaking of which, before I did libav*, I had to find a library [02:10:50 CEST] <Phi> to preface this, I've never worked with video, displaying, or webcams [02:10:58 CEST] <Phi> so I went through GStreamer, OpenCV... [02:11:15 CEST] <Phi> OpenCV literally took 40 minutes every time I rebuilt it [02:11:25 CEST] <Phi> and I have a beefy dev PC, so... [02:11:25 CEST] <babadoc> are you using ffserver to stream the video? [02:11:35 CEST] <Phi> I don't think I am, no [02:11:36 CEST] <furq> i hope not [02:11:42 CEST] <Phi> it's not my webcam firmware [02:12:10 CEST] <Phi> "Media Server V3.1.2" is the SDP description [02:12:39 CEST] <Phi> the dumbest part was [02:13:01 CEST] <Phi> after about a month of kicking the OpenCV install around, finding debug versions, finding DLLs, linking them in the project, going through OpenCV tutorials... [02:13:07 CEST] <Phi> turns out OpenCV doesn't support any network access [02:13:12 CEST] <babadoc> ;-; [02:13:16 CEST] <babadoc> that SUUUUUCKS [02:13:20 CEST] <babadoc> holy crap [02:13:33 CEST] <Phi> USB webcams it can do, but nothing over network [02:13:46 CEST] <Phi> then there's libav*... [02:14:21 CEST] <klaxa> it looks like ffserver is going to be deprecated in the long run, huh? [02:14:24 CEST] <Phi> for which I had to set up mingw64, install the right packages, mess around with paths, find the right cmdl for make, and likewise for x264... [02:15:09 CEST] <babadoc> is mpv a ffmpeg fork? [02:15:14 CEST] <babadoc> or is it something different [02:15:16 CEST] <klaxa> no [02:15:20 CEST] <furq> klaxa: i'm pretty sure it'll be gone in 3.2 [02:15:20 CEST] <klaxa> something different [02:15:27 CEST] <babadoc> thats weird [02:15:32 CEST] <furq> there's an announcement of its death on the site somewhere [02:15:33 CEST] <Phi> I think it's a type of car [02:15:36 CEST] <klaxa> it uses ffmpeg's libraries [02:15:43 CEST] <babadoc> ah, thats what iti s [02:15:48 CEST] <furq> it's a fork of mplayer [02:15:57 CEST] <babadoc> oh, neat [02:16:03 CEST] <klaxa> oh? well there was a guy trying to save it, but it probably is too huge of a task [02:16:15 CEST] <Phi> bit like OpenOffice :p [02:16:27 CEST] <furq> it's a good idea but it needs burning down and starting from scratch [02:16:42 CEST] <Phi> they're chucking that out the window now, since LibreOffice is gaining more ground [02:16:49 CEST] <klaxa> pretty much [02:16:51 CEST] <babadoc> ha, openoffice [02:16:56 CEST] <furq> it must have been around for a decade at this point and not much has changed from what i can tell [02:17:06 CEST] <babadoc> i havent heard that program in a while [02:17:07 CEST] <furq> it still has some of the issues it had when i used it years ago [02:17:09 CEST] <klaxa> i still have patches lying around from gsoc 2015, but wow [02:17:36 CEST] <klaxa> the whole design is reeeeeally weird [02:17:51 CEST] <babadoc> yeah, thanks guys, putting -ss before the command worked nicely [02:17:56 CEST] <babadoc> it now seeks instantly [02:17:58 CEST] <babadoc> :) [02:18:07 CEST] <Phi> yea, the team got so small they could only push out one update in six months [02:18:15 CEST] <babadoc> well, it still throws errors, but it works, thats all i care about [02:18:42 CEST] <klaxa> Phi: the ffserver team? [02:18:53 CEST] <Phi> nah, the OpenOffice [02:18:57 CEST] <klaxa> ah [02:19:01 CEST] <furq> are they actually ditching openoffice [02:19:10 CEST] <Phi> yea, they announced it about a month or so back [02:19:12 CEST] <furq> i'm sure i read fairly recently that they're sticking with it [02:19:45 CEST] <furq> http://mail-archives.apache.org/mod_mbox/openoffice-dev/201609.mbox/%3C008d… [02:19:52 CEST] <furq> if you mean this then that isn't an announcement of its death [02:20:02 CEST] <furq> although a bunch of places reported on it being that [02:20:24 CEST] <babadoc> just fork it to death, that will solve everyones problems [02:20:26 CEST] <babadoc> right [02:20:37 CEST] <furq> "announcement of its death" is a really unwieldy phrase to have used twice in five minutes [02:20:39 CEST] <klaxa> no... [02:21:12 CEST] <Phi> hmm [02:21:30 CEST] <Phi> well it seems they're going to that point, but they're dragging their heels for a couple more updates and hoping another company will pay to keep it going [02:21:47 CEST] <Phi> that's my guess [02:22:01 CEST] <Phi> the article I read made the demise sound pretty definite [02:22:27 CEST] <klaxa> well everyone and their dog is using libreoffice nowadays, no? [02:22:43 CEST] <furq> i know a guy who works at apache who uses libreoffice [02:22:46 CEST] <babadoc> i use a mac [02:22:50 CEST] <furq> so yeah [02:22:56 CEST] <babadoc> no libreoffice here :) [02:23:12 CEST] <babadoc> just overheating [02:23:15 CEST] <Phi> the devs want to keep OpenOffice going, but Apache doesn't seem too interested in it, so it's up in the air [02:23:45 CEST] <Phi> OpenOffice's Mac equivalent is NeoOffice [02:23:51 CEST] <Phi> it is the one [02:23:51 CEST] <furq> something like that, yeah [02:23:59 CEST] <furq> also there's some bad blood between the two camps [02:24:06 CEST] <Phi> the one for the office o.ó [02:24:23 CEST] <Phi> there would be, they're inherently rivals [02:24:27 CEST] <furq> it's hard to imagine bad blood between developers of two forks of the same software, isn't it [02:24:31 CEST] <furq> but amazingly it's true [02:24:40 CEST] <klaxa> haha [02:24:43 CEST] <Phi> my amazement reaches unto the heavens [02:25:03 CEST] <Phi> back to my issue folks [02:25:10 CEST] <Phi> I have X264 options be ignored. what do [02:25:18 CEST] <klaxa> say please [02:25:21 CEST] <Phi> plz [02:25:26 CEST] <Phi> >.> [02:25:28 CEST] <Phi> <.< [02:25:54 CEST] <Phi> http://stackoverflow.com/questions/40053873/ffmpeg-rtsp-stream-to-mpeg4-h26… [02:26:00 CEST] <Phi> moooooop [02:26:09 CEST] <Phi> I still don't know the diff between ffmpeg and libav* [02:26:21 CEST] <Phi> I probably mis-tagged the question [02:27:10 CEST] <babadoc> do you guys have any thoughts on how I could host webm files on my server and seek the file from my laptop [02:27:14 CEST] <babadoc> instead of downloading it [02:27:24 CEST] <babadoc> i dont want to use plex because its CPU intensive [02:27:28 CEST] <babadoc> and premium [02:28:05 CEST] <furq> any decent media player over http [02:28:13 CEST] <furq> maybe sshfs if you're feeling snazzy [02:29:18 CEST] <Phi> chrome has built-in player [02:29:25 CEST] <llogan> Phi: tags look fine to me. you can add the libav tag. hat tag on SO now refers to the FFmpeg liba*v libraries [02:29:32 CEST] <Phi> it seems to seek without buffering to a point [02:29:38 CEST] <llogan> * that tag [02:29:58 CEST] <furq> if your httpd supports range requests you should be able to seek anywhere [02:30:23 CEST] <furq> and if it doesn't then get an httpd from this century [02:31:13 CEST] <Phi> thanks llogan [02:31:38 CEST] <llogan> " [02:31:40 CEST] <llogan> libav (or libav*) is the collective name of the FFmpeg libraries: libavcodec, libavformat, libavfilter, libavutil, etc. The name has also been appropriated by the Libav projecta fork of FFmpeg. " [02:31:47 CEST] <llogan> from the tag desc [02:31:56 CEST] <Phi> I have added [02:32:24 CEST] <Phi> I'm now going full retard and manually checking every frame for profile being changed [02:32:54 CEST] <babadoc> any thoughts on this video https://www.youtube.com/watch?v=o4PFDKIc2fs [02:35:25 CEST] <Phi> the comments say it's sarcastic [02:35:41 CEST] <Phi> I use git like I use fireball launchers - at arm's length [02:35:53 CEST] <furq> you should use fossil [02:36:15 CEST] <furq> that way you can repeatedly tell everyone how you use fossil whenever they mention git, and then they will think you're a cool cat who doesn't play by society's rules [02:37:08 CEST] <babadoc> ha furq [02:37:21 CEST] <furq> expect to hear the following phrase a lot: "wow! you use fossil? tell me more" [02:38:07 CEST] <Phi> I've not ever heard a single person mention that before you [02:38:17 CEST] <Phi> yay, popularity [02:38:22 CEST] <furq> well i use git [02:38:24 CEST] <Phi> the next big thing is Discord [02:38:26 CEST] <furq> i'm not cool enough to use fossil [02:39:05 CEST] <furq> i'm not cool enough to repeatedly tell everyone how github are untrustworthy and i prefer to self-host my repos on an atari xl which is permanently on fire [02:39:15 CEST] <babadoc> hahahaha [02:41:22 CEST] <Phi> oh yeah [02:41:34 CEST] <Phi> well I run two servers off a raspberry pi [02:41:52 CEST] <furq> i run a quakeworld server on my raspberry pi [02:41:57 CEST] <Phi> nuuuu [02:41:59 CEST] <furq> i can't decide whether that makes me worse than the people i'm making fun of [02:42:21 CEST] <Phi> I'm not sure what metric we're using [02:42:28 CEST] <furq> smugness [02:42:30 CEST] <Phi> ...but my code's crashing again [02:42:33 CEST] <Phi> yay, C++ [02:43:21 CEST] <babadoc> i have a raspberry pi b+ [02:43:30 CEST] <babadoc> i should get a new one soon [02:43:57 CEST] <furq> they're not that much different [02:44:15 CEST] <furq> four cores and more ram is sort of nice but you still have to use a slow sd card [02:44:35 CEST] <babadoc> on another note, the server im using is so old and crappy, whenever i restart it it wont boot unless i kick it [02:44:37 CEST] <furq> i wouldn't buy anything similar that didn't have onboard eMMC and/or SATA [02:44:47 CEST] <babadoc> i think the motherboard is broke [02:44:49 CEST] <furq> and also ideally a 1G nic that isn't actually usb [02:45:04 CEST] <babadoc> 2gb of ddr2 ram [02:45:26 CEST] <Phi> maybe it's a masochist [02:45:45 CEST] <babadoc> lol [02:45:48 CEST] <Phi> just print out a little target on some A4 and stick it to the side [02:45:59 CEST] <babadoc> my computer may well be a masochist [02:46:00 CEST] <Phi> improve your self-defence and stress relief [02:46:25 CEST] <Phi> Google Chrome is [02:46:30 CEST] <Phi> at least, on my compy [02:46:41 CEST] <Phi> it has a beasty NVIDIA card but it insists on rendering everything on the processor [02:46:53 CEST] <babadoc> wow really [02:47:05 CEST] <Phi> yea [02:47:33 CEST] <Phi> my CPU has 8 cores, so it only manages to suck 25% out of it, but still [02:47:44 CEST] <babadoc> 8 cores [02:48:02 CEST] <Phi> yea [02:48:05 CEST] <babadoc> the server has a core 2 duo lma [02:48:06 CEST] <babadoc> lmao [02:48:23 CEST] <Phi> i7-4770K 3.5GHz ftw [02:48:27 CEST] <babadoc> i just grabbed something that my school was going to throw away and stuck it in the attic [02:48:28 CEST] <babadoc> wow nice [02:48:52 CEST] <furq> that's 8 threads, not 8 cores [02:48:52 CEST] <Phi> I just bought high-level stuff until I had a fully high-level compy, so I shouldn't have to upgrade for a week or two [02:49:00 CEST] <Phi> it says 8 CPUs [02:49:10 CEST] <furq> yeah it's four physical cores with HT [02:49:17 CEST] <Phi> so it tricks the computer into somehow doubling up [02:49:23 CEST] <Phi> beats me how that works [02:49:24 CEST] <babadoc> hyperthreading? [02:49:28 CEST] <furq> yeah [02:49:29 CEST] <Phi> yea [02:49:49 CEST] <Phi> but I have a nice NVIDIA GTX 970 that's all neglected [02:50:06 CEST] <furq> the os wouldn't be able to schedule properly if the cpu didn't present 8 cores [02:50:14 CEST] <Phi> (as a side note I have to work out how to hardware-accelerate H264 encoding with libav*, but that'll come later) [02:50:27 CEST] <babadoc> good luck with that [02:50:34 CEST] <Phi> you can disable HT in BIOS, I think [02:50:42 CEST] <furq> yeah you can [02:50:52 CEST] <Phi> does it still present 8? [02:50:55 CEST] <furq> no [02:51:06 CEST] <babadoc> alright, well i will be leaving now. bye [02:51:23 CEST] <furq> things will still work with four cores but you should get a speedup with HT [02:51:34 CEST] <klaxa> hyperthreading is pipelining and context switch magic [02:51:39 CEST] <furq> pretty much [02:51:47 CEST] <furq> the cpu deals with it all internally [02:52:02 CEST] <Phi> I wonder how the i7-6950X performs [02:52:12 CEST] <Phi> I'm idly scrolling the Intel product list now XD [02:53:05 CEST] <klaxa> furq: i like you, when did you join #ffmpeg? [02:54:40 CEST] <klaxa> you seem to know all the stuff i do and more :P [02:57:03 CEST] <Phi> gr [02:57:10 CEST] <Phi> it's still profile high [02:57:26 CEST] <Phi> this ruffles my jammies [03:10:42 CEST] <Phi> so [03:11:58 CEST] <Phi> well, I'm gonna sleep [03:12:19 CEST] <Phi> even scanning every packet for SDP profile information didn't fix [03:12:34 CEST] <Phi> I'll try something else tomorrow [03:12:42 CEST] <Phi> cya later folks [03:22:49 CEST] <Mad7Scientist> HI, how can I convert a video to audio .ogg? It works fine with file.mp3 it detects mp3 and drops the video. Problem is .ogg files can contain video. [03:23:29 CEST] <TD-Linux> Mad7Scientist, -vn (video none) [03:23:36 CEST] <Mad7Scientist> Thanks! [03:24:36 CEST] <Mad7Scientist> Is it still the case that stereo audio can't be mixed down to mono with ffmpeg? [03:25:49 CEST] <Mad7Scientist> encoding audio only youtube videos with a 30 fps video of a single image or a slide show at 2 frames per second is great! [03:26:12 CEST] <Mad7Scientist> I mean somebody uploaded audio and added a still image as video [03:26:42 CEST] <TD-Linux> there is a filter to mix down to mono, haven't used it though [03:28:29 CEST] <kepstin> you can use e.g. the pan filter, which lets you specify exactly how to mix them. [03:34:54 CEST] <llogan> or just do "-ac 1" [06:01:25 CEST] <kittyfoots> Trying to encode h.264 via libx264, I've got it working correctly except it seems to buffer a little over 1 second of video data. [06:01:44 CEST] <kittyfoots> Is there something I can do to reduce that buffer time (preferably to as few frames as possible - using Baseline, so no b-frames) [06:05:01 CEST] <kittyfoots> looks like with the "veryfast" preset it's buffering 14 frames [06:05:19 CEST] <furq> kittyfoots: -tune zerolatency [06:05:54 CEST] <kittyfoots> To clarify I'm using the C api, is that an option I can add via av_opt_set [06:06:00 CEST] <furq> no idea [06:06:03 CEST] <furq> probably [06:06:30 CEST] <furq> x264 is capable of one frame of latency with the right vbv settings [06:07:13 CEST] <furq> https://web.archive.org/web/20150507012544/http://x264dev.multimedia.cx/arc… [06:07:18 CEST] <furq> comment #8 [06:08:20 CEST] <BinaryBench__> Welp rip [06:08:33 CEST] <BinaryBench__> My internet isn't happy ;( [06:12:00 CEST] <kittyfoots> furq looks like that worked, thanks [06:12:19 CEST] <kittyfoots> av_opt_set(m_ctxCodec->priv_data, "tune", "zerolatency", 0); [06:13:09 CEST] <furq> if you weren't using bframes i imagine the latency was from using frame multithreading [06:15:35 CEST] <Matador> What kinda $$ is it gonna take to fix QSV in ffmpeg ? :) [11:03:12 CEST] <ootje> derr.. -filter_complex .. so if i drawtext on a color=black@0:s=1280x720 (fully transparent) background, even with drawtext=alpha=1:fontcolor=white, the text ends up with 0% alpha also.. wtf? [11:03:48 CEST] <ootje> if i ,format=yuva420p,alphaextract it i get a 100% black output (no alpha, even for the text) [11:08:18 CEST] <ootje> hm, i guess related to https://trac.ffmpeg.org/ticket/3302 [14:32:38 CEST] <SouLShocK> how can I check if an mp4 file has +faststart applied? [14:33:07 CEST] <SouLShocK> I want to check if it already has, I don't want to apply it [15:15:47 CEST] <beauty> hello [15:16:03 CEST] <beauty> how to understand audio channel layout? [17:13:21 CEST] <Threads> any reason why i get this for subtitle extraction :: Decoder (codec dvb_teletext) not found for input stream #0:4 [17:13:55 CEST] <Threads> yet ffmpeg clearly shows subtitles on stream 0:4 :: Stream #0:4[0x932](eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006) [17:15:30 CEST] <c_14> You don't have a decoder for teletext [17:15:41 CEST] <c_14> You either need to install libzvbi (or whatever) or use -c copy [17:49:15 CEST] <Mista_D> is there a switch to add a frame accuracy to concat input format, like " -ss 300 -i $file -ss 0.250 ..." otherwise it cuts from nearest i-frame [17:50:29 CEST] <DHE> no, but there is a 'trim' filter (and matching atrim for audio) [17:51:20 CEST] <DHE> you might need to make intermediate files if the filter pipeline is too complex (and it is pretty nuts what's involved) [18:02:54 CEST] <boxk> Hi, I have a script to extract part of the video and I want to do that maintaining the same quality, just cut a part. I'm using ffmpeg -i $FNAME -vcodec copy -acodec copy -threads 8 -ss $START -to $END -f mp4 build/${FNAME%.*}-$i.mp4 but such paramenters seems to be wrong [18:02:58 CEST] <boxk> how could I do that? [18:07:46 CEST] <DHE> looks okay. threads won't help you much for stream copying [18:07:55 CEST] <boxk> DHE: I see [18:08:04 CEST] <boxk> so i can remove it [18:08:04 CEST] <DHE> what's it doing? [18:08:18 CEST] <boxk> I was using it before, because I created some compression videos [18:08:23 CEST] <boxk> but now I need the same quality [18:08:49 CEST] <DHE> actually, with -ss after the input, you may have keyframe issues. [18:08:54 CEST] <boxk> mm [18:09:00 CEST] <boxk> it should be before? [18:09:26 CEST] <DHE> yes, but understand that -c copy isn't compatible with exact timestamps. ffmpeg will round timestamps to a nearby keyframe [18:09:37 CEST] <boxk> well it's fine [18:09:43 CEST] <boxk> I don't need the exact frame [18:09:55 CEST] <boxk> I don't think it will change much [18:09:59 CEST] <boxk> I mean in terms of seconds [18:10:04 CEST] <furq> it could be out by as much as five seconds [18:10:09 CEST] <boxk> wow [18:10:18 CEST] <boxk> that's much :) [18:10:38 CEST] <SchrodingersScat> didn't know you put -ss and -t before the -i [18:10:45 CEST] <SchrodingersScat> I'm doing it wrong too? [18:11:05 CEST] <furq> you can put it before or after [18:11:23 CEST] <boxk> furq: what's the main difference? [18:11:52 CEST] <furq> http://ffmpeg.org/ffmpeg.html#Main-options [18:12:06 CEST] <boxk> thx [18:12:08 CEST] <DHE> whether the seek is done on the input or whether seek is done by skipping frames on the input until the desired timestamp arrives [18:12:18 CEST] <DHE> input seeking always goes to a keyframe [18:12:27 CEST] <SchrodingersScat> interesting [18:13:04 CEST] <boxk> I'm just building a script where I can select files inside and intervals and get some slices [18:13:22 CEST] <boxk> inside a text file [18:13:26 CEST] <Mista_D> DHE: then `-f concat1 is not of much use with long gops... [18:14:00 CEST] <DHE> boxk: just a thought depending on your needs, there's an output type called 'segment' that will routinely stop one file and start a new one. so you could make 10-second increments such that the concatenation of them all is a seamless video [18:14:39 CEST] <SchrodingersScat> yeah, segment is great, I use that in one script to chop up 5 minute segments :> [18:14:42 CEST] <boxk> DHE: ah [18:15:16 CEST] <DHE> maybe that doesn't meet your needs. just thought I'd mention since you seem to be heading in that direction [18:15:55 CEST] <boxk> I basically have big files from nikon camera I recorded for a band and they wanted to select which part of that to keep. So I told them to write in a file the name following the timestamps and wrote that script [18:16:11 CEST] <DHE> ah... well never mind that then [18:16:27 CEST] <boxk> but i didn't know the -ss can miss it up to 5 secs [18:32:41 CEST] <pomaranc> hello, can ffmpeg handle video that is a mix of interlaced and progressive (as PsF, "fake" interlacing)? [18:54:56 CEST] <c_14> yadif should only deinterlace frames marked as interlaced [18:56:56 CEST] <JEEB> the problem usually is that streams don't have that signaling correct [18:57:09 CEST] <JEEB> if it is correct, SureFine jaypeg [18:59:43 CEST] <iive> isn't there interlace detect filter too? [19:00:04 CEST] <c_14> There's the idet filter [19:00:08 CEST] <c_14> No clue how good it is though [19:05:54 CEST] <pomaranc> assuming it is correctly marked [19:06:08 CEST] <pomaranc> even when using PsF? [19:08:00 CEST] <DHE> you can force yadif to deinterlace all frames, but that's going to have a negative impact on normal frames [19:37:48 CEST] <babadoc> hello [19:38:00 CEST] <babadoc> does anyone know how to copy the last 5 minutes of a video with ffmpeg [19:38:06 CEST] <babadoc> a webm [19:47:39 CEST] <soulshok> babadoc: what if you wrote -ss -00:05:00 [19:50:21 CEST] <babadoc> "ffmpeg -ss 00:05:00 -i test.webm"? [19:50:33 CEST] <babadoc> but that doesn't copy it, does it? [19:52:27 CEST] <soulshok> -ss -00:05:00 - i test.webm -c copy output.webm [19:52:31 CEST] <babadoc> Oh. [19:52:33 CEST] <babadoc> I see. [19:52:36 CEST] <babadoc> I will try that right now [19:54:03 CEST] <babadoc> It did not work [19:54:36 CEST] <babadoc> http://pastebin.com/U6KSUX5K [19:54:39 CEST] <babadoc> No idea why... [19:55:21 CEST] <babadoc> "Conversion failed!" [19:57:16 CEST] <BtbN> you need to pass the actual duration minus 5 minutes to ss. [19:58:00 CEST] <babadoc> :( [19:58:20 CEST] <babadoc> So, I would need to run something like ffmpeg -i file.flv 2>&1 | grep "Duration" [19:58:35 CEST] <babadoc> then put duration into the -ss tag [19:58:40 CEST] <furq> use -sseof 00:05:00 [19:59:14 CEST] <babadoc> Still not working. [19:59:38 CEST] <babadoc> It gave me the same v8, v9 error i posted earlier [19:59:45 CEST] <babadoc> but now it says that it has an invalid argument [19:59:52 CEST] <babadoc> (for --sseof [19:59:53 CEST] <babadoc> ) [20:00:16 CEST] <furq> -sseof not --sseof [20:00:28 CEST] <babadoc> yes, -sseof [20:00:30 CEST] <babadoc> my mistake [20:00:39 CEST] <babadoc> it still throws the error [20:01:01 CEST] <furq> pastebin the command and output [20:02:02 CEST] <babadoc> http://pastebin.com/53m5w5ej [20:03:02 CEST] <furq> oh [20:03:07 CEST] <furq> your input file isn't a webm [20:03:10 CEST] <babadoc> It output a file named Test.webm, but it has only 258 bytes [20:03:13 CEST] <babadoc> What do you mean? [20:03:19 CEST] <furq> Input #0, mpegts, from 'Oct21_2016_02_14_22.webm': [20:03:29 CEST] <furq> it's h264/aac in mpegts, and someone has given it the wrong extension [20:03:35 CEST] <babadoc> So... what exactly is [20:03:37 CEST] <babadoc> oh shit [20:03:40 CEST] <babadoc> holy [20:03:42 CEST] <furq> which explains why you can't mux the streams into webm [20:03:57 CEST] <babadoc> every single file on my system was named .webm [20:04:10 CEST] <babadoc> and i thought it was the correct extension [20:04:15 CEST] <babadoc> well. [20:04:32 CEST] <furq> it's a good job ffmpeg doesn't trust input extensions [20:04:52 CEST] <babadoc> So, is there no way to extract the last 5 minutes with the wrong extension? [20:05:04 CEST] <BtbN> just output to .ts and it will work. [20:05:05 CEST] <babadoc> Because I can still upload the webm's to youtube no problem [20:05:05 CEST] <furq> sure, but not into webm without reencoding [20:05:10 CEST] <BtbN> or anything that's not webm [20:05:12 CEST] <furq> you can mux into mp4/mkv/mpegts/whatever [20:05:21 CEST] <babadoc> okay, mp4 should work [20:05:25 CEST] <babadoc> i will export to mp4 [20:05:27 CEST] <babadoc> thank you [20:05:41 CEST] <BtbN> remember to add the faststart option for mp4 [20:05:49 CEST] <babadoc> Whats that? [20:05:51 CEST] <furq> -movflags faststart [20:05:54 CEST] <babadoc> --faststart? [20:05:56 CEST] <babadoc> oh okay [20:06:06 CEST] <BtbN> Or use a more sane container :P [20:06:08 CEST] <furq> youtube will bitch if you don't have it but it doesn't really make much difference [20:06:15 CEST] <BtbN> It does for large files. [20:06:20 CEST] <babadoc> well, youtube hasn't been bitching [20:06:29 CEST] <furq> they claim it makes conversion faster but it doesn't make much difference usually [20:06:30 CEST] <babadoc> wait, youtube will be bad for large files [20:06:34 CEST] <furq> except on very large files, yeah [20:06:40 CEST] <BtbN> furq, it makes conversion _a lot_ faster for them [20:06:48 CEST] <BtbN> because they can start transcoding while the user is still uploading. [20:07:06 CEST] <babadoc> Hm... I don't mind how long it takes to transcode [20:07:15 CEST] <furq> oh [20:07:15 CEST] <babadoc> It just matters that it is viewable to the end user [20:07:25 CEST] <furq> i guess that's what i get for usually uploading from my server [20:08:03 CEST] <babadoc> options movflags not found [20:08:05 CEST] <babadoc> weird [20:08:14 CEST] <BtbN> it's an output option. [20:08:17 CEST] <babadoc> oh [20:08:47 CEST] <BtbN> But the only reason to stick with mp4 is if you are using some software that supports nothing else [20:08:52 CEST] <BtbN> otherwise mkv is better [20:08:58 CEST] <babadoc> True. [20:10:27 CEST] <babadoc> mp4 does not work [20:10:29 CEST] <babadoc> but mkv does [20:10:35 CEST] <babadoc> so, all in all it works [20:11:46 CEST] <babadoc> nevermind [20:12:02 CEST] <babadoc> ffmpeg -sseof 00:05:00 -i Oct21_2016_02_14_22.webm -c copy -movflags faststart TestingFINAL.mkv [20:12:10 CEST] <babadoc> What exactly am i doing wrong with this [20:12:18 CEST] <BtbN> there are no movflags for mkv [20:13:07 CEST] <babadoc> the output is 1.7kb, so I am assuming it didn't work [20:13:25 CEST] <babadoc> (the full file size is 1.6gb) [20:14:47 CEST] <babadoc> it didn't work [20:15:01 CEST] <babadoc> ffmpeg -sseof 00:05:00 -i Oct21_2016_02_14_22.webm -c copy TestingFINAL2.mkv [20:15:13 CEST] <babadoc> (there are underscores in the filename) [20:17:29 CEST] <babadoc> "1.7K Oct 21 11:17 TestingFINAL2.mkv" [20:18:21 CEST] <babadoc> http://pastebin.com/MXGLZvW4 [20:21:36 CEST] <babadoc> I have fixed it. [20:21:40 CEST] <babadoc> Thanks for the help :) [20:21:53 CEST] <babadoc> the final command i used was "ffmpeg -ss -00:05:50 -i Oct21_2016_01_52_55.webm -c copy -bsf:a aac_adtstoasc test.mp4" [21:20:04 CEST] <babadoc> Hi, im back [21:20:20 CEST] <babadoc> how could i copy now the first five minutes of a video? [21:20:40 CEST] <furq> -t 00:05:00 [21:20:42 CEST] <babadoc> "ffmpeg -ss -00:00:^C -i Oct21_2016_02_14_22.webm -c copy -bsf:a aac_adtstoasc testending.mkv" was my first command to copy the last five minutes [21:20:47 CEST] <babadoc> oh okay, thanks [21:23:12 CEST] <babadoc> wow [21:23:17 CEST] <babadoc> thats weird [21:23:53 CEST] <babadoc> i had to remove the - from the time [21:23:58 CEST] <babadoc> to get it to work [21:23:58 CEST] <babadoc> ffmpeg -t 00:00:50 -i Oct21_2016_02_14_22.webm -c copy -bsf:a aac_adtstoasc testbeginning.mkv [21:24:08 CEST] <babadoc> Is there something wrong here? [21:24:14 CEST] <babadoc> It exports to mkv, but... [21:24:37 CEST] <babadoc> Why do I need to remove the - from the time period? [21:25:25 CEST] <babadoc> This command does not work "ffmpeg -t -00:00:50 -i Oct21_2016_02_14_22.webm -c copy -bsf:a aac_adtstoasc testbeginning.mkv" [21:25:39 CEST] <pzich> you want negative 50 seconds? [21:25:46 CEST] <babadoc> i want the first 50 seconds [21:26:02 CEST] <babadoc> oh [21:26:03 CEST] <babadoc> haha [21:26:05 CEST] <babadoc> i am an idiot [21:26:08 CEST] <pzich> ;) [21:26:10 CEST] <babadoc> NOW i see how that works [21:26:21 CEST] <babadoc> -50 seconds from the beginning and 50 from the... hahahaha [21:26:32 CEST] <babadoc> im still learning [21:26:53 CEST] <pzich> -t flag is for duration, so -t 50 gets you 0-50 [21:27:03 CEST] <babadoc> what is the -ss flag for? [21:27:13 CEST] <pzich> offset from the beginning [21:27:19 CEST] <babadoc> ah [21:27:27 CEST] <pzich> so -ss 10 -t 50 would be 10-60 [21:27:32 CEST] <pzich> -ss 10 -to 50 would be 10-50 [21:27:49 CEST] <babadoc> i understand now [21:27:51 CEST] <babadoc> thank you [21:28:05 CEST] <pzich> no problem! [00:00:00 CEST] --- Sat Oct 22 2016

1 0