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

[burek]

[00:00:05 CEST] <furq> yes there is
[00:00:16 CEST] <kerio> well ok you can brag about it
[00:00:20 CEST] <furq> 96/24 is essential if you want ot be Smug On Line
[00:00:22 CEST] <alexpigment> kerio: I was really talking about bitrates in response to Threads' comment
[00:00:24 CEST] <Threads> alexpigment thats very true yes i cant lie i have an old drive somewhere with flac albums on it
[00:00:54 CEST] <alexpigment> but yeah 96/24 is not a delivery format for most music, so yeah, i'm at 16-bit 44.1khz for pretty much everything
[00:01:18 CEST] <kerio> 7056000hz when
[00:02:02 CEST] <kerio> so you can downsample to 44100 and 48000 without complicated math
[00:02:06 CEST] <alexpigment> kerio: maybe they'll update DSD and it'll have a comically large sample rate
[00:02:08 CEST] <durandal_170> look at sacd
[00:02:23 CEST] <kerio> thankfully we're not bound to physical media anymore
[00:02:51 CEST] <alexpigment> durandal_170: yeah that was the joke I was making. DSD has a low bit depth but huge sample rate
[00:04:11 CEST] <pzy> 24/96 and HDR audio only!
[00:04:38 CEST] <alexpigment> "HDR"... that word is getting used in more and more ridiculous ways every day ;)
[00:04:53 CEST] <pzy> audio had it first ;)
[00:04:55 CEST] <alexpigment> yeah
[00:05:01 CEST] <alexpigment> i mean admittedly it makes sense with audio
[00:05:22 CEST] <pzy> kerio: did you see that bizarro "metal positive matrix" OK Computer rip?
[00:05:35 CEST] <alexpigment> i have to explain to people all the time why HDR video is not the same as HDR photos from a few years ago
[00:05:40 CEST] <kerio> vinyl lul
[00:05:47 CEST] <pzy> that's what I said
[00:05:50 CEST] <pzy> but it's not quite that
[00:06:02 CEST] <pzy> http://forums.stevehoffman.tv/threads/metal-positive-matrix-vinyl.663612/
[00:06:11 CEST] <kerio> i mean
[00:06:15 CEST] <kerio> it might be high quality
[00:06:19 CEST] <kerio> but it's still some analog crap
[00:06:38 CEST] <kerio> also, the mastering is the same as the 97 cd right
[00:06:53 CEST] <pzy> yeah but.... the original tapes are analog too :P
[00:07:11 CEST] <pzy> just another interesting version to digest
[00:07:12 CEST] <furq> is it still radiohead
[00:07:15 CEST] <kerio> yeah but the original tapes are not in a format ready for distributio
[00:07:15 CEST] <kerio> n
[00:07:24 CEST] <kerio> furq is SO HYPED about the ok computer rerelease
[00:07:30 CEST] <durandal_170> what about dolby atmos and dts:x?
[00:08:05 CEST] <alexpigment> you know, i'm a pretty huge radiohead fan, but i find them to be too relatable as humans during the OK Computer era. I can kinda get how they wrote some of the songs
[00:08:41 CEST] <alexpigment> with Kid A and onward, I'm just puzzled by how they made any of those songs. it really makes me think less of any 90s-era radiohead
[00:09:19 CEST] <kerio> you mean kid A and amnesiac, right
[00:09:29 CEST] <kerio> and maybe half of HTTT
[00:10:23 CEST] <kerio> i mean whats not to understand about bangers+mash
[00:14:56 CEST] <alexpigment_> weird, what's going on with freenode?
[00:15:26 CEST] <pzy> you'll get it
[00:15:26 CEST] <pzy> 10 years from now
[00:15:26 CEST] <pzy> time uncomplicates all music
[00:15:49 CEST] <alexpigment> sorry, freenode went down on me
[00:16:08 CEST] <alexpigment> kerio: yes, kid A up to king of limbs
[00:16:16 CEST] <DHE> it does that a lot. IRC tends to be like that
[00:16:25 CEST] <kerio> alexpigment: to be fair
[00:17:11 CEST] <kerio> even kid A can be decomposed quite easily in its main constituents
[00:17:25 CEST] <kerio> namely, "thom is sad" and "jonny bought an ondes martenot"
[00:17:26 CEST] <alexpigment> what about the song "Kid A"?
[00:17:31 CEST] <alexpigment> haha
[00:18:22 CEST] <kerio> my biggest regret in life is always going to be not having a lossless version of https://soundcloud.com/iamjfp/a-thousand-miles-x-hard-in-da-paint-vanessa-carlton-waka-flocka
[01:07:56 CEST] <Sashmo_> is there a way to make ffmpeg encoding to file to always end on a I frame?
[01:09:21 CEST] <vlt> Sashmo_: One would be to use I-frames only.
[01:09:37 CEST] <vlt> Technically.
[01:10:00 CEST] <JEEB> Sashmo_: you could use the API or use a frame type file (at least for x264, no idea about the rest of the encoders)
[01:10:01 CEST] <Sashmo_> dont have that option, need to set bitrate to like 1Mbps and if I do all I frames only, I get crappy quality
[01:10:12 CEST] <JEEB> no idea why you'd need an I frame at the end tho
[01:10:54 CEST] <Sashmo_> well, if I dont end on an I frame, then the end of the file GOP is incomplete and will allways get a macro block at the end
[01:11:54 CEST] <kerio> https://www.youtube.com/watch?v=WIIKXOrt3bk "high quality 256kbps mp3"
[01:11:57 CEST] <kerio> and no mention of opus
[01:12:00 CEST] <kerio> ayfkm
[01:12:37 CEST] <JEEB> Sashmo_: what
[01:12:39 CEST] <furq> why are you watching this
[01:12:41 CEST] <JEEB> that makes no sense
[01:12:50 CEST] <JEEB> a GOP is from a RAP to X
[01:13:04 CEST] <kerio> furq: because i go hard in the motherfucking paint
[01:13:06 CEST] <Sashmo_> it does for special project, I need to end on a key frame regarless of the diration of the file if its not factor of the GOP
[01:13:20 CEST] <furq> is that why you're banned from so many basketball courts
[01:13:26 CEST] <JEEB> well there you go. it's just really misleading to say that your GOP is broken because it doesn't end with a RAP
[01:13:33 CEST] <JEEB> :P
[01:14:13 CEST] <JEEB> Sashmo_: anyways, if you know the input lengths every time, with libx264 you can use a frame type file
[01:14:23 CEST] <JEEB> which lets you define the last picture as a RAP
[01:14:32 CEST] <JEEB> and everything else will be "auto"
[01:14:32 CEST] <Sashmo_> whats a RAP ?
[01:14:36 CEST] <JEEB> Random Access Picture
[01:14:51 CEST] <JEEB> includes IDR as well as all the other types of things including those in Open GOP
[01:15:14 CEST] <Sashmo_> I need a fixed GOP, with the ability to complete the last GOP in a file regardless of duration, even if it has to be "vairiable gop" becuase of the timeing, that can happen at the end, I dont care
[01:15:27 CEST] <Sashmo_> hmmm Ive never heard of RAP before
[01:15:33 CEST] <Sashmo_> thats an x264 option?
[01:15:35 CEST] <JEEB> no
[01:15:39 CEST] <JEEB> it's a thing in the specification
[01:16:03 CEST] <JEEB> also what does "complete the last GOP" actually mean?
[01:16:19 CEST] <Sashmo_> what dont you get?  if the file has a fixed gop of 15
[01:16:20 CEST] <JEEB> because that just means a normal GOP for me
[01:16:38 CEST] <Sashmo_> that calculation of how many GOPS it does till the end of the file
[01:16:50 CEST] <Sashmo_> needs to be a factor of that duration or it will be incomplete
[01:17:01 CEST] <Sashmo_> hence the file ends on  a P or  B frame
[01:17:05 CEST] <Sashmo_> indtead of an I frame
[01:17:12 CEST] <JEEB> ...
[01:17:16 CEST] <Sashmo_> and P and B are not complete frames
[01:17:21 CEST] <kerio> why would the file end on a I-frame
[01:17:21 CEST] <JEEB> a GOP is complete even if it doesn't have a RAP at the end
[01:17:27 CEST] <Sashmo_> no its not
[01:17:43 CEST] <JEEB> yes it is, this is your specific requirements, just note that instead of trying to speak in generalities
[01:17:44 CEST] <Sashmo_> jsut do ffrpobe show pict
[01:17:55 CEST] <Sashmo_> the end of the file can be I P or B
[01:18:00 CEST] <Sashmo_> but its not constant
[01:18:03 CEST] <kerio> a GOP just means that all the frames inside can be decoded without referring to frames outside of the GOP
[01:18:07 CEST] <JEEB> ^this
[01:18:28 CEST] <JEEB> a GOP is "something that starts with a RAP and all following images in presentation order can be decoded after you start from the RAP"
[01:18:52 CEST] <Sashmo_> ok sure thats the begining of the file
[01:18:58 CEST] <Sashmo_> Im talking about the end
[01:18:59 CEST] <kerio> JEEB: does it have to start from a RAP
[01:19:04 CEST] <JEEB> kerio: yes
[01:19:14 CEST] <kerio> why can't the RAP be like the second frame
[01:19:22 CEST] <kerio> with the first frame being a B frame
[01:19:26 CEST] <JEEB> you can have coded images in decoding order that are after the RAP but are before in presentation
[01:19:32 CEST] <kerio> oh i see
[01:19:34 CEST] <JEEB> and which do not have to be decode'able
[01:19:39 CEST] <JEEB> it's complicated.jpg
[01:19:48 CEST] <JEEB> that's why I specify "in presentation order"
[01:19:54 CEST] <kerio> no no it's as i imagined it
[01:19:59 CEST] <kerio> i think
[01:20:29 CEST] <Sashmo_> do you think if I add force keyframes option and set the end of the file time as the key frame it would throw one in there? or is that option a starting point to insert from?
[01:20:29 CEST] <JEEB> Sashmo_: it really doesn't matter in general. if you will get out of that state that what you're required to create is the standard we're all OK
[01:20:47 CEST] <kerio> -g 1
[01:20:51 CEST] <JEEB> otherwise I will keep telling you that your definition is incorrect
[01:21:01 CEST] <kerio> trivial groups of pictures
[01:21:18 CEST] <Sashmo_> JEEB: I disagree.  If I want to seemless replace at the frame level one video for another video, it should happen on the key frame
[01:21:19 CEST] <JEEB> anyways, do you want a RAP at the end or do you want to make the image count divisible by your GOP legnth?
[01:21:38 CEST] <Sashmo_> JEEB: thats acceptable
[01:21:46 CEST] <Sashmo_> I think that could work
[01:21:55 CEST] <Sashmo_> the GOP in the file dosnt matter
[01:22:03 CEST] <Sashmo_> as long as I start and end on Is
[01:22:49 CEST] <JEEB> Sashmo_: no. if you want to replace GOPs in your file all that is needed in AVC and HEVC is that a) the parameter sets match (and/or are avaialble to the decoder) and B) you have all the images in your previous GOP decode'able and start with the RAP of the GOP that you want to stick together
[01:23:20 CEST] <JEEB> thus it is not a requirement for stitching streams together to have a RAP at the end of a GOP
[01:23:30 CEST] <JEEB> but maybe I have no fucking clue about these things
[01:23:36 CEST] <JEEB> yea, that must be it
[01:25:16 CEST] <Sashmo_> well could be
[01:25:27 CEST] <Sashmo_> cuz RAP is not random access picture
[01:25:37 CEST] <Sashmo_> its a random access point
[01:25:39 CEST] <Sashmo_> as I read it
[01:27:48 CEST] <JEEB> it's the previous one in 14496-12, and "picture" in HEVC most likely
[01:27:56 CEST] <JEEB> 14496-12 being the mp4 container
[01:28:15 CEST] <JEEB> or wait no
[01:28:23 CEST] <Sashmo_> I trust 10000% you know more than me
[01:28:27 CEST] <Sashmo_> so I wont debate
[01:28:29 CEST] <Sashmo_> just asking....
[01:28:40 CEST] <JEEB> picture in HEVC I thought, but it could be that they write "RAP picture" there
[01:28:48 CEST] <JEEB> in that case it's the same as 14496-12
[01:28:50 CEST] <JEEB> "point"
[01:29:10 CEST] <JEEB> but yea, as long as you have the parameter sets available and all of the coded images in the "first" GOP are decode'able
[01:29:30 CEST] <JEEB> then as long as your start from the RAP of your "following" GOP
[01:29:34 CEST] <JEEB> you should be OK
[01:29:45 CEST] <JEEB> (exceptions would be bugs in the decoders)
[01:30:01 CEST] <Sashmo_> correct, on the decoders 100%
[01:30:15 CEST] <JEEB> preferably you have the exact same parameter sets on all GOPs tho
[01:30:21 CEST] <JEEB> in which case bugs are unlikely
[01:30:53 CEST] <JEEB> (which basically means using the same settings and having the same resolution and bit depth and chroma subsampling between the GOPs)
[01:32:09 CEST] Action: JEEB hits the sack
[01:32:19 CEST] <kerio> ouch D:
[01:33:48 CEST] <Sashmo_> gnight! thanks for the wise info
[01:46:45 CEST] <thomedy> i have broken up  my mp4 into images and seperated out the audio
[01:47:22 CEST] <thomedy> i can combine the audio back into the the film when i push the imges together agin and go from 0 - end frames
[01:48:02 CEST] <thomedy> but i want too use -start_number and vframes to only do lets say 31 - 60 frames or the 2nd second with synced audio
[07:16:12 CEST] <fern> anoyne here can help me trying to split an FireWire DV Camera into audio and video? I only get video and can't get audio
[10:06:09 CEST] <termos> I'm pushing some decoded video to my filter graph with av_buffersrc_add_frame_flags and receiving it in another thread, but on the receiving end the AVFrame.pkt_dts is no longer monotonically increasing. Is the filter graph known to reorder packets somehow? It's making my flv muxer complain about the dts values
[10:07:13 CEST] <termos> The AVFrame.pkt_dts is monotonically increasing before I push it into my filter graph, but not on the outcoming AVFrames
[10:11:38 CEST] <durandal_1707> depends on graph
[10:17:04 CEST] <termos> ah it's happening after the filter graph, I need to investigate some more
[10:29:11 CEST] <DHE> AVFrames usually don't have dts values
[10:29:20 CEST] <DHE> or at least the value is not relevant
[10:31:38 CEST] <termos> the problem was caused by my own code, huge surprise! I'm pushing AVPackets from different encodings into the same AVThreadMessageQueue and pulling from it into the muxer. weird artifacts in the video as well, which makes sense
[14:32:34 CEST] <kerio> theres radioheds
[14:32:39 CEST] <kerio> in mp3 320 D:
[14:32:43 CEST] <kerio> fug
[14:33:29 CEST] <kerio> ok nvm got the flac
[16:05:09 CEST] <immelting> I have a question about FFmpeg 3.3.1: I've downloaded & installed it. According to what I've read I've expected to have to do anything additional so that FFmpeg uses the GNU GPLv3 license.
[16:05:31 CEST] <c_14> --enable-gpl --enable-version3
[16:06:05 CEST] <c_14> though I'm not sure what requires v3, v2 should be fine for almost everything
[16:07:05 CEST] <immelting> But when I run "ffmpeg -version" it says under "configuration" "--enable-gpl" and "--enable-version3", so... is FFmpeg GNU GPLv3 by default?
[16:07:16 CEST] <c_14> in that config, yes
[16:07:23 CEST] <c_14> by default no
[16:07:38 CEST] <c_14> the person who built your ffmpeg binary decided to make it gplv3
[16:07:55 CEST] <furq> ffmpeg is normally lgpl2
[16:08:03 CEST] <immelting> but I've switched or changed nothing; just downloaded & installed, so said config is the default...
[16:08:05 CEST] <furq> some external libs require gpl2, and some require gpl3
[16:08:19 CEST] <c_14> immelting: FFmpeg the project does not distribute binaries
[16:08:23 CEST] <furq> if you downloaded an ffmpeg binary then the license depends on what libs that binary comes with
[16:08:42 CEST] <c_14> the binaries are distributed by independent third parties who decide how they're built
[16:08:47 CEST] <furq> https://www.johnvansickle.com/ffmpeg/
[16:08:56 CEST] <furq> if you downloaded this then it's gplv3 because of libopencore
[16:08:59 CEST] <c_14> they are only linked on the main page to make it easier for people who don't want to build from the source
[16:09:49 CEST] <immelting> Really? This is where I got FFmpeg 3.3.1 from - it was linked from the official page and seem official, as well: https://ffmpeg.zeranoe.com/builds/
[16:10:02 CEST] <furq> yeah those aren't official
[16:10:05 CEST] <furq> otherwise they'd be on ffmpeg.org
[16:10:09 CEST] <immelting> Oh...
[16:10:35 CEST] <c_14> I swear there was a disclaimer there at some point
[16:10:36 CEST] <furq> they're just done by people who the project considers reasonably trustworthy
[16:11:13 CEST] <immelting> Well, but I'm fine with it. All I wanted to do is rendering an animation with a software, which uses GNU GPLv3, apparently this official build embodies this. :)
[16:11:50 CEST] <immelting> ehm, inofficial build...
[16:12:26 CEST] <furq> c_14: yeah i remember there being a disclaimer
[16:12:37 CEST] <furq> not sure why they'd get rid of that
[16:12:41 CEST] <furq> whoever "they" is
[16:13:10 CEST] <immelting> But I do encourage the official project to fully transition to GNU GPLv3 - I'm certainly not the only one for whom user freedom has top priority when it comes to choosing software.
[16:26:34 CEST] <alexp> hey guys. I logged an issue regarding bad aliasing on NVENC in certain scenarios, and it turns out that the issue is specific to the yuv420p pixel format - it doesn't occur with nv12. being a bit of a pixel format noob, does nv12 differ in a significant enough way to cause player compatibility issues, particularly on hardware formats like Blu-ray/AVCHD?
[16:38:37 CEST] <alexp> \nick alexpigment
[16:41:03 CEST] <dreamon> Hello. doing ’ ffmpeg -i input.mpg out.mkv ’ http://pastebin.ubuntu.com/24917350/
[16:41:18 CEST] <jkqxz> alexpigment:  NV12 and YUV420P contain identical information, and should generate identical output.
[16:42:15 CEST] <jkqxz> alexpigment:  Them doing different things suggests a bug somewhere.  How are you testing the two to come to that conclusion?
[16:43:01 CEST] <dreamon> what I did. playing a VHS video ’ recording it with a DVD recording DVD-RW media. Now I rip it with k9copy. Now I have a mpg. VLC plays it without problems. All other player making fragmented picture.
[16:43:29 CEST] <alexpigment> jkqxz: https://trac.ffmpeg.org/ticket/6260
[16:44:08 CEST] <dreamon> now tried to convert with ffmpeg but getting a huge mount of errors. Playing the output.mky looks same bad. But vlc can play the mpg well.
[16:44:34 CEST] <alexpigment> the reproduction steps cause the issue; if you add -pix_fmt yuv420p, the issue occurs. if you add -pix_fmt nv12 instead, the issue goes away
[16:46:02 CEST] <dreamon> alexpigment, me?
[16:46:11 CEST] <alexpigment> jkqxz: but if the output of yuv420p and nv12 are functionally identical, it's sort of a non-issue for me going forward, even if it's an issue with ffmpeg
[16:46:27 CEST] <alexpigment> dreamon: no, I was talking to jkqxz, sorry
[16:46:38 CEST] <dreamon> ;)
[16:46:59 CEST] <alexpigment> i've done a lot of VHS > DVD Recorder stuff in the past though. it's very finicky from what I recall. I don't have any solutions though :(
[16:47:19 CEST] <furq> alexpigment: they're both 4:2:0 yuv, just packed slightly differently
[16:47:34 CEST] <alexpigment> good to know, furq. thanks
[16:47:40 CEST] <furq> i think all the commercial hardware encoders use nv12 natively
[16:47:50 CEST] <furq> so i guess some conversion is going wrong somewhere
[16:48:00 CEST] <furq> s/commercial/consumer/
[16:49:28 CEST] <jkqxz> From the picture on that bug, maybe it has switched the top and bottom field?
[16:49:37 CEST] <furq> do you actually get nv12 output from it
[16:49:59 CEST] <jkqxz> No idea why nv12 would change anything with that, though.  Maybe there is something funny in the nvidia driver depending on the input format.
[16:50:55 CEST] <jkqxz> furq:  The output is an H.264 stream, so there will be no difference between yuv420p and nv12 (they're both YUV 4:2:0, which is all H.264 cares about).
[16:51:42 CEST] <furq> actually nvm
[16:51:58 CEST] <furq> i was wondering if it would be sending yuv420p input to nvenc, but of course it is
[16:52:15 CEST] <furq> i forgot how video encoding works for a minute there
[16:52:28 CEST] <alexpigment> jkqxz: if the bottom and top were switched, I figure I'd see the problem everywhere. oddly, it's only certain places you notice it. it also happens on progressive too, but to a lesser degree
[16:53:10 CEST] <jkqxz> It looks switched everywhere on that image.
[16:54:11 CEST] <furq> yeah that looks like textbook wrong field order
[16:54:37 CEST] <furq> at least the png does
[16:54:40 CEST] <furq> i've not looked at the videos
[16:54:53 CEST] <alexpigment> I guess you guys can look at the sample video if you don't believe me, but the motion itself isn't judder-y
[16:54:56 CEST] <alexpigment> it's perfectly smooth
[16:55:04 CEST] <jkqxz> Yeah, I only looked at the png too.
[16:55:51 CEST] <alexpigment> now if there was some sort of color-only field problem, I might believe that, but it still doesn't explain why it affects progressive
[16:57:36 CEST] <furq> does the progressive output look noticeably better with nv12
[16:58:00 CEST] <furq> progressiveoutput.mp4 looks broadly fine to me
[16:58:55 CEST] <alexpigment> lemme check
[17:00:13 CEST] <furq> i mean it doesn't look amazing but it doesn't look obviously buggy
[17:01:19 CEST] <alexpigment> yeah, i'm still seeing it there
[17:01:23 CEST] <alexpigment> look at the bottom area of the red ring
[17:01:34 CEST] <furq> with nv12?
[17:01:36 CEST] <alexpigment> there's this aliasing that kinda moves down the ring
[17:01:37 CEST] <alexpigment> oh
[17:01:38 CEST] <alexpigment> no
[17:01:41 CEST] <furq> oh right
[17:01:42 CEST] <alexpigment> with yuv420p
[17:01:53 CEST] <alexpigment> nv12 looks good
[17:02:05 CEST] <furq> fair enough then
[17:03:01 CEST] <alexpigment> yeah, i at least have a good workaround, so I'm fine now
[17:03:18 CEST] <alexpigment> but it does make a good argument to always use nv12 rather than assuming yuv420p
[17:03:36 CEST] <furq> it would maybe be better if yuv420p just broke
[17:03:39 CEST] <alexpigment> rather, it makes a good argument for FFMPEG to use nv12 for nvenc rather than assuming yuv420p
[17:03:46 CEST] <furq> oh
[17:03:50 CEST] <furq> i thought you were specifying yuv420p
[17:03:59 CEST] <alexpigment> no
[17:04:00 CEST] <furq> i should probably read the bug report better
[17:04:10 CEST] <alexpigment> however if i specify yuv420p it's the same as not specifying it
[17:04:49 CEST] <alexpigment> furq: no worries. my bug report was probably long-winded and didn't summarize it well in the first place
[17:05:38 CEST] <alexpigment> and at the time i logged it, I didn't know it was a yuv420p problem. that info came from a comment on the bug that someone made 6 hours ago
[17:14:49 CEST] <alexpigment> on an entirely unrelated note, I'm trying to recreate AVC Intra (more or less) with NVENC right now. I can't figure out how to turn off CABAC. I guess -coder 0 is just ignored?
[17:16:39 CEST] <alexpigment> also, if i'm setting the gop to 1, should I use this -forced-idr parameter? admittedly, i'm not sure if there's any difference between I and IDR in a "-g 1" setup
[17:17:13 CEST] <JEEB> AVC Intra is a fucked up thing
[17:17:15 CEST] <alexpigment> (ignore the IDR thing. they're doing that already)
[17:17:21 CEST] <alexpigment> JEEB: why is that?
[17:17:45 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=9b94896b3735052cabb52d081de3b50020a077cb
[17:17:47 CEST] <alexpigment> are you talking about the format itself or the concept of an intra-only video?
[17:17:49 CEST] <JEEB> missing parameter sets
[17:17:51 CEST] <JEEB> etc
[17:17:58 CEST] <JEEB> AVC-Intra, the way of doing vendor lock-in
[17:18:03 CEST] <JEEB> with a standard format
[17:18:04 CEST] <JEEB> :V
[17:18:16 CEST] <JEEB> you should just look at some of that crap and FFFUUUU
[17:18:45 CEST] <alexpigment> ahh, I'm not really trying to recreate AVC Intra to comply with any specifications to be honest
[17:19:08 CEST] <JEEB> well that's what you mean when you say "AVC(-| )Intra"
[17:19:10 CEST] <alexpigment> the principles of AVC Intra, though, are important for NLEs
[17:19:11 CEST] <JEEB> with the big things
[17:19:20 CEST] <alexpigment> fair point
[17:19:25 CEST] <JEEB> if you said just intra-only AVC that'd be OK
[17:19:46 CEST] <alexpigment> ok, yes, i'm trying to create intra-only AVC
[17:20:09 CEST] <jkqxz> If only the real H.264 specification included intra profiles.
[17:20:42 CEST] <alexpigment> well, MediaInfo shows a profile of High Intra on x264, for what it's worth
[17:20:56 CEST] <alexpigment> i'm not sure if that makes any difference
[17:21:06 CEST] <JEEB> that's most likely just mediainfo's bullshit
[17:21:07 CEST] <alexpigment> but NVENC just produces High profile
[17:21:18 CEST] <alexpigment> JEEB: tell us how you *really* feel ;)
[17:21:30 CEST] <jkqxz> NVENC doesn't have any options for producing the intra profiles.
[17:21:47 CEST] <jkqxz> If you set it up right you can just edit the profile_idc byte after the fact, though.
[17:21:51 CEST] <JEEB> there are no intra profiles AFAIK, and thankfully this poor person doesn't need actual AVC-Intra
[17:21:57 CEST] <JEEB> or are there?
[17:22:03 CEST] <alexpigment> yeah, I guess I'm less concerned about that, and more concerned with turning off CABAC and forcing the refs to zero
[17:22:05 CEST] <JEEB> (AVC-Intra is the mangled piece of shit)
[17:22:27 CEST] <jkqxz> And constraint_setwhicheveroneitis_flag.
[17:22:56 CEST] <alexpigment> but that does kinda make me wonder: what does CABAC do, and what does a reference frame do, when all frames are IDR?
[17:23:00 CEST] <jkqxz> Yes, there are a load of standard intra profiles in H.264.
[17:23:28 CEST] <jkqxz> To turn off CABAC in NVENC, you can probably just set -profile baseline.
[17:23:41 CEST] <jkqxz> There aren't really any ways to set each feature individually.
[17:24:02 CEST] <alexpigment> I suppose I could try that
[17:24:41 CEST] <alexpigment> but if CABAC = CALVC when GOP is 1, then maybe it's not even worth messing with it
[17:24:52 CEST] <jkqxz> Looks like there is a config option for it if you want to hack the lavc wrapper.
[17:25:06 CEST] <alexpigment> link?
[17:25:09 CEST] <jkqxz> Er, what?  No, they're completely unrelated.
[17:26:00 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/nvenc/nvEncodeAPI.h#l1228>
[17:26:06 CEST] <alexpigment> i thought cabac did some sort of multi-frame referencing, but maybe i'm just mixing things up
[17:26:50 CEST] <JEEB> no
[17:26:56 CEST] <JEEB> CABAC you could think of is at the end of the process
[17:26:58 CEST] <JEEB> you have the data
[17:27:03 CEST] <JEEB> then you compress it
[17:27:09 CEST] <alexpigment> well it's good to know that the API supports turning CABAC off at least
[17:27:10 CEST] <JEEB> CAVLC and CABAC are just two ways of compressing it
[17:27:13 CEST] <alexpigment> ahh
[17:27:25 CEST] <JEEB> then during decode you decompress it and handle it
[17:27:43 CEST] <JEEB> that's also why the more bit rate you use the more CPU you use because CABAC and CAVLC start eating more and more of the cycles
[17:27:52 CEST] <alexpigment> right, and CAVLC is easier to decode presumably
[17:28:15 CEST] <JEEB> yes, but at high bit rates I'd be surprised if it had significant effect on anything
[17:28:28 CEST] <alexpigment> gotcha
[17:28:29 CEST] <JEEB> I remember someone doing some tests like seven (?) or so years ago
[17:28:43 CEST] <JEEB> and for editing even a two-three frame GOP was fast enough with lossless AVC
[17:28:54 CEST] <JEEB> of course intra-only enables other things
[17:32:38 CEST] <alexpigment> JEEB: I guess if you're using Intra-only, file size isn't a huge concern, so you might as well set the GOP 1 rather than worry about the sweet spot
[17:33:29 CEST] <alexpigment> but yeah, I'm sure it's a diminishing returns situation
[18:12:52 CEST] <billyshambrook> Hey, I am using the command at the bottom in this guide - (https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg), but with the w and h set to 640 and 360 (ffmpeg -i in.mp4 -vf scale=w=640:h=360:force_original_aspect_ratio=decrease out.mp4) but am getting the error "width not divisible by 2 (203x360)"
[18:13:22 CEST] <billyshambrook> Is there anyway of forcing it to round up to the closest divisible by 2 number?
[18:30:50 CEST] <alexpigment> billyshambrok: yeah scale=-2,360 I believe
[18:31:36 CEST] <alexpigment> assuming you want to enforce the 360 height
[18:31:56 CEST] <alexpigment> oops
[18:32:01 CEST] <alexpigment> scale=-2:360
[18:32:03 CEST] <alexpigment> sorry about that
[18:32:32 CEST] <alexpigment> if you want to enforce the 640 instead, you can do scale=640:-2
[18:40:15 CEST] <alexpigment> man, this nvenc has so many strict rules that just result in unexplained failure
[18:40:54 CEST] <alexpigment> for example, I just found out that 1080i will fail if you try and use a bitrate over 37.5mbps with strict bitrate constraints
[18:41:09 CEST] <JEEB> not surprising
[18:41:30 CEST] <alexpigment> it will also fail if you use a profile level of 5.0 with that same bitrate (granted, I know this doesn't make sense, but I was getting failures with 5.0 and 100mbps and I had to figure out what was breaking)
[18:42:33 CEST] <alexpigment> well, that pretty much rules out doing a high bitrate intra-only 1080i...
[18:46:07 CEST] <JEEB> I do know the nvidia encoder at least in gtx 1080 supports uhd at 60hz with 4:4:4, lossless
[18:46:19 CEST] <JEEB> that made my ssd sweat
[18:46:21 CEST] <JEEB> :)
[18:46:36 CEST] <alexpigment> yeah, i assume the 1060 I have does as well
[18:46:55 CEST] <alexpigment> but yeah, that's wayyyyy overkill for my needs
[18:47:17 CEST] <alexpigment> i'm just looking for common formats to use in NLEs
[18:47:18 CEST] <JEEB> it does also do 4:2:0 and 4:2:2 I guess
[18:47:34 CEST] <alexpigment> actually, i don't know how to specify 4:2:2 on this 1060
[18:48:29 CEST] <alexpigment> it allows you to specify 4:4:4 as the pix_fmt
[18:48:34 CEST] <alexpigment> 4:2:2 isn't there though
[18:57:58 CEST] <jasom> If I have a large number of files to transcode to x265, what's the tradeoff between several parallel single-threaded encodes and a single multi-threaded encode?  It looks like unlike x264 there's not a significant bitrate difference between single and multithreaded encodes, but I would expect to get a nearly linear speedup of parallel single-threaded encodes, but a sublinear speedup of a single multi-threaded
[18:58:00 CEST] <jasom> encode.
[18:58:20 CEST] <furq> "unlike x264"?
[18:58:38 CEST] <furq> i wasn't aware that was a thing
[18:59:13 CEST] <furq> unless you're using slice threading
[19:09:17 CEST] <DHE> frame threading in x264 does increase the file size, but it's quite minor. less than 1% typically
[19:11:05 CEST] <furq> yeah that's not significant
[19:33:30 CEST] Action: jasom reads up on x265 and discovers his my x264 info is out of date; slice threading was the only thing last time I looked at it
[19:36:35 CEST] <furq> that's a pretty long way out of date
[19:36:55 CEST] <jasom> 2009 maybe?
[19:38:21 CEST] <jasom> sadly I lack the free-time for reading nitty-gritty details of video encoders these days
[19:39:07 CEST] <JEEB> frame threading was added quite a bit earlier than 2009
[19:39:56 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=7b4f6a1fd95c7e0ab479e116fe59e66e5d1fd107
[19:39:59 CEST] <JEEB> 2006 :)
[19:40:06 CEST] <kepstin> if you really want to encode stuff fast, the trick is of course to get multiple computers, then do parallel multi-threaded encodes.
[19:41:53 CEST] <jasom> kepstin: or one multi-threaded encode per NUMA zone
[19:42:51 CEST] <jasom> JEEB: I'd believe 2006; I just know it was post-college and pre-kids which is 2004-2009
[19:43:29 CEST] <JEEB> I linked the commit that added frame threads :)
[19:48:37 CEST] <jasom> JEEB: but someone could have faked the timestamp, just to confuse me ;)
[19:50:32 CEST] Action: kepstin wonders where the best video encoder efficiency on EPYC is gonna be - per CCX? per die? per socket?
[19:53:48 CEST] <jasom> kepstin: well I hear Zen has significantly slower per-core AVX, so x265 could be CPU bound at low thread-counts.
[19:57:44 CEST] <kepstin> yeah, i heard it was 2-clock avx2 instructions instead of the 1-clock that intel has (although recent intel also reduces frequency on heavy avx2?, but not nearly enough to make up the difference)
[19:58:23 CEST] <furq> yeah zen doesn't have any 256-bit registers
[19:58:50 CEST] <furq> it has avx2 instructions but they don't really do anything
[20:27:36 CEST] <DHE> yes, e6-2600v4 series CPUs will throttle down cores executing avx2 instructions. older cpus would throttle down the whole package
[20:28:16 CEST] <DHE> kepstin: I have a ryzen 7.. know of a test/benchmark app?
[20:28:47 CEST] <BtbN> Prime95
[20:29:10 CEST] <kepstin> well, a test/benchmark for what, video encoding?
[20:29:28 CEST] <kepstin> just get yourself a sample video file and do a few runs in ffmpeg :/
[20:30:30 CEST] <kepstin> on the ryzen out now you can only really do per-ccx and per-die tests, it won't be until threadripper/epyc that there are multiple dies per socket or multiple sockets.
[20:30:33 CEST] <DHE> I meant in terms of AVX specifically
[20:31:10 CEST] <DHE> and epyc is supposed to be released. motherboard manufacturers (I've seen supermicro) are touting their products now
[20:34:54 CEST] <ChocolateArmpits> So I'm trying to get near real time streaming with video only. Currently latency including encoding, transmission and playback is around 250-300ms. I'm using x264 to encode for lowlatency intra refresh, transmitting mpegts over udp and mplayer for playback using benchmark and a few other corner cutting parameters.
[20:35:11 CEST] <ChocolateArmpits> Is there some special sauce to push the latency even further down?
[20:37:03 CEST] <kerio> DHE: the names are so dumb tho
[20:37:56 CEST] <DHE> ChocolateArmpits: zerolatency is about the best x264 can offer. do note that the player will buffer at least a little bit. 300 ms is actually pretty reasonable
[20:40:19 CEST] <ChocolateArmpits> DHE, well as per the archived shikari blog post it's not just zerolatency but also using buffer the size of a single frame and using intra refresh that minimize encoder latency too
[20:41:09 CEST] <ChocolateArmpits> so the frames would get sent to the output as fast as possible keeping same size to get over the network faster
[20:41:39 CEST] <kepstin> intra-refresh iirc doesn't really reduce total encoder latency, but it does make the latency more consistent frame-to-frame (otherwise e.g. keyframes would take longer to cabac because they're bigger, for example)
[20:42:02 CEST] <ChocolateArmpits> yeah I probably should've written it like that
[20:44:39 CEST] <DHE> intra refresh is more for the bitrate and size of each frame. since zerolatency means no forward prediction decisions can be made, having a ~80 kilobyte keyframe is a huge kick in the nuts when you're under a birate constraint and have no way to predict how far off course you'll go
[20:46:05 CEST] <furq> what are you actually encoding
[20:46:15 CEST] <furq> if it's from a v4l source or something then that'll probably add some latency
[20:47:03 CEST] <ChocolateArmpits> source is camera output that's captured via decklink
[20:48:54 CEST] <ChocolateArmpits> 300ms delay is sort of acceptable for slower speech but when spoken faster the delay is more apparent
[20:56:33 CEST] <BtbN> kepstin, my Ryzen can do 1080p60 with x265 at decent settings
[20:57:14 CEST] <kepstin> BtbN: not bad. I only have an R7 1700, but I haven't done any x265 on it yet.
[20:57:25 CEST] <BtbN> I got the 1800X
[20:57:31 CEST] <hpp> try vp9
[20:57:38 CEST] <BtbN> you can just overclock a 1700 to 1800X levels though, very easily
[20:57:59 CEST] <kepstin> hmm, I'm using a ... novelty case design, so I'm a bit cooling limited ;)
[20:58:26 CEST] <kepstin> if you do try vp9, make sure you have a recent git build so you have the new row threading stuff
[20:58:44 CEST] <BtbN> I put a NH-D15 on mine
[20:58:50 CEST] <BtbN> it's basically at room teperature at all times
[20:58:51 CEST] <alexpigment> noctua is a nice choice
[20:58:58 CEST] <BtbN> The D15 is _huge_
[20:59:03 CEST] <BtbN> It's almost 2kg of metal
[20:59:07 CEST] <alexpigment> is it a 2-fan design?
[20:59:10 CEST] <BtbN> yes
[20:59:21 CEST] <alexpigment> wow
[20:59:31 CEST] <alexpigment> the pictures on that are ridiculous
[20:59:37 CEST] <alexpigment> it takes up the whole width of the boar
[20:59:39 CEST] <alexpigment> *board
[20:59:40 CEST] <kepstin> yeah, I'm running the stock wraith spire with the 1700, and I actually had some issues because one of the edges on the fan rim was ~1mm too tall
[21:00:07 CEST] <furq> lol that's insane
[21:00:19 CEST] <furq> http://abload.de/img/82q8sba.jpg
[21:00:26 CEST] <kepstin> and the only reason it was too tall was the silly rgb leds they stuck in the top edge :(
[21:00:42 CEST] <furq> i bet a lot of people with fancy ram heatsinks have had to return those
[21:01:06 CEST] <alexpigment> furq: almost all of those horizontal coolers get in the way of RAM tbh
[21:01:25 CEST] <kepstin> the fan mounting height on the D15 is adjustable, it can be moved up to clear ram if you have enough height in the case
[21:01:35 CEST] <kepstin> but yeah, it is an issue :)
[21:01:47 CEST] <BtbN> furq, you can just mount the fan higher
[21:01:48 CEST] <furq> that's probably a big if
[21:02:13 CEST] <BtbN> I had to move it up on mine a bit
[21:02:15 CEST] <alexpigment> yeah, I just have a coolermaster hyper evo or whatever it is. it keeps my i7-5930k at 30 idle and 50 max. i can't complain
[21:02:19 CEST] <BtbN> even without big heat sinks on the RAM
[21:04:35 CEST] <alexpigment> kepstin: still you've got a 65 watt chip with the 1700. i would think your cooler could handle a decent bump in speed
[21:04:43 CEST] <BtbN> I could probably just remove the fans, and it'd still not overheat
[21:04:47 CEST] <alexpigment> (unless it runs hotter than other 65w chips)
[21:05:01 CEST] <BtbN> pretty much all R7 can hit 3.8GHz
[21:05:07 CEST] <kepstin> alexpigment: the actual restriction is the lack of case airflow / limited ventiliation
[21:05:13 CEST] <alexpigment> ah
[21:05:16 CEST] <BtbN> And they all cap out at 3-9-4.0GHz, so a 1800X is mostly pointless
[21:05:22 CEST] <alexpigment> how "novelty" is your case? ;)
[21:05:50 CEST] <kepstin> alexpigment: hmm, I think i've shared this image before: https://www.kepstin.ca/dump/DSC_4562.JPG
[21:06:00 CEST] <alexpigment> haha
[21:06:06 CEST] <alexpigment> lol
[21:06:46 CEST] <BtbN> https://btbn.de/public/pc.jpg that's my current build
[21:06:59 CEST] <BtbN> I'd say the airflow is decent
[21:07:23 CEST] <alexpigment> BtnB: is that an antec?
[21:07:28 CEST] <BtbN> no
[21:07:35 CEST] <BtbN> Fractal Design
[21:07:38 CEST] <kepstin> the problem with this case is that it doesn't have space for a proper exhaust fan, it had the psu mounted over the cpu socket on the board and relied on psu exhaust
[21:07:56 CEST] <alexpigment> ah
[21:08:26 CEST] Last message repeated 1 time(s).
[21:08:26 CEST] <alexpigment> i haven't used a fractal before
[21:08:31 CEST] <kepstin> I switched the psu for a sfx in an adapter bracket to gain z-space, and the board I'm using puts the main 16x pcie one slot down, so I have an old-fashioned "pci slot cooler" in slot 1
[21:08:31 CEST] <alexpigment> i've been an antec guy for so long
[21:09:11 CEST] <kepstin> that gets me enough airflow, combined with an 80mm fan in the front, to keep it stable around 70-75C at stock clocks, which is... ok.
[21:09:22 CEST] <furq> that's not really that ok
[21:09:31 CEST] <alexpigment> kepstin: this is dedication to a flawed design :)
[21:09:47 CEST] <hpp> why power supply goes bottom these days when heat goes up?
[21:09:55 CEST] <furq> i take it you're not running any spinning disks in there
[21:10:09 CEST] <alexpigment> hpp: i think it's because the intake is from the bottom of the case where the air isn't hot from components below it
[21:10:19 CEST] <alexpigment> the PSU intake, i mean
[21:10:51 CEST] <hpp> hmm, makes sense i guess
[21:11:17 CEST] <alexpigment> but it also allows you to have a chambered airflow at the bottom, which my old antec has. the bottom part is basically just fan, HDD, HDD, fan, PSU. and the airflow is completely separated from the top part of the case
[21:11:34 CEST] <furq> living the P180 lifestyle
[21:11:41 CEST] <alexpigment> furq: that's the one
[21:11:51 CEST] <furq> lol do you actually have a P180
[21:11:54 CEST] <alexpigment> yeah
[21:11:54 CEST] <furq> did they make a new version or something
[21:12:03 CEST] <kepstin> heh, at some point I might give up on this case and move it into my old P180 ;)
[21:12:05 CEST] <alexpigment> they have a p280 that's wider - i have that at work
[21:12:10 CEST] <furq> lol
[21:12:21 CEST] <furq> my friend had a P180 in like 2005
[21:12:25 CEST] <alexpigment> but the p180 is fine for my main machine at home. the only thing that sucks is the front USB 2.0 ports
[21:12:26 CEST] <furq> iirc he hated it
[21:12:42 CEST] <kepstin> oh, its an awful case. huge and annoying to work in
[21:12:49 CEST] <furq> yeah apparently it was a pig to work on
[21:12:52 CEST] <furq> looked nice though
[21:12:54 CEST] <alexpigment> if you have a lot of drives, the P180 is great
[21:12:59 CEST] <furq> and i imagine it does have very good airflow
[21:13:03 CEST] <alexpigment> i have 6 HDDs in mine and they all have spaces in between them
[21:13:09 CEST] <kepstin> yeah, I did have 6 spinning disks in mine at one point
[21:13:19 CEST] <kepstin> now I moved all the disks to a dedicated nas, so...
[21:13:44 CEST] <kepstin> I think I have my old athlon 64 x2 in there, I wonder if it still works
[21:13:56 CEST] <alexpigment> I would do nas if I had gigabit ethernet to my main system. unfortunately, i have to settle for 801.11AC 3x3
[21:14:02 CEST] <furq> i still have an antec sonata 2 somewhere with an a64 3000+ in it
[21:14:07 CEST] <furq> and no door
[21:14:21 CEST] <alexpigment> my wife has the antec sonata 2 still
[21:14:25 CEST] <kepstin> alexpigment: if you read the marketing, 802.11ac is faster than gigabit ;)
[21:14:32 CEST] <furq> covered in fingerprints no doubt
[21:14:44 CEST] <alexpigment> kepstin: well it's not duplex, so you're not going to get gigabit speeds
[21:15:01 CEST] <kepstin> (in actual use, I've seen 500-600mbit real throughput on my laptop, which isn't that bad.)
[21:15:05 CEST] <alexpigment> but my connection reads a steady 1.3gbps in windows, for what it's worth
[21:15:14 CEST] <alexpigment> and that's pretty fast
[21:16:00 CEST] <furq> the main reason to have a nas is because nobody wants freebsd on their desktop system
[21:16:01 CEST] <alexpigment> kepstin: yeah i get the same on my laptop. my desktop is a bit faster I believe because of the 3x3 card. honestly, it's fast enough that I haven't paid someone to drop ethernet in our place
[21:16:10 CEST] <furq> and that's the most usable thing that has worthwhile zfs support
[21:18:41 CEST] <alexpigment> do you guys actually do high bitrate encoding straight to the NAS?
[21:18:58 CEST] <alexpigment> i'd be worried about bottlenecking the speed
[21:19:15 CEST] <alexpigment> rather, waiting for a 20GB file to write over the network
[21:20:13 CEST] <kepstin> I generally don't do extremely high bitrate stuff, biggest I deal with is BD sizes. I have local SSDs and some local spinning rust on all of my boxes that I sometimes use for temp work tho.
[21:21:13 CEST] <alexpigment> yeah, I deal with mostly broadcast or Blu-ray bitrates daily. nothing below ~12mbps really
[21:21:24 CEST] <kepstin> only a single local hdd tho, so it's only a little faster than the gigabit network.
[21:21:40 CEST] <alexpigment> fair enough
[21:22:53 CEST] <furq> i encode to local disk and then move it across
[21:23:01 CEST] <furq> regardless of the bitrate
[21:23:08 CEST] <furq> i do that with dvdrips and flac as well
[21:23:47 CEST] <alexpigment> i guess i just do all my encoding on my system that serves as a network server for my HTPCs, so a NAS feels kinda like extra work for me
[21:24:04 CEST] <furq> like i said, i only have a nas for zfs
[21:24:13 CEST] <alexpigment> oh right
[21:24:31 CEST] <furq> i wouldn't bother if i was just running a jbod
[21:27:52 CEST] <kepstin> I have the nas nfs mounted and honestly a lot of the time I just do stuff over the network directly, particularly if I expect it would be cpu limited anyways.
[21:28:26 CEST] <furq> you can't defrag zfs so i prefer not to move stuff onto the nas until it's done
[21:28:43 CEST] <furq> it also has a tendency to allocate blocks wherever the fuck it feels like
[21:29:37 CEST] <alexpigment> sounds like a ringing endorsement ;)
[21:48:23 CEST] <alexpigment> does anyone know why transcoding from 1080i60 (i.e. 29.97fps) to 1080i60 with NVENC would cause "Original Frame Rate" to show up as 59.94fps in MediaInfo?
[21:48:54 CEST] <alexpigment> If I do the same encode with libx264 and QSV, that field doesn't show up in MediaInfo
[21:54:22 CEST] <ChocolateArmpits> alexpigment, nvenc might insert some information in the encoded stream
[21:55:04 CEST] <alexpigment> possibly
[21:55:28 CEST] <alexpigment> it just seems weird that the original frame rate is 29.97. perhaps they're meaning the original *field* rate?
[21:58:46 CEST] <BtbN> nvenc interlaced encoding is horribly broken on the driver side
[21:59:00 CEST] <alexpigment> well, from what I've read, they fixed it
[21:59:17 CEST] <alexpigment> https://devtalk.nvidia.com/default/topic/976088/ffmpeg-h264_nvenc-interlaced-encode/
[22:06:22 CEST] <alexpigment> and it works in Staxrip for what it's worth
[22:07:06 CEST] <alexpigment> the working copy from Staxrip doesn't have the "Original Frame Rate: 59.94fps" field at all
[22:36:51 CEST] <dystopia_> hey all
[22:36:54 CEST] <dystopia_> https://pastebin.com/USh7pEEr
[22:37:17 CEST] <dystopia_> im setting -x264opts force-cfr=1
[22:37:28 CEST] <dystopia_> but getting a variable framerate output
[22:37:56 CEST] <dystopia_> going from a 23.976fps source back to 23.976
[22:38:02 CEST] <dystopia_> anyone know whats up?
[22:38:18 CEST] <furq> i'm pretty sure mediainfo always reports 24000/1001fps in mkv as vfr
[22:38:40 CEST] <furq> mkv has a fixed timebase of 1/10000 which can't accurately represent 24000/1001
[22:38:51 CEST] <furq> so the PTS values aren't evenly spaced
[22:38:59 CEST] <RandomCouch> I apologize for cutting in, but I am trying to copy one video's metadata into another video but something isn't working right
[22:39:03 CEST] <RandomCouch> I'm using this command .\ffmpeg.exe -i .\sourceVideo.mp4 -map 1 -c copy -map_metadata 0 -map_metadata:s:v 0:s:v -map_metadata:s:a 0 :s:a .\Out.mp4
[22:39:13 CEST] <RandomCouch> And I'm getting this error :Invalid input file index: 1.
[22:39:24 CEST] <RandomCouch> my Out.mp4 file exists in the folder
[22:39:24 CEST] <furq> -map 1 refers to the second input file
[22:39:26 CEST] <furq> you only have one
[22:39:27 CEST] <dystopia_> hmm ok furq
[22:39:51 CEST] <furq> also you shouldn't need the other -map_metadata calls
[22:39:59 CEST] <furq> -map_metadata 0 will map all metadata from input file 0
[22:40:52 CEST] <furq> dystopia_: maybe consider using mp4 for 24000/1001
[22:41:40 CEST] <dystopia_> ok :) will give it a shot
[22:42:36 CEST] <RandomCouch> Awesome thanks furq  that worked!
[22:43:11 CEST] <RandomCouch> Wait actually... it just copied the whole file
[22:43:22 CEST] <RandomCouch> now my out.mp4 is exactly the same video as my sourcevideo
[22:44:37 CEST] <kepstin> RandomCouch: that's what you told it to do, yes?
[22:44:58 CEST] <RandomCouch> I only want to copy the metadata
[22:45:03 CEST] <RandomCouch> mainly the resolution and the framerate
[22:45:20 CEST] <kepstin> that... doesn't make sense
[22:45:32 CEST] <furq> lol what
[22:45:38 CEST] <RandomCouch> hmm, I have 2 mp4 videos, I need the second one to have the same resolution and framerate as the first oen
[22:45:48 CEST] <RandomCouch> I'm not sure if I'm asking for the right thing now
[22:46:11 CEST] <furq> that is technically what you've got
[22:46:15 CEST] <furq> is that not good enough
[22:46:37 CEST] <RandomCouch> well the two videos are not the same, like one is a video of a gameplay for a game, the other is a video of a generic Game Over screen
[22:46:41 CEST] <kepstin> RandomCouch: ok, then you have to re-encode the second video, and use the -s and -r options (or scale and fps filters) to set the output size and framerate appropriately.
[22:46:53 CEST] <RandomCouch> when I tried that method you showed me, my second video became exactly the first video which was the gameplay
[22:46:55 CEST] <furq> you don't need to set -s and -r if you want them to be the same as the source video
[22:47:15 CEST] <furq> wait
[22:47:15 CEST] <kepstin> RandomCouch: I'm guessing what you actually want to concatenate these two videos, but can't because they're different sizes?
[22:47:19 CEST] <furq> ok go back to the start again
[22:47:23 CEST] <RandomCouch> kepstin: exactly
[22:47:30 CEST] <furq> ah
[22:47:32 CEST] <RandomCouch> but I'm not concatenating with ffmpeg, I'm using an external library for android
[22:47:40 CEST] <furq> sherlock kepstin over here
[22:47:51 CEST] <kepstin> I can apparently read minds over the internet!
[22:47:57 CEST] <kepstin> time to go off and get rich. somehow.
[22:48:01 CEST] <RandomCouch> I just need them to be the same resolution and framerate haha
[22:48:09 CEST] <RandomCouch> I believe in you kepstin
[22:50:50 CEST] <kepstin> RandomCouch: so yeah, something like "ffmpeg -i SecondVideo.mp4 -s 1280x720 -r 30 SecondVideoResized.mp4" - replace the size and framerate with the desired values - although you might also want to add other options to set the video encoder/quality. Do you also have audio?
[22:51:43 CEST] <kepstin> there's no way to have ffmpeg read the values from the first file and then apply them to the second, you'll have to do that manually.
[22:51:48 CEST] <RandomCouch> Yeah I have audio, both are already using the same audio codec
[22:51:51 CEST] <RandomCouch> although the bitrate is different
[22:52:03 CEST] <RandomCouch> gotcha, that shouldn't be an issue
[22:52:08 CEST] <RandomCouch> I'll give it a try, thanks kepstin and furq  !
[22:52:11 CEST] <kepstin> then you'll want to add "-c:a copy" to keep the audio without re-encoding
[22:52:18 CEST] <RandomCouch> gotcha
[22:52:27 CEST] <kepstin> the video has to be re-encoded to do the resize, of course.
[22:53:56 CEST] <kepstin> by default it will (probably) use the x264 video encoder with crf 23 when encoding to mp4. If it's too low quality add a "-crf" option with a lower number, e.g. around 18 should give very good quality.
[22:54:33 CEST] <hpp> 18 give also too large file
[22:54:41 CEST] <hpp> 23 it like optimal
[22:54:50 CEST] <hpp> is*
[22:55:39 CEST] <hpp> 20 will do
[23:19:53 CEST] <alexpigment> Is there no way to modify the body of a ticket I created on trac.ffmpeg.org?
[23:30:30 CEST] <furq> i don't think much of this bwdif
[23:30:41 CEST] <furq> granted i tried it with a 5-second sample but it's done a poor job
[23:31:15 CEST] <alexpigment> it's a deinterlacing filter?
[23:31:20 CEST] <furq> yeah
[23:31:32 CEST] <alexpigment> is there any supposed avantage over yadif?
[23:31:35 CEST] <furq> it's supposedly better than yadif, but squinting is better than yadif
[23:31:46 CEST] <alexpigment> haha
[23:31:56 CEST] <furq> better meaning slower but higher quality
[23:32:06 CEST] <furq> i normally use qtgmc for dvdrips so i'm totally fine with slow deinterlacing
[23:32:08 CEST] <alexpigment> is anything in ffmpeg better than yadif already?
[23:32:17 CEST] <furq> bwdif is in ffmpeg
[23:32:22 CEST] <furq> assuming it is actually better
[23:32:40 CEST] <alexpigment> oh gotcha. you're trying out bwdif to get something close to qtgmc
[23:33:13 CEST] <furq> nah i was just cutting out an interlaced clip and i;m not breaking out vapoursynth for that
[23:33:26 CEST] <furq> so i figured i'd try bwdif since i've seen people talking about it
[23:33:31 CEST] <alexpigment> gotcha
[23:33:35 CEST] <furq> https://0x0.st/l5e.mp4
[23:33:37 CEST] <furq> you be the judge
[23:34:46 CEST] <alexpigment> I mean I see the aliasing for sure, but I don't know how qtgmc would do on that same clip
[23:35:23 CEST] <furq> i'd have to double check but it generally does really well on that kind of edge aliasing
[23:35:35 CEST] <alexpigment> I've gotten to the point where I just leave everything interlaced. The DXVA2 deinterlacer seems to do a good job for me, and I maintain the ability to go back to a DVD or Blu-ray later
[23:35:37 CEST] <furq> that's always the thing i notice most when i use something else
[23:36:07 CEST] <furq> qtgmc is higher quality than anything i can use realtime
[23:36:28 CEST] <furq> although the best thing about qtgmc by far is the bad deinterlacing repair mode
[23:36:40 CEST] <furq> i have a ton of early-2000s bbc dvds that have been really badly deinterlaced
[23:36:44 CEST] <alexpigment> I'll take your word for it. I've still never gotten into avi/vapoursynth
[23:36:48 CEST] <furq> it does an amazing job of cleaning that shit up
[23:37:10 CEST] <furq> without destroying the quality as much as a full deinterlacer would
[23:37:15 CEST] <alexpigment> I'll have to force my old man brain to learn vapoursynth and try it out sometime
[23:37:25 CEST] <pa> hi
[23:37:26 CEST] <furq> it can be a bit annoying to set up
[23:37:26 CEST] <pa> question
[23:37:31 CEST] <furq> but once you've got it all installed it's pretty simple
[23:37:40 CEST] <furq> vs is definitely much less hassle than avisynth
[23:37:41 CEST] <pa> i try to grab the screen with ffmpeg and output to a pipe
[23:37:56 CEST] <furq> i literally only use it for deinterlacing though
[23:38:00 CEST] <pa> but if i do that, i get "unable to find a suitable output format for pipe:"
[23:38:03 CEST] <furq> so if you just encode interlaced then it might not be that useful to you
[23:38:06 CEST] <pa> i even specify -format matroska
[23:38:08 CEST] <pa> but nothing
[23:38:19 CEST] <pa> if i specify a file, say foo.mp4, things work
[23:38:29 CEST] <pa> how can i pipe the output of ffmpeg?
[23:38:42 CEST] <furq> -f, not -format
[23:38:48 CEST] <pa> ah
[23:38:51 CEST] <pa> -f matroska?
[23:38:52 CEST] <pa> i try
[23:38:54 CEST] <furq> yeah
[23:38:54 CEST] <pa> thanks
[23:39:24 CEST] <alexpigment> furq: well, I *do* deinterlace sometimes for some specific workflows, but it's not common. either way, it's a skill that I need under my belt at some point
[23:40:09 CEST] <furq> the main annoyance with vs is that a lot of the filters (particularly qtgmc) depend on a bunch of nonstandard c libraries
[23:40:27 CEST] <furq> if you're on windows you need to hunt all those down yourself
[23:40:53 CEST] <furq> and of course these libs are all using the avisynth documentation model, which is forum posts on doom9
[23:41:04 CEST] <furq> so it's not particularly easy to even know what libs you need
[23:41:17 CEST] <alexpigment> you've just described my exact situation
[23:41:29 CEST] <alexpigment> on windows, and I don't like hunting through forum posts
[23:41:39 CEST] <furq> yeah it can be a bit annoying
[23:41:58 CEST] <furq> i figured it all out but i could probably upgrade half the libs by now
[23:42:08 CEST] <furq> but there's not much chance of that
[23:42:16 CEST] <alexpigment> hence why i hang out here. there's enough collective knowledge here, that I save a lot of frustration with undocumented stuff
[23:42:28 CEST] <alexpigment> (and hopefully I don't ask dumb annoying questions too often)
[23:42:35 CEST] <pa> furq: works indeed!
[23:43:01 CEST] <pa> btw what's the fastest encoder i could use for grabbing screen?`space efficiency is not important at all, i'm piping it to a player
[23:43:06 CEST] <pa> only cpu usage is
[23:43:12 CEST] <furq> just use rawvideo then
[23:43:19 CEST] <pa> ah awesome
[23:43:20 CEST] <pa> i try
[23:43:24 CEST] <pa> thanks agian
[23:44:11 CEST] <durandal_170> utvideo
[23:45:31 CEST] <pa> rawvideo seemingly not supported in matroska, i can force it, but then it doesnt play bwell
[23:45:38 CEST] <furq> use -f nut
[23:46:10 CEST] <alexpigment> so right now, I'm logging up several NVENC issues in an effort to get FFMPEG's implementation whipped into shape. does it seem overboard to log up several enhancement requests for explicit error messages on things that fail and give generic errors?
[23:46:15 CEST] <durandal_170> .nut extension
[23:46:17 CEST] <pa> thanks i try that
[23:46:31 CEST] <furq> durandal_170: he's piping it to a player
[23:47:09 CEST] <durandal_170> alexpigment: ask nvidia devs
[23:47:35 CEST] <alexpigment> durandal_170: this request is specific to FFMPEG though, I would think
[23:48:18 CEST] <alexpigment> If FFMPEG sees a bitrate that it knows is out of range for NVENC, FFMPEG could give a specific error message
[23:49:02 CEST] <alexpigment> but maybe i'm thinking about this wrong, so feel free to state your case
[23:49:13 CEST] <durandal_170> if ffmpeg knows....
[23:49:39 CEST] <alexpigment> ffmpeg is sentient now, right? ;)
[23:50:20 CEST] <durandal_170> if nvenc exports that info
[23:50:57 CEST] <alexpigment> durandal: I mean I know what the limits are now. 144Mbps for progressive, 37.5Mbps for interlaced
[23:51:38 CEST] <alexpigment> I would think that information could be just parsed by ffmpeg and error out before it gives a generic NVENC error
[23:53:59 CEST] <alexpigment> again, I accept that I could be misunderstanding how FFMPEG works and this may indeed be something for the Nvidia developers, but I was hoping for a "you're wrong and this is why" sort of response
[00:00:00 CEST] --- Thu Jun 22 2017