October 2018 - Ffmpeg-devel-irc

ffmpeg-devel.log.20181010
by burek 11 Oct '18

11 Oct '18

[06:04:33 CEST] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/d098cb44f6103a03476d16ac… [07:11:45 CEST] <geri> hi [07:11:49 CEST] <geri> someone here? [07:12:10 CEST] <geri> how can i concatinate horizontally and vertically video with ffmpeg? [17:43:58 CEST] <BtbN> philipl, looks good, feel free to push. [17:44:30 CEST] <BtbN> That's the third individual UUID type defined by nvidia... [18:02:14 CEST] <philipl> hah. [18:02:39 CEST] <philipl> thanks [18:03:28 CEST] <philipl> pushed. [18:40:45 CEST] <durandal_1707> wtf, now people who top post say sorry for top posting! what is happening? perhaps carl started to reply off-list with his usual mantra? [19:36:02 CEST] <durandal_1707> michaelni: nobody gives anything for free any more [19:36:52 CEST] <atomnuker> well our servers are hosted for free [19:44:07 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:d95c5b003c04: libavfilter/ebur128: add target level option for EBUR128 visualization filter [19:44:07 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:1cee8f03cf01: libavfilter/ebur128: add target value to statistics line [19:44:07 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:d587390988e1: libavfilter/ebur128: add gauge option [19:44:07 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:d445bcb137fa: libavfilter/ebur128: introduce target range [19:44:07 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:4069d2d08707: libavfilter/ebur128: add scale parameter [19:44:08 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:a628fa1feca4: libavfilter: bump micro version to 101 [20:07:28 CEST] <cone-843> ffmpeg 03Paul B Mahol 07master:7a6d88ee6269: avfilter/af_afir: remove again option, merge it with gtype [20:33:36 CEST] <durandal_1707> atomnuker: are you paid to work in multimedia or you are working in web stuff? [20:43:03 CEST] <atomnuker> web stuff? god no, never have [20:43:17 CEST] <atomnuker> am paid to work on av1 for now [20:46:12 CEST] <durandal_1707> atomnuker: and FFv2? [20:48:50 CEST] <atomnuker> for fun, lol, like everything I've done for the project (with exception of dirac/vc2 from 2.5 years ago) [20:57:17 CEST] <jamrial> is there anything to gain by making avcodec_default_get_buffer2() allocate a single contiguous buffer for all planes instead of separate ones? [20:58:13 CEST] <durandal_1707> our allocator can alloc max 4gb? [21:02:42 CEST] <jamrial> INT_MAX or so by default, it seems [21:05:09 CEST] <atomnuker> shouldn't do anything, all planes are always aligned so even on old arm CPUs there shouldn't be a delay continuously reading each pixel [21:05:47 CEST] <durandal_1707> nano-optimization [21:05:51 CEST] <atomnuker> in 99% of the cases they're allocated and freed together, so shouldn't cause fragmentatioin [21:06:14 CEST] <atomnuker> yeah, you'd save some work for the allocator but that's nanooptimization territory [21:10:14 CEST] <jkqxz> Yeah, it makes sense that it should be irrelevant in terms of normal use. [21:10:34 CEST] <jkqxz> There could be some consequences of the large virtually-contiguous allocations, though. [21:11:11 CEST] <jkqxz> It might make memory pressure worse on systems with small address space (i.e. 32-bit systems), though case where that matters are hopefully rare. [21:11:32 CEST] <jkqxz> On the other hand, it could lead to better use of huge pages where they are available. [21:54:33 CEST] <BtbN> Nvidia has a bunch of APIs that absolutely expect the buffer to be continous, and only want one pointer and the stride as input. [21:58:01 CEST] <atomnuker> how... unflexible, with vulkan you're suggested to put padding in between the planes and in some cases are required to do so [21:58:36 CEST] <atomnuker> though that's only on intel and maybe amd, nvidia's minimal alignment for a mappable buffer is 1 [21:59:54 CEST] <jkqxz> Presumably that is with offsets (somehow constrained) for the planes after the first, not requiring the planes to directly follow each other? [22:01:08 CEST] <BtbN> Nvidia just doesn't really want/expect you to use plain memory there. But a CUarray instead [22:01:18 CEST] <BtbN> Which abstracts that stuff away [22:01:29 CEST] <philipl> yeah [22:20:33 CEST] <nevcairiel> if you map sysmem onto gpu textures in d3d, its also one big buffer only, no separate planes [22:23:59 CEST] <BtbN> Using actual CUDA pointers is convenient though, as they behave exactly like normal pointers in pretty much all aspects [00:00:00 CEST] --- Thu Oct 11 2018

1 0

ffmpeg.log.20181010
by burek 11 Oct '18

11 Oct '18

[00:03:29 CEST] <JEEB> trashPanda_: fftools/ffmpeg.c: av_usleep(10000); [00:03:37 CEST] <JEEB> it looks like it's straight in ffmpeg.c :P [00:04:00 CEST] <trashPanda_> I saw those calls, but how could that be used to match input framerates? Its a flat sleep for 10 seconds [00:08:01 CEST] <JEEB> ctrl+F "rate_emu" in ffmpeg.c [00:08:13 CEST] <JEEB> I checked which variable the "re" option goes to in ffmpeg.c [00:08:15 CEST] <JEEB> and that was it [00:17:48 CEST] <trashPanda_> that makes more sense, thank you [02:27:04 CEST] <garyserj> if i want to concatenate two mp4 files, each is AVC/AAC. I want to maintain those codecs. What command should I use? Is ffmpeg -i a.mp4 -i b.mp4 output.mp4 ? If I do that then would I get some default encoding? When I do that I get lots of errors/warnings like "Past duration 0.600655 too large", and I ctrl-c. If I try ffmpeg -i part1.mp4 -c copy -i part2.mp4 -c copy output2.mp4 Then it says [02:27:04 CEST] <garyserj> "Unknown decoder 'copy'". What command should I be using? [02:59:23 CEST] <relaxed> garyserj: ffmpeg -f concat -safe 0 -i <(for i in part1.mp4 part2.mp4; do printf "file "%s"\n" "$PWD"/"$i"; done) -c copy -movflags +faststart done.mp4 [03:18:36 CEST] <garyserj> relaxed: I see that uses a linux shell. so I switched from cmd to cygwin(which gives some linux commands and bash functionality in windows). I got the message "/dev/fd/63: No such file or directory" [03:22:15 CEST] <kepstin> garyserj: ah, you'd need a cygwin build of ffmpeg for that command to work. [03:22:50 CEST] <kepstin> try just making the playlist file for the concat muxer manually [03:28:24 CEST] <garyserj> thanks I think that worked, making the playlist file for the concat muxer manually! [05:11:03 CEST] <quint> How can I tell ffmpeg to use more threads? I used the -threads option and it remained the same while encoding with opus [05:11:31 CEST] <quint> Or is it codec specific? [05:25:34 CEST] <furq> it is codec specific [05:25:34 CEST] <furq> i don't think any audio codecs have multithreading [05:25:34 CEST] <furq> if you're encoding multiple files then use xargs or parallel or something [05:35:44 CEST] <quint> I'll have a look furq, thanks [06:36:19 CEST] <geri> hi, how to merge 2 videos, they are mixed horicontally and vertically, format is .mov [06:36:21 CEST] <geri> ? [06:49:17 CEST] <geri> i get that error: Invalid data found when processing input [06:49:18 CEST] <geri> hm [07:11:27 CEST] <geri> hu? [11:46:25 CEST] <illuminated> when encoding does time= output correspond to the time on the video it's encoding or how long the encoding process has been going? [14:09:22 CEST] <Essadon> Hello, I would like to know the syntax for combining a slideshow of multiple GIF pictures and the sound of a MP4 file. I have timestamps for when a certain picture should be viewed, and I want to merge the pictures and the sound together into a single file. [15:43:43 CEST] <King_DuckZ> hi, I'm still working on my seeking problem and I found I'm not the only one https://stackoverflow.com/questions/23018933/calculate-current-video-time-w… [15:43:58 CEST] <King_DuckZ> so is that frame number thing just a monotonic counter? [15:52:19 CEST] <JEEB> there's no frame exact frame number thing in libavformat [15:52:26 CEST] <JEEB> if you need to be frame exact use something like ffms2 [15:54:44 CEST] <King_DuckZ> JEEB: I looked into that but it looks like it's going to be a lot of work before I can use it [15:55:05 CEST] <King_DuckZ> JEEB: I'd have to refactor the whole reader backend, which I tried already and I failed [15:55:38 CEST] <w1kl4s> I know that it's not vapoursynth related channel, but i don't know anything better :P How to obtain frame timestamps using ffms2 plugin? [15:55:42 CEST] <w1kl4s> King_DuckZ that's easier than it sounds once you go throu black magic [15:56:02 CEST] <w1kl4s> Depends what you want to do with those frames [15:57:00 CEST] <King_DuckZ> it's just used in debug print statements as I'm trying to find out what's wrong with my seeking, and I'm wondering if I'm looking at some useless number [16:03:19 CEST] <King_DuckZ> this is my program's output https://alarmpi.no-ip.org/kamokan/cw?colourless starting from the first time I seek back (line 137) the frame number goes out of sync with the dts (5338 is DTS for frame 161) [16:03:36 CEST] <King_DuckZ> so that's my question, am I looking at a pointless number or do I have some real problem there? [16:04:20 CEST] <King_DuckZ> as for my overall problem, as you can see I seek to different DTS but every read restarts from 5338 for some reason [16:05:29 CEST] <King_DuckZ> compare line 47 and 68 for example, how can the same DTS have different frame numbers? [16:06:49 CEST] <Foaly> it nowhere says pts in that text, only pts [16:06:55 CEST] <Foaly> *dts [16:07:32 CEST] <Foaly> i mean, it only talks about pts in you log [16:12:12 CEST] <Foaly> also, where do you get you frame number? [16:27:34 CEST] <King_DuckZ> Foaly: yes, I just found out that av_seek_frame expects a dts, I used to pass the pts before and haven't updated all the output strings and variable names yet [16:28:11 CEST] <Foaly> and where are the frame numbers from? [16:28:56 CEST] <King_DuckZ> Foaly: that frame number comes from AVCodecContext's frame_number [16:29:50 CEST] <King_DuckZ> avcodec_receive_frame(my_decoder, my_frame); printf("%d", my_decoder->frame_number); [16:30:49 CEST] <Foaly> well, and it is monotonically increasing? [16:31:03 CEST] <Foaly> the docs just say "decoding: total number of frames returned from the decoder so far." [16:31:17 CEST] Action: King_DuckZ facepalms [16:31:30 CEST] <Foaly> you should rely on the pts usually [16:31:51 CEST] <King_DuckZ> I'm trying to, I was trying to print some meaningful debug messages [16:32:01 CEST] <Foaly> it is not even guaranteed that every frame is equally long, since you may have a variable framerate [16:32:43 CEST] <Foaly> probably makes sense to output a timestamp in seconds.milliseconds [16:32:50 CEST] <King_DuckZ> indeed, pts increases by 32 or 33 at each frame [16:34:39 CEST] <King_DuckZ> I have this code https://alarmpi.no-ip.org/kamokan/ct?colourless which is currently returning an incorrect value at frame 160, as explained in that pastie [16:35:55 CEST] <Foaly> incorrect means ...? [16:35:59 CEST] <King_DuckZ> the other day I've been told that I can't rely on just that multiplication to be pts-accurate so I'm trying to fall back to the closest frame now whenever my pts is between 2 frames [16:36:41 CEST] <King_DuckZ> Foaly: it means frame_to_pts(160) = 5339, but input file has 5338 [16:37:49 CEST] <Foaly> well, it may have rounded differently on encoding [16:37:58 CEST] <King_DuckZ> I have this: 5338 (frame 160) --- 5339 (my calculated pts) ------ 5371 (frame 161) [16:38:00 CEST] <King_DuckZ> yes [16:38:32 CEST] <Foaly> so what do you need? [16:39:12 CEST] <King_DuckZ> in that case there is no exact match so I just take 5338 because it's the closest, but frame 161 has been read already, or otherwise I wouldn't know its pts [16:40:53 CEST] <King_DuckZ> so I take frame 160 and av_seek_frame to 5338, so that frame 161 doesn't get skipped during the next attempt to read a frame [16:42:22 CEST] <Foaly> well, arguing about frame numbers is hard, since you can't be sure that your input has a fixed framerate [16:43:04 CEST] <King_DuckZ> but then look at the log, line 58 and line 68: av_seek_frame(5371) and avcodec_receive_frame() -> 5338 [16:43:37 CEST] <King_DuckZ> I know, it's extremely frustrating to debug and I can't figure out what I'm doing wrong [16:45:10 CEST] <King_DuckZ> but I keep on getting the same frame at every read, starting from that frame the code goes like 160, then 160,161, then 160,161,162 etc, and so decoding becomes slower and slower after each frame [16:45:53 CEST] <King_DuckZ> if you quickly scroll my log you'll notice a chunk of text that becomes longer and longer [16:46:07 CEST] <Foaly> well, what is you application of this? [16:46:13 CEST] <Foaly> why do you do that? [16:46:51 CEST] <Foaly> also, av_seek_frame says: "Seek to the keyframe at timestamp." [16:47:02 CEST] <Foaly> so you cannot seek to a frame that is not a keyframe [16:47:41 CEST] <King_DuckZ> I'm writing an API that's like load_image(int frame number) so although client code is likely to request sequential frames I can't be sure [16:48:10 CEST] <Foaly> well, then you will have to keep state internally to optimize for that [16:51:04 CEST] <King_DuckZ> this https://stackoverflow.com/questions/39983025/how-to-read-any-frame-while-ha… says I should land at the first keyframe at or before the PTS [16:51:55 CEST] <Foaly> and it does not do that? [16:54:05 CEST] <King_DuckZ> interesting... can I retriever that somehow? for debug printing? [16:55:13 CEST] <Foaly> what? [16:55:36 CEST] <King_DuckZ> I'd like to print if my current frame is a keyframe or not [16:56:36 CEST] <Foaly> AVFrame.key_frame duh [16:57:52 CEST] <King_DuckZ> kewl [17:02:05 CEST] <King_DuckZ> you're right, 160 is a keyframe :S [17:02:09 CEST] <King_DuckZ> I see what's going on now [18:02:58 CEST] <King_DuckZ> thanks for helping, I haven't fixed my problem yet but at least I know where I should look now :) [19:41:20 CEST] <grkblood13> if there a way to reuse a predefined list of filenames in segment mode? for example if I defined 5 segments could i have ffmpeg used file_0.ts through file_4.ts and overwrite the oldest one if all files are being used? [19:41:43 CEST] <grkblood13> so after file_4.ts is written, file_0.ts would be rewritten next [19:44:10 CEST] <ChocolateArmpits> grkblood13, there's a segment_wrap option [19:45:29 CEST] <grkblood13> thanks, ill give it a look [19:45:46 CEST] <grkblood13> can you define segments by byte size? [19:46:27 CEST] <ChocolateArmpits> grkblood13, don't see such an option [19:46:37 CEST] <ChocolateArmpits> seems only frames or time specified [19:47:26 CEST] <grkblood13> would frames from the same video all be the same size? [19:47:37 CEST] <JEEB> possibly [19:47:45 CEST] <JEEB> always check your AVFrame width/height [19:47:49 CEST] <JEEB> after decoding [19:48:00 CEST] Action: JEEB has streams that switch SD to HD and back [19:48:24 CEST] <grkblood13> ok, thanks for the info [19:48:32 CEST] <ChocolateArmpits> I think he's asking in terms of file size [19:48:36 CEST] <JEEB> right [19:48:40 CEST] <JEEB> that's all over the place :P [19:48:52 CEST] <JEEB> depending on the encoder, parameters etc [19:49:01 CEST] <grkblood13> oh, well nvmd then :/ [19:49:06 CEST] <JEEB> some encoders can possibly make you packets of exact size [19:49:10 CEST] <JEEB> but that's just *some* [19:49:19 CEST] <ChocolateArmpits> grkblood13, check out the options here https://www.ffmpeg.org/ffmpeg-formats.html#toc-segment_002c-stream_005fsegm… [19:49:21 CEST] <JEEB> also that tends to be inefficient as hell [19:49:40 CEST] <grkblood13> i want to use ffmpeg in a web-worker to repack an mpegts stream into an hls one [19:49:59 CEST] <grkblood13> so im thinking i need to create blobs beforehand [19:50:11 CEST] <grkblood13> and Im guessing ill need to know the size of those blobs [19:50:22 CEST] <grkblood13> so this might not be possible [19:52:56 CEST] <BtbN> you want segments to always start at an iframe, so filesize is a bad measurement [19:53:11 CEST] <BtbN> If you use CBR and a constant gop length, you will get a constant file size automatically [19:53:32 CEST] <JEEB> but in HLS the size of segments doesn't really matter [19:53:38 CEST] <JEEB> you just need to know your theoretical max [19:53:42 CEST] <JEEB> (length) [19:53:50 CEST] <JEEB> and the length in duration of each segment [19:53:52 CEST] <BtbN> well, you do want them to be in roughly the same size [19:53:58 CEST] <JEEB> sure [19:54:02 CEST] <BtbN> otherwise bad networks will hate you [19:54:03 CEST] <grkblood13> right, but the output would be written to blobs, not files [19:54:09 CEST] <BtbN> to what? [19:54:09 CEST] <JEEB> yes? [19:54:11 CEST] <grkblood13> so i need to knwo beforehand how big to make those blobs [19:54:28 CEST] <JEEB> you parse the input in your inpur parser far enough? [19:54:35 CEST] <JEEB> then you know the size and then you can memcpy [19:54:47 CEST] <JEEB> or write that block or whatever [00:00:00 CEST] --- Thu Oct 11 2018

