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

[burek]

[03:02:49 CEST] <fling> How can I mux multiple live sources together properly?
[03:07:48 CEST] <fling> Can I mux two mono usb audio pulse inputs as stereo?
[03:07:54 CEST] <fling> Or should I join them in pulse first?
[04:21:13 CEST] <HickHoward> apparently some genius had the bright idea to post a link containing new "open content"
[04:21:16 CEST] <HickHoward> from netflix
[11:03:57 CEST] <emr> Hello i have corrupted video file (ext is mts), when i query with file 'd2818_11UY0011-3_300612_TCS-PB-0922.mts: ISO-8859 text, with very long lines, with no line terminators' and with ffmpeg `d2818_11UY0011-3_300612_TCS-PB-0922.mts: Invalid data found when processing input`  but its there, its 561 mb data,  is there any way to recover? thanks
[12:02:10 CEST] <tomboy64_> i've been scouring the man-pages, but so far without avail.
[12:02:30 CEST] <tomboy64_> i'm looking for a way to extract a single chapter from a dvd-filestructure
[12:02:37 CEST] <tomboy64_> without transcoding
[12:03:37 CEST] <JEEB> I think the chapters etc are separate from the VOBs etc themselves so you'd have to have something that reads the metadata files and applies those to the MPEG-PS VOB files)
[12:03:40 CEST] <tomboy64_> but possibly with preserving audio and subtitles as well
[12:03:46 CEST] <tomboy64_> oh
[12:03:48 CEST] <tomboy64_> hm
[12:04:24 CEST] <JEEB> oh, tools/dvd2concat
[12:04:28 CEST] <JEEB> I wonder if that does what you want
[12:04:42 CEST] <JEEB> check its sources
[12:04:57 CEST] <JEEB> oh, it uses lsdvd
[12:07:30 CEST] <tomboy64_> hmm i guess i could work with the timestamp, too
[12:07:34 CEST] <tomboy64_> that would be even better
[12:46:38 CEST] <lain98> where can i find demuxer imlpementations using libav. i'm having some trouble with my code and maybe looking at those might help me
[12:49:24 CEST] <JEEB> are you asking where within FFmpeg the demuxers live, or applications utilizing lavf's demuxing?
[12:49:33 CEST] <durandal_1707> you mean demuxers code?
[12:50:13 CEST] <lain98> yes
[12:50:20 CEST] <lain98> both JEEB
[12:50:59 CEST] <JEEB> for demuxers it's libavformat/ for example libavformat/yuv4mpegdec.c for a simple one
[12:51:30 CEST] <lain98> essentially my requirement is to decode n frames starting from frame number x. but i run into issues seeking in different formats
[12:51:35 CEST] <JEEB> yes
[12:51:38 CEST] <JEEB> use somethign that indexes
[12:51:41 CEST] <JEEB> like ffms2
[12:51:46 CEST] <JEEB> or your own index creation
[12:51:53 CEST] <JEEB> only that way you can be frame exact
[12:52:53 CEST] <lain98> that might work for playing a video. but i'm trying to decode hundres of videos and holding indices for all of them in memory, idk if that might work for me
[12:53:16 CEST] <lain98> also variable frame is a pain in the butt
[12:54:30 CEST] <pink_mist> why do you need to hold the indices in memory for all eternity? just hold them while you're processing that file
[12:54:31 CEST] <lain98> also i dont care about presentation and temporal info, so if i can find implementations like that it might help
[12:55:01 CEST] <lain98> pink_mist: because a file might reappear according to my usecase
[12:55:21 CEST] <JEEB> lain98: just check out what ffms2 does :P it's not indexing in memory
[12:55:31 CEST] <lain98> and i never decode a file in full from start to end
[12:55:46 CEST] <lain98> JEEB: ill check that out
[12:55:57 CEST] <JEEB> it writes an index based on the container level
[12:56:14 CEST] <JEEB> that way you have numeric frames available as well as in general frame exact seeking
[12:56:35 CEST] <JEEB> in other words, FFmpeg's APIs provide you the capability to do that yourself, but they are not made for this use case
[12:56:53 CEST] <JEEB> f.ex. with mp4 you could get pretty good results because there's an index and the demuxer can utilize that
[12:56:56 CEST] <JEEB> but then you have MPEG-TS etc
[12:57:03 CEST] <JEEB> thus -> indexing is the only salvation
[12:57:16 CEST] <JEEB> and you can either code that yourself, or utilize something like ffms2 that already exists
[12:57:50 CEST] <lain98> ill take code from ffms2, its mit licensed
[12:57:51 CEST] <lain98> thanks
[14:58:37 CEST] <Beam_Inn> hey is anyone here really good with ffmpeg?
[15:00:54 CEST] <another> just ask your question
[15:27:03 CEST] <Beam_Inn> I just want to chat about it.
[15:27:36 CEST] <Beam_Inn> I'm trying to learn about advanced effects.  I wonder if there are video filters that could do things like warp the video or re-colorize sections
[15:29:05 CEST] <Beam_Inn> and just curious about using ffmpeg to try to make lossless changes
[15:29:39 CEST] <durandal_1707> yes
[15:29:42 CEST] <Beam_Inn> i guess the big question in my mind right now is about quality settings.  Is it possible to accidentally increase a video's size by setting the quality too high?
[15:29:57 CEST] <durandal_1707> yes
[15:45:23 CEST] <Beam_Inn> is there some way to figure out the highest possible quality based on the input and not suprassing it?
[15:46:57 CEST] <JEEB> no
[15:47:06 CEST] <FooNess_> Visual inspection after encoding is the only way, I'd reckon.
[15:47:19 CEST] <FooNess_> You compare (preferable double-blind) the input and the output.
[15:47:30 CEST] <JEEB> highest possible quality is same as input, and lossy encoders can possibly never get there
[15:47:36 CEST] <JEEB> so you end up ballooning and ballooning
[15:47:47 CEST] <FooNess_> If both are indistinguishable, you have "the highest possible quality" from a perceptual point of view.
[15:48:05 CEST] <JEEB> if you want to automate something, you need to define your own limit of something in some metric that can be calculated
[15:48:07 CEST] <Beam_Inn> I mean, what I'd like to do, for example, is cut a part out of a video, losslessly
[15:48:31 CEST] <JEEB> you can generally do that GOP by GOP in sane video formats
[15:48:43 CEST] <JEEB> within a GOP you need to re-encode
[15:48:56 CEST] <JEEB> for example if the frame you want to start from is not a random access point
[15:49:33 CEST] <Beam_Inn> I dunno.  I mostly deal with downloaded videos from youtube and videos I made myself.
[15:50:06 CEST] <JEEB> that's irrelevant. just noting that you can in various cases just losslessly copy the video stream (and audio), cut it
[15:50:15 CEST] <JEEB> but only starting on a random access picture
[15:50:33 CEST] <JEEB> if your starting frame of a cut is not a rnadom access picture, then you will have to re-encode or cut from an earlier frame
[15:50:49 CEST] <Beam_Inn> I just thought that youtube videos followed some somewhat universal format
[15:51:48 CEST] <Beam_Inn> I have an upload limit of 20 mb on my clips where I submit clips, and I keep running into it.
[15:52:01 CEST] <Beam_Inn> usually the clips are only 3-5 minutes long.
[15:52:04 CEST] <JEEB> then you have a file size limit :P
[15:52:06 CEST] <Beam_Inn> never longer than 5 minutes
[15:52:27 CEST] <Beam_Inn> would that help in deciding the best way to select the output settings?
[15:52:51 CEST] <Beam_Inn> or maybe are there some videos I could watch or books I could read to learn about understanding output settings well?
[15:53:05 CEST] <JEEB> try cutting losslessly first, check output file size, if too big start re-encoding an average bit rate so you get that maximum allowed file size :P
[15:53:20 CEST] <JEEB> because if you have to hit a file size, then that is your maximum allowed size
[15:53:31 CEST] <Beam_Inn> I have this other question I want to ask while someone is around
[15:53:44 CEST] <Beam_Inn> Can I increase the speed of the default video/audio without screwing up the pitch?
[15:54:48 CEST] <Beam_Inn> JEEB can you give a sample of the commands you'd use for the two steps you mentioned at 06:53?
[15:56:02 CEST] <JEEB> 2pass encoding if available in the encoder you'd be using, maximum preset that is still fast enough for you(if such are available in the encoder you're using), and -b:v XXXXk (kilobits/second)
[15:56:31 CEST] <Beam_Inn> so the built-in encoder with ffmpeg isn't goign to work?
[15:56:58 CEST] <JEEB> where you can calculate the bit rate to hit 20MiB from the clip duration and the maximum file size (which is 20MiB)
[15:57:12 CEST] <JEEB> Beam_Inn: there is no single "built-in "encoder
[15:57:22 CEST] <JEEB> there so many encoders in libavcodec :P
[15:57:48 CEST] <JEEB> I'd probably be using libx264 for H.264, but the site you'd be uploading to might have its own requirements/limitations
[15:57:51 CEST] <JEEB> I cannot possibly know
[15:58:08 CEST] <Beam_Inn> yeah i think i'd like to use h.264 because I dunno libx264
[15:58:24 CEST] <Beam_Inn> unless one of the new-popular streaming formats ... I dunno
[15:58:29 CEST] <Beam_Inn> maybe I shouldn't get into that
[15:58:40 CEST] <Beam_Inn> I feel like there's a lot of stuff invovled here that I have no idea about and no idea hwo to learn about
[15:58:43 CEST] <JEEB> the site you are uploading to is your limiting factor :P
[15:58:45 CEST] <FooNess_> Something like VP9 may be more useful for more efficient (yet slower) encoding; it also depends on the website and what it supports.
[15:59:33 CEST] <Beam_Inn> any kind of website I'd post to would just be my own website
[15:59:40 CEST] <Beam_Inn> so it really is more like 'the player' than 'the website', imo.
[16:00:04 CEST] <JEEB> ok
[16:00:14 CEST] <Beam_Inn> I have this ongoing wish to find a way to make online streaming video that nobody can record/download
[16:00:16 CEST] <JEEB> then you can indeed make your own limitations based on the clients you're supporting
[16:00:21 CEST] <Beam_Inn> but imo that's not possible.
[16:00:22 CEST] <JEEB> good luck with that
[16:00:22 CEST] <FooNess_> If you know your target audience and what kind of compatibility their player and/or browser has, you can use a more efficient encoding scheme.
[16:01:28 CEST] <FooNess_> Beam_Inn, that's probably next to impossible -- anyone with a simple screen recorder could defeat any limitation you set.
[16:01:45 CEST] <FooNess_> Or a video capture card.
[16:02:14 CEST] <Beam_Inn> yeah, I mean... I saw some work-arounds to prevent screen cap software from working implemented well a few times in my life... not often at all.
[16:02:31 CEST] <Beam_Inn> but nothing can prevent someone from setting up a video camera. XD
[16:02:44 CEST] <JEEB> or just HDMI capture
[16:02:47 CEST] <FooNess_> ^
[16:02:48 CEST] <JEEB> fully digital RGB from your screen
[16:02:49 CEST] <Beam_Inn> yeah
[16:03:09 CEST] <Beam_Inn> I should do hdmi capture XD
[16:03:12 CEST] <Beam_Inn> I keep worrying about harddrive space.
[16:03:55 CEST] <JEEB> basically for normal businesses the main thing is to keep people from accessing content they don't have a license for: anything additional to that is just trying to get into laws that make breaking "protections" illegal
[16:04:09 CEST] <Beam_Inn> I have this pipe dream of writing down all the times of the day I want to capture my screen and then just doing it by CSV. lol
[16:04:33 CEST] <JEEB> which is why DRM exists, not to actually secure the content but to be a legally "strong enough" lock :P
[16:04:45 CEST] <JEEB> so that if someone breaks it at least theoretically someone could get litigated for it
[16:04:51 CEST] <Beam_Inn> I haven't been able to call the software police on my company.  I'm in China. :/
[16:04:55 CEST] <TheAMM> Same with most locks, too
[16:05:00 CEST] <Beam_Inn> I don't even think they'd answer the phone.
[16:05:11 CEST] <TheAMM> Even if you go Abloy there's likely something weaker in the chain
[16:05:15 CEST] <Beam_Inn> They do so many illegal things.  They're dbs.  I can't wait to cut and run.
[16:05:31 CEST] <JEEB> and that's then written into some content licensing agreement
[16:05:34 CEST] <JEEB> that you have to do X,Y,Z
[16:05:38 CEST] <JEEB> (´4@)
[16:05:43 CEST] <JEEB> business be business
[16:05:51 CEST] <JEEB> (and lawyers get the moneys)
[16:05:58 CEST] <JEEB> TheAMM: yea
[16:09:12 CEST] <Beam_Inn> this chat was badass.  I wish I could keep it giong.  Really just don't know what I'mtalkin about right now and need to read a lot more
[16:42:53 CEST] <another> for starters you could read about h.264 encoding https://trac.ffmpeg.org/wiki/Encode/H.264
[16:53:48 CEST] <pink_mist> he already left
[17:21:02 CEST] <Aerroon> can i set a lower bitrate for dnxhr?
[17:21:12 CEST] <Aerroon> i want something below lb
[18:03:57 CEST] <Diag> Yo, i seem to be having an issue encoding from a file stream or whatever on my computer. for whatever reason ffmpeg doesnt seem to want to use more than ~35-40% of the cpu, and whines that the buffer is full
[18:05:32 CEST] <BtbN> It's probably correct in that statement.
[18:06:00 CEST] <Diag> Its a 150 meg buffer and im trying to do x264 in 'slow'
[18:06:10 CEST] <Diag> should i make the buffer larger and see if it still whines?
[18:08:18 CEST] <Diag> 2048 meg buffer, ~35% cpu
[18:08:47 CEST] <Diag> its using about 70% of 20 threads or so
[18:13:58 CEST] <furq> what cpu is that
[18:14:13 CEST] <Diag> xeon e5 2696 v4
[18:14:33 CEST] <Diag> furq: http://valid.x86.fr/7x8893
[18:15:29 CEST] <Diag> aha
[18:16:41 CEST] <Diag> this was automatically tacking a "tune zerolatency" in there, which it does NOT like
[18:18:31 CEST] <furq> oh
[18:18:46 CEST] <furq> yeah pretty much never enable that
[18:18:49 CEST] <Diag> Eh
[18:18:53 CEST] <furq> that disables frame threading which would explain it
[18:18:54 CEST] <Diag> this is on sharex :X
[18:18:58 CEST] <furq> lol
[18:19:09 CEST] <Diag> I kinda figured it would be something along those lines, because the workload was very spikey
[18:19:18 CEST] <furq> the guy still refuses to turn that dumbass option off does he
[18:19:24 CEST] <Diag> yeah
[18:19:33 CEST] <Diag> Its like, why
[18:19:58 CEST] <Diag> frikken now i can realtime 4k yay
[18:39:58 CEST] <Diag> furq: is the hwaccel_device flag applicable to both decode AND encode?
[18:53:21 CEST] <Diag> fuark
[18:53:34 CEST] <Diag> I cant find bolagna on these amf settings
[18:58:07 CEST] <DHE>  weird, that screen shot says 2699 but the text says 2696. and for the core count, 2699 is correct
[18:58:36 CEST] <Diag> DHE: the cpu is a revision of the 2699
[18:58:47 CEST] <Diag> its multiplier is 37 instead of 36
[18:58:52 CEST] <Diag> :)
[18:59:02 CEST] <Diag> everything shows it wrong and intel doesnt even have a page for it
[18:59:23 CEST] <furq> https://en.wikichip.org/wiki/intel/xeon_e5/e5-2696_v4
[18:59:30 CEST] <Diag> valid
[19:00:21 CEST] <DHE> alrighty then..
[19:00:28 CEST] <Diag> yeah its an oddball lol
[19:00:29 CEST] <DHE> (I have some 2698 cpus)
[19:00:33 CEST] <Diag> oh really?
[19:00:39 CEST] <DHE> yeah
[19:00:52 CEST] <Diag> v3 or 4
[19:00:54 CEST] <DHE> v4
[19:01:08 CEST] <Diag> ah nice
[19:01:23 CEST] <Diag> its weird that its a lower number isnt it
[19:01:25 CEST] <aep> is AV_PIX_FMT_YUVJ422P  litteraly compressed jpeg? what does AVCodec even do in this case when "decoding" MJPEG?
[19:01:51 CEST] <furq> aep: it's full range yuv422p
[19:02:12 CEST] <furq> it has nothing to do with jpeg other than that full range is also called jpeg range
[19:02:16 CEST] <aep> ah!
[19:02:18 CEST] <aep> thanks
[19:03:11 CEST] <aep> not sure what i'm doing wrong then. the output of that looks like digital junk, not like a pixel format.
[19:18:52 CEST] <lain98> uhh i'm trying to use this bitstream filter mpeg4_unpack_bframe when demuxing divx videos and sending them to decode. i imagine there is something quirky about this filter and when i seek to point in between the stream and not from the beginning its not able to decode all frames.
[19:19:43 CEST] <lain98> when i preprocess my file using ffmpeg command line and the same filter, everything works fine.
[19:20:02 CEST] <lain98> where can i get help about this ?
[19:20:26 CEST] <kepstin> this would be the place. can you share some sample code?
[19:21:04 CEST] <kepstin> the main thing to check would be to make sure you're seeking to a keyframe, can't decode starting at arbitrary frames regardless of whether you're using a bsf.
[19:22:27 CEST] <aep> this might be the issue. i'm confused what AVFrame::linesize is. for a 848x480 image it is 896  which is not 2 times width (yuv should be 16 bytes wide, right?)
[19:24:46 CEST] <aep> if i use 896/2 as width, i get a correct image. but where is that number coming from?  AVFrame::width is set to 480 as expected by the input
[19:25:22 CEST] <kepstin> line size is the number of bytes you add to go from the same column in one line to the same column in the next
[19:25:45 CEST] <kepstin> it's not the same thing as width, because individual lines may be padded for alignment for simd instructions
[19:26:45 CEST] <aep> 896 seems excessive padding for a 480 byte wide image
[19:26:58 CEST] <aep> also..not alligned
[19:26:59 CEST] <kepstin> that's 848 pixels = 848 bytes wide on the Y plane
[19:27:16 CEST] <aep> err, of course
[19:27:39 CEST] <kepstin> note that linesize is separate per plane, you should have different value for the u/V planes
[19:28:07 CEST] <aep> oh wow thats confusing
[19:28:17 CEST] <aep> thanks tho. i think i get it
[19:29:17 CEST] <lain98> kepstin: i'm able to demux other containers properly
[19:29:20 CEST] <jimevans> g'day all. i'm having a devil of a time muxing a subtitle stream into an mp4 container.
[19:29:30 CEST] <lain98> just avi with divx
[19:29:56 CEST] <jimevans> here's my command line and output: https://pastebin.com/EVNi9ZGm
[19:31:20 CEST] <kepstin> jimevans: if i had to guess, the timestamps in your input srt file are messed up :/ (also, subtitles in mp4 are kinda weird and poorly supported by players in general)
[19:31:27 CEST] <lain98> kepstin: here's the code i'm using http://tiny.cc/r52mbz
[19:31:58 CEST] <jimevans> the forced.srt is a copy of part of the full.srt file. i've corrected the indexes in the forced file so they are sequential and starting at 1, but the copy is done to make sure that the timestamps are identical to the same subtitle entries in full.srt.
[19:32:21 CEST] <jimevans> the full srt file muxes properly, without error.\
[19:33:52 CEST] <jimevans> i'm not worried about player compatibility; i have that well in hand. i *do* need to use an mp4 container (as opposed to something more flexible like matroska), because reasons.
[19:33:59 CEST] <jimevans> kepstin: ^^
[19:34:21 CEST] <kepstin> jimevans: are any entries in the srt file out of order according to timestamps, maybe? those numbers look suspiciously like wrapping in a 32bit unsigned int :/
[19:34:45 CEST] <jimevans> nope, not in the slightest. again, using the full srt muxes just fine.
[19:35:11 CEST] <jimevans> and i agree, it looks suspiciously like a 32-bit wrapping issue
[19:35:23 CEST] <kepstin> if the full srt muxes fine and your edited one doesn't, then probably something's wrong in the edited one :/
[19:36:49 CEST] <jimevans> i can guarantee that's not the case; i've checked, rechecked, and rechecked multiple times. the problematic entries in the edited file, are *identical* to the same entries in the full file.
[19:37:14 CEST] <jimevans> happy to share the .srt files, if you'd like to verify that for yourself.
[19:37:17 CEST] <Diag> *still cant find anything about amf usage flag*
[19:37:36 CEST] <furq> Diag: -h encoder=h264_amf
[19:37:48 CEST] <furq> unless you want to know what those options actually do in which case who knows
[19:37:51 CEST] <furq> it's really badly documented
[19:37:52 CEST] <Diag> XD
[19:38:08 CEST] <Diag> Im just wondering whats the difference between transcoding, lowlatency and webcam is
[19:38:19 CEST] <Diag> I mean, i can assume lowlatency, but webcam and transcoding? XD
[19:38:21 CEST] <lain98> :D
[19:39:14 CEST] <furq> i assume transcoding is just "normal"
[19:39:31 CEST] <Diag> Thats what it looks like. its default
[19:39:34 CEST] <Diag> weird
[19:39:48 CEST] <furq> and i guess webcam is some kind of webrtc-friendly profile
[19:40:02 CEST] <Diag> Its weird for as hard as amd pushes this shit, they sure friggen do a bad job of documenting it
[19:40:08 CEST] <furq> the thing i got stuck on was the ratecontrol stuff
[19:40:11 CEST] <Diag> amf/vce/uvd are like mystery boxes
[19:40:35 CEST] <furq> i couldn't find any documentation on that that wasn't just doom9 posts that were contradicted by other doom9 posts
[19:40:51 CEST] <Diag> why does doom9 ring a bell
[19:41:09 CEST] <furq> doom9 is the premier forum for custom xvid quant matrices
[19:41:16 CEST] <Diag> oh
[19:41:21 CEST] <Diag> heh
[19:41:23 CEST] <furq> and people arguing about avisynth
[19:41:33 CEST] <Diag> oh god, im glad i didnt google it
[19:41:40 CEST] <Diag> i dont want my internet history tainted
[19:41:43 CEST] <furq> it does still have useful stuff on it but its day has pretty much passed
[19:41:52 CEST] <furq> mostly because video encoding became much less arcane
[19:41:54 CEST] <Diag> thats the internet in general :V
[19:42:19 CEST] <Diag> huh, preanalysis mode
[19:42:24 CEST] <Diag> that sounds like it could be useful
[19:42:57 CEST] <furq> i guess you'd never actually use amf outside of vbr_peak mode anyway since it's there for livestreaming your heated gaming moments
[19:43:06 CEST] <furq> but it'd be nice to actually know how to use cqp mode
[19:43:22 CEST] <Diag> Yeah, i forget why i was looking at it now
[19:43:34 CEST] <Diag> *scratches head*
[19:44:02 CEST] <Diag> I wish there was a way to say take your gaht dang time and encode a little better :l
[19:45:23 CEST] <furq> well there's -quality quality
[19:45:40 CEST] <furq> it doesn't seem to do much other than being fun to type
[19:46:28 CEST] <Diag> yeah i found that out years ago, ;(
[19:46:43 CEST] <Diag> the handbrake dudes do not like vce
[19:47:17 CEST] <Diag> although i will say, the one ess fiddy five dude did actually send me the friggen source to the vce build long before it became a thing, which was cool
[19:47:48 CEST] <furq> does ffmpeg's amf stuff work outside of windows yet
[19:47:55 CEST] <Diag> uhhhhh
[19:47:59 CEST] <Diag> I dont *think* so
[19:48:01 CEST] <Diag> only nvenc
[19:48:06 CEST] <furq> i think it's still through vaapi elsewhere
[19:48:12 CEST] <furq> that would explain why other tool devs aren't keen on it
[19:48:20 CEST] <Diag> I think it said mesa supports decode but not encode?
[19:48:33 CEST] <Diag> I can always reboot into linux and try it :shrug:
[19:50:28 CEST] <Diag> Too bad windows decided to disable my vt-x/d or id try it right now
[19:54:47 CEST] <kepstin> yeah, on linux most people use the vaapi interface for amd and intel hardware encoders, particularly if they have the open source drivers installed.
[19:55:34 CEST] <Diag> python quicksync emulator when
[19:57:13 CEST] <Diag> oh wow ffmpeg does aptx, nice
[20:00:04 CEST] <lain98> kodi is having the same issue as i have with divx/avi
[20:02:52 CEST] <jimevans> ah well, looks like subler will fix up the subtitles properly. i don't like that i can't command-line it like ffmpeg, but as long as it gets done, i suppose i'm good with that.
[20:03:01 CEST] <jimevans> thanks for the insight, y'all.\
[20:04:01 CEST] <Diag> >hardware accelerated mpeg2 decode
[20:04:04 CEST] <Diag> bruh
[20:06:21 CEST] <Diag> oh good gracious
[20:17:02 CEST] <Diag> vp9 two pass has to be run twice?
[20:18:08 CEST] <FooNess> ... yes, a two-pass encode has to do, well, two passes.
[20:18:12 CEST] <FooNess> If that's what you're asking.
[20:19:32 CEST] <Diag> Sure, but has two pass encoding always been running ffmpeg twice?
[20:19:37 CEST] <furq> yes except for nvenc
[20:19:38 CEST] <kepstin> yes
[20:19:47 CEST] <furq> nvenc's two-pass mode is...weird
[20:20:01 CEST] <kepstin> nvenc's "two pass mode" is what normal encoders call "looking at the entire frame to decide how to allocate bits", iirc
[20:20:04 CEST] <Diag> Huh wow, i guess the frontends for them really do make it retard proof
[20:20:10 CEST] <furq> yeah something like that
[20:20:23 CEST] <Diag> Isnt that what the vce preanalysis does
[20:20:40 CEST] <furq> probably
[20:20:45 CEST] <furq> i assume they're both just stupid names for lookahead
[20:21:03 CEST] <furq> but nvenc's is particularly stupid because it's repurposing existing terminology
[20:21:14 CEST] <Diag> right
[20:22:57 CEST] <Diag> huh, well weird
[20:30:09 CEST] <kepstin> and then there's the cases where you might want to run a two-pass filter (e.g. vidstab) and then do a two-pass encode, which means you need to do three separate executions of ffmpeg :)
[20:30:43 CEST] <Diag> kepstin: its time to stop
[20:41:04 CEST] <Diag> Is two pass worth it with vp9
[20:41:14 CEST] <Diag> if im coming from constant quality h264
[20:41:51 CEST] <kepstin> google says that libvpx vp9 has worse quality when using single-pass, even in cq mode.
[20:41:56 CEST] <furq> iirc two-pass makes a much bigger difference with vp9, even in crf mode, because their ratecontrol is awful
[20:42:05 CEST] <Diag> heh
[20:42:10 CEST] <furq> or whatever mode ffmpeg's crf switch actually activates in vpx
[20:42:36 CEST] <Diag> I guess ill fudge around with custom actions in sharex :(
[20:43:29 CEST] <kepstin> note that in x264, the '-crf' option basically works by running the second pass mode of the encoder with a preset value instead of a value calculated from the first pass.
[20:43:39 CEST] <furq> also vpx has terrible multithreading so this experiment probably won't last long on your 22-core xeon
[20:43:55 CEST] <furq> when you notice you can't get it to use more than 5% of it
[20:45:50 CEST] <Diag> ah
[20:46:01 CEST] <kepstin> splitting the video into segments and encoding them independently is the workaround, and it improves scalability of encoding even with x264
[20:46:07 CEST] <kepstin> for vod applications only, of course
[20:46:08 CEST] <Diag> furq: not the idea, the using the xeon was for realtime h264/5
[20:46:17 CEST] <Diag> this is for post encoding
[20:46:31 CEST] <Diag> Im hoping that the file size reduction will be worth it
[20:52:01 CEST] <lain98> aaa, why this filter doesnt work on this obscure dead format
[21:01:31 CEST] <Diag> wwwwwwwwwwwwwwew x265 takes some time
[21:02:44 CEST] <Diag> Is there a way to set the file buffer size
[21:03:06 CEST] <Diag> err, disregard, im retarded and spelled it wrong
[21:03:12 CEST] <lain98> Can someone attempt to explain what this error might mean "Missing one N-VOP packet, discarding one B-frame.". its in https://ffmpeg.org/doxygen/3.2/mpeg4__unpack__bframes__bsf_8c_source.html
[21:07:28 CEST] <lain98> i guess no :(
[22:21:55 CEST] <Diag> god what the hell even is vp9
[22:26:13 CEST] <kepstin> a temporary step on the way to av1, imo.
[22:31:02 CEST] <Diag>  I mean, i just made an h264, vp9, and h265 file of the same 250kbps shit on just the normal "medium" encoder preset
[22:31:29 CEST] <Diag> h264 blows vp9 and h265 out of the water
[22:31:31 CEST] <Diag> hardcore
[22:31:53 CEST] <Diag> vp9 and h265 have huge moving blocks around any motion
[22:31:55 CEST] <kepstin> which encoders? x264, libvpx, x265?
[22:31:57 CEST] <FooNess> ... in terms of what? File size? Or perceptual quality?
[22:32:00 CEST] <FooNess> Or what.
[22:32:23 CEST] <Diag> x264/5 and whatever vp9 encoder is with handbrake lol
[22:32:30 CEST] <kepstin> out of those encoders, x264 almost certainly has the best perceptual optimizations.
[22:32:45 CEST] <Diag> filesizes are 2.43 h264, 2.4 h265, 2.2 vp9
[22:33:03 CEST] <Diag> and oh my god, i thought vp9 was eh, but h265 looks like aaaays
[22:33:04 CEST] <kepstin> so, libvpx has terrible rate control, as you saw
[22:33:08 CEST] <Diag> Yeah
[22:33:11 CEST] <Diag> well
[22:33:13 CEST] <Diag> that was two pass
[22:33:15 CEST] <Diag> :shrug:
[22:33:26 CEST] <kepstin> with two pass it's merely terrible
[22:33:30 CEST] <kepstin> with one pass it's horrendous
[22:33:35 CEST] <Diag> lemme upload the files here
[22:33:41 CEST] <Diag> im like, shocked
[22:34:00 CEST] <kepstin> anyways, vp9/h265 were really designed for larger video sizes (4k video in particular) and have issues with lower res stuff, tbh.
[22:34:08 CEST] <Diag> oh yeah, id believe it
[22:34:14 CEST] <kepstin> the larger block size options probably hurt at lower res
[22:34:26 CEST] <Diag> I remember when h265 was first becoming a thing and there was that basketball shot
[22:34:43 CEST] <Diag> and like, overall the scenes had more detail, but h265 got blocky instead of blurry
[22:34:54 CEST] <kepstin> blocky instead of blurry is actually something x264 does intentionally.
[22:34:58 CEST] <Diag> uhhh
[22:35:03 CEST] <Diag> no, the other way around
[22:35:05 CEST] <Diag> h265 was blocky iirc
[22:35:29 CEST] <kepstin> blurry gives you better psnr, but x264 tends to leave some blockiness in to preserve high frequency energy
[22:35:36 CEST] <Diag> Im thankin *hnnnnnnnnnnnnnnnng*
[22:35:45 CEST] <kepstin> it's a tricky balance :)
[22:36:03 CEST] <Diag> :V
[22:36:09 CEST] <Diag> h264 just always seemed well rounded
[22:36:17 CEST] <Diag> and vp9 and h265 were special use cases
[22:36:42 CEST] <furq> x264 is just a really thoroughly developed encoder
[22:37:12 CEST] <FooNess> Speaking of; so there's videos on YouTube with an avc1 stream, and then a VP9 stream. Are there supposed to be any measurable perceptual differences between either of these?
[22:37:19 CEST] <furq> x265 is harder to contribute to afaik and also people are generally less keen on using it because of the stupid licensing
[22:37:29 CEST] <furq> and how slow it is if you want measurable gains for most content
[22:37:48 CEST] <furq> FooNess: the vp9 stuff on youtube is generally higher quality
[22:38:00 CEST] <kepstin> FooNess: google's intention (from the limited info they've revealed) is that they're using vp9 primarily for bandwidth saving
[22:38:04 CEST] <Diag> vp9 on  youtube pulls off some wizardry :thonk:
[22:38:14 CEST] <furq> you could be conspiratorial and say it's because they're trying to push vp9 over h264
[22:38:19 CEST] <FooNess> furq, I see. And I guess that's because they use a two-pass encode? And not a one-pass CRF encode which as discussed before, has bad efficiency?
[22:38:27 CEST] <furq> but i think they're just using quick h264 settings to get a video up as fast as possible
[22:38:38 CEST] <furq> and then the vp9 always comes a lot later after the video hits a certain view count
[22:38:48 CEST] <FooNess> Yeah, I have a feeling they just have some ffmpeg script set up somewhere and parse uploads through it.
[22:38:58 CEST] <furq> i'm pretty sure it was confirmed they use ffmpeg on the backend
[22:39:02 CEST] <FooNess> Right.
[22:39:04 CEST] <kepstin> FooNess: google almost certainly uses libvpx with 2-pass mode (because 1-pass mode sucks) with combined bitrate and quality limits, encoded in a segmented fashion
[22:39:06 CEST] <FooNess> I mean, it's what'd make sense.
[22:39:10 CEST] <FooNess> kepstin, I see.
[22:39:16 CEST] <furq> but yeah nobody outside google really knows what settings they're using
[22:39:25 CEST] <FooNess> Right.
[22:39:59 CEST] <kepstin> they give a hint, in their recommended encoder settings for other people doing vod: https://developers.google.com/media/vp9/settings/vod/
[22:40:06 CEST] <furq> they use vp9 for rate savings and it takes a long time for them to show up so it's a safe bet they're using high quality settings
[22:40:14 CEST] <furq> plus they did make it so presumably they know how to get everything out of it
[22:40:22 CEST] <FooNess> Excellent.
[22:40:32 CEST] <furq> and also i heard they have quite a few servers over there at google so they can distribute the encoding
[22:41:16 CEST] <FooNess> And in my experience, the VP9 only shows up after the video gains traction in terms of views or something, so it may be a kind of "reward" for the uploader for having uploaded something people want to see -- "here, have a higher quality version."
[22:41:22 CEST] <kepstin> i dunno about now, but a while ago they'd only bother encoding vp9 for videos that hit a certain popularity level. since they were balancing cost of video encoding vs. cost of bandwidth.
[22:41:29 CEST] <FooNess> Yes, exactly.
[22:41:33 CEST] <FooNess> That's what I also noticed.
[22:41:38 CEST] <furq> i used to upload a lot of music to youtube and everything with >150 views had vp9
[22:41:41 CEST] <furq> anything without didn't
[22:41:47 CEST] <furq> but that's probably changed 100 times since i last checked
[22:41:48 CEST] <FooNess> Oh, 150 is all that's needed?
[22:41:50 CEST] <FooNess> Yeah.
[22:41:55 CEST] <FooNess> Google change shit aaaaaaaaaall the time.
[22:41:56 CEST] <FooNess> lol
[22:42:01 CEST] <furq> it makes sense because probably 99% of videos on there never hit 100 views
[22:42:08 CEST] <FooNess> Yeah, heh.
[22:42:14 CEST] <Diag> oh hey i forgot
[22:42:52 CEST] <Diag> >mfw chrome wont play a vp9 mkv
[22:42:57 CEST] <Diag> what the FUARK
[22:42:58 CEST] <kepstin> (btw, if you read that google vp9 settings doc, note that they made a typo - you need to add a k after the minrate and maxrate values they provided)
[22:43:08 CEST] <kepstin> chrome won't play mkv at all, that's nothing special
[22:43:11 CEST] <kepstin> put it in webm
[22:43:19 CEST] <furq> ignore the fact that webm is mkv
[22:43:30 CEST] <furq> that would make too much sense
[22:43:35 CEST] <FooNess> lol
[22:43:45 CEST] <kepstin> hey, it has a different vendor id :)
[22:44:32 CEST] <Diag> I mean for forks sake
[22:44:34 CEST] <TheAMM> (technically chrome will play mkv in <video>, ala https://mygi.ga/iXk/aecmI.mkv/embed)
[22:44:51 CEST] <Diag> /embed?
[22:45:29 CEST] <TheAMM> An endpoint for serving html with relevant embed dom and metadata
[22:45:49 CEST] <Diag> ah
[22:47:00 CEST] <kepstin> huh. well, that certainly doesn't play in firefox.
[22:50:17 CEST] <kepstin> last time i checked, epiphany (gnome-web, based on webkit-gtk) would play anything you have gstreamer plugins installed for. i wonder if they've added a whitelist now
[22:50:28 CEST] <Diag> TheAMM: id say i need this, but i dont need this, vp9 is poo poo
[23:02:18 CEST] <Diag> wait
[23:02:33 CEST] Last message repeated 1 time(s).
[23:02:33 CEST] <Diag> I literally just had to rename it from mkv to webm and it fkin embeds??!
[23:02:42 CEST] <Diag> wheres my good rope
[23:02:58 CEST] <furq> hooray for browsers
[23:22:17 CEST] <Diag> does chrome not play h265 either?
[23:22:20 CEST] <Diag> what the balls is this crap
[23:31:06 CEST] <BtbN> No Browser does, the patent swamp surrounding hevc and intense hardware requirements makes it not worth the effort.
[23:31:38 CEST] <Diag> wow, double rope
[23:32:59 CEST] <BtbN> There really is hardly any point to using HEVC in general
[23:33:11 CEST] <Diag> yeah i was just testing some nonsense out
[23:33:16 CEST] <Diag> and its like :l
[23:33:26 CEST] <BtbN> h264 and vp9 are kinda the sweet spot of hardware demands and quality
[23:33:31 CEST] <Diag> pfft
[23:33:55 CEST] <Diag> vp9 does not fair well with desktop recording
[23:34:15 CEST] <BtbN> That's primarily because libvpx is a pile of garbage
[23:34:24 CEST] <Diag> whats better?
[23:34:28 CEST] <BtbN> x264
[23:34:35 CEST] <Diag> :facepalm:
[23:34:49 CEST] <BtbN> I'm not aware of any proper non-commercial vp9 encoders
[23:34:57 CEST] <Diag> oh
[23:35:12 CEST] <Diag> Google pulls off some serious shit with vp9 on youtube
[23:35:56 CEST] <BtbN> They use libvpx though
[23:36:06 CEST] <kepstin> i'm pretty sure most of it on youtube is careful choice of bitrates, combined with using 2 pass mode and throwing lots of computer hardware at it.
[23:36:12 CEST] <BtbN> It's fine for conversion of complete files
[23:36:20 CEST] <Diag> ?
[23:36:29 CEST] <BtbN> I doubt YouTube uses twopass mode. They are not usually aiming for an exact file size
[23:36:29 CEST] <Diag> I *am* doing complete files
[23:36:52 CEST] <BtbN> You just said you're doing desktop recording. That's very much not a complete and done for file.
[23:36:57 CEST] <kepstin> due to the issues with rate control, you want to use 2-pass mode even when not encoding to a target file size
[23:37:20 CEST] <BtbN> Does it not have an equivalent to crf?
[23:37:25 CEST] <kepstin> no, it doesn't
[23:37:43 CEST] <kepstin> there's an option called crf, in ffmpeg, but it's actually a quality-limit mode that works very differently
[23:37:43 CEST] <BtbN> So you just do two-pass encoding to a desired bitrate, and that's best you can get?
[23:37:47 CEST] <BtbN> That's even worse than I expected.
[23:38:58 CEST] <kepstin> the libvpx quality limit mode is basically an option to make it not use the full target bitrate if the quality would be above some set level (i'm not sure how they measure quality)
[23:39:15 CEST] <kepstin> google uses that in youtube as a way to save disk space for easy-to-encode files
[23:39:24 CEST] <Diag> BtbN: I have a raw file i recorded
[23:39:32 CEST] <Diag> and i was encoding it with different shit
[23:40:02 CEST] <BtbN> Yeah, so apparently you want to do a 2pass encoding with libvpx
[23:40:11 CEST] <Diag> thats schwat i did :D
[23:40:24 CEST] <chungy> Hello, is there a way to tell ffmpeg to not include an "encoder" metadata tag on output files?
[23:40:40 CEST] <BtbN> try the bitexact mode
[23:40:54 CEST] <Diag> erm, who
[23:41:09 CEST] <Diag> oh, him
[23:41:11 CEST] <kepstin> you can use libvpx-vp9 in a mode where you set only the quality limit and no target bitrate, and you get something sort of like x264's crf mode - but you still need to use 2-pass encoding for this to work properly because ?? :/
[23:41:24 CEST] <Diag> heh
[23:41:36 CEST] <Diag> I just said screw it and did avg bitrate 2 pass :shrug:
[23:41:55 CEST] <kepstin> vp8 requires a target bitrate set, you can set the target bitrate arbitrarily high and use the quality limit stuff.
[23:42:08 CEST] <BtbN> I'd kinda like to play with EVE-VP9, but it's not exactly accessible.
[23:42:25 CEST] <Diag> oh thats a good point
[23:42:32 CEST] <Diag> lemme try a vp8 of the same bologna
[23:42:48 CEST] <kepstin> vp8 will be worse than vp9, of course
[23:42:57 CEST] <Diag> will it really tho
[23:43:02 CEST] <Diag> this is lower resolution stuff
[23:43:08 CEST] <BtbN> of course it will
[23:43:11 CEST] <kepstin> yes? it's basically the same as vp9 but worse
[23:43:21 CEST] <chungy> thanks, -bitexact is what I want
[23:43:27 CEST] <kepstin> intel has their svt-vp9 encoder too, but iirc that's designed for realtime 1-pass stuff?
[23:43:43 CEST] <BtbN> Isn't that kinda a hwenc?
[23:43:54 CEST] <kepstin> no, the svt encoders are pure software
[23:44:14 CEST] <kepstin> https://github.com/OpenVisualCloud/SVT-VP9
[23:44:19 CEST] <Diag> huh
[23:44:25 CEST] <kepstin> they also have hevc and i think they might be working on av1?
[23:44:46 CEST] <kepstin> hmm, they are targetting vod applications too
[23:45:14 CEST] <Diag> testing vp8
[23:45:25 CEST] <Diag> because screw reality, this isnt a given
[23:45:45 CEST] <kepstin> vp8 also has worse multithreading support than vp9, which means that it's sometimes slower than vp9, too
[23:45:58 CEST] <Diag> you wanna stop making me wanna kms
[23:46:04 CEST] <Diag> im close enough already
[23:46:24 CEST] <Diag> I wanna find that sweet spot of like
[23:46:45 CEST] <Diag> h264 vs 65 where i can either have really slow 264 or somewhat slow 265
[23:47:06 CEST] <BtbN> last time I checked x265 was still way slower than x264
[23:47:12 CEST] <Diag> Sure
[23:47:23 CEST] <Diag> But theres diminishing returns, yaknow
[23:47:44 CEST] <kepstin> note that if you're doing screencapture of applications (e.g. lots of text, limited motion) libvpx-vp9 has a specific content tune for that which should help with quality.
[23:48:04 CEST] <Diag> tell me more
[23:48:20 CEST] <BtbN> I don't think there's more to that
[23:48:22 CEST] <kepstin> '-tune-content screen'
[23:48:25 CEST] <kepstin> that's it.
[23:48:31 CEST] <Diag> OH GOD MY EYES
[23:48:46 CEST] <Diag> what in the holy hell, the colors are going all whack
[23:50:04 CEST] <kepstin> my impression of the current state of h265 software encoders was that if you run them at about the same encoding speed as x264, they were pretty close to it in terms of encoding efficiency? (quality per bit)
[23:50:15 CEST] <kepstin> and they could be better if you ran them slower
[23:50:24 CEST] <Diag> :shrug: Id be willing to wait a little longer if i *could* get better
[23:50:36 CEST] <Diag> but like going between slower and placebo is like nothing
[23:50:47 CEST] <kepstin> although the benefits at lower resolutions would be minimal if any
[23:50:56 CEST] <BtbN> Get libaom out then, and set it's quality to 11
[23:51:04 CEST] <BtbN> Might take "a little" longer, but sure will look good
[23:51:06 CEST] <Diag> why you gotta get me all excited, and then shoot down my hopes and dreams like that
[23:55:07 CEST] <Diag> the tune helped a little bit
[23:55:11 CEST] <Diag> any movement goes to shit though
[23:55:18 CEST] <Diag> x264 it is
[23:58:57 CEST] <Diag> oh man, placebo 2 pass x264 is nutworthy
[23:59:15 CEST] <furq> just use veryslow
[23:59:18 CEST] <kepstin> no real benefit to placebo in x264
[23:59:26 CEST] <BtbN> placebo is pointless, as its name might suggest
[23:59:39 CEST] <BtbN> and 2pass is as well, if you're not aiming for a precise size
[00:00:00 CEST] --- Sat Aug 24 2019