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

[burek]

[00:00:08 CET] <alexpigment> yeah, i'd made sure and test that parameters on your friend's computer if it failed on QSV. i know that it's required at least up until haswell, and possible on current hardware
[00:01:09 CET] <TehEpikDuckeh> It failed on his computer whenever I did CUVID to QSV. But using just the GPU, it was really fast for even HEVC to H264.
[00:01:56 CET] <TehEpikDuckeh> NVIDIA should make a dedicated card for just CUVID and NVENC. They could sell the ASIC for very cheap and people would buy it. I'd buy it for the server.
[00:02:26 CET] <TehEpikDuckeh> Just installed the drivers again, but nope.avi
[00:02:31 CET] <alexpigment> :(
[00:02:34 CET] <TehEpikDuckeh> :/
[00:02:40 CET] <alexpigment> well, i'm not entirely sure what else to do
[00:02:50 CET] <TehEpikDuckeh> Neither do I.
[00:02:51 CET] <alexpigment> have you omitted the cuvid part to see if it's just the decoding that's failing?
[00:02:55 CET] <TehEpikDuckeh> I'm probably going to build again.
[00:02:59 CET] <TehEpikDuckeh> rebuild*
[00:03:07 CET] <TehEpikDuckeh> It's just HEVC_CUVID that's the issue.
[00:03:10 CET] <ZeroWalker> hmm, so when i got a packet from x264, should i then sent it to a muxer that will write and append?
[00:03:28 CET] <TehEpikDuckeh> I could use H264_CUVID to HEVC, or H264_NVENC and it works just fine.
[00:03:46 CET] <ZeroWalker> and which part will do the frame syncing according to the timestamps "so if i receive 20fps but i want it to be 30fps, it will duplicate frames to make it so" kinda thing
[00:03:51 CET] <alexpigment> oh i see. hmmm, i haven't tested HEVC cuvid to be honest
[00:03:56 CET] <BtbN> There was Crystal HD. It was shit.
[00:04:19 CET] <TehEpikDuckeh> alexpigment: Must be extremely new due to issues as such. H264_CUVID is just fine.
[00:05:15 CET] <TehEpikDuckeh> Actually, H264_CUVID to HEVC_NVENC is extremely fast. Last night I tested it and it was encoding around 1000 fps. I thought it was a glitch, but it wasn't. Quality was a bit crappy (hence 1000 fps) but it was a cool test.
[00:05:50 CET] <alexpigment> yeah, quality is certainly the secondary priority
[00:06:04 CET] <alexpigment> (for nvidia, i mean)
[00:06:19 CET] <TehEpikDuckeh> How do you mean?
[00:06:49 CET] <alexpigment> well, at a given bitrate, nvenc is always worse than x264 or x265
[00:06:56 CET] <alexpigment> but speed is faster
[00:07:08 CET] <alexpigment> and of course resources usage is lower
[00:07:21 CET] <alexpigment> so it's great for, say, screen recording or teleconferencing
[00:07:47 CET] <alexpigment> not great for encoding an optimized file for streaming or disc authoring
[00:07:51 CET] <TehEpikDuckeh> Seriously? But let's say we had the bitrate at a certain amount, 4000 KB/s, would NVENC look just as good as x264/5, or would it be a crappier quality?
[00:08:04 CET] <alexpigment> nvenc would look worse
[00:08:15 CET] <TehEpikDuckeh> Noticeably worse?
[00:08:35 CET] <alexpigment> well, there's a threshold at which it stops mattering because you're reaching transparency
[00:08:50 CET] <alexpigment> but at 4000kbps and below for HD material, yeah, you'll probably notice the difference
[00:08:53 CET] <ZeroWalker> nvenc looks a ton worse compared to x264 on default settings
[00:09:04 CET] <ZeroWalker> same with amd vce
[00:09:11 CET] <alexpigment> and qsv
[00:09:19 CET] <TehEpikDuckeh> Seriously. Wow, had no idea.
[00:09:27 CET] <alexpigment> all the hardware encoders are lagging behind x264 in terms of quality
[00:09:30 CET] <ZeroWalker> done many tests on especially amd vce, it's really bad compared to x264, but that's to be expected
[00:09:31 CET] <TehEpikDuckeh> So all HW transcoding is trash?
[00:09:39 CET] <ZeroWalker> in short, yes
[00:09:42 CET] <TehEpikDuckeh> Wow.
[00:09:51 CET] <ZeroWalker> you only use it for speed, nothing else
[00:09:53 CET] <BtbN> it's CPU free encoding.
[00:09:55 CET] <alexpigment> no, not trash, really. but you have to have a specific use case to justify using hardware encoding
[00:09:57 CET] <TehEpikDuckeh> I only want to use it so I can transcode crap w/o the server dying.
[00:10:07 CET] <ZeroWalker> well in that case it's useful
[00:10:14 CET] <TehEpikDuckeh> ... and so it looks fairly good.
[00:10:24 CET] <ZeroWalker> i mean, like he said, you would never use it for quality per see
[00:10:34 CET] <ZeroWalker> if you got the performance, x264 is what you want
[00:10:36 CET] <TehEpikDuckeh> Hmmm, strange.
[00:10:43 CET] <alexpigment> is this just for streaming to devices, or are you actually using those hardware transcodes as saved copies for posterity?
[00:10:59 CET] <TehEpikDuckeh> Streaming mainly.
[00:11:05 CET] <ZeroWalker> for example, i use amd vce with like 40mbps, and it's still bad
[00:11:06 CET] <BtbN> you can also use them for high quality local second encodes while streaming
[00:11:14 CET] <BtbN> when you don't care about the files being a little larger
[00:11:21 CET] <alexpigment> zerowalker: to be fair, AMD is not even trying in this field ;)
[00:11:24 CET] <TehEpikDuckeh> ZeroWalker: Then something is probably wrong. It probably should look just fine by then.
[00:11:29 CET] <ZeroWalker> they aren't?
[00:11:44 CET] <ZeroWalker> i mean, i wouldn't say quicksync is any better
[00:11:49 CET] <alexpigment> no, they came late to the game
[00:11:57 CET] <alexpigment> and ffmpeg doesn't even support VCE yet
[00:12:04 CET] <TehEpikDuckeh> BtbN: I'd prefer to save space and have things look nice. Hence why I'm attempting HEVC.
[00:12:19 CET] <ZeroWalker> can't say that much for nvenc as i don't have much data on those, or well i got some from maxwell i think
[00:12:23 CET] <alexpigment> intel and nvidia have a good head start compared to VCE
[00:12:30 CET] <ZeroWalker> yeah i don't get why ffmpeg doesn't support VCE
[00:12:38 CET] <ZeroWalker> VCE has existed since 7xxx series
[00:12:51 CET] <ZeroWalker> though their support is horrible
[00:12:55 CET] <BtbN> If you are aiming for quality at minimum size, use x264
[00:12:56 CET] <ZeroWalker> vce that is
[00:12:57 CET] <alexpigment> yeah, but i think it was severely limited then
[00:12:59 CET] <TehEpikDuckeh> Damn, and AMD can't make their crap nicer? Gees.
[00:13:21 CET] <BtbN> you don't just make a hardware encoder that's on par with software encoding
[00:13:24 CET] <alexpigment> having said that, i'm also shocked that 40mbps isn't reaching transparency for 1080p...
[00:13:31 CET] <TehEpikDuckeh> I wonder how good Ryzen is at encoding HEVC.
[00:13:31 CET] <ZeroWalker> well yeah it was, at least resolution wise, and it was weak
[00:14:17 CET] <ZeroWalker> i got r9 380, so i can do 1920x1200 60fps, but i from however have coded for it (i haven't) it seems the SDK etc is just bad and weird
[00:14:56 CET] <ZeroWalker> and i wouldn't brag about the capabilities of the VCE encoder, i have had much issues with it, if you play around you can easily make things freeze up or something
[00:14:58 CET] <TehEpikDuckeh> I was really pissed off whenever I was trying to use an older card on Linux and AMD had no driver support at all for newer versions of Ubuntu. (now I'm on Debian)
[00:15:49 CET] <ZeroWalker> well i heard good things about the encoding quality and performance of Ryzen, though haven't seen any tests, but it should surely be better than what AMD got now, how much however i duno
[00:16:02 CET] <alexpigment> yeah, in the not too distant past, everyone used Nvidia for XBMC on low-end hardware because intel and AMD didn't have driver support for harware decoding. intel came next, and then AMD
[00:16:23 CET] <ZeroWalker> if they could make it 30% better, it would be quite decent quality wise, though i would want like 50+ tbh, but that's wishful thinking;p
[00:16:25 CET] <TehEpikDuckeh> Intel supposedly has some good driver support on Linux.
[00:16:37 CET] <alexpigment> they do now
[00:16:43 CET] <alexpigment> but this was in like 2010 or so
[00:17:35 CET] <alexpigment> i had one of the first gen intel atom systems with an nvidia "ion" graphics card. it could play anything due to having hardware acceleration support on linux at the time. intel and amd didn't have support back then
[00:17:46 CET] <alexpigment> so yeah, i guess it's been like 7 years, but it feels like not too long ago ;)
[00:18:31 CET] <TehEpikDuckeh> I'd like to get some Ryzen hardware to test and make a YouTube video on it. I'd then get a Black Magic HDMI interface device so I can livestream to YouTube. I need some streaming hardware because people on my channel want a livestream for installing macOS 10.13 when it comes out.
[00:18:45 CET] <TehEpikDuckeh> Too much money though :/
[00:18:48 CET] <alexpigment> why blackmagic specifically?
[00:19:04 CET] <TehEpikDuckeh> I like their products. I know I can get cheaper stuff, but they have some nice stuff that "works".
[00:19:07 CET] <alexpigment> hauppauge and elgato make fairly cheap consumer alternatives
[00:19:12 CET] <alexpigment> fair
[00:19:27 CET] <TehEpikDuckeh> I've heard of them, but they seem rather crappy and have a weird gamer appeal to them.
[00:19:36 CET] <TehEpikDuckeh> Especially Elgato.
[00:19:43 CET] <alexpigment> i've been very happy with Elgato over the past few years. they're the only ones who seem to support TV broadcast standards well and "just work"
[00:19:56 CET] <furq> does "weird gamer appeal" mean they're covered in useless LEDs and angular plastic panels that look like optimus prime's bra
[00:20:00 CET] <TehEpikDuckeh> Yeah, I've seen them whenever I was looking for some TV tuners.
[00:20:08 CET] <TehEpikDuckeh> furq: 100%.
[00:20:27 CET] <TehEpikDuckeh> Lol, no, but they have colors and cheap plastic on them w/ a USB 2 interface for 1080i.
[00:20:35 CET] <furq> and they have a heatsink in the shape of a gun
[00:20:41 CET] <TehEpikDuckeh> xD
[00:20:41 CET] <alexpigment> haha
[00:21:15 CET] <TehEpikDuckeh> If I was going to -waste- spend the money on streaming hardware, I'm going to make sure it's semi bullet-proof.
[00:21:25 CET] <alexpigment> anyway, the HD PVR 2 original non-gamer model (model 1512 i think) is my workhorse. it can record 1080i30 with 5.1 audio over HDMI. it's great
[00:21:39 CET] <alexpigment> but i have to use an HD PVR 60 for anything that requires 1080p60
[00:21:55 CET] <alexpigment> it's ok, but i prefer the former for its comparatively pro-level features
[00:21:56 CET] <TehEpikDuckeh> I want to stream at 1080p60. 1080i is just cheap crap for 2017.
[00:22:12 CET] <alexpigment> yeah, i just use it for recording TV and archiving to Blu-ray. so i hear you
[00:22:13 CET] <TehEpikDuckeh> ... if it were new.
[00:22:41 CET] <furq> don't all the livestreaming services have ridiculously low bandwidth limits that make 1080p60 worthless
[00:22:46 CET] <ZeroWalker> http://sprunge.us/JSiT
[00:22:46 CET] <TehEpikDuckeh> I'd like to have a 4k30 capture device, but EHHHHH, that money thing isn't cheap to invest into.
[00:22:54 CET] <furq> at least for games, which is the only thing where you'd notice the difference
[00:22:58 CET] <ZeroWalker> hints on the next step after getting the packet there;)
[00:23:02 CET] <TehEpikDuckeh> Actually, YouTube isn't that bad.
[00:23:24 CET] <llogan> a $3200 TS anal-yzer that won't let you use it in a VM...
[00:23:27 CET] <alexpigment> furq: yeah, twitch is like 3500kbps or less. most people do 720p60
[00:24:16 CET] <ZeroWalker> i stream to youtube at 40mbps
[00:25:57 CET] <alexpigment> zerowalker: and then they re-encode it at horrible joke-level quality ;)
[00:26:09 CET] <ZeroWalker> indeed;P
[00:26:25 CET] <ZeroWalker> but at least it has a non-horrible source, so that's something xd
[00:26:32 CET] <alexpigment> i agree with that
[00:27:41 CET] <ZeroWalker> i would like to have some way to keep the source like twitch, but with at least higher bitrate, then again i can't stream with x264 so my quality would basically be worse then the youtube re-encode anyway
[00:28:07 CET] <alexpigment> yeah, doing twitch on x264 is pretty demanding
[00:28:12 CET] <furq> use the tee muxer or stream via a local nginx-rtmp which records a copy
[00:28:56 CET] <ZeroWalker> yeah, but sadly that's the only way to achieve decent quality on that bitrate;(
[00:29:39 CET] <alexpigment> yep, i had to guide a friend through that process and was ultimately just like "ok, use nvenc, and accept that this is what it looks like"
[00:29:46 CET] <furq> i bet a 3.5mbit nvenc 1080p60 encode of a fast fps looks just great
[00:29:48 CET] <furq> also i am lying
[00:29:52 CET] <alexpigment> haha
[00:30:15 CET] <TehEpikDuckeh> alexpigment: What should I configure my FFmpeg build w/?
[00:30:20 CET] <alexpigment> 1080p60 at 3.5 looks pretty bad on x264 too, for what it's worth
[00:30:24 CET] <furq> last time i did a 720p60 encode of quakeworld with x264 veryslow it ended up at about 11mbit
[00:30:29 CET] <alexpigment> since you can't even do 2-pass
[00:30:39 CET] <furq> although quakeworld is probably some kind of pathological worst case for a modern video encoder
[00:30:50 CET] <alexpigment> did you set a CRF?
[00:31:02 CET] <furq> yeah i started at crf 20 and it was hitting 15mbit or so
[00:31:06 CET] <furq> i had to step it down a lot
[00:31:06 CET] <alexpigment> tehepikduckeh are you compiling on linux?
[00:31:13 CET] <alexpigment> yeah, you probably are
[00:31:14 CET] <alexpigment> :)
[00:31:16 CET] <furq> this was ages ago though so i forget what i actually used
[00:31:20 CET] <furq> it looks shit on youtube anyway
[00:31:49 CET] <TehEpikDuckeh> alexpigment: Correct.
[00:31:50 CET] <alexpigment> tehepikduckeh - used a build script on linux for windows, so admittedly, i'm not sure what you need to build with
[00:32:01 CET] <alexpigment> but make sure all the nvidia stuff is enabled if you have a list of available options
[00:32:10 CET] <TehEpikDuckeh> alexpigment: Do you still have that script? I might be able to copy the configuration it has.
[00:32:12 CET] <thebombzen> how do you have 40 Mbps of internet access lol
[00:32:17 CET] <alexpigment> (i'm very new to this, so i'd actually defer to the experts here)
[00:32:33 CET] <furq> 40mbps up isn't that impressive any more
[00:32:38 CET] <TehEpikDuckeh> thebombzen: You know what's funny, I have 180 down, but 10-15 up ~_~
[00:32:42 CET] <furq> i'm on cable and i could have 20 if i could be bothered to upgrade
[00:32:57 CET] <alexpigment> thebombzen: living in austin, the minimum is 100mbps down for most services
[00:33:03 CET] <furq> and the FTTC providers round here do 20 up if you're close enough to the cabinet
[00:33:05 CET] <thebombzen> I'm referencing up
[00:33:10 CET] <thebombzen> I have 150 down
[00:33:19 CET] <TD-Linux> I'm 20/2, which is actually quite livable when de-bufferbloated
[00:33:26 CET] <TehEpikDuckeh> I understand, but it's just crazy. Fiber-4-America.
[00:33:28 CET] <alexpigment> oh yeah, up speed is lower than 40mbps on my end
[00:33:29 CET] <thebombzen> "[18:24:16] <ZeroWalker> i stream to youtube at 40mbps"
[00:33:29 CET] <furq> yeah i had 20/2 adsl2+ for years
[00:33:29 CET] <alexpigment> nm
[00:33:35 CET] <furq> it was all right
[00:33:36 CET] <alexpigment> yeah, i'm an idiot, it's ok ;)
[00:33:38 CET] <furq> i wouldn't go back to it though
[00:33:46 CET] <TD-Linux> furq, I can choose between this and bandwidth capped comcast
[00:33:53 CET] <furq> what's the bandwidth cap
[00:34:00 CET] <furq> isn't it like 1TB a month or something
[00:34:06 CET] <thebombzen> yea
[00:34:08 CET] <alexpigment> tehepikduckeh: https://github.com/rdp/ffmpeg-windows-build-helpers <-- this is what i used
[00:34:15 CET] <TehEpikDuckeh> Thanks!
[00:34:19 CET] <thebombzen> I have comcast (competition is for losers)
[00:34:22 CET] <furq> actually i guess 20mbps for a month is 6.5TB
[00:34:24 CET] <TD-Linux> furq, they were doing 250GB at one point
[00:34:28 CET] <thebombzen> so I have a bandwidth cap
[00:34:39 CET] <furq> i have 150 down and i don't think i've ever exceeded 1TB down
[00:34:41 CET] <thebombzen> I didn't know I had a bandwidth cap tho until I went to some website that wasn't https
[00:34:49 CET] <furq> although my router doesn't track it reliably
[00:34:57 CET] <thebombzen> and then comcast injected something into the html to tell me that I was close to my cap
[00:35:02 CET] <alexpigment> ok guys, gotta head out. good luck duckeh
[00:35:21 CET] <thebombzen> but I think I have 1 TB
[00:35:26 CET] <TD-Linux> I'd have to check again, I guess it hasn't bothered me enough to reevaluate comcast yet
[00:35:28 CET] <thebombzen> my roommate handles the internet bills so I'd have to ask him
[00:35:38 CET] <TD-Linux> I think I could get 150/20
[00:35:39 CET] <thebombzen> comcast is a piece of shit
[00:35:47 CET] <thebombzen> but it's also my only option
[00:35:58 CET] <thebombzen> #natural monopoly
[00:36:09 CET] <furq> apparently i have 250GB/150GB down/up in 60 days
[00:36:16 CET] <furq> but i've definitely rebooted my router in the last 60 days, so that can't be right
[00:36:32 CET] <furq> it's cool that this router can't even track uptime reliably
[00:38:19 CET] <thebombzen> it's okay it's using av_gettime_relative
[00:38:25 CET] <furq> ;_;
[00:39:07 CET] <TD-Linux> >$150/mo nope
[00:39:45 CET] <furq> i know someone who gets 1G fttp for £30/month
[00:39:54 CET] <furq> although it's in a building where the rent is £2000/month so it probably evens out
[00:42:53 CET] <TD-Linux> heh I've only done 40GB the last two weeks
[00:43:48 CET] <furq> my isp used to throttle upload to 6 and then 4mbit during peak hours, but they seem to have stopped that now unless you're taking the piss
[00:44:02 CET] <furq> since that happened i'm pretty happy with 10mbit up
[00:48:29 CET] <thebombzen> I think I have 150 down 10 up
[00:48:43 CET] <thebombzen> it might be 100/10 tho
[00:48:56 CET] <thebombzen> I've never actually achieved 100 from any server so idk
[00:51:27 CET] <thebombzen> that's odd. so apparently I can't get more than like 88 no matter how I try
[00:51:30 CET] <thebombzen> and we're paying for 100
[00:51:32 CET] <thebombzen> :P
[00:53:25 CET] <furq> is that cable
[00:54:27 CET] <thebombzen> it's not cable tv
[00:54:36 CET] <thebombzen> it's cable internet yea
[00:54:51 CET] <furq> fun
[00:54:56 CET] <furq> i routinely get 19MB/s down
[01:48:19 CET] <TehEpikDuckeh> alexpigment: Just had time to test out FFmpeg and it still presents the same issue.
[01:52:30 CET] <ZeroWalker> a bit lost:( http://sprunge.us/JDPS
[02:00:20 CET] <rafasc> can ffmpeg output something like this: http://i.imgur.com/idCuKrY.gifv?
[02:00:37 CET] <rafasc> from a list of frames?
[02:01:34 CET] <iive> i think this is done by motion stabilization software
[02:01:48 CET] <iive> i'm not sure if the one used by ffmpeg could do it...
[02:02:24 CET] <rafasc> The motion stabilization I have figured it out.
[02:02:47 CET] <rafasc> I have each frame as an image.
[02:03:13 CET] <ZeroWalker> well, that's what a frame is;o
[02:03:35 CET] <rafasc> i need something like ffmpeg -i frames%3d.tif video.mp4
[02:04:03 CET] <rafasc> but this only shows one frame at a time. I want the frames to persist.
[02:06:13 CET] <furq> !filter vidstabtransform
[02:06:13 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#vidstabtransform-1
[02:06:15 CET] <furq> maybe that
[02:09:50 CET] <ZeroWalker> none that could help me mux and write my encoded frames;d?
[15:33:52 CET] <peetah> hi, I came here some days ago about a suspicion of FFmpeg licence violation: I did my homework, and now I'm sure about my claims
[15:35:51 CET] <peetah> The company visioforge.com is repackaging FFmpeg binaries compiled from GPLed code (not LGPL since they include libpostproc and the binaries contains the --enable-gpl string) without any licence information whatsoever
[15:36:55 CET] <peetah> their last changelog claim for "Fixed FFMPEG source memory leak" (https://www.visioforge.com/video-capture-sdk.html)
[15:40:21 CET] <peetah> I checked the bug tracker for previous report of such violation, and it seems you don't take any action, which I can understand given the time and efforts it could require. So I let this information here to be useful for anyone it may concern
[15:46:36 CET] <peetah> to their credit, they seem to have "misunderstood" the FFmpeg licence (https://www.visioforge.com/support/717091-Decoding-in-Video-Edit-SDK-with-FFMPEG)
[16:15:23 CET] <zevarito> hi all, I am looking forward to live convert HLS into RTSP with FFmpeg, is this possible ?
[16:44:21 CET] <DHE> zevarito: it's possible, but ffmpeg isn't an RTSP server itself. you need to provide one and ffmpeg can feed it
[16:55:57 CET] <zevarito> DHE: cool thanks!
[17:28:58 CET] <paperManu> hi there, I have trouble using the h264_nvenc encoder with the libavcodec API. The x264 encoder works well, but the avcodec_send_frame keeps complaining with a AVERROR(EINVAL), which makes not much sense to me.
[17:29:11 CET] <paperManu> has anyone experience with the h264_nvenc encoder?
[17:37:08 CET] <alexpigment> paperManu: i've used h264_nvenc before
[17:37:20 CET] <alexpigment> although i'm not familiar with the error you're getting
[17:37:45 CET] <paperManu> by any chance, do you have code using it available somewhere?
[17:37:47 CET] <alexpigment> out of curiosity, what nvidia card do you have, and have you updated to the newest drivers?
[17:38:19 CET] <paperManu> I tested it only with 670, on Ubuntu 16.04, with the 375.39 drivers
[17:38:38 CET] <alexpigment> no - my experience is under Windows 7 64-bit using an Zeranoe compiled build. i used nvidia 650, 750, 970, and 1060
[17:38:50 CET] <alexpigment> unfortunately, i haven't done any testing on linux
[17:39:18 CET] <paperManu> ok
[17:39:30 CET] <paperManu> do you remember if there was any specific context parameter to set?
[17:41:01 CET] <alexpigment> i don't believe so. here's a sample test command i just did:
[17:41:38 CET] <alexpigment> ffmpeg -i [input file] -c:v h264_nvenc -global_quality 20 -c:a aac outfile.mp4
[17:41:48 CET] <alexpigment> everything worked fine
[17:42:48 CET] <alexpigment> sorry, i guess i can't really help with your specific error
[17:43:32 CET] <paperManu> thanks anyway, I'll continue trying to figure this out =)
[17:43:38 CET] <alexpigment> k
[17:43:59 CET] <alexpigment> it may be worth trying a simple video file - perhaps another sample - to rule out an issue with decoding
[17:44:15 CET] <alexpigment> then again, you said x264 worked fine, so that probably isn't the case
[17:45:25 CET] <paperManu> yes, and the error is not really informative
[17:45:34 CET] <paperManu> the command line works fine for me too
[18:19:00 CET] <ZeroWalker> the time has come for ppl to help me
[18:19:43 CET] <ZeroWalker> i can't do write header not write interleaved: http://sprunge.us/GbPi
[18:57:16 CET] <ctmeece> I have an mp4 file, avc/aac encoded, 960x540.  When I play this video with jwplayer, OI get the expected output, a 16x9 video file that plays fine.  I am trying to segment this video for hls so I can stream it on the web with jwplayer.  The segmenting is succesful and the resultant playlist runs in jwplayer, but the video is squished with black bars on top and bottom.  I have added the command I ran to pastebin:
[18:57:37 CET] <ctmeece> http://pastebin.com/eGW61xHW
[18:58:18 CET] <ctmeece> the resultant segmented video appears to have a resolution of 960x260
[18:58:41 CET] <ctmeece> if I look at any individual .ts, though, it appears to have the correct resolution:
[18:59:20 CET] <ctmeece> http://pastebin.com/7A5aP7pq
[19:02:18 CET] <ctmeece> I probably have more options to ffmpeg than I need, but I keep adding some to try to troubleshoot this.  I have tried many combinations of options but they all seem to produce this squashed video.
[19:04:11 CET] <ctmeece> I have the same source video file split with a program called One Click M3U8 that produces the output I want, and here is the mediainfo on one of the .ts files it produced:
[19:04:56 CET] <ctmeece> http://pastebin.com/VqD0jTAJ
[19:05:17 CET] <ctmeece> and finally, here is the mediainfo data on my source file:
[19:05:48 CET] <ctmeece> http://pastebin.com/ny37FRRW
[19:36:41 CET] <ctmeece> i transfered 2 of the .ts files, one that works (generated from One Click M3U8) and one from my ffmpeg command back to my local mac, and tried playing them both in VLC
[19:37:17 CET] <ctmeece> they both play fine, both have the 960x540 resolution, and both appear o have the same media informaiton in the VLC inspector
[19:37:28 CET] <JEEB> uhh
[19:37:32 CET] <ctmeece> so, maybe it has somethign to do with the playlist file?
[19:37:42 CET] <JEEB> what about you not using the segment muxer
[19:37:54 CET] <JEEB> and instead just be a nice guy and set the output file name to something.m3u8
[19:38:15 CET] <JEEB> although I guess the segment muxer can also do hls due to the segment_list_type parameter
[19:38:46 CET] <JEEB> also...
[19:38:48 CET] <ctmeece> i havent tried just renaming the mp4 but I will try that.
[19:38:55 CET] <JEEB> http://pastebin.com/eGW61xHW
[19:39:10 CET] <JEEB> under output you have major brand and other random isobmff specific shit
[19:39:50 CET] <JEEB> and then it says "copy" at the end?!
[19:39:50 CET] <DHE> there's a dedicated `hls` format as well for your consideration.
[19:40:13 CET] <JEEB> yeah, that's what I meant with "just set your output file name to 'something.m3u8'"
[19:40:24 CET] <JEEB> since that should pick the hls muxer by default
[19:40:33 CET] <ctmeece> will that cause jwplayer to do a progressive download of the whole file?
[19:40:43 CET] <JEEB> what the flying fuck
[19:40:48 CET] <JEEB> are you trolling or just that much out there
[19:40:48 CET] <DHE> ow
[19:40:49 CET] <ctmeece> oj, you mean during the conversion
[19:41:09 CET] <JEEB> also you're using avconv
[19:41:15 CET] <JEEB> an ancient version at that
[19:41:30 CET] <ctmeece> right, its the most recent version in the ubuntu standard repos
[19:41:30 CET] <DHE> speaking of which, "-codec copy -vf 960:-1 -bsf h264_mp4toannexb" is contradictory
[19:41:34 CET] <JEEB> I don't care if you utilize FFmpeg or Libav, but it's ancient
[19:42:02 CET] <JEEB> ctmeece: it's the "the last release available as of winter 2013-2014"
[19:42:09 CET] <ctmeece> i did initially just try a simple name the output file with m3u8 but as that didnt work, I have been adding more and more options
[19:42:21 CET] <JEEB> sounds like you just want to stop at that point
[19:42:27 CET] <JEEB> go grab a static build of FFmpeg
[19:42:34 CET] <JEEB> one of the guys here builds them if I recall correctly
[19:42:35 CET] <DHE> but seriously, upgrade to something made in the last 12 months
[19:42:53 CET] <JEEB> and then just do `ffmpeg -i input -c copy out.m3u8`
[19:43:01 CET] <JEEB> that should "just do what you need"
[19:43:07 CET] <JEEB> if not, then add the bsf
[19:43:22 CET] <JEEB> but you shouldn't need anything else for segmenting
[19:43:32 CET] <ctmeece> i think at the minimu, with my ancient version, it required bsf and map at minimum
[19:43:51 CET] <JEEB> yeah, but a lot of the BSF stuff is now automagic
[19:43:57 CET] <JEEB> that's a recent improvement
[19:44:02 CET] <JEEB> at least for AVC and HEVC
[19:44:34 CET] <JEEB> (someone link this poor bastard the static lunix builds)
[19:45:16 CET] <JEEB> with those you can just call the ffmpeg with its path unless you add it to your PATH if you know what that is
[19:45:20 CET] <DHE> https://johnvansickle.com/ffmpeg/ Is this the one you wanted?
[19:45:25 CET] <JEEB> probably that one
[19:45:40 CET] <JEEB> you extract that and then /path/to/ffmpeg OPTIONS
[19:45:46 CET] <JEEB> that will use the static build
[19:45:56 CET] <DHE> or uninstall your existing ffmpeg and install this one in its place
[19:46:00 CET] <DHE> (uninstall very important here)
[19:47:28 CET] <JEEB> "install", if it's not a deb package don't use that word because the lusers won't know how to do it :P
[19:47:55 CET] <JEEB> better to just tell them to extract and then use the full path so they don't have to know about PATH either
[19:48:03 CET] Action: JEEB shrugs
[19:48:22 CET] <JEEB> (note: you should decide this by the seeming knowledge level of the user)
[19:48:32 CET] <JEEB> in this case, though, KISS seems to be a good thing :P
[19:48:47 CET] <ctmeece> jesus, this is why I never come to IRC&
[19:49:19 CET] <JEEB> well, try out that static binary
[19:49:45 CET] <JEEB> and don't worry, by your pastebin that just didn't make any sense I just grasped that you might not have too much knowledge about *nix in general. which might have been incorrect.
[19:50:54 CET] <JEEB> (I will still note that "install" is still a misnomer when we're not talking of a distro package)
[19:51:14 CET] <JEEB> ctmeece: did it work better with the simple command line?
[19:51:24 CET] <ctmeece> no
[19:51:32 CET] <JEEB> post command line and terminal output, please
[19:51:38 CET] <JEEB> on a pastebin
[19:51:40 CET] <ctmeece> oh, you mean with the new binaries?
[19:51:45 CET] <JEEB> yes
[19:55:15 CET] <ctmeece> that will have to wait a bit.  You see, there are reasons that lots of admins like to stick with the standard distro versions of packages that have nothing to do with being noobs, but have to do with corporate governance, change control, ongoing maintenance, integration with local package management etc etc.  My life would be much easier without having to install static binaries.  But Ive thrown every option at it at this point, so now I have to spin up 
[19:55:16 CET] <ctmeece> new dev box to test this.  Ill let you know how it goes.
[19:55:53 CET] <DHE> oh believe me we know. but ffmpeg is one of those projects where running the most up-to-date version of software really makes a huge difference
[19:56:26 CET] <ctmeece> ugh, yes, i recall it being a headache for some other reason about 5 years ago.  I was hoping repo maintainers had caught up
[19:56:40 CET] <JEEB> even if they had, your distro is still three years old
[19:56:46 CET] <ctmeece> or features/bugs had stabilized
[19:57:02 CET] <JEEB> nah, OSS multimedia is pretty much alway in motion. usually towards better :)
[19:57:15 CET] <DHE> repo maintainers have different priorities. for long term support there's an expectation that interfaces, parameters and any already-written user scripts won't break as a result of an upgrade.
[19:58:02 CET] <JEEB> ctmeece: if it's better for you to build yourself just install build-essential, git and yasm. you get all the basic features with a simple `./configure && make -jX`
[19:58:06 CET] <JEEB> if you don't like static binaries
[19:58:26 CET] <JEEB> since you only need re-packaging and not encoding with, say, libx264
[19:59:00 CET] <DHE> JEEB: considering he's trying to rescale the video and output to HLS, I suspect he does in fact need libx264
[19:59:12 CET] <JEEB> I think that was him just adding all sorts of parameters
[19:59:26 CET] <JEEB> since he got the wrong size after remuxing
[19:59:29 CET] <ctmeece> yeah, i dont want to be building packages
[19:59:32 CET] <JEEB> for some weird reason
[20:00:08 CET] <ctmeece> well, ftr, i think avtool got the wrong size
[20:00:30 CET] <JEEB> ctmeece: nah - not packaging in that sense. taking streams from one container and putting them into another. generally called "remuxing"
[20:00:46 CET] <ctmeece> i was referring to building from source
[20:00:49 CET] <JEEB> right
[20:00:57 CET] <JEEB> I wouldn't make a package in that case anyways
[20:01:02 CET] <JEEB> more issues
[20:01:05 CET] <JEEB> just keep it in your home dir
[20:01:15 CET] <JEEB> and call it specifically when you need it
[20:01:23 CET] <ctmeece> its not that simple
[20:01:33 CET] <ctmeece> this is not a hobby project
[20:01:41 CET] <JEEB> ok
[20:01:53 CET] <ctmeece> i have to administer many boxes across many environments across many locations
[20:02:07 CET] <ctmeece> so anything i build I eventually have to support
[20:02:11 CET] <DHE> neither is what I do. and I'll be honest, I still run from the Git version of ffmpeg and build my own versions. (My name is even in a small number of git commits, these are related events)
[20:03:18 CET] <JEEB> yeah, at work I build as well.
[20:03:21 CET] <ctmeece> im just saying that put the bins in your home dir only solve a small part of the problem.
[20:03:24 CET] <JEEB> we have specific hashes
[20:03:31 CET] <JEEB> that are tested
[20:03:47 CET] <DHE> make your own packages, host an internal repo and distribute it from there?
[20:04:02 CET] <JEEB> also I recommend you don't try to package it in the same way as the system libav
[20:04:05 CET] <ctmeece> i do do that for some ssl packages, but ita major pain, tbh
[20:04:22 CET] <DHE> well, I'm sorry but you're currently stuck between a rock and a hard place
[20:04:41 CET] <JEEB> make it a self-contained package containing just ffmpeg and maybe ffprobe if you want that
[20:04:45 CET] <ctmeece> not really.  I will get static binaries and distribute those.
[20:05:06 CET] <CalimeroTeknik> how can I specify jpeg as the output (to a pipe)?
[20:05:13 CET] <JEEB> -f mjpeg ?
[20:05:22 CET] <JEEB> or just jpeg
[20:05:24 CET] <ctmeece> im just saying that the hassle of that is unfortunate, but that is neither here nor there.
[20:05:36 CET] <CalimeroTeknik> Requested output format 'jpeg' is not a suitable output format
[20:05:43 CET] <JEEB> ctmeece: yes it's unfortunate that you can't use what comes from the repos
[20:06:02 CET] <CalimeroTeknik> the input is a webp image
[20:06:02 CET] <relaxed> CalimeroTeknik: mjpeg
[20:06:20 CET] <CalimeroTeknik> Output #0, mjpeg, to 'pipe:': Output file #0 does not contain any stream
[20:07:12 CET] <CalimeroTeknik> here goes http://sprunge.us/gUJh
[20:07:29 CET] <JEEB> ctmeece: btw one quick way of checking which version of FFmpeg you want is to check if the current HEAD is green on FATE for the architectures/operating systems you require
[20:07:42 CET] <CalimeroTeknik> oh, the output. http://sprunge.us/NLJF
[20:07:51 CET] <JEEB> not a perfect test, but at least every time you think of updating FFmpeg it's a good way to see if something is completely bonkers
[20:07:52 CET] <ctmeece> ok, thanks
[20:07:58 CET] <ctmeece> right
[20:07:58 CET] <JEEB> FATE being http://fatebeta.ffmpeg.org/
[20:08:22 CET] <JEEB> regression tests being run on various architectures and operating systems
[20:13:16 CET] <CalimeroTeknik> well, it works fine as long as I don't want to use pipes as the input of ffmpeg I suppose
[20:28:34 CET] <llogan> you could just use ffmpeg -i https://...
[21:10:57 CET] <oal> I'm looking for a way to cut a video file in Linux without rerendering the whole thing. I found the -ss and -t flags to set start and duration, but can I specify multiple start/stops? Say I want to have a result file with 10s-20s and 40s-60s but not what's before the 10s mark and between 20 and 40?
[21:12:44 CET] <thebombzen> pal: if you don't want to transcode, you'll have to cut on keyframes. that being said, check out the segment muxer
[21:14:09 CET] <llogan> if you need to re-encode, you can use the trim and concat filters. if you can cut on keyframes, adn therefore possibly avoid re-encoding, you can use the concat demuxer using the inpoint and outpoint options.
[21:14:51 CET] <thebombzen> if you're okay with transcoding, then you can do something like this: -filter_complex '[0:v]split[a][b];[a]trim=start=10:end-20,setpts=PTS-STARTPTS[c];[b]trim=start=40:end=60,setpts=PTS-STARTPTS[d];[c][d]concat=n=2:v=1:a=0[v]' -map '[v]'
[21:15:22 CET] <thebombzen> essentially, you split it, trim both clips, and concatenate them
[21:21:17 CET] <jcay> what does re-encode mean and with which options does it start?
[21:22:04 CET] <oal> Thanks, I'll experiment a bit. I just don't want to wait 20 minutes for Pitivi to render my 2 minute clip. :)
[21:22:42 CET] <thebombzen> jcay: well the video stream is already compressed using lossy encoding. if you were to decode it and then encode it again using lossy encoding, that's re-encoding
[21:22:57 CET] <thebombzen> also known as "transcoding"
[21:23:52 CET] <jcay> thebombzen: I see, how can I avoid it?
[21:24:30 CET] <thebombzen> -c copy
[21:25:07 CET] <jcay> I see, thanks
[21:29:30 CET] <thebombzen> pal: I generally find that to do what you're doing is easier with separate commandlines
[21:30:00 CET] <thebombzen> like: ffmpeg -ss 10 -i input -t 10 -c:v ffv1 -c:a flac start.nut
[21:30:14 CET] <thebombzen> ffmpeg -ss 40 -i input -t 20 -c:v ffv1 -c:a flac end.nut
[21:30:43 CET] <thebombzen> ffmpeg -i start.nut -i end.nut -lavfi concat=n=2:v=1:a=1 <output options> output
[21:33:50 CET] <ChocolateArmpits> Is there  any format that can wrap both uncompressed video and audio stream and send it over udp ? I fear sending rawvideo and s16le two ways may end up in losing synchronization
[21:37:28 CET] <kepstin> ChocolateArmpits: rtp? note that setup is a bit tricky, you might need to pass around sdp so both ends know all the codec config.
[21:37:45 CET] <kepstin> ChocolateArmpits: also mpeg-ts
[21:37:54 CET] <ChocolateArmpits> kepstin, mpegts can't wrap uncompressed
[21:37:56 CET] <kepstin> but codec choice is a bit more limited there
[21:38:02 CET] <ChocolateArmpits> I mean it does wrap it but I can't read it afterwards
[21:38:27 CET] <ChocolateArmpits> so it's more likely the wrapping is botched because of unsupported encoding
[21:39:10 CET] <ChocolateArmpits> also I think rtp only allows sending 1 stream
[21:39:49 CET] <kepstin> hmm, i guess ffmpeg doesn't support rtp-mux, which allows multiple on same port? But rtp does support syncing multiple streams on different ports.
[21:40:30 CET] <kepstin> no idea if you can do that with the 'ffmpeg' command line tool, which is of course not intended for use with realtime streaming applications :)
[21:41:26 CET] <kepstin> (the fact that it mostly works most of the time is testament to how fast modern computers are)
[21:43:19 CET] <llogan> i always reserved the word "transcode" to refer to re-encoding while re-using info from the input such as motion vectors, etc. whle re-encode is decode input into rawvideo, then encoding that with no additional info from the input. but in reality nobody differentiates between the two words.
[21:47:32 CET] <feliwir> hey, i am trying to compile ffmpeg with new MSVC 2017
[21:48:31 CET] <feliwir> but i am failing during configure stage (C compiler test failed)
[21:48:43 CET] <feliwir> cl.exe is in path
[21:50:12 CET] <JEEB> see config.log
[21:50:15 CET] <JEEB> and pastebin it
[21:50:27 CET] <JEEB> I think nevcairiel is already running VS2017 FATE
[21:50:31 CET] <JEEB> so I would say it should work already
[21:51:55 CET] <JEEB> hmm,  not yet registered on the global FATE system it seems
[21:56:41 CET] <feliwir> JEEB, https://gist.github.com/feliwir/b649d6f8e0067aa23ab562c45a940655
[21:57:11 CET] <feliwir> fails to open LIBCMT
[21:57:52 CET] <ZeroWalker> FATE?
[22:03:52 CET] <JEEB> ZeroWalker: http://fatebeta.ffmpeg.org/
[22:03:57 CET] <JEEB> automated regression test suite
[22:04:10 CET] <JEEB> feliwir: double-checked with nev
[22:04:11 CET] <JEEB> 22:52 <+JEEB> nevcairiel: did VS2017 work for FFmpeg?
[22:04:11 CET] <JEEB> 22:58 <@nevcairiel> yes
[22:04:26 CET] <feliwir> so what did i do wrong?
[22:04:33 CET] <feliwir> i followed the ffmpeg guide
[22:04:48 CET] <feliwir> but the paths did change for msvc 2017
[22:05:17 CET] <JEEB> I have NFI :) will be installing MSVC 2017 this week myself
[22:06:17 CET] <feliwir> okay :)
[22:06:54 CET] <feliwir> i am currently writing a vp6 decoder in C# it's a pain :D Does someone here maybe still have the original libvp62 sourcecode?
[22:07:04 CET] <ZeroWalker> ah
[22:07:09 CET] <JEEB> just use libavcodec's :)
[22:07:12 CET] <feliwir> that was on Sourceforge during 2006
[22:07:22 CET] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/207721.html
[22:07:26 CET] <JEEB> try applying this?
[22:07:31 CET] <JEEB> not sure if relevant
[22:08:03 CET] <feliwir> well, problem with libav is that it uses many functions split across many files
[22:08:37 CET] <feliwir> JEEB, hm it doesn't seem relevant for a linking error during configure stage
[22:08:55 CET] <JEEB> ye
[22:10:26 CET] <feliwir> Another question: Is Aurelien Jacobs still active on ffmpeg?
[22:11:25 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=author&s=Aurelien
[22:11:30 CET] <JEEB> last commit in 2013
[22:11:38 CET] <Kirito> Is there a way to have ffmpeg work with filenames that don't have padded zero's? i.e. frame-1.tiff - frame-999.tiff
[22:11:48 CET] <Kirito> instead of frame-001.tiff - frame-999.tiff
[22:12:58 CET] <RossW> the way I do it is to pipe the files to ffmpeg (because I'm often wanting to use only a subset of the images, or skip every nth, etc)
[22:15:01 CET] <Kirito> Nevermind, I bloody love Directory Opus
[22:15:22 CET] <Kirito> https://a.uguu.se/5XIkx1I5VrQ4_dopus_2017-03-07_16-15-22.png
[22:16:59 CET] <Kirito> Renamed all the files in %04d format while preserving the natural sorting order, hah
[22:17:28 CET] <faLUCE> (I know that this could be off-topic, but I don't know where to ask) hello.  Is there a way to demux a MPEGTS http stream with wireshark? I can do that with a mpegts file, but for a living http stream all the packets are generically marked as "TCP"
[22:17:44 CET] <feliwir> by any chance someone in here is an expert for vpX codecs? :D
[22:18:55 CET] <feliwir> and also i am confused a bit. My video container (electronic arts) does specify the video size, but the vp6 codec does specify a size again. They are equal, but which one would be the relevant one?
[22:21:13 CET] <kepstin> feliwir: I'd expect them both to be the same normally. In some cases, containers may specify a display resolution in order to request that players change the display aspect ratio by scaling.
[22:21:53 CET] <feliwir> kepstin, the vp6 codec does specify a display resolution aswell :D (presentation dimensions)
[22:22:25 CET] <kepstin> feliwir: great! I guess you'll just have to call up EA and ask them which one to use :)
[22:22:55 CET] <feliwir> kepstin, hehe if EA see's what i am doing i'll probably get sued :D
[22:23:04 CET] <kepstin> (I assume these are game videos, so it probably depends on the game code which value is used)
[22:23:47 CET] <feliwir> kepstin, the BFME series was the main one that used the VP6 Codec i think. And thats what i am doing it for
[22:29:57 CET] <faLUCE> I just want to compute the network delay for received mpegts packets. Is there a tool that helps me in doing that?
[22:42:38 CET] <BtbN> ping
[22:45:12 CET] <kepstin> faLUCE: the only thing I can really think of is synchronizing the computer clocks really closely, then logging the times that you see particular packets on both ends.
[22:45:19 CET] <kepstin> since it's not a 2-way thing
[22:45:56 CET] <kepstin> unless you're using tcp i guess, the tcp stack might have an rtt estimate you could pull out
[22:47:20 CET] <faLUCE> kepstin: I can sync the computer clocks, but then... how can I log the times for particular packets? I did not implement a demuxer, so I can't filter anything
[22:47:38 CET] <kepstin> faLUCE: you'd have to have a custom app to do that
[22:47:45 CET] <kepstin> be tricky :)
[22:47:57 CET] <faLUCE> kepstin: in fact I wonder which app could I use
[22:48:04 CET] <faLUCE> I don't want to implement it
[22:48:47 CET] <kepstin> well, if you're using udp, I'd just take BtbN's suggestion and use ping. It should be pretty close. (returns rtt of course, not 1-way delay)
[22:49:32 CET] <faLUCE> kepstin: but ping will give me a generic network delay
[22:50:00 CET] <kepstin> yes, which should be equivalent to the delay any particular udp packet has
[22:50:10 CET] <faLUCE> I'm using TCP
[22:50:34 CET] <kepstin> ok, then on linux? look at the TCP rtt estimate with the `ss -i` command
[22:50:45 CET] <faLUCE> but the stream is over HTTP
[22:51:00 CET] <kepstin> you're asking about network delay...
[22:51:27 CET] <kepstin> any delay other than what's on the tcp connection is application delay on either end (in software), not network delay
[22:51:28 CET] <faLUCE> kepstin: you are right. The question changes with: HTTP delay...
[22:52:10 CET] <kepstin> so for that you'd want to look at kernel buffers on both end, and userspace application buffers.
[22:54:14 CET] <faLUCE> kepstin: the problem is that I can control the mpegts http stream parameters (= all the delays) on the streaming side. But when I receive the stream with a player, all the delays go in a black box and I don't have any control over them
[22:54:43 CET] <pclbr> Someone working with ISDB-T ? I? trying to trancoderthe AAC Audio into AC3, but when I do it in a output (MPEGTS  UDP mux) start to show artfacts and syncronization are wrong ( Timestamps are not set correctly)  I thinks it is a demuxer problem in AAC. but even when I just copy the mux happens in the same way, output get wrong Timestamps.
[22:54:46 CET] <faLUCE> I coded the streamer, so I can control that parameters. But I did not code the receiver
[22:54:52 CET] <kepstin> faLUCE: most players when streaming off a network connection use fairly large buffers in the player, to smooth over network glitches
[22:55:18 CET] <kepstin> faLUCE: nothing you can do about that without tweaking the player side, really.
[22:56:02 CET] <faLUCE> kepstin: in fact I wonder if it exists a http demuxer which shows when it receives a ts packet and dump its timestamp
[22:56:22 CET] <faLUCE> kepstin: I found some mpegts demuxer, but they don't work over http
[22:56:56 CET] <faLUCE> kepstin: I can pipe the output of a http receiver to these demuxers, but it's not a good solution
[22:57:51 CET] <kepstin> if you're dealing with players that you don't control over a network connection, you're going to have buffers you don't control. I'm not sure what you're really trying to accomplish.
[22:59:14 CET] <faLUCE> <kepstin> if you're dealing with players that you don't control over a network connection, you're going to have buffers you don't control. <---- there should be a good http mpegts player... or at least a good http mpegts demuxer
[23:00:13 CET] <kepstin> I'm sure that with some configuration, you could probably get ffmpeg's mpegts demuxer hooked up to an http stream with pretty low latency, fwiw.
[23:00:38 CET] <kepstin> but players purposely add buffering to smooth out variations in network speed. it's a feature.
[23:01:45 CET] <faLUCE> kepstin: I use ffplay  -probesize 500000 http://mystrem. I can have a minimum delay of 0.4 seconds on localhost. This is not enough, because the delay is big and I can't control any param
[23:02:41 CET] <faLUCE> but before writing my own demuxer or player, I wonder if is there something better for http mpegts
[23:03:49 CET] <faLUCE> kepstin: in addition, I don't understand why these players add buffering out of control, instead of providing the user the choice of dropping frames
[23:04:37 CET] <kepstin> dropping frames wouldn't help unless the computer's to slow to decode the video realtime - the buffers are there to compensate for the network not providing frames fast enough
[23:05:07 CET] <kepstin> have you tried forcing the input demuxer on ffplay, so it doesn't have to probe? the probing might be adding a fair bit of delay.
[23:05:09 CET] <faLUCE> kepstin: I see, but these buffers are completely out of control
[23:05:47 CET] <faLUCE> how could I force it so it doesn't have to probe?
[23:06:04 CET] <kepstin> use the '-f mpegts' input option
[23:06:15 CET] <kepstin> hmm, actually, it still needs to probe that, to find the codecs in use
[23:07:18 CET] <kepstin> might still help a bit tho, but probably not that much
[23:07:37 CET] <kepstin> to be honest, 0.4s for an http stream is already exceptionally good.
[23:07:44 CET] <faLUCE> kepstin: tried, it doesn't help
[23:08:20 CET] <faLUCE> kepstin: I know it's good, but skype has a lower delay
[23:08:34 CET] <kepstin> skype doesn't use mpegts over http, obviously :)
[23:08:52 CET] <kepstin> I assume they use some sort of encrypted rtp, optionally tunneled through tcp only if they can't use udp
[23:09:35 CET] <faLUCE> kepstin: I know that I should use rtp, but there's no reason for which http-mpegts can't have a lower delay than 0.4
[23:10:16 CET] <kepstin> faLUCE: if you write custom applications and use it on a high performance network under your control, it's probably possible.
[23:10:28 CET] <kepstin> with normal players and over the internet? hah.
[23:10:52 CET] <faLUCE> kepstin: I know that too. In fact I could write my application with libcurl and a demuxer (with libav)
[23:11:09 CET] <faLUCE> but it appears strange to me that common players don't do that
[23:12:17 CET] <kepstin> common players assume that http streams are probably over internet, and are vod, not realtime, so they apply buffering appropriate to that use case. they're doing the right thing by default for most users.
[23:12:55 CET] <faLUCE> kepstin: but http with mpegts is even more easy to manage than rtp
[23:13:13 CET] <faLUCE> so, I wonder why there are not real time http-mpegts players
[23:13:45 CET] <kepstin> faLUCE: because nobody uses mpegts in http for live streaming, because web browsers can't play it at all.
[23:13:58 CET] <BtbN> Technically, Twitch does
[23:14:22 CET] <faLUCE> kepstin: http-mpegts is much easier to be implemented than rtp
[23:14:44 CET] <kepstin> huh, I haven't actually looked at twitch's html5 player. I assume they're rebuilding it into a dash stream to feed into the browser?
[23:14:59 CET] <BtbN> They basically implemented their own hls.js
[23:15:10 CET] <faLUCE> kepstin: I'm avoiding hls
[23:15:12 CET] <kepstin> (and the delay on that would still be in the low seconds, I bet)
[23:15:34 CET] <BtbN> HLS has tons of delay anyway, because 3 segments being required
[23:15:42 CET] <kepstin> is twitch using segmented files, or a single live stream?
[23:15:49 CET] <kepstin> we're talking about a single stream here.
[23:15:52 CET] <feliwir> can someone tell me where those values come from: https://github.com/FFmpeg/FFmpeg/blob/415f907ce8dcca87c9e7cfdc954b92df399d3d80/libavcodec/vp56data.c#L83 ?
[23:15:53 CET] <faLUCE> I implemented my http-mpegts streamer with v4l2+alsa+libav... but I don't have time to implement the receiver
[23:16:11 CET] <feliwir> those tables aren't mentioned anywhere in the vp6 specification: https://multimedia.cx/mirror/vp6_format.pdf
[23:16:21 CET] <BtbN> Twitch is using HLS
[23:16:40 CET] <kepstin> right, that's kind of boring then. :/
[23:18:08 CET] <kepstin> can't do low delay with HLS, and nothing supports doing low delay mpegts stream in HTTP (chunked encoding, i guess?)
[23:22:44 CET] <faLUCE> kepstin: you think that mpegts-http has necessarily some delay because of the container and the protocol. But it's not true
[23:23:52 CET] <faLUCE> I think that there's a "fashion" followed by all the players: they think that rtp is the only good protocol for real-time streaming
[23:24:15 CET] <faLUCE> but this is nonsense
[23:24:30 CET] <kepstin> faLUCE: there's no inherent delay in http+mpegts, no - i didn't say that
[23:25:00 CET] <faLUCE> kepstin: but you said [23:08] <kepstin> skype doesn't use mpegts over http, obviously :)
[23:25:05 CET] <kepstin> I'm just saying that players in general assume that stuff over http isn't realtime, but  is rather vod, so they buffer appropriately.
[23:25:26 CET] <kepstin> well, it certainly wouldn't be anyone's first choice
[23:25:27 CET] <faLUCE> kepstin: but this assumption is false, IMHO
[23:25:47 CET] <kepstin> udp is better in general for live media, and if you're using udp anyways, you'd probably go for rtp
[23:26:03 CET] <faLUCE> I don't agree... I used udp and rtp for years
[23:26:19 CET] <kepstin> faLUCE: the assumption that content over http is vod (or segmented) is far more often true than false.
[23:26:59 CET] <kepstin> and in use cases that have seen media streamed over http or similar (think shoutcast), low latency hasn't generally mattered.
[23:28:00 CET] <faLUCE> kepstin: that was true some years ago, with low bandwidth
[23:28:15 CET] <faLUCE> today, the http overhead is meaningless
[23:28:32 CET] <kepstin> (I mostly deal with flash stuff at work, which means rtmp - another tcp protocol. We have to have *server side* frame dropping in connections to compensate for people with slow/overloaded downlings)
[23:28:36 CET] <faLUCE> but people are still convinced that rtp is better in a dogmatic way
[23:29:40 CET] <kepstin> i'd really rather use udp so frames just get thrown away in the network, instead of backing up tcp connections :/
[23:29:59 CET] <faLUCE> udp is bad with firewalls
[23:30:03 CET] <kepstin> although then you have to have your own bitrate adaptation code, so still a pain...
[23:31:58 CET] <kepstin> for a while, we didn't have the server side frame dropping, and instead buffered frames forever... until we started getting OOM issues when sending video to slow consumers ;) best not to do that...
[23:35:47 CET] <faLUCE> kepstin: anyway, changing the probesize now I have a delay of 0.3s
[23:35:51 CET] <faLUCE> :-)
[23:36:20 CET] <kepstin> so that's a delay of around ~10 frames.
[23:36:34 CET] <kepstin> not bad.
[23:36:42 CET] <faLUCE> kepstin: the x264 delay is about 0.2s
[23:37:08 CET] <faLUCE> I used av_write_frame instead of av_interleaved_write_frame
[23:39:03 CET] <faLUCE> adding -sync ext improves
[23:39:09 CET] <kepstin> what's the final bitrate of the mpegts look like?
[23:39:25 CET] <kepstin> i'm wondering if you might hit issues with the tcp slow start behaviour :/
[23:39:33 CET] <kepstin> although I guess that might not show up on localhost
[23:41:12 CET] <kepstin> but if you're trying to send e.g. 10mbit or higher, the tcp connection over an actual network interface won't be able to send the full rate immediately due to congestion control
[23:41:34 CET] <kepstin> without tuning of course (which you don't want to do if you're in a public network)
[23:41:37 CET] <faLUCE> kepstin: I'm streaming at 10000kb/s
[23:42:33 CET] <kepstin> although it usually should get up to speed reasonably quick, but it might not be fast enough for this sort of low-latency work
[23:43:12 CET] <ChocolateArmpits> Is reducing gop length good for latency reduction ?
[23:44:02 CET] <kepstin> ChocolateArmpits: it can reduce time until a picture is shown if people are tuning into the middle of a stream, but it doesn't have a direct impact on latency.
[23:48:19 CET] <ChocolateArmpits> oh ok
[23:48:45 CET] <kepstin> (some indirect effects - having longer gop in vbr video means more variation in bitrate, which can cause issues with tcp rate control, which means you need more buffering in the player, which increases latency)
[23:50:14 CET] <kepstin> of course "time until a picture is shown" is still a type of latency, but it's different from end-to-end latency which is what we're talking about here
[23:50:42 CET] <kepstin> e.g. tv channels don't care if you're seeing the picture a few seconds delay, but they do care if you have to wait 10s before your tv shows something after switching channels
[23:51:02 CET] <alexpigment> i'm not sure how everyone else works, but i started using GOP = framerate a while back and have been very happy ever since
[23:51:30 CET] <alexpigment> seeking just always feels clunky with the default GOP length (250)
[23:51:43 CET] <kepstin> gop=framerate means 1s between keyframes, which means pretty quick recovery from lost packets, etc., but far less efficient video encoding.
[23:52:05 CET] <alexpigment> yeah, it's not as efficient, obviously. but it feels less janky to me for my own personal encodes
[23:52:11 CET] <alexpigment> anyway, sorry for the tangent ;)
[23:52:26 CET] <kepstin> short gop is great for intermediate files, particularly if you need to frame step backwards, yeah :)
[23:53:04 CET] <alexpigment> yeah, short GOP is good for intermediate, although intra is ideal
[23:54:30 CET] Action: kepstin is kind of disappointed that x264's intra refresh mode isn't used more in video streaming.
[23:55:27 CET] <alexpigment> yeah i hear you on that (although i was specifically talking about intra-frame compression only, where the GOP is effectively 1
[23:55:51 CET] <kepstin> yeah, unrelated to that discussion :) intra-refresh spreads out bits so that frames are consistent sizes rather than big keyframe + little predicted frames, and gives cool-looking recovery from packet loss.
[23:56:02 CET] <kepstin> makes seeking a pain tho :)
[23:56:17 CET] <alexpigment> yeah, i think you need to decode certain number of frames still, right?
[23:56:48 CET] <alexpigment> in other words, you still have to decode x number of frames before you get a full i-frame?
[23:56:49 CET] <kepstin> yeah, you need to decode N frames after you seek to get a whole frame, where N is the number of columns x264 is using
[23:57:10 CET] <kepstin> or you can just start watching, and see the video fill in column-by-column :)
[23:57:11 CET] <alexpigment> gotcha. that's what i remember when reading up on it a while back
[23:57:22 CET] <alexpigment> progressive jpeg comes to mind ;)
[23:58:35 CET] <kepstin> the main thing is that it fixes the issue you often see in bitrate-limited (vbv) streams where the keyframes cause noticable drops in quality, and then quality slowly improves until the next keyframe drops.
[23:59:24 CET] <alexpigment> yeah, i used a few techniques to get around that at work, although not completely starving the bitrate was also important
[23:59:25 CET] <alexpigment> ;)
[23:59:56 CET] Action: kepstin last remembers seeing that on some big cisco conferencing system, and he was suitably unimpressed.
[00:00:00 CET] --- Wed Mar  8 2017