[03:02:36 CEST] <bencc> I'm doing screen capture with: [03:02:37 CEST] <bencc> -vcodec libx264 -pix_fmt yuv420p -preset:v ultrafast -crf 0 [03:02:42 CEST] <bencc> and saving to mkv [03:03:08 CEST] <bencc> the mkv file size increases monotonically even when there is no change on the screen for hours. [03:03:42 CEST] <bencc> is it possible to change something so the file size won't increase without affecting the cpu load too much? [03:06:48 CEST] <furq> using -preset superfast will make a big difference [03:07:13 CEST] <furq> there's no way to stop the filesize from increasing at all unless you want to patch ffmpeg to support vfr output [03:07:34 CEST] <bencc> furq: it's ok if the file size increases [03:07:44 CEST] <bencc> but 1GB per hour with no change seems to much [03:07:50 CEST] <bencc> I'll try -preset superfast [03:08:15 CEST] <furq> i just tested with a static 1080p image and superfast takes about 10% of the space [03:08:42 CEST] <bencc> furq: that's huge difference. what about cpu? [03:08:58 CEST] <furq> 300ish fps for ultrafast, 200 for superfast [03:09:33 CEST] <bencc> nice [03:10:08 CEST] <bencc> In my case I only need 30fps with: -framerate 30 [03:15:33 CEST] <furq> actually it looks like vfr output is supported [03:15:42 CEST] <furq> you can try -vf mpdecimate to drop duplicate frames [03:16:01 CEST] <furq> the defaults will drop some non-duplicate frames though so you'll need to tune it [03:17:49 CEST] <bencc> furq: I'll read about "-vf mpdecimate" and try it. thanks [03:20:19 CEST] <dougquaid> I'm not sure if this is the right place to ask, but is there a video codec that supports GPS metadata? For example, if I have a dashcam with GPS, can I save the route I drove in the video's metadata? [03:21:51 CEST] <furq> mp4 supports location metadata [03:21:57 CEST] <furq> i don't know if you'd be able to store an entire route in it though [03:22:23 CEST] <k_sze[work]> aren't there container formats that support arbitrary data streams? [03:22:29 CEST] <furq> yeah obviously you could do that [03:22:34 CEST] <furq> it won't be readable by any tools though [03:23:59 CEST] <k_sze[work]> What you can do is cheat: encode the GPS metadata as subtitles. [03:24:04 CEST] <k_sze[work]> :P [03:24:12 CEST] <dougquaid> That's actually not a bad idea [03:25:34 CEST] <furq> just make sure cohaagen doesn't get hold of it [03:27:24 CEST] <k_sze[work]> Vilos Cohaagen? [05:50:20 CEST] <beauty> hello [05:50:39 CEST] <beauty> why av_frame_get_channels(frame) return 0, but frame->channels is 2? [05:55:28 CEST] <k_sze[work]> Are there some likely causes for avformat_free_context to result in segfault? [06:41:25 CEST] <k_sze[work]> Hmm, ok, why does avcodec_free_context and then avformat_free_context cause segfault? [08:14:21 CEST] <ritsuka> k_sze[work]: apple uses time metadata in mov for gps route, not sure if ffmpeg supports it [08:15:24 CEST] <k_sze[work]> ritsuka: ffmpeg is probably agnostic to it. [08:15:46 CEST] <ritsuka> right, probably you can get the raw samples from the track [08:16:53 CEST] <k_sze[work]> One would still write their own formatter and parser. I don't think there is any magic, unless you use some Apple API, not ffmpeg. [08:17:35 CEST] <beauty> why av_frame_get_channels(frame) return 0, but frame->channels is 2? [09:46:33 CEST] <sasha047> äîáðûé äåíü [09:50:36 CEST] <ootje> trying again today: what is the -filter_complex equivalent of -loop 1 -i image.png -t 2 ? tried -filter_complex "movie=image.png:loop=0, setpts=PTS-STARTPTS" -t 2 but it just renders on and on and on without stopping. tried adding ", trim=0:2" also but nope.. any takers? [09:51:15 CEST] <ootje> (even if i do :loop=100 it only seems to render one frame, am i doing something wrong with the setpts?) [10:45:35 CEST] <A124> Hello, can someone please give me an example how to take audio from an a/v file, encode that to aac and put it in mp4 container? [10:45:56 CEST] <A124> I am getting Output file #0 does not contain any stream [10:46:07 CEST] <A124> Maybe nevermind... the source might not have audio. [14:09:31 CEST] <termos> I'm having the same issues as described here: https://trac.ffmpeg.org/ticket/5319 does anyone know of some secret progress on this? [14:10:07 CEST] <JEEB> I would bet on "nothing after that change 6 months ago" [14:14:18 CEST] <wildefyr> why can't ffmpeg cut video accurately to the frame? [14:14:46 CEST] <wildefyr> usually when I cut video the audio is cut precisely but the video is not leaving a freeze of 'about' a second at the beginning of the video [14:15:29 CEST] <wildefyr> or the player interprets this as no video data and skips over the audio for that second, retaining the sync, but it's no good when I import the file into the video editor, or upload to youtube [14:32:17 CEST] <c_14> Are you copying the video? [14:33:00 CEST] <wildefyr> yeh, I'd prefer not to do re-encoding but it's not a requirement [14:33:18 CEST] <c_14> If you don't reencode the video you'll always cut at the nearest keyframe [14:33:49 CEST] <wildefyr> interesting [14:34:53 CEST] <c_14> It shouldn't cause the issues you're describing, but it might. [14:35:15 CEST] <nonex86> if you need frame accuracy usually you need to reencode first and usually last gop [14:35:21 CEST] <c_14> What you can do is either reencode the video, or write a script that uses ffprobe to get the timestamp of the closest keyframe to where you want to cut and use that as the cutting point [14:36:10 CEST] <c_14> Or what nonex86 mentioned, though that'll require cutting out the "middle portion" and then cutting out the other portions reencoding and concatenating [14:36:10 CEST] <wildefyr> the latter seems more applicable [14:36:51 CEST] <wildefyr> how would I get the keyframe with ffprobe? [14:36:57 CEST] <wildefyr> closest* [14:37:06 CEST] <nonex86> frame type=I [14:37:14 CEST] <nonex86> dump all frames [14:37:20 CEST] <nonex86> grep the certain type [14:38:05 CEST] <nonex86> what kind of stream we are speaking? h264? [14:38:44 CEST] <wildefyr> yes [14:38:52 CEST] <nonex86> not sure about one thing [14:38:59 CEST] <nonex86> when ffprobe report i frame [14:39:01 CEST] <nonex86> does it mean [14:39:03 CEST] <nonex86> idr [14:39:11 CEST] <wildefyr> well what you've said is confusing [14:39:15 CEST] <nonex86> and i frame with SEI recovery point [14:39:33 CEST] <wildefyr> I want to enter a timestamp and get the closest keyframe to the entered timestamp [14:39:40 CEST] <wildefyr> then cut from there [14:40:26 CEST] <nonex86> isnt ffmpeg muxer concat work this way? [14:40:51 CEST] <nonex86> it takes closest to keyframe pts and cut fragment? [14:40:57 CEST] <wildefyr> no [14:41:01 CEST] <wildefyr> well [14:41:05 CEST] <wildefyr> yes for video streams [14:41:10 CEST] <wildefyr> but I have audio as well [14:41:18 CEST] <wildefyr> that it cuts from the entered time and NOT the keyframe [14:41:30 CEST] <wildefyr> so I have audio that is out of sync from video [14:41:53 CEST] <c_14> ffprobe -skip_frame nokey -select_streams v -show_entries frame=pkt_pts_time -of default=nokey=1:nw=1 [14:41:54 CEST] <wildefyr> or frozen video frame until it syncs with audio [14:42:03 CEST] <c_14> Go through the list output from that command and pick the timestamp closest to what you want [14:43:50 CEST] <nonex86> few days ago i cut using ffmpeg from movie (h264 + aac) without any audio issue :/ [14:44:01 CEST] <nonex86> i didnt supply any special parameters [14:45:13 CEST] <nonex86> result fragment had video and audio in sync [14:45:17 CEST] <nonex86> at least it looks like [14:45:44 CEST] <wildefyr> well it depends on the player I think [14:46:08 CEST] <wildefyr> ie importing the cut file into a video editor makes the audio and video become out of sync [14:47:18 CEST] <nonex86> the players cant do anything, if the pts of the streams will be out of sync [14:47:33 CEST] <nonex86> dont think it was a player magic :/ [14:49:45 CEST] <Zucca> Hi. Does ffmpeg have a video filter that could copy parts that have no significant changes from previous frame to next one? I would use this to eliminate the wast of bits to render noice in the background. ImageMagick has the -fuzz switch for creating animations that acts close to this at least. So I could "pipe" the whole video trough IM, but that seems dirty... [14:52:31 CEST] <wildefyr> ah! [14:52:43 CEST] <wildefyr> -ss seeks if it's placed before -i [14:53:17 CEST] <wildefyr> if after it cuts there from the audio, and then the following keyframe for video [14:55:48 CEST] <DHE> Zucca: there's a "decimate" filter that drops frames when they are close enough to the previous frame. technically it produces a variable FPS output which you would then need to compensate for if you can't take that. [15:01:22 CEST] <Zucca> DHE: Ok. I'll see how that works. Thanks. :) [15:46:47 CEST] <Kadigan> VFR is evil. [15:47:12 CEST] <nonex86> variable frame rate? [15:47:22 CEST] <Kadigan> Yes. [15:47:52 CEST] <nonex86> well, if you need to merge several compatible streams [15:48:01 CEST] <nonex86> but with different frame rate [15:48:20 CEST] <nonex86> its the only solution - proper container with vfr support :) [15:48:30 CEST] <Kadigan> I should clarify: VFR is evil when you're trying to use some form of predictive frame stuffing/tweening. [15:48:56 CEST] <Kadigan> Unfortunately, this happens a lot in anime, esp. in the action genre. [15:48:58 CEST] <nonex86> ah :) [15:49:58 CEST] <Kadigan> There's this thing called SVP (Smooth Video Project) for Windows which does that -- it tweens until the frame rate matches the display refresh rate. Each time FPS changes, the buffer needs to be rebuilt, which results in a noticeable jerk. [15:50:03 CEST] <Kadigan> Meh. [15:50:34 CEST] <nonex86> frame tweening sounds like a magic [15:50:47 CEST] <nonex86> i did not say the simple blend from one frame to another [15:50:53 CEST] <nonex86> *did not mean [15:51:11 CEST] <Kadigan> Yeah, they do proper motion vector detection and compensation, along with artifact masking and such. [15:52:03 CEST] <Kadigan> The result, when it works well, is smooth but sharp animation. [15:52:17 CEST] <nonex86> its better than nothing i guess [15:52:29 CEST] <Kadigan> And yes, it works best with high-quality content. [15:52:55 CEST] <Kadigan> Well, I suppose it's the PC's counterpart to what TVs do... Used to hate that, I did. [15:53:05 CEST] <Kadigan> (makes film material look TV-like) [15:53:15 CEST] <nonex86> too much blur? :) [15:53:31 CEST] <Kadigan> No, the main difference is in the time resolution/domain. [15:53:41 CEST] <Kadigan> Film = 24fps, something, [15:53:48 CEST] <Kadigan> while TV is either 50i or 60i [15:54:13 CEST] <Kadigan> Less spatial resolution, more temporal resolution. Film feels a bit unreal, while TV material typically looks like a reality show, [15:54:16 CEST] <Kadigan> or something... [15:54:32 CEST] <nonex86> isnt interlace here is another pain in the @ss? :) [15:55:01 CEST] <Kadigan> You know the difference when you go filming with your cheap-ass consumer camera, and it looks... well, like if YOU filmed it, not a pro film crew? :D [15:55:05 CEST] <Kadigan> That's the feel I mean :D [15:55:51 CEST] <Kadigan> Try filming it in 24p, or 24/1.001 -- it'll feel very different. [15:56:40 CEST] <Kadigan> As for interlacing, I believe YADIF is sufficiently advanced to basically IGNORE interlacing at this point. ffmpeg will crunch it down just as well. [15:57:16 CEST] <Kadigan> (actually, if you ask YADIF to rebuild frames from fields, 1:1 fi:fr, and set PTS accordingly, you'll get slow motion with that "filmic" look!) [15:59:42 CEST] <nonex86> that SVP thing, is it commercial or opensource? [16:02:17 CEST] <nonex86> nevermind, found it :) [16:07:33 CEST] <Kadigan> You want madVR and MPC-HC with that, I suppose ;) [16:42:04 CEST] <termos> My encoded h264 and aac works by itself but when I mux it together in an FLV container everything is messed up. No audio and lagging picture. If I mux into mpegts everything is fine. Any ideas? [16:52:10 CEST] <nonex86> termos: what about your pts? [16:53:42 CEST] <nonex86> termos: how do you provide them? check the pts in both flv and ts files [16:53:53 CEST] <nonex86> termos: be sure they are correct in both case [16:54:18 CEST] <nonex86> termos: enable ffmpeg debug, check for warning/errors when muxing to flv [17:06:51 CEST] <termos> I could double-check my pts, but it's strange how it's working for mpegts isn't it? [19:29:15 CEST] <help> hi [19:29:43 CEST] <Guest30393> is there anyone here currently? [19:35:04 CEST] <maximq> Hi guys. I've been experimenting a bit with the Tesseract based OCR filter, which takes bitmaps/dvb subs input and outputs the text format to the frame metadata property 'lavfi.ocr.text'. What I want is to get this text into WebVTT and segmented into a mpegts. Would I need to write an intermediate filter to extract the frame metadata and use the output to the WebVTT encoder? Or can this be done more dynamically? [19:54:13 CEST] <c_14> maximq: probably [20:09:44 CEST] <DHE> can I specify the number of threads used by the filter_complex pipeline on the commandline like I can for codecs? [20:17:03 CEST] <DHE> I can do it in libav, but I can't find any way to do it in ffmpeg itself. [20:19:17 CEST] <BtbN> Doesn't the global threads option also count for those? [20:20:28 CEST] <DHE> I thought -threads was input/output sensitive [20:23:23 CEST] <DHE> whereas filter_complex is inherently a global thing, leaving the question of where does that work? [20:41:09 CEST] <BtbN> DHE, allocating the filter graph should do some option parsing, which then ends up setting nb_threads on the FilterGraph/AVFilterContext from the threads option [20:42:32 CEST] <BtbN> ffmpeg.c is probably also involved in that [20:42:35 CEST] <DHE> BtbN: that's not what I'm experiencing... [20:42:46 CEST] <DHE> actually, let me try one thing... [20:44:02 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg_filter.c#L1022 [20:44:18 CEST] <DHE> BtbN: wrapped in if(simple) which I assume means filter_complex doesn't apply [20:44:41 CEST] <BtbN> that's indeed odd. Seems like a bug [20:45:23 CEST] <DHE> yeah debugger confirms it's not being used. (test run with 1 input, 3 outputs, 4 instances of "-threads 1" on the commandline) [20:45:47 CEST] <BtbN> Just moving it out of the if(simple) should do the trick? [20:45:59 CEST] <BtbN> At least I'm not aware of a way to set filter graph opts via the commandline [20:47:33 CEST] <DHE> BtbN: https://paste.fedoraproject.org/456337/98918814/ here's the backtrace of a filter_complex being loaded [20:50:09 CEST] <DHE> nb_threads=0 and I don't see any place to set a number of threads [20:50:28 CEST] <BtbN> it should just carry over the encoder threads count imo [20:51:02 CEST] <BtbN> But I wouldn't be surprised if the filter_compley string has some way to pass opts to the filter graph itself [20:51:11 CEST] <DHE> okay that backtrace isn't applicable. that's used only temporarily... [20:51:18 CEST] <DHE> it should, but if there's multiple encoders which one does it use? [20:51:41 CEST] <BtbN> There should be one filter graph per encoder? [20:52:25 CEST] <BtbN> OutputStream *ost = fg->outputs[0]->ost; [20:52:29 CEST] <BtbN> So if there's more: The first one. [20:57:31 CEST] <BtbN> DHE, doesn't settings the threads option on the individual filter work? [21:00:34 CEST] <Parker__> Hey guys! I'm back! [21:01:13 CEST] <Parker__> Question: I have 1000 .ppm images that I want to convert into a movie and all of them have a white background [21:01:48 CEST] <Parker__> is there any tricks I could do to save on filesize yet maintain a lossless representation of the important pixels? [21:02:10 CEST] <klaxa> https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images [21:02:19 CEST] <klaxa> if you want lossless compression use a lossless codec [21:02:37 CEST] <Parker__> I'm using x264 [21:02:50 CEST] <Parker__> but for a 1 minute movie, the filesize is about 150 mb... [21:03:08 CEST] <Parker__> -c:v libx264 -preset veryslow -qp 0 [21:03:19 CEST] <klaxa> not gonna get any better than that [21:03:29 CEST] <Parker__> Mmm [21:03:34 CEST] <klaxa> you can *try* -preset placebo [21:03:36 CEST] <Parker__> if my images are mostly white background [21:03:42 CEST] <klaxa> but it will change it by 1-2% [21:03:46 CEST] <Parker__> is there anyway I could cut down on filesize? [21:04:02 CEST] <klaxa> it doesn't matter [21:04:21 CEST] <klaxa> the ppm images get decoded and then encoded with x264 [21:04:31 CEST] <Parker__> Mmmm [21:04:35 CEST] <Parker__> how can I make this smaller... [21:04:37 CEST] <klaxa> whether you save space in the images or not is irrelevant [21:04:49 CEST] <klaxa> use lossy compression [21:05:08 CEST] <Parker__> what would you recommend? [21:05:51 CEST] <klaxa> try -crf 23 and if it satisfies you stick with it, if not decrease by 2 or 3 [21:06:04 CEST] <klaxa> hint: use -t 10 to only encode 10 seconds of material [21:06:17 CEST] <klaxa> to check quality on a small sample [21:12:25 CEST] <DHE> BtbN: ffmpeg -threads -i INPUT -threads 1 -filter_complex "..." [-threads 1 -opts.... output1] [...repeat...] # is there a better syntax? [21:13:43 CEST] <DHE> this command runs ffmpeg with no threads except those produced by the call to configure_filtergraph(), so I think you're right about treating the threads bit there as a bug... [21:14:11 CEST] <DHE> I'm wondering if maybe a -filter_complex_threads option might be appropriate rather than taking -threads from the first output target [21:17:06 CEST] <DHE> or is that overcomplicating it? [21:20:57 CEST] <Parker__> klaxa: what about vp9? [21:21:11 CEST] <Parker__> do you have any experience with that lossy codec? [21:21:18 CEST] <klaxa> you can give it a try [21:25:38 CEST] <Parker__> maybe x265 [21:50:50 CEST] <furq> vp9 and x265 both have lossless modes [21:51:02 CEST] <DHE> BtbN: I'll see if I can make a patch to fix or improve things... the right way to fix it is still a bit of an open question though [23:06:29 CEST] <StrongBad> hi, can I get some help with my command syntax? I have an mp4 video file w/ audio and an m4a edited audio file. I'd like to replace the audio in the existing mp4 with the edited audio that I have. [23:06:54 CEST] <StrongBad> I've googled around for examples of other commands people have used, but I can't seem to find anyone doing exactly what I want to do [23:07:28 CEST] <StrongBad> edited audio is the m4a [23:11:42 CEST] <klaxa> ffmpeg -i video.mp4 -i audio.m4a -map 0:v -map 1:a -c copy replaced_video.mp4 [23:12:33 CEST] <klaxa> that will take the video from the 0th input (-map 0:v) and the audio from the 1st input (-map 1:a), copy the codecs and put it in replaced_video.mp4 [23:16:47 CEST] <StrongBad> this is what I just tried klaxa ffmpeg-3.1.4-win64-static\bin>ffmpeg -i C:\Users\$user\Desktop\ffmpeg-3.1.4-win64-static\files\video_trimmed.mp4 -i C:\Users\$user\Desktop\ffmpeg-3.1.4-win64-static\files\video_audio.m4a -map 0:v -map 1:a -c copy video_newaudio.mp4 [23:17:00 CEST] <StrongBad> it gives me this [mp4 @ 0000000002a25e00] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. [23:17:21 CEST] <StrongBad> may be more there, lots to read [23:17:26 CEST] <StrongBad> but that was highlighted [23:18:26 CEST] <StrongBad> ah wait [23:18:32 CEST] <kepstin> StrongBad: so, did it work? what's the problem? [23:18:45 CEST] <StrongBad> I think I'm stupid [23:19:01 CEST] <StrongBad> I didn't see anything show up in the working folder [23:19:15 CEST] <StrongBad> but I see I didn't put a path for the output, so I think it went into bin [23:20:06 CEST] <kepstin> yes, if you don't use a full path, it'll write to the current directory [23:21:03 CEST] <StrongBad> wonderful [23:21:09 CEST] <StrongBad> thank you klaxa [23:21:13 CEST] <b6s3d> im am trying to convert a mp4 file in 720p so it will be playable on psp and i get this error [libxvid @ 0x86980c0] Invalid pixel aspect ratio 477/272, limit is 255/255 reducing [23:21:18 CEST] <llogan> StrongBad: you can ignore that codecpar message (or use the git version as recommended, not the release version) [23:21:47 CEST] <b6s3d> i am using this command: for file in *.mp4; do outfile='/media/user/B056-729D/VIDEO/'$file; ffmpeg -i "$file" -b 450k -s 320x240 -vcodec libxvid -ab 128k -ar 48000 -acodec aac -strict -2 "$outfile";done [23:22:29 CEST] <b6s3d> ok [23:24:34 CEST] <b6s3d> llogan: https://pastebin.mozilla.org/8920527 [23:26:32 CEST] <furq> i thought the psp supported h264 these days [23:27:42 CEST] <b6s3d> i think it just ignores the error or changes it to standard? [23:27:58 CEST] <b6s3d> i see a working file on the computer, but don't know yet if it will work on the psp [23:28:51 CEST] <furq> if that was a warning and not an error then yeah, it just reduced it to a valid par [23:29:01 CEST] <furq> but you shouldn't use xvid unless you have a good reason to [23:29:11 CEST] <furq> apparently the psp supports 480p h264 [23:33:10 CEST] <StrongBad> thanks again klaxa , kepstin llogan [23:34:16 CEST] <b6s3d> well, i think i have a good reason? i have a psp. [23:34:32 CEST] <b6s3d> 480p h264 you say furq [23:37:27 CEST] <furq> according to google [23:37:55 CEST] <b6s3d> could you share a link or two? [23:40:32 CEST] <furq> i can but it's in japanese [23:40:34 CEST] <furq> http://wiki.crav-ing.com/index.php?PSP [23:41:24 CEST] <furq> `-s 640x480 -level 3.0 -profile:v main` should be all you need [23:41:37 CEST] <furq> or -s 720x480 -aspect 16:9 for widescreen [23:42:03 CEST] <b6s3d> could you add it to my command that i shared with you in that paste? [23:42:16 CEST] <b6s3d> 720x480 would be great [23:42:36 CEST] <furq> ffmpeg -i "$file" -s 640x480 -level 3.0 -profile:v main -c:a aac -b:a 128k -ar 48000 "$outfile" [23:42:45 CEST] <furq> assuming outfile ends in .mp4 [23:45:06 CEST] <b6s3d> ayy works without error messaging :D [23:45:32 CEST] <furq> actually the native res is 480x272 so you probably just want to use that [23:45:43 CEST] <furq> 480p is only useful if you're plugged into a tv [23:46:29 CEST] <furq> you'll need -level 2.1 for that [23:47:54 CEST] <JEEB> ay [23:53:32 CEST] <b6s3d> and how would that look like furq? [23:58:27 CEST] <b6s3d> bam: ffmpeg -i "$file" -s 480x272 -level 2.1 -profile:v main -c:a aac -strict -2 -b:a 128k -ar 48000 "$outfile" [23:58:38 CEST] <b6s3d> video is supported, but it can't play the file ? [00:00:00 CEST] --- Fri Oct 21 2016