Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2017

1 participants
62 discussions

ffmpeg-devel.log.20170430
by burek 01 May '17

01 May '17

[01:06:53 CEST] <cone-985> ffmpeg 03Muhammad Faiz 07master:d535e0c14004: avcodec/pthread_frame, decode: allow errors to happen on draining [13:01:27 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:8dd3a53dbf7d: avfilter/af_crystalizer: add support for more sample formats [14:25:53 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:7796f2906533: libswscale/tests/swscale: Fix uninitialized variables [14:25:54 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:a9b5b6a97f4f: tools: Eliminate codec_type complexity from fuzzer [15:20:32 CEST] <durandal_1707> i found brutefir, where i could find coeffs stuff for it? [15:21:09 CEST] <durandal_1707> going back to implementing generic fir convolver filter in lavfi [15:21:42 CEST] <durandal_1707> anybody knows something about this topic? [15:26:00 CEST] <cone-556> ffmpeg 03Anton Khirnov 07master:c2fa6bb0e870: mpeg12dec: move setting first_field to mpeg_field_start() [15:26:01 CEST] <cone-556> ffmpeg 03James Almer 07master:d61f93bf04eb: Merge commit 'c2fa6bb0e8703a7a6aa10e11f9ab36094416d83f' [17:37:52 CEST] <jamrial> nevcairiel: there, decoupled hevc sei [17:40:24 CEST] <nevcairiel> not as terrible as it initially seemed? [17:40:40 CEST] <jamrial> yeah, it was fairly trivial [18:04:29 CEST] <durandal_1707> nobody? [18:14:37 CEST] <Compn> durandal_1707 ? [18:14:47 CEST] <Compn> [09:20] <durandal_1707> i found brutefir, where i could find coeffs stuff for it? [18:14:47 CEST] <Compn> [09:21] <durandal_1707> going back to implementing generic fir convolver filter in lavfi [18:14:47 CEST] <Compn> [09:22] <durandal_1707> anybody knows something about this topic? [18:15:02 CEST] <Compn> have to ask filter people [18:15:04 CEST] <Compn> ubitux maybe? [18:15:20 CEST] <Compn> probably everyone taking the weekend off, durandal_1707 :D [18:16:04 CEST] <wm4> normal people don't work on weekends [18:17:51 CEST] <j-b> except when it rains [18:18:38 CEST] <jkqxz> Normal people don't work on ffmpeg, either. [18:19:02 CEST] <alevinsn> what's normal? [18:19:20 CEST] <j-b> what's work? [18:19:26 CEST] <alevinsn> jamrial: you there? [18:25:16 CEST] <jamrial> yes [18:27:24 CEST] <alevinsn> jamrial: I haven't gotten through all the e-mails, so I'm not sure if you've submitted those two patches [18:27:32 CEST] <alevinsn> but, I seem to recall that the reason you submitted them in the first place [18:27:42 CEST] <alevinsn> was you investigated the crash my memory leak "fix" addressed [18:28:02 CEST] <alevinsn> and you noticed that in order to fix the crash, it was necessary to copy the coded_side_data [18:28:24 CEST] <alevinsn> by eliminating that from the patch, why bother with doing anything? [18:28:48 CEST] <alevinsn> the function is deprecated [18:29:16 CEST] <alevinsn> I meant, I'm not sure if you've committed those two patches [18:29:21 CEST] <jamrial> the patchset i sent prevents your patch from crashing, even if it doesn't copy coded_side_data anymore [18:29:26 CEST] <jamrial> i have not [18:31:05 CEST] <alevinsn> because it zeroes out coded_side_data and nb_coded_side_data after doing the memcpy()? [18:33:58 CEST] <alevinsn> yes, I think that's the reason [18:34:39 CEST] <alevinsn> jamrial: the behavior now is technically different though, and even though avcodec_copy_context() is deprecated, if any code was dependent on [18:34:59 CEST] <alevinsn> coded_side_data being valid if it was set in the context in which it was copied from [18:35:02 CEST] <alevinsn> that won't work anymore [18:35:24 CEST] <alevinsn> the original code was wrong, since both AVCodecContext object's referred to the same coded side data [18:35:35 CEST] <jamrial> exaclty, it didn't work before either. it was copying the pointer but not the buffer [18:35:42 CEST] <alevinsn> true [18:35:50 CEST] <alevinsn> but, perhaps because of the way the memory way freed [18:35:51 CEST] <jamrial> what i did was do a proper clean up. i'm not going to make it copy anything else [18:35:56 CEST] <alevinsn> it didn't cause a crash [18:36:12 CEST] <alevinsn> and both objects "owned" the same coded side data before, which was wrong [18:36:29 CEST] <alevinsn> but, perhaps there is some code that works on the copied context that expects coded side data to be valid [18:36:33 CEST] <alevinsn> and that won't work anymore [18:36:55 CEST] <alevinsn> I guess it depends on how ffmpeg.c uses that new context [18:38:16 CEST] <alevinsn> there are multiple places that use avcodec_copy_context() unfortunately it seems [18:41:57 CEST] <wm4> probably better to try to remove those uses, and putting effort into making avcodec_copy_context() do whatever [18:44:53 CEST] <alevinsn> this whole coded_side_data stuff seems to be solely used by ffmpeg.c [18:44:58 CEST] <alevinsn> I don't see any uses of it other than there [18:45:09 CEST] <alevinsn> I'm not sure if it is even used in practice [18:45:49 CEST] <alevinsn> I mean, there is code to populate it [18:46:01 CEST] <alevinsn> but nothing that I've found that actually uses it [18:47:38 CEST] <wm4> ffmpeg.c is just 1 API user [18:47:43 CEST] <wm4> out of maybe... hundreds? [18:48:29 CEST] <alevinsn> the way it is used seems to be via ff_add_cpb_side_data() [18:48:33 CEST] <alevinsn> and the return value of that function [18:52:19 CEST] <alevinsn> it seems that it is a little odd the way it is used [18:52:40 CEST] <alevinsn> as far as I can tell, ffmpeg.c copies the coded side data into the stream [18:52:57 CEST] <alevinsn> and then it is used via the stream with av_stream_get_side_data() [18:53:09 CEST] <alevinsn> other than originally being populated by codecs [18:53:26 CEST] <alevinsn> in the AVCodecContext, I don't think it is ever used, at least in the ffmpeg code base [18:53:56 CEST] <alevinsn> and, I wouldn't be surprised if it is was added for this purpose and this purpose alone [18:53:59 CEST] <alevinsn> to be copied into the stream [18:54:03 CEST] <alevinsn> by ffmpeg.c [18:54:36 CEST] <wm4> not sure [18:55:23 CEST] <wm4> one thing is clear though: libavformat is not supposed to access the AVStream.codec ctx [18:56:58 CEST] <alevinsn> yes, but, the whole process of copying the coded_side_data into side data for a stream [18:57:11 CEST] <alevinsn> is a bit kludgy [18:57:16 CEST] <alevinsn> it seems to me [18:58:08 CEST] <wm4> yes [19:00:21 CEST] <jamrial> both ff_add_cpb_side_data() and coded_side_data came from libav [19:00:38 CEST] <jamrial> so they are unrelated to our temporary dependency on AVStream.codec [19:09:10 CEST] <alevinsn> jamrial: just sent e-mail to the list regarding those two patches--I think they are good for check-in [19:21:29 CEST] <alevinsn> I was revisiting a patch that switched from using strncpy() to av_strlcpy() today [19:21:44 CEST] <alevinsn> and I examined the implementation of av_strlcpy() [19:21:46 CEST] <alevinsn> here it is: [19:21:47 CEST] <alevinsn> size_t av_strlcpy(char *dst, const char *src, size_t size) [19:21:47 CEST] <alevinsn> { [19:21:47 CEST] <alevinsn> size_t len = 0; [19:21:47 CEST] <alevinsn> while (++len < size && *src) [19:21:47 CEST] <alevinsn> *dst++ = *src++; [19:21:49 CEST] <alevinsn> if (len <= size) [19:21:51 CEST] <alevinsn> *dst = 0; [19:21:53 CEST] <alevinsn> return len + strlen(src) - 1; [19:21:55 CEST] <alevinsn> } [19:21:57 CEST] <alevinsn> Am I missing something here, or is the check [19:22:04 CEST] <alevinsn> if (len <= size) [19:22:08 CEST] <alevinsn> unnecessary? [19:22:25 CEST] <alevinsn> I would think because of the way the while() loop is structured [19:22:35 CEST] <alevinsn> than len will always be less than or equal to size by the time it gets there [19:23:09 CEST] <alevinsn> and, if somehow it is not, then we have a problem, since the copied string may not be null-termianted [19:23:11 CEST] <alevinsn> terminated [19:24:59 CEST] <nevcairiel> the loop doesnt copy null termination, so instead its added there explicitly [19:26:21 CEST] <alevinsn> i understand that [19:26:38 CEST] <alevinsn> but, the if check seems to be unnecessary [19:26:48 CEST] <nevcairiel> if you remove it, shit breaks [19:26:57 CEST] <nevcairiel> since null termination would be missing [19:27:00 CEST] <alevinsn> I'm not saying remove the null character set [19:27:03 CEST] <alevinsn> I'm saying, do this [19:27:50 CEST] <alevinsn> size_t av_strlcpy(char *dst, const char *src, size_t size) [19:27:50 CEST] <alevinsn> { [19:27:50 CEST] <alevinsn> size_t len = 0; [19:27:50 CEST] <alevinsn> while (++len < size && *src) [19:27:50 CEST] <alevinsn> *dst++ = *src++; [19:27:51 CEST] <alevinsn> *dst = 0; [19:27:53 CEST] <alevinsn> return len + strlen(src) - 1; [19:27:55 CEST] <alevinsn> } [19:31:33 CEST] <nevcairiel> calling it with size = 0 is valid and it should not modify the buffer then [19:31:34 CEST] <jkqxz> It shouldn't write anything if size is zero. [19:31:38 CEST] <jkqxz> That. [19:32:06 CEST] <jkqxz> It might be clearer if that was a shortcut at the beginning, though. [19:33:02 CEST] <nevcairiel> the implementation is likely taken from somewhere else, its specifically documented to be equivalent to BSD strlcpy [19:39:45 CEST] <alevinsn> if size is 0 [19:40:00 CEST] <alevinsn> yeah, it will work properly because it always does ++len [19:44:07 CEST] <alevinsn> jkqxz: I was at NAB show last week, and I spoke with Mark Buxton, who is the head of the group that works on the Intel Media SDK [19:44:20 CEST] <alevinsn> he told me that someone on his team maintains an ffmpeg git tree [19:44:26 CEST] <alevinsn> that has QSV improvements [19:44:38 CEST] <alevinsn> I asked him why these changes aren't being contributed to ffmpeg proper [19:44:50 CEST] <alevinsn> and he said because it takes too long for patches to make it in [19:44:53 CEST] <nevcairiel> i dont think we have ever gotten one direct submission for qsv from intel [19:45:00 CEST] <nevcairiel> so doubtful they have any data [19:45:12 CEST] <nevcairiel> they employed some other company once to work on the qsv code [19:45:15 CEST] <nevcairiel> but they really made it worse [19:45:33 CEST] <alevinsn> hmm, the name of the person he mentioned is someone who works for Intel [19:45:37 CEST] <alevinsn> I'm pretty sure [19:45:54 CEST] <alevinsn> but, I haven't seen the git repository yet [19:46:18 CEST] <nevcairiel> if a developer is reponsive to feedback he gets, it usually doesnt take long to get something in [19:46:24 CEST] <nevcairiel> if they send a patch once and expect it to land [19:46:26 CEST] <nevcairiel> well yeah [19:46:34 CEST] <nevcairiel> corporate culture often conflicts with oss development [19:47:11 CEST] <alevinsn> possible, although Intel, at least with certain projects, has a good track record with OSS [19:47:56 CEST] <alevinsn> I'll see if I can track down the git repository and the person at Intel [19:50:53 CEST] <wm4> nevcairiel: was the libyami stuff from intel devs? [19:51:30 CEST] <nevcairiel> maybe [19:51:39 CEST] <nevcairiel> but yet another wrapper is not an improvement to qsv code =p [19:51:58 CEST] <jkqxz> Patches for qsv in ffmpeg tend to be from random companies using it commercially for specific things. That tends not to be very useful, because they are attached to their use-case and don't want to do any work for anything else around it. [19:53:42 CEST] <jkqxz> Intel hasn't done anything directly for a while, as far as I know. Maxym Dmytrychenko has sent some stuff in the past from an Intel address, but hasn't been active recently. [19:53:53 CEST] <jkqxz> libyami came directly from Intel, yes. [19:55:08 CEST] <alevinsn> I have the name of the person at Intel at home that supposedly maintains the ffmpeg fork with "better" QSV code [19:55:20 CEST] <alevinsn> I'll check that out later [19:55:52 CEST] <nevcairiel> if they provide binaries they also have to provide sources [19:56:36 CEST] <alevinsn> "provide binaries"--what do you mean? there would be no point to providing ffmpeg.exe, or something like that [19:56:55 CEST] <nevcairiel> well what do they maintain a ffmpeg fork if they dont publish it in some form somewhere [19:57:14 CEST] <alevinsn> supposedly it is published somewhere [19:57:23 CEST] <alevinsn> but I did a basic search just now and can't find it [19:58:06 CEST] <alevinsn> at least, that's what Mark Buxton (the directory of Media Development Products at Intel) told me [19:58:28 CEST] <alevinsn> but, I guess he could be mistaken, although he's pretty sharp [19:58:44 CEST] <jkqxz> Would be interesting to see that - cleaner qsvenc support would be good for everyone. [19:59:59 CEST] <alevinsn> jkqxz: You suggested that I post the QSV patch to libav just because that there would be more people with QSV experience that would see it, right? [20:00:26 CEST] <jkqxz> Yes. Did you look at the merge I posted two (?) days ago? I'll push that if you're happy with it. [20:00:29 CEST] <wm4> jkqxz: would you really expect it to become "cleaner" [20:00:55 CEST] <jkqxz> wm4: Query things properly so you don't have the ridiculous catch all "bad rate control parameters" error. [20:01:06 CEST] <alevinsn> wm4: I used to work for Intel :-) . It depends on the developer [20:01:08 CEST] <jkqxz> That would be cleaner. [20:01:38 CEST] <ubitux> jamrial: are you looking at dropping the hevc decoder dependency from the parser? [20:01:50 CEST] <nevcairiel> proper runtime feature selection would be nice [20:01:57 CEST] <wm4> the problem with these things is really that ffmpeg develoipers don't know enough about qsv, and intel developers don't know enough about ffmpeg [20:02:03 CEST] <nevcairiel> instead of kinda hoping it matches whatever hardware we made it for [20:02:05 CEST] <jamrial> ubitux: i tried that, yes, but fate-hevc-bsf-mp4toannexb "fails" [20:02:07 CEST] <wm4> and the result is a misery of bad hacks [20:02:17 CEST] <alevinsn> Intel has a paper that talks about using QSV and ffmpeg [20:02:18 CEST] <jamrial> which is to say, the output is different, and seemingly worse [20:02:26 CEST] <alevinsn> although, that doesn't mean they know the codebase [20:02:41 CEST] <jkqxz> If it's adding terrible hacks to optimise some particular qsvdec->qsvenc case then that would be less interesting. [20:02:53 CEST] <alevinsn> actually, a few papers [20:03:12 CEST] <jkqxz> (qsvdec is dead. Long live dxva2/d3d11va/vaapi.) [20:03:55 CEST] <ubitux> jamrial: if you succeed, it will mean one less entry in doc/libav-merge.txt ;) [20:04:03 CEST] <jamrial> whatever happened with that huge d3d11 patchset by Steve Lhomme? [20:04:19 CEST] <wm4> jamrial: I picked it up, mangled it through a meat grinder, and recently reposted it [20:04:20 CEST] <jkqxz> wm4 has adopted it, kindof. [20:04:21 CEST] <alevinsn> jkqxz: Perhaps the only real issue I have with the ffmpeg patches is the log messages--my original log messages [20:04:25 CEST] <jamrial> wm4: ah cool [20:04:31 CEST] <alevinsn> made it clear that I was pretty much restoring the code back to how it used to work [20:04:32 CEST] <alevinsn> for ffmpeg [20:04:35 CEST] <wm4> (libav-devel only) [20:04:44 CEST] <alevinsn> although, I made a few changes on top of that, but it was mostly restoring things [20:05:33 CEST] <alevinsn> Luca rewrote my log messages [20:06:30 CEST] <jamrial> ubitux: i sent a patchset some time ago to remove the api breaking behavior from our aac_adtstoasc bsf implementation that will get rid of another libav-merge.txt line, for that matter [20:06:36 CEST] <jamrial> hopefully we can remove lines faster than we add them :p [20:06:41 CEST] <alevinsn> jkqxz: but the patches are good otherwise [20:07:07 CEST] <ubitux> jamrial: we have to keep up with the 400+ commits to merge too :( [20:07:37 CEST] <jkqxz> alevinsn: Right, yeah. Do you want to write something for ffmpeg to match the patches as they are now, or shall I have a go? [20:08:00 CEST] <alevinsn> jkqxz: Based on what Michael wrote about merges last week [20:08:16 CEST] <alevinsn> it seems that he prefers it if developers submit new patches to ffmpeg for review [20:08:26 CEST] <alevinsn> rather than it being "merged" in [20:08:32 CEST] <alevinsn> so, perhaps I ought to do that [20:09:40 CEST] <jkqxz> Sure. If you want to send it to the ML then I can commit it from there. (Not like anyone else is ever going to say anything about it on ffmpeg-devel, which was why I suggest libav instead.) [20:09:40 CEST] <alevinsn> since you've already reviewed the changes, it should be a simple matter to commit them as patches instead of merges [20:10:15 CEST] <alevinsn> but, there does see to be a preference, at least from Michael, to commit as regular patches rather than merges [20:10:23 CEST] <jkqxz> To clarify, I believe that merge comment was really about developers merging changes to things that they are not responsible for. [20:10:24 CEST] <alevinsn> if the developer is so inclined to submit to both MLs [20:10:44 CEST] <alevinsn> oh [20:10:52 CEST] <jkqxz> Oh, maybe that wasn't quite the same thing. [20:11:05 CEST] <alevinsn> it seemed fairly general what Michael was talking about [21:35:40 CEST] <jamrial> ubitux: guess what :D [23:19:37 CEST] <jamrial> ubitux, nevcairiel: if you could spare a review or two, that'd be great :p [00:00:00 CEST] --- Mon May 1 2017

1 0

ffmpeg.log.20170430
by burek 01 May '17

01 May '17

[00:44:30 CEST] <mosb3rgler> hey guys, im trying to see if its possible to connect to a HLS Master Playlist, and grab the entire set of pids in 1 go. and reproduce them to another system to maintain the HLS ABR style playlist + mapping to some degree? [00:45:13 CEST] <mosb3rgler> i realize i can choose the feeds i want to include and so on.. but is it possible to do multiple videos and such the way im saying. keeping B frames intact so it will correctly switch between bitrates [03:02:35 CEST] <LoopHoldYoaBrown> Hello, is scc muxer working with Quicktime mov? [06:03:01 CEST] <zap0> when i do ffmpeg -i file.mp4 is there another option to get similar to the ffprobe -print_format flat ? [06:03:09 CEST] <zap0> no, i don't want to just use ffprobe. [06:06:13 CEST] <furq> -print_format doesn't do anything on its own [06:14:00 CEST] <zap0> i know, that's not my question. [06:14:47 CEST] <furq> well that code is all specific to ffprobe.c so i suspect the answer is no [06:26:55 CEST] <zap0> ok. next question: with ffprobe flat.. you see things like: streams.stream.0.width=480 and streams.stream.0.duration="10.000000" see how teh 2nd one is in quotes? is there any reasoning about when quotes are used? [11:34:01 CEST] <schelleursli> hi there, quick question, is it possible to change the cache value for http input streams? I seem to run out of buffer on my local network streams and can't find anything regarding cache on the ffmpeg manual [11:34:40 CEST] <schelleursli> funny thing is if I do the same ffmpeg commandline but pipe it via vlc first and then input it things work just fine [14:56:44 CEST] <xeche> at which point when opening a file for decoding is possible to know the pixel format of a decoded image? [14:56:59 CEST] <xeche> do you actually have to decode a frame before you can get that information? [14:57:56 CEST] <atomnuker> yes [14:58:05 CEST] <xeche> *sigh [14:58:08 CEST] <xeche> okay thanks man [14:58:14 CEST] <atomnuker> since pixel format and image size can change in between frames [14:58:23 CEST] <xeche> i was afraid that were the case [14:59:07 CEST] <atomnuker> if you control everything you can guarantee it, but if its some unknown mpegts stream anything can change [14:59:56 CEST] <xeche> dealing with multiple files, i'm guessing i shouldn't make that assumptions, as I didn't generate the files [15:00:59 CEST] <xeche> so, what's a good way to set up an sws_context then. should you really call sws_getCachedContext every time you work with a decoded frame? depending on how fast that cache look up is, that seems like it would be slow. but maybe it's negligeble [15:02:12 CEST] <atomnuker> I'd keep a state and reinit if pix_fmt/witdth/height change [15:02:41 CEST] <atomnuker> but sws_getCachedContext seems to already do that for you [15:03:55 CEST] <atomnuker> yeah, just call sws_getCachedContext on every frame, it'll be fine [15:03:56 CEST] <xeche> atomnuker: it does, except for filter settings [15:04:08 CEST] <xeche> i guess so. thanks again [15:23:32 CEST] <xeche> how on earth can av_frame_get_buffers return a single buffer of size 6266911 [15:23:54 CEST] <xeche> for 1920x1080 AV_PIX_FMT_RGB24 buffer? [15:24:01 CEST] <xeche> the single part is fine [15:24:12 CEST] <xeche> but an odd number of bytes? what the fuck? [15:31:35 CEST] <xeche> i guess the buffer sizes are work space, and the data[] array is what i actually want. [16:13:52 CEST] <faLUCE> xeche: you have to use data[] array [20:45:13 CEST] <chatter29> hey guys [20:45:16 CEST] <chatter29> allah is doing [20:45:20 CEST] <chatter29> sun is not doing allah is doing [20:45:23 CEST] <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger [21:35:11 CEST] <faLUCE> hello, I would like to make a http-mpegts-h264 player for chrome... what do you suggest to use? is there a way to integrate libav on chrome? [21:35:38 CEST] <sfan5> chrome already includes a video player? [21:35:53 CEST] <furq> yeah chrome already plays h264 [21:36:06 CEST] <furq> and there's already at least one bit of code which remuxes mpegts to fmp4 in javascript [21:36:23 CEST] <faLUCE> furq: sfan5, but what about http? [21:36:37 CEST] <furq> are you asking if chrome does http [21:36:42 CEST] <sfan5> i think he is [21:37:03 CEST] <BtbN> Just use hls.js? [21:37:13 CEST] <furq> yeah that's the javascript remuxer to which i refer [21:37:20 CEST] <BtbN> It plays HLS, like the name may suggest, which is mpegts [21:37:23 CEST] <furq> if you really don't want to use hls for some reason then you could probably adapt that [21:37:47 CEST] <BtbN> If you give it a HLS playlist with one huge chunk, it'll probably play it just fine [21:37:53 CEST] <faLUCE> I have to demux a HTTP-h264 stream, not a hls stream [21:38:09 CEST] <BtbN> what is a "HTTP-h264 stream"? [21:38:14 CEST] <BtbN> mpeg-ts over http? [21:38:18 CEST] <furq> yeah [21:38:18 CEST] <faLUCE> BtbN: yes [21:38:29 CEST] <BtbN> so, use hls.js then. Most likely the way easiest solution [21:38:58 CEST] <faLUCE> BtbN: do you mean that hls.js plays a generic http mpegts stream? [21:38:58 CEST] <furq> well hls.js expects a playlist, which i assume he doesn't have [21:39:05 CEST] <furq> so you'd probably need to adapt it [21:39:12 CEST] <BtbN> Just write a dummy one with just your one file [21:39:19 CEST] <furq> it's a live stream [21:39:24 CEST] <BtbN> shouldn't matter [21:39:26 CEST] <faLUCE> a playlist where? in the header? [21:39:44 CEST] <furq> you might be right actually [21:39:48 CEST] <BtbN> It expects a HLS playlist, so give it one, which just points to your stream [21:39:53 CEST] <furq> just serve an m3u8 that points to your sream [21:39:54 CEST] <furq> +t [21:40:25 CEST] <BtbN> I think m3u8 even has a defined mode for that special case [21:40:33 CEST] <BtbN> But too lazy to look up the spec [21:40:39 CEST] <furq> it's worth a try anyway [21:40:53 CEST] <faLUCE> but where has this playlist to be put? in the stream header? [21:41:22 CEST] <furq> well hls.js is javascript so you'd need to embed the video in a webpage [21:41:25 CEST] <BtbN> somewhere, it doesn't matter. [21:41:34 CEST] <furq> so just serve the playlist from the same httpd [21:41:48 CEST] <BtbN> can probably even generate it on the fly from JS [21:41:50 CEST] <furq> point a <video> tag to the m3u8 [21:41:50 CEST] <faLUCE> I don't understand exactly, but I want to try [21:44:07 CEST] <faLUCE> so, basically hls.js adds a demuxer to the browser native decoder? [21:44:22 CEST] <furq> it remuxes mpegts to fmp4 and then feeds that to the native player [21:44:23 CEST] <BtbN> hls.js is a mpegts to mp4 remuxer written in JavaScript [21:44:37 CEST] <faLUCE> I see, but I don't need do remux to mp4 [21:44:40 CEST] <BtbN> you do [21:44:43 CEST] <faLUCE> why? [21:44:43 CEST] <BtbN> browsers only play mp4 [21:44:45 CEST] <furq> ^ [21:44:46 CEST] <faLUCE> I see [21:44:57 CEST] <furq> it's an awful hack but it's the easiest way to do it [21:45:03 CEST] <faLUCE> I see [21:45:15 CEST] <faLUCE> what if I mux mp4? Is it possible for a live stream? [21:45:16 CEST] <furq> and it works in any browser on any platform [21:45:35 CEST] <BtbN> mp4 can't be easily live streamed. But if you generate a fragmented mp4 stream, it might work as well [21:45:36 CEST] <furq> fragmented mp4 should work [21:45:41 CEST] <furq> although i wouldn't bother [21:45:44 CEST] <BtbN> if you are not bound to mpeg-ts, I'd try that [21:45:56 CEST] <furq> i'd trust mpegts more for non-browser players [21:46:01 CEST] <faLUCE> I can try mp4 as well [21:46:02 CEST] <furq> and hls.js should works for browsers [21:46:06 CEST] <BtbN> should just be able to play a fragmented mp4 file from a <video> tag [21:46:07 CEST] <furq> but yeah either should be ok [21:46:19 CEST] <BtbN> But it will always play from the beginning, even if it's live [21:46:21 CEST] <faLUCE> but why browsers need mp4? I don't understand [21:46:30 CEST] <furq> because browsers suck [21:46:31 CEST] <BtbN> It's the only container they support [21:46:38 CEST] <furq> for h264, yeah [21:46:51 CEST] <BtbN> or rather, all of them support [21:46:56 CEST] <BtbN> some individual browsers support more [21:46:56 CEST] <furq> yeah [21:47:10 CEST] <faLUCE> [21:46] <BtbN> But it will always play from the beginning, even if it's live <--- I add a header as soon as the client makes the http request [21:47:19 CEST] <furq> annoyingly, mobile browsers have native mpegts [21:47:21 CEST] <BtbN> ...? [21:47:27 CEST] <BtbN> How would you do that? [21:47:39 CEST] <faLUCE> BtbN: I created a library [21:47:44 CEST] <BtbN> You have a plain single video file on the server [21:47:53 CEST] <BtbN> it'll serve it from the beginning [21:47:54 CEST] <faLUCE> BtbN: no, I made a live video library [21:48:07 CEST] <faLUCE> https://github.com/paolo-pr/laav [21:48:21 CEST] <faLUCE> it works for mpegts but I can adapt it to mp4 [21:48:57 CEST] <faLUCE> the http stream part of the code is made with libevent and handles multiple requests, by adding the container's header for each one [21:50:11 CEST] <faLUCE> I thought that mp4 was not good for live stream, then I did not use it [21:50:21 CEST] <BtbN> mp4 is horrible for live streaming [21:50:27 CEST] <BtbN> which is why HLS and DASH exist [21:50:46 CEST] <faLUCE> BtbN: but it's the only way to see a stream on the browser [21:50:53 CEST] <BtbN> exactly [21:51:00 CEST] <BtbN> so, browsers are bad for live streaming. [21:51:12 CEST] <BtbN> Can just use Flash and play an rtmp stream... [21:51:12 CEST] <faLUCE> I thought is could not be used at all (mp4) for live streams [21:51:18 CEST] <furq> it's ok i'm sure there's no demand for internet livestreaming these days [21:51:24 CEST] <BtbN> it can't. You cut it into a lot of short fragments [21:51:39 CEST] <BtbN> So each fragment can be played individually [21:52:12 CEST] <faLUCE> BtbN: do you mean that fragmented mp4 is somewhat a hack? [21:52:20 CEST] <BtbN> It's a horrible hack, yes. [21:52:34 CEST] <faLUCE> BtbN: then in this way I introduce latency [21:52:38 CEST] <furq> it's not so much a hack as a solution to a problem which shouldn't exist [21:52:48 CEST] <furq> we already have perfectly good streaming containers [21:53:01 CEST] <BtbN> If browsers would just support mpeg-ts or mkv natively, there wouldn't be an issue [21:53:07 CEST] <furq> this is just a way to backdoor a streamable container into the warring factions of browser makers [21:53:39 CEST] <BtbN> if you are Ok with only supporting MS Edge, that one does play mpegts just fine. [21:53:44 CEST] <furq> it has no other utility as far as i can tell [21:53:57 CEST] <faLUCE> let me think [21:54:00 CEST] <BtbN> Well, HLS/DASH also make things easier for CDNs [21:54:08 CEST] <james999> hey furq given i got streaming to work to my xbox over wifi with a special command line [21:54:16 CEST] <faLUCE> my goald is to create a low latency http-mpegts player [21:54:16 CEST] <james999> is there some way to submit a documentation update or patch for it?'' [21:54:32 CEST] <BtbN> low latency streaming to a browser is not going to happen [21:54:41 CEST] <faLUCE> BtbN: I see [21:54:42 CEST] <BtbN> there will always be 3 times the gop length of latency at minimum [21:54:53 CEST] <faLUCE> BtbN: then I have to switch to a standalone player [21:55:45 CEST] <BtbN> There are some sites utilizing WebRTC or something to have ultra-low-latency Remote-Desktops [21:55:53 CEST] <BtbN> But I have no idea how they manage to do that [21:57:27 CEST] <faLUCE> ok, now, if I want to make a SIMPLE http-mpegts player with libav, should I use libcurl for the http part? Or do I have to use libav for it as well? [21:57:40 CEST] <faLUCE> (if I want to control the latency) [21:57:55 CEST] <BtbN> what? [21:58:02 CEST] <BtbN> Just use mpv? [21:58:21 CEST] <faLUCE> BtbN: vlc, mpv and ffplay introduce a latency which I can't control [21:58:50 CEST] <faLUCE> better: I can't control it completely [21:59:05 CEST] <james999> faLUCE: ah low latency video streaming, exactly what I'm intersted in. :D [21:59:24 CEST] <faLUCE> james999: I can control completely the server part, in my library [22:00:03 CEST] <james999> my goals are much more modest than writing a library [22:00:12 CEST] <james999> i just want to stream youtube to my xbox one over wifi [22:00:21 CEST] <BtbN> Can't it play YouTube on its own? [22:00:26 CEST] <james999> finally figured it out, and wanted to ask furq if i could add it to the ffmpeg documentation somewhere [22:00:34 CEST] <james999> yeah but you can't select the quality [22:00:38 CEST] <james999> plus i can stream my desktop this way too [22:01:04 CEST] <james999> i ended up having to use a udp url which specified a max packet size [22:03:55 CEST] <BtbN> I wonder why nobody has come up with an easy way to Stream VP8 via srtp to browsers yet [22:04:01 CEST] <BtbN> That should work great [22:06:49 CEST] <james999> i'm trying to udp stream to the xbox with vlc udp legacy atm but it's not working [22:06:52 CEST] <james999> prob cuz of packet isze thing [22:18:16 CEST] <faLUCE> so, basically, I don't understand how to demux a http mpegts stream with libav: do I have to manage http with avio or with avformat? [22:18:39 CEST] <james999> well that was a complete failure [22:18:56 CEST] <james999> tried using both udp and http to my xbox with vlc and it wouldn't stream [22:19:08 CEST] <james999> but when i picked samba share or UPNP server it worked [22:21:02 CEST] <faLUCE> any tip about that? [22:33:12 CEST] <kode54> how cute, deadbeef wants to continue to support ffmpeg 0.x [22:33:22 CEST] <kode54> apparently, distributions living in the past still matter [22:39:33 CEST] <kode54> apparently, my changes to their ffmpeg input cause a deadlock in playback on several years old versions of ffmpeg [23:42:18 CEST] <alphabitcity> Hi all, I'm trying to use ffmpeg to delay the audio on an mp4 (to fix audio desync issue). I was able to figure that out, but I can't seem to figure out how to copy over the 3rd stream of the input mp4 to the output, which is a data stream (amf) data. Is that possible with ffmpeg? https://pastebin.com/EK5vHawT [23:45:23 CEST] <alphabitcity> Sorry, here's the correct CLI cmd I've been using: https://pastebin.com/ZN6qTYjh [23:46:52 CEST] <thebombzen> alphabitcity: use -map d in order to map all data streams [23:47:38 CEST] <thebombzen> just like 'v' is video and 'a' is audio, there's 'd' for data, 's' for subtitle and 't' for attachment [23:47:55 CEST] <thebombzen> or 't' for text, idk. but that one is used for attached fonts [23:48:30 CEST] <thebombzen> so you could -map 0:d or -map 1:d depending on where you want it. in your case, using -map d will map the data stream from both files, so you probably want to use -map 0:d [23:49:05 CEST] <alphabitcity> thebombzen: thx so much. i tried that but am getting "Data stream encoding not supported yet (only streamcopy)" .. perhaps i'm using an old version of ffmpeg? [23:49:27 CEST] <thebombzen> is it a warning? and yea that's not a surprise [23:49:45 CEST] <thebombzen> what that means is that you cannot convert between different codecs for the data stream... which you shouldn't be able to [23:49:56 CEST] <thebombzen> do suppress the warning you can use -c:d copy, which streamcopies the data stream [23:50:06 CEST] <thebombzen> but it should do that by default anyway [23:50:29 CEST] <thebombzen> otherwise it tries to autoselect a codec... but for data there isn't any so it'll just default to copy. same with 't' streams [23:50:39 CEST] <alphabitcity> hmm i see [23:51:56 CEST] <alphabitcity> getting a "Couold not write header" error now: https://pastebin.com/xAGXcrQ3 (with -map 0:d and -c:d copy) [23:53:35 CEST] <thebombzen> you're using an ancient version of ffmpeg [23:53:52 CEST] <alphabitcity> ok good to know, will update :) [23:54:04 CEST] <thebombzen> that sounds like an issue that should be fixed [23:54:18 CEST] <thebombzen> I mean that looks like a bug but check a recent version first [23:54:23 CEST] <thebombzen> fyi you can intall ffmpeg with homebrew [23:54:33 CEST] <alphabitcity> yea, i have it installed with homebrew. updating it now [23:54:39 CEST] <alphabitcity> on 3.3 now [23:55:16 CEST] <thebombzen> try again on 3.3. that should work [23:55:30 CEST] <thebombzen> also you should use -ss, not -itsoffset [23:55:39 CEST] <thebombzen> -ss says "seek" and -itsoffset just shifts the timestamps [23:56:17 CEST] <thebombzen> although -itsoffset is useful for streamcopy, you could run into issues [23:56:25 CEST] <thebombzen> compatibilty issues with bad players I mean [23:56:42 CEST] <thebombzen> if you don't care then you don't care, I just figured I'd warn you [23:56:59 CEST] <alphabitcity> @thebombzen: ty. i switched to ss and upgraded to 3.3. it looks like it's having trouble looking for a codec for the data stream: https://pastebin.com/3G34rrgY [23:57:29 CEST] <thebombzen> ss is not a drop-in replacement by the way [23:57:35 CEST] <thebombzen> it'll effectively work in the other direction [23:57:44 CEST] <alphabitcity> ok, good to know :) i'll read the docs on it [23:57:46 CEST] <thebombzen> so keep using itsoffset until you fix the data issue. one step at a time [23:57:57 CEST] <alphabitcity> ok [23:58:36 CEST] <thebombzen> that's... interesting. what if you write it to matroska? [23:59:29 CEST] <alphabitcity> @thebombzen: looks like mkv doesn't support data tracks? "Only audio, video, and subtitles are supported for Matroska." [23:59:37 CEST] <thebombzen> what about nut? [00:00:00 CEST] --- Mon May 1 2017

1 0