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

Mon Oct 24 03:05:01 EEST 2016

[00:04:21 CEST] <Phi> lol furq
[00:04:30 CEST] <Phi> I worked out the reason the writing application was different
[00:04:40 CEST] <Phi> I've spent so long trying to get this to work my build was out-dated
[01:11:57 CEST] <Guest15626> I've got a performance issue with my use of ffmpeg in my rtmp streaming application
[01:12:56 CEST] <Guest15626> if I stream a static image for some number of minutes, and then switch to a different image or video, my CPU and network utilization skyrocket for some period of time
[01:13:21 CEST] <Guest15626> it will eventually normalize, but this period of high utilization is crippling
[01:13:47 CEST] <Guest15626> I suspect it may have to do with my AVCodecContext settings
[01:14:05 CEST] <Guest15626> I'm using ME_HEX as my me_method
[03:10:55 CEST] <Phi> welp
[03:10:59 CEST] <Phi> the beta is a completely confusing mess
[03:11:09 CEST] <Phi> seems slightly more logical
[03:11:15 CEST] <Phi> but half-baked too
[03:11:32 CEST] <Phi> and a connection with RTSP results in every single character spewed out in a new log line
[03:18:16 CEST] <s0126h> why does x265 have proper version system but  x264 has crappy version system
[03:23:51 CEST] <furq> because they're not developed by the same people
[03:24:15 CEST] <furq> not that i think anything is wrong with x264's version numbering
[03:27:19 CEST] <klaxa> doesn't x264 just increase by 1 with every release?
[03:28:53 CEST] <furq> there's the core number and the revision number
[03:29:15 CEST] <furq> if the core number changes then there are breaking api changes
[03:29:28 CEST] <klaxa> sound pretty sane to me
[03:29:38 CEST] <furq> it's slightly roundabout but broadly fine
[03:29:52 CEST] <furq> makes more sense than linux's version numbering anyway
[03:44:52 CEST] <s0126h> klaxa how is x264 version system  sane
[03:45:15 CEST] <furq> what exactly is confusing about it
[03:45:21 CEST] <klaxa> newer version, higher number
[03:45:35 CEST] <klaxa> why does it have to be like 1.0 and stuff?
[03:45:42 CEST] <klaxa> nobody made it a mandatory rule
[03:45:43 CEST] <s0126h> furq have you not seen  x264 version system
[03:45:59 CEST] <furq> no i have never seen it
[03:46:09 CEST] <furq> that's why i didn't just explain how it works
[03:46:43 CEST] <s0126h> klaxa  is that why 99% people use  x.x version system
[03:47:05 CEST] <klaxa> why is it so important to you that they do that?
[03:47:16 CEST] <furq> do you have a complaint other than "it's different from the thing i like"
[03:47:21 CEST] <s0126h> because i like to know what version i am using
[03:47:29 CEST] <klaxa> but it tells you, no?
[03:47:34 CEST] <furq> can you not count over 100 or something
[03:47:37 CEST] <klaxa> core X revision Y
[03:48:02 CEST] <s0126h> i see bunch of core 64
[03:48:12 CEST] <klaxa> >klaxa at neu ~> x264 --version
[03:48:13 CEST] <klaxa> >x264 0.148.2699 a5e06b9
[03:48:13 CEST] <klaxa> >[...]
[03:48:19 CEST] <klaxa> it even does the X.X thing for me
[03:48:24 CEST] <klaxa> 0.148.2699
[03:48:31 CEST] <s0126h> so what is  core 64  then
[03:48:40 CEST] <furq> what kind of question is that
[03:50:07 CEST] <s0126h> if i have a x265 video that is  1.7   and current version is 2.1, then i have some perspective of how far behind is 1.7 from current  version
[03:50:07 CEST] <klaxa> the more important thing is to know when which number has to change
[03:50:27 CEST] <s0126h> with x264, i have no clue of that perspective
[03:50:28 CEST] <klaxa> really though?
[03:50:43 CEST] <furq> how is 2.1 vs 1.7 more illuminating than 148 vs 64
[03:50:43 CEST] <klaxa> that's an illusion though
[03:50:57 CEST] <klaxa> just look at linux 2.6.insane_high_number
[03:51:01 CEST] <furq> all you know in either case is that one number is a bit higher than the other
[03:51:08 CEST] <furq> you'd have to check the release dates anyway
[03:51:12 CEST] <klaxa> ^
[03:51:54 CEST] <s0126h> if i have PS2  and  i know current version is ps4  , then i know i am behind 2 generation..   but if i have xbox1  and current version is xbox-ONE,  i am like WTF
[03:52:15 CEST] <furq> yeah to work that one you'd have to know things
[03:52:17 CEST] <furq> god forbid
[03:52:20 CEST] <furq> +out
[03:52:38 CEST] <s0126h> calling xbox-one: horrible idea
[03:52:49 CEST] <s0126h> and i am microsoft fan
[03:53:16 CEST] <klaxa> i'm a fan of many things, microsoft is not one of them
[03:54:20 CEST] <s0126h> if you think x264 has good version system,  then that is like saying  microsoft xbox uses good version system
[03:54:44 CEST] <furq> your opinions are bad and you should stop mentioning them
[03:54:45 CEST] <klaxa> x264 doesn't jump backwards though
[03:55:02 CEST] <klaxa> yeah this has gotten rather off-topic
[03:55:03 CEST] <s0126h> okay what is latest version of  x264  now?
[03:55:17 CEST] <furq> damn, he's right
[03:55:29 CEST] <furq> if only x264 used x.y.z versioning we would always know the latest version number
[03:56:31 CEST] <s0126h> i see  x264 core 65
[03:56:55 CEST] <s0126h> with no  revision Y
[03:57:13 CEST] <s0126h> what kind of version system   adds  revision Y  later
[03:57:20 CEST] <s0126h> but didn't in the beginning
[03:59:15 CEST] <s0126h> klaxa explain that
[03:59:31 CEST] <klaxa> benevolence of the developer
[03:59:58 CEST] <s0126h> huh
[04:07:10 CEST] <s0126h> anybody else
[04:17:46 CEST] <tobiasBora> Hello,
[04:19:33 CEST] <tobiasBora> I would like to know if there is a way to cut precisely a video at a given time
[04:19:35 CEST] <tobiasBora> I tried :
[04:19:37 CEST] <tobiasBora> ffmpeg -i 2016-10-23\ 02-14-27.mp4 -ss 10.45 -to 01:20 -copyinkf -c copy 02.mp4
[04:19:46 CEST] <furq> probably not with -c copy
[04:19:51 CEST] <tobiasBora> but the problem is that the beginning frames are very strange
[04:19:56 CEST] <furq> the cut segment has to start on a keyframe
[04:20:17 CEST] <tobiasBora> furq: I do need to full recode the whole video only for a few seconds at the beginning ?
[04:20:37 CEST] <furq> no?
[04:20:56 CEST] <tobiasBora> you know better than me ^^
[04:20:57 CEST] <furq> if you want an exact cut at any timestamp you'll need to encode the segment you're cutting
[04:21:06 CEST] <furq> otherwise the segment has to start on a keyframe
[04:21:27 CEST] <furq> and maybe end on one too, i forget now
[04:21:41 CEST] <tobiasBora> encode only a segment is not a problem, the problem is to encode the whole video
[04:21:56 CEST] <tobiasBora> the frame must have the same size ?
[04:21:57 CEST] <furq> there's no need to do that
[04:22:06 CEST] <furq> if you're reencoding it can be whatever size you want
[04:22:54 CEST] <tobiasBora> And if I'm not reencoding the whole video ?
[04:24:10 CEST] <furq> uh
[04:24:14 CEST] <furq> that's what i meant
[04:24:30 CEST] <furq> at no point will i suggest anything to do with reencoding the whole video
[04:25:41 CEST] <furq> just replace `-copyinkf -c copy` with `-c:v libx264 -c:a copy " and that command should work fine
[04:25:48 CEST] <furq> s/ "/`/
[04:26:53 CEST] <s0126h> tobiasBora  what do you think about x264's version system
[04:31:46 CEST] <tobiasBora> furq: -c:v libx264 will re-encode everything no ?
[04:32:14 CEST] <furq> why would it do that
[04:33:20 CEST] <tobiasBora> so how would you re-encode it using libx246 ?
[04:33:35 CEST] <furq> if you want to reencode the whole thing then remove -ss and -to
[04:34:06 CEST] <s0126h> tobiasBora  what do you think about x264's version system
[04:34:11 CEST] <tobiasBora> Oh
[04:34:17 CEST] <tobiasBora> s0126h: What do you mean ?
[04:34:43 CEST] <s0126h> tobasbora  do you use x264 ?
[04:35:29 CEST] <tobiasBora> furq: Well I use ogg when I can. But sometimes x264 has one advantage : it's faster to convert Mov to x264 rather than MOV to ogg.
[04:35:52 CEST] <tobiasBora> * s0126h ^
[04:36:43 CEST] <tobiasBora> furq: Oh ^^ I wanted to say, is it possible to reencode only the first part which is not linked with a key frame, and then say "just read the key frame"
[04:37:07 CEST] <tobiasBora> so that it would encode 5 seconds, and copy 1 hours.
[04:37:22 CEST] <furq> oh right
[04:37:28 CEST] <s0126h> tobiasBora  is OGG is just container?
[04:37:31 CEST] <s0126h> what do you mean OGG?
[04:37:42 CEST] <furq> no, but that command only cuts 80 seconds
[04:37:43 CEST] <s0126h> tobiasBora  OGG is just container
[04:38:08 CEST] <s0126h> i am sure you can put  x264 on OGG too
[04:38:17 CEST] <furq> you probably could reencode the first gop and then stitch it to the rest, but not in one command
[04:38:18 CEST] <tobiasBora> s0126h: Yes, but by ogg I mean everything linked with vorbis
[04:38:34 CEST] <furq> you can't put h264 in ogg
[04:38:45 CEST] <s0126h> you can't?
[04:38:49 CEST] <tobiasBora> h264 isn't free right ?
[04:38:53 CEST] <furq> no
[04:38:56 CEST] <s0126h> then what video  can you put on OGG?
[04:38:57 CEST] <furq> and no
[04:39:00 CEST] <furq> theora
[04:39:09 CEST] <furq> maybe vp8/9 these days
[04:39:29 CEST] <s0126h> ogg allows  vp* video but not x26*  ?
[04:39:34 CEST] <s0126h> interesting
[04:40:08 CEST] <tobiasBora> yes vp* is ok
[04:40:20 CEST] <furq> vp8 works, vp9 doesn't
[04:40:23 CEST] <furq> at least in ffmpeg
[04:40:32 CEST] <furq> whether anything will play anything but theora i don't know
[04:41:09 CEST] <tobiasBora> really ?
[04:41:16 CEST] <tobiasBora> oh
[04:41:21 CEST] <s0126h> tobiasBora  i condone using x264
[04:41:21 CEST] <tobiasBora> webm is not ogg right ?
[04:41:28 CEST] <furq> webm is based on mkv
[04:41:44 CEST] <s0126h> tobiasBora  sorry i mean  i  frown upon people using x264
[04:42:01 CEST] <s0126h> and i recommend people using x265
[04:42:10 CEST] <tobiasBora> how
[04:42:18 CEST] <s0126h> x264 has crappy version system
[04:42:26 CEST] <furq> just use x264
[04:42:31 CEST] <tobiasBora> ahah
[04:42:33 CEST] <furq> it's still the best
[04:42:43 CEST] <s0126h> x265 is better and  better version system
[04:43:08 CEST] <tobiasBora> One thing I hate is that in mp4 I cannot test my file before the end of the encoding, while I can with webm
[04:43:24 CEST] <s0126h> tobiasBora  true/agreed  that's why i use .mkv
[04:43:28 CEST] <furq> if it works with webm it should work with mkv
[04:43:56 CEST] <s0126h> i think mkv is superior than .mp4
[04:44:14 CEST] <tobiasBora> what is the difference between all these containers ?
[04:44:34 CEST] <furq> none of them were invented by the people who invented the other containers
[04:44:59 CEST] <s0126h> and MOV is worse than mp4
[04:45:09 CEST] <furq> mov and mp4 are more or less the same
[04:45:47 CEST] <furq> mp4 is an IEC standard, if that matters to you
[04:46:46 CEST] <tobiasBora> it's possible to be IEC standard and proprietary ?
[04:47:28 CEST] <furq> aren't most ISO standards proprietary
[04:48:56 CEST] <furq> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38538
[04:49:00 CEST] <furq> a bargain for 58 CHF
[04:50:13 CEST] <s0126h> flv is also horrible container
[04:50:31 CEST] <tobiasBora> What about avi ?
[04:50:49 CEST] <furq> avi is ancient
[04:51:00 CEST] <furq> just use mkv
[04:51:12 CEST] <furq> it supports everything and it's open
[04:51:28 CEST] <furq> if you happen to need mp4 you can just remux
[04:51:41 CEST] <s0126h> why was avi popular before h264
[04:51:58 CEST] <furq> what does h264 have to do with it
[04:52:29 CEST] <s0126h> because avi became unpopular after h264
[04:53:15 CEST] <furq> most modern codecs don't work in avi without hacks
[04:54:12 CEST] <s0126h> then why was avi popular even before h264
[04:54:34 CEST] <s0126h> - "even"
[04:55:31 CEST] <furq> familiarity i guess
[04:55:55 CEST] <tobiasBora> both h264 and mp4 are proprietary ?
[04:56:00 CEST] <furq> yes
[04:56:22 CEST] <s0126h> tobiasBora  almost everything is proprietary
[04:56:42 CEST] <tobiasBora> webm + vp* is not !
[04:56:53 CEST] <s0126h> vp9 certainly is
[04:57:34 CEST] <s0126h> tobiasBora  if you invented  vp9 or mp3,, would you give it away for free when you can make money off it
[04:57:55 CEST] <tobiasBora> vp9 is proprietary O_o
[04:58:05 CEST] <furq> vp9 is open-source and license-free
[04:58:15 CEST] <tobiasBora> hum yes
[04:58:33 CEST] <s0126h> tobiasBora  you are obviously lying
[04:58:43 CEST] <tobiasBora> VP9 est un codec vidéo ouvert et sans redevance
[04:59:03 CEST] <tobiasBora> VP9 is an open and royalty free[1] video coding format developed by Google.
[04:59:05 CEST] <tobiasBora> Wikipedia
[04:59:07 CEST] <s0126h> furq  if you invented  vp9 or mp3,, would you give it away for free when you can make money off it
[04:59:46 CEST] <furq> why are you asking me
[04:59:54 CEST] <s0126h> why not
[04:59:57 CEST] <s0126h> just a question
[04:59:58 CEST] <tobiasBora> Well yes, fees and royalties kill innovation
[05:00:49 CEST] <s0126h> furq  by not answering the question,  it gives away  what your honest answer is
[05:02:20 CEST] <furq> i already told you i use x264
[05:02:26 CEST] <furq> because it has the best version numbers
[05:03:08 CEST] <s0126h> furq  if you invented  vp9 or mp3,, would you give it away for free when you can make money off it
[05:05:02 CEST] <furq> http://4.bp.blogspot.com/_tK5X1ZCnM_w/SoQ2eszv8oI/AAAAAAAABII/nH4VDE1xQLs/s400/viof0002.png
[05:05:05 CEST] <furq> they say a picture is worth 1000 words
[05:06:07 CEST] <s0126h> ??
[05:09:19 CEST] <s0126h> why do people lie in freenode?  damn it's only irc, no need to lie
[06:31:49 CEST] <solenodic> is there any way to re-encode a file in a streaming fashion (e.g. write to the new file at the same FPS as the actual video instead of instantly writing it)
[06:33:48 CEST] <furq> -re
[06:35:10 CEST] <solenodic> thanks
[07:28:18 CEST] <BinaryBench> Greetings
[07:29:26 CEST] <BinaryBench> I'm trying to stream from one computer to another with as low latency as possible from Windows to Mac, what's the best way to do this?
[07:29:47 CEST] <BinaryBench> atm I'm doing: ffmpeg -f dshow -i video="UScreenCapture" -r 30 -vcodec libx264 -pix_fmt yuv444p -tune zerolatency -preset ultrafast -f mpegts udp://localhost:6666
[07:30:06 CEST] <BinaryBench> However this is still giving me approx 300ms latency
[07:31:20 CEST] <JEEB> libx264 itself is very low latency, so it's mostly the FFmpeg things around it that you have to try and optimize
[07:31:23 CEST] <furq> are you sure it's encoder latency and not playback latency
[07:31:48 CEST] <JEEB> and then of course you have the playback side in whatever you're using
[07:32:06 CEST] <furq> you need to mess with the vbv to get the lowest possible latency, but 300ms seems quite high
[07:32:09 CEST] <BinaryBench> furq: I'm not sure which it is, it may be play back
[07:32:27 CEST] <furq> it could also be from the capture driver
[07:32:30 CEST] <BinaryBench> I don't think it's internet latency as I'm testing on localhost atm
[07:32:46 CEST] <furq> what are you playing it with
[07:32:56 CEST] <BinaryBench> UScreenCapture
[07:33:13 CEST] <furq> test it with ffplay -fflags nobuffer
[07:34:36 CEST] <BinaryBench> furq: that helped a good deal, but still not quite as fast as what I'm looking for
[07:35:06 CEST] <furq> maybe test with `-f lavfi -i testsrc` instead of dshow to rule out the capture device
[07:36:33 CEST] <BinaryBench> furq: how do I see the latency?
[07:37:03 CEST] <furq> that is a good point
[07:37:07 CEST] <furq> maybe the tee muxer
[07:37:11 CEST] <BinaryBench> (before I was just viewing a timer & subtracting the difference
[07:37:14 CEST] <BinaryBench> )
[07:37:20 CEST] <BinaryBench> Hum, tee muxer?
[07:37:30 CEST] <furq> last time i used that i just compared the video timestamp and the ffmpeg timestamp, but that was to a remote rtmp server
[07:37:40 CEST] <furq> it's not accurate enough to measure sub-500ms latency
[07:38:26 CEST] <BinaryBench> Hum, well, any ideas?
[07:40:56 CEST] <furq> tee would be -f tee -map 0:v "[f=mpegts]pipe:1|[f=mpegts]udp://127.0.0.1:6666" | ffplay -fflags nobuffer -
[07:41:04 CEST] <furq> i guess that's useful for checking if there's some kind of network latency
[07:42:12 CEST] <furq> https://web.archive.org/web/20150507012544/http://x264dev.multimedia.cx/archives/249
[07:42:17 CEST] <furq> that has some pointers on reducing x264 latency
[07:42:44 CEST] <furq> specifically comment #8
[07:47:52 CEST] <BinaryBench> furq: what would the packet size be?
[07:50:49 CEST] <furq> probably your router's MTU
[07:52:10 CEST] <JEEB> libx264 itself is capable of very low latencies, it's usually the rest around it that causes additional latency
[07:53:56 CEST] <BinaryBench> JEEB, what usually is the culprit?
[07:54:32 CEST] <JEEB> can't really say because I have no idea which thing in your case is causing it :P
[07:54:41 CEST] <furq> BinaryBench: you can probably ignore slice-max-size
[07:55:02 CEST] <furq> if that is your mtu then i imagine that'll do more harm than good without jumbo frames
[07:55:04 CEST] <JEEB> I mean, you are using ffmpeg cli which is in turn using the libraries in some way, which in turn...
[07:55:04 CEST] <BinaryBench> furq: How do I add parameters to libx264 in ffmpeg?
[07:55:10 CEST] <JEEB> -x264-params
[07:55:15 CEST] <JEEB> and then key=val
[07:55:27 CEST] <JEEB> with : as the delimiter between settings
[07:55:52 CEST] <furq> those are mapped in ffmpeg -maxrate, -bufsize and -intra-refres
[07:55:55 CEST] <furq> +as
[07:56:03 CEST] <furq> -intra-refresh
[11:00:44 CEST] <Ecco> Hi guys
[11:01:15 CEST] <Ecco> I'd like to encode a video that allows for fast random access (i.e. going to frame #x is as fast as possible)
[11:01:32 CEST] <Ecco> My understanding is that I'll need to make every frame a keyframe. Is that correct?
[11:01:49 CEST] <Ecco> If that is the case, would any codec behave significantly better than a succession of JPEG files?
[11:03:02 CEST] <JEEB> do you need lossy or lossless?
[11:03:54 CEST] <Ecco> JEEB: I can deal with lossy
[11:04:26 CEST] <JEEB> -c:v libx264 -preset slowest_you_can_take -crf XX (highest that still looks OK for you)
[11:04:40 CEST] <JEEB> usually though for quick seeking I use ~3-4 picture GOPs
[11:04:48 CEST] <Ecco> ok
[11:04:59 CEST] <Ecco> Thanks for the command line, but what about the "theoretical" question?
[11:05:59 CEST] <JEEB> you just need short enough GOPs for the fastest seeking at all times, all-intra is not necessary, but of course the last resort
[11:06:49 CEST] <Ecco> Ok, got it. Thanks :)
[11:07:17 CEST] <JEEB> also trying out -tune fastdecode might also be worth a try depending on what you're decoding the stuff on
[11:07:34 CEST] <Ecco> ok
[11:07:43 CEST] <Ecco> thanks
[11:37:56 CEST] <furq> Ecco: x264 should be much smaller than a bunch of jpegs
[11:38:09 CEST] <furq> even with -g 1
[11:48:45 CEST] <Ecco> furq: thanks
[14:36:27 CEST] <pyBlob> I'm using ffplay on arch, and somehow the playback window does not react to keystrokes
[14:36:41 CEST] <pyBlob> also clicking on the window doesn't do seeking
[16:31:09 CEST] <iMath> for a ffmpeg time 00:05:25.80, what does ".80" mean?
[16:37:12 CEST] <__jack__> sub-seconds
[16:37:29 CEST] <c_14> milliseconds
[16:38:05 CEST] <iMath> sub-seconds and milliseconds are the same?
[16:46:24 CEST] <DHE> milliseconds are 1/1000
[16:46:30 CEST] <DHE> .80 would be 8/10
[16:50:25 CEST] <LinuxLoader> Hi , did  someone have issues with ffprbe under centos7 , stream is comming to the interface ( udp stream ) but no info is shown
[16:50:46 CEST] <DHE> check for things like iptables blocking said stream
[16:50:54 CEST] <LinuxLoader> none rules
[16:50:58 CEST] <LinuxLoader> ipforward is ok
[16:51:13 CEST] <DHE> multiple interfaces?
[16:51:13 CEST] <iMath> DHE: what does ".80" mean in ffmpeg ?
[16:51:27 CEST] <DHE> iMath: I already answered that question
[16:51:34 CEST] <LinuxLoader> yep , one for uplink one for udp stream
[16:51:53 CEST] <DHE> LinuxLoader: for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $i ; done
[16:52:01 CEST] <LinuxLoader> i tried with ffmpeg from some repos , and manualy compiled , same shit
[16:52:10 CEST] <LinuxLoader> yep , and rpfilter is ok :)
[16:53:01 CEST] <LinuxLoader> fsck :( deam
[16:53:20 CEST] <iMath> DHE: still cannot understand
[16:53:38 CEST] <LinuxLoader> DHE 10x man ... but strange
[16:53:42 CEST] <LinuxLoader> net.ipv4.conf.default.force_igmp_version=2
[16:53:42 CEST] <LinuxLoader> net.ipv4.conf.all.force_igmp_version=2
[16:53:42 CEST] <LinuxLoader> net.ipv4.conf.all.rp_filter=0
[16:53:42 CEST] <LinuxLoader> net.ipv4.ip_forward=1
[16:53:47 CEST] <LinuxLoader> in sysctl
[16:54:00 CEST] <DHE> don't trust the 'all' setting for rp_filter. check 'default' and the interface involved
[16:54:07 CEST] <LinuxLoader> din`t work :)
[16:54:35 CEST] <LinuxLoader> 10x again ... got rly stuped right now , lost 2 days in that
[16:54:35 CEST] <DHE> hmm... those tricks do it for me...
[16:54:58 CEST] <DHE> strace -f your ffprobe and see if it's recv()ing the data.
[16:58:01 CEST] <LinuxLoader> just got engry that only centos is supported for intel quick sync in kernel
[17:08:59 CEST] <Thaconut> I've compiled ffmpeg with x11grab. How can I pipe the contents of screen 0 to a new mplayer instance running on screen 1?
[17:09:20 CEST] <Thaconut> "ffmpeg -video_side 640x480 -framerate 25 -f x11grab -i :0.0+0,0 - | mplayer - " says its unable to find a suitable output format for 'pipe:'
[17:09:41 CEST] <Thaconut> *video_size
[17:11:32 CEST] <klaxa> add -f matroska
[17:11:47 CEST] <klaxa> before -
[17:12:05 CEST] <Thaconut> klaxa: I'll try that
[17:12:14 CEST] <klaxa> (since '-' has no file extension ffmpeg can't guess what format you want, so you have to say it explicitly)
[17:12:51 CEST] <Thaconut> Ooh it's doing something now
[17:13:23 CEST] <Thaconut> Its not crashing anymore (although now mplayer won't open)
[17:13:25 CEST] <Thaconut> Thanks!
[17:27:49 CEST] <Mad7Scientist> apparently mp3 won't go under -ar 8000 -b:a 8k
[17:30:03 CEST] <BtbN> not exactly surprising
[17:30:29 CEST] <BtbN> you are merely giving it one bit per sample.
[17:31:11 CEST] <BtbN> And that sample rate alone is enough to ruin any kind of audio
[17:35:02 CEST] <iive> technically 44khz stereo is 1,4mbps, so encoded at 128kbps gives similar ratio.
[17:35:17 CEST] <iive> it's just that mp3 is not optimized for low bitrates.
[17:43:56 CEST] <DHE> well, it's hard to argue with a 50% bitrate increase even if you're starting from crap
[18:19:21 CEST] <sopparus> anyone know if quick sync ork on freebsd?
[18:25:57 CEST] <BtbN> QSV only somewhat "works" on Windows.
[18:26:53 CEST] <sopparus> I see
[18:27:13 CEST] <BtbN> In theory it exists on linux, but i'd forget about that.
[18:29:44 CEST] <relaxed> vaapi should work on freebsd
[18:39:44 CEST] <Mad7Scientist> How do I just see info about the input file and then exit?
[18:54:09 CEST] <BtbN> by using ffprobe.
[19:07:46 CEST] <Mad7Scientist> thanks
[19:08:22 CEST] <Mad7Scientist> How can youtube have a 640x480 video like this: Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 589 kb/s, 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc (default)
[19:08:36 CEST] <Mad7Scientist> That looks almost as good as a DVD which is almost 10 times the bit rate?
[19:15:02 CEST] <JEEB> Mad7Scientist: first of all it probably doesn't look too good (in general). but dvd is mpeg-2 video, has a bufsize of 1.5mbits (which is like less than a quarter of a second with 8mbps maxrate). and dvds have very short GOPs, usually a second or less.
[19:15:51 CEST] <JEEB> dvds are not really a high quality medium given the limitations
[19:16:27 CEST] <JEEB> blu-rays at least have the capacity of being utilized as such
[19:17:18 CEST] <JEEB> (40mbps maxrate, 1 second bufsize, avc is permitted)
[19:18:06 CEST] <BtbN> why are they using that short of a bufsize though?
[20:20:51 CEST] <Mad7Scientist> What's GOP?
[20:21:27 CEST] <c_14> https://en.wikipedia.org/wiki/Group_of_pictures
[20:23:02 CEST] <JEEB> BtbN: DVD is old
[20:23:14 CEST] <JEEB> it was designed in the early-to-mid 1990s
[20:29:17 CEST] <BtbN> But even then
[20:29:24 CEST] <BtbN> such a short gop interval and buffer size
[20:29:40 CEST] <BtbN> it's not like you need to be able to enter the "stream" at any point
[20:31:20 CEST] <JEEB> well it was made for the hardware designs they had back then
[20:31:35 CEST] <JEEB> and 1.5 megabits was quite a bit more than how it feels now
[20:31:45 CEST] <JEEB> like twenty+ years later
[20:55:07 CEST] <DHE> sorta does. DVDs did have chapter seeking, time seeking, and the expectation that the player would run at "1x" speed. so under those requirements it makes sense...
[20:55:17 CEST] <DHE> sure, by today's standards that's laughable
[21:15:37 CEST] <Mad7Scientist> mpeg2 produces higher quality than mpeg4 at the same higher bit rates though
[21:15:44 CEST] <Mad7Scientist> so 4mb should be plenty
[21:17:12 CEST] <JEEB> which MPEG-4 spec are you talking of? Part 2 (MPEG-4 Visual) or Part 10 (MPEG-4 Advanced Video Coding)
[21:17:53 CEST] <JEEB> in either case, the bit rates where the difference between MPEG-2 Visual and MPEG-4 AVC go away are nowhere near the rates that DVDs use
[21:18:16 CEST] <JEEB> it's just that DVD is shit and the limitations youtube has picked for itself are shit, but less shit
[21:18:44 CEST] <JEEB> also youtube is utilizing stuff from 2003 and later, while DVDs utilize tech from early 1990s
[21:28:25 CEST] <Mad7Scientist> Is MPEG-4 AVC similar or the same as h264?
[21:30:19 CEST] <JEEB> yes
[21:30:38 CEST] <JEEB> AVC is the ISO/IEC name, and then those specs made in co-operation with ITU-T also get an identifier there
[21:30:48 CEST] <JEEB> H.264 is AVC's and H.265 is HEVC's
[22:39:22 CEST] <chuprin_> hi. guys. is there any way to allow insecure connection when i use hls stream as input. ffmpeg unable to open key file because server use self signed certificate
[22:39:47 CEST] <chuprin_> piece of log http://pastebin.com/TE3ruPxw
[22:47:41 CEST] <DHE> chuprin_: might try adding "-verify 0" to the commandline just before "-i ..."
[22:47:50 CEST] <DHE> I'm not sure if that will work since it's a sub-request of the hls layer...
[22:49:31 CEST] <DHE> from a code examination, I'm guessing not...
[22:51:51 CEST] <chuprin_> hm& "Reading option '-verify' ...Unrecognized option 'verify'." pasted just before -i
[22:52:09 CEST] <chuprin_> ffmpeg version 3.1.4
[23:32:15 CEST] <Mad7Scientist> Does taking something that is h264 / AVC and recompressing it in mpeg2 affect the quality and size of the mpeg2 video?
[23:33:17 CEST] <Mad7Scientist> I went from 1080 youtube to -s 960x540 and it looks great
[23:33:22 CEST] <furq> compared to what
[23:33:29 CEST] <Mad7Scientist> to what I'm used to
[23:34:06 CEST] <Mad7Scientist> but I wonder if having it already compressed in the previous lossy format makes the mpeg2 compression require less of a bit rate
[23:34:58 CEST] <BtbN> it makes it lose quality
[23:35:13 CEST] <furq> if it does make it smaller then it's from quality loss, yeah
[23:35:30 CEST] <furq> if the source is youtube then it's probably been aggressively denoised
[23:36:32 CEST] <Mad7Scientist> At a certain distance nobody can really tell 1080p from 540p
[23:37:04 CEST] <furq> most people can tell blu-ray 1080p from youtube 1080p though
[23:37:05 CEST] <Mad7Scientist> But they may still be able to see the other things done to reduce bit rate that vary between formats
[23:37:17 CEST] <furq> it's very obvious with some sources
[23:37:21 CEST] <Mad7Scientist> right and they can see that from a distance
[23:38:18 CEST] <Mad7Scientist> I need an actual proper source of 1080p to experiment with
[23:40:38 CEST] <furq> https://media.xiph.org/video/derf/
[23:40:48 CEST] <furq> there are some 1080p rawvideo samples near the bottom
[23:45:51 CEST] <Mad7Scientist> thanks
[23:50:18 CEST] <Mad7Scientist> 40GB video clips!
[00:00:00 CEST] --- Mon Oct 24 2016