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

[burek]

[00:00:26 CEST] <furq> well yeah they're both sharing the same physical core
[00:00:41 CEST] <viric> It is also annoying in terms of proper cpu scheduling; if you want a heavy background task at 'nice 20', it is going to be noticeable on higher priority tasks with HT
[00:01:15 CEST] <viric> furq: I could not find a situation where HT has lower throughput.
[00:01:17 CEST] <furq> did you actually disable HT in the bios or just set affinity
[00:01:26 CEST] <viric> I tested both. No difference.
[00:01:39 CEST] <viric> Also disabling cpus in linux /sys. No difference. All equivalent.
[00:01:44 CEST] <furq> i'm more surprised by that really
[00:01:57 CEST] <furq> i figured setting affinity would be worse than disabling it entirely
[00:02:13 CEST] <viric> I talk about somewhat long running tasks (over some seconds)
[00:02:21 CEST] <furq> googling suggests that a bunch of HPC guys think HT is the worst and always disable it, but this was from a few years ago
[00:02:44 CEST] <furq> it might even have been talking about netburst-era HT
[00:02:50 CEST] <viric> It fucks the scheduler process priorities
[00:03:07 CEST] <viric> that alone may be a good reason to disable it
[00:03:19 CEST] <furq> yeah i guess that's a bigger issue for HPC workloads
[00:03:48 CEST] <viric> But definitely it gave more throughput in all I tried
[00:04:05 CEST] <viric> (introducing latencies to more priority processes)
[00:05:03 CEST] <viric> you may think that +8% in x264 encoding is not worth it. :)  But you can always play with affinity and enabling/disabling cpus - no need to reboot and run *always* without HT.
[00:05:21 CEST] <furq> i absolutely think that's worth it
[00:06:46 CEST] <viric> as for my notebook, that increase of throughput is noticeable in temperature as well, HT vs no-HT
[00:13:43 CEST] <viric> I think I read that the linux scheduler has a "balancer" that is aware of HT, and tries to keep heavy cpu tasks in separate cores as possible
[00:14:25 CEST] <viric> But I think this does not apply to tasks that require small amounts of cpu, so these may have a penalty under HT-enabled cores
[01:39:49 CEST] <klaxa> i'm surprised people suggest to turn off HT, iirc, it's basically an extra set of registers for the cpu to make instant context switches, right?
[01:43:35 CEST] <klaxa> shouldn't it always improve performance? i guess it's not that easy, is it? :P
[01:45:59 CEST] <furq> the people i've seen say it sucks are all running 32+ core xeon systems
[01:49:47 CEST] <klaxa> i see
[01:50:46 CEST] <furq> https://www.researchgate.net/publication/267242498_An_Empirical_Study_of_Hyper-Threading_in_High_Performance_Computing_Clusters
[01:50:52 CEST] <furq> that seems more well-balanced
[01:51:24 CEST] <klaxa> oh, nice thanks
[01:52:05 CEST] <furq> actually nvm that's from 2002
[01:52:24 CEST] <klaxa> alight, my claim that it always increases performance is disputed in the abstract: >The characteristics of application run on a cluster will determine whether Hyper-Threading will help or hinder performance.
[01:52:42 CEST] <klaxa> i would guess that still holds true in 2016 though?
[01:52:50 CEST] <furq> i would assume so
[01:53:40 CEST] <klaxa> ok, so on wikipedia it says intel shipped the first xeons with HT in feburary 2002 and this paper is from january 2002?
[01:54:12 CEST] <furq> nice
[01:54:23 CEST] <furq> maybe they were using engineering samples
[01:55:03 CEST] <kepstin> iirc, the purpose of HT is to improve throughput by having a core be able to run another thread immediately when it's stalled on e.g. a memory access or branch mispredict?
[01:55:15 CEST] <furq> https://www.nas.nasa.gov/assets/pdf/papers/saini_s_impact_hyper_threading_2011.pdf
[01:55:18 CEST] <furq> that one's from 2011
[01:57:34 CEST] <DHE> klaxa: if you don't need the extra threads, the CPU can do better branch prediction using the second thread with HT off
[01:58:32 CEST] <DHE> the branch can run BOTH directions through the execution pipeline while waiting on the result of the branch condition, and then abort the thread that turns out to be wrong
[01:59:35 CEST] <klaxa> ooh, that sounds smart
[01:59:46 CEST] <klaxa> and with HT enabled i take that away?
[02:00:00 CEST] <klaxa> because it can only execute one branch per logical cpu
[02:00:13 CEST] <klaxa> did i get that right?
[02:01:38 CEST] <DHE> I don't know the specifics. my guess would be that the second thread would be executing a kernel idle thread running the `hlt` instruction and as such not available for work
[02:02:47 CEST] <kepstin> in most cases the kernel would have told the extra HT virtual core to go into C1 state, and the cpu is responsible for deciding what that means :/
[02:02:51 CEST] <DHE> but based on perf executions, CPU branch prediction is actually really good, so the benefits on this probably won't outweigh the advantage of a second thread if you have enough running processes to take advantage of it
[02:03:44 CEST] <DHE> if I have a 4-core CPU and expect to run more than OS 5 threads at once, hyperthreading is probably going to be a better choice
[02:03:54 CEST] <DHE> unless this PDF has a graph that says otherwise. :)
[02:04:38 CEST] <kepstin> this nasa pdf has a page showing that applications making heavy use of vector instructions (sse2) tend to not be better with HT
[02:04:44 CEST] <kepstin> but that's on nehalem
[02:05:59 CEST] <DHE> makes sense. the instructions would monopolize the FPU and the threads contend for it.
[02:06:53 CEST] <kepstin> I could see some issues with applications running threads with disjoint working sets bigger than cache; each would effectively get 1/2 the cache of a real core
[02:07:22 CEST] <kepstin> or it might be enough to tip a thread from fitting in cache to no longer fitting in cache :/
[02:07:54 CEST] <DHE> true. the L1 and L2 caches are shared. I would argue that the L3 cache would see contention equal to multi-core contention instead, so it's not quite as bad as going to the main memory
[02:08:42 CEST] <DHE> and an HT aware scheduler should keep the processes on distinct cores before sharing threads, so in this scenario, the system is already busy. right?
[02:09:20 CEST] <kepstin> sure, but running e.g. 2 threads on a 2-core box vs 4 on a 2-core-ht box means more threads are trying to fit in cache at a time
[02:09:22 CEST] Action: DHE is intentionally poking at the scenario to make sure he's not making any mistakes either
[05:02:15 CEST] <Kakashi> hello
[05:02:16 CEST] <Kakashi> http://pastebin.com/jaHJK8Tj
[05:02:31 CEST] <Kakashi> would this be handled internally at 32-bit floating point?
[05:22:47 CEST] <Kakashi> http://pastebin.com/mjcVLS53 << I changed it.
[09:39:31 CEST] <Spring> does MSI Afterburner come with x264 as part of the install? I can't remember.
[09:41:11 CEST] <Spring> apparently not
[12:28:43 CEST] <TheHackOps> Does ffmpeg support GPU encoding?
[12:29:05 CEST] <JEEB> it supports both intel and nvidia's ASIC encoders, yes
[12:40:14 CEST] <Spring> what about AMD?
[12:41:45 CEST] <JEEB> do they have any sane APIs :P
[12:45:26 CEST] <__jack__> AMD : do they have any sane <whatever> ? :)
[12:50:11 CEST] <furq> Spring: apparently it "kind of works a bit" through vaapi
[12:50:39 CEST] <furq> so not really, but i guess maybe soon
[12:51:17 CEST] <Spring> it should be a significant different between a CPU and GPU encode, no?
[12:51:32 CEST] <furq> different how
[12:51:44 CEST] <Spring> in terms of speed
[12:51:52 CEST] <furq> not really
[12:51:52 CEST] <JEEB> well, it's a completely different encoder for a format
[12:52:03 CEST] <JEEB> so in that sense you have to test it separately just like any other encoder
[12:52:11 CEST] <furq> the idea with the consumer ones is that it doesn't hit your cpu
[12:52:22 CEST] <furq> so you can live stream yourself getting sniped by russian hackers in battlefield 4
[12:52:34 CEST] <JEEB> you can't go "encoder X was great for format Y, so encoder Z is too"
[12:52:37 CEST] <JEEB> furq: yup
[12:52:47 CEST] <JEEB> the nvidia private screencap API is pretty neat too
[12:52:59 CEST] <JEEB> + they support lossless encoding now which is neat
[12:53:16 CEST] <Spring> is that part of their ShadowPlay offering?
[12:53:26 CEST] <JEEB> (note: they are trying to keep the screencap API private so ffmpeg can't do it for ObviousReasons)
[12:53:45 CEST] <JEEB> (someone pleasantly just posted some code #elsewhere for it and I was ReallyHappy)
[12:54:43 CEST] <furq> but yeah the quality of the hardware h264 encoders is somewhere between x264 ultrafast and superfast
[12:55:11 CEST] <bencoh> and with more artefacts
[12:55:14 CEST] <Spring> as I've found ShadowPlay to handle captures very well with higher compression, moreso than Afterburner. However the downside is the lack of advanced settings that Afterburner provides via custom codec settings
[12:55:21 CEST] <furq> which you should be getting >100fps at on any decent cpu
[12:55:34 CEST] <JEEB> Spring: basically the API that steam uses with 900 series f.ex.
[12:55:44 CEST] <JEEB> they are licensing the private API
[12:55:52 CEST] <JEEB> if you don't support it, they will be using libx264
[12:56:01 CEST] <JEEB> (they license libx264 with the corp license)
[12:56:06 CEST] <Spring> Steam has a video capture functionality?
[12:56:10 CEST] <JEEB> yes?
[12:56:15 CEST] <Spring> what
[12:56:19 CEST] Action: Spring googles
[12:56:21 CEST] <JEEB> they even have game streaming
[12:56:28 CEST] <Spring> yeah, I know that bit
[12:56:29 CEST] <JEEB> and people can ask to watch your gameplay
[12:58:27 CEST] <Spring> can't find details that it has a capture functionality
[12:59:09 CEST] <Spring> according to some posts you can't control when to broadcast, it's when others choose to watch that it initiates
[12:59:10 CEST] <JEEB> well it most certainly has the functionality. it doesn't let you save it or stream it to !steam of course
[13:01:19 CEST] <Spring> in my testing Afterburner can be configured to capture better quality than ShadowPlay at the expense of a slightly greater FPS hit. ShadowPlay is quite miraculous with how minimal the fps hit is.
[13:01:58 CEST] <furq> well yeah that's the whole point
[13:02:21 CEST] <JEEB> yeah, the private API keeps everything on the GPU
[13:02:25 CEST] <JEEB> capture to encode
[13:02:33 CEST] <JEEB> so it just writes the bit stream to a file, basically
[13:02:38 CEST] <Spring> if the quality could be increased and filesizes reduced I'd probably use it all the time
[13:02:55 CEST] <Spring> as it is all that's exposed are some simple sliders
[13:03:19 CEST] <JEEB> I think the API lets you tweak things but I haven't looked at that C file for a while now
[13:03:19 CEST] <Spring> 'Average' to 'best' quality or whatever
[13:03:32 CEST] <furq> for a given definition of "best"
[13:04:32 CEST] <Spring> with Afterburner I can punch in that I want CRF 23 and voila. Been finding it captures frames out of sequence recently however.
[13:05:07 CEST] <Spring> been meaning to test ffmpeg's shuffle frames filter
[13:05:53 CEST] <furq>  /demo_capture for life
[13:08:14 CEST] <t0mm3k> hi everybody ... is someone here who can help me with a simple ffmpeg problem (from user perspective)?
[13:12:04 CEST] <t0mm3k> I have a webcam that sends raw (yuyv422) and mjpeg streams. I would like to capture the mjpeg stream via ffmpeg and pipe it via stdout to netcat. then on the other side, there should be a ffplay instance, that plays that stream from netcat. I already managed to do this, but only with a delay of ~30sec. I want it to be like <1s (as short as possible).
[13:18:20 CEST] <t0mm3k> my current approach: ffmpeg -f v4l2 -r 30 -s 640x480 -input_format mjpeg -i /dev/video0 -f h264 pipe:1 | ffplay -f h264 -i pipe:1
[13:22:31 CEST] <sfan5> t0mm3k: using ffmpeg -i /dev/video0 -c copy -f nut - | nc -l 1234 and nc 127.0.0.1 1234 | ffplay - i get about 4 seconds of delay
[13:24:14 CEST] <t0mm3k> @sfan5: hey sfan5, thanks for that quick response. unfortunately 4s is still to long. what causes that high delay? I thought i might be able to get sth around 250-500ms ?!
[13:24:37 CEST] <sfan5> i have no idea
[13:25:58 CEST] <sfan5> my guess would be that ffmpeg and/or ffplay keep a buffer before encoding/playing
[13:26:20 CEST] <furq> ffplay -fflags nobuffer
[13:30:51 CEST] <t0mm3k> hm ... thanks furq. already better, but still a delay of ~3s
[13:31:40 CEST] <durandal_1707> ffplay is toy
[13:31:55 CEST] <durandal_1707>  use something else
[13:32:49 CEST] <Spring> DivX certainly went the way of the dodo
[13:32:59 CEST] <t0mm3k> i already tried mplayer ... still no good results yet :-(
[13:34:10 CEST] <durandal_1707> It will buffer frames, check mplayer manual
[13:34:55 CEST] <t0mm3k> ok i will ... what kind of player can you recommend?
[13:34:57 CEST] <JEEB> Spring: well they got a successful buy-out after buying mainconcept with whatever funds they had
[13:35:26 CEST] <JEEB> and I think they're still kind of alive now under another owner
[13:35:33 CEST] <durandal_1707> what happened?
[13:35:57 CEST] <Spring> remember when it was the the ripper hotness... and then h.264 become the de facto format
[13:36:10 CEST] <JEEB> well they first got bought by rovi, and then by some sports-streaming company
[13:36:15 CEST] <Spring> always felt dirty
[13:36:16 CEST] <furq> there's a good few years of xvid in the middle of that timeline
[13:36:28 CEST] <Spring> yeah, I used xvid
[13:37:00 CEST] <furq> i still have a lamentable amount of xvid
[13:37:15 CEST] <Spring> the artifacts were annoying though
[13:37:18 CEST] <bencoh> same, sitting around somewhere
[13:37:33 CEST] <bencoh> every video format has "artifcats"
[13:37:43 CEST] <JEEB> last I dealt with divx folk was in '13 I think, when HEVC in matroska was specified (and they tried to do it their way at first, and I then posted stuff from the mpeg-4 part 15 draft to not create a drift between the two)
[13:37:50 CEST] <Spring> yeah but these were 'crunchy' JPEG-like ones
[13:38:43 CEST] <bencoh> h264 doesn't look that better when bitstarved ... but it's easier to bitstarve xvid than h264, that's all :)
[13:38:58 CEST] <JEEB> well the in-loop deblocking does help
[13:39:04 CEST] <bencoh> true
[13:39:06 CEST] <JEEB> which mpeg-4 part 2 didn't have for whatever reason
[13:39:12 CEST] <JEEB> while the thing it based on did have it
[13:39:15 CEST] <JEEB> (H.263)
[13:39:22 CEST] <furq> especially when you're trying to fit it onto a cd-r even though nobody has used cd-rs for ten years
[13:39:38 CEST] <bencoh> furq: :))
[13:39:42 CEST] <furq> except to burn dreamcast games obviously
[13:40:40 CEST] <furq> that must be the only thing keeping the cd-r industry afloat these days
[13:40:43 CEST] <Spring> at the time I looked at comparison encodes of xvid vs h.264 and the deblocking helped immensely. Didn't have a powerful enough system to rip to it though :p
[13:41:30 CEST] <JEEB> yeah, I think the deblocking and CABAC are the two main reasons why we saw such a difference between MPEG-4 Part 2 (the spec that divx and xvid used) and AVC
[13:41:42 CEST] <JEEB> and partially why it's harder to now get similar results from HEVC against AVC
[13:42:05 CEST] <furq> but x265 is 50% better than x264. i read it on the internet
[13:42:20 CEST] <JEEB> you mean HEVC and AVC, and that's theoretical
[13:42:22 CEST] <furq> also have you heard about this one weird trick that doctors hate me for
[13:42:35 CEST] <JEEB> I mean, tested with HM and so forth but it's still theoretical
[13:43:07 CEST] <furq> thank you for displaying so much confidence in my intelligence
[13:43:09 CEST] <JEEB> you have to let actually usable encoders get somewhere to get even somewhere close to that
[13:43:21 CEST] <bencoh> JEEB: think furq forgot his sarcasm sign at home ;)
[13:43:28 CEST] <bencoh> +I
[13:43:29 CEST] <JEEB> I'm pretty sure he was facetious
[13:43:37 CEST] <furq> how are you only pretty sure
[13:43:47 CEST] <bencoh> :)
[13:43:48 CEST] <JEEB> but I'm just replying as usual :P
[14:53:20 CEST] <DaVu> Hello....I would relly appreciate if someone is able to give a ffmpeg-newcomer a little bit
[14:54:14 CEST] <DaVu> I have a m2ts file which contains 3 different audio tracks (DTS-MA, DTS-HRA, AC3) and I want a 60 second snippet from that file with all audio tracks
[14:54:50 CEST] <DaVu> ffmpeg -i input.m2ts -map 0 -t 60 out.m2ts only gives a single audio track
[14:55:10 CEST] <JEEB> it shouldn't, but with MPEG-TS there's one useful thing
[14:55:11 CEST] <DaVu> and I'm a bit stuck now
[14:55:15 CEST] <JEEB> you can cut it with dd :P
[14:55:30 CEST] <DaVu> could you tell me how, please?
[14:55:43 CEST] <JEEB> so you just dd if=input.m2ts bs=1M count=ENOUGH_MEGABYTES_FOR_YOU of=output.m2ts
[14:55:56 CEST] <DaVu> really? that simple
[14:55:58 CEST] <JEEB> yes
[14:56:06 CEST] <DaVu> ok, i'll try. Thanks a bunch
[14:56:18 CEST] <JEEB> and the best part is that you'd be providing the sample as-is, not remuxed
[14:56:28 CEST] <DaVu> indeed
[14:56:41 CEST] <DaVu> that's the point and what is absolutely needed
[14:57:24 CEST] <JEEB> mpeg-ts was originally meant for broadcast so you can just cut it. as long as your cut includes enough stuff it's decode'able
[14:57:34 CEST] <DaVu> so: count=25 gives me 25MB?
[14:57:37 CEST] <JEEB> yup
[15:00:48 CEST] <DaVu> thanks, that works. But the ffmpeg command above should have worked, too normally?
[15:01:41 CEST] <JEEB> yes, -map 0 is correct for mapping in all streams from input
[15:01:51 CEST] <DaVu> hm...strange
[15:01:53 CEST] <JEEB> if you just do `ffmpeg -i input.m2ts` does it list all tracks?
[15:03:26 CEST] <DHE> m2ts is what all the over-the-air tv stations use. it's join-anywhere compatible and all that.
[15:03:49 CEST] <JEEB> well when talking about m2ts that's usually the 192 byte one :)
[15:03:51 CEST] <DaVu> http://pastebin.com/QCJLZNmt
[15:04:18 CEST] <JEEB> well that it seems to do
[15:04:30 CEST] <DHE> 188 for what I"ve seen. or is there another spec I don't know about?
[15:04:48 CEST] <JEEB> DHE: 188 for broadcast, blu-ray uses 4 extra bytes for timestamps I think?
[15:05:01 CEST] <JEEB> then there's 204 byte stuff for extra checksums?
[15:05:11 CEST] <furq> DHE: https://en.wikipedia.org/wiki/.m2ts
[15:05:30 CEST] <DHE> JEEB: m2ts includes timestamps in both the adaptation header and the PES themselves. odd that would be needed
[15:05:46 CEST] Action: DHE wrote a simple de/remuxer so he knows the format fairly well...
[15:05:54 CEST] <JEEB> yeah, I know there's the 90kHz stuff in there :)
[15:06:09 CEST] <JEEB> "The header consists of a 2-bit copy permission indicator and the 30-bit arrival timestamp with a resolution of 27 MHz."
[15:06:17 CEST] <JEEB> don't ask me why but that's what they have :)
[15:06:47 CEST] <JEEB> the stuff after 0x47 is still the same so you are able ot handle the files with a "normal" MPEG-TS parser as well
[15:06:53 CEST] <DaVu> JEEB: this is what I get after the commmand above: http://pastebin.com/khZXB7Kn
[15:07:28 CEST] <JEEB> DaVu: everything else seems fine except the fact that you forgot to specify -c copy
[15:07:38 CEST] <DaVu> aaaah
[15:07:48 CEST] <bencoh> "ooops" :)
[15:07:50 CEST] <JEEB> you can see the stream mapping in the end :P
[15:08:00 CEST] <DaVu> so: ffmpeg -i 00000.m2ts -map 0 -t 60 -c copy out2.m2ts
[15:08:01 CEST] <DHE> the adaptation header's PCR value is already a 27 MHz clock source with more bits than 30. seems superfluous to me, but I guess they wanted to make it extra-easy to do time seeking.
[15:08:15 CEST] <JEEB> yeah
[15:08:22 CEST] <JEEB> DaVu: puh-ret-teh much
[15:08:22 CEST] <DaVu> ok, I 'll try
[15:08:25 CEST] <JEEB> but that's remuxing
[15:08:36 CEST] <JEEB> so it's better to do samples with dd when you can
[15:08:57 CEST] <DaVu> yes, but I need to upload the file and 100MB are about 25 seconds of the whole video
[15:09:06 CEST] <DaVu> I don't cate about the video quality
[15:09:14 CEST] <DaVu> it's the audio track we need to test
[15:09:17 CEST] <JEEB> then just do -map 0:a
[15:09:26 CEST] <JEEB> or write something to filter packets out of the video track :)
[15:09:38 CEST] <DaVu> I did this, but then I get 3 audio streams all in stereo
[15:09:39 CEST] <JEEB> (I mean, on MPEG-TS level)
[15:09:48 CEST] <JEEB> DaVu: with -c copy?
[15:09:55 CEST] <DaVu> think so
[15:09:58 CEST] <JEEB> with re-encode of course it will do all that automagics
[15:09:59 CEST] <DaVu> but will try again
[15:11:23 CEST] <DaVu> JEEB: http://pastebin.com/snWuguXr
[15:11:33 CEST] <DaVu> correct so far?
[15:11:46 CEST] <JEEB> so far yes, remuxed by libavformat of course
[15:12:07 CEST] <DaVu> with vlc I see only a single audio track
[15:12:39 CEST] <JEEB> what does `ffmpeg -i out12.m2ts` say?
[15:12:43 CEST] <JEEB> or mpv
[15:12:54 CEST] <JEEB> also wouldn't be surprised if your VLC is just old :)
[15:13:07 CEST] <JEEB> (v3 has been very long in the cooking)
[15:15:59 CEST] <DaVu> JEEB: http://pastebin.com/nLqS4wHg
[15:16:17 CEST] <JEEB> well there you have them streams at least
[15:16:23 CEST] <DaVu> yes, I see
[15:16:25 CEST] <DaVu> hmmm
[15:16:58 CEST] <JEEB> I'm not gonna say that libavformat's mpeg-ts muxer is too great of course ;) but to see why VLC would fail would require stuff that I'm not willing to do
[15:19:11 CEST] <DaVu> I have it working...maybe an issue with VLC, Kodi shows the correct streams
[15:19:14 CEST] <DaVu> thanks much
[16:04:08 CEST] <edfoxx> Hello, i'm having an issue with "showwavespic"
[16:04:27 CEST] <edfoxx> No matter what i do, the waveform always appears of a brown color
[16:04:35 CEST] <edfoxx> "ffmpeg -i test.mp3 -filter_complex "showwavespic=s=640x120" -frames:v 1 output.png"
[16:04:53 CEST] <edfoxx> While on the website it showed a white waveform when that command was used
[16:31:54 CEST] <c_14> showwavespic=s=640x120:colors=white
[16:40:20 CEST] <edfoxx> Let me try
[16:40:58 CEST] <edfoxx> Yay it works
[17:15:03 CEST] <agrathwohl> Hey guys. I am very fortunate to have run into some unexpected funding, so just for fun I'd like to build a headless GPU video processing server with lots of CUDA cores. I will mainly be using FFmpeg and vapoursynth on this server. I have picked out my hardware but have not yet figured out what OS to use. Would FreeBSD be a bad choice? Gentoo? CentOS?
[17:20:19 CEST] <furq> is cuda natively supported on freebsd yet
[17:22:12 CEST] <Mavrik> Is using GPUs for that even sensible? Xeons usually behave better.
[17:22:22 CEST] <Mavrik> agrathwohl, use something widely supported and used on servers.
[17:22:31 CEST] <Mavrik> So you'll have proper support when you have issues.
[17:22:34 CEST] <furq> i assume he's using it for filtering, which it sometimes makes sense for
[17:22:35 CEST] <Mavrik> CentOS, Debian, Ubuntu, etc.
[17:22:49 CEST] <JEEB> I'd probably go for ubuntu 16.04 to have non-ancient components but still LTS
[17:22:56 CEST] <JEEB> unless you enjoy building python etc yourself
[17:23:17 CEST] <furq> why would you use an lts release "just for fun"
[17:23:37 CEST] <c_14> I'd check for distros with up to date GPU drivers.
[17:23:38 CEST] <Mavrik> Yeah, Ubuntu 16.04 or Debian Stable would be my choice as well.
[17:23:54 CEST] <JEEB> debian sta(b)le usually tends to be a wee bit too old for my liking
[17:23:59 CEST] <furq> debian testing is generally less hassle for a headless box
[17:24:00 CEST] <Mavrik> Ubuntu 16.04 more probably, since there are PPAs with new nvidia drivers.
[17:24:17 CEST] <JEEB> well ubuntu also seems to be updating their drivers every few months
[17:24:37 CEST] <JEEB> agrathwohl: I guess you did some development with vapoursynth?
[17:24:52 CEST] <JEEB> since I don't strictly remember many filters doing GPU work publicly
[17:25:34 CEST] <furq> knlmeanscl is pretty nice
[17:25:41 CEST] <furq> i've not had cause to use anything else
[17:27:55 CEST] <furq> it looks like cuda still isn't supported on freebsd without using the linux emulation
[17:28:07 CEST] <furq> and even then it's a nightmare to get it to work
[17:28:49 CEST] <furq> opencl works fine obviously
[17:38:10 CEST] <agrathwohl> furq JEEB Mavrik thanks so much for your help
[17:38:33 CEST] <agrathwohl> I think Ubuntu Server makes sense
[17:39:04 CEST] <agrathwohl> i just have had bad experiences with their PPAs in the past, especially for FFmpeg (when they chose to go with libav and all that)
[17:39:22 CEST] <Mavrik> You shouldn't ever install ffmpeg from repos :)
[17:39:33 CEST] <JEEB> that's why most people who actually handle this daily don't really use PPAs
[17:39:49 CEST] <agrathwohl> JEEB I do handle this daily, and build the nightlies every day for my day job :)
[17:40:17 CEST] <furq> a good rule to live by is to never use PPAs ever
[17:40:36 CEST] <agrathwohl> But since FFmpeg is such a common dep for other apps I find that even when doing innocent things with PPAs it can cause problems for custom FFmpeg builds
[17:40:41 CEST] <furq> they rank somewhere between crystal meth and heroin in a list of things to avoid using
[17:41:00 CEST] <agrathwohl> LOL noted! :D
[17:41:03 CEST] <Mavrik> agrathwohl, yes, we use fully static builds of ffmpeg because of that.
[17:41:14 CEST] <Mavrik> Which can then be directly deployed to any kind of machine.
[17:41:23 CEST] <Mavrik> And don't get messed up by what distros do :P
[17:41:51 CEST] <furq> debian's ffmpeg is pretty much fine now
[17:42:01 CEST] <furq> although now i've said that they'll probably remove everything good from it
[17:42:08 CEST] <Mavrik> ^^
[17:42:22 CEST] <Mavrik> Isn't docker now end-all of any kind of ops and the holy grail?
[17:42:23 CEST] <agrathwohl> I have been using CentOS on production FFmpeg servers for my day job -- is this considerably less ideal than an Ubuntu setup?
[17:43:03 CEST] <furq> if you want to install binary packages which aren't a million years old then RHEL/centos are less than ideal
[17:43:40 CEST] <agrathwohl> furq noted! :D thanks
[17:44:09 CEST] <furq> if you want an up-to-date rolling release then debian testing is great
[17:44:27 CEST] <furq> ubuntu seems to have sorted out a lot of the bullshit that turned me off it though
[17:45:31 CEST] <JEEB> centos/RHEL are pretty much "what comes in the package is old as hell so if you need something newer you build *everything* yourself"
[17:45:49 CEST] <JEEB> I think RHEL does get some development packages so you can get newer toolchains etc tho
[17:46:13 CEST] <agrathwohl> hmm.. looks like I'll be investigating whether I go with Debian testing or Ubuntu
[17:46:21 CEST] <furq> there's no real compelling reason to use them for personal use though
[17:47:45 CEST] <agrathwohl> How about Gentoo - out of the question?
[17:48:01 CEST] <JEEB> if you enjoy maintaining it, sure
[17:48:08 CEST] <agrathwohl> I really like the idea of USE flags for bleeding edge media work
[17:49:07 CEST] <furq> does that get you any advantage that --enable-runtime-cpudetect doesn't
[17:49:32 CEST] <JEEB> build-time optimizations don't really help you with FFmpeg
[17:49:39 CEST] <JEEB> unless you start experimenting by overriding what the configure sets
[17:49:51 CEST] <JEEB> because it f.ex. currently disables vectorization
[17:49:55 CEST] <furq> all the popular codecs these days support runtime cpu detection as well
[17:50:19 CEST] <JEEB> yeah, since you don't want to break the C code path users and checking for CPU capabilities isn't hard
[17:50:22 CEST] <furq> and you'll be compiling all your vapoursynth plugins yourself anyway
[17:50:24 CEST] <agrathwohl> great points. you guys are so helpful, really appreciate this insight.
[17:50:51 CEST] <furq> so the only bit of the pipeline which benefits is python
[17:51:01 CEST] <JEEB> does it?
[17:51:03 CEST] <furq> and i don't think python will stop being slow as fuck because you have AVX2
[17:51:40 CEST] <furq> JEEB: in theory, obviously
[17:51:44 CEST] <JEEB> :)
[17:52:20 CEST] <JEEB> yeah, our HEVC decoder wouldn't be as slow if compilers were perfect at optimizing our code to what we think it should do
[17:52:41 CEST] <JEEB> (let's ignore for a moment that we globally disable autovectorization)
[17:53:02 CEST] <furq> i do wonder if that luajit fork of vapoursynth would be noticeably faster
[17:53:15 CEST] <JEEB> so much of it is done natively that most probably not
[17:53:17 CEST] <furq> probably not enough to bother putting any work into it
[18:10:00 CEST] <Mavrik> JEEB, why is vectorization disabled anyway?
[18:10:10 CEST] <Mavrik> Bad compiler versions?
[18:11:14 CEST] <iive> yes, all of them
[18:11:14 CEST] <JEEB> yeah, there's been cases of miscompilation and everyone doesn't want that to happen again
[18:11:40 CEST] <JEEB> I'm pretty sure FATE passes even with optimizations on in many cases
[18:11:48 CEST] <JEEB> but then there's the bad apples :)
[18:12:19 CEST] <iive> vectorization was enabled for a while, but then came bugreports... so that was reverted.
[18:13:16 CEST] <JEEB> I think those were some old cases or specific ones, not sure how many we actually got
[18:13:41 CEST] <bencoh> were there any real significant benefit anyway?
[18:13:55 CEST] <JEEB> for those parts where there's less manual optimizations yes
[18:14:08 CEST] <JEEB> where stuff was mostly done with SIMD, nope
[18:14:50 CEST] <bencoh> yeah but ... isn't most of the really important/critical stuff already handwritten in SIMD?
[18:14:52 CEST] <Mavrik> That stuff is ASM and untouched anyway right? :)
[18:14:57 CEST] <bencoh> Mavrik: right
[18:15:06 CEST] <JEEB> bencoh: well try stuff like HEVC decoding
[18:15:11 CEST] <Mavrik> Is there any preceptible difference between clang and gcc atm?
[18:15:15 CEST] <JEEB> IIRC that had some effect because of the lack of optimization
[18:15:15 CEST] <bencoh> haven't tried for a while :
[18:15:17 CEST] <bencoh> :)
[18:15:42 CEST] <JEEB> Mavrik: it really depends on what you're going to use, but at least clang doesn't miscompile any more
[18:16:01 CEST] <JEEB> I would have been interested of any benchmarks on FFmpeg on ARMv7 with GCC | clang 3.8
[18:16:07 CEST] <JEEB> since GOOG's toolchain is pushing for clang
[18:17:03 CEST] <JEEB> when you google for benchmarks you generally find phoronix's benchmarks which don't contain FFmpeg and are mostly x86_64
[18:17:09 CEST] <Mavrik> Yeah, wonder just how bad clangs ARM generator is
[18:17:31 CEST] <JEEB> the last armv7 one I found was for clang 3.0 which is by now ancient
[18:53:30 CEST] <krystalkay> is this a good place to ask about advice for a streaming setup i want to try with ffmpeg and nginx?
[18:54:12 CEST] <klaxa> it certainly isn't the worst place to ask
[18:54:57 CEST] <krystalkay> i basically have an nginx server with the rtmp module installed, videos saved locally on the server, and i want to stream a local video to my rtmp server in a way that everybody can see the stream and everybody can control playback of the video
[18:55:57 CEST] <krystalkay> i have it set up with nginx already so that someone can broadcast to that rtmp server and everyone can see it, but the hurdle now is having the playback of the video originating from my server, and having that playback be able to be controlled by someone
[18:56:36 CEST] <krystalkay> i've got ffmpeg working so that it can basically transcode a local video and output it in flv format to the rtmp server, so in that sense the local video in the server is streaming to everybody
[18:57:01 CEST] <krystalkay> but the catch of course is that you can't really "seek" ffmpeg that way so nobody would be able to pause, rewind, forward, etc.
[18:57:38 CEST] <krystalkay> anybody have any ideas on how to basically just playback a video and stream it to the rtmp server, and have that be controlled? maybe ffmpeg isn't the right approach or it isn't the full approach
[18:59:06 CEST] <furq> are they controlling playback for themselves or for everybody
[18:59:27 CEST] <krystalkay> for everybody
[19:00:13 CEST] <krystalkay> could one approach be to create a program that plays a local video and outputs it to a fake video device, and have ffmpeg just grab+transcode+stream from that device to the stream?
[19:00:25 CEST] <krystalkay> and that way the program can be controlled
[19:06:04 CEST] <krystalkay> think that may work, i'll give it a try
[19:27:38 CEST] <brontosaurusrex> hello, what is the latest statuc with 10bit encoding (x264), do i still need a separated build?
[19:27:42 CEST] <brontosaurusrex> status*
[19:27:52 CEST] <JEEB> yes
[19:28:43 CEST] <brontosaurusrex> And that is due to x264 right?
[19:28:47 CEST] <DHE> x264 is built with only one bit depth supported, so you have to choose one and compile it. that's not likely to change soon
[19:32:21 CEST] <brontosaurusrex> so https://www.johnvansickle.com/ffmpeg/ < the one that says ffmpeg-10bit is probably what i want?
[19:33:14 CEST] <DHE> sounds right
[19:49:09 CEST] <brontosaurusrex> Do I want -pix_fmt yuv444p ?
[19:52:18 CEST] <BtbN> how should we know what you want?
[19:54:35 CEST] <DHE> people who want 10bit usually know what their needs are. 8bit is most common
[19:55:24 CEST] <brontosaurusrex> I don't really, just trying to figure this out if i ever decide that would be my backup format
[00:00:00 CEST] --- Mon Aug 29 2016