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

[burek]

[00:13:11 CEST] <oldfriend83> and now?
[00:13:22 CEST] <JEEB> uh-huh
[00:14:19 CEST] <oldfriend83> hello, gus. Can anybody tell me why ffmpeg crashes when I set in overlay option Y coordinate with negative value?
[00:15:59 CEST] <oldfriend83> https://pastebin.com/eP1tK4MU
[00:19:30 CEST] <durandal_1707> oldfriend83: use latest ffmpeg version. not some old one.
[00:25:55 CEST] <oldfriend83> durandal_1707: thank you
[08:32:59 CEST] <lain98> i have a video with variable frame rate. i want to transcode it with smaller gop size. i use the command ffmpeg -i in.mp4 -g 10 out.mp4 but output video is constant frame rate.

[16:32:17 CEST] <DHE> th3_v0ice: it's just called "format", shared with audio sample format and video pixel format
[16:33:21 CEST] <kepstin> th3_v0ice: do you get a playback problem if you try to play it with ffplay? if so, can you post the complete log?
[16:56:45 CEST] <th3_v0ice> kepstin: ffplay actually plays the video but it takes a while to start. It also prints the warning about unspecified pixel format.
[17:29:07 CEST] <giaco> hello
[17:30:05 CEST] <giaco> I'm playing with ffmpeg blackframe videofilter to detect dark frames: I successfully tune the params to get desired frames according to console output, but I'm not succeeding getting an output file
[17:56:58 CEST] <kepstin> giaco: the blackframe filter should be just passing the frames through (it just attaches some metadata to them), it shouldn't be doing anything that prevents you from encoding an output file
[17:57:19 CEST] <kepstin> giaco: maybe give an example of your command line and what you expect it to do?
[19:36:17 CEST] <brimestone> Hey guys, is there a way to add close caption (not subtitle) to an MXF file using an srt file?
[19:38:43 CEST] <DHE> if you mean EIA closed captions, there is no such encoder in ffmpeg right now
[19:39:15 CEST] <brimestone> I see.. but you can extract from it correct?
[19:40:04 CEST] <JEEB> you can get them from the video stream if they're included in it, yes
[19:40:13 CEST] <JEEB> there's parsing from MPEG-2, H.264 and HEVC
[19:40:15 CEST] <JEEB> and a decoder
[19:40:35 CEST] <brimestone> Ahh so ffmpeg can decode but not encode?
[19:44:57 CEST] <JEEB> brimestone: it can also of course pass those things through as long as the encoder side can put those in correctly
[19:46:38 CEST] <brimestone> JEEB, DHE said no CC encoder in FFmpeg right now..
[19:46:52 CEST] <JEEB> no encoder for the closed caption data
[19:46:57 CEST] <JEEB> but if you decode say H.264 with them
[19:47:06 CEST] <JEEB> the caption data packets will be attached as side data
[19:47:19 CEST] <JEEB> and as long as those don't get lost in your API usage, and as long as the video encoder can handle them
[19:47:26 CEST] <DHE> and you can pass them unmodified to an output h264 or h265 stream
[19:47:36 CEST] <JEEB> they will then be packaged in the encoder in the whatever format you're encoding
[19:47:58 CEST] <brimestone> ahh.. as long as they already exist and not creating CC from an srt file
[19:48:25 CEST] <JEEB> yup, making the closed caption packets out of nothing is what FFmpeg can't atm do since nobody wrote an encoder :)
[19:48:28 CEST] <JEEB> watches are pelcome
[19:48:43 CEST] <Chagall> I deleted all my installed ffmpeg libs, rebuilt from scratch and ran make install but ffmpeg still reports a config mismatch, what to do?
[19:48:45 CEST] <brimestone> I see.
[19:48:50 CEST] <brimestone> Thanks for the clarification.
[19:49:12 CEST] <JEEB> Chagall: time to look at where the hell you're loading solibs from
[19:49:17 CEST] <JEEB> strace or something
[19:49:36 CEST] <DHE> an prior build not cleaned up?
[19:49:49 CEST] <DHE> rm libav*/*.{so,a}
[19:49:51 CEST] <DHE> something like that
[19:58:04 CEST] <Chagall> ./usr/lib/x86_64-linux-gnu/libavcodec.so
[19:58:05 CEST] <Chagall> derp
[20:46:16 CEST] <SpeakerToMeat> Hello
[20:46:24 CEST] <SpeakerToMeat> Question, doesn't x264 encoding support level 6?
[20:47:25 CEST] <BtbN> "level 6"?
[20:47:40 CEST] <DHE> as opposed to level 4.1 ?
[20:48:10 CEST] <SpeakerToMeat> I need 6, as I'm encoding a 7680x740 file, afaik
[20:48:15 CEST] <DHE> I don't think x264 itself cares. it doesn't have realtime requirements by itself, which is what the level really means
[20:48:26 CEST] <SpeakerToMeat> Oh. I see
[20:48:31 CEST] <DHE> ffmpeg does have some internal limit of 4096x4096 images iirc, due to 32 bit risks
[20:48:43 CEST] <SpeakerToMeat> level is not a spec in the codec but a "equipment needs to support level x to play something this big/fast"
[20:49:14 CEST] <DHE> yes, and x264 can constrain your encoding parameters or call you out if you tell if what level you want to meet and your options actually exceeds it
[20:49:27 CEST] <SpeakerToMeat> Nod
[20:49:37 CEST] <SpeakerToMeat> Well it IS encoding (without specifying a level), so...
[20:49:54 CEST] <JEEB> SpeakerToMeat: x264 can support it, but unfortunately there were some additional things added into levels 6.x :P
[20:50:06 CEST] <SpeakerToMeat> at 0.0043x but it is encoding supposedly for 7680x740
[20:50:34 CEST] <JEEB> namely it will utilize longer motion vectors
[20:50:45 CEST] <JEEB> because for some bloody reason the H.264 spec contains that for level 6.x
[20:50:55 CEST] <JEEB> which is why generally if you can, limit yourself to 5.2 :P
[20:51:04 CEST] <SpeakerToMeat> hmmmm
[20:51:13 CEST] <JEEB> x264 should output which level it's utilizing
[20:51:19 CEST] <JEEB> if not by default, then -v verbose should bring it out
[20:51:29 CEST] <SpeakerToMeat> Yeah sadly at that pixel size no go for 5.x
[20:51:31 CEST] <JEEB> by default it selects the lowest matching your frame size etc
[20:52:05 CEST] <JEEB> SpeakerToMeat: are you planning on having that thing decoded by a) older software decoders b) hardware decoders ?
[20:52:12 CEST] <JEEB> if not, then don't care
[20:52:25 CEST] <SpeakerToMeat> Interesting: "profile High, level 5.1
[20:52:38 CEST] <JEEB> yea, level frame size limitations are in 16x16 blocks
[20:52:47 CEST] <SpeakerToMeat> Yeah no it's recent hardware and software that will decode it so.
[20:52:50 CEST] <JEEB> not exact width/height
[20:53:02 CEST] <SpeakerToMeat> Yeah macroblocks
[20:53:06 CEST] <SpeakerToMeat> afaik
[20:53:08 CEST] <JEEB> yup
[20:53:36 CEST] <SpeakerToMeat> So what do you say about level 6... it enforces longer vectors? or it permits longer vectors and x264 goes happy with them?
[20:53:48 CEST] <JEEB> it permits and x264 does default to them
[20:53:51 CEST] <SpeakerToMeat> And, what's the harm/pro of longer motion vectors?
[20:53:53 CEST] <JEEB> noticed it when encoding 2160p60
[20:54:04 CEST] <JEEB> (the rate isn't really related)
[20:54:19 CEST] <JEEB> but yea, in the best case hwdec just says "nope, that level I don't support"
[20:54:26 CEST] <JEEB> in the worst case your hwdec will just barf at it
[20:54:41 CEST] <SpeakerToMeat> My guess is longer vectors make for a much longer encoding process but shouldn't affect quality or decoding speed
[20:54:56 CEST] <SpeakerToMeat> Or am I wrong
[20:55:09 CEST] <JEEB> it's mostly for encoder freedom, but note that until then the spec had motion vectors of specific length
[20:55:19 CEST] <JEEB> thus any decoder that didn't specifically add support for longer ones "just in case"
[20:55:25 CEST] <JEEB> would just give fabulous artifacts
[20:55:26 CEST] <JEEB> :)
[20:55:43 CEST] <SpeakerToMeat> Hah yeah, true
[20:56:07 CEST] <SpeakerToMeat> Well x264 has a good truckload of options which afaik ffmpeg passes on... so, I guess it should be possible to reign those in... I hope
[20:56:19 CEST] <JEEB> level most definitely
[20:56:22 CEST] <SpeakerToMeat> At least without killign the expanded macroblock size capability
[20:56:35 CEST] <JEEB> the motion vector lenght stuff I'm less sure about
[20:56:36 CEST] <SpeakerToMeat> Yeah I mean achieving a level 6 with a defualt/short vector size
[20:56:51 CEST] <JEEB> that said, a lot of hwdec just nope with level 6
[20:56:52 CEST] <SpeakerToMeat> If I'm idle one of these days I have to give the source a look
[20:57:54 CEST] <JEEB> https://code.videolan.org/videolan/x264/commit/6f8aa71ce797be01fd2ebe53c072a6696ea19828
[20:58:17 CEST] <JEEB> seems hard-coded
[20:58:33 CEST] <SpeakerToMeat> My gods, thank god this is a short video (25 seconds), the encoding speed is atrocious
[20:59:00 CEST] <SpeakerToMeat> I need an nvenc with the image quality and options granularity of x264
[21:00:00 CEST] <SpeakerToMeat> JEEB: Isn't it "i_mv_range" ?
[21:00:24 CEST] <JEEB> true
[21:00:28 CEST] <JEEB> that is actually a parameter :P
[21:01:02 CEST] <JEEB> but only if that's exported
[21:01:03 CEST] <SpeakerToMeat> Yuppers, on one hand it is a parameter so it grows the maximum value but you could still set it in theory
[21:01:04 CEST] <SpeakerToMeat> yet.....
[21:01:26 CEST] <SpeakerToMeat> checkasm.c line 1984.....
[21:02:00 CEST] <JEEB> I think that's just updating the test
[21:02:03 CEST] <furq> wait since when was there a level 6
[21:02:07 CEST] <JEEB> 2016
[21:02:11 CEST] <furq> nice
[21:02:33 CEST] <JEEB> I'm a masochist that does 2160p60 with slow presets so I noticed it with my first 3D render :P
[21:02:55 CEST] <furq> doesn't 5.2 support 2160p60
[21:03:03 CEST] <SpeakerToMeat> JEEB: it's seteable
[21:03:09 CEST] <SpeakerToMeat> JEEB: "--mvrange <integer>     Maximum motion vector length [-1 (auto)]"
[21:03:16 CEST] <JEEB> SpeakerToMeat: great :)
[21:03:26 CEST] <JEEB> the bigger problem is just that a lot of hw decoders will just barf at you
[21:03:29 CEST] <JEEB> with level 6.x
[21:03:33 CEST] <SpeakerToMeat> Nod
[21:03:43 CEST] <furq> a lot of them will barf at 5 as well
[21:03:47 CEST] <JEEB> furq: yes it does, just that my slower preset usage would have led to level 6.x by default :)
[21:03:53 CEST] <furq> oh right yeah
[21:04:16 CEST] <SpeakerToMeat> furq: But I'm nto sure it supports 7680x740 :P
[21:04:36 CEST] <JEEB> anyways, at least I noticed with my first ever render :P
[21:04:44 CEST] <SpeakerToMeat> Yet... it encoded at level 5.1 so x264 thinks it does
[21:04:46 CEST] <furq> if that's not a typo then it should
[21:04:50 CEST] <JEEB> "wait that stuff at ~40s looks weird" https://megumin.fushizen.eu/videos/mmd_stuff/yukarin_conqueror_sample.mp4
[21:04:54 CEST] <furq> that's way fewer macroblocks than 2160p
[21:04:59 CEST] <JEEB> yea
[21:05:28 CEST] <gmaciolek> I have an FFMPEG (n4.2.1) instance I'm running (via bash script, but straightforward on that end) that's processing a directory of .jpg files into an animated gif, using an "inline" usage of palettegen/paletteuse. for some reason, it's only giving me a 24 frame output, regardless of there being ~45 input frames. A simpler version of the same command (without the 'vf' mess) makes the expected result.
[21:05:29 CEST] <SpeakerToMeat> Btw any idea why premiere (cs6) will insist an mjpeg (in mov) is prog whereas ff and mediainfo insists it's interlaced?
[21:05:54 CEST] <BtbN> Can mjpeg even be interlaced?
[21:06:00 CEST] <gmaciolek> Also, this only seems to happen on *some* of my image sets (!?) I can provide them if helpful.
[21:06:13 CEST] <SpeakerToMeat> can't all formats be? in theory?
[21:06:15 CEST] <furq> gmaciolek: pastebin the command line and output
[21:06:29 CEST] <BtbN> I mean, you can just make half-height images and call them fields, sure.
[21:06:37 CEST] <gmaciolek> furq: Working on it - what's a good pastebin these days?
[21:06:47 CEST] <kepstin> BtbN: i'm pretty sure i've heard of interlaced mjpeg stuff, iirc mov has signalling for it
[21:07:00 CEST] <furq> vpaste or clbin or something
[21:08:11 CEST] <kepstin> hmm, might be wrong about that, but i'm pretty sure people have thrown interlaced video into mjpeg before
[21:10:08 CEST] <BtbN> I'd imagine a weaved picture to look horrible when encoded with mjpeg
[21:10:10 CEST] <SpeakerToMeat> Some days I feel the impulse to hexedit a file to check what's the real truth
[21:10:20 CEST] <kepstin> looks like it's normally done with a separate image per field
[21:10:34 CEST] <gmaciolek> Functional, no-split: http://vpaste.net/QRKRi
[21:10:44 CEST] <SpeakerToMeat> BtbN: Not really, mjpeg should add no degradation to interlacing that any other codec wouldn't
[21:11:08 CEST] <BtbN> other codecs encode interlaced as two separate images
[21:11:26 CEST] <BtbN> or at least have special handling for the fact it's fields, not images
[21:12:04 CEST] <gmaciolek> Broken, incomplete frame list, w/split: http://vpaste.net/vwuvt
[21:12:40 CEST] <kepstin> BtbN: i just read the mov spec - each "frame" in the container consists of the jpeg data for both fields in the frame concatenated
[21:12:54 CEST] <kepstin> (there's an offset stored to find the start of the second field)
[21:14:22 CEST] <kepstin> https://developer.apple.com/standards/qtff-2001.pdf page 95 if you're curious
[21:15:58 CEST] <gmaciolek> furq: If you're interested in the set of images, it's 12 megs. full-disk images of the GOES-16 weather satellite, and I've uploaded them here: https://kb1ysq.com/ffmpeg/
[21:16:11 CEST] <gmaciolek> (zipped and .tar.gz for convenience)
[21:17:00 CEST] <SpeakerToMeat> Question, is there any player that'll do 1:1 playback? mpv and vlc all fit to screen so I can't see the true pixels...
[21:17:19 CEST] <SpeakerToMeat> I don't care if it overflows my screen, I just need to see a section to see how the fine detail ended up
[21:17:28 CEST] <gmaciolek> SpeakerToMeat: you can set them to be unscaled
[21:17:49 CEST] <SpeakerToMeat> with which player? I tried setting vlc... it still constrained it to screen size
[21:18:09 CEST] <gmaciolek> Take it out of fullscreen mode, and I *think* it works.
[21:18:38 CEST] <SpeakerToMeat> Also, do you know of any player you can ask not to pad the video? I want to see black only where there's black, so I can see the true boundaries
[21:19:12 CEST] <gmaciolek> Again, outside of fullscreen mode, both should do that unless you're specifying an aspect ratio or some such thing
[21:19:31 CEST] <SpeakerToMeat> gmaciolek: Ooook.. if I take vlc off maximized, it WILL do it if I unselect always fit
[21:19:35 CEST] <gmaciolek> If you have black borders on a window-sized VLC video with default settings, those borders are in your source material
[21:19:42 CEST] <kepstin> mpv by default will downscale if the window would otherwise be larger than the screen, but there's probably a way to override that
[21:20:14 CEST] <gmaciolek> kepstin: Yeah, I was about to try that, but I had to find a 4k video for my 2560x1440 screen heh
[21:20:31 CEST] <kepstin> you could always playback with cropping if you need to see 1:1 detail of a section of thevideo
[21:20:40 CEST] <gmaciolek> I'm also using a tiling window manager, so, my setup isn't exactly typical. And yeah - good call re: cropping
[21:22:52 CEST] <kepstin> (note also that mpv will by default do scaling to correct aspect ratio if the video doesn't match your screen, tho this isn't a problem with most HD video formats)
[21:26:36 CEST] <SpeakerToMeat> At least vlc complied as long as it wasn't maximized
[21:28:08 CEST] <gmaciolek> Oh my - if I'm processing this without using the split, but just using it once after another (with palettenet and paletteuse), I get an error now!
[21:33:46 CEST] <gmaciolek> here's the error where it bails/quits, near the bottom - http://vpaste.net/NLbA0
[21:34:25 CEST] <kepstin> gmaciolek: there's no possible way to have both palettegen and paletteuse in a single pipeline, that doesn't make sense
[21:34:46 CEST] <gmaciolek> https://i.imgur.com/bhDRe2q.png
[21:34:56 CEST] <furq> kepstin: it works fine if you ignore the fact that it buffers every frame
[21:35:09 CEST] <gmaciolek> kepstin: There are several examples using it, and, I'm having similar issues now without doing it in one pipeline
[21:35:11 CEST] <kepstin> well, if the buffers overflow then you'll lose some video
[21:35:16 CEST] <gmaciolek> Or at least, I'm getting a visible error
[21:35:42 CEST] <furq> i take it you got that png from palettegen
[21:35:45 CEST] <gmaciolek> Take a look at my most recent vpaste and/or the screenshot of the error (so you get color syntax)
[21:36:15 CEST] <gmaciolek> yes, command being ffmpeg -framerate 8 -pattern_type glob "*.jpg" -vf "palettegen" that-file.png
[21:36:33 CEST] <furq> weird
[21:36:34 CEST] <gmaciolek> (I don't probably need the framerate there, I just copied/pasted)
[21:36:49 CEST] <gmaciolek> furq: If you want to try it with the same images, https://kb1ysq.com/ffmpeg/
[21:37:14 CEST] <gmaciolek> I'm a bit too bleary-eyed to try to move this to another machine right now
[21:37:30 CEST] <kepstin> gmaciolek: can you run that with -v verbose so i can see what the filter setup did?
[21:37:46 CEST] <furq> https://clbin.com/gV62t
[21:37:49 CEST] <furq> that's what i use fwiw
[22:13:45 CEST] <gmaciolek> kepstin: http://vpaste.net/xTnJe
[22:18:12 CEST] <gmaciolek> kepstin: with color, as an image: https://i.imgur.com/As78Qy3.png
[22:19:54 CEST] <kepstin> gmaciolek: there's some weirdness there - are your input jpeg files a mix of color and greyscale?
[22:20:58 CEST] <kepstin> it looks like partway through one of the scalers is getting reconfigured from yuv to gray and stuff breaks after that
[22:21:17 CEST] <gmaciolek> hmmm. They're the output from imagemagick's "convert" - scaling images down from 5k x 5k ish to 1080x1080
[22:21:34 CEST] <gmaciolek> I can probably specify more details re: the output format?
[22:22:38 CEST] <furq> you could just do the scaling with ffmpeg
[22:23:07 CEST] <gmaciolek> furq: Yeah, actually - I think I'll do that.
[22:23:23 CEST] <gmaciolek> The current workflow is related to trying to minimize data moved over the wire, but, that's not needed anymore I think
[22:23:56 CEST] <furq> just make sure you scale before split or else it'll use way more memory
[22:24:15 CEST] <gmaciolek> hmm. Looks like the easiest kludge for that is to replace my "convert" with an ln -s heh
[22:26:33 CEST] <SpeakerToMeat> Do you people have an opinion on this book? https://courses.streaminglearningcenter.com/courses/produce-videos-with-ffmpeg-the-beginner-s-course
[22:27:58 CEST] <gmaciolek> Hm. Can I specify a maximum dimension, rather than e.g. a height? if I scale it as e.g. "scale=1080:1080" I assume it'll screw up the aspect ratio if the source isn't square, rather than using it as a max?
[22:28:34 CEST] <furq> 1080:-1 if you know width is always >= height
[22:28:40 CEST] <furq> otherwise you need to get fancier
[22:29:08 CEST] <kepstin> gmaciolek: yes, the 'force_original_aspect_ratio' option to the scale filter allows that
[22:30:39 CEST] <kepstin> you can also play around with using expressions for the height/width, but that options makes it a bit simpler, at least if all your stuff has the same input/output sar.
[22:32:34 CEST] <gmaciolek> I'm going to pull my eues opit iof cI can 't find my glasses - IO don't even know how to change text size in urxvt /:
[22:32:38 CEST] <gmaciolek> be back in a few
[22:34:01 CEST] <SpeakerToMeat> you might need 1080:-2 in some cases
[22:34:07 CEST] <SpeakerToMeat> or -2:1080 as you preffer
[22:40:13 CEST] <kepstin> if you're using the force_original_aspect ratio option, then you'd use force_divisible_by=2 instead
[22:40:48 CEST] <jpb> question on the loop filter - it seems that loop requires a "size" parameter.  is there no option to just loop the entire file?
[22:41:25 CEST] <kepstin> jpb: the loop filter buffers the entire uncompressed video in ram, so that's typically a bad idea
[22:41:41 CEST] <jpb> ah - that's why.  ok
[22:42:01 CEST] <kepstin> jpb: consider using the the -loop input option instead
[22:42:27 CEST] <kepstin> (which causes ffmpeg to seek back and re-read the file from the start when it reaches the end)
[22:42:54 CEST] <jpb> that would be "stream_loop" ?
[22:42:57 CEST] <kepstin> er, wait, let me make sure i have the right option there
[22:43:01 CEST] <kepstin> yeah, stream_loop
[22:43:13 CEST] <jpb> k, thx!
[23:01:33 CEST] <gmaciolek>  furq is there an advantage to your mkgif() vs your mkgif_long() ?
[23:05:03 CEST] <kepstin> gmaciolek: for short videos it should be a bit faster
[23:05:52 CEST] <gmaciolek> kepstin: with a 1080x1080 (we can call it 1920x1080 for ballpark), outputting to a GIF with a whole set of JPEG files as an input, what kind of buffer size are we talking for ~48 frames?
[23:06:06 CEST] <gmaciolek> is that 1080*1080*8*48 bytes?
[23:06:35 CEST] <kepstin> 1080*1080*4*48 assuming it's buffered as bgr0 or something similar
[23:07:16 CEST] <kepstin> i think the buffering between filter elements is capped by frame count rather than memory size, but i don't remember the actual limits offhand
[23:07:33 CEST] <gmaciolek> oh, yes, hm. so ~210 megs for that, so. Fine for most of my VMs, probably not something I want to run on an embedded system, especially if it gets larger/longer
[23:11:52 CEST] <kepstin> huh, looks like there's actually no explicit limit, it'll just go until it runs out of ram or memory space. fun.
[23:22:53 CEST] <gmaciolek> hm.
[23:23:18 CEST] <gmaciolek> actually, scratch that hm - there may be an output size discrepancy, but that may be PEBKAC - my input image set may have changed
[23:27:06 CEST] <gmaciolek> Yep - same file sizes. And, it looks like the processing time is a bit slower on the one with the pipeline / ppm conversion, on the order of 68 seconds vs 49 seconds for my batch of 7 conversions; I think I can take that, for the added wiggle room
[23:37:26 CEST] <gmaciolek> Also, I can write out the ... can I?  I wrote out the input file list to a temp file this time, and had ffmpeg read that, instead of making a bunch of symlinks. But, I have to sort that file anway. I wonder if I can do named pipes to save some disk IO... hmm...
[23:43:49 CEST] <cehoyos> To whoever asked: FFmpeg's mjpeg encoder does not support interlace, so if you put an interlaced image into the encoder, you will get (very) bad quality if you don't increase the bitrate by a very factor / you will get significantly higher bitrate than with similar non-interlaced images. This is not true for encoders that do support interlaced input.
[23:49:01 CEST] <kepstin> nothing stopping you from using the separatefields filter before encoding to mjpeg (and recombining them with weave filter after decoding), but that's unlikely to be compatible with other apps.
[23:53:44 CEST] <gmaciolek> Ever wonder how different the world would be if - for example - the US color TV standard hadn't decided to be backward-compatible with B&W? And they'd decided to drop interlacing too?
[23:54:21 CEST] <pink_mist> surely they've done that with digital tv signals though?
[23:54:37 CEST] <BtbN> most digital TV signals are still interlaced for... bullshit reasons
[23:55:04 CEST] <pink_mist> wow, that's very unfortunate
[23:55:48 CEST] <gmaciolek> good lord
[23:57:37 CEST] <kepstin> if your just set your digital tv encoder to output 60i, then you can send mixed 24p (telecined), 30p (split into fields) and 60i content without any discontinuities/reconfiguration :/
[23:58:46 CEST] <gmaciolek> I mean, these displays aren't using scanlines anymore, generally, and if they are, do they actually interlace their writes?
[23:58:48 CEST] <kepstin> gotta make sure the transitions into commercials which might be different framerate from the show don't have any video dropouts/glitches on cheap hardware.
[23:59:03 CEST] <kepstin> nah, the tvs all run motion-compensated deinterlacing before display
[23:59:07 CEST] <gmaciolek> Because I can't imagine 60i displaying ..
[23:59:09 CEST] <gmaciolek> exactly
[23:59:11 CEST] <kepstin> usually with >1 frame lag
[23:59:16 CEST] <gmaciolek> ughdfshjaf
[23:59:31 CEST] <kepstin> (not that that's an issue with tv stuff, as long as the a/v sync is ok)
[23:59:55 CEST] <gmaciolek> I imagine it's somewhat of an issue if you have multiple TVs in the same space on, but yeah
[00:00:00 CEST] --- Fri Oct 11 2019