1 0

ffmpeg-devel.log.20181009
by burek 10 Oct '18

10 Oct '18

[02:10:20 CEST] <cone-411> ffmpeg 03Avi Halachmi (:avih) 07release/4.0:42355d12dbfd: configure: speed up flatten_extralibs_wrapper() [02:10:20 CEST] <cone-411> ffmpeg 03Avi Halachmi (:avih) 07release/4.0:df6e929e8934: configure: speed up print_enabled_components() [02:10:20 CEST] <cone-411> ffmpeg 03Avi Halachmi (:avih) 07release/4.0:a634da282b7c: configure: speed up check_deps() [02:10:20 CEST] <cone-411> ffmpeg 03Avi Halachmi (:avih) 07release/4.0:3fb09dba40b0: configure: <fflib>_deps: validate, reduce sensitivity [12:21:26 CEST] <j-b> durandal_1707: koda: https://wiki.videolan.org/Bounties/ [12:25:48 CEST] <durandal_1707> j-b: it is AGM2 not AG2M and there are variants from AGM0 to AGM8 [12:26:20 CEST] <j-b> ok [12:29:36 CEST] <j-b> durandal_1707: anything else? [12:29:51 CEST] <atomnuker> there's no sum listed for either AACE or xHE-AAC [12:30:36 CEST] <j-b> atomnuker: that's a good point. Because I have NO clue. [12:30:56 CEST] <j-b> let me ask around [12:30:58 CEST] <kierank> I guess there's opus fec in ffmpeg [12:31:00 CEST] <kierank> that's a bounty [12:31:11 CEST] <durandal_1707> j-b: i will do AGM2 and AGM3 (AGM3 for free, because you are very very evil) [12:31:32 CEST] <j-b> I am evil, sure. But Why? [12:32:05 CEST] <durandal_1707> why you are evil? how do i know? [12:32:40 CEST] <j-b> You told me I was [12:32:45 CEST] <j-b> there must be a good reason [12:34:39 CEST] <atomnuker> afaik xhe-aac's getting used in india now, got no idea about aace (!= aac-eld) [12:36:04 CEST] <atomnuker> I only know about that from a youtube video with 50 views of some guy using gnuradio to feed the demodulated data into a torn apart radio [12:37:00 CEST] <kierank> atomnuker: ah for DRM radio [12:37:48 CEST] <kierank> I might be able to receive that with a coathanger and sdr [12:38:30 CEST] <atomnuker> https://www.youtube.com/watch?v=CPu0ZODJ2tA [12:39:11 CEST] <kierank> lol [14:09:10 CEST] <January> michaelni: https://0x0.st/s3YD.nal as fate/h264/crew_cif.nal please. I've updated the test to work on 32bit now as well (was a pain to get multilib working but I probably could have just looked at the code and found the bug...) [14:09:44 CEST] <JEEB> I think the extension .264 or so could be better for those? [14:09:55 CEST] <JEEB> (since I think lavf picks that up) [14:10:37 CEST] <January> JEEB: it's not quite .264, it's got NALU sizes before each NALU [14:12:48 CEST] <JEEB> oh [14:12:51 CEST] <JEEB> so it's not Annex B [14:13:10 CEST] <JEEB> do we even support that? oh, I guess it's for the API test :) [14:14:17 CEST] <nevcairiel> as a raw file thats not supported [14:14:24 CEST] <nevcairiel> its really quite invalid [14:24:40 CEST] <michaelni> January, i think ive already uploaded this one [14:25:03 CEST] <January> oh right thanks [15:19:30 CEST] <JEEB> another fun case of ffmpeg.c's timestamp fixing breaking apart :) [16:14:01 CEST] <cone-296> ffmpeg 03Derek Buitenhuis 07master:b1504e7796a4: h264_slice: Copy the value of x264_build before calling h264_slice_header_init during thread init [16:16:31 CEST] <atomnuker> jamrial: btw there's a todo in matroskadec.c on line 2424 about av1, is that still valid? [16:18:12 CEST] <jamrial> yes. i was waiting for the decoder to land before doing that, since changing what we export as extradata would affect how it's parsed [16:19:03 CEST] <jamrial> but i guess we could do it in time for ffmpeg 4.1 [16:19:07 CEST] <jamrial> only cbs av1 needs to be adapted [16:20:01 CEST] <atomnuker> we got that merged already though [16:22:10 CEST] <jamrial> it's a simple change [16:28:22 CEST] <philipl> BtbN, nevcairiel: So do we actually have an issue with the new pix fmts? [16:29:06 CEST] <philipl> Should we remove P010 for Carl?... [16:31:17 CEST] <nevcairiel> P010 is at least a rather common format, and we don't have P012 and still somehow manage to deal with 12-bit video. In an ideal world you could just use a few formats that describe the data layout and additional metadata that describes the finer details [16:31:20 CEST] <kierank> the naming is super confusing the on the pixel formats [16:41:21 CEST] <philipl> kierank: I have no attachment to the names (but note I did get them the wrong way round in the patch and I've switched it locally). I'll take any suggestions. [16:41:56 CEST] <philipl> I'm also happy to just use 444P16 and call it a day. I just don't want a situation where it ends up being 'solve this big problem before you can make your small change' [16:47:30 CEST] <atomnuker> 444p16 isn't even an option [16:47:42 CEST] <atomnuker> for when you have p010 but with lsb padding [16:48:32 CEST] <nevcairiel> p010 always has lsb padding [16:48:41 CEST] <nevcairiel> this is about a new 444 format [16:49:52 CEST] <atomnuker> eh? well damn, I was right after all, that's why I must have left it in hwcontext_vulkan [17:08:21 CEST] <philipl> nevcairiel: So where does this leave us? Yes, in an ideal world, we'd do things differently, but that's a task as big as yuvj which is still ongoing. So the only short term options are fudge it and just use YUV444P16 with no bit depth information or add the new pix fmts. Before Carl showed up it seemed we all agreed that pix fmts were acceptable, even if not great. Is that still the position? [17:11:40 CEST] <atomnuker> I'd rather have the new pixfmts, bits per sample isn't acceptable as there's no such field in avframes and it doesn't describe where the padding would be anyway [17:14:19 CEST] <nevcairiel> you could define that anyway [17:14:24 CEST] <nevcairiel> just like with audio [17:14:31 CEST] <nevcairiel> we shove 20 and 24 bit in S32 and have bitdepth to go with that [17:14:47 CEST] <nevcairiel> padding is a lways LSB, which means you can interpret that as 32-bit audio if you wanted to, and it would sound fine [17:14:53 CEST] <nevcairiel> knowing the actual bitdepth is only a small advantage [17:15:15 CEST] <nevcairiel> its not like this is a new concept, we already have that, just not for video [17:15:33 CEST] <atomnuker> yeah, I guess [17:28:30 CEST] <BtbN> Wasn't YUVJ even un-deprecated? Because nobody could reasonably fix the alternative in due time? [17:29:47 CEST] <BtbN> There is such a big wave of changes neccesary to not get the bit depth from the pix_fmts, I really see the pix_fmts as the only option right now. The alternative is a massive patchset by itself that would take months to polish [17:29:53 CEST] <atomnuker> nope, its still deprecated [18:37:29 CEST] <durandal_1707> all thanks to your tremendous help! [18:40:58 CEST] <atomnuker> we've been trying to get you to resubmit your patches, the current ones from february had a bug afaik which you solved [18:41:05 CEST] <atomnuker> but you didn't resubmit them [18:46:49 CEST] <durandal_1707> why anybody listen to Carl? he is irrelevant [18:49:32 CEST] <kierank> durandal_1707: he is leader [18:50:07 CEST] <durandal_1707> no, he is f* word [18:52:33 CEST] <j-b> atomnuker: any other idea for Bounties? [18:53:58 CEST] <durandal_1707> add lottery... channces are bigger to get more cash [18:54:13 CEST] <j-b> if you need more cash, ask Youtube. [19:07:47 CEST] <atomnuker> can't think of anything, I'm no expert on obscure one-off audio codecs which became popular enough for a bounty [19:08:51 CEST] <durandal_1707> j-b: so no VLC lottery? :( [19:09:01 CEST] <j-b> atomnuker: [19:09:05 CEST] <j-b> atomnuker: thx [19:09:12 CEST] <j-b> durandal_1707: I wish I had more money [19:09:37 CEST] <kierank> durandal_1707: ask j-b for saturn v rocket [19:09:45 CEST] <durandal_1707> lol [19:09:51 CEST] <j-b> that, I can provide. [19:10:06 CEST] <durandal_1707> one, filled with air? [19:12:59 CEST] <atomnuker> no, helium, that's what it used to pressurize tanks [19:24:12 CEST] <philipl> So who's going to tell Carl that we're happy adding new pix fmts? [19:25:59 CEST] <durandal_1707> j-b: do you have any other agm2 sample, beside one i uploaded? [20:23:02 CEST] <durandal_1707> if i do vertical flip of block before dct, how should zigzag pattern look like? so I do not need to do extra vertical flip again with idct? [20:52:43 CEST] <durandal_1707> nobody is (I)DCT expert here? [20:54:48 CEST] <atomnuker> not sure, this isn't as trivial as transposing is [20:55:25 CEST] <atomnuker> what are you trying to do which requires you to undo a flip in the spatial domain? [20:56:54 CEST] <durandal_1707> atomnuker: codec is encoded videos vertically flipped [20:57:52 CEST] <jkqxz> You want something like negating all coefficients in even rows, I think? (With standard even-size DCT and nothing funny going on.) [20:58:33 CEST] <durandal_1707> dct 8x8 blocks [20:58:38 CEST] <atomnuker> pretty sure that would affect horizontal coeffs as well [21:01:45 CEST] <jkqxz> Yeah. That gets the vertical right, but messes with the horizontal. [21:02:09 CEST] <atomnuker> apparently its just a matrix multiply by diag(1, -1, 1, -1, 1, -1, 1, -1) [21:02:12 CEST] <atomnuker> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.603.7187&rep=rep1&… [21:04:10 CEST] <atomnuker> so for a vertical flip you do K*X and for a horizontal you do X*K, where K is that diag matrix [21:18:59 CEST] <durandal_1707> atomnuker: you are genius [21:19:21 CEST] <durandal_1707> jkqxz: it is odd rows [21:20:45 CEST] <JEEB> :) [21:43:36 CEST] <atomnuker> durandal_1707: if they're encoding stuff flipped you also need to swap the blocks vertically, right? [21:46:51 CEST] <durandal_1707> atomnuker: yes [21:48:55 CEST] <atomnuker> I guess they wanted to make encoding fast so rather than doing it there they signal it for the decoder to do [21:54:50 CEST] <cone-878> ffmpeg 03Marton Balint 07master:4db291d76422: avfilter/f_cue: always check the return value of ff_inlink_consume_frame [21:54:50 CEST] <cone-878> ffmpeg 03Marton Balint 07master:6e6ecdf44d62: ffmpeg: check return value of avcodec_parameters_from_context [21:54:50 CEST] <cone-878> ffmpeg 03Marton Balint 07master:d6a1f711bcd1: avfilter/af_asetnsamples: do not leak frame on ENOMEM [22:50:40 CEST] <cone-878> ffmpeg 03Carl Eugen Hoyos 07master:f85fa100db7d: lavf/ftp: Remove an unneeded forward declaration. [00:00:00 CEST] --- Wed Oct 10 2018

1 0

ffmpeg.log.20181009
by burek 10 Oct '18

10 Oct '18

