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

Thu Aug 18 03:05:02 EEST 2016

[00:00:05 CEST] <CoJaBo> Ah, that'd do it.. but if that's the case, you probably expanded the size of the video stream
[00:00:35 CEST] <CoJaBo> Yeh, I can't recall ever seeing an MKV that wasn't encoded specifically with x264
[00:00:55 CEST] Action: c_14 has several mkvs with all sorts of video codecs
[00:01:24 CEST] <CoJaBo> I have some too, but only when I've stream-copied from some other container.. never seen them made elsewhere like that
[00:01:53 CEST] <CoJaBo> The stupidest thing I've ever seen was someone "compressing" videos using MPEG1
[00:02:19 CEST] Action: c_14 even has an mkv encoded with snow
[00:02:21 CEST] <c_14> Because why not.
[00:03:21 CEST] <CoJaBo> They'd take a ~100MB clip that was 5MB of x264-encoded video and 95MB of uncompressed audio, then compress that to a 50MB clip with no sound that looked horrificly bad
[00:03:29 CEST] <CoJaBo> I can't even.
[00:11:26 CEST] <Bray90820> Honestly I don't see why anyone would even have a need to do something like that
[00:24:43 CEST] <CoJaBo> Bray90820: 50MB size limit
[00:25:03 CEST] <Bray90820> I guess
[00:25:22 CEST] <Bray90820> But I'm good with what I have
[00:29:58 CEST] <Conder> hello, how to identify what preset has been used for x264 encoded file? mediainfo doesnt show it.
[00:32:52 CEST] <durandal_1707> why you use mediainfo?
[00:33:50 CEST] <durandal_1707> unless its exported as metadata you can only guess by watching
[00:35:15 CEST] <CoJaBo> I just use `strings`; if it's there, it'll show up
[00:35:46 CEST] <furq> Conder: http://dev.beandog.org/x264_preset_reference.html
[00:35:54 CEST] <furq> you can figure it out from the mediainfo output and that
[00:36:41 CEST] <furq> subme is unique for each preset so that's a good place to start
[00:37:06 CEST] <Conder> nice, thx
[00:40:59 CEST] <furq> durandal_1707: http://vpaste.net/456Zb
[00:41:04 CEST] <furq> ffprobe doesn't show that afaik
[00:42:49 CEST] <durandal_1707> what ffprobe commands you tried?
[00:42:55 CEST] <furq> -show_streams
[00:43:36 CEST] <durandal_1707> will try tomorrow...
[00:43:48 CEST] <furq> and -show_format since i think that string is container metadata
[01:06:08 CEST] <deweydb> I would like to take a vertical video (9:16) and crop it, and vertical letterbox it to 4:3. right now i've got: -filter_complex "crop=w=iw:h=iw*a:x=0:y=n*(ih-oh)/(819)"
[01:06:15 CEST] <deweydb> where 819 is number of frames.
[01:06:26 CEST] <deweydb> but i don't know how to do the 4:3 part and the black bars on left and right
[01:07:20 CEST] <deweydb> the last part there can be ignored, i guess i should have simplied my example and said my current command is: -filter_complex "crop=w=iw:h=iw*a:x=0:y=0"
[01:16:04 CEST] <furq> durandal_1707: looks like it's part of the video stream
[01:16:06 CEST] <furq> http://vpaste.net/EjdLe
[02:55:25 CEST] <rkantos> how might I pipe ffplay after a youtube stream? I just want to be sure that the stream works.. By the looks of things the stream with colorkey still seems to be ok, but youtube doesn't start streaming with it. cpu usage is under 50%..., so it shouldn't be a performance issue.
[08:11:43 CEST] <jya> hi... when using ffmpeg to truncate a flac file, it doesn't appear to rewrite the metadata to indicate the new size
[08:12:07 CEST] <jya> I did ffmpeg -i input.flac -ss 00:00:30.0 -t 4 -acodec copy flac.flac
[08:12:11 CEST] <jya> am I missing something?
[09:47:57 CEST] <viric> oh. h264 veryslow is not that much slower than medium
[09:48:02 CEST] <viric> x264 I mean
[09:48:36 CEST] <viric> less than 4x slower I'd say
[11:04:11 CEST] <flux> you call 4x slower "not that much slower"?-)
[11:04:26 CEST] <infinarchy> talking about presets. huh?
[11:05:18 CEST] <viric> flux: right. I expected 20x slower :)
[11:05:53 CEST] <flux> viric, are you getting better results?
[11:06:14 CEST] <viric> flux: I'm checking. I was dumb enough to test with different crf :)
[11:06:21 CEST] <flux> of course :)
[11:06:39 CEST] <viric> So, for what I understand, for the same crf I should get a smaller file
[11:06:41 CEST] <flux> the scientific method "always vary more than one parameter to converge faster"
[11:06:55 CEST] <viric> hehe very well stated.
[11:07:33 CEST] <viric> flux: medium crf30  vs  veryslow crf45. The file was definitely smaller :)
[11:08:05 CEST] <viric> I found crf=30 to be the greatest acceptable value (I go for small files)
[11:08:41 CEST] <infinarchy> crf 30. rly? sounds bad.
[11:08:50 CEST] <infinarchy> i prefer higher quality
[11:08:56 CEST] <viric> 2h recordings
[11:09:02 CEST] <infinarchy> so?
[11:09:08 CEST] <infinarchy> i use crf 18
[11:09:20 CEST] <viric> and ethernet bandwidth
[11:09:23 CEST] <viric> I guess :)
[11:09:53 CEST] <infinarchy> check this: http://slhck.info/articles/crf
[11:09:53 CEST] <viric> these are for public download (archive.org)
[11:10:25 CEST] <viric> infinarchy: I know about the crf
[11:10:51 CEST] <flux> small size is fine, but so is the lack of artifacts :)
[11:11:20 CEST] <viric> Right. 30 seems good enough for me. :)
[11:12:17 CEST] <viric> the camera isn't that good either.
[11:18:42 CEST] <viric> moreover, many people are used to the artifacts already.
[11:19:11 CEST] <flux> ..
[11:19:15 CEST] <viric> :)
[11:19:16 CEST] <flux> like the worst reason ever :)
[11:20:06 CEST] <viric> See, we had good TV, interlaced (50fps), in CRT. Then we got those TFT screens, which had worse contrast.
[11:20:24 CEST] <viric> Then we got youtube, and spread of 25fps video, and full of artifacts
[11:20:44 CEST] <viric> Then we got DVB-T mpeg2, that gave even more artifacts than what people got in DivX.
[11:21:04 CEST] <viric> with HD flat screens.
[11:21:26 CEST] <viric> And when we got FullHD and h264 DVB-T, we get everyone recording with mobile phones and rolling shutter cameras
[11:21:47 CEST] <bencoh> "'good' TV" huhu
[11:21:49 CEST] <viric> with heavy video compression in social networks, full of artifacts
[11:22:06 CEST] <viric> So
[11:22:14 CEST] <bencoh> we had another kind of artifacts back then :)
[11:22:15 CEST] <viric> (and noone buying bluerays)
[11:22:56 CEST] <viric> bencoh: right, but lack of square pixels made the low resolution look like slighly out of focus and little more.
[11:23:23 CEST] <bencoh> bleeding colors, blooming, not-so-good definition/resolution, cropped picture, ...
[11:23:24 CEST] <viric> and 50fps was great. I love the 50fps
[11:23:52 CEST] <viric> bencoh: that's more for low-band vhs, isn't it?
[11:23:57 CEST] <bencoh> dont get me wrong, I still play arcade games and wish I kept my CRT or bought a multisync/15k screen, but ...
[11:24:09 CEST] <viric> :)
[11:24:26 CEST] <viric> The bw of PAL was quite good. But VHS was quite below it
[11:25:18 CEST] <bencoh> I lived in the PAL world, but it still wasnt that good
[11:28:10 CEST] <viric> better than a rolling-shutter mobile phone recording at 25fps without stabilizer.
[11:28:19 CEST] <bencoh> agreed :)
[12:29:41 CEST] <viric> furq: long ago I made some work regarding jpeg and its artifacts
[12:30:11 CEST] <viric> furq: more artifacts gave the impression of a sharper image
[12:30:29 CEST] <viric> furq: so, reducing the artifacts efectively was perceived as lack of sharpness
[13:59:59 CEST] <kepstin> viric: yeah, x264's psy optimizations make use of that effect - for noisy/high detail video areas at low bitrate, it'll put artifacts there rather than attempt to encode the detail accurately, to give the impression of more detail.
[14:05:51 CEST] <viric> kepstin: great
[14:12:21 CEST] <kdehl> So, I have encoded a yuv file to H.264 using OpenH264, and now I try to decode the H.264 file back to YUV. I get three buffers, a Y, U and V. But they don't seem to make much sense. When I save them to separate files, this is what I get: http://dose.se/~madman/hex/
[14:13:00 CEST] <kdehl> First, the Y part seems to be padded with a lot of zeros for each line.
[14:13:31 CEST] <kdehl> (It's the Static 152x100 yuv file that comes with the package that I am playing with.)
[14:14:42 CEST] <kdehl> Anyone knows OpenH264?
[14:16:26 CEST] <kepstin> kdehl: it looks like it's using a stride that's longer than the width of the image (stride 0xC0, while the image width is 0x98)
[14:16:35 CEST] <kepstin> so you just have to account for that.
[14:16:53 CEST] <kepstin> the stride should be given to you somehow...
[14:16:58 CEST] <kdehl> It does, doesn't it.
[14:17:10 CEST] <kdehl> The only info I can find about the output is the width and height.
[14:18:37 CEST] <kdehl> What is the point of strides anyway?
[14:18:56 CEST] <kdehl> I can imagine HBlank and the likes on CRT TVs, but nowadays?
[14:19:27 CEST] <kepstin> efficiency, it makes it so the start of a line is on a nice even byte boundary, so still like sse/avx can operate on aligned values
[14:20:11 CEST] <kdehl> Yeah okay. That makes sense.
[14:20:24 CEST] <kdehl> C0 is a pretty even number.
[14:20:32 CEST] <kepstin> ffmpeg's "crop" filter makes use of it - it doesn't actually change the image data, just the start pointer, line count, and image width/stride values.
[14:20:35 CEST] <kdehl> I guess.
[14:20:38 CEST] <furq> yeah it would be crazy if we were still using things that only made sense on old TVs
[14:20:46 CEST] <kdehl> Ah.
[14:21:02 CEST] <kdehl> furq: Yeah really... Like interlacing... heh.
[14:21:08 CEST] <furq> i was thinking more of yuv but sure
[14:21:14 CEST] <viric> what is better than interlacing, nowadays? :)
[14:21:20 CEST] <furq> not interlacing
[14:21:25 CEST] <viric> I like 50fps
[14:21:28 CEST] <viric> 50fps progressive?
[14:21:33 CEST] <furq> sure
[14:21:50 CEST] <kdehl> furq: Ah. Heh. :)
[14:21:56 CEST] <viric> isn't it more cpu load than just interlacing?
[14:22:06 CEST] <durandal_1707> 120 fps
[14:22:15 CEST] <furq> i imagine it's less cpu load than running a deinterlacer
[14:22:24 CEST] <furq> it's certainly less than running a good one
[14:22:31 CEST] <kdehl> YUV makes sense though, doesn't it. Like chroma subsampling. Or maybe there are better ways of doing it, I dunno.
[14:22:35 CEST] <kdehl> I just learned about it. :)
[14:22:39 CEST] <viric> furq: the nvidia hw deinterlacer is quite good
[14:23:05 CEST] <viric> I wish intel hw had it
[14:23:10 CEST] <kepstin> kdehl: the openh264 api should be giving you stride, https://github.com/cisco/openh264/blob/master/codec/api/svc/codec_api.h#L358 - you pass in a int pointer that it'll fill with the stride value
[14:23:14 CEST] <furq> i'm using a slower-than-realtime one for dvd ripping, so i don't want to hear about interlacing right now
[14:23:20 CEST] <viric> hehe
[14:23:21 CEST] <furq> that's slower than realtime on 8 threads
[14:23:28 CEST] <viric> furq: what one?
[14:23:30 CEST] <furq> qtgmc
[14:23:33 CEST] <viric> furq: do you store 50fps?
[14:23:39 CEST] <furq> depends on the source, but usually
[14:23:41 CEST] <viric> ok
[14:23:55 CEST] <kepstin> kdehl: looks like there's some newer more recommended apis that'll store it in a picture information structureof some sort
[14:23:56 CEST] <viric> double fps is far from double file size, in x264?
[14:24:06 CEST] <furq> at slow settings it doesn't make much difference
[14:24:13 CEST] <furq> i imagine at ultrafast it would be close to twice the size
[14:24:16 CEST] <viric> ah ok
[14:24:37 CEST] <viric> furq: what image height do you store? full frame, or only field height?
[14:24:43 CEST] <furq> full frame
[14:24:47 CEST] <viric> I guess full frame, with the good deinterlacer
[14:24:48 CEST] <viric> k
[14:24:49 CEST] <viric> ok
[14:25:00 CEST] <furq> http://avisynth.nl/index.php/QTGMC
[14:25:00 CEST] <viric> I will try for the 50fps; I thought it would be double size
[14:25:13 CEST] <kdehl> kepstin: Thank you! I haven't seen that one. I just followed the example in the comments in the beginning of that very file.
[14:25:16 CEST] <furq> it's based on nnedi3 which is available in libavfilter, but it's single-threaded in libavfilter
[14:25:18 CEST] <viric> furq: do you use avisynth?
[14:25:22 CEST] <furq> i use vapoursynth
[14:25:30 CEST] <furq> avisynth-mt really enjoys crashing
[14:25:38 CEST] <furq> which is annoying after 7 hours of encoding
[14:26:00 CEST] <viric> aha
[14:26:08 CEST] <viric> furq: I wanted to use an avisynth piece...
[14:26:23 CEST] <viric> I can't remember the name. For the VHS bad hclock
[14:26:30 CEST] <kdehl> kepstin: BTW, do you know whether DecodeFrameNoDelay decodes all frames in the H.264 buffer or does it only decode one frame at a time?
[14:26:31 CEST] <viric> would that work in vapoursynth?
[14:26:38 CEST] <furq> no idea, i've never touched vhs stuff
[14:26:42 CEST] <furq> it depends if someone has ported the plugin
[14:26:53 CEST] <furq> i've only ever really used avisynth for qtgmc and srestore
[14:27:00 CEST] <kepstin> kdehl: no idea, I only read the header just now to find where the stride is stored :)
[14:27:06 CEST] <kdehl> Maybe it ought to be DecodeFrameSNoDelay. But I don't trust the Chinese to distinguish between singular and plural. :)
[14:27:13 CEST] <kdehl> kepstin: Ah okay.
[14:27:50 CEST] <viric> why isn't qtgmc in ffmpeg?
[14:28:16 CEST] <furq> iirc libavfilter doesn't do frame multithreading so it'd be pretty useless
[14:28:31 CEST] <furq> nnedi on its own is unusably slow with one thread
[14:28:42 CEST] <viric> aha
[14:28:50 CEST] <durandal_1707> it have slice threading
[14:29:15 CEST] <furq> i got the impression that wasn't used by much
[14:29:18 CEST] <kdehl> kepstin: But how does that work in general though? Say I want to decode just _one_ frame at a time and send a H.264 buffer to the decoder, how does the decoder know where to start reading the buffer? As I understand one frame can depend on other frames (P and B frames or whatever?).
[14:29:34 CEST] <furq> wasn't/couldn't be
[14:30:38 CEST] <furq> qtgmc also depends on a bunch of other filters which aren't in libavfilter, like fft3d/dfttest/knlmeanscl
[14:31:45 CEST] <kepstin> kdehl: hmm. openh264 is baseline only, right? that means it doesn't have B frames
[14:32:00 CEST] <viric> ok
[14:32:05 CEST] <kepstin> kdehl: without B frames, it can do decoding with one-frame in, one frame out
[14:32:19 CEST] <kdehl> kepstin: Aha.
[14:32:23 CEST] <kepstin> (it'll internally store buffers with info needed for predicted frames)
[14:32:30 CEST] <kdehl> Right.
[14:32:35 CEST] <kdehl> Well, that makes sense.
[14:33:54 CEST] <kepstin> with a full h264 decoder, there's a decoding delay - you may have to feed multiple frames in before you get a frame out
[14:34:16 CEST] <kdehl> Right.
[14:34:19 CEST] <kepstin> depending on the input stream, of course
[14:34:24 CEST] <kdehl> Yeah.
[14:34:43 CEST] <kdehl> Well this file was also encoded with OpenH264 so I guess I don't have to worry about that.
[14:34:46 CEST] <kdehl> Oh shit.
[14:35:04 CEST] <kepstin> but openh264 was written by cisco for video conferencing, so encoding modes that don't add extra delay were preferred
[14:35:13 CEST] <kdehl> I just realized that later I might get a stream I need to decode that could have been encoded with other codecs.
[14:35:44 CEST] <kdehl> Hm. Is this true for all video conferencing H.264 streams?
[14:35:52 CEST] <kepstin> x264's "-tune zerolatency" switches it to a mode where frames are 1-in-1-out
[14:36:19 CEST] <kepstin> it should be, for latency reasons. But some people might have messed it up and used bad settings :/
[14:36:19 CEST] <kdehl> Well I kinda have to use OpenH264.
[14:36:26 CEST] <kdehl> Right.
[14:36:29 CEST] <kdehl> Hm.
[14:36:35 CEST] <kdehl> Does that mean OpenH264 can't handle it?
[14:36:48 CEST] <kdehl> The decoding of that stream, that is.
[14:36:55 CEST] <kepstin> openh264 can't handle anything other than baseline (or maybe constrained baseline)
[14:37:27 CEST] <kdehl> Hm. Strange that the guy who started this project chose to use this codec then.
[14:37:35 CEST] <kdehl> Was years ago though. Maybe he had his reasons.
[14:38:05 CEST] <kdehl> It's for a video call simulator for 3G and 4G telephony.
[14:38:13 CEST] <kepstin> well, the only reason to use openh264 is the cisco patent license
[14:38:34 CEST] <kepstin> if it wasn't for that, ffmpeg's decoder and x264 encoder are rather better
[14:38:57 CEST] <kdehl> I see.
[14:39:13 CEST] <kdehl> Strange though, I thought those patents only mattered in the States.
[14:39:22 CEST] <kdehl> I'm in Europe.
[14:40:12 CEST] <kepstin> I'll leave that up to you and your lawyers to decide :)
[14:40:36 CEST] <kdehl> Hehe. Yeah.
[14:40:55 CEST] <furq> a lot of people continue to live in america for some reason
[14:43:15 CEST] <kdehl> Yeah, and I'm going to be one more.
[14:51:44 CEST] <kdehl> kepstin: There doesn't seem to be any stride in the U and V buffers though, could that be right?
[14:51:59 CEST] <DHE> kepstin: zerolatency does other things as well. even without b-frames x264 can buffer frames for bitrate prediction purposes. zerolatency takes that away.
[14:52:20 CEST] <kdehl> The stride is 40 bytes of the Y buffer, then it ought to be 10 bytes per U and V buffer, no?
[14:52:47 CEST] <kepstin> kdehl: if the u/v have a stride, it should be indicated separately
[14:52:57 CEST] <kdehl> kepstin: Aha.
[14:53:17 CEST] <kdehl> kepstin: That makes sense, since the buffers are paresed separately.
[14:53:21 CEST] <kdehl> And need to be aligned separately.
[14:53:46 CEST] <kdehl> I'll try to figure out how to find them in the structs.
[14:54:07 CEST] <kdehl> BTW, shouldn't it be possible to just copy the Y buffer and let U and V be zero?
[14:54:13 CEST] <kdehl> I'll still get a video, right?
[14:54:27 CEST] <kepstin> using the Y only will give you a B&W video, yeah
[14:54:34 CEST] <kdehl> Right.
[14:54:39 CEST] <kdehl> Excellent.
[14:54:41 CEST] <kdehl> I'll try that first.
[14:55:17 CEST] <kepstin> (need to interpret that either as single-plane B&W or set the u/v to contain all 0x80 tho)
[14:55:29 CEST] <kepstin> unless you like weird colors :)
[14:55:43 CEST] <kdehl> Heh. I don't mind, this is just for testing.
[14:55:48 CEST] <kdehl> What's magical about 0x80?
[14:55:54 CEST] <kdehl> I see a lot of those.
[14:56:02 CEST] <kepstin> it's the middle/neutral value for u/v
[14:56:59 CEST] <kdehl> Hm. Mkay.
[14:57:05 CEST] <kepstin> if you set both to 0 you'll get red
[14:57:25 CEST] <viric> what is there FOSS for videoconferencing, beyond linphone? (in C/C++)
[14:57:44 CEST] <viric> telepathy for gajim maybe... never tried.
[14:57:52 CEST] <viric> All I tried was horrible.
[14:58:06 CEST] <viric> qtox too.
[14:58:08 CEST] <kepstin> basically, you can think of the U/V as signed numbers, where 0x80 is 0, less is negative, more is positive. It's kind of a color bias thing
[14:58:39 CEST] <kdehl> Huh. Okay.
[14:59:23 CEST] <kdehl> Alright, well I'll try not to dig into the details. It's hard, but my boss gets annoyed when I spend an entire day reading books and Wikipedia. :-/
[15:01:04 CEST] <kepstin> you can sort of think of e.g. U as the 'blueiness', where 80 is neutral (like in grey), lower is unblue, higher is more blue. Similarly, V is 'rediness'. Not exactly correct, but it gives an idea more or less :)
[15:01:29 CEST] <kdehl> Interesting.
[15:01:39 CEST] <kdehl> Now you make me want to read up on it.
[15:01:50 CEST] <kdehl> Boss did go home early today...
[15:02:17 CEST] <kepstin> it's really just 2 arbitrary axis defining a color plane. not that exciting.
[15:02:40 CEST] <kdehl> Oh.
[15:02:45 CEST] <kdehl> Now I even get it.
[15:03:43 CEST] <kdehl> So that is what that color plane means on Wikipedia's page on YUV.
[15:04:56 CEST] <JEEB> planar = separate buffers for the parts, packed = stuff is together. and then you have mixed cases like NV12 (which GPUs seem to like)
[15:05:10 CEST] <kdehl> Hm. Is it just me, or is V=0, U=+0.5 less blue than V=-0.5 and U=+0.5
[15:06:05 CEST] <kepstin> kdehl: the color space is defined based on the locations of the RGB primaries, so V=0 U=max should mean only the 'B' or RGB is lit up
[15:06:15 CEST] <kepstin> well, that's not exactly true
[15:06:18 CEST] <kdehl> JEEB: So what OpenH264 returns is "planar" (since there are three buffers), but a YUV file contains "packed" data?
[15:06:33 CEST] <kepstin> there's some wonkiness and a matrix calculation needed
[15:06:44 CEST] <JEEB> depends on how the data is handled
[15:06:47 CEST] <kdehl> Yeah I saw that.
[15:07:02 CEST] <kdehl> I hated linear algebra. Took me like five years to pass that exam.
[15:07:29 CEST] <kepstin> kdehl: the colors on the U/V plane don't really correspond to anything - they were picked so as to minimize redundant information (i.e. have as much detail as possibly in Y, and as little in U/V)
[15:07:46 CEST] <kepstin> kdehl: so that U/V could be subsampled and still look ok
[15:07:52 CEST] <kdehl> kepstin: Right.
[15:08:23 CEST] <kepstin> kdehl: as a result of this, most of the 'G' of RGB is actually stored in Y rather than either of the U/V planes, since humans are more sensitive to it.
[15:09:10 CEST] <kdehl> And B is the other way around? Since we're less sensitive to that, IIRC.
[15:09:55 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/colorspace.h;h=cc27f382218caa8ab35594505e44acf81fcab2ab;hb=1f77e634bb838f71ff21923b5e9fe3104c831c52#l44
[15:09:57 CEST] <kepstin> yeah. There's some coefficients defined in that wikipedia article
[15:10:04 CEST] <JEEB> I added this lately for BT.709
[15:10:18 CEST] <JEEB> terrible macros, but might be simpler than linear algebra:)
[15:10:55 CEST] <kepstin> those macros look a lot like linear algebra to me ;)
[15:11:58 CEST] <JEEB> and yeahm
[15:12:14 CEST] <JEEB> they are terrible but I just added one with the correct BT.709 coeffs
[15:12:27 CEST] <JEEB> so that the blu-ray subpictures would be correct finally :)
[15:15:43 CEST] <kepstin> one of the hilarious parts of YUV (and YPbPr) is that you still get kinda ok looking human skin tones with only the V/Pr. One of my friends had this Pb cable come loose on component video and didn't realize for quite a while :)
[15:16:09 CEST] <kdehl> Hehe.
[15:18:50 CEST] <viric> furq: what is the vapoursynth output for your deinterlacing? Do you later use ffmpeg?
[15:18:55 CEST] <viric> (for "final" encoding)
[15:18:58 CEST] <furq> yeah
[15:19:10 CEST] <viric> what is that middle format? a big file?
[15:19:19 CEST] <furq> it's rawvideo
[15:19:23 CEST] <furq> you can pipe it stright into ffmpeg
[15:19:37 CEST] <furq> http://www.vapoursynth.com/doc/vspipe.html
[15:19:50 CEST] <viric> ah, no file. ok
[15:19:55 CEST] <viric> and what about sound?
[15:20:00 CEST] <furq> i mux that in separately
[15:20:42 CEST] <viric> another pipe
[15:20:43 CEST] <viric> ?
[15:20:50 CEST] <furq> http://vpaste.net/ZEWaH
[15:21:15 CEST] <viric> ah, directly from the dvd files
[15:21:34 CEST] <kdehl> Aha. There are two strides. I assume it's width and height of the frame.
[15:21:38 CEST] <viric> what is that input file syntax ${...} ?
[15:21:53 CEST] <furq> https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html
[15:21:53 CEST] <viric> ah, bash
[15:21:59 CEST] <viric> ok
[15:22:00 CEST] <furq> it strips off the file extension
[15:22:22 CEST] <viric> I use to run $(basename $m .extension)
[15:22:27 CEST] <viric> good
[15:24:31 CEST] <kdehl> Weird. The first value is 224, the other is 112. That doesn't seem to be right.
[15:43:32 CEST] <viric> What do you think of 'melt'?
[15:43:47 CEST] <viric> https://mltframework.org/
[15:57:49 CEST] <viric> furq: can you share your vapoursynth script?
[15:57:56 CEST] <viric> for deinterlacing dvd
[15:59:00 CEST] <furq> http://vpaste.net/HRsf5
[16:00:28 CEST] <furq> https://bitbucket.org/mystery_keeper/vapoursynth-editor
[16:00:31 CEST] <furq> you can use that to preview scripts
[16:00:36 CEST] <viric> oh nice
[16:00:44 CEST] <viric> ah it is a python thing
[16:00:54 CEST] <furq> yeah
[16:00:59 CEST] <furq> it's slower than avisynth but less crash-prone
[16:01:07 CEST] <viric> good.
[16:01:12 CEST] <furq> shame they didn't write it in luajit really
[16:01:26 CEST] <viric> is .d2v in the dvd?
[16:01:35 CEST] <furq> no
[16:01:38 CEST] <furq> that's from dgindex
[16:01:50 CEST] <viric> it's quite a constellation of pieces at work
[16:02:01 CEST] <durandal_1707> so why you don't use hqdn3d?
[16:02:16 CEST] <furq> it's not one of the supported denoisers in qtgmc
[16:02:28 CEST] <furq> i was also under the impression it was lower quality than nlmeans
[16:02:52 CEST] <viric> I worked a few years with the writer of hqdn3d
[16:02:58 CEST] <durandal_1707> that's just for anime
[16:03:58 CEST] <furq> that's not what i've read
[16:05:58 CEST] <viric> the writer of hqdn3d wrote it thinking of vhs, I think
[16:06:05 CEST] <viric> very long ago.
[16:07:36 CEST] <furq> i normally don't denoise anyway
[16:07:46 CEST] <furq> but this source is pretty dirty
[16:35:38 CEST] <magusx> Hello - is anyone here?
[17:09:18 CEST] <maziar> I have a HDMI camera and i connect the camera to my system over HDMI, now i want to stream from my system to all person on my lan, how should i do it ?
[17:12:19 CEST] <nonex86> capture the stream with ffmpeg and stream it with ffserver perhaps?
[17:15:53 CEST] <DHE> use of ffserver is discouraged. try something else like nginx-rtmp, or multicast. what you do will depend on your network and the viewers' clients
[17:20:04 CEST] <furq> if it's on a lan then you could use the hls muxer and an httpd
[17:20:17 CEST] <nonex86> yeah, nginx with rtmp module good too
[17:21:15 CEST] <DHE> I like multicast if it's possible. setting it up tends to require more skill than most users fully understand, unfortunately.
[17:25:41 CEST] <kdehl> kepstin: You still here?
[17:25:52 CEST] <kdehl> kepstin: I can't make any sense of my outputs still.
[17:27:57 CEST] <kdehl> I've added an "util_output.hex.txt" to http://dose.se/~madman/hex/
[17:28:43 CEST] <kdehl> It is a hexdump of the output generated by the h264dec utility that comes with OpenH264, so it ought to be legitimate.
[17:29:16 CEST] <kdehl> But the offsets are completely different from the ones the ones I get from the library.
[17:30:39 CEST] <kdehl> My utility reports correctly that the h264 file has a resolution of 152x100 and that it generates a yuv output with a stride of 40.
[17:32:03 CEST] <kdehl> If you look at the pattern of y.hex.txt it seems like each line is 184 bytes long (plus a stride of zeros of 40), which makes it 224.
[17:32:23 CEST] <kdehl> Sorry, I meant that my program reports a stride of 224. Which seems to be correct.
[17:32:29 CEST] <kdehl> And YUV420 format.
[17:32:57 CEST] <kdehl> But where do those 184 bytes per row come from?
[18:16:09 CEST] <Mavrik> kdehl, hmm, 152x100 file kinda shouldn't have a stride of 40
[18:16:22 CEST] <Mavrik> It should have a stride of 152*bit depth + any padding
[18:19:13 CEST] <kepstin> kdehl: the decoder is allowed to put data in the padding that you're supposed to just ignore
[19:19:56 CEST] <kdehl> Mavrik: Sounds somewhat excessive, doesn't it?
[19:20:11 CEST] <Mavrik> Excessive?
[19:20:15 CEST] <Mavrik> Which part? :)
[19:20:30 CEST] <kdehl> Mavrik: Sorry, misunderstanding.
[19:20:34 CEST] <kdehl> I just got home. Heh.
[19:20:53 CEST] <kdehl> Mavrik: It's 224, not 40. :)
[19:21:19 CEST] <kdehl> kepstin: It
[19:21:40 CEST] <kdehl> kepstin: It's strange though, it seems like the first line is smaller than the rest.
[19:21:49 CEST] <kdehl> Anyway, I'll look at it when I'm back at work tomorrow.
[19:23:22 CEST] <kepstin> kdehl: I bet looks like it uses 16px on either side of the real image for decoder use
[19:24:44 CEST] <kdehl> kepstin: You mean it pads the frame both left and right?
[19:25:55 CEST] <kepstin> Yeah, but the start pointer you get will be the start of the real image. Explains why first line appears shorter
[19:31:26 CEST] <wallbroken> not clear if is better to use 32 or 64 bit version of ffmpeg, anybody have a good answer?
[19:32:12 CEST] <kdehl> kepstin: I wasn't aware of a start pointer.
[19:32:21 CEST] <kdehl> kepstin: I'll look for it tomorrow.
[19:32:35 CEST] <DHE> 64 bit should have access to features like AVX[2] if you have them. I don't think those are available on 32 bit systems
[19:33:33 CEST] <wallbroken> but the product file have some difference?
[19:34:39 CEST] <DHE> there may be minute floating point variances when using different calculation methods or operations
[19:35:47 CEST] <wallbroken> both the output will work in the same way on all the devices?
[19:37:09 CEST] <kepstin> the architecture of the ffmpeg executable has no relation to the file formats of the output files
[19:41:01 CEST] <DHE> if that's your concern, don't worry. h264 is h264, etc.
[19:55:59 CEST] <wallbroken> no, i'm just trying to figure out which one is better to use
[19:56:27 CEST] <furq> haven't you been trying to figure this out for about two weeks now
[19:56:28 CEST] <furq> just pick one
[19:56:53 CEST] <kepstin> the 64bit version is likely to be marginally faster if you can run it; if you really care, test them both and compare.
[20:01:26 CEST] <wallbroken> kepstin: i've done
[20:01:39 CEST] <wallbroken> i've produced the same with both 32 and 64
[20:01:55 CEST] <wallbroken> and i have no clue on which one to pick
[20:02:03 CEST] <kepstin> which one encoded faster?
[20:02:11 CEST] <wallbroken> and i don't want to pick one of them with throing a coin
[20:02:30 CEST] <wallbroken> i don't remember, but i don't care about the encoding speed
[20:02:49 CEST] <kepstin> if they're about the same, the 64bit version should have better memory address randomization, which might be handy if you're encoding user-provided content (security improvement)
[20:02:52 CEST] <wallbroken> i just want to focus on the outputs
[20:03:21 CEST] <kepstin> the output should be identical between the two of them, modulo any tiny differences due to floating point rounding
[20:03:33 CEST] <kepstin> (and you can't say one is better than the other in that case, they're just different)
[20:04:21 CEST] <wallbroken> so, it should be a little bit better the 64bit one?
[20:18:13 CEST] <haasn> Does libavcodec have known issues scaling to multiple cores (more than 4) for e.g. HEVC decoding?
[20:18:26 CEST] <haasn> Can the codec perhaps not be parallelized further by design?
[20:33:58 CEST] <Earthnail> Hi there. I'm decoding audio files, and noticed that when specifying the -t option to set a stop time, that it sometimes reads a tiny bit less than what I specified. For example, with `-t 5`, it reads 4.99 seconds of audio. Is there a way to make ffmpeg read the exact number of seconds?
[20:34:59 CEST] <durandal_170> yes by using strum filter
[20:35:13 CEST] <durandal_170> *atrim
[20:35:46 CEST] <Earthnail> durandal_170: but that's not very efficient, is it?
[20:36:34 CEST] <durandal_170> it comes with price
[20:42:15 CEST] <Earthnail> Unfortunately, atrim still doesn't work:
[20:42:18 CEST] <Earthnail> ffmpeg -accurate_seek -i tests/data/audio/example_mono.ogg -f s16le -ac 1 -to 6.000000 -af atrim=0.000000:5.000000 -
[20:43:30 CEST] <relaxed> omit -accurate_seek and -to 6.000000
[20:44:40 CEST] <Earthnail> ffmpeg -i tests/data/audio/example_mono.ogg -f s16le -ac 1 -af atrim=end=5.000000 -
[20:44:42 CEST] <Earthnail> same problem
[20:46:05 CEST] <Earthnail> If I specify end_sample, it works. Unfortunately, I don't know the sample_rate when executing the command.
[20:47:46 CEST] <Earthnail> Ah, now it's getting interesting: end_sample works, but end_pts does not work.
[20:48:11 CEST] <kepstin> hmm. the issue is that the pts (used by -to, etc.) is per-packet, and a packet contains some number of samples
[20:48:44 CEST] <kepstin> in theory, atrim could be more accurate, since it knows the sample rate so it can calculate exact times :/
[20:49:56 CEST] <Earthnail> Could the problem be that the time stamps in the file are off? That would explain why end_sample= works, since it simply reads 5*44100 samples, whereas end_pts= doesn't work since the 5 second mark is a bit earlier.
[20:50:25 CEST] <pgorley> can h263p be accelerated with ffmpeg, or is it only h263?
[20:51:17 CEST] <kepstin> Earthnail: hmm. I dunno about ffmpeg's internal representation, but in the ogg format audio packets are given the timestamp of the *last* sample in the packet
[20:51:34 CEST] <kepstin> Earthnail: so I could see it behaving that way
[20:51:46 CEST] <Earthnail> hmm. Well, I just tried duration=5 instead, but that again gave me the wrong result
[00:00:00 CEST] --- Thu Aug 18 2016