[Ffmpeg-devel-irc] ffmpeg.log.20161009

[burek]

[02:13:37 CEST] <Enverex> Is it possible to use h264_qsv whilst a dedicated card is also present? My Broadwell iGPU is present and active (kernel sees it) but no combination of options in ffmpeg seem to work
[02:13:49 CEST] <Enverex> I -always- get "[h264_qsv @ 0x55c0555f5840] Selected ratecontrol mode is not supported by the QSV runtime. Choose a different mode."
[02:21:11 CEST] <jkqxz> Enverex:  You have a "-b:v $something" option already?  Add "-maxrate $something" too: the libmfx code declares ABR support but it isn't actually supported, so you need push it into using CBR instead.
[02:36:35 CEST] <Enverex> jkqxz: I do. Adding a maxrate didn't seem to help.
[02:36:46 CEST] <BtbN> Did you patch your kernel and stuff for QSV to work at all?
[02:37:06 CEST] <BtbN> If your intel card has a dri device, you can use it via vaapi.
[02:37:11 CEST] <Enverex> BtbN: I have all the deps installed, wasn't aware it needs kernel patches though, that's a bit extreme.
[02:37:34 CEST] <Enverex> BtbN: It's been assigned dri1 (my actual card's on dri0) so I'll try that.
[02:37:36 CEST] <BtbN> it needs kernel patches, libva patches, libdrm patches, and a patched/special libva-intel-driver.
[02:38:05 CEST] <BtbN> So basically, just use vaapi and forget QSV exists.
[02:38:06 CEST] <Enverex> Wow, that's really naff.
[02:40:50 CEST] <jkqxz> The one supported CentOS version does work.  Anything else is Not Fun to set up.
[02:42:06 CEST] <BtbN> It just messes up the entire system because it overwrites a bunch of system files.
[02:42:08 CEST] <jkqxz> (Definitely into "requires only minimal configuration and tweaking" territory <http://www.xkcd.com/1742/>.)
[02:45:58 CEST] <Enverex> Well I tried vaapi which gave me "Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto-inserted scaler 0'" so I added "-vf
[02:46:16 CEST] <Enverex> 'format=nv12,hwupload'" which is apparently needed, but that fails with [AVFilterGraph @ 0x5638a9b85a40] No such filter: 'format=nv12,hwupload'
[02:54:09 CEST] <Enverex> Should VAAPI need a lot of faffing around to work? x264 and nvenc seemed pretty simple but this one doesn't seem to like anything.
[02:55:47 CEST] <jkqxz> Paste your command line.
[02:56:24 CEST] <Enverex> It's a large script, I'll try and break it down to what it would be running
[02:58:31 CEST] <jkqxz> VAAPI only works with frames in GPU memory, so you need the hwupload instance to copy them there.  (Or do the whole operation there.)
[02:59:43 CEST] <Enverex> Is there a proper example of this anywhere? The few I've found were very basic and resulted in this error
[02:59:54 CEST] <Enverex> My command line is basically - ffmpeg -vaapi_device /dev/dri/renderD129 -vsync 1 -strict -2 -f x11grab -s ${currentRes} -i :0.0 -f pulse -ac 2 -channel_layout stereo -i default -c:a libfdk_aac -af volume=1.0 -b:a ${audioRate}k -cutoff 18000 -vaapi_device /dev/dri/renderD129 -c:v h264_vaapi -profile:v high -preset slow -b:v 10M ${recordLocation}
[03:00:19 CEST] <Enverex> (ignore vaapi_device being there twice, that's a copy/paste error)
[03:03:51 CEST] <jkqxz> My command line lying around for recording the screen in X:  "ffmpeg -y -vaapi_device /dev/dri/renderD128 -video_size 1920x1080 -framerate 30 -f x11grab -i :0 -vf 'hwupload,scale_vaapi=1920:1080:nv12' -c:v h264_vaapi out.mp4".
[03:05:28 CEST] <jkqxz> x11grab gives you bgr0, so you need the filter chain to convert as well as upload.  That one converts on the GPU side, "-vf 'format=nv12,hwupload'" would do the same thing converting on the CPU side.
[03:08:35 CEST] <Enverex> Same issue as before, "no such filter".
[03:08:42 CEST] <Enverex> Is there some way to list valid filters?
[03:08:49 CEST] <jkqxz> No such filter what?
[03:09:03 CEST] <jkqxz> ffmpeg -filters
[03:10:43 CEST] <Enverex> jkqxz: [AVFilterGraph @ 0x557ac979c8e0] No such filter: 'hwupload,scale_vaapi=1280:720:nv12'
[03:11:34 CEST] <Enverex> hwupload and scale_vaapi show as available filters...
[03:12:00 CEST] <jkqxz> Commas separate filters, they can't appear in filter names.  Is that some sort of weird character which looks like a comma but isn't, or something like that?
[03:13:03 CEST] <Enverex> Nope, tried again, copy/pasting your filter list as a test (and changing the res), but same error
[03:13:46 CEST] <jkqxz> Um.  Your shell is doing something nasty to the command, maybe?
[03:14:07 CEST] <Enverex> Yeah, it was the single quotes around the -vf argument
[03:14:18 CEST] <Enverex> -vf 'hwupload,scale_vaapi=1920:1080:nv12' doesn't work -vf hwupload,scale_vaapi=1920:1080:nv12 does
[03:18:10 CEST] <Enverex> Well, at least it's sorted. Thanks for the help
[06:06:25 CEST] <s0126h> hy is it that all scratched up DVD can  play fine    but  bluray with no visible scrach cannot even play fine
[06:10:16 CEST] <Wilawar> Might be bad luck or maybe the Blu-Ray is of lower quality
[06:58:28 CEST] <s0126h> wilawar they are all commercial dvd/bluray
[07:41:26 CEST] <Wilawar> Doesn't mean they're the same quality
[07:47:02 CEST] <Woof0> anyone know why I'm getting [AVFilterGraph @ 0x265ea60] No such filter: 'drawtext'
[07:47:02 CEST] <Woof0>  I've configured with  --enable-libfreetype but its not showing up   configuration: --enable-gpl --enable-nonfree --enable-pthreads --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-encoder=png
[08:18:30 CEST] <Woof0> Super weird I ./configured with --enable-libfreetype :/
[09:10:36 CEST] <bencoh> Woof0: missing freetype headers (-dev package on most distribs I suppose) ?
[09:12:01 CEST] <Woof0> bencoh: yeah I dunno lemme see
[09:14:44 CEST] <Woof0> bencoh: libfreetype6-dev is already the newest version (2.6.1-0.1ubuntu2).
[09:15:18 CEST] <bencoh> then you'll have to check config log
[09:20:09 CEST] <Woof0> which config logs are you refering to?
[09:23:13 CEST] <bencoh> config.log iirc
[09:25:07 CEST] <Woof0> libfreetype='yes'
[09:27:22 CEST] <Woof0> I mean there is alot of instances of freetype in the log file here but I'm digginaround and not really seeing anything that stands out
[09:31:00 CEST] <Woof0> Ah I thunk I may have fixerd it
[09:50:43 CEST] <Woof0> looks like its working
[09:50:58 CEST] <Woof0> and if I told you what the cause was ... lol
[10:21:23 CEST] <bencoh> meh, he could've explained the cause ...
[10:52:48 CEST] <kivutar> hello, what is the configure flag to have flac builtin?
[10:54:19 CEST] <relaxed> kivutar: flac support is built by default
[10:55:00 CEST] <kivutar> then I may have a flag that remove it, because I get the following error:
[10:55:13 CEST] <kivutar> Cannot find acodec flac.
[10:56:39 CEST] <kivutar> my version: http://dpaste.com/19FNZ3Q
[11:00:47 CEST] <relaxed> that's the record for most configure options
[11:01:21 CEST] <kivutar> I notice that i'm using
[11:01:22 CEST] <kivutar> --disable-encoders --enable-encoder=ac3 --enable-encoder=aac --enable-encoder=wmav2
[11:01:42 CEST] <kivutar> maybe I should do a --enable-encoder=flac?
[11:01:55 CEST] <relaxed> yes
[11:02:12 CEST] <kivutar> ok thanks
[11:02:28 CEST] <kivutar> I guess I need to package flac first?
[11:03:16 CEST] <relaxed> ffmpeg uses its own flac encoder
[11:03:52 CEST] <relaxed> I have arm build here, by the way
[11:03:58 CEST] <relaxed> builds*
[11:04:16 CEST] <relaxed> https://www.johnvansickle.com/ffmpeg/
[11:13:07 CEST] <kivutar> ok thanks, so I can remove my flac package
[11:13:23 CEST] <kivutar> i'm doing a distro from source, but thanks anyway
[12:57:36 CEST] <cowai> I am trying to distribute encoding with ffmpeg. I have split the source file into multiple segments with -f segment, encode them to libx264 csr 23 and DTS sound (using -c:a copy), I then concat them using -f concat with a file list. The result is that the transition between segments cause a small "lag" of about 0.25 second.
[12:57:55 CEST] <cowai> Is there any obvious faults I did here?
[12:58:29 CEST] <cowai> I did not specify keyframe interval in the encodes it self, maybe I need to do that?
[13:11:46 CEST] <BtbN> cowai, you have to make sure you only split at keyframes.
[13:11:59 CEST] <BtbN> Otherwise everything before the next keyframe will be lost at the beginning of a segment
[13:12:00 CEST] <furq> won't -f segment do that automatically
[13:12:09 CEST] <cowai> ah
[13:12:12 CEST] <BtbN> It should, but I wouldn't bet on it.
[13:12:13 CEST] <cowai> I thought it did.
[13:12:25 CEST] <furq> i'm pretty sure it does but there's no harm double checking
[13:12:37 CEST] <cowai> I tried to segment and then concat without reencoding now, and the lag is still there.
[13:12:48 CEST] <cowai> So I guess it doesnt segment by keyframes.
[13:12:55 CEST] <cowai> Thanks
[13:12:56 CEST] <BtbN> It might simply have no idea if there's a keyframe, after all the codecpar/coded_frame changes and everything
[13:13:25 CEST] <BtbN> you should open a bug with that
[13:13:30 CEST] <BtbN> That should not happen
[13:13:48 CEST] <cowai> I should try with latest static build
[13:13:51 CEST] <BtbN> Ideally including the sample.
[13:13:57 CEST] <cowai> Now I use a random ppa
[13:20:14 CEST] <furq> it looks like you  have to enable -break_non_keyframes to get it to not break only on keyframes
[13:21:27 CEST] <cowai> Why do I want that?
[13:21:47 CEST] <furq> you don't wan thtat
[13:21:56 CEST] <furq> it's off by default so that shouldn't be the problem
[13:22:23 CEST] <cowai> Ah, yes get it now.
[13:22:40 CEST] <c_14> You could check with ffprobe to see if the first and last frames are keyframes
[13:23:12 CEST] <cowai> They should right?
[13:23:35 CEST] <c_14> They should, yes.
[13:25:50 CEST] <cowai> Actually, The last frame on segment 1 and first frame on segment 2 should be the same keyframe?
[13:28:40 CEST] <cowai> note: pts_time is not reset on segment 2
[13:29:20 CEST] <c_14> I don't think so, it should be the next frame encoded as a keyframe.
[13:30:22 CEST] <cowai> last frame on segment 1: "packet|pts_time=885.218000|flags=_"
[13:30:34 CEST] <cowai> first frame on segment 2: "packet|pts_time=885.385000|flags=K"
[13:31:01 CEST] <cowai> last frame on segment 1 is not a keyframe.
[13:34:01 CEST] <cowai> One weird thing is that pts_time=885.218000 on the original source is a keyframe, but in segment 1 its a regular frame
[13:34:25 CEST] <c_14> But you reencoded inbetwen, no?
[13:34:34 CEST] <cowai> no
[13:34:46 CEST] <cowai> only segmented
[13:35:16 CEST] <cowai> first frame in original source: "packet|pts_time=0.000000|flags=K", segment 1: "packet|pts_time=0.167000|flags=K"
[13:35:37 CEST] <cowai> The lag I see could be 0.16~s long
[13:35:56 CEST] <furq> https://trac.ffmpeg.org/ticket/4676
[13:36:01 CEST] <furq> i wonder if it's the same issue as this
[13:39:28 CEST] <cowai> I use dts sound and the container is mkv.
[13:39:33 CEST] <cowai> But could be.
[13:39:45 CEST] <furq> well that issue definitely affects other containers
[13:39:57 CEST] <BtbN> Might be related to audio frames.
[13:40:10 CEST] <furq> if the root cause is that ffmpeg doesn't properly handle overlapping timestamps then all sorts of stuff could go wrong
[13:40:32 CEST] <BtbN> But audio frames are too short to cause that long of a gap
[13:40:44 CEST] <cowai> I could test without audio
[13:41:00 CEST] <BtbN> or re-encode the audio to raw pcm first
[13:41:03 CEST] <furq> i might try and find something with dts audio to test with
[13:41:24 CEST] <furq> i just tested with h264+aac in ts and the audio is choppy at segment boundaries
[13:49:00 CEST] <cowai> I dropped the audio and now there is no gap.
[13:49:13 CEST] <cowai> But the pts_times around the split is exactly the same.
[13:50:32 CEST] <cowai> So clearly its the audio.
[13:50:39 CEST] <BtbN> timestamps might get re-written, unless you specify copyts
[13:51:41 CEST] <cowai> Maybe I should just do the audio separately
[13:52:08 CEST] <cowai> segment the video, reencode them, merge back together with the audio from source.
[13:52:43 CEST] <BtbN> that's very hard to get right
[13:52:59 CEST] <BtbN> you easily end up with out of sync a/v then
[13:53:28 CEST] <BtbN> It's a bug that should be fixed. please open a bug on trac and include the sample if possible.
[13:53:31 CEST] <cowai> as long as the total duration is the same, it should sync up, right?
[13:54:13 CEST] <bencoh> when segmenting video I'd only transcode video, not audio
[13:54:45 CEST] <cowai> bencoh, any special reason for that?
[13:55:05 CEST] <bencoh> audio frames of fixed length
[13:55:37 CEST] <bencoh> not sure what ffmpeg does, but you supposedly might end up with blank/silence at the end of the last audio frame of every segment
[13:55:43 CEST] <bencoh> which would explain choppy audio in furq test
[13:56:01 CEST] <BtbN> as it's filling up the audio frame?
[13:56:13 CEST] <furq> yeah that bug report mentions padding frames being inserted
[13:56:14 CEST] <bencoh> avcodec does fill it
[13:56:26 CEST] <cowai> I remember having to produce 1second segments and the audio couldnt conform to 1s in 60p.
[13:56:46 CEST] <cowai> so the 1.000s would be 1.033s
[13:56:52 CEST] <cowai> or something like that.
[13:56:56 CEST] <bencoh> I once wrote a live video recorder+segmenter (ie live to mp4 segments) and transcoded audio *before* segmenting
[13:57:06 CEST] <bencoh> meaning I'd always write complete audio frames
[13:57:21 CEST] <bencoh> (hence no inserted padding)
[13:57:23 CEST] <furq> i don't see how the audio would get out of sync if you only segmented the video
[13:57:51 CEST] <cowai> Is there any information in the containers about when the audio frames will start?
[13:58:13 CEST] <BtbN> usually audio is put in a container just like video. As frames.
[13:58:14 CEST] <cowai> So when we merge them back together they could start at the exact time and they should have a small offset?
[13:58:20 CEST] <BtbN> Each frame contains X samples, and has a timestamp
[14:03:19 CEST] <cowai> BtbN: What do you suggest I do?
[14:04:01 CEST] <cowai> Can I fix this by properly segmenting the files based on keyframe info of ffprobe for instance?
[14:04:14 CEST] <cowai> instead of relying on -f segment
[14:11:48 CEST] <ffxx> how to enable hw acc with ffplay? there is -vcodec
[14:12:52 CEST] <ffxx> ffplay -vcodec what_goes_here h264_video.mp4
[14:16:49 CEST] <BtbN> ffxx, use mpv instead.
[14:17:02 CEST] <BtbN> ffplay is not designed for hardware acceleration at all.
[14:17:22 CEST] <BtbN> Not that it does not work in some way, but mpv works better.
[14:21:31 CEST] <cowai> Scratch what I said, I still see a small gap in the picture without audio too.
[14:22:49 CEST] <furq> does it happen with different segment containers
[14:23:15 CEST] <BtbN> Yeah, what container are you trying to segment into? And have you tried mpegts yet?
[14:25:29 CEST] <cowai> mkv to mkv
[14:25:40 CEST] <BtbN> Try ts.
[14:25:50 CEST] <furq> yeah ts is probably a better choice for the segments
[14:26:00 CEST] <cowai> I will try, thanks
[14:26:13 CEST] <BtbN> .ts and .flv are the only formats that work fine for segmenting/concat from my experience.
[14:27:05 CEST] <cowai> I have concatted mkv many times before with success.
[14:27:25 CEST] <BtbN> concating them is probably fine, but cutting them in segments is not
[14:27:56 CEST] <cowai> hold on
[14:27:59 CEST] <BtbN> .ts and .flv are trivial enough that a simple cat command can successfully concat them to a valid file.
[14:28:17 CEST] <__jack__> (meaning: they are a lot of overhead)
[14:28:27 CEST] <__jack__> have*
[14:28:39 CEST] <bencoh> flv doesn't exactly sound like a great choice though :D
[14:28:45 CEST] <bencoh> but ... as long as it works ...
[14:28:52 CEST] <BtbN> The overhead of ts and flv is negligible
[14:29:07 CEST] <BtbN> And flv is a nice format, if the codecs it supports are enough for you.
[14:29:13 CEST] <furq> it should be negligible in this case at least
[14:29:15 CEST] <BtbN> It's simple and robust
[14:29:24 CEST] <BtbN> The overhead of mpegts is not that bad at all
[14:29:41 CEST] <furq> i've seen mpegts files with >3GB of overhead compared to mkv
[14:29:59 CEST] <BtbN> That must have been very huge video then
[14:30:02 CEST] <BtbN> or very long
[14:30:08 CEST] <furq> it was off a blu-ray
[14:30:20 CEST] <bencoh> it also depends on how you mux it actually
[14:30:23 CEST] <BtbN> Then it was also with error-correction data.
[14:30:34 CEST] <BtbN> a simple remux to ts would have shrinked it probably
[14:31:49 CEST] <furq> i tested mp4 and ts segments a while ago and ts is about 8% bigger every time
[14:32:04 CEST] <furq> it's not a big deal though really
[14:32:08 CEST] <__jack__> 10% overhead on a simple sd-serie (200MB) for ts, for almost 0% with mkv
[14:32:17 CEST] <furq> they're only intermediate files
[14:32:28 CEST] <__jack__> mkv: 193MB, ts: 214MB (same content, streams copied)
[14:32:49 CEST] <furq> the m2ts i remuxed was 30GB, so 3GB was about what i expected really
[14:32:50 CEST] <__jack__> to me, that's "a lot of overhead", but indeed, it may be negligeable
[14:33:21 CEST] <furq> it's not worth worrying about for intermediate files
[14:33:41 CEST] <BtbN> mpeg-ts is designed for streaming
[14:33:45 CEST] <furq> ^
[14:33:46 CEST] <BtbN> so it contains a lot of redundancy
[14:34:07 CEST] <BtbN> which makes it very resilient against pretty much anything
[14:34:13 CEST] <furq> yeah that's desirable for this use case
[14:34:55 CEST] <furq> i would also generally expect segmenting to ts to be a more well-trodden code path
[14:35:01 CEST] <bencoh> well extradata at the begining would be enough for this usecase, but ... meh :)
[14:35:26 CEST] <bencoh> furq: I wouldn't bet on that
[14:35:41 CEST] <bencoh> especially for the merge part
[14:36:14 CEST] <furq> i just mean for segmenting
[14:36:22 CEST] <furq> segmenting to ts has got to be much more popular than segmenting to mkv
[14:36:53 CEST] <bencoh> ah, maybe ... but then again people segmenting to ts usually do it with hls in mind
[14:36:56 CEST] <furq> especially if there's code shared with the hls muxer
[14:37:00 CEST] <bencoh> meaning they target iStuff
[14:37:27 CEST] <bencoh> which is possibly one of the worst TS player spec-wise :p
[14:38:02 CEST] <bencoh> your timestamps might be completely fucked up and you wouldn't notice it
[14:38:32 CEST] <BtbN> segmenting to mp4 also works quite well now.
[14:38:48 CEST] <BtbN> Because as stupid as it is, it's a common usecase thanks to Browsers being trash
[14:40:22 CEST] <cowai> The segments are about 15minutes each. The mkv is 2.8GB, and the ts is 3.5GB.
[14:40:27 CEST] <cowai> So huge overhead.
[14:40:46 CEST] <BtbN> We should add mpi support to ffmpeg.
[14:44:06 CEST] <cowai> TS gives me the save gap.
[14:45:16 CEST] <cowai> Just to be sure. Here is my command for segmenting: "ffmpeg -hide_banner -loglevel error -i source.mkv -c copy -copyts -segment_time 885 -f segment segments_%03d.ts"
[14:45:55 CEST] <bencoh> 15:21 < cowai> Scratch what I said, I still see a small gap in the picture without audio too.
[14:45:57 CEST] <furq> does it work without -copyts
[14:46:02 CEST] <bencoh> what did you mean by that?
[14:46:23 CEST] <cowai> I tried both with and without audio in the segments
[14:46:41 CEST] <cowai> Both times, the concated result had a slight gap in the picture.
[14:46:49 CEST] <bencoh> what's a gap in the picture?
[14:47:03 CEST] <cowai> lag,
[14:47:26 CEST] <cowai> complete freeze of the picture for about 0.1s
[14:47:29 CEST] <bencoh> ah
[14:47:38 CEST] <cowai> right at the transition between the segments
[14:48:06 CEST] <bencoh> late pictures that eventually get dropped and/or trickplayed to catch with actual framerate?
[14:48:29 CEST] <cowai> I am not sure, there is no errors with ffplay.
[14:48:42 CEST] <cowai> It just looks like I hit pause
[14:48:49 CEST] <bencoh> what about vlc/mpv?
[14:50:36 CEST] <cowai> vlc: 2-3 seconds before the gap:
[14:50:36 CEST] <cowai> "core warning: playback way too early (-137311): playing silencecore debug: inserting 6590 zeroes"
[14:50:42 CEST] <cowai> There we have it.
[14:52:16 CEST] <BtbN> so the audio frame in the first segment is too long, and overlaps into the second one. And in the second segment, the timestamp get fixed up to start in parallel with the video, and when concating that, it messes up?
[14:52:53 CEST] <bencoh> could be yeah
[14:53:21 CEST] <BtbN> dts might not be the ideal format for split/concat, hm
[14:54:08 CEST] <bencoh> ?
[14:54:24 CEST] <BtbN> Never had that happen with aac
[14:54:51 CEST] <cowai> BtbN: if the audio frame is too long, and that is why the gap is visible in the concatted result, why is gap also visible in the non-audio version of the experiment?
[14:59:02 CEST] <bencoh> no audio means ... no audio at all?
[14:59:26 CEST] <cowai> -an
[14:59:36 CEST] <bencoh> even in segments?
[15:00:03 CEST] <cowai> I meant that I have tested with both segmenting with audio and without.
[15:00:29 CEST] <cowai> When I concat, the end result still has gaps around the time the segments have been merged.
[15:09:34 CEST] <cowai> Alright I think I fixed the whole thing. setting -segment_time_delta 3 made it not having any gap at all.
[15:11:56 CEST] <cowai> I think I will try to set -segment_time_delta to a really high number to let it adjust in all scenarios.
[15:13:25 CEST] <BtbN> Please report that bug.
[15:15:17 CEST] <cowai> I am not sure its a bug?
[15:16:31 CEST] <cowai> what is the point of -segment_time_delta if not for this ?
[15:16:41 CEST] <cowai> default for -segment_time_delta is 0.
[15:17:57 CEST] <BtbN> It should not produce broken output, even with it being set to 0.
[19:48:45 CEST] <teratorn> what filtergraph fragment is the -loop 1 ffmpeg cmd-line option equal to? :)
[19:49:40 CEST] <teratorn> e.g. if I need to loop a static frame (.png) at a given fps, do I use -loop or a loop filter? or a loop+fps filter? or?
[19:50:10 CEST] <furq> use -loop for images
[19:50:30 CEST] <furq> -loop and -framerate before -i
[19:50:31 CEST] <teratorn> and -frame_rate to set an explicit fps?
[19:50:38 CEST] <teratorn> right, ok
[19:50:58 CEST] <furq> actually if it's a single image then don't use -framerate
[19:51:00 CEST] <furq> use -r after -i
[19:51:41 CEST] <teratorn> well
[19:51:51 CEST] <teratorn> it has to loop for a specific amount of time
[19:52:06 CEST] <teratorn> and is concat'd with other streams
[19:52:22 CEST] <furq> if it needs to be the same length as an audio track then just use -shortest
[19:52:44 CEST] <teratorn> I was going to calculate the number of frames needed ahead of time, and try to do it with the loop filter
[19:52:51 CEST] <teratorn> and a setpts
[19:52:57 CEST] <teratorn> to achieve the right framerate
[19:53:17 CEST] <furq> you can probably use -framerate before -i with a single image as well
[19:53:23 CEST] <furq> i've never tried but i imagine that would work
[19:53:37 CEST] <teratorn> random google results suggest you can
[19:56:52 CEST] <teratorn> ok I can just use the -framerate and -loop 1 options before the -i, and use a trim filter in the graph to get as much time as I want
[19:57:07 CEST] <teratorn> this should work! ;)
[19:57:13 CEST] <teratorn> freaking <3 ffmpeg
[19:59:25 CEST] <teratorn> so, can I achieve the same thing entire within -filter_complex?
[19:59:29 CEST] <furq> probably
[19:59:31 CEST] <teratorn> *entirely
[19:59:43 CEST] <furq> image2's -loop doesn't map directly to a filter
[19:59:51 CEST] <furq> or at least my inept reading of the code suggests it doesn't
[20:00:05 CEST] <teratorn> well
[20:00:06 CEST] <furq> but there's no reason to use -framerate over -vf fps afaik
[20:00:29 CEST] <teratorn> my understanding was that the fps filter looks at existing timestamps
[20:01:01 CEST] <teratorn> if you just use a loop filter on a source that comes from a single static frame, with an assumed pts of 0 I guess, how can it possibly infer what to d?
[20:01:11 CEST] <teratorn> hmm
[20:01:29 CEST] <teratorn> maybe I'm over-thinking it
[20:01:49 CEST] <teratorn> hey I know, I'll just try it
[20:02:25 CEST] <furq> well -loop -i foo.png just spits out a 25fps video by default, so presumably it generates pts
[20:02:38 CEST] <furq> -loop 1 -i foo.png, rather
[20:02:42 CEST] <teratorn> e.g. what time does the loop filter set the pts values to when it does not have a display duration for the single input frame? does it assume one from a default fps?
[20:02:43 CEST] <furq> no idea how the loop filter handles that case
[20:04:02 CEST] <teratorn> well it does work somehow, because I do use the loop filter to loop a single frame that was trimmed out of a real video. just one frame. and it does loop it @fps without any explicit fps filter
[20:04:30 CEST] <furq> yeah i just checked, it defaults to 25fps
[20:05:27 CEST] <teratorn> yeah, I shouldn't be scared of reading sources. I've answered many ffmpeg questions that way :)
[20:05:42 CEST] <furq> well by "checked" i mean i ran it
[20:07:43 CEST] <teratorn> ffmpeg -i preroll1.png -vf fps=29.97,loop=9999:start=0:size=1,trim=start=0:end=1.0 out.mp4
[20:07:56 CEST] <teratorn> works for me ;)
[20:08:14 CEST] <teratorn> i don't like having to use loop=9999 though
[20:08:42 CEST] <teratorn> since I think ffmpeg has to actually process through all of them
[20:11:32 CEST] <teratorn> or maybe not... using huge values does not appear to slow anything down
[20:25:29 CEST] <teratorn> how do I plot a graph of immediate fps?
[20:25:45 CEST] <teratorn> just to sanity check files?
[20:27:59 CEST] <DHE> shenanigans with ffprobe -show_frames is the only thing I can think of
[20:55:31 CEST] <teratorn> [Parsed_concat_14 @ 0x1b1e120] Input link in1:v0 parameters (size 1280x720, SAR 1:1) do not match the corresponding output link in0:v0 parameters (1280x720, SAR 2835:2835)
[20:55:49 CEST] <teratorn> wat
[21:00:13 CEST] <furq> nice
[21:00:23 CEST] <furq> i guess you need an explicit setsar in there
[21:03:32 CEST] <teratorn> yeah, was about to try it... kinda dumb that they are equivalent SARs though
[21:09:18 CEST] <cowai> Is it normal that coded_picture_number with ffprobe is not always sorted and increasing?
[21:09:29 CEST] <cowai> Sometimes the next frame has a lower coded_picture_number
[21:09:34 CEST] <cowai> Only sometimes.
[21:11:25 CEST] <cowai> scratch that. I was thinking that was the index of the frame.
[22:22:40 CEST] <SouLShocK> are there any win32/64 builds with either libssh or libsmbclient enabled?
[22:28:12 CEST] <BtbN> Why do you need libsmbclient on windows?
[22:29:30 CEST] <BtbN> Doesn't just opening \\1.2.3.4\something\bla.ts just work natively?
[22:30:20 CEST] <furq> it does
[22:33:54 CEST] <SouLShocK> I wanted to see if I could get around the horrible performance from Windows' own smb drivers
[22:35:54 CEST] <BtbN> that's not a driver thing. Just SMB.
[22:36:25 CEST] <SouLShocK> well the Ubuntu samba driver is a lot faster than the windows samba driveur
[22:36:42 CEST] <SouLShocK> up to 15x faster
[22:37:05 CEST] <BtbN> For what usecase? Windows easily uses up my gigabit LAN here.
[22:37:26 CEST] <SouLShocK> using a samba share as destination for ffmpeg
[22:38:10 CEST] <SouLShocK> copying files is fast enough, sure. but when writing the ffmpeg output to \\server\share\file.mp4 ubuntu is many times faster than windows
[22:38:39 CEST] <SouLShocK> yet writing to c:\temp\file.mp4 is same speed as writing to the samba share in ubuntu
[22:39:13 CEST] <maziar> how to change mp4 bitrate with ffmpeg ?
[22:43:58 CEST] <SouLShocK> I was thinking of using sftp instead, since the files are going to be uploaded to akamai through sftp anyway. so might as well do it while encoding and save the time spent
[22:45:07 CEST] <furq> sftp will be much slower
[22:45:22 CEST] <BtbN> output to a network device will just slow down encoding immensely
[22:45:53 CEST] <SouLShocK> why would a network device be slower?
[22:46:03 CEST] <BtbN> because there's a network involved.
[22:46:17 CEST] <BtbN> Which is slightly slower and has a higher latency than a local disk that's also cached.
[22:47:03 CEST] <SouLShocK> copying the file to the network storage after transcoding is finished takes X seconds also
[22:47:28 CEST] <furq> use plain ftp if you can
[22:47:30 CEST] <SouLShocK> you're saying that copying after encoding would be, in most cases, faster?
[22:47:33 CEST] <furq> (over sftp, not smb)
[22:47:50 CEST] <furq> anything that goes through ssh has awful throughput
[22:48:14 CEST] <furq> also ftp is built in
[22:49:07 CEST] <BtbN> SouLShocK, not neccesarily for the same file. But in total, yes, definitely.
[22:49:22 CEST] <furq> it might not be the best idea with mp4 though
[22:49:35 CEST] <BtbN> as ffmpeg is single threaded, a slow output will slow everything else down as well
[22:49:40 CEST] <furq> you need seekable output for mp4 and there's a big disclaimer in the manual saying it's not recommended to rely on that working properly
[22:49:51 CEST] <furq> and i don't see the option at all for sftp
[22:50:40 CEST] <SouLShocK> yeah ffmpeg says mp4 over ftp is not possible
[22:51:32 CEST] <SouLShocK> [mp4 @ 0x40add80] muxer does not support non seekable output
[22:52:11 CEST] <SouLShocK> well I can build it to do the encoding to local harddisk and then ftp it over
[23:19:23 CEST] <ericwooley> When I stream video from a device, I get data as it happens, if I use pipe1 from a file, i get it as fast as it reads. is there any way to limit it to real time speed? I am trying to use a video file for testing
[23:19:46 CEST] <ericwooley> or i guess limit it to the fps of the file?
[23:20:04 CEST] <furq> ericwooley: -re before -i
[23:20:16 CEST] <ericwooley> furq to the rescue again
[23:20:22 CEST] <ericwooley> thanks you!
[23:26:51 CEST] <TwinTailed> furq: you're good with libav?
[23:27:49 CEST] <ericwooley> furq: I am running `ffmpeg  -re -i ../video-samples/file.mpeg -f mp3 pipe:1` and `ffmpeg -re -i ../video-samples/file.mpeg -f mpeg1video pipe:1` and collecting the output into buffers. Then sending both buffers somewhere else, and hitting play. This works with streams from avfoundation, but doesn't seem to work in when reading the mpeg file. Any ideas as to what might be happening differently?
[23:28:22 CEST] <ericwooley> the video buffer has way more of the video in it
[23:30:47 CEST] <ericwooley> Actually I might be really dumb and forgot to restart the process collecting the bufferes
[23:37:26 CEST] <ericwooley> yep, I was just dumb, thanks again
[23:48:32 CEST] <TwinTailed> There is a real mystery here in #ffmpeg... FFMPEG experts suddenly disappear leaving no trace in the middle of the conversation between you and them. I always imagine them typing then their wives tell them "Honey leave the PC and lets have sex", so they leave you with half an answer.
[00:00:00 CEST] --- Mon Oct 10 2016