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

[burek]

[03:13:37 CET] <ossifrage> I'm looking for a minimal dependancy h.264 systems library for taking elementary frames (with PTS as metadata) and generating a something that ffplay will play properly.
[03:14:38 CET] <ossifrage> Just giving ffplay the '-framerate' option works if the source is constant frame rate, but I'm starting to work with variable frame rate video
[04:10:51 CET] <DHE> any reason you can't put it in some kind of container? mkv or maybe mpegts could work
[04:15:52 CET] <t4nk820> Getting Past duration too large errors when converting from mp4 to xvid using -vcodec mpeg4 -vtag xvid
[04:22:55 CET] <ossifrage> DHE, yeah I'm looking for a lazy way to add the container (because it is only for debug)
[04:24:19 CET] <ossifrage> The hardware spits out a PTS and a list of NALs (size + offset) and a block of data, I've just been shoving the block of data at ffplay
[04:26:55 CET] <DHE> ossifrage: mpegts is used in broadcast, has a fixed timebase of 1/90,000, and has a somewhat high muxing overhead. but the (de)muxer is pretty straight-forward and is a widely supported format.
[04:27:06 CET] <DHE> mkv is much more complex, but is also more feature complete
[04:27:46 CET] <ossifrage> Yeah, I've been through the joy that is transport streams in a previous life...
[04:29:50 CET] <ossifrage> I am heavily resource limited because some hardware guy thought that 13MB of flash was plenty.
[04:31:20 CET] <ossifrage> I guess gpac or Bento are an option depending on how many deps they have in the minimal config.
[06:29:16 CET] <Delicates> Trying to build ffmpeg 3.2 on Gentoo with CUDA and CUVID support... I have nVIDIA CUDA Toolkit installed, but ./configure says it can't find CUDA. Any ideas?
[07:19:19 CET] <Alex> Delicates: WHat's the exact error from configure, OOI?
[07:27:37 CET] <Delicates> Alex: fatal error: cuda.h: No such file or directory
[07:28:14 CET] <Delicates> This is with nVIDIA CUDA Toolkit v8.0.44 installed btw
[07:30:53 CET] <Alex> I think I ended up using  -I /usr/local/cuda/include/  (or my equivalent dir) as it wasn't being pulled in properly.
[07:42:21 CET] <Delicates> Alex: considering I'm trying to use Gentoo ebuild system, I'd rather fix the environment whatever might be wrong with it
[07:54:54 CET] <kerio> ossifrage: 13mb?
[07:55:09 CET] <kerio> shit, i think a daily log file from my desktop takes more than that
[07:56:02 CET] <ossifrage> Yeah, I use a compressed filesystem (otherwise nothing fits)
[07:58:17 CET] <ossifrage> But a 16MB SPI flash part is really cheap. But you could buy alot of flash parts for the time I spent working around the lack of space...
[10:57:19 CET] <jcath> hello, friends
[11:00:16 CET] <jcath> the filter minterpolate, may i use it to do ntsc to pal framerate conversion?
[11:03:40 CET] <jcath> it seems that the filter is very slow, i only get about 1 fps with my i5 cpu, is it ok?
[12:29:46 CET] <fling> I have a video which is longer than audio and I want to sync them. There is a lot of dupe frames here and there and some of them need to be dropped to shorted the video by about 30 seconds in total
[12:29:57 CET] <fling> Which tool to use to accurately calculate frame numbers?
[12:36:08 CET] <fling> Do I need avidemux or openshot?
[12:36:52 CET] <fling> I can try to determine frame numbers with avidemux or to just drop the pieces with openshot&
[12:37:02 CET] <fling> What would be the proper way of syncing? :P
[13:58:41 CET] <fling> How is audio/video syncing happening when capturing from multiple live inputs at once (eg webcam with sound)? Is ffmpeg just dropping frames and inserting dupes sometimes to match the video timestamps to audio?
[13:59:36 CET] <fling> Then can't I easily capture a multiangle video?
[14:03:53 CET] <BtbN> there are no timestamps on webcam or audio captures
[14:04:04 CET] <BtbN> ffmpeg just makes them up
[14:05:32 CET] <fling> BtbN: right, so are they in sync because of the frame dropping and/or dupe injecting?
[14:05:40 CET] <BtbN> what?
[14:06:10 CET] <BtbN> they are in sync because they happen at the same time?
[14:07:16 CET] <fling> BtbN: no, they are should be running at different speed because webcam clock is not in sync with soundcard clock!
[14:07:32 CET] <BtbN> there is no "webcam clock" or "soundcard clock"
[14:07:33 CET] <fling> For example a capture from multiple sound cards will be out of sync
[14:07:41 CET] <fling> BtbN: ohh there is!
[14:08:17 CET] <JEEB> maybe there is, but whether or not that means anything in the FFmpeg context is a whole separate discussion
[14:08:21 CET] <fling> BtbN: I have a clock connector on my soundcard for syncing for other hardware for this purpose
[14:08:31 CET] <BtbN> that's nice for your soundcard.
[14:08:37 CET] <fling> JEEB: you are right
[14:08:38 CET] <BtbN> ffmpeg still uses unix time based timesamps.
[14:08:45 CET] <BtbN> +t
[14:08:53 CET] <fling> BtbN: ok, you are not getting what I'm asking about.
[14:09:05 CET] <JEEB> well, it uses whatever the "demuxer" or whatever utilizes
[14:09:20 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/alsa_dec.c#L40
[14:09:37 CET] <JEEB> basically if you use input modules X,Y,Z
[14:09:44 CET] <JEEB> you have to check WTF they do for their timestamps if anything
[14:09:45 CET] <furq> "an unix"
[14:09:52 CET] <fling> BtbN: the question is how it is getting the video to be synced with this ^ alsa captured audio?
[14:10:18 CET] <BtbN> how would it not be like that?
[14:10:33 CET] <fling> The webcam can't know the alsa times so it outputting the stream with it's own speed and ffmpeg is syncing this mess somehow together.
[14:10:43 CET] <BtbN> why would it need to know that?
[14:10:58 CET] <fling> It would not need
[14:11:01 CET] <BtbN> If a new frame comes from the webcam, ffmpeg puts a timestamp based on the current unix time in microseconds on it.
[14:11:07 CET] <BtbN> It does the same for audio frames.
[14:11:07 CET] <fling> It is ffmpeg's job to sync things together
[14:11:16 CET] <fling> ahh
[14:11:29 CET] <BtbN> So as long as your webcam or soundcard doesn't do stupid shit like delaying frame output, everything just works.
[14:13:23 CET] <fling> ok, so for example the alsa is running at system clock and the camera is a bit behind returning like 14.99 fps while we are capturing at 15 fps. What will ffmpeg do to sync this? Will it insert a dupe to the videosteam sometimes to get 15fps for the target?
[14:14:51 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/v4l.c#L292
[14:18:15 CET] <fling> Does this mean we will always have 15 frames per second in the output container?
[14:19:17 CET] <BtbN> If the webcam advertises a framerate and then delivers frames faster than that, it's plain broken and results might be undefined
[14:19:25 CET] <BtbN> If it's slower, ffmpeg will drop a frame at some point
[14:20:00 CET] <BtbN> ffmpeg assumes the webcam to be correct about its framerate.
[14:20:23 CET] <BtbN> No idea if there is a simple vfr mode
[14:20:26 CET] <BtbN> but doesn't look like it
[14:21:07 CET] <fling> Then is it possible to captre multiangle video easily if there is not much to get in sync?
[14:21:18 CET] <fling> I can have multiple ffmpegs running then.
[14:21:41 CET] <fling> for example for two webcams setup I will need two ffmpegs capturing the webcams and outputting to pipes
[14:21:53 CET] <BtbN> make sure to use wallclock for timestamps if you want to sync multiple independend files.
[14:22:01 CET] <fling> then another ffmpeg will be reading from pipes and muxing all the things together
[14:22:03 CET] <BtbN> and make sure that wallclock is accurate
[14:22:26 CET] <fling> wallclock?
[14:30:04 CET] <iive> system clock.
[14:30:25 CET] <fling> I don't get this.
[14:30:43 CET] <iive> audio cards have their own sampling clocks and they might drift (e.g. different temperature)
[14:30:46 CET] <fling> >> multiple independend files.
[14:30:49 CET] <fling> ^ no
[14:31:01 CET] <iive> same applies to video and it's timing.
[14:31:15 CET] <fling> right, this is why I'm asking how is ffmpeg syncing them.
[14:31:20 CET] <iive> since you capture from different sources, there might be small differences.
[14:31:31 CET] <fling> There should be!
[14:32:23 CET] <fling> iive: so is it just dropping frames and inserting dupes when needed to sync to the audio right?
[14:32:41 CET] <fling> Is not there such thing as a timestamp of each frame in the video stream for syncing to audio instead?
[14:33:00 CET] <iive> donno, ask BtbN  ;) what options make you use system clock .
[14:33:20 CET] <iive> i thought that v4l2 already provides monotonic timestamps.
[14:33:41 CET] <fling> Are timestamps going into the target container?
[15:21:08 CET] <fling> ffv1 is bad about dupes!
[15:21:28 CET] <fling> I mean it is compressing dupes bad
[15:41:50 CET] <kerio> ?
[15:52:00 CET] <xeuari> Hello all and happy Saturday
[15:52:14 CET] <xeuari> I have a question about compilation
[15:54:08 CET] <xeuari> I would like to use the vidstabdetect and vidstabtransform filters to stabalize a video. The documentation says 'To enable compilation of this filter you need to configure FFmpeg with --enable-libvidstab'. Does this mean I will need to compile a fresh copy and get rid of my apt installed version? Or is there a runtime configuration option somewhere?
[15:54:21 CET] <furq> you need to rebuild
[15:54:30 CET] <xeuari> nooo !!!
[15:55:40 CET] <kerio> rip
[15:55:48 CET] <xeuari> okay, I'm pretty shaky with building software .. could you point me in the direction of a makefile and such ..?
[15:56:05 CET] <kerio> https://ffmpeg.org/download.html
[15:56:13 CET] <kerio> check if you have the filter, tho
[15:56:20 CET] <furq> apt-get install build-essential; apt-get build-dep ffmpeg
[15:56:32 CET] <furq> then just copy the configure line from your installed ffmpeg and add --enable-libvidstab
[15:57:49 CET] <xeuari> oo ok .. where would I find the config line?
[15:57:55 CET] <furq> ffmpeg -version
[15:58:07 CET] <xeuari> ah .. quality
[15:58:12 CET] <furq> it doesn't look like vidstab is in apt so you'll need to install that separately
[15:58:24 CET] <xeuari> yeah .. thought so
[15:58:57 CET] <xeuari> does that need a separate download of transform or vid.stab then?
[15:59:45 CET] <furq> i assume you need vid.stab, yeah
[15:59:50 CET] <furq> i've never used it
[16:00:10 CET] <kerio> apparently deb-multimedia.org's ffmpeg has vidstab enabled by default
[16:00:27 CET] <furq> i wouldn't install anything from there
[16:00:37 CET] <xeuari> cool, I'm still getting to grips with what a library is
[16:00:42 CET] <kerio> furq: bad packages?
[16:01:15 CET] <furq> i forget the reason now but i remember them causing some problems in the past
[16:02:27 CET] <xeuari> I've read there's a package called transform which includes the vid.stab (plugin|library)?
[16:02:50 CET] <xeuari> reckon I can apt that and reference in at build time?
[16:03:07 CET] <furq> there's no debian package with that name
[16:03:59 CET] <xeuari> hmm seems you're right
[16:04:39 CET] <furq> https://packages.debian.org/search?searchon=contents&keywords=libvidstab.h&mode=path&suite=stable&arch=any
[16:05:06 CET] <xeuari> (I meant transcode)
[16:06:10 CET] <xeuari> I'm looking at Georg Martius' GitHub: https://github.com/georgmartius/vid.stab
[16:06:51 CET] <furq> i think that just means you can't do a single pass with ffmpeg
[16:06:57 CET] <furq> the transcode package on debian doesn't have vidstab
[16:07:30 CET] <xeuari> well that is but a minor inconvenience
[16:08:20 CET] <xeuari> This is pretty much a 1 off, I'm not building anything for other users
[16:11:06 CET] <xeuari> Am I right in assuming that, if I make this vidstab plugin, and put it somewhere in my $_PATH, ffmpeg will find it at build time without needing an absolute path?
[16:12:17 CET] <furq> it doesn't go in your $PATH
[16:12:34 CET] <furq> just run make install
[16:13:22 CET] <xeuari> (( noob confusion ))
[16:14:13 CET] <xeuari> but then how will ffmpeg locate in with a simple flag `--enable-libvidstab`?
[16:15:03 CET] <furq> it'll install to /usr/local/lib
[16:15:12 CET] <furq> although annoyingly on debian that's not in gcc's default search path
[16:15:15 CET] <kerio> xeuari: https://www.johnvansickle.com/ffmpeg/ has some static libs
[16:15:17 CET] <kerio> er
[16:15:18 CET] <kerio> static bins
[16:15:30 CET] <furq> oh hey that has vidstab
[16:15:37 CET] <furq> well that's a time saver
[16:15:55 CET] <kerio> indeed!
[16:16:23 CET] <furq> in that case disregard everything i said and just install those binaries
[16:16:37 CET] <kerio> put them in ~/bin/
[16:16:44 CET] <kerio> so you don't touch anything of the system
[16:16:55 CET] <furq> it's debian, you can safely mess with /usr/local/bin
[16:17:03 CET] <furq> and/or ubuntu
[16:17:03 CET] <kerio> still
[16:17:18 CET] <furq> you'll also want to uninstall ffmpeg from apt
[16:17:33 CET] <furq> i don't think debian puts ~/bin on your PATH by default
[16:17:44 CET] <furq> not that it's hard to change, but you might as well use /usr/local
[16:17:57 CET] <kerio> i think it does, if it exists
[16:18:15 CET] <kerio> sure, just keep track of what you put in there
[16:18:18 CET] <kerio> in general
[16:18:25 CET] <kerio> this time it's easy, it's just a handful of binaries
[16:26:17 CET] <xeuari> haha .. sweet. So i'm on Mint is Mint debian?
[16:26:43 CET] <furq> regular mint is based on ubuntu
[16:26:47 CET] <dl2s4> mint is ubuntu based afaik nd ubuntu is debian based
[16:26:47 CET] <xeuari> I'm happy with /usr/local
[16:26:49 CET] <dl2s4> afaik
[16:26:50 CET] <furq> there's a version which is based on debian
[16:26:53 CET] <dl2s4> ya
[16:27:05 CET] <xeuari> right ..there's some history I'm missing here methinks
[16:27:08 CET] <furq> but yeah they use fundamentally the same packaging and filesystem layout and whatnot
[16:27:15 CET] <xeuari> cool ok
[16:27:22 CET] <furq> debian packages will never touch /usr/local so you can do with it as you see fit
[16:27:50 CET] <furq> most stuff you compile yourself will go to /usr/local by default
[16:28:21 CET] <furq> this is one of the things that baffles me about the ffmpeg wiki ubuntu compilation guide which does some insane gymnastics to keep everything in ~
[16:28:27 CET] <furq> just put it all in /usr/local
[16:28:53 CET] <JEEB> well I would totally recommend a custom prefix and not everyone has access to root (/usr/local is indeed root-only by default in most systems)
[16:29:06 CET] <JEEB> for example I have ~/encoding_prefix myself, or ~/ownapps
[16:29:09 CET] <furq> i guess
[16:29:22 CET] <JEEB> those are also things I can relatively simply just clean up
[16:29:23 CET] <JEEB> if needed
[16:29:49 CET] <JEEB> but that is also OK for /usr/local as long as you know what exactly you've put there
[16:30:02 CET] <xeuari> sounds sensible .. my /usr/local only contains a few shell scripts and my stuff anyway  ..
[16:47:08 CET] <xeuari> success!! .. but (grr) I can't call it from command line without specifying /usr/local/bin/. Is there any harm in just whacking it straight into /usr/bin?
[16:48:24 CET] <c_14> xeuari: Just adjust your PATH?
[16:49:11 CET] <c_14> In ~/.profile or ~/.bash_profile or ~/.zprofile or whatever
[16:49:17 CET] <xeuari> hmm .. but can run my shell scripts just find from /usr/local/ .. so it must already be in there right?
[16:49:33 CET] <c_14> echo $PATH
[16:49:46 CET] <xeuari> null
[16:49:56 CET] <c_14> What shell is this?
[16:50:01 CET] <xeuari> oh i did echo $_PATH
[16:50:10 CET] <xeuari> *facepalm*
[16:51:09 CET] <kerio> xeuari: also try rehash
[16:51:18 CET] <kerio> or restarting your shell
[16:51:34 CET] <xeuari> nah they are all there ..
[16:51:38 CET] <kerio> there's no way /usr/local/bin is not in the path
[16:51:43 CET] <xeuari> is $PATH non recursive?
[16:51:47 CET] <c_14> yes
[16:52:35 CET] <furq> what happens if you just run ffmpeg
[16:52:42 CET] <furq> if it's running debian's ffmpeg then you'll want to uninstall that
[16:54:11 CET] <xeuari> no that's been purged .. it's fine, this is just a matter of tidiness now
[16:55:49 CET] <xeuari> thank you for your ninja linking people .. !!
[16:58:27 CET] <kerio> ^^
[17:58:39 CET] <BtbN> Anyone happens to know if ffmpeg is able to connect to a spice server?
[18:17:56 CET] <xeuari> hmm ffmpeg is complaining about trailing options on the command line ..
[18:18:38 CET] <xeuari> command: ffmpeg -i lightStrDemo.mp4 -vf vidstabdetect
[18:20:16 CET] <BtbN> looks more like you are missing the output.
[18:22:10 CET] <xeuari> yeah that too (The documentation says there is a default result file), but still trialing options for..
[18:22:16 CET] <xeuari> command: ffmpeg -i lightStrDemo.mp4 -vf vidstabdetect=result="lightStrDemoTransf.trf"
[18:23:14 CET] <furq> add -f null -
[18:24:15 CET] <BtbN> the vf does not apply to anything. So it's dangling and does nothing anyway.
[18:24:22 CET] <BtbN> You need an output
[18:24:25 CET] <xeuari> oh I see. ffmpeg itself needs an outputfile
[18:24:31 CET] <furq> BtbN: that filter writes a pass file
[18:24:45 CET] <xeuari> yeah it's a two pass thng
[18:24:56 CET] <BtbN> furq, so? Without an output it still does nothing.
[18:25:03 CET] <furq> oh
[18:25:10 CET] <furq> i thought you were saying a null output wouldn't work
[18:25:33 CET] <BtbN> ffmpeg options allways apply to the input or output that comes after them
[18:25:44 CET] <BtbN> so without such an option after it, it does nothing and is dangling
[18:25:44 CET] <xeuari> ffmpeg is currently running successfully after specifying an output
[18:26:25 CET] <xeuari> thanks for the vf tip.. I'm just being cautious and coying what i read in docs
[18:26:52 CET] <furq> https://github.com/georgmartius/vid.stab#usage-instructions
[18:27:26 CET] <furq> that looks more useful than the ffmpeg filter docs
[18:28:17 CET] <DHE> but the examples still specify an output file at the end of the command-lines
[18:28:29 CET] <DHE> even if it is 'null to stdout'
[18:29:42 CET] <furq> they sure do
[18:29:53 CET] <xeuari> aw yea, that looks good .. I'm there
[19:15:18 CET] <FishPencil> What are some decent commandlines for ripping Bluray's? I'm thinking x264 in an mp4 container, or maybe mkv
[19:19:33 CET] <larsi> mkv is the format that is more widely used FishPencil
[19:19:40 CET] <FishPencil> It'd like to retain as much quality as possible, so prettymuch visually lossless
[19:20:06 CET] <JEEB> FishPencil: you mean re-encoding a blu-ray? with libx264 it's hard to go wrong. first of all, do you have any plastic boxes or mobiles that you want this to play on? that usually sets you some limits more than else
[19:21:19 CET] <JEEB> otherwise it's the vlassic "encode 2500 frames or so with defaults" (preset medium and crf 23), then go down on crf if it looks bad, up otherwise
[19:21:32 CET] <FishPencil> JEEB: I'll probably be sticking to a laptop so VLC. Ripping a high quality bluray to a mobile phone size doesn't make sense to me.
[19:22:06 CET] <larsi> mp4 will most likely work better on low end devices and on old devices, but mkv is far better in terms of quality
[19:22:13 CET] <JEEB> and when you have found the highest crf value that still looks good enough you poke the presets to see which is the slowest stillnfast enough for you
[19:22:16 CET] <JEEB> eh
[19:22:26 CET] <JEEB> matroska has nothing to do with quality
[19:22:37 CET] <JEEB> it's a container for gawd's sake
[19:22:40 CET] <FishPencil> larsi: "quality"? The container doesn't effect the quality
[19:23:17 CET] <JEEB> what you stick into the container is what matters and there are of course more things you can stick into matroska than mp4
[19:23:37 CET] <larsi> yes, but an mkv container supports far more formats than mp4
[19:23:45 CET] <JEEB> whuch might or might not matter in your use case
[19:23:59 CET] <FishPencil> JEEB: If I don't care about encoding times, any reason to not just do -p:v veryslow
[19:24:14 CET] <JEEB> nope
[19:24:32 CET] <FishPencil> Do the tune settings matter anymore? Like -tune film
[19:24:36 CET] <JEEB> just stick to guesstimating your crf then
[19:24:51 CET] <JEEB> it can help, but not necessary
[19:25:15 CET] <FishPencil> How about audio? Blurays come as 5.1 DTS
[19:25:42 CET] <JEEB> unless you want to re-encode, just do -c:a copy
[19:26:03 CET] <JEEB> audio shouldn't be too big in general.compared to video
[19:26:33 CET] <JEEB> and I'm not sure if lavf can write dts into mp4 yet. it's specified but not often used
[19:26:46 CET] <microchip_> it can't
[19:26:54 CET] Action: microchip_ dislikes DTS with a passion
[19:27:01 CET] <FishPencil> I'd like to compress everything as much as I can but maintaining visually/audibly lossless
[19:27:27 CET] <microchip_> FishPencil: use E-AC-3 @ 768 kbits. Virtually transparent
[19:27:33 CET] <JEEB> well dts-hd ma isn't too bad as lossless audio :p
[19:27:55 CET] <furq> FishPencil: -tune does make a big difference
[19:28:10 CET] <furq> film and grain will obviously retain a lot more fine detail at the cost of higher bitrate
[19:28:14 CET] <FishPencil> E-AC-3 is better in compression than AAC LE?
[19:28:24 CET] <FishPencil> Or is it HE?
[19:28:24 CET] <furq> no
[19:28:30 CET] <JEEB> furq: but if you're eyeballing the crf anyways
[19:28:35 CET] <microchip_> FishPencil: it isn't, but it provides better quality than HE-AAC
[19:29:07 CET] <microchip_> FishPencil: you should not use HE-AAC unless you have a good reason. If you need AAC, stick to LC-AAC
[19:29:18 CET] <FishPencil> microchip_: But if it's worse compression wouldn't you still want to do HE-AAC @ 768?
[19:29:27 CET] <furq> yeah there's no point encoding to ac3 in 2016
[19:29:36 CET] <microchip_> FishPencil: no, as that's overkill for HE-AAC
[19:29:44 CET] <furq> keep it if you already have it, otherwise use aac or opus or something less ancient
[19:29:51 CET] <JEEB> furq:  you will get somewhat different coding of course (less deblock etc), but in the end when you're setting your crf you will get the quality you want
[19:29:57 CET] <FishPencil> I do like Opus
[19:30:19 CET] <microchip_> JEEB: problem is, many receivers don't do Opus or Vorbis :(
[19:31:02 CET] <furq> i was going to say "something more modern" but aac turns 20 next year
[19:31:22 CET] <FishPencil> So what about: subtitles, playlists, multiple audio tracks
[19:31:33 CET] <furq> mkv can handle all of that
[19:31:35 CET] <furq> mp4 can handle some of that
[19:31:56 CET] <furq> it definitely does multiple audio tracks and plaintext subtitles
[19:32:08 CET] <FishPencil> I'll do mkv, but how should I be selecting the streams or playlists? Can FFmpeg even read a bluray playlist?
[19:32:19 CET] <furq> i don't even know what a bluray playlist is
[19:32:28 CET] <microchip_> FishPencil: I don't support playlists in ffx264 (i have no need for them) but you can try https://sourceforge.net/projects/ffx264/ :P
[19:33:05 CET] <furq> is this like a pgc
[19:33:30 CET] <FishPencil> Why wouldn't you just use FFmpeg directly microchip_
[19:34:49 CET] <microchip_> FishPencil: ffx264 uses ffmpeg..... directly using ffmpeg for what I need will make my life harder by specifying all the options manually for it, so I wrote ffx264
[19:35:10 CET] <furq> https://www.ffmpeg.org/ffmpeg-protocols.html#bluray
[19:35:18 CET] <furq> looks like it's supported anyway
[19:35:40 CET] <furq> not sure if that still needs libbluray
[19:35:48 CET] <FishPencil> It does
[19:35:51 CET] <microchip_> furq: probably
[19:36:28 CET] <furq> it sure would be nice if there was an equivalent for reading pgcs with libdvdread or whatever
[19:37:02 CET] <FishPencil> I know this is #ffmpeg, but are there better tools to convert/encode a bluray?
[19:38:50 CET] <furq> i wouldn't use anything else for converting an m2ts with x264
[19:39:00 CET] <furq> as far as the actual ripping of the bluray i have no idea
[19:40:19 CET] <microchip_> furq: MakeMKV (if you don't mind losing playlists, etc)
[19:40:45 CET] <furq> makemkv just remuxes
[19:41:00 CET] <furq> oh nvm you meant the second sentence
[19:41:10 CET] <furq> i guess that works
[19:41:44 CET] <microchip_> furq: I just need the movie, so MakeMKV works for me :)
[19:42:27 CET] <furq> it's a shame there's no linux version
[19:42:55 CET] <microchip_> furq: sure there is http://www.makemkv.com/forum2/viewtopic.php?f=3&t=224
[19:43:12 CET] <furq> oh neat
[19:43:12 CET] <FishPencil> For subtitles I'm guessing I just rip them to an .srt and choose to not map the subtitle stream during the encode?
[19:43:24 CET] <furq> let's see if this builds on freebsd
[19:43:39 CET] <microchip_> furq: builds on Linux. Never tried on BSD
[19:43:55 CET] <furq> i take it you can just build the cli version
[19:44:13 CET] <microchip_> FishPencil: disable subs with -sn, then add your own during encoding
[19:44:49 CET] <furq> i'm pretty sure mkv can store pgs subtitles
[19:44:56 CET] <microchip_> yes
[19:44:58 CET] <furq> there's no harm in ripping them though
[19:44:59 CET] <FishPencil> microchip_: That'd be part of the same command right? I'd like to do it all in one step to avoid any sync issues
[19:45:23 CET] <furq> FishPencil: sure
[19:45:42 CET] <microchip_> FishPencil: yes.... -sn -map 0:2 (example) -c:s copy
[19:54:28 CET] <FishPencil> Does Opus provide the best compression to bitrate ratio of audio encoders?
[19:59:02 CET] <microchip_> FishPencil: it's one of the best, currently. Problem is, there's still (very) poor support for it, especially on hardware devices like receivers
[20:00:29 CET] <FishPencil> I think most software players can handle it though
[20:00:37 CET] <microchip_> yes
[20:01:01 CET] <microchip_> at least those based on libavcodec, or ones that link to libopus
[20:02:23 CET] <microchip_> FishPencil: 5 years ago I never imagined I'd get a surround receiver. Now I have one, and am glad I did all my encodes in AC3/EAC3 since it supports them, like the majority of other receivers
[20:03:11 CET] <microchip_> FishPencil: while AC3/EAC3 doesn't provide the best compression, I'm fine in trading that for compatibility with virtually everything
[20:03:41 CET] <microchip_> FishPencil: besides, you'd need serious equipment  and golden ears to hear the difference
[20:04:34 CET] <FishPencil> microchip_: I can tell the file size difference :)
[20:04:53 CET] <microchip_> FishPencil: sure,... but i quote "storage is cheap" :P
[20:04:53 CET] <furq> it's not going to add a significant amount to a decent 1080p x264 encode
[20:05:04 CET] <furq> also makemkv does not build under freebsd
[20:06:27 CET] <FishPencil> I might as well not even encode the audio if I'm using AC3
[20:06:48 CET] <microchip_> furq: got Linux around? Try it there. I package MakeMKV myself for openSUSE. Very few things need to be patched for compilation, if at all
[20:07:07 CET] <furq> it's for my nas, so no
[20:07:15 CET] <microchip_> ah
[20:10:51 CET] <s0126h> what is the difference between  8 bit color  vs  6-bits + FRC
[20:11:23 CET] <microchip_> FishPencil: well, if you get DTS HD MA/TrueHD, you can encode it to EAC3 (or AC3) and at high enough bitrates and you won't tell the diff, while at them same time save space :)
[20:12:11 CET] <microchip_> FishPencil: of course, doing AAC at lower bitrates than AC3/EAC3 will give you more space saving
[20:12:45 CET] <FishPencil> I'm leaning to Opus, x264, mkv, srt. I don't need hardware player support
[20:13:35 CET] <microchip_> FishPencil: go for it. Just remember, you can't predict the future. Just like I said to myself 5 years ago that I'll never get a receiver :)
[20:14:26 CET] <FishPencil> I'd use x265, but I think the consensus is it isn't always better than x264
[20:15:11 CET] <microchip_> FishPencil: from personal experience (and this is really personal, my opinion is that x265 needs a lot of work to reach x264 details
[20:15:30 CET] <FishPencil> microchip_: With that same logic receivers might support Opus in the future :)
[20:16:07 CET] <microchip_> FishPencil: *might*. Most still don't support Vorbis and Vorbis is getting old ;)
[20:16:58 CET] <c_14> It's also rather academic because your receiver will support raw pcm and decoding audio to pcm isn't really that much effort
[20:17:16 CET] <microchip_> unless Opus becomes widely popular, I doubt receivers will add support for it. Be who knows? :)
[20:18:20 CET] <microchip_> c_14: i can do it (am a power user), but most folks won't be able to unless they get into it, which most won't
[20:19:33 CET] <c_14> People who aren't power users also don't tend to hook up their receivers to their computers. They'll just use their smart TVs and smart BluRay players etc
[20:20:01 CET] <FishPencil> Not really #ffmpeg related, but why even use a receiver? Couldn't you just use a cheapo laptop with HDMI and software players?
[20:20:04 CET] <microchip_> c_14: right :)
[20:20:17 CET] <FishPencil> I despise dedicated optical players
[20:20:57 CET] <FishPencil> Laptop with a USB DAC that supports whatever you need?
[20:21:13 CET] <microchip_> FishPencil: my receiver is multi-functional, like most current ones are, so I use it to listen to radio, stream music from PC with DLNA, listen to internet radio, stream music from mobile devices with bluethooth, etc :)
[20:21:47 CET] <c_14> You can do everything with a pc as well, the receiver is just easier to set up (at least it's supposed to be) because you don't have to do anything yourself but can just plug it in and it should work"
[20:21:56 CET] <furq> don't use x265 unless you're prepared to encode at 2fps to get a noticeable compression improvement over x264
[20:22:30 CET] <furq> and also know that you can decode it
[20:22:49 CET] <c_14> in at least realtime
[20:23:12 CET] Action: c_14 still remembers the few times he's tried playing 4k HEVC
[20:23:25 CET] <microchip_> :D
[20:23:26 CET] <furq> libavcodec's hevc decoder is pretty slow, so if you're using anything based on that (e.g. mpv) then don't even bother
[20:23:31 CET] <FishPencil> Yeah, I think x264, Opus, srt, mkv are the winning combo.
[20:23:57 CET] <microchip_> Opus offers best compression atm, so yes
[20:24:06 CET] <furq> i tend to use aac with x264 but it's probably less of a concern for a bluray rip
[20:24:50 CET] <FishPencil> Should Opus be used in a -q:a or -b:a way?
[20:25:01 CET] <s0126h> why opus
[20:25:25 CET] <furq> i don't think -q is mapped for opus
[20:25:35 CET] <microchip_> s0126h: he wants best possible compression with best possible quality
[20:25:41 CET] <furq> iirc -b is quality-based with opus anyway
[20:25:50 CET] <furq> it's not abr
[20:26:29 CET] <FishPencil> And 128k Opus is probably pretty audibly lossless?
[20:26:44 CET] <microchip_> 192
[20:27:00 CET] <microchip_> depending on your ears ;)
[20:27:11 CET] <FishPencil> microchip_: For what channel config
[20:27:12 CET] <furq> like how lame -V0 is nominally 256k, libopus -b 128k is nominally 128k
[20:27:17 CET] <furq> also yeah 64k per channel
[20:27:29 CET] <furq> if it's 5.1 you'll want at least 384k
[20:27:40 CET] <FishPencil> Opus support 5.1 I take it
[20:27:42 CET] <microchip_> FishPencil: stereo, for 5.1 try 256
[20:29:28 CET] <FishPencil> Huh, mp4 "officially" support Opus
[20:29:48 CET] <c_14> I don't think the draft is final yet, is it?
[20:30:18 CET] <microchip_> no idea.i don't really follow Opus much yet
[20:30:21 CET] <FishPencil> Perhaps not
[20:30:58 CET] <c_14> https://www.opus-codec.org/docs/opus_in_isobmff.html
[20:31:01 CET] <c_14> says incomplete
[20:33:52 CET] <microchip_> https://commons.wikimedia.org/wiki/Opus_(audio_codec)
[20:33:53 CET] <s0126h> how does  smartphones handle opus
[20:34:06 CET] <furq> android does, iOS probably doesn't
[20:34:20 CET] <furq> all non-apple browsers support opus now
[20:35:56 CET] <FishPencil> I wonder why that is... Apple must be too busy designing phones without 3.5mm audio jacks
[20:36:24 CET] <microchip_> FishPencil: NIH (Not Invented Here). Only add it if enough pressure
[20:36:31 CET] <furq> because opus goes with vp9 which is google
[20:37:04 CET] <furq> also because they're doubtless paying a lot of money for aac and would prefer it if everyone else had to pay for it too
[20:37:21 CET] <FishPencil> What a mess
[20:37:49 CET] <BtbN> There are decent hardware decoders for AAC
[20:37:50 CET] <microchip_> one of the reasons why I avoid anything Apple
[20:37:53 CET] <BtbN> but not for opus
[20:38:09 CET] <furq> that's true but that doesn't explain its absence from desktop safari
[20:38:09 CET] <BtbN> So playing Opus+VP8 or even 9 is fully on to the CPU
[20:39:30 CET] <microchip_> wasn't Apple involved in initial AAC development, or am I thinking of the mp4 container?
[20:39:37 CET] <furq> mp4 is based on mov
[20:39:38 CET] <furq> so yeah
[20:40:09 CET] <furq> apple weren't involved in initial development but they do have a best-in-class implementation
[20:40:23 CET] <microchip_> better than fdk?
[20:40:28 CET] <furq> yeah
[20:40:33 CET] <microchip_> crap :p
[20:40:39 CET] <MrMonkey31> really quick q - for libx265, I'm not seeing a ffmpeg2pass-0.btree : why aren't I seeing a ffmpeg2pass-0.btree?
[20:40:42 CET] <furq> fdk isn't even the best fraunhofer aac encoder
[20:41:30 CET] <microchip_> furq: fraunhofer has another one?
[20:41:37 CET] <furq> fhg
[20:41:41 CET] <MrMonkey31> it's on the second pass now
[20:41:44 CET] <microchip_> oooooo
[20:42:05 CET] <furq> i think fdk is a spinoff from fhg but nobody's really sure
[20:44:19 CET] <microchip_> furq: well no linux version :( (at least not from Googeling for a minute)
[20:44:47 CET] <furq> i don't think you can get a standalone version
[20:45:01 CET] <microchip_> this all i found http://www.andrews-corner.org/linux/fhgaacenc.html
[20:45:06 CET] <furq> winamp paid for the right to bundle it
[20:49:15 CET] <microchip_> MrMonkey31: wild guess... because x265 doesn't need it? :P
[20:49:32 CET] <microchip_> smae thing for .mbtree ?
[20:49:46 CET] <MrMonkey31> WHAT?!  Sorcery!
[20:50:50 CET] <microchip_> MrMonkey31: x265 is quite different to x264. It took x264 code base a&s source, but diverged heavily since HEVC and AVC differ a lot
[20:51:36 CET] <MrMonkey31> oh right, I omitted an m... oh well I only tried the former once or twice before
[20:51:40 CET] <microchip_> MrMonkey31: anyways, you should be using CRF encoding, if you don't shoot for target file size :p
[20:51:45 CET] <MrMonkey31> good to know it's working proper
[20:51:50 CET] <BtbN> x265 was based of on x264?
[20:52:06 CET] <MrMonkey31> I shoot for efficiency, always.  is there any reason not to?
[20:52:19 CET] <microchip_> BtbN: yes, the initial codebase... they took it from x264
[20:52:34 CET] <microchip_> or something like that :p
[20:52:47 CET] <MrMonkey31> by this I mean highest possible compression while keeping desired fidelity
[20:53:48 CET] <furq> 2-pass is only useful if you want to hit a specific bitrate
[20:54:01 CET] <microchip_> MrMonkey31: problem with 2-pass, is you have to guess the bitrate. And bitrate requirements differ from video to vide, so you can't use the same bitrate for all videos, unless you use some insane value but then you're overshooting and wasting bits. Better let the encoder handle that for you
[20:54:03 CET] <MrMonkey31> but if I'm hering you right crf is the go-to right now with x265?
[20:54:16 CET] <furq> yes
[20:54:20 CET] <furq> and x264 fwiw
[20:54:28 CET] <iive> hevc and AVC differ far less than ASP and AVC
[20:54:39 CET] <furq> 2-pass is a relic of the bad old days of xvid
[20:54:51 CET] <iive> nah...
[20:55:08 CET] <furq> and the bad current days of vp9
[20:55:11 CET] <iive> 2 pass is how you get consistent quality for fixed size.
[20:55:51 CET] <furq> those two criteria disagree with each other
[20:56:11 CET] <MrMonkey31> interesting.... I did not find those days *so* bad.  well my feeling would be that it depends on the clip length also.  the longer the source, the more fudging you can afford in the bit rate guess
[20:56:31 CET] <microchip_> iive: hevc is an evolution of avc, but has enough differences to say it differs enough from avc
[20:56:42 CET] <MrMonkey31> but I'm also inclined to take heed to what I hear here :-p
[20:56:57 CET] <furq> well crf isn't an abr mode at all
[20:57:11 CET] <furq> it'll use as much bitrate as it feels it needs to use
[20:57:28 CET] <microchip_> MrMonkey31: rule of thumb is: if you shoot for roughly equal quality in all you encodes, use same CRF. If you need to target specific file size, use 2-pass
[20:57:43 CET] <MrMonkey31> furq, then aye, that sounds like something to look into
[20:57:43 CET] <furq> pretty much that with an emphasis on roughly
[20:57:44 CET] <iive> furq: that's why you need 2 passes to satisfy both.
[20:58:02 CET] <furq> iive: if you mean consistent quality within the file then sure
[20:58:24 CET] <MrMonkey31> although... if you think about that logically....
[20:58:53 CET] <MrMonkey31> it would stand to reason you let crf do its estimation thing, then use the resulting value for a 2 pass encode
[20:58:59 CET] <MrMonkey31> for max efficiency
[20:59:16 CET] <microchip_> MrMonkey31: you'll get almost same result
[20:59:38 CET] <microchip_> MrMonkey31: except with CRF you only need it once, instead of doing it in 2 passes
[20:59:59 CET] <furq> 2-pass only makes sense for abr
[21:00:30 CET] <furq> or if there's some kind of upper limit on how much bitrate you can use
[21:01:06 CET] <BtbN> not so much bitrate, but filesize
[21:01:19 CET] <BtbN> like, if you want a movie to fit perfectly on a DVD, that's what you use.
[21:01:26 CET] <microchip_> yup
[21:02:11 CET] <furq> the problem with 1-pass abr is that you can run out of bitrate towards the end of a file
[21:02:42 CET] <furq> so you need to analyse the whole file so the encoder can make the best decision about where to use the bits
[21:03:02 CET] <furq> if you're not trying to hit an average then it makes no difference, it'll just use what's needed
[21:03:18 CET] <furq> assuming it's a halfdecent encoder ofc
[21:03:24 CET] <BtbN> ABR doesn't usually mean "average over the whole file"
[21:03:27 CET] <BtbN> that's what 2pass is for
[21:03:38 CET] <BtbN> ABR usually just means average over a given timeframe
[21:04:12 CET] <MrMonkey31> I don't wanna spout steam here but where you said those two criteria disagree with each other, I highly disagree.  that's probably why we aren't understanding one another
[21:04:44 CET] <furq> i took "consistent quality" to mean across a variety of sources
[21:04:54 CET] <MrMonkey31> compression to me has always meant that "look, we're trying our best while being small" (if files could talk)
[21:05:01 CET] <furq> one of the nice things about crf is that you can pretty much pick one value and use it for everything
[21:05:16 CET] <MrMonkey31> ah ah ic
[21:05:34 CET] <BtbN> if you don't care too much about the final filesize
[21:05:39 CET] <furq> sure
[21:06:07 CET] <furq> but i've had as many things turn out unexpectedly small as i have unexpectedly large
[21:10:19 CET] <MrMonkey31> I guess for personal stuff (read: pron! j/k!) I prefer a compromise.  I mean if a video has ninja stars flying across the entire screen, the entire time, then I'll allow an extra 100-150 mbs, but then again I might just elect to only take a clipping, ie a sample of the ninja stars.  a shuriken's a shuriken after all
[21:10:26 CET] <MrMonkey31>  /wisdom
[21:10:57 CET] <furq> are you encoding the godfrey ho criterion collection or something
[21:11:23 CET] <MrMonkey31> quiet!  I have been charged this task by ALL HUMANITEY!
[21:12:09 CET] <MrMonkey31> but yeah: file size, clip length, clip prettiness, everything is subject to compromise.  I'm just glad the technology's around to give me more options
[21:13:03 CET] <furq> i just stopped caring about filesize
[21:13:26 CET] <furq> if a 24 minute tv show comes out at 600MB or something then i'll probably denoise it but otherwise idc
[21:13:55 CET] <kerio> qp 18 or bust
[21:13:55 CET] <microchip_> MrMonkey31: we're not here to convince you, but some of the people in here know a lot about compression. In no way are we claiming that 2pass is not to be used. Just that common consensues is, that if you want specific quality and don't care too much about file size, CRF is the way to go. Of course, you decide :)
[21:14:18 CET] <furq> crf is also obviously much faster
[21:14:54 CET] <furq> the fact that it's better for what i care about is secondary to that
[21:15:16 CET] <MrMonkey31> alright microchip_, thanks for the sum-up
[21:27:03 CET] <larsi> is there a way to limit the download speed per second when seeking an online stream? e.g if I have 100MB of data and want to ratelimit it to x amount of bytes per second?
[21:43:25 CET] <larsi> using command: ffmpeg -ss %(seekto)s -i %(url)s -to %(captureTo)s -c copy %(outfile)s -y
[22:11:49 CET] <Luc__> Can somebody pleasse help me with the sysntax of ffmpeg? I would like to stream audio and video from a Raspberry Pi running Raspbian.
[22:18:03 CET] <kerio> isn't the pi camera just v4l2
[22:18:15 CET] <JEEB> also original rpi was way too underpowered
[22:18:32 CET] <kerio> i think there's some way to pull out h264 out of the gpu
[22:18:35 CET] <kerio> maybe
[22:18:37 CET] <JEEB> even if you got the video done with hw encoding it was actually too slow to encode the audio
[22:18:43 CET] <JEEB> which was pop corn time for me
[22:20:02 CET] <kerio> the raspberry pi is so overhyped
[22:20:48 CET] <JEEB> rpi3 is kind of usable for some things
[22:21:05 CET] <JEEB> original rpi was OK as a random hacking machine, but holy begesus do not try to do multimedia with it :D
[22:21:32 CET] <xeuari> I <3 rpi's ..but they are not audio visual platforms
[22:22:06 CET] <xeuari> unless you get a graphics card of equal physical size
[22:23:04 CET] <xeuari> you could certainly perform non realtime operations on video, but streaming might be asking too muxch
[22:23:29 CET] <furq> you can use the builtin h264 encoder with ffmpeg now
[22:23:37 CET] <furq> it's not very good though
[22:23:45 CET] <kerio> however, it's "free"
[22:23:50 CET] <kerio> from a performance standpoint
[22:24:03 CET] <JEEB> and then you will want to do audio and you go :sadface:
[22:24:07 CET] <kerio> hm can't you stream raw data
[22:24:18 CET] <furq> depends what comes out of the camera
[22:24:30 CET] <furq> and what you're streaming to
[22:24:44 CET] <kerio> furq: something with an actual cpu, clearly :^)
[22:27:28 CET] <kerio> 40MB/s is doable on gigE right
[22:27:36 CET] <xeuari> I'm user of what you want to do Luc__ but if it's webcam streaming, you can use fswebcam for ras pi (sudo apt-get install fswebcam)
[22:27:38 CET] <kerio> raw yuv420p
[22:27:47 CET] <furq> the rpi doesn't have 1G
[22:27:51 CET] <Waddledee> Is there a way to set FFmpeg to _reduce_ an input's FPS, but not to _increase_ it? In this case, I want to encode a video to 25 FPS at _most,_ but if it's already 25 FPS or less I don't want to change its frame rate.
[22:28:02 CET] <kerio> furq: yes it does
[22:28:07 CET] <kerio> the pi3 at least
[22:28:12 CET] <kerio> ...i think
[22:28:52 CET] <furq> it's still 10/100
[22:29:24 CET] <furq> although it's usb anyway so you could always just get a 1G or 802.11ac dongle
[22:29:38 CET] <kerio> *300mbps
[22:29:47 CET] <kerio> with like a best case scenario of 480
[22:29:50 CET] <furq> i wouldn't trust the throughput on either of those though
[22:29:52 CET] <kerio> usb 2 is shite
[22:30:08 CET] <furq> yeah it's still usb2 sadly
[22:42:29 CET] <Luc__> @xeuari: i want to stream audio and video from an USB capture device to a RTMP server.
[22:44:36 CET] <kerio> does it get detected as v4l2?
[23:32:42 CET] <Phi> yo folks
[23:33:17 CET] <Phi> I'm trying to cut down the ./configure command so the output .libs are small
[23:33:47 CET] <Phi> for some reason "make" is saying there's nothing to produce for "all"
[23:34:07 CET] <furq> did you run make clean
[23:34:24 CET] <Phi> no diff
[23:34:31 CET] <Phi> I'm probably disabling everything somehow
[23:34:59 CET] <Phi> http://pastie.org/private/h5j0cysrqado1pqhdqffq
[23:35:19 CET] <Phi> it's RTSP or HTTP H264 -> H264 MP4 file
[23:45:06 CET] <furq> you don't need any decoders or encoders to do that
[23:46:04 CET] <Phi> I'm not flat copying, I'm decoding then re-encoding in a new profile
[23:46:27 CET] <Phi> also I'm converting the YUV to display formats
[23:46:29 CET] <furq> you'll need the h264 decoder then
[23:47:31 CET] <furq> you probably also want --enable-protocol=file
[23:48:04 CET] <Phi> do I need the h264 decoder if I'm using libx264?
[23:48:12 CET] <furq> x264 is an encoder
[23:48:33 CET] <Phi> so I use --enable-encoder=x264?
[23:49:28 CET] <furq> --enable-decoder=h264
[23:50:01 CET] <c_14> you'll need the parser too
[23:50:01 CET] <Phi> moop
[23:50:26 CET] <furq> you probably also want the rtp/rtsp protocols
[23:52:24 CET] <Phi> they're in there
[23:52:38 CET] <furq> you've got the demuxers, not the protocols
[23:52:49 CET] <furq> i assume you need both
[23:53:16 CET] <furq> fwiw --enable-demuxer=rtsp,rtp,sdp works
[23:53:29 CET] <Phi> http://pastie.org/private/k4r0fw7d7voqghprnborw
[23:53:34 CET] <Phi> that might help cut it down XD
[23:54:38 CET] <furq> i take it you need that mjpeg/mpeg4 stuff
[00:00:00 CET] --- Sun Nov  6 2016