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

[burek]

[03:07:09 CET] <kingsley> If you happen to have the time, and are so inclined, I'd be interested in your thoughts on how to fix...
[03:07:43 CET] <kingsley> # ffmpeg -i in.mp4 -filter_complex 'aphasemeter,transpose=1' out.mkv
[03:07:56 CET] <kingsley> so it doesn't fail with...
[03:08:10 CET] <kingsley> Media type mismatch between the 'Parsed_aphasemeter_0' filter output pad 0 (audio) and the 'Parsed_transpose_1' filter input pad 0 (video)
[03:08:24 CET] <kingsley> Cannot create the link aphasemeter:0 -> transpose:
[03:08:37 CET] <kingsley> Error initializing complex filters
[03:08:54 CET] <kingsley> So...
[03:08:58 CET] <kingsley> what do you think?
[03:14:22 CET] <furq> kingsley: -lavfi "aphasemeter[aout][tmp];[tmp]transpose=1[vout]" -map "[vout]" -map "[aout]"
[03:18:40 CET] <kingsley> furq: I'm happy to report I ried your suggestion, and it worked! Thank you very much.
[03:37:29 CET] <ariyasu> if i have a video that is 720x480 with anamorphic widescreen
[03:37:49 CET] <ariyasu> what can i scale it to, to end up with only 16:9 widescreen
[03:37:52 CET] <ariyasu> without upscaling
[03:39:25 CET] <kode54> ariyasu: you'll have to downscale it vertically to 405
[03:40:34 CET] <kode54> or upscale it horizontally to 853, but you don't want to upscale
[03:45:17 CET] <furq> or just leave it anamorphic if possible
[03:49:46 CET] <kode54> that too
[03:54:11 CET] <ariyasu> furq i want to put them on youtube when im done with them
[03:54:28 CET] <ariyasu> and if i upload them at 720x480 now, youtube plays them in it's 4:3 player
[03:54:33 CET] <ariyasu> even though it's 3:"
[03:54:38 CET] <ariyasu> 3:2
[03:55:06 CET] <ariyasu> thanks kode54 i will run some tests
[03:55:44 CET] <ariyasu> so like 405x228?
[03:56:21 CET] <kode54> no, 720x405
[03:56:27 CET] <furq> 404 if it's 4:2:0
[03:56:32 CET] <kode54> ah right
[03:57:03 CET] <furq> or if it's youtube then just upscale to 720p
[03:57:45 CET] <furq> definitely at least scale to 854x480 or else it'll only give you 360p on youtube
[03:58:08 CET] <ariyasu> ok :) i will test
[03:58:11 CET] <ariyasu> thanks guys
[03:58:19 CET] <furq> obviously never do this in any other scenario
[03:58:40 CET] <furq> but common sense goes out the window when youtube is involved
[12:33:35 CET] <Mavrik> friendofafriend, seems like your camera is inserting some of its own info into a stream and not registering size correctly
[12:45:58 CET] <friendofafriend> Mavrik: Is there something I should be doing to resolve the warnings?
[12:46:40 CET] <Mavrik> I don't think so - type 5 seems to be "user data"
[12:46:56 CET] <Mavrik> Meaning a provision for the encoder to add some kind of non-standard proprietary stuff to the stream
[12:47:07 CET] <friendofafriend> Ah!  Hey, thank you so much!
[12:47:14 CET] <Mavrik> It's unlikely to affect anything except be annoying.
[12:49:28 CET] <friendofafriend> I've got this RTSP stream that dies sometimes, and I'd like to display an image when it does.  I've tried overlaying the stream over a test pattern, but the encode still stops when the stream dies.  Is there a clever way to do it?
[12:55:34 CET] <Mavrik> Hrmf, I haven't see a way to do that without using some other software
[12:56:24 CET] <friendofafriend> Fiddlesticks, maybe it can be coaxed into a pipe somehow.  Thank you.
[12:57:44 CET] <Mavrik> friendofafriend, tbh if you have such use-cases, you probably need a streaming server, not just ffmpeg :)
[12:57:53 CET] <Mavrik> Those usually have the placeholder image functionality and stuff like that
[12:58:12 CET] <friendofafriend> I've got a streaming server, but it's icecast and not so hot.
[12:58:46 CET] <JEEB> basically the FFmpeg API can let you do it if you build your stuff but ffmpeg.c doesn't really have a feature where an input can go up and down
[12:59:06 CET] <JEEB> and I'm not sure if all these things should go into ffmpeg.c, I'd rather have a separate tool for live streaming uses
[12:59:40 CET] <JEEB> because in live streaming your input generally is live, so you can help decisions with what the time difference is to a previous case
[12:59:45 CET] <friendofafriend> Would ffmpeg still die if a FIFO emptied?
[12:59:47 CET] <JEEB> while with file-based stuff you can't
[13:00:08 CET] <Mavrik> What was the name of the opensource streaming server thing? Open broadcast encoder or what was it?
[13:00:20 CET] <JEEB> you're thinking of live encoders
[13:00:23 CET] <JEEB> not streaming servers
[13:00:27 CET] <furq> if you mean the desktop capture thing then obs
[13:00:28 CET] <JEEB> streaming servers generally are what serve the end user
[13:00:35 CET] <JEEB> there's OBE that's geared for broadcast
[13:00:46 CET] <JEEB> and OBS for desktop/game streaming
[13:01:16 CET] <Mavrik> Ah, yeah, OBE was the thing
[13:01:17 CET] <furq> oh so there is
[13:01:47 CET] <JEEB> I've been meaning to write a PoC for web streaming feeding with upipe (which OBE is seemingly switching to), since it seems to have already made components like input switching
[13:02:02 CET] <JEEB> so if you have one input die and come back up that code's already there
[13:02:18 CET] <JEEB> upipe is a framework which utilizes things like FFmpeg etc where they're generally good at
[13:02:38 CET] <JEEB> lacks a libavformat based output module tho since the broadcast people don't trust FFmpeg's MPEG-TS or UDP
[13:03:26 CET] <Mavrik> Last time I tried to feed things to muxers using ffmpeg's MPEG-TS it was rather terrible :/
[13:04:50 CET] <JEEB> the last time someone complained about a mux the result was surprisingly decent
[13:05:03 CET] <JEEB> the main thing was to figure out the magic values for the UDP output to make throttling work well enough
[13:05:28 CET] <JEEB> his fancy checker app was not showing clearly if it thought the mux was bad, or if it just came in too big bursts :P
[13:05:38 CET] <Mavrik> Mhm, I couldn't get the ciscos to eat ffmpeg muxer output at all
[13:05:49 CET] <Mavrik> Then again, that was DVB-C which was extra strict around PCR
[13:06:22 CET] <JEEB> yea, I wouldn't be surprised if lavf's MPEG-TS output just failed in various ways
[13:06:35 CET] <JEEB> but that one time the only issue (Surprisingly enough) was the UDP bursting
[13:07:01 CET] <JEEB> you'd wish those expensive pieces of shit would actually tell you about the difference :P
[13:07:18 CET] <JEEB> instead of having a person switch to a file input and see his app not complain
[13:07:22 CET] <JEEB> *output
[13:07:39 CET] <JEEB> then switching back to UDP and seeing it complain, which thankfully limits things at that point
[13:08:07 CET] <Mavrik> Oh yeah!
[13:08:31 CET] <JEEB> that said, if I were making something new I'd probably start off with upipe's MPEG-TS/UDP after looking at what it supports/doesn't
[13:08:48 CET] <JEEB> since it's made for broadcast/live use cases
[13:08:52 CET] <Mavrik> Having damn things actually tell you what's wrong is impossible pretty much.
[13:08:57 CET] <JEEB> yup
[13:09:07 CET] <JEEB> "this line here is not straight"
[13:09:29 CET] <JEEB> also yesterday I had to go tell someone their timestamps were wrong because their expensive DVB analyzers didn't give a fuck
[13:09:39 CET] <JEEB> DTS > PTS coming out of the woodworks :P
[13:37:10 CET] <Shezi> Hi every one. I am stocked from last one week in trying rtmps on facebook live and its not working at all. RTMP works though.
[13:37:54 CET] <Shezi> It sends few packets and then hangs indefinitely.
[13:38:07 CET] <Shezi> Any help would be appreciated. Thank you
[13:38:29 CET] <Shezi> Sorry stucked not stocked. (Auto correct typo)
[17:31:07 CET] <lantizia> hey, anyone here know of anyway to diagnose why chrome (or firefox etc) won't play my mp4 url directly (by directly i mean, just by sticking it in the location bar)
[17:32:10 CET] <JEEB> look at the developer console?
[17:32:30 CET] <JEEB> and also pastebin or so the result of `ffprobe -v verbose FILE.mp4`
[17:32:33 CET] <JEEB> and link here
[17:32:50 CET] <lantizia> well it's not a file - it's just a h254 stream
[17:32:54 CET] <lantizia> *h264
[17:33:18 CET] <JEEB> unless you use fragmented mp4 nothing can play an mp4 "stream"
[17:33:32 CET] <lantizia> i just get... https://i.snag.gy/zuyjrf.jpg
[17:33:39 CET] <JEEB> since the file will be written to, but will not have the necessary structures to initialize decoders, among other things
[17:33:52 CET] <lantizia> what I do know is I can play it with VLC
[17:34:10 CET] <JEEB> ok, so your explanation sounds a bit weird then. then it isn't a stream (ongoing thing)
[17:34:30 CET] <lantizia> well - yeah it is a stream :)
[17:34:42 CET] <JEEB> (or it is fragmented mp4, but congrats for whomever figured out to do that)
[17:34:44 CET] <lantizia> i can PM it you if you like (it's nothing offensive or anything)
[17:35:09 CET] <lantizia> just wouldnt want the link going around (bandwidth concerns)
[17:35:16 CET] <JEEB> I really don't have the time to go into it too deep, but check the results of ffprobe -v verbose or so :P
[17:35:45 CET] <Shezi> I have asked earlier in this channel related to RTMPS issue. I would like some assistance. Its streaming to Facebook Live using rtmps instead of rtmp. Does FFmpeg needs special compilation flag to make it work?
[17:36:58 CET] <JEEB> Shezi: if you have TLS and zlib it should work according to the dependencies list in the configure script
[17:37:12 CET] <JEEB> ffmpeg -formats |grep rtmps
[17:37:19 CET] <JEEB> or protocols maybe
[17:37:21 CET] <lantizia> JEEB, https://pastebin.com/raw/PbKWUn4y
[17:37:43 CET] <lantizia> and it *is* a stream :)  and it *does* play fine when giving the same URL to VLC
[17:37:45 CET] <JEEB> lantizia: it's not mp4
[17:37:48 CET] <JEEB> as I expected
[17:37:54 CET] <JEEB> Input #0, mpegts
[17:37:57 CET] <lantizia> no I've been saying it is h264
[17:38:12 CET] <lantizia> the URL ends in mp4 though :)
[17:38:16 CET] <JEEB> > won't play my mp4 url directly
[17:38:23 CET] <lantizia> right :)
[17:38:27 CET] <JEEB> anyways, it's MPEG-TS
[17:38:32 CET] <JEEB> which can be streamed, yes
[17:38:33 CET] <Shezi> JEEB, Can I paste the output in pastbin? Seems tls and zlib are not visible
[17:38:34 CET] <JEEB> it's made for that
[17:38:56 CET] <JEEB> Shezi: and yes it was -protocols not -formats
[17:39:03 CET] <JEEB> that shows which protocols you have built in
[17:39:08 CET] <Shezi> Ok let me check again
[17:39:26 CET] <JEEB> lantizia: anyways the reason is that Firefox has no support for MPEG-TS natively
[17:40:00 CET] <lantizia> JEEB, bugger, so I'd need something to take it apart and put it back together in mp4 container?
[17:40:11 CET] <JEEB> lantizia: you could in theory re-multiplex the video and audio into fragmented mp4 and see if that works
[17:40:26 CET] <JEEB> not sure if there's any pre-existing tools for that live conversion without using files
[17:40:35 CET] <Shezi> Here you go! https://pastebin.com/raw/xy79Dw3r
[17:40:47 CET] <JEEB> Shezi: so it's there
[17:40:57 CET] <Shezi> But why it gets hanged indefinitely
[17:41:15 CET] <Shezi> RTMP is ok. RTMPS hangs after sending few packets.
[17:41:28 CET] <JEEB> and there have been no changes specifically mentioning rtmps since 2017 http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=rtmps
[17:41:47 CET] <JEEB> so it sounds like what you need to do specifically somehow is between you and your service provider
[17:41:55 CET] <JEEB> which in your case is Facebook
[17:42:00 CET] <JEEB> good luck, and have fun
[17:42:26 CET] <Shezi> Ok. Thanks. But it works with OBS the same facebook live rtmps url
[17:42:47 CET] <JEEB> then it sounds like they're doing some things somewhat differently and/or using different components
[17:43:01 CET] <JEEB> how various options are passed in various RTMP implementations depends
[17:43:15 CET] <JEEB> librtmp might take them in one way, the FFmpeg internal RTMP might be taking them in another
[17:43:47 CET] <Shezi> Ok. Yeah that sounds logical. But I thought it might be same standard that these tools would be using
[17:44:14 CET] <JEEB> the protocol is the same, different components might be receiving options in different ways
[17:44:21 CET] <JEEB> and after all, OBS might just be parsing the URL
[17:44:25 CET] <JEEB> and then passing options on
[17:44:39 CET] <JEEB> so asking OBS people if they do anything special with RTMPS sounds like a good beginning
[17:44:41 CET] <Shezi> Ok. Can I install librtmp with FFmpeg?
[17:45:06 CET] <JEEB> you can first install/build librtmp, and then build FFmpeg with it - yes
[17:45:26 CET] <Shezi> Ok fair enough. Thank you JEEB . Very much appreciated for your help :)
[17:45:35 CET] <JEEB> the most often occuring thing I've noticed is that people are used to librtmp ways of passing options to the protocol implementation
[17:45:44 CET] <Shezi> ok
[17:45:45 CET] <JEEB> usually the same option is around in both
[17:46:17 CET] <JEEB> but yea, I have no idea - I'm just speaking out of experience looking at people screaming that librtmp works for them and the internal doesn't (and then things getting fixed by them passing on options)
[17:46:37 CET] <Shezi> So what kind of options are there which may differ
[17:47:05 CET] <Shezi> Assuming simple file streaming . Ffmpeg -re -I somefile.mp4 -c copy -f flv "somefacebook, rtmps url"
[17:47:54 CET] <JEEB> the difference mostly being that librtmp might be passed those options with the URL
[17:48:04 CET] <JEEB> while there are AVOptions in FFmpeg :P
[17:48:23 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/rtmpproto.c;h=b741e421af972a66bf424c730f3992549962eb05;hb=HEAD#l3094
[17:48:30 CET] <JEEB> these are the options in the internal protocol implementation
[17:48:46 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/librtmp.c;h=43013e46e0a758d0e5a943ba55f6d390cc993c04;hb=HEAD#l321
[17:48:49 CET] <JEEB> these are the ones for librtmp
[17:49:09 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/librtmp.c;h=43013e46e0a758d0e5a943ba55f6d390cc993c04;hb=HEAD#l85
[17:49:23 CET] <JEEB> and the rtmp_open() function seems to parse an awful lot of stuff from the URL
[17:49:33 CET] <JEEB> (in the librtmp one at least)
[17:50:33 CET] <Shezi> Ok. Yes I can see the different. Internal rtmp has more options.
[17:50:46 CET] <Shezi> Sorry my keyboard autocorrect has issues. Need to disable it.
[17:51:45 CET] <Shezi> Is librtmp a kind of external library for ffmpeg?
[17:51:52 CET] <JEEB> similar but a bit different rtmp_open in the internal one http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/rtmpproto.c;h=b741e421af972a66bf424c730f3992549962eb05;hb=HEAD#l2584
[17:51:58 CET] <JEEB> yes, librtmp is an older external library
[17:52:02 CET] <JEEB> which hasn't seen activity in ages
[17:53:09 CET] <Shezi> Ok, so its not good to use librtmp
[17:53:29 CET] <Shezi> I can try to compile librtmp to test. But for surely I won't use it if it has issues.
[17:53:47 CET] <JEEB> I didn't say it has issues, it's just an older and generally left-around-to-be library
[17:53:53 CET] <JEEB> so while I am not against testing with it
[17:54:07 CET] <JEEB> I'd probably just focus on seeing what's going differently with the internal one
[17:54:25 CET] <Shezi> ok
[17:54:53 CET] <Shezi> Loglevel verbose should be ok for a lot of debugging?
[17:55:25 CET] <JEEB> I'd probably go with -v debug, and possibly if that doesn't show differences I would just look at traffic dumps :P
[17:55:47 CET] <Shezi> Ok, I can try wireshark
[17:55:53 CET] <Shezi> Lets see, I will get back to you.
[17:56:49 CET] <Shezi> But in any case is there some developer whom we can talk and possibly pay something according to my budget to help me with this.
[17:57:15 CET] <JEEB> probably the best alternative is to look into the list of developers who actually worked on that module first
[17:57:55 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavformat/rtmpproto.c;h=b741e421af972a66bf424c730f3992549962eb05;hb=HEAD
[17:58:13 CET] <JEEB> (ignore the merge commits, those are just people merging Libav changes into FFmpeg)
[17:58:26 CET] <Shezi> Ok Great that should help
[17:59:22 CET] <lantizia> JEEB, am I essentially wanting the same as this guy? http://lists.live555.com/pipermail/live-devel/2015-September/019635.html
[17:59:22 CET] <Shezi> I just tested it with verbose
[17:59:35 CET] <lantizia> (and yes it happens to be a tv card)
[17:59:45 CET] <Shezi> Got so little output
[17:59:47 CET] <lantizia> albeit one that hands out its streams on http
[18:00:34 CET] <JEEB> lantizia: you want something that remultiplexes the mpeg-ts into fragmented mp4 or so. although that still won't probably give you good or well supported results if you really want people to be able to watch it from browsers
[18:01:06 CET] <lantizia> seems like ffmpeg only handles files though
[18:01:09 CET] <JEEB> nowadays the young folk prefer to have segments available through HTTP(S) as files and then a manifest that they can refresh
[18:01:24 CET] <JEEB> lantizia: nope. it has a *lot* of protocol support
[18:01:39 CET] <JEEB> so in theory you could make a nginx or apache module that does real-time remultiplexing :P
[18:01:44 CET] <JEEB> buut
[18:02:15 CET] <JEEB> lantizia: anyways is browser playback a must for you :P
[18:02:21 CET] <JEEB> because in that case you are losing the subtitle stream
[18:03:06 CET] <JEEB> (you can hard-code it into the video stream but that requires decoding, overlaying and re-encoding again)
[18:04:08 CET] <lantizia> yeah i don't mind loosing the subtitles
[18:04:40 CET] <JEEB> ok, then probably one of the simplest things is to grab ffmpeg.c and start pushing HLS or DASH onto a web server that can take traffic through HTTP(S)
[18:05:00 CET] <JEEB> so POST to a web server, and then clients would be GET'ing the results from that
[18:05:09 CET] <lantizia> meh just lost interest :)
[18:05:15 CET] <lantizia> thanks for the help though!
[18:05:25 CET] <JEEB> alright. and yes, streaming for browsers sucks :P
[18:05:29 CET] <lantizia> at the moment i've just been making light tweaks to apache to make this thing work over the net
[18:06:05 CET] <lantizia> ta ta for now, thanks again
[18:06:07 CET] <JEEB> I've been doing as-is MPEG-TS streaming myself before and I've liked it, but you have to re-package it into small segments that are auto-generated for browsers
[19:15:04 CET] <xn0r> are there any known problem with passing CFLAGS -fdata-sections -ffunction-sections -flto -ffat-lto-objects -Wl,-flto -Wl,--gc-sections when building ffmpeg?
[19:16:06 CET] <xn0r> I'm getting ./../x86_64-w64-mingw32/bin/ld: /tmp/test.exe.Nnwiac.ltrans0.ltrans.o:<artificial>:(.text+0xbfdd): undefined reference to `strndup'
[19:16:15 CET] <xn0r> and finally ERROR: libtls not found using pkg-config
[20:37:34 CET] <Zexaron> Even if it may not benefit FFMPEG do you guys as enthusiasts applaud this or it's not big deal? https://www.techpowerup.com/251984/intel-launches-free-open-image-denoise-library-for-ray-tracing
[20:38:56 CET] <Zexaron> Also it may be Raja Kuduri behind, yeah I was pissed at AMD exodus of top talent too
[20:40:09 CET] <Zexaron> It's not going to make thigns different if things go from one to another company, if AMD gets in trouble in GPUs then what, it'll be the same with 2 guys Nvidia and Intel, same thing, so I hope AMD doesn't go down so we can have 3 in the high-end GPU market
[21:28:44 CET] <Hello71> xn0r: -fdata-sections is counterproductive with -flto
[21:28:48 CET] <Hello71> and -Wl,-flto is invalid
[21:50:16 CET] <JEEB> lantizia: also I notice that your FFmpeg version is very old
[21:50:23 CET] <JEEB> try seeing if you can grab a more recent one
[21:50:33 CET] <JEEB> I think someone here hosted static builds if you don't want to build yourself
[21:50:33 CET] <JEEB> :P
[21:50:47 CET] <lantizia> yeah it's just some debian 8 box i'm borrowing to test this on
[21:51:05 CET] <lantizia> so whatever debian 8 had basically
[21:52:31 CET] <lantizia> i may have a way of making this perhaps easier
[21:52:57 CET] <JEEB> thankfully demuxing and remuxing doesn't require any additional libraries
[21:53:08 CET] <JEEB> so even if you build it yourself you wouldn't need any options
[21:53:11 CET] <lantizia> if this is even possible
[21:53:13 CET] <JEEB> just ./configure
[21:53:18 CET] <JEEB> and make
[21:53:25 CET] <JEEB> (as long as you have nasm installed and the basic toolchain
[21:53:40 CET] <JEEB> also all of the options I've given to you are documented in https://www.ffmpeg.org/ffmpeg-all.html#http
[21:53:52 CET] <JEEB> (that has the initial anchor to the http module's docs to make sure I'm not lying to you)
[21:54:07 CET] <JEEB> although it does say it's an experimental thing
[21:54:14 CET] <JEEB> (and I've not used it at all)
[21:54:34 CET] <JEEB> ok, the static builds linked from ffmpeg.org were https://johnvansickle.com/ffmpeg/
[21:54:38 CET] <lantizia> save your patience a sec :) back in a sec, like i said - might have a way of making this easier
[21:55:19 CET] <JEEB> (I think I've been patient enough with you already to be honest since you've generally not understood that I've been trying to help you - or that's how it's felt like)
[21:55:51 CET] <lantizia> right so I don't want you to exert yourself any more unnecessarily than required
[21:56:03 CET] <JEEB> also for the record, browsers do support fragmented mp4 but I wonder how well they'll deal with a constantly growing file input
[21:56:08 CET] <lantizia> which is why step 1 should be... Are we wasting our time, is this even possible? :D
[21:56:14 CET] <lantizia> so I'm going to do this one thing and be back
[21:56:32 CET] <JEEB> just try with a static build and if that HTTP listening thing doesn't work let's just stop at that :P
[21:56:40 CET] <JEEB> then you either give up browser support or do HLS/DASH as I noted
[21:56:49 CET] <JEEB> it requires JS based players but at least is supported
[21:59:34 CET] <JEEB> also these small segment file based things have the positive thing of being simple to serve through a more bandwidth-capable box
[21:59:47 CET] <JEEB> since all HTTP servers can take in POST/DELETE/RENAME requests
[22:00:17 CET] <lantizia> you exert yourself!
[22:00:25 CET] <JEEB> sure :P
[22:00:47 CET] <lantizia> right finished
[22:00:59 CET] <lantizia> ok dead easy - open that link in your PM
[22:01:10 CET] <lantizia> and you'll see i've apache proxypass'd that tuner so it works over the net
[22:01:19 CET] <lantizia> all the links on that page will work with VLC just fine
[22:01:23 CET] <lantizia> the HD ones are h264
[22:01:29 CET] <lantizia> *that* is what I'm trying to remux
[22:01:40 CET] <JEEB> yes, VLC and FFmpeg-based players should work with MPEG-TS over HTTP just fine
[22:01:44 CET] <JEEB> the input really isn't the problem
[22:01:50 CET] <lantizia> if you happen to have a latest ffmpeg then brill - you'll prob be able to tell me in 5 seconds if it is or isn't possible on your own localhost :P
[22:01:58 CET] <JEEB> true that
[22:02:02 CET] <lantizia> as you now have access to the input :)
[22:02:09 CET] <JEEB> although I did link you the static builds :P
[22:02:20 CET] <JEEB> which you can just curl/extract/run
[22:02:31 CET] <lantizia> sure but due to my incompetence/newbie-ness at all this - i guarantee this is quicker :P
[22:02:40 CET] <lantizia> and there isn't much point in working on something if it turns out it can't be done
[22:02:43 CET] <lantizia> :D
[22:02:57 CET] <lantizia> just remember the non-HD chans are mpeg2 - only the HD ones are h264
[22:03:14 CET] <lantizia> and welcome to british TV :P
[22:03:21 CET] <JEEB> oh I have that already due to $dayjob :P
[22:03:46 CET] <JEEB> can you just link me one thing instead of the index? I curl'd the index and it has no links since it's all JS
[22:04:19 CET] <JEEB> cheers
[22:04:24 CET] <furq> send me the link to pick tv so i can watch brit cops
[22:04:25 CET] <furq> tia
[22:04:45 CET] <lantizia> furq, done :)
[22:04:56 CET] <lantizia> not sure how mpeg2 over my upload will fair you though :)
[22:06:17 CET] <JEEB> huh, latest master also outputs nothing about the output
[22:06:32 CET] <JEEB> it does listen so it did at least do something for the output protocol
[22:06:36 CET] <lantizia> hurrah i'm not crazy :D
[22:07:25 CET] <JEEB> ah
[22:07:30 CET] <JEEB> it starts doing stuff as soon as you get a connection
[22:07:31 CET] <JEEB> funky
[22:07:41 CET] <JEEB> but then it says LATM is not supported in container :<
[22:07:49 CET] <JEEB> (the style of AAC audio in there)
[22:08:03 CET] <lantizia> the irony here is even if we get this working I likely have no use for it at all (which is why i gave up earlier) - but i hate being defeated
[22:08:49 CET] <furq> there are js mpegts to mp4 remuxers but they're intended for hls
[22:08:52 CET] <JEEB> and the last time LATM in mp4 was mentioned on the bug tracker it ended up with "please tell us if you ever find a specification for this" https://trac.ffmpeg.org/ticket/3244
[22:09:00 CET] <JEEB> furq: yes and he specifically doesn't seem to want to have any JS there
[22:09:01 CET] <JEEB> :P
[22:09:03 CET] <lantizia> mostly because even if it did work for my ultimate goal of something like cytube... well i then found out all that does is sync videos for the watchers, not re-stream... so ultimately i probbaly don't have the bandwidth to host many connections anyway :P
[22:09:03 CET] <furq> oh right
[22:09:05 CET] <furq> understandable
[22:09:07 CET] <JEEB> which is why he said no to HLS or DASH
[22:09:19 CET] <furq> well presumably for hls you'd need to remux it anyway
[22:09:22 CET] <lantizia> although i can put the tuner in our datacentre i guess
[22:09:32 CET] <furq> so you might as well just go straight to fmp4
[22:10:19 CET] <JEEB> lantizia: it worked with ffprobe btw, although it did receive the initial packets because the thing seemed to not write stuff out before there's a client
[22:10:30 CET] <JEEB> -map 0:v -map 0:a -c:v copy -c:a aac -b:a 192k -f mp4 -movflags "frag_keyframe+empty_moov+default_base_moof" -listen 1 "http://127.0.0.1:1337"
[22:10:42 CET] <JEEB> re-encoding the audio because LATM doesn't go into mp4 it seems
[22:10:42 CET] <lantizia> i'll test here on the LAN the tuner is on
[22:10:55 CET] <JEEB> and then as the client exits it exits too
[22:11:08 CET] <JEEB> so it's less good than VLC's http server thing
[22:11:42 CET] <JEEB> anyways, if you want to do this on a corporate scale then you definitely want to go for HLS/DASH. or at least while I agree that HLS/DASH suck, if you are going to want to support browsers that's pretty much the only real way :P
[22:12:06 CET] <JEEB> if nothing else because segments can be cached and served, while this stuff is much less simple to cache :P
[22:12:11 CET] <lantizia> translation: not possible?
[22:12:24 CET] <lantizia> i'm more talking 4 or 5 watchers, tiny scale
[22:12:57 CET] <JEEB> if this thing stayed up and worked it'd probably be possible :P (and it's possible this thing only supports a single client since it's probably some random PoC)
[22:13:12 CET] <lantizia> but tbh i was also thinking it'd be nice if v11 is pick and v107 is bbc news - to pass that along too :P
[22:13:20 CET] <JEEB> in general if you want browser playback you go HLS or DASH, and use hls.js or dash.js
[22:13:21 CET] <lantizia> which is a whole new world of hurt I'm sure
[22:14:21 CET] <lantizia> furq, hows pick? :D
[22:14:59 CET] <furq> this is classic brit cops
[22:15:10 CET] <lantizia> does it even stream alright?
[22:15:14 CET] <furq> yeah it works fine
[22:15:17 CET] <lantizia> wow ok
[22:15:24 CET] <lantizia> must have more upload than i thought
[22:15:41 CET] <lantizia> that's literally the tv tuner dumping the DVB-T contents into http for you
[22:15:43 CET] <JEEB> anyways, HTTP MPEG-TS works as long as you're using custom apps
[22:15:49 CET] <JEEB> yea, I've done that sort of streaming too :P
[22:15:50 CET] <furq> it's only about 1600kbps
[22:16:28 CET] <JEEB> but then you hit the problem where you want browser support and suddenly you can't serve the same stream to those people :P
[22:17:06 CET] <JEEB> (as in, by the minimum you have to repackage it - not re-encode necessarily)
[22:17:31 CET] <lantizia> it'd just be nice if your talking to 3 or 4 people to just go... Hmm, this is interesting on tv... http://mytv.whatver.com   (**everyone clicks**)
[22:17:37 CET] <lantizia> rather than... Step 1) Get VLC
[22:17:48 CET] <lantizia> Step 2) Open this menu, that menu, paste this - do that
[22:17:50 CET] <JEEB> yes, then just let go of your "doesn't require JS" requirement
[22:17:53 CET] <lantizia> you get the idea :P
[22:17:58 CET] <JEEB> and do HLS
[22:18:05 CET] <lantizia> right but that cytube thing is quite nice as it does the whole chat room thing around it
[22:18:28 CET] <JEEB> well, that's it then
[22:18:32 CET] <JEEB> have fun
[22:18:59 CET] <JEEB> (also btw, you're not the only who's depressed that browsers don't want to do proper streaming)
[22:19:35 CET] <lantizia> as in... they're going out of their way not to?
[22:20:27 CET] <JEEB> dunno if out of their way. in theory there's WebRTC which is just RTP with some other fluff, but that also needs plenty of JS to set it up
[22:20:33 CET] <lantizia> hmm a new thought... i wonder if the actual bbc website when it broadcasts live tele - if thats using hls
[22:20:53 CET] <JEEB> HLS or DASH or if they require silverlight - smooth streaming
[22:20:55 CET] <JEEB> all very similar
[22:21:30 CET] <JEEB> if you see the JS player load up m3u8 -> HLS playlists
[22:21:36 CET] <lantizia> dash i think
[22:21:36 CET] <furq> iplayer uses hls yeah
[22:21:40 CET] <JEEB> if you see it loading mpd -> DASH manifests
[22:21:51 CET] <lantizia> at least this pops up when i right click...  2908kbps | dash (akamai_dash_live_https)
[22:21:52 CET] <JEEB> if you see it loading /Manifest -> smooth streaming
[22:21:57 CET] <furq> i think technically it's hds
[22:22:49 CET] <lantizia> so are the beeb sending TS and then some JS is remuxing to mp4 ?!
[22:22:56 CET] <furq> is that for a live stream or vod
[22:23:00 CET] <lantizia> live stream
[22:23:08 CET] <furq> that must be new then
[22:23:16 CET] <furq> i want to say they support hls, hds and dash for vod
[22:23:16 CET] <JEEB> lantizia: yes. HLS segments quite often are .ts (since that's what apple started with)
[22:23:42 CET] <furq> apple devices only support hls so everything needs to support that
[22:23:47 CET] <JEEB> and yes, then the JS player reads that and makes fragmented mp4 out of it :P
[22:23:52 CET] <JEEB> and feeds that to the browser
[22:23:56 CET] <JEEB> because AHAHAHAHA
[22:23:58 CET] <lantizia> https://i.snag.gy/w9KB8T.jpg
[22:23:58 CET] <furq> yeah it's terrible but it works
[22:24:22 CET] <JEEB> if it's DASH then it's likely fragmented mp4 fragments
[22:24:25 CET] <JEEB> see the network tab
[22:24:26 CET] <furq> get_iplayer will show you all the formats
[22:24:44 CET] <JEEB> &34
[22:24:50 CET] <lantizia> furq, i think get_iplayer is only for vod stuff
[22:24:57 CET] <furq> it does live stuff as well
[22:24:59 CET] <furq> or it did last time i tried
[22:25:04 CET] <furq> they're constantly trying to break it though
[22:25:18 CET] <JEEB> lantizia: anyways I guess you now understand why I was constantly recommending HLS/DASH when you noted you wanted a browser to play it :P
[22:25:48 CET] <furq> yeah last time i needed to do livestreaming to browsers, hls was by far the least annoying method
[22:25:49 CET] <lantizia> i only wanted a browser to play it because then i knew it'd *also* work with cytube
[22:25:56 CET] <furq> and i doubt anything much has changed since then
[22:26:04 CET] <lantizia> which is essentially a browser playing it as all cytube does is sync up everyones <video> players
[22:26:12 CET] <furq> it says a lot that remuxing mpegts to mp4 in the browser is the most appealing way of doing anything
[22:26:15 CET] <lantizia> afaik
[22:26:50 CET] <lantizia> ok so isn't a bit insane that a bit of javascript can do what ffmpeg and vlc can't do!?
[22:26:59 CET] <furq> uh
[22:27:08 CET] <furq> ffmpeg will remux mpegts to mp4 just fine
[22:27:18 CET] <lantizia> so that'd then be fine for a normal <video> tag?
[22:27:29 CET] <JEEB> of course not since browsers don't support MPEG-TS
[22:27:32 CET] <JEEB> argh
[22:27:33 CET] <JEEB> fuck it
[22:27:35 CET] <JEEB> it's almost midnight
[22:27:51 CET] <furq> you still need js to play fmp4 streams iirc
[22:27:56 CET] <furq> it has to go through MSE
[22:28:22 CET] <lantizia> this do-hicky? https://en.wikipedia.org/wiki/Media_Source_Extensions
[22:28:24 CET] <furq> yeah
[22:28:30 CET] <JEEB> and it can't be a constant stream with JS because JS based AJAX requests buffer the whole thing
[22:28:39 CET] <furq> and you generally can't just livestream mp4 because of the nature of the format
[22:28:39 CET] <JEEB> welcome to "browsers hate streaming data"
[22:28:45 CET] <furq> non-fragmented mp4
[22:28:59 CET] <furq> you would really think this would be less of a clusterfuck considering how popular streaming video on the internet is now
[22:29:06 CET] <furq> but then that would require browser vendors to agree on things
[22:29:11 CET] <furq> and to take less than a decade to do so
[22:30:02 CET] <lantizia> OH http://i.imgur.com/uOMz41Y.png
[22:30:58 CET] <JEEB> I guess it's time for you to set up a web server with a POST/DELETE/RENAME white list towards you stream source :
[22:30:58 CET] <lantizia> hmm if it does - that maybe i can just feed it the TS stream
[22:31:01 CET] <JEEB> :P
[22:31:11 CET] <JEEB> no, you cannot. you still need to segment it with ffmpeg or so
[22:31:16 CET] <lantizia> also a DONKEY/HORSE/SKUNK
[22:31:25 CET] <JEEB> ok, thank you
[22:31:25 CET] <lantizia> no idea what those means in respect to anything :)
[22:31:34 CET] <JEEB> POST posts data onto a http server
[22:31:40 CET] <lantizia> ok that kinda post
[22:31:41 CET] <JEEB> DELETE is deleting a file from a web server
[22:31:44 CET] <JEEB> RENAME is rename
[22:31:45 CET] <JEEB> d'uh
[22:31:52 CET] <JEEB> so you have an apache or nginx or something
[22:31:57 CET] <lantizia> it's just apache doing proxypass
[22:32:04 CET] <lantizia> what is there to delete or rename :S
[22:32:07 CET] <lantizia> or even post
[22:32:11 CET] <lantizia> totally confused
[22:32:17 CET] <JEEB> ok, then you clearly don't understand that HLS is a bunch of MPEG-TS segments
[22:32:20 CET] <JEEB> not a continuous stream
[22:32:39 CET] <JEEB> continuous streams are something BROWSERS CANNOT HANDLE FOR THE ALMIGHTY INEFFECTIVE BEING'S SAKE
[22:32:47 CET] <JEEB> because they will just keep buffering it
[22:32:47 CET] <lantizia> even with HLS JS
[22:32:53 CET] <furq> i mean if you're going to use nginx
[22:33:16 CET] <furq> nginx-rtmp will do all the segmenting for you and you can just have it pull the right rtsp stream (or whatever your dvb box outputs) when someone starts playing back the stream
[22:33:26 CET] <furq> so that's probably worth looking into
[22:33:41 CET] <lantizia> furq, think i know a customer who uses that too
[22:34:11 CET] <furq> that's probably what i would do in this situation
[22:34:30 CET] <furq> https://github.com/arut/nginx-rtmp-module/wiki/Directives#exec_pull
[22:34:51 CET] <lantizia> so am I right in thinking - even if a webpage was LOADED with HLS/DASH/MSE/GOODNESS all in JS and stuffsss...
[22:35:07 CET] <furq> it won't just play the mpegts stream, no
[22:35:12 CET] <lantizia> my TS stream (from the tuner) being accessed by that page - would still be pointless
[22:35:16 CET] <furq> you need an hls playlist or dash manifest or whatever
[22:35:21 CET] <lantizia> right something has to break it up into segments
[22:35:23 CET] <furq> right
[22:35:30 CET] <furq> like i said, nginx-rtmp will do that on demand for you
[22:35:42 CET] <lantizia> can it keep it http?
[22:36:06 CET] <furq> if hls is http enough for you then yes
[22:36:12 CET] <lantizia> or presumably the rtmp is purposeful
[22:36:25 CET] <furq> well in this case it wouldn't be using rtmp at all
[22:36:31 CET] <furq> normally it uses rtmp as ingest and optionally as an output
[22:36:33 CET] <lantizia> right just the name of the module then
[22:36:49 CET] <furq> but you'd be pulling over http and then serving hls fragments
[22:38:10 CET] <lantizia> well if its true cytube does accept hls streams
[22:38:13 CET] <lantizia> then this idea might be back on
[22:38:37 CET] <lantizia> think i've psychologically harmed JEEB though
[00:00:00 CET] --- Sun Feb  3 2019