[00:11:42 CEST] <tytan> Hello everyone, I am trying to two pass encode a file in Windows but there is no /dev/null in Windows. How do I do it there? [00:12:59 CEST] <JEEB> NUL [00:13:10 CEST] <tytan> just "NUL" ? [00:13:11 CEST] <JEEB> a quick search would have made you find that I think? [00:14:17 CEST] <tytan> in the guide it says [00:14:18 CEST] <tytan> Note: Windows users should use NUL instead of /dev/null and ^ instead of \. [00:14:31 CEST] <tytan> I wasn't sure about the syntax [00:24:50 CEST] <tytan> it fails at the && though [00:32:04 CEST] <poutine> tytan, when asking for help with syntax, posting the syntax used is always helpful (and in a pastebin) [00:35:23 CEST] <tytan> http://ffmpeg.pastebin.com is dead [00:36:57 CEST] <poutine> I guess there's no alternatives then [00:37:06 CEST] <tytan> + [00:38:51 CEST] <ariyasu> are you running your command from a batch file? [00:39:13 CEST] <ariyasu> if not, use & instead of && [00:39:41 CEST] <ariyasu> and yes posting your full command and output to pastbin would be very helpful if you need help [00:40:16 CEST] <tytan> https://pastebin.com/pcMn61t2 [00:40:35 CEST] <tytan> just powershell [00:40:57 CEST] <ariyasu> whats the output [00:42:13 CEST] <ariyasu> i don't believe you need " && ^" at all [00:42:14 CEST] <poutine> I don't think you need the ^ in powerhsell [00:42:20 CEST] <ariyasu> just end the line with NUL [00:44:10 CEST] <tytan> let me try that first [00:48:02 CEST] <tytan> ok so doing it in cmd works. I guess I just don't use power shell then. [00:48:21 CEST] <ariyasu> i personally hate powershell and do everything in cmd [00:48:25 CEST] <ariyasu> but it should work in both [00:48:27 CEST] <tytan> I just used power shell because that what you get when you shift right click in a directory on Windows 10 1809 [00:48:44 CEST] <ariyasu> you can change that with a registry tweak if you want [00:49:25 CEST] <tytan> nah i will just use cmd as I don't care. I'm more the GNU/Linux guy either but I'm at a Threadripper 2990WX atm and I want to play around with it ^^ [00:52:37 CEST] <tytan> 32 cores and 64 threads. pretty fast for video encoding. the future looks good [00:53:27 CEST] <tytan> anyway, have a nice day everyone [01:52:33 CEST] <rkantos_> Btw... Any idea if FFMpeg is supposed to be able to encode say 2x2 videos? [01:52:46 CEST] <rkantos_> I need recording capabilities for 2x1920 footage :) [01:53:06 CEST] <rkantos_> It actually seems to function with greyscale.. just not with color [02:09:25 CEST] <Hello71> some codecs may not support it [02:09:41 CEST] <Hello71> and some pixel formats [03:00:15 CEST] <rkantos_> Hello71: meh... leadtools MJPEG handles it :D [03:05:24 CEST] <rkantos_> actually 1920x2 footage is what I really mean, so 2px height [12:19:23 CEST] <TheGrumpyScot> Having problems building ffmpeg with --enable-vorbis on ubuntu 18.04 (server) -- stated error is "vorbis not found using pkg-config"; (./configure command and partial config.log at https://node86.com/pastebin/ww26b) - what am I missing ? [12:25:38 CEST] <spaam> TheGrumpyScot: did you install the dev packet of libvorbis? [12:26:11 CEST] <TheGrumpyScot> spaam: Yes, installed `libvorbis-dev` [12:32:05 CEST] <zerodefect> Could try running 'ldconfig' and try rebuilding incase the .so db wasn't updated [12:35:55 CEST] <TheGrumpyScot> Same results I'm afraid - and I've checked the ldconfig cache is in fact listing libvorbis.so [12:38:29 CEST] <TheGrumpyScot> ah.. it's a pkg-config error; my bad! Sorry to waste your time folks. (Corrected with apt install pkg-config) :D [17:12:38 CEST] <King_DuckZ> hello, I found one more thing (surprise!) I don't understand in the code I'm trying to fix [17:14:05 CEST] <King_DuckZ> there's a function that gets asked to return frame n, so n gets converted to a PTS via the function I posted yesterday and then the code starts calling avcodec_receive_frame() until it gets a frame with the desired PTS [17:14:22 CEST] <King_DuckZ> I have no idea if that's optimal or not, but that's how the previous programmer wrote it [17:15:27 CEST] <King_DuckZ> what I added is that if the returned PTS is greater than the desired one, then choose current or previous frame depending on which one is closest to the wanted PTS [17:17:11 CEST] <King_DuckZ> if it's the old one then I call av_seek_frame(prev_frame->pts) because current frame is being discarded and should be re-read next time, however from here on the code seems to always resume from the first frame found through avcodec_receive_frame() [17:46:08 CEST] <Essadon> Hello, I would like to know the syntax for combining a slideshow of multiple GIF pictures and the sound of a MP4 file. I have timestamps for when a certain picture should be viewed, and I want to merge the pictures and the sound together into a single file. [17:48:47 CEST] <King_DuckZ> am I correct if I say that avcodec_receive_frame() advances the read position of the stream? [18:06:16 CEST] <JEEB> King_DuckZ: you might be confusing that one with the lavf read function which is called frame while it returns an AVPacket [18:25:16 CEST] Action: King_DuckZ looks around [18:25:35 CEST] <King_DuckZ> JEEB: you might be confusing me with someone who understands ffmpeg :p [18:26:11 CEST] <King_DuckZ> I'm trying to figure out what's going on in the code flow... been doing that for the past 2 weeks [19:11:58 CEST] <King_DuckZ> this is fucked up https://alarmpi.no-ip.org/kamokan/cu?colourless [19:12:27 CEST] <King_DuckZ> frame number goes up, pts loops around [20:04:48 CEST] <sonicrocketman> hello all! Does anyone have experience with the x11grab device? Im getting an error "Cannot get the image data event_error:" and I just get a 12KB 1 second all black video. [20:04:57 CEST] <sonicrocketman> Im kinda lost on a way to debug this rly. [21:07:17 CEST] <retal> Hello guys, i am publishing live rtmp stream like: [21:07:17 CEST] <retal> ffmpeg -i SOURCE -preset fast ... -f flv rtmp://10.110.0.5:1935/test_rtmp/stream [21:07:17 CEST] <retal> Now need publish with password, how can i do that? [21:09:52 CEST] <relaxed> retal: man ffmpeg-all|less +/^' 'rtmp [21:10:37 CEST] <retal> relaxed, i did but in manual i see rtmp://username:password@myserver/ [21:10:51 CEST] <retal> I dont have username, only password [21:12:09 CEST] <relaxed> maybe, rtmp://password@myserver/ ? [21:12:30 CEST] <retal> relaxed, tnx i will try [21:12:30 CEST] <sonicrocketman> maybe rtmp://:password@myserver/ [21:12:40 CEST] <sonicrocketman> notice colon before pass [21:12:43 CEST] <retal> sonicrocketman, tnx [21:55:52 CEST] <trashPanda_> Hello, does anyone have any experience using programatic filtergraphs? I'm feeding frames into the graph and receiving frames from it, however the PTS values of frames coming from the buffersink are all increased by 1 PTS. Am I expected to convert this into my appropriate output timebase? [21:57:32 CEST] <JEEB> I think both the sink and the buffer src had time bases [21:57:57 CEST] <trashPanda_> I know the buffer src does, I didn't see any parameters for the sink in the documentation on the web [21:58:06 CEST] <JEEB> and then you appropriately have to set the time base for the encoder AVCodecContext, and the muxer AVStream [21:58:27 CEST] <trashPanda_> do you think it works(has the same names) as the buffer src? [21:59:12 CEST] <JEEB> well I'm just looking at the example I did ages ago of doing something simple, and that one seems to set a time_base for the buffersrc [21:59:29 CEST] <JEEB> ok, "buffer" I mean as far as the filter's name goes [21:59:35 CEST] <trashPanda_> Yes, I did that. The output still has values increasing by 1 [21:59:53 CEST] <JEEB> trashPanda_: av_buffersink_get_time_base [21:59:59 CEST] <JEEB> there's a thing called like this it seems [22:00:21 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavfi__buffersink__accessors.ht… [22:02:33 CEST] <trashPanda_> I'll see what I get from it, thanks [22:02:52 CEST] <JEEB> np [22:03:44 CEST] <trashPanda_> how should "timebase" be used officially? [22:04:26 CEST] <trashPanda_> I see it used in different ways depending on the context [22:04:33 CEST] <JEEB> set it to the minimal value viable or pass it through as-is? [22:04:56 CEST] <JEEB> AVStreams have them, AVCodecContexts have them, avfilter has them [22:05:21 CEST] <trashPanda_> Yes, AVStream seems to report the PTS conversion rate of 1 to 90000hz number [22:05:30 CEST] <JEEB> yup, that's MPEG-TS [22:05:44 CEST] <trashPanda_> CodecContexts seem to report something closer to a framerate, 1001/60000 or 1001/30000 etc. [22:05:48 CEST] <JEEB> yes [22:06:01 CEST] <JEEB> generally they parse the value that most likely'ishly is the frame rate [22:06:05 CEST] <trashPanda_> This framerate filter is reporting 1/30 (aka fps) [22:06:12 CEST] <JEEB> yup [22:06:30 CEST] <JEEB> that's the time base that the filter will use in the output then [22:06:41 CEST] <JEEB> and since it's the fps filter it most likely will output the frames at +1 [22:06:42 CEST] <JEEB> each [22:07:44 CEST] <trashPanda_> Yes, it is doing that. Ok, so do AVStreams typically report pts conversion rate? or is it just special with Mpeg2 TS. SHould I expect other formats to output something similar to the AVCodecContext framerates? [22:08:01 CEST] <trashPanda_> Just curious for knowledge sake [22:08:17 CEST] <JEEB> in containers like MPEG-TS where the time base is hard-coded you will get exactly that [22:08:22 CEST] <JEEB> in other containers you can get the actual rate [22:08:44 CEST] <JEEB> tl;dr don't expect stuff, other than DTS/PTS over the AVStream's time base [22:08:57 CEST] <JEEB> you may get exact numbers, or you might get inexact [22:09:26 CEST] <trashPanda_> Ok, thank you [22:09:41 CEST] <JEEB> np [22:10:22 CEST] <JEEB> the biggest problem generally is that AVPackets and AVFrames always have PTS/DTS from something, and you have to keep in mind from where that is [22:10:41 CEST] <JEEB> demuxer AVPacket? AVStream it came from [22:10:54 CEST] <JEEB> decoded AVFrame? AVCodecContext it came from [22:11:07 CEST] <JEEB> filtered AVFrame? the filter graph [22:11:24 CEST] <JEEB> encoded AVPacket? the AVCodecContext [22:11:27 CEST] <JEEB> and so on [22:11:40 CEST] <JEEB> and you have to convert between those if they differ [23:10:26 CEST] <Aardwolf> Hi, I'd like to encode a single frame with a certain exact target filesize. I try combinations of the -r and -b:v parameter, but I can't get it to output the size I want. Is this possible? E.g. -r 1 and -b:v 100k, should output a 100k file? (it doesn't). Thanks! [23:11:14 CEST] <JEEB> that 100% depends on the encoder in use [23:11:19 CEST] <JEEB> some suck at hitting specific rates [23:11:40 CEST] <Aardwolf> I see, that explains why it differs wildly with different encoders [23:11:58 CEST] <JEEB> also the bit rate is in bits per second, and kilo/mega are bases of 1000 [23:12:01 CEST] <JEEB> not 1024 [23:12:34 CEST] <Aardwolf> If there is a single frame, how many seconds is that? I hoped setting -r 1 would make it count as 1 second [23:13:48 CEST] <JEEB> it depends on the time base and the duration of the picture. with one picture it's left rather vague [23:16:06 CEST] <trashPanda_> Hey JEEB, do you know of any reason I would keep getting frames out of the filter pipeline, despite not feeding it any more frames? [23:16:22 CEST] <JEEB> depends on the filter chain I guess? [23:16:48 CEST] <trashPanda_> I'm using a string to construct it, mind if I paste it? [23:17:23 CEST] <JEEB> as long as it's not too long. if it's long just pastebin or so it and link here [23:17:30 CEST] <trashPanda_> "buffer=width=%d:height=%d:pix_fmt=%s:time_base=%d/%d:sar=1, fps=fps=%i, %sbuffersink" [23:18:13 CEST] <trashPanda_> I fill the variables in with the source width, height, input AVStream timebase num and den, target fps and the last %s is an empty string right now [23:18:42 CEST] <trashPanda_> so basically, "buffer, fps, buffersink" not a long chain [23:19:18 CEST] <JEEB> yea, no idea of the internals of the fps filter unfortunately [23:20:21 CEST] <trashPanda_> so you think it would be that filter that keeps producing frames? [23:21:58 CEST] <trashPanda_> that makes sense, my timebases must be off and its trying to hit a wrong timebase number. thanks [23:46:24 CEST] <trashPanda_> Does anyone know where in code the -re command line argument (limiting read speed to be at the input src rate) is implemented? [23:50:30 CEST] <JEEB> trashPanda_: in ffmpeg.c [23:50:34 CEST] <JEEB> as in the example API client [23:50:44 CEST] <JEEB> it just sleeps according to some heuristic I think [23:50:57 CEST] <JEEB> so if your timestamps go wee-wee, it's going to 100% break on you [23:58:09 CEST] <trashPanda_> is it in a function call defined elsewhere? I'm not seeing anything that sleeps in the actual ffmpeg.c file, sorry if I missed it [23:58:48 CEST] <trashPanda_> nothing that would sleep like that anyway [00:00:00 CEST] --- Wed Oct 10 2018

1 0

ffmpeg-devel.log.20181008
by burek 09 Oct '18

09 Oct '18

[01:13:52 CEST] <bofh_> atomnuker: pong [02:13:58 CEST] <kierank> JEEB: did you fix your h264 bug? [07:59:00 CEST] <JEEB> kierank: not yet [11:54:40 CEST] <January> Is there a special way to bisect ffmpeg? [11:56:08 CEST] <nevcairiel> use the bisect script in the tools folder [11:56:18 CEST] <thardin> you mean other than git bisect run make fate? [11:58:52 CEST] <January> thardin: doing that I end up at some nonsensical commits [11:59:06 CEST] <January> nevcairiel: thanks, will give it a shot [12:03:55 CEST] <thardin> seems that just does git bisect run but checks that ffmpeg.c etc exists? [12:06:11 CEST] <funman> yes rather than avconv.c [12:06:51 CEST] <nevcairiel> yeah it ensures to stay on the right side of the merges [12:07:34 CEST] <thardin> aha [12:18:51 CEST] <J_Darnley> Since we are all jumping on to that bug... [12:18:58 CEST] <J_Darnley> Is there a known good commit? [12:20:27 CEST] <J_Darnley> kierank, January? [12:21:01 CEST] <kierank> No [12:21:14 CEST] <January> I just went back 'far' [12:21:15 CEST] <kierank> HEAD~1500 or so iirc works [12:21:22 CEST] <J_Darnley> okay [12:23:57 CEST] <cone-013> ffmpeg 03Paul B Mahol 07master:3cbf37bf098a: avfilter/af_silenceremove: fix max for duration options [13:01:24 CEST] <J_Darnley> This bisect tool is a POS! It looks like it is skipping every commit. [13:05:05 CEST] <J_Darnley> And now it looks like it deleted the entire tree. [13:06:56 CEST] <J_Darnley> Is that because some genius decided to move ffmpeg.c to fftools/? [13:17:36 CEST] <durandal_1707> yes [13:17:40 CEST] <JEEB> yea, it was moved at one point [13:22:55 CEST] <akravchenko188> jkqxz: hi, it is reminder. hwcontext_amf and vf_scale_amf is pending to integrate for a long time. is there any reason? could I fix something or provide some help? [13:27:16 CEST] <J_Darnley> "cf57cb3ae4364ab8e70af37beea7a45a86de90e9 is the first bad commit" [13:27:23 CEST] <J_Darnley> "h264: add AVOption to set x264_build default" [13:27:30 CEST] <J_Darnley> great [13:38:31 CEST] <cone-013> ffmpeg 03Paul B Mahol 07master:e10fe34e7c60: avfilter/f_reverse: add packed sample format support to areverse [18:45:34 CEST] <drbuck> I am working on a toy dash live streaming setup. For debugging, I would like to have pts, dts based on wallclock. output_ts_offset in mux.c seems like a good fit, but it is not supported in movenc.c. I'm not an expert on isobmff/cmaf, does output_ts_offset plausibly make sense to support? [18:48:47 CEST] <JEEB> I think nonzero PTS should work if you just note that it's a thing that starts with a discontinuity [18:48:50 CEST] <JEEB> IIRC [18:49:04 CEST] <JEEB> also there's another flag that tells the muxer to not draw your PTS/DTS to zero in the muxer either [18:50:47 CEST] <JEEB> some value of avoid_negative_ts IIRC [18:53:55 CEST] <drbuck> @JEEB: looking into it, thx! [20:34:21 CEST] <llogan> What is the answer to this question? "Is this gcc inlining problem still relevant for FFmpeg"? https://twitter.com/Art1Pirat/status/1049357199343071232 [20:34:47 CEST] <llogan> He then links to https://nadav.amit.zone/blog/linux-inline [21:58:18 CEST] <tmm1> "Decomposition unimplemented for unit 4 (type 10)" what is this in h264? [21:59:12 CEST] <tmm1> ah "Coded slice data partition C" [21:59:25 CEST] <tmm1> err no, that's type 4 not type 10. type 10 is "End of sequence" [22:43:01 CEST] <BtbN> philipl, so the latest nvidia driver fixes the mapping weirdnes? [22:50:34 CEST] <philipl> BtbN: an unreleased future driver will. [22:51:51 CEST] <nevcairiel> probably one that officially claims support for a future nvdec revision that actually has those output formats listed =p [22:52:09 CEST] <philipl> This is the vulkan interop bug. Different. [22:52:20 CEST] <philipl> They claim that works in the current driver releases, except it doesn't work for VkImages. [22:52:33 CEST] <nevcairiel> oh that [22:54:03 CEST] <BtbN> oh right, Windows has different numbers [23:02:14 CEST] <durandal_1707> forget about multimedia [23:03:32 CEST] <durandal_1707> it is full of crap [00:00:00 CEST] --- Tue Oct 9 2018

