February 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190202
by burek 03 Feb '19

03 Feb '19

[03:58:49 CET] <agrecascino> okay so uh [03:58:50 CET] <agrecascino> i messed it up [03:58:53 CET] <agrecascino> as in i probably should read documentation [03:58:56 CET] <agrecascino> so uhm [03:58:57 CET] <agrecascino> before i mess it up again [03:59:42 CET] <agrecascino> nevermind [04:01:12 CET] <agrecascino> okay i have a new question [04:02:11 CET] <agrecascino> so offset at the end of mov_read_sidx = initial + atom.size + offset of item [04:02:19 CET] <agrecascino> + offsets in references [04:02:30 CET] <agrecascino> actually i really have no idea what i'm doing [04:02:34 CET] <agrecascino> :thonk: [04:02:42 CET] <agrecascino> *raises their hand* [04:02:52 CET] <agrecascino> can someone explain to me how the mp4 parser thing works? [04:03:02 CET] <agrecascino> or at least how mov_read_sidx is supposed to work [04:06:41 CET] <agrecascino> first offset = 0 in the failing test [04:06:46 CET] <agrecascino> but 52 in the problem file [04:06:58 CET] <agrecascino> which causes the "duplicated offset" issue [04:07:36 CET] <agrecascino> because the offset points to the moof and there's a second sidx between the moof [04:07:41 CET] <agrecascino> and the other sidx [04:07:55 CET] <agrecascino> and since that's added to offset it pretends as if the second sidx doesn't exist [04:08:02 CET] <agrecascino> and everything breaks like that [04:09:11 CET] <agrecascino> because in that adding the first_ref makes it so that equals the file size [04:09:52 CET] <agrecascino> so i don't really know why anything is happening but my spidey senses say adding first_ref is a bad [04:10:27 CET] <agrecascino> but it seems sane? [04:10:47 CET] <agrecascino> like commenting random stuff shouldn't be a "fix" [04:13:38 CET] <agrecascino> like part of me is wondering if the file encoded is wrong? [04:13:50 CET] <agrecascino> or maybe i'm just not getting any of this because i'm new [04:15:40 CET] <agrecascino> like from what i'm looking at first_offset is 52 because both are pointing at the same moof and mdats and the offset is for them being 52 bytes ahead in the file [04:15:42 CET] <agrecascino> which is [04:15:44 CET] <agrecascino> correct? [04:15:59 CET] <agrecascino> i mean the math works out and we reach the end of the file but like [04:16:10 CET] <agrecascino> that's not correct in that we ignore the second sidx [04:20:31 CET] <cone-061> ffmpeg 03Jun Zhao 07master:6dc06e979c38: doc/filters: document ranges and defaults for nlmeans options [11:02:45 CET] <JEEB> agrecascino: check out something like L-SMASH's boxdumper (`boxdumper --box FILE`) for an alternative dump of what's inside the file. compare that to the spec. you should probably have a better idea after that [11:44:13 CET] <durandal_1707> gstreamer all the things [13:30:20 CET] <JEEB> can someone remind me where under libavcodec the documentation is? [13:30:37 CET] <JEEB> as in, if I add a new decoder, where do I stick its docs? [13:32:44 CET] <nevcairiel> doc/decoders.texi? [13:32:49 CET] <JEEB> danke [13:33:01 CET] <nevcairiel> the list is underwhelmingly incomplete however [13:33:05 CET] <JEEB> yea [13:33:25 CET] <JEEB> I just thought I'd do this kind of properly this time :P esp. since I have two AVOptions [13:37:36 CET] <JEEB> btw did we have any helper function to do something like [13:37:39 CET] <JEEB> `(int)round(((double)region->i_fontwidth / (double)profile_font_size) * 100)` [13:38:14 CET] <JEEB> (gets the % of how large the width is compared to the default width) [14:32:41 CET] <JEEB> alright, tweaked my upstreaming branch a bit, and posted [15:27:37 CET] <JEEB> not surprisingly the first response was "can't we just internalize this library" :) which unfortunately seems to be a 'no' due to its license. I did mention alternatives, but they'd have to be rewritten at least partially to be usable :/ [17:07:39 CET] <agrecascino> https://my.mixtape.moe/rdxsje.png [17:07:42 CET] <agrecascino> like [17:08:14 CET] <agrecascino> both sidx[1].position + .size + .offset + .reference_size = 7131 [17:08:16 CET] <agrecascino> and [17:08:30 CET] <agrecascino> sidx[0].position + .size + .offset + .reference_size [17:10:15 CET] <agrecascino> because they point to the same moof and mdat boxes [17:10:46 CET] <JEEB> one of them is clearly for the audio (timescale 48000) [17:10:58 CET] <JEEB> what's the definition of the reference_ID [17:11:26 CET] <agrecascino> *runs to find the standard* [17:11:52 CET] <JEEB> https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html [17:11:54 CET] <JEEB> as noted on the ML [17:11:58 CET] <agrecascino> i have it open [17:12:01 CET] <JEEB> alright [17:12:01 CET] <JEEB> Ö= [17:12:02 CET] <JEEB> :) [17:12:16 CET] <JEEB> it's nice that some of the ISO/IEC specs are free [17:13:07 CET] <agrecascino> they have different reference ids? [17:13:28 CET] <agrecascino> actually [17:13:30 CET] <agrecascino> well [17:13:53 CET] <agrecascino> the second first one reference a sidx box before the first moof [17:14:01 CET] <agrecascino> as that one has reference_id = 1 [17:15:29 CET] <JEEB> yes that's the first difference I noticed when looking at the field [17:15:35 CET] <JEEB> first had a reference_ID of 1, the second 2 [17:17:48 CET] <agrecascino> like i'm not entirely sure how to solve this without 2 passes or like [17:18:06 CET] <agrecascino> changing the exit condition [17:21:14 CET] <agrecascino> like you could possibly have the exit condition check if the ref_id == last_track_id [17:21:30 CET] <agrecascino> but unless the order is mandated in the standard that would only kinda work [19:00:23 CET] <cone-289> ffmpeg 03Paul B Mahol 07master:9e0e8e10c7b4: avfilter/vf_mix: add timeline support to tmix filter [19:00:24 CET] <cone-289> ffmpeg 03Paul B Mahol 07master:08b83bf82893: avfilter/vf_mix: always output frame if array is filled [19:55:22 CET] <durandal_1707> what is RIST? [19:56:39 CET] <JEEB> I think I had a PDF about that open some time ago... let me check [19:58:49 CET] <JEEB> ugh, pretty sure I closed a tab like that today, but I can't find it from my history :| [19:59:29 CET] <JEEB> some RTP like spec if I recall correctly [20:13:28 CET] <agrecascino> someone just mailed another fix but [20:13:39 CET] <agrecascino> i'm also not sure if it's correct in the sense that it only really prevents the hanging but doesn't really fix the reason behind that hang? [20:14:11 CET] <JEEB> not sure what you're talking about, but welcome to "let's just make something 'work'" sort of stuff [20:14:14 CET] <agrecascino> but i think i fixed the not loading all the sidx atoms part and i still that it hanged so [20:14:32 CET] <agrecascino> maybe it is correct [20:15:14 CET] <JEEB> sounds like you have to give it some extra thought then :) [20:15:34 CET] <agrecascino> yeah uhm [20:15:40 CET] <agrecascino> all the fragments actually seem to be loaded [20:16:02 CET] <agrecascino> as of this dumb patch thing [20:16:47 CET] <agrecascino> nope wait nevermind [20:16:51 CET] <agrecascino> the last fragment is still just [20:16:52 CET] <agrecascino> nonsense [20:17:12 CET] <agrecascino> actually correction it isn't [20:17:13 CET] <agrecascino> i think [20:17:40 CET] <agrecascino> yeah it's all there actually so [20:18:13 CET] <cone-289> ffmpeg 03Shiyou Yin 07master:0c43429210d6: avcodec/mips: [loongson] optimize put_hevc_qpel_uni_hv_8 with mmi. [20:18:14 CET] <cone-289> ffmpeg 03Shiyou Yin 07master:c0942b7a2c5c: avcodec/mips: [loongson] optimize put_hevc_epel_bi_hv_8 with mmi. [20:18:15 CET] <cone-289> ffmpeg 03Shiyou Yin 07master:dceefb2b84b3: avcodec/mips: [loongson] optimize put_hevc_qpel_bi_h_8 with mmi. [20:18:16 CET] <cone-289> ffmpeg 03Shiyou Yin 07master:b429c86d84cf: avcodec/mips: [loongson] optimize put_hevc_qpel_h_8 with mmi. [20:19:03 CET] <agrecascino> one bug kinda fixed and another seemingly still there [20:22:24 CET] <agrecascino> ah actually this is part of the bug [20:22:40 CET] <JEEB> :) [20:23:13 CET] <agrecascino> in the sense that their patch actually fixes an issue where since the fragment data for each track is split per sidx [20:23:21 CET] <agrecascino> and mine makes it so the last sidx box is actually read [20:25:52 CET] <agrecascino> i still don't like the way mine works and i think it's kind of a hack but i'm not really sure how to do it otherwise considering any consecutive sidx boxes pointing to the same whateverthatoneboxiscalled at the end of the file would leave the offset at the end of the file [20:26:18 CET] <agrecascino> unless the spec mandates somewhere that the consecutive sidx boxes are put in order of track id [20:29:27 CET] <agrecascino> like we're looking for sidx data in fragment 1 for stream 1 when it only exists in 0 and 3 [20:29:54 CET] <agrecascino> so the patch is right, maybe not in implementation but idk what the heck i'm talking about [20:31:32 CET] <agrecascino> actually there's absolutely no issue in the first place what [20:32:25 CET] <agrecascino> wait nevermind [20:32:47 CET] <JEEB> just take your time :) [20:32:59 CET] <JEEB> these things are not simple and there are various gotchas [20:33:03 CET] <agrecascino> actually [20:33:09 CET] <agrecascino> okay with just my patch it's working now [20:33:15 CET] <agrecascino> am i still alive [20:33:35 CET] <JEEB> thankfully there's things like boxdumper that help you get a second view on the file [20:33:35 CET] <agrecascino> alright uhm [20:33:41 CET] <JEEB> (or DVBInspector for MPEG-TS) [20:33:50 CET] <agrecascino> i just used an online parser thing [20:33:56 CET] <agrecascino> err [20:34:09 CET] <agrecascino> anyway i don't really know what's happening but it's loading all the sidx stuff now [20:34:16 CET] <agrecascino> and not hanging [20:34:38 CET] <agrecascino> i just really think this is a hack [20:37:16 CET] <agrecascino> well uhm [20:37:18 CET] <agrecascino> the test passes [20:44:57 CET] <agrecascino> uhm [20:46:54 CET] <agrecascino> ok so is number of movie fragments * track count a robust count of sidx boxes [20:51:02 CET] <agrecascino> nope the spec is way too vague for that [20:51:13 CET] <thardin> https://www.wired.com/story/finding-lena-the-patron-saint-of-jpegs/ [20:52:52 CET] <agrecascino> JEEB, the parser for mp4 files in ffmpeg is one pass right? [20:53:31 CET] <JEEB> it does seek to places as far as I know [20:53:40 CET] <JEEB> since it can read the moov atom from the end of the file for example [20:53:52 CET] <agrecascino> ok so uhm [20:54:07 CET] <agrecascino> i'm not sure i should be making parser changes like this but [20:54:23 CET] <agrecascino> i think i need to add a step to count the number of sidx boxes [20:54:45 CET] <agrecascino> because like of how absolutely sinfully vague the spec is there can be like [20:54:52 CET] <JEEB> you can always post an RFC or something on the ML [20:58:10 CET] <agrecascino> like the spec says a segment index provides information for one media stream and should document the entirety of the stream [20:58:42 CET] <agrecascino> but also says that segment indexes can be present for less than all streams [00:00:00 CET] --- Sun Feb 3 2019

