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

[burek]

[00:00:07 CET] <alexpigment> i tend to use CRF + VBV for streaming, which allows you to save overall on file size even though it's a bit more unpredictable
[00:01:06 CET] <alexpigment> maybe that's a noob move, but i haven't heard any complaints so far and it's been over a year
[00:01:54 CET] <ZeroWalker> so, anyone wana lend me a hand in my lost attempt to write encoded frames to a file?;d
[00:02:00 CET] <furq> that's pretty much fine
[00:04:23 CET] <kepstin> yeah, with crf+vbv you can replace the "perfectly clear still shot that turns into meh when something moves" into "everything's pretty much constant mehness" ;)
[00:05:17 CET] <alexpigment> well, to be fair, i go aggressive on the CRF
[00:05:45 CET] <alexpigment> and i keep the VBV much higher than, say, YouTube at a given resolution
[00:06:08 CET] <alexpigment> so basically i'm hitting the VBV wall anytime it's complex, and then I'm saving bits when it's not complex
[00:06:35 CET] <kepstin> hmm, i actually should check whether the h264 decoders used in browsers for webrtc can decode intra-refresh stuff properly. Would be fun to sneak that into production.
[00:06:43 CET] <alexpigment> i don't have the luxury of 2-pass, so it's the best i could come up with
[00:07:00 CET] <kepstin> annoyingly, flash can't handle it in rtmp, at least as encoded by ffmpeg.
[00:07:21 CET] <alexpigment> well, you're in luck - *it's 2017*
[00:07:26 CET] <kepstin> and we want to use the same encoding for flash and webrtc where possible :/
[00:07:43 CET] <alexpigment> finding a modern browser that even lets you run flash out of the box is difficult
[00:07:57 CET] <TD-Linux> hate to break it to you but chrome has flash built in
[00:08:01 CET] <kepstin> you mean, "the standard installation of chrome"? :)
[00:08:12 CET] <TD-Linux> the proprietary one ye :)
[00:08:35 CET] <alexpigment> as of i think chrome 56, they started preferring HTML5 over Flash when both were available
[00:08:38 CET] <kepstin> (when we're doing flash mode, it's a full-page flash application, so it bypasses some of the automatic blocking)
[00:08:43 CET] <alexpigment> meaning that it's probably on the way out
[00:08:58 CET] <alexpigment> but yeah, if you're in an application, flash is fine
[00:09:53 CET] <kepstin> we're doing this stuff all backwards, we have a full-page flash application... which uses webrtc via javascript for audio when the browser can do it.
[00:10:03 CET] <kepstin> owell.
[00:10:15 CET] <alexpigment> i hear you
[00:11:17 CET] <kepstin> the folks behind me are working on the html5 version, it's coming soon"
[00:11:39 CET] <alexpigment> we just had to go through our web app this year and rip out all the flash because chrome's dev blog made it sound like flash *wouldn't work* in either v55 or v56 (i think). it turned out that it didn't have as much affect as they said it would, but it at least got us to work harder really quickly :)
[00:11:43 CET] <kepstin> the pain point is that we are trying to get video going between flash and html5 clients to have a smooth transition period
[00:11:50 CET] <alexpigment> and of course, safari all but blocks it without the user opting in
[00:12:02 CET] <alexpigment> firefox prompts the user, i believe
[00:12:08 CET] <alexpigment> does Edge even support flash at all?
[00:12:16 CET] <kepstin> edge supports flash, yes.
[00:12:27 CET] <kepstin> in desktop mode, unclear about metro mode
[00:12:44 CET] <alexpigment> gotcha. they were pretty "no plugins" at the beginning. i didn't know if they got away from that or not
[00:13:00 CET] <kepstin> it supported flash from the start, but never any other plugins (e.g. java)
[00:13:08 CET] <alexpigment> i don't even think it was npapi vs ppapi plugins. i want to say they were against all of them
[00:13:17 CET] <alexpigment> i see. maybe they just made a single exception for flash
[00:13:37 CET] <kepstin> heh, plugins in IE are activex, no npapi vs ppapi issue at all ;)
[00:14:00 CET] <kepstin> (I suspect Edge uses a special sandboxed flash build, similar to chrome)
[00:14:40 CET] <alexpigment> sorry, i didn't mean literally npapi. i'm saying it wasn't like old format vs new format
[00:15:23 CET] <kepstin> well, they certainly haven't made any public plugin api for Edge.
[00:15:52 CET] <kepstin> (there's an extension api based on chrome's extension api tho)
[00:16:52 CET] <alexpigment> at any rate, i have mixed feelings about the death of flash. it's got its advantages, but it's just always been a bloated turd
[00:19:24 CET] <kepstin> getting live streaming video into browsers is a lot harder without it :)
[00:20:12 CET] <alexpigment> yeah for sure
[00:20:18 CET] <alexpigment> and you know, copy protection
[00:20:54 CET] <alexpigment> (not that i'm necessarily in favor of copy-procting all web video)
[01:11:29 CET] <ZeroWalker> JEEB, http://sprunge.us/QPhN i can't get any further;(
[01:43:46 CET] <maicod> Hi. my ffmpeg doesn't know the -f concatenate. What build config file do I need to edit to enable this to compile this function in ?
[01:45:08 CET] <JEEB> maicod: since that is enabled by default my guess is just that your FFmpeg is old enough to not have it
[01:45:26 CET] <maicod> JEEB I recently got it from github
[01:45:47 CET] <JEEB> if you're doing disable-everything kind of config then you'll just have to find it by yourself because doing that means that you understand what you are doing
[01:46:13 CET] <JEEB> and if you don't, then you start off with a more full configuration
[01:46:20 CET] <maicod> I did not
[01:46:33 CET] <JEEB> then whatever you got is just old
[01:46:46 CET] <maicod> how do I list the version of ffmpeg ?
[01:47:02 CET] <JEEB> ffmpeg -version
[01:47:28 CET] <JEEB> also do note that all of the concat stuff is most likely in some uses cases broken so you have been warned. I mean, someone made them and they worked for that person's exact use case
[01:48:09 CET] <JEEB> heck, I've used the concat video filter myself, mostly because it works on the highest level with all the demuxers and decoders working separately
[01:48:26 CET] <maicod> thanks for the warning
[01:48:32 CET] <maicod> did you have succes ?
[01:48:42 CET] <JEEB> the demuxer and protocol is where it gets funky, esp. if you want to do stream copying
[01:49:11 CET] <JEEB> maicod: yes. since in my opinion that is the one where things are least likely to go awry as you don't have demuxers hopping from one thing to another
[01:49:33 CET] <JEEB> each demuxer (and decoder) work separately, but the things are just concatenated together *after* decoding
[01:49:33 CET] <maicod> root at raspberrypi:/1/a/1080p# ffmpeg -version
[01:49:33 CET] <maicod> avconv version 11.8-6:11.8-1~deb8u1+rpi1, Copyright (c) 2000-2016 the Libav developers
[01:49:33 CET] <maicod>   built on Oct  8 2016 02:37:00 with gcc 4.9.2 (Raspbian 4.9.2-10)
[01:49:33 CET] <maicod> avconv 11.8-6:11.8-1~deb8u1+rpi1
[01:49:33 CET] <maicod> libavutil     54.  3. 0 / 54.  3. 0
[01:49:33 CET] <maicod> libavcodec    56.  1. 0 / 56.  1. 0
[01:49:33 CET] <maicod> libavformat   56.  1. 0 / 56.  1. 0
[01:49:34 CET] <maicod> libavdevice   55.  0. 0 / 55.  0. 0
[01:49:34 CET] <maicod> libavfilter    5.  0. 0 /  5.  0. 0
[01:49:35 CET] <maicod> libavresample  2.  1. 0 /  2.  1. 0
[01:49:35 CET] <maicod> libswscale     3.  0. 0 /  3.  0. 0
[01:49:36 CET] <maicod> damn
[01:49:46 CET] <maicod> I wanted to paste a pastebin link
[01:49:47 CET] <JEEB> yes, that's most likely your packaged version
[01:49:55 CET] <JEEB> and yes, please do that in the future
[01:50:09 CET] <maicod> I already prepared but the clipboard didnt work :)
[01:50:13 CET] <JEEB> but yeah, that's not even FFmpeg :)
[01:50:20 CET] <maicod> its avconv huh
[01:50:28 CET] <JEEB> from Libav project, yes
[01:50:40 CET] <maicod> I see I thought they were idetical
[01:50:43 CET] <maicod> identical
[01:50:54 CET] <maicod> they say set an alias for ffmpeg=avconv even
[01:51:17 CET] <JEEB> well, in some ways they are very similar (after all, current ffmpeg bases on the updates done for avconv), but a lot of features inside the libraries etc are FFmpeg-only
[01:51:22 CET] <maicod> btw the hardware encoding on the Rpi works like a charm ! (openmax)
[01:51:30 CET] <maicod> I see now
[01:51:48 CET] <JEEB> mostly because to get stuff from FFmpeg to Libav someone needs to care enough, but Libav->FFmpeg used to be something done on a weekly basis
[01:52:12 CET] <maicod> so there is not other way to combine video files into ffmpeg :(
[01:52:13 CET] <JEEB> and you're not sure to get through Libav's review anyways, so f.ex. I mostly gave up at some point :P
[01:52:19 CET] <maicod> hehe
[01:52:24 CET] <JEEB> maicod: so what's your actual use case?
[01:52:36 CET] <JEEB> transcoding, stream copy?
[01:53:18 CET] <maicod> just wanting to combine two video files (both from same camera) and then transcode it. Transcoding
[01:53:26 CET] <JEEB> ok
[01:53:29 CET] <maicod> like this
[01:54:01 CET] <JEEB> so yea, Libav doesn't even have the concat VF it seems
[01:54:11 CET] <maicod> indeed it seems so
[01:54:17 CET] <JEEB> so I recommend you get a rpi cross-toolchain on an actual PC
[01:54:24 CET] <JEEB> and build FFmpeg for it
[01:54:30 CET] <JEEB> then transfer the binaries back to the rpi
[01:54:43 CET] <JEEB> you can use it from your home directory or something
[01:55:00 CET] <JEEB> unless you like building on that hunk o' metal :P
[01:55:02 CET] <maicod> ok :)
[01:55:07 CET] <maicod> heheeh its cute :)
[01:55:19 CET] <maicod> JEEB: did you know it can do hardware encoding ?
[01:55:24 CET] <JEEB> yes
[01:55:30 CET] <JEEB> most ARM SOCs can
[01:55:31 CET] <maicod> it uses the GPU (via openmax)
[01:55:34 CET] <JEEB> they contain ASICs
[01:55:35 CET] <maicod> ok :)
[01:55:52 CET] <maicod> it is 12x faster than software encoding :)
[01:55:57 CET] <JEEB> well, d'uh
[01:56:00 CET] <JEEB> ARM
[01:56:03 CET] <maicod> its cool
[01:56:22 CET] <maicod> what is so special about that its ARM ?
[01:56:31 CET] <maicod> I mean what makes that do such things easier ?
[01:56:34 CET] <JEEB> less processing power per clock cycle
[01:56:44 CET] <maicod> ah I see
[01:56:46 CET] <JEEB> so of course CPU based stuff is gonna be slower
[01:56:50 CET] <JEEB> compared to an ASIC
[01:57:18 CET] <JEEB> of course doesn't stop people using libx264 with the NEON optimizations in some cases
[01:57:38 CET] <maicod> thanks for you making me understand its cause its avconv that I don't have concatenate
[01:57:44 CET] <JEEB> (some ASICs or their drivers in the ARM space are just awful, and in that case it's often more useful to drop resolution and encode with CPU)
[01:58:11 CET] <maicod> yeah GPU encoding drivers can be a little rough huh
[01:58:13 CET] <JEEB> (some well-made mobile apps have sanity checks for that)
[01:58:21 CET] <maicod> not developed thorough enoug
[01:58:24 CET] <JEEB> garbage out => switch to cPU encoding
[01:58:30 CET] <JEEB> *CPU
[01:58:42 CET] <maicod> how you call my beloved Pi a piece of metal :)
[01:58:54 CET] <JEEB> I'm sorry, it's plastic
[01:58:58 CET] <maicod> its fine
[01:59:01 CET] <JEEB> and I have one too :P
[01:59:03 CET] <maicod> LOL
[01:59:08 CET] <maicod> a 3 ?
[01:59:17 CET] <JEEB> waiting for me to build a 64bit kernel
[01:59:26 CET] <JEEB> so I can poke at the aarch64 mode
[01:59:28 CET] <maicod> yeah raspbian is still 32bit huh
[01:59:41 CET] <TD-Linux> ugh reminds me I need to do that for mine too
[01:59:49 CET] <maicod> but won't the 1GB mem be a bastard for 64bit OS ?
[01:59:53 CET] <JEEB> although you lose most of the desktop side of things with the aarch kernel
[01:59:55 CET] <TD-Linux> my 64bit kernel doesn't boot and I haven't debugged why yet
[02:00:01 CET] <TD-Linux> upstream kernel support is 64bit only
[02:00:06 CET] <JEEB> yea
[02:00:14 CET] <TD-Linux> and you actually don't lose most of the desktop things
[02:00:19 CET] <JEEB> oh
[02:00:37 CET] <JEEB> I heard the blob bridge thing wasn't done yet
[02:00:38 CET] <TD-Linux> you get kms and mesa instead of blob driver, and I think HDMI audio might not work
[02:00:46 CET] <TD-Linux> (vc4 accelerated mesa)
[02:00:51 CET] <JEEB> interesting
[02:00:59 CET] <TD-Linux> it can actually run gnome-shell (barely)
[02:01:03 CET] <maicod> JEEB thanks for the insights again. have a nice day
[02:27:44 CET] <r0ute> When stuck on an ffmpeg programming task. Don't do what I did to try and get past the block. 8 pints of beer, followed by 4 coffees in 30 minutes does not put you in good sted. Just a heads up..
[02:28:51 CET] Action: klaxa takes notes
[02:31:31 CET] <r0ute> Stage 2 of the brilliant plan is if it's still not working in an hour, malt whisky will help.
[02:40:06 CET] <furq> 8 pints of beer in 30 minutes eh
[02:41:15 CET] <r0ute> 4 coffes in 30 minutes, the pints took a while longer
[02:43:40 CET] <furq> maybe that's the problem
[02:44:03 CET] <r0ute> I should have drunk the beer quicker?
[02:44:19 CET] <llogan> i found a rye in the office today. now it's on my desk.
[02:56:02 CET] <DHE> look up the ballmer peak (xkcd)
[02:59:45 CET] <r0ute> That's a good one, hadn't seen that before. The solution to this problem is clear to me now...
[03:11:18 CET] <llogan> i'm not much of a mpegts user or broadcast encoder, but a client wants a PAT/PMT interval of 100, but they don't state the unit of measurement and they didn't know what it is supposed to be. any ideas of what unit of measurement it probably is?
[03:13:35 CET] <JEEB> 50 frames I guess?
[03:13:40 CET] <JEEB> uhh, 100 I mean
[03:13:57 CET] <JEEB> although even that is kind of long (4 seconds for 25)
[03:18:09 CET] <llogan2> the power went out...
[03:19:02 CET] <llogan2> conviently right when i saw that JEEB responded but didn't get to read it fully
[03:21:18 CET] <furq> llogan2: http://ffmpeg.gusari.org/irclogs/ffmpeg.log.20170308
[03:22:56 CET] <kiwi_banal> What is a good encoding format suitable for playing video via USB on a Panasonic TH24A400Z television?
[03:23:28 CET] <llogan2> furq: thanks. for some reason i assumed the logs were compiled daily
[03:23:33 CET] <kiwi_banal> The Panasonic TH24A400Z is a flat-screen PAL TV of about 3 years of age.
[03:24:00 CET] <furq> they're rotated daily but the current day's log is updated live
[03:24:09 CET] <llogan2> well i'll be damned
[03:24:22 CET] <furq> incredible~
[03:24:25 CET] <llogan2> wait, i already am. mpegts.
[03:29:10 CET] <kiwi_banal> I am competent with ffmpeg, prefer not to use a *possibly* malware gui with ffmpeg under the hood, but cannot find say, yuv etc.
[03:30:00 CET] <klaxa> kiwi_banal: what have you tried yet? just ffmpeg -i movie.avi movie.mp4 ?
[03:30:59 CET] <klaxa> they even claim to support mkv
[03:31:47 CET] <klaxa> i would assume they support h264 high at least then
[03:32:57 CET] <kiwi_banal> I tried a few weeks ago and am back trying (for a computer-illiterate)...
[03:33:16 CET] <klaxa> oh then they probably don't care too much about quality too i guess? :/
[03:33:47 CET] <kiwi_banal> h264 with aac/mp3, in mkv and mp4 containers
[03:34:01 CET] <kiwi_banal> no :)
[03:34:29 CET] <kiwi_banal> I am trying to get youtube etc. videos to convert successfully for him.
[03:35:00 CET] <kiwi_banal> I suspect it is the pixel format or color type ??
[03:35:12 CET] <klaxa> if you download them in the right format it should work out of the box
[03:36:12 CET] <kiwi_banal> OK, I'll keep trying (sigh) as I catch up maybe once a week, so it is a slow process of trial and error. Thanks all the same :)
[03:37:03 CET] <klaxa> otherwise i personally would just throw "ffmpeg -i input.avi -crf 20 -preset slower output.mp4" or so at it
[03:37:30 CET] <kiwi_banal> I'll give it a whirl. Cheers, klaxa
[03:39:53 CET] <furq> kiwi_banal: do you have a sample that works
[03:40:48 CET] <kiwi_banal> furq: Not yet. I will try one file on usb in various formats (once a week!) until I hit the jackpot.
[03:41:39 CET] <furq> well yeah i'm sure i don't need to tell you, but hardware media players are notoriously finicky and underdocumented
[03:41:47 CET] <furq> and smart tvs are among the worst offenders
[03:42:13 CET] <furq> if it's from 2014 then i assume it wants h264 and aac, but who knows
[03:43:26 CET] <kiwi_banal> yep, I'd assumed the same. The only file I have got working is mp3 straight audio so far.
[03:43:56 CET] <kiwi_banal> I have been trying to convince my illiterate friend to buy a second hand laptop.
[03:44:21 CET] <furq> one of those hdmi sticks is probably a better choice
[03:44:29 CET] <furq> like the chromecast or something
[03:45:32 CET] <kiwi_banal> I'll check out the hdmi stick as you say. I was kind of dreading the free help time with a new laptop ;)
[03:45:56 CET] <furq> those things are like $30 or so and will be less hassle for both of you
[03:46:14 CET] <furq> if he just wants to watch stuff on his tv anyway
[03:46:49 CET] <klaxa> probably
[03:48:36 CET] <kiwi_banal> That's all he wants at this point. Cheers, furq
[04:47:54 CET] <FishPencil> How much faster *should* ffmpeg be with multithreading? I'm seeing anywhere from 7 to 50% faster depending on the number of cores/threads available
[04:48:11 CET] <furq> that depends on a lot of things you didn't mention
[04:48:34 CET] <r0ute> Number of CPU's would be quite a big factor there.
[04:49:13 CET] <FishPencil> For example, from 1 to 2 cores it was 14% faster, 2 to 3 it was 42% faster, and 3 to 4 it was 7% faster.
[04:49:56 CET] <FishPencil> The CPU was an i5, so 2 cores 4 threads
[04:51:19 CET] <FishPencil> Hyperthreading is probably playing a big roll here
[04:51:21 CET] <furq> i was thinking more of the codec
[04:51:26 CET] <furq> and also whether you mean encoding or decoding
[04:51:32 CET] <FishPencil> libx264
[04:51:49 CET] <FishPencil> Encoding
[04:52:33 CET] <furq> i mean that's a 75% speedup with two cores
[04:52:39 CET] <furq> that sounds pretty good to me
[04:52:55 CET] <furq> physical cores, that is
[04:54:09 CET] <FishPencil> Where are you getting 75% from
[04:54:29 CET] <furq> 03:49:14 ( FishPencil) For example, from 1 to 2 cores it was 14% faster, 2 to 3 it was 42% faster, and 3 to 4 it was 7% faster.
[04:54:42 CET] <furq> that adds up to 73.2%
[04:55:33 CET] <FishPencil> Um... 63?
[04:55:47 CET] <furq> https://www.google.co.uk/search?q=(((100%20%2B%2014%25)%20%2B%2042%25)%20%2B%207%25)
[04:55:58 CET] <furq> also you should use 6 threads with x264 if you have 4 logical cores
[04:56:09 CET] <furq> that's what it would pick automatically
[04:56:26 CET] <FishPencil> It's an i5, two cores, 4 threads total
[04:56:31 CET] <furq> yes
[04:57:38 CET] <FishPencil> How does one use 6 threads when 4 are available? -threads 6?
[04:57:47 CET] <furq> well ideally just get rid of -threads
[04:58:04 CET] <furq> but -threads 6 will do the same thing
[04:58:07 CET] <FishPencil> It wasn't used, so it would do that anyway
[04:58:31 CET] <FishPencil> Does it anyways do n+2?
[04:58:37 CET] <furq> n*1.5
[05:00:45 CET] <FishPencil> Is there a reason for the odd dispersion of improvement? I'm not sure how hyperthread is effecting this, but how does that play a roll
[05:01:09 CET] <furq> ask intel
[05:01:23 CET] <furq> and your os vendor, since they're the one responsible for the thread scheduling
[05:02:47 CET] <FishPencil> furq: Thanks for the input
[05:03:16 CET] <furq> i assume -threads 2 is using one logical core during this phase of the moon
[05:03:32 CET] <furq> one physical core
[05:05:42 CET] <FishPencil> I changed the # of threads/cores on an OS level, so I'm not sure if it's doing one core and hyperthreading it to get the one and two, and then the 2nd core comes in at 3
[05:05:50 CET] <FishPencil> That would make the most sense
[05:05:58 CET] <furq> probably
[05:06:33 CET] <FishPencil> Also explains the jump to 42% faster
[05:06:51 CET] <FishPencil> So you could assume a "hyperthread" only helps 7-14%
[05:07:05 CET] <FishPencil> Though that might be a jump
[05:09:28 CET] <FishPencil> x265 did a similar thing, 18.7, 42.6, and 5.6.
[05:20:29 CET] <lindylex> I am trying to crop and slice in time the length of a video and it does not crop it at all.  This is what I tried.  ffmpeg -i acrobaticyoga_Sara_R_2.mp4 -ss 00:00:00.0 -t 00:01:03.0 -codec:v libx264 -vf "crop=640:640:320:60" -profile:v baseline -preset slow -pix_fmt yuv420p -r 29.97 -b:v 3500k -threads 0 -acodec aac -ar 44100 -filter:v "setpts=.96*PTS" -y o.mp4
[05:34:48 CET] <klaxa> i think -filter:v overwrites -vf
[05:39:35 CET] <thebombzen> lindylex: why are you using setpts=0.96*PTS
[05:39:59 CET] <lindylex> i was tryng to slow the movie down.  But I do not need to.
[05:40:09 CET] <thebombzen> then do not do that because that's going to mess stuff up
[05:40:18 CET] <lindylex> ok
[05:40:18 CET] <thebombzen> especially if you don't slow the audio down too
[05:40:39 CET] <thebombzen> remember that with digital hardware we don't need to pulldown
[05:41:00 CET] <thebombzen> everything's progressive so we don't need to do weird stuff like that
[05:41:51 CET] <lindylex> That worked
[05:43:13 CET] <lindylex> how do you recomend I speed up the video so it plays with within 60 seconds instead of 63
[05:43:18 CET] <lindylex> 63 seconds?
[05:46:40 CET] <furq> -vf "crop=640:640:320:60,setpts=1.05*PTS" -af atempo=1.05
[05:47:21 CET] <furq> er
[05:47:42 CET] <furq> -vf "crop=640:640:320:60,setpts=(60/63)*PTS" -af atempo=1.05
[05:52:03 CET] <lindylex> furq: Thanks
[05:52:58 CET] <lindylex> Is -af the audio tempo?
[05:54:16 CET] <klaxa> lindylex: https://ffmpeg.org/ffmpeg-filters.html#atempo
[05:55:37 CET] <lindylex> Thanks got it now.  -vf "crop=640:640:320:60,setpts=(60/63)*PTS"  This here the 60 is how long I want the video to play and 63 is the length in seconds of the cut?
[06:26:31 CET] <lindylex> Why does this not work for my video after I slice it and copy the audio and video codec?  ffmpeg -i o.mp4 -codec:v libx264 -vf "crop=640:640:320:60" -profile:v baseline -preset slow -pix_fmt yuv420p -r 29.97 -b:v 3500k -threads 0 -an -filter:v "setpts=0.95*PTS" -y o2.mp4
[06:28:06 CET] <furq> 04:34:48 ( klaxa) i think -filter:v overwrites -vf
[07:03:25 CET] <furq> https://theintercept.com/2017/03/07/wikileaks-dump-shows-cia-could-turn-smart-tvs-into-listening-devices/
[07:03:30 CET] <furq> in case you needed another reason to not buy a smart tv
[09:13:26 CET] <lindylex> furq: thanks for sharing that article.
[14:15:45 CET] <sybariten> oh hai
[14:16:34 CET] <sybariten> I have a wmv file and what i want to do, although i don't know if this is really technically possible, is to split it up into its audio and video components (two files) with as little as possible or no re-encoding
[14:16:59 CET] <sybariten> Do i need to find out axactly what is inside that wmv container first?
[14:18:00 CET] <c_14> depends
[14:18:04 CET] <c_14> Just for splitting, no
[14:18:12 CET] <c_14> but depending on what you want to do with it afterwards maybe
[14:18:28 CET] <sybariten> yeah, my inital attempt must have been wrong in some way, at least. THe original wmv is 156 megs, and i got a 234 mb wma file and a 62 mb wmv video file
[14:19:06 CET] <sybariten> I'm guessing were probably dealing with 90 percent vidoe and 10 percent audio in terms of data here
[14:19:07 CET] <DHE> ffmpeg -i inputfile.wmv -map 0:v -c copy output-video.mp4  -map 0:a -c copy output-audio.mp4   # adjust extensions to more suitable ones depending on codecs, etc
[14:19:34 CET] <c_14> I'd probably use wmv as extension instead of mp4 just because then you'll know the codec'll fit
[14:20:00 CET] <DHE> point taken...
[14:21:15 CET] <sybariten> i did this, from some web searches...      ffmpeg -i $jacob/Webinar_uncut.wmv -map 0:0 -vcodec copy $jacob/tempo/daVideo.wmv -map 0:1 -acodec copy $jacob/tempo/daAudio.wma   this is the one that gave a 234+62 Mb file
[14:21:30 CET] <sybariten> i mean one of 230 and one of 60
[14:21:58 CET] <c_14> stream 0 might not be video, and stream 1 might not be audio
[14:22:08 CET] <c_14> use what DHE wrote just with wmv instead of mp4
[14:23:08 CET] <DHE> that makes a lot of sense. "acodec" won't set a video codec which means mpeg2 video by default, right?
[14:23:20 CET] <DHE> mine is more generic and likely to work as intended
[14:23:30 CET] <DHE> and hopefully should finish in less time than it takes to sneeze
[14:23:32 CET] <sybariten> okay, uh.... i notice now i have probably mixed something up. The 234 mb .wma file i got is actually the video, and the 60 mb wmv files is the audio track . So at least the audio is smaller than the video, thats as expected
[14:24:27 CET] <c_14> DHE: msmpeg4v3 apparently
[14:24:28 CET] <sybariten> but ill try DHEs advcive
[14:26:53 CET] <sybariten> ooh that was a magnitude faster
[14:27:06 CET] <sybariten> and the sum of the files match up with my original wmv!
[14:27:24 CET] Action: DHE takes a bow
[14:27:30 CET] <sybariten> grazie!
[14:27:44 CET] <sybariten> What am i doing with the map ... is it "command" ? Argument?
[14:28:11 CET] <DHE> it tells ffmpeg which streams (audio, video, etc) you want to go into the output file. from input file 0, stream 'v' (preferred video)
[14:28:13 CET] <DHE> and so on
[15:10:23 CET] <shincodex> av_dict_set(&options, "profile", "High 10", 0);
[15:10:39 CET] <shincodex> if (avcodec_open2(codecContext, codec, &options) > -1)
[15:10:44 CET] <shincodex> h264 codec
[15:10:47 CET] <shincodex> h264.c
[15:10:55 CET] <shincodex> Why does the profile for decoding
[15:10:57 CET] <shincodex> not set
[15:11:09 CET] <shincodex> trying to fix blocky/pixelation with this codec
[15:11:32 CET] <DHE> you don't set a decoding profile. only encoding
[15:12:06 CET] <shincodex> So i got no decoding options
[15:12:09 CET] <DHE> the profile specifies the capabilities of the decoder. like "Baseline" for the free libopenh264 (?) player, or first generations of phones
[15:12:10 CET] <shincodex> to alleviate it
[15:12:47 CET] <DHE> it's too late. sounds like the input is either damaged or overcompressed
[15:12:52 CET] <shincodex> Some images it contains 30% of the image
[15:13:02 CET] <shincodex> then mirrors the bottom scanline
[15:13:03 CET] <shincodex> retardedly
[15:13:05 CET] <shincodex> other images
[15:13:12 CET] <shincodex> ITs like someone took a mixxed bag of ink
[15:13:14 CET] <BtbN> so the file is broken
[15:13:16 CET] <shincodex> and splooged it on the image
[15:13:24 CET] <DHE> broken
[15:13:30 CET] <shincodex> So your thinking
[15:13:33 CET] <shincodex> fix the encoding
[15:13:55 CET] <shincodex> User was lead to believe that VLC somehow handled it better
[15:14:01 CET] <shincodex> and I looked at it in vlc do the same effect
[15:14:19 CET] <shincodex> i did not turn on libx264
[15:14:42 CET] <BtbN> VLC also just used lavc for decoding h264
[15:14:58 CET] <BtbN> You can't fix a broken file with magic decoder flags
[15:16:46 CET] <shincodex> thanks
[15:16:52 CET] <shincodex> Its coming to me RTSP
[15:17:01 CET] <shincodex> and i believe they just send it h264
[15:17:04 CET] <shincodex> of some recorded file
[15:17:08 CET] <shincodex> il ltell them to fix there camera
[15:17:11 CET] <shincodex> Any suggestions?
[15:17:22 CET] <shincodex> like tell them to do baseline profile or crf 18
[15:17:42 CET] <shincodex> the camera might be 900 years old for all i know too or they have stupid networks
[16:04:44 CET] <Guest80384> comr
[16:08:36 CET] <Guest80384> shall I have to complete the expected task to work in the community.
[16:33:52 CET] <durandal_1707> Guest80384: ?
[17:34:11 CET] <kepstin> found out yesterday that the 'concat' filter doesn't handle inputs with different framerates correctly
[17:34:39 CET] <kepstin> it doesn't set out framerate on the out links at all, so the default ffmpeg behaviour of "copy from first input" kicks in
[17:35:09 CET] Action: kepstin has done the trivial patch for the issue - explicitly setting output frame rate to '1/0' to indicate vfr/unknown
[17:35:12 CET] <kepstin> i guess I should post that.
[17:40:53 CET] <kepstin> (could probably use a test tho, which is a bit more annoying to write)
[17:41:29 CET] <alexpigment> kepstin: tbh that *seems* like a thing that wouldn't work
[17:41:55 CET] <alexpigment> probably because 99.99% of users out there are probably using concat on videos encoded with the same parameters
[17:42:04 CET] <alexpigment> otherwise, you know, you'd probably be using a video editor ;)
[17:42:20 CET] <kepstin> this is the concat filter, it doesn't matter how the video's encoded...
[17:42:45 CET] <alexpigment> i'm considering frame rate to be part of the encoding parameters
[17:42:59 CET] <kepstin> and my friend who originally hit the issue has verified that it does actually handle the frame rate transitions correctly in the pts values
[17:43:23 CET] <kepstin> so it just is missing the bit where it indicates vfr output
[17:44:26 CET] <kepstin> (I think the case he was hitting was working with ntsc video with mixed detelecined 24fps content and deinterlaced 30/60fps content)
[17:45:03 CET] <alexpigment> interesting. still, that seems like something you'd want to do in Adobe Premiere
[17:45:12 CET] <alexpigment> but i guess you can do a hell of a lot with FFMPEG
[17:53:53 CET] <furcifer> Hello, everybody
[17:54:55 CET] <furcifer> I have a video with very few colors (console output). If it was an image I would save it to a PNG with reduced palette size to make the file length shorter.
[17:55:55 CET] <furcifer> I am looking for something like this for videos. I am not sure whether look up tables are the thing I am looking for.
[18:02:16 CET] <c7j8d9> I am trying to convert a remux h.264 to a hevc. Is it possible to create a 10bit from this remux which  is 8bit? Or is that a waste?
[18:02:38 CET] <DHE> don't
[18:02:41 CET] <DHE> just don't do that
[18:03:46 CET] <kepstin> I suppose if you want a smaller file with slight quality loss you might do that :/ (but obviously it's a re-encode, not a remux)
[18:07:00 CET] <BtbN> Is 25~27 FPS for "-c:v libx265 -preset medium -crf 26" a decent result?
[18:07:30 CET] <alexpigment> yeah, 25-27 seems pretty good in my experience
[18:07:56 CET] <c7j8d9> what advantage does 10bit have over 8bit with hevc? when would it come in handy?
[18:08:27 CET] <alexpigment> c7j8d9, it's an expanded color range. in my opinion, it's only important for source content that you're going to be further editing or color grading
[18:08:44 CET] <alexpigment> in the consumer sphere, it's a necessary part of 4K HDR
[18:09:13 CET] <alexpigment> if you don't know what it is, you probably don't need to use it
[18:09:30 CET] <kepstin> c7j8d9: with h264, there's some benefit in some video sources of using 10bit even on 8bit sources, since it improves the accuracy of bases used for predicted frames. Popular with anime encoders, benefit is fairly minimal iirc
[18:09:34 CET] <BtbN> I really like this 8 core so far. It's doing what it should.
[18:09:40 CET] <c7j8d9> so for storing bluray 1080p 8bit is more than enough?
[18:09:54 CET] <alexpigment> blu-ray is inherently 8-bit
[18:10:17 CET] <alexpigment> (non-UHD blu-ray, that is)
[18:10:31 CET] <c7j8d9> alexpigment: thanks
[18:10:36 CET] <alexpigment> np
[18:12:10 CET] <alexpigment> furcifer: are you using H.264 CRF already?
[18:12:47 CET] <furcifer> I know of crf, but I encode webm.
[18:13:05 CET] <alexpigment> webm has a qscale encoding method
[18:13:10 CET] <alexpigment> not as good as CRF, but it's there
[18:14:15 CET] <alexpigment> last i checked - and it's been several years since i even tried webm - you had to set both a CRF and a bitrate. and the bitrate effectively acted as the maxrate
[18:14:20 CET] <kepstin> by 'webm' you mean vp8/vp9?
[18:14:23 CET] <furcifer> I use "-b:v 0 -crf whatever", I though qscale is outdatet.
[18:14:25 CET] <alexpigment> i suspect that's been changed
[18:14:37 CET] <kepstin> the '-crf' parameter in ffmpeg maps to the vp8/vp9 qscale parameter
[18:14:59 CET] <alexpigment> kepstin - do you know if you still have to specify a bitrate?
[18:15:12 CET] <kepstin> in vp9 you no longer need to set a bitrate when using qscale mode, you can give it '0' for unconstrained
[18:15:16 CET] <kepstin> you do with vp8.
[18:16:02 CET] <alexpigment> at any rate, you mentioned you wanted it to act more like PNG. if you set the CRF to 1, you'll get lossless and save the bitrate since you only have console output
[18:16:26 CET] <alexpigment> are the file sizes currently too large when using CRF [whatever] for VP8?
[18:18:00 CET] <furcifer> I only encode VP9. Yes, I want to cut down on altogether video size.
[18:18:38 CET] <alexpigment> but you still want color rather than grayscale?
[18:18:40 CET] <furcifer> Also I try to find all the knobs and switches to cut down on video size while maintaining the quality, at least kinda.
[18:19:00 CET] <furcifer> Yes, console is like 8 bit color output.
[18:19:08 CET] <furcifer> But I don't know for sure.
[18:19:19 CET] <alexpigment> what's your current command line?
[18:19:23 CET] <kepstin> hmm. the change to have the concat filter set output framerate to 1/0 means the pts values in the filter graph output are in AV_TB rather than converted to framerate timebase
[18:19:44 CET] Action: kepstin ponders whether he should leave it like that, or try to find a "common multiple" framerate
[18:20:02 CET] <furcifer> ffmpeg -i 1.webm -vf scale=240:-1,crop=in_w:in_h*.65:1:1,fps=20 -crf 63 out.webm
[18:20:21 CET] <alexpigment> kepstin: if it's 60 & 24 mixed, then 120 is your only common multiple :(
[18:20:45 CET] <kepstin> alexpigment: well, it should work with arbitrary framerates and find a common multiple automatically
[18:20:46 CET] <alexpigment> then again, 30i does have it's advantages :)
[18:21:12 CET] <alexpigment> furcifer: -crf 63?
[18:21:40 CET] <furcifer> Makes smaller output size than 1. I figured by trial and error.
[18:21:44 CET] <alexpigment> i thought the range was 1-51
[18:21:56 CET] <furcifer> Error output tells about -1 as well.
[18:21:56 CET] <alexpigment> i'd guess that it's because it's being ignored
[18:22:09 CET] <alexpigment> what if you put it at, say, 20?
[18:22:49 CET] <furcifer> "Value 64.00000 for parameter 'crf' out of range [-1 - 64]"
[18:22:50 CET] <alexpigment> oh, apparently 63 is the max CRF for VP8. that means it's the absolute lowest quality
[18:23:14 CET] <alexpigment> from the wiki "By default the CRF value can be from 463, and 10 is a good starting point. Lower values mean better quality."
[18:23:15 CET] <furcifer> *63 is the lowest. My typo.
[18:25:01 CET] <alexpigment> anyway, does CRF 10 give you low enough file sizes?
[18:26:33 CET] <furcifer> It is bigger than the file with -crf 63.
[18:26:37 CET] <alexpigment> it should be
[18:26:47 CET] <alexpigment> so you're saying that 63 is too big?
[18:26:53 CET] <alexpigment> (file size)
[18:27:02 CET] <alexpigment> i mean, i'd imagine is unwatchable, right?
[18:27:40 CET] <furcifer> No, console output is still legible. There is not really much moving. Only some counters going up or down.
[18:28:17 CET] <alexpigment> the others here may have more info, but it doesn't sound like vp8 is the ideal codec for the job
[18:30:21 CET] <kepstin> well, vp8's not really an ideal codec for any job, except maybe video playback in old versions of chrome and firefox :/
[18:30:29 CET] <furcifer> So crf is an encoding option. My initial question was about a filter that reduces colors.
[18:31:11 CET] <kepstin> furcifer: with the way these video codecs work, fine detail usually matters more than color
[18:31:16 CET] <alexpigment> yes, i get it. i was really just implying that an efficient encoder should take care of that for you since there aren't many colors on the screen
[18:31:16 CET] <furcifer> I only can compare to my experience in image editing. Thus I referred to color indexing. I don't know whether there is something comparable in videos.
[18:31:22 CET] <kepstin> and text is.. well, lots of fine detail
[18:32:39 CET] <alexpigment> if you have, say, 5 colors on the screen, and those 5 colors never change, you're not wasting bits on extra colors. now if you have gradients and they're changing all the time, there might be some validity and reducing the colors
[18:32:57 CET] <alexpigment> *validity in
[18:34:08 CET] <alexpigment> also, i agree with kepstin's assertion about vp8. i've only used it as an HTML5 fallback, and even then it was just for Firefox on Windows XP
[18:45:55 CET] <obamoose> wait what
[18:46:01 CET] <obamoose> there is an ffmpeg channel?
[18:46:11 CET] <obamoose> hello!
[18:46:37 CET] <alexpigment> hey obamoose
[18:46:39 CET] <furcifer> Hello, obamoose
[18:47:11 CET] <obamoose> this is 2 years old but is it still the right way to loop files in a directory?
[18:47:12 CET] <obamoose> http://stackoverflow.com/questions/25320187/how-to-tell-ffmpeg-to-loop-through-all-files-in-directory-in-order
[18:50:35 CET] <c7j8d9> anyone using ffmpeg with nvidia gpu acceleration?
[18:50:52 CET] <c7j8d9> for h265
[18:59:42 CET] <alexpigment> cjj8d9: yeah, i have
[19:00:14 CET] <alexpigment> it's great for speed
[19:00:31 CET] <alexpigment> but there aren't many parameters
[19:00:45 CET] <alexpigment> and the quality is probably nowhere as good as libx265, though i haven't done tests
[19:01:55 CET] <c7j8d9> what's the command for it?
[19:03:06 CET] <DHE> c7j8d9: have done for h264. it's similar. and as noted, not many options for it.
[19:06:15 CET] <c7j8d9> So if I was using a gui all options would be useless after I enable it. I would just get what i get?
[19:06:19 CET] <obamoose> can anyone help me figure out why my stream is lagging?
[19:06:54 CET] <DHE> c7j8d9: the codec tab would be a lot more barren than if you selected a software encoder like x265
[19:09:36 CET] <c7j8d9> DHE: what is the command line for gpu acceleration?
[19:11:01 CET] <DHE> start with -c:v nvenc_hevc  and then give it your common options like -b:v or -crf
[19:11:54 CET] <DHE> you can use -preset slow (highest quality), -profile main[10] as the most likely additionals for quality and output options
[19:12:17 CET] <DHE> of course this assumes your ffmpeg is up to date. nvenc's seen a lot of work lately
[19:12:59 CET] <c7j8d9> DHE: thanks...and in your experience you lose quality but gain speed?
[19:16:25 CET] <DHE> I only use h264. even in slow mode it still does real-time 1080p without issues at 30fps.
[19:16:51 CET] <DHE> but if I have the choice, I trust x264 over hardware encoding any day.
[19:27:08 CET] <BtbN> alexpigment, I'm pretty sure nvenc_hevc has more than enough parameters: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc_hevc.c#L28
[19:34:30 CET] <persina> What does it mean Movie-Aspect is 3.32:1 - prescaling to correct movie aspect.?
[19:40:30 CET] <alexpigment> c7j8d9: hey, sorry for the late reply. CRF doesn't work with nvenc. you have to use "-global_quality" instead
[19:41:35 CET] <alexpigment> but yeah, i usually encode for delivery formats, broadcast, or streaming
[19:41:40 CET] <alexpigment> nvenc is way too barebones
[19:42:06 CET] <alexpigment> having said that, it's probably fine for anyone doing like blu-ray backups
[19:46:12 CET] <c7j8d9> alexpigment: thanks
[20:11:58 CET] <artista_frustrad> I've got some footage that was supposed to be 24fps but it is actually 23.9fps. Which are the best parameters to convert the frame rate without loosing quality?
[20:18:23 CET] <kepstin> artista_frustrad: I bet it's actually "NTSC" style 24fps, which is really 24/1.001 fps. Do you actually need to convert it? The tricky bit is mostly adjusting the audio so it stays in sync.
[20:18:30 CET] <DHE> can't just leave it at 23.9? not touching it is always the best choice
[20:19:47 CET] <xjmx_> Hi there
[20:20:27 CET] <xjmx_> is there anyone who can help to fix audio synchronization on multicast streams ?
[20:23:50 CET] <xjmx_> Hello guys? is anyone alive there))?
[20:29:00 CET] Last message repeated 2 time(s).
[20:29:15 CET] <Cysioland> How can I convert a variable framerate mjpeg stream to a constant framerate one (possibly duplicating frames)?
[20:30:20 CET] <kepstin> Cysioland: it should normally just require using the '-r <framerate>' or equivalently '-vf fps=<framerate>' output options. depends on whether the input timestamps are correct.
[20:31:33 CET] <kepstin> hmm. I suppose in this case you don't want to re-encode tho?
[20:31:53 CET] <kepstin> I don't think ffmpeg can do anything to help you without re-encoding, unfortunately
[20:31:57 CET] <Cysioland> kepstin, I'd like to reencode it to a more modern format
[20:32:01 CET] <Cysioland> Possibly also delay it
[20:33:19 CET] <xjmx_> Guys, who can say how to keep stream be synchronized? A preset that I'm using going to out of synch in 1 or 2 days
[20:33:31 CET] <xjmx_> ffmpeg -re -i "udp://xxx.xxx.xxx.xxx?fifo_size=1000000&buffer_size=40000000" -map 0:v -map 0:a -c:a aac -c:v copy -flush_packets 0 -f mpegts "udp://xxx.x.x.xx:1234?pkt_size=8648" >/dev/null 2>&1
[20:33:59 CET] <BtbN> restart it every once in a while
[20:34:14 CET] <xjmx_> is it the only one way only ?
[20:34:38 CET] <xjmx_> maybe it can be detectable somehow ?
[20:35:05 CET] <llogan> if you play the input for a few days is it also out of sync?
[20:35:40 CET] <xjmx_> the input is fine
[20:35:46 CET] <llogan> that was a quick test
[20:35:57 CET] <Cysioland> kepstin, this does not work, it still does not record second-to-second, thus video is sped up
[20:36:00 CET] Last message repeated 1 time(s).
[20:37:09 CET] <xjmx_> any other ideas ?
[20:37:27 CET] <xjmx_> how it can be handled...
[20:37:32 CET] <llogan> if you output to a local file then play it does it also go out of sync?
[20:37:43 CET] <kepstin> Cysioland: ah, yeah, the mjpeg demuxer assumes a constant framerate. I assume this is from a variable framerate live source?
[20:38:47 CET] <Cysioland> kepstin, yup, from a very crappy web cam
[20:39:05 CET] <Cysioland> So FPS is dependent on the humors of crappy CPU inside the camera
[20:39:06 CET] <xjmx_> llogan yes, already checked this
[20:39:19 CET] <kepstin> Cysioland: you'll probably have to retime the frames based on local rtc then. You can do this with the setpts filter, just a moment...
[20:40:06 CET] <Cysioland> kepstin, I want this to, finally, go for a restream
[20:40:09 CET] <kepstin> Cysioland: try "-vf settb=AV_TB,setpts=RTCTIME-RTCSTART,fps=24" or something like that
[20:40:27 CET] <kepstin> that'll set frame timestamps based on local rtc, then redo the stream as cfr 24
[20:40:57 CET] <llogan> xjmx_: i guess that narrows it down a little that it is probably not due to it being a network output
[20:41:06 CET] <kepstin> er, typo, -vf settb=AVTB,setpts=RTCTIME-RTCSTART,fps=24
[20:45:34 CET] <xjmx_> so guys maybe you know a sources where I can get any ideas or answers ?
[20:47:50 CET] <BtbN> Have you tried -vsync passthrough?
[20:48:29 CET] <Cysioland> kepstin, seems to work
[20:49:56 CET] <Cysioland> kepstin, now it's unplayable
[20:50:35 CET] <DHE> xjmx_: every 26.5 hours?
[20:50:42 CET] <xjmx_> BtbN yes, I have tried but maybe you have a ready preset? Is there any debug commands for ffprobe ?
[20:50:49 CET] <xjmx_> how to detect asynch
[20:51:42 CET] <xjmx_> DHE I'm not sure :(
[20:52:09 CET] <Cysioland> kepstin, my cmdline: ffmpeg -f mjpeg -analyzeduration 5000 -probesize 20000 -i http://10.0.0.5/VIDEO.CGI -vf settb=AVTB,setpts=RTCTIME-RTCSTART,fps=24 test.mp4
[20:52:20 CET] <Cysioland> Video seems to be correct length, but is unplayable
[20:52:54 CET] <kepstin> Cysioland: unplayable with what player? can you try with e.g. ffplay, give full output? and also the ffmpeg output?
[20:53:57 CET] <Cysioland> kepstin, unplayable with Windows 10 one (Groove probably). ffplay cannot try, because currently am doing it on a headless machine.
[20:59:47 CET] <Cysioland> kepstin, https://gist.github.com/Cysioland/a1a5e41cec1cc9b86b79a7c1ea115de8
[21:00:33 CET] <kepstin> Cysioland: your problem is probably https://gist.github.com/Cysioland/a1a5e41cec1cc9b86b79a7c1ea115de8#file-gistfile1-txt-L16-L17
[21:02:48 CET] <Cysioland> kepstin, trying that...
[21:03:38 CET] <kam187> anyone have experience with flv/rtmp (libavformat i.e. using the library not ffmpeg binary)?  I'm trying to do resolution change mid stream.  I've sent onMetaData and AVC updates but youtube and twitch both do not change resolution.
[21:05:49 CET] <Cysioland> kepstin, works, that camera is utter poop though
[21:10:30 CET] <Meins_da> Hello!
[21:10:38 CET] <Meins_da> i need help with udp streaming
[21:11:46 CET] <Meins_da> my client is a Setupbox with a 100MBit connection. My server has a 1GB. Between the two devices i have 3 switches. the last one before the setupbox can handle igmp snooping
[21:12:17 CET] <Meins_da> if i use this setup, i have problems to stream, if i set the server interface to 100MBit half duples, it works...
[21:12:37 CET] <Meins_da> it seems that ffmpeg sends the data tooo fast to the client
[21:14:41 CET] <BtbN> are you streaming at more than 100Mbps? oO
[21:15:02 CET] <Meins_da> Hi BtbN
[21:15:05 CET] <thebombzen> o_O
[21:15:09 CET] <Meins_da> at the moment i have one stream
[21:16:34 CET] <Meins_da> on my pc with 1gb (it is also connected to the last switch) it also works perfect, but it has more performance than the stp
[21:27:48 CET] <Meins_da> No idea BtbN?
[21:28:03 CET] <BtbN> Well, are you?
[21:28:10 CET] <BtbN> Still haven't answered.
[21:40:42 CET] <thebombzen> Meins_da: "ffmpeg is sending the data too fast to the client"
[21:40:48 CET] <thebombzen> check out the -re input option
[21:44:00 CET] <Meins_da> yes the -re is set
[21:45:08 CET] <thebombzen> well then you shouldn't be sending data too fast
[21:45:14 CET] <thebombzen> if your client can't read realtime data then your client sucks
[21:45:41 CET] <Meins_da> ffmpeg -threads 2 -re -fflags +genpts -i samsung_low_1M_2M.ts -vcodec copy -acodec copy -f mpegts "udp://239.2.0.2:1234?broadcast=1"
[21:46:00 CET] <Meins_da> thebombzen it is a MAG256
[21:46:28 CET] <thebombzen> that does not actually answer anything
[21:46:36 CET] <thebombzen> if you are broadcasting the data in realtime
[21:46:39 CET] <thebombzen> but realtime is too fast
[21:46:43 CET] <thebombzen> then there's nothing ffmpeg can do about that
[21:46:51 CET] <thebombzen> because if realtime is too fast then you can't stream.
[21:47:17 CET] <thebombzen> because in order to stream, you have to be able to consume video in realtime
[21:47:22 CET] <thebombzen> otherwise there's really no point
[21:51:22 CET] <Meins_da> do you mean that the software of  the mag has a problem?
[21:52:00 CET] <thebombzen> what I"m saying is, if you're producing video in realtime
[21:52:03 CET] <thebombzen> but realtime is "too fast"
[21:52:10 CET] <thebombzen> then you need to fix whatever is unable to consume video in realtime
[21:52:34 CET] <Meins_da> can you check my command line if this is ok?
[21:52:50 CET] <thebombzen> your ffmpeg command line is the producer
[21:52:59 CET] <thebombzen> your problem is you cannot consume the video in realtime
[21:53:07 CET] <thebombzen> you need to fix that problem, or you won't be able to play a livestream
[21:53:48 CET] <Meins_da> i don't understand you at the moment.
[21:54:08 CET] <Meins_da> do you think i can't read the file fast enouth?
[21:55:37 CET] <IntruderSRB> hey guys, do you know if FFMPEG has added support for HLS with fMP4 cbcs encryption support?
[21:56:01 CET] <IntruderSRB> I saw some changes regarding encryption and HLS on mailing list but didn't managed to find this one out
[22:00:20 CET] <JEEB> IntruderSRB: you can check what encryption mode the cenc thing in movenc.c uses, and if it's not there it's not implemented
[22:00:38 CET] <JEEB> if it's not implemented then make a feature request.
[22:00:53 CET] <JEEB> normal MPEG-TS HLS encryption is supported, and has been for years.
[22:02:57 CET] <JEEB> feature requests go to the trac, just fyi
[22:03:17 CET] <JEEB> (also another alternative is that you implement the feature and post a patch on the ML)
[22:06:57 CET] <IntruderSRB> nop ... looks like only MOV_ENC_CENC_AES_CTR
[22:07:01 CET] <IntruderSRB> is supported now
[22:07:27 CET] <IntruderSRB> I'll be the first to share patch once I get my CENC_AES_CBC to work :)
[22:39:30 CET] <IntruderSRB> btw. if anyone has any m3u8 playlist that uses fmp4 with cbcs - please share, I fail to find any...
[22:42:26 CET] <JEEB> https://tools.ietf.org/html/draft-pantos-http-live-streaming-20#page-14
[22:42:29 CET] <JEEB> probably the relevant part
[22:43:03 CET] <JEEB> so it seems to be the same as with "normal HLS"
[22:49:04 CET] <bray90820> OF TOPIC: Can any device that can play MP4 play M4V
[22:49:32 CET] <thebombzen> what is m4v
[22:49:55 CET] <thebombzen> because iTunes' file extension .m4v is not the same as ffmpeg's m4v encoder
[22:49:59 CET] <thebombzen> m4v muxer*
[22:50:19 CET] <bray90820> Well isn't the only difference that M4 on itunes has DRM?
[22:50:25 CET] <thebombzen> apple's .m4v files are just mp4 files (possibly with drm)
[22:50:42 CET] <bray90820> thebombzen: Yeah that's what I was talking about
[22:50:51 CET] <thebombzen> well then the answer is yes as long as there's no drm
[22:51:00 CET] <bray90820> thebombzen: Thanks
[22:51:13 CET] <thebombzen> it doesn't matter what the filename is, if it's an mp4 file without drm then it's still an mp4 file even if apple thinks .m4v is cooler than .mp4
[22:51:50 CET] <thebombzen> if it's got drm then you can only play it on iDevices which definitely can play it
[00:00:00 CET] --- Thu Mar  9 2017