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

[burek]

[00:00:26 CEST] <Ingersol> i reading documentaztion
[00:00:34 CEST] <Ingersol> but even last examples uses old version
[00:00:44 CEST] <Ingersol> so its why i asking about _right_ example
[00:20:08 CEST] <Ingersol> some examples uses fread some uses av_read_frame()
[00:20:29 CEST] <Ingersol> both of them uses codecpar structure so i think they all uses latest ffmpeg
[00:42:49 CEST] <thebombzen> CoJaBo: you'll run into issues with Generation Loss
[00:45:52 CEST] <nicolas17> Ingersol: you can just give ffmpeg a filename/URL and let it read from the file
[00:46:59 CEST] <nicolas17> Ingersol: you give avformat a filename, then read packets from it with av_read_frame, then send those packets to avcodec, then read decoded frames from avcodec
[01:01:24 CEST] <Ingersol> so av_read_frame is the right way? thanx
[01:01:40 CEST] <CoJaBo> thebombzen: Most of the files have been reencoded 18+ times already. One more can't hurt that much :P
[01:01:52 CEST] <JEEB> isn't that visible in the demuxing example under docs?
[01:01:57 CEST] <JEEB> @ av_read_frame
[01:02:35 CEST] <JEEB> I'd be surprised if a demuxing example would be using fread :)
[01:02:45 CEST] <JEEB> you can create your own custom AVIO wrapper though
[01:03:23 CEST] <JEEB> like this IStream thing I created for windows, which defines the read and seek callbacks https://github.com/jeeb/matroska_thumbnails/blob/master/src/istream_wrapper.c
[01:03:37 CEST] <JEEB> (and then you can register them into your AVIOContext
[01:03:39 CEST] <thebombzen> CoJaBo: at crf 50? yes it can, unless you want to look at something that is not a smudge
[01:04:17 CEST] <nicolas17> JEEB: is stuff like directory listing for wildcards in image2 also abstracted into avio?
[01:04:56 CEST] <JEEB> no idea, to be honest
[01:05:27 CEST] <nicolas17> -pattern_type glob -f image2 -i "custom:foo/bar/*.jpg"
[01:06:26 CEST] <JEEB> I know that the thing is a custom thing on top of something but not sure if it's AVIO
[01:06:38 CEST] <CoJaBo> thebombzen: I'm trying to figure out a sane way to guess at a reasonable CRF; 50 is fine for files that look like barf smeared on a tan background, which is something like half of all the files I need to convert.. The decent ones, still trying to fine-tune it, but looks like I can get away with 40 for mid quality and 31 for the better ones.
[01:06:40 CEST] <JEEB> AVIO is the basic I/O framework, though
[01:06:54 CEST] <nicolas17> damn ffmpeg compiles fast
[01:07:02 CEST] <nicolas17> I'm used to large C++ codebases x_x
[01:07:17 CEST] <thebombzen> CoJaBo: why do you care about files that look like barf smeared on a tan background? why are you doing this?
[01:09:05 CEST] <CoJaBo> thebombzen: It's user-uploaded content; I'd just rm -rf *, but the reason I'm being tasked to do this in the first place is exactly because the barf-iest files are the popular ones.
[01:09:19 CEST] <nicolas17> o_o
[01:11:40 CEST] <CoJaBo> nicolas17: Fun Fact: It is possible to encode HD 1080p, and even 4K video, as MPEG-1.
[01:11:53 CEST] <CoJaBo> I did not know that before today.
[01:12:02 CEST] <nicolas17> sure why not
[01:12:09 CEST] <nicolas17> you just need a ton of bitrate to get decent quality
[01:12:14 CEST] <nicolas17> compared to more modern codecs
[01:15:18 CEST] <CoJaBo> nicolas17: But you don't! Incidentally, that happens to be why they all look like vomit slowly dispersing across the surface of a placid lake.
[01:15:49 CEST] <nicolas17> that doesn't sound like decent quality
[01:16:42 CEST] <CoJaBo> And yet, 28,687 downloads in the past month.
[01:17:28 CEST] <CoJaBo> If nothing else, users will be waiting substantially less time for their doses of dissappointment.
[01:38:58 CEST] <CoJaBo> nicolas17: (and about half of the files *aren't* completely hopeless, but I still need to reencode those to support the new web player)
[03:17:30 CEST] <kusfedora> this might be off topic but is it normal for ffmpeg conversion from mkv to mp4 to nail my processor this hard? all i want to do is add a few youtube videos to a laptop for the baby to watch on a flight >_> https://i.imgur.com/ds9OVuu.png
[03:18:21 CEST] <kusfedora> I am on 3.1.9 btw
[03:19:18 CEST] <furq> yes
[03:19:42 CEST] <furq> although i don't see why you'd need to convert video for a laptop
[03:19:50 CEST] <c_14> If it's h264 add -c:v copy?
[03:19:56 CEST] <kusfedora> aah I meant iPad sorry
[03:20:02 CEST] <furq> right
[03:20:07 CEST] <furq> then yeah you can probably just copy the video stream
[03:20:26 CEST] <c_14> (and if the audio is aac or mp3 copy that too)
[03:20:29 CEST] <furq> ^
[03:20:47 CEST] <kusfedora> ah is that a different command than ffmpeg source.mkv destination.mp4?
[03:21:04 CEST] <furq> ffmpeg -i foo.mkv -c copy dest.mp4
[03:24:39 CEST] <kusfedora> furq I get Could not find tag for codec opus in stream #1, codec not currently supported in container
[03:24:48 CEST] <furq> -c:v copy then
[03:26:00 CEST] <kusfedora> thank you speed is 13x!
[03:26:19 CEST] <kusfedora> as opposed to .8x :D
[04:42:58 CEST] <nicolas17> okay, I found a fundamental difference between my code and ffmpeg.c + examples/muxing.c
[04:43:52 CEST] <nicolas17> I'm setting parameters on st->codecpar, then creating a codec context and copying the parameters to it with avcodec_parameters_to_context(codecCtx, st->codecpar)
[04:44:35 CEST] <nicolas17> the examples set parameters on the codec context, then copy the parameters to the stream with avcodec_parameters_from_context(st->codecpar, codecCtx)
[04:54:29 CEST] <nicolas17> what's more!
[04:54:38 CEST] <nicolas17> the examples set parameters on the codec context, *open it*, then copy the parameters to the stream with avcodec_parameters_from_context(st->codecpar, codecCtx)
[06:04:57 CEST] <Trundler> howdy, getting ERROR: x265 not found using pkg-config when i'm trying to configure
[06:05:52 CEST] <Trundler> I was reading through some mailing lists and forum posts about this issue where ffmpeg is throwing "ffmpeg: error while loading shared libraries: libx265.so.95: cannot open shared object file: No such file or directory
[06:05:52 CEST] <Trundler> "
[06:06:44 CEST] <Trundler> installing ffmpeg through the package manager gives you libx265.so.116 and libx265.so.102 but not .95 as required
[06:07:03 CEST] <Trundler> i tried manually compiling x265-95 with no luck
[07:06:55 CEST] <Trundler> i fixed it
[07:23:53 CEST] <lilibox> hi, please, how to convert PAL DV input file to h264 with fixing interlace? pretty thank you
[07:24:53 CEST] <furq> that's a pretty open-ended question
[07:25:18 CEST] <furq> the most basic answer would be ffmpeg -i foo.dv -vf yadif=1 bar.mp4
[07:26:53 CEST] <lilibox> furq thank you for auick reply, so, such switches like -c:v libx264 i do not need use? extension .mp4 at end of line will cause ffmpeg will use correct codec etc?
[07:27:16 CEST] <furq> right
[07:27:27 CEST] <nicolas17> huh really?
[07:27:28 CEST] <furq> mp4 defaults to h264 and aac
[07:27:59 CEST] <furq> http://vpaste.net/GQfrn
[07:28:17 CEST] <nicolas17> that's good, I thought mp4 defaulted to mpeg4 part 2 video
[07:28:35 CEST] <furq> i think it'll fall back to that if you don't have an h264 encoder
[07:28:46 CEST] <furq> a few other containers do default to mpeg4
[07:28:59 CEST] <lilibox> ok, thank you, and second question is far different
[07:31:31 CEST] <lilibox> I have got sequention of .dpx files (usualy 10 or 12bits) and some .wav and i need merge them to prores which should be broadcasted in TV, usualy EU regions, do i need make special color correction (LUT), frame rate etc? again, does exist any recommended settings?
[08:33:16 CEST] <nicolas17> I can't believe it, I finally got it
[08:33:33 CEST] <nicolas17> my program is producing an .mp4 that is bitwise identical to what ffmpeg.c produces :O
[08:34:27 CEST] <furq> what was the problem
[08:34:57 CEST] <nicolas17> oh a ton of things, but it's like I finally fixed them all
[08:35:03 CEST] <nicolas17> one was
[08:35:30 CEST] <nicolas17> <nicolas17> I'm setting parameters on st->codecpar, then creating a codec context and copying the parameters to it with avcodec_parameters_to_context(codecCtx, st->codecpar)
[08:35:32 CEST] <nicolas17> <nicolas17> the examples set parameters on the codec context, open it, then copy the parameters to the stream with avcodec_parameters_from_context(st->codecpar, codecCtx)
[08:36:55 CEST] <nicolas17> I'm sure that affected a bunch of defaults that come from the codec context and I wasn't copying to the stream codecpar
[08:37:37 CEST] <nicolas17> for the extradata format, I was missing this snippet:
[08:37:40 CEST] <nicolas17> if (outputFormatContext->oformat->flags & AVFMT_GLOBALHEADER) outCodecCtx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
[08:38:24 CEST] <nicolas17> and by the way, if I set AV_CODEC_FLAG_GLOBAL_HEADER like that but I kept the wrong way to handle codecpar, the output file wasn't even playable
[08:39:09 CEST] <nicolas17> I think it's because the encoder stopped putting that info on the stream, but the muxer didn't know it had to put it in the headers :P
[08:43:04 CEST] <nicolas17> the only remaining detail is that I need to set st->codec->time_base (despite it being deprecated), otherwise the bitrate ends up slightly different and ffprobe's guessed average fps is 30.30 instead of 30
[08:52:00 CEST] <lilibox> furq could you help me also with my second question please?
[08:52:25 CEST] <furq> i've never touched dpx, prores or done any broadcast stuff
[08:52:51 CEST] <nicolas17> I had never heard of dpx
[08:53:44 CEST] <lilibox> https://en.wikipedia.org/wiki/Digital_Picture_Exchange
[08:54:01 CEST] <furq> i assume it needs to be 25p or 50i, and you can look at the colorspace or zscale filters for colour correction
[08:55:20 CEST] <furq> if your dpx is yuv422p10le then i guess you don't need to do anything
[08:55:35 CEST] <furq> but it's not something i've ever looked into
[08:56:28 CEST] <furq> oh nvm it's rgb only
[08:56:37 CEST] <furq> !filter zscale @lilibox
[08:56:37 CEST] <nfobot> lilibox: http://ffmpeg.org/ffmpeg-filters.html#zscale
[08:56:44 CEST] <furq> you probably want to take a look at that
[08:57:33 CEST] <lilibox> nfobot: ok, thanks
[10:36:45 CEST] <break_da_funk_> hi! is ffmpeg support full g729 codec?
[10:38:10 CEST] <furq> it has a decoder but not an encoder
[10:38:38 CEST] <break_da_funk_> the codec is now free
[10:38:52 CEST] <break_da_funk_> is ffmpeg team going to develop encoder ?
[10:43:21 CEST] <thebombzen> break_da_funk_: probably not
[10:44:37 CEST] <thebombzen> Not sure there's much reason to use G.729 over Opus nowadays
[10:45:22 CEST] <break_da_funk_> many devices uses g729
[10:45:41 CEST] <break_da_funk_> anyway is there any "place" where I can put an request?
[10:46:03 CEST] <break_da_funk_> request for new feature (g729 encode) in ffmpeg?
[10:47:52 CEST] <thebombzen> you can put one on the trac, but it'll probably be ignored tbh
[10:48:06 CEST] <break_da_funk_> thank You for the answer
[10:48:07 CEST] <thebombzen> the trac isn't used much, even for defects, so wishes probably won't be looked at
[10:48:57 CEST] <thebombzen> You can ask on the mailing list if you want a more complete answer than "probably not tbh"
[10:49:05 CEST] <thebombzen> about any sort of plans I mean
[11:01:30 CEST] <faLUCE> Hello. If I use "fastdecode" for h264, does it override zerolatency ?
[11:01:55 CEST] <JEEB> no, also I'm pretty sure the fastsdecode mode no longer does things with a lot of formats
[11:01:59 CEST] <JEEB> oh wait, encoder setting
[11:02:05 CEST] <JEEB> both are tunes right?
[11:02:09 CEST] <JEEB> if so, yes
[11:02:13 CEST] <JEEB> you can only have one tune set
[11:02:13 CEST] <faLUCE> JEEB: yes, encoder
[11:02:22 CEST] <faLUCE> I see, thanks
[11:02:37 CEST] <JEEB> fastdecode's parameters are rather simple, though
[11:02:42 CEST] <JEEB> stuff like CABAC=>CAVLC
[11:03:02 CEST] <JEEB> setting the baseline profile should provide you with quite similar stuff
[11:03:09 CEST] <JEEB> since baseline profile requires CAVLC
[11:03:17 CEST] <faLUCE> I see
[11:03:17 CEST] <furq> you can have multiple tunes set with the x264 cli
[11:03:23 CEST] <furq> just not multiple psy tunes
[11:03:23 CEST] <JEEB> hmm
[11:03:29 CEST] <JEEB> then I remembered incorrectly
[11:03:30 CEST] <JEEB> :D
[11:03:40 CEST] <JEEB> and if the cli can do it then the libx264 API can do it as well
[11:03:51 CEST] <faLUCE> furq: so I can set both fastdecode and zerolatency at the same time?
[11:04:16 CEST] <furq> yeah but there's no point
[11:04:27 CEST] <faLUCE> furq: why?
[11:04:29 CEST] <furq> preset ultrafast enables all the options in tune fastdecode
[11:04:43 CEST] <faLUCE> ok, I see
[11:05:01 CEST] <furq> you can do -tune fastdecode,zerolatency in the x264 cli
[11:05:02 CEST] <furq> not sure about ffmpeg
[11:05:16 CEST] <furq> but yeah if you're using ultrafast then you don't need to
[11:05:32 CEST] <furq> and it seems like you might as well be using it in this scenario
[11:05:57 CEST] <faLUCE> furq: yes, I use ultrafast :-)
[11:09:24 CEST] <kerio> just go audio only at thay point, man
[11:09:31 CEST] <kerio> that
[11:20:21 CEST] <thebombzen> JEEB: you can use -tune:v fastdecode and -tune:v zerolatency
[11:20:26 CEST] <thebombzen> they don't override each other, afaik
[11:20:51 CEST] <thebombzen> those two are exceptions to the "single" tune rule b/c they're not psy tunings
[11:21:19 CEST] <thebombzen> although ultrafast *shudders*
[11:22:24 CEST] <furq> is there an echo in here
[11:22:57 CEST] <kerio> is there an echo in here
[11:24:00 CEST] <thebombzen> is there an echo in here
[11:24:26 CEST] <BtbN> of course the same parameter twice overrides the other
[11:24:46 CEST] <thebombzen> well, then I'm just wrong about that :P
[11:25:10 CEST] <BtbN> That's just how ffmpeg cli works. The right-most one wins
[11:25:38 CEST] <BtbN> no idea if you can combine x264 tunes somehow
[11:25:50 CEST] <thebombzen> probably -x264-params or something
[11:26:12 CEST] <JEEB> -x264-params lets you pass key=value pairs to libx264 straight, yes
[11:34:14 CEST] <furq> -tune zerolatency,fastdecode appears to work
[11:35:11 CEST] <furq> update: it definitely works
[11:37:52 CEST] <JEEB> gotcha
[11:58:33 CEST] <Fig1024> I'm trying to implement rtsp streaming client with FFMPEG C++ API. How can I check connection status using API?
[12:26:11 CEST] <Fig1024> I can't find any list of streaming specific functions in FFMPEG API. Seems like streaming is done same way as writing file using URL for output. But then there's no way to check connection. If server is not running, encoder simply blocks on 'avformat_write_header' - there's not even a timeout!
[12:56:24 CEST] <DHE> Fig1024: there are usually options you can pass in an AVDictionary and get timeouts. most ffmpeg command-line parameters -- especially format/protocol specifics -- are usable in an AVDictionary
[12:58:48 CEST] <Fig1024> does ffmpeg use librtmp for streaming
[13:00:52 CEST] <furq> it does if you built with librtmp
[13:01:03 CEST] <furq> it has internal rtmp support now which might be better
[13:07:05 CEST] <Fig1024> I want to find more API functions for controlling that part. I don't think AVDictionary options would be sufficient. I need basic things like checking connection status, network specific errors when something's wrong
[14:11:53 CEST] <DHE> Fig1024: ffmpeg -h muxer=rtsp   # and see what options are available
[14:12:19 CEST] <DHE> while you can't directly monitor/manage the session, you may be able to set error thresholds
[14:16:34 CEST] <Fig1024> thanks
[16:35:09 CEST] <lilibox> c/win 15
[16:35:16 CEST] <lilibox> sorry
[19:36:40 CEST] <PixelPerfect> I just want to put it out there that https://trac.ffmpeg.org/wiki/CompilationGuide/Centos is outdated
[19:37:07 CEST] <PixelPerfect> The download links for libogg and libvorbis are plain wrong
[19:38:09 CEST] <PixelPerfect> They've moved to https://ftp.osuosl.org/pub/xiph/releases/ogg/ and https://ftp.osuosl.org/pub/xiph/releases/vorbis/
[19:39:06 CEST] <PixelPerfect> Also, in the centos docker container at least, xmlto and file are both missing dependencies
[19:59:25 CEST] <lindylex> I made a python project to edit video, photo and audio using various system calls mostly to FFmpeg. https://github.com/MotionDesignStudio/commandlinemediahelper  Hope it is useful to someone.
[20:05:45 CEST] <Hopper_> lindylex: What is it capable of?
[20:07:12 CEST] <lindylex> Hopper_ : the following https://github.com/MotionDesignStudio/commandlinemediahelper/blob/master/README.md
[20:10:05 CEST] <Hopper_> Neat!
[20:11:55 CEST] <Hopper_> Question to all, I'm currently looking to transmit a .ts file ATO as it is being created, I'm currently using a UT-100 modulator.  My issue is all the programs I've found that push .ts files to my modulator will not send a file as it is being generated.  Any ideas?
[20:13:18 CEST] <c_14> PixelPerfect: as long as the download links at xiph.org still point to the old links I'd keep them as they are. (they do 301 redirect to the other links). But if you want to change them, create an account on trac and edit the page
[20:13:52 CEST] <kepstin> Hopper_: you probably want to do something like have ffmpeg write to a pipe rather than (or in addition to) a file
[20:14:43 CEST] <Hopper_> kepstin: Where should I read about this?
[20:15:37 CEST] <kepstin> Hopper_: oh, wait, you said you were switching to windows, didn't you?
[20:15:44 CEST] <kepstin> I have no idea how to do that on windows :/
[20:16:37 CEST] <Hopper_> I am now in windows.  The .ts file plays just fine locally as it is being recorded, it seems to be an issue with the program that creates some sort of metadata for itself when the file is selected.
[20:17:01 CEST] <Hopper_> Wish I was in linux, but the drives just don't work for my modulator.
[20:17:28 CEST] <kepstin> Hopper_: consider using ffmpeg's segment writer to split up the .ts files into e.g. 10 second chunks or something, then send them separately?
[20:18:21 CEST] <Hopper_> That's my next option, but I was hoping to do it in one chunk to reduce delay and to keep me from having to write the transmission software from the ground up.
[20:19:09 CEST] <Hopper_> I'm also concerned about buffering the files to create seamless playback.
[20:19:49 CEST] <kepstin> yeah, that's where writing to a pipe for ipc rather than a file would be the best solution
[20:19:59 CEST] <kepstin> but I really have no idea how that could be done in windows
[20:22:02 CEST] <Hopper_> It sounds like a good solution,  but then I have to figure out how get the pipe and transmission software to interact.
[20:40:08 CEST] <lindylex> Hooper_: Thanks
[20:57:58 CEST] <lilibox> btw, does anybody still maintain ffmpeg for old rhel4 at least prores support?
[20:58:32 CEST] <BtbN> no
[20:58:51 CEST] <BtbN> pretty sure whatever is in rhel5 is also long dead
[20:58:56 CEST] <kepstin> hasn't rhel4 been end of life for many years anyways? why would someone maintain ffmpeg for an unmaintained distro?
[21:00:55 CEST] <nicolas17> kepstin: rhel4 super-super-extended support expired in March 2017
[21:01:16 CEST] <kepstin> oh, wow :/
[21:01:20 CEST] <nicolas17> https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle
[21:03:30 CEST] <lilibox> and guys, do you think is unpossible to build it from souce for such old distros?
[21:04:19 CEST] <nicolas17> lilibox: try it :P
[21:06:20 CEST] <lilibox> nicolas17: please, point me for page where is described how to build static version
[21:06:44 CEST] <kepstin> lilibox: assuming you're ok with manually installing a bunch of deps (yasm, libx264, etc.), it'll probably still work.
[21:07:07 CEST] <nicolas17> if there was a detailed and up-to-date on how to build static ffmpeg specifically for rhel4... surely the person maintaining the guide would just provide their binaries?
[21:07:47 CEST] <nicolas17> download the code and check the README / INSTALL / whatever
[21:12:01 CEST] <kepstin> there are a bunch of general guides for building static ffmpeg around, I imagine there's not really too much difference between e.g. ubuntu and rhel in that regard (aside from some package names)
[21:12:57 CEST] <c_14> I mean, you can just build everything from new sources except for the libc (or even use a static musl or something)
[21:17:52 CEST] <kepstin> do the static builds on https://www.johnvansickle.com/ffmpeg/ not work on rhel 4? (is the kernel too old or something?)
[21:18:37 CEST] <kepstin> huh, i guess it is, you don't get a 2.6.32 kernel until rhel6.
[21:24:36 CEST] <nicolas17> I still don't understand why changes to the timebase would affect the bitrate of an x264 encoding if I'm using crf mode :/
[21:27:45 CEST] <JEEB> if you have enough features enabled the rate control does try to look at how "quickly" things go by
[21:27:52 CEST] <JEEB> and either use or not use bit rate on details etc
[21:28:04 CEST] <JEEB> oh wait, just the time base?
[21:28:12 CEST] <JEEB> not actual timestamp values per se?
[21:28:25 CEST] <kepstin> yeah, x264 has optimizations where it looks for "fast motion" in the video, and doesn't bother encoding details it doesn't think the eye will see
[21:28:34 CEST] <JEEB> although I'm not sure if libx264 itself supported timebase switches? (It might but I am not sure)
[21:29:03 CEST] <kepstin> if you change the timebase without changing pts values, then that's equivalent to changing the framerate, but I dunno what you're actually doing?
[21:29:30 CEST] <azarus> What's the difference between encoding with libvorbis vs vorbis, or libopus vs opus?
[21:29:58 CEST] <JEEB> internal vs external library
[21:30:07 CEST] <JEEB> also the internal vorbis encoder should just be thrown out
[21:30:10 CEST] <kepstin> azarus: 'vorbis' will use ffmpeg's builtin vorbis encoder, which isn't particularly good, while 'libvorbis' uses the reference library
[21:30:15 CEST] <JEEB> it's barely a bit stream writer
[21:30:21 CEST] <JEEB> (just like the AAC encoder was, although even worse)
[21:30:45 CEST] <JEEB> the AAC encoder thankfully got improved, and the opus one is gaining dev traction it seems
[21:30:55 CEST] <azarus> So I should avoid internal encoders?
[21:30:59 CEST] <kepstin> azarus: depending on the version of ffmpeg you use, 'libopus' and 'opus' may or may not do different things
[21:31:06 CEST] <kepstin> azarus: depends on the codec.
[21:31:55 CEST] <azarus> Are builtin encoders faster?
[21:32:05 CEST] <kepstin> azarus: depends on the codec.
[21:32:10 CEST] <kepstin> and the settings :)
[21:32:22 CEST] <azarus> Okay, kinda expected that :p
[21:32:39 CEST] <azarus> The best thing would be to try them all, right?
[21:32:54 CEST] <kepstin> if you ask about a specific codec, we can give recommendations
[21:33:10 CEST] <azarus> I'd mostly like to convert audio to opus.
[21:33:19 CEST] <JEEB> then for now use libopus
[21:33:22 CEST] <kepstin> but in general, you should be as specific as possible when telling ffmpeg which codec to use.
[21:33:41 CEST] <JEEB> if you had said AAC the internal AAC encoder is the best distributable one
[21:33:42 CEST] <kepstin> E.g. in old ffmpeg, you could say "-c:a opus" and since there was no internal opus decoder, it would use libopus
[21:34:07 CEST] <kepstin> but now that there's an internal encoder, that does something different now
[21:34:13 CEST] <azarus> I use a new ffmpeg with an internal opus encoder, so I'd need to specify libopus, right?
[21:34:20 CEST] <kepstin> yes.
[21:34:44 CEST] <kepstin> (and ideally make sure you have libopus 1.2.1 installed, since 1.2 adds some nice improvements)
[21:35:27 CEST] <azarus> I have opus-1.2 in gentoo, dunno if that's libopus 1.2.1.
[21:36:06 CEST] <kepstin> close enough, I think 1.2.1 was mostly build fixes, maybe minor bugfixes
[21:36:42 CEST] <kepstin> "fixes a relatively rare issue where the 1.2 encoder would wrongly assume a signal to be bandlimited to 12 kHz and not encode frequencies between 12 and 20 kHz" hmm.
[21:36:53 CEST] <azarus> Nothing big then :)
[21:37:27 CEST] <azarus> What's everyone's favourite audio codec? :)
[21:37:43 CEST] <kepstin> opus, obviously ;)
[21:37:43 CEST] <azarus> I'm split between opus and vorbis!
[21:38:05 CEST] <kepstin> opus is better than vorbis in pretty much every way except hardware player compatibility :/
[21:38:40 CEST] <nicolas17> I had a video where at one point there was some microphone feedback, causing a loud tone
[21:38:47 CEST] <azarus> Pretty much, some of my players don't support opus, that's why I still need vorbis sometimes.
[21:38:53 CEST] <nicolas17> (on 8mm tape)
[21:39:26 CEST] <nicolas17> I was encoding it to DVD-Video... that loud tone made ffmpeg's mp2 encoder crash... I don't remember if I ever reported it :x
[21:39:50 CEST] <JEEB> lol
[21:39:55 CEST] <azarus> BTW, has anyone too had really slow vp9 encodes? x265 seems to be much faster for me :s
[21:40:12 CEST] <JEEB> libvpx is slow as molasses although with anything usable x265 probably is, too
[21:40:27 CEST] <kepstin> azarus: well, both are really slow, but vp9 has worse threading optimizations
[21:40:36 CEST] <JEEB> usable as in that actually gives you perf benefit in compression ratios compared to libx264
[21:40:46 CEST] <JEEB> (with same speed)
[21:40:51 CEST] <kepstin> make sure you're using a recent git build of vp9, of course, the release versions are all way out of date.
[21:40:56 CEST] <azarus> vp9 for me is about 50% the speed as x265, am I doing something wrong?
[21:41:11 CEST] <azarus> Of course, I can build libvpx from git if needed.
[21:41:12 CEST] <kepstin> azarus: you're not running x265 with slow enough settings, probably.
[21:41:16 CEST] <JEEB> you are not mentioning any other parameters so I will guess they are just differently configured :P
[21:41:54 CEST] <JEEB> azarus: basically there's tags in the libvpx repo that are meant for the different chrome versions. latest of those is generally recommended
[21:42:07 CEST] <JEEB> s/chrome/chromium/ although effectively is the same
[21:42:21 CEST] <nicolas17> JEEB: is there even such thing as "vp9 and x265 configured the same way"? :)
[21:42:28 CEST] <JEEB> to the same speed that is
[21:42:50 CEST] <kepstin> azarus: general recommendation is that unless you need H.265 for some other reason, you probably shouldn't use any faster settings than -preset veryslow (use x264 instead)
[21:42:53 CEST] <JEEB> so saying X is slower than Y without mentioning any parameters is just bullshit
[21:43:15 CEST] <azarus> h265 is not free, that's why I kinda want to get away from x265 :(
[21:43:28 CEST] <nicolas17> define "free"
[21:43:38 CEST] <azarus> not patent-encumbered
[21:43:45 CEST] <JEEB> everything is patent-encumbered
[21:43:49 CEST] <kepstin> in terms of dealing with the patents h265 is much worse than h264, of course.
[21:43:57 CEST] <JEEB> the question is whether something is de facto considered "free to use"
[21:44:00 CEST] <nicolas17> H264 has plenty of patents
[21:44:01 CEST] <furq> azarus: i think you still need libvpx from git for the new multithreading mode
[21:44:08 CEST] <furq> although idk how much faster it is
[21:44:17 CEST] <azarus> Thanks for the answer, furq
[21:44:31 CEST] <JEEB> also it really depends on the use case. AVC for example didn't require any fees for freely available internet video
[21:44:40 CEST] <azarus> vp9 is much for free than h264, for example.
[21:44:41 CEST] <kepstin> hmm, the chrome 59 tag should give you working new multithreaded mode, I think, but the 60 tag is probably better
[21:44:46 CEST] Action: nicolas17 shrugs
[21:44:52 CEST] <kepstin> 58 has it about half-implemented iirc
[21:44:56 CEST] <JEEB> and I think the HEVC licensing pools (which is complete bullshit btw) did kind of come to their senses
[21:45:00 CEST] <JEEB> in that regard
[21:45:04 CEST] <furq> kepstin: sure, but that's still a tag
[21:45:14 CEST] <furq> the static builds generally use release versions
[21:45:33 CEST] <kepstin> yeah
[21:45:39 CEST] <JEEB> the main issue I have with people calling VP9 libre or whatever is that those people generally never saw how it was developed. it was created behind closed doors with just el GOOG
[21:45:51 CEST] <JEEB> that's the whole antithesis of OSS or anything similar IMHO
[21:45:52 CEST] <kepstin> i wish they'd just make the chrome tagged versions official "releases" or something
[21:45:58 CEST] <furq> it's free as in the one that stallman doesn't like
[21:46:06 CEST] <azarus> Is it a good idea then to build the newest version from git?
[21:46:12 CEST] <furq> but it's still better than paying four bars to drink one beer
[21:46:12 CEST] <nicolas17> JEEB: yeah, iirc by the time it was made public, the bitstream was already frozen
[21:46:21 CEST] <azarus> of libvpx I mean*
[21:46:24 CEST] <furq> azarus: yes
[21:46:39 CEST] <JEEB> furq: kind of. I guess it got enough adoption that you could de facto consider it "free to use"
[21:46:40 CEST] <kepstin> azarus: git head is sometimes a bit wonky, which is why i normally use the chrome tags, but probably ok?
[21:46:52 CEST] <furq> well yeah i meant it's freeware
[21:46:58 CEST] <JEEB> because there's always the thing that you might get someone trying to screw the party
[21:47:02 CEST] <JEEB> because effectively nothing is patent-free
[21:47:03 CEST] <JEEB> :V
[21:47:17 CEST] <furq> idc if google handle the litigation
[21:47:23 CEST] <nicolas17> what ever happened with that cisco-patenting-x264-algorithm thing?
[21:47:29 CEST] <furq> obviously they might lose and then the party is over, but google can afford it
[21:47:37 CEST] <JEEB> yea, if google handles it
[21:47:45 CEST] <lilibox> kepstin nicolas17 i am getting installers of CentOS it is pretty hard to wind centos4upg3 these days :)
[21:47:46 CEST] <JEEB> it would get funky if google just leaves someone to struggle :D
[21:48:28 CEST] <JEEB> anyways, at this point with AOM I kind of dislike it less than libvpx and the VPx formats, since it's no longer a single-vendor race
[21:48:29 CEST] <nicolas17> http://x264.nl/developers/Dark_Shikari/tandberg.html
[21:49:04 CEST] <azarus> Although I don't think I'll make use of a lot of threading though, I have a 2-core 2-thread processor :p
[21:49:34 CEST] <kepstin> azarus: hey, it should still go from being super super slow to being merely super slow.
[21:49:47 CEST] <azarus> What an improvement! ;)
[21:50:06 CEST] <JEEB> nicolas17: ah right that stuff. that said cisco actually joined VDD with a talk regarding their patent-avoiding Thor thing
[21:50:12 CEST] <JEEB> like a year or two ago
[21:50:31 CEST] <JEEB> right, VDD '14
[21:50:32 CEST] <JEEB> *15
[21:50:38 CEST] <nicolas17> VDD
[21:50:39 CEST] <nicolas17> ?
[21:50:46 CEST] <JEEB> https://vimeo.com/141153289
[21:50:57 CEST] <JEEB> nicolas17: the primary event for OSS multimedia devs
[21:51:04 CEST] <JEEB> done every year so far
[21:51:13 CEST] <nicolas17> I also didn't know of Thor
[21:51:15 CEST] <JEEB> VideoLAN being nowadays an umbrella organization
[21:51:44 CEST] <JEEB> nicolas17: they joined other efforst later
[21:51:45 CEST] <nicolas17> is Thor still a thing or did it get consumed by AO1?
[21:52:54 CEST] <JEEB> pretty sure they joined the group efforts
[21:53:03 CEST] <JEEB> also man it was surprising getting some "suit" people :D
[21:53:15 CEST] <JEEB> compared to the usual OSS nerd folk
[21:53:17 CEST] <azarus> Can vaapi accelerate my vp9 encodes=
[21:53:20 CEST] <azarus> *?
[21:53:34 CEST] <JEEB> even if it could, you still wouldn't get the compression ratios as with SW encoders
[21:53:46 CEST] <JEEB> unless something magical happens and the software encoder is really bad
[21:53:48 CEST] <BtbN> Is there even hardware that does vp9 hw encode?
[21:53:55 CEST] <nicolas17> JEEB: I think similarly of patents and of "thou shalt not reverse engineer", and this is what I think of the latter https://pbs.twimg.com/media/Czf29XDXUAAdBcd.jpg:large
[21:54:02 CEST] <furq> azarus: it can accelerate it by offloading the decode
[21:54:08 CEST] <furq> that's all i'd use it for
[21:54:22 CEST] <azarus> Good point, decoding h264 is a task by itself too!
[21:54:39 CEST] <JEEB> nicolas17: hehe. RE is fun!
[21:54:59 CEST] <nicolas17> iirc I tweeted the latter with "fuck the IP police"
[21:55:08 CEST] <JEEB> I need to get the new version of IDA I guess :V
[21:55:42 CEST] <JEEB> although I'm generally OK with the OSS debuggers
[21:56:32 CEST] <nicolas17> I once spent a week manually decompiling ARM64 code (because Hopper can only decompile 32-bit arm, for ARM64 it only disassembles) and added a button I wanted to the iOS mail app
[21:56:55 CEST] <JEEB> also if you want to know what happened with libvpx last year https://vimeo.com/181634997
[21:57:45 CEST] <JEEB> there's also great talks from the last two years regarding the AAC encoder updates etc
[21:59:17 CEST] <nicolas17> JEEB: I finally got my program to produce a .mp4 bitwise identical to what ffmpeg.c produces
[21:59:29 CEST] <JEEB> nicolas17: that can be both a good and a bad thing :D
[21:59:34 CEST] <JEEB> because ffmpeg.c is ffmpeg.-c
[21:59:37 CEST] <JEEB> *.c
[22:00:11 CEST] <nicolas17> JEEB: https://paste.kde.org/pr0cjy1y5
[22:01:17 CEST] <kepstin> BtbN: no vp9 hw encode as far as I know. There's some hw decode support around, e.g. nvidia
[22:01:35 CEST] <BtbN> nvidia and intel have decode support
[22:01:45 CEST] <BtbN> but I can't think of any consumer hw encoders
[22:02:12 CEST] <jkqxz> Latest Intel has encode support.  (8-bit only, 10-bit just has decode.)
[22:04:13 CEST] <kepstin> huh, I wonder how much of that is in hw vs. software (the media sdk stuff is all a bit purposefully unclear about that)
[22:04:43 CEST] <jkqxz> Pretty much all hardware.  (Easily does 4K60.)
[22:05:54 CEST] Action: JEEB can do HLG in VP9.2 with his TV and that's kind off is nice :3
[22:21:34 CEST] <azarus> Right, I now have compiled and installed a brand new libvpx from git, let's see if this improves my encodes.
[22:23:35 CEST] <azarus> There were 923 commits to master since 1.6.1 (the release I was at before) so surely some changes were made to improve performance :p
[22:29:34 CEST] <kepstin> azarus: you'll probably want to recompile your ffmpeg against the new libvpx as well. there's a few things in the ffmpeg codec which are conditionally enabled based on the libvpx features available.
[22:29:53 CEST] <azarus> kepstin: Already in the middle of recompiling ffmpeg :p
[22:30:05 CEST] <kepstin> azarus: in particular, the "-row-mt" avoption :)
[22:30:35 CEST] <azarus> kepstin: Never heard of that! Do I have to enable a compiler flag for that?
[22:30:49 CEST] <TD-Linux> azarus, you can make libvpx pretty fast with the --cpu-used option (8 fastest, 0 slowest) but you do throw out compression gain doing that.
[22:31:01 CEST] <kepstin> azarus: no, as long as you build ffmpeg against a new enough libvpx version, that'll be available.
[22:31:55 CEST] <azarus> TD-Linux: Does a loss of compression gain mean an increase in file-size?
[22:32:02 CEST] <azarus> kepstin: Thanks for informing me :)
[22:32:05 CEST] <TD-Linux> azarus, yup.
[22:32:14 CEST] <TD-Linux> azarus, same as x265 does with its default speed (medium iirc)
[23:14:40 CEST] <azarus> I want to do 2-pass encoding with vp9. Why is the command 'ffmpeg -i in.mkv -c:a libopus -c:v libvpx-vp9 -pass 1 -f mkv /dev/null' invalid while 'ffmpeg -i The.Grand.Tour.S01E12.WEBRip.X264-DEFLATE\[ettv\].mkv -c:a libopus -c:v libvpx-vp9 -pass 1 -f webm /dev/null' is valid?
[23:14:58 CEST] <azarus> Ah whoops. Pasted a bit too much!
[23:15:58 CEST] <nicolas17> I'm not sure if ffmpeg has a special interpretation of [] characters but I'd recommend avoiding them just in case :P (rename input file)
[23:23:19 CEST] <JEEB> (it doesn't - it's all up to your shell)
[23:23:34 CEST] <JEEB> only img2 has special features in there
[23:24:45 CEST] <furq> both of them already left
[23:25:02 CEST] <furq> i understand the first guy leaving, i wouldn't want anyone to know i watched the grand tour either
[23:35:06 CEST] <JEEB> lol
[00:00:00 CEST] --- Tue Jul 11 2017