1 0

ffmpeg.log.20190202
by burek 03 Feb '19

03 Feb '19

[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=b7… [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=4301… [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=4301… [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=b7… [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… [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-l… [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

1 0

ffmpeg-devel.log.20190201
by burek 02 Feb '19

02 Feb '19

[00:04:54 CET] <llogan> michaelni: i looked at 6 randomish proposed changes by your script and it seemed fine [00:27:20 CET] <michaelni> llogan, ok thanks, will run the commands then, they should improve the status on average then at least [14:52:52 CET] <atomnuker> "SVT-AV1 support a compressed 10-bit format" [14:53:03 CET] <atomnuker> yes, as in packed 10 bit, no padding [14:53:58 CET] <atomnuker> "to achieve a higher speed and channel density levels." <- right, they're high [14:54:18 CET] <JEEB> so they did packing and then compress that too? [14:54:24 CET] Action: JEEB golfclaps [14:55:02 CET] <atomnuker> well, its an encoder, so either they based their whole thing around packed 10bit (e.g. you need a bitstream reader to read a pixel e.g. they're beyond nuts) or they uncompress it for you [15:20:09 CET] <thardin> I thought it was Sveriges Television at first [15:20:43 CET] <thardin> and I was excited that they're doing things that benefit the free software world [15:20:46 CET] <thardin> but alas [15:21:35 CET] <thardin> 48GB to encode 4k, yikes [15:26:43 CET] <gnafu> thardin: In realtime across over 100 cores. I'm not sure if non-realtime modes across fewer cores would need as much RAM. [15:27:03 CET] <gnafu> I'm hoping to play with it on much more meager machines and see what happens :-). [15:27:19 CET] <thardin> realtime eh? [15:27:33 CET] <thardin> sounds a bit like poor man's FPGA [15:27:45 CET] <gnafu> thardin: Hehe. [15:28:02 CET] <gnafu> Or a rich man's, since I imagine realtime 4K requires Intel's most expensive processors. [15:34:17 CET] <gnafu> atomnuker: It looks like the packed 10-bit input is optional, and it can still take 8-bit yuv420p. [15:34:30 CET] <gnafu> (Or 10-bit yuv420ple.) [15:34:46 CET] <gnafu> (Err, yuv420p10le.) [15:41:38 CET] <thardin> good point :) [15:42:00 CET] <thardin> actually that very much sounds like typical cluster stuff [15:42:24 CET] <thardin> an MPI based encoder would make a lot of sense for a format as complex as AV1 [15:44:18 CET] <nevcairiel> mthe [15:44:37 CET] <nevcairiel> the SVT things are strongly focused on scaling to endless resources [15:45:25 CET] <thardin> I guess realtime implies broadcast or large streamer at the very least. would be hard to justify needing an entire rack or two of machines for the bandwidth savings otherwise [15:46:21 CET] <thardin> hrm, perhaps I should fix up the patches I've been working on the last few weeks so they can be pushed [15:46:35 CET] <thardin> .. after the next meeting [19:09:33 CET] <trfl> looks like trac exploded https://trac.ffmpeg.org/ [19:10:42 CET] <durandal_1707> all bug reports lost, finally! [19:16:32 CET] <kurosu_> realtime over 100 cores? what is that? 4* E7-8890 v4 or some Platinum 81xy with xy>50 or some such? around 20K for that system? [19:17:29 CET] <kurosu_> s/that system/just the CPUs [19:17:30 CET] <nevcairiel> their hevc encoder has quoted realtime numbers for the Platinum 8180 [19:17:41 CET] <nevcairiel> so probably in that area [19:18:55 CET] <kurosu_> codecs: everybody loses, but Intel [19:19:33 CET] <nevcairiel> hardware costs are mostly irrelevant for big companies anyway [19:20:21 CET] <nevcairiel> 10k for one cpu seems unthinkable, but there is still racks full of that =p [19:26:40 CET] <kurosu_> encoding videos of cats [19:26:54 CET] <nevcairiel> of course [20:59:29 CET] <cone-278> ffmpeg 03Jun Zhao 07master:6c586303a14a: lavfi/nlmeans: improve the performance [20:59:30 CET] <cone-278> ffmpeg 03Clément BSsch 07master:65e61febc8ad: lavfi/nlmeans: simplify log() call [20:59:31 CET] <cone-278> ffmpeg 03Clément BSsch 07master:1a9c6cc41102: lavfi/nlmeans: use a dynamic size for the weight LUT [21:16:27 CET] <JEEB> how many here have tried out videolan's gitlab merge request flow and think of it positively btw? [21:22:52 CET] <atomnuker> its meh, no better than github [21:23:51 CET] <atomnuker> I think by default pushers should be able to rebase PRs as they merge them but currently they need permission from the author [21:24:14 CET] <JEEB> possibly because it's considered still a branch in the author's repo [21:25:52 CET] <atomnuker> at least it doesn't make merge commits [21:26:14 CET] <JEEB> that's configurable @ github as well [21:26:24 CET] <JEEB> w/39 [21:26:27 CET] <JEEB> whoops [23:18:54 CET] <JEEB> if anyone is still awake, feel free to check out the two commits on the top of https://github.com/jeeb/ffmpeg/commits/mpegts_arib_stuff_upstreaming [23:19:02 CET] <JEEB> if those look good I'll post them on the ML :) [23:19:53 CET] <cone-278> ffmpeg 03Carl Eugen Hoyos 07master:73d4efc596ad: lavu/imgutils: Use FFABS() instead of abs() for ptrdiff_t. [00:00:00 CET] --- Sat Feb 2 2019

1 0

ffmpeg.log.20190201
by burek 02 Feb '19

02 Feb '19

[00:23:31 CET] <mfwitten> The `minterpolate' filter is producing nice results, but at the very beginning of the results, there is some jerky motion as though no interpolation were done, or as though frames are duplicated. Is this an expected artifact of the algorithm? [00:30:03 CET] <mfwitten> Specifically, I'm interpolating to `fps=180000/1001' and then making the result slow motion via `setpts=6*PTS'. [00:30:47 CET] <mfwitten> At the very beginning of the resulting stream, there is non-smooth/stuck motion [00:36:47 CET] <mfwitten> When I drop the `setpts' part, it naturally produces a result with `179.82 fps'. Interestingly, the encoding process shows `frame= 4253 ... dup=3544'. That seems suspicious. [01:05:44 CET] <raytiley> can I make this filter run at realtime? ffmpeg -f lavfi -i smptehdbars=1920x1080 -f lavfi -i "sine=frequency=1000" [01:18:52 CET] <mfwitten> The only way I can get rid of the jerky motion at the beginning of the stream is to save the stream, and then `-ss 1' to seek past it and just copy out the rest of the stream. That seems so absurd [01:42:36 CET] <mfwitten> I've used `trim=start_frame=...' to remove an initial 6x multiple of the ~179.82 FPS stream, and then used `setpts=6*(PTS-STARTPTS)' [01:42:48 CET] <mfwitten> This at least cuts out the bad part, but I do wonder why there is a bad part at all. [17:24:45 CET] <yrios> I always get "Native MSYS builds are discouraged, please use the MINGW environment." ... Why does the configure script even think I use MSYS? [17:44:01 CET] <BtbN> Because the target os matches msys* [17:44:09 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=e1412352fa450b9d… [18:08:52 CET] <yrios> I had multiple 'uname' installed, so I had to fix the order in which they appeared in %PATH%. seems to work now [18:13:20 CET] <BtbN> how even [18:42:22 CET] <yrios> not my machines .. [18:42:42 CET] <furq> i was baffled by that at first but it's windows so there's probably 17 broken msys installs on there still in the path [18:43:16 CET] <yrios> yep [18:50:32 CET] <yrios> the generated Makefile only contains 'include ./Makefile' ... What could be the reason? [19:05:18 CET] <mfolivas> not sure how I can get my videos to show on quicktime using vaapi [19:17:22 CET] <mfolivas> using this: ffmpeg -vaapi_device /dev/dri/renderD128 -i some-random-video.mp4 -vf 'hwupload,scale_vaapi=w=1920:h=1080:format=nv12' -c:v h264_vaapi -level 4.1 -preset fast -b:v 5M -profile 578 -bf 0 small-video.mp4 [19:17:37 CET] <mfolivas> I figured that I should use a profile but can't find the right one [20:05:31 CET] <mfolivas> one of our investors wants me to try to see if we can use Intel's nueral compute stick 2 [20:05:44 CET] <mfolivas> does anyone knows if this can be used for decoding? [20:05:49 CET] <mfolivas> https://venturebeat.com/2018/11/14/intels-neural-compute-stick-2-is-8-times… [20:12:01 CET] <durandal_1707> nope [20:12:33 CET] <pink_mist> do you mean that nobody knows, or do you mean it can't be used :P [20:14:01 CET] <durandal_1707> if someone build neurons specifically for decoding some codecs that it can be used [20:32:55 CET] <mfolivas> durandal_1707 The hardware accelerators include things like hardware encode and decode of H.264 and Motion JPEG, as well as a warp engine for handling a fish-eye lens, dense optical flow, and stereo depth perception [20:33:16 CET] <mfolivas> so, it does has encode and decode [20:33:46 CET] <durandal_1707> not all codecs ... [20:35:55 CET] <furq> apparently it's not quicksync so it won't be supported by ffmpeg [20:36:22 CET] <furq> "won't be" meaning isn't now, someone might add it [20:37:11 CET] <JEEB> if it's not vaapi or QS, then lul [20:38:11 CET] <furq> https://www.movidius.com/myriadx [20:38:13 CET] <furq> it's this thing [22:11:39 CET] <saml> if key frames are at irregular interval, I need to encode it again to make key frames at regular interval, right? [22:12:36 CET] <JEEB> only if you actually need that [22:12:44 CET] <JEEB> and often when you think you need that, it's not actually true [22:15:13 CET] <saml> cdn vendor, akamai, cannot support HLS packaging of videos with irregular key frame interval [22:16:07 CET] <saml> JEEB, how would you generate HLS (m3u8) properly given a video with irregular key frame interval? [22:16:14 CET] <saml> i should try first [22:16:33 CET] <JEEB> the usual way? I mean, I've had mismatching GOPs between profiles in HLS for ages :P [22:17:00 CET] <JEEB> there might be some minor devices that don't support it, maybe, but android's exoplayer and iOS's player support that stuff for ages [22:17:14 CET] <saml> https://ffmpeg.org/ffmpeg-formats.html#hls-2 It says Make sure to require a closed GOP when encoding and to set the GOP size to fit your segment time constraint. [22:18:03 CET] <mfolivas> need help with VAAPI, can't get it to play with QuickTime [22:18:17 CET] <mfolivas> I'm sure if has to be some settings that I can use [22:18:24 CET] <mfolivas> I tried using -profile [22:20:26 CET] <JEEB> saml: that just means that you probably want closed GOPs (not open), and that the GOP size is at least having a max length set [22:20:30 CET] <JEEB> to what you need [22:40:18 CET] <GuiToris> hey, can you help me encode a video with vp9 codec? [22:40:40 CET] <GuiToris> it must have a different scale than x265 [22:41:22 CET] <GuiToris> I've tried crf 28 but the output file was way too big [22:41:33 CET] <GuiToris> 1:50 ~ 250Mb [23:01:59 CET] <mfolivas> ffmpeg -hide_banner -vaapi_device /dev/dri/renderD128 -i input.mp4 -vf 'format=yuv420p' -c:v h264_vaapi output.mp4 [23:02:15 CET] <mfolivas> gives me this error: "Impossible to convert between the formats supported by the filter 'Parsed_format_0' and the filter 'auto-inserted scaler 0'" [00:00:00 CET] --- Sat Feb 2 2019

1 0

ffmpeg-devel.log.20190131
by burek 01 Feb '19

01 Feb '19

[00:25:31 CET] <cone-009> ffmpeg 03Michael Niedermayer 07master:b559c58a03f8: avformat/flvdec: Try to support some concatenated flv files [00:25:32 CET] <cone-009> ffmpeg 03Michael Niedermayer 07master:db1c4acd02af: avcodec/fic: Check that there is input left in fic_decode_block() [00:25:33 CET] <cone-009> ffmpeg 03Michael Niedermayer 07master:f4079d5174c2: avcodec/rasc: Check uncompressed dlta size [00:25:34 CET] <cone-009> ffmpeg 03Michael Niedermayer 07master:9f4af97aff89: avcodec/rasc: Move ff_get_buffer() after frame checks [00:25:35 CET] <cone-009> ffmpeg 03Michael Niedermayer 07master:0b50f27635f6: avformat/rtsp: Clear reply in every iteration in ff_rtsp_connect() [09:17:57 CET] <cone-836> ffmpeg 03Steven Liu 07master:62e8644bcadb: avformat/hlsenc: make the EXT-X-MEDIA NAME field by stream id. [09:17:57 CET] <cone-836> ffmpeg 03Steven Liu 07master:6a25bb5aa422: avformat/hlsenc: add var_stream_map DEFAULT field status parameter [09:17:57 CET] <cone-836> ffmpeg 03Steven Liu 07master:1e03d600542d: avformat/hlsenc: add var_stream_map LANGUAGE field string parameter [17:18:33 CET] <cone-438> ffmpeg 03Mateusz 07master:fe1ccc1e9116: libavcodec/rscc.c: add missing semicolon [17:18:34 CET] <cone-438> ffmpeg 03Michael Niedermayer 07master:5d0139d5f0aa: avcodec/ffv1: Simplify fold() [17:18:35 CET] <cone-438> ffmpeg 03Michael Niedermayer 07master:a53c4f368999: avcodec/ffv1: Simplify update_vlc_state() [18:03:25 CET] <cone-438> ffmpeg 03Michael Niedermayer 07master:497c9b0cce55: avformat/rtsp: Check number of streams in sdp_parse_line() [20:17:33 CET] <cone-438> ffmpeg 03Carl Eugen Hoyos 07master:608572ce847a: tests/checkasm/checkasm: Do not define an unused function. [20:18:34 CET] <llogan> michaelni: IIRC, i noticed that replying with "applied", then patchwork changes patch state to accepted, but not when replying with "pushed". does it use keywords or something to set the state? [20:19:43 CET] <llogan> or maybe I'm not remembering anything correctly [20:23:19 CET] <cone-438> ffmpeg 03Magnus Röös 07master:833fed525361: libavcodec: vp8 neon optimizations for aarch64 [20:33:38 CET] <cone-438> ffmpeg 03Justin Bull 07master:22fc9cdd7e2e: INSTALL.md: Fix Markdown formatting [20:36:41 CET] <llogan> nevermind. guess I was wrong about patchwork. result of being too lazy to actually look. [20:37:04 CET] <michaelni> llogan, theres some magic [20:38:09 CET] <michaelni> llogan, theres a cronjob which checks git and if it detects a patch applied it updates patchwork theres also some keyword recognization of things like LGTM and such to set the matching tags [20:39:44 CET] <michaelni> also theres another script i wrote which i did run manually but i forgot for a while, i think we didnt automate this yet so i need to check what that would update [20:50:40 CET] <kierank> atomnuker: will you be at fosdem [21:05:38 CET] <atomnuker> nope, not this time [21:43:09 CET] <michaelni> llogan, heres what my script would change (the pwclient commands) https://pastebin.com/ckH6Jx7K <-- do you want to check before i execute them ? [21:46:28 CET] <llogan> michaelni: what does DUP mean? [21:46:57 CET] <michaelni> duplicate [21:47:59 CET] <michaelni> as in someone sends a newer patch superseeding a previous one [21:52:26 CET] <llogan> michaelni: i'll take a look in an hour or so [21:53:24 CET] <michaelni> sure, and thanks, normally i checked it before i applied the changes but this time as i forgot running it for so long it seems to have become really alot ... [22:07:41 CET] <michaelni> script btw is here if anyone wants to look, improve, use or anything else: https://github.com/michaelni/patchwork-update-bot [22:37:20 CET] <cone-438> ffmpeg 03Carl Eugen Hoyos 07master:ed20fbcd48b0: lavc/aarch64/vp8dsp: Fix the include guard. [00:00:00 CET] --- Fri Feb 1 2019

1 0

ffmpeg.log.20190131
by burek 01 Feb '19

01 Feb '19

[00:02:06 CET] <mfwitten> mfolivas: I suspect that using a single pass or 2 pass will be better for you: https://trac.ffmpeg.org/wiki/Encode/H.264#twopass [00:04:46 CET] <mfolivas> mfwitten: yes, we'll never scale up, we'll either keep in the same scale or lower [00:04:49 CET] <mfolivas> I guess . that's ok [00:05:22 CET] <mfolivas> I was thinking in testing with different encoders [00:05:27 CET] <mfolivas> see if that helps [00:05:44 CET] <mfwitten> mfolivas: Well, hardware accleration would probably make a big difference in the time it takes [00:05:57 CET] <mfolivas> mfwitten: yes, all options are on the table [00:06:21 CET] <mfolivas> and so far, the lowest-hanging fruit will be adding vertically scaling - more CPU [00:07:06 CET] <mfwitten> mfolivas: Maybe. If you've got GPUs in your machines, make sure ffmpeg is built to use them. [00:08:32 CET] <mfolivas> JEEB: not sure how I could find the bottleneck [00:08:49 CET] <mfolivas> I understand that I could use something like this: `ffmpeg -i INPUT -f null -` [00:09:05 CET] <mfolivas> I have this right now: ffmpeg -i two-minute-video.mp4 -vf scale=1920:1080 -profile:v baseline -level 4.1 -crf 17 -preset fast -bf 0 scaled-some-random-video.mp4 [00:09:22 CET] <mfolivas> and that gives me real 4m18.763s - real time [00:09:50 CET] <mfolivas> can I get a breakdown on what is taking longer somehow? [00:17:08 CET] <mfolivas> mfwitten: how would I know which encoder am I using for my tests? [00:17:17 CET] <mfolivas> would that be in the metadata? [00:17:51 CET] <mfolivas> Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 3840x2160, 59879 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default) [00:18:05 CET] <mfolivas> would that mean that I'm using the libx264? [00:18:58 CET] <ocrete> would there be any appetite to implement support to keep closed caption around when encoding/transcoding inside ffmpeg ? [00:21:53 CET] <mfwitten> mfolivas: Specify it directly in your command line: -c:v libx264 [00:22:11 CET] <mfwitten> mfolivas: You can see it in the "metadata" too: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) [00:24:06 CET] <Hello71> ocrete: -c:s copy [00:24:27 CET] <ossifrage> Does anyone know of a minimal C library that can decode iframe only h.264? I could use ffmpeg, but I was hoping for something with a smaller footprint [00:25:05 CET] <ocrete> Hello71: it's not a seprate stream, they're generally SEIs inside the h.264/h.265 stream ... or in the case I'm looking at, would have to be extracted from the Ancilliary data given by a decklink card and then encoded into a SEI [00:25:43 CET] <ocrete> there is code to parse them out of a h264/h265 steam, but I don't see much else [00:28:23 CET] <mfwitten> ossifrage: If you're familiar with C, maybe you could just rip out of ffmpeg the code paths you need. [00:29:39 CET] <BtbN> build ffmpeg with nothing but ffh264 [00:30:19 CET] <ossifrage> BtbN, that was my next step, turn off as much as possible and see how big it is [00:30:35 CET] <BtbN> There is a switch called literally --disable-everything [00:31:32 CET] <ossifrage> I remember seeing a fairly clean still decoder that would do what I want, but my googlefoo is letting me down [00:33:03 CET] <ossifrage> It was something that predated the BPG stuff [00:34:49 CET] <mfolivas> mfwitten: Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 3840x2160, 59879 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default) [00:35:02 CET] <mfolivas> does that means that the encoder is a h264? [00:36:06 CET] <ossifrage> mfolivas, high profile h.264 [00:36:39 CET] <mfwitten> mfolivas: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) [00:36:42 CET] <mfwitten> mfolivas: Look for that [00:37:09 CET] <mfwitten> mfolivas: Something like that [00:37:39 CET] <mfolivas> ah ok... [00:37:50 CET] <mfolivas> `Stream mapping: ` [00:37:57 CET] <mfolivas> ` Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))` [00:38:38 CET] <mfwitten> mfolivas: Specify it directly in your command line: -c:v libx264 [00:38:42 CET] <mfwitten> mfolivas: or some other encoder [00:39:35 CET] <mfwitten> mfolivas: `-c:v h264_nvenc' for example, if you've got the hardware support [01:10:49 CET] <mfolivas> mfwitten: want to try the QuickSync [01:11:25 CET] <mfolivas> any tips/thoughts if it will make any difference in my performance? [01:11:51 CET] <mfwitten> mfolivas: Unfortunately, I don't. [01:12:00 CET] <mfolivas> thanks! [01:12:20 CET] <mfwitten> mfolivas: Glad to help [01:13:14 CET] <mfwitten> mfolivas: With GPU support, you'd be able to encode more videos simultaneously; you could do some with GPUs and some with CPU [01:13:26 CET] <mfwitten> mfolivas: Maybe [01:13:30 CET] <mfolivas> I could, and we're thinking about that [01:13:44 CET] <mfolivas> but, I'm afraid that there will be some changes in the code as well [01:15:02 CET] <mfwitten> mfolivas: Yeah. It kind of makes you want to throw the computers out of the airplanes, eh? [01:15:11 CET] <mfolivas> LOL!! [01:15:17 CET] <mfolivas> yes [02:18:27 CET] <mfolivas> trying to use QuickSync but got an error [02:18:42 CET] <mfolivas> I have only installed the ffmpeg [02:18:53 CET] <mfolivas> when trying to do this: [02:18:54 CET] <mfolivas> ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -vf hwdownload,format=nv12 -pix_fmt yuv420p -f sdl - [02:19:06 CET] <mfolivas> I get: `Unknown decoder 'h264_qsv'` [02:21:39 CET] <DHE> that's a decoder position, not an encoder position... [02:21:48 CET] <DHE> also did you check wit "ffmpeg -encoders" to make sure a qsv option is available? [02:26:28 CET] <mfolivas> DHE: thanks, will check [02:29:20 CET] <mfolivas> DHE: doesn't seem like it [02:31:30 CET] <mfolivas> does that means that I need to do this? https://trac.ffmpeg.org/wiki/Hardware/QuickSync#InstallingtheMediaSDKonLinux [03:56:19 CET] <mfolivas> how can I find the type of decoder/encoder that I use by default using ffmpeg? [03:56:37 CET] <mfolivas> I was under the misconception that h264 and libx264 meant the same thing [06:09:15 CET] <pink_mist> libx264 is an encoder, not a decoder [06:09:24 CET] <pink_mist> for h264 the decoder is part of ffmpeg [06:42:34 CET] <mfolivas> thanks pink_mist [13:48:12 CET] <mfolivas> trying to do some test with h264_vaapi: ffmpeg -vaapi_device /dev/dri/renderD128 -i two-minute-video.mp4 -vf 'format=nv12,hwupload' -c:v h264_vaapi vvapi_two-minute-video.mp4 [13:48:27 CET] <mfolivas> so far, none of the videos that I've tried is working/showing. [16:44:53 CET] <mfolivas> doing some search regarding VAAPI but I don't see any video [16:45:15 CET] <mfolivas> I'm getting a 4K video and then tried to do a simple encoding [16:45:17 CET] <mfolivas> ffmpeg -vaapi_device /dev/dri/renderD128 -i two-minute-video.mp4 -vf 'format=nv12,hwupload' -c:v h264_vaapi vvapi_two-minute-video.mp4 [16:45:54 CET] <mfolivas> but as I mentioned before, I cannot see the video [16:50:03 CET] <mfolivas> also, has anyone done some test with qsv? [16:50:13 CET] <mfolivas> I haven't been able to install it. [16:50:26 CET] <mfolivas> I'm running Linux Debian [16:52:44 CET] <mfolivas> oh, shoot, is it because I'm running Intel? The Mesa VAAPI driver uses the UVD (Unified Video Decoder) and VCE (Video Coding Engine) hardware found in all recent AMD graphics cards and APUs. [16:54:05 CET] <mfolivas> >initially developed by Intel but can be used in combination with other devices. [17:10:58 CET] <jkqxz> mfolivas: What hardware do you have, and what error are you getting? [17:11:25 CET] <mfolivas> I have NUC and running an Intel chip [17:11:54 CET] <mfolivas> jkqxz Intel® NUC Mini PCs. [17:12:24 CET] <mfolivas> I just want to get some different encodes running [17:12:43 CET] <mfolivas> I just having a hard time installint QuickSync or use VAAPI to access it [17:13:05 CET] <BtbN> You do not want to be using QSV on Linux, really [17:13:12 CET] <jkqxz> What error did you get when you ran the command above? [17:13:24 CET] <BtbN> VAAPI is almost always the better choice [17:15:12 CET] <mfolivas> jkqxz command above? You mean this: ```ffmpeg -vaapi_device /dev/dri/renderD128 -i two-minute-video.mp4 -vf 'format=nv12,hwupload' -c:v h264_vaapi vvapi_two-minute-video.mp4``` [17:15:18 CET] <mfolivas> if so, there were no errors [17:15:33 CET] <mfolivas> but I don't think this is for Intel (which is what I am running) [17:16:56 CET] <jkqxz> That should work. What's wrong with the output, then? [17:17:07 CET] <mfolivas> the video doesn't show [17:17:17 CET] <mfolivas> it's just black with audio [17:18:44 CET] <jkqxz> Did you install from the default Debian package? Encode support uses proprietary blobs on recent chips, and the default package doesn't include those so it doesn't work. [17:19:04 CET] <jkqxz> There is a separate package in non-free containing those blobs. [17:19:13 CET] <mfolivas> I did the following: [17:19:17 CET] <mfolivas> apt-get install -y vainfo i965-va-driver vainfo [17:19:21 CET] <mfolivas> then reboot [17:20:13 CET] <jkqxz> Then you probably lack the proprietary encode blobs. Install i965-va-driver-shaders as well. [17:21:31 CET] <mfolivas> jkqxz ok, let me try that! [17:21:38 CET] <mfwitten> mfolivas: I wonder whether `dmesg --follow' will show you messages from the kernel if the kernel driver is upset about something. [17:22:16 CET] <mfolivas> yeah, I follow this pdf from the Intell's media server [17:22:28 CET] <mfolivas> and it deleted something [17:22:36 CET] <mfolivas> now I get this error: ffmpeg: error while loading shared libraries: libva.so.1: cannot open shared object file: No such file or directory [17:42:14 CET] <ecrist> Hey folks. I've run into this issue where a single ffmpeg instance to an rtp stream results in all other instances to be just that one stream [17:42:48 CET] <ecrist> anyone else see that? [19:25:08 CET] <mfolivas> jkqxz sorry, had to rebuild the server. That i965-va-driver-shaders doesn't exists [19:25:23 CET] <mfolivas> i did an `apt-cache search i965-va-driver-shaders` nothing came back [19:26:16 CET] <mfolivas> I'm just not sure how I can get access to either the VAAPI to access quicksync [20:24:59 CET] <mfolivas> hmm... [20:25:10 CET] <mfolivas> so, I think i have the vaapi installed [20:25:23 CET] <mfolivas> I am using it an intel server [20:25:46 CET] <mfolivas> however, this `ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128` game me this error: [20:25:51 CET] <mfolivas> Unrecognized option 'init_hw_device'. [20:28:13 CET] <DHE> you need to specify an input or output "file" [20:43:48 CET] <mfwitten> I'm trying to use `amix' to mix 2 audio streams together into 1; I've tried to offset one of the audio streams relative to the other by using `asetpts' on it, but amix seems to completely ignore PTS (i.e., `asetpts' does nothing. Ever.). Am I using PTS incorrectly for this purpose? [20:47:23 CET] <BtbN> I don't think it particularily cares about input pts [20:47:45 CET] <BtbN> try adelay [20:48:33 CET] <mfwitten> BtbN: Yes, adelay works. However, `asetpts' still seems like a much more philosophically correct way to think about it. [20:49:02 CET] <mfwitten> BtbN: For one thing, adelay is a channel-based; I had to go look to see whether this audio is stereo or mono [21:10:40 CET] <mfolivas> can someone explain me the when to use format=nv12 vs format=nv12,hwupload on VAAPI? [00:00:00 CET] --- Fri Feb 1 2019

1 0