Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2016

1 participants
62 discussions

ffmpeg-devel.log.20160830
by burek 31 Aug '16

31 Aug '16

[00:07:48 CEST] <BBB> what is p010be/le? [00:08:20 CEST] <BBB> I remember cehoyos wanting something like that a while ago also (by setting bits_per_sample or so?) using a different pixfmt [00:14:00 CEST] <jamrial> nv12 but 10bit, basically. for hwaccel [00:18:33 CEST] <TD-Linux> bofh_, it's a lossless format, likely an attempt to avoid bit-inexactness of float implementations [00:21:28 CEST] <iive> 10 most significant bits [00:41:55 CEST] <cone-427> ffmpeg 03Stephen Hutchinson 07master:92916e8542e4: avisynth: support pix_fmts added to AviSynth+ [00:57:52 CEST] <durandal_1707> does rust have templates? [00:59:23 CEST] <TD-Linux> it has generics, so "yes" [02:01:05 CEST] <Plorkyeran> and it has hygenic macros [02:56:55 CEST] <cone-427> ffmpeg 03James Almer 07master:115a90a0dbeb: doc/APIChanges: mention nb_threads addition to AVFilterContext [04:09:48 CEST] <cone-427> ffmpeg 03Tobias Rapp 07master:a64839189622: cmdutils: fix implicit declaration of SetDllDirectory function [04:09:51 CEST] <cone-427> ffmpeg 03Tobias Rapp 07release/2.8:c32ce247a026: cmdutils: fix implicit declaration of SetDllDirectory function [04:09:54 CEST] <cone-427> ffmpeg 03Tobias Rapp 07release/3.0:426b959e37bd: cmdutils: fix implicit declaration of SetDllDirectory function [04:09:58 CEST] <cone-427> ffmpeg 03Tobias Rapp 07release/3.1:12320c08221f: cmdutils: fix implicit declaration of SetDllDirectory function [10:14:17 CEST] <BtbN> Compn, no, slow as in "it takes an hour for my own mails to reach me via the list" [10:36:39 CEST] <durandal_1707> michaelni: scale filter still doesn't use slice threading? [10:46:44 CEST] <michaelni> no i think noone implemeted that yet [10:47:21 CEST] <durandal_1707> michaelni: but swscale supports it? [10:47:41 CEST] <durandal_1707> I wonder how was it tested? [10:51:38 CEST] <michaelni> swscale supports slices but theres no native thread support, so one could do slice threads for unscaled convertions from the outside (with multiple contexts), for scaled cases changes in sws are needed unless ive forgotten about some change [10:52:49 CEST] <michaelni> also talk with Pedro Arthur, he worked on code related to this [14:18:17 CEST] <BtbN> 1h15min for this mail to get through, hm [15:11:43 CEST] <ubitux> i'm confused [15:11:52 CEST] <ubitux> what's the difference between av_log_format_line() and av_log_format_line2()? [15:14:03 CEST] <JEEB> o_O [15:14:17 CEST] <JEEB> oh right, that's different level from av_log [15:18:40 CEST] <durandal_1707> michaelni: i plan to do frame mt with caches of size bb_threads, for each filter, this eats RAM [16:03:10 CEST] <BtbN> hm, something feels broken with the ML. It's taking WAY too long to deliver mails. [16:06:20 CEST] <BtbN> https://bpaste.net/show/05cc5caaaa3f something on the ffbox0-bg.mplayerhq.hu is taking its time [16:06:52 CEST] <BtbN> michaelni, ^ or whoever is in charge of those boxes? [17:20:02 CEST] <cone-287> ffmpeg 03Simon Hailes 07master:a2fcacc880ca: libavformat/crypto - encourage reads of 4096 bytes [17:20:03 CEST] <cone-287> ffmpeg 03Simon Hailes 07master:a13a81a0dc98: avformat/crypto: add seeking support on read [18:29:19 CEST] <michaelni> BtbN, ML should be fast again, i hope [19:40:49 CEST] <BtbN> what was the issue? [19:52:34 CEST] <michaelni> mailman+postfix timeouts+dns failures causing longer than normal delays [20:35:47 CEST] <BtbN> The interest on the P010 sws output seems to be incredibly high. [20:43:17 CEST] <fritsch> hehe [23:36:04 CEST] <kierank> is it possible to pin threads to certain cores in ffmpeg [23:36:15 CEST] <kierank> i.e pin the downstream threads that are created by lavc [23:36:24 CEST] <kierank> without doing weird pidof trickery [23:48:37 CEST] <Compn> on linux? bsd ? [23:48:39 CEST] <Compn> x64 ? [23:59:28 CEST] <DHE> kierank: ffmpeg doesn't do it internally, you'll have to do something external. under linux you might use control groups or the `taskset` utility [00:00:00 CEST] --- Wed Aug 31 2016

1 0

ffmpeg.log.20160830
by burek 31 Aug '16

31 Aug '16

[00:00:53 CEST] <deweydb> llogan: gotcha! the -preset ultrafast seems to have helped quite a bit. [00:02:31 CEST] <deweydb> llogan: http://pastebin.com/74V5RrnM [00:03:30 CEST] <deweydb> not sure if this can be optimized further? [00:04:44 CEST] <llogan> i mostly wanted to make sure you weren't using --disable-(y)asm. you could try a modern FFmpeg and see if it makes a difference. [00:30:53 CEST] <Hitechcg> remind me to unalias ffmpeg if I ever ask for help [00:31:08 CEST] <Hitechcg> I have all the ffmpeg commands aliased to (command) -hide_banner [02:08:30 CEST] <Victorma> Hello! I am getting "Connection to ... failed: Error number 26 occurred" inside avformat_open_input. Anyone knows what does it mean? [02:08:51 CEST] <memeka> hi; how can i convert AVFrame/AVPacket to annexB? [02:16:31 CEST] <Kadigan> Hello, fair folk of the ffmpeg land. :) [02:17:13 CEST] <DHE> memeka: if you're talking h264/265 for copying, there's a bsf for that... [02:17:37 CEST] <DHE> Victorma: what OS? [02:19:44 CEST] <Victorma> DHE: lets say none, it's happening inside a 3DS [02:19:59 CEST] <memeka> DHE: yes i know how to do it with ffmpeg [02:20:28 CEST] <memeka> but how to in code -> i am trying to feed a hw decoder only annexB frames (or else it's not decoding) ... [02:21:14 CEST] <memeka> DHE: like, in here: https://github.com/mihailescu2m/FFmpeg/commit/cca21ca457da2c921d16b5ffb29d6… - how can i do it? [02:23:41 CEST] <DHE> memeka: based on ffmpeg cli code, I'd start here: https://ffmpeg.org/doxygen/3.0/group__lavc__misc.html#ga4f87a57cd7c08c1d9b9… [02:26:18 CEST] <memeka> DHE: so i need to do that actually outside of avpriv_v4l_enqueue_frame_or_pkt_or_buf, such that avpriv_v4l_enqueue_frame_or_pkt_or_buf will receive annexb already, correct? [02:26:49 CEST] <memeka> i won't be converting frame in there, but have a filter higher up that converts the entire stream, before feeding it [02:28:00 CEST] <DHE> well, I'm looking into the code some more and there are a few API changes in newer versions of ffmpeg, so the exact function sequence varies... [02:28:24 CEST] <DHE> but you should be able to just pass in the AVPacket (or the payload thereof, still not sure which function to use) and you'll get the annexB version back out [02:31:16 CEST] <memeka> DHE: thx, i'll try [03:34:48 CEST] <kyleogrg> is yadif + mcdeint much better than just yadif? is there a better free deinterlacer that can be used with ffmpeg? [03:35:03 CEST] <BigWoop> arighgt fuck it (o°¡° o5 ;; ffmpeg -i "$INDIR/$@" -i $LOGODIR/watermark.png -filter_complex 'overlay=x=main_w-overlay_w-5:y=main_h-overlay_h-5' -strict -2 "$OUTDIR/$@" [03:35:17 CEST] <BigWoop> and I'm getting [png_pipe @ 0x3744920] Could not find codec parameters for stream 0 (Video: png, none): unspecified size [03:35:17 CEST] <BigWoop> Consider increasing the value for the 'analyzeduration' and 'probesize' options [03:35:36 CEST] <BigWoop> anyoen have a clue cause I'm grittin the teeth over here lol [03:36:40 CEST] <deweydb> is there syntax for the ffmpeg concat demuxer that does not require a file. i.e. a commandline version? instead of -i somefiles.txt perhaps -i filename.mp4 -file2.mp4 etc? [03:41:24 CEST] <Kadigan> deweydb: You can always string together multiple inputs and multiple outputs... [03:41:51 CEST] <deweydb> you mean using a filter? [03:43:11 CEST] <Kadigan> In the specific case of concat, [03:43:33 CEST] <deweydb> yeah, but a concat filter is much slower than a concat demuxer [03:43:34 CEST] <Kadigan> I'm seeing `-i "contact:file1.mp4|file2.mp4|file3.mp4"` [03:43:37 CEST] <Kadigan> Ah. [03:43:48 CEST] <Kadigan> concat: * [03:44:10 CEST] <deweydb> its ok. i'm just gonna script it to create that file. and then delete the file afterwards. [03:44:16 CEST] <deweydb> its a bit clunky but oh well [03:44:24 CEST] <Kadigan> Have You tried < "" ? [03:44:37 CEST] <Kadigan> I never did that stuff with ffmpeg before, to be honest... [03:44:51 CEST] <deweydb> yeah, i'm waaaaay down the rabbit hole [03:45:02 CEST] <deweydb> its funny cause what i'm doing ought to be pretty simple [03:45:08 CEST] <deweydb> but its surprisingly difficult. [03:45:15 CEST] <Kadigan> Funny, yes. [03:45:17 CEST] <Kadigan> Funny. [03:45:19 CEST] <Kadigan> >.> [03:45:31 CEST] <Kadigan> "Been there, done that, got the scars." comes to mind [03:45:37 CEST] <deweydb> lol [03:45:57 CEST] <Kadigan> (if You catch the reference, I love You ;)) [03:47:50 CEST] <Kadigan> If You ever need another challenge like this one, try changing a video framerate w/o modifying frames (either dropping or duplicating) in a codec that doesn't support timestamps. [03:52:17 CEST] Action: deweydb shudder [03:53:29 CEST] <Kadigan> I mean, it's basically a case of flipping the FPS bit, so to speak, but ffmpeg seems unable to do it (maybe because it's a hack?) [03:54:03 CEST] <Kadigan> Well, I base my theory on the fact that it took a second for multi-GB files in a small app once, but ffmpeg takes its sweet time to recode PTS. [03:54:59 CEST] <ytan> hey guys [03:55:31 CEST] <Kadigan> Hello. [03:55:59 CEST] <ytan> I'm having problems trying to stream using TLS protocol [03:56:10 CEST] <Kadigan> I'm not the person to ask. [03:56:12 CEST] <ytan> Not sure if this is the place to ask... [03:56:15 CEST] <ytan> hahha [03:56:31 CEST] <ytan> been stuck for a few days now [03:56:33 CEST] <Kadigan> No, seriously. I don't know anything about it. Wanted to save You the trouble of asking me specifically, since I'm active. ;) [03:56:39 CEST] <ytan> I think my sanity is slipping away [03:56:49 CEST] <ytan> no that's cool [03:56:49 CEST] <Kadigan> Oh, THAT I know plenty about, [03:56:53 CEST] <Kadigan> in conjuction with ffmpeg :D [03:56:55 CEST] <ytan> I just needed someone to talk to [03:57:10 CEST] <Kadigan> Go ahead, ask deweydb about his remuxing issues. [03:57:12 CEST] <Kadigan> Just ask. ;D [03:57:15 CEST] <ytan> and commiserate with [03:58:19 CEST] <ytan> if you don't mind me asking, what do you use ffmpeg for? [03:58:49 CEST] <Kadigan> Though I suppose this isn't a channel that takes kindly to commiserating, I suppose. But You can find help with various issues here, most of the time. [03:59:10 CEST] <Kadigan> Me? Hm, mostly recoding video. [03:59:11 CEST] <Kadigan> :D [03:59:42 CEST] <Kadigan> But seriously -- mostly for processing of incoming media (so it's a process I control, not my software), and then producing deliveries when post is done. [04:00:02 CEST] <Kadigan> That, at work. [04:00:17 CEST] <Kadigan> At home, I just use it to put all of my media into one, standard format (typically mkv and flac). [04:00:26 CEST] <Kadigan> (where it's sane to do so, anyway) [04:00:45 CEST] <ytan> I see [04:00:55 CEST] <ytan> have you considered using webm format? [04:01:21 CEST] <Kadigan> MKV has ordered chapter support. I don't know about webm. [04:01:42 CEST] <Kadigan> Can webm contain more than audio/video streams - stuff like subs, fonts, scripts etc.? [04:01:49 CEST] <ytan> ordered chapter support? is that like bookmarking in a video? [04:02:22 CEST] <ytan> good question. I don't know. [04:02:25 CEST] <Kadigan> I think You could call it that, though it's not user-generated but rather pre-made (ie. you specify them at mux). [04:02:40 CEST] <Kadigan> It also supports linked chapters, [04:02:55 CEST] <Kadigan> so you can put a common part of multiple video files (like a TV series intro) into its own file and just link against it. [04:03:49 CEST] <ytan> wow. that's neat. [04:04:01 CEST] <Kadigan> So all in all, even despite the fact that I don't put such stuff in myself, [04:04:16 CEST] <Kadigan> I do watch a lot of stuff that uses that, and I like to have a certain order to my media. So... MKV. [04:05:18 CEST] <Kadigan> As for webm, I do sometimes find myself producing such files when I need to put something up on the web, in some player or other. But that doesn't happen all that often. I usually just put up an .mp4 file coded for streaming. [04:05:36 CEST] <ytan> turns out webm is considered a profile in Matroska using VP8 and Vorbis: https://en.wikipedia.org/wiki/Comparison_of_video_container_formats [04:06:08 CEST] <Kadigan> Seems webm is a subset of Matroska, yeah. [04:06:28 CEST] <Kadigan> Or, based on. [04:06:38 CEST] <Kadigan> Says so on webmproject.org. [04:07:54 CEST] <ytan> so it seems [04:08:15 CEST] <Kadigan> And now if You'll excuse me, I have some watching before work. :D [04:08:38 CEST] <ytan> sure [04:08:42 CEST] <ytan> nice talking to you [04:12:45 CEST] <Kadigan> Likewise. :) [04:23:26 CEST] <BigWoop> Does anyone understand [png_pipe @ 0x3744920] Could not find codec parameters for stream 0 (Video: png, none): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [04:23:45 CEST] <BigWoop> cause I'm a nub anything ffmpeg related and could use anyones help [04:30:18 CEST] <memeka> hi, i'm converting each AVPacket to h264_annexb before decoding, but as a result I get: Packet header is not contained in global extradata, corrupted stream or invalid MP4/AVCC bitstream [04:31:30 CEST] <memeka> any idea why this happens? [04:35:15 CEST] <BigWoop> Sall greek to me I've been trying to google out what I can. Doesn't seem like there is much alive here :( [04:38:35 CEST] <mrelcee> beyond my use. [04:48:09 CEST] <deweydb> with the -t flag, is there some trick to getting the end of the file and backing off from there. [04:48:43 CEST] <deweydb> like: ffmpeg -ss 5 -t endOfVideo-5 -i myvid.mp4 myclip.mp4 [04:48:50 CEST] <deweydb> would take 5 seconmds off both ends [04:57:04 CEST] <ytan> if you know how long the video is, you can specify the length of the video you want to crop [05:01:16 CEST] <ytan> you can use ffprobe for that ffprobe -i input.file -show_format | grep duration [05:02:46 CEST] <Victorma> hi, i'm trying to load hls streamings in my 3ds but i'm always getting "connection to tcp:// ... failed: error number 26 occurred". i cant find any reference anywhere... this happens all the time with tcp i think. however, when i put "hls+" before the url it starts to try over and over again, and in the end i get an "invalid data found when processing input" and it seems that the connections are made through http [05:03:34 CEST] <Victorma> maybe I am missing something important to receive hls streamings? [05:23:17 CEST] <miketo> hey, i'm having trouble with some old divx/xvid/mpeg4 files. running "ffmpeg -i test.avi -c copy test.mkv" fails with notice "Can't write packet with unknown timestamp" [05:24:22 CEST] <miketo> i've tried a few different files and they all report the same. is there something strange about the way old xvid-era video streams were encoded that prevents ffmpeg from finding timestamps ^^? [05:52:01 CEST] <ytan> Hi, I'm getting the errror "Protocol not found" when I try to run ffplay tls://127.0.0.1:8554 [05:52:06 CEST] <ytan> any idea why that is? [07:07:22 CEST] <Victorma> hi, i'm trying to open a hls streaming using avformat_open_input, is there any problem with leaving the format and options as NULL? [07:11:17 CEST] <memeka> after converting a packet to annexb (bsf), i get [vd] Error while decoding frame! => any idea why this might happen? [07:33:44 CEST] <ricemuffinball> if google/youtube/gmail/maps/etc cost $10/year to use it, would you still use it? [07:37:02 CEST] <memeka> anyone can help me with the annexb filter?? [07:47:17 CEST] <BigWoop> Anyone alive in here? [07:52:41 CEST] <miketo> probably not [07:54:09 CEST] <ricemuffinball> miketo cheapstake [07:55:42 CEST] <miketo> ricemuffinball: i was responding to BigWoop [07:56:07 CEST] <ricemuffinball> miketo oh, put a name in front next time [07:58:09 CEST] <miketo> is cheapstake bad steak? [08:05:01 CEST] <Gedrean> hi, I have a problem trying to work with ffmpeg and ffserver and I can find no information online that seems to match my problem. I am running Ubuntu Server 16.0something LTS, and using the ffmpeg as included in that distro. I run ffserver and it seems to take its settings, have a feed with avi and a feed with asf (as enabled by the default config). When I run ffmpeg, input with an mp4 file, output to [08:05:04 CEST] <Gedrean> localhost:port/feed1.ffm, it loads up fine, gives me some error about past duration .79992 too large, then proceeds to start encoding at something like 110-320 fps. The server gives no indication of a problem until a client connects and then it's just dropped frame errors spamming the console until the client disconnects - client gets no data. [08:06:45 CEST] <Gedrean> A friend suggested I try -framerate 60 but that option seems gone or deprecated or never existed. I tried -r 60 for a reduction in rate, but that didn't change the fps at all. [08:13:20 CEST] <squ> what if you can change framerate in the video itself :) [08:15:04 CEST] <Gedrean> i'm not sure what you mean, squ [08:15:35 CEST] <squ> try to stream video with other framerate [08:16:04 CEST] <Gedrean> I'm still not following - where am I changing a framerate? [08:18:47 CEST] <memeka> anyone can help me with the annexb filter?? [08:19:36 CEST] <Gedrean> A bit more searching using a few other options has revealed I could try -re - which seems to have put the output of ffmpeg at the same framerate as the feed settings (15 for now) in the ffserver config - but when connecting using a media player (VLC in this case) to the ffserver I still see a "too large number of skipped frames" error [08:20:01 CEST] <Gedrean> Same if I set the feed framerate to 30 [08:20:22 CEST] <squ> Gedrean: you can encode a video file with specific framerate [08:20:44 CEST] <squ> if framerate is your problem, which I don't know if it is [08:21:43 CEST] <furq> fyi ffserver is going to be removed soon so you probably shouldn't use it [08:21:53 CEST] <furq> you also probably shouldn't use it because it sucks [08:22:20 CEST] <Gedrean> ahhh [08:22:36 CEST] <Gedrean> squ: I'm not encoding a file the file is already encoded fine. It plays fine just trying to stream it [08:22:49 CEST] <squ> oh my [08:22:53 CEST] <Gedrean> but if ffserver is deprecating which it sounds like, what's a better streaming server you'd suggest? [08:23:07 CEST] <squ> you can encode a file with needed framerate and stream it [08:23:09 CEST] <Gedrean> furq that is [08:23:10 CEST] <furq> the only one i've ever used is nginx-rtmp [08:23:27 CEST] <Gedrean> heh, except trying to avoid flash necessity here lol [08:23:37 CEST] <Gedrean> well, thanks anyway. :) [08:23:39 CEST] <furq> if you're connecting with vlc then you can do that just fine with rtmp [08:23:44 CEST] <Gedrean> oh you can? [08:23:47 CEST] <Gedrean> hmm [08:23:47 CEST] <furq> it also outputs to hls/dash if you care about web browsers [08:23:51 CEST] <squ> you can stream with vlc itself [08:24:21 CEST] <furq> although if you're not using a web browser then rtmp is much better than those two hack jobs [08:24:25 CEST] <Gedrean> yeah streaming with vlc is a headache on its own [08:24:32 CEST] <squ> why [08:24:42 CEST] <squ> last time I tried it worked ok [08:24:48 CEST] <Gedrean> Because the documentation and usage is completely unclear [08:24:59 CEST] <squ> clear as day [08:25:03 CEST] <Gedrean> For every command line, it mentions "options" and doesn't say what those are [08:25:27 CEST] <Gedrean> the wiki page for command line arguments is just a copy paste of the --help and that doesn't detail what things to put in [08:25:45 CEST] <bencoh> --fullhelp [08:26:03 CEST] <Gedrean> yeah that's all the wiki page is, and it's not clear [08:26:20 CEST] <squ> maybe problem is with you [08:27:09 CEST] <squ> I'm told you couple of times to try to encode video with framerate you want (15), and you don't get it [08:27:27 CEST] <bencoh> well vlc definitely isn't a proper broadcast solution, but it can do the job [08:27:49 CEST] <squ> I streamed hockey match for my friend with it [08:28:17 CEST] <squ> he called me in emergency saying there is important match going on now [08:28:22 CEST] <Gedrean> I'm going to drop the whole encoding, framerate, etc, bullshit because you're stukc on saying I need to re-encode the video which is not at all the damn problem. [08:28:32 CEST] <bencoh> yeah and I know ISPs than stream a few hundreds channels with it [08:28:35 CEST] <bencoh> but still :) [08:28:36 CEST] <squ> I figured out how to stream it quite quickly [08:28:48 CEST] <furq> squ: did you do so with the express written consent of the national hockey league [08:28:49 CEST] <Gedrean> squ: Did you have a GUI? [08:29:04 CEST] <squ> me? gui? [08:29:08 CEST] <squ> well [08:29:34 CEST] <bencoh> he probably meant guilt or something like that [08:30:14 CEST] <Gedrean> no I meant GUI [08:30:18 CEST] <Gedrean> Graphical user Interface [08:30:29 CEST] <Gedrean> because every fuckign streaming tutorial out there for vlc is based upon using a windows gui [08:30:30 CEST] <furq> as an aside, the whole framerate thing is an artefact of ffserver not letting you stream without reencoding [08:30:38 CEST] <furq> because, as i might have said, ffserver sucks [08:30:55 CEST] <furq> so you probably don't actually need to do that [08:30:55 CEST] <bencoh> Gedrean: just kidding :) [08:30:56 CEST] <Gedrean> furq: Wow. Okay yeah that explains that. Thank you. You were FAR more helpful at explaining why something is. [08:31:40 CEST] <Gedrean> I swear all I'm trying to do is take a video and begin streaming it so multiple stations can receive it, this is giving me an ulcer I fear. I'm off to try to study the VLC documentation more. [08:35:09 CEST] <ytan> furq [08:36:07 CEST] <ytan> have you had experience streaming using encryption? [08:36:31 CEST] <memeka> :( can anyone help me with my issue? :( [08:37:38 CEST] <ytan> what's your issue? [08:39:16 CEST] <memeka> ytan: my decoder can't handle frames that are not annexb; if i run ffmpeg to save a file after doing a h264_mpeg4annexb filter and play that file, it works, but my code to convert the AVPacket directly is not [08:39:41 CEST] <memeka> where the code is: https://github.com/mihailescu2m/FFmpeg/commit/d012bc50211fbf8c2cd61624d71fc… [08:40:14 CEST] <memeka> basically replace packet data with the one resulted from the av_bitstream_filter_filter function [08:41:18 CEST] <memeka> the file converted by ffmpeg will complain that "packet was not converted to annexb" and play (cause it's already converted); files that are not annexb will say "packet was successfully converted to annexb" but won't actually play :( [08:51:58 CEST] <nonex86> why converting from avcc to anneb and vise versa is a problem for you? its quite easy task [08:52:11 CEST] <nonex86> *annexb [08:59:59 CEST] <ytan_> I don't know the answer to that. Sorry. [09:01:55 CEST] <memeka> nonex86: well i can't see what's wrong wuith my code [09:02:54 CEST] <nonex86> well, lets see how this should work [09:03:01 CEST] <nonex86> you open the source file [09:03:06 CEST] <nonex86> check the extradata [09:03:31 CEST] <nonex86> if its in avcc format, get the size of length prefix [09:03:46 CEST] <nonex86> than for every nalu in packet [09:03:54 CEST] <nonex86> read the size of nalu [09:04:08 CEST] <nonex86> put a start code to decoder [09:04:13 CEST] <nonex86> put a nalu payload [09:04:21 CEST] <nonex86> thats all i guess [09:04:33 CEST] <nonex86> if the extradata contains annexb payload [09:04:43 CEST] <nonex86> you even dont need to convert anything [09:07:18 CEST] <nonex86> if the size of length is 4 bytes you can just replace it with start code "inplace" [09:08:48 CEST] <nonex86> and if you dont see whats wrong with code i guess it would be good idea to check it in debugger :) [09:13:46 CEST] <memeka> well, it all looks good [09:13:56 CEST] <memeka> but mpv complains [09:15:51 CEST] <memeka> nonex86: what i do: if codec = H264, create av_bitstream_filter_init("h264_mp4toannexb") ; for each packet, av_bitstream_filter_filter(s->bsf, avctx, NULL, &p_filtered, &n_filtered, avpkt->data, avpkt->size, avpkt->flags & AV_PKT_FLAG_KEY); [09:16:16 CEST] <nonex86> i never used ffmpeg bitstream conversion filters [09:16:26 CEST] <nonex86> i just converted payload myself [09:16:29 CEST] <memeka> then replace avpkt->data with p_filtered and avpkt->size with n_filtered [09:16:29 CEST] <nonex86> but again [09:16:44 CEST] <nonex86> you can check in debugger what do you get [09:16:56 CEST] <nonex86> after using conversion filter [09:17:12 CEST] <nonex86> what exactly happends with your packet payload [09:17:21 CEST] <nonex86> to be sure its the thing you want [09:17:55 CEST] <memeka> i may need debug flags when compiling, now debugging doesn't work [09:19:34 CEST] <nonex86> well, actually you can debug any code, even not a debug build :) but if you need, yes, rebuild it with debug information, its not a problem i guess [09:20:17 CEST] <nonex86> one more question [09:20:25 CEST] <nonex86> avpkt->flags & AV_PKT_FLAG_KEY [09:20:39 CEST] <nonex86> ^^^ why do you need this parameter? [09:20:56 CEST] <nonex86> what does it mean in context of conversion process? [09:21:00 CEST] <nonex86> just curious [09:22:06 CEST] <nonex86> its a keyframe flag, but why do it need to be supplied to conversion? [09:23:13 CEST] <nonex86> ah, well, never mind [09:23:19 CEST] <nonex86> i already check documentation :) [09:28:54 CEST] <memeka> i have no idea [09:29:11 CEST] <memeka> but the function had flag, so i supplied it [09:29:21 CEST] <nonex86> yeah, i already check it :) [09:56:34 CEST] <well> hey guys, i want to convert a bluray (mkv) into a 480p video with max size of 160mb. with other sources the results were really good but now i got a source where the results looks really ugly [09:56:50 CEST] <well> can you maybe tell me what i have to adjust or recommend anything? [10:06:31 CEST] <gauthier> Hi! I have trouble with avformat_new_stream(). [10:07:57 CEST] <gauthier> The comment for AVStream's member `codecpar` in avformat.h states that memory is allocated for `codecpar` in `avformat_new_stream()` [10:09:00 CEST] <gauthier> Yet after calling `av_st = avformat_new_stream(av_oc, video_codec);`, which does not return any error, I get: [10:09:17 CEST] <gauthier> av_oc->streams[0]->codecpar == 0 [10:09:55 CEST] <gauthier> my guess is that the ffmpeg source I am looking for does not match what I got installed on my system. [10:10:36 CEST] <gauthier> But I don't know how to match the lib version with the source version. [10:10:48 CEST] <gauthier> ldd on my application says: [10:10:55 CEST] <gauthier> libavformat.so.56 => /usr/local/lib/libavformat.so.56 (0x00007f629ef8f000) [10:10:55 CEST] <gauthier> [10:11:28 CEST] <gauthier> but what tag or commit should I look for in the repo? [11:33:25 CEST] <manusitara> Hi [11:33:27 CEST] <manusitara> all [11:33:56 CEST] <manusitara> How can I extract the count of particular macro block types(I, P and S) from the frames in the video (H.264 and MP4)? [11:35:14 CEST] <BtbN> S? [11:39:52 CEST] <pihpah> Any idea how to fix that error: [aac @ 0x5621547692a0] element type mismatch 3 != 0 [11:40:17 CEST] <pihpah> I am trying to convert mkv video to mp4. [11:41:13 CEST] <manusitara> @BtbN S stands for skipped macro block [11:41:39 CEST] <pihpah> It looks like the problem is with the audio stream. [11:48:11 CEST] <pihpah> Okay, seems like I can just ignore that error. [11:48:56 CEST] <pihpah> Thanks for helping, feel free to grab some cookies in the jar. [11:49:14 CEST] <manusitara> How can I extract the count of particular macro block types(I, P and S) from the frames in the video (H.264 and MP4)? [12:27:52 CEST] <iive> manusitara: maybe something in ffprobe would help you in that... [12:27:56 CEST] <c_14> manusitara: ffprobe -v quiet -show_entries frame=pict_type -select_streams v -count_frames -of flat ako_framed.webm | sed 's/[^=]\+="$.$"/\1/' | gawk '{array[$0]+=1} END {for (i in array) { print i, array[i] } }' [12:28:59 CEST] <manusitara> thanks for the suggestions [12:29:00 CEST] <manusitara> Also, I would like to extract the prediction residual of each of the P and B frames (computed from its corresponding reference frame) in the video from the encoded version itself while the package is decoding it. [12:29:01 CEST] <iive> c_14: isn't that only frame types? [12:29:42 CEST] <c_14> Oh, hmm. I don't think ffprobe will give you anything about macro blocks [12:30:17 CEST] <c_14> you'd probably have to hook into the h264 decoder to get those [12:30:43 CEST] <manusitara> any suggestions on how to do that? [12:31:47 CEST] <BigWoop> anyone see anything wrong with this by chance ffmpeg -i movie.mp4 -i logos/watermark.png -filter_complex 'overlay=x=main_w-overlay_w-10:y=main_h-overlay_h-10' -strict -2 output.mp4? I'm at a loss [12:34:29 CEST] <BigWoop> I'm I asking the wrong question lol? [12:37:12 CEST] <c_14> manusitara: ah, nvmd. ffmpeg -debug mb_type -i video -f null /dev/null [12:37:18 CEST] <c_14> Have fun parsing the output though& [12:38:27 CEST] <c_14> For the prediction residual you'd probably have to modify the decoder/parser in ffmpeg [12:38:45 CEST] <BigWoop> Ewwww :( [12:39:23 CEST] <c_14> BigWoop: hmm? [12:40:07 CEST] <BigWoop> Nada I'm just having my own fit over here probably something silly but its killing me [12:41:20 CEST] <BigWoop> http://pastebin.com/EKGfXv4N [12:44:20 CEST] <c_14> try adding -analyzeduration 1G -probesize 1G before -i logos/watermark.png [12:45:12 CEST] <manusitara> thanks c_14 [12:45:36 CEST] <c_14> But it looks like the png is missing its (or has a corrupted) header, you could probably rewrite it using anything that can open it (imagemagick, gimp w/e) [12:45:51 CEST] <c_14> Also you shouldn't need -strict -2 anymore with teh version of ffmpeg you have. [12:49:39 CEST] <BigWoop> k just s second lemme givec it go [12:51:53 CEST] <BigWoop> http://pastebin.com/dm2KmQUS [12:54:01 CEST] <c_14> Yeah, try rewriting the png with something like imagemagick or gimp or whatever [12:54:21 CEST] <BigWoop> resaving the file? [12:56:16 CEST] <BigWoop> Its just a normal PNG file thats worked before but I haven't the foggiest idea why.. resaved it image file seems fine though [12:59:53 CEST] Action: BigWoop scratchs his head [13:05:07 CEST] <BigWoop> c_14: any other ideas? [13:05:33 CEST] <c_14> What dimensions does the png have? [13:05:36 CEST] <c_14> widthxheight [13:06:06 CEST] <c_14> try -s widthxheight -i logos/watermark.png [13:06:39 CEST] <c_14> and/or -video_size widthxheight -i logos/watermark.png [13:06:45 CEST] <c_14> not sure if those are aliases [13:07:32 CEST] <BigWoop> hmm [13:08:08 CEST] <BigWoop> http://pastebin.com/uLLQm9UN [13:09:21 CEST] <c_14> ffmpeg -decoders | grep png [13:09:58 CEST] <BigWoop> http://pastebin.com/Y7Szu4fC [13:10:07 CEST] <c_14> Well [13:10:10 CEST] <c_14> That explains everything [13:10:17 CEST] <BigWoop> O.o [13:10:28 CEST] <c_14> Does your system have zlib-devel installed? [13:11:03 CEST] <c_14> or anything that provides zlib.pc (or at least zlib.h) [13:11:38 CEST] <BigWoop> I don't believe i put that in just a moment while I sift thru this [13:12:10 CEST] <furq> zlib1g-dev on ubuntu [13:13:19 CEST] <BigWoop> yteah just apt cached it I give -dev a try since I was like nope I'm not doing yum here ;) [13:13:19 CEST] <BigWoop> ok were installed on zlib [13:13:47 CEST] <c_14> now rebuild ffmpeg [13:14:00 CEST] <BigWoop> an new option in configure? [13:14:10 CEST] <furq> it's enabled by default if it finds it [13:14:11 CEST] <c_14> It should pick it up automagically [13:14:22 CEST] <c_14> you can check the configure output to see if it's there [13:15:04 CEST] <BigWoop> Usually go with ./configure --enable-gpl --enable-nonfree --enable-pthreads --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-encoder=png [13:15:27 CEST] <furq> is libfaac even still supported [13:15:52 CEST] <Kakashi> hello. is there a precise way to RMS normalize a file with ffmpeg? [13:15:58 CEST] <c_14> furq: afaik for now it's still there [13:16:03 CEST] <BigWoop> *shrug* I don't too much things to keep track of :P [13:16:08 CEST] <furq> well don't use it anyway [13:16:20 CEST] <furq> if you want to use a halfway decent non-free aac encoder then use fdk [13:16:24 CEST] <furq> otherwise just use the builtin one [13:18:14 CEST] <BigWoop> I'll be honest I'm a moron with anything ffmpeg by comparision. I just need it to water mark things though I've tinkered around with some rtmp stuff but just trying to get my quest completed here lol [13:18:41 CEST] <BigWoop> Bonking my head on the wall ... durpie dee [13:18:42 CEST] <c_14> Kakashi: https://ffmpeg.org/ffmpeg-filters.html#dynaudnorm the r value sets the rms [13:19:02 CEST] <Kakashi> c_14: thanks! [13:19:36 CEST] <durandal_1707> thats not typically normalization [13:19:55 CEST] <BigWoop> c_14: http://pastebin.com/YJb20VSi [13:20:29 CEST] <Kakashi> c_14: so, can I specify dBFS? [13:20:42 CEST] <BigWoop> c_14: it might be working just a moment on me [13:21:00 CEST] <Kakashi> I can do so with normalize_audio, but it doesn't support raw audio [13:21:39 CEST] <Kakashi> and I'd prefer not to have to transcode before normalizing [13:22:35 CEST] <Kakashi> "This filter applies a certain amount of gain to the input audio in order to bring its peak magnitude to a target level (e.g. 0 dBFS)." << aha. [13:28:22 CEST] <BigWoop> c_14: seems like its kind of working now... Now I just have to check and see if it has any problems along the way.. Thank you very much though! [14:06:25 CEST] <gauthier> Hi, I'm very new to libav. I'm going through (the right version of, this time) doc/examples/output.c, and I'm a bit overwhelmed by the amount of setup needed to output a video. [14:06:49 CEST] <gauthier> Is all that is there really necessary? [14:07:07 CEST] <gauthier> Is there any other - more minimalistic - example? [14:08:01 CEST] <gauthier> What I mean is that I'm surprised there isn't a simpler, higher level API [14:08:08 CEST] <_jason_> hello [14:08:29 CEST] <_jason_> i have cross complied build for windows on linux [14:08:44 CEST] <DHE> gauthier: you make an AVFormatContext to store the file itself, you make AVCodecContext(s) to encode the video (and audio), and so on [14:08:53 CEST] <_jason_> using https://github.com/rdp/ffmpeg-windows-build-helpers [14:09:05 CEST] <_jason_> it created a ffmpeg_g file [14:09:48 CEST] <_jason_> when i'm trying to execute it : ./ffmpeg_g.exe -f dshow -r 30 -i video="screen-capture-recorder" -s 1366x786 -vcodec libx264 output.mkv [14:10:00 CEST] <DHE> gauthier: where is this output.c you find? The official examples are list at: http://ffmpeg.org/doxygen/3.1/examples.html (a bit version dependent) [14:10:04 CEST] <_jason_> it gives : bash: ./ffmpeg_g.exe: cannot execute binary file: Exec format error [14:10:16 CEST] <gauthier> DHE: that sounds simple enough. Which is why I wonder why doc/examples/output.c is so complex [14:10:37 CEST] <gauthier> DHE: they are in the source. [14:10:56 CEST] <DHE> ... not in mine [14:11:11 CEST] <gauthier> DHE: I currently have commit 1985c2e checked out, since I want the lib version 56 [14:11:31 CEST] <DHE> oh wow, 2014 [14:11:55 CEST] <gauthier> yeah, it's the one distributed in Debian Jessie [14:12:07 CEST] <DHE> ah, that'd make sense... [14:12:59 CEST] <furq> gauthier: there's a newer version in jessie-backports [14:14:22 CEST] <gauthier> Or I could just build from git and install (I made a short attempt at that, but only the static libs seemed to install, not .so) [14:14:37 CEST] <furq> --enable-shared [14:14:48 CEST] <gauthier> (so I decided to go for the ones in apt-get) [14:14:57 CEST] <furq> the one in backports is pretty recent [14:15:08 CEST] <furq> 3.0.1 iirc [14:15:17 CEST] <gauthier> of course, you recommend to go for the latest version :) ... [14:15:50 CEST] <DHE> well, as a guy who follows the development out of both personal and professional interest, yes I do [14:16:05 CEST] <gauthier> but that's I had checked out when I was looking for examples, and the examples in master were not much simpler. [14:16:13 CEST] <furq> i'm not really sure which version you are using [14:16:18 CEST] <furq> it's not in the normal jessie repos [14:16:37 CEST] <DHE> they're designed to be thorough. like the audio encoding examples will deal with the fact that different codecs produce different amounts of output and consume different amounts of input [14:16:51 CEST] <gauthier> exactly! [14:16:52 CEST] <DHE> and of course, checking all return codes for errors [14:17:28 CEST] <gauthier> I don't mind my implementation being very narrow minded when it comes to what to output [14:18:10 CEST] <gauthier> I need a video stream, I need either no compression or mpeg... I don't need the flexibility. [14:23:18 CEST] <gauthier> Ok, I'll start over. Checking out n3.1.3, I'll install with --enable-shared. That will probably break other programs, we'll see [14:23:29 CEST] <xmedeko> Hi, I have found a great option force_original_aspect_ratio in the http://ffmpeg.org/ffmpeg-filters.html#scale filter. But rarelly it causes ffmpeg error "height not divisible by 2". is there any option, how to make this option behave like -2 in scale width or height? ths [14:25:33 CEST] <gauthier> by the way, building gives quite the number of warnings. Array bounds, deprecated, discarding const... Is it normal? [14:28:48 CEST] <durandal_1707> Yes [14:34:42 CEST] <xmedeko> looking at the source code i'm afraid force_original_aspect_ratio cannot make divisible height, width. it's pitty [14:41:41 CEST] <gauthier> any reason why --enable-shared would not imply --enable-pic in configure? [14:43:47 CEST] <durandal_1707> because its different option [14:45:28 CEST] <gauthier> I'm just trying to understand why one would like to build shared libs without PIC. (really, this is not meant as an aggressive question) [16:21:14 CEST] <inkbottle> Hi, I'm trying to do sth like that: ffmpeg -i test.wav -f avi pipe:1 | cat > test.avi, but from a webcam, and to a video player [16:22:48 CEST] <inkbottle> this: ffmpeg -v verbose -r 5 -s 320x240 -f video4linux2 -i /dev/video0 pipe:1 | ffmpeg - [16:23:00 CEST] <inkbottle> gives Unable to find a suitable output format for 'pipe:1' [16:23:28 CEST] <furq> you had the answer in your first command [16:24:38 CEST] <inkbottle> furq: really? [16:24:45 CEST] <Spring> is it possible to merge two videos on top of each other with ffmpeg? [16:24:47 CEST] <furq> add -f avi (and probably also -c copy) before pipe: [16:25:05 CEST] <furq> or -f nut if the webcam outputs rawvideo [16:25:27 CEST] <furq> it'll probably be mjpeg though in which case i guess avi is right [16:25:49 CEST] <furq> Spring: what does "merge two videos on top of each other" mean [16:25:55 CEST] <furq> overlay? [16:26:45 CEST] <durandal_1707> vstack? blend? [16:26:56 CEST] <durandal_1707> lut2? [16:27:18 CEST] <Spring> vstack looks like it's what I [16:27:24 CEST] <Spring> 'm looking for, thanks [16:28:09 CEST] <durandal_1707> your videos need to be of same format and width [16:28:28 CEST] <inkbottle> I must be doing sth silly: ffmpeg -v verbose -r 5 -s 320x240 -f video4linux2 -i /dev/video0 -f avi -c copy "pipe:1" | ffmpeg - => Unable to find a suitable output format for 'pipe:' [16:28:47 CEST] <inkbottle> same without the quotes [16:29:11 CEST] <inkbottle> I tryed "-f nut" [16:29:15 CEST] <furq> if the player you're piping to is actually ffmpeg then you probably need -f avi on that side as well [16:29:25 CEST] <inkbottle> ok [16:30:13 CEST] <durandal_1707> replace pipe with -? [16:33:54 CEST] <inkbottle> At least that works: ffmpeg -f v4l2 -framerate 25 -video_size 640x480 -i /dev/video0 output.mkv => and then playing output.mkv [16:34:07 CEST] <inkbottle> as for the piping nothing worked yet [16:36:45 CEST] <Spring> durandal_1707, by format you mean codec? Or everything, including bitrate? [16:37:09 CEST] <Spring> also used one too many 'looks' in my previous post :p [16:37:31 CEST] <durandal_1707> Spring: pixel format [16:39:23 CEST] <Spring> that shouldn't be a problem then [16:49:54 CEST] <inkbottle> I'll probably find the solution some other time [18:09:26 CEST] <Lucretia> hi, I'm getting corrupt screengrabs, https://youtu.be/pFqhIGYLbDM can someone point me in the right direction of which component could be failing? [18:16:36 CEST] <iive> Lucretia: unfortunately, this looks like xorg driver issue [18:17:16 CEST] <Lucretia> iive: I was wondering whether it would be kernel, xorg, libdrm, mesa or ffmpeg [18:17:58 CEST] <Lucretia> so many components [18:27:15 CEST] <Lucretia> iive: the /usr/lib/xorg/modules/drivers/amdgpu_drv.so not the /usr/lib/dri/radeonsi_dri.so module? [18:49:38 CEST] <Mista_D> Trying to set up libx264 to use static IDR with "-g" and use non-IDR intra-refresh frames for scene change. Any advice? [18:53:01 CEST] <bencoh> is that even possible without patching it? [20:28:03 CEST] <transhuman_> anyone know how to launch ffmpegYAG or ffmpeg-hi? [22:32:28 CEST] <pxl__> hello hello [22:46:02 CEST] <Kayy> odd question. Ive got a still image that im turning into a video but I cant manage to get it over 50kbs to save my life. I'm aiming for at least 200kbs to stress test a system with. [22:46:13 CEST] <Kayy> http://pastebin.com/ccCHtATH [23:49:52 CEST] <Denise0311> Hi, is there a way to access webcam raw video stream without modifying its firmware? [23:54:25 CEST] <kyleogrg> does libvpx-vp9 have any tune options like libx264? [23:54:41 CEST] <Jnorthrup> is there a filter to un-aperture quicktime codings? [00:00:00 CEST] --- Wed Aug 31 2016