1 0

ffmpeg.log.20181008
by burek 09 Oct '18

09 Oct '18

[00:04:39 CEST] <killown> the issue is -c copy [00:06:27 CEST] <killown> not the issue also [00:06:32 CEST] <killown> still only copying 1.mp4 [00:15:38 CEST] <fahadash> I have 3 clips exact same frame width and height that I am trying to concat using -f concat and -safe 0; The result has the first one sped up. I also see the following in the errors [00:15:49 CEST] <fahadash> https://www.irccloud.com/pastebin/d2o5Woai/ [00:18:41 CEST] <killown> can anyone help me? [00:21:00 CEST] <tdr> it pob the syntac of the multiple files, can't yo uuse put them in a list and: ffmpeg -f concat -safe 0 -i mylist.txt -c copy output.mp4 ? [00:22:04 CEST] <tdr> got that from: https://trac.ffmpeg.org/wiki/Concatenate [00:24:14 CEST] <fahadash> That is what I am doing [00:24:34 CEST] <fahadash> If I don't use -c copy, then I see the actual error message [00:29:09 CEST] <BtbN> The concat protocol is basically like cat 1.mp4 2.mp4 ... > new.mp4 [00:29:22 CEST] <BtbN> that doesn't work with mp4, it will only "see" the first file [00:30:24 CEST] <tdr> on that page, it says "If you have MP4 files, these could be losslessly concatenated by first transcoding them to MPEG-2 transport streams. With H.264 video and AAC audio, the following can be used: ...." [00:30:52 CEST] <BtbN> well, remux, not transcode [00:31:13 CEST] <tdr> ok i just copied from the page [00:31:25 CEST] <BtbN> the page is wrong then and should be fixed [00:37:12 CEST] <killown> fahadash I have the sema issue [00:37:34 CEST] <killown> tdr, i did what you said and worked [00:37:44 CEST] <killown> but now some parts is playing very fast [00:40:31 CEST] <tdr> you mean using them via a list? they may need remux'd first or whatever. not sure, but BtbN agreed with that the page said about mp4 (even if the wording was off) [00:41:19 CEST] <BtbN> If the files are not all 100% identical, you cannot concat them without transcoding [00:41:45 CEST] <BtbN> you will at least have to transcode the file with the lower framerate [00:41:50 CEST] <BtbN> to match the other ones [00:46:17 CEST] <killown> BtbN, can you teach me how to do that? [00:46:21 CEST] <killown> transcoding [00:46:53 CEST] <BtbN> not at 1am, no [00:49:03 CEST] <killown> here is still 19:48 [00:49:05 CEST] <killown> hehehe [01:03:55 CEST] <Hello71> atomnuker: why wlstream is not work? wlstream 22 drm /dev/dri/renderD128 libx265 bgr0 12 /tmp/a.mkv gives "Failed to get hw device constraints!" [01:04:11 CEST] <Hello71> I think drm literally doesn't have that function [01:04:37 CEST] <Hello71> hm... what happens if I hardcode something stupid [01:05:07 CEST] <Hello71> but why is there no software encoding option [01:08:57 CEST] <killown> can anyone help me transcode videos to look all the same to later concatenate them? [01:54:41 CEST] <fahadash> I guess killown and I are looking for same thing [02:04:17 CEST] <fahadash> killown: I usually rotate 360 degrees and save as a different format and it transcodes for me :) [02:51:49 CEST] <Hello71> wat [03:20:37 CEST] <killown> lol [03:50:42 CEST] <killown> this is my issue http://wpbin.io/1vjs7k [03:51:05 CEST] <killown> the command is this ffmpeg -y -i 4.mp4 -r 25 -s 300x500 -c:v libx264 -b:v 3M -strict -2 -movflags faststart 4.mp4 [06:00:22 CEST] <fella> killown: Whoops, looks like something went wrong. <-- ( http://wpbin.io/1vjs7k ) [10:10:00 CEST] <GuiToris> hey, can I safely suspend an ffmpeg convertion by ctrl z? [12:11:08 CEST] <njoyce> Hi, I am building a custom RTMP server and am at the point where I have the separate video/audio streams. I want to use ffmpeg to consume the video stream and figure what the metadata of the video is (width, height, format, etc.) rather than relying on the RTMP client metadata. Can someone point me in the right direction of what ffmpeg api I can use to achieve this? [12:28:45 CEST] <matteo> which one should I prefer between nasm and yasm? [13:05:33 CEST] <durandal_1707> matteo: nasm [13:35:57 CEST] <GuiToris> durandal_1707, can I safely suspend an ffmpeg convertion by ctrl z or it'll mess it up [13:35:58 CEST] <GuiToris> ? [13:39:09 CEST] <durandal_1707> you can suspend it, it should not mess up [13:39:59 CEST] <GuiToris> thank you durandal_1707 [16:34:10 CEST] <King_DuckZ> hi, my code has problems reading frames from a webm file -> https://alarmpi.no-ip.org/kamokan/cs?colourless [16:35:26 CEST] <King_DuckZ> one function gets a request for a specific frame, in my case 161, then it converts that number to a pts and tries to find the corresponding frame in the source file but it misses it [16:40:04 CEST] <w1kl4s> try to search for frame nearest the timestamp [16:40:18 CEST] <w1kl4s> generally timestamps and exact frame timings don't like each other [16:40:22 CEST] <w1kl4s> learned it the hard way [16:40:53 CEST] <JEEB> King_DuckZ: if you need frame exact access use something like ffms2 [16:40:57 CEST] <King_DuckZ> this is the conversion functions I have https://alarmpi.no-ip.org/kamokan/ct?cc [16:41:47 CEST] <w1kl4s> multiplying frame rate by timestamp won't get you anywhere [16:41:47 CEST] <King_DuckZ> JEEB: I do, the whole interface works with "give me frame <X>" [16:41:51 CEST] <King_DuckZ> whats ffms2? [16:42:08 CEST] <JEEB> https://github.com/FFMS/ffms2 [16:42:15 CEST] <w1kl4s> Avisynth/Vapoursynth black magic [16:42:15 CEST] <JEEB> it's a frame-exact layer on top of FFmpeg's libraries [16:42:22 CEST] <JEEB> no need for avs/vapoursynth [16:42:27 CEST] <JEEB> it's also just a C library [16:42:29 CEST] <King_DuckZ> w1kl4s: I know, if I don't round up it breaks at frame 2 or 3, if I do round up it breaks at 161 [16:42:50 CEST] <w1kl4s> JEEB yeah but it's still black magic [16:42:56 CEST] <JEEB> suit yourself [16:43:11 CEST] <w1kl4s> I still try to install vapoursynth on linux with 2 goddamn plugins and it fails [16:43:24 CEST] <w1kl4s> i have like 3 lines of code why can't it just work [16:43:32 CEST] <w1kl4s> reee [16:44:52 CEST] <w1kl4s> However i think i got an idea what's wrong. If it fail with it again, do you mind if i PM you JEEB? [16:44:53 CEST] <King_DuckZ> interesting library, I'll give it a try thanks! [17:16:03 CEST] <King_DuckZ> before I pull in a new dependency, is there any risk in just choosing the closest PTS match? [17:17:00 CEST] <King_DuckZ> like in my case wanted_pts = 5339, I've got 5338 then 5371, so 5338 would be selected [20:01:31 CEST] <alexmarkley> so hey, everybody, here's a protip on something that just cost me like 6 hours of hair-tearing-out madness [20:01:41 CEST] <alexmarkley> if you're breaking up your audio and video decoders into separate threads [20:01:53 CEST] <alexmarkley> make sure you remember to give them their own AVFrame [20:01:58 CEST] <JEEB> uhh [20:02:03 CEST] <alexmarkley> because... otherwise it won't work at all [20:02:05 CEST] <JEEB> how do you even end up with the same AVFrame? [20:02:05 CEST] <JEEB> :D [20:02:12 CEST] <alexmarkley> haha it was, um, an oversight [20:02:15 CEST] <JEEB> same stack thing? [20:02:22 CEST] <JEEB> called from multiple threads or something like that? [20:02:29 CEST] <JEEB> I dunno how stack allocation works technically :P [20:02:36 CEST] <alexmarkley> i'm working in c++ and i have one big FFmpeg class [20:03:00 CEST] <alexmarkley> so i was pulling all of the per-decoder state into child classes and splitting the threaded worker in two [20:03:20 CEST] <alexmarkley> and i looked at `AVFrame *frame;` and i thought, "that's just for the video decoder, right?" [20:03:22 CEST] <alexmarkley> nope [20:03:30 CEST] <JEEB> lol [20:03:32 CEST] <alexmarkley> total brain fart [20:03:37 CEST] <JEEB> well, it happens [20:03:44 CEST] <JEEB> also as another protip, I recommend you use the newer APIs [20:03:51 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [20:03:57 CEST] <alexmarkley> valgrind had zero concerns about this situation [20:04:03 CEST] <JEEB> :D [20:04:14 CEST] <JEEB> you at least had valgrind around [20:04:29 CEST] <alexmarkley> i would have caught it eventually with helgrind but it never actually managed to run out to that point [20:04:44 CEST] <alexmarkley> so when you say "new APIs" you mean the refcounting frame stuff? [20:04:55 CEST] <JEEB> the push/pull stuff [20:04:59 CEST] <JEEB> where the two are separate [20:05:04 CEST] <JEEB> for decoding and encoding [20:05:09 CEST] <alexmarkley> yeah i wrote this code pretty recently, so i think i am using that [20:05:13 CEST] <JEEB> ok, cool [20:05:19 CEST] <JEEB> I linked to the doxygen page for that API [20:05:20 CEST] <JEEB> :) [20:05:49 CEST] <alexmarkley> ex. avcodec_receive_frame() right [20:05:50 CEST] <alexmarkley> ? [20:05:56 CEST] <JEEB> yup [20:06:01 CEST] <alexmarkley> and avcodec_send_packet() [20:06:05 CEST] <JEEB> yup [20:06:08 CEST] <alexmarkley> yeah that's how i built this app [20:06:13 CEST] <JEEB> alrighty then [20:06:31 CEST] <alexmarkley> https://github.com/markleybros/yer-face [20:06:47 CEST] <alexmarkley> i'm trying to get it as close to realtime as possible [20:07:05 CEST] <alexmarkley> (although it also has an offline processing mode for prerecorded video) [20:07:39 CEST] <alexmarkley> previously i was using an ffmpeg process to multiplex audio/video from hardware into a NUT container which i piped into my program [20:08:20 CEST] <alexmarkley> but in the quest for lower latency i am eliminating the separate ffmpeg process (and thus all the overhead of a needless muxing / demuxing process, plus whatever buffering unix pipes add) [20:09:15 CEST] <alexmarkley> the thing that shocks me, about accidentally sharing an AVFrame * between two threads, is that it never managed to corrupt a frame visibly or audibly [20:09:29 CEST] <alexmarkley> it just got really unstable :-P [22:43:36 CEST] <ahoo> hey there [22:43:46 CEST] <ahoo> i'm recording 720P from my webcam [22:44:12 CEST] <ahoo> i tried using x264 and x265 and both give good compression but very ugly quality (blurry, artifacts) [22:44:27 CEST] <BtbN> set a lower crf [22:47:50 CEST] <ahoo> oh yes, that fixes it. thanks bra [22:51:27 CEST] <ahoo> are there hardware encoders ffmpeg can use and take advantage of? [22:51:57 CEST] <ahoo> (except CPU/GPU features) [22:52:05 CEST] <furq> yes but if you care about quality then they're not going to help you [22:52:30 CEST] <ahoo> no, quality is fine with a lower crf [22:52:56 CEST] <ahoo> it's just& my cpu is barely managing to do the job [22:53:31 CEST] <ahoo> and i thought maybe you can outload the whole compression process into a hardware implementation of h264/5 [22:54:12 CEST] <ahoo> so what features are there? and what piece of hardware is required for it? [22:54:44 CEST] <ahoo> i remember back in the days when i had a video capturing card that, when recording live tv, there was almost null load on the CPU [22:54:48 CEST] <furq> nvenc and quicksync are supported [22:54:58 CEST] <furq> and amd's thing is sort of supported now [22:55:23 CEST] <BtbN> you don't just put x264 in hardware [22:55:34 CEST] <BtbN> all the hw encoders have a notably worse quality/bitrate ratio [23:02:57 CEST] <ChocolateArmpits> ahoo, have you tried using the -preset parameter to adjust performance? [23:04:26 CEST] <ahoo> ultrafast is the only preset that doesn't make ffmpeg drop frames continually [23:05:11 CEST] <ChocolateArmpits> ahoo, drop frames? What are you trying to do? [23:05:19 CEST] <ChocolateArmpits> oh webcam input [23:06:14 CEST] <ChocolateArmpits> maybe use some other type of realtime encoding that better fits your hardware, like mpeg2? [23:06:45 CEST] <ChocolateArmpits> do it at a high enough bitrate and you can transcode to h264 afterwards [23:06:52 CEST] <ChocolateArmpits> to save some space [23:07:32 CEST] <BtbN> ultrafast x264 is probably still better than mpeg2 by far [23:07:52 CEST] <BtbN> But if your CPU is shit enough to not handle 720p at veryfast, might as well use nvenc [23:08:02 CEST] <iive> maybe x264 have been compiled without simd? [23:08:18 CEST] <BtbN> Or it's a really bad CPU [23:08:36 CEST] <ChocolateArmpits> well if his CPU isn't up to the cast then I doubt he has a GPU that can encode anyhow [23:08:44 CEST] <ChocolateArmpits> task* [23:13:49 CEST] <ahoo> i3-6100 [23:16:51 CEST] <ahoo> cool. according to wikipedia my GT 1030 supports nvenc. [23:17:45 CEST] <BtbN> GT1030 only supports nvdec, no encoding. [00:00:00 CEST] --- Tue Oct 9 2018

1 0

ffmpeg-devel.log.20181007
by burek 08 Oct '18

08 Oct '18

