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

[burek]

[00:00:07 CET] <furq> it's a w3c thing
[00:00:12 CET] <leibnizzle> Completely forgot that existed, thanks so much
[00:16:19 CET] <klaxa> am i correct to assume that webrtc is based on neither tcp nor udp?
[00:16:43 CET] <furq> it runs on top of either
[00:16:55 CET] <furq> pretty much everything on the internet has to because that's what routers support these days
[00:17:09 CET] <klaxa> i once read something about "raw sockets"
[00:17:32 CET] <furq> that's why people have to implement sctp on top of udp, because routers will just block it
[00:17:47 CET] <klaxa> oh
[00:17:58 CET] <leibnizzle> udp lite is mainline linux now though so maybe it will open up
[00:18:00 CET] <furq> raw sockets are often blocked as well
[00:18:13 CET] <furq> except maybe ICMP
[00:18:33 CET] <klaxa> i see
[00:18:36 CET] <klaxa> thanks
[00:18:58 CET] <furq> a lot of routing protocols use them, but i imagine they're blocked for general internet traffic
[00:19:33 CET] <leibnizzle> they're used for other stuff than internet traffic too
[00:20:40 CET] <furq> stuff like that is fine for lan stuff where you can set your routers up appropriately
[00:20:46 CET] <leibnizzle> CAN traffic in cars for instance
[00:20:59 CET] <furq> but if you want to use something over the internet, generally you need to stick to tcp and udp
[00:21:16 CET] <leibnizzle> I really think that is bound to change at some point though
[00:21:24 CET] <leibnizzle> but that does seem to be a sad fact
[00:21:25 CET] <furq> i hope so because it sort of sucks
[00:21:47 CET] <furq> although everything seems to be going the other way
[00:22:00 CET] <leibnizzle> it just makes so little sense to protect the payload with a checksum
[00:22:05 CET] <furq> all the fancy new streaming protocols (if you can call them protocols) are implemented on top of http
[00:22:30 CET] <leibnizzle> Perhaps it is becoming more polarized
[00:22:36 CET] <leibnizzle> Because that does seem true
[00:22:58 CET] <leibnizzle> But at the same time, there's projects heading in way the other direction as well
[00:23:01 CET] <furq> thanks a lot, corporate firewalls
[00:24:03 CET] <leibnizzle> makes sense really because streaming a netflix movie and streaming the camera of the 18-wheeler in front of you to decide whether you should overtake or not are two pretty different things
[00:24:46 CET] <leibnizzle> and i'll tell you that I'd rather not do the latter with TCP :D
[00:25:14 CET] <furq> i've never dug too deep into this stuff but udp generally seems "good enough"
[00:25:40 CET] <leibnizzle> it's good enough but just fundamentally gross
[00:25:58 CET] <leibnizzle> imo anyway haha
[02:49:43 CET] <nichego> hello. is there an ffmpeg invocation that tells me whether a particular mp4 file uses edit lists or not?
[02:50:13 CET] <nichego> that information is not specified in 'ffmpeg -i' output. mediainfo is silent about it as well
[04:53:08 CET] <bornpilot> queston about sws_flags my options look something like this -sws_flags area -sws_flags +print_info -sws_flags -full_chroma_int for the sws_flag value does the - or + mean add or negate the option? or would this be simple by -sws_flags flagOptionValue
[04:54:46 CET] <bornpilot> related to this if I wanted to put this in filtergraph form would it be comma seperated vlaues i.e. sws_flags=area,print_info &
[05:00:43 CET] <furq> bornpilot: iirc it'd be -sws_flags +print_info-full_chroma_int
[05:03:57 CET] <bornpilot> furq thanks, so in the example what do the options + and - mean for the sws_flags value?
[05:04:14 CET] <furq> add and remove
[05:06:56 CET] <bornpilot> if no value is set for an sws_flags is it implied add or remove?
[06:46:02 CET] <UV> Hi. I'm following the compilation guide for ffmpeg on debian testing from here: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[06:48:09 CET] <UV> and I'm getting this error while making lib-x264: http://dpaste.com/3Q2HMJM
[06:48:32 CET] <UV> any idea why this wouldbe occuring?
[06:49:35 CET] <UV> this is on debian sid
[06:50:20 CET] <UV> sorry, I meant debian testing, not sid.
[06:50:59 CET] <furq> what's wrong with the ffmpeg in the repos
[06:53:00 CET] <UV> nothing, but I was trying to compile against the newest lib-x264
[06:53:41 CET] <UV> and trying to fix this error
[09:33:21 CET] <nirvanko> Hi everyone. top -H shows that ffmpeg has a lot of threads but only few of them are actually doing something for all others TIME+ is zero. Why?
[09:34:33 CET] <IamTrying> https://www.amazon.com/FFmpeg-Basics-Multimedia-handling-encoder/dp/1479327832/ref=as_sl_pc_ss_til?tag=ffmbas-20&linkCode=w00&linkId=LHB3XUX5YEPKCIPN&creativeASIN=1479327832 - Is this BOOK good? how to use the FFMpeg in Windows visual studio C++ or in C# which book covers somthing about it from build/compile
[09:39:46 CET] <IamTrying> do you know "Frantisek Korbel" ? just bought his book, but did he wrote in the book how can i use the FFmpeg in Windows visual studio C++ or C#?
[09:59:50 CET] <ahoo> hey there
[10:00:46 CET] <ahoo> when extracting audio via -c:a from a youtube video, will re-encoding that aac to mp3 cause a noticeable loss in quality?
[10:01:40 CET] <JEEB> -c:a copy you mean? yes, re-encoding it to a lossy format will incur loss. whether or not that loss will be notice'able is dependant on your parameters
[10:04:09 CET] <ahoo> yeah, c:a copy
[10:10:56 CET] <ahoo> ta
[10:11:12 CET] <xeche> eh? codec copy will re-encoding?
[10:11:18 CET] <xeche> uhhh.. english
[10:11:24 CET] <xeche> re-encode*
[10:11:55 CET] <xeche> i thought copy was a container only operation
[10:12:29 CET] <pano> Hi all
[10:23:26 CET] <pano> i have asked question yesterday... i get answer for it. Just in case anyone here need it :). The command should be: ffmpeg -i rtsp://{user}:{password}@{ip}:554/onvif1 -c copy -f ssegment -segment_time 20 -reset_timestamps 1 "capture-%03d.avi"  . The main difference is: " -reset_timestamps 1 " .
[10:23:31 CET] <markvandenborre> xeche: copy is a container only operation, but if you re-encode it afterwards from lossy aac to lossy mp3
[10:23:34 CET] <markvandenborre> ...
[10:24:02 CET] <markvandenborre> pano: cool, thx
[10:46:56 CET] <bencc> browsers support any sample_rate in mp3 and aac?
[10:47:10 CET] <bencc> or should I use 48000 for best compatibility?
[10:52:35 CET] <JEEB> xeche: no, he specifically asked if after -c copy re-encoding to MP3 would be lossy
[11:10:22 CET] <bencc> how can I get the container with ffprobe?
[11:10:36 CET] <bencc> like Matroska
[11:11:29 CET] <bencc> -show_format
[11:11:51 CET] <JEEB> yup
[11:11:55 CET] <JEEB> "format_name": "matroska,webm"
[11:11:55 CET] <bencc> thanks
[11:11:57 CET] <JEEB> in json
[11:12:27 CET] <bencc> do browsers support wav with adpcm_ms
[11:12:29 CET] <bencc> ?
[11:35:53 CET] <xeche> what does the "Speed" field signify when encoding
[11:36:41 CET] <xeche> playback speed * x = speed ?
[11:54:54 CET] <darsain> I'm  trying to create a scaling command that will downscale-only to a specific megapixel value. I have this:
[11:54:58 CET] <darsain> scale=min((921600/iw*ih)*iw, iw):min((921600/iw*ih)*ih, ih)
[11:55:14 CET] <darsain> but I'm getting "*iw was unexpected at this time."
[11:55:43 CET] <darsain> any pointers to what I'm doing wrong? :)
[11:57:54 CET] <iive> xeche: you mean the text on the status bar? yes it shows how faster/slower is the encoder compared to real time.
[12:02:14 CET] <xeche> iive: thanks. and the speed displayed at the end is the average speed compared to realtime playback then?
[12:02:40 CET] <iive> yes
[12:02:54 CET] <xeche> alrighty. sanity restored. :)
[12:04:33 CET] <iive> :D
[12:05:03 CET] <xeche> has anyone here ever been able to make hevc_qsv work via ffmpeg? (CLI or API)
[12:05:52 CET] <xeche> reading Intel's documentation, it looks like hevc codecs are not available via the community edition
[12:08:12 CET] <xeche> yeah, this is a dead end. Media Studio professional is $4000
[12:15:25 CET] <bencoh> $4000 to decode hevc in hw?
[12:25:12 CET] <xeche> bencoh: encode
[12:25:22 CET] <xeche> not sure if it makes a difference to be honest
[12:25:34 CET] <xeche> but their docs on how to integrate with ffmpeg is littered with "you need the professional version"
[12:28:37 CET] <jkqxz> What are you wanting to do with it?  The hardware encoder is not very good.
[12:30:58 CET] <xeche> that depends on you measure
[12:31:05 CET] <xeche> how you measure, rather
[12:31:27 CET] <xeche> libx265 (software) does not play nice with the CPU usage
[12:32:00 CET] <xeche> to answer your question; i want to encode an HEVC stream in real time
[12:35:05 CET] <jkqxz> And you don't care how good the result it?  Use H.264 instead.
[12:36:26 CET] <jkqxz> The hardware-only H.265 encoder on Intel (Skylake/Kaby Lake) is usable via VAAPI on Linux with the open source stuff, but it sucks.
[12:37:22 CET] <xeche> jkqxz: I assume your measurement is quality. And that's a very subjective thing, so it's impossible for me to know what you mean by "good"
[12:37:42 CET] <jkqxz> The proprietary Intel one has more magic (in software) which makes it better, but you end up trading off against CPU time again.
[12:40:02 CET] <jkqxz> I mean the quality of the output image at the same bitrate is no better than the H.264 encoder.
[12:41:15 CET] <jkqxz> In its favour, it easily manages >4K60 throughput using ~zero CPU.  If this is the only thing you care about, then it's awesome.
[12:47:18 CET] <xeche> jkqxz: it is very important in my use case.
[12:47:43 CET] <xeche> bandwidth and CPU usage is the priority, compared to near zero compression artifacts
[12:48:14 CET] <xeche> jkqxz: do you have any links to quality comparisons between 264 and 265?
[12:48:44 CET] <xeche> i find it hard to believe that the 265 hw encoder does no better than a sw 264 encoder
[12:52:12 CET] <jkqxz> Why?  A hardware encoder doesn't have any opportunity to do anything clever at all.  H.265 only gains over H.264 if you make use of the advanced features which require a lot more processing to squeeze value out of.
[12:52:38 CET] <jkqxz> Also I was comparing the Intel hardware-only H.264 and H.265 encoders.  x264 is better than either of those.
[12:53:29 CET] <xeche> jkqxz: to get an idea of what you mean by comparable quality and good quality
[12:53:44 CET] <xeche> and no, h265 by specification, does more than 264
[12:53:53 CET] <xeche> more passes, different algo, etc
[12:54:40 CET] <jkqxz> All of which you can ignore and still create a valid stream.
[12:54:57 CET] <xeche> then what you're saying is the QSV implementation is not standard compliant
[12:55:02 CET] <jkqxz> The use of features there completely depends on the encoder which is using them.
[12:55:55 CET] <jkqxz> What?  No.  The standard specifies how to decode the stream, it doesn't place any constraints on how you encode it.
[12:59:15 CET] <xeche> it appears you're right about that part
[12:59:22 CET] <xeche> at least according to wiki's write up on profiles
[12:59:53 CET] <xeche> so yes, then your argument holds; 265 may well perform equal to 264
[13:01:00 CET] <JEEB> he is correct, the specification is just notes what constitutes a valid bit stream in that format
[13:01:07 CET] <JEEB> it doesn't limit the encoder to do dumb or not dumb things
[13:01:11 CET] <jkqxz> Profiles just add additional constraints to the set of features you are allowed to use.  There is nothing which compels you to actually use them, though.
[13:01:29 CET] <JEEB> as long as you can decode what an encoder produces according to the specification, it is valid
[13:02:51 CET] <jkqxz> For example, you can make a trivial H.264 or H.265 encoder which encodes every macroblock as PCM.  It's not very useful (the output is bigger than the input), but it is valid.
[13:02:57 CET] <xeche> right. if i could actually make ffmpeg do the damned encodes, i could look for myself and compare the quality..
[13:03:22 CET] <xeche> jkqxz: point taken, technical terms aside.
[13:03:37 CET] <jkqxz> Are you on Linux?
[13:03:52 CET] <xeche> Windows. :P
[13:06:05 CET] <jkqxz> My condolences.  I have little clue, then.
[13:06:22 CET] <xeche> Selected rate control mode is not supported by QSV runtime. I'm going around in circles...
[13:06:51 CET] <nzbmets> Hi All, I'm having a problem compiling in chromaprint. Here's a trivial script to reproduce http://pastebin.com/s9afca2v . (It does not seem to be related to ticket #5997). I see no other open issue that may be related.
[13:07:03 CET] <nzbmets> any help appreciated
[13:07:33 CET] <jkqxz> I think you get that error if it doesn't load properly, since probing for a usable rate control mode with the encoder always fails if it isn't working.
[13:07:37 CET] <jkqxz> Does H.264 work for you?
[13:08:29 CET] <xeche> yeah, libx264 and h264_qsv both work
[13:09:32 CET] <jkqxz> Right.  The H.265 encode plugin really is required to get anywhere.
[13:09:58 CET] <xeche> indeed it is. not statically linked to ffmpeg for licensing reasons, i assume
[13:10:51 CET] <xeche> i do have that plugin installed, but I guess FFMPEG doesn't find it
[13:11:03 CET] <xeche> trial version of the "professional" whatever their tool is called
[13:12:02 CET] <xeche> ffmpeg -y -i MacGruber.mp4 -vcodec hevc_qsv -load_plugin hevc_hw -vcm 1 hevc_qsv.hevc
[13:12:11 CET] <jkqxz> Hmm.  On Linux I would suggest using strace to work out where it's looking for the plugin to load it.  Maybe there is something similar on Windows?
[13:12:51 CET] <xeche> does strace catch runtime linked libraries?
[13:15:23 CET] <xeche> QSV uses a frontend library, the mfx dispatcher, to pick implementations
[13:17:18 CET] <jkqxz> strace is below that sort of concern.  It just prints system calls, so you can watch for an open() with the name of the plugin file and see where it was looking for it.
[13:21:50 CET] <xeche> jkqxz: okay thanks. there is supposed to be something equivalent in WinDbg tools
[13:32:31 CET] <xeche> well, it finds the dispatcher, but the dispatcher is the only intel DLL i can see
[15:07:36 CET] <Tom_B_> hi all, I have a mpeg2-ts stream being written to a file continuously as a .ts  file, is it possible to use ffmpeg to periodically slice the video so only the last hour or last video remains to prevent the file growing in size or will changing the file as it's being written cause a problem?
[15:15:36 CET] <kerio> that's not how file descriptors work
[15:16:30 CET] <markvandenborre> Tom_B_: what you want is a way to make ffmpeg record one hour slices continuously
[15:16:34 CET] <kerio> you can't just make some other process seek
[15:16:50 CET] <markvandenborre> then handle the deletion of the old files externally
[15:16:50 CET] <markvandenborre> I guess
[15:18:00 CET] <Tom_B_> yes, you're probably right. I'm trying to implement a timeshift type feature on a live stream that's being recorded as a .ts file
[15:20:56 CET] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-ssegment
[15:21:05 CET] <furq> that'll split the output every hour
[15:21:14 CET] <furq> deleting everything else is probably doable with inotifywait or something
[15:21:30 CET] <furq> or just a cron job
[15:42:01 CET] <DHE> interestingly HLS is basically mpegts with a playlist file. you could probably abuse that as well. it has built-in rotation and stuff
[15:43:06 CET] <kerio> that... is a very good point
[15:43:07 CET] <DHE> including deleting the files
[15:43:21 CET] <bencoh> Tom_B_: if you're recording stream "as-is" you might want to have a look at multicat
[15:43:45 CET] <kerio> DHE: do you know if players accept mp4 in playlists rather than .ts
[15:43:47 CET] <bencoh> (assuming this is indeed a udp or rtp encapsulated stream)
[15:45:00 CET] <Tom_B_> I also have access to the raw data as it's received. I'm actually getting data from tvheaded using its bespoke HTSP protocol via a basic node.js interface I wrote
[15:45:23 CET] <DHE> kerio: officially no
[15:45:36 CET] <kerio> i didn't ask "is mp4 allowed in hls"
[15:45:39 CET] <kerio> :^)
[15:46:22 CET] <JEEB> fragmented ISOBMFF in HLS IIRC was recently added to the spec
[15:46:29 CET] <JEEB> which Apple implements
[15:55:57 CET] <furq> if "playlists" includes dash manifests then sure
[16:11:31 CET] <dudududu> hi i've been getting inflate returned errors when concatenating large list (3000) of pngs. any ideas for a solution? it causes pretty big frame skips heres a screenshot http://i.imgur.com/mC43T4Q.png
[16:13:51 CET] <JEEB> furq: https://tools.ietf.org/html/draft-pantos-http-live-streaming-20#section-3.3
[16:13:54 CET] <JEEB> HLS ;)
[16:14:11 CET] <furq> 14:43:45 ( kerio) DHE: do you know if players accept mp4 in playlists rather than .ts
[16:14:14 CET] <furq> i was responding to that
[16:14:28 CET] <furq> it's cool that it's supported in hls now though
[16:14:50 CET] <furq> maybe that means i'll be able to stop remuxing ts to mp4 in javascript, which is a concept that makes me feel ill
[16:14:56 CET] <DHE> unfortunately my players aren't going to be new enough to meet those criteria...
[16:15:38 CET] <JEEB> yeah, atm that is now only for iOS
[16:15:52 CET] <JEEB> on android thankfully you have exoplayer
[16:15:57 CET] <JEEB> I wonder if they added support already
[16:16:16 CET] <JEEB> on embedded things you're out of luck unless you're developing the thing :P
[16:20:22 CET] <__raven__> how to capture vbi data from a analogue capture card and save it to kind of teletext file?
[16:30:51 CET] <dudududu> would you guys happen to know how i can tell exactly what png cause the error here? http://i.imgur.com/TLB9FVe.png [png @ 0000000004682940]
[16:31:19 CET] <dudududu> i have them in a list of like 3000 so im trying to figure out which one is the problem
[17:32:02 CET] <sagerdearia> What video codec is commonly used to record video of practically exact pixel colors from Xorg desktop? I want to extract specific frames during recording of pixel animation to reproduce them elsewhere.
[17:34:28 CET] <kerio> it depends on how fast is your storage
[17:34:31 CET] <kerio> and how fast is your cpu
[17:36:23 CET] <Mavrik> yeah... huffyuv in RGB is usually resonable
[17:36:33 CET] <Mavrik> or losless x264rgb
[17:36:46 CET] <kerio> you mean ffvhuff
[17:37:02 CET] <kerio> is lossless x264rgb actually fast enough to do realtime?
[17:38:20 CET] <Mavrik> yeah
[17:38:28 CET] <klaxa> depends on your cpu and throughput, but on a reasonably modern machine, yes
[17:39:31 CET] <Mavrik> And I pretty much meant huffyuv :P
[17:40:11 CET] <kerio> it is ;o
[17:40:25 CET] <klaxa> on my laptop i get 25 fps at 3200x1800
[17:40:37 CET] <klaxa> with libx264rgb
[17:40:58 CET] <klaxa> ultrafast preset, lossless
[17:42:51 CET] <kerio> yea i'm getting a solid 30 at ultrafast
[17:44:37 CET] <DHE> Keridos: yeah, ultrafast is just that. but if you use a slower preset you'll get a smaller file size while still being lossless
[17:44:57 CET] <DHE> this is why disk throughput matters
[17:45:00 CET] <kerio> wrong nickname tho
[17:45:52 CET] <kerio> 100MB/s for a recording of a video tho
[18:02:55 CET] <rjp421> "-f flv 'rtmp://test:ing@media.whohacked.me/live/livestream flashver=FMLE/3.0\20(compatible;\20FMSc/1.0) live=1'" usually has worked, but now im getting "Problem accessing the DNS. (addr: test)" "rtmp://test:ing@media.whohacked.me/live/livestream live=1: Unknown error occurred"
[18:04:55 CET] <rjp421> with the latest ffmpeg-git nightly for linux 64bit
[18:07:24 CET] <rjp421> on centos6.7
[18:18:49 CET] <rhagu> Hi I would like to find out, whether ffmpeg on my ubuntu xenial machine supports multithreading, how can I do that?
[18:22:30 CET] <thebombzen> rhagu: lscpu
[18:22:38 CET] <thebombzen> if there is more than one "cpu" then yes
[18:24:10 CET] <rhagu> thebombzen the problem is not about the number of cpus, but quite some time ago, ubuntu packaged ffmpeg without multithreading support although it was already available upstream. I am curious whether ubuntu compiles ffmpeg with multithreading enabled at the moment
[18:24:33 CET] <Mavrik> uhh
[18:24:45 CET] <Mavrik> Whatever they package is probably obsolete and broken.
[18:24:53 CET] <Mavrik> I'd really really advise against using it :/
[18:24:58 CET] <Mavrik> Use static builds instead.
[18:27:14 CET] <thebombzen> by "ubuntu packaged ffmpeg" do you mean "ubuntu packaged libav"
[18:27:29 CET] <thebombzen> afaik debian derivatives still feel obligated to use the bad fork
[18:27:55 CET] <thebombzen> either way rhagu the solution 98% of the time is to build it yourself
[18:28:58 CET] <rhagu> thebombzen as far as I understand, ubuntu changed back to ffmpeg with 15.04
[18:30:46 CET] <thebombzen> huh. I didn't know that
[18:30:59 CET] <thebombzen> as for your original question, you could try to check the build flags
[18:31:12 CET] <thebombzen> afaik you disable threading with ./configure --disable-threads, so check for that flag somewhere
[18:33:05 CET] <rhagu> https://paste.ubuntu.com/23707021/ as --disable-threads is not mentioned, I guess it is disabled by noww
[18:39:26 CET] <furq> the recent ubuntu builds are fine afaik
[18:39:59 CET] <furq> 16.10 is using 3.0.5
[18:40:15 CET] <furq> presumably the same one as debian testing from a few months ago, which was fine
[18:40:43 CET] <furq> this is assuming you're using ubuntu 16.10 and not some LTS build from last century
[18:41:34 CET] <rhagu> furq 16.04
[18:41:52 CET] <rhagu> version 2.8.10
[18:41:53 CET] <furq> 16.04 is on 2.8.10 which is still usable
[18:42:27 CET] <rhagu> it is inside a lxc container, so I can switch to 16.10 if necessary, I want to use it as backend for emby media server
[18:42:30 CET] <furq> they should just be the packages from debian testing cut at a particular date
[18:42:38 CET] <furq> and those have been perfectly usable for a few years now
[18:49:36 CET] <darsain> how can I make -c:v libvpx-vp9 utilize the whole CPU? it sits at around ~30% currently. the whole command looks like this: http://pastebin.com/0DpzRkMQ
[18:51:16 CET] <furq> libvpx doesn't have frame multithreading, so you're limited by the resolution of the output
[18:51:29 CET] <furq> also i'm pretty sure some of those options shouldn't be used any more
[18:51:30 CET] <rjp421> ffmpeg wont parse the username part of the auth, "problem acccessing DNS addr user";  ./ffmpeg -loglevel info -re -i 'rtmp://jblive.videocdn.scaleengine.net/jb-live/play/jblive.stream' -vf "fps=24,scale=640x360,format=yuv420p" -c:v libx264 -profile:v main -level 30 -crf 23 -r 24 -g 48 -c:a copy -sn -f flv "rtmp://user:pass@media.whohacked.me/live/livestream flashver=FMLE/3.0\20(compatible;\20FMSc/1.0) live=1"
[18:51:39 CET] <furq> just -threads and -tile-columns are all you need now iirc
[18:52:04 CET] <furq> also -movflags faststart definitely doesn't do anything with webm output
[18:52:39 CET] <rjp421> i addes user/pass for auth if anyone can test that cmd
[18:53:12 CET] <darsain> furq: most of that stuff is just  copy pasted from recomendations in wiki and other documentation pages :) so there's no way how to speed it up?
[18:53:19 CET] <furq> darsain: http://comments.gmane.org/gmane.comp.multimedia.webm.devel/1937
[18:53:31 CET] <furq> judging by that it won't use more than 4 threads for 720p
[18:54:13 CET] <furq> and yeah a lot of information on libvpx is badly outdated
[18:55:12 CET] <furq> you can make it faster with -speed but you'll lose quality obv
[18:56:03 CET] <furq> maybe TD-Linux or someone else who actually uses libvpx can shed more light
[18:56:40 CET] <TD-Linux> darsain, you mean use multiple threads?
[18:57:24 CET] <darsain> TD-Linux: if it isn't doing so already, and that's why it only consumes 30% of my CPU atm, than yes
[18:57:34 CET] <TD-Linux> what is "30% of your CPU"
[18:58:08 CET] <TD-Linux> what resolution is this, how many cores do you have, how many is it using
[18:58:58 CET] <darsain> TD-Linux: its 854x480, cpu: https://i.imgur.com/YRl8orX.png
[18:59:50 CET] <TD-Linux> on windows is each of those boxes a thread? it does look odd then. you will probably only get 2 cores being used
[19:00:39 CET] <TD-Linux> but I would expect to see two at 100% and the rest at 0.
[19:00:40 CET] <darsain> I assume each of those boxes is a core, since its a 4 core CPU, and there are 4 boxes :)
[19:00:51 CET] <TD-Linux> also I don't know what -movflags faststart does for webm, if anything, and what's the -c:v copy for
[19:00:54 CET] <TD-Linux> *-c copy
[19:00:59 CET] <furq> yeah windows' thread scheduling is weird like that
[19:01:24 CET] <furq> idk if it's actually the scheduler or just task manager lying
[19:01:35 CET] <darsain> -c copy is to set all streams to copy unless overriden by subsequent -c: commands. I got it from docs
[19:01:46 CET] <furq> yeah that's fine
[19:01:51 CET] <furq> movflags is only for mov/mp4 etc
[19:01:58 CET] <furq> it does nothing for webm
[19:02:03 CET] <darsain> k, I'll remove that
[19:02:13 CET] <furq> and you should apparently remove frame-parallel now
[19:03:06 CET] <furq> but yeah for 854*480 output you won't get more than two or three threads being used
[19:05:31 CET] <markvandenborre> darsain: I checked if it would be possible at all to do live 720p on somewhat reasonable hardware
[19:05:35 CET] <markvandenborre> the answer was no
[19:05:41 CET] <markvandenborre> vp9 I mean
[19:05:44 CET] <darsain> so it's encoding at 10 fps while using only 30% CPU and I can't speed it up?
[19:06:07 CET] <markvandenborre> it's improved considerably between versions
[19:06:07 CET] <darsain> is the encoder designed like that? so weird
[19:06:11 CET] <furq> yeah this is why i don't use libvpx
[19:06:29 CET] <furq> you can speed it up with -speed but you won't be able to increase the cpu utilisation
[19:06:29 CET] <darsain> is there any other alternative to encode into VP9?
[19:06:38 CET] <furq> there's a commercial encoder but idk how good that is
[19:06:43 CET] <markvandenborre> haven't read your entire thing darsain, but vp9 encoding has only gained somewhat decent multithreading
[19:06:48 CET] <markvandenborre> recently
[19:06:53 CET] <furq> it's not really decent
[19:06:53 CET] <markvandenborre> and it's not very efficient yet
[19:07:01 CET] <markvandenborre> furq: +1
[19:07:19 CET] <furq> it won't be decent until it gets frame multithreading
[19:07:30 CET] <TD-Linux> the problem is that most video sites implement threading at a higher level
[19:07:30 CET] <markvandenborre> darsain: ronald bultje helped build something
[19:07:32 CET] <furq> slice multithreading sucks for anything other than realtime
[19:07:45 CET] <TD-Linux> so no one is really motivated to add it to libvpx
[19:07:54 CET] <furq> it works for youtube because they're processing thousands of videos at a time, and they're the biggest user
[19:07:57 CET] <TD-Linux> and ffmpeg doesn't support chunk threading
[19:08:01 CET] <markvandenborre> https://blogs.gnome.org/rbultje/
[19:08:16 CET] <furq> and they don't encode the vp9 copy until after the initial processing is done anyway
[19:08:19 CET] <TD-Linux> furq, no actually yt does really care about the speed to first playback. but they split the video into GOP-sized chunks and encode each separately
[19:08:27 CET] <furq> the speed to first playback is h264 though
[19:08:29 CET] <TD-Linux> they do this for the H.264 encodes too
[19:08:55 CET] <furq> the speed to first vp9 playback is irrelevant if there's already an h264 stream ready to go
[19:09:12 CET] <furq> and i'm pretty sure they do that first and then do the vp9 encodes after a certain view count is hit
[19:11:31 CET] <furq> i guess chunk threading is at least better than slice threading though
[19:12:37 CET] <jkqxz> If you want fast VP9 encode you basically have to go with hardware, though that of course compromises on the quality of the result somewhat.
[19:14:48 CET] <darsain> damn. I wish h265 had a wider adoption. I'm quite all right with its results, and speeds are also decent. but can't use it if I can't play the video afterwards :/
[19:16:36 CET] <furq> x264 is still pretty good
[19:17:56 CET] <darsain> but 265/vp9 cut almost half off of the filesize
[19:20:58 CET] <TD-Linux> at some point I'm going to have to write my chunk threading software
[19:22:00 CET] <rjp421> do i still have to rebuild ffmpeg manually with librtmp like http://sinclairmediatech.com/building-ffmpeg-for-adobe-media-server-akamai-auth/ for the adobe rtmp user auth support? or has that been included? cause im using the latest git nightly static binary on centos6 x64, and ffmpeg doesnt like my URI :(
[19:22:34 CET] <furq> the static builds have librtmp
[19:22:40 CET] <klaxa> TD-Linux: inspiration, starting point, place to look for design flaws maybe? https://github.com/klaxa/Distributed-encoding
[19:23:11 CET] <klaxa> wrote it a few years ago, it works generally (i think?) but it could use some polish and maybe even a general rewrite
[19:23:19 CET] <furq> surely the default port should be 31337
[19:23:52 CET] <klaxa> >python2
[19:23:57 CET] <klaxa> okay, definitely needs a rewrite
[19:24:17 CET] <furq> yeah you need to rewrite line 1 so it says #! /usr/bin/env python2
[19:24:24 CET] <furq> hth
[19:25:37 CET] <iive> can you put options there? For some reason I though that it doesn't work like this...
[19:25:52 CET] <furq> sure
[19:26:23 CET] <furq> you should use env for pretty much anything that's not /bin/sh
[19:26:50 CET] <c_14> You're allowed to put one option there. More than one is implementation defined.
[19:27:02 CET] <furq> http://vpaste.net/zQraf
[19:27:07 CET] <furq> because otherwise this will happen
[19:27:23 CET] <markvandenborre> jkqxz: do you have any info on hardware vp9 encoding using foss tools?
[19:27:39 CET] <rjp421> google shows this ffmpeg patch, but obviously it wasnt adopted? http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2013-January/058790.html :(
[19:27:43 CET] <markvandenborre> from my quite extensive research, I was under the impression that this was not possible
[19:27:55 CET] <furq> i don't think any consumer hardware supports it yet
[19:28:24 CET] <furq> although if it's anything like nvenc hevc, you might as well just use libvpx -speed 8 or whatever the fastest is
[19:30:04 CET] <TD-Linux> markvandenborre, yeah I think kaby lake will be the first intel chip with it
[19:30:21 CET] <furq> and yeah if you're going to buy new cpus, you might as well just buy cpus with enough grunt to do it in software
[19:30:58 CET] <markvandenborre> furq: :-)
[19:31:14 CET] <markvandenborre> nah, for now, we stayed with h264
[19:31:32 CET] <TD-Linux> I think in general a chunk encoder would pay well. but I am curious to see how the kaby lake encoder does
[19:31:33 CET] <markvandenborre> we have a budget to stay within...
[19:31:39 CET] <furq> is libvpx with -speed 8 still not fast enough
[19:31:58 CET] <furq> obviously you lose the bitrate benefit but it still satisfies the open-source requirement
[19:32:09 CET] <furq> or license-free, rather
[19:33:19 CET] <jkqxz> markvandenborre:  The Kaby Lake VP9 encoder is already usable with the open-source VAAPI driver.  There are some initial patches on the libav list <https://lists.libav.org/pipermail/libav-devel/2016-November/080821.html>; I'm intending to finish it off soon.
[19:33:48 CET] <furq> you can't buy kaby lake desktop cpus yet can you
[19:33:59 CET] <furq> although i guess it makes no difference if you only want the hw encoder
[19:34:15 CET] <jkqxz> Yeah, the laptop ones are identical for this purpose.
[19:34:25 CET] <furq> can you buy those yet if you're not an oem
[19:34:33 CET] <jkqxz> Yes, they've been out for a few months.
[19:35:28 CET] <markvandenborre> jkqxz: interesting, thank you for the info!
[19:35:51 CET] <furq> guess it's time to buy one of these then
[19:35:52 CET] <furq> https://www.youtube.com/watch?v=PjSThVKLbTo
[19:37:55 CET] <iive> rjp421: this is main in *-cvslog" maillist. patches are sent there when they are committed.
[19:38:03 CET] <iive> main/mail
[19:38:16 CET] <Andulien> Hello all, if I read right, this is the chat where one might be able to receive some support on ffmpeg questions.
[19:38:51 CET] <iive> Andulien: you can ask questions about ffmpeg. getting answers is ... definitely a posibility :D
[19:39:08 CET] Action: iive hides
[19:39:15 CET] <haroldp> trying to stream a 1280x720 webcam at a smaller size, but whatever I specify on the commandline (eg, -s 640x360), the video always seems to come out full size
[19:39:27 CET] <furq> haroldp: pastebin the full command line
[19:39:54 CET] <Andulien> Well let's try. I have ffmpeg installed on my Synology NAS for http streaming. Now the site has changed to https and as such I need to enable openssl and I don't know how.
[19:40:10 CET] <furq> you'd need to recompile
[19:40:20 CET] <haroldp> http://pastebin.com/AVJPuCFu
[19:40:21 CET] <furq> https://www.johnvansickle.com/ffmpeg/
[19:40:28 CET] <furq> or use those if there's one for the right arch
[19:41:10 CET] <furq> haroldp: you can't resize if you're copying the video stream
[19:41:30 CET] <furq> change -vcodec copy to -c:v lib264
[19:41:33 CET] <furq> change -vcodec copy to -c:v libx264
[19:42:16 CET] <Andulien> hmm.. ok, then I just need to figure out how to and what works for my Synology.
[19:42:22 CET] <haroldp> thanks.
[19:43:10 CET] <furq> Andulien: uname -m
[19:43:41 CET] <iive> c_14, furq : Do you have idea why "#!/bin/bash -c" doesn't work? i tried with --version and it did work, but -c causes delay and strange message...
[19:44:53 CET] <furq> bash -c expects the script as the next argument
[19:45:06 CET] <furq> i'm pretty sure the shebang pipes the script to stdin
[19:45:16 CET] <Andulien> armv5tel
[19:45:20 CET] <furq> it would be a nightmare if it passed it as an argument
[19:45:27 CET] <haroldp> hmmm, if I just drop -vcodec copy, it works (but looks awful).  If I add "-c:v libx264", I can't connect with VLC anymore
[19:45:30 CET] <iive> furq: i suspected that
[19:45:39 CET] <furq> Andulien: i'm not sure any of those builds will work with armv5
[19:45:45 CET] <furq> you might have to build it yourself
[19:46:24 CET] <furq> also you probably want gnutls rather than openssl, building with openssl was a nightmare last time i tried
[19:46:37 CET] <furq> haroldp: the default codec for flv is flv1 or some other awful ancient codec
[19:47:11 CET] <furq> i have no idea why it wouldn't work with h264, i assume that's what your source is and you said it worked fine when you were copying
[19:48:06 CET] <haroldp> yeah, src is "Stream #0:0: Video: h264 (Baseline), yuv420p(progressive), 1280x720, 15 tbr, 90k tbn, 180k tbc"
[19:48:50 CET] <c_14> furq: Are you sure? Because then #!/usr/bin/awk -f shouldn't work
[19:50:38 CET] <markvandenborre> haroldp: I guess the -crf bit too is not very useful with -c copy
[19:51:01 CET] <haroldp> that is true.
[19:51:17 CET] <haroldp> I was trying various settings
[19:51:26 CET] <Andulien> ok that's what I feared... I'll try to reach out then to the creator of the ffmpeg package in the hope that there will be an update in the future :(
[19:51:37 CET] <c_14> furq, iive: it does get the filename (tested with #!/bin/echo)
[19:51:53 CET] <furq> yeah i guess it does pass the filename
[19:51:56 CET] <furq> that makes more sense
[19:52:22 CET] <Andulien> and there is no way to enable this in the pipe I use as an option?
[19:53:19 CET] <markvandenborre> Andulien: building yourself (which is not trivial, but not impossible either) or asking the packager of this ffmpeg package are the only options as far as I can see
[19:53:39 CET] <markvandenborre> you might glean useful hints from the source package behind your current binary install maybe?
[19:54:01 CET] <haroldp> aaaand now neither works, heh
[19:57:33 CET] <Andulien> ok thank you.
[19:58:27 CET] <Andulien> The strange thing is when I uninstall the package on my NAS the ffmpeg option is still there to use so it seems that ffmpeg also does not completely uninstall right? Maybe there might be more it as well uff.
[19:59:41 CET] <chandoo> hi
[20:01:03 CET] <chandoo> i created png from video file and i deleted before and after the image and left with images what i want, i want to create gif file out of the images, do i need to put them in sequence starting from 0000.png?
[20:01:17 CET] <chandoo> my sequence starts from 0022.png it is not taking
[20:01:45 CET] <chandoo> it says no file found
[20:03:48 CET] <c_14> -start_image
[20:03:50 CET] <c_14> iirc
[20:04:19 CET] <c_14> -start_number
[20:04:35 CET] <c_14> so in your case -start_number 22
[20:07:19 CET] <furq> Andulien: whereis ffmpeg
[20:08:02 CET] <Andulien>  -sh: whereis: command not found
[20:08:24 CET] <furq> which ffmpeg
[20:23:21 CET] <Andulien> hmm seems to be another installation on
[20:23:23 CET] <Andulien> which ffmpeg /bin/ffmpeg
[20:24:36 CET] <Andulien> is there an easy way to remove?
[20:24:54 CET] <Andulien> maybe that's why it is not working, because it keeps referring to an older version?
[20:53:37 CET] <Andulien> so it seems on my NAS are two instances of ffmpeg installed. Is it possible to point in my pipe to a specific one or do I need to try to uninstall both and then have just one on the system?
[20:55:49 CET] <markvandenborre> Andulien: where is the other version of ffmpeg?
[20:56:12 CET] <markvandenborre> (apart from the /bin/ffmpeg)
[20:56:31 CET] <Andulien> Well I did a search:
[20:56:44 CET] <Andulien> find / -type d -name 'ffmpeg'
[20:58:12 CET] <markvandenborre> yes, so you found all directories named ffmpeg
[21:00:56 CET] <markvandenborre> ?
[21:03:44 CET] <markvandenborre> Andulien, the useful command was 'which ffmpeg'
[21:04:05 CET] <markvandenborre> that shows you the version of the executable 'ffmpeg' currently on your path
[21:04:24 CET] <markvandenborre> if you do a find, best to do at least a find / -type f -name 'ffmpeg'
[21:04:46 CET] <markvandenborre> and exclude /proc and other funky pseudo filesystems
[21:05:05 CET] <markvandenborre> though I'm not sure why you would want to do that
[21:05:36 CET] <markvandenborre> if you have trouble finding the executable, your only option really is to wait for an updated package from the mainainter of whatever distro is running on this synology
[21:06:14 CET] <markvandenborre> it's only when you've become quite a bit more fluent at *nix that building ffmpeg becomes an option
[21:06:53 CET] <Andulien> Well I'm guessing that Synology has it's own downsized ffmpeg package which is used for it's Video and Audio station. Additionally I have installed from the syno community an ffmpeg package that should have the ssl option enabled but it seems that ffmpeg is only pointing to the older package
[21:09:11 CET] <Andulien> ran your find and found the following
[21:11:09 CET] <Andulien> are those all different installs? Or just each grabbing their part. and is there a way when running pipe:// to use a specific one?
[21:18:56 CET] <ZexaronS> hello
[21:19:02 CET] <Andulien> chacka that was the solution....
[21:19:10 CET] <Andulien> I just had to point it to the right ffmpeg :D
[21:19:23 CET] <Andulien> Thanks for the help to troubleshoot it :D
[21:19:34 CET] <ZexaronS> I found VP9 encoding super slow and I have Intel 3820 at 3.6 GHZ quad core
[21:19:50 CET] <ZexaronS> so it's still kinda useless, I do all my YT downloads in WEBM now
[21:20:28 CET] <ZexaronS> I was kinda resisting to use webm over mp4 but I kinda got to the point It does seem to be up to 30% better saving cost compared to H264
[21:20:58 CET] <ZexaronS> So I'm still forced to do my own stuff in x264, it's not that much tho, a few vids here and there
[21:21:42 CET] <ZexaronS> I mentioned before how poor is the state of encoding industry, just because it's a niche doesn't mean it has to be totall shunned out
[21:22:00 CET] <JEEB> there's theoretical improvements and then there's actual encoders
[21:22:19 CET] <JEEB> like, VP9 is better than AVC, but libvpx as an encoder has some really bad issues
[21:22:34 CET] <ZexaronS> Does intel QuickSync do any improvement, since this is an older Sandy Bridge-E CPU without any iGPU ... maybe new Intels have better encoding support or some actual VP/H265 HW support ?
[21:22:54 CET] <ZexaronS> i mean VP9 there ...
[21:23:10 CET] <JEEB> and always remember that youtube is not really indicative of anything :P they have to drink their own kool-aid no matter what. and let's not forget that they never were about transcoding with quality in mind
[21:23:32 CET] <JEEB> and hardware encoders are hardware encoders, they might or might not match your use case
[21:23:47 CET] <JEEB> they are usually geared for low latency and being just fast enough
[21:24:14 CET] <ZexaronS> Youtube is very bad indeed, everything's ; I have a lot of experience with all kinds of DL utilities, but the ones that I settled for are CYS for Firefox addon and Chris PC Youtube Downloader, these two good ones have features I need and support DASH downloading
[21:24:18 CET] <JEEB> not good compression ratios or very high speeds
[21:24:33 CET] <JEEB> nobody told you about youtube-dl ? :P
[21:24:41 CET] <JEEB> which is a python-based command line tool
[21:24:43 CET] <ZexaronS> I think I heard it
[21:24:47 CET] <ZexaronS> But never got to it
[21:25:20 CET] <ZexaronS> So do you know the 2 I mentioned, does this phyton one have anything significantly better to offer ?
[21:25:42 CET] <ZexaronS> One thing would be to download a custom list of URLs with a pre-defined FMT code
[21:25:48 CET] <JEEB> no I do not, because all I need are the videos downloaded. it can download the DASH fragments and put them together with ffmpeg
[21:26:04 CET] <JEEB> and yes, it can list formats and download the ones you need - it even has rules I think
[21:26:06 CET] <ZexaronS> I have some stuff I'd like to get down at 360p Webm Dash i think the fmt is 245
[21:26:42 CET] <JEEB> anyways, yes - libvpx is slow as molasses (and has bad psychovisual optimizations and rate control)
[21:26:50 CET] <JEEB> talking about VP9 that is
[21:27:19 CET] <JEEB> although I think partially it might be because -threads 0 means -threads 1 @ libvpx, so you might want to put -threads XX after -i and see if that improves at all
[21:27:35 CET] <JEEB> where XX is some random number of threads you want the encoder to use
[21:28:01 CET] <ZexaronS> oh
[21:29:42 CET] <ZexaronS> also long videos sometimes have many hours of delay for webm conversion, only mp4, i thought it was a bug at first
[21:34:49 CET] <JEEB> well lol, not surprising :P
[21:35:08 CET] <ZexaronS> speaking of youtube weirdness, I really don't like the whole gui terminology of resolution, it means nothing at all, and most videos that don't even have the proper resolution just get encapsulated and only after you download them you see the true resolution with mediainfo
[21:35:10 CET] <JEEB> even with their encode-in-parts thing libvpx is much slower
[21:36:01 CET] <ZexaronS> the whole 480p 720p 1080p thing ... this is some marketing hdtv terminology that has little use for techical stuff
[21:36:16 CET] <rjp421> https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=723 if ffmpeg includes the rtmp user-auth patch, why cant it parse -f flv rtmp://user:pass@server/app/stream ? http://pastebin.com/raw/Wz2DwQtp i get "Problem accessing the DNS. (addr: user)"
[21:37:17 CET] <pbos> ZexaronS: Got any better terms?
[21:37:31 CET] <JEEB> rjp421: did you quote the argument properly? :P
[21:37:40 CET] <ZexaronS> this is like the words choice for youtube were there's ... as youtube targets the most support in codecs/audience, sites like twitch tv could be more suited for such terminology they could have a reason to limit broadcasters to these exact true 16:9 resolutions (divisable by 8)
[21:37:41 CET] <pbos> To play devil's advocate, with all the 720p and 1080p buzz I think those are more commonplace than anything else
[21:37:46 CET] <JEEB> ZexaronS: 1080p et al are actual resolutions tho :P
[21:37:53 CET] <ZexaronS> words .. i meant worst
[21:37:57 CET] <rjp421> JEEB, with single quotes, yes.. its in the paste
[21:38:05 CET] <JEEB> "2K" and "4K" is where stuff got bad
[21:38:21 CET] <JEEB> because 1920x1080 isn't 2K wide, and neither is 3840x2160 4K wide
[21:38:30 CET] <JEEB> marketing, ho
[21:38:30 CET] <ZexaronS> JEEB, it doesn't mean anything really, okay, I have here 1080p at 25 kb/s ... good luck
[21:38:37 CET] <ZexaronS> and 5 fps
[21:38:39 CET] <ZexaronS> hah
[21:38:44 CET] <JEEB> yeah, sure - it has nothing to do with the quality of a thing
[21:38:56 CET] <pbos> JEEB: 1920*1080/1000 is >=2k :|
[21:39:16 CET] <JEEB> it just tells you the resolution, which is what those numbers are supposed to tell you in height
[21:39:28 CET] <pbos> that'd make the other one 8k
[21:39:33 CET] <pbos> I know nothing
[21:39:53 CET] <ZexaronS> Because the wide public won't be respecting the HDTV bitrate standards, so why use HDTV monikers, it's very confusing and the actual quality is varies extremely
[21:40:24 CET] <pbos> ZexaronS: What do you propose? res at ssim?
[21:40:35 CET] <pbos> :)
[21:42:11 CET] <ZexaronS> Well, something else, actual bitrate along with the resolution would help, or some kind of GUI meter, like the signal meter on a phone, customized per resolution according to HDTV standard, if a 1080p video has below 1000 kb/s that would be pretty low red bar sign
[21:42:24 CET] <JEEB> "HDTV bit rate standards"
[21:42:25 CET] <JEEB> pfft
[21:42:34 CET] <JEEB> as if there are such things :P
[21:42:42 CET] <ZexaronS> well if they want to use hdtv resolutuon monikers
[21:42:57 CET] <ZexaronS> or get rid of them and show full resolution
[21:42:58 CET] <JEEB> there are maximum bit rates over buffer in video standards' levels
[21:43:31 CET] <rjp421> http://blog.mediacoderhq.com/h264-profiles-and-levels/
[21:43:40 CET] <kurufu> 1080p video of nothing happening would be just fine at <1000 kb/s
[21:43:51 CET] <JEEB> but that's just the maximum values for a decoder that says it supports that level
[21:44:06 CET] <DHE> There's also a summary on the wikipedia page for H264. easy to remember and find
[21:44:25 CET] <ZexaronS> JEEB, i mean broadcast standards, they do have bitrates defined
[21:44:29 CET] <ZexaronS> hdtv broadcast
[21:44:37 CET] <JEEB> ZexaronS: broadcast standards have maximum bandwidth limits
[21:44:49 CET] <JEEB> MAXIMUM that can be transferred
[21:44:52 CET] <JEEB> :P
[21:45:03 CET] <JEEB> be it DVB/ATSC/ISDB
[21:45:20 CET] <DHE> broadcast are inherently constrained by the frequency and QAM settings they are transmitted through. though historically they are wide enough to allow MPEG-2 based 1080i
[21:45:21 CET] <rjp421> ZexaronS, for reference https://support.google.com/youtube/answer/2853702 for yt live
[21:48:50 CET] <DHE> dealing with broadcast TV, can confirm bitrates are all over. loosely speaking some providers will up the bitrate for sports channels, but there's no strict rules
[21:49:27 CET] <ZexaronS> here's an example here from my isp http://pastebin.com/ctLQtpP2
[21:49:30 CET] <JEEB> yeah, you just have the maximum bandwidth for all of your muxes
[21:49:40 CET] <JEEB> and then you fit as many or as few as you want in there
[21:49:52 CET] <pbos> DHE: Not many samples, but I've seen extreme quantization in HDTV Sports
[21:50:18 CET] <ZexaronS> rjp421, yes I saw those, but are those Youtube's own or have some similarity to hdtv =
[21:50:19 CET] <pbos> Almost like the ball/handegg is a macroblock
[21:50:19 CET] <ZexaronS> ?
[21:51:02 CET] <DHE> pbos: no, I don't have a lot of samples either. and frankly people do horrible things like put interlaced SD through an upscaler to 720p and call it good
[21:51:06 CET] <rjp421> ZexaronS, not sure, but i assume they are targeting the standards
[21:51:11 CET] <ZexaronS> I just remember i saw once some broadcast papers and had some bitrates in, maybe just ITU recommendation
[21:51:13 CET] <pbos> DHE: Technically HD, right?
[21:51:27 CET] <DHE> pbos: sure, let's go with that. whatever helps them sleep at night
[21:51:38 CET] <JEEB> ZexaronS: all broadcast and video format specs usually mention maximum bandwidth over a buffer
[21:51:49 CET] <pbos> FWIW a lot of video chat apps switch over to HD before the bitrates on HD look better than VGA
[21:51:52 CET] <JEEB> that's the maximum and how you use your bandwidth is up to them :P
[21:51:56 CET] <ZexaronS> like 1080p at 8000 kb/s ... 720p at 4000 .... or maybe I read that on youtube
[21:52:08 CET] <rjp421> s/standards/most commonly supported formats/
[21:52:54 CET] <JEEB> for example tokyo MX used to have a single higher bit rate 1080i channel in its ISDB-T mux, but now it has a lower bit rate 1080i channel and the rest of the bits get used onto a separate 480i mux :P
[21:53:24 CET] <rjp421> i would expect youtube formatted shit to play on a smart tv etc
[21:53:45 CET] <ZexaronS> but MPEG-TS is still MPEG2 ?
[21:53:53 CET] <JEEB> container
[21:53:57 CET] <JEEB> vs video or audio format
[21:54:01 CET] <ZexaronS> ah sorry
[21:54:03 CET] <DHE> MPEG-TS is a container. it typically holds H264 or MPEG2, at least in the broadcast world
[21:54:06 CET] <JEEB> MPEG-2 Systems (H.222) contains MPEG-TS and MPEG-PS
[21:54:27 CET] <ZexaronS> I meant, yes, they moved from MPEG2 to MPEG4 maybe that's why they moved 1080i to lower bitrate ?
[21:54:35 CET] <JEEB> no
[21:54:35 CET] <pbos> Recommended rates make no sense if you don't include the codec
[21:54:43 CET] <ZexaronS> i mean AVC not MPEG-v4
[21:54:55 CET] <DHE> well, yes. 5.5 megabits of video in H264 is watchable
[21:55:20 CET] <DHE> and the industry calls it MPEG4 even though it's MPEG4-part10 (or H264 to most people)
[21:55:40 CET] <pbos> Also we're way skewed samples, maybe most people are fine with more quantization than us.
[21:56:00 CET] <JEEB> anyways, minimum rates really don't make much sense in the great scale of things. people would just stuff their streams if there were such requirements or something :P
[21:56:24 CET] <ZexaronS> DHE... a clusterfuck as always
[21:56:46 CET] <JEEB> you'd have to standardize a whole encoding chain and in that case you'd probably just want to use something else than a static minimum bit rate
[21:57:02 CET] <DHE> yeah, minimum rates are for people who have CBR issues. I avoid them and even raise the -qmin a little bit
[21:57:15 CET] <ZexaronS> But not that of a big deal, I'm more pissed at 16:9 taking over 16:10 in the PC industry
[21:59:10 CET] <rjp421> some devices are picky about the stream settings, be careful. for example yt says to have keyframes every 2 or 4s for best results... i prefer 24 fps with 48 gop
[21:59:53 CET] <ZexaronS> with MPEG-v4 i mean the "Visual" one, i see now it's MPEG4-Part2
[22:00:03 CET] <rjp421> using 25 or 29.97 or 30fps only gave a black video on ustream and playing back on android
[22:00:32 CET] <JEEB> yes, MPEG-4 Part 2 was the one where they let theoretical people have all the things they wanted to play with
[22:00:42 CET] <ZexaronS> But I'm pleased they're getting rid of uneven framerates in newer connector standards
[22:01:07 CET] <JEEB> hint: most features were not used in the end because they were overcomplicated and didn't actually bring the compression benefits
[22:02:32 CET] <ZexaronS> so VP9 is the answer to all these ITU/IEC weirdness ... I guess it makes sense now
[22:02:39 CET] <JEEB> wat
[22:02:57 CET] <JEEB> no, AVC was the thing that then improved on the previous stuff
[22:03:04 CET] <JEEB> because MPEG-4 Part 2 didn't work :P
[22:03:14 CET] <JEEB> (hint: you can see which formats ITU-T took in as well)
[22:03:19 CET] <ZexaronS> the EU borecraucy making "standards" on paper without actually having any programming skills to create an encoder
[22:03:27 CET] <JEEB> ...
[22:04:37 CET] <JEEB> ok, so let me set the stage a bit more correctly. HEVC standardization mailing list is open for everyone to register and even an idiot like me is on that list. their documents are all open.
[22:04:42 CET] <DHE> "oh they'll make hardware encoders and it won't be an issue"  (I imagine someone said)
[22:04:45 CET] <ZexaronS> I was quite shocked when I found out that the H264 is only a specification on paper, without any code, and that x264 is just some 3rd-party group that made an encoder supposably more or less according to the specification
[22:04:56 CET] <DHE> ZexaronS: there is a reference decoder
[22:05:02 CET] <JEEB> there's a reference decoder and encoder
[22:05:07 CET] <JEEB> for both AVC And HEVC
[22:05:21 CET] <JEEB> how the hell else could they test their improvement theories!?
[22:05:42 CET] <ZexaronS> but then nobody uses the references in practise right ?
[22:05:43 CET] <JEEB> and how the hell do you think did they get their "this many % of theoretical improvements" (based on reference encoder results)
[22:06:04 CET] <JEEB> ZexaronS: well x265 for example is based on the reference encoder code, except it is made faster
[22:06:23 CET] <JEEB> (and it takes shortcuts of course in order to be faster)
[22:06:44 CET] <JEEB> and I bet quite a few other commercial HEVC encoders started off by forking HM
[22:07:12 CET] <ZexaronS> VP9 comment ... JEEB, I meant all the war between codecs it was widely reported
[22:07:16 CET] <ZexaronS> with google in the mix
[22:07:33 CET] <JEEB> but yes, the idea of a reference encoder and decoder package is to validate ideas, not to be production ready. if it is production ready, that's of course good - but it shouldn't be a requirement on a video format development thing
[22:07:38 CET] <ZexaronS> and with royalties
[22:07:57 CET] <JEEB> ZexaronS: let me get back to that. regarding "how bad the standardization stuff is".
[22:08:08 CET] <JEEB> because while JCT-VC mailing list and document archives are open
[22:08:14 CET] <JEEB> you know how Google did VP9?
[22:08:26 CET] <JEEB> behind closed doors and I don't think anyone could contribute from the outside
[22:08:51 CET] <JEEB> it also lacked a specification at all until like september, 2016
[22:09:05 CET] <JEEB> because that's when the google person at VDD said they had made one
[22:09:08 CET] <JEEB> and got applause
[22:09:58 CET] <JEEB> literally the only thing going for VP9 is that it's pretty much a slightly modified copy of HEVC and that el GOOG says it's royalty-free
[22:10:20 CET] <ZexaronS> Well, see this is the weird thinking, it's not required, well, the market will eventually, they produce a specification, then they say it's not required to be production ready, that's their own thing they made up, everyone's going to move to VP9 and for whom will they be creating an encoder for, if it's for profit, I guess not, I guess it's just a boondoggle to get some "scientific progress" to spend money in EU borecraucy so they
[22:10:20 CET] <ZexaronS> get taxpayer funding lol
[22:10:48 CET] <ZexaronS> or what
[22:11:16 CET] <ZexaronS> SO the whole opening up is because youtube/google wouldn't pay the royalty ?
[22:11:24 CET] <JEEB> no?
[22:12:18 CET] <ZexaronS> I meant to say, I didn't know HEVC is all open now, it supposed to be closed source right? --- but because YT wouldn't support it any other bailed out, they had to open it up, so is there still royalty now ?
[22:12:22 CET] <JEEB> no?
[22:12:33 CET] <JEEB> both AVC and HEVC are fully open source as far as the reference implementations go
[22:12:39 CET] <JEEB> and both AVC and HEVC are freely available specifications
[22:12:50 CET] <JEEB> also they always were
[22:13:43 CET] <ZexaronS> Maybe I was in another dimension some years ago, or maybe you don't remember the royalty war?
[22:13:44 CET] <JEEB> also royalties are a whole separate subject from the actual specs. MPEG-LA is completely separate from MPEG (part of ISO/IEC).
[22:14:17 CET] <JEEB> there was no royalty war, the latest royalty thing I remember was HEVC getting raped by some of the corporations that designed it
[22:14:23 CET] <pbos> open spec doesn't mean royalty free, but ianal
[22:14:30 CET] <JEEB> well, d'uh
[22:14:34 CET] <ZexaronS> Yes see how it's confusing, that's why I asked if google went on to make VP9 because of this weirdness from international organizations
[22:14:35 CET] <pbos> I believe hevc have multiple patent pools
[22:14:59 CET] <JEEB> pbos: three things which is what I mean with the whole rape business by the suits in the companies
[22:15:16 CET] <JEEB> there's MPEG-LA (reasonable'ish), HEVC Advance (lol bring me the pop corn) and Technicolor
[22:15:24 CET] <ZexaronS> VP9 slightly modified, how is that possible ... I guess because it's the specification it self was open?
[22:15:46 CET] <pbos> ZexaronS: vp9 isn't really based on hevc as far as I'm aware
[22:15:49 CET] <JEEB> ZexaronS: google went to make VP9 because they knew VP8 was a modified AVC and HEVC was being designed
[22:15:58 CET] <JEEB> so they needed a better format
[22:16:18 CET] <JEEB> pbos: I'm pretty darn sure they looked over the fence :P 64x64 blocks and all that other jazz.
[22:17:16 CET] <pbos> JEEB: larger block sizes when hdtv etc is getting more popular doesn't seem like a shocker to me
[22:17:55 CET] <pbos> also not sure if either vp9 or hevc were first with that, I wouldn't be surprised if academia touched it before
[22:17:56 CET] <JEEB> it's not a shocker, but just look at the VP9 design and there are plenty of similarities with some differences in implementation (sometimes just not to use something described in a related patent)
[22:18:07 CET] <ZexaronS> I'm thinking why doesn't some private company make their own codec and an encoder/decoder ready to use for production ... without this back and forth and with clear and simple terminology
[22:18:20 CET] <JEEB> oh companies have tried that
[22:18:31 CET] <JEEB> but usually they end up copying standard formats
[22:18:32 CET] <JEEB> badly
[22:18:46 CET] <JEEB> what do you think VP8 was if not On2's child :P
[22:18:55 CET] <JEEB> On2 was then bought by el GOOG
[22:19:52 CET] <JEEB> anyways, the net positive from the fact that HEVC got pretty much rolled into the dirt by some of its creators with regards to royalties is that we got the AOM thing
[22:20:19 CET] <JEEB> so at the very goddamn least we don't have the next-gen thing being developed by a single entity behind closed doors (hi Google!)
[22:20:57 CET] <JEEB> because with a single entity you have that single entity's business needs controlling the implementation and everything around it
[22:21:07 CET] <JEEB> you can see that with libvpx
[22:21:21 CET] <JEEB> rate control? youtube doesn't need it, goes out
[22:21:35 CET] <JEEB> psychovisual optimizations? not a priority
[22:21:53 CET] <JEEB> frame threading? we encode GOPs separately so not needed
[22:22:47 CET] <JEEB> one of the original people behind VP9 did make a closed source encoder for VP9 that seems better than libvpx, just to show that it's not the format
[22:23:05 CET] <JEEB> (and to of course try to make a living)
[22:23:47 CET] <JEEB> https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-2/
[22:25:02 CET] <rjp421> JEEB, i found http://sinclairmediatech.com/building-ffmpeg-for-adobe-media-server-akamai-auth/ and http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2013-January/058790.html  im using the latest git nightly static binary on centos6 x64... is there some way to narrow down the cause? i tried installing librtmp and librtmp-devel, even though im using the static build, and it shouldnt matter..
[22:25:26 CET] <JEEB> rjp421: installing any external libraries most certainly won't help you :P
[22:26:46 CET] <rjp421> i was thinking maybe i had too old a version, or was missing it.. but that shouldnt matter using the static build, i thought
[22:26:57 CET] <ZexaronS> .. AOM? ... need to look that up
[22:27:32 CET] <JEEB> rjp421: are you sure you're providing it the authentication parameters correctly?
[22:27:36 CET] <pbos> ZexaronS: Alliance for Open Media
[22:27:52 CET] <JEEB> ^ a bit of a misnomer, but still a very good thing
[22:28:01 CET] <pbos> ZexaronS: Their effort is to make the nextgen codec a joint-effort one, it merges VP10, Thor and Daala efforts
[22:28:06 CET] <pbos> iirc it's based on VP10
[22:28:08 CET] <JEEB> yea
[22:28:15 CET] <JEEB> they forked the VP10 code base and are improving it
[22:28:23 CET] <ZexaronS> JEEB, wow, so VP9 isn't even meant for much only what youtube datacenters need
[22:28:23 CET] <pbos> adding ideas from Thor/Daala
[22:28:25 CET] <JEEB> or well, it became the current VP10 code base I guess?
[22:28:48 CET] <pbos> ZexaronS: We use it as a realtime codec in webrtc
[22:29:00 CET] <JEEB> thor was the thing that caught me by surprised, and the fact that cisco sent people over to VDD in '15
[22:29:11 CET] <JEEB> like, cisco sending actual video format people
[22:29:13 CET] <rjp421> JEEB, user/pass is valid atm for this testing.. and thats a cmd line i copies out of an old bash_history, where i know it was working (on the same os)
[22:29:31 CET] <rjp421> im not sure what else is different, that could cause this
[22:29:43 CET] <JEEB> so did you have your full command line log somewhere posted?
[22:30:05 CET] <pbos> ZexaronS: https://aomedia.googlesource.com/aom/ fwiw
[22:30:26 CET] <rjp421> JEEB, http://pastebin.com/raw/Wz2DwQtp
[22:30:27 CET] <ZexaronS> so AOM will support a codec that has varius niches in mind ?
[22:30:46 CET] <pbos> ZexaronS: Stakeholders for it have both realtime and YouTube in mind at least
[22:30:53 CET] <JEEB> well, dunno if niches, but at least its design and implementation is not controlled by a single entity
[22:30:55 CET] <ZexaronS> i mean, ... not purposelly denying some features to be at least somewhat good
[22:31:00 CET] <pbos> I'm not closer to it in terms of that.
[22:31:18 CET] <pbos> ZexaronS: I doubt that was done with VP9 either, prioritizations might have been different though
[22:31:28 CET] <pbos> you can't throw all features into a codec and prioritize everything
[22:31:33 CET] <pbos> assume good faith
[22:31:35 CET] <JEEB> libvpx is the thing that got most of the issues, not VP9
[22:31:44 CET] <JEEB> as the blog entry I linked noted
[22:32:04 CET] <JEEB> usually people have issues with libvpx, not the actual video format. the problem is that libvpx is pretty much the only VP9 encoder around.
[22:32:43 CET] <JEEB> and libpvx revolves around el goog of course. and what I'm happy about is that libaom revolves just a wee bit less around el goog, although el goog is still probably the biggest contributor
[22:33:04 CET] <ZexaronS> but youtube isn't using VPX right ?
[22:33:17 CET] <ZexaronS> ah revolves around them ..
[22:33:28 CET] <pbos> ZexaronS: YouTube uses libvpx
[22:33:31 CET] <iive> what else is there to encode vp9?
[22:33:32 CET] <ZexaronS> so it's only meant to work for youtube  and what they need
[22:33:42 CET] <JEEB> iive: eve by BBB, but that's not out there
[22:33:45 CET] <ZexaronS> ah that really explains it now holy crap
[22:33:53 CET] <JEEB> business needs 101 :P
[22:33:58 CET] <pbos> ZexaronS: As does Chrome and Firefox, fwiw.
[22:34:25 CET] <JEEB> if you don't need XYZ for business, it's not gonna get done unless there's free time and no bigger priorities
[22:34:37 CET] <ZexaronS> Why don't we, FFMPEG people come up with something of our own then ...
[22:34:52 CET] <JEEB> BBB did, but since he wants to make a living out of it it's closed source :P
[22:35:00 CET] <JEEB> (it's the thing I linked)
[22:35:23 CET] <ZexaronS> where, i was in batroom in the middle ...
[22:35:32 CET] <JEEB> just scroll up :P
[22:35:43 CET] <JEEB> the blogs.gnome.org one
[22:35:52 CET] <ZexaronS> but it's not that, it's that Hexchat doesn't highlight urls
[22:36:04 CET] <JEEB> just ctrl+F then
[22:36:06 CET] <JEEB> xchat had that
[22:36:17 CET] <JEEB> and hexchat is a fork of that :P
[22:36:23 CET] <ZexaronS> Ronald guy?
[22:36:26 CET] <JEEB> urd
[22:36:28 CET] <JEEB> yes
[22:37:15 CET] <JEEB> rjp421: well the best I can tell you is that you could try doing the same with -v debug
[22:37:25 CET] <JEEB> it will spam you a lot more but you should get a bunch more logging
[22:37:41 CET] <rjp421> ty, ill give it a shot
[22:53:23 CET] <rjp421> JEEB, can i output this to a file? or even better, along with the colors so its easier to follow
[22:55:25 CET] <JEEB> "2> ffmpeg.log" at the end
[22:55:37 CET] <rjp421> ty again
[22:55:42 CET] <JEEB> that redirects stderr (which is where ffmpeg cli outputs) to a file
[23:05:52 CET] <rjp421> JEEB, 3.2MB txt :( https://media.whohacked.me/files/ffmpeg-rtmpauth.log
[23:06:32 CET] <JEEB> wow, the rtmp demuxer sure is verbose
[23:06:40 CET] <JEEB> might want to use a file as input for testing purposes
[23:07:25 CET] <rjp421> everything was green except for the "Problem accessing the DNS. (addr: user)"
[23:07:29 CET] <rjp421> ok, will do
[23:07:58 CET] <JEEB> see the parsed protocol, host and app thing :P
[23:14:31 CET] <ZexaronS> Found out I forgot to add moovatom faststart for all my encodes for the last ... year or so ... gah
[23:15:19 CET] <ZexaronS> can moovatom be added ontop without reencoding ?
[23:19:46 CET] <JEEB> ZexaronS: it's there already :P just at the end. and yes, you can do -movflags faststart with a -c copy run
[23:21:19 CET] <salviadud> Hi there, I'm having trouble with ffmpeg right now...
[23:21:32 CET] <salviadud> It complains about broken ffmpeg default settings detected
[23:21:58 CET] <ZexaronS> cool thanks
[23:22:04 CET] <salviadud> error while opnening codec for output stream #0.0 - maybe incorrect paramters such as bit_rate, rate, width or height
[23:22:36 CET] <salviadud> codec rate differs from container framte rate
[23:22:45 CET] <salviadud> frame *
[23:23:42 CET] <salviadud> How do I create a preset?
[23:23:49 CET] <salviadud> for libx264?
[23:25:07 CET] <ZexaronS> emm, container's framerate, i don't think that exists
[23:25:39 CET] <salviadud> dam
[23:25:46 CET] <salviadud> I'm screwed I guess
[23:26:04 CET] <ZexaronS> just post the details of your command
[23:26:11 CET] <ZexaronS> what OS are you working with
[23:26:18 CET] <salviadud> it's slackware
[23:26:23 CET] <salviadud> an old linux machine
[23:26:44 CET] <ZexaronS> Well, I have no idea if ffmpeg will even run over there, sorry I'm a Windows guy
[23:26:44 CET] <salviadud> It's not connected to my network right now
[23:26:58 CET] <ZexaronS> It doesnt need any network tho
[23:27:08 CET] <salviadud> for me to post the command
[23:27:14 CET] <salviadud> it be easier for me to connect to it
[23:27:22 CET] <ZexaronS> how can you chat here?
[23:27:26 CET] <salviadud> well, I'm gonna try something different...
[23:27:34 CET] <salviadud> I'm not chatting via that computer
[23:28:09 CET] <kepstin> if you're getting that 'broken ffmpeg default settings detected' message, it usually means your ffmpeg is out of date
[23:28:26 CET] <kepstin> but if you could get actual copy/paste of the command line and the output, that would make it easier to help
[23:28:46 CET] <salviadud> It is actually
[23:28:53 CET] <salviadud> ffmpeg version 5
[23:29:08 CET] <salviadud> I might just need to compile an older version of h264 then
[23:29:29 CET] <kepstin> well, that won't fix the fact that you're using broken ffmpeg default settings - it just won't complain about them
[23:29:45 CET] <salviadud> good enough for me, hehe
[23:29:59 CET] <kepstin> you should probably just try getting a static ffmpeg build of a newer version, and use that
[23:30:46 CET] <salviadud> I'm trying out something that worked back in 2009
[23:31:00 CET] <salviadud> I guess libx264 got too advanced
[23:31:15 CET] <ZexaronS> the syntax has changed in ffmpeg since yes
[23:31:25 CET] <ZexaronS> bt I kinda wasn't much of a user back then
[23:31:37 CET] <ZexaronS> unfortunately documentation is all outdated
[23:31:57 CET] <salviadud> Maybe I'll get lucky
[23:32:08 CET] <salviadud> I was trying x264 from 2016
[23:32:14 CET] <salviadud> I'm gonna go 2011
[23:33:58 CET] <salviadud> fails just the same...
[23:33:59 CET] <salviadud> grrr
[23:49:49 CET] <leibnizzle> Anyone know of any studies on the burstiness of bit errors over (non-wireless) IP?
[00:00:00 CET] --- Fri Dec 30 2016