1 0

ffmpeg-devel.log.20160829
by burek 30 Aug '16

30 Aug '16

[01:53:44 CEST] <Timothy_Gu> Any more comments on https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=17 ? [09:51:48 CEST] <durandal_1707> michaelni: does dsmudhar have commit rights? [10:42:23 CEST] <michaelni> durandal_1707, ive offered access as he is in MAINTAINERs, so probably soon but not yet [11:11:59 CEST] <durandal_1707> then I gonna apply that minterpolate patch [11:39:21 CEST] <durandal_1707> the one that fixes segv [12:41:29 CEST] <wm4> mateo`: I think the mediacodec wrapper should convert timestamps to the correct unit using pkt_timebase [13:12:21 CEST] <mateo`_> wm4: it still does if pkt_timebase is set [13:12:48 CEST] <wm4> then I overlooked that [13:15:12 CEST] <michaelni> durandal_1707, the green line one ? thats ok to apply but i think it didt apply cleanly without the other [14:54:41 CEST] <durandal_1707> recursive lavfi calls are killing me, how is this able to work at all? [15:02:41 CEST] <kierank> are there any full framerate deinterlacers faster than yadif [15:02:44 CEST] <kierank> quality doesn't matter [15:04:39 CEST] <j-b> BoB? [15:08:20 CEST] <nevcairiel> w3fdif is faster, at least on 64-bit with full assembly [15:09:59 CEST] <durandal_1707> it have slice threads too [15:11:09 CEST] <durandal_1707> What is bob , just dupeing lines? [15:11:10 CEST] <kierank> maybe bob yes [15:11:27 CEST] <bencoh> 66 [15:11:29 CEST] <bencoh> woops [15:11:48 CEST] <durandal_1707> Or use bilinear resize? [15:13:45 CEST] <durandal_1707> michaelni: adding frame threading inside filter is much much much easier, don't you agree? [15:15:14 CEST] <kierank> durandal_1707: probably going to do bilinear resize on both fields [15:21:27 CEST] <michaelni> durandal_1707, i didnt try to implement either so i dont really know which is easier [15:23:17 CEST] <cone-058> ffmpeg 03Steven Liu 07master:557ad3a4745c: avformat/hlsenc: add option hls_init_time to set init hls window segment duration [15:23:17 CEST] <cone-058> ffmpeg 03Steven Liu 07master:7ba98824a948: doc/muxers: add option hls_init_time document [15:28:06 CEST] <durandal_1707> michaelni: is my patchset to add finer control to lavfi slice threading, ok? [15:30:32 CEST] <michaelni> durandal_1707, yes i think they are ok [15:38:44 CEST] <BtbN> So, AV_PIX_FMT_P010 is NV12 for 10bit? [15:41:45 CEST] <wm4> yes [15:42:23 CEST] <BtbN> So there is no conversion to that in sws, hm [15:44:20 CEST] <durandal_1707> So I must bump minor, when adding new field to AVFilterContext? [15:44:41 CEST] <BtbN> yes. And only add them at the end. [15:57:55 CEST] <BtbN> Does sws even support outputting 10bit formats? oO [15:58:14 CEST] <JEEB> yes [15:58:24 CEST] <JEEB> although I recommend you poke those things with zscale [15:58:26 CEST] <BtbN> So there just isn't a single 10bit output format implemented yet [15:58:40 CEST] <JEEB> huh [15:58:51 CEST] <JEEB> it can do yuv420p10 to yuv420p just fine [15:58:55 CEST] <JEEB> among other things [15:58:55 CEST] <BtbN> Right now 10bit encoding with nvenc fails, because sws can't convert to that format [15:59:02 CEST] <BtbN> that's 8bit output though [15:59:08 CEST] <JEEB> yes, and it can do it the other way :P [15:59:15 CEST] <JEEB> it probably only lacks a conversion to P010 [16:00:07 CEST] <BtbN> There is no notion of YUV420P10 in output.c [16:00:29 CEST] <JEEB> no idea, it Just Works if you try it with, say, 10bit libx264 :P [16:00:44 CEST] <BtbN> are you sure it's not just passing it through untouched? [16:06:07 CEST] <BtbN> So looks like sws can only output YUV420P10 if it's not scaling. [16:07:32 CEST] <nevcairiel> sws can output a variety of 10-bit formats, it just cant output p010 [16:07:52 CEST] <BtbN> But only in unscaled-mode from what it looks like. [16:07:57 CEST] <nevcairiel> no [16:08:04 CEST] <BtbN> Then I have no idea how and where it does it [16:08:10 CEST] <BtbN> cause in output.c they are not listed [16:08:12 CEST] <nevcairiel> is it important? :) [16:08:24 CEST] <BtbN> well, I'd like to add P010 [16:08:26 CEST] <nevcairiel> utils.c format_entries lists all supported conversions [16:08:32 CEST] <nevcairiel> the first 1 is for input, the second for output [16:08:42 CEST] <nevcairiel> all of those work wit heverything [16:08:55 CEST] <nevcairiel> and no you don'Ät [16:08:58 CEST] <nevcairiel> don't [16:09:05 CEST] <nevcairiel> sws output code is crazy ass magic [16:09:10 CEST] <nevcairiel> guess why it wasnt added =p [16:10:18 CEST] <nevcairiel> many of the base yuv4xxpxx formats are handled by rather generic code [16:10:23 CEST] <nevcairiel> all thats listed is probably more special cases [16:10:26 CEST] <BtbN> But where does it do the YUV420P10BE output? Or is there no output function for it, as it's the native internal format that needs no conversion [16:11:05 CEST] <BtbN> So I'll just set P010 to supported output in that format_entires list, and see where it explodes [16:11:31 CEST] <BtbN> probably in the output.c function for it, where it then needs something to convert the planes, but that code is weird [16:11:35 CEST] <nevcairiel> i'm not sure why you insist on going after yuv420p10be, and why be of all things, p010 is le =p [16:11:44 CEST] <BtbN> Hm? [16:11:52 CEST] <BtbN> I'm going after P010 for nvenc. [16:12:02 CEST] <nevcairiel> should rather look for nv12 because its a half-packed format of the same base layout, and how thats handled [16:12:12 CEST] <nevcairiel> and just make it do the same in 10-bit [16:12:17 CEST] <BtbN> I was looking for some other 10 bit format, wondering why it works. [16:12:34 CEST] <nevcairiel> like i said, all the planar formats probably use a rather generic function that handles all of them [16:12:41 CEST] <BtbN> But YUV420P(10) is probably the native internal format, so no conversion is needed. [16:12:55 CEST] <BtbN> They are not even handled in the output switchcase [16:13:09 CEST] <durandal_1707> is there reason why filter-complex doesn't set number of graph threads? [16:13:50 CEST] <nevcairiel> BtbN: of course they are [16:14:18 CEST] <nevcairiel> they use yuv2planeX_10LE_c etc [16:14:22 CEST] <nevcairiel> ie. the generic case [16:14:42 CEST] <BtbN> yes, but that's not in the switchcase, but in front of it. [16:14:55 CEST] <nevcairiel> well same difference [16:15:07 CEST] <nevcairiel> no reason to override it if it works for the majority of formats [16:16:00 CEST] <kierank> 3:10 PM <"nevcairiel> many of the base yuv4xxpxx formats are handled by rather generic code [16:16:00 CEST] <kierank> 3:10 PM <"nevcairiel> all thats listed is probably more special cases [16:16:00 CEST] <kierank> yes [16:16:41 CEST] <nevcairiel> anyway when i added p010 input support to sws i looked what output might need, and i decided its too scary to bother, since i have no interest in it [16:16:53 CEST] <nevcairiel> sws input is trivial in comparison to output =p [16:17:06 CEST] <BtbN> it shouldn't be too hard to add just P010BE/LE output. [16:17:21 CEST] <BtbN> I don't think even BE is needed, but might as well add it. [16:17:41 CEST] <nevcairiel> you would think so, but then again sws [16:18:05 CEST] <JEEB> iä iä swscale f'thagn [16:18:08 CEST] <kierank> what's P010 again? [16:18:13 CEST] <BtbN> 10bit NV12 [16:18:14 CEST] <kierank> yuv422p16 with LSBS? [16:18:14 CEST] <JEEB> NV12 with 10bit [16:18:15 CEST] <kierank> oh [16:18:23 CEST] <JEEB> and yes LSBS [16:18:41 CEST] <JEEB> DXVA2 10bit is defined to be it [16:18:47 CEST] <kierank> oh well you get what you deserve with LSBs :) [16:19:08 CEST] <BtbN> nvenc also uses it as input format, and if they ever add 10bit to vdpau/cuvid, it will be that. [16:19:11 CEST] <nevcairiel> thats really the annoying part of it, that it puts the bits at the other end as any of the internal formats [16:19:36 CEST] <BtbN> it does? [16:20:31 CEST] <nevcairiel> YUV420P10 is "000000XXXXXXXXXX", while P010 is "XXXXXXXXXX000000" [16:20:48 CEST] <nevcairiel> assuming a 16-bit wrapper for both, of course [16:21:19 CEST] <BtbN> /**< 10 bit Semi-Planar YUV [Y plane followed by interleaved UV plane]. Each pixel of size 2 bytes. Most Significant 10 bits contain pixel data. */ [16:21:20 CEST] <BtbN> from nvenc [16:21:29 CEST] <BtbN> so yeah, at least it matches in that regard [16:21:34 CEST] <nevcairiel> yeah, in the most significant bits [16:21:39 CEST] <nevcairiel> but thats not what the other formats we have do [16:21:54 CEST] <BtbN> would have been annoying if it expected in in the LSB [16:33:05 CEST] <cone-058> ffmpeg 03Paul B Mahol 07master:449339084fb2: avfilter: add nb_threads to AVFilterContext [16:33:06 CEST] <cone-058> ffmpeg 03Paul B Mahol 07master:5b1907142dca: avfilter: add ff_filter_get_nb_threads() [16:33:07 CEST] <cone-058> ffmpeg 03Paul B Mahol 07master:a0a57072c93b: avfilter: make use of ff_filter_get_nb_threads [16:49:31 CEST] <BtbN> kierank, nevcairiel you happen to know if I can just copy the dither-logic from nv12? [16:52:35 CEST] <BtbN> looks like nv12 is the only output format that applies dithering at all, or am I missing somthing again? [16:52:53 CEST] <BtbN> at least using the chrDither8 variable [16:53:24 CEST] <BtbN> ah, no. It's passed as argument, nevermind [17:33:48 CEST] <cone-058> ffmpeg 03Davinder Singh 07master:11a631d4a768: avfilter/vf_minterpolate: do not right shift negative numbers [17:41:45 CEST] <BtbN> so, this should be it: https://gist.github.com/14cd93969c084c303f127436388aaab3 [17:41:49 CEST] <BtbN> haven't tested it yet [17:42:33 CEST] <BtbN> I wonder what happens if the filter size is 0 though. It just returns 0 values for everything? [19:10:56 CEST] <BtbN> now I have to somehow verify if the P010 scaler works. [19:12:21 CEST] <nevcairiel> fate should test that, i think [19:12:39 CEST] <nevcairiel> but your earlier snippet probably lacked something to deal with luma [19:15:18 CEST] <BtbN> oh right, luma also needs to be shiftes left by 6 bits... [19:15:48 CEST] <BtbN> I don't think fate tests P010 output, as it didn't exist before? [19:16:11 CEST] <BtbN> It should definitely start doing it now though [19:28:56 CEST] <nevcairiel> It should automatically test any formats that have in and out support, I think [19:33:11 CEST] <jamrial> nevcairiel: doesn't look like. none of the pixdesc filters test p010, only nv12 [19:33:44 CEST] <jamrial> pixfmts rather [19:34:56 CEST] <nevcairiel> tests/pixfmts.mak is generated, it should include p010 if sws declares in/out support [19:35:16 CEST] <nevcairiel> delete it and let fate remake it [19:35:17 CEST] <jamrial> it only declares in [19:35:37 CEST] <jamrial> ./ffmpeg -pix_fmts list | grep p010 -> I.... p010[lb]e [19:35:38 CEST] <nevcairiel> yes, but thats what BtbN is trying to fix =p [19:36:06 CEST] <jamrial> ah. i shall go back under my rock then :p [19:36:33 CEST] <nevcairiel> as far as i know it tries to do a reversible conversion or something, so it might catch mismatches between in/out conversion [19:36:37 CEST] <nevcairiel> at least that would be useful [19:36:40 CEST] <nevcairiel> so maybe not [19:36:40 CEST] <nevcairiel> :D [19:37:35 CEST] <nevcairiel> anyway easy enough to just write raw yuv frames and read them back in manually [19:58:31 CEST] <kierank> is there anything faster than bilinear (fewer taps please) in swscale [20:01:20 CEST] <nevcairiel> point? [20:03:31 CEST] <kierank> ah point = nearest neighbour [20:03:52 CEST] <kierank> oh it's not [20:04:00 CEST] <nevcairiel> i thought it would be [20:04:02 CEST] <kierank> oh it is [20:04:07 CEST] <kierank> meh confusing names are confusing [20:05:46 CEST] <ubitux> there is "fast bilinear" [20:10:50 CEST] <durandal_1707> and how would that be faster than w3fdif simple? [20:12:36 CEST] <kierank> durandal_1707: eh? [20:14:42 CEST] <durandal_1707> kierank: aren't you making bob deinterlacer? [20:15:33 CEST] <kierank> avoiding libavfilter means I can render straight into hardware memory [20:19:44 CEST] <durandal_1707> yes, but nobody told you to use lavfi :D [20:28:43 CEST] <omerjerk> is there a place where the ffmpeg-devel mailing lists emails could be found? [20:28:55 CEST] <omerjerk> like we have lkml.org for linu [20:28:58 CEST] <omerjerk> *linux [20:30:57 CEST] <JEEB> omerjerk: https://ffmpeg.org/pipermail/ffmpeg-devel/ [20:31:55 CEST] <omerjerk> thanks a lot [20:41:19 CEST] <BtbN> how do I run just that one fate test? [20:42:01 CEST] <JEEB> make fate-TEST [20:42:19 CEST] <BtbN> but which one is the pixfmts copy back and fourth test? [20:46:14 CEST] <jamrial> BtbN: fate-filter-pixdesc and fate-filter-pixfmts [20:48:08 CEST] <BtbN> hm, they only output one hash though [20:57:42 CEST] <BtbN> hm, something seems to go wrong with the Y part of it [20:58:24 CEST] <BtbN> at least white is missing from the result of testsrc -> p010le -> raw file -> png [21:19:45 CEST] <BtbN> Am I missing something about the Y plane? Shouldn't it just be identical to a normal one, except for a << 6? [21:46:59 CEST] <BtbN> I don't understand this function: https://github.com/FFmpeg/FFmpeg/blob/master/libswscale/output.c#L193 [21:47:15 CEST] <BtbN> won't it, for 10 bits, just shift out 5 bits of the 10 bits? [22:13:03 CEST] <BtbN> ok, this is confusing. p010be works fine [22:13:07 CEST] <BtbN> it's only p010le that fails [22:18:26 CEST] <BtbN> http://imgur.com/a/lCJim this is the luma plane missing, or is something else wrong there? Also, the very last line does have it [22:32:11 CEST] <cone-427> ffmpeg 03Michael Niedermayer 07master:adbf1c905447: avutil/version: Mention similarities and differences to semver [22:33:53 CEST] <BtbN> There is something strange going on there. The conversion is definitely working correctly. It's just that the luma conversion function isn't called more than once. [22:48:15 CEST] <BtbN> Oh... it's overriding the conversion function with some assembley one. [22:48:21 CEST] <BtbN> Well that explains it [22:49:53 CEST] <cone-427> ffmpeg 03Michael Niedermayer 07master:ac028794ad70: avutil/version: Improve lib versioning scheme for release branches with the next major release [23:09:12 CEST] <BtbN> Ok, works now. [23:09:30 CEST] <BtbN> Doing a "full" fate run (without samples) on it now. [23:32:31 CEST] <BtbN> Is it only me or is the ffmpeg-devel list very slow recently? [23:33:09 CEST] <bofh_> out of curiosity, why does alsdec do floating-point decoding via IEEE754 softfloats instead of just using, like, native IEEE754 floats? [23:50:25 CEST] <Compn> BtbN : slow as in lack of emails? yes [23:50:30 CEST] <Compn> probably summer vacation for many [23:50:39 CEST] <Compn> or just nice weather [00:00:00 CEST] --- Tue Aug 30 2016

1 0

ffmpeg.log.20160829
by burek 30 Aug '16

30 Aug '16