[03:08:03 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:ad89e203bfed: avcodec/unary: Improve get_unary() docs [03:08:03 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:8c49340b189f: libavformat/ty: use decimal constant for shift [03:08:03 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:52e62b0585c1: avformat/movenc: Remove unneeded variable from mov_find_codec_tag() [03:08:03 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:8dd7c2c6a71b: avfilter/af_aiir: Remove l from %lf in av_log environment [03:08:03 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:64144158890b: avfilter/af_biquads: Remove l from %lf in av_log environment [03:08:03 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:1a7a17fb75e8: libavcodec/v4l2_buffers.h: fix cant typos [03:08:03 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:1fc3d8ee004a: avcodec/vc1_loopfilter: Fix colums typos [03:08:04 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:c07bbdbcf051: avfilter/vf_tonemap_opencl: Fix seperate typo [03:08:05 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:fd3eda40308e: avcodec/speedhq: Make speedhq_vlc const [03:08:06 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:beb3aea48e5f: avformat/utils: Do not ignore failure in extract_extradata_init() [03:08:07 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:b4a1ccfc4161: avformat/utils: Do not use "i" as a context pointer, "i" is normally the integer counter in loops [03:08:08 CEST] <cone-926> ffmpeg 03Michael Niedermayer 07master:0a41a8bf2945: avformat/utils: Fix potential integer overflow in extract_extradata() [05:23:28 CEST] <philipl> BtbN: reminder about header updates, and: https://github.com/philipl/FFmpeg/commits/master for the hevc 444 stuff. [10:06:47 CEST] <durandal_1707> michaelni: stop adding regressions with your "security" fixes ! [10:26:41 CEST] <BtbN> philipl, can you make it optionally load those functions, so it doesn't bump the driver requirement? It should be fairly easy to add runtime checks for the functions to exist. [10:41:17 CEST] <BtbN> There's already a macro for that that's used for one cuvid function [10:52:57 CEST] <BtbN> I also still think ffmpeg should gain a pix_fmt that has the right padding for most hw de/encoders. Yes, it's annoying, but that's how it is now. [11:02:43 CEST] <atomnuker> I think LSB padding makes more sense anyway [11:04:21 CEST] <BtbN> It's the one that enables you to just straight up use 10 bit as 12 or 16 bit I think? [11:04:44 CEST] <nevcairiel> the beauty of that padding is that you really dont need more then two formats [11:04:44 CEST] <BtbN> Which is exactly what the nvidia hardware does [11:04:49 CEST] <nevcairiel> one for 8, one for 16 [11:05:05 CEST] <nevcairiel> and you can square away the difference with an additional bitdepth argument [11:05:09 CEST] <nevcairiel> just like eg. audio [11:05:42 CEST] <BtbN> For ffmpeg that would still mean 3 new pix_fmts, even though they are technically identical, there is no other way to signal 10, 12 or 16 bits [11:17:54 CEST] <atomnuker> what for? extra info to do proper dithering? [11:23:45 CEST] <BtbN> Selecting the right encoder mode for example. [11:23:56 CEST] <BtbN> Otherwise it will always think it's getting 16 bit [11:24:54 CEST] <BtbN> We used to just use the 16bit format everywhere, but there were issues with that, and it was patched out [11:31:34 CEST] <atomnuker> ah, right [11:32:03 CEST] <nevcairiel> using an additional bitdepth argument would still be better tho [11:35:13 CEST] <atomnuker> we have one but its in avctx, not in avframes [11:38:19 CEST] <BtbN> An extra bit depth argument would seem confusing to me, given how the whole rest of ffmpeg communicates that via the pix_fmt [11:40:17 CEST] <nevcairiel> it only does that because noone bothered to clean it up p roperly [11:40:40 CEST] <nevcairiel> when all formats have identical layout anyway, using a bitdepth argument seems superior to me [11:41:29 CEST] <BtbN> True. It's just the P16 variant. So the bitdepth argument would just have to be added to AVFrame, and maybe some other places. [11:41:42 CEST] <BtbN> If it's unset, assume 16 bit, or whatever the format says [11:42:54 CEST] <nevcairiel> audio uses avctx->bits_per_raw_sample for that same purpose, ie. 20 and 24-bit audio is all put into S32 format [11:43:00 CEST] <nevcairiel> but yeah its not in avframe apparently [12:18:52 CEST] <BtbN> atomnuker, I can't see a bit depth in AVCodecContext either? [12:19:10 CEST] <nevcairiel> see two lines above, its bits_per_raw_sample [12:19:44 CEST] <nevcairiel> * Bits per sample/pixel of internal libavcodec pixel/sample format. [12:19:48 CEST] <nevcairiel> even has the proper docs [12:20:01 CEST] <cone-339> ffmpeg 03Paul B Mahol 07master:9c120b4d4201: avfilter/avf_showspectrum: add legend support to showspectrum filter [12:20:10 CEST] <BtbN> oh, thought that only applied to audio [12:20:19 CEST] <nevcairiel> its only really used for audio now [12:20:34 CEST] <nevcairiel> but no reason to make another one [12:20:46 CEST] <BtbN> yeah, it matches video just fine [12:21:12 CEST] <BtbN> Does audio just not communicate it on a per-frame level at all? [12:21:19 CEST] <nevcairiel> apparently not [12:21:52 CEST] <BtbN> Tempting to just copy bits_per_raw_sample over there [12:22:10 CEST] <nevcairiel> could use a rename, that name is a bit weird [12:23:01 CEST] <BtbN> A bit on the audio side of things [12:23:17 CEST] <BtbN> It does describe the meaning of the field pretty well though [12:26:27 CEST] <atomnuker> well having a per-frame bits per sample would go part of the way to simplifying [12:26:33 CEST] <BtbN> A problem I see is format selection for encoders. How would for example nvenc communicate that it cannot take 12 and 16 bit, but only 10 bit on 444P16 [12:26:51 CEST] <atomnuker> a new field to indicate accepted bit depths? [12:27:03 CEST] <atomnuker> like encoder's acceptable samplerates [12:27:06 CEST] <BtbN> The accepted bit depths vary per pix fmt [12:27:16 CEST] <JEEB> yea, they'd have to be in a struct [12:27:21 CEST] <JEEB> pic_fmt + bit depth [12:27:32 CEST] <BtbN> Or a callback querying if it's supported [12:27:37 CEST] <JEEB> yea [12:28:14 CEST] <BtbN> I still feel like just adding those padded formats as new pix_fmts would be less error prone [12:28:35 CEST] <JEEB> yes, it would be the simplest way out according to what we have at the moment, that I do agree on [12:29:39 CEST] <JEEB> also this somehow reminded me that I wanted to make libx264 update its colorspace information according to AVFrames fed in encode() [12:29:48 CEST] <JEEB> I tried to do that earlier but never got it to work [12:30:19 CEST] <JEEB> since after init() you still haven't written anything, so in theory if you get the data only at encode() it should still be possible :V [16:40:25 CEST] <philipl> BtbN: ok. I'll look at conditional loading. [16:41:09 CEST] <BtbN> It's just a minimal change, there's a macro for it, and then one check before using them [16:41:28 CEST] <philipl> What's the punchline on the pix fmt stuff? Are you with it as just P16 or do you want the pixfmts added? [16:41:43 CEST] <BtbN> I kinda want them added, everything else seems like a horrible mess [16:42:14 CEST] <BtbN> Using an additional varible to indicate the bitness would make sense, but it would involve a huge bunch of code changes all over the place, even down into client apps [16:42:32 CEST] <BtbN> a couple new _LSB pix fmts don't seem so bad in comparison [16:42:42 CEST] <JEEB> and at that point you might as well go for structs [16:42:47 CEST] <philipl> yeah. and I don't want to block this work on doing that. [16:43:03 CEST] <philipl> ok. [17:38:39 CEST] <philipl> BtbN: Updated the header diff. I'll push if you're happy [17:42:11 CEST] <BtbN> yeah, looks ok [17:43:42 CEST] <philipl> Thanks. [17:43:52 CEST] <cone-701> ffmpeg 03Paul B Mahol 07master:3d308746eb45: avfilter/af_afade: add logistic sigmoid curve [17:48:32 CEST] <philipl> done [19:26:17 CEST] <philipl> BtbN: remind me what the scenario is where the copy-to-main-memory path is taken inside cuviddec? I need to test my changes here. [19:26:25 CEST] <philipl> I can't get it to trigger. [19:27:04 CEST] <philipl> It seems to also end up using the hwcontext transfer path [19:27:09 CEST] <philipl> s/also/always/ [19:39:59 CEST] <durandal_1707> i have nothing left to do/play [19:45:35 CEST] <jamrial> durandal_1707: give yuvj a killing blow [19:46:17 CEST] <durandal_1707> i wish i could, but there is strong oposition [19:47:03 CEST] <BtbN> philipl, when not CUDA is requested from it. [19:47:10 CEST] <BtbN> Not passing any hwaccel to ffmpeg.c should do that? [19:49:51 CEST] <jamrial> durandal_1707: what oposition? other than reported regressions in some command lines i haven't seen people against it [19:50:07 CEST] <JEEB> yea I don't think people are against it at all [19:50:14 CEST] <JEEB> it's just that fixing all the issues is gonna need busywork [19:52:56 CEST] <atomnuker> yeah, no one objected afaik, koda mentioned that he'd like every single property to be negotiated (iirc) but having yuvj removed goes part of the way [19:55:30 CEST] <durandal_1707> libswscale becomes monstrosity [19:57:16 CEST] <atomnuker> it needs to get replaced anyway [19:58:00 CEST] <durandal_1707> atomnuker: replaced? with what? don't be funny! [20:01:23 CEST] <philipl> BtbN: Thanks. So my copy-out logic in the patchset isn't right yet. [20:40:29 CEST] <cone-701> ffmpeg 03Marton Balint 07master:0e9a09793a98: avfilter/af_afade: fix crossfade duration maximum value [20:40:31 CEST] <cone-701> ffmpeg 03Marton Balint 07master:3bfd409e59e8: avformat/segment: fix segment_time_delta option min/max value [20:40:31 CEST] <cone-701> ffmpeg 03Marton Balint 07master:d40dc64173a1: avutil/opt: check for minimum and maximum values when setting AV_OPT_TYPE_DURATION fields [20:40:32 CEST] <cone-701> ffmpeg 03Marton Balint 07master:4c777d52b9b1: avutil/parseutils: fix some overflows in duration calculations [20:40:33 CEST] <cone-701> ffmpeg 03Marton Balint 07master:416804fe4120: avutil/tests/parseutils: add some big duration tests [20:45:24 CEST] <cone-701> ffmpeg 03Dave Rice 07master:1431ff2d379e: ffplay: add options to specify window position [21:39:58 CEST] <BtbN> philipl, I'll wait for confirmation of the next pix_fmts first. [22:59:15 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:1a4a6d94ccb9: avutil/pixfmt: Document chroma plane size for odd resolutions [22:59:16 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:cec6df48ba89: swresample/swresample: Fix input channel count in resample_first computation [22:59:17 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:f291acafbb30: avcodec/diracdec: Prevent integer overflow in intermediate in global_mv() [22:59:18 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:8147da2bad1b: avcodec/dirac_dwt_template: Fix several integer overflows in horizontal_compose_daub97i() [22:59:19 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:88093d2c1fbb: avcodec/diracdec: Change frame_number to 64bit as its a 32bit from the bitstream and we also have a -1 special case [22:59:20 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:6cf72a56e7e6: avcodec/diracdec: Check slice numbers for overflows in relation to picture dimensions [22:59:21 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:4f51a21c30c6: avcodec/diracdec: Check bytes count in else branch in decode_lowdelay() too [22:59:22 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:f9235773d60b: avcodec/qtrle: Check remaining bytestream in qtrle_decode_XYbpp() [22:59:23 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:07255282d0ba: avcodec/mlp_parser: Check if synccode is within buffer [22:59:24 CEST] <cone-701> ffmpeg 03Nikolas Bowe 07release/4.0:8591d16ce5f8: lavc/svq3: Fix regression decoding some files. [22:59:25 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:386975d7a4aa: avformat/flvenc: Check audio packet size [22:59:26 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:cc0817af0d66: avcodec/aacpsdsp_template: Fix integer overflow in ps_stereo_interpolate_c() [22:59:27 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:c0a6febf3231: avcodec/mpegaudio_parser: Initialize poutbuf* [22:59:28 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:2c3ea340826a: avcodec/shorten: Check verbatim length [22:59:29 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:32353f8bcbb4: avcodec/shorten: Fix integer overflow in residual/LPC combination [22:59:30 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:cd42c19f53de: avcodec/shorten: Fix signed 32bit overflow in shift in shorten_decode_frame() [22:59:31 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:b95c209a6108: avcodec/scpr: Check for min > max in decompress_p() [22:59:32 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:3f095c5b56ba: avformat/rmdec: Fix EOF check in the stream loop in ivr_read_header() [22:59:33 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:0f36c5f5c776: avformat/mlvdec: read_string() received unsigned size, make the argument unsigned [22:59:34 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:f2b51fd54c44: avformat/dashdec: Fix strlen(rep_id_val) with it being NULL [22:59:35 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:6e60a38322d1: avformat/nsvdec: Do not parse multiple NSVf [22:59:36 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:ce828a247d5f: avcodec/mpeg4videodec: Fix slice end detection in mpeg4_decode_studio_mb() [22:59:37 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:a04ff0c054e8: avcodec/snowdec: Fix integer overflow with motion vector residual [22:59:38 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:229025799f62: avcodec/vb: Check for end of bytestream before reading blocktype [22:59:39 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:8327559fe80d: avcodec/hq_hqa: Check remaining input bits in hqa_decode_mb() [22:59:40 CEST] <cone-701> ffmpeg 03Michael Bunk 07release/4.0:84ab680624e8: examples: Fix use of AV_CODEC_FLAG_GLOBAL_HEADER [22:59:41 CEST] <cone-701> ffmpeg 03Dale Curtis 07release/4.0:968ffb93af04: avformat/mov: Error on too large stsd entry counts. [22:59:42 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:17a5df4ab8c6: avcodec/indeo4: Check dimensions in decode_pic_hdr() [22:59:43 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:318b13a5adb3: avcodec/ra144: Fix undefined integer overflow in add_wav() [22:59:44 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:7da37aa9804a: avcodec/h264_refs: Document last if() in ff_h264_execute_ref_pic_marking() [22:59:45 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:9afcf994f6f7: avcodec/dvdsubdec: Avoid branch in decode_run_8bit() [22:59:46 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:6d2b2ee3a53a: avcodec/shorten: Fix bitstream end check in read_header() [22:59:47 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:5af88171e738: avcodec/zmbv: Update decomp_len in raw frames [22:59:48 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:47f608a7e146: avcodec/zmbv: Check that the decompressed data size is correct [22:59:49 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:5a4234de5eb3: avcodec/mpeg4videodec: Fix undefined shift in get_amv() [22:59:50 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:1a05e6ced3dc: avcodec/dvdsubdec: Sanity check len in decode_rle() [22:59:51 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:f645fd64c3f3: doc/examples/vaapi_transcode: Fix the typo [22:59:52 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:45fb50b4bc5d: avcodec/eac3dec: Check that channel_map does not contain more than EAC3_MAX_CHANNELS [22:59:53 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:d7973cf03d07: avcodec/ac3dec: Fix shift signedness in mask creation [22:59:54 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:531ebb7506fd: avcodec/gdv: Replace divisions by shifts in rescale() [22:59:55 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:7f521fae2b1f: avcodec/unary: Improve get_unary() docs [22:59:56 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07release/4.0:eb495b20e51f: avformat/utils: Fix potential integer overflow in extract_extradata() [23:07:11 CEST] <philipl> BtbN: K. [00:00:00 CEST] --- Mon Oct 8 2018

1 0

ffmpeg.log.20181007
by burek 08 Oct '18

08 Oct '18

[04:01:45 CEST] <velix> Anyone with an idea, how to scan a complete file using ffmpeg -i? Actually, I've got a VBR file and want to get the real average bitrate. [04:01:54 CEST] <velix> Right now, it only seems to touch the file. [04:09:37 CEST] <velix> maybe -analyzeduration 1000000000 [05:08:24 CEST] <mixfix41> my vcr script ffmpeg command is way too bloated [05:08:47 CEST] <mixfix41> and quality is way less visually but i think the audio is very good thats why [05:08:59 CEST] <mixfix41> compared to simplescreenrecorder anyways [05:09:11 CEST] <mixfix41> brb [12:01:14 CEST] <ChrisWarrick> Oh hi, that channel exists [12:02:03 CEST] <ChrisWarrick> I have a file that is multiple tracks merged into one file. I also have a track list with start times (h:m:s). How can I use ffmpeg to split that file into many? [13:02:20 CEST] <ChrisWarrick> ffmpeg -ss START_TIME_IN_SECONDS -t DURATION -i all.mp3 -acodec copy 01.mp3 [15:54:24 CEST] <onodera> Hi, I have some flac files that I want to convert to ogg, and I also want to add an external cover.jpg file to the ogg metadata, is this possible? [15:54:55 CEST] <onodera> I figured out the first part using `ffmpeg -i $i -i cover.* -c -codec:a libvorbis -qscale:a 6 $o`, however, I'm kind of stuck with the album art part [15:57:49 CEST] <furq> cover art in ogg isn't supported yet [15:58:01 CEST] <furq> there's been an open feature request for it for a few years [15:58:27 CEST] <furq> you'd be better off using opusenc [15:58:50 CEST] <onodera> ahh okay, thanks [15:58:55 CEST] <furq> or oggenc if you really want to use vorbis [15:59:21 CEST] <onodera> nah I thought ogg was the best [15:59:35 CEST] <furq> opus is the successor to vorbis [15:59:37 CEST] <onodera> *vorbis, seems like opus was designed to replace it though [15:59:40 CEST] <furq> yeah pretty much [16:25:07 CEST] <dalu> Alright I'm trying to convert a .mp3 file to a .m3u8 playlist, and encrypt it with aes-cbc. `ffmpeg -i 3.mp3 -c copy -hls_time 10 -hls_key_info_file 3.info playlist.m3u8` and that works, as in various .ts files are created. However the playlist.m3u8 file only has like 5 of those .ts files there. [16:26:12 CEST] <furq> dalu: -hls_list_size 0 [16:26:25 CEST] <dalu> furq, thanks I'll try [16:27:12 CEST] <furq> or i guess -hls_playlist_type vod is the correct way to do it [16:27:16 CEST] <dalu> nice! thanks so much :) [16:27:26 CEST] <furq> not sure how much difference it makes [16:27:41 CEST] <dalu> I'll try that too, do the other options fall off? [16:27:55 CEST] <furq> that will set hls_list_size to 0 anyway [16:27:59 CEST] <dalu> aka is this then the only hls option that's used? [16:28:08 CEST] <furq> no [16:28:15 CEST] <furq> !muxer hls @dalu [16:28:16 CEST] <nfobot> dalu: http://ffmpeg.org/ffmpeg-formats.html#hls-2 [16:28:23 CEST] <dalu> ty [16:32:47 CEST] <Zexaron> Hello [16:32:58 CEST] <Zexaron> is ffmpeg able to stream like OBS for twitch ? [16:33:45 CEST] <Zexaron> on windows, plus, fullscreen? [16:34:19 CEST] <Zexaron> nevermind about fullscreen, I mixed something up [16:41:50 CEST] <ChocolateArmpits> Zexaron, should be no problem, though I think screen capture may be sluggish depending on your setup [16:42:50 CEST] <Zexaron> This is actually intergrating ffmpeg, first it's just offline dump, wondering if it's possible to integrate ffmpeg with a 3D program in a way that it would produce the relative correct output, if the FPS drops (makes the sound also go slower) then that fps drop wouldn't be there on the offline video [16:43:07 CEST] <Zexaron> Or is it possible to do this on the offline video later as a second step ? [16:43:34 CEST] <ChocolateArmpits> you shouldn't call VODs "offline video" [16:44:09 CEST] <Zexaron> Heh, sorry, not talking about VODs anymore, that would be separate step anyway, not trying to make a OBS competitor [16:44:26 CEST] <Zexaron> That's a lower priority task [16:45:12 CEST] <Zexaron> I was just thinking of some kind of ability, for the user to set it up, or some kind of preset script, if OBS isn't working for them for some reason, but offline dumping is primary as it's about max quality [16:46:12 CEST] <Zexaron> Not that about quality, the current implementation is buggy, unstable, producing bad codec integrity, etc, doesn't work with dual core good, etc [16:46:36 CEST] <ChocolateArmpits> Your "3d applications" are games, right? [16:47:27 CEST] <Zexaron> I should have mentioned in the beginning what I'm talking about, sorry, https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/… [16:49:26 CEST] <JEEB> I would start with having something out of your primary thread being able to take in RGB pictures in a non-blocking way (you probably need to have a buffer of them or something with a max or whatever) [16:49:46 CEST] <JEEB> then after that you can look into libplacebo for RGB<->YCbCr conversions on the GPU [16:49:57 CEST] <JEEB> because for some formats you want RGB as-is, and others you want YCbCr [16:50:19 CEST] <JEEB> and you probably want it to be done on the GPU as to not block the CPU [16:51:00 CEST] <JEEB> then, finally, you have an output AVFormat and AVCodec contexts which you initialize for the video encoder and muxer you want, and encode/write stuff [16:51:31 CEST] <JEEB> feeding into streaming services with RTMP shouldn't really be a problem since a lot of people already do that with libavformat [16:51:38 CEST] <JEEB> but for that you need H.264 of course [16:51:54 CEST] <JEEB> which can either be a hardware ASIC encoder, or x264 with a very fast preset [16:52:09 CEST] <JEEB> for offline archiving on the other hand a fast encoding lossless encoder might be preferred [16:52:13 CEST] <JEEB> maybe even in RGB [16:54:35 CEST] <Zexaron> Yeah, users have tried using other codecs that the current system doesn't support (custom built libs) so the first step was to get it upgraded and updated , then I can finally do something about the actual framedumping improvements, as it is (historically) called [16:55:26 CEST] <Zexaron> That upgrade is like this: https://github.com/dolphin-emu/dolphin/pull/7110 [16:57:26 CEST] <Zexaron> But it's the users who are all trying to get max offline quality, they're not that about streaming, the ones that stream just use OBS already probably [16:57:47 CEST] <Zexaron> JEEB: You mean different games would need YCbCr or what's the reason, I don't understand at this moment. [16:58:02 CEST] <JEEB> dpeending on what you want or what your output requirements are [16:58:13 CEST] <JEEB> for example streaming into a service you need to keep it YCbCr, 4:2:0 and H.264 [16:58:27 CEST] <JEEB> while for offline archival you might want either 4:4:4 YCbCr or RGB [16:59:35 CEST] <JEEB> anyways, if people care about high quality archival recordings then that's almost fully something lossless, so compression ratios don't really matter [16:59:45 CEST] <JEEB> be it RGB or YCbCr [17:02:44 CEST] <Zexaron> Oh, that, in this case the users asked and talked about quality, now I started recalling, someone even wanted Lagarith codec support, it's probably not hard to do both so it'll be an option, switch, but I guess full RGB will be the default [17:02:58 CEST] <JEEB> not sure how quick lagarith is [17:03:06 CEST] <JEEB> I recommend benchmarking a few lossless encoders [17:03:16 CEST] <furq> i don't think ffmpeg has a lagarith encoder [17:03:34 CEST] <furq> there's not really any reason to use it these days though [17:03:38 CEST] <JEEB> ffvhuff, ut video (this one has actual support in video editors funny enough), ffv1 and libx264's lossless mode [17:03:49 CEST] <furq> and magicyuv now as well [17:03:52 CEST] <Zexaron> Codec support wasn't a Dolphin limitation, just a lib limitation, if they have the speed they can use any codec the official ffmpeg DDLs will provide, now that it's going to be switched to the full blown DLLs [17:04:26 CEST] <furq> apparently magicyuv does rgb because names mean nothing any more [17:04:28 CEST] <Zexaron> From Zeranoe, for windows, this doesn't apply to other OS, they ffmpegs are managed by the OS, not Dolphin [17:11:33 CEST] <analogical> I'm curious. How come it's possible to play back incomplete MKV video files but not incomplete MP4 video files? [17:12:02 CEST] <JEEB> index which usually also contains the decoder initialization stuff generally can only be fully written at the end of a thing [17:12:20 CEST] <JEEB> you can help that with fragmented mp4 [17:12:49 CEST] <analogical> fragmented mp4? [17:12:49 CEST] <JEEB> also another way is that after you once write the mp4 file, you then do another pass and move the required thing into the front of the file [17:12:55 CEST] <JEEB> since you then know all the packets' sizes etc [17:13:01 CEST] <JEEB> aka the content of the mp4 file [17:13:19 CEST] <JEEB> analogical: movie fragments for f.ex. each GOP instead of one big index [18:13:13 CEST] <keglevich> ffmpeg -re -i 1.mp4 -g 50 -c:v libx264 -preset veryfast -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -ac 2 -b:a 192k -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316" [18:13:21 CEST] <keglevich> running the command above gives somehow CBR UDP multicast stream, but it's not perfect (lots of bursts, spikes, etc.), nothing similar to those generated by hardware encoders...is there anything I can do to improve it? [18:43:44 CEST] <ChocolateArmpits> keglevich, Is there a general upper limit in terms of bitrate that you see? [18:55:02 CEST] <fahadash> Trying to concat 3 videos using a concat.txt file all are MOV files, different frame width and heights https://pastebin.com/c8tzqeh1 [18:55:08 CEST] <fahadash> I got a ton of errors [18:55:31 CEST] <fahadash> How do I resolve this? [18:55:56 CEST] <durandal_1707> fahadash: you cannot use concat demuxer with differrent sizes, this is in documentation [18:56:31 CEST] <fahadash> What are alternate ways to concat? just may be add paddings around the smaller frames to fit the size of the largest one? [18:57:16 CEST] <durandal_1707> you can not concat without transcoding [18:57:42 CEST] <ChocolateArmpits> fahadash, you could first convert each separately to a common standard frame option and then do it [18:57:44 CEST] <durandal_1707> for concat with transcoding use concat filter [18:58:40 CEST] <durandal_1707> ChocolateArmpits: that is nothing better than using concat filter and rescaling videos [18:58:47 CEST] <fahadash> The other two clips are the zoomed in and cropped pieces of the first clip. May be I should rezoom and crop to keep the same size [19:03:58 CEST] <ChocolateArmpits> durandal_1707, well if there are lots of files, then a long command line may not be appropriate [19:05:19 CEST] <durandal_1707> ChocolateArmpits: really, so you prefer one which takes extremly long time? [19:07:12 CEST] <ChocolateArmpits> durandal_1707, windows has a limit for command line length so.... [19:08:15 CEST] <durandal_1707> ChocolateArmpits: you can use text files to specify filtergraph so ..... [19:08:32 CEST] <ChocolateArmpits> durandal_1707, sad you can't specify inputs with a text file so.... [19:08:43 CEST] <durandal_1707> you can [19:08:59 CEST] <ChocolateArmpits> can you point me? [19:09:31 CEST] <durandal_1707> -filter_complex_script [19:10:12 CEST] <ChocolateArmpits> the inputs as a text file I mean [19:13:36 CEST] <durandal_1707> ChocolateArmpits: that is very easy to add [19:14:16 CEST] <keglevich> ChocolateArmpits: why would bitrate upper limit matter? [19:14:37 CEST] <ChocolateArmpits> keglevich, maybe it's predictable and you may only need to set a higher muxrate ? [19:14:41 CEST] <keglevich> ChocolateArmpits: buy yes, upper limit for this particular stream is 2.6mbit7s [19:15:03 CEST] <keglevich> in other words...set lower video bitrate? [19:15:38 CEST] <ChocolateArmpits> I'd certainly try hammering all the available options and setting a lower bitrate may be just that [19:16:51 CEST] <keglevich> ChocolateArmpits: i have also tried that already, and numerous other options as well...but it just seems CBR encoding ins't the main issue... the main issue seems to be UDP output mpegts which goes out in some kind of bursts...it seems that it send data as soon as it's available, or something... [19:17:16 CEST] <keglevich> having a decent CBR UDP output would probably solve that...but so far it seems impossible to me [19:19:06 CEST] <JEEB> I think the UDP thing tried to control the mux rate if you set it, and then IIRC with UDP output people set the packet size or whatever it was to a multiple of 188 [19:19:27 CEST] <JEEB> both of those IIRC required threading to be enabled in FFmpeg [19:19:44 CEST] <JEEB> or well, the muxrate thing I think required? [19:20:03 CEST] <keglevich> yes...pkt_size is 1316 (7x 188bits) required by HW encoders...this works ok [19:20:31 CEST] <keglevich> pkt_size is accepted as well with w32threads version....bitrate output parameter need ptrheads, but it has issues, I already tried it [19:21:16 CEST] <JEEB> I don't think there should be much in there specifically needing pthreads? [19:21:26 CEST] <JEEB> unless someone didn't update the ifdefs [19:22:03 CEST] <keglevich> "bitrate" UDP output parameter requires ptrheads for some reason...it won't work without [19:22:38 CEST] <keglevich> therefore I compiled latest trunk with pthreads to test it...but it has issues, it crashes a lot with "cannot allocate memory" [19:22:55 CEST] <keglevich> but yes, UDP output with that parameter is much better than with w32threads version [19:23:08 CEST] <keglevich> so I'm looking a solution with w32threads if possible, as it's stable [19:23:09 CEST] <ChocolateArmpits> keglevich, what are you using to compile? [19:23:16 CEST] <JEEB> right, it requires pthread_cancel... I wonder if the pthreads wrapper that we have for win32 works for that :P [19:23:18 CEST] <keglevich> media-autosuite-builte [19:23:21 CEST] <JEEB> and someone just didn't update the deps [19:23:53 CEST] <JEEB> anyways unfortunately I don't want to look into this too much since UDP+windows is not on my care level right now [19:23:56 CEST] <furq> does ffmpeg have its own pthread wrapper [19:24:01 CEST] <JEEB> yes [19:24:02 CEST] <keglevich> I only haven't tried it on linux yet...there pthreads are native? [19:24:06 CEST] <furq> or do you mean the one in mingw64 [19:24:08 CEST] <JEEB> that's the win32 threads [19:24:34 CEST] <JEEB> furq: I think it just wraps the NT6+ threading things now [19:24:38 CEST] <ChocolateArmpits> keglevich, I'm using msys2 with mingw64 and had no problems [19:25:08 CEST] <keglevich> that media-autobuild-suite also uses mingw64... [19:25:21 CEST] <keglevich> does ffmpeg on linux by default use pthreads? [19:25:26 CEST] <JEEB> of course [19:25:33 CEST] <keglevich> so I can try that same thing there to see if it also crashes [19:25:45 CEST] <keglevich> if not then it's probably windows issue with ptrheads? [19:25:49 CEST] <JEEB> furq: seems to be a really lightweight wrapper around the nt6+ things [19:26:04 CEST] <JEEB> keglevich: it could be an issue with the pthreads wrapper you're using on your mingw-w64 thing too [19:26:07 CEST] <JEEB> I dunno [19:26:18 CEST] <JEEB> without any details it's hard to say one way or another :P [19:26:22 CEST] <keglevich> so if I cross-compile it on linux, it could be different? [19:26:45 CEST] <JEEB> yes, esp. if you use a different mingw-w64 version or different pthreads wrapper if you want to utilize pthreads on windows [19:27:00 CEST] <JEEB> I'd almost just implement the cancel function in the w32pthreads thing [19:27:04 CEST] <JEEB> to be honest [19:27:11 CEST] <keglevich> is there a simple way to compile v4.0 for instance, x86 build for windows on linux? [19:27:35 CEST] <furq> like i said before it's not that difficult if the only external lib you need is x264 [19:28:20 CEST] <JEEB> but yea, I have no idea what pthread_cancel is, but unless it's really complex it might be worth it to just implement it in w32pthreads.h [19:28:37 CEST] <JEEB> that said, it's sunday and I don't use that feature on windows so E_NOCARE [19:28:56 CEST] <JEEB> just saying that might be better than trying random versions of pthreads wrappers :P [19:29:10 CEST] <furq> pthread_cancel may or may not stop a thread [19:29:21 CEST] <furq> great! [19:29:57 CEST] <keglevich> is there an option for someone to implement this to w32threads? I don't have the knowledge to do it [19:30:17 CEST] <furq> just cross-compile with pthreads [19:30:37 CEST] <furq> or --disable-w32threads [19:30:47 CEST] <JEEB> there's always the possibility - make an issue on the tracker about it and hope someone cares enough? [19:30:54 CEST] <JEEB> if you have budget you could also sponsor someone :P [19:31:05 CEST] <keglevich> yes, that's what I used on windows when compiling...but the result was (as said) always an issue... [19:31:36 CEST] <furq> if it doesn't work with a --disable-w32threads build then it's probably not going to work at all [19:31:42 CEST] <keglevich> the build with pthreads works fine as soon as you don't add "bitrate=2600000" output UDP parameter to my command above... [19:32:14 CEST] <keglevich> also, there's "burst_bits", but I don't know which value should be set to that one? [19:32:29 CEST] <keglevich> whichever value I set, it crashes after some mins with "cannot allocate memory" fatal error [19:32:47 CEST] <JEEB> furq: he hasn't provided a backtrace nor anything else so you can't really say jack shit :D [19:33:02 CEST] <JEEB> other than "maybe your pthreads wrapper sucks, maybe?" [19:33:07 CEST] <furq> i mean i probably couldn't say anything with a backtrace [19:33:37 CEST] <keglevich> how can I provide backtrace? [19:33:41 CEST] <JEEB> although if it just fails at some memory allocation fuck if I know [19:33:42 CEST] <furq> gdb [19:33:46 CEST] <JEEB> keglevich: run under gdb? [19:33:53 CEST] <keglevich> how is this done? [19:34:02 CEST] <furq> all i know is that people who know more than me about the topic (e.g. Mavrik) have said this use case doesn't work at all [19:34:17 CEST] <JEEB> the UDP thing does work to a level [19:34:32 CEST] <JEEB> it's not that. I mean it's imperfect but it seems to work for various people to a level :P [19:34:40 CEST] <JEEB> but > windows > random pthreads wrappers [19:34:49 CEST] <furq> i'm fortunate to not need to give a shit about true cbr mpegts output [19:35:04 CEST] <JEEB> I don't even think you need true CBR [19:35:13 CEST] <JEEB> you just need to keep the bits flowing relatively smoothly [19:35:29 CEST] <JEEB> how smoothly depends on how retarded your receiver side is [19:35:36 CEST] <keglevich> it's a requirement by our IPTV client...perfect CBR, percfect PCR < 30ms, right PID's, etc... [19:35:40 CEST] <JEEB> and on how bad your network equipment is [19:35:49 CEST] <JEEB> "perfect CBR" [19:35:54 CEST] <JEEB> please define [19:36:02 CEST] <JEEB> like seriously, people keep saying that but never define it [19:36:11 CEST] <keglevich> straight 2.6mbit/s line in mpegts analyzer, without and jumps [19:36:23 CEST] <keglevich> without any bursts...something that all hw encoders can generate [19:36:28 CEST] <JEEB> whatever that means [19:36:43 CEST] <keglevich> like 2.1mbit/s video bitrate...padding up to 2.6mbit/s [19:36:57 CEST] <JEEB> yea it's clear you don't know the specifics [19:37:04 CEST] <JEEB> you just look at a piece of software [19:37:06 CEST] <keglevich> it's somehow there, but it jumps +-10% and it seems no parameter can solve this in ffmpeg [19:37:51 CEST] <keglevich> I can check other UDP streams from out provider in the same network...TV channels....more or less all are clear perfect CBR [19:37:59 CEST] <keglevich> but all are HW-encoders generated [19:38:08 CEST] <keglevich> so I'm trying to achieve the same with ffmpeg [19:38:11 CEST] <keglevich> if it's possible [19:38:20 CEST] <JEEB> anyways, I know that lavf's muxer is not perfect but I also know people make stuff with lavf that is "good enough" [19:38:26 CEST] <JEEB> since some people have mentioned it [19:38:37 CEST] <JEEB> with the muxrate over at MPEG-TS and bitrate over at UDP [19:38:40 CEST] <keglevich> what is lavf? [19:38:43 CEST] <JEEB> libavformat [19:38:50 CEST] <JEEB> the demuxing/muxing library in FFmepg [19:39:06 CEST] <keglevich> I should only use mpeg2video for some streams and x264 for others [19:39:39 CEST] <JEEB> also funny enough I can't find my gdb binary that I was going to link :P [19:39:54 CEST] <JEEB> ah yes [19:40:23 CEST] <JEEB> https://kuroko.fushizen.eu/random/gdb_builds/gdb-8.0.1.7z [19:40:25 CEST] <JEEB> there you go [19:40:29 CEST] <keglevich> strange is...if I output my current stream to a file (i.e. test.mp4) and play it in VLC later, it's really nice CBR...but if I output direct to -f mpegts output, it jumps a bit up and down all the time [19:40:47 CEST] <keglevich> seems like UDP output does shitty job there, not muxer itself [19:41:23 CEST] <JEEB> well since you're not using teh feature that you can't have without pthread_cancel?! [19:41:32 CEST] <JEEB> just fucking test with native linux first [19:41:43 CEST] <keglevich> that's what I'm going to do now [19:41:43 CEST] <JEEB> *then* you know it works well enough and you can try making it work on windows [19:41:55 CEST] <keglevich> exactly... [19:42:02 CEST] <JEEB> just build FFmpeg on linux for linux [19:42:05 CEST] <keglevich> how can I use the gbd.exe binary you provided to test ffmpeg? [19:42:16 CEST] <JEEB> http://www.unknownroad.com/rtfm/gdbtut/ [19:42:24 CEST] <keglevich> is it good enough if I just use ubuntu and install the bundled ffmpeg? [19:42:27 CEST] <JEEB> tl;dr is "gdb path\to\ffmpeg.exe" [19:42:46 CEST] <JEEB> the bundled FFmpeg is old, but I think 18.10 should have FFmpeg 4 I think? [19:42:47 CEST] <keglevich> so I don't need to compile it manually [19:43:05 CEST] <JEEB> not like compiling FFmpeg if you only need libx264 or so externally is hard, thankfully :) [19:43:18 CEST] <keglevich> I'll try as you suggested and I'll report back with backtrace logs of gdb and with results on linux! [19:43:41 CEST] <JEEB> just test with linux first, 18.10 seems to have a relatively new FFmpeg [19:43:59 CEST] <keglevich> ok, I'll report back...thanks for help! [19:44:04 CEST] <JEEB> and you can of course build FFmpeg by just having pkg-config and nasm and the x264 -dev package installed [19:44:19 CEST] <JEEB> (and the build-essential package of course with the compiler etc) [19:44:40 CEST] <keglevich> what's the easiest way to cross-compile win x86 shared binaries there as well? [19:45:02 CEST] <JEEB> no idae, I just usually use the bundled mingw-w64 toolchain with some tweaks. but that's probably not the simplest way :P [19:45:08 CEST] <JEEB> so stay focused on testing linux first [19:45:12 CEST] <keglevich> ok [20:24:21 CEST] <DapOrp> I'm trying to test streaming a video file from one computer to another on my LAN, I'm using the command: ffmpeg -re -i out.mp4 -f mpegts udp://192.168.1.4:23000 to send the video to the 192.168.1.4 box, which is a windows machine, using VLC on the windows machine I'm telling it to play udp://127.0.0.1:23000 but it's not displaying anything. What am I doing wrong? [20:27:27 CEST] <ChocolateArmpits> DapOrp, did you try using the machine's IP for playback? [20:29:32 CEST] <DapOrp> yes, telling vlc on the windows machine to play: udp://192.168.1.4:23000 displays nothing. [20:36:11 CEST] <keglevich> JEEB, furq: you were completely right...th ffmpeg 4.0.2 on ubuntu runs flawlessly...it's been running now with UDP bitrate ptrheads output parameter for 25+mins...on windows it crashes in 2-3mins, so I can confirm...on linux it works perfectly! [20:36:27 CEST] <keglevich> and the output is real CBR; as it should be! [20:36:39 CEST] <ChocolateArmpits> DapOrp, are the ports open ? [20:36:59 CEST] <keglevich> now I'm wondering...it there an issue in ffmpeg code for windows, or it was just bad mingw compiler as you mentioned before? [20:37:55 CEST] <ChocolateArmpits> keglevich, *psst* try msys2 [20:38:30 CEST] <keglevich> is there an "easy" way to cross-compile ffmpeg 4.0.2 x86 shared windows builds on ubuntu linux? [20:38:45 CEST] <keglevich> pthreads enabled of course [20:41:23 CEST] <JEEB> keglevich: since the code in FFmpeg is the same I would guess an issue with the pthreads wrapper lib :P [20:41:48 CEST] <JEEB> for cross compilation I dunno. try installing the mingw-w64 cross-toolchain packaged with your distro? [20:42:06 CEST] <furq> apt-get install mingw-w64; ./configure --cross-prefix= [20:42:14 CEST] Last message repeated 1 time(s). [20:42:14 CEST] <furq> dfssd [20:42:18 CEST] <JEEB> and then you'll have to install the mingw-w64 pthreads thing if you need pthread_cancel [20:42:30 CEST] <JEEB> that's usually packaged as well in ubuntu [20:42:32 CEST] <furq> apt-get install mingw-w64; ./configure --cross-prefix=x86_64-w64-mingw32 --target-os=mingw32 --disable-w32threads [20:43:30 CEST] <furq> the mingw-w64 pthread stuff is included as standard now afaik [20:43:39 CEST] <furq> at least i never had to install anything separate on debian [20:43:43 CEST] <JEEB> ok [20:44:26 CEST] <furq> i guess you also want --extra-ldflags="-static --static-libgcc" [20:44:37 CEST] <furq> it's been too long since i dug into this to remember why i use that [20:45:00 CEST] <JEEB> probably because gcc/ld prefer shared libs if only available [20:45:10 CEST] <JEEB> so you end up with something gcc dot dll dependencies [20:45:10 CEST] <furq> i meant the static-libgcc thing specifically [20:45:17 CEST] <furq> right [20:45:23 CEST] <furq> obviously you'll also need to crosscompile x264 but that's fairly easy iirc [20:46:24 CEST] <furq> libx264 should just be ./configure --host=x86_64-w64-mingw32 --cross-prefix=x86_64-w64-mingw32- [20:49:25 CEST] <keglevich> ok, I'll dig into it... if I won't be able to finish it, I'll kindly ask for more help [20:49:43 CEST] <keglevich> and again...it's running now 35+mins without a single hiccup, multiple instances, all ok [20:49:51 CEST] <furq> the mingw stuff on debian/ubuntu is pretty simple [20:50:27 CEST] <furq> just to be clear the ffmpeg configure line should be ./configure --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 --disable-w32threads --enable-libx264 --extra-ldflags="-static --static-libgcc" [20:50:36 CEST] <keglevich> what about this one: https://github.com/rdp/ffmpeg-windows-build-helpers [20:51:02 CEST] <furq> never tried it [20:51:14 CEST] <furq> i wrote my own thing but apparently i haven't updated it since 2015 so it probably doesn't work any more [20:51:26 CEST] <furq> good work furq [20:54:33 CEST] <DapOrp> I made a new rule in windows for port 23000 and added 23000 to the iptables in the linux machine and they still won't stream to each other. [20:57:11 CEST] <JEEB> keglevich: there's a general tutorial on the trac's wiki most likely :P [20:57:26 CEST] <JEEB> although I guess not for cross-compilation :P [21:10:40 CEST] <DapOrp> really not understanding what's going wrong here. I even turned off the windows firewall altogether and it still won't send the stream to it, or VLC isn't catching it.. one or the other. [21:11:46 CEST] <ChocolateArmpits> DapOrp, does it work if you send it from the other side? [21:11:53 CEST] <ChocolateArmpits> DapOrp, what about localhost? [21:12:48 CEST] <DapOrp> I have not attempted to send anything from the windows machine to linux. only the other way around. [21:12:57 CEST] <DapOrp> localhost in linux works just fine. [21:15:53 CEST] <ChocolateArmpits> DapOrp, the network works otherwise? [21:16:34 CEST] <DapOrp> yeah the network is fine. these two see and talk to each other through SSH no problem, even SMB, but trying to do this ffmpeg stream out from the .3 to the .4 machine just isn't doing anything. [21:19:56 CEST] <ChocolateArmpits> DapOrp, what about sending the output the IP of the Linux machine and have Windows grab the stream from that? [21:20:03 CEST] <ChocolateArmpits> to the ip* [21:21:29 CEST] <DapOrp> so tell ffmpeg -f mpegts "udp://192.168.1.3:23000" and vlc: udp://192.168.1.3:23000 ? [21:22:44 CEST] <ChocolateArmpits> ye [21:23:03 CEST] <DapOrp> doesn't seem to be working that way either. [21:26:47 CEST] <w1kl4s> sorry to ask in middle of something, but how should i take a screenshot that includes subtitles from a stream? [21:27:59 CEST] <w1kl4s> for now i used something like that: [21:27:59 CEST] <w1kl4s> ffmpeg -ss 00:43:38.240 -i vid.mkv -vframes 1 -s 1920x1080 -c:v png -pix_fmt rgb24 output.png [21:28:23 CEST] <w1kl4s> i tried to mess with -map and -c:s but nothing really came out of it [21:45:58 CEST] <DapOrp> WTF?!?! it's VLC... version 3.0 has issues with this for some reason.. [21:46:06 CEST] <DapOrp> https://forum.videolan.org/viewtopic.php?t=143133 [21:46:19 CEST] <DapOrp> no solution, but downgraded to version 2.x and now it works just fine.. wtf!?... [21:51:26 CEST] <DapOrp> this kind of shit makes me want to start smoking again.. grr.. thanks for your assistance ChocolateArmpits. [23:51:32 CEST] <killown> should this work? ffmpeg -i "concat:1.mp4|2.mp4|5.mp4|6.mp4|7.mp4|9.mp4|10.mp4|12.mov" -c copy output.mp4 [23:51:43 CEST] <killown> output is only 1.mp4 [23:51:50 CEST] <killown> what is wrong? [00:00:00 CEST] --- Mon Oct 8 2018

1 0

ffmpeg-devel.log.20181006
by burek 07 Oct '18

07 Oct '18

[01:12:21 CEST] <alexmarkley> i'm trying to control camera input parameters, such as framerate, resolution, and pixel format... examples show setting those options via av_set_dict() and passing the dictionary into avformat_open_input() [01:12:45 CEST] <alexmarkley> is this correct? it seems to have no effect for me [01:13:00 CEST] <alexmarkley> the input format is video4linux2 [01:13:46 CEST] <alexmarkley> also, av_dict_count() reports 0 after avformat_open_input() which i think means that it recognized all of the options [01:15:59 CEST] Action: kierank tries to figure out how frame properties are obtained in threaded h264 [01:32:12 CEST] <jamrial> "uncut console output pls (2)" [01:38:07 CEST] <alexmarkley> if somebody could even point me to the relevant documentation that would be helpful [01:39:14 CEST] <alexmarkley> i'm having a lot of trouble following ffplay.c to see how it handles, (eg.) video_size [01:53:32 CEST] <jamrial> alexmarkley: documentation is in https://ffmpeg.org/documentation.html, but it may be lacking [01:53:45 CEST] <jamrial> and api usage questions go in #ffmpeg, not here [01:53:57 CEST] <alexmarkley> oh my bad, i misread the topic [01:54:06 CEST] <alexmarkley> thanks for the pointer [05:41:33 CEST] <philipl> BtbN: My 2080ti arrived today. Supports HEVC 4444 decoding. [09:27:27 CEST] <nevcairiel> philipl: i read that it would, but did they actually add a chroma format for that to any of the APIs? [11:17:01 CEST] <BtbN> It probably works like all the other formats, and it just outputs NV12? [11:17:08 CEST] <BtbN> Pr P016 at best [11:21:55 CEST] <nevcairiel> so practically useless then [11:22:41 CEST] <nevcairiel> I understand why they support 444 encode, its for their streaming tools, but decode into subsampled chroma seems a bit weird [11:37:45 CEST] <atomnuker> true, considering doing the conversion and subsampling on the encoding side would be faster [13:05:11 CEST] <cone-826> ffmpeg 03Jun Zhao 07master:ab9349e664f1: lavfi/deshake: fix deshake crash issue. [13:18:00 CEST] Last message repeated 1 time(s). [13:40:00 CEST] Last message repeated 1 time(s). [13:40:07 CEST] <JEEB> > same commit thrice [13:40:27 CEST] <durandal_1707> wtf? [13:40:42 CEST] <JEEB> note the same hash too, so it could just be the bot [13:41:00 CEST] <durandal_1707> lets kick him? [13:41:19 CEST] <JEEB> and what would that help with? [13:41:25 CEST] <durandal_1707> dunno [13:41:31 CEST] <JEEB> exactly [13:46:28 CEST] <cone-826> ffmpeg 03Jun Zhao 07master:ab9349e664f1: lavfi/deshake: fix deshake crash issue. [13:48:18 CEST] <durandal_1707> see ^ [13:50:12 CEST] <durandal_1707> actually bot is ok, looks like commit cant go in [13:50:33 CEST] <JEEB> yea I don't see it in the repo [13:51:13 CEST] <durandal_1707> really, what is going on? [13:51:24 CEST] <nevcairiel> maybe a hook is refusing it, and instead of fixing it, he is just trying again and again =p [13:51:37 CEST] <durandal_1707> but bot should be silent.... [13:52:02 CEST] <JEEB> it's probably pre-hook or something [13:57:19 CEST] <jkqxz> There is something wrong, I think. Trying to push seems to hang at the point when the remote has been sent the change - I've been sitting there for several minutes. [13:57:34 CEST] <jkqxz> Maybe the bot message will appear when it times out, or something? [13:58:03 CEST] <durandal_1707> ugh, right, same happened to me [13:58:43 CEST] <durandal_1707> but my patches got in [14:05:58 CEST] <jkqxz> "remote: send-mail: Connection lost in middle of processing" "remote: Can't send mail: sendmail process failed with error code 1" [14:06:31 CEST] <JEEB> right, if it's the sendmail trigger at the end of the push? [14:06:43 CEST] <JEEB> for the ffmpeg-cvs or whatever the list was? [14:07:25 CEST] <jkqxz> It's still hung after giving that, too. [14:13:51 CEST] <cone-826> ffmpeg 03Mark Thompson 07master:6ff4473012bc: av1_metadata: Fix constraint on setting chroma_sample_position [14:14:20 CEST] <JEEB> that went through at least [14:15:29 CEST] <jkqxz> Taking ~20 minutes. [14:16:19 CEST] <JEEB> ouch [14:16:23 CEST] <JEEB> but at least not impossible [14:18:11 CEST] <jkqxz> Maybe it's two mail timeouts, each ten minutes? <https://0x0.st/sgH3.txt> [14:50:49 CEST] <JEEB> jkqxz: there was indeed an issue with e-mail and seems to be fixed now [15:30:58 CEST] <cone-826> ffmpeg 03Jun Zhao 07master:5a3ce4a92b84: lavfi/deshake: fix deshake crash issue. [16:00:59 CEST] <thardin> a friend tells me there's anime webms encoded with av1 in the wild. does that mean it's finally standardized or is some encoder jumping the gun? [16:03:07 CEST] <atomnuker> lol no, they're jumping the gun, no av1 in webm until google says so [16:04:17 CEST] <atomnuker> and even then, only webvtt subtitles [16:04:29 CEST] <JEEB> yea, everyone just thought av1 in matroska will be the thing picked by GOOG [16:04:41 CEST] <JEEB> except for now mp4 is the pick [16:05:14 CEST] <JEEB> so we might see av1 in mstroska, but whether GOOG puts the webm stamp on it is up in the air [16:08:52 CEST] <gnafu> Maybe it's just time for the "WebM" moniker to die. [16:12:02 CEST] <gnafu> Let "WebM" just mean "VPx", and then use AV1 in standard containers. [16:15:28 CEST] <thardin> that's what I suspected [16:16:01 CEST] <thardin> webm might be useful as it narrows down what an mkv file can be [16:22:48 CEST] <gnafu> But do we really want that anymore? I mean, sure it can be nice to know it "must" be using a free audio codec (and not someone putting AV1 and AAC into an MKV container), but I don't know we really need that distinction anymore. [16:24:02 CEST] <thardin> it might be helpful for that, yes. and for users, maybe [16:24:39 CEST] <thardin> but eventually you kind of get back to square one when old devices that can't be easily upgraded support "webm" but only say vp8 and vorbis, not av1 and opus [16:25:15 CEST] <thardin> you'd almost want it to be .web1 .web2 .web3 etc [16:25:29 CEST] <thardin> I dunno [16:28:56 CEST] <gnafu> Well, maybe .webm2. [16:29:30 CEST] <gnafu> Too many applications do weird things based solely on file extensions, though. [16:30:03 CEST] <thardin> I'm also reminded of mp4 ftyps [16:30:11 CEST] <gnafu> Honestly, I'm probably going to end up using AV1+Opus-in-MP4 :-P. [16:30:25 CEST] <gnafu> At the end of the day, nothing beats good ol' AVI. [16:30:38 CEST] <thardin> that's standardized? I recall mp4 being very picky [16:30:41 CEST] <thardin> mov on the other hand [16:31:20 CEST] <gnafu> thardin: I believe it is official now, yes. My understanding was that the final MKV spec for AV1 was waiting on the MP4 spec being finished, and I think both have happened now. [16:31:28 CEST] <gnafu> And Opus-in-MP4 is official. [16:32:40 CEST] <gnafu> Or maybe it hasn't reached "1.0": http://opus-codec.org/docs/opus_in_isobmff.html [16:33:15 CEST] <gnafu> But AV1 has: https://cdn.rawgit.com/AOMediaCodec/av1-isobmff/v1.0.0/index.html [16:35:28 CEST] <atomnuker> mp4 has no support for sane subtitles (and even then not exactly widespread for the insane ones) [16:36:17 CEST] <gnafu> And WebM is too restrictive, so I would expect people who care about subtitles to use Matroska. [16:39:20 CEST] <jamrial> google left the av1 in matroska definition to matroska people, and then they just used that for webm [16:40:16 CEST] <jamrial> which is a no brainer seeing the matroska spec was defined following the mp4 one [16:41:13 CEST] <jamrial> i think it's not finished-finished, but libaom was recently updated to be compliant with it [16:41:19 CEST] <jamrial> libwebm not so much [16:42:06 CEST] <durandal_1707> thardin: put them in jail! [16:53:10 CEST] <thardin> seven years! no trials! [16:58:46 CEST] <philipl> nevcairiel: Presumably until the next SDK update, there is no appropriate output format available. I did a brief attempt to see if it was undocumented but present but got errors back [16:59:22 CEST] <philipl> I tried asking it to output to P016 and it would decode but then the copy-out failed with errors implying the memory layout was mismatched. [16:59:43 CEST] <nevcairiel> but nv12 worked? [17:00:12 CEST] <philipl> I did not try. Perhaps I should. [17:03:09 CEST] <philipl> nv12 does seem to work (although I started with a 12bit 444 sample). [17:03:20 CEST] <philipl> At least it decodes and the initial copy works. [17:03:41 CEST] <philipl> The rest of the pipeline is currently reacting to the expected 444p12 format, but if I fixed that, I think it would display correctly [17:04:07 CEST] <philipl> So ok, it can downsample to nv12 but not to p016. [18:48:44 CEST] <philipl> nevcairiel: After more effort, there are undocumented 444 output formats and I can use them. Not sure what the layout is. [18:49:17 CEST] <philipl> This is where we again see nvidia using a YUV444P10 (or 12) format with the padding at the opposite end from what ffmpeg does. [18:49:32 CEST] <philipl> At least that's my suspicion [18:50:24 CEST] <atomnuker> yeah, it kinda sucked vulkan chose that format for most pixfmts [18:53:30 CEST] <atomnuker> which just made me notice VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 (p010) is also defined with padding in the LSBs so I have to remove yet another pixfmt from my hwcontext code [18:54:28 CEST] <philipl> yay... [18:54:45 CEST] <atomnuker> was the entire industry on paint tinners when they made this part of the spec? [18:55:42 CEST] <philipl> It's somehow better for the hardware? [18:57:12 CEST] <atomnuker> I think they do such shifts for free [19:06:29 CEST] <philipl> Hmm. So I'm also seeing the chroma planes seemingly misaligned. I'll probably be flailing around with this until they document the layout. [19:07:51 CEST] <atomnuker> misaligned chroma planes? I had issues with delayed chroma planes when I had the binary drivers with cuda [19:08:28 CEST] <philipl> Looks like the V plane is half a frame vertically misaligned. [19:08:31 CEST] <philipl> U plane looks correct. [19:09:03 CEST] <philipl> bingo. [19:09:10 CEST] <philipl> I did a manual offset adjustment and output looks correct. weird. [19:12:53 CEST] <philipl> I'm guessing there's something wrong in our copying code - we've not had 3 plane output from the decoder before. [19:48:24 CEST] <cone-793> ffmpeg 03Zhong Li 07master:21733b39d0af: lavu/qsv: fix a random hwupload failure regression [19:48:24 CEST] <cone-793> ffmpeg 03Mark Thompson 07master:1f1ec958f6c6: Merge commit '21733b39d0af5211d7b9f168ff3667ea86362e2b' [20:31:37 CEST] <cone-793> ffmpeg 03Paul B Mahol 07master:c98ffa086c5d: avfilter/avf_showspectrum: switch to activate and add fps option [00:00:00 CEST] --- Sun Oct 7 2018

1 0

ffmpeg.log.20181006
by burek 07 Oct '18

07 Oct '18

[01:56:54 CEST] <alexmarkley> hi, i'm trying to figure out how to affect webcam capture properties when doing avformat_open_input() [01:57:10 CEST] <alexmarkley> i'm trying something like this https://pastebin.com/uH2cv1Tr but it's not having the desired (or apparently any) effect [03:55:15 CEST] <alexmarkley> i'm still looking for a solution which allows me to tell video4linux2 to open the camera at a particular resolution [03:55:36 CEST] <alexmarkley> i must be missing something in the documentation [04:17:28 CEST] <alexmarkley> i'm seeing exactly what i want to do in the example on this page: http://ffmpeg.org/doxygen/trunk/group__lavf__decoding.html [04:17:33 CEST] <alexmarkley> but it's not working for me [08:26:16 CEST] <keglevich> ffmpeg -re -i 1.mp4 -g 50 -c:v libx264 -preset veryfast -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -ac 2 -b:a 192k -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316" [08:26:21 CEST] <keglevich> running the command above gives somehow CBR UDP multicast stream, but it's not perfect (lots of bursts, spikes, etc.), nothing similar to those generated by hardware encoders...is there anything I can do to improve it? [08:46:44 CEST] <freepoutine> did you mistype your bufsize? [08:48:28 CEST] <keglevich> hmm...I tried different values, from 80k, to 4000k, no difference really [08:49:21 CEST] <keglevich> lower value also helps keep stream a bit more CBR...bigger value more spikes and bursts [08:51:39 CEST] <keglevich> produced stream actually is CBR, but the issue is UDP output as it seems it sends packages as soon as they're available in some kind of bit-bursts...so it goes up and down like 2500k, 2700k, 2500k, 2700k, ..., etc. [09:53:16 CEST] <azaki> BtbN, ah, ok, thanks. i saw the av1 parser recently landed, so looks like it'll indeed make it into 4.1, that's sweet. [09:53:18 CEST] <azaki> =) [14:59:54 CEST] <ilushka4> Hey guys,I have no idea why my rtsp stream won't work. I tried asking in videolan forums but nobody responded. Here is the log: https://paste.ee/p/PilXq. Maybe it has to do with the codecs? [18:25:39 CEST] <keglevich> there are options like "bitrate" and "burst_bits" for UDP output.... if I set the "bitrate=260000", what's the suggested value for burst_bits? I can't find any info on that one... [19:21:04 CEST] <ilushka4> Hey guys,I have no idea why my rtsp stream won't work. I tried asking in videolan forums but nobody responded. Here is the log: https://paste.ee/p/PilXq. Maybe it has to do with the codecs? [19:21:51 CEST] <ilushka4> https://paste.ee/p/kp0DH (the link was broken) [19:23:37 CEST] <c_14> >Server returned 400 Bad Request [21:05:20 CEST] <w1kl4s> Hello, does anyone know if those issues are still around? [21:05:20 CEST] <w1kl4s> incorrectly uses BT.601 matrix for all content (results in wrong colors) [21:05:20 CEST] <w1kl4s> - colormatrix filter causes strong banding [21:05:20 CEST] <w1kl4s> - uses point upscaling for chroma planes and ordered dithering (low video quality) [21:06:49 CEST] <JEEB> w1kl4s: i think swscale does both bt709 and bt601 [21:07:29 CEST] <JEEB> but if you want high quality colorspace conversion then the zscale filter using the zimg library is what you want [21:07:56 CEST] <JEEB> i don't think even swscale by default uses point scaling for chroma tho [21:08:19 CEST] <JEEB> (swscale is used by the scale filter automagically) [21:08:32 CEST] <w1kl4s> I will be honest with you, you are speaking language of the gods to me [21:08:42 CEST] <w1kl4s> i have no idea about encoding and stuff, i am just a shitty dev [21:09:29 CEST] <w1kl4s> i wanted to make a program that compares videos with different sources, so ffmpeg was my best bet because it's avalaible on every system [21:09:36 CEST] <w1kl4s> but i found that on the wiki [21:09:49 CEST] <JEEB> basically, swscale has its issues but I don't think it's as bad as noted as long as you signal the colorspace correctly [21:10:01 CEST] <JEEB> oh, if you are doing static file comparison [21:10:20 CEST] <w1kl4s> yeah [21:10:23 CEST] <JEEB> look into vapoursynth and ffms2 [21:10:26 CEST] <w1kl4s> i wanted to pull out single frames [21:10:45 CEST] <durandal_1707> no, file comparison can be done with mpv [21:10:48 CEST] <JEEB> ffms2 is a wrapper around ffmpeg that is frame accurate [21:11:05 CEST] <w1kl4s> durandal_1707 i am using mpv right now gor that [21:11:07 CEST] <JEEB> it indexes the input [21:11:10 CEST] <w1kl4s> *for [21:11:20 CEST] <w1kl4s> but i wanted to make it automated [21:11:44 CEST] <w1kl4s> and MPV is kind of tricky to get stuff right without opening up interface [21:12:08 CEST] <w1kl4s> at least i didn't have any luck with that [21:13:07 CEST] <w1kl4s> JEEB i don't need indexed frames, timestamps will get the job done as well [21:14:14 CEST] <w1kl4s> i just wanted to know if those issues still persist for making screenshots using ffmpeg [21:14:20 CEST] <JEEB> the problem is that with not all containers are frame accurate in seeking. so even if you seek into a timestamp you might end up earlier or later [21:14:35 CEST] <JEEB> earlier not really a problem o 'course [21:14:52 CEST] <JEEB> since you can decode to the wanted timestamp [21:14:56 CEST] <w1kl4s> that shouldn't be a problem since i'm gonna be comparing diffrent sources anyway [21:15:04 CEST] <w1kl4s> so time diffrences are expected [21:16:24 CEST] <JEEB> also I'll say that some issues are still there but I think chroma and bt709/601 should be handled ok now? granted zscale will do it more fancily (or you can use zimg yourself due to the liberal license) [21:16:28 CEST] <JEEB> )6 [21:16:32 CEST] <w1kl4s> like i random a frame from source 1, get general timestamp of it, and using OpenCV i'll look for a frame that has highest similarity [21:16:40 CEST] <w1kl4s> and pull that one out [21:17:36 CEST] <durandal_1707> OpenCV ? what it does special? [21:18:34 CEST] <w1kl4s> well, look for proper frame to pull out [21:19:25 CEST] <durandal_1707> of all available? [21:19:25 CEST] <JEEB> i think marcan just used fft for that [21:20:10 CEST] <w1kl4s> no, i wanted to pull random frame from first source, and make openCV search like lets's say 5 seconds back and 5 seconds forth [21:20:43 CEST] <w1kl4s> pulled numbers out of my ass now, those will prolly need some fiddling to not make it sluggish as hell [21:20:54 CEST] <w1kl4s> while maintaining accuracy [00:00:00 CEST] --- Sun Oct 7 2018

1 0