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

[burek]

[00:05:54 CEST] <Demon_Fox> Can webm be decoded by an mkv library?
[00:06:06 CEST] <nicolas17> demuxed, yes, probably
[00:06:17 CEST] <nicolas17> you still need to decode the vp8/vp9/whatever video stream in it
[00:07:22 CEST] <c_14> libavformat uses the same code to demux both matroska and webm, so yes (though webm-dash is special)
[00:08:36 CEST] <Demon_Fox> I'm guessing it's because they're almost the same format
[00:08:40 CEST] <Demon_Fox> except for different branding
[00:08:53 CEST] <Demon_Fox> As in, file ID at the start of the file
[00:20:08 CEST] <Demon_Fox> Out of curiosity, did vp9 actually live up to the promise of HECV performance in terms of bitrate and quality?
[00:20:39 CEST] <wallbroken> c_14, ffmpeg on windows has something different?
[00:20:41 CEST] <wallbroken> is crapped?
[00:20:50 CEST] <c_14> Demon_Fox: https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/
[00:20:55 CEST] <c_14> wallbroken: hmm?
[00:21:10 CEST] <wallbroken> is called "Zanoe"
[00:21:56 CEST] <c_14> Zeranoe? That's just the guy who provides Windows Builds
[00:22:03 CEST] <c_14> of ffmpeg
[00:22:31 CEST] <Demon_Fox> Thanks c_14
[00:22:48 CEST] <wallbroken> ok
[00:22:56 CEST] <Demon_Fox> AVC is h.264 and HEVC is h.265, iirc
[00:23:20 CEST] <c_14> yes
[00:23:32 CEST] <c_14> Advanced Video Coding and High Efficiency Video Coding
[00:23:52 CEST] <nicolas17> there was an "MPEG4" before AVC, right?
[00:24:10 CEST] <nicolas17> even though confusingly .mp4 usually has an h264 stream
[00:24:12 CEST] <Demon_Fox> Thanks again c_14
[00:24:36 CEST] <furq> nicolas17: https://en.wikipedia.org/wiki/MPEG-4_Part_2
[00:24:49 CEST] <Mavrik> nicolas17, AVC is MPEG4 :P
[00:24:50 CEST] <nicolas17> that's the one
[00:24:51 CEST] <c_14> nicolas17: AVC is actually MPEG-4 Part 10. But yes, there's a lot of stuff in MPEG4
[00:24:52 CEST] <furq> avc is mpeg-4 part 10
[00:24:53 CEST] <nicolas17> and how does it compare?
[00:25:04 CEST] <furq> part 2 is divx/xvid
[00:25:14 CEST] <furq> it compares badly
[00:26:13 CEST] <Demon_Fox> mpeg4 part 2 is h.263
[00:26:18 CEST] <c_14> Unless you're rather fond of artifacts and blockiness
[00:26:41 CEST] <furq> Demon_Fox: not quote
[00:26:44 CEST] <furq> quite
[00:27:40 CEST] <Demon_Fox> I was unaware
[00:27:52 CEST] <Demon_Fox> h.262 is mpeg2 if I'm not mistaken
[00:29:33 CEST] <Mavrik> Those standards may or may not exactly conform to other similar standards :)
[00:29:48 CEST] <Mavrik> Or better said, those namings :)
[00:30:00 CEST] <Demon_Fox> The naming system sucks
[00:31:15 CEST] <furq> well soon we'll all be watching mpeg-h part 2
[00:32:50 CEST] <Demon_Fox> mpeg-h?
[00:33:09 CEST] <furq> the h stands for hyperactive
[00:33:27 CEST] <Demon_Fox> https://en.wikipedia.org/wiki/MPEG-H
[00:33:33 CEST] <Demon_Fox> I see 13 parts listed
[00:33:42 CEST] <nicolas17> yeah but it's like
[00:34:05 CEST] <nicolas17> video, audio, containers, conformance testing, reference software...
[00:34:10 CEST] <c_14> furq: each scene isn't allowed to last longer than 0.2 seconds?
[00:34:18 CEST] <furq> https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format
[00:34:29 CEST] <furq> this is a really long wikipedia page for something i've never even heard about anyone using
[00:34:36 CEST] <nicolas17> :D
[00:34:39 CEST] <furq> or even heard mentioned outside of this wikipedia page
[00:34:53 CEST] <nicolas17> the fanciest one I heard of is BPG
[00:34:54 CEST] <Demon_Fox> Besides, we have webp, which is free
[00:34:56 CEST] <nicolas17> (and the results are impressive)
[00:35:03 CEST] <furq> yeah this looks basically the same as bpg
[00:35:13 CEST] <furq> except this one has nothing to do with fabrice bellard and therefore in this channel is worse
[00:35:39 CEST] <nicolas17> lol
[00:35:41 CEST] <furq> also bpg actually seems to exist in the world, which i consider a feature
[00:36:06 CEST] <nicolas17> lol "Extensible to other coding formats"
[00:36:14 CEST] <nicolas17> as if that was a positive feature for an image format
[00:36:17 CEST] <furq> it'd be nice if webp had thought of that tbh
[00:36:27 CEST] <furq> since it's now stuck with vp8 intra forever
[00:37:06 CEST] <furq> and it's not like anyone except them has bothered integrating a decoder into their products
[00:37:08 CEST] <nicolas17> I dunno, does it make sense to have a .webp and not know if your software will be able to read it or not, because it could use one of several wildly different codecs?
[00:37:19 CEST] <furq> it would make less sense if it had been widely adopted
[00:37:32 CEST] <furq> as it is they might as well have kept it in beta, which would give them the chance to upgrade it
[00:37:46 CEST] <nicolas17> both gzip and bzip2 have provisions for different compression formats in the same "container" :)
[00:38:47 CEST] <furq> with all that said bpg and heif have got even less chance of being adopted by firefox
[00:47:21 CEST] <Mavrik> furq, hmm, why wouldn't webp be widely adopted
[00:47:22 CEST] <Mavrik> ?
[00:47:49 CEST] <furq> it hasn't been
[00:48:03 CEST] <furq> i know mozilla are against it because they're probably still mad about chrome not supporting apng
[00:48:17 CEST] <nicolas17> lol
[00:48:20 CEST] <c_14> has any image format been widely adopted since jpeg and png?
[00:48:42 CEST] <furq> apple are against it because they are best friends with google
[00:48:44 CEST] <Mavrik> I mean, it's very likely you're looking at webps served from CDNs if you use Chrome :)
[00:48:49 CEST] <furq> and ie/edge probably just haven't got around to it yet
[00:48:52 CEST] <nicolas17> furq: they are?
[00:49:04 CEST] <nicolas17> furq: maybe the browser people...
[00:49:19 CEST] <furq> the point was that google own the only product with a webp decoder in widespread use
[00:49:29 CEST] <furq> so it wouldn't be earth-shattering if they messed with it
[00:49:38 CEST] <nicolas17> generally yeah
[00:49:44 CEST] <nicolas17> I mean there are several products using webp "internally"
[00:49:55 CEST] <furq> i know ffmpeg has a webp decoder but i can't imagine more than four people have used it
[00:50:17 CEST] <nicolas17> but browsers or other things accepting "public" content... yeah
[00:50:17 CEST] <furq> and i'd have thought it just uses libvpx anyway
[00:50:59 CEST] <furq> nvm it's libwebp isn't it
[00:51:01 CEST] <furq> same thing though
[01:16:10 CEST] <CoJaBo> Unintentional fuzz testing is not fun :/
[01:16:17 CEST] <nicolas17> lol
[01:17:54 CEST] <CoJaBo> How does VP8+Opus compare to x264+AAC? Anyone know offhand, or am I going to have to spend the next day benchmarking this :/
[01:18:39 CEST] <c_14> x264 > libvpx
[01:18:56 CEST] <c_14> opus > aac (imo, not much evidence on that one)
[01:21:14 CEST] <furq> CoJaBo: http://listening-test.coresv.net/s/scores_by_tracks_en.png
[01:21:25 CEST] <furq> there's very little in it really
[01:22:28 CEST] <CoJaBo> c_14: Yeh, I want to use x264+opus, but no permissible output container supports both D=
[01:22:39 CEST] <c_14> matroska?
[01:22:47 CEST] <furq> yeah mkv supports both
[01:22:49 CEST] <CoJaBo> I'm limited to the webm subset of it
[01:22:55 CEST] <furq> you might as well just use x264+aac though
[01:23:04 CEST] <furq> you won't be able to tell the difference at 128kbps
[01:23:11 CEST] <furq> unless you are a dog
[01:23:17 CEST] <CoJaBo> I am a dog
[01:23:27 CEST] <klaxa> webm doesn't support h264
[01:23:35 CEST] <CoJaBo> I'm mostly concerned about performance at the lowest possible bitrate
[01:23:49 CEST] <klaxa> i don't it supports aac either
[01:23:50 CEST] <c_14> there's always vp9 (I mean, you have hours to encode footage right? Right?)
[01:24:04 CEST] <furq> if you want super low bitrates then use he-aac
[01:24:15 CEST] <furq> although i've not seen that benchmarked against opus at low bitrate
[01:24:18 CEST] <klaxa> does it outperform opus in low bitrates?
[01:24:19 CEST] <klaxa> ah
[01:24:25 CEST] <furq> it should be good enough though
[01:24:59 CEST] <furq> if you're talking about voice at 8kbps or something then i'd expect opus to win that one
[01:26:12 CEST] <CoJaBo> c_14: heh, and yeh, I need FAST encoding too :/
[01:26:30 CEST] <klaxa> vp8 and crank up the bitrate :V
[01:26:41 CEST] <furq> yeah if you need fast encoding you're stuck with x264 really
[01:26:44 CEST] <furq> libvpx can't compete
[01:26:59 CEST] <furq> http://listening-tests.hydrogenaud.io/igorc/nonblocked_means_all.png
[01:27:02 CEST] <klaxa> even with multithreading? (they implemented that, right?)
[01:27:12 CEST] <CoJaBo> VP8+Opus isn't too awful, but I have to downscale to postage stamp :/
[01:27:16 CEST] <elvador> hey, i have a broken m4v file. it appears that the pixel format is "none", should be yuv420p (Stream #0:0(und): Video: h264 (avc1 / 0x31637661), none, 1280x720, 2581 kb/s, 25 fps, 25 tbr, 90k tbn, 180k tbc (default)). is there any quick way to fix this without reencoding the whole file?
[01:27:55 CEST] <CoJaBo> furq: Can AAC support crazy low bitrates? Lots of info on doing that with Opus, oddly not AAC :/
[01:28:04 CEST] <furq> i've never tried
[01:28:17 CEST] <c_14> elvador: probably not with ffmpeg (though you can try forcing input options to see if it helps), maybe something like l-smash will help
[01:28:17 CEST] <furq> if you do need he-aac then you'll need ffmpeg with fdk-aac
[01:28:23 CEST] <klaxa> CoJaBo: are you absolutely bound to the webm container?
[01:28:33 CEST] <furq> i assume he's bound to webm or mp4
[01:28:33 CEST] <CoJaBo> klaxa: webm or MP4
[01:28:53 CEST] <klaxa> ah, h264 with aac might be the better choice then
[01:28:54 CEST] <furq> i'd make that choice on the basis of the video quality
[01:28:59 CEST] <furq> and video encoding speed
[01:29:03 CEST] <CoJaBo> I think it's actually using Gecko, so yeh basically in-browser formats
[01:29:05 CEST] <furq> since that's going to be the more noticeable
[01:30:16 CEST] <furq> i believe fdk-aac will be roughly the same as nero he-aac in that chart i posted
[01:30:31 CEST] <elvador> c_14: thanks for you response. i've tried different parameters like -pix_fmt yuv420p, -input_format yuv420p and -pixel_format yuv420p but they all result in an error: [buffer @ 0x73d420] Unable to parse option value "-1" as pixel format
[01:30:35 CEST] <furq> they're both fraunhofer encoders but they're not the same encoder and it's not clear what's different
[01:30:37 CEST] <elvador> *your
[01:30:42 CEST] <CoJaBo> furq: ..what do i actually specify there
[01:30:43 CEST] <furq> other than that fdk is fixed-point for mobile devices
[01:30:56 CEST] <furq> specify where?
[01:31:14 CEST] <CoJaBo> ah, libfdk_aac
[01:31:31 CEST] <furq> yeah you'll probably need to compile ffmpeg yourself if you want to use it
[01:31:59 CEST] <CoJaBo> ..o that sucks becasue I can't get it to compile :
[01:32:01 CEST] <c_14> elvador: probably try l-smash then or some actual recovery tool
[01:32:02 CEST] <CoJaBo> ..o that sucks becasue I can't get it to compile :/
[01:32:06 CEST] <furq> what os
[01:32:29 CEST] <CoJaBo> Ubuntu; I think the build env is effed
[01:33:23 CEST] <furq> x264 and fdk-aac are both in apt
[01:33:31 CEST] <furq> although if you're on an old ubuntu they'll probably be shitty versions
[01:33:51 CEST] <furq> you could always just debootstrap debian sid into a chroot
[01:34:41 CEST] <CoJaBo> Yeh, I'm running the static builds actually
[01:34:49 CEST] <CoJaBo> The release ones are too buggy
[01:35:06 CEST] <furq> all of the "HOW 2 BUILD FFMPEG ON LUNIX" guides i've seen are insane
[01:35:11 CEST] <CoJaBo> ..actually the git builds are too buggy, but less so lol
[01:35:24 CEST] <furq> presumably because they're designed for people on ubuntu from five years ago or RHEL which is permanently from five years ago
[01:35:39 CEST] <furq> if you're on a distro with up-to-date packages then it's really simple
[01:38:35 CEST] <CoJaBo> ..yeh, libfdk_aac is probaby not worth the effort :/
[01:38:48 CEST] <CoJaBo> Are the other AAC encoders good enough to be worth trying?
[01:38:53 CEST] <furq> not for he-aac
[01:39:04 CEST] <furq> the builtin encoder is only good at cbr lc-aac
[01:39:34 CEST] <furq> which ubuntu are you on
[01:40:01 CEST] <furq> http://vpaste.net/r3HnJ
[01:40:06 CEST] <furq> it should literally be that simple if you're on a recent one
[01:41:11 CEST] <CoJaBo> OldLTS.. tho also, I was counting on being able to run the static build
[01:41:24 CEST] <CoJaBo> I can't install packages on the target machine
[01:41:55 CEST] <furq> that'll produce a static binary but it'll be dynamically linked against glibc
[01:42:17 CEST] <furq> there's some trick to static linking glibc which i've never needed
[01:42:23 CEST] <furq> relaxed presumably knows
[01:43:01 CEST] <furq> i'm not entirely sure it matters if the target glibc is newer, though
[01:43:28 CEST] <furq> https://wiki.debian.org/Debootstrap
[01:43:48 CEST] <furq> you'll probably also want to do that if you're on oldlts
[01:45:11 CEST] <CoJaBo> ..damn; just tried it, and actually x264 royally sucks at 32k
[01:45:21 CEST] <CoJaBo> Even at postage stamp :/
[01:45:36 CEST] <c_14> You're encoding video with a bitrate at 32k?
[01:45:54 CEST] <c_14> at what resolution?
[01:46:32 CEST] <CoJaBo> 320:180
[01:46:41 CEST] <furq> that's not that small
[01:46:55 CEST] <CoJaBo> It needs to be "distinguishable"
[01:47:06 CEST] <furq> hevc would probably suck there as well
[01:47:27 CEST] <CoJaBo> I got an output file down to 15kbits (A+V) total at that res tho
[01:48:00 CEST] <furq> did it look like a broken tetris romhack
[01:48:34 CEST] <CoJaBo> It looks like tetris tripping acid
[01:48:41 CEST] <c_14> CoJaBo: maybe you do need to use vp9?
[01:48:47 CEST] <CoJaBo> I saved that file, it's actually really cool xD
[01:48:49 CEST] <c_14> At that size/bitrate the results are much better than x264
[01:49:02 CEST] <furq> vp9 should at least not be disgracefully slow at that bitrate
[01:49:35 CEST] Action: c_14 got 3x realtime at default settings
[01:49:39 CEST] <c_14> (for a 2s clip)
[01:49:49 CEST] <furq> i imagine you're going to want to max out --cpu-used though
[01:49:52 CEST] <CoJaBo> The target machine is dreadfully slow; I think I do need a minimum of realtime
[01:50:23 CEST] <CoJaBo> VP8-PostageStamp" gets 10× realtime on my laptop
[01:50:53 CEST] <furq> at that bitrate you might even want to encode it smaller and stretch it on playback
[01:51:06 CEST] <CoJaBo> That's actually what it's doing lol..
[01:51:16 CEST] <furq> oh
[01:51:20 CEST] <CoJaBo> This is played at 720p
[01:51:26 CEST] <furq> jesus
[01:51:35 CEST] <furq> what did you do to deserve this job
[01:51:41 CEST] <c_14> How difficult is the content?
[01:52:11 CEST] <CoJaBo> Relatively little movement
[01:52:26 CEST] <c_14> mostly flat colors? few gradients?
[01:52:32 CEST] <CoJaBo> It's actually possible to read huge text if it stands still long enough
[01:52:41 CEST] <c_14> oh boy
[01:53:02 CEST] <CoJaBo> furq: I wish I knew >_>
[01:53:17 CEST] <furq> i can't even imagine what this could be used for
[01:53:30 CEST] <furq> other than an elaborate punishment for you
[01:54:05 CEST] <CoJaBo> Yeh, I get a lot of fringe usecases rofl
[01:54:48 CEST] <CoJaBo> My last project unearthed exotic bugs in almost every single tool used; today alone, I found 2 ffmpeg bugs and a dd bug
[01:55:18 CEST] <CoJaBo> That one's on hold again, on account of too many bugs in tools I need to proceed >_>
[01:59:15 CEST] <CoJaBo> The tradeoff is interesting; I can tune them both to pretty close to the same speed and bitrate
[01:59:43 CEST] <CoJaBo> x264 is worlds clearer, but the motion is obliterated; VP8 is just the opposite
[02:00:01 CEST] <klaxa> who would have thunked
[02:00:33 CEST] <klaxa> the x264dev site if offline, but in the blogpost where he compared x264 with vp8, vp8 was just bad
[02:00:39 CEST] <klaxa> and filled with bugs
[02:00:48 CEST] <klaxa> because the "spec" was copy pasted c code
[02:01:04 CEST] <CoJaBo> It was unusably bad when it came out
[02:01:37 CEST] <klaxa> i don't know if the spec changed after that, but i don't think so
[02:01:38 CEST] <CoJaBo> Frankly, what I'm seeing now probably beat my first try at it, which was at a much much more reasonable bitrate
[02:04:02 CEST] <klaxa> https://archive.is/CMb5Y
[02:04:12 CEST] <klaxa> that's the blogpost i was referring to
[02:05:08 CEST] <CoJaBo> Curiously, aac is better than opus on the clip im testing with
[02:05:12 CEST] <klaxa> oh looks more like a follow up to the one i meant
[02:05:43 CEST] <iive> CoJaBo: `dd` bug? I'd like to see that.
[02:05:56 CEST] <CoJaBo> Yeh, but encoders improve a hell of a lot in 6 years  lol
[02:06:14 CEST] <CoJaBo> iive: https://www.google.com/search?q=dd%3A%20%E2%80%98standard%20input%E2%80%99%3A%20cannot%20skip%20to%20specified%20offset
[02:06:28 CEST] <CoJaBo> More a stupid "feature" than a bug maybe, but frustrating
[02:07:06 CEST] <Demon_Fox> How big is a raw, completely uncompressed DVD?
[02:07:20 CEST] <CoJaBo> "a lot big"
[02:07:23 CEST] <Demon_Fox> If you were to just store the entire video y4m for example
[02:07:28 CEST] <furq> depends how long it is
[02:07:37 CEST] <CoJaBo> 10 minutes of 1080p is 722GB
[02:07:37 CEST] <Demon_Fox> I was hoping for a rough average
[02:08:18 CEST] <CoJaBo> ffmpeg cannot encode more than 2 minutes of that without crashing
[02:09:42 CEST] <CoJaBo> Demon_Fox: Height × Width × bpp × fps × duration
[02:09:56 CEST] <CoJaBo> (tho that's not including the audio, which is also huge)
[02:10:25 CEST] <c_14> bit depth * channels * sampling rate
[02:10:27 CEST] <furq> an ntsc dvd would be about 675KB per frame
[02:10:33 CEST] <CoJaBo> Demon_Fox: This about sums it up nicely: https://en.wikipedia.org/wiki/File:LDDVDComparison-mod.png =D
[02:10:55 CEST] <CoJaBo> Demon_Fox: (disc on left is double-sided, btw)
[02:11:10 CEST] <Demon_Fox> I think I have an answer
[02:11:13 CEST] <furq> and you'd be looking at about 200k frames on average
[02:11:16 CEST] <furq> so a lot
[02:11:57 CEST] <Demon_Fox> Thanks
[02:12:02 CEST] <Demon_Fox> I think I figured it out
[02:12:05 CEST] <furq> er
[02:12:09 CEST] <furq> 506KB per frame, rather
[02:12:24 CEST] <CoJaBo> Thankfully, there is almost never a reason to store completely uncompressed video/audio
[02:13:10 CEST] <c_14> audio is usually fine
[02:13:13 CEST] <c_14> video is the problem
[02:13:57 CEST] <CoJaBo> Theatre-grade audio might be pushing it tho lol
[02:14:15 CEST] <furq> well it's a dvd so it'll be 5.1 16/48
[02:14:17 CEST] <iive> CoJaBo: i tried dd with stdin and it seems to work.... so what is the bug exactly?
[02:14:21 CEST] <furq> which is about 4.6mbps
[02:14:47 CEST] <furq> or stereo which is even less
[02:14:54 CEST] <CoJaBo> iive: You can't skip data in stdin; it generates output, but not the correct output
[02:16:34 CEST] <iive> CoJaBo: you know, you could have typed this, instead of giving me shitty google searches.
[02:16:45 CEST] <iive> and yes, you seem to be correct.
[02:17:50 CEST] <CoJaBo> The suckiness of the google searches was a big part of why it sucks overall <_<
[02:26:59 CEST] <iive> :P
[02:27:08 CEST] <iive> you...
[02:27:14 CEST] <iive> see ya
[04:50:55 CEST] <Demon_Fox> What is the performance promise of xvid?
[04:51:36 CEST] <Demon_Fox> I believe it was 70% the size of mpeg2 part 2 at the same quality
[09:19:52 CEST] <operator> i'm trying to read growing file (from intensity pro 4k capture card), ffmpeg stops
[09:22:10 CEST] <operator> for example, capture runs for 10 sec and then I start ffmpeg. So, ffmpeg will encode only 10 sec and then stop, even if the capture still runs and file is still growing
[09:37:13 CEST] <nifwji2_> help
[09:37:21 CEST] <nifwji2_> I am trying to enode a bunch of images into a video
[09:37:34 CEST] <nifwji2_> and it won't let me because it says the image is not divisible by two
[09:37:48 CEST] <nifwji2_> I don't wont to go into 68 frames and add 1 extra pixel to the width
[09:38:01 CEST] <nifwji2_> is there a way around this?
[09:47:41 CEST] <cbsrobot> nifwji2_: you could use the pad filter
[09:47:57 CEST] <nifwji2_> thanks for your reply
[09:48:14 CEST] <nifwji2_> I decided to just make an animated png file instead though.
[12:46:54 CEST] <paul_> hi all, im new to linux and im trying to remove yasm 1.1.99.HEAD which yum says its not installed. How else can I remove it so I can get 1.2 installed?
[12:49:00 CEST] <BtbN> well, how did you install it?
[12:49:30 CEST] <paul_> i was following a guide from http://360pc.com:8090/display/TECHDOCS/ClipBukit+Setup+On+Centos+6
[12:50:50 CEST] <paul_> but i then found that that version of ffmpeg is way out of date and not compatible
[12:51:23 CEST] <paul_> so im stuck now trying to remove the old ffmpeg and reinstalling it another way
[12:52:45 CEST] <BtbN> So you manually installed it. You'll have to remove all the files that put into your system manually as well.
[12:53:00 CEST] <BtbN> If you still have the source tree from which you installed it, make uninstall could work.
[12:53:55 CEST] <paul_> would you have any idea where they would be installed to?
[12:54:18 CEST] <DHE> source builds usually install to /usr/local/bin unless overridden
[12:54:29 CEST] <paul_> kk will have a look
[12:54:29 CEST] <BtbN> and lib, and include, and share
[12:54:40 CEST] <paul_> thanks
[12:54:49 CEST] <BtbN> But it could be anywhere in your system, even cluttered through your actual /usr
[12:54:59 CEST] <DHE> that too
[13:01:32 CEST] <paul_> im running a search across the entire drive
[13:02:08 CEST] <paul_> fingers crossed, i dont want to reinstall the system again
[13:02:26 CEST] <paul_> steep learning curve this linux
[13:05:09 CEST] <BtbN> Just don't install stuff without your package manager.
[13:05:35 CEST] <DHE> sounds like the package manager installed very old versions of stuff
[13:07:27 CEST] <drathir> mornin/evenin...
[13:07:43 CEST] <drathir> hi guys...
[13:07:47 CEST] <paul_> lesson learned
[13:07:52 CEST] <paul_> hi
[13:08:25 CEST] Action: drathir wonder  if is any reason of  [ffmpeg] libssh: Connection failed: crypt_set_algorithms2: no crypto algorithm function found for chacha20-poly1305 at openssh.com ?
[13:09:12 CEST] <BtbN> Your openssl/openssh does not support said algorithm.
[13:10:10 CEST] <drathir> openssh is fine, bc connectin w/o problem...
[13:12:52 CEST] <drathir> k openssl have only aes let me check at aes than...
[13:18:32 CEST] <BtbN> openssh uses openssl-crypto
[13:27:37 CEST] <drathir> BtbN: in that case if ssh workin that ffmpeg should also workin?
[13:28:02 CEST] <BtbN> I'd think so, yes. Unless libssh is independend from openssh
[13:28:22 CEST] <BtbN> which it seems it indeed is
[13:28:52 CEST] <BtbN> Yeah, http://www.libssh.org
[13:29:07 CEST] <BtbN> entirely independend from openssh. I'd guess they just don't support an @openssh.com algorithm.
[13:29:10 CEST] <drathir> any tips to detect that? the issue occur ar arch trying to play over sftp in mpv...
[13:29:36 CEST] <BtbN> detect what?
[13:30:05 CEST] <drathir> supported by ffmpeg methods to connect....
[13:31:00 CEST] <BtbN> ffmpeg uses libssh
[13:31:06 CEST] <BtbN> so whatever libssh supports works.
[13:31:14 CEST] <DHE> usually an algorithm is decided on. if there's not compatible algorithm, you're kinda out of luck unless you have admin access to the remote side
[13:31:20 CEST] <BtbN> If the server forces a cipher that's not supported by libssh, you can't connect.
[13:31:29 CEST] <DHE> or know where to send the beer
[13:32:39 CEST] <BtbN> https://www.libssh.org/archive/libssh/2015-05/0000009.html claims chacha20-poly1305 is on their TODO list.
[13:32:50 CEST] <drathir> DHE: isnt it in theory should support all latest algo?
[13:33:28 CEST] <BtbN> libssh only supports algorithms it implemented.
[13:33:40 CEST] <BtbN> And the ones that are in openssl
[13:38:16 CEST] <DHE> and the admin can turn off algorithms depending on security updates, sly NSA statements, etc.
[13:40:58 CEST] <bencoh> ooh, reminds me I have a patch for ffmpeg/libssh
[13:41:37 CEST] <bencoh> and I still have to ask for help regarding ffmpeg+libssh and caching
[13:42:05 CEST] <BtbN> you could allways just use ssh .... | ffmpeg -i - ...
[13:42:17 CEST] <BtbN> if all you want is play/transcode a file.
[13:42:24 CEST] <bencoh> seeking? ;)
[13:42:47 CEST] <BtbN> you don't usualy seek with the ffmpeg cli tool.
[13:42:48 CEST] <drathir> BtbN: i will check that thanks for tips...
[13:43:19 CEST] <bencoh> BtbN: no, but the ffmpeg/libssh backend is used by some players (mpv, mplayer, ...)
[13:43:32 CEST] <BtbN> also works for the output, but the no seeking is a bigger issue there
[13:43:41 CEST] <bencoh> and the way we fetch chunks of data make it painfully slow for now
[13:44:26 CEST] <bencoh> basically it sends a new request everytime the demux needs a chunk ...
[13:44:36 CEST] <bencoh> so chunks can be reaally small
[13:45:13 CEST] <bencoh> it's fine on local networks, but with a bit of latency (or jitter) ... it's over
[14:01:58 CEST] <drathir> https://github.com/djblue/ssh-mpv get a try of that...
[14:04:58 CEST] <wallbroken> [mp3 @ 03264580] Header missing
[14:04:58 CEST] <wallbroken> Error while decoding stream #0:0: Invalid data found when processing input
[14:05:41 CEST] <drathir> but if good see its only wrapper...
[14:17:20 CEST] <drathir> i guess stay only thunar method... ;/ with cat not seeking...
[14:17:37 CEST] <drathir> with ssh+cat*
[14:26:50 CEST] <drathir> or plain sshfs for console...
[14:29:08 CEST] <drathir> wallbroken: for me sounds like partially downloaded file but im not any pro...
[14:29:30 CEST] <wallbroken> no
[18:26:21 CEST] <anddam> checking the 26x lines in encoders I see "V..... h264_videotoolbox    VideoToolbox H.264 Encoder (codec h264)" , that's the accelerated h264 encoder as per https://trac.ffmpeg.org/wiki/HWAccelIntro
[18:26:23 CEST] <anddam> is that correct'
[18:26:25 CEST] <anddam> ?
[18:32:54 CEST] <f00bar80> thinking of writing a script which check if a stream is up and has both audio and video, what's the suitable and optimum way to do it? using ffprobe ?
[18:33:04 CEST] <f00bar80> any suggestions are greatly appreciated
[18:34:36 CEST] <anddam> f00bar80: can a stream "have" audio _and_ video?
[18:34:58 CEST] <anddam> AFAICT a stream is either audio OR video OR something else like subtitle
[18:41:08 CEST] <f00bar80> anddam: sorry I meant the input source
[18:41:24 CEST] <anddam> mmm no luck with hw accel
[18:41:26 CEST] <anddam> [h264_videotoolbox @ 0x7fe00982ca00] Error: cannot create compression session: -12915
[18:41:28 CEST] <anddam> [h264_videotoolbox @ 0x7fe00982ca00] Try -allow_sw 1. The hardware encoder may be busy, or not supported.
[18:46:07 CEST] <anddam> btw are there h.265 hardware encoders out there? a brief web search didn't show any
[18:53:16 CEST] <f00bar80> even how to check encoded file for any dropped frames / audio streams ?
[18:58:43 CEST] <c_14> anddam: some nvenc asics support hevc encoding, yes
[18:59:44 CEST] <jkqxz> anddam:  Recent Intel CPUs and NVidia graphics cards have hardware H.265 encoders usable by ffmpeg in.  Others exist, but not supported in ffmpeg.
[18:59:50 CEST] <wallbroken> c_14, you know something about the error i've posted?
[18:59:55 CEST] <anddam> I see
[19:00:07 CEST] <wallbroken> [14:04:58] <wallbroken> [mp3 @ 03264580] Header missing
[19:00:07 CEST] <wallbroken> [14:04:58] <wallbroken> Error while decoding stream #0:0: Invalid data found when processing input
[19:00:18 CEST] <klaxa> that's the most generic error possible
[19:00:25 CEST] <klaxa> your file is broken
[19:00:39 CEST] <klaxa> it is not in the correct mp3 format
[19:00:45 CEST] <wallbroken> don't think, it's playing
[19:00:51 CEST] <klaxa> with what player?
[19:00:56 CEST] <wallbroken> vlc
[19:01:04 CEST] <c_14> the mp3 parser is notoriously shit
[19:01:04 CEST] <anddam> btw is ffmpeg doing something "odd" with stdout/err? I'm seeing an issue while grepping the output of -encoders through a pipe in fish shell, but not in bash https://gist.github.com/anddam/b5d35d7fda7d7ca88cfe59c6b97d7854
[19:01:19 CEST] <c_14> open a bugreport on trac and upload a sample, (you are on a recent git, right?)
[19:01:20 CEST] <wallbroken> c_14, so, don't care about that error?
[19:01:29 CEST] <anddam> the ^/dev/null is the same as 2>/dev/null
[19:01:30 CEST] <wallbroken> the output is fine
[19:01:55 CEST] <klaxa> i also use fish, but it's somewhat fishy with scripting for me
[19:02:12 CEST] <c_14> that pun
[19:02:15 CEST] <klaxa> it also breaks when i want to tab-complete directories with utf-8 characters
[19:02:29 CEST] <klaxa> i usually just switch to bash if i need to
[19:02:31 CEST] Action: klaxa shurgs.
[19:02:42 CEST] <wallbroken> the file looks muxed well, i need to worry the same?
[19:02:52 CEST] <c_14> anddam: ffmpeg shouldn't be doing anything weird. If it only happens with fish it might be a problem in fish or fish handling something different
[19:03:14 CEST] <c_14> wallbroken: if it picks it up correctly after a while, ignore the error. It's just the parser being funky
[19:03:24 CEST] <klaxa> fish being interactive and all that i can imagine fish does more odd stuff to streams than ffmpeg
[19:04:29 CEST] <anddam> ok
[19:04:41 CEST] <wallbroken> c_14, i haven't understood your sentence
[19:04:50 CEST] <wallbroken> what do you mean with "picks it up"
[19:05:03 CEST] <c_14> wallbroken: if the ffmpeg command doesn't abort, ignore the error
[19:05:04 CEST] <wallbroken> the error is in the end of processing
[19:05:16 CEST] <wallbroken> no' does not abort
[19:06:37 CEST] <wallbroken> c_14, yesterday you calculated the stretching time for -atempo, i geave you mins:secs, i need to give you also decimals of seconds?
[19:08:00 CEST] <c_14> it will make it more precise, yes
[19:13:11 CEST] <wallbroken> Duration                                 : 42mn 46s
[19:13:19 CEST] <wallbroken> mediaInfo told me only this
[19:14:06 CEST] <c_14> If you can't notice a delay between the audio and video it's not important, but you can try ffprobe to see if that gives a better duration.
[19:17:13 CEST] <wallbroken> c_14, can you teach me how to calculate the stretch time?
[19:17:20 CEST] <wallbroken> so, i will calculate by myself
[19:17:55 CEST] <c_14> hours*3600+minutes*60+seconds / hours*3600+minutes*60+seconds
[19:17:58 CEST] <c_14> video / audio
[19:18:23 CEST] <wallbroken> where to put it?
[19:18:42 CEST] <c_14> that's the number than you put in atempo=
[19:20:21 CEST] <wallbroken> ok, so, your suggestion is that i do not notice some delay, don't do anything?
[19:20:27 CEST] <wallbroken> *if
[19:20:40 CEST] <f00bar80> ppl any comment ?
[19:21:53 CEST] <c_14> f00bar80: use ffprobe
[19:24:28 CEST] <wallbroken> c_14, you used a manual calculator device?
[19:24:47 CEST] <f00bar80> c_14: suppose i'm encoding a live stream , how can i use ffprobe to watch the encoded output for any dropped streams?
[19:25:34 CEST] <c_14> wallbroken: I used numerous cpu registers to store the values so my cpu could do it for me
[19:25:37 CEST] <c_14> f00bar80: dropped streams?
[19:25:58 CEST] <f00bar80> c_14: any dropped audio/video streams
[19:26:08 CEST] <c_14> As in streams vanishing?
[19:27:19 CEST] <wallbroken> c_14, ffprobe gives me only two digits after seconds
[19:27:32 CEST] <wallbroken> 00:00:00.00
[19:27:44 CEST] <wallbroken> virtualdub for example gives: 00:00:00.000
[19:27:46 CEST] <wallbroken> 3 digits
[19:28:04 CEST] <wallbroken> virtualdub is more precise?
[19:29:03 CEST] <furq> are you dealing with a lot of 240fps video
[19:29:50 CEST] <c_14> wallbroken: ffprobe -show_format will show you up to 6
[19:30:06 CEST] <f00bar80> c_14: i don't know what do you mean by streams vanishing , but i have a transcoding common problem that transcoders sometimes fail to trancode both audio and video so it needs restarting, I'm not sure how to use ffprobe to detect such kind of problems on a live stream encoded output
[19:30:49 CEST] <c_14> f00bar80: I'm not sure what problem you're trying to solve.
[19:31:02 CEST] <wallbroken> c_14, which digits do you suggest to me to care about?
[19:31:23 CEST] <furq> does atempo not accept expressions
[19:32:00 CEST] <wallbroken> and how to edit your ratio to add also decimals?  hours*3600+minutes*60+seconds / hours*3600+minutes*60+seconds
[19:32:19 CEST] <c_14> you won't really need more than the first 2
[19:32:31 CEST] <wallbroken> ok
[19:32:40 CEST] <f00bar80> c_14: i wan to be able to check for all included audio / video streams of a live source are existing in encoded output
[19:32:40 CEST] <c_14> instead of seconds you'll have seconds.fractional
[19:32:55 CEST] <furq> yeah it does
[19:33:19 CEST] <furq> you can just do -af atempo=1234.567/1235.678
[19:33:40 CEST] <c_14> f00bar80: you'll probably have to run an ffmpeg -i stream -f null /dev/null and monitor stdout/stderr
[19:34:06 CEST] <c_14> furq: you still have to grab both durations etc so it doesn't really matter if you do the division first as well
[19:34:15 CEST] <furq> well it saves a step
[19:34:24 CEST] <furq> and it means you don't need to worry about significant digits
[19:34:36 CEST] <wallbroken>  echo "$(date -u -d "00:41:38.233" +"%s.%N") / $(date -u -d "00:39:55.34" +"%s.%N")" | bc -l
[19:34:40 CEST] <wallbroken> that's good ?
[19:35:04 CEST] <furq> 18:33:19 ( furq) you can just do -af atempo=1234.567/1235.678
[19:35:06 CEST] <furq> wallbroken: ^
[19:35:42 CEST] <c_14> wallbroken: ye, and like furq said you can just plug that directly into atempo instead of passing it to bc if you want
[19:35:53 CEST] <f00bar80> c_14: ffprobe can't be used to monitor the audio / video streams integrity , if yes so how?
[19:36:31 CEST] <wallbroken> [19:34:06] <c_14> furq: you still have to grab both durations etc so it doesn't really matter if you do the division first as well
[19:36:38 CEST] <c_14> f00bar80: ffprobe doesn't run continually, you could run ffprobe in a loop checking the output if you wanted
[19:36:42 CEST] <wallbroken> this means that it's not the best idea
[19:38:01 CEST] <wallbroken> c_14, 1.00000007022994967621
[19:38:04 CEST] <wallbroken> this is the ratio
[19:38:15 CEST] <wallbroken> i need to pot it into -atempo as long as it is?
[19:40:07 CEST] <c_14> Well, having a ratio of 1 wouldn't do anything, so yeah
[19:43:37 CEST] <f00bar80> c_14: k but in which way ? ? something like the following > http://vpaste.net/514hA ?
[19:43:44 CEST] <wallbroken> but the video are with different lenght
[19:44:05 CEST] <wallbroken> that value is the result of this:
[19:44:06 CEST] <wallbroken> echo "$(date -u -d "00:41:38.233" +"%s.%N") / $(date -u -d "00:39:55.34" +"%s.%N")" | bc -l
[19:44:16 CEST] <wallbroken> and as you can see: video is 41:38
[19:44:20 CEST] <wallbroken> audio is 39:55
[19:46:24 CEST] <c_14> f00bar80: I guess
[19:47:10 CEST] <c_14> wallbroken: that calculation is off somehow
[19:47:38 CEST] <c_14> wallbroken: %s is seconds since 1970
[19:48:12 CEST] <c_14> I don't think you can use date for that, you'd have to parse the time yourself
[19:50:37 CEST] <furq> you can do it with date if you put 01/01/1970 before it
[19:50:54 CEST] <f00bar80> c_14: did you notice something isn't correct in this script , ffprobe isn't showing as started process after running this script , only ffmpeg
[19:50:57 CEST] <furq> or 1970-01-01 or whatever iso8601 wants
[19:51:22 CEST] <c_14> f00bar80: because ffmpeg isn't forking. Therefore ffprobe would only be run after ffmpeg quits
[19:51:35 CEST] <c_14> It might just be better to run two scripts
[19:51:39 CEST] <c_14> One for ffmpeg and one for ffprobe
[19:53:03 CEST] <wallbroken> the ratio must be in seconds, right?
[19:53:21 CEST] <furq> yes
[19:54:08 CEST] <f00bar80> c_14: or to put ffprobe in the background i.e '&'
[19:54:34 CEST] <c_14> Well, you could calculate everything in hours or lightyears or nanoseconds, but that just makes it harder on yourself
[19:54:50 CEST] <c_14> f00bar80: ffprobe is a short-lived process already, no real point forking it
[20:06:02 CEST] <wallbroken> echo "$(date -u -d "1970-01-01 00:41:38.233" +"%s.%N") / $(date -u -d "1970-01-01 00:39:55.34" +"%s.%N")" | bc -l
[20:06:06 CEST] <wallbroken> 1.043
[20:06:09 CEST] <wallbroken> it's correct?
[20:06:23 CEST] <c_14> close enough
[20:06:55 CEST] <wallbroken> the value you geave me yeasterday
[20:06:58 CEST] <wallbroken> was < 1
[20:07:01 CEST] <wallbroken> 0,95
[20:07:09 CEST] <wallbroken> are you sure that is video / audio ?
[20:07:14 CEST] <wallbroken> and not the reverse?
[20:07:44 CEST] <wallbroken> the audio is faster than video, and i need to throttle it
[20:07:45 CEST] <c_14> Eh, it is the reverse yes.
[20:07:49 CEST] <c_14> yeah
[20:08:34 CEST] <wallbroken> so, is audio/video
[20:09:18 CEST] <wallbroken> but there is a tool to automate that? there are 30 videos
[20:09:34 CEST] <wallbroken> and calculating over them all, could be boring and very time consuming
[20:09:47 CEST] <c_14> write a script?
[20:10:18 CEST] <wallbroken> mmm
[20:10:23 CEST] <wallbroken> in bash?
[20:11:12 CEST] <c_14> whatever language really
[20:28:17 CEST] <wallbroken> ok, so you suggest to do: AudioSeconds.xx/VideoSeconds.xx directly in -atempo , right ?
[20:28:29 CEST] <wallbroken> xx means two decimal digits
[20:29:23 CEST] <c_14> sure
[20:29:41 CEST] <wallbroken> ok thank you
[20:39:40 CEST] <furq> wallbroken: ffprobe will give the duration in ssss.ms anyway
[20:41:35 CEST] <furq> http://vpaste.net/ltnX3
[20:41:55 CEST] <furq> add -select_streams v:0 (or a:0) if necessary
[20:44:19 CEST] <wallbroken> why?
[21:06:48 CEST] <wallbroken> furq, i see two values
[21:06:58 CEST] <wallbroken> which one is for video?
[21:24:12 CEST] <furq> it depends which stream is first in the file
[21:24:20 CEST] <furq> it's usually video but if you want to be sure then use -select_streams
[21:24:41 CEST] <furq> and run it once with v:0 and once with a:0
[21:25:59 CEST] <wallbroken> ok thank you
[22:55:01 CEST] <wallbroken> i downloaded the last version of zaranoe
[22:55:08 CEST] <wallbroken> but i get an error while running
[22:59:29 CEST] <wallbroken> unable to find the entrypoint _wfopen_s of foutine in library msvcrt.dll (is a translation from italian)
[23:20:51 CEST] <hyponic> Guys is there a bug in ffmpeg that makes it not possible to burn subtitles from an matroska stream? it works perfect if the the subtitle is a file but not if it is a part of the matroska stream i am transcoding??
[23:21:57 CEST] <c_14> not really a bug, more like lack of a feature
[23:22:06 CEST] <c_14> the filter framework doesn't support subtitles well (at all)
[23:24:07 CEST] <wallbroken> c_14, some suggestion about my problem?
[23:24:31 CEST] <c_14> wallbroken: no clue, sounds like some sort of windows problem
[23:24:48 CEST] <wallbroken> where's zaranoe?
[23:24:51 CEST] <wallbroken> is here?
[23:25:21 CEST] <c_14> not usually, try the zeranoe forums
[23:29:31 CEST] <hyponic> c_14 any idea what other alternatives are there for me to acheive this?
[23:30:30 CEST] <c_14> You have a live stream as input?
[23:32:07 CEST] <c_14> Dump it to a fifo and use that as input for ffmpeg and the subtitles filter
[23:34:10 CEST] <hyponic> c_14 isn't that asking for desync ?
[23:34:35 CEST] <c_14> why?
[23:34:54 CEST] <c_14> You'll increase the buffering time, but that should be it
[23:35:14 CEST] <hyponic> c_14 another challenge is that the stream includes 4 subtitles 4 languages. and i want to burn all 4. but you can only read once from fifo right?
[23:35:58 CEST] <c_14> This is why the GNU gods invented tee
[23:36:22 CEST] <c_14> it does get kinda complicated though
[23:37:09 CEST] <c_14> There's a couple of possible constellations for how it could work
[23:37:13 CEST] <c_14> I'm not sure which one would be best though
[23:39:09 CEST] <hyponic> c_14 could you possibly help me out with it?
[23:40:30 CEST] <c_14> I can try generating something to test with
[23:41:43 CEST] <hyponic> i can supply a test stream for you that i want the subs burned from.
[23:41:48 CEST] <hyponic> c_14
[23:42:15 CEST] <c_14> sure
[23:42:23 CEST] <hyponic> private?
[23:42:32 CEST] <c_14> you can pm me
[23:42:36 CEST] <hyponic> ok
[00:00:00 CEST] --- Mon Jun  6 2016