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

[burek]

[11:18:34 CEST] <kier[work]> hi all, having an interesting problem: i'm passing "--enable-vaapi --enable-hwaccels" to configure, and it reports that it's going to build said hwaccels, but the resulting ffmpeg executable doesn't seem to include them (ffmpeg -hwaccels doesn't list any)
[11:19:17 CEST] <kier[work]> this is on version 3.0. This problem doesn't occur on the latest version, so it's just a legacy issue
[11:19:56 CEST] <kier[work]> is there some magic configure flag that I'm missing, or does this just not work in v3.0?
[11:32:30 CEST] <Fig1024> I heard there was some change to the way hardware acceleration was handled, I don't think hwaccels is used. But I dunno for sure
[11:33:27 CEST] <Fig1024> now hardware encoders have their own codec ID and names, so like nvenc is NVidia h264
[11:34:13 CEST] <kier[work]> ah i'm looking at decoders, forgot to say that earlier
[11:35:11 CEST] <kier[work]> afaict encoders have their own codec (e.g. hevc_vaapi) as you say, while decoders use the "hevc" codec with a hwaccel enabled
[11:35:58 CEST] <kier[work]> apologies if that sentence didn't make any sense, haven't had enough coffee yet today
[11:46:42 CEST] <jkqxz> kier[work]:  3.0 does not support VAAPI decode in the ffmpeg utility, only through libavcodec.
[11:48:11 CEST] <kier[work]> jkqxz: ah, thanks
[13:51:00 CEST] <kiki`> hi. i have the following task: concat videoA (100frames) and videoB (100frames) blending videoB over VideoA using N (lets say 20) frames -> so effectively at frame 80 videoA starts to crossfade to videoB .. resulting in 180 frames .. im trying for hours now, but its really just a simple crossfade between two channels.. can u help?
[13:52:22 CEST] <Mavrik> That sounds like a task for a video editing software, not ffmpeg :/
[13:52:31 CEST] <Mavrik> I don't know of a way that wouldn't be painful as heck
[13:54:36 CEST] <furq> i've done this before for the benefit of someone on irc
[13:54:39 CEST] <furq> but yeah, it's pretty horrible
[13:56:01 CEST] <kiki`> ffmpeg -i videoA -i videoB -complex_filter [0:v]setpts=pts+80[a],[1:v][b],[a][b]blend=blah sth like that the fucj
[13:56:10 CEST] <kiki`> it is
[13:56:44 CEST] <kiki`> i guess once one understands that cryptic syntax its super powerful
[13:57:58 CEST] <Forgon> Why does this command not work? I want to extract pictures from seconds 16:31 to 16:76 out of an mkv videofile.
[13:58:23 CEST] <Forgon> ffmpeg -i input.mkv -ss 16:31 -to 16:76 -q:v 'picture\%03.png'
[13:59:43 CEST] <furq> what is 16:76 supposed to be
[14:00:25 CEST] <furq> if that's supposed to be 16 seconds then you want 16.76
[14:01:14 CEST] <Forgon> Okay thanks
[14:01:21 CEST] <furq> also get rid of -q:v
[14:17:01 CEST] <Asuran> ehm, is it possible that ffmpeg shows also how many frames are left to encode?
[14:28:42 CEST] <DHE> unfortunately not. it's not always known or even accurate without reading the whole input ahead of time just to measure it.
[14:29:12 CEST] <DHE> above the progress report is ffmpeg's best guess as to the duration, so you can see how it's going with regards to time
[14:35:16 CEST] <JEEB> yea, if you're only dealing with files then I recommend using something like ffms2 that is a library which wraps around FFmpeg's libraries to create an index and use seeking/decoding according to that
[15:20:33 CEST] <t3v4> Hi all
[15:21:30 CEST] <t3v4> I have problem with metadata API via AVFormatContext. Detailed problem is here: https://stackoverflow.com/questions/45050177/adding-metadata-informations-with-ffmpeg
[15:21:38 CEST] <t3v4> Can anyone help me with this? Thanks!
[15:31:19 CEST] <DHE> the most glaring issue is that you're not using AVDictionaryEntry properly
[15:31:50 CEST] <DHE> oops, sorry my bad.
[15:32:09 CEST] <DHE> can you at least indicate what line it crashes on?
[15:58:53 CEST] <t3v4> hi
[15:59:06 CEST] <durandal_1707> hi
[16:01:30 CEST] <DHE> wtf...
[16:01:55 CEST] <shincodex> i assume his shit crashes on tag
[16:01:59 CEST] <shincodex> tag->key
[16:02:05 CEST] <shincodex> probably null ptr
[16:02:30 CEST] <shincodex> AVDictionaryEntry *tag = nullptr;
[16:02:36 CEST] <shincodex> thats a abomination
[16:02:49 CEST] <t3v4> problem is at int status = avformat_write_header(ctx, &ctx->metadata);
[16:02:53 CEST] <t3v4> its causing sigseg
[16:11:58 CEST] <shincodex> does crash go away when you remove  av_dict_set(&ctx->metadata, "TPFL", "testtest", 0);
[16:26:58 CEST] <Asuran> DHE, JEEB ok thx
[18:24:03 CEST] <Blubberbub> Hello, i've got a question about the design of the filters and filtergraph. Maybe i'm missing something, but it looks to me, that these are not designed to work with streaming applications at all, because: A lot of the filters require an EOF to function properly and will shut down afterwards. You can only feed in a predetermined number of files. (Example: concat list of files, but silenceremove them individually before concat or
[18:24:03 CEST] <Blubberbub> acrossfade a list of files or stream of files) Am i right about this or am i missing something? Was this a deliberate design decision?
[18:27:07 CEST] <JEEB> Blubberbub: it works for streaming but you might have to re-init the filterchain if you have an input count change
[18:27:45 CEST] <JEEB> unless you build a separate filter chain for each stream
[18:28:16 CEST] <JEEB> of course there are specific filters where the use case is more limited
[18:28:27 CEST] <RealName7890> Why is it that my bitrate is being ignored and the encoding is going over the CBR that i specify for libvpx?
[18:28:55 CEST] <RealName7890> ffmpeg -i in.mp4 -an -ss 120 -t 119 -c:v libvpx -bufsize 10k -b:v 180k -y -threads 4 -speed 0
[18:28:55 CEST] <RealName7890>  output.webm
[18:29:23 CEST] <JEEB> have you set maxrate+bufsize and just fyi libvpx's rate control is known to be bad
[18:29:43 CEST] <Blubberbub> so i need to reinit it every time and it does not work out of the box with ffmpeg, but needs a custom application
[18:30:15 CEST] <JEEB> Blubberbub: depends on the filters you want to use, but yes
[18:30:34 CEST] <Blubberbub> i thought it would be great, if there would be some additional kind of link that supports multiple files after one another separated by a special packet or something like that.
[18:31:05 CEST] <Blubberbub> and then have filters that turn this into a "normal" stream - like concat, or crossfade
[18:31:17 CEST] <JEEB> I mean even with ffmpeg.c I can do streaming with specific filters. ffmpeg.c is just very static regarding inputs etc
[18:31:50 CEST] <Blubberbub> you need to know your input files in advance, though. You cannot really play an infinite amount of files
[18:31:53 CEST] <RealName7890> JEEB, it's still going over: ffmpeg -i .\in.mp4 -an -ss 120 -t 119 -c:v libvpx -bufsize 10k -b:v 180k -maxrate 180k -y -threa
[18:31:53 CEST] <RealName7890> ds 4 -speed 0 out3.webm
[18:32:14 CEST] <JEEB> RealName7890: also is that vp8 or 9?
[18:32:23 CEST] <RealName7890> JEEB, vp8 i believe
[18:32:35 CEST] <JEEB> and yea, have fun with libvpx \o/
[18:32:49 CEST] <JEEB> #vp8 might be able to help
[18:32:57 CEST] <RealName7890> JEEB, should the -bufsize be high or low to have a more accurate bitrate?
[18:33:29 CEST] <JEEB> RealName7890: you just have to calculate bits with the buffer size
[18:34:03 CEST] <JEEB> as long as you use the bufsize in calculations you should get valid results
[18:34:08 CEST] <RealName7890> JEEB, how do i do that?
[18:34:33 CEST] <RealName7890> I don't understand what you meant
[18:35:31 CEST] <JEEB> google for vbv.pl
[18:35:43 CEST] <JEEB> that should have a function that explains you
[18:36:16 CEST] <Blubberbub> Thanks for your answers, JEEB. Do you think this "static-ness" for input files is by design or is it considered a "missing feature"?
[18:36:49 CEST] <RealName7890> JEEB, I only did: bitrate = (target filesize in kilobits) / (length in seconds) kbps
[18:36:53 CEST] <JEEB> duration and size of packet and bufsize+maxrate let you calculate if you are within your vbv or not
[18:37:08 CEST] <cableguy> hello, team
[18:37:24 CEST] <cableguy> my ffmpeg wont copy subtitle stream/track
[18:37:35 CEST] <JEEB> Blubberbub: lavfi should be improved a lot and ideas/patches are generally welcome
[18:37:36 CEST] <cableguy> ffmpeg -i "source.VOB" -map 0:v -map 0:a -map 0:s -c copy -fs 10000000 -ss 00:00:00 -t 00:10:00 "split.vob"
[18:37:48 CEST] <cableguy> 'Stream map '0:s' matches no streams.'
[18:38:31 CEST] <JEEB> then there are no subs according to ffmpeg
[18:38:31 CEST] <RealName7890> JEEB, I was trying to do CBR to get the targetted file size.
[18:38:33 CEST] <JEEB> c
[18:38:42 CEST] <cableguy> but they are
[18:38:46 CEST] <cableguy> mediainfo shows them
[18:39:17 CEST] <cableguy> Text ID 189 (0xBD)-33 (0x21)
[18:39:30 CEST] <cableguy> they exist in the vob and play in any player
[18:44:25 CEST] <RealName7890> JEEB, I think the problem was that I had to set minrate and maxrate
[18:44:30 CEST] <RealName7890> i was missing minrate
[18:50:52 CEST] <gmoryes> Can somebody help? Why I can't see audio-bitrate from webm format? Using this command: ffprobe -analyzeduration 20M -i video.webm?
[18:51:30 CEST] <gmoryes> And this I can see in the output
[18:51:31 CEST] <gmoryes> Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp (default)
[18:51:59 CEST] <gmoryes> where is bitrate? And yes, there is an audio in video
[18:52:57 CEST] <Asuran> idk maybe due vbr
[18:53:56 CEST] <Asuran> what about ffmpeg -i file?
[18:54:48 CEST] <gmoryes> the same situation
[18:54:51 CEST] <gmoryes> Duration: 00:07:56.09, start: 0.000000, bitrate: 640 kb/s     Stream #0:0: Video: vp8, yuv420p, 640x360, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)     Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp (default)
[18:55:44 CEST] <gmoryes> Okey, let propose it has a variable bitrate
[18:56:54 CEST] <gmoryes> Do anybody know how to know is it variable bitrate or not?
[19:02:21 CEST] <JEEB> RealName7890: minrate is generally something you do not set
[19:02:21 CEST] <DHE> vorbis is intended as a VBR codec by design
[19:06:44 CEST] <iranen> no one should use ogg/vorbis anymore since there are OPUS
[19:07:11 CEST] <JEEB> cableguy: then cut a sample of the VOB with dd or so (without any remuxing) that contains a subtitle and then open a ticket for it (just make sure you're using latest FFmpeg)
[19:07:23 CEST] <JEEB> that way developers get a sample, too :P
[19:08:00 CEST] <furq> cableguy: you might need to bump up analyzeduration/probesize
[19:09:12 CEST] <furq> failing that, use something like tcdemux
[19:14:56 CEST] <RealName7890> JEEB, that's what it says under constant bitrate and it fixed getting CBR to work, https://trac.ffmpeg.org/wiki/Encode/VP8
[19:17:03 CEST] <JEEB> could be libvpx/VP8 specific
[19:17:29 CEST] <JEEB> also always question the wiki as it is not written by developers in general (it wouldn't be the first time it had incorrect data in it)
[19:18:40 CEST] <JEEB> in general (f.ex. with libx264) minrate is frowned upon as something that tries to hack the rate control on the libavcodec side
[19:19:17 CEST] <JEEB> and with libx264 you'd probably get better results by using a low enough CRF with maxrate+bufsize
[19:27:01 CEST] <gmoryes> Does anybody know how to get average VBR from video?
[19:27:19 CEST] <gmoryes> or audio
[19:28:16 CEST] <JEEB> average over the whole clip is the size of the stream divided by the seconds of content
[19:28:57 CEST] <gmoryes> yes, but I need average vbr of video, and I don't know the size of audio stream
[19:29:16 CEST] <gmoryes> average vbr of audio stream in video*
[19:29:25 CEST] <gmoryes> any ideas?
[19:31:53 CEST] <kerio> gmoryes: -map the video alone, mux it with -null
[19:31:54 CEST] <kerio> er
[19:31:56 CEST] <kerio> with -f null
[19:38:17 CEST] <LinuxLoader> hello , did some one have tested 4xGPU quadro P5000 on single server from udp stream transcoding to mpeg-dash
[20:04:53 CEST] <cableguy> JEEB, whats a dd
[20:05:07 CEST] <furq> https://en.wikipedia.org/wiki/Dd_(Unix)
[20:07:51 CEST] <cableguy> anyway i ran ffprobe and it does indeed not see the subtitle stream, it does on other dvd
[20:08:09 CEST] <cableguy> but i dont get it,subtitle is in there.
[20:08:11 CEST] <furq> did you try increasing analyzeduration and probesize
[20:08:14 CEST] <cableguy> and im on windows
[20:08:19 CEST] <cableguy> so no ^
[20:08:33 CEST] <furq> what does that have to do with windows
[20:08:36 CEST] <JEEB> lol
[20:08:50 CEST] <cableguy> i thought its only on linux
[20:08:55 CEST] <furq> those are ffmpeg options
[20:08:57 CEST] <JEEB> no, its ffprobe/ffmpeg options
[20:09:01 CEST] <JEEB> *it's
[20:09:05 CEST] <cableguy> so how do you run it
[20:10:43 CEST] <cableguy> ok i ran this ffprobe -i "VTS_01_1.VOB" -analyzeduration 2147483647 -probesize 2147483647 i found it on some ticket
[20:11:03 CEST] <cableguy> and now it sees the subtitle
[20:11:14 CEST] <cableguy> so not sure whats going on
[20:11:41 CEST] <furq> those default to 5 million (microseconds/bytes)
[20:11:47 CEST] <furq> i.e. 5 seconds, 5MB
[20:11:57 CEST] <furq> so the subtitle stream doesn't show up until after that point in the file
[20:12:18 CEST] <cableguy> okay so how i make my initial command work
[20:12:33 CEST] <cableguy> the ffmpeg -i "source.VOB" -map 0:v -map 0:a -map 0:s -c copy -fs 10000000 -ss 00:00:00 -t 00:10:00 "split.vob"
[20:12:34 CEST] <furq> you do the same thing with ffmpeg
[20:13:06 CEST] <cableguy> same how
[20:16:03 CEST] <cableguy> the -analyzeduration 2147483647 -probesize 2147483647 on ffmpeg does not show subtitle stream
[20:16:18 CEST] <cableguy> and if i add it to my original splitting command i get same error
[20:16:24 CEST] <cableguy> 'Stream map '0:s' matches no streams.
[20:19:49 CEST] <rodorgas> I'm using pad and overlay to merge two rtsp live streams. The output stream is `-f mpegts udp://localhost:1234`, can it be played on VLC? How? I'd rather have a RTP stream, but whenever I try, it says "Only one stream supported in the RTP muxer". Suggestions?
[20:20:59 CEST] <cableguy> ok i solved
[20:21:17 CEST] <cableguy> apparently you add analyzeduration and probesize on ffmpeg before input -i
[20:21:30 CEST] <cableguy> and i changed it to -analyzeduration 2148M -probesize 2148M
[20:21:44 CEST] <cableguy> because someone had problem like that https://lists.ffmpeg.org/pipermail/ffmpeg-user/2014-May/021564.html
[20:22:03 CEST] <cableguy> and it says sometimes subtitle starts at the middle of the vob
[20:22:08 CEST] <cableguy> so probably that was the trouble
[20:22:22 CEST] <cableguy> but looks like nobody gives a fuck in this chat,as usual
[20:22:25 CEST] <cableguy> take care
[20:23:03 CEST] <rodorgas> lol
[20:27:48 CEST] <momomo> anyone have any experience with tvheadend? is it possible to view signal strength so one can adjust the satellite dish?
[20:44:39 CEST] <Blubberbub> probably a stupid question, but i was not able to google the answer for it, yet: does PTS include the time of day or does it start at 0 when the demuxer/decoder is initialized?
[20:47:22 CEST] <JEEB> PTS is just something
[20:47:33 CEST] <JEEB> for MPEG-TS for example you can have it somewhere way positive
[20:47:44 CEST] <JEEB> while for audio in mp4 the initial samples can have a negative PTS
[20:48:21 CEST] <JEEB> (usually negative PTS means "you can throw <amount of samples until zero> out after decoding")
[20:48:47 CEST] <Blubberbub> ah ok. Thanks :)
[20:52:10 CEST] <JEEB> usually what it means is that it's just a means to synchronize between different things, even if the time base is different between say audio or video tracks
[20:56:38 CEST] <Blubberbub> so if i understand correctly the actual double value is identical, but the pts might differ because of different time_base between the streams?
[20:57:52 CEST] <JEEB> not necessarily identical but you can then utilize the PTS values to synchronize between streams
[20:58:52 CEST] <Blubberbub> ah, true
[21:30:04 CEST] Action: kepstin notes that in mpeg-ts, the pts values were designed to be able to hold (slightly more than) 24h before wrapping, so *some* broadcasters may have the current time of day in the pts, wrapping every 24h.
[21:30:09 CEST] <kepstin> but you probably won't see that
[21:36:26 CEST] <DHE> mpegts is intended to run perpetually. so you can run into the situation where dts is (visually) around 8 billion time units but pts is around 1000
[21:36:34 CEST] <DHE> which is always fun
[21:45:43 CEST] <kerio> whats dts instead
[21:45:54 CEST] <kerio> sync between different programs?
[21:45:58 CEST] <JEEB> decoding time stamp
[21:46:06 CEST] <JEEB> as opposed to presentation timestamp
[21:46:11 CEST] <kerio> oh
[22:31:33 CEST] <Mavrik> Ugh.
[22:31:43 CEST] <Mavrik> Just found another PTS/DTS rollover bug in ffmpeg.
[22:31:50 CEST] <Mavrik> -_-
[22:33:00 CEST] <JEEB> weeeeeee
[22:33:13 CEST] <JEEB> I actually thought about adding extra fields to AVPacket/AVFrame
[22:33:15 CEST] <JEEB> a la upipe
[22:34:08 CEST] <JEEB> upipe has: timestamp, coded_timestamp, unix_time_of_receipt
[22:34:18 CEST] <JEEB> I can see why you'd have at least two of those
[22:34:28 CEST] <Mavrik> For? :)
[22:35:15 CEST] <JEEB> some of the issues currently with the roll-over stuff is because the mpegts demuxer outputs the timestamps with roll-over
[22:35:25 CEST] <JEEB> which people defent because they want remuxing to possibly keep timestamps
[22:35:27 CEST] <JEEB> *defend
[22:35:44 CEST] <JEEB> for which separate timestamp fields would make sense
[22:35:51 CEST] <JEEB> "if you want the original coded timestamp, here"
[22:36:04 CEST] <JEEB> "if you just want a rising timestamp properly fixed, here"
[22:37:37 CEST] <Mavrik> Oh yeah.
[22:37:50 CEST] <Mavrik> The people I'm writing this code for certanly want the timestamps to remain the same
[22:38:09 CEST] <Mavrik> Including the batshit crazy "We're splicing commercials so PTS/DTS jumps thefuck whatever" type stuff
[22:38:18 CEST] <JEEB> :D
[22:38:20 CEST] <Mavrik> So there are a few patches around fixing that
[22:38:29 CEST] <JEEB> yea, I bet
[22:38:38 CEST] <JEEB> makes sense for live input
[22:38:41 CEST] <Mavrik> Trying to upstream them as much as possible, but my ugly hacks probably won't be looked upon with grace :P
[22:38:51 CEST] <Mavrik> Yeah, broadcast TV must die.
[22:39:35 CEST] <Mavrik> Hmm, should I add a .ts sample: https://trac.ffmpeg.org/ticket/6531#ticket ?
[22:40:28 CEST] <JEEB> would probably help
[22:40:47 CEST] <JEEB> Mavrik: if done correctly it's not a hack, but requirement of the format
[22:40:49 CEST] <JEEB> generally speaking
[22:41:37 CEST] <Mavrik> I'm not sure what a proper solution for that is though?
[22:41:58 CEST] <Mavrik> Checking if DTS difference is over treshold and reset the counters? Since I'm guessing the DTS isn't coming in linearly into muxer in all cases.
[22:42:22 CEST] <JEEB> isn't it basically a discontinuity?
[22:42:32 CEST] <JEEB> or does everything expect no decoder reset on those?
[22:43:39 CEST] <Mavrik> That's the part which I might be a bit fuzzy about - are DTS discontinuities legal in MPEG-TS or do they have to be ordered?
[22:44:13 CEST] <JEEB> I do have a 2012 H.222 bible somewhere here, but it might also be written in the DVB/EBU specs as well
[22:44:17 CEST] <Mavrik> Meaning, is "fuu, emit PAT/PMT if dts < last_seen_dts" a valid strategy :)
[22:44:26 CEST] <Mavrik> Yeah, gonna go dig through my spec books as well
[22:48:17 CEST] <c7j8d9> Is there nvenc hw acceleration for vp9 like hevc?
[22:48:17 CEST] <JEEB> Mavrik: also as a framework I'm surprised everything else took it well enough :D
[22:48:53 CEST] <JEEB> granted, I guess after you decode it the PTS comes out sane enough
[22:49:15 CEST] <JEEB> and then you can just re-time the output packet. or you're just remuxing
[22:50:25 CEST] <Mavrik> Most of the stuff doesn't really care all that much.
[22:50:33 CEST] <Mavrik> I had to do a few fixes in vf_fps
[22:51:09 CEST] <Mavrik> And I think two or three other fixes.
[22:51:20 CEST] <Mavrik> But it's a rather specific use-case - MPEG-TS -> transcode -> MPEG-TS
[22:51:35 CEST] <JEEB> yea
[22:51:46 CEST] <JEEB> also I just read the code and noticed that you can't add extra streams?
[22:51:53 CEST] <JEEB> in the mpegts muxer
[22:52:05 CEST] <JEEB> unless I read it wrong
[22:53:02 CEST] <JEEB> so if I will ever have to do broadcast I guess I'll have to either implement that or just look for a "proper" MPEG-TS muxer
[22:53:30 CEST] <Mavrik> Yeah, for me that's not an issue yet
[22:53:47 CEST] <JEEB> yea, not an issue for me either
[22:53:53 CEST] <Mavrik> The input streams are all very stable (they come from content providers and are emitted to IPTV targets)
[22:54:03 CEST] <JEEB> that's the usual thing :)
[22:54:10 CEST] <Mavrik> Not sure if anyone even uses that capability here.
[22:54:20 CEST] <JEEB> at least the inputs do :D
[22:54:25 CEST] <Mavrik> The only real panful thing that made me think about switching muxers was trying to emit to DVB-C
[22:54:38 CEST] <Mavrik> Aaaand that did not go well at all with ffmpegs muxer
[22:54:42 CEST] <JEEB> yea libavformat is gonna fail hard at that
[22:54:47 CEST] <JEEB> it's not a "real" MPEG-TS muxer
[22:55:03 CEST] <Mavrik> I think they just bought a few Ciscos for that instead of spending a lot of time porting to another TS library
[22:55:18 CEST] <Mavrik> Since I wasn't really able to find any good ones that wouldn't cost the same as getting a few encoders
[22:55:41 CEST] <Mavrik> (See also: budgeting politics)
[22:56:00 CEST] <JEEB> I had a couple of alternatives but I haven't touched either
[23:31:56 CEST] <kepstin> c7j8d9: as far as I can tell, the vp8/vp9 support on nvidia cards is decode-only.
[23:32:33 CEST] <kyleogrg> Using ffmpeg to pipe 2560x1440 video to x265, with --crf 20, --preset slower, --no-sao, -rskip.  This is in Lubuntu in Virtualbox, on Windows 10.  Processor is ASUSTek P8H67-M EVO.  Thoughts on how to speed up encoding at minimal quality loss?
[23:32:40 CEST] <c7j8d9> that's what I am figuring out too...thanks for checking
[23:33:27 CEST] <kepstin> kyleogrg: you listed your motherboard, not your processor :) But if you want to speed up encoding... use a faster preset?
[23:34:06 CEST] <kyleogrg> oops, processor is Intel Xeon E3 1230 v2
[23:34:19 CEST] <kepstin> kyleogrg: also, consider using x264 instead of x265.
[23:34:48 CEST] <kyleogrg> kepstin: sure, i might just try a faster preset.  just wondering if there were other tweaks too.  i like x265 for the smaller file size
[23:35:52 CEST] <kepstin> kyleogrg: in general, the devs have the presets set up to already do the minimum quality change for maximum speed difference between them, so there's no real reason to do manual tweaking unless you want something inbetween
[23:36:29 CEST] <kyleogrg> kepstin: ok, i will do some tests, but i wonder how much of a size difference there is between medium and slower
[23:36:32 CEST] <kepstin> and unless you're using x265 with a preset that's slower than x264 with 'veryslow', you're probably not actually getting smaller file sizes anyways (for the same quality)
[23:37:55 CEST] <kyleogrg> kepstin: i've thought about that.  but aren't you supposed to get noticeably smaller videos with x265 over x264?
[23:38:37 CEST] <kepstin> kyleogrg: in theory if you use a reference encoder (very very slow) and >HD content, the size of H.265 video will be smaller than H.264 for the same quality
[23:38:54 CEST] <kyleogrg> what's a reference encoder?
[23:39:29 CEST] <kepstin> in practice, x264 is a really damn good encoder, and all x265 encoders isn't optimized to the same point yet.
[23:40:35 CEST] <kyleogrg> i guess it takes time, because it's been several years that i've heard about x265 development
[23:40:40 CEST] <kepstin> a "reference encoder" is an encoder built while designing a codec, usually as a way to test all the possible features; generally they aren't optimized for speed but rather to simply encode video at max quality.
[23:41:07 CEST] <kyleogrg> hmm, so what are some x265 reference encoders?
[23:41:25 CEST] <furq> that's max quality not relative to bitrate
[23:42:21 CEST] <kepstin> how old is x264 now anyways? Got to be >10years.
[23:42:26 CEST] <furq> at least 13
[23:42:31 CEST] <furq> https://hevc.hhi.fraunhofer.de/trac/hevc/browser
[23:42:34 CEST] <furq> this is the hevc reference encoder fwiw
[23:42:47 CEST] <furq> i don't recommend using it unless you're that russian website that publishes slightly wonky codec comparisons
[23:43:05 CEST] <kepstin> if you're looking for a way to speed up your hevc encodes... using the reference encoder is not it ;)
[23:43:16 CEST] <furq> but yeah x264 is much older and actively invited contributions
[23:44:06 CEST] <furq> it's really hard to beat even with a new standard
[23:44:18 CEST] <kyleogrg> kepstin: yes... this would be even slower.  i guess i'll likely have to stick with x264, which is very good.  i was just trying to keep up with newer technology.  i thought x265 would be fairly mature after several years.
[23:44:22 CEST] <furq> last time i saw a comparison, x264 beats x265 at the same speed
[23:44:32 CEST] <furq> but obviously x265 has much slower settings you can use
[23:44:55 CEST] <JEEB> the real issue is, x265 just doesn't get as much love to actually optimize the coding tools at its disposal. which there are plenty new
[23:45:02 CEST] <furq> right
[23:45:15 CEST] <JEEB> they can copy stuff from x264, but that only works for features that were in AVC
[23:45:23 CEST] <kyleogrg> JEEB: you mean everyone loves x264 too much, basically?
[23:45:36 CEST] <furq> x264 is much more highly optimised
[23:45:53 CEST] <furq> because it's older and attracted a ton of developers from all over the place
[23:45:54 CEST] <JEEB> kyleogrg: it was an actual OSS project handled by nerds and various corporate projects handled by those nerds
[23:46:10 CEST] <JEEB> when you get a community around something it tends to get better
[23:46:24 CEST] <kyleogrg> JEEB: ok, so x265 development isn't like that?
[23:46:38 CEST] <JEEB> x265 tried to do open source, but flopped due to various reasons
[23:46:44 CEST] <kyleogrg> ah
[23:46:51 CEST] <JEEB> I even tried to contribute at the very beginning :P
[23:47:02 CEST] <furq> i can imagine people being less interested anyway
[23:47:04 CEST] <JEEB> (I think I even might have a patch in the build system)
[23:47:07 CEST] <furq> x264 was pretty revolutionary
[23:47:17 CEST] <furq> whereas x265 seems more like an incremental step
[23:47:30 CEST] <furq> unless you're doing 4k, which you probably aren't
[23:47:30 CEST] <JEEB> that's the hard part of optimizing. there are good tools in HEVC, but a lot of them lead to PSNR-optimized results
[23:47:47 CEST] <kyleogrg> i guess i just heard the hype about x265 being, you know, like 60% the size of x264 videos
[23:47:51 CEST] <JEEB> kyleogrg: so in the end it was just MCW and a couple of randoms (I think one guy from Oki?)
[23:47:58 CEST] <JEEB> kyleogrg: don't mish-mash formats and encoders
[23:48:08 CEST] <furq> yeah that's h264 vs h265
[23:48:23 CEST] <JEEB> HEVC as it as a format goes, according to testing done by JCT-VC
[23:48:39 CEST] <furq> if you're comparing the reference encoders then 30-50% is probably true
[23:48:39 CEST] <JEEB> that you should be able to get ~40% improvement in file size
[23:48:52 CEST] <furq> but x264 is much better than the h264 reference encoder
[23:49:06 CEST] <furq> x265 is better than the h265 reference encoder, but comparatively less than x264
[23:49:09 CEST] <JEEB> yes, of course it was reference encoders, and I guess they know their shit and it's the theoretical improvement you can get (with X% of error)
[23:49:14 CEST] <kyleogrg> hmm, so if i went with the slowest settings on the HEVC (not x265) reference encoder, it would indeed beat x264 in file size?
[23:49:25 CEST] <JEEB> ahahaha, HM
[23:49:35 CEST] <furq> shrug
[23:49:37 CEST] <JEEB> kyleogrg: no it was reference encoder vs reference encoder
[23:49:41 CEST] <furq> ^
[23:49:45 CEST] <JEEB> kyleogrg: also you don't want frame per minute speeds
[23:49:51 CEST] <JEEB> I encoded clips with HM
[23:49:52 CEST] <JEEB> in late 2012
[23:50:09 CEST] <JEEB> you not only have to manually configure the hell out of it, it has no real optimizations in it
[23:50:36 CEST] <JEEB> the end theme is that someone has to care for a current-gen format for it to be more viable than previous-gen formats
[23:50:50 CEST] <kyleogrg> yeah
[23:50:53 CEST] <furq> i expect AV1 has taken the wind out of x265's sails as well
[23:50:57 CEST] <JEEB> if the best previous gen encoder is good enough, and the format difference is not as big as with MPEG-4 Part 2 => AVC
[23:51:11 CEST] <furq> in terms of developer attention
[23:51:19 CEST] <JEEB> I mean, AVC was already wow because of stuff like in-loop deblocking or CABAC
[23:51:21 CEST] <kyleogrg> okay, what about vp9?  i guess that's mainly youtube's thing?
[23:51:30 CEST] <JEEB> kyleogrg: yea it's a one-vendor thing
[23:51:38 CEST] <furq> vp9 doesn't have any future
[23:51:42 CEST] <JEEB> AOM and AV1 is the thing where they took VP10 and took other people in
[23:51:47 CEST] <JEEB> and groups
[23:51:55 CEST] <furq> AV1 is more or less the future of vp9
[23:52:12 CEST] <furq> and hopefully the future of all video that isn't on apple devices
[23:52:13 CEST] <JEEB> but yea, I hope having more than one cook in the mess will improve things
[23:52:14 CEST] <kyleogrg> JEEB: given the choice between HEVC and VP9, which would you say is better?  not talking about compatibility
[23:52:29 CEST] <JEEB> kyleogrg: HEVC was actually made with a specification
[23:52:40 CEST] <JEEB> VP9 should now have a spec, but it definitely wasn't made with one
[23:52:41 CEST] <furq> in terms of encoders, x265 is p much universally thought of as better than libvpx-vp9
[23:52:54 CEST] <JEEB> (also I hate the way GOOG did its formats behind closed doors)
[23:53:06 CEST] <JEEB> BBB's proprietary VP9 encoder might be better than x265
[23:53:15 CEST] <JEEB> but that's gonna be business-to-business licensed
[23:53:22 CEST] <JEEB> so we're not gonna see it
[23:53:24 CEST] <furq> right
[23:54:29 CEST] <furq> x264 is good enough to tide us over until av1 is mature enough to bother with
[23:54:38 CEST] <furq> it's certainly good enough to tide me over anyway
[23:54:46 CEST] <kyleogrg> so when i download a youtube video, why is the vp9 file size often larger than the avc/mp4 version (at the same res)?  i thought the idea of vp9 was to save bandwidth
[23:55:06 CEST] <furq> it's almost always smaller at the same resolution in my experience
[23:55:09 CEST] <furq> and it often looks noticeably better
[23:55:19 CEST] <Diag> Because vp9 is softer instead of blocky
[23:55:21 CEST] <furq> i've not done exhaustive checks though, and youtube is notoriously weird
[23:55:50 CEST] <Diag> It's quality just gets bad, it doesn't give you the notorious jpeg compression artifacts
[23:56:24 CEST] <JEEB> kyleogrg: you have to keep in mind that 'tube doesn't really encode for quality anyways
[23:56:33 CEST] <furq> i only really notice it with pathological cases like strobing, water etc
[23:56:43 CEST] <furq> the h264 encode is almost always fine
[23:56:50 CEST] <JEEB> and it's not a surprise they would give more rate to the VP9 thing compared to AVC
[23:57:02 CEST] <JEEB> after all, HAVE TO SHOW HOW VP9 IS BETTUR
[23:57:34 CEST] <kyleogrg> well, i know this isn't really the place, but using youtube-dl at "bestvideo" rarely seems to give me VP9.  so i manually told it to download the best VP9, because it might be the same or higher quality even though the bitrate is lower
[23:57:52 CEST] <furq> you can check the bitrates with youtube-dl -F
[23:57:52 CEST] <JEEB> it really depends on what kind of settings 'tube is using
[23:58:12 CEST] <JEEB> I mean, you're expecting them to try and match settings while they could be skewing things however they want
[23:58:15 CEST] <furq> in my experience 1080p30 h264 is usually 3.5mbit and vp9 is closer to 2.5
[23:58:22 CEST] <kyleogrg> furq: sure, but i expect VP9 to have lower bitrate at identical quality
[23:58:39 CEST] <furq> that is the case in my experience
[23:59:07 CEST] <kyleogrg> that's what i imagined too, because i think that's part of yt's motivation, to save bandwidth
[23:59:10 CEST] <JEEB> anyways, if nothing else on firefox VP9 is nice because it uses FFmpeg's VP9 decoder which BBB optimized to sell his encoder :D
[23:59:23 CEST] <kyleogrg> okay, what's bbb?
[23:59:27 CEST] <JEEB> it's a person
[23:59:33 CEST] <JEEB> (also a video clip)
[00:00:00 CEST] --- Tue Jul 18 2017