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

[burek]

[05:22:26 CEST] <narinzea> I am using ffplay to play a video, but only the pause keys (p and space) is not working while other keys (esc, q, right, left, etc) seem to work fine. Any workarounds I could do?
[06:52:16 CEST] <Terlisimo> is there some switch that tells ffmpeg how much to search when looking for streams? Got an input stream with video, audio, subs, but when transcoding it does not detect the subs. The input stream is http://something if that means anything.
[06:52:32 CEST] <Terlisimo> I mean what percentage of file or how much time
[07:07:58 CEST] <furq> Terlisimo: -analyzeduration and/or -probesiz
[07:08:00 CEST] <furq> probesize
[07:11:02 CEST] <Terlisimo> that's it, thanks! I knew it existed but failed at googling it :)
[08:37:50 CEST] <LABcrab> Hi. I'm wondering where is the best place to talk about video cables.
[09:16:14 CEST] <Fyr> hey, guys. is FFMPEG AAC development frozen?
[09:16:41 CEST] <Fyr> the commits come once in a month without any significant change.
[10:59:08 CEST] <Mavrik> I guess the AAC support is now good enough? What's missing?
[11:00:04 CEST] <Fyr> the linear quality when using the variable bitrate option.
[11:00:45 CEST] <Mavrik> Ah
[11:00:50 CEST] <Fyr> has variable bitrate been implemented or it's sill experimental?
[11:01:12 CEST] <Mavrik> No idea, sorry :/
[11:01:20 CEST] <Mavrik> I usually use fdk-aac still
[11:02:00 CEST] <Fyr> cool, but John Van Sickle and Zeranoe do not add it to their builds.
[11:02:41 CEST] <Mavrik> Yeah, because it's not redistributable due to license.
[11:03:23 CEST] <Fyr> it's possible to distribute libfdcaac and a library.
[11:03:29 CEST] <Fyr> *as a library
[11:04:47 CEST] <c_14> but not as part of a (l)gpl'd ffmpeg
[11:08:13 CEST] <Fyr> can anybody forecast when h.265 replaces h.264?
[11:08:36 CEST] <Fyr> Blu-Rays still come with H.264.
[11:10:17 CEST] <Mavrik> It'll take awhile.
[11:10:24 CEST] <Fyr> ='(
[11:10:37 CEST] <Mavrik> Especially due to ridiculous patent costs of H.265 anything
[11:10:47 CEST] <Mavrik> There's not much effort put into libx265 due to that either
[11:11:15 CEST] <Mavrik> Google went VP9 / AV1 way as well so they're probably not going to invest into H.265 either
[11:11:38 CEST] <Fyr> Mavrik, the patents cover only the devices.
[11:12:04 CEST] <Fyr> if you produce devices, then you have to pay for each device.
[11:12:26 CEST] <Mavrik> Which patent pool? ;)
[11:12:41 CEST] <Fyr> well, it requires digging.
[11:13:44 CEST] <Mavrik> Anyway, at least HEVC Advance requires you to pay as the content distributor as well
[11:13:53 CEST] <Mavrik> Unless you give out the videos for free
[11:14:10 CEST] <Mavrik> Which makes it less attractive for content providers like Google as well, meaning less support
[11:14:52 CEST] <Fyr> then, we should press on Google to release VP10.
[11:15:07 CEST] <Mavrik> What's wrong with VP9? :)
[11:15:12 CEST] <c_14> the encoder
[11:15:12 CEST] <Mavrik> It's comparable to HEVC
[11:15:17 CEST] <Mavrik> And they're working on AV1
[11:15:17 CEST] <Fyr> lack of hardware acceleration.
[11:15:31 CEST] <Fyr> most of devices do not support it.
[11:15:33 CEST] <Mavrik> VP9 right now is hardware accelerated on more devices than HEVC probably
[11:15:43 CEST] <Mavrik> And yes, the encoder sucks ass
[11:15:47 CEST] <Fyr> not really
[11:15:50 CEST] <Mavrik> But then again, H.265 encoders suck ass as well
[11:17:03 CEST] <Fyr> the players use 10% of CPU on my computer when playing VP9, while H.264 and some others codecs use only 1-2%.
[11:18:00 CEST] <Mavrik> So what does you computer have to do with general state of HW acceleration?
[11:18:16 CEST] <Fyr> my phone and tablets support H.264, but HEVC and VP9 make them almost burn.
[11:19:43 CEST] <c_14> ffvp9 decodes as fast or faster than ffh264
[11:20:05 CEST] <Fyr> Mavrik, because most of my videos are in H.264 and not in VP9 or HEVC.
[11:20:49 CEST] <Fyr> VP9 or HEVC would halve their size and use lower bandwidth on stream videos.
[11:21:01 CEST] <Mavrik> Not sure what you're talking about.
[11:21:10 CEST] <Mavrik> I guess your computer and tablets are old enough to not support either HEVC or VP9?
[11:21:14 CEST] <Fyr> that has to do with the general state of HW acceleration.
[11:21:24 CEST] <Fyr> maybe
[11:21:31 CEST] <Mavrik> Pretty much everything that supports HEVC HW decode also supports VP9. With the exception of Apple devices I guess?
[11:21:39 CEST] <Fyr> right
[11:21:40 CEST] <Mavrik> Not sure what the state of iOS is with VP9
[11:21:47 CEST] <Fyr> add also lack of AC-3.
[11:22:05 CEST] <Fyr> 8'-(
[11:22:15 CEST] <Mavrik> AC3 can be easily CPU decoded, not a huge deal
[13:48:09 CEST] <darsain> hey guys I have this command to scale down to required dimensions:
[13:48:12 CEST] <darsain> -vf scale="trunc(min(iw\,1024)/2)*2:trunc(min(ih\,600)/2)*2:force_original_aspect_ratio=decrease"
[13:48:47 CEST] <darsain> and I'm getting "height not divisible by 2" error if the ":force_original_aspect_ratio=decrease" is there
[13:48:52 CEST] <darsain> any way how to work around it?
[13:54:16 CEST] <niklob> hello, I need a windows build with dvb_teletext encoder enabled. Google couldn't help so far. Does anyone where I could get that?
[13:55:08 CEST] <niklob> --enable-libzvbi is what I need
[14:00:43 CEST] <kepstin> darsain: yeah, that seems to be an issue with that option. If you're using expressions anyways you can probably implement the effect of that option in the expressions, but it will make it more complicated.
[14:03:04 CEST] <darsain> kepstin, uh, any pointers how? :)
[14:04:38 CEST] <kepstin> darsain: you have the input width and height (and sar) available as variables, so you can calculate "is the source video wider or taller than the desired output?", and use that in a conditional when picking the output size
[14:06:32 CEST] <darsain> kepstin, yes, that is obvious, but I'm not that familiar with the syntax and methods to do that in the -vf string
[14:10:56 CEST] <kepstin> You'd probably just want something like 'if(gte(dar\,1024/600)\,{wider}\,{narrower})'
[14:11:09 CEST] <kepstin> note that the expression docs are here: https://www.ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation
[14:11:41 CEST] <darsain> kepstin, thx, I'll play around with that :)
[14:14:34 CEST] <niklob> are there ffmpeg builds with all codecs enabled available?
[14:15:03 CEST] <Cracki> maybe
[14:15:03 CEST] <kepstin> no, because ffmpeg builds with all codecs enabled are a license combination that's not redistributable
[14:15:18 CEST] <Cracki> in some jurisdictions
[14:15:21 CEST] <kepstin> there's some with *most* codecs enabled, tho.
[14:40:47 CEST] <darsain> can the expression return a string? for example, instead of doing:
[14:40:51 CEST] <darsain> "if(gte(dar\,1024/600)\,{widthCalcWide}\,{widthCalcNarrow}):if(gte(dar\,1024/600)\,{heightCalcWide}\,{heightCalcNarrow})"
[14:40:56 CEST] <darsain> to do a simpler version with only one conditional method:
[14:41:00 CEST] <darsain> "if(gte(dar\,1024/600)\,{widthCalcWide}:{heightCalcWide}\,{widthCalcNarrow}:{heightCalcNarrow})"
[14:52:41 CEST] <darsain> or rather, if I can return a stringexpression from if()
[15:29:53 CEST] <niklob> Does anyone here got mingw installed?
[15:30:24 CEST] <JEEB> i have at home
[15:30:50 CEST] <Fyr> (=
[15:30:52 CEST] <Fyr> I do
[15:31:12 CEST] <niklob> Fyr, are you able to compile with --enable-libzvbi flag?
[15:31:53 CEST] <Fyr> niklob, I've never tried to compile it with this option.
[15:32:40 CEST] <niklob> Fyr: Could you give it a try please? I can't get it done now and I can't find a build
[15:32:54 CEST] <Fyr> niklob, is it connected to:
[15:32:54 CEST] <Fyr> https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=1390
[15:32:54 CEST] <Fyr> ?
[15:33:02 CEST] <niklob> I hope it's not too much work
[15:33:53 CEST] <Fyr> so, is it a Linux library?
[15:34:01 CEST] <Fyr> why is it necessary for Windows?
[15:34:12 CEST] <niklob> I don't have linux atm :(
[15:35:51 CEST] <niklob> Oh that last link from the thread did it for me!
[15:36:02 CEST] <niklob> Thank you, Fyr! <3
[15:37:55 CEST] <niklob> Fyr, damnit actually it didn't. It got the decoder enabled, but not the encoder. I'll keep searching
[15:44:30 CEST] <JEEB> i don't think ffmpeg's libzvbi wrapper had encoding support?
[15:49:24 CEST] <CoreX> niklob i tried soo many times to add libzvbi to my compiles i gave up in the end
[16:21:59 CEST] <niklob>  ( :+/  I'LL NEVER GIVE UP! GLOBALIST SCUM! AAAAAAAAAAAAAHHHHHHHHHHHH!
[16:39:39 CEST] Action: redrabbit watches UHD1 by astra
[16:39:43 CEST] <redrabbit> encoding porn
[16:39:54 CEST] <redrabbit> picture & so perfect
[16:40:26 CEST] <redrabbit> 17.8Mbit
[16:42:19 CEST] <redrabbit> im trying hard to see artifacts
[16:42:43 CEST] <redrabbit> got to get ridicoulously close to the screen lol
[16:47:09 CEST] <Fyr> redrabbit, do you mean, re-encoding?
[16:47:28 CEST] <redrabbit> its satellite tv
[16:48:24 CEST] <redrabbit> orbital position 19.2°E
[16:52:22 CEST] <Fyr> I always thought that the video downloaded from server has a better quality than the video retranslated and received as analogous.
[16:52:49 CEST] <redrabbit> well in that case, the quality is impeccable
[16:53:13 CEST] <Fyr> but quality fades with distance.
[16:53:27 CEST] <redrabbit> you are kidding right :p
[16:53:29 CEST] <Fyr> that's why people turn to digital TV.
[16:53:42 CEST] <redrabbit> nice try
[16:53:47 CEST] <Fyr> though it requires a better bandwidth.
[16:53:48 CEST] <redrabbit> such a troll rofl
[16:53:51 CEST] <redrabbit> :')
[16:54:14 CEST] <Fyr> redrabbit, send me a sample.
[16:54:29 CEST] <redrabbit> capping right now
[16:58:31 CEST] <redrabbit> i hope you wont mind the wait, upload is crowded atm, uploading stuff to yt
[17:07:18 CEST] <JEEB> redrabbit: any broadcast encode is in no way special. the artifacts depending on the format are somewhat different (in addition to encoder-specific stuff if an encoder has faults that end up in visible artifacting), and you might just not be noticing them due to the added resolution.
[17:07:49 CEST] <JEEB> broadcast in general is limited through VBV/HRD and usually has short GOPs etc
[17:07:54 CEST] <redrabbit> just saying it looks better than current hdtv
[17:08:47 CEST] <Fyr> redrabbit, does it look better than current 4k?
[17:09:07 CEST] <JEEB> define whatever you mean with that first
[17:09:41 CEST] <Mavrik> That's usually because broadcast TV has significantly higher bitrates than the compressed dreck they stream over IPTV or cable
[17:09:47 CEST] <Mavrik> At least here in EU on average.
[17:09:51 CEST] <Fyr> I mean than current non-free 4k porn distributed on the Internet.
[17:10:32 CEST] <JEEB> I've had 40mbps 2160p60 BT.2020 streams and they definitely were showing off the fact that it was a lulzy broadcast encoder
[17:10:34 CEST] <redrabbit> it is 4K
[17:11:13 CEST] <redrabbit> imgpost.cf/UHD1.ts
[17:11:16 CEST] <JEEB> of course, if you watch it in a way that the samples are small enough you might not notice the artifacts just due to the added amount of stuff
[17:11:35 CEST] <JEEB> (that is the reason why broadcast wants to go 8K)
[17:11:56 CEST] <JEEB> "because the compression artifacts on a 4K screen will look smaller"
[17:12:26 CEST] <Guest39209> Is there any good way to add chapters with the C APIs?
[17:12:42 CEST] <JEEB> chapters most definitely are in the API
[17:12:50 CEST] <JEEB> check the muxer you'll be poking
[17:13:54 CEST] <redrabbit> looks way better than current 1080p tv streams
[17:14:25 CEST] <leif> JEEB: Ah, okay, so you insert it at the start, before you start adding packets?
[17:14:58 CEST] <JEEB> leif: not sure how exactly it works, that's why I noted checking some code in the FFmpeg repo
[17:16:08 CEST] <leif> JEEB: Makes sense, thanks.
[17:16:39 CEST] <BtbN> Why don't they just use non-shit encoders?
[17:16:56 CEST] <BtbN> Seriously, a single powerful PC with a bunch of x264 processes could do a better job
[17:17:13 CEST] <JEEB> because politics
[17:17:21 CEST] <JEEB> it's always been a VeryExpensiveBox
[17:17:27 CEST] <JEEB> thus it will be a VeryExpensiveBox
[17:17:35 CEST] <JEEB> (and maybe someone somewhere got some blowjobs)
[17:17:38 CEST] <Fyr> redrabbit, the picture IS NOT impeccable.
[17:17:43 CEST] <BtbN> I don't think x264 supports multi-stream-cbr.
[17:17:55 CEST] <BtbN> But that could definitely be added
[17:18:19 CEST] <redrabbit> its quite good for a satellite stream
[17:18:24 CEST] <Fyr> it looks lakie hardware encoding with the highest possible quality.
[17:18:48 CEST] <JEEB> redrabbit: if it's just 17Mbps that's defintely on the lower spectrum of satellite broadcast
[17:18:48 CEST] <redrabbit> yeah its hw encoding
[17:18:54 CEST] <Fyr> good, but software encoding is better in comparable bitrate.
[17:18:57 CEST] <JEEB> I've had 40Mbps satellite broadcasts
[17:19:29 CEST] <redrabbit> on what orbital position
[17:19:55 CEST] <JEEB> let me check, it was the "4K Channel" that was received in Japan
[17:20:20 CEST] <redrabbit> max bitrate ive seen in europe from my rotor is 25Mbit
[17:20:28 CEST] <redrabbit> on some 4K test channels
[17:20:58 CEST] <JEEB> ok, 40Mbps was a bit over the top, it seems like it was 35Mbps
[17:21:12 CEST] <JEEB> DVB-S2 8PSK 3/5
[17:22:14 CEST] <redrabbit> what i like about that 17Mbit 4K is the fact that its closer to actual bitrates for 1080p and still looks a ton better.. could possibly end up used for actual broadcastings in the future
[17:22:21 CEST] <redrabbit> can't wait to see the low end disapear
[17:22:22 CEST] <redrabbit> :p
[17:23:09 CEST] <redrabbit> tons of horrid stuff on sattelite
[17:23:11 CEST] <JEEB> anyways, I've got some samples from that channel and the encoder's just shit :P
[17:23:13 CEST] <redrabbit> mpeg2 rules
[17:23:33 CEST] <redrabbit> i posted the sample JEEB
[17:23:44 CEST] <redrabbit> can judge by youself
[17:23:54 CEST] <JEEB> I have some earlier samples from that one as well
[17:24:12 CEST] <JEEB> didn't really show anything that AVC couldn't do IMHO
[17:24:16 CEST] <atomnuker> hevc video and yet crappy mpeg2 audio at 192kbps
[17:24:47 CEST] <redrabbit> yeah its crazy how bad the settings are on satellite broadcasting
[17:24:57 CEST] <redrabbit> im comparing satellite broadcasting to satellite broadcasting in that case
[17:26:04 CEST] <niklob> How to encode teletext subtitles, guys. :(
[17:26:41 CEST] <JEEB> niklob: implement it either in libavcodec or write a libzvbi wrapper for encoding if libzvbi supports encoding it
[17:29:08 CEST] <kerio> teletext subtitles?
[17:29:09 CEST] <kerio> what year is this
[17:29:22 CEST] <JEEB> it's the DVB way of passing text based subtitles
[17:29:26 CEST] <JEEB> (´4@)
[17:29:41 CEST] <JEEB> just like US likes its ATSC captions within the video stream
[17:29:42 CEST] <redrabbit> i have to setup that on my transcoding setup as well
[17:30:14 CEST] <kerio> JEEB: not on fancy hd streams for sure tho
[17:30:24 CEST] <JEEB> yes, even in HD
[17:30:32 CEST] <JEEB> if you have text based subs
[17:30:36 CEST] <JEEB> they are teletext in DVB
[17:30:36 CEST] <redrabbit> gross
[17:30:53 CEST] <JEEB> image based subtitles are usually DVB subtitles because that lets you do higher resolution
[17:31:48 CEST] <kerio> hmm
[17:32:18 CEST] <JEEB> the libavcodec libzvbi wrapper will decode teletext in image mode by default, though. which is why it can look like shit
[17:32:25 CEST] <JEEB> you have to select the text mode manually
[17:32:31 CEST] <kerio> anyway my parents managed to buy a tv with integrated sat tuner and no SCART port
[17:33:15 CEST] <kerio> so we couldn't connect our old tuner box, and we had to buy a CAM :|
[17:33:29 CEST] <JEEB> heh
[17:33:30 CEST] <kerio> who makes a tv without SCART
[17:33:42 CEST] <JEEB> I'm pretty sure my current TV has no SCART
[17:33:50 CEST] <kerio> who makes a tv without SCART in europe
[17:34:01 CEST] <JEEB> I had to buy a RGB SCART cable for my console + SCART->HDMI converter
[17:34:04 CEST] <JEEB> this is Europe :
[17:34:05 CEST] <JEEB> :D
[17:34:06 CEST] <kerio> dear lord
[17:34:10 CEST] <kerio> hold on what console is that
[17:34:16 CEST] <JEEB> original xbox
[17:34:20 CEST] <kerio> ...y tho
[17:34:27 CEST] <kerio> skies of arcadia?
[17:34:29 CEST] <JEEB> because I have it and i want to have the capability to play it?
[17:34:50 CEST] <JEEB> there's some old games that were never released on anything else later
[17:34:53 CEST] <kerio> i mean you could just play halo with a controller on pc
[17:34:59 CEST] <kerio> :^)
[17:35:04 CEST] <JEEB> and Xbox emulation isn't exactly in good state
[17:35:11 CEST] <redrabbit> because you can is enough
[17:35:11 CEST] <redrabbit> :p
[17:35:27 CEST] <JEEB> I will probably have to get some stuff for my Megadrive too
[17:35:28 CEST] <JEEB> :D
[17:35:33 CEST] <kerio> yea it strikes a weird imbalance of being quite powerful, because pc, but hard to emulate, because not really pc
[17:35:33 CEST] <BtbN> Scart->HDMI converter that understands RGS?
[17:35:35 CEST] <BtbN> *RGB
[17:35:41 CEST] <redrabbit> keepin' the gear working is a satisfaction
[17:35:44 CEST] <redrabbit> even if you dont use it
[17:35:44 CEST] <JEEB> BtbN: at least I think so
[17:35:44 CEST] <redrabbit> lol
[17:35:52 CEST] <JEEB> BtbN: it still does weird upscaling and filtering though
[17:35:54 CEST] <BtbN> The ones I dealt with just used the composite signal and ignored the high quality RGB
[17:35:58 CEST] <kerio> redrabbit: yea that's why i bought another flash cart
[17:36:09 CEST] <kerio> even though i haven't been playing with my 3ds at all
[17:36:41 CEST] <BtbN> If you want high quality RGB to Digital, you'll want something like an OSSC.
[17:37:16 CEST] <kerio> "high quality"
[17:37:20 CEST] <JEEB> yea, the box I have currently is crap but it works well enough
[17:37:29 CEST] <JEEB> (although I'm indeed not 100% sure if it's RGB input or not)
[17:37:53 CEST] <BtbN> RGB is the highest quality you can possibly get out of pre-HDMI consoles
[17:38:13 CEST] <BtbN> If you have money to spare, you can also get a Framemeister. That's supposedly even better, but not open-source.
[17:41:42 CEST] <BtbN> The setup we had at ESA primarily involved an OSSC and an iScan VP50, to generate optimal quality digital image, no matter what console you connected to it.
[17:41:57 CEST] <BtbN> And some other devices which I forgot about.
[17:44:37 CEST] <kerio> BtbN: rgb? not component?
[17:44:44 CEST] <kerio> rgb is still interlaced, right?
[17:44:56 CEST] <BtbN> Can be, but doesn't have to
[17:45:11 CEST] <BtbN> A lot of older consoles can output RGB, or can easily be modded to do so.
[17:45:28 CEST] <BtbN> And out of all the possible outputs, it's by far the best
[17:45:39 CEST] <kerio> why did i buy that component cable for the wii then 🤔
[17:45:46 CEST] <BtbN> Wii can't output RGB
[17:45:51 CEST] <BtbN> Component is the best you get there
[17:45:56 CEST] <furq> skies of arcadia fucking sucks
[17:45:57 CEST] <JEEB> without HW modding that is
[17:45:59 CEST] <furq> i just wanted to mention that
[17:46:16 CEST] <BtbN> sure, but why would you mod the Wii, which can do Component natively, to get RGB out of there?
[17:46:20 CEST] <BtbN> The benefit of that is not worth it
[17:46:40 CEST] <JEEB> true
[17:46:41 CEST] <kerio> especially if you're going to convert it to yuv anyway :^)
[17:47:30 CEST] <BtbN> But on very old consoles, like (S)NES, getting RGB is just a matter of soldering some pre-existing connectors on the PCB to some new RCA connector on the back
[17:48:04 CEST] <JEEB> yea
[17:48:50 CEST] <BtbN> And I think all the Sony-Consoles just support RGB natively in their better SCART cables
[17:49:01 CEST] <BtbN> But not YCbCr
[17:50:51 CEST] <furq> i'm not really sure what you'd do with a megadrive
[17:50:57 CEST] <furq> it does rgb natively but all the adapters i've seen are scart
[17:51:25 CEST] <BtbN> You put it into a Syncstrike
[17:51:41 CEST] <furq> oh nvm there are some component cables for it
[17:52:59 CEST] <JEEB> I think I checked the alternatives for my model from some UK cable store lately
[17:53:21 CEST] <furq> scart cables are pretty cheap and widely available
[17:53:21 CEST] <BtbN> The Standard-Setup for Scart-Console was SCART from console into Syncstrike to VGA, VGA into OSSC, into iScan VP50, output in 1080p60 HDMI, to capture card.
[17:53:21 CEST] <JEEB> something like https://www.retrogamingcables.co.uk/games-consoles/sega/mega-drive-2/sega-mega-drive-2-sega-genesis-2-rgb-av-scart-cable-tv-lead
[17:53:40 CEST] <furq> yeah
[17:53:56 CEST] <furq> i'm glad i decided to stick with emulators
[17:54:03 CEST] <furq> especially given how expensive all this shit is now
[17:54:20 CEST] <BtbN> We had 5 racks with a full capture chain. I think each rack was easily worth like 10k¬
[17:54:42 CEST] <furq> i think i mentioned there's a CEX near me that was selling a megadrive and mega-cd for £120
[17:54:55 CEST] <furq> the same shop is now selling a boxed alisia dragoon for £40
[17:55:18 CEST] <furq> what kind of brain sickness would compel a man to spend £40 on alisia dragoon
[17:55:23 CEST] <furq> it wasn't even mint condition or anything
[17:55:26 CEST] <BtbN> need something like this for most classic RGB consoles http://arcadeforge.net/Scaler-and-Strike-Devices/Sync-Strike::15.html?language=en
[17:57:20 CEST] <furq> i do wish i'd bought that 1-slot MVS my friend was selling a few years ago
[17:57:32 CEST] <furq> those have exploded in value lately
[18:02:42 CEST] <JEEB> hah, https://www.retrogamingcables.co.uk/games-consoles/sega/mega-drive-2/sega-mega-drive-2-sega-genesis-2-rgb-av-scart-cable-tv-lead-packapunch
[18:02:57 CEST] <JEEB> BtbN: how much bullshit is in this description? :D
[18:09:23 CEST] <BtbN> which one? The SyncStrike one, or the cable one?
[18:09:39 CEST] <JEEB> the cable I just linked :D
[18:09:54 CEST] <JEEB> although I just noticed that everything for MD2 is out of stock anyways
[18:09:57 CEST] <JEEB> (´4@)
[18:10:05 CEST] <furq> should've got a 1
[18:10:25 CEST] <JEEB> hey, it's a thing I got as a BD present back in my kiddo years :D
[18:10:31 CEST] <JEEB> couldn't actually select what I got
[18:10:38 CEST] <BtbN> reads quite reasonable to me. A bit over the top on praising the cable quality though.
[18:10:44 CEST] <furq> i had a 1 and a 32x and my parents chucked them when i moved out
[18:10:52 CEST] <furq> i could've got £150 for those now
[18:10:58 CEST] <BtbN> I'd rather buy a seperate SyncStrike and a normal cable. Would be cheaper and more versatile.
[18:11:33 CEST] <BtbN> It's essentially just a built-in SyncStrike into the plug
[18:12:24 CEST] <JEEB> furq: in my case I passed the MD2 to my Russian family side's kids
[18:12:36 CEST] <JEEB> and now they no longer care about it so I'm going to take it back and check it
[18:15:29 CEST] <furq> are they not big fans of >;K<8 @C:0<8
[18:25:06 CEST] <cryptodechange> Encoding DVDs again, what was it again when 2 frames had scanlines and 3 were fine? Telecine right?
[18:25:14 CEST] <furq> yes
[18:26:24 CEST] <cryptodechange> I found a thread somewhere that had a pretty nifty cheat sheet for telecine, interlaced etc
[18:29:28 CEST] <cryptodechange> Scan type : Interlaced, Scan order : Top Field First
[18:31:10 CEST] <cbsrobot> cryptodechange: https://ffmpeg.org/ffmpeg-filters.html#detelecine
[18:33:21 CEST] <furq> cryptodechange: i've probably mentioned this before but all DVDs show as tff interlaced
[18:33:37 CEST] <furq> you need to check it by eye
[18:34:56 CEST] <cryptodechange> Yeah I spoke about this months ago, I've yet to experiment with it as I was focusing on my blurays for the time being
[18:35:03 CEST] <cryptodechange> but it's definitely 3 frames progressive, 2 interlaced
[18:36:08 CEST] <furq> well yeah there are a bunch of filters for it of varying complexity for sources of varying complexity
[18:36:13 CEST] <furq> detelecine is the most basic iirc
[18:37:50 CEST] <cryptodechange> Also, if the end result is a different fps, would I need to reencode the audio?
[18:38:00 CEST] <furq> no
[18:38:16 CEST] Action: cryptodechange usually leaves audio untouched
[18:38:52 CEST] <furq> the fps changes from 30 to 24 because you're combining two frames out of every five
[18:39:03 CEST] <furq> the duration stays the same
[18:39:29 CEST] <JEEB> no, you remove fields so that it goes down
[18:39:43 CEST] <JEEB> combining just puts two fields together
[18:40:01 CEST] <JEEB> so you get 30/1.001Hz out of 60/1.001Hz fields
[18:40:19 CEST] <cryptodechange> i see, makes sense
[18:40:37 CEST] <furq> sure
[18:40:45 CEST] <furq> you're combining half of one frame with half of the next
[18:40:52 CEST] <JEEB> uhh, no?
[18:41:01 CEST] <JEEB> and that's field matching
[18:41:09 CEST] <JEEB> field match => decimation
[18:41:09 CEST] <redrabbit> does all american tv is shot at 30fps
[18:41:19 CEST] <furq> no, some is shot at 24
[18:41:26 CEST] <furq> and some is shot at 60
[18:41:50 CEST] <JEEB> so you first do field matching so that you get 30Hz frames out of 60Hz fields with the minimum amount of combing
[18:42:02 CEST] <JEEB> and then you decimate (usually to 24Hz from 30Hz)
[18:42:30 CEST] <JEEB> usually stuff that requires decimation can be seen after field matching as the pattern ends up being 1-2-3-4-4 instead of 1-2-3-4-5
[18:51:21 CEST] <cryptodechange> the original framerate is 29.970 (30000/1001) FPS
[18:53:59 CEST] <JEEB> cryptodechange: the coded frame rate (with fields put together usually)
[18:54:08 CEST] <JEEB> that really means... not much with interlacism
[18:54:18 CEST] <JEEB> it just means what you get in, not what's inside of it
[19:02:19 CEST] <cryptodechange> So something like -vf "fps=24000/1001,fieldmatch,yadif=deint=interlaced,decimate"
[19:03:01 CEST] <JEEB> wat @ the fps override in the beginning
[19:03:21 CEST] <cryptodechange> me rn https://cdn-images-1.medium.com/max/455/1*snTXFElFuQLSFDnvZKJ6IA.png
[19:03:38 CEST] <JEEB> you can do deint after fieldmatch but that usually means you're expecting the source to not be pure telecine
[19:03:51 CEST] <JEEB> which it can be, but you should check
[19:04:19 CEST] <JEEB> doing extra stuff if not needed is kind of meh. you will have to quality check the transcode anyways
[19:05:02 CEST] <cryptodechange> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2014-May/021253.html
[19:05:46 CEST] <cryptodechange> so the decimate and the fps is redundant
[19:06:04 CEST] <JEEB> no, it just means that you are field matching something that is supposedly already 24Hz
[19:06:19 CEST] <JEEB> which means you go (4/5)*24Hz
[19:06:42 CEST] <JEEB> (unless decimate filter picks another decimation pattern with 24Hz input)
[19:07:09 CEST] <JEEB> and yes, the yadif is often added so that users don't ask more questions and possible "no match found" fields would get "magically handled"
[19:08:38 CEST] <JEEB> also don't expect blu-rays to be free of interlacism btw, I've seen plenty of blu-rays with interlacism on them :V (in both telecined and truly interlaced form)
[19:08:53 CEST] <JEEB> although you have much higher chances of getting progressive stuff on the disc
[19:09:46 CEST] <JEEB> since unlike older things like DVD the spec doesn't require interlacism (even if soft telecine with the headers that mark when an interlaced device should duplicate fields)
[19:11:21 CEST] <cryptodechange> oh jeez, weirdly most DVDs I play (animated, at least), I can notice it off the bat
[19:12:44 CEST] <JEEB> you get extra points for finding stuff that's somehow been f'd up. like the opening of the 2008 animated series "true tears" having two separate telecine patterns at the same time
[19:12:54 CEST] <JEEB> young me was... rather confused
[19:13:01 CEST] <cryptodechange> ;_;
[19:13:02 CEST] <JEEB> "I field match this and it's still wrong?!"
[19:13:22 CEST] <JEEB> (since field matching would only fix one of the patterns)
[19:13:27 CEST] <cryptodechange> i suppose -vf "fieldmatch,fieldmatch" won't work
[19:13:41 CEST] <JEEB> nope
[19:13:43 CEST] <cryptodechange> :P
[19:14:08 CEST] <cryptodechange> following some oldish ffmpeg mail list trail
[19:14:17 CEST] <JEEB> and then there's the more usual case of "whomever edited this stuff did it in interlaced mode"
[19:14:17 CEST] <cryptodechange> how -vf fieldmatch,yadif=deint=interlaced does most the work but can leave juddering
[19:14:48 CEST] <JEEB> that does just fieldmatch, if the content looks like it has doubling (1-2-3-4-4 instead of 1-2-3-4-5) you of course decimate
[19:15:03 CEST] <cryptodechange> so -vf fieldmatch,yadif=deint=interlaced,decimate \o/
[19:15:23 CEST] <cryptodechange> batch encode without visual comparison starting naow!
[19:15:31 CEST] <JEEB> :<
[19:15:50 CEST] <JEEB> most likely it will be "fine", but I still hate batch crap for interlaced content
[19:15:54 CEST] <CoreX> somebody said the fieldmatch filter is terrible in ffmpeg
[19:16:02 CEST] <CoreX> is that true or just alot of BS ?
[19:16:08 CEST] Action: cryptodechange hits ctrl+c
[19:16:15 CEST] <JEEB> it can be, but IIRC it was a port of the Vapoursynth filter which seemed OK
[19:16:27 CEST] <JEEB> which in its own part based on the TIVTC filter in Avisynth
[19:16:47 CEST] <JEEB> (which is what pretty much everyone used in avisynth)
[19:17:20 CEST] <CoreX> so better to stick with avs+dlls if you want perfection with encoding in ffmpeg
[19:17:22 CEST] <JEEB> I generally hate not being able to preview the result so I'm mostly using avs (and vapoursynth nowadays) for most filtering
[19:17:52 CEST] <cryptodechange> I'll test a 150 frame encode once makemkv has finished
[19:17:57 CEST] <CoreX> yeah same here tho all my stuff is yadif based pal content but still its intresting to know
[19:18:49 CEST] <cryptodechange> my server spent a week encoding the dbz bluray, and my nlmeans filter made the backgrounds shake a little, where the frames misaligned but the grain somewhat hid it
[19:19:41 CEST] <cryptodechange> apart from that I'm pretty happy with it
[19:19:55 CEST] <cryptodechange> the negative smartblur (forgot who mentioned it) worked well
[19:20:33 CEST] <durandal_1707> JEEB: you can preview filters with mpv
[19:22:14 CEST] <JEEB> durandal_1707: true
[19:22:19 CEST] <JEEB> you just have to remember --pause
[20:29:23 CEST] <zyme> This might Dumb/pointless/not be the best place to ask: But does anyone know if there was a design reason or pattern basis for the resolutions chosen for HD standards? or it it just a coincidence that if you calculate the pixel count of 720p and divide by 1080 you get 853.333~ which is the column count for 480p when both are standard 16:9; and is it also coincidental that 1080-480=600 which is exactly halfway between 480
[20:29:23 CEST] <zyme> and 720? Just seems like there was an mathematical idealology used for deciding the ideal resolution difference/increments. I'm thinking the up/downscale encoding processes are more efficient at specific amount intervals instead of being just reliant on maintaining  similar ratios and being different in efficiency or accuracy only based off the % resolution size difference.
[20:34:58 CEST] <BtbN> They are just multiples of 360?
[21:16:53 CEST] <cryptodechange> I asked yesterday about packet/frame loss on a network drive, what about a 100% HDD load?
[21:25:20 CEST] <BtbN> what about it? Things will be slow.
[22:10:31 CEST] <dystopia_> so i have a weird issue
[22:10:51 CEST] <dystopia_> somtimes when encoding somthing, ffmpeg will just freeze for like a minute
[22:10:59 CEST] <dystopia_> then just continue going like normal
[22:11:24 CEST] <dystopia_> could this be a sign the drive it's running from is dying
[22:11:26 CEST] <dystopia_> or somthing else
[22:17:10 CEST] <BtbN> most likely waiting on io
[22:31:43 CEST] <jj15> Hey all, I'd like to place an audio EQ into a stream. I'm unsure of the best way to do this. Only thing I can think of is converting the audio to a visual equaliser and then layering that over the original video. Is there a better way to do it?
[23:06:44 CEST] <furq> jj15: what do you mean by audio EQ
[23:07:37 CEST] <jj15> A visual audio equaliser. You see them on videos. Like the on here https://www.youtube.com/watch?v=cmT_hJdvDp0
[23:08:06 CEST] <furq> !filter showspectrum
[23:08:06 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#showspectrum-1
[23:08:11 CEST] <furq> that's the closest thing ffmpeg has afaik
[23:08:25 CEST] <furq> and it doesn't really look as neat as that
[23:08:54 CEST] <furq> er
[23:08:56 CEST] <furq> !filter showfreqs
[23:08:56 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#showfreqs
[23:08:59 CEST] <furq> that, rather
[23:10:42 CEST] <jj15> I took a look at those, but yeah as you say they don't look too good. I was thinking to do it in aftereffects, export it and just use ffmpeg for the streaming. I think that's as good as I'm going to get.
[23:42:47 CEST] <lightbulb6> hello. i'm trying to encode with ffmpeg using libvpx-vp9 with the `-row-mt` switch under windows using the latest zeranoe build (2017-08-17), but ffmpeg does not recognize that parameter. i've also tried the static linux build, once again 2017-08-17, and it recognizes the parameter just fine
[23:45:35 CEST] <lightbulb6> apparently both builds were built with vpx version 1.6.1, so i can't really see why the zeranoe build would not recognize that switch
[23:47:27 CEST] <furq> i don't think row-mt has made it into a release yet
[23:47:32 CEST] <furq> you still need a git build iirc
[23:49:04 CEST] <lightbulb6> so the libvpx version zeranoe uses does not have that yet? i'll try building ffmpeg myself on windows, thanks
[00:00:00 CEST] --- Sun Aug 20 2017