[00:05:29 CEST] <ozette> what are alternatives to hls? [00:06:14 CEST] <ozette> i feel like not all browsers like hls [00:07:39 CEST] <Mavrik> HLS is pretty much the best you can do. [00:07:54 CEST] <Mavrik> There's also DASH but it's a standard from hell that's even less supported. [00:08:16 CEST] <Mavrik> (I suggest using a streaming server that can do HLS and DASH) [00:11:20 CEST] <DHE> there is a javascript library that will convert HLS to MP4 in-browser. still requires the browser capable of H264 playback [00:14:05 CEST] <ozette> hmm [00:15:58 CEST] <ozette> i will see if I can find such a js library, sounds useful, at least as a fallback [00:16:34 CEST] <Mavrik> Flash is a more useful fallback in most cases we deployed that [00:18:07 CEST] <ozette> also an idea [05:15:56 CEST] <ytan> Hello there [05:16:11 CEST] <ytan> I need some help with ffmpeg rtsp streaming [05:16:46 CEST] <ytan> Whenever I start streaming, ffmpeg.exe crashes. [05:18:58 CEST] <ytan> Here are the messages that appeared when the crash happens http://pastebin.com/CHvedJ8g [05:19:23 CEST] <ytan> Any ideas? [06:40:06 CEST] <madprops> so [06:40:08 CEST] <memeka> hi, how can i output to caca ? [06:40:12 CEST] <madprops> is libav in debian the same as ffmpeg? [06:40:15 CEST] <memeka> with ffplay? [06:44:38 CEST] <memeka> anyonw? [06:44:44 CEST] <madprops> nvm i read about it [06:44:52 CEST] <madprops> now the confusion is that supposedly debian is returning to ffmpeg [06:56:38 CEST] <furq> it returned to ffmpeg ages ago [06:56:52 CEST] <furq> if you're on stable for some reason then you can install it from backports [07:01:29 CEST] <memeka> how can i play a video to caca output with ffmpeg?? [07:11:31 CEST] <durandal_170> memeka: add -f caca smthing I don't remember [07:11:42 CEST] <memeka> durandal_170: doesn't work :( [07:12:23 CEST] <durandal_170> memeka: pastebin full output you tried [07:13:20 CEST] <memeka> durandal_170: tried: ffplay -an ./sintel_trailer-720p.mp4 -f caca [07:13:26 CEST] <memeka> output: http://paste.debian.net/794474/ [07:15:15 CEST] <durandal_170> memeka: ffplay supports caca via sdl [07:15:34 CEST] <memeka> --enable-libcaca [07:15:46 CEST] <memeka> should be libcaca, not sdl, rite? [07:15:51 CEST] <durandal_170> so compile sdl with caca support [07:16:26 CEST] <durandal_170> memeka: no, that option is for ffmpeg command [07:16:47 CEST] <memeka> can i then use ffmpeg? [07:17:02 CEST] <durandal_170> yes... [07:17:14 CEST] <memeka> durandal_170: ffmpeg -an -i ./sintel_trailer-720p.mp4 -pix_fmt rgb24 -f caca ncurses [07:17:21 CEST] <memeka> got it to work [07:17:38 CEST] <memeka> durandal_170: now, can i set the decoder manually? [07:18:12 CEST] <durandal_170> ? I don't understand [07:19:20 CEST] <shkm> Hi guys, a question: Im trying to place one or several overlays on a video. These overlays can be images or videos themselves. No problem, but I need to scale these overlays before applying them to the base video (which can also be an image). How can I do that? If I scale, for example, [1:v] as the last filter_complex operation, that ends up being the entire output. Command example: http://pastebin.com/BPXKTRQC [07:19:21 CEST] <memeka> durandal_170: e.g. i wanna add -vcodec h264 [07:20:43 CEST] <durandal_170> shkm: then add scales before overlay [07:21:03 CEST] <durandal_170> memeka: for encoding? [07:21:05 CEST] <shkm> Will give that a try, durandal_170. Thanks :) [07:21:09 CEST] <memeka> durandal_170: i want to use a hw-accelerated decoder [07:21:31 CEST] <memeka> but the decoder output format is not rgb24 [07:21:37 CEST] <memeka> which is the input for caca [07:22:02 CEST] <durandal_170> yes, caca supports only that [07:22:02 CEST] <memeka> so i need to specify decoder, and then convert nv12 (decoder output) to rgb24 ... how to do that? [07:23:48 CEST] <durandal_170> -vf format_-_rgb32 [07:23:54 CEST] <durandal_170> ? [07:24:04 CEST] <durandal_170> never tried [07:30:19 CEST] <memeka> durandal_170: something like: ffmpeg -an -i ./sintel_trailer-720p.mp4 -vcodec h264_v4l2m2m -device /dev/video0 -f caca ncurses -vf format=pix_fmts=rgb24 ? [07:31:47 CEST] <durandal_170> put vf format before -f caca ncurses [07:33:06 CEST] <memeka> tried it like that ... segm fault in any case [07:33:45 CEST] <memeka> [swscaler @ 0x89600] No accelerated colorspace conversion found from yuv420p to rgb24. [07:33:58 CEST] <memeka> [h264_v4l2m2m @ 0x12d0f0] Suggested pixel format rgb24 is not accepted on output pool, will guess one. [07:34:04 CEST] <memeka> then segm fault :( [07:34:18 CEST] <memeka> maybe the h264_v4l2m2m has issues [07:34:25 CEST] <durandal_170> heh, no [07:35:04 CEST] <durandal_170> perhaps you need to add hwdownload or something [07:35:26 CEST] <memeka> what's hwdownload? :D [07:35:50 CEST] <durandal_170> another filter [07:36:36 CEST] <durandal_170> actually, you cant use hw decoders like that [07:37:06 CEST] <memeka> durandal_170: h264_v4l2m2m had a pull request more than 1 year ago, but was not accepted - i have a patched ffmpeg with it - so it might be that [07:37:34 CEST] <memeka> in fact, this is what i wanna do - try h264_v4l2m2m :D [07:38:03 CEST] <durandal_170> I don't think that can work [07:38:36 CEST] <durandal_170> hw accels are not decoders in ffmpeg any more [07:39:12 CEST] <durandal_170> or thay are, dunno [07:40:20 CEST] <memeka> so how should thinks work? [07:40:34 CEST] <memeka> this one is accessed via v4l2 [07:41:11 CEST] <memeka> so u put in h264 in /dev/video0 and decoded nv12 comes out of it [07:42:55 CEST] <durandal_170> uh, that is hacky [07:43:22 CEST] <durandal_170> use pipe [07:44:05 CEST] <durandal_170> with another ffmpeg instance to take nv12 [07:44:24 CEST] <durandal_170> and output it to caca [07:45:07 CEST] <durandal_170> if there's container that supports nv12 [07:45:23 CEST] <durandal_170> as raw format [08:29:01 CEST] <memeka> durandal_1707: still here? [08:41:22 CEST] <memeka> durandal_1707: back? [08:57:17 CEST] <shkm> Im overlaying a video onto something else (e.g. a jpg). This kind of works, but the overlaid video behaves like a static image. Is there any reason for this? Command: ffmpeg-loop 1 -i base.jpg -i overlay1.png -i overlay2.mp4 -filter_complex "[0:v] overlay=0:0:enable='between(t, 0, 10)' [stream1]; [stream1] overlay=0:0:enable='between(t, 10, 20)'" -c:v libx264 -pix_fmt yuv420p -t 20 -r 25 -y out.ts [09:22:51 CEST] <durandal_1707> memeka: ? [09:26:59 CEST] <memeka> durandal_1707: so, looks like the decoding works - i can get libcaca picture [09:27:16 CEST] <memeka> the problem is that the hw decoder only likes annexB h264 [09:28:01 CEST] <memeka> durandal_1707: basically this works: ffmpeg -i ./sintel_trailer_1080p.mp4 -codec:v copy -codec:a none -bsf:v h264_mp4toannexb -f rawvideo - | ffplay -an -vcodec h264_v4l2m2m - [09:28:18 CEST] <memeka> is there a way to make it annexb in ffplay directly? [09:33:31 CEST] <soulshock> kind of unrelated: the website seems slow today [09:33:48 CEST] <soulshock> meaning it takes over 10 seconds to get a response [09:39:01 CEST] <durandal_1707> DOS attack? [10:44:10 CEST] <Kadigan_KSB> Hey. I was wondering: since ffmpeg doesn't have "-target xdcamhd422" like ffmbc does, can someone please enlighten me what does that target mode entail, so I can set it for ffmpeg? (since ffmbc doesn't seem to have a Mac port) [10:44:38 CEST] <Kadigan_KSB> Would anyone here even know? [10:48:28 CEST] <furq> Kadigan_KSB: https://github.com/AndyA/ffmbc/blob/cb114a8bf3d2362757d8ced6dec3b58bd7f3501… [10:49:22 CEST] <furq> https://github.com/bcoudurier/FFmbc/blob/ffmbc/ffmbc.c#L5201-L5224 [10:49:28 CEST] <furq> that one looks more up to date [11:00:29 CEST] <Kadigan_KSB> furq: thank You kindly! [11:00:46 CEST] <Kadigan_KSB> Now, I'm trying to figure out what to map color_transfer, color_primaries and color_matrix, if any [11:26:04 CEST] <Fa1th> moin moin everyone :) [11:27:47 CEST] <Kadigan_KSB> Okay, I had to figure out that flags2 changed shape into actual flags at some point. [11:56:43 CEST] <Kadigan_KSB> Okay. I need a little more help here... I'm trying to convert 1080p25 to 1080i50. I'm doing '-top 1' (TFF), '-flas +ilme+ildct', and MediaInfo still claims the file is Progressive. What am I missing? [11:56:53 CEST] <Kadigan_KSB> -flags* [12:01:07 CEST] <Mavrik> Are you actually generating interlaced frames with interlace filter? [12:03:34 CEST] <Kadigan_KSB> If I need to set up a filter, then no. I had no idea I have to use a filter, though it makes sense... [12:04:12 CEST] <Kadigan_KSB> So what, -vf interlace ? [12:11:00 CEST] <Fa1th> May I ask if its possible to create a vhs effect in a video without scripts in ffmpeg? [12:14:42 CEST] <brontosaurusrex> Fa1th: That would be a combined effort of mayn filters i imagine, probably scaling width to around 200px would be first one... [12:14:47 CEST] <brontosaurusrex> many* [12:14:57 CEST] <Kadigan_KSB> Mavrik: so now I'm attempting to use -vf interlace, and I get a "Timecode frame rate 12/1 not supported". When I set -r 25 the video looks weird (like half of the frames were dropped and then duplicated)... unfortunately, so does -r 50. [12:15:35 CEST] <Kadigan_KSB> Oh... RTFM. So it actually halves the FPS. [12:15:54 CEST] <Kadigan_KSB> Is there a way to simply encode Progressive as TF/BF? [12:29:02 CEST] <Kadigan_KSB> Funny thing... I specify -tag:v xd5c, and I always get xd5e. [13:08:00 CEST] <ytan> Has anyone got streaming to work using TLS protocol? [13:22:07 CEST] <shkm> Is there anything I should know when overlaying a video on top of an image? The overlaid video isnt played; it just shows statically. [13:27:45 CEST] <kepstin> shkm: you'll probably have to turn the image into a video by looping it. Add the "-loop 1" and "-framerate <fps>" options before the still image input. [13:29:14 CEST] <shkm> @kepstin I already have those set :( [13:36:29 CEST] <shkm> @kepstin sorry, had to remove some private project stuff from the input/output. But its something like this: http://pastebin.com/GwNy5Hej [13:39:46 CEST] <kepstin> hmm, i'd recommend using the -framerate input option, not -r (they do behave differently), but that shouldn't make a difference here :/ [13:40:57 CEST] <shkm> OK, switched it to -framerate anyway :) [13:41:12 CEST] <kepstin> shkm: how long is the video in 'overlay.mp4'? that filterchain will be taking the section from 10s to 20s in that video. [13:41:32 CEST] <kepstin> if that video isn't at least 20s long, it'll just show the last frame i think [13:42:04 CEST] <shkm> Aha! Its well below 20s. [13:42:18 CEST] <shkm> What I actually want is for the overlays to loop for those 10 seconds. [13:42:20 CEST] <kepstin> shkm: sounds like you might want to use the concat filter :) [13:42:27 CEST] <shkm> Ill go look at that. Thanks! [14:23:25 CEST] <Kadigan_KSB> Huff. Puff. Turns out I can't use ffmpeg in a straightforward fashion for this encoding after all - the recipient does technical validation based on FourCC, not content, so all frames can be interlaced, but the file will be rejected on grounds of having xd5e (progressive) instead of xd5c. [14:40:11 CEST] <c_14> Have you tried -vtag xd5c ? [15:02:41 CEST] <brontosaurusrex> Kadigan_KSB: that mpeg2 version of xdcam right? [15:03:48 CEST] <brontosaurusrex> Kadigan_KSB: I have this in my script: ffmpeg -hide_banner -i "$file" -i "$tmpdir/$base.L.wav" -i "$tmpdir/$base.R.wav" -map 0:v -map 1:a -map 2:a -vf setfield=tff -vcodec mpeg2video -pix_fmt yuv422p -b:v 50000k -minrate 50000k -maxrate 50000k -bufsize 17825792 -rc_init_occupancy 17825792 -sc_threshold 1000000000 -bf 2 -g 12 -intra_vlc 1 -non_linear_quant 1 -dc 10 -qmin 1 -qmax 12 -s 1920x1080 -flags [15:03:50 CEST] <brontosaurusrex> +ilme+ildct -aspect 16:9 -acodec pcm_s24le -ar 48000 -timecode 00:00:00:00 -f mxf "$tmpdir/$base.mxf" -loglevel panic -stats </dev/null [15:05:02 CEST] <Kadigan_KSB> c_14: yes, I have tried -vtag xd5c, -tag:v xd5c, both before and after specc'ing the format etc. [15:05:35 CEST] <Kadigan_KSB> brontosaurusrex: suppose I need an XDCAM .mov file. :) [15:05:54 CEST] <brontosaurusrex> Kadigan_KSB: mpeg2 or what? [15:07:23 CEST] <Kadigan_KSB> Is there an XDCAM format OTHER than MPEG-2? [15:07:54 CEST] <Kadigan_KSB> (if there is, that would be interesting to hear btw.) [15:08:20 CEST] <brontosaurusrex> than thats it, just replace mxf with mov [15:08:25 CEST] <Kadigan_KSB> Yes, I need an XDCAM HD422 mpeg2video in a .mov container for a delivery. The codec specified must be specifically xd5c. [15:08:39 CEST] <Kadigan_KSB> Yes, well, no matter what I set up, I end up getting xd5e. [15:09:17 CEST] <Kadigan_KSB> Even if I forcibly interlace the video - and it SHOWS - I still end up with xd5e. As I understand it, I would need to split into separate files and then remux. [15:09:25 CEST] <Kadigan_KSB> (to be clear, this is a BUG) [15:09:34 CEST] <JEEB> are you actually coding interlaced? [15:09:44 CEST] <JEEB> and if yes, how you are configuring that? [15:09:54 CEST] <Kadigan_KSB> MediaInfo and idet are claiming it's interlaced. [15:10:02 CEST] <JEEB> because ffmpeg will happily encode interlaced content as progressive [15:10:10 CEST] <JEEB> depending on the encoder [15:10:19 CEST] <Kadigan_KSB> But it doesn't matter. I don't care for it being interlaced [15:10:27 CEST] <Kadigan_KSB> (in fact, I need it claimed TFF but otherwise progressive) [15:10:42 CEST] <Kadigan_KSB> I do care for it not being set to xd5c when I want to. [15:10:50 CEST] <brontosaurusrex> Kadigan_KSB: how do you read that tag? [15:11:13 CEST] <Kadigan_KSB> Okay, wait. [15:11:59 CEST] <JEEB> Kadigan_KSB: well I'm just wondering if it (libavformat muxer) was selecting the flag depending on how it's coded :P [15:15:51 CEST] <brontosaurusrex> ok, how do i read that flag, dont see anything with mediainfo or ffprobe [15:17:11 CEST] <JEEB> if it's MOV-like use l-smash's boxdumper [15:18:39 CEST] <JEEB> btw, I don't find the string xd5e in libavformat [15:19:14 CEST] <JEEB> can you note the full command line used somewhere? [15:22:03 CEST] <Kadigan_KSB> https://paste.ee/r/oZfHW [15:29:14 CEST] <JEEB> yeah, it picks the xd5c from somewhere [15:29:24 CEST] <JEEB> couldn't find it with a simple grep so I might take a look at that after work [15:29:27 CEST] <michaelshroyer> im having a problem when uploading videos i record with my dslr to youtube. the audio is muffled when the video is played on a mobile phone without headphones [15:30:01 CEST] <BtbN> that's what poor phone speakers do. [15:30:09 CEST] <JEEB> because if there's separate identifiers for progressive and interlaced content and I *think* those flags should be enabling interlaced coding [15:30:56 CEST] <michaelshroyer> ? [15:31:06 CEST] <brontosaurusrex> Must be blind, but I dont see anything xd* [15:31:45 CEST] <Kadigan_KSB> JEEB, brontosaurusrex: ex. " Stream #0:0(und): Video: mpeg2video (xd5c / 0x63356478), yuv422p, 1920x1080 [SAR 1:1 DAR 16:9], q=1-28, 50000 kb/s, 25 fps, 12800 tbn, 25 tbc (default) [15:31:45 CEST] <Kadigan_KSB> " [15:31:57 CEST] <Kadigan_KSB> Video: mpeg2video (xd5c / ... [15:32:03 CEST] <JEEB> yeah, I noticed that. anyways, will take a look after work [15:32:07 CEST] <Kadigan_KSB> Claims to be encoding xd5c [15:32:11 CEST] <Kadigan_KSB> but when I ffmpeg idet, [15:32:12 CEST] <JEEB> that's the muxing [15:32:13 CEST] <Kadigan_KSB> it says xd5e. [15:32:36 CEST] <JEEB> what does boxdumper say? [15:32:50 CEST] <Kadigan_KSB> What's that? [15:33:06 CEST] <JEEB> a very useful tool for looking at what's actually written in a MOV-like file (MP4 etc. go as well) [15:33:11 CEST] <JEEB> comes in the L-SMASH project [15:33:23 CEST] <JEEB> https://github.com/l-smash/l-smash [15:33:33 CEST] <bencoh> libavformat/isom.c:214: { AV_CODEC_ID_MPEG2VIDEO, MKTAG('x', 'd', '5', 'e') }, /* XDCAM HD422 1080p25 CBR */ [15:33:50 CEST] <Kadigan_KSB> JEEB: know the equivalent for OS X? [15:33:59 CEST] <JEEB> Kadigan_KSB: in OS X it should be pretty simple to build [15:34:06 CEST] <JEEB> ./configure and make [15:34:11 CEST] <JEEB> it doesn't have real dependencies [15:34:15 CEST] <JEEB> other than a compiler [15:34:27 CEST] <JEEB> and in OS X you get that pretty easily with XCode/tools [15:34:52 CEST] <Kadigan_KSB> Yeah, running config nowe [15:34:55 CEST] <Kadigan_KSB> now* [15:35:21 CEST] <JEEB> after make you should be able to call `./cli/boxdumper --help` I think [15:36:08 CEST] <Kadigan_KSB> jesus that's a lot of info [15:36:17 CEST] <Kadigan_KSB> Which switches? Or do I paste everything?\ [15:36:19 CEST] <JEEB> and then you can dump the structure of a file with `./cli/boxdumper --box INPUT_FILE > boxdumper_info.txt` [15:36:29 CEST] <brontosaurusrex> Kadigan_KSB: Interesting, I have nothing in my mxf xdcams that would look like xd* [15:36:31 CEST] <JEEB> and then you can search for xd5e [15:36:39 CEST] <brontosaurusrex> both generated by ffmpeg or Adobe [15:36:41 CEST] <JEEB> brontosaurusrex: MXF is separate [15:36:44 CEST] <JEEB> completely different [15:36:45 CEST] <JEEB> this is MOV [15:36:48 CEST] <brontosaurusrex> oh [15:36:56 CEST] <Kadigan_KSB> [xd5e: Visual Description] [15:37:01 CEST] <Kadigan_KSB> (no match for xd5c) [15:37:04 CEST] <brontosaurusrex> Ok, that makes sense :) [15:37:08 CEST] <JEEB> yeah, then the file only has xd5e [15:37:11 CEST] <Kadigan_KSB> That's on OUTPUT_1080i25.mov [15:37:25 CEST] <JEEB> and you have checked the actual contents of the file instead of trusting some app ;) [15:37:33 CEST] <Kadigan_KSB> Yeah, I used my eyes to see the comb pattern. [15:37:40 CEST] <JEEB> that's completely separate [15:37:49 CEST] <JEEB> you don't need to have combing for interlaced coding [15:37:51 CEST] <JEEB> coding != content [15:38:15 CEST] <Kadigan_KSB> Okay. Please propose a good way to "check" without "trusting some app" and yet not using my eyes. [15:38:35 CEST] <Kadigan_KSB> I can't read rawhex GOP or anything. [15:38:42 CEST] <Kadigan_KSB> :) [15:38:49 CEST] <_jason_> hello [15:40:02 CEST] <JEEB> Kadigan_KSB: the written MOV ID thing can be checked with boxdumper (and yes, ffmpeg cli also shows it), and the coding mode should be check'able with ffprobe/ffmpeg [15:40:08 CEST] <JEEB> content is then something you have to check with eyes [15:41:01 CEST] <Kadigan_KSB> Well, all I can say is this: the source file has no combing, the resultant i25 file has combing, at least visually. [15:41:22 CEST] <Kadigan_KSB> I do realize that it may simply be w/ some fill, or multiplexed or something [15:41:26 CEST] <Kadigan_KSB> but then, how do I trust it? [15:41:29 CEST] <JEEB> well my point was that coding mode has nothing to do with the actual content [15:41:41 CEST] <JEEB> you can code interlaced content with progressive modes in encoders, and vice versa [15:41:49 CEST] <Kadigan_KSB> I know. [15:41:58 CEST] <Kadigan_KSB> My problem is that I consistently get xd5e, [15:42:08 CEST] <Kadigan_KSB> and the verification software consistently rejects it for not being xd5c. [15:42:09 CEST] <JEEB> yes, and I already told you that I'll poke at this after work :P [15:42:24 CEST] <Kadigan_KSB> Oh, I apologize if I'm scanning a tiny tiny bit [15:42:33 CEST] <Kadigan_KSB> (I'm kinda at work >.>) [15:42:44 CEST] <Kadigan_KSB> Sorry. [15:43:16 CEST] <JEEB> thankfully I don't have to use MPEG-2 encoding any more for anything at work, but if it's fix'able I'll try to do it. I'm just never sure when those things get set so you might or might not have to manually set the interlacism in some way in the command line [15:43:39 CEST] <Kadigan_KSB> All I know is that ffmbc does it right. [15:43:54 CEST] <JEEB> and that code we can't see because it's GPL and we can't take those changes back as LGPL :P [15:44:23 CEST] <JEEB> but it hopefully shouldn't be too hard [15:44:36 CEST] <Kadigan_KSB> Well, the way I see it, it's a bug in ffmpeg (... or so I think - there's an entry about it in the bug tracker) [15:44:41 CEST] <JEEB> yes, it is a bug [15:44:57 CEST] <Kadigan_KSB> so any fix ffmbc guys did ... theoretically contributes to core ffmpeg ;P [15:45:16 CEST] <durandal_1707> Nope [15:45:26 CEST] <JEEB> the ffmbc author made the decision to make his stuff GPL, which means that unless we make stuff GPL we can't apply those changes [15:45:30 CEST] <durandal_1707> ffmbc is gpl only [15:45:42 CEST] <JEEB> and yes, he has the right to do that since you can switch LGPL to GPL [15:45:49 CEST] <Kadigan_KSB> In any case, I'm sorry for being a bit of a spoiled princess, but I'm kinda backed into a corner of my boss wondering why I'm still spending time on this. (he's the kind of guy that "will cross that bridge when he comes to it", or "we'll worry about HDD data when they break") [15:45:52 CEST] <JEEB> it just means that it's a one-way street in that sense :P [15:46:10 CEST] <JEEB> Kadigan_KSB: hah, then I wonder why you're not looking into the movenc muxer then :P [15:46:23 CEST] <JEEB> anyways, back to work for me [15:46:36 CEST] <Kadigan_KSB> JEEB: I'm just saying that nobody says You should take their code, but since it's o/s, You're more than welcome to see HOW they fixed it, and WHERE the issue is [15:46:38 CEST] <Kadigan_KSB> or sth. [15:46:59 CEST] <JEEB> as soon as you look at it or make a "derivative" of that code it's GPL [15:47:02 CEST] <JEEB> :P [15:47:27 CEST] <JEEB> although I think this can be solved in a similar manner to the colorimetry-specific fourccs for AVI and Ut Video [15:47:30 CEST] <Kadigan_KSB> So what, if someone GPLs something and I think of the exact same thing (but not in the exact same code), I still can't claim it? [15:47:52 CEST] <bencoh> nobody talked about "claiming" [15:48:03 CEST] <JEEB> basically we're LGPL and we want to keep our stuff LGPL [15:48:10 CEST] <JEEB> he has used his right to make his changes GPL only [15:48:12 CEST] <bencoh> just that once you've looked at an implementation, then .... [15:48:18 CEST] <JEEB> ^this [15:48:20 CEST] <Kadigan_KSB> Besides, like I said - it's a bug in ffmpeg. It's not like You will have to go out of Your way to fix it in a way that's different from ffmbc, if the solution is trivial - right? [15:48:30 CEST] <JEEB> no, I just won't look at ffmbc [15:48:34 CEST] <Kadigan_KSB> Okay. [15:48:39 CEST] <Kadigan_KSB> Fair enough. [15:48:57 CEST] <bencoh> Kadigan_KSB: you could look at ffmbc, have a look at ffmpeg, and point at the bug in ffmpeg, though [15:49:10 CEST] <bencoh> and then someone would write a patch for ffmpeg [15:49:16 CEST] <JEEB> but he can't post any code from ffmbc [15:49:29 CEST] <JEEB> anyways, I hope at some point you will in such situations take a look at the FFmpeg code yourself :P [15:49:42 CEST] <JEEB> because it's not magical pixie dust [15:50:29 CEST] <Kadigan_KSB> I assume it's not, but I can only do that on my own time... And this is kind of a pain, because we're again 2 days to deadline, and I still need to keep running between two PCs to make stuff happen. It's never a crisis until it is, here. [15:50:51 CEST] <JEEB> hah [15:51:30 CEST] <Kadigan_KSB> Anyway, full-on crisis mode hat, on you go [15:51:33 CEST] <Kadigan_KSB> back to work. [15:51:35 CEST] <Kadigan_KSB> Thanks! [16:27:06 CEST] <deivid___> Hello! I have a video that, by default, doesn't detect the codec parameters, running ffprobe with -analyzduration 16M gives me the correct values. Can I fix without re-encoding? [16:27:28 CEST] <deivid___> I'm getting: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1bbf800] Could not find codec parameters for stream 0 (Video: h264 (avc1 / 0x31637661), none, 1280x720, 1000 kb/s): unspecified pixel format [16:28:04 CEST] <kepstin> weird that it works with -analyzeduration 16M, that means it must be a segmented file of some sort? [16:28:31 CEST] <kepstin> you can probably mix it by just remuxing to a new file, use '-c copy' to copy the video/audio streams without re-encoding. [16:29:30 CEST] <deivid___> I edited a few h264 files with kdenlive; it seems like it doesn't output "good" files. This has happened on 12 large files that's why I'm trying to avoid reencoding [16:29:48 CEST] <deivid___> Remuxed to another mp4 and an mkv, same thing [16:29:52 CEST] <BtbN> raw h264 is not good by any definition [16:30:13 CEST] <deivid___> nah it's not raw; a combination of h264+.. in different formats. flv/mkv/mp4 from different sources [16:34:48 CEST] <deivid___> Ok; copying the streams directly doesn't work. Splitting audio and video to different files and remuxing works. Do I report this? [16:42:31 CEST] <Kadigan_KSB> Sounds kind of like "working as intended". [16:45:54 CEST] <deivid___> Why does copying audio+video at the same time (from a broken file) result in a broken file, but copying them separately and merging them work? [16:46:43 CEST] <Kadigan_KSB> Garbage in, garbage out. [16:47:22 CEST] <Kadigan_KSB> The error is somewhere in the mux. Demuxing to two separate (perfectly valid) files removes the bullshit info. Remuxing them creates a new, valid mux. [16:47:27 CEST] <Kadigan_KSB> Or that's how it looks to me. [16:48:06 CEST] <deivid___> Then I'd like to request the feature "-force_remux" or something like that to avoid this [16:50:55 CEST] <Kadigan_KSB> Which would -probably- work... except ffmpeg might need to write to a number of different temp streams/files on the way... Not sure that's how it should behave... [17:02:52 CEST] <_jason__> hello [17:03:13 CEST] <_jason__> i have download ffmpeg and complied [17:03:38 CEST] <_jason__> running this command to capture desktop [17:04:06 CEST] <_jason__> ./ffmpeg -f x11grab -r 25 -s 361x176 -i :0.0+0,24 -vcodec libx264 -threads 0 video.mkv [17:04:28 CEST] <_jason__> nothing is showing in video.mkv just black screen [17:05:32 CEST] <Kadigan_KSB> (asdide from my suspicion about overlay video modes, [17:05:38 CEST] <Kadigan_KSB> aside* [17:06:08 CEST] <Kadigan_KSB> I would suggest You encode to something less demanding, like motion jpeg, first) [17:06:20 CEST] <_jason__> and how to do that [17:08:48 CEST] <_jason__> anyone? [17:08:53 CEST] <_jason__> hello? [17:09:23 CEST] <_jason__> i'm recording screen in ubuntu and nothing appears [17:09:37 CEST] <durandal_1707> _jason__: use better player [17:09:45 CEST] <_jason__> better player? [17:10:09 CEST] <durandal_1707> or encode to yuv420p [17:10:33 CEST] <durandal_1707> There should be message [17:10:52 CEST] <durandal_1707> Post full logs to pastebin [17:12:11 CEST] <_jason__> ok [17:17:08 CEST] <_jason__> http://pastebin.com/3qLM0sn2 [17:17:17 CEST] <_jason__> @durandal here you go [17:20:58 CEST] <mrelcee> GI_Jack ping? [17:21:02 CEST] <mrelcee> nope he isn't here [17:21:31 CEST] <mrelcee> figured out where freebsd 4 kept it's noodles.. [17:21:51 CEST] <mrelcee> hit me as i was near unconsciousness last night going to bed.. [17:27:35 CEST] <durandal_1707> _jason__: those are configure logs [17:32:48 CEST] <_jason__> let me clear logs and then create again [17:34:27 CEST] <_jason__> i cleared the logs and then started again but it seems nothing is writing into config.log... now what? [17:38:04 CEST] <durandal_1707> _jason__: ffmpeg logs! [17:39:02 CEST] <_jason_> oh ok [17:42:14 CEST] <_jason__> http://pastebin.com/Gfk1aait [17:42:59 CEST] <afnj> What is better for decoding (h264) in ffmpeg, a higher CPU frequency or more CPU cores? [17:43:34 CEST] <nonex86> afnj: how many streams plan to decode simultaneously? [17:44:03 CEST] <afnj> multiple.. its 10bit stuff too [17:44:21 CEST] <nonex86> afnj: multiple... how many exactly ? :) [17:45:00 CEST] <nonex86> afnj: also, resolution/bitrate does matter [17:45:16 CEST] <afnj> four 10bit h264 streams... 1080p content [17:45:33 CEST] <afnj> Looking at Xeon's trying to decide between more CPU cores or higher frequency for the same price [17:46:34 CEST] <nonex86> just fyi, on my quad core haswell 4.0Ghz (4 physical cores/8 ht) i decoded 9 1080p 30fps h264 streams without any noticeable problems [17:47:39 CEST] <nonex86> i guess i5 like cpu will be able to decode 4 streams without any problems [17:47:53 CEST] <nonex86> also, does xeon support intel quick sync? [17:48:24 CEST] <nonex86> if so, you can offload all decoding work to mfx engine [17:48:27 CEST] <afnj> Not 10bit content, its the 10bit thats nasty, a lot of optimizations on 8bit processing don't work [17:48:54 CEST] <nonex86> well, cant say anything about 10bit per color component [17:50:01 CEST] <nonex86> http://ic.pics.livejournal.com/vedmysh/21083959/13708/13708_original.png [17:50:12 CEST] <nonex86> 16 hd streams, stable fps on all [17:50:32 CEST] <nonex86> decoded using intel quick sync [17:51:06 CEST] <afnj> Nice! QSV has gotten really good [17:51:08 CEST] <nonex86> around 5% cpu load [17:51:18 CEST] <afnj> What CPU is that? [17:51:35 CEST] <nonex86> same haswell [17:51:43 CEST] <nonex86> let me check the model [17:52:15 CEST] <nonex86> honestly speaking dxva decoder over ffmpeg works well too [17:52:48 CEST] <nonex86> i7 4790k [18:01:30 CEST] <afnj> cool thanks yeah thats a nice CPU [18:51:05 CEST] <pxl_> hey everyone, need help on syntax if anyone has a minute? [18:52:27 CEST] <pxl_> I have a subtitle file that needs utf-8 encoding for special characters. I am using a video filter though and cant find an example online to show how to use -sub_charenc with a vf [18:52:46 CEST] <pxl_> here is my command http://pastebin.com/ecjNNRbj [18:55:43 CEST] <c_14> -vf subtitles=blah.srt:sub_charenc=UTF-8 [18:55:47 CEST] <c_14> though isn't utf-8 default? [18:56:17 CEST] <c_14> eh [18:56:25 CEST] <c_14> -vf subtitles=blah.srt:charenc=UTF-8 [19:02:15 CEST] <pxl_> thanks, going to give it a try. I think ansi is default [21:06:15 CEST] <pgorley> can h263p be accelerated using the h263_vaapi and h263_videotoolbox hwaccels? [22:11:58 CEST] <deweydb> is there any way to do this faster: [22:11:59 CEST] <deweydb> ffmpeg -i input.flv -vf "select='eq(pict_type,PICT_TYPE_I)'" -vsync vfr thumb%04d.png [22:12:12 CEST] <deweydb> i.e. extract I fromes from video [22:12:32 CEST] <deweydb> it seems incredibly slow. even when i limit it to a 90 frame chunk of video. [22:13:23 CEST] <c_14> try adding -skip_frame nokey [22:17:17 CEST] <deweydb> thanks i'll try that. [22:18:49 CEST] <kepstin> also, png encoding is pretty slow [22:20:29 CEST] <deweydb> oh. good to know, should i use jpg? [22:20:33 CEST] <deweydb> whats fastest? [22:24:27 CEST] <c_14> if the input is yuv, raw yuv will be fastest [22:26:14 CEST] <kepstin> it really depends what you're going to be doing with the images after - if you're just feeding them into another ffmpeg later, some raw yuv format is great. If you need to open them in a graphics editor, but have lots of disk space, consider maybe bmp? [22:26:41 CEST] <kepstin> if you're e.g. finding thumbnails to use on a website, you probably want jpg [22:26:44 CEST] <deweydb> i'm computing the laplacian transfer to find the least blurry ones, then saving those to disk [22:27:06 CEST] <kepstin> deweydb: so it really depends what image formats your analysis tool supports :) [22:27:30 CEST] <deweydb> yeah, i gotta look into if i can feed raw yuv into python PIL. i think i can. [22:27:36 CEST] <deweydb> actually it might save some processing power [22:27:45 CEST] <deweydb> cause i think right now i'm compressing, then expanding [22:43:56 CEST] <deweydb> when i tried the -skip_frame nokey [22:43:58 CEST] <deweydb> i get this error: [22:43:58 CEST] <deweydb> Codec AVOption skip_frame (skip decoding for the selected frames) specified for output file #0 (./test-%02d.jpg) is not an encoding option. [22:44:10 CEST] <c_14> It's an input option, put it before -i [22:44:18 CEST] <deweydb> ohhh [22:48:46 CEST] <deweydb> hmm now i'm just getting no output at all "Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)" [22:48:52 CEST] <deweydb> "ffmpeg -skip_frame nokey -i "../video_in/1472486031995_UFE2MyBWaWRlbyA4LTI3LTE2Lk1PVg.MOV" -vf "select=eq(pict_type\,I)*between(n\,739\,929)" -vsync vfr ./test-%02d.jpg" [22:57:22 CEST] <deweydb> O.O [22:57:50 CEST] <deweydb> i know why its slow... this command is processing the full video beofre taking those frames from that small segment. [22:57:59 CEST] <deweydb> but if i cut it first... [22:58:01 CEST] <deweydb> aha! [23:40:37 CEST] <deweydb> guys is there anything i can do to speed up this command: [23:40:40 CEST] <deweydb> ffmpeg -i video_temp/1472506615-no-audio.mp4 -i assets/image/bid13-logo-150-transparent.png -filter_complex "overlay=x=(main_w-overlay_w-20):y=(main_h-overlay_h-20)" video_temp/1472506615-watermarked.mp4 [23:40:50 CEST] <deweydb> basically i want to add a watermark to the whole video. [23:44:13 CEST] <relaxed> deweydb: -preset veryfast [23:47:13 CEST] <deweydb> sorry, yeah, i usually pastebin, i was being lazy cause it was just one line. [23:47:16 CEST] <deweydb> i will do that next time. [23:49:19 CEST] <mgraczyk> Hello, I noticed that much of the same functionality is implemented in libavformat/oggparseopus.c and libavcodec/opusdec.c, but that the behavior in the two implementations differs in certain cases. [23:49:32 CEST] <mgraczyk> Would it be desirable or possible to consolidate those two implementations? [23:50:03 CEST] <mgraczyk> I actually meant to say libavformat/oggparseopus.c and libavcodec/opus.c [23:50:19 CEST] <DHE> there are a lot of codecs with parsers and decoders. [23:51:47 CEST] <mgraczyk> In this case it seems that the header parsing logic in oggparseopus.c is much less detailed than the logic in libavcodec/opus.c. Is that also common? [23:57:58 CEST] <llogan> deweydb: it contains info that may reveal why it may be slow [00:00:00 CEST] --- Tue Aug 30 2016

1 0

ffmpeg-devel.log.20160828
by burek 29 Aug '16

29 Aug '16

[03:37:31 CEST] <kierank> durandal_1707: going to vdd? [03:56:53 CEST] <kode54> is it to be expected that a developer needs to implement their own pre-roll when seeking? [03:57:11 CEST] <kode54> when calling avformats seeking functions, that is [03:57:49 CEST] <kode54> I found that when using FFmpeg in VGMStream, I needed to implement a maximum of 2 seconds of pre-roll (or up to the beginning of the file, if its less than that) [03:58:07 CEST] <kode54> or else the WMA Pro decoder would ramp up from silence [03:59:03 CEST] <kode54> so I manually pre-roll and discard samples at the decode stage [04:20:03 CEST] <Compn> kierank : no, durandal_1707 said he isnt. i hope he shows though [04:24:24 CEST] <Compn> kode54 : sorry, not sure, try libav-user mailing list, for people using ffmpeg in different projects. http://ffmpeg.org/pipermail/libav-user/ [07:24:01 CEST] <kode54> I also had another question, but Ive since posted it to the mailing list [07:24:19 CEST] <kode54> specific to the use of the AAC decoder, versus parsers for ADTS or ADIF [11:10:15 CEST] <cone-906> ffmpeg 03Paul B Mahol 07master:88bcdf109a44: avfilter: hflip,swapuv,vflip: add timeline support [11:22:14 CEST] <cone-906> ffmpeg 03Jai Luthra 07master:0c023d181e58: lavc/lpc: Add min_shift parameter in LPC [12:13:20 CEST] <BtbN> michaelni, if "make fate-source" doesn't throw an error anymore, I should be fine? [12:13:46 CEST] <BtbN> Or is there something else that needs changing except for the error it shows [12:15:29 CEST] <nevcairiel> you just need to add the exception line since its not a ffmpeg header, but third-party [12:16:12 CEST] <BtbN> Yeah, that's what I did. [13:40:18 CEST] <durandal_1707> can I get reviews? Do I need to bribe someone? [13:52:16 CEST] <cone-906> ffmpeg 03Davinder Singh 07master:fecf5ae9aa74: MAINTAINER: add myself for Motion Estimation and Interpolation filters [14:49:17 CEST] <Compn> durandal_1707 : kierank wants you to come to vdd [14:50:30 CEST] <durandal_1707> I want vdd/kierank comes to me [16:04:44 CEST] <cone-906> ffmpeg 03Marton Balint 07master:13b90ff2c127: avformat: fix decoded creation_time timestamps [17:11:30 CEST] <BtbN> I really wish Nvidia would release some GT Multimedia Updated cards [17:11:40 CEST] <BtbN> Kepler is still the most recent you can get there [17:12:09 CEST] <cone-906> ffmpeg 03Timo Rothenpieler 07master:325e56479ff6: avcodec/nvenc: include nvEncodeAPI v7 SDK header [17:12:10 CEST] <cone-906> ffmpeg 03Oliver Collyer 07master:d1bf8a3aa878: avcodec/nvenc: added support for 10 bit HEVC encoding [17:12:11 CEST] <cone-906> ffmpeg 03Oliver Collyer 07master:a81b398e869e: avcodec/nvenc: added support for rate control lookahead [17:17:37 CEST] <durandal_1707> michaelni: how to properly take frames once they are returned by separate thread? [17:18:03 CEST] <durandal_1707> in lavfi, attempting to write mt frame support [18:11:34 CEST] <durandal_1707> michaelni: every thread instance needs own private context. [18:12:50 CEST] <durandal_1707> because each filter need allocate own temp memory [18:13:26 CEST] <durandal_1707> and I don't see nice way to do it [18:31:37 CEST] <cone-906> ffmpeg 03Marton Balint 07master:2ee8a4f8873b: ffmpeg: fix -stream_loop with -re [18:36:22 CEST] <BtbN> MSVC finds an amazing amount of warnings in ffmpeg. [18:49:01 CEST] <JEEB> BtbN: clang probably as well [18:49:15 CEST] <BtbN> most of them are bullshit though [18:49:29 CEST] <JEEB> yes, although clang's % of non-bullshit is probably higher [18:49:33 CEST] <JEEB> MSVC also has static analysis [18:49:38 CEST] <JEEB> (ok, clang has it as well) [18:49:45 CEST] <BtbN> There are a few valid ones, but most of them are pointless [18:50:32 CEST] <nevcairiel> it doesnt help that ffmpeg builds with W4, which really includes all sorts of warnings that most people would find "normal code" [18:50:39 CEST] <JEEB> yup [18:50:48 CEST] <JEEB> -Wall -Wextra level [18:51:15 CEST] <BtbN> not even that [18:51:24 CEST] <BtbN> it's _way_ above -Wall -Wextra -pedantic [18:51:25 CEST] <nevcairiel> more like -Wpedantic [18:51:35 CEST] <nevcairiel> no W in that? oh well [18:52:06 CEST] <BtbN> for extra fun, add -pedantic-errors [18:52:08 CEST] <JEEB> I wonder how many times someone has tried adding -Werror to FFmpeg compilation [18:52:22 CEST] <JEEB> and then facedesked hard [18:52:33 CEST] <BtbN> Werror is just plain wrong to add to productive cflags. [18:52:51 CEST] <BtbN> You don't want a compiler update with new warnings break your build for no good reason. [18:53:06 CEST] <JEEB> I know :P [18:53:27 CEST] <JEEB> I just wondered out loud if anyone had even tried that without looking at what FFmpeg produces during compilation [18:53:31 CEST] <BtbN> It's also lovely that it's impossible to change the lanauge of MSVC warnings [18:53:38 CEST] <BtbN> They are all german, with no way to change that. [18:53:39 CEST] <JEEB> as in, a random person maintaining a random package [18:54:18 CEST] <nevcairiel> dont install german msvc if you dont want german warnings =p [18:54:26 CEST] <BtbN> It is english msvc [18:54:29 CEST] <BtbN> but on a german windows [18:54:37 CEST] <BtbN> and that's what determines the compiler output apparently [18:54:54 CEST] <nevcairiel> well dont use gmerna windows then! [18:55:19 CEST] <JEEB> I think it might be using the language for non-unicode applications thing [18:55:22 CEST] <JEEB> not sure, though [18:55:22 CEST] <iive> can't you switch windows language? [18:55:26 CEST] <JEEB> you can [18:55:30 CEST] <BtbN> I don't want to switch Windows language. [18:55:44 CEST] <JEEB> anyways, try switching the code page for non-unicode apps [18:55:50 CEST] <JEEB> not sure if that'll do the trick [18:55:52 CEST] <JEEB> but worth a try [18:56:04 CEST] <iive> nah... [18:56:18 CEST] <iive> whey are not guessing the language from the codepage [18:56:28 CEST] <JEEB> you'd be surprised how many do that :P [18:56:39 CEST] <JEEB> it's called "locale" in some things even [18:56:50 CEST] Action: iive facedesk [18:56:57 CEST] Action: iive facedesks [18:57:35 CEST] <JEEB> oh, and it's called "change system locale" in the control panel thing as well [18:58:22 CEST] <cone-906> ffmpeg 03Timo Rothenpieler 07master:19e75fd8838d: avcodec/nvenc: fix library names on cygwin [18:58:23 CEST] <cone-906> ffmpeg 03Timo Rothenpieler 07master:a19989cae581: avcodec/nvenc: fix potantially uninitialized free [18:58:46 CEST] <nevcairiel> presumably you can control this in visual studio options -> environment -> international settings [18:58:54 CEST] <nevcairiel> not sure if this only applies to the gui or what [18:58:57 CEST] <BtbN> That changes the IDE language [18:58:57 CEST] <nevcairiel> since mine is all english [18:59:01 CEST] <BtbN> not the compiler output [18:59:22 CEST] <BtbN> I have spent quite some time trying to figure this out, and it is hard-tied to the system language. [18:59:36 CEST] <nevcairiel> well then its your fault for installing german windows [18:59:36 CEST] <JEEB> yeah, I just tried and it's not the system locale [18:59:50 CEST] <JEEB> because my locale is .jp and I'm getting en_us messages [19:00:06 CEST] <BtbN> I don't want an English Windows. But English compiler messages. Which is plain impossible. [19:00:59 CEST] <nevcairiel> supposedly you can delete/rename the locale dir and it falls back to english [19:06:50 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/compat/nvenc/nvEncodeAPI.h#L30… https://github.com/FFmpeg/FFmpeg/blob/master/compat/nvenc/nvEncodeAPI.h#L117 do i interpret this right, that these don't match up? oO [19:30:08 CEST] <durandal_1707> michaelni: I got idea how to start, put thread_crc to AVframeInternal [19:30:23 CEST] <durandal_1707> *thread_ctx [19:58:31 CEST] <cone-906> ffmpeg 03Timo Rothenpieler 07master:df615efcf275: avcodec/nvenc: check maximum driver API version [19:58:32 CEST] <cone-906> ffmpeg 03Timo Rothenpieler 07master:26a5cbd7811e: avcodec/nvenc: use proper soname for cuda/nvenc libraries [19:58:33 CEST] <cone-906> ffmpeg 03Timo Rothenpieler 07master:cac2df230e73: avcodec/nvenc: update license header [20:03:38 CEST] <michaelni> durandal_1707, possible yes [21:18:40 CEST] <cone-906> ffmpeg 03Thomas Hebb 07master:a37e6dd2ba85: avformat/mov: aax: pass proper AVClass to av_log() [23:25:08 CEST] <durandal_1707> michaelni: so what would ff_filter_frame do if run inside worker thread? I need to cache input frames and output frames? [23:42:57 CEST] <michaelni> durandal_1707, i didnt think deeply about it but if you have 2 filters each filtering multiply frames with a thread per frame. A worker passing a frame on would likely put it in a fifo (possibly of size 1 frame) where the next filter would take it from when the next thread is available or so [23:49:31 CEST] <durandal_1707> michaelni: and how handle ordering? using pts is fragile [23:50:31 CEST] <nevcairiel> like frame threading in avcodec, make the threads themself fifo ordered [23:50:52 CEST] <michaelni> something would need to keep track of order [23:52:53 CEST] <durandal_1707> eh, I think I got it [00:00:00 CEST] --- Mon Aug 29 2016

1 0

ffmpeg.log.20160828
by burek 29 Aug '16

29 Aug '16

[00:00:26 CEST] <furq> well yeah they're both sharing the same physical core [00:00:41 CEST] <viric> It is also annoying in terms of proper cpu scheduling; if you want a heavy background task at 'nice 20', it is going to be noticeable on higher priority tasks with HT [00:01:15 CEST] <viric> furq: I could not find a situation where HT has lower throughput. [00:01:17 CEST] <furq> did you actually disable HT in the bios or just set affinity [00:01:26 CEST] <viric> I tested both. No difference. [00:01:39 CEST] <viric> Also disabling cpus in linux /sys. No difference. All equivalent. [00:01:44 CEST] <furq> i'm more surprised by that really [00:01:57 CEST] <furq> i figured setting affinity would be worse than disabling it entirely [00:02:13 CEST] <viric> I talk about somewhat long running tasks (over some seconds) [00:02:21 CEST] <furq> googling suggests that a bunch of HPC guys think HT is the worst and always disable it, but this was from a few years ago [00:02:44 CEST] <furq> it might even have been talking about netburst-era HT [00:02:50 CEST] <viric> It fucks the scheduler process priorities [00:03:07 CEST] <viric> that alone may be a good reason to disable it [00:03:19 CEST] <furq> yeah i guess that's a bigger issue for HPC workloads [00:03:48 CEST] <viric> But definitely it gave more throughput in all I tried [00:04:05 CEST] <viric> (introducing latencies to more priority processes) [00:05:03 CEST] <viric> you may think that +8% in x264 encoding is not worth it. :) But you can always play with affinity and enabling/disabling cpus - no need to reboot and run *always* without HT. [00:05:21 CEST] <furq> i absolutely think that's worth it [00:06:46 CEST] <viric> as for my notebook, that increase of throughput is noticeable in temperature as well, HT vs no-HT [00:13:43 CEST] <viric> I think I read that the linux scheduler has a "balancer" that is aware of HT, and tries to keep heavy cpu tasks in separate cores as possible [00:14:25 CEST] <viric> But I think this does not apply to tasks that require small amounts of cpu, so these may have a penalty under HT-enabled cores [01:39:49 CEST] <klaxa> i'm surprised people suggest to turn off HT, iirc, it's basically an extra set of registers for the cpu to make instant context switches, right? [01:43:35 CEST] <klaxa> shouldn't it always improve performance? i guess it's not that easy, is it? :P [01:45:59 CEST] <furq> the people i've seen say it sucks are all running 32+ core xeon systems [01:49:47 CEST] <klaxa> i see [01:50:46 CEST] <furq> https://www.researchgate.net/publication/267242498_An_Empirical_Study_of_Hy… [01:50:52 CEST] <furq> that seems more well-balanced [01:51:24 CEST] <klaxa> oh, nice thanks [01:52:05 CEST] <furq> actually nvm that's from 2002 [01:52:24 CEST] <klaxa> alight, my claim that it always increases performance is disputed in the abstract: >The characteristics of application run on a cluster will determine whether Hyper-Threading will help or hinder performance. [01:52:42 CEST] <klaxa> i would guess that still holds true in 2016 though? [01:52:50 CEST] <furq> i would assume so [01:53:40 CEST] <klaxa> ok, so on wikipedia it says intel shipped the first xeons with HT in feburary 2002 and this paper is from january 2002? [01:54:12 CEST] <furq> nice [01:54:23 CEST] <furq> maybe they were using engineering samples [01:55:03 CEST] <kepstin> iirc, the purpose of HT is to improve throughput by having a core be able to run another thread immediately when it's stalled on e.g. a memory access or branch mispredict? [01:55:15 CEST] <furq> https://www.nas.nasa.gov/assets/pdf/papers/saini_s_impact_hyper_threading_2… [01:55:18 CEST] <furq> that one's from 2011 [01:57:34 CEST] <DHE> klaxa: if you don't need the extra threads, the CPU can do better branch prediction using the second thread with HT off [01:58:32 CEST] <DHE> the branch can run BOTH directions through the execution pipeline while waiting on the result of the branch condition, and then abort the thread that turns out to be wrong [01:59:35 CEST] <klaxa> ooh, that sounds smart [01:59:46 CEST] <klaxa> and with HT enabled i take that away? [02:00:00 CEST] <klaxa> because it can only execute one branch per logical cpu [02:00:13 CEST] <klaxa> did i get that right? [02:01:38 CEST] <DHE> I don't know the specifics. my guess would be that the second thread would be executing a kernel idle thread running the `hlt` instruction and as such not available for work [02:02:47 CEST] <kepstin> in most cases the kernel would have told the extra HT virtual core to go into C1 state, and the cpu is responsible for deciding what that means :/ [02:02:51 CEST] <DHE> but based on perf executions, CPU branch prediction is actually really good, so the benefits on this probably won't outweigh the advantage of a second thread if you have enough running processes to take advantage of it [02:03:44 CEST] <DHE> if I have a 4-core CPU and expect to run more than OS 5 threads at once, hyperthreading is probably going to be a better choice [02:03:54 CEST] <DHE> unless this PDF has a graph that says otherwise. :) [02:04:38 CEST] <kepstin> this nasa pdf has a page showing that applications making heavy use of vector instructions (sse2) tend to not be better with HT [02:04:44 CEST] <kepstin> but that's on nehalem [02:05:59 CEST] <DHE> makes sense. the instructions would monopolize the FPU and the threads contend for it. [02:06:53 CEST] <kepstin> I could see some issues with applications running threads with disjoint working sets bigger than cache; each would effectively get 1/2 the cache of a real core [02:07:22 CEST] <kepstin> or it might be enough to tip a thread from fitting in cache to no longer fitting in cache :/ [02:07:54 CEST] <DHE> true. the L1 and L2 caches are shared. I would argue that the L3 cache would see contention equal to multi-core contention instead, so it's not quite as bad as going to the main memory [02:08:42 CEST] <DHE> and an HT aware scheduler should keep the processes on distinct cores before sharing threads, so in this scenario, the system is already busy. right? [02:09:20 CEST] <kepstin> sure, but running e.g. 2 threads on a 2-core box vs 4 on a 2-core-ht box means more threads are trying to fit in cache at a time [02:09:22 CEST] Action: DHE is intentionally poking at the scenario to make sure he's not making any mistakes either [05:02:15 CEST] <Kakashi> hello [05:02:16 CEST] <Kakashi> http://pastebin.com/jaHJK8Tj [05:02:31 CEST] <Kakashi> would this be handled internally at 32-bit floating point? [05:22:47 CEST] <Kakashi> http://pastebin.com/mjcVLS53 << I changed it. [09:39:31 CEST] <Spring> does MSI Afterburner come with x264 as part of the install? I can't remember. [09:41:11 CEST] <Spring> apparently not [12:28:43 CEST] <TheHackOps> Does ffmpeg support GPU encoding? [12:29:05 CEST] <JEEB> it supports both intel and nvidia's ASIC encoders, yes [12:40:14 CEST] <Spring> what about AMD? [12:41:45 CEST] <JEEB> do they have any sane APIs :P [12:45:26 CEST] <__jack__> AMD : do they have any sane <whatever> ? :) [12:50:11 CEST] <furq> Spring: apparently it "kind of works a bit" through vaapi [12:50:39 CEST] <furq> so not really, but i guess maybe soon [12:51:17 CEST] <Spring> it should be a significant different between a CPU and GPU encode, no? [12:51:32 CEST] <furq> different how [12:51:44 CEST] <Spring> in terms of speed [12:51:52 CEST] <furq> not really [12:51:52 CEST] <JEEB> well, it's a completely different encoder for a format [12:52:03 CEST] <JEEB> so in that sense you have to test it separately just like any other encoder [12:52:11 CEST] <furq> the idea with the consumer ones is that it doesn't hit your cpu [12:52:22 CEST] <furq> so you can live stream yourself getting sniped by russian hackers in battlefield 4 [12:52:34 CEST] <JEEB> you can't go "encoder X was great for format Y, so encoder Z is too" [12:52:37 CEST] <JEEB> furq: yup [12:52:47 CEST] <JEEB> the nvidia private screencap API is pretty neat too [12:52:59 CEST] <JEEB> + they support lossless encoding now which is neat [12:53:16 CEST] <Spring> is that part of their ShadowPlay offering? [12:53:26 CEST] <JEEB> (note: they are trying to keep the screencap API private so ffmpeg can't do it for ObviousReasons) [12:53:45 CEST] <JEEB> (someone pleasantly just posted some code #elsewhere for it and I was ReallyHappy) [12:54:43 CEST] <furq> but yeah the quality of the hardware h264 encoders is somewhere between x264 ultrafast and superfast [12:55:11 CEST] <bencoh> and with more artefacts [12:55:14 CEST] <Spring> as I've found ShadowPlay to handle captures very well with higher compression, moreso than Afterburner. However the downside is the lack of advanced settings that Afterburner provides via custom codec settings [12:55:21 CEST] <furq> which you should be getting >100fps at on any decent cpu [12:55:34 CEST] <JEEB> Spring: basically the API that steam uses with 900 series f.ex. [12:55:44 CEST] <JEEB> they are licensing the private API [12:55:52 CEST] <JEEB> if you don't support it, they will be using libx264 [12:56:01 CEST] <JEEB> (they license libx264 with the corp license) [12:56:06 CEST] <Spring> Steam has a video capture functionality? [12:56:10 CEST] <JEEB> yes? [12:56:15 CEST] <Spring> what [12:56:19 CEST] Action: Spring googles [12:56:21 CEST] <JEEB> they even have game streaming [12:56:28 CEST] <Spring> yeah, I know that bit [12:56:29 CEST] <JEEB> and people can ask to watch your gameplay [12:58:27 CEST] <Spring> can't find details that it has a capture functionality [12:59:09 CEST] <Spring> according to some posts you can't control when to broadcast, it's when others choose to watch that it initiates [12:59:10 CEST] <JEEB> well it most certainly has the functionality. it doesn't let you save it or stream it to !steam of course [13:01:19 CEST] <Spring> in my testing Afterburner can be configured to capture better quality than ShadowPlay at the expense of a slightly greater FPS hit. ShadowPlay is quite miraculous with how minimal the fps hit is. [13:01:58 CEST] <furq> well yeah that's the whole point [13:02:21 CEST] <JEEB> yeah, the private API keeps everything on the GPU [13:02:25 CEST] <JEEB> capture to encode [13:02:33 CEST] <JEEB> so it just writes the bit stream to a file, basically [13:02:38 CEST] <Spring> if the quality could be increased and filesizes reduced I'd probably use it all the time [13:02:55 CEST] <Spring> as it is all that's exposed are some simple sliders [13:03:19 CEST] <JEEB> I think the API lets you tweak things but I haven't looked at that C file for a while now [13:03:19 CEST] <Spring> 'Average' to 'best' quality or whatever [13:03:32 CEST] <furq> for a given definition of "best" [13:04:32 CEST] <Spring> with Afterburner I can punch in that I want CRF 23 and voila. Been finding it captures frames out of sequence recently however. [13:05:07 CEST] <Spring> been meaning to test ffmpeg's shuffle frames filter [13:05:53 CEST] <furq> /demo_capture for life [13:08:14 CEST] <t0mm3k> hi everybody ... is someone here who can help me with a simple ffmpeg problem (from user perspective)? [13:12:04 CEST] <t0mm3k> I have a webcam that sends raw (yuyv422) and mjpeg streams. I would like to capture the mjpeg stream via ffmpeg and pipe it via stdout to netcat. then on the other side, there should be a ffplay instance, that plays that stream from netcat. I already managed to do this, but only with a delay of ~30sec. I want it to be like <1s (as short as possible). [13:18:20 CEST] <t0mm3k> my current approach: ffmpeg -f v4l2 -r 30 -s 640x480 -input_format mjpeg -i /dev/video0 -f h264 pipe:1 | ffplay -f h264 -i pipe:1 [13:22:31 CEST] <sfan5> t0mm3k: using ffmpeg -i /dev/video0 -c copy -f nut - | nc -l 1234 and nc 127.0.0.1 1234 | ffplay - i get about 4 seconds of delay [13:24:14 CEST] <t0mm3k> @sfan5: hey sfan5, thanks for that quick response. unfortunately 4s is still to long. what causes that high delay? I thought i might be able to get sth around 250-500ms ?! [13:24:37 CEST] <sfan5> i have no idea [13:25:58 CEST] <sfan5> my guess would be that ffmpeg and/or ffplay keep a buffer before encoding/playing [13:26:20 CEST] <furq> ffplay -fflags nobuffer [13:30:51 CEST] <t0mm3k> hm ... thanks furq. already better, but still a delay of ~3s [13:31:40 CEST] <durandal_1707> ffplay is toy [13:31:55 CEST] <durandal_1707> use something else [13:32:49 CEST] <Spring> DivX certainly went the way of the dodo [13:32:59 CEST] <t0mm3k> i already tried mplayer ... still no good results yet :-( [13:34:10 CEST] <durandal_1707> It will buffer frames, check mplayer manual [13:34:55 CEST] <t0mm3k> ok i will ... what kind of player can you recommend? [13:34:57 CEST] <JEEB> Spring: well they got a successful buy-out after buying mainconcept with whatever funds they had [13:35:26 CEST] <JEEB> and I think they're still kind of alive now under another owner [13:35:33 CEST] <durandal_1707> what happened? [13:35:57 CEST] <Spring> remember when it was the the ripper hotness... and then h.264 become the de facto format [13:36:10 CEST] <JEEB> well they first got bought by rovi, and then by some sports-streaming company [13:36:15 CEST] <Spring> always felt dirty [13:36:16 CEST] <furq> there's a good few years of xvid in the middle of that timeline [13:36:28 CEST] <Spring> yeah, I used xvid [13:37:00 CEST] <furq> i still have a lamentable amount of xvid [13:37:15 CEST] <Spring> the artifacts were annoying though [13:37:18 CEST] <bencoh> same, sitting around somewhere [13:37:33 CEST] <bencoh> every video format has "artifcats" [13:37:43 CEST] <JEEB> last I dealt with divx folk was in '13 I think, when HEVC in matroska was specified (and they tried to do it their way at first, and I then posted stuff from the mpeg-4 part 15 draft to not create a drift between the two) [13:37:50 CEST] <Spring> yeah but these were 'crunchy' JPEG-like ones [13:38:43 CEST] <bencoh> h264 doesn't look that better when bitstarved ... but it's easier to bitstarve xvid than h264, that's all :) [13:38:58 CEST] <JEEB> well the in-loop deblocking does help [13:39:04 CEST] <bencoh> true [13:39:06 CEST] <JEEB> which mpeg-4 part 2 didn't have for whatever reason [13:39:12 CEST] <JEEB> while the thing it based on did have it [13:39:15 CEST] <JEEB> (H.263) [13:39:22 CEST] <furq> especially when you're trying to fit it onto a cd-r even though nobody has used cd-rs for ten years [13:39:38 CEST] <bencoh> furq: :)) [13:39:42 CEST] <furq> except to burn dreamcast games obviously [13:40:40 CEST] <furq> that must be the only thing keeping the cd-r industry afloat these days [13:40:43 CEST] <Spring> at the time I looked at comparison encodes of xvid vs h.264 and the deblocking helped immensely. Didn't have a powerful enough system to rip to it though :p [13:41:30 CEST] <JEEB> yeah, I think the deblocking and CABAC are the two main reasons why we saw such a difference between MPEG-4 Part 2 (the spec that divx and xvid used) and AVC [13:41:42 CEST] <JEEB> and partially why it's harder to now get similar results from HEVC against AVC [13:42:05 CEST] <furq> but x265 is 50% better than x264. i read it on the internet [13:42:20 CEST] <JEEB> you mean HEVC and AVC, and that's theoretical [13:42:22 CEST] <furq> also have you heard about this one weird trick that doctors hate me for [13:42:35 CEST] <JEEB> I mean, tested with HM and so forth but it's still theoretical [13:43:07 CEST] <furq> thank you for displaying so much confidence in my intelligence [13:43:09 CEST] <JEEB> you have to let actually usable encoders get somewhere to get even somewhere close to that [13:43:21 CEST] <bencoh> JEEB: think furq forgot his sarcasm sign at home ;) [13:43:28 CEST] <bencoh> +I [13:43:29 CEST] <JEEB> I'm pretty sure he was facetious [13:43:37 CEST] <furq> how are you only pretty sure [13:43:47 CEST] <bencoh> :) [13:43:48 CEST] <JEEB> but I'm just replying as usual :P [14:53:20 CEST] <DaVu> Hello....I would relly appreciate if someone is able to give a ffmpeg-newcomer a little bit [14:54:14 CEST] <DaVu> I have a m2ts file which contains 3 different audio tracks (DTS-MA, DTS-HRA, AC3) and I want a 60 second snippet from that file with all audio tracks [14:54:50 CEST] <DaVu> ffmpeg -i input.m2ts -map 0 -t 60 out.m2ts only gives a single audio track [14:55:10 CEST] <JEEB> it shouldn't, but with MPEG-TS there's one useful thing [14:55:11 CEST] <DaVu> and I'm a bit stuck now [14:55:15 CEST] <JEEB> you can cut it with dd :P [14:55:30 CEST] <DaVu> could you tell me how, please? [14:55:43 CEST] <JEEB> so you just dd if=input.m2ts bs=1M count=ENOUGH_MEGABYTES_FOR_YOU of=output.m2ts [14:55:56 CEST] <DaVu> really? that simple [14:55:58 CEST] <JEEB> yes [14:56:06 CEST] <DaVu> ok, i'll try. Thanks a bunch [14:56:18 CEST] <JEEB> and the best part is that you'd be providing the sample as-is, not remuxed [14:56:28 CEST] <DaVu> indeed [14:56:41 CEST] <DaVu> that's the point and what is absolutely needed [14:57:24 CEST] <JEEB> mpeg-ts was originally meant for broadcast so you can just cut it. as long as your cut includes enough stuff it's decode'able [14:57:34 CEST] <DaVu> so: count=25 gives me 25MB? [14:57:37 CEST] <JEEB> yup [15:00:48 CEST] <DaVu> thanks, that works. But the ffmpeg command above should have worked, too normally? [15:01:41 CEST] <JEEB> yes, -map 0 is correct for mapping in all streams from input [15:01:51 CEST] <DaVu> hm...strange [15:01:53 CEST] <JEEB> if you just do `ffmpeg -i input.m2ts` does it list all tracks? [15:03:26 CEST] <DHE> m2ts is what all the over-the-air tv stations use. it's join-anywhere compatible and all that. [15:03:49 CEST] <JEEB> well when talking about m2ts that's usually the 192 byte one :) [15:03:51 CEST] <DaVu> http://pastebin.com/QCJLZNmt [15:04:18 CEST] <JEEB> well that it seems to do [15:04:30 CEST] <DHE> 188 for what I"ve seen. or is there another spec I don't know about? [15:04:48 CEST] <JEEB> DHE: 188 for broadcast, blu-ray uses 4 extra bytes for timestamps I think? [15:05:01 CEST] <JEEB> then there's 204 byte stuff for extra checksums? [15:05:11 CEST] <furq> DHE: https://en.wikipedia.org/wiki/.m2ts [15:05:30 CEST] <DHE> JEEB: m2ts includes timestamps in both the adaptation header and the PES themselves. odd that would be needed [15:05:46 CEST] Action: DHE wrote a simple de/remuxer so he knows the format fairly well... [15:05:54 CEST] <JEEB> yeah, I know there's the 90kHz stuff in there :) [15:06:09 CEST] <JEEB> "The header consists of a 2-bit copy permission indicator and the 30-bit arrival timestamp with a resolution of 27 MHz." [15:06:17 CEST] <JEEB> don't ask me why but that's what they have :) [15:06:47 CEST] <JEEB> the stuff after 0x47 is still the same so you are able ot handle the files with a "normal" MPEG-TS parser as well [15:06:53 CEST] <DaVu> JEEB: this is what I get after the commmand above: http://pastebin.com/khZXB7Kn [15:07:28 CEST] <JEEB> DaVu: everything else seems fine except the fact that you forgot to specify -c copy [15:07:38 CEST] <DaVu> aaaah [15:07:48 CEST] <bencoh> "ooops" :) [15:07:50 CEST] <JEEB> you can see the stream mapping in the end :P [15:08:00 CEST] <DaVu> so: ffmpeg -i 00000.m2ts -map 0 -t 60 -c copy out2.m2ts [15:08:01 CEST] <DHE> the adaptation header's PCR value is already a 27 MHz clock source with more bits than 30. seems superfluous to me, but I guess they wanted to make it extra-easy to do time seeking. [15:08:15 CEST] <JEEB> yeah [15:08:22 CEST] <JEEB> DaVu: puh-ret-teh much [15:08:22 CEST] <DaVu> ok, I 'll try [15:08:25 CEST] <JEEB> but that's remuxing [15:08:36 CEST] <JEEB> so it's better to do samples with dd when you can [15:08:57 CEST] <DaVu> yes, but I need to upload the file and 100MB are about 25 seconds of the whole video [15:09:06 CEST] <DaVu> I don't cate about the video quality [15:09:14 CEST] <DaVu> it's the audio track we need to test [15:09:17 CEST] <JEEB> then just do -map 0:a [15:09:26 CEST] <JEEB> or write something to filter packets out of the video track :) [15:09:38 CEST] <DaVu> I did this, but then I get 3 audio streams all in stereo [15:09:39 CEST] <JEEB> (I mean, on MPEG-TS level) [15:09:48 CEST] <JEEB> DaVu: with -c copy? [15:09:55 CEST] <DaVu> think so [15:09:58 CEST] <JEEB> with re-encode of course it will do all that automagics [15:09:59 CEST] <DaVu> but will try again [15:11:23 CEST] <DaVu> JEEB: http://pastebin.com/snWuguXr [15:11:33 CEST] <DaVu> correct so far? [15:11:46 CEST] <JEEB> so far yes, remuxed by libavformat of course [15:12:07 CEST] <DaVu> with vlc I see only a single audio track [15:12:39 CEST] <JEEB> what does `ffmpeg -i out12.m2ts` say? [15:12:43 CEST] <JEEB> or mpv [15:12:54 CEST] <JEEB> also wouldn't be surprised if your VLC is just old :) [15:13:07 CEST] <JEEB> (v3 has been very long in the cooking) [15:15:59 CEST] <DaVu> JEEB: http://pastebin.com/nLqS4wHg [15:16:17 CEST] <JEEB> well there you have them streams at least [15:16:23 CEST] <DaVu> yes, I see [15:16:25 CEST] <DaVu> hmmm [15:16:58 CEST] <JEEB> I'm not gonna say that libavformat's mpeg-ts muxer is too great of course ;) but to see why VLC would fail would require stuff that I'm not willing to do [15:19:11 CEST] <DaVu> I have it working...maybe an issue with VLC, Kodi shows the correct streams [15:19:14 CEST] <DaVu> thanks much [16:04:08 CEST] <edfoxx> Hello, i'm having an issue with "showwavespic" [16:04:27 CEST] <edfoxx> No matter what i do, the waveform always appears of a brown color [16:04:35 CEST] <edfoxx> "ffmpeg -i test.mp3 -filter_complex "showwavespic=s=640x120" -frames:v 1 output.png" [16:04:53 CEST] <edfoxx> While on the website it showed a white waveform when that command was used [16:31:54 CEST] <c_14> showwavespic=s=640x120:colors=white [16:40:20 CEST] <edfoxx> Let me try [16:40:58 CEST] <edfoxx> Yay it works [17:15:03 CEST] <agrathwohl> Hey guys. I am very fortunate to have run into some unexpected funding, so just for fun I'd like to build a headless GPU video processing server with lots of CUDA cores. I will mainly be using FFmpeg and vapoursynth on this server. I have picked out my hardware but have not yet figured out what OS to use. Would FreeBSD be a bad choice? Gentoo? CentOS? [17:20:19 CEST] <furq> is cuda natively supported on freebsd yet [17:22:12 CEST] <Mavrik> Is using GPUs for that even sensible? Xeons usually behave better. [17:22:22 CEST] <Mavrik> agrathwohl, use something widely supported and used on servers. [17:22:31 CEST] <Mavrik> So you'll have proper support when you have issues. [17:22:34 CEST] <furq> i assume he's using it for filtering, which it sometimes makes sense for [17:22:35 CEST] <Mavrik> CentOS, Debian, Ubuntu, etc. [17:22:49 CEST] <JEEB> I'd probably go for ubuntu 16.04 to have non-ancient components but still LTS [17:22:56 CEST] <JEEB> unless you enjoy building python etc yourself [17:23:17 CEST] <furq> why would you use an lts release "just for fun" [17:23:37 CEST] <c_14> I'd check for distros with up to date GPU drivers. [17:23:38 CEST] <Mavrik> Yeah, Ubuntu 16.04 or Debian Stable would be my choice as well. [17:23:54 CEST] <JEEB> debian sta(b)le usually tends to be a wee bit too old for my liking [17:23:59 CEST] <furq> debian testing is generally less hassle for a headless box [17:24:00 CEST] <Mavrik> Ubuntu 16.04 more probably, since there are PPAs with new nvidia drivers. [17:24:17 CEST] <JEEB> well ubuntu also seems to be updating their drivers every few months [17:24:37 CEST] <JEEB> agrathwohl: I guess you did some development with vapoursynth? [17:24:52 CEST] <JEEB> since I don't strictly remember many filters doing GPU work publicly [17:25:34 CEST] <furq> knlmeanscl is pretty nice [17:25:41 CEST] <furq> i've not had cause to use anything else [17:27:55 CEST] <furq> it looks like cuda still isn't supported on freebsd without using the linux emulation [17:28:07 CEST] <furq> and even then it's a nightmare to get it to work [17:28:49 CEST] <furq> opencl works fine obviously [17:38:10 CEST] <agrathwohl> furq JEEB Mavrik thanks so much for your help [17:38:33 CEST] <agrathwohl> I think Ubuntu Server makes sense [17:39:04 CEST] <agrathwohl> i just have had bad experiences with their PPAs in the past, especially for FFmpeg (when they chose to go with libav and all that) [17:39:22 CEST] <Mavrik> You shouldn't ever install ffmpeg from repos :) [17:39:33 CEST] <JEEB> that's why most people who actually handle this daily don't really use PPAs [17:39:49 CEST] <agrathwohl> JEEB I do handle this daily, and build the nightlies every day for my day job :) [17:40:17 CEST] <furq> a good rule to live by is to never use PPAs ever [17:40:36 CEST] <agrathwohl> But since FFmpeg is such a common dep for other apps I find that even when doing innocent things with PPAs it can cause problems for custom FFmpeg builds [17:40:41 CEST] <furq> they rank somewhere between crystal meth and heroin in a list of things to avoid using [17:41:00 CEST] <agrathwohl> LOL noted! :D [17:41:03 CEST] <Mavrik> agrathwohl, yes, we use fully static builds of ffmpeg because of that. [17:41:14 CEST] <Mavrik> Which can then be directly deployed to any kind of machine. [17:41:23 CEST] <Mavrik> And don't get messed up by what distros do :P [17:41:51 CEST] <furq> debian's ffmpeg is pretty much fine now [17:42:01 CEST] <furq> although now i've said that they'll probably remove everything good from it [17:42:08 CEST] <Mavrik> ^^ [17:42:22 CEST] <Mavrik> Isn't docker now end-all of any kind of ops and the holy grail? [17:42:23 CEST] <agrathwohl> I have been using CentOS on production FFmpeg servers for my day job -- is this considerably less ideal than an Ubuntu setup? [17:43:03 CEST] <furq> if you want to install binary packages which aren't a million years old then RHEL/centos are less than ideal [17:43:40 CEST] <agrathwohl> furq noted! :D thanks [17:44:09 CEST] <furq> if you want an up-to-date rolling release then debian testing is great [17:44:27 CEST] <furq> ubuntu seems to have sorted out a lot of the bullshit that turned me off it though [17:45:31 CEST] <JEEB> centos/RHEL are pretty much "what comes in the package is old as hell so if you need something newer you build *everything* yourself" [17:45:49 CEST] <JEEB> I think RHEL does get some development packages so you can get newer toolchains etc tho [17:46:13 CEST] <agrathwohl> hmm.. looks like I'll be investigating whether I go with Debian testing or Ubuntu [17:46:21 CEST] <furq> there's no real compelling reason to use them for personal use though [17:47:45 CEST] <agrathwohl> How about Gentoo - out of the question? [17:48:01 CEST] <JEEB> if you enjoy maintaining it, sure [17:48:08 CEST] <agrathwohl> I really like the idea of USE flags for bleeding edge media work [17:49:07 CEST] <furq> does that get you any advantage that --enable-runtime-cpudetect doesn't [17:49:32 CEST] <JEEB> build-time optimizations don't really help you with FFmpeg [17:49:39 CEST] <JEEB> unless you start experimenting by overriding what the configure sets [17:49:51 CEST] <JEEB> because it f.ex. currently disables vectorization [17:49:55 CEST] <furq> all the popular codecs these days support runtime cpu detection as well [17:50:19 CEST] <JEEB> yeah, since you don't want to break the C code path users and checking for CPU capabilities isn't hard [17:50:22 CEST] <furq> and you'll be compiling all your vapoursynth plugins yourself anyway [17:50:24 CEST] <agrathwohl> great points. you guys are so helpful, really appreciate this insight. [17:50:51 CEST] <furq> so the only bit of the pipeline which benefits is python [17:51:01 CEST] <JEEB> does it? [17:51:03 CEST] <furq> and i don't think python will stop being slow as fuck because you have AVX2 [17:51:40 CEST] <furq> JEEB: in theory, obviously [17:51:44 CEST] <JEEB> :) [17:52:20 CEST] <JEEB> yeah, our HEVC decoder wouldn't be as slow if compilers were perfect at optimizing our code to what we think it should do [17:52:41 CEST] <JEEB> (let's ignore for a moment that we globally disable autovectorization) [17:53:02 CEST] <furq> i do wonder if that luajit fork of vapoursynth would be noticeably faster [17:53:15 CEST] <JEEB> so much of it is done natively that most probably not [17:53:17 CEST] <furq> probably not enough to bother putting any work into it [18:10:00 CEST] <Mavrik> JEEB, why is vectorization disabled anyway? [18:10:10 CEST] <Mavrik> Bad compiler versions? [18:11:14 CEST] <iive> yes, all of them [18:11:14 CEST] <JEEB> yeah, there's been cases of miscompilation and everyone doesn't want that to happen again [18:11:40 CEST] <JEEB> I'm pretty sure FATE passes even with optimizations on in many cases [18:11:48 CEST] <JEEB> but then there's the bad apples :) [18:12:19 CEST] <iive> vectorization was enabled for a while, but then came bugreports... so that was reverted. [18:13:16 CEST] <JEEB> I think those were some old cases or specific ones, not sure how many we actually got [18:13:41 CEST] <bencoh> were there any real significant benefit anyway? [18:13:55 CEST] <JEEB> for those parts where there's less manual optimizations yes [18:14:08 CEST] <JEEB> where stuff was mostly done with SIMD, nope [18:14:50 CEST] <bencoh> yeah but ... isn't most of the really important/critical stuff already handwritten in SIMD? [18:14:52 CEST] <Mavrik> That stuff is ASM and untouched anyway right? :) [18:14:57 CEST] <bencoh> Mavrik: right [18:15:06 CEST] <JEEB> bencoh: well try stuff like HEVC decoding [18:15:11 CEST] <Mavrik> Is there any preceptible difference between clang and gcc atm? [18:15:15 CEST] <JEEB> IIRC that had some effect because of the lack of optimization [18:15:15 CEST] <bencoh> haven't tried for a while : [18:15:17 CEST] <bencoh> :) [18:15:42 CEST] <JEEB> Mavrik: it really depends on what you're going to use, but at least clang doesn't miscompile any more [18:16:01 CEST] <JEEB> I would have been interested of any benchmarks on FFmpeg on ARMv7 with GCC | clang 3.8 [18:16:07 CEST] <JEEB> since GOOG's toolchain is pushing for clang [18:17:03 CEST] <JEEB> when you google for benchmarks you generally find phoronix's benchmarks which don't contain FFmpeg and are mostly x86_64 [18:17:09 CEST] <Mavrik> Yeah, wonder just how bad clangs ARM generator is [18:17:31 CEST] <JEEB> the last armv7 one I found was for clang 3.0 which is by now ancient [18:53:30 CEST] <krystalkay> is this a good place to ask about advice for a streaming setup i want to try with ffmpeg and nginx? [18:54:12 CEST] <klaxa> it certainly isn't the worst place to ask [18:54:57 CEST] <krystalkay> i basically have an nginx server with the rtmp module installed, videos saved locally on the server, and i want to stream a local video to my rtmp server in a way that everybody can see the stream and everybody can control playback of the video [18:55:57 CEST] <krystalkay> i have it set up with nginx already so that someone can broadcast to that rtmp server and everyone can see it, but the hurdle now is having the playback of the video originating from my server, and having that playback be able to be controlled by someone [18:56:36 CEST] <krystalkay> i've got ffmpeg working so that it can basically transcode a local video and output it in flv format to the rtmp server, so in that sense the local video in the server is streaming to everybody [18:57:01 CEST] <krystalkay> but the catch of course is that you can't really "seek" ffmpeg that way so nobody would be able to pause, rewind, forward, etc. [18:57:38 CEST] <krystalkay> anybody have any ideas on how to basically just playback a video and stream it to the rtmp server, and have that be controlled? maybe ffmpeg isn't the right approach or it isn't the full approach [18:59:06 CEST] <furq> are they controlling playback for themselves or for everybody [18:59:27 CEST] <krystalkay> for everybody [19:00:13 CEST] <krystalkay> could one approach be to create a program that plays a local video and outputs it to a fake video device, and have ffmpeg just grab+transcode+stream from that device to the stream? [19:00:25 CEST] <krystalkay> and that way the program can be controlled [19:06:04 CEST] <krystalkay> think that may work, i'll give it a try [19:27:38 CEST] <brontosaurusrex> hello, what is the latest statuc with 10bit encoding (x264), do i still need a separated build? [19:27:42 CEST] <brontosaurusrex> status* [19:27:52 CEST] <JEEB> yes [19:28:43 CEST] <brontosaurusrex> And that is due to x264 right? [19:28:47 CEST] <DHE> x264 is built with only one bit depth supported, so you have to choose one and compile it. that's not likely to change soon [19:32:21 CEST] <brontosaurusrex> so https://www.johnvansickle.com/ffmpeg/ < the one that says ffmpeg-10bit is probably what i want? [19:33:14 CEST] <DHE> sounds right [19:49:09 CEST] <brontosaurusrex> Do I want -pix_fmt yuv444p ? [19:52:18 CEST] <BtbN> how should we know what you want? [19:54:35 CEST] <DHE> people who want 10bit usually know what their needs are. 8bit is most common [19:55:24 CEST] <brontosaurusrex> I don't really, just trying to figure this out if i ever decide that would be my backup format [00:00:00 CEST] --- Mon Aug 29 2016

1 0

ffmpeg-devel.log.20160827
by burek 28 Aug '16

28 Aug '16

[00:19:59 CEST] <nevcairiel> Its still useful if you just know which fail [00:20:02 CEST] <nevcairiel> It's not many [00:22:33 CEST] <nevcairiel> I have considered somehow hooking up a fate station that tests this, but my fate box is virtual so no GPU [00:33:58 CEST] <durandal_1707> will add copy mode to metadata filter [00:35:46 CEST] <durandal_1707> hmm, does anyone get infinite loop with: ffmpeg -h full? [00:36:08 CEST] <nevcairiel> That usually means two things share the same avclass [02:05:15 CEST] <cone-688> ffmpeg 03Michael Niedermayer 07master:c75273310cf1: avformat/utils: End probing if the expected codec surpasses AVPROBE_SCORE_STREAM_RETRY [07:47:16 CEST] <DSM___> michaelni: issue seems to be fixed [13:12:43 CEST] <cone-248> ffmpeg 03Vittorio Giovara 07master:6648da359114: vf_colorspace: Check av_frame_copy_props() return value [13:12:43 CEST] <cone-248> ffmpeg 03Vittorio Giovara 07master:69abf4f93cb6: vf_colorspace: Add support for full range yuv [13:25:28 CEST] <BtbN> Great. Nvidia put the NVENC SDK/Header behind a registration-wall. [13:25:33 CEST] <BtbN> Now I want to bundle it again. [13:27:15 CEST] <BtbN> But there now is VP9 decoding in there. [13:29:13 CEST] <JEEB> welp [13:34:08 CEST] <BtbN> And they have to acknowledge my access to the SDK. In a manual process. [13:39:08 CEST] <JEEB> that's basically a big middle finger kind of thing [13:39:25 CEST] <JEEB> since they freed it up for a while and now it's back to the old way [13:39:34 CEST] <BtbN> The header is still MIT licensed [13:40:03 CEST] <BtbN> Otherwise I'd have to reject the two patches on the ML... [13:41:07 CEST] <BtbN> https://developer.nvidia.com/nvidia-video-codec-sdk <- they even advertise FFmpeg [13:48:10 CEST] <cone-248> ffmpeg 03Paul B Mahol 07master:b2c6a11fb604: avfilter/vf_atadenoise: add planes option [13:50:27 CEST] <BtbN> michaelni, https://patchwork.ffmpeg.org/patch/270/ it doesn't exactly handle those kind of attached patches well. [14:49:36 CEST] <RiCON> BtbN: if you only need nvencodeapi.h you can also get it here: https://github.com/jb-alvarado/media-autobuild_suite/blob/gh-pages/extras/n… [14:50:04 CEST] <BtbN> The registration was accepted already [14:50:13 CEST] <BtbN> took them "only" an hour. [14:50:41 CEST] <BtbN> Preparing a patch to bundle the header with ffmpeg. [16:14:40 CEST] <cone-248> ffmpeg 03Paul B Mahol 07master:f242d74d170e: avfilter/vf_convolution: add >8 bit depth support [16:22:26 CEST] <cone-248> ffmpeg 03James Almer 07master:dc7e5adbc086: avformat/utils: fix a codecpar non use [17:42:57 CEST] <atomnuker> can someone take a look at the MLP encoder? [17:43:10 CEST] <atomnuker> the patch's been on the ML for a few days now [18:22:34 CEST] <BtbN> If I have a filter formula, that applies on RGB colors, can I just apply it unmodified to YUV, and it will work? [18:22:51 CEST] <nevcairiel> that depends entirely what it does [18:23:16 CEST] <BtbN> remove color-spill for greenscreens and stuff [18:34:25 CEST] <BtbN> resR = clamp(R - keyR + (R+G+B)/3, 0.0, 1.0)*intensity + R*(1-intensity) [19:43:15 CEST] <kierank> is there an idiom for rounding down to the nearest multiple [19:43:24 CEST] <kierank> i.e the opposite to (x+n-1)/n [19:43:37 CEST] <kierank> oh bah [19:43:45 CEST] <kierank> (x / n) * n [19:49:31 CEST] <DHE> I have a minipatch I'd like feedback on: https://github.com/DeHackEd/FFmpeg/commit/fad431cf451a [19:50:23 CEST] <DHE> The issue I have is that at 29.97fps, most reasonable hls_time values like 6 seconds will result in 6.006 second durations for the segment files, which the old code would round up to 7s [19:50:42 CEST] <DHE> and I have a specific player that has... uhh... issues when the error is relatively large [19:51:11 CEST] <JEEB> DHE: don't comment out code but rather remove it or add extra checks. also use spaces instead of tabs [19:51:27 CEST] <DHE> I mean from a purely conceptual standpoint. I know commenting out the old code isn't right. [19:51:51 CEST] <JEEB> also what did the time variable contain and when is it initialized or not initialized? [19:52:06 CEST] <DHE> it's set with -hls_time X and defaults to 2 [19:53:45 CEST] <DHE> the original problem (vendor-specific possibly) is that it assumes that the length of the segments are exactly what the target_duration is set to. when it's 6.006 and the file contains '7' the internal clock drifts pretty badly [19:54:05 CEST] <DHE> and according to the HLS spec it must be a whole integer. :/ [19:54:35 CEST] <JEEB> if you set it to six and your actual segment length is 6.006 that is actually out of spec I think though? [19:54:38 CEST] <JEEB> https://tools.ietf.org/html/draft-pantos-http-live-streaming-19#section-4.3… [19:55:14 CEST] <DHE> interesting, I must have misread that... [19:55:48 CEST] <DHE> well, damned if I do, damned if I don't... [19:57:00 CEST] <JEEB> and yeah, that means your thing you're poking is completely bonkers :P congratulations. I've had my own share of crappy vendors with other formats [19:58:05 CEST] <JEEB> but yeah, if you try to do something that's against the spec then most likely it isn't going to get merged [19:58:26 CEST] <DHE> -this one's funny. if you set a large hls_time for a live stream you can basically get pause-live-TV without needing storage on the player. but it's not using the timestamps to measure times, it just assumes every segment is the target duration length. [20:07:11 CEST] <DHE> bug report submitted. the spec wins [20:07:17 CEST] <DHE> to the player vendor I mean [20:07:27 CEST] <JEEB> hopefully it gets fixed [20:07:56 CEST] <JEEB> in my case sometimes the vendor would point at a completely different part of the spec (unrelated) or would say it would get fixed in the next model [20:08:48 CEST] <DHE> they've given me test firmwares for a couple of bugs I found. that's reassuring, but releases are infrequent... :/ [20:40:37 CEST] <michaelni> BtbN, i think attaching multiple patches per mail isnt supported in patchwork. If theres something that can be done about this, someone please tell me, but IIUC raz correctly, the way projects generally handle this is to reject such patches and ask for clean resubmission. Multiple patches per mail are also a bit annoying to deal with even without patchwork [21:12:12 CEST] Action: durandal_1707 wonders why is there dither in owdenoise [21:13:56 CEST] <durandal_1707> michaelni: I more interested in generic frame multithreading in lavfi [21:14:51 CEST] <DHE> as opposed to slice threading? [21:18:12 CEST] <durandal_1707> yes, unless there are clear benefits doing it other way around [21:18:45 CEST] <michaelni> <michaelni> durandal_1707, a filter could implement frame multitherading without any changes to avfilter core. It could be done throgh core with multiple filter instances filtering several frames at once, there are probably more options and i wonder if this wasnt discussed before on ML [21:19:01 CEST] <michaelni> i think you didnt see ^^ as you timedout after [21:24:13 CEST] <DHE> depends on the filters. some this could work (eg: scale) but some require processing of frames in order (eg: deinterlacers) [21:27:23 CEST] <michaelni> DHE filters like deinterlacers would need to syncrnize the different instances so none accesses something from a previous frame that hasnt been calculated yet. Its the same as wih P frames in video decoders, but slice multitreading might be easier [21:30:59 CEST] <DHE> in a "thinking out loud" way I'm wondering if there's some advantage to a work queue system for filters and/or decoders. I have some big ffmpeg jobs that end up creating hundreds of threads while running. I do have a lot of cores, but not THAT many. Could this help limit the number of threads needed? [21:31:19 CEST] <DHE> process ulimits do count threads, so that's a pretty big hit on systems where limits have not been configured. [21:37:00 CEST] <Timothy_Gu> BtbN: in case you are interested, I put all the MIT-licensed headers of the nvidia video codec sdk here: https://github.com/TimothyGu/nvidia-video-codec-sdk [21:37:22 CEST] <BtbN> there's more than one? [21:38:00 CEST] <BtbN> cuvid... interesting. [21:38:14 CEST] <BtbN> With that it could be made non-nonfree and bundled as well [21:38:33 CEST] <BtbN> wait, it needs dynlink_cuda.h as well [21:38:35 CEST] <BtbN> so, nevermind that [21:38:51 CEST] <Timothy_Gu> yeah. dynlink_cuda is nonfree [21:39:28 CEST] <Timothy_Gu> For a diff between 6.0 and 7.0 see https://github.com/TimothyGu/nvidia-video-codec-sdk/compare/v6.0...v7.0?w=1 [21:42:43 CEST] <DHE> hardware vp9 encoding is in the newest chips? [21:42:54 CEST] <BtbN> It's in Maxwell and Pascal [21:43:15 CEST] <BtbN> oh, _en_coding [21:43:20 CEST] <BtbN> I don't think that's in there at all [21:43:25 CEST] <BtbN> https://developer.nvidia.com/nvidia-video-codec-sdk <- has a feature matrix [21:43:44 CEST] <RiCON> vp9 is only on pascal, iirc [21:43:51 CEST] <durandal_1707> DHE: you got so many threads with lavfi or lavc? [21:43:59 CEST] <BtbN> RiCON, it's also marked on GM20x [21:44:22 CEST] <DHE> durandal_1707: both really. but lavfi seems to be the worst offender. x264 needs threads and I have multiple instances [21:44:24 CEST] <RiCON> oh, so 950/960 [21:44:35 CEST] <BtbN> All the 900 cards [21:44:52 CEST] <RiCON> right, hevc is the one that's only in those two [21:45:06 CEST] <BtbN> HEVC is exception ² [21:45:13 CEST] <Timothy_Gu> lol nvidia even lists ffmpeg as "Video Codec SDK In Action" [21:45:23 CEST] <BtbN> "Only GM206 in the Maxwell generation of GPUs supports hardware accelerated HEVC decoding" [21:45:27 CEST] <durandal_1707> DHE: what filters you use at same time? [21:45:49 CEST] <DHE> durandal_1707: yadif, split, and a scale on each split output [21:46:16 CEST] <RiCON> Timothy_Gu: they also use the nvresize patch [21:46:17 CEST] <DHE> durandal_1707: one thing of note is that this machine has 80 threads total, so there's a fairly strong bias to big numbers on everything [21:46:31 CEST] <durandal_1707> well, only yadif creates threads [21:46:54 CEST] <BtbN> RiCON, nope. They just link to ffmpeg org. [21:47:04 CEST] <BtbN> All the functionality of that nvresize stuff is in ffmpeg by now. [21:47:19 CEST] <RiCON> it is? [21:47:26 CEST] <RiCON> i remember it being refused [21:47:34 CEST] <BtbN> And propperly reimplemented [21:47:44 CEST] <Timothy_Gu> vf_scale_npp? [21:47:52 CEST] <BtbN> yes, and cuviddec, and CUDA frames [21:48:00 CEST] <BtbN> you can have a full decode, scale, encode chain with CUDA now. [21:48:32 CEST] <Timothy_Gu> oh cool [21:51:43 CEST] <durandal_1707> michaelni: why is number of slice threads global per graph, instead of per filter? [21:52:20 CEST] <durandal_1707> this is bad design [21:52:56 CEST] <DHE> this would require a central thread queue. which I don't think exists right now [21:53:29 CEST] <durandal_1707> what? [21:53:54 CEST] <durandal_1707> no, it can be controlled per filter [21:53:59 CEST] <DHE> is there? I don't recall seeing one. [21:54:26 CEST] <durandal_1707> because I have an idea [21:54:42 CEST] <DHE> oh, sure, I go looking closer and find it in 15 seconds... [23:14:34 CEST] <durandal_1707> michaelni: added posibilty for finer control of number of threads which Will be used [23:47:53 CEST] <durandal_1707> jamrial: so what you tried that does not work with transcode.c? [23:50:46 CEST] <jamrial> durandal_1707: try converting any mpeg2 or h264 file in and to avi/mp4. when i tested the resulting files had stutter [23:52:09 CEST] <jamrial> pre-patch h264 seems to fail with a "broken ffmpeg presets" error from libx264, though [23:52:44 CEST] <jamrial> probably because of avcodec_copy_context(), which is removed with this patch [23:55:19 CEST] <durandal_1707> who didn't filled evaluation? [00:00:00 CEST] --- Sun Aug 28 2016

1 0

ffmpeg.log.20160827
by burek 28 Aug '16

28 Aug '16

[00:00:09 CEST] <wallbroken> thank you [00:00:11 CEST] <iive> however if you don't have keyframes every second, the start might be a little off [00:00:52 CEST] <iive> depending on the duration of the keyframe interval. [00:01:40 CEST] <iive> if you want exact cut, you'd have to re encode. [00:02:16 CEST] <iive> aka, instead of -c copy, it would be -c:a copy -c:v libx264 [00:41:03 CEST] <wallbroken> [00:02] <iive> aka, instead of -c copy, it would be -c:a copy -c:v libx264 [00:41:04 CEST] <wallbroken> why? [00:43:00 CEST] <DHE> because 'copy' can only start from a keyframe. if you want to start from a non-keyframe you need to re-encode [00:43:50 CEST] <wallbroken> but if i'm lucky, the keyframe is near the cut point, right? [00:45:52 CEST] <DHE> no harm in trying. see how it turns out [02:08:03 CEST] <wallbroken> 32bit or 64bit? [02:09:17 CEST] <furq> the n64 is more powerful but the playstation has better games [02:09:36 CEST] <wallbroken> very fun [02:09:45 CEST] <furq> yes, they are very fun [02:31:03 CEST] <klaxa> n64 has smash bros. though [02:31:26 CEST] <klaxa> probably my favorite fighting game [02:41:20 CEST] <wallbroken> klaxa, sometime ago you told me a thing that it's not clear [02:41:55 CEST] <klaxa> if you can repeat what i said and tell what you didn't understand we can probably clear that up [02:42:15 CEST] <wallbroken> <klaxa> 32 bit will probably be unsupported earlier than 64 bit (just a guess) [02:42:21 CEST] <wallbroken> this is what you said [02:42:28 CEST] <wallbroken> and the question is: which would that mean? [02:42:52 CEST] <klaxa> i'm guessing that maybe 10 years from now everybody will be on 64-bit [02:43:20 CEST] <klaxa> but with all the guesses in computer science and technology in general i'm probably way off [02:43:58 CEST] <wallbroken> and so? where is the incompatibility? [02:44:22 CEST] <klaxa> non-existent, you will also be running 64-bit then :) [02:44:33 CEST] <wallbroken> are you talking about the compatibility of the executable or about the output file? [02:44:39 CEST] <klaxa> the executable [02:44:50 CEST] <klaxa> the file will still be compatible [02:45:38 CEST] <klaxa> there is not really a reason not to use 64-bit operating systems [02:46:17 CEST] <klaxa> i think there are some slight performance differences [02:46:28 CEST] <wallbroken> yes i know but there is no compatibility problem about the output file if it's produced with 32bit or 64 [02:46:42 CEST] <klaxa> usually negligible [02:46:48 CEST] <klaxa> no [02:47:09 CEST] <klaxa> video files are independent of the software that produced them [02:47:46 CEST] <klaxa> you can watch youtube on a 32-bit system just as well as on a 64-bit system, right? [02:47:53 CEST] <klaxa> they use the same files [02:48:29 CEST] <wallbroken> yes, but i do not know anything about performances on reproducing 64bit output or 32 [02:49:24 CEST] <klaxa> it's really nothing to worry about [02:49:33 CEST] <furq> how many times do we have to tell you it makes no difference before you stop asking [02:50:17 CEST] <klaxa> oh color me surprised [02:50:18 CEST] <klaxa> http://forum.doom9.org/showthread.php?t=147686 [02:50:27 CEST] <klaxa> seems like it *does* make a difference for x264 [02:50:35 CEST] <klaxa> this is from 2009 though [02:51:26 CEST] <klaxa> if you really want to be sure run some benchmarks yourself [02:53:37 CEST] <wallbroken> furq, when there is no difference, there is the problem: i do not know which one to use [02:54:28 CEST] <klaxa> <klaxa> there is not really a reason not to use 64-bit operating systems [04:24:17 CEST] <ytan> Hi there [04:24:51 CEST] <ytan> I'm trying to see how to use rtsp streaming [04:25:54 CEST] <ytan> One one console, I have: ffmpeg -rtbufsize 100M -re -f dshow -s 320x240 -i video="BisonCam, NB Pro" -r 10 -an -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:8554/demo [04:26:23 CEST] <ytan> and on another, I have [04:26:24 CEST] <ytan> ffplay rtp://127.0.0.1:8554/demo [04:27:53 CEST] <ytan> sorry, I have this: ffplay -rtsp_flags listen -i rtsp://127.0.0.1:8554/demo [04:29:04 CEST] <ytan> I can see the connection established, and my webcam LED is turned on [04:29:11 CEST] <ytan> but I get this message: real-time buffer [BisonCam, NB Pro] [video input] too full or near too full (97% of size: 100000000 [rtbufsize parameter])! frame dropped! [04:30:11 CEST] <ytan> and I get a crash [05:05:26 CEST] <ytan> hello... [05:05:34 CEST] <ytan> anybody... here? [05:10:32 CEST] Action: ytan drops a pin [05:14:05 CEST] <VamoMenem> yea [05:17:29 CEST] <VamoMenem> ytan try using rtbufsize 1M or less [05:18:09 CEST] <VamoMenem> Note also that using dshow's "rtbufsize" has the unfortunate side effect of sometimes allowing frames to "buffer" while it is waiting on encoding of previous frames, or waiting for them to be sent over the wire. This means that if you use a higher value at all, it can cause/introduce added latency if it ever gets used (but if used, can be helpful for other aspects, like transmitting more frames [05:18:09 CEST] <VamoMenem> overall consistently etc. so YMMV). Almost certainly if you set a very large value for this, and then see the "buffer XX% full! dropping!" message, you are introducing latency. [05:18:09 CEST] <VamoMenem> There is also apparently an option -fflags nobuffer which might possibly help, usually for receiving streams reduce latency. [05:19:19 CEST] <VamoMenem> and try to without -re option [05:24:03 CEST] <VamoMenem> ls [05:47:32 CEST] <ytan> thanks for the tip VamoMenem [05:47:57 CEST] <ytan> tried this [05:47:57 CEST] <ytan> ffmpeg -rtbufsize 10M -re -f dshow -s 320x240 -i video="BisonCam, NB Pro" -r 10 -an -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:8554/demo [05:48:04 CEST] <ytan> but it just crashes [06:09:54 CEST] <VamoMenem> ffmpeg -rtbufsize 1M -f dshow -s 320x240 -i video="BisonCam, NB Pro" -r 10 -an -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:8554/demo [06:10:15 CEST] <VamoMenem> pastebin the crash ytan [06:32:08 CEST] <MrDave20161> has anyone else noticed a problem with the pkg-config file libavutil.pc ? It does not seem to be updated for the new lib requirements of version 3.1 from what I have seen. [06:32:59 CEST] <mrelcee_> i had some joy with libavutil on my system after manually compiling ffmpeg. couldn't conmpile the vlc port.. [06:33:16 CEST] <mrelcee_> library too new it said [06:34:44 CEST] <MrDave20161> hmm...I needed to change the libs it used to get my app to compile. Had to add -lX11 -lvdpau -lva-drm -lva-x11 -lva [06:36:12 CEST] <MrDave20161> just wondering if this is a common problem with 3.1 that others are seeing [06:38:02 CEST] <mrelcee_> i am probably on a different platform than you - but i haven't heard of anything like that till you. [06:47:25 CEST] <MrDave20161> Ok. This was a 16.04 Xubuntu fresh install. Completed the published instructions for Ubuntu and ffmpeg compiled fine. When I then compiled my app using the pkg-config it failed (worked fine for version 3). Looks like HW acceleration was added in 3.1 which needs these libs and they were not part of the pc file. [06:47:58 CEST] <MrDave20161> thanks for the response. [06:56:36 CEST] <mrelcee_> you are using the hw accelleration? [07:11:49 CEST] <MrDave20161> I'm testing on all different platforms/versions and this is a VM machine so I'm not sure. The app needs it to work whether it is enabled or disabled. [07:20:16 CEST] <mrelcee_> if it's a VM i doubt hw acceleration is making it thru [07:20:28 CEST] <mrelcee_> yeah it does. [07:21:25 CEST] <mrelcee_> i can't keep track of all the forks of ubuntu any more [07:23:30 CEST] <mrelcee_> I use ubuntu to refresh old laptops and desktop machines that shipped with XP to make usable web/email platforms for people wiho don't ahve a lot of money. Sometimes I just donate them, especially if I get a referral from the women's shelter.. lotta people need basic computers so they can get jobs or communicate with family.. [12:21:56 CEST] <msk> Hello! I've just tried to compile ffmpeg on OS X 10.11.6 with no luck. ./configure does not find libmp3lame library version >= 3.98.3 (though, libmp3lame 3.99.5 is installed, like every other dependency, via homebew). [12:22:05 CEST] <msk> What should I do? [12:32:19 CEST] <msk> Found solution to my probem over here: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=94 [12:32:22 CEST] <msk> Bye. [15:10:59 CEST] <t4nk674> I am getting error in av_calloc [15:11:16 CEST] <t4nk674> how to debug it? does it mean there is some memory leakage [15:11:26 CEST] <t4nk674> segfault [15:18:11 CEST] <t4nk674> can anyone please help, how to debug? [15:20:55 CEST] <c_14> You're getting a segfault in av_calloc? [15:21:14 CEST] <c_14> Is this the ffmpeg binary or your program? [15:26:27 CEST] <fritsch> provide a backtrace from gdb [15:26:28 CEST] <t4nk674> ffmpeg binary and I have added my custom decoder [15:27:47 CEST] <t4nk674> sharing the gdb backtrace [15:27:52 CEST] <t4nk674> 2 min [15:28:19 CEST] <c_14> make sure you run gdb on ffmpeg_g otherwise you won't have any symbols [15:31:27 CEST] <t4nk674> i dont have ffmpeg_g but added -g in makefile [15:31:59 CEST] <t4nk674> I mean -g is there, so I should be getting debug symbols there and gdb [15:32:05 CEST] <t4nk674> trace, is it correct [15:32:06 CEST] <c_14> the important thing is --disable-stripping [15:32:47 CEST] <t4nk674> yes [15:41:38 CEST] <t4nk674> Err logs: http://paste.ubuntu.com/23097632/ [15:41:43 CEST] <t4nk674> please check [15:44:12 CEST] <t4nk674> @fritsc @c_14 please check [15:44:24 CEST] <fritsch> nothing to check there [15:44:31 CEST] <fritsch> the issue is not in [15:44:47 CEST] <fritsch> stack is broken before [15:44:52 CEST] <fritsch> how do you use ffmpeg? [15:46:28 CEST] <t4nk674> command line [15:46:43 CEST] <fritsch> this is all what you do? [15:46:47 CEST] <fritsch> with the above command line? [15:46:57 CEST] <t4nk674> yes, providing you [15:47:25 CEST] <t4nk674> ffmpeg -y -f mp4 -i ip_file.mp4 -vsync 0 out.yuv [15:47:37 CEST] <fritsch> `ffmpeg -y -f mp4 -i bbb_sunflower_1080p_30fps_normal.mp4 -vsync 0 -f null /dev/' <- this i saw [15:47:42 CEST] <fritsch> and could not make any sense of it [15:47:56 CEST] <fritsch> no idea [15:48:42 CEST] <t4nk674> -f null /dev/null is used to calculate performance of decoder [15:49:22 CEST] <t4nk674> But this error is same as when used "ffmpeg -y -f mp4 -i ip_file.mp4 -vsync 0 out.yuv" [15:49:57 CEST] <t4nk674> its failing on av_calloc ? Is this due to heap overflow ! [15:51:26 CEST] <fritsch> "heap overflow"? [15:55:25 CEST] <t4nk674> means no memory available to alloc [15:55:33 CEST] <t4nk674> is that so? [16:05:14 CEST] <Spring> why does h.264 require heights divisible by two? [16:06:44 CEST] <fritsch> cause the standard demands it :-) [16:08:09 CEST] <fritsch> to why, see the answer by Adisak, that makes sense: http://stackoverflow.com/questions/20847674/ffmpeg-libx264-height-not-divis… [16:08:55 CEST] <Spring> fritsch, interesting. Anything else I need to look out for? [16:09:15 CEST] <Spring> if it weren't for accidentally coming across the error I wouldn't have known [16:09:16 CEST] <fritsch> no idea, if you want to learn x264, check the standard more in detail [16:10:16 CEST] <fritsch> ffmpeg's wiki is a good start [16:10:21 CEST] <fritsch> talking about quality [16:10:37 CEST] <fritsch> next step then is containers [16:10:54 CEST] <fritsch> profiles before that of course - level 4.1@high most player can play nowadays [16:10:57 CEST] <fritsch> if not level 3.0 [16:13:10 CEST] <Spring> I wonder how many will think AV1 is AVI [16:13:47 CEST] <fritsch> hehe [16:13:55 CEST] <fritsch> how many will know what "avi" is :-) [16:14:04 CEST] <fritsch> the windozers without file extensions have no idea [16:16:07 CEST] <Spring> You could be right. There'll be a whole generation that wouldn't have even heard of it, as well. [16:16:36 CEST] <fritsch> the next generation won't even know what "interlaced content" is [16:23:29 CEST] <Mavrik> Thank all the gods for that :P [16:58:50 CEST] <jazzy> New to ffmpeg so excuse if the question looks fairly basic. I am trying to extract ID3 tags from an AAC file using ffmpeg. The steps are to convert AAC to PCM and then to extract the ID3 tags. Any help on this would be highly appreciated. [17:08:07 CEST] <Spring> anyone know what the source quality of PS4/Xbox native captures are? I know the PS4 has a native capture, assuming Xbox One does, too. [17:09:00 CEST] <c_14> jazzy: ffprobe file -show_entries format_tags ? [17:10:28 CEST] <jazzy> c_14: I get no output when I run that. [17:11:19 CEST] <c_14> Then the file probably doesn't have any ID3 tags [17:19:18 CEST] <jazzy> c_14: Thanks. How would I convert thta to a PCM file? [17:20:11 CEST] <c_14> ffmpeg -i file out.pcm [17:20:19 CEST] <c_14> eh [17:20:23 CEST] <c_14> ffmpeg -i file -f s16le out.pcm [17:26:44 CEST] <jazzy> c_14: Im getting this output. http://pastebin.com/jyAiyvTL [17:30:12 CEST] <c_14> ffmpeg -i aac/Test1.acc -f s16le out.pcm [17:34:39 CEST] <jazzy> c_14: still getting the same output as pasted in pastebin earlier. [17:35:09 CEST] <c_14> It should look at least a bit different now though [17:35:13 CEST] <c_14> Can you pastebin the output again? [17:35:26 CEST] <jazzy> Sorry. Got a different output. Pasting it. [17:38:53 CEST] <jazzy> c_14: This is the output. It did create a pcm file. http://pastebin.com/1YF9Sibm [17:39:45 CEST] <jazzy> But there are quite a few errors while executing. [17:40:00 CEST] <c_14> yeah, it really doesn't like the input aac file [18:03:40 CEST] <Conder> hello, i have audio stream in .AC3, its from 25 fps DVD. i want convert it to 23.976 fps. can i do it in ffmpeg? [18:04:12 CEST] <JEEB> yes [18:04:19 CEST] <c_14> Under the assumption that you're slowing down the video or under the assumption that you're dropping frames? [18:04:20 CEST] <JEEB> see the list of audio filters [18:05:36 CEST] <Conder> JEEB: u mean this? https://ffmpeg.org/ffmpeg-filters.html [18:05:41 CEST] <Conder> there isnt anything about AC3 [18:05:55 CEST] <JEEB> of course not because you have to decode the audio :P [18:06:10 CEST] <JEEB> and thus it's a standard audio filter [18:13:12 CEST] <Conder> JEEB: u mean decode to WAV, then run it through ffmpeg with --fps 25 and then encode to AC3 again? [18:14:32 CEST] <JEEB> well since audio doesn't have a frame rate you just use the filter that switches the audio rate (since I will guess that the 25fps thing was made from speeding up the 24/1.001 fps one), and then if you for whatever reason want to have the output in AC3, then yes [18:15:53 CEST] <JEEB> ffmpeg -i hurr.ac3 -af filter=parameters out.file [18:16:20 CEST] <JEEB> I don't do such editing myself so I don't know which audio filter is best suited for this, but atempo seems like one thing :P [18:16:36 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#Examples-46 [18:17:10 CEST] <c_14> If you want to preserve pitch use atempo, otherwise asetrate [18:19:36 CEST] <Conder> okay im going try it. thx [18:27:03 CEST] <markg1> I can't make ffmpeg go faster, I have 20 input files trying to convert to h264 but it has taken more than 1 day, the sad part is, I do have a greate cpu and ram but it doesnt use more than %23 of my cpu, I enabled thread -4 and I also ran 4 instance of the ffmpeg stilll is not using more than %23 of my cpu. any idea? [18:27:29 CEST] <JEEB> depends on which decoders and encoders you're using :P [18:27:36 CEST] <JEEB> and other things such as settings [18:27:41 CEST] <markg1> -c:v libx264 -preset superfast -crf 25 -c:a aac -threads 4 [18:28:02 CEST] <markg1> what other settings would u add to that ? [18:28:04 CEST] <JEEB> post full command line and terminal output on a pastebin, then link here [18:31:24 CEST] <markg1> @JEEB http://pastebin.com/1zwTGW83 [18:34:22 CEST] <markg1> so I am converting from mjpeg to h264 [18:34:45 CEST] <JEEB> I'd prefer an uncut thing of what I requested. but first of all,try doing `ffmpeg -i /input/your_thing.avi -f null -` [18:34:50 CEST] <JEEB> see how quickly that goes [18:36:45 CEST] <JEEB> also you don't need to set threads for encoding with libx264 - it picks according to the amount of your virtual cores automagically [18:37:08 CEST] <JEEB> so the only function of setting threads is to *limit* them for libx264 [18:37:43 CEST] <markg1> @JEBB I only set threads when I saw it wasnt using cpu before having it [18:38:09 CEST] <JEEB> well now I told you that setting threads after -i with libx264 makes no difference unless you want to *limit* it :P [18:38:27 CEST] <JEEB> (after -i meaning for encoding, the placement of settings matters in that sense in ffmpeg cli) [18:38:45 CEST] <JEEB> so yes, just try how quickly you can decode that thing in general with your thingg [18:38:53 CEST] <JEEB> I gave you a sample of how to check that [18:40:47 CEST] <markg1> @JEBB allright the null thing is 9X [18:41:03 CEST] <markg1> without null other wise its is 0.4X upt to 1X [18:41:12 CEST] <markg1> and cpu usage is sitll less than 17% [18:41:31 CEST] <markg1> so with null the speed goes up. cpu usage no. [18:41:46 CEST] <JEEB> basically the -f null one is how fast you can "just decode" the tracks :P [18:41:58 CEST] <markg1> gotcha [18:42:30 CEST] <markg1> so is there anything I can do to make ffmpeg use my cpu ? I even tried to move my files to my SSD I though the HDD was the bottleneck [18:42:51 CEST] <JEEB> if you mean faster for a single file than with -f null, then no [18:43:27 CEST] <JEEB> -f null one is pretty much the maximum, and then after that it goes through any sort of possible filters and through to the encoder/muxer [18:44:50 CEST] <markg1> no I didnt meant that. when I dont do null, and I do the actual file ouptput it is max 1 X [18:44:56 CEST] <markg1> but mostly 0.2X [18:45:06 CEST] <markg1> with null it is 9X [18:45:09 CEST] <JEEB> how fast does `ffmpeg -i /input/file.avi -an -c:v libx264 -preset superfast -f null -` go? [18:45:17 CEST] <markg1> can I make my actual thing to be faster than 1 ? [18:45:45 CEST] <JEEB> that encodes the video and skips the audio track [18:45:49 CEST] <JEEB> and skips muxing [18:46:14 CEST] <markg1> ok will try thanks [18:47:11 CEST] <markg1> what does -an do ? [18:47:26 CEST] <JEEB> "audio none" (ignores input audio) [18:47:39 CEST] <JEEB> thus you're only encoding video [18:48:42 CEST] <markg1> gotcha. but still makes me sad that ffmpeg doesnt use all my cpu, when I had a shitty laptop everyone said just go get a nice cpu, I got extreme core i7 and a 32 GB RAM [18:48:47 CEST] <markg1> and still encoding slow [18:49:10 CEST] <markg1> I wish ffmpeg would have used all my cpu [18:49:39 CEST] <JEEB> x264 is not perfect but unless it's blocked by something else it's utilizing modern CPUs pretty darn well :P [18:52:00 CEST] <JEEB> markg1: so how is just video encoding without writing or audio? :P [18:52:39 CEST] <markg1> will that that in a minute [18:53:37 CEST] <markg1> it is still pretty low speed=0.884x [18:53:42 CEST] <markg1> depressing... [18:54:21 CEST] <JEEB> post full command line and terminal output on a pastebin [18:54:24 CEST] <Spring> what are you encoding? [18:54:39 CEST] <JEEB> Spring: 1440x1080 MJPEG [18:54:44 CEST] <JEEB> at 30fps [18:55:39 CEST] <iive> check if the heat sinc haven't detached. the cpu may overheat and throttle down. [18:56:30 CEST] <JEEB> yeah, I would make sure it's actually keeping the CPU speed up even when under load [18:56:35 CEST] <iive> `sensors` should be able to show cpu temperature. [18:57:04 CEST] <iive> and powertop shuold be able to show the clock speeds and idle times. [18:57:45 CEST] <markg1> iive are you talking to me ? [18:57:56 CEST] <markg1> I checked the cpu usage using top, it is like 18% [18:57:58 CEST] <Spring> 0.8 is bad? I'd say it's pretty good [18:58:12 CEST] <markg1> Spring thats same as when I had a shitty laptop [18:58:16 CEST] <markg1> now I have a full blown imac [18:58:19 CEST] <markg1> with core i7 [18:58:42 CEST] <markg1> obviosuly encoding is taking a lot of computations but ffmpeg is not using all my cpu to do the computations [18:58:53 CEST] <markg1> I think ffmpeg can do a better job using parallel algorirthms [18:59:01 CEST] <JEEB> but yeah, make sure you're not getting downclocked :P [18:59:06 CEST] <JEEB> under load [18:59:28 CEST] <markg1> I dont think iMac core i7 ships with downclocked [18:59:32 CEST] <Spring> I have an i5-4670K 3.4Ghz, 8GB memory, 970 GPU and get speeds lower than that for 1440p content [18:59:42 CEST] <markg1> I even moved the files to SSD to make sure it is not harddisk stopping cpu [18:59:47 CEST] <JEEB> Spring: it's not 1440p [18:59:52 CEST] <JEEB> it's 4:3 1080p [18:59:56 CEST] <JEEB> so even less than 1920x1080 [19:00:01 CEST] <Spring> oh right [19:00:15 CEST] <Spring> misread the 1440 resolution [19:00:35 CEST] <JEEB> markg1: not about shipping with downclock but actually downclocking due to the cooler or whatever not keeping up :P just make sure your CPUs are still at full speed and that the core temps are good [19:01:59 CEST] <Spring> encoding an Apple trailer at 1440px wide it's about 1.3x on average [19:04:22 CEST] <JEEB> that really depends on your configuration and how fast the input decoder is [19:04:26 CEST] <JEEB> and some other things [19:04:40 CEST] <Spring> just btw markg1 this is from the command line directly or via a front end with command line option input? [19:04:54 CEST] <markg1> my cpu temp is normal CPU temp: 47.875°C [19:05:06 CEST] <markg1> yeah it is commandline [19:05:11 CEST] <markg1> through a for loop in a bash script [19:05:18 CEST] <JEEB> markg1: check your cpu core speeds and what CPU you have [19:06:09 CEST] <markg1> I stopped the scripts I willl check in a few minutes [19:06:16 CEST] <Spring> I had this strange issue with a Windows ffmpeg front end that accepted CLI options and it was limiting the encoding speed dramatically. It wasn't until I began using my own script that I realized the difference. [19:06:27 CEST] <JEEB> uhh, you were running stuff in the background? [19:06:33 CEST] <JEEB> while testing speeds? [19:06:53 CEST] <markg1> what do you mean running stuff in background [19:07:00 CEST] <markg1> I only had chrome open chatting with you [19:07:05 CEST] <JEEB> ok [19:07:07 CEST] <markg1> but now I killed all the scripts [19:07:12 CEST] <JEEB> wait what [19:07:12 CEST] <markg1> not encoding at the moment [19:07:26 CEST] <JEEB> so were you actually encoding in the background when testing the commands I noted? [19:07:37 CEST] <markg1> no [19:07:40 CEST] <JEEB> ok [19:07:44 CEST] <markg1> but one thign I tried was [19:07:52 CEST] <markg1> I dvided my files into 4 folders [19:07:55 CEST] <markg1> and I ran 4 instances of ffmpeg [19:08:06 CEST] <markg1> to see if they will eventually be faster in paralell [19:09:32 CEST] <JEEB> anyways, find out your CPU type and speed and if it keeps speed while under load (x264) [19:12:41 CEST] <markg1> I am pretty sure it is not my cpu, after buying a whole new computer just because ppl told me it is my cpu [19:12:55 CEST] <markg1> and it is not a laptop that heats up it isa desktop [19:13:12 CEST] <markg1> anyways In my previous notes I had one option -b:a 192k [19:13:15 CEST] <markg1> what does -b:a 192k do ? [19:13:23 CEST] <markg1> should I add that back to my script maybe that makes it fater? [19:13:24 CEST] <Spring> sets the audio bitrate [19:13:25 CEST] <markg1> faster* [19:13:44 CEST] <JEEB> it just sets the audio bit rate but since you say it's slow with just the video encoding then that has nothing to do with it :P [19:14:15 CEST] <JEEB> also stop being so self-confident, make sure you're OK and know exactly what sort of hardware you have before going forward [19:15:05 CEST] <iive> markg1: can we see your full command line ? [19:15:27 CEST] <JEEB> the MJPEG decoding speed is not quick (if you say 9x speed at 30fps it's 270fps) [19:15:34 CEST] <Spring> oh I forgot, I also set my script to slower, hence why my speeds are slower (obvs) [19:15:42 CEST] <JEEB> yeah, this was with superfast [19:15:58 CEST] <JEEB> I mean his under-realtime results [19:15:59 CEST] <markg1> ffmpeg -i /input/$f -c:v libx264 -preset superfast -crf 25 -c:a aac /output/$f.mp4 [19:16:21 CEST] <JEEB> iive: he's posted information on the results of decoding-only and video encoding-only tests here, too :P [19:17:38 CEST] <JEEB> markg1: anyways I don't think there's any reason to continue this discussion until you provide some information so we can gauge expectations and other things [19:18:36 CEST] <JEEB> anyways, going for a run - brb [19:19:56 CEST] <markg1> allright. let me know what other information you guys need [19:20:06 CEST] <markg1> I will check the cpu core speed later when I re-run the script [19:20:09 CEST] <JEEB> I think I've noted it a few times already :P [19:20:16 CEST] <iive> you said it is imac, is it desktop or laptop? [19:20:22 CEST] <markg1> iMac [19:20:28 CEST] <JEEB> what hardware, what speed is it running at during load [19:20:32 CEST] <markg1> iMac is techincally a desktop because it doesnt have battery [19:20:42 CEST] <JEEB> as in CPU type, CPU speeds under load [19:20:43 CEST] <markg1> core i7 [19:20:53 CEST] <JEEB> yeah, sure [19:20:57 CEST] <JEEB> mine is i7 as well [19:21:02 CEST] <JEEB> but mine has the marking 4790K [19:21:09 CEST] <JEEB> which is quite different from many other i7s [19:21:19 CEST] <markg1> Intel(R) Core(TM) i7@ 3.40GHz [19:21:32 CEST] <JEEB> yeah, that misses the main part :P [19:21:38 CEST] <JEEB> aka the model [19:21:46 CEST] <markg1> Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz [19:21:47 CEST] <Spring> IIRC there's an extended system info in the About item of the Apple menu [19:22:04 CEST] <markg1> check out the benchmark for Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz on cpu benchmarks [19:22:11 CEST] <markg1> it is one of the highest [19:22:20 CEST] <markg1> except it uses more power than new i7s [19:22:46 CEST] <JEEB> is that really the CPU you have or are you just throwing things around again? [19:22:46 CEST] <markg1> anyway, we cant say it is because of my cpu, if it is not even using more than 26% of my cpu [19:22:52 CEST] <JEEB> jesus christ... [19:23:01 CEST] <markg1> when did I ever throw things arround ? [19:23:05 CEST] <markg1> why would I lie to you? [19:23:15 CEST] <markg1> jesus christ... [19:23:15 CEST] <markg1> $ sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz [19:23:18 CEST] <JEEB> because you think you know things, because you assume things [19:23:22 CEST] <JEEB> thank you [19:23:33 CEST] <markg1> what makes you think I Assume things ? [19:24:08 CEST] <JEEB> like the way you are saying that it can't be your CPU even though you haven't checked basic things yet (does the CPU keep its speed under load etc) [19:24:11 CEST] <markg1> what makes you think, I only think I know things... [19:24:26 CEST] <Spring> interestingly my i5 performs better [19:24:28 CEST] <JEEB> because this is clearly not your familiar thing [19:24:34 CEST] <JEEB> s/thing/setting/ [19:24:53 CEST] <markg1> you are being condesesnign and not helpful [19:24:56 CEST] <JEEB> ok, so it's a quad core at 3.4GHz. thank you very much for providing that information [19:24:56 CEST] <markg1> I am leaving this chat. [19:25:01 CEST] <Spring> perhaps the Mac is limiting the CPU power [19:25:12 CEST] <JEEB> Spring: that's one possibility, or it's just not getting cooled properly [19:25:22 CEST] <JEEB> or the build is built without threading somehow [19:25:28 CEST] <markg1> I posted the cpu temprature [19:25:29 CEST] <Spring> not sure how large those inbuilt fans are [19:25:30 CEST] <markg1> it is 47 [19:25:34 CEST] <markg1> it is bellow average [19:25:39 CEST] <JEEB> markg1: yeah but that doesn't say what your CPU is doing to keep it there [19:25:54 CEST] <Mavrik> Note that when macs start overheating you see a "kernel_task" using a lot of CPU [19:25:55 CEST] <JEEB> that's the point. something in your system can tell you at which speed your CPU is running and show it on screen [19:26:10 CEST] <Mavrik> (It's how thermal throttling shows up in OSX) [19:26:19 CEST] <Spring> fwiw my CPU is idling at around 33c [19:26:27 CEST] <JEEB> and you just make sure that even when running the video encode test (-c:v libx264 -f null -an one) it's keeping on that speed [19:26:30 CEST] <Spring> but I'm guessing that is load [19:26:36 CEST] <markg1> anywas, I just wanted to note here that ffmpeg does a horrible job being parallel. I dont wanna continue this discussion. bye [19:26:42 CEST] <JEEB> hah [19:26:50 CEST] <JEEB> there goes my wasted time [19:27:07 CEST] <JEEB> some people really don't understand they're being helped [19:27:11 CEST] <Spring> APPLE USERS AMIRITE [19:27:22 CEST] <JEEB> the OS really doesn't matter [19:27:28 CEST] <JEEB> idiots are everywhere idiots [19:27:33 CEST] <Mavrik> Indeed, ffmpeg works wonderfully on OSX :P [19:27:46 CEST] <Mavrik> Or timOS or whatever they renamed it now to make people feel better. [19:28:29 CEST] <Spring> did they buy the iMac /just/ for the encoding? [19:28:42 CEST] <JEEB> a '11 CPU bearing iMac at that [19:28:50 CEST] <JEEB> so he didn't use too much money on that :P [19:29:13 CEST] <JEEB> funny enough if he wanted used he could have just taken one of those 2x E5 2670 setups [19:29:15 CEST] <Mavrik> Could be worse, could be C2D :P [19:29:22 CEST] <JEEB> and get 2x 20MiB sandy-es [19:29:30 CEST] <JEEB> probably not for much more money even [19:45:27 CEST] <JEEB> Mavrik: I actually did encoding with a C2D from '08 to '13 [19:45:43 CEST] <JEEB> before that it was a dual core Turion64 [19:47:53 CEST] <Mavrik> Well that was a current CPU at that time [20:00:05 CEST] <mrelcee_> dont' take it all out on apple users. a few of us have clues :) [20:00:25 CEST] <Mavrik> <-- apple user [20:00:59 CEST] <dave`> I'm intending to use ffmpeg to stream content from a well-known website which uses webm (vp9) encoding. How do I tell ffmpeg to digest this encoding? [20:02:06 CEST] <Mavrik> ffmpeg will recognise the format and decode it [20:02:10 CEST] <Mavrik> What's the actual problem? [20:02:34 CEST] <JEEB> vp9 decoder is included in default configuration, and the matroska demuxer as well (in which VP9 usually is) [20:02:36 CEST] <dave`> I wasn't sure if I could speed things up by specifying the exact encoding. [20:02:48 CEST] <JEEB> in an API using thing, maybe [20:02:54 CEST] <JEEB> with ffmpeg not likely [20:03:04 CEST] <JEEB> I guess this is about ffmpeg probing for a while [20:03:39 CEST] <dave`> I consider my question answered; thanks. [20:07:50 CEST] <iive> JEEB: markg1 problem is indeed very strange, since ffmpeg/x264 doesn't seem to be using threading. I do suspect that it is some kind of OS problem, or something missing at compilation. [20:08:15 CEST] <JEEB> probably the binary was weird [20:08:28 CEST] <JEEB> I was trying to see if threading or asm was disabled, but it didn't seem to be [20:08:42 CEST] <JEEB> since he posted a single pastebin at least with some terminal output [20:09:15 CEST] <JEEB> it was really weird because it looked like an ubuntu build (had 16.04 or whatever noted as well) [20:09:20 CEST] <iive> threading might not be disabled in configure, but simply not detected... [20:09:41 CEST] <JEEB> I would think that would be a "please make sure you're OK with this" level of stuff :P [20:09:46 CEST] <JEEB> like asm on x86 [20:09:48 CEST] <iive> heh... [20:09:59 CEST] <JEEB> you have to really set --disable-asm for it to configure [20:17:37 CEST] <DHE> or not have yasm (?) installed [20:18:01 CEST] <DHE> that's an error, right? [20:27:10 CEST] <mrelcee_> i would be shocked if he built it himself on osx. probably downloaded it.. [20:27:31 CEST] <JEEB> DHE: that's what I noted :) [20:27:50 CEST] <JEEB> not having yasm or nasm will make x264 and FFmpeg configure derp and ask if you are really sure [22:51:30 CEST] <kyleogrg> I've downloaded a bunch of YouTube videos having vp9 codec, sorted by various resolutions. I have used the plotframes script to get these OVERALL bitrate statistics. [22:52:29 CEST] <MINIMAN10000> Alright so what did I actually run? "ffmpeg -i in.mp4 -ss 00:15:55 -t 00:16:20 -async 1 cut.mp4" [22:52:31 CEST] <kyleogrg> http://pastebin.com/hEbFMph4 [22:52:43 CEST] <kyleogrg> Please have a look if you're interested. [22:52:43 CEST] <MINIMAN10000> I wanted to start at 15 minutes 55 seconds and end at 16 minutes 20 seconds [22:52:49 CEST] <ChocolateArmpits> kyleogrg: Youtube does some neural analysis to determine best bitrate for each paralelyzed segment [22:52:59 CEST] <MINIMAN10000> Is that what I did... or... did I start at 15:55 and run for 16 minutes? [22:53:18 CEST] <dl2s40> MINIMAN10000, -t is duration afaik [22:53:24 CEST] <MINIMAN10000> FFFFF [22:53:27 CEST] <ChocolateArmpits> MINIMAN10000: use -to instead of -t [22:53:37 CEST] <ChocolateArmpits> then it'll work as you expect [22:53:37 CEST] <kyleogrg> ChocolateArmpits: I'm trying to approximate the youtube bitrates for my own much smaller-scale project [22:54:34 CEST] <ChocolateArmpits> kyleogrg: hmm the lower bitrates really use vp9? [22:55:00 CEST] <kyleogrg> ChocolateArmpits: yeah! at least i was able to get 'em with youtube-dl [22:55:17 CEST] <MINIMAN10000> neat [22:55:29 CEST] <MINIMAN10000> I only remember hearing the 4k videos using 4k [22:55:35 CEST] <MINIMAN10000> er use vp9 [22:56:08 CEST] <kyleogrg> So, the question now is how do I translate this into a command for libvpx-vp9 [22:56:15 CEST] <MINIMAN10000> I wonder why it stalls for like 15 seconds before it begins encoding [22:56:29 CEST] <kyleogrg> I probably want to use Constrained Quality for this (http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide) [22:56:57 CEST] <MINIMAN10000> I've always just been a fan of using max bitrate but that's mainly cause it's transmitted over the internet [22:57:19 CEST] <MINIMAN10000> and quality is of little concearn [22:57:33 CEST] <MINIMAN10000> at least I don't feel the need to constrain it. [22:57:39 CEST] <kyleogrg> MINIMAN10000: i hear ya [22:57:54 CEST] <MINIMAN10000> Usually 1500 kbps as an average is "good enough" in my use case. [22:57:55 CEST] <kyleogrg> but i'm just trying to copy youtube here, just kind of experimentally [22:58:17 CEST] <kyleogrg> 480p for instance [22:58:20 CEST] <MINIMAN10000> I was experimenting to have a low latency stream [22:58:22 CEST] <MINIMAN10000> I failed miserably. [22:58:29 CEST] <MINIMAN10000> the latency was not low enough [22:58:59 CEST] <kyleogrg> for 480p the very max bitrate i found (across hundreds of videos) was 3660. [22:59:02 CEST] <kyleogrg> kbps [22:59:19 CEST] <kyleogrg> does that mean i should set vp9 to have a max of 3660? then what about crf? [22:59:28 CEST] <MINIMAN10000> wat [22:59:30 CEST] <MINIMAN10000> holy crap [22:59:43 CEST] <BtbN> I wouldn't be surprised if they have their own private encoder. [22:59:47 CEST] <MINIMAN10000> is that normal for 480p? [22:59:47 CEST] <dl2s40> some videos just need more bitrate [22:59:58 CEST] <MINIMAN10000> for 480p I use like... 800 kbps? [23:00:02 CEST] <kyleogrg> BtbN: yeah... but then, vp9 is theirs to begin with [23:00:18 CEST] <ChocolateArmpits> MINIMAN10000: peak bitrate may mean just a short burst at the start of a video [23:00:27 CEST] <MINIMAN10000> oh right constrained [23:00:34 CEST] <kyleogrg> MINIMAN10000: what codec? cuz vp9 uses less than x264 for instance [23:00:40 CEST] <MINIMAN10000> I dono I usually just stick with 1080 1500kbps vp9 [23:01:06 CEST] <MINIMAN10000> but this video i'm working on now I just used whatever the defaults it gave me were for a quick and easy encode. [23:01:13 CEST] <kyleogrg> And here's another thing, the avg bitrate across all 480p vids is 207 kbps. [23:01:17 CEST] <ChocolateArmpits> kyleogrg: start out with simple -b:v 200k without setting any other ratecontrol [23:02:06 CEST] <ChocolateArmpits> youtube encodes per content, so more motion will have more assigned more bits on their system [23:02:08 CEST] <furq> this makes me wonder where youtube-dl pulls its bitrate info from [23:02:20 CEST] <furq> it looks to be way off [23:02:33 CEST] <kyleogrg> ChocolateArmpits: if it's per content, isn't that like crf? [23:03:23 CEST] <dl2s40> 1080p at 1500 kbps?? well i dont no much about vp9 but i would say for x246 1500 kbps sounds about right for SD content [23:03:58 CEST] <kyleogrg> furq: well, i just used youtube-dl to download vids based on codec and resolution. later i used ffprobe and plotframes to look at bitrate. [23:04:54 CEST] <MINIMAN10000> I'm quite happy I learned that -to is a command. now I can save that to a file and go back to playing games. [23:05:24 CEST] <ChocolateArmpits> kyleogrg: well it sort would be closer to dynamic crf with maxrate [23:05:38 CEST] <ChocolateArmpits> like crf getting set for each segment separately [23:05:40 CEST] <kyleogrg> the vp9 guide recommends two-pass for best quality, but i wonder why. i only use two-pass with x264 using crf [23:05:59 CEST] <ChocolateArmpits> well that's because you will get the most out of your encode [23:06:20 CEST] <kyleogrg> how does that work, because it's just using a bitrate setting, not crf [23:06:24 CEST] <kyleogrg> why not just one pass [23:07:46 CEST] <ChocolateArmpits> it assigns bits according to the whole video rather than the current time mark [23:07:52 CEST] <dl2s40> is two pass really better? [23:07:54 CEST] <kyleogrg> ahh [23:08:26 CEST] <kyleogrg> even with their best quality setting, they have a speedy first pass. you think it would be much better with a slow first pass? [23:10:13 CEST] <ChocolateArmpits> kyleogrg: the 2nd pass only need specific data, rest of that is dropped so might as well turn off feature on the 1st pass [23:11:00 CEST] <kyleogrg> ok [23:11:26 CEST] <kyleogrg> with libopus, should i use vbr or b:v for streaming? [23:11:31 CEST] <furq> http://vpaste.net/2JqGa [23:11:37 CEST] <furq> i have no idea where it's getting 1603k from [23:11:48 CEST] <furq> i wonder if that's the max bitrate or something [23:16:24 CEST] <kyleogrg> i wonder why the avg bitrate for both 480p and 360p was about 200k [23:16:43 CEST] <kyleogrg> whereas 240p was 70k and 144p was 60k [23:59:36 CEST] <viric> furq: I wanted to share my HT results... HT helps in x264 encoding (+8% faster than without the extra cpu thread), and it helps even more in less simd-optimized tasks (pigz, +21% faster). But it introduces latencies, because for two threads to run 120% compared to one, both have to run at 60%. [00:00:00 CEST] --- Sun Aug 28 2016

1 0

ffmpeg-devel.log.20160826
by burek 27 Aug '16

27 Aug '16

[00:13:05 CEST] <cone-556> ffmpeg 03Burt P 07master:9d5e3c3f59aa: af_hdcd: for easier maintenance alongside libhdcd [00:13:06 CEST] <cone-556> ffmpeg 03Burt P 07master:ec220a8c1ca5: af_hdcd: av_frame_free(out) if av_frame_copy_props() fails [01:06:00 CEST] <Shiz> /w 21 [02:15:44 CEST] <cone-556> ffmpeg 03Jan Sebechlebsky 07master:bcd115316234: libavcodec/bsfs: Fix bsf option setting [06:36:42 CEST] <durandal_1707> looks like yuvj will not die ever [11:21:34 CEST] <cone-356> ffmpeg 03Davinder Singh 07master:b07d4a0fb20d: avfilter: added motion estimation and interpolation filters [11:31:59 CEST] <DHE> regarding ticket #5799 -- seriously? console output does not validate a memory leak [11:44:50 CEST] <durandal_1707> ignore Carl [11:46:37 CEST] <DHE> I'm looking to see if I can reproduce it better than needing actual TV signals. but since it's based on side data, I don't think i can create a reproducer using only testsrc or such [11:47:04 CEST] <DHE> I do have 12+ hours of TV saved just for reproducing this... [11:47:33 CEST] <JEEB> the only thing I'd do if you can't somehow generate a nice input for it, is to simplify the command line [11:48:17 CEST] <DHE> it looks like outputting to mpeg2 is the magic bit, so I could just drop the audio processing entirely and simplify the bitrate constraints [11:48:32 CEST] <DHE> I'll give it a test run in the morning before updating the ticket with the simplified output [11:48:45 CEST] <DHE> I was hoping that the stack dump would be enough to run it down by someone who understands it better than I [11:49:49 CEST] <DHE> the only problem with the stack trace is that gcc inlined a function [11:50:49 CEST] <JEEB> I will take a wild guess and say it has something to do with the props copying [11:51:39 CEST] <DHE> it's odd that it doesn't actually leak the data - points are kept somewhere. but the number of allocations counted by valgrind is always roughly the number of frames processed thus far [11:51:47 CEST] <DHE> *pointers are kept [11:53:05 CEST] <BtbN> DHE, there seems to be an issues with av_frame_new_side_data in https://github.com/FFmpeg/FFmpeg/blob/500662784341373d625af629cad94826beca3… [11:53:09 CEST] <BtbN> or I misunderstand the code [11:53:50 CEST] <BtbN> av_frame_new_side_data allocates a buffer using av_mallocz, and returns that buffer. And I don't see where frame_copy_props ever frees that. [11:54:17 CEST] <BtbN> Or does av_dict_copy do that? [11:54:36 CEST] <DHE> I honestly have no idea what's going on there. I would agree with you, except mysteriously valgrind reports no leaked memory on a clean shutdown. [11:54:45 CEST] <DHE> unless there are circular references and valgrind doesn't track that [11:55:22 CEST] <BtbN> ah. frame_new_side_data does "frame->side_data[frame->nb_side_data++] = ret;" [11:55:47 CEST] <DHE> shouldn't that be freed when the new frame is freed? [11:55:51 CEST] <BtbN> Yes [11:56:01 CEST] <BtbN> but it's applied on the coded_frame in avctx [11:56:05 CEST] <BtbN> which is there for the entire runtime [11:56:13 CEST] <BtbN> to it just keeps appending another sidedata for the entire runtime [11:56:38 CEST] <DHE> oh.. so the saved coded_frame just ends up with a massive list of side_data items? [11:56:45 CEST] <BtbN> Yep [11:56:52 CEST] <DHE> well then [11:56:55 CEST] <BtbN> Using av_frame_copy_props for filling the coded_frame seems wrong in the first place. [12:01:56 CEST] <BtbN> DHE: https://gist.github.com/d06a87934870c984246d23dde353bc29 [12:01:59 CEST] <BtbN> can you try this? [12:02:36 CEST] <BtbN> Hm, nevermind. The actual data also needs to be freed. [12:02:55 CEST] <BtbN> That would just cause an actual leak. [12:04:17 CEST] <DHE> it'll be a few hours before I can test any candidate fix [12:19:55 CEST] <flux> should (in libavformat/movenc.c) mov->track[*].st->id be unique among tracks? [12:28:27 CEST] <flux> hmm, or for that matter, should mov->tracks[x].st be unique [13:00:33 CEST] <cone-356> ffmpeg 03Davinder Singh 07n3.1.3:HEAD: avfilter: added motion estimation and interpolation filters [14:41:08 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:330f4ef48c63: avformat/options_table: Add missing identifier for very strict compliance [14:41:09 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:0aaf66fb2e22: avcodec/mjpegdec: Do not try to detect last scan but apply idct after all scans for progressive jpeg [14:41:10 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:3bbef6082aee: avformat/oggparseopus: Check that granule pos is within the supported range [14:41:11 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:fc6f314838dc: avformat/utils: Check bps before using it in a shift in ff_get_pcm_codec_id() [14:41:12 CEST] <cone-356> ffmpeg 03Chris Cunningham 07release/2.8:345231336fd2: libavformat/oggdec: Free stream private when header parsing fails. [14:41:13 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:500cf2e159fd: swresample/rematrix: Use error diffusion to avoid error in the DC component of the matrix [14:41:14 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:67c7f8ca143d: swresample/rematrix: Use clipping s16 rematrixing if overflows are possible [14:41:15 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:8857dc6cd856: ffmpeg: Check that r_frame_rate is set before attempting to use it [14:41:16 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:2e0af764b32f: avformat/utils: Do not compute the bitrate from duration == 0 [14:41:17 CEST] <cone-356> ffmpeg 03Chris Cunningham 07release/2.8:c1c6cb21b7d2: avformat/utils: Check negative bps before shifting in ff_get_pcm_codec_id() [14:41:18 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:90b27febc6ac: avformat/avidec: Detect index with too short entries [14:41:19 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:9fe101291008: doc/developer.texi: Add a code of conduct [14:41:20 CEST] <cone-356> ffmpeg 03Thomas Guilbert 07release/2.8:669fc1338f25: avformat/oggparseopus: Fix Undefined behavior in oggparseopus.c and libavformat/utils.c [14:41:21 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:2bbbd3e50a8f: avcodec/bmp_parser: Fix state [14:41:22 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:ffb503c9a14c: avcodec/mpegvideo: Deallocate last/next picture earlier [14:41:23 CEST] <cone-356> ffmpeg 03Vivekanand 07release/2.8:5af0ada44271: avformat/allformats: Making av_register_all() thread-safe. [14:41:24 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:76fd8145a1e2: avfilter/af_amix: dont fail if there are no samples in output_frame() [14:41:25 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:731848ef8083: avcodec/bmp_parser: Fix frame_start_found in cross frame cases [14:41:26 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:591c0b527c50: avcodec/bmp_parser: Fix remaining size [14:41:27 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:166921c23eb4: avcodec/bmp_parser: reset state [14:41:28 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:003fa5c3e3c3: avcodec/bmp_parser: Check fsize [14:41:29 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:a4484854db89: avformat/mpegts: Do not trust BSSD descriptor, it is sometimes not an S302M stream [14:41:30 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:04987035ffca: avcodec/utils: check skip_samples signedness [14:41:31 CEST] <cone-356> ffmpeg 03Umair Khan 07release/2.8:1dd34bdb09ad: avcodec/alsdec: fix max bits in ltp prefix code [14:41:32 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:8a32f19d5bd3: avcodec/alsdec: Check r to prevent out of array read [14:41:33 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:bfca58ee2f4c: avcodec/h264: Fix off by 1 context count [14:41:34 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:d9ad05abce33: MAINTAINERs cleanup (remove myself from things i de facto dont maintain) [14:41:35 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:ed7fe48445c7: avcodec/mpegvideo: Do not clear the parse context during init [14:41:36 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:40ffbe7678b7: avcodec/mpc8: Correct end truncation [14:41:37 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:087bd8fbdfb9: avfilter/vf_telecine: Make frame writable before writing into it [14:41:38 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:9fefd76eec20: avcodec/flac_parser: Raise threshold for detecting invalid data [14:41:39 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:4a0b0cffc15a: avformat/format: Fix registering a format more than once and related races [14:41:40 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:054db631200c: avformat/mov: Check sample size [14:41:41 CEST] <cone-356> ffmpeg 03Sasi Inguva 07release/2.8:0f6e244bb009: libx264: Increase x264 opts character limit to 4096 [14:41:42 CEST] <cone-356> ffmpeg 03Kacper MichajBow 07release/2.8:d3ecb2453913: libavutil/opt: Small bugfix in example. [14:41:43 CEST] <cone-356> ffmpeg 03Kacper MichajBow 07release/2.8:73e09e371bda: libavformat/rtpdec_asf: zero initialize the AVIOContext struct [14:41:44 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:da12d544bf0b: avcodec/vp9_parser: Check the input frame sizes for being consistent [14:41:45 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:486aa4fe39db: ffplay: Fix invalid array index [14:41:46 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:942c3bfbdfd1: avformat/oggdec: Fix integer overflow with invalid pts [14:41:47 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:3a6b27caf878: avcodec/ffv1enc: Fix assertion failure with non zero bits per sample [14:41:48 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:3988470ee355: avcodec/raw: Fix decoding of ilacetest.mov [14:41:49 CEST] <cone-356> ffmpeg 03Hendrik Leppkes 07release/2.8:65fff8e71ac9: cmdutils: remove the current working directory from the DLL search path on win32 [14:41:50 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:7a2329fac1ea: avcodec/h264: Put context_count check back [14:41:51 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:7132e71a841c: Update for FFmpeg 2.8.8 [14:41:52 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:e965fedf7e94: avformat/swfdec: Fix inflate() error code check [14:41:53 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:2b135f266dd3: avcodec/indeo2: check ctab [14:41:54 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:33ec0280f38a: avcodec/diracdec: Check numx/y [14:41:55 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:5a96b4b443d5: libavcodec/wmalosslessdec: Check the remaining bits [14:41:56 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:562f2ba4ed07: avcodec/aacenc: Tighter input checks [14:41:57 CEST] <cone-356> ffmpeg 03James Almer 07release/2.8:2f9bc30956fc: cmdutils: check for SetDllDirectory() availability [14:52:47 CEST] <BtbN> I think I'll just by a GTX1060 next month. And hope it works at all in my PC. [14:53:10 CEST] <JEEB> unless your PCI-e is derped, it should [14:53:29 CEST] <JEEB> also I'll probably just grab the 1080 because WhyNot >_> [14:53:49 CEST] <BtbN> I can't afford a 1080 right now. [14:54:02 CEST] <BtbN> I just need something more recent than Kepler for NVENC stuff [14:54:14 CEST] <BtbN> Can't test any HEVC patches, let alone the HEVC10 one on the ML. [14:54:56 CEST] <BtbN> I have a Sandy Bridge board, which has only PCIe 2.0. To get my GTX760 running, i had to get an experimental BIOS update from ASUS via mail. [14:55:50 CEST] <BtbN> Current plan is, to get a GTX1060 now, wait until Kaby Lake comes out, get a board with the new 200 series Chipset and an i7-7700k. [14:56:20 CEST] <BtbN> And run it with the same 1060 for the time being, until I can upgrade to a 1080. [15:04:02 CEST] <JEEB> yeah, the 1060 is pretty alright compared to f.ex. 960 [15:04:06 CEST] Action: JEEB has the 960 atm [15:09:53 CEST] <BtbN> I have a 760 right now, so anything is an improvement. [15:10:20 CEST] <BtbN> I don't want to go for the 1060 3GB edition though. 3GB doesn't seem worth it. [15:13:55 CEST] <JEEB> if you don't game, probably not [15:14:14 CEST] <JEEB> I've got a 2160p screen so games are starting to want more than 3GiB of VRAM [15:19:08 CEST] <BtbN> I only have 1080p, and the most I'd go for would be 1440p [15:19:24 CEST] <BtbN> But still, 3GB just isn't that much anymore. And the card is also slower with less cores. [15:39:02 CEST] <RiCON> BtbN: 1060 can handle 1440p as well, not highest settings-well but well enough [15:39:24 CEST] <BtbN> The 1440p screen I'll get will be 144Hz though [15:39:53 CEST] <RiCON> with gsync? [15:41:13 CEST] <RiCON> if not, just better to turn vsync off [15:41:42 CEST] <nevcairiel> if you are a gamer at all, then go get gsync, its just brilliant [15:44:11 CEST] <BtbN> Was thinking about the Acer XB271HUbmiprz [15:45:24 CEST] <nevcairiel> i have th acer xb270, ie. the predecessor to that, can recommend [15:46:01 CEST] <BtbN> But that will be in over a year. 1060 first, new PC, 1080, and finally the screen. [16:40:11 CEST] <ubitux> i'm not really convinced by the results of mestimate [16:41:09 CEST] <durandal_1707> default me? [16:41:57 CEST] <ubitux> esa, exhaustive one [16:42:15 CEST] <ubitux> but that might be only optimized for encoding [16:43:23 CEST] <durandal_1707> that one is slowest [16:51:14 CEST] <ubitux> durandal_1707: yes, but the result don't seem much relevant [16:51:31 CEST] <ubitux> at least from an optical flow PoV [16:51:47 CEST] <ubitux> ofc when targetting encoders that's another story [16:52:09 CEST] <ubitux> but here i have a video with panning on half of it, and i just see shuffles of directions [16:52:49 CEST] <ubitux> the encoded mvs used are actually much better [16:57:49 CEST] <ubitux> durandal_1707: wget http://b.pkh.me/sfx-sky.mov and then ./ffplay -flags2 +export_mvs sfx-sky.mov -vf codecview=mv=pf vs ./ffplay sfx-sky.mov -vf mestimate,codecview=mv=pf [16:58:43 CEST] <ubitux> in this case, if you're going to try to interpolate some kind of global motion (in a meaningful way, not encoder optimized), you'd better use the existing encoded mvs [16:59:35 CEST] <durandal_17> yes, i agree [17:00:32 CEST] <durandal_17> ubitux: expor_mvs is lavc option? [17:00:47 CEST] <ubitux> yes [17:00:56 CEST] <ubitux> flags2 are accessible in AVCodecContext [17:01:04 CEST] <ubitux> so decoders can export them through frame side data [18:37:33 CEST] <durandal_17> lol libav fixing pcx bugs, we fixed 4 years ago [19:05:00 CEST] <izacarias> I'm interesting in extract information about QoE from ffmpeg... like initialization time, number of video stops, sum of video downtimes... [19:05:01 CEST] <izacarias> Does anyone know if there is an easy way to do it? [20:27:51 CEST] <rcombs> so, lavc currently exports a lot of HEVC profiles as FF_PROFILE_HEVC_REXT [20:28:26 CEST] <rcombs> that macro expands to 4, which is technically what they're coded as in general_profile_idc, but isn't very helpful to the user [20:41:16 CEST] <cone-688> ffmpeg 03Michael Niedermayer 07master:7827813f8cb3: avfilter/motion_estimation: Fix warning: variable dir_x set but not used [20:47:31 CEST] <cone-688> ffmpeg 03James Almer 07master:ba3f32d07134: tools/crypto_bench: simplify gcrypt functions using a macro [20:47:32 CEST] <cone-688> ffmpeg 03James Almer 07master:cf16d620765a: tools/crypto_bench: add support for des [20:48:40 CEST] <BtbN> rcombs, there's more than MAIN and MAIN10? [20:50:01 CEST] <rcombs> BtbN: https://puu.sh/qPmPj/e2da1efb1f.png [20:50:38 CEST] <rcombs> the differences between them all are specified in what used to be XXX_reserved_zero_44bits [20:52:41 CEST] <rcombs> which is replaced by everything below general_frame_only_constraint_flag here: https://puu.sh/qPmXb/2202504f00.png [20:57:47 CEST] <rcombs> https://puu.sh/qPnj2/fb263e2cae.png [20:58:07 CEST] <BtbN> this must be new [20:58:13 CEST] <rcombs> version 2, 2015 [20:58:23 CEST] <rcombs> so& relatively new? [20:59:05 CEST] <rcombs> wonder what portion of it lavc decodes properly and just doesn't export usefully in avctx->profile and what portion it doesn't handle at all [20:59:46 CEST] <cone-688> ffmpeg 03Paul B Mahol 07master:e3fbfa561ebb: doc/filters: fix anequalizer docs [20:59:56 CEST] <rcombs> came up because apparently some consumer device manufacturers document support for Main 4:2:2 10 [21:00:40 CEST] <rcombs> (kinda weird that there's no Main 4:2:2 8-bit profile, but there is a Main 4:4:4 8-bit one?) [21:02:14 CEST] <rcombs> I mean, you could set the flags to 0b11110000 and effectively have a "main 4:2:2" (8-bit), it's just not documented as such [21:02:18 CEST] <fritsch> rcombs: that 4:2:2 10 <- is probably a typo [21:02:21 CEST] <fritsch> isn't it? [21:02:48 CEST] <rcombs> fritsch: it's consistent everywhere in the spec where the profiles are discussed [21:03:23 CEST] <fritsch> and in the detailed discussion it gets clear, that they really have that 2:2? [21:03:42 CEST] <rcombs> you mean in the HEVC spec, or in the device documentation? [21:03:47 CEST] <fritsch> device documentation [21:04:00 CEST] <rcombs> all I've got for that is https://www.samsungdforum.com/Tizen/Spec#2016TVSpec [21:04:10 CEST] <rcombs> "HEVC (H.265 - Main, Main10, Main4:2:2 10 )" [21:04:25 CEST] <fritsch> nice, my tv [21:04:31 CEST] <fritsch> i already tried main and main10 [21:04:33 CEST] <fritsch> which both worked [21:04:38 CEST] <fritsch> but did not have Main 4:2:2 10 [21:05:08 CEST] <rcombs> as in, you didn't have a sample, or you tried it and it didn't work? [21:05:29 CEST] <rcombs> if the former, would love if you could find a sample and test [21:05:31 CEST] <fritsch> yeah, sorry: I did not have a sample [21:05:57 CEST] <rcombs> wouldn't put it past Samsung to fuck up device docs so would be good to confirm [21:06:13 CEST] <fritsch> if you have a sample I can try and test [21:06:31 CEST] <rcombs> I'll look around [21:07:33 CEST] <JEEB> funky @ 4:2:2 [21:07:41 CEST] <rcombs> apparently there's a paper on best-effort decoding 4:2:2 10 as 4:2:0 8 [21:08:08 CEST] <JEEB> so far even the most funkiest broadcasts have been 4:2:0 10bit BT.2020-NCL [21:08:39 CEST] <fritsch> including the new german DVB-T2 [21:08:49 CEST] <fritsch> 1080p hevc 10 bit [21:09:01 CEST] <JEEB> the BT.2020 part is the most surprising [21:09:05 CEST] <fritsch> world is waiting on intel to release their broxton / kabilake [21:09:58 CEST] <BtbN> I'll get a Kaby Lake i7-7700k the moment it comes out [21:10:07 CEST] <BtbN> But it will be running Windows. [21:10:43 CEST] <rcombs> no idea where to find samples for this tbh [21:10:47 CEST] <fritsch> btw. nvidia vdpau also has no 10 bit hevc decoding support as of now, right? [21:10:56 CEST] <jamrial> that tv supports vp9 4k but no opus? [21:11:11 CEST] <BtbN> The only API from nvidia that supports 10bit is NVENC [21:11:24 CEST] <fritsch> BtbN: might be the first time amd (christian könig) will implement it first [21:11:33 CEST] <fritsch> and send patches to libvdpau / if needed [21:11:35 CEST] <jamrial> only vorbis, so no full webm support [21:11:42 CEST] <rcombs> I'll see if I can get some from Samsung or someone [21:11:47 CEST] <fritsch> i don't use the TVs decoding caps at all [21:11:48 CEST] <BtbN> Nvidia supports decoding it just fine in their hardware. They expose it via DXVA2 on windows i think? [21:12:00 CEST] <fritsch> yes, they do [21:12:08 CEST] <fritsch> but not via vdpau [21:17:11 CEST] <RiCON> http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-VDPAU-1.0-Released this mentions main10 support [21:18:24 CEST] <fritsch> afaik that's yet another phoronix article [21:18:43 CEST] <BtbN> https://cgit.freedesktop.org/vdpau/libvdpau/tree/include/vdpau/vdpau.h#n2490 [21:18:44 CEST] <fritsch> they get the prepared values from libvdpau [21:18:47 CEST] <BtbN> it does indeed have the profiles [21:18:51 CEST] <fritsch> but not what the driver supports [21:18:52 CEST] <fritsch> yes [21:19:00 CEST] <fritsch> but that does not mean the driver supports it [21:19:37 CEST] <BtbN> I can't find any 10 bit YUV pixel formats though [21:21:21 CEST] <fritsch> interally conversion to RGB :-( [21:21:24 CEST] <fritsch> and downscaling? [21:21:32 CEST] <fritsch> or converting to yuv 8 bit? [21:35:59 CEST] <rcombs> inb4 it's that "best-effort decode-as-4:2:0-8-bit" thing [21:39:04 CEST] <BtbN> DHE, https://gist.github.com/BtbN/42f8f581149920dc28da1afe71310948 [21:41:15 CEST] <DHE> BtbN: so now we don't copy side data into coded_frame ? [21:41:28 CEST] <DHE> conceptually it should work [21:43:32 CEST] <BtbN> I don't think there is supposed to be side data in there anyway [21:43:43 CEST] <BtbN> it was deprecated before side data even existed [21:44:03 CEST] <DHE> makes sense [21:44:18 CEST] <DHE> but the TV signal would include closed captions as side data [21:44:33 CEST] <BtbN> Which just comes out with the normal frame side-data [21:44:45 CEST] <BtbN> It's just the side data in the coded_frame that's removed here. [21:45:29 CEST] <BtbN> The fact that it accumulates an ever growing list of sida_data elements and nothing explodes because of it should be quite clear about how many users of that exist [21:45:51 CEST] <DHE> well, that's only used by API users. ffmpeg itself doens't use it [21:47:01 CEST] <DHE> I'm running the patch now in the same test [21:49:37 CEST] <BtbN> ./ffmpeg -f lavfi -i testsrc -c:v mpeg2video -s 320x240 -f null -y /dev/null [21:49:43 CEST] <BtbN> that command does not grow indefinitely for me [21:49:55 CEST] <BtbN> without any patch, that is [21:49:55 CEST] <DHE> testsrc produces side data? [21:50:00 CEST] <BtbN> oh [21:50:01 CEST] <BtbN> good point [21:50:31 CEST] <DHE> 20 minutes of encoding and memory usage seems to have long peaked out. [21:50:43 CEST] <DHE> that's 20 minutes of video, not wall clock [21:51:22 CEST] <BtbN> ah [21:51:30 CEST] <BtbN> you can make it emit side_data, using mb_info [21:53:28 CEST] <BtbN> mpeg2video doesn't seem to be the right codec to trigger that [21:54:52 CEST] <DHE> my source is ~14 hours of TV broadcast totaling around 54 GB [21:55:04 CEST] <BtbN> I mean the mpeg2video encoder [21:55:21 CEST] <BtbN> is not in mpegvideo_enc.c [21:56:30 CEST] <BtbN> i wonder why valgrind says it's being called [21:56:50 CEST] <DHE> memory usage is still increasing, but at a much slower rate. not sure if it's just normal memory variation or not... [21:57:12 CEST] <atomnuker> DHE: that's like, what, 8 mbps/second? [21:57:19 CEST] <DHE> ? [21:57:31 CEST] <atomnuker> (54*1024.0)/(14*60*60.0) [21:57:33 CEST] <BtbN> I'm confused as to why that change had any effect. mpeg2video is not in mpegvideo_enc.c [21:58:02 CEST] <atomnuker> most broadcast stuff I've seen won't go below 20 mbps [21:58:07 CEST] <nevcairiel> mpeg2 encoding does use mpegvideo_enc internally [21:58:12 CEST] <DHE> atomnuker: over 1 hour of video processed, RAM usage increased 3 megabytes... [21:58:18 CEST] <nevcairiel> even if the main thing is in another file [21:58:29 CEST] <DHE> atomnuker: it's H264 video, which is much lower bitrate. 7 to 8.5 is what I see, depending on the carrier [21:58:56 CEST] <BtbN> nevcairiel, ah, now i see the chain. [21:59:01 CEST] <BtbN> The valgrind output is very lacking then [21:59:01 CEST] <DHE> MPEG-2 in HD will go way up to 15 or even 18 megabits at times. ATSC broadcasts cap out near that [21:59:32 CEST] <DHE> BtbN: inlined functions do that. valgrind points at the correct line, but names the wrong function doing it [21:59:45 CEST] <BtbN> but a function which has a symbol is plain missing [22:01:38 CEST] <DHE> next time I'll have to compile with --disable-optimizations [22:02:28 CEST] <BtbN> nah, it's fine. I think that workaround should fix it. [22:03:04 CEST] <DHE> I'm going to want to run it under valgrind though. I'm still seeing a slow memory usage though, it's just a lot slower. seems to be around 1 megabyte per 20 minutes of video processed.. [22:03:31 CEST] <DHE> just need to convince myself it's allocator noise or it's actually a hidden allocation somewhere [22:04:45 CEST] <BtbN> Well, is it gone when you disable the coded_frame api? [22:07:22 CEST] <DHE> I didn't valgrind that version. Just ran it for an extended period and watched it with `top`. Looking at the overnights, I think I'm going to have to valgrind both [23:07:12 CEST] <durandal_1707> I gonna apply vaguedenoiser [23:12:59 CEST] <cone-688> ffmpeg 03Michael Niedermayer 07master:0c7979b43d5b: avfilter/motion_estimation: Fix pre processor formating [23:14:32 CEST] <durandal_1707> michaelni: how much is frame multithreading doable in lavfi? [23:18:31 CEST] <cone-688> ffmpeg 03Paul B Mahol 07master:0429ff4be674: avfilter: add vaguedenoiser filter [23:20:19 CEST] <michaelni> durandal_1707, a filter could implement frame multitherading without any changes to avfilter core. It could be done throgh core with multiple filter instances filtering several frames at once, there are probably more options and i wonder if this wasnt discussed before on ML [23:48:51 CEST] <jamrial> nevcairiel: does "make fate-h264-conformance-cvfc1_sony_c HWACCEL=dxva2" fail for you? [23:54:51 CEST] <jkqxz> jamrial: It will. That one has cropping on the left and top. [23:55:29 CEST] <jamrial> ah [23:55:34 CEST] <jamrial> kinda pointless having that fate option then, i guess [00:00:00 CEST] --- Sat Aug 27 2016

1 0

ffmpeg.log.20160826
by burek 27 Aug '16

27 Aug '16

[00:41:48 CEST] <DHE> durandal_1707: I opened a ticket for it, but since it seems to be based on old APIs I'm guessing it won't see much attention [00:55:03 CEST] <donics> when i use -r, it captures the video, but when i use -framerate it doesn't [00:55:41 CEST] <donics> maybe -r is just speeding it up [01:35:32 CEST] <Mista_D> lloking to keep -g 60 static no matter what and include scene change detetction i frames as well without interfering with a statcic gop interval... any advice? libx264... [01:35:44 CEST] <DHE> -x264opts no-scenecut [01:37:41 CEST] <Mista_D> want use static 60 frames interval + scene cut. but normally it'd go 0, 60, 65, 125... ; while looking for 0, 60, 65, 120... [01:39:14 CEST] <DHE> I'm going to disagree with that. H264 still allows for I frames. There's a special type of I frame called IDR (I + discard references) which are the true keyframes in H264 [01:39:39 CEST] <DHE> so choosing to force IDR when an I frame is sufficient is usually not useful except if you need a true keyframe (eg: for seeking) [01:39:49 CEST] <DHE> and I'm guessing that's not what you need [01:40:28 CEST] <Mista_D> -force_key_frames "expr:gte(t,n_forced*2)" ? [01:41:54 CEST] <Mista_D> woudl that force I frames? or IDRs? [01:42:21 CEST] <DHE> IDR [01:51:35 CEST] <Mista_D> DHE: thank you [02:31:06 CEST] <coyotenq> hi ppl, im fighting with nvencoder and 2 parallel streams limit [02:32:49 CEST] <coyotenq> anyone has a solution to solve this? the hard im trying to use (Quadro K620) for sure can do more than that [03:08:12 CEST] <`D`> Is it possible for the ffmpeg in debian to use shared library libvpx3 (1.5.0) from backports? [03:11:11 CEST] <c_14> probably not. Depends on whether the libvpx3 from backports is abi compatible with the libvpx3 you already have [03:11:27 CEST] <c_14> You'd either also have to pull ffmpeg from backports or build it yourself [03:12:42 CEST] <`D`> ffmpeg is from backports, but it's not picking it up. [03:14:26 CEST] <c_14> check the configure line if it has --enable-libvpx [03:17:22 CEST] <furq> https://packages.debian.org/jessie-backports/ffmpeg [03:17:28 CEST] <furq> it doesn't look like it depends on libvpx [03:17:38 CEST] <furq> oh nvm libavcodec does [03:18:10 CEST] <furq> it depends on libvpx1 which is dumb and you should probably report it to debian [03:28:02 CEST] <`D`> it works in debian testing so I doubt they will care. I guess libvpx3 is just a pointless package in backports. [03:29:37 CEST] <furq> backports packaging seems pretty haphazard [03:30:02 CEST] <furq> i've noticed a few things in there which don't make any sense [03:30:03 CEST] <`D`> I am using deb-multimedia backports, which I guess is just as bad. [03:30:44 CEST] <furq> probably worse [03:31:01 CEST] <`D`> well is supports more stuff, but this problem seems the same. [03:31:46 CEST] <furq> it should be an easy fix if you don't mind compiling the package yourself [03:32:16 CEST] <`D`> yes, I've done it before, but I'll weigh that and upgrading to testing. [03:32:38 CEST] <furq> i just run testing everywhere [03:32:46 CEST] <furq> never had any issues with it [03:38:28 CEST] <ytan> Hi there [03:39:47 CEST] <ytan> I have encountered some issues cross-compiling ffmpeg on an arm device. [03:40:39 CEST] <ytan> I test@ubuntu:~/Dev/ffmpeg_src/ffmpeg-arm$ ./configure --prefix=/home/test/Dev/build-arm/ffmpeg-armhf/ --enable-cross-compile --cross-prefix=${CROSS_COMPILE}- --arch=armhf --target-os=linux --pkg-config-flags="--static" --enable-shared --enable-libvpx --enable-libvorbis ERROR: libvorbis not found [03:41:00 CEST] <ytan> When I run configure, I get the following error: ERROR: libvorbis not found [03:43:01 CEST] <ytan> I don't know why that is [03:43:09 CEST] <furq> do you have it installed for arm [03:43:11 CEST] <ytan> $ arm-openwrt-linux-gnueabi-pkg-config --modversion vorbis [03:43:23 CEST] <ytan> when I check with pkg-config [03:43:28 CEST] <ytan> it tells me 1.3.5 [03:43:35 CEST] <ytan> that means it's there? [03:44:16 CEST] <ytan> $ arm-openwrt-linux-gnueabi-pkg-config --libs vorbis [03:44:27 CEST] <ytan> returns "-L/home/reccsi/Dev/build-arm/home/reccsi/Dev/build-arm/libvorbis/lib -lvorbis " [03:44:30 CEST] <furq> add --pkg-config="arm-openwrt-linux-gnueabi-pkg-config" to configure [03:45:09 CEST] <furq> failing that, pastebin the output of config.log [03:46:46 CEST] <ytan> no good [03:46:53 CEST] <ytan> let me show you the config.log [03:47:43 CEST] <furq> i take it you need to use that specific toolchain for openwrt instead of just using the generic ubuntu armhf toolchain [03:49:41 CEST] <ytan> the http://pastebin.com/QipLqHYX [03:51:08 CEST] <ytan> Yes it is. The toolchain is provided by the vendor. [03:52:42 CEST] <furq> what does pkg-config --cflags vorbis return [03:53:57 CEST] <ytan> -I/home/reccsi/Dev/build-arm/home/reccsi/Dev/build-arm/libvorbis/include -I/home/reccsi/Dev/build-arm/home/reccsi/Dev/build-arm/libogg/include [03:54:03 CEST] <relaxed> force its hand with, --extra-cflags="-I/path/to/prefix/include" --extra-ldflags="-L/path/to/prefix/lib" [03:55:26 CEST] <ytan> let me try [03:57:21 CEST] <ytan> same error [03:57:40 CEST] <relaxed> is vorbis/vorbisenc.h is in libvorbis/include ? [03:57:54 CEST] <`D`> well I finally managed to hunt down all the dev lib packages to build ffmpeg. had to leave x265 out since the version available is not compatible with ffmpeg git. [03:59:08 CEST] <relaxed> `D`: check out x265 master [03:59:10 CEST] <ytan> $ ls /home/reccsi/Dev/build-arm/libvorbis/include/vorbis codec.h vorbisenc.h vorbisfile.h [03:59:24 CEST] <`D`> relaxed, nah I don't need it. [03:59:26 CEST] <ytan> yea, the file is present [04:00:58 CEST] <relaxed> ytan: pastebin the ./configure you just tried [04:02:03 CEST] <ytan> 1 sec [04:02:27 CEST] <ytan> http://pastebin.com/cHiUXhEE [04:04:30 CEST] <relaxed> hmm, omit --pkg-config-flags=--static [04:05:30 CEST] <relaxed> oh wait, we're getting somewhere [04:05:57 CEST] <relaxed> now it can't find libogg- do that same for it's include/lib dir [04:06:06 CEST] <ytan> yea, I saw that [04:06:10 CEST] <relaxed> its* [04:06:27 CEST] <ytan> I think forcing with --extra-cflags helped [04:06:42 CEST] <ytan> now I'm getting this: [04:06:46 CEST] <ytan> ERROR: libvpx decoder version must be >=0.9.1 [04:07:29 CEST] <relaxed> you'll have to compile a more recent libvpx [04:08:09 CEST] <ytan> holy-- [04:08:24 CEST] <ytan> i did the same thing, using --extra-cflags [04:08:33 CEST] <ytan> now it configured successfully. [04:08:45 CEST] <ytan> Still I wonder. What gives? [04:09:16 CEST] <ytan> I wonder if my pkg-config is set up incorrectly. [04:10:10 CEST] <relaxed> correct, it returned "-L/home/reccsi/Dev/build-arm/home/reccsi/Dev/build-arm/libvorbis/lib -lvorbis" which is wrong [04:11:53 CEST] <ytan> oh... [04:11:57 CEST] <ytan> I see it now [04:12:16 CEST] <ytan> wow, what a blunder. [04:13:44 CEST] <ytan> I couldn't see why it's causing that problem though. [04:14:33 CEST] <furq> fwiw if you can use the generic toolchain you'll have a much easier time [04:14:55 CEST] <ytan> I would if I could. :) [04:15:05 CEST] <ytan> http://pastebin.com/sGman0u1 <== here is my vorbis.pc [04:16:47 CEST] <ytan> and this is my arm-openwrt-linux-gnueabi-pkg-config script ==> http://pastebin.com/PsRjw7XM [04:18:55 CEST] <relaxed> edit SYSROOT=/home/reccsi/Dev/build-arm to SYSROOT="" [04:20:12 CEST] <ytan> I've simplified to this: [04:20:14 CEST] <ytan> #!/bin/sh SYSROOT= export PKG_CONFIG_PATH=/home/reccsi/Dev/build-arm/pkgconfig exec pkg-config "$@" [04:20:24 CEST] <ytan> SYSROOT= [04:20:31 CEST] <ytan> export PKG_CONFIG_PATH=/home/reccsi/Dev/build-arm/pkgconfig [04:20:37 CEST] <ytan> exec pkg-config "$@" [04:21:52 CEST] <ytan> sorry [04:25:07 CEST] <ytan> thank you relaxed and furq [04:25:28 CEST] <ytan> please accept my kowtow to both of you [05:02:35 CEST] <Mista_D> Any way to set "-force_key_frames" to insert every 75 frames instead of seconds please? [05:04:07 CEST] <Mista_D> its like 2.502502502... seconds, that doesn't work exactly right. [05:09:24 CEST] <`D`> libvpx is at 1.6.0?? is this stable enough to use? [05:10:47 CEST] <furq> looks like it [05:13:07 CEST] <`D`> it's odd that html5 browsers do not support vp9 profile 1 yuv422 [05:13:25 CEST] <`D`> but chrome does yuv444 [06:27:07 CEST] <c_14> Mista_D: force_key_frames expr:eq(mod(n,75),0) [06:28:00 CEST] <Mista_D> c_14: Thank you! I used -force_key_frames "expr:gte(n,n_forced*75)" --- seem to work too. [06:28:38 CEST] <c_14> should do the same thing, ye [07:00:33 CEST] <Mista_D> Can extra key frames be addded please? "force_key_frames expr:eq(mod(n,75),0) + 50sec + 60sec" as well? [07:05:27 CEST] <c_14> sure [07:06:03 CEST] <c_14> force_key_frames expr:eq(mod(n,75),0)+eq(t,50)+eq(t,60) [07:06:47 CEST] <c_14> using '+' in an expression is the equivalent of a logical OR and '*' is the equivalent of a logical AND [07:11:20 CEST] <furq> i don't suppose there's a really fast way to count the number of i-frames in a file with ffprobe that i've missed [07:13:08 CEST] <furq> as in, faster than -skip_frame nokey -count_frames [10:15:21 CEST] <rossome> good ol' mr robot https://i.sli.mg/JkfWEM.jpg [10:26:08 CEST] <Threads> rossome is it me or is that a bad command [10:26:42 CEST] <rossome> with map? [10:28:01 CEST] <Threads> yep [10:28:07 CEST] <Threads> also output [10:29:16 CEST] <rossome> yeah overwriting the inpit essentially [10:29:46 CEST] <rossome> well after it runs she is propmpted to overwrite the file [10:31:04 CEST] <radia> Is there a command so that it automatically generates resolution, bitrate, video codec and audio codex to keep the webm file under 10 MB? [10:33:27 CEST] <rossome> radia: got this from a quick google [10:33:29 CEST] <rossome> http://stackoverflow.com/questions/29082422/ffmpeg-video-compression-specif… [10:36:20 CEST] <_jason_> hello there [10:36:48 CEST] <_jason_> how can i configure ffmpeg with --enable-opengl option? [10:38:30 CEST] <_jason_> anyone? [10:39:28 CEST] <whald> _jason_, i think "./configure --enable-opengl" might work [10:40:21 CEST] <ozette> _jason_: ./configure --help | grep opengl [10:40:48 CEST] <radia> thanks. [12:30:06 CEST] <Milad264> Hi [14:03:14 CEST] <JohnPreston72> Hi everyone. I am facing a few issues with FFMPeg which maybe you guys can help me with [14:03:54 CEST] <JohnPreston72> I am running on AWS G2 intance, which uses a GRID K520. I am running on Amazon Linux with the NVIDIA drivers and CUDA provided by the AWS repos. [14:04:10 CEST] <JohnPreston72> I have compiled FFMPEG from the release 3.1.3 [14:04:26 CEST] <JohnPreston72> compile passed just fine, but when I use ffmpeg it fails, as follows [14:05:14 CEST] <JohnPreston72> https://www.irccloud.com/pastebin/AXeiu4PG/ [14:05:44 CEST] <JohnPreston72> I am quite a n00b with ffmpeg generally speaking, so if there is anything you guys can see as wrong, help would be very welcomed [14:14:50 CEST] <ozette> i'm going to build an older version of ffmpeg and pray mp4 > m3u8 works [14:15:52 CEST] <ozette> i don't see a quick way to trace the SIGILL problem with 3.1.2 [14:20:34 CEST] <DHE> rebuild with --disable-asm and see if it solves your problem. if so, you can report it as a bug. if not, your compiler flags need fixing [14:20:42 CEST] <DHE> this applies to both ffmpeg and x264 [14:30:15 CEST] <ozette> will try that [14:33:37 CEST] <DHE> could have sworn I suggested that before... [14:34:33 CEST] <_jason_> hello [14:34:47 CEST] <_jason_> im having issue when compiling ffmpeg [14:35:28 CEST] <_jason_> $ configure --prefix=ffmpeg/ --disable-network --disable-debug --disable-yasm gcc is unable to create an executable file. If gcc is a cross-compiler, use the --enable-cross-compile option. Only do this if you know what cross compiling means. C compiler test failed. If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-user(a)ffmpeg.org [14:35:57 CEST] <_jason_> Include the log file "config.log" produced by configure as this will help solving the problem.ÿ [14:36:02 CEST] <DHE> pastebin the contents of config.log [14:36:07 CEST] <DHE> as indicated [14:36:56 CEST] <_jason_> i dont have any file config.log [14:37:12 CEST] <_jason_> i have config and Changelog two files [14:38:19 CEST] <JohnPreston72> gentle bump (if you've seen it) [14:39:16 CEST] <_jason_> found [14:39:31 CEST] <_jason_> should i paste the whole content on config.log here? [14:39:35 CEST] <_jason_> of* [14:39:49 CEST] <DHE> no, pastebin of your choosing. I like fpaste [14:40:05 CEST] <_jason_> i dont get you [14:40:33 CEST] <JohnPreston72> _jason_: instead of copy paste the whole change.log here, fpaste it [14:40:43 CEST] <JohnPreston72> https://paste.fedoraproject.org/ [14:41:27 CEST] <JohnPreston72> as asked earlier, anyone has any idea where this could come from ? [14:41:28 CEST] <JohnPreston72> https://www.irccloud.com/pastebin/AXeiu4PG/ [14:41:34 CEST] <JohnPreston72> I have been searching all night [14:41:46 CEST] <_jason_> https://paste.fedoraproject.org/414309/47221527/ [14:45:08 CEST] <DHE> do pthreads exist on mingw? [14:46:16 CEST] <DHE> actually it's odd because they were not requested in the compile commandline [14:50:13 CEST] <JEEB> there are packages that provide pthreads on mingw [14:50:21 CEST] <JEEB> but by default not included [14:50:36 CEST] <JEEB> both x264 and FFmpeg have their own wrappers around windows threads [14:50:51 CEST] <JEEB> so having pthreads is not required [14:51:46 CEST] <AznGuy> Hi? [14:52:13 CEST] <AznGuy> Does anyone have experience with recording a rtsp streaming?> [14:52:31 CEST] <nonex86> + [14:54:31 CEST] <_jason_> whats pthread? [14:54:54 CEST] <_jason_> how can i get through this issue guys :( [14:55:28 CEST] <AznGuy> Currently working on a story. When in recording and the recording is stopped by hand the file seems correct. But when the stream is disconnected due network failure, can that causes the file to be corrupted or something like missing meta data? aka ( duration) [14:56:13 CEST] <AznGuy> (using ffmepg v2.2.2) [14:57:25 CEST] <nonex86> AznGuy: are you talking about cli? or you use ffmpeg muxer api directly? [14:57:58 CEST] <AznGuy> ffmpeg api directly [14:58:16 CEST] <AznGuy> ffmpeg ${RTSP_TRANSPORT_STRING} -y -i ${INPUT_STREAM} ${QUALITY_STRING} -an -f flv ${OUTPUT_FILE} [14:58:24 CEST] <AznGuy> for instance [14:59:05 CEST] <jkqxz> _jason_: Your compiler doesn't work - it tried to compile the simplest possible program and that didn't work, so configure gave up immediately. (Somehow it is trying to link with pthreads but can't, but that failure has nothing to do with ffmpeg.) [14:59:27 CEST] <ozette> well, --disable-asm still results in SIGILL when trying to transcode mp4 > m3u8 [14:59:40 CEST] <nonex86> AznGuy, you talk about cli :) [14:59:59 CEST] <AznGuy> ohw.. :( [15:00:20 CEST] <AznGuy> i guess i'm far from being an expert [15:01:50 CEST] <AznGuy> Point is: I'm maintaining some piece of video software and I'm not so sure what can cause this bug I described earlier.. [15:02:25 CEST] <_jason_> jkqxz: What should i do now? [15:05:05 CEST] <_jason_> anyone? [15:05:44 CEST] <_jason_> i'm having this issue when compiling ffmpeg. https://paste.fedoraproject.org/414309/47221527/ [15:05:45 CEST] <jkqxz> _jason_: Get a working compiler. [15:06:15 CEST] <_jason_> jkqxz: you mean mingw? [15:07:06 CEST] <AznGuy> _jason_: I think you need to understand compilers first.. how things link ... [15:07:30 CEST] <nonex86> _jason_ are you building your code for windows? [15:07:33 CEST] <_jason_> yes [15:07:48 CEST] <nonex86> well, then why dont you use msvc instead? [15:08:18 CEST] <_jason_> was trying to follow this video : https://www.youtube.com/watch?v=3yhkX0uaQGk [15:08:41 CEST] <nonex86> you have a problem with building or at configure steps? [15:09:43 CEST] <_jason_> configure steps [15:10:17 CEST] <nonex86> yeah, i already checked the config.log you are provided [15:10:31 CEST] <nonex86> wait a second, ill check a configure script [15:10:39 CEST] <_jason_> my goal is to enabl opengl [15:10:44 CEST] <_jason_> enable* [15:10:54 CEST] <_jason_> ok [15:11:16 CEST] <nonex86> last config.log messages related to pthreads, isnt it? [15:11:17 CEST] <_jason_> by default ffmpeg configure does not configure opengl. [15:11:27 CEST] <nonex86> so why dont you just disable pthreads [15:11:36 CEST] <_jason_> umm [15:11:40 CEST] <_jason_> --disable-pthreads? [15:12:05 CEST] <nonex86> yes [15:12:12 CEST] <_jason_> let me try [15:12:23 CEST] <nonex86> as you building for windows w32threads should be enough [15:12:36 CEST] <nonex86> also, i cant understand why you get this error [15:12:41 CEST] <handbrake-learne> hello [15:12:43 CEST] <_jason_> why? [15:12:46 CEST] <nonex86> i build ffmpeg on windows several times [15:12:52 CEST] <_jason_> i see [15:12:58 CEST] <nonex86> and everyting was fine [15:13:05 CEST] <nonex86> you dont need pthreads on windows at all [15:13:06 CEST] <_jason_> whats your fmmpeg version [15:13:16 CEST] <handbrake-learne> im using : ffmpeg -i input.mkv -vcodec copy -acodec copy output.mp4 to converts files... is there a ffmpeg gui interface i can use/ [15:13:16 CEST] <_jason_> yeah getting same error [15:13:17 CEST] <nonex86> last version i build was 3.0.0 [15:13:28 CEST] <_jason_> i'm using 3.13 [15:13:31 CEST] <_jason_> 3.1.1 [15:13:35 CEST] <_jason_> 3.1.3 [15:13:47 CEST] <_jason_> latest version [15:13:54 CEST] <_jason_> whats your mingw version [15:13:57 CEST] <nonex86> one more on your error [15:14:17 CEST] <nonex86> configure creates test program [15:14:25 CEST] <nonex86> and try to compile it [15:14:30 CEST] <nonex86> in your case its gcc [15:14:42 CEST] <nonex86> again, why dont you give a try to msvc? [15:14:52 CEST] <_jason_> ok let me try msvc [15:14:53 CEST] <nonex86> or just add pthreads support [15:14:57 CEST] <nonex86> to your mingw [15:15:06 CEST] <nonex86> for configure i used msys2 [15:15:11 CEST] <_jason_> ok i'll get back to you when checking boths these things [15:15:30 CEST] <_jason_> i'm using msys also [15:15:35 CEST] <_jason_> when comes with mingw [15:15:40 CEST] <_jason_> which* [15:16:00 CEST] <nonex86> for gcc my guess you just need to install some pthread devel packets [15:16:20 CEST] <nonex86> into your msys [15:17:00 CEST] <JEEB> why would you want to use pthreads with mingw-w64 (32bit or 64bit), though? [15:17:10 CEST] <JEEB> neither FFmpeg nor most of the sane libraries require it [15:17:58 CEST] <_jason_> JEEB: can you please tell how to reslove this issuue : https://paste.fedoraproject.org/414309/47221527/ [15:19:04 CEST] <JEEB> > --disable-yasm [15:19:09 CEST] <JEEB> you have no idea wtf you're doing [15:19:40 CEST] <JEEB> also why do you need opengl? [15:19:48 CEST] <JEEB> just out of interest [15:20:47 CEST] <kdehl> So um, is it reliable to assume that the first NAL unit of a H.264 stream is the SPS and hence contains the width and height of the video stream? [15:21:04 CEST] <JEEB> no [15:21:07 CEST] <kdehl> Okay. [15:21:19 CEST] <JEEB> there can be multiple parameter sets of different types or SEIs or whatever [15:21:35 CEST] <JEEB> you can only assume those kind of things when you control the full chain yourself and make sure you never get anything else than that first [15:22:16 CEST] <JEEB> kdehl: I'd say your system is borked [15:22:22 CEST] <nonex86> kdehl, depends [15:22:24 CEST] <JEEB> also you should not use ye olde msys or mingw [15:22:29 CEST] <_jason_> JEEB: My friend i want to enable open so that i can capture opengl texture from screen-capture-recorder. I can't capture full screen mode in games. [15:22:39 CEST] <JEEB> uhh [15:22:45 CEST] <JEEB> that's not what the opengl thing does [15:22:51 CEST] <nonex86> kdehl: only if you know the source of stream you can make an assumptions about [15:23:01 CEST] <JEEB> also sorry kdehl I mis-autotab'd :P [15:23:19 CEST] <JEEB> _jason_: your toolchain is mis-installed + you shouldn't use ye olde msys or mingw [15:23:29 CEST] <_jason_> JEEB: that's not what the opengl thing does. Can you explain? [15:23:42 CEST] <_jason_> ok fine [15:24:05 CEST] <JEEB> the "opengl" feature in FFmpeg is a very crappy output "device" which IMHO should have not been merged [15:24:13 CEST] <JEEB> it doesn't help you capture. at all [15:24:47 CEST] <_jason_> what it does then lol [15:24:54 CEST] <BtbN> ffmpeg cannot capture hardware-accelerated windows, let alone exclusive fullscreen games. [15:25:01 CEST] <BtbN> Use OBS. [15:25:33 CEST] <JEEB> _jason_: I just explained, it's an "output device" because someone cried enough and didn't want to maintain their thing separately. even though it doesn't really fit the library [15:25:55 CEST] <JEEB> _jason_: installing the 32bit or 64bit mingw-w64 toolchain from https://msys2.github.io/ probably is the least insane thing (also don't forget yasm because you definitely want those hand-written assembly optimizations :P) [15:26:15 CEST] <_jason_> <BtbN> : Yes i will try it later its in my todo list. [15:26:31 CEST] <BtbN> Trying thing that won't work first seems not too efficient. [15:26:55 CEST] <nonex86> _jason_ and Rabeet is the same guy... [15:26:56 CEST] <kdehl> nonex86: Right. [15:27:00 CEST] <kdehl> JEEB: I understand. [15:27:21 CEST] <nonex86> few days ago he already ask about capturing the opengl/directx surfaces afair [15:27:22 CEST] <kdehl> I just realized that I can just wait until I have a full frame available. [15:27:50 CEST] <kdehl> Then I most certainly know about the width and height of the stream. [15:27:59 CEST] <nonex86> kdehl, usually you dont, for example, if the source is file container [15:28:12 CEST] <_jason_> So its of no use enabling opengl in ffmpeg? it will not solve my full screen issue right? [15:28:27 CEST] <nonex86> kdehl, or, if the live source is rtsp source with sps/pps in sdp :) [15:29:03 CEST] <nonex86> sometimes you can easily get frame dimensions before decoding first frame, sometimes not :) [15:29:15 CEST] <kdehl> Right. [15:29:58 CEST] <nonex86> actually, you always can get frame dimension before decoding 1st frame in h264 :) just find sps/pps :) [15:35:04 CEST] <kdehl> Yeah. I'm pondering what to do... I'm using OpenH264 (as you know), but it doesn't seem to have a function to find the video resolution. [15:35:26 CEST] <kdehl> Wonder if it's any point writing a parser myself for that. [15:35:42 CEST] <nonex86> depends :) [15:35:49 CEST] <kdehl> It's a fun exercise. [15:35:52 CEST] <kdehl> I guess. [15:35:53 CEST] <nonex86> what do you want and what you need :) [15:36:03 CEST] <nonex86> its an easy task [15:36:14 CEST] <nonex86> to write golomb/bit stream parser [15:36:23 CEST] <kdehl> Yeah. The other option is that I can just start decoding until I have a frame available, then get the size out of that. [15:36:28 CEST] <nonex86> sure :) [15:36:41 CEST] <nonex86> thats why i like this word - "depends" :) [15:36:50 CEST] <nonex86> you almost always have a choice :) [15:36:56 CEST] <kdehl> But the point is that I want to allocate a buffer for the decoding, and so I kinda need to know the resolution before I start decoding! [15:37:23 CEST] <kdehl> Uh. Wonder how the test util does it. Haven't even thought of checking that. [15:37:44 CEST] <kdehl> Right. It just writes to a file. [15:37:48 CEST] <kdehl> Cheaters. [15:38:16 CEST] <nonex86> are you sure openh264 did not give you any abilities to get frame information after decoding sps/pps nalu? [15:38:38 CEST] <kdehl> No. [15:38:47 CEST] <nonex86> and you need to supply it [15:38:51 CEST] <nonex86> preallocated buffer? [15:38:55 CEST] <nonex86> to get a frame? [15:39:37 CEST] <kdehl> No, it allocates separate Y, U and V buffers for me. [15:39:56 CEST] <nonex86> ok, than no problem exists [15:40:07 CEST] <nonex86> you got your frame data [15:41:02 CEST] <kdehl> Yeah, I realized this has more to do with how I designed the decoding on a higher level. [16:21:27 CEST] <Spring> if I have say 130 images that I'm encoding to a GIF, and I set -framerate 15 and -r 15 is that using only the 130 images or adding inter-frames? [16:36:54 CEST] <ChocolateArmpits> Spring: that shouldn't do anything to the images [16:37:19 CEST] <Spring> ChocolateArmpits, by that you mean it will only use those images? [16:38:47 CEST] <ChocolateArmpits> Spring: Most likely, as far as I'm aware because 15fps isn't possible with gif timebase it should get rounded to 14.2fps or 16.6 fps depending on how this is implemented [16:40:29 CEST] <ChocolateArmpits> gif timebase works in increments of 0.01 second and that's the smallest single frame duration possible, 1 second is longest [16:43:28 CEST] <Spring> does ffmpeg use any advanced GIF frame blending techniques to optimize filesizes? [16:43:50 CEST] <Spring> such as only encoding the moving section of a frame [16:45:00 CEST] <ChocolateArmpits> Have no idea, options are limited to looping and delay between loops [16:45:28 CEST] <c_14> Spring: I'm pretty sure it doesn't. [16:45:43 CEST] <Spring> hmm, know of any other encoders I could use? [16:46:58 CEST] <iive> c_14: why do you think so? [16:48:22 CEST] <c_14> Oh, nvmd I think it might. [16:48:40 CEST] <iive> there is nothing advances in gif, afair it have only 1 bit alpha channel, and each frame just writes over the previous. [16:48:41 CEST] <c_14> iive: I said that because libavcodec encoders by default don't have reference to the last frame so they can't do comparisons like that. [16:48:51 CEST] <c_14> But the gif encoder actually stores the last frame in its private data [16:51:12 CEST] <c_14> Though the comparison is pretty basic, it only checks if the outer columns/rows are the same as the last frame and if so crops those rows/columns [16:51:32 CEST] <t4nk010> I am getting "*** glibc detected *** ffmpeg corrupted double-linked list" [16:51:42 CEST] <t4nk010> if anyone know how to debug this [16:51:53 CEST] <t4nk010> I have tried gdb and no hints in that [16:53:44 CEST] <iive> there is actually variable honor_transparancy that seems to be controlled by flags [16:54:08 CEST] <iive> yep [16:54:50 CEST] <iive> there is option "gifflags" that takes arguments "offsetting" and "transdiff" [16:57:57 CEST] <iive> and if i guess right, they should be enabled by default. [17:01:02 CEST] <Spring> optimizations like the first one mentioned here, http://blog.bahraniapps.com/gifcam/ [17:01:44 CEST] <Spring> the Pooh bear example. Gifcam has terrible quality output but was wondering if ffmpeg can do that same thing [17:02:08 CEST] <Vollmer> With ffmpeg 3.1.2 attempting to encode a ppm stream when I specify a framerate for the input stream (from stdin) I get - http://pastebin.ca/3705623 [17:02:22 CEST] <Vollmer> (pastebin also includes ffmpeg command used) [17:03:50 CEST] <iive> spilotro: yes, ffmpeg supports that, it uses one of the palette colors for transparency [17:04:11 CEST] <iive> and ffmpeg have a filter to create optimized palette. [17:06:39 CEST] <Vollmer> ooh for context the ppm is coming from gource using -o - [17:13:14 CEST] <Spring> man, gifflags is buried in the results [17:14:25 CEST] <Spring> doesn't seem to help with filesize however :/ [17:17:02 CEST] <c_14> Spring: probably because it's already on by default, you can try disabling it to see if it's doing anything for you. Also, as I mentioned before the algorithm it uses is pretty basic [17:17:46 CEST] <Spring> I will say that palette generation wise ffmpeg is very good [17:37:28 CEST] <ozette> how do you guys say ffmpeg? f-f-m-peg? fam-peg? ff-m-p-e-g ? [17:38:47 CEST] <ozette> or don't you say it at all.. write it down and show it to someone interested? [17:39:36 CEST] <drv> the first one is what I would guess is most common [17:41:00 CEST] <ozette> hmm [17:42:17 CEST] <ozette> i think it's tiresome to say f-f-m-peg all the time in coversation [17:46:01 CEST] <transhuman_> hi with ffmpeg I am using the following syntax ffpeg -f x11grab -s 640x480 -i :0.0+10,20 -vf format=pix_fmts=yuv420p -f v4l2 /dev/video2 & I am getting the following ----- Invalid MIT-MAGIC-COOKIE-1 key[x11grab @ 0x25401c0] Could not open X display. :0.0+10,20: Input/output error [17:47:09 CEST] <transhuman_> do i need to enable xhost + and X11Forwarding yes in /etc/ssh/ssh_config or does this have nothing to do with it since its not ssh? [17:47:38 CEST] <c_14> transhuman_: there's something wrong with your Xauthority [17:47:53 CEST] <c_14> Is this running on a local machine? [17:47:58 CEST] <transhuman_> yes [17:48:08 CEST] <transhuman_> but want to do it on remote machines too [17:48:09 CEST] <c_14> Does the user running the command own the X session? [17:48:35 CEST] <transhuman_> using sudo as the user so yes I would say so [17:49:01 CEST] <c_14> try something like xhost +local:username [17:49:09 CEST] <transhuman_> ok let me try thanks [17:50:14 CEST] <transhuman_> same thing c_14 [17:50:25 CEST] <transhuman_> should I log out and try again [17:50:44 CEST] <c_14> You said you're running this through sudo? sudo might be messing up your xauth stuff [17:51:04 CEST] <transhuman_> ah but i need sudo in order to direct it to /dev/video0 correct? [17:51:17 CEST] <c_14> In most cases no [17:51:25 CEST] <transhuman_> oh ok let me try then [17:51:36 CEST] <c_14> If you have standard unix permissions you just have to be in the "video" group [17:51:55 CEST] <c_14> If you have polkit/logind it may or may not do magic [17:52:55 CEST] <transhuman_> ok i added user to video group will have to log out as far as I am aware to get it to take affect correct? [17:53:01 CEST] <c_14> yes [17:53:15 CEST] <transhuman_> ok be back if that doesnt work ...if it does thanks in advance [18:51:07 CEST] <Mista_D> Can extra key frames be addded to a preset interval please? "-force_key_frames expr:eq(mod(n,75),0)" + @50sec ?? [18:57:50 CEST] <izacarias> Hi! [18:58:17 CEST] <c_14> force_key_frames expr:eq(mod(n,75),0)+eq(t,50)+eq(t,60) <- Mista_D [19:01:06 CEST] <izacarias> I'm interesting in extract information about QoE from ffmpeg... like initialization time, number of video stops, sum of video downtimes... [19:02:00 CEST] <izacarias> Does anyone know if there is an easy way to do it? [19:24:12 CEST] <DHE> that doesn't sound like something ffmpeg does directly. it doesn't typically feed users, just into a server like nginx-rtmp which would be better suited to that [19:27:13 CEST] <izacarias> :-/ maybe I could modify the logging mechanism to write log entries when certain events occur (buffer underrun etc..) [19:47:44 CEST] <Sashmo> Can anyone suggest how to find slates or frozen images in files using FFmpeg? I can do it with black screen just perfectly, but what about non blacks or frozens? [19:58:21 CEST] <durandal_1707> Sashmo: with tblend [19:59:09 CEST] <Sashmo> ok let me check it thanks durandal_1707 [20:00:31 CEST] <durandal_1707> mode difference [20:00:51 CEST] <durandal_1707> and then use blackdetect [20:01:11 CEST] <Sashmo> yeah reading that now..... I guess I can make some logic... if X frames = 0 difference [20:01:24 CEST] <Sashmo> how would you use blackdtect with that? [20:01:27 CEST] <durandal_1707> you may adjust colors with lutyuv [20:02:07 CEST] <Sashmo> cool durandal_1707 thanks I will experiment [20:02:09 CEST] <durandal_1707> you try with tblend to get black color for stills [20:02:33 CEST] <durandal_1707> and need high percent [20:02:43 CEST] <durandal_1707> very high [20:03:15 CEST] <durandal_1707> alternatively use lut2 filter [20:04:24 CEST] <Sashmo> alright I will experiment to see what I can do [20:04:33 CEST] <Sashmo> looks like wayyyy over my head though [20:05:24 CEST] <Sashmo> I guess I could use scene detection too [20:05:39 CEST] <Sashmo> but it will just give me the times of the detection [20:05:54 CEST] <durandal_1707> Sashmo: c0 mode is difference and c1, c2 mode is difference128 [20:07:21 CEST] <Sashmo> what is difference128 [20:08:35 CEST] <durandal_17> Sashmo: ffmpeg.exe -i VIDEO -vf tblend=c0_mode=difference:c1_mode=difference128:c2_mode=difference128,blackdetect -f null - [20:10:14 CEST] <Sashmo> I get it [20:10:23 CEST] <Sashmo> ok ill try that [20:10:28 CEST] <Sashmo> thanks! [21:14:39 CEST] <ultrav1olet> How can I embed an wav file into an mkv video? [21:15:21 CEST] <ultrav1olet> ffmpeg -i audio.wav -c:a copy out.mkv produces: [mp4 @ 0x82582e0] Tag [1][0][0][0]/0x00000001 incompatible with output codec id '65536' ([0][0][0][0]) [21:15:31 CEST] <ultrav1olet> and "Could not write header for output file #0 (incorrect codec parameters ?): Invalid data found when processing input" [21:15:46 CEST] <Threads> ffmpeg -i audio.wav -acodec copy output.mka [21:16:03 CEST] <Threads> mkv = video [21:16:07 CEST] <Threads> mka = audio [21:16:55 CEST] <ultrav1olet> OK, here's the full command line: ffmpeg -loop 1 -i image.png -i audio.wav -c:a copy -c:v libx264 -vf fps=25 -pix_fmt yuv420p out.mp4 [21:17:17 CEST] <ultrav1olet> if I remove "-c:a copy" it works [21:17:23 CEST] <ultrav1olet> but I want PCM/wav audio [21:18:10 CEST] <Threads> ohh you want it encoded with the video [21:18:59 CEST] <ultrav1olet> out.avi worked [21:19:10 CEST] <ultrav1olet> looks like Matroska isn't the best container [21:19:12 CEST] <ultrav1olet> lol [21:19:20 CEST] <ultrav1olet> I thought it's the most versatile [21:22:55 CEST] <furq> but you're not using matroska [21:23:57 CEST] <fritsch> ultrav1olet: check the matroska spec ... [21:24:13 CEST] <furq> do you mean the part where it says "the extension isn't mp4" [21:24:17 CEST] <ultrav1olet> furq: what am I using then? [21:24:23 CEST] <furq> you're using mp4 [21:24:23 CEST] <ultrav1olet> omg [21:24:28 CEST] <fritsch> :-) [21:24:29 CEST] <ultrav1olet> sorry [21:24:47 CEST] <ultrav1olet> haven't slept enough today [21:24:53 CEST] <ultrav1olet> thanks ))))) [21:26:12 CEST] <ultrav1olet> "loop 1" loops forever even though my wav file is long read out. How can I force ffmpeg to output the file which matches the length of my wav file? [21:26:19 CEST] <furq> -shortest [21:26:27 CEST] <ultrav1olet> thanks! [21:26:52 CEST] <ultrav1olet> furq: where does it go? [21:26:58 CEST] <ultrav1olet> before all "-i"'s? [21:27:05 CEST] <ultrav1olet> or after them? [21:27:09 CEST] <furq> it's an output option [21:29:15 CEST] <ultrav1olet> thanks again [21:34:08 CEST] <ultrav1olet> I'm encoding a soundtrack with a poster for youtube - I wonder if it'll accept keyint=3000 for my video :-D [21:34:37 CEST] <furq> -vf fps=6 [21:34:51 CEST] <furq> you could use 1 but youtube won't go any lower than 6 anyway [21:35:01 CEST] <ultrav1olet> furq: you're sure about 6? ;-) [21:35:25 CEST] <furq> i used to get bad desyncs with 1, idk if that was fixed [21:35:36 CEST] <furq> but the lowest fps youtube will encode to is 6 [21:35:43 CEST] <furq> so you might as well do the same [21:35:50 CEST] <ultrav1olet> I set fps 10 just to be sure [21:36:26 CEST] <furq> "desyncs" meaning the total file length was a few seconds too long, since obviously you can't desync a static image [21:36:36 CEST] <ultrav1olet> lol [21:37:12 CEST] <ultrav1olet> the resulting video bitrate almost matches the source audio bitrate ;-) [21:37:21 CEST] <ultrav1olet> keyint for static videos rules [21:37:46 CEST] <ultrav1olet> seeking will be broken completely though [21:37:55 CEST] <furq> youtube will reencode it anyway [21:39:01 CEST] <ultrav1olet> I know [21:45:27 CEST] <ultrav1olet> something is very wrong, darn [21:45:53 CEST] <ultrav1olet> tCfLNEnWsHA around 12 seconds from the beginning [21:47:21 CEST] <ultrav1olet> only at fullHD [21:47:31 CEST] <ultrav1olet> Is it just my PC? [21:48:00 CEST] <furq> if it only happens at one quality setting then it's probably not worth worrying about [21:48:19 CEST] <ultrav1olet> furq: only with Google Chrome - weird [21:48:29 CEST] <ultrav1olet> Firefox plays this video just fine [21:48:40 CEST] <furq> cache refresh [21:49:12 CEST] <ultrav1olet> wow, Firefox and Chrome show totally different colors [21:49:18 CEST] <ultrav1olet> Can anyone confirm? [21:49:46 CEST] <ultrav1olet> Firefox shows true colors [21:51:28 CEST] <JEEB> generally if you want "reference colors", use mpv to test and make sure you're using the opengl renderer [21:51:52 CEST] <JEEB> that in 99% of all cases barring your drivers failing at life should give you the closest to "reference look" you can get in many apps [21:51:55 CEST] <ultrav1olet> JEEB: under mpv/mplayer everything is fine [21:52:07 CEST] <JEEB> mplayer is older and different [21:52:17 CEST] <JEEB> latest mpv is the thing that you can *generally* trust [21:52:22 CEST] <ultrav1olet> Only Google Chrome botches everything [21:52:38 CEST] <JEEB> just saying that make sure you have a semi-sane reference thing instead of a browser [21:52:44 CEST] <ultrav1olet> I wonder if there's a bugzilla for youtube [21:52:55 CEST] <ultrav1olet> I have a source PNG file :) [21:53:01 CEST] <furq> echo "it doesn't work" > /dev/null [21:53:24 CEST] <ultrav1olet> http://imgur.com/a/0e3Kd [21:53:30 CEST] <JEEB> ultrav1olet: do note that ffmpeg can rape it in various ways with swscale. if it doesn't, great [21:53:39 CEST] <ultrav1olet> Now look at what youtube shows under Google Chrome [21:53:41 CEST] <JEEB> which is why I would pretty much always check with mpv your YCbCr video's output [21:53:43 CEST] <ultrav1olet> day and night, lol [22:36:20 CEST] <Mista_D> c_14: Thanks for the forced key frames advice. [23:54:28 CEST] <wallbroken> guys [23:54:56 CEST] <wallbroken> i need to estract a piece of video [23:54:58 CEST] <wallbroken> is possible? [23:57:46 CEST] <iive> wallbroken: usually. check the -ss -t -to and -c copy [23:58:49 CEST] <wallbroken> iive, it must be the range 24:23 - 25:11 [23:58:55 CEST] <wallbroken> how to set? [23:59:06 CEST] <wallbroken> the format is mp4 [23:59:48 CEST] <iive> -ss 24:23 -to 25:11 -c copy [00:00:00 CEST] --- Sat Aug 27 2016

1 0