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

[burek]

[00:00:33 CEST] <furq> you might want to look at line 551 as well
[00:01:50 CEST] <durandal_1707> ugh, are you sure looking at right source code?
[00:02:41 CEST] <durandal_1707> i mean nothing in ffmpeg should use libavresample
[00:02:46 CEST] <furq> i was talking to fiera
[00:03:04 CEST] <furq> line 551 is #if CONFIG_AVRESAMPLE
[00:03:23 CEST] <durandal_1707> but even that shouldnt exist
[00:03:40 CEST] <durandal_1707> somebody fucked up
[00:06:34 CEST] <furq> speaking of swresample, is it worth changing any of the defaults other than -filter_size
[00:07:02 CEST] <furq> i couldn't find anything on the ML other than stuff like exact_rational which is default enabled now anyway
[00:11:03 CEST] <durandal_1707> furq: filter_type
[00:11:25 CEST] <furq> i take it there isn't a "best" one of those
[00:12:28 CEST] <furq> i was going to submit some new samples to that resampler comparison, so it'd be nice to have the most overkill settings possible
[00:12:36 CEST] <durandal_1707> furq: hmm, could be better than default
[00:12:39 CEST] <fiera> 551 line does not cancel 37, I'm trying to compile in the VC 2015, if I comment line 37, then the build ffplay is successful, but the does not sound
[00:13:32 CEST] <furq> i'll probably send one set with defaults and one with -filter_size 256 -filter_type kaiser
[00:13:50 CEST] <furq> i had a look at the sweep spectrograph and filter_type made no difference for that
[00:14:14 CEST] <furq> the defaults are already much better than the ffmpeg 1.1 samples they've got there anyway
[00:15:12 CEST] <durandal_1707> yes, but note that only >90 dB matters in spectogram
[00:15:44 CEST] <furq> sure
[00:15:57 CEST] <furq> filter_size 256 looks basically the same as soxr defaults
[00:16:53 CEST] <furq> so that's one less thing that i need to build ffmpeg for
[00:17:02 CEST] <furq> shame i still want fdk
[00:22:18 CEST] <fiera> Can still tell me how to build ffplay in Visual Studio? I do not need ffmpeg, only ffplay. Too many dependencies are created with the mingw, how it avoid?
[00:23:26 CEST] <durandal_1707> i do not use windows, exp visual studio
[00:24:57 CEST] <fiera> ok, which flag and where to pass, in order to avoid dependencies libwinpthread-1.dll etc.
[00:25:44 CEST] <furq> --enable-static --disable-shared
[00:28:12 CEST] <fiera> These are enabled  by default, but there are dependencies
[03:46:30 CEST] <ac_slater> hey guys. When I'm muxing two streams in an mpegts container (manually via libavformat), do the timestamps (PTS/DTS) of the two streams have to be interleaved?
[03:47:11 CEST] <ac_slater> or related in any way?
[03:49:56 CEST] <DHE> as in audio and video?
[03:50:44 CEST] <DHE> as best you can you should submit AVPackets in globally ascending dts order
[03:51:00 CEST] <DHE> av_interleave_write_frame (sp?) can help here
[03:52:26 CEST] <ac_slater> DHE: thanks for the reply
[03:52:34 CEST] <ac_slater> specifically, I have a video and a data source
[03:53:01 CEST] <ac_slater> the data source isnt subtitles or anything, but it is a format the ffmpeg/mpegts has a mapper for
[03:53:07 CEST] <ac_slater> it's KLVA
[03:53:57 CEST] <ac_slater> currently, I just increment the data source's PTS/DTS monotonically from 0 for every packet :-/
[03:54:20 CEST] <ac_slater> I'm wondering if I should scale it to the container (mpegts) clock or just let demuxers handle it
[03:59:01 CEST] <hendry> ffserv is mentioned to be removed the next release ... http://ffmpeg.org/index.html#ffserv will it be ?
[04:06:41 CEST] <furq> i hope so
[04:06:59 CEST] <furq> actually no, that's from last year
[04:07:05 CEST] <hendry> yes, a year ago
[04:07:22 CEST] <furq> it was supposed to be dropped in 3.2 but some dev decided it was their pet project and they were suddenly very interested in it again
[04:07:31 CEST] <hendry> i'm looking for software to dump an rtmp stream, do you have any alternatives to suggest furq ?
[04:07:33 CEST] <furq> and by "very interested" i mean they did the bare minimum to port it to non-deprecated apis
[04:07:42 CEST] <furq> and then didn't fix any of the stuff that makes it shit
[04:08:00 CEST] <furq> and er
[04:08:03 CEST] <furq> rtmpdump?
[04:08:38 CEST] <ac_slater> hendry: rtmpdump works well
[04:09:21 CEST] <hendry> oh, thanks, i somehow discounted it before since it didn't have a listening server component (i thought) now i see rtmpsrv
[04:09:38 CEST] <furq> if you want a server then use nginx-rtmp
[04:10:08 CEST] <hendry> i just need it to to listen reliably
[04:10:27 CEST] <hendry> nginx-rtmp seems to do transcoding and lots of other stuff on the fly that i don't need. i think.
[04:10:36 CEST] <furq> only if you ask it to
[04:10:47 CEST] <furq> and it only does transcoding if you ask it to exec ffmpeg
[04:11:12 CEST] <hendry> what's the benefit of using saying nginx-rtmp over rtmpdump's rtmpsrv ?
[04:11:30 CEST] <hendry> is it more robust / tested or something ?
[04:11:48 CEST] <furq> it depends what you actually want
[04:12:01 CEST] <furq> rtmpsrv is a fake server that you use to invoke rtmpdump
[04:12:37 CEST] <hendry> basically want to convert a rtmp stream to Web playback, but also have an archive. so thinking dump + generate some HLS playlists
[04:12:50 CEST] <furq> nginx-rtmp will do exactly that
[04:13:40 CEST] <hendry> furq: ok, must revisit it. thanks
[04:14:05 CEST] <hendry> i guess the nginx part put me off, since i intend to have everything off the S3server httpd
[04:14:46 CEST] <furq> you can just disable all the http modules when you build nginx
[04:15:45 CEST] <hendry> so what is nginx actually doing? the listening part?
[09:49:13 CEST] <Diego_> Hi there. I want to know the bitrate and FPS of a video. I've tried "ffprobe -i video.webm -select_streams v:0 -show_entries format=bit_rate:stream=avg_frame_rate -v quiet -of default=noprint_wrappers=1", but avg_frame_rate shows "15/1". In VLC shows that "video.webm" FPS are 21.0000020. How can I obtain those 21 FPS from codec information?
[10:16:45 CEST] <Diego_> Can someone help me with my problem with FFprobe, please?
[12:22:50 CEST] <Diego_> Why ffmpeg procees does not exit normally when finishes compiling? It doesn't use any CPU resources, but the process stays up without errors and compilation is fine
[13:04:36 CEST] <DHE> it means it's trying to do something. maybe a graceful close of hardware that didn't close so gracefully? maybe flush data to a slow disk or network share?
[13:17:30 CEST] <Diego_> I don't think so. I have an SHDD and every other process is finishing fast. Probably a graceful close of the process(?) I don't know. Doesn't show errors nor warnings
[14:19:44 CEST] <Diego_> I've tested converting the webm videos to mp4 and when I create the mp4 compilation, the process stops immediatelly, but not when the compilation is in webm
[14:46:09 CEST] <dido> Hi, need help with parallel encoding for hls segments. More detailed info on https://stackoverflow.com/questions/44628825/hls-parallel-segment-encoding
[14:47:23 CEST] <__jack__> that's not how it works
[14:47:30 CEST] <__jack__> it reads the input file
[14:47:32 CEST] <__jack__> then decode it
[14:47:35 CEST] <__jack__> then encode it
[14:47:42 CEST] <__jack__> then chunks the output into multiple ts
[14:49:44 CEST] <dido> my point is to encode all .ts segments at the same time, not one by one
[14:51:13 CEST] <dido> splitting into multiple ts and encode each wont be slower?
[15:17:09 CEST] <termos> I'm pushing AVPackets onto a AVThreadMessageQueue in order, but they are received in a different thread sometimes out of order giving me "non monotonically increasing dts to muxer". Is there some re-ordering happening? From looking at the implementation I don't see anything like that happening
[15:40:16 CEST] <DHE> dido: depends. encoding can be multi-threaded. if you only have one machine to do the encoding work, you may be better off having it do the whole thing at once in multi-threaded mode
[15:40:34 CEST] <DHE> (though there is diminishing returns if you have some crazy core count and the video is low resolution)
[15:45:39 CEST] <dido> DHE: i know it can be multi-threaded but still segments will be done one by one if i m right
[15:46:24 CEST] <dido> i just want to speed up the encoding of one video
[15:50:16 CEST] <DHE> if you have 1 hour 1080p video and a quad-core CPU, just do it in one instance and let libx264 multi-threading to do its job
[16:15:46 CEST] <Diego_> DHE: Does "-preset ultrafast" option work only on h264 codecs? I'm trying it to compile a mosaic with VP8 and speed seems the same
[16:16:39 CEST] <DHE> presets, and what they mean, are per-encoder.
[16:16:55 CEST] <DHE> wait, why are you asking me?
[16:20:59 CEST] <Diego_> DHE: because you are the only one that answers here XD
[16:21:02 CEST] <Diego_> sorry
[16:21:22 CEST] <BtbN> ultrafast is libx264 specific.
[16:22:40 CEST] <Diego_> Thanks BtbN
[16:23:12 CEST] <furq> libvpx uses either -speed or -cpu-used
[16:23:19 CEST] <furq> i forget which one is the ffmpeg option and which is the libvpx option
[16:23:32 CEST] <BtbN> libvpx is not exactly good with that
[16:23:41 CEST] <furq> and yeah it's going to be pretty slow either way
[16:23:47 CEST] <furq> particularly vp8, which doesn't do any kind of multithreading
[16:24:04 CEST] <furq> i imagine vp9 will actually be faster on a decent cpu since they added row-mt
[16:24:12 CEST] <Diego_> So the best way is to convert vp8 to h264 then recompile into mosaic with -preset if I want a fast compilation, right?
[16:24:23 CEST] <BtbN> what?
[16:24:36 CEST] <BtbN> why would you add a pointless transcode?
[16:24:40 CEST] <furq> yeah don't do that
[16:24:53 CEST] <furq> the vp8/9 decoder is very fast anyway
[16:25:34 CEST] <Diego_> Because I have 2 videos in webm (VP8 codec) and I want to create a mosaic with them and I need to do it very fast
[16:25:48 CEST] <furq> well then don't encode it twice when you only need to encode it once
[16:26:03 CEST] <BtbN> video encoding is not going to be very fast
[16:26:41 CEST] <Diego_> I meant "very fast". If I can get a 15 mins video into a mosaic output in 2 mins, its quite decent
[16:27:24 CEST] <BtbN> that's That's 7.5x real-time, that's not very realistic for any decent quality
[16:27:30 CEST] <Diego_> And I've tested to do a codec conversion while generating the mosaic, but throws an error about I can't do that or something like that
[16:28:03 CEST] <Diego_> I don't need full hd, just kinda nice quality and I'm testing it right now with -preset option. Not bad at all
[16:28:53 CEST] <DHE> <Diego_> DHE: because you are the only one that answers here XD   # I still discourage this though. I might be gone for hours and there's no way to tell on IRC
[16:30:10 CEST] <Diego_> Tbh, I've been asking here for 6 hours and you were the only one that answered one of my questions (I've made only 2 questions though)
[16:30:25 CEST] <Diego_> I didn't want to offend anyone
[16:31:25 CEST] <BtbN> nice quality and fast don't go with each other
[16:31:32 CEST] <BtbN> you buy the speed with quite horrible quality
[16:31:38 CEST] <BtbN> Or huge files
[16:32:15 CEST] <furq> 15:27:29 ( Diego_) And I've tested to do a codec conversion while generating the mosaic, but throws an error about I can't do that
[16:32:23 CEST] <furq> pastebin the command and output
[16:34:12 CEST] <Diego_> BtbN: yea, I know, but I get a "good" quality. Enough for the project
[16:34:36 CEST] <sgermain> Hi! I'm trying to convert MPEG-TS to HLS and I'm running into problems. The main problem is, when the source stream is being transcoded at the source (using Zenverge transcoding chip), the HLS ends up with lots of macroblocks. When I turn off the transcoding at the source, the stream is fine, but way too big. Also, the machine running ffmpeg isn't strong enough to do software transcoding (which work fine, I tried it, as a te
[16:34:41 CEST] <Diego_> furq: I can't do that right now as I must go for now. I will give another shot and check if I can get it work
[16:35:18 CEST] <sgermain> I can provide the command line I use.
[16:35:58 CEST] <furq> that just sounds like a fundamental problem with the chip you're using
[16:36:25 CEST] <furq> if you're not encoding with ffmpeg then it has no control over the quality
[16:36:51 CEST] <sgermain> If I view the HLS stream using VLC, the stream is fine, but not with any Apple devices using their native HLS support.
[16:37:44 CEST] <sgermain> I understand it has no control over the quality of the stream, but maybe it has something to do with timing? I'm not entirely sure.
[16:38:55 CEST] <sgermain> Because macroblocks come and go
[16:39:55 CEST] <sgermain> For example, it'll play perfect for 1 second, then show macroblocks for a second or 2, then go back to perfect, so on and so forth.
[16:55:31 CEST] <RandomCouch> Hi, is anyone around?
[16:55:44 CEST] <RandomCouch> I'm trying to compile ffmpeg for android using this guide https://ericnjennifer.wordpress.com/2014/07/25/android-porting-ffmpeg-with-ndk-1/
[16:55:51 CEST] <RandomCouch> but I keep getting compile errors
[16:56:00 CEST] <RandomCouch> using NDK r13b and ffmpeg-3.3.2
[16:56:22 CEST] <RandomCouch> also I'm on windows so I'm using cygwin to execute the shell script
[17:21:26 CEST] <sgermain> I'm reading the documentation on ffmpeg's hls demuxer and I'm curious as to how do I set multiple hls_flags?
[17:26:09 CEST] <c_14> separated by + afaik
[17:43:10 CEST] <AnonBaiter> so
[17:44:44 CEST] <AnonBaiter> has anyone gotten around to decode this early mdec file?
[17:44:45 CEST] <AnonBaiter> https://www.sendspace.com/file/6s3oiw
[17:44:45 CEST] <AnonBaiter> the sector in which CD-XA is stored can be decoded, while the video can`t
[17:45:16 CEST] <AnonBaiter> *video sector
[17:45:48 CEST] <AnonBaiter> the rest is just "unknown sector type ##"
[17:51:32 CEST] <AnonBaiter> oh, and this file came from an early PS1 game called Jumping Flash, released in 1995
[17:52:14 CEST] <AnonBaiter> it`s not just Jumping Flash however, there were some early PS1 games that used this format too
[18:06:28 CEST] <RandomCouch> unfortunately this place seems inactive
[18:06:38 CEST] <RandomCouch> wish I could get some help building ffmpeg for android
[18:41:44 CEST] <jasom> Is the correct set of filters for performing an IVTC of an NTSC source: dejudder,fps=30000/1001,fieldmatch,decimate ?
[18:45:08 CEST] <furq> there isn't a correct set, it depends on the source
[18:45:35 CEST] <furq> you probably want either that or pullup,fps=24000/1001
[18:45:49 CEST] <furq> someone else has probably done a lot more ivtcing than me though
[19:08:02 CEST] <AnonBaiter> guess I need to have that issue I`m having on trac.ffmpeg
[19:19:42 CEST] <RandomCouch> Is there an updated guide on building ffmpeg for android
[19:55:49 CEST] <kepstin> jasom: I think you'd want the dejudder after the decimate, since its purpose is to smooth out the framerate after decimate removes the dup frames.
[19:57:37 CEST] <kepstin> and yeah, there's no such thing as a perfect/correct automatic ivtc. If you have movement on every frame and no interlaced crossfades, fieldmatch will probably do pretty well.
[20:06:51 CEST] <FishPencil> Does it make sense to use FFmpeg as an image decoder? Or should I tie into the libs themselves (libjpeg, libpng)?
[20:07:30 CEST] <furq> depends what you're doing
[20:07:35 CEST] <furq> something like libvips might be a better choice
[20:08:05 CEST] <DHE> it makes sense if you're using it for video work on top of it. like image overlays...
[20:08:17 CEST] <DHE> otherwise, yeah I'd just go with an image-specific library'
[20:08:39 CEST] <furq> if you need absolutely comprehensive format support then libavcodec/libavformat is probably a good choice
[20:08:52 CEST] <furq> but it's probably not going to be particularly quick or lightweight
[20:08:57 CEST] <FishPencil> I just need to decode jpg, fits, gif, and png. I don't think FFmpeg supports fits, so I'll have to go elsewhere for that anyway
[20:09:04 CEST] <furq> libvips does fits
[20:10:14 CEST] <FishPencil> Doesn't vips just use the libraries themselves and ties it into one API?
[20:10:55 CEST] <furq> yeah it does
[20:11:02 CEST] <furq> saves you the effort though
[20:16:06 CEST] <FishPencil> I bet it does, I'll probably just use it. No need reinventing the wheel
[20:30:20 CEST] <alexpigment> hey guys, I'm trying to figure out if this fix/patch is working: https://trac.ffmpeg.org/ticket/6260
[20:30:32 CEST] <alexpigment> i feel like I've done everything to ensure that my build has this fix in place
[20:30:37 CEST] <alexpigment> but it's clearly not fixed at all
[20:31:08 CEST] <alexpigment> can anyone else check to see if their interlaced output gets really bad stair-stepping?
[20:54:18 CEST] <jasom> kepstin: the main thing I want is to never lose audio-sync; I don't care too much if a few crossfades have combing
[20:55:43 CEST] <kepstin> jasom: yeah, keeping sync won't be a problem unless you throw a setpts filter in them. I think all the detelecining stuff in ffmpeg should preserve timestamps fine.
[20:56:24 CEST] <kepstin> (which is part of the reason the dejudder filter is needed, it fixes the jump in timestamps where the frames that the detelecine filter dropped used to be)
[20:57:00 CEST] <furq> afaik if you have a clean source then pullup,fps will work great
[20:57:21 CEST] <furq> according to the docs, dejudder is mostly for fixing hybrid interlaced/telecined sources
[20:57:44 CEST] <jasom> furq: but lots of sources start out with e.g. an interlaced intro or will switch field order on some scene changes.
[20:57:47 CEST] <furq> sure
[20:57:58 CEST] <furq> those are not clean sources
[20:58:13 CEST] <furq> films are generally clean sources, tv shows tend not to be
[20:58:31 CEST] <jasom> kepstin: using some of the suggested ivtc filters on the wiki, I've ended up losing sync
[20:59:28 CEST] <jasom> furq: I've never tried ivtc from TV, but 1/3 of all DVDs I've tried do not maintain the same field order for the entire film (either with the studio logo at the beginning being 29.97 native, or field-order switch at a scene change)
[20:59:45 CEST] <furq> fair enough
[20:59:50 CEST] <furq> i'm in a pal region so i don't really know much about ivtc
[21:00:19 CEST] <jasom> furq: I've heard some pal musicals use a 24/25 pulldown, but never encountered one.
[21:00:31 CEST] <furq> yeah i've never seen that
[21:00:35 CEST] <furq> it's usually just sped up by 4%
[21:00:37 CEST] <furq> which is easy to fix
[21:00:58 CEST] <furq> we have more than our fair share of hybrid interlaced/film though
[21:01:09 CEST] <furq> which is probably still easier to fix than hybrid interlaced/telecine
[21:38:32 CEST] <RandomCouch> I really need help with ffmpeg for android build
[21:38:46 CEST] <RandomCouch> If anyone can provide me with a working guide or tutorial
[21:38:54 CEST] <RandomCouch> for building ffmpeg for android on windows
[21:39:08 CEST] <RandomCouch> with the latest versions of NDK and ffmpeg
[21:55:06 CEST] <JEEB> RandomCouch: building FFmpeg with NDK is rather simple to be honest... make the toolchain with the python script that comes with the NDK, and then gas-preprocessor if you want to use clang
[21:55:22 CEST] <JEEB> of course personally the latest NDK (r15) breaks the mediacodec hwdec
[21:56:08 CEST] <RandomCouch> Thanks JEEB, I'll have to look up what clang and gas-preprocessor is, I'm a bit of a novice
[21:56:20 CEST] <JEEB> NDK comes with two compilers. gcc and clang
[21:56:26 CEST] <RandomCouch> Ultimately what I'm trying to do is just combine two mp4 files together on native android
[21:56:49 CEST] <RandomCouch> I feel like ffmpeg is overkill for that but it's the only solution I'm finding
[21:58:39 CEST] <JEEB> gas-preprocessor is a script you can get from https://git.libav.org/?p=gas-preprocessor.git;a=summary
[21:58:44 CEST] <JEEB> it's for ARM
[21:59:04 CEST] <JEEB> gcc can handle the asm that's in FFmpeg as-is, but clang still needs manual love which the gas-preprocessor can do
[21:59:09 CEST] <JEEB> just needs to be in PATH
[22:01:34 CEST] <JEEB> and the standalone toolchain stuff is this https://developer.android.com/ndk/guides/standalone_toolchain.html
[22:02:02 CEST] <JEEB> (because with FFmpeg you cannot use the google hackjobs that's called the "NDK build system"
[22:32:05 CEST] <RandomCouch> Thanks JEEB I'm looking into all this now
[23:26:09 CEST] <kerio> this .wmv is slow to open in mpv
[23:26:12 CEST] <kerio> how do i fix
[23:26:25 CEST] <kerio> don't say "transcode to a real codec"
[23:26:39 CEST] <kerio> oh ok actually it just doesn't work in mpv
[23:27:24 CEST] <durandal_170> kerio: please upload it somewhere
[23:27:36 CEST] <kerio> ...
[23:27:44 CEST] <durandal_170> it might be asf demuxer issue
[23:27:57 CEST] <kerio> wouldn't that get fixed after remuxing into mkv?
[23:28:03 CEST] <kerio> i tried that and it still failed to open
[23:28:34 CEST] <hpp> maybe vlc plays it better?
[23:28:38 CEST] <kerio> HERESY
[23:28:45 CEST] <kerio> oh hold on i have vlc installed
[23:29:11 CEST] <durandal_170> kerio: if it doesnot work with ffmpeg but does with wmp please upload short sample
[23:29:35 CEST] <kerio> durandal_170: well, it's (correctly?) transcoding with ffmpeg
[23:29:39 CEST] <kerio> the same ffmpeg that mpv is built against
[23:31:07 CEST] <durandal_170> hmm, make sure you are not using hwdec
[23:31:15 CEST] <kerio> ...i am ;o
[23:31:22 CEST] <kerio> wait there's hwdec for wmv?
[23:31:24 CEST] <kerio> on macos?
[23:32:10 CEST] <kerio> what do you fucking know, it was hwdec
[23:32:24 CEST] <durandal_170> what video codec is it using?
[23:33:00 CEST] <kerio> Stream #0:1: Video: wmv3 (Main) (WMV3 / 0x33564D57), yuv420p, 1280x720, 5210 kb/s, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, 1k tbn, 1k tbc
[23:33:15 CEST] <furq> yeah i tend to remux wmv to mkv
[23:33:21 CEST] <furq> seeking is a fucking nightmare in wmv
[23:33:22 CEST] <kerio> why's hwdec even attempted
[23:33:35 CEST] <furq> remuxing to mkv fixes most issues i have with wmv
[23:33:42 CEST] <kerio> furq: given that this is pretty vile porn, i should probably remux to .nut
[23:33:44 CEST] <furq> other than the big issue of "it's fucking wmv"
[23:33:46 CEST] <kerio> U(  )W
[23:33:52 CEST] <furq> ofc it's porn
[23:33:54 CEST] <furq> why else would you have wmv
[23:34:02 CEST] <kerio> well whats the alternative
[23:34:03 CEST] <kerio> transcoding?
[23:34:08 CEST] <kerio> we must preserve our history
[23:34:19 CEST] <kerio> i think i have some like
[23:34:22 CEST] <kerio> 160x120 .rm or something
[23:34:25 CEST] <furq> i've reencoded a lot of 1080p wmv porn to 576p x264
[23:34:43 CEST] <furq> it looks just as good considering how blocky the source looked
[23:34:49 CEST] <durandal_170> you lost bunch of pixels
[23:34:59 CEST] <furq> im cryeing
[23:35:21 CEST] <kerio> anyway why is hwdec messing with a wmv of all things
[23:35:26 CEST] <furq> vc-1?
[23:35:33 CEST] <kerio> i'm pretty sure that wmv is not accelerated on macos
[23:35:41 CEST] <furq> intel has vc-1 hwdec iirc
[23:35:46 CEST] <furq> if it's wmv9 then no idea
[23:36:06 CEST] <kerio> isn't it just videotoolbox
[23:36:14 CEST] <furq> shrug
[23:37:04 CEST] <kerio> furq: it's not wmv9, it's wmv3
[23:37:12 CEST] <furq> wonderful
[23:37:26 CEST] <furq> oh those are the same
[23:37:31 CEST] <furq> just a different fourcc
[23:37:55 CEST] <kerio> anyway it's still a bug right
[23:37:56 CEST] <kerio> in mpv
[23:37:57 CEST] <furq> vc-1 is based on wmv9 so maybe the vc-1 hwdec still works
[23:38:05 CEST] <furq> also that seems like a question for #mpv
[23:38:10 CEST] <furq> those guys fucking suck though
[23:38:46 CEST] <durandal_170> no they are nice and friendly
[23:40:33 CEST] <kerio> why can't i get some lossless porn
[23:40:46 CEST] <furq> make it yourself
[23:42:17 CEST] <kerio> hold on lemme take a pic of my dick in raw
[23:42:26 CEST] <kerio> i'll pm it to you
[23:43:06 CEST] <furq> go on then
[23:43:23 CEST] <dystopia_> these seems rather off topic
[23:43:37 CEST] <kerio> does mpv do its own thing for hwdec
[23:43:50 CEST] <durandal_170> this ch is logged and stay ontopic
[23:44:30 CEST] <kerio> should i enable more things in my ffmpeg
[23:44:40 CEST] <kerio> i have --with-x265 --with-opus
[23:44:47 CEST] <kerio> in brew
[23:46:55 CEST] <durandal_170> depends what you need?
[23:47:35 CEST] <kerio> is openh264 any good?
[23:47:39 CEST] <kerio> other than the patent thing
[23:47:51 CEST] <furq> no
[23:47:53 CEST] <furq> it's baseline only
[23:48:04 CEST] <kerio> fdk-aac?
[23:48:04 CEST] <furq> it exists solely for the patent thing
[23:48:16 CEST] <furq> fdk is better than the builtin encoder, especially if you want he-aac
[23:48:21 CEST] <kerio> that's the only thing in this list that i could see myself using
[23:48:22 CEST] <kerio> aite
[23:49:00 CEST] <kerio> why isn't the builtin encoder better
[23:49:10 CEST] <kerio> why can't you guys just git gud
[23:49:26 CEST] <furq> it's already better than every oss encoder that isn't fdk
[23:49:33 CEST] <Threads> how about you code it for them and they port it into ffmpeg :P
[23:49:44 CEST] <furq> and better than every gpl compatible encoder
[23:49:58 CEST] <Threads> last i looked online nobody uses the dead format wmv anymore
[23:50:01 CEST] <iive> furq: are you sure about builtin aac encoder?
[23:50:15 CEST] <furq> there hasn't been a listening test so i'm not 100% sure
[23:50:34 CEST] <furq> if nothing else fdk is definitely better for he-aac and vbr
[23:50:45 CEST] <kerio> iive: well, when anyone says "better" it's always implied "other than the fact that at >128k, aac is pretty much perceptually lossless anyway so yea"
[23:50:45 CEST] <Threads> ^
[23:50:50 CEST] <furq> i don't think the builtin encoder even supports those yet
[23:50:58 CEST] <Threads> just lc
[23:51:00 CEST] <kerio> "also just use opus"
[23:51:01 CEST] <hpp> since there is OPUS that is all you need
[23:51:12 CEST] <furq> you'd struggle to tell the difference at 128k cbr
[23:51:26 CEST] <furq> it was designed to replace faac, not fdk
[23:51:42 CEST] <kerio> i have laptop speakers and bluetooth headphones
[23:51:50 CEST] <kerio> i'd probably struggle to tell the difference at 128k cbr mp3
[23:52:01 CEST] <furq> definitely
[23:52:30 CEST] <Threads> all you want todo is listen to the music does bitrate really matter :/
[23:52:40 CEST] <kerio> ok thats not true, mp3 128 is noticeable even on my shit listening setup
[23:52:41 CEST] <kerio> but only barely
[23:53:29 CEST] <kerio> Threads: https://www.dropbox.com/s/wngqdpdttau2alk/Screenshot%202017-06-20%2023.53.22.png?dl=0 mfw
[23:58:33 CEST] <Threads> are you one of them audiophiles or what ever they call them that has to have high bitrates for music
[23:59:03 CEST] <kerio> nah, only radiohead :^)
[23:59:22 CEST] <alexpigment> Threads - when storage is so cheap, why would you not? You never know when your audio setup will improve and you regret ripping at something lower
[23:59:24 CEST] <pzy> amen to that kerio
[23:59:27 CEST] <alexpigment> (I'm speaking from experience)
[23:59:55 CEST] <kerio> alexpigment: there is absolutely no reason whatsoever to have 96/24 audio if you're not in a mixing studio
[23:59:56 CEST] <alexpigment> But yes, you want Weird Fishes - Arpeggio at the highest bitrate possible :)
[00:00:00 CEST] --- Wed Jun